SRE Lounge のスピンオフで、議論中心の新しい勉強会 "SRE Session" への誘い

SRE Session とは？

SRE Lounge のスピンオフで、SRE Session という勉強会の第1回が4月10日に開催されました。

sre-lounge.connpass.com

SRE Session は少人数かつ全員参加型で議論するタイプの勉強会です。当日は議論が盛り上がり、参加者の反応も良かったので、おそらく SRE Session #2 が6月頃に開催されそうです。そこで、だいぶ遅れましたけど（3週間近く経ってる……）軽く感想をメモしておきます。

SRE Lounge には何度か参加していて、SRE Session にもちょっと興味あるけど参加しようかどうしようか……という方の参考になればと思います。

イベントレポート

SRE Session #1 の内容については、すでに充実したレポートが書かれているので、こちらを読んでもらえると大体の雰囲気がわかると思います。

blog.chaspy.me

SRE Session の発起人 @chaspy_ さんのレポート。Session #1 の会場は Quipper Ltd. さまに提供いただいたのですが、こちらも chaspy さんにお世話いただきました。感謝しかない……。

qrunch.net

いつも SRE Lounge でお世話になっているスタッフの ktykogm (k-oguma) さんのレポート。Welcome talk の内容から、oguma さんが参加されたグループでの議論内容まで詳しくまとめてくださっています。

SRE Session のスタイル

ここから先は、主に SRE Session という勉強会のスタイルの紹介と、それに対する僕の感想です。一応、今回スタッフとして参加したのですが、椅子運びくらいしかしていないので、一参加者の感想として読んでもらえれば。

第1回はこういうスタイルでした（第2回以降で改善されて変わる可能性はあります）。

事前アンケート

connpass での申込時に、今回のテーマ（SLO と Monitoring）に関するアンケートを取りました。

• SLOについて共有したい事例を記入してください
• SLOについてディスカッションしてみたいテーマを記入してください
• Monitoringについて共有したい事例を記入してください
• Monitoringについてディスカッションしてみたいテーマを記入してください
• その他この会に期待することを何でも教えてください

このアンケート結果は、スタッフが匿名化したうえで、事前に参加者全員に共有していました。今回、本編ではほとんど使わなかったですが、懇親会での話題のネタになっていました。

アンケートの記入は任意だったので、記入していたのは参加者の半分以下でした。ただ勉強会の性質上、議論のネタを持っている同士でないとつらいので、今後は記入必須になるかもです。

グループ分け

受付終了後に、いくつかのテーブルに散らばって座ってもらいました。

人数が少ないと議論が盛り上がりづらいため、3名のグループになってしまったところは他のグループに合流してもらい、最終的に4〜5名のグループを作りました。

テーマごとのサイクル

SRE Session #1 は "SLO" と "Monitoring" の2テーマでした。このテーマごとに、以下の35分のサイクルを繰り返しました。

• Welcome talk 10分
  • そのテーマに関する導入として、有識者の方のプレゼンを聞く
• Discussion 20分
  • 軽く自己紹介をしてから、テーマについて思うことを話し合う
• Sharing 5分
  • 各グループにマイクを回して、代表者1名が1〜2分で議論内容を紹介

Welcome talk

今回の Welcome talk は、Yahoo の tsuka さんと、メルカリの spesnova さんが担当してくれました。いずれも、このテーマだけで30分くらい話を聞きたいくらいの濃い内容でした。

SRE Session #1 from Minoru Tsuka

こちらの welcome talk の詳しい内容について興味の湧いた方は、ぜひ上述のイベントレポートをご覧ください。

Discussion

Welcome talk のあとは議論の時間。

グループによって進め方はいろいろ違ったと思うのですが、僕たちのグループでは最初に自己紹介をしてから、welcome talk で出たキーワードを拾って、それぞれが興味あることを話した感じでした。

ちなみに、参加者全員が SRE だったわけではなく、例えば僕たちのグループの内訳はこんな感じ。

• SRE 3名（自分含む）
  • ゲーム、アドテク、プロジェクト管理
• バックエンド寄りの開発者 2名
  • うち1名の会社は、これから SRE を作ろうとしている段階

一言で SRE と言っても、サービスの種類や規模や、その人の組織内での SRE の立ち位置など、いろいろ違うところがあるので自己紹介は重要そう。

Sharing

最後に、司会が各グループにマイクを持って回って、グループの代表者が1〜2分で議論の内容を紹介しました。

内容のまとめ方は今回特に指定されなかったので、ホワイトボードを使うグループ、SRE Lounge の Slack に書いていくグループ、各人が手元にメモしていくグループ（僕のグループはこれでした）などいろいろでした。

懇親会

最後に、1時間ほど懇親会の時間がありました。

議論中心のイベントだけあって懇親会で帰る人はほとんどおらず、テーマに沿って話が盛り上がったあとだったので、普段の勉強会以上に議論が盛り上がったのではないかと思います（※個人の感想です）。

感想

普段、他社の SRE と深い議論をする機会ってあまり無いので、特定のテーマに沿ってじっくりと議論するのは楽しかったです。良い会だったと思います。

なお、chaspy さんが SRE Session のまとめ記事 に書いていますが、この会は Cloud Native Deep Dive というイベントのやり方にインスパイアされたものらしいです。今回の勉強会が楽しかったので、そちらにもいずれ参加してみたいです。

以下、次回以降どうするともっと盛り上がるかな……と考えたことのメモです。

時間の長さ

開催前は、2テーマは多すぎるのでは？ 1テーマあたりの時間が短すぎないか？という議論もありました。

ただ、結果としては20分で少し足りないかちょうどよいくらいで、むしろこの倍の40分だったら場が保たずに辛かったかな、と思いました。

もう少し細かいテーマを設定すれば、もっと議論の時間が長くてもいいかもしれません。例えば、SLO のテーマであれば「組織内で SLO を決めるときに苦労していること」、「組織内で SLO をどのように、どれくらいの頻度で振り返るべきか」といったサブテーマをいくつか用意しておくとか……。

グループ分け

人数はこれくらいでよかったと思います。今回は5名上限でしたが、それ以上になると、1人あたりの話す時間が短くなりそうです。少なすぎても話に広がりがなくなるので、5〜6名がベスト？

あとは、参加者全員が SRE というわけではなかった（事前アンケートでそこまで聞いていなかったので当日気づいた）ので、グループ内に SRE の数が少ないと、その人の話を聞くだけになりそうです。

参加者が全員 SRE である必要はないと思いますけどね。個人的には、いずれ「SRE と開発者の関係」のようなテーマの回があってもいいんじゃないかと思っています。

とはいえ SRE の比率はある程度必要だと思うので、申込時に、SRE only 枠と自由枠で、募集枠を分けるとかしたほうがいいんでしょうか？　そのうえで、各グループで SRE の比率が偏らないようにするとか？

議論のまとめ方

今回は特に指定がなかった部分ですが、これは事前に決めておいたほうがよかったかもしれません。

全グループの分だけホワイトボードを用意できる会場は多くないと思うので、ポストイットのイーゼルパッドを用意しておくとか。

ポストイット イーゼルパッド 方眼入り 762×634mm 30枚x2冊セット EASEL 560

あるいは HackMD や Cacoo のような（手前味噌ですみません）、リアルタイムに共同編集ができるサービスを使うようにお願いしておくとか決めておくと良いかも。議論の内容が電子的にまとまっていると、イベントレポートで共有したり、振り返るのも楽になりますしね。

参加者の総数

Sharing の時間は、元々5分の予定でしたが、実際は1グループあたり1分以上かかっていました。グループの数が多くなりすぎると、Sharing の時間が長くなってつらそうです。

そう考えると、参加者の総数としては6名×6グループ=36名くらいがちょうどいいあたりでしょうか？

参加者の総数をこれくらいに少なめに抑えておいたほうが、会場提供のハードルが下がっていいんじゃないか？と個人的には思っています。

SRE Lounge のほうはすっかり人気イベントになって参加希望者が多くなり、この規模の会場を提供できる会社さんは少なくなってきています。ちなみに、次回5月29日の SRE Lounge #9 は、募集開始から1日で150名の枠が埋まってしまいました（すごい！！）。

sre-lounge.connpass.com

SRE Session のほうは、それよりもっと小さい会場を転々とできるといいなあと。30名程度なら、議論に使える小さめの会議室いくつかと、Sharing の時間だけ集まるセミナールーム1室くらいでギリギリ開催できそうですし。具体的には、うちの会社の東京事務所でもギリギリ開催できそうですし。

SRE Lounge の Slack ワークスペースへのお誘い

SRE Lounge は特定のスポンサーとか特に付いていない、コミュニティベースの勉強会です。

イベント開催情報なども早めに展開されますので、もし SRE Session にご興味のある方はぜひ srelounge.slack.com にご参加ください！　特定のテーマで開催してほしい！もっとこういうスタイルで議論したい！という熱烈な希望があれば #sresession チャンネルでアピールしてもらえると採用されるかも？

SRE Lounge #8 の感想（取り入れたいと思った活動の話を中心に）

今週の水曜に、クックパッド社にて SRE Lounge #8 が開催されました。今回も参考になるお話が多かったです。

ちなみに、会場はキッチン付きの勉強会スペースで、さすがクックパッド！という感じでした。

SRE Lounge会場、さすがクックパッドという感じ。キッチンがある！ #srelounge pic.twitter.com/iut4EdeIJp

— Masahiro Yoshizawa (@muziyoshiz) 2019年3月13日

ソラコムAPIの裏側で運用チームは何をやってきたのか

SRE Lounge #8 | ソラコムAPIの裏側で運用チームは何をやってきたのか from SORACOM,INC

SORACOM の OpsDev Manager 五十嵐さん（インタビュー記事）による発表。

OpsDev というのは DevOps の書き間違いではありません。SORACOM では開発チームがメンテナンスと運用の両方に関わり、OpsDev チームは運用作業省力化のための開発をするチームとのことです。

OpsDev チームが開発したロングセラーツールとして、以下のものが紹介されていました。

• 緊急時のみ SSH 接続を許可するための設定自動化
  • Slack に接続してきた開発者の IP アドレスを、Security Group に自動反映
  • CodeCommit に登録された公開鍵の、EC2 インスタンスへの自動配布
  • ログ取得（詳細は秘密でした）
• PagerDuty に似た、電話での通知の仕組み
  • Slack で /tel ニックネーム とすると強制的に電話を鳴らす
• 実際の移動体通信を監視するためのラズパイのタワー（ソラコム・サグラダ・ファミリア）

質疑応答の中で面白いと思ったのは、SORACOM の他の社員の方が「SORACOM ではエンジニアが開発、運用、サポートまで見るので、サポートが一人負けするようなシステムにはならない」と言っていたこと。開発と運用が一体なのは当たり前、という感じで、素直にうらやましいと思いました（個人的にはいつも悩んでいるところなので……）。ただ、基本的に開発者向けのサービスだからできる話かもしれません。

「開発チームの中に開発担当と運用担当ができてしまうのでは？」という鋭い質問もありましたが、「まだ、両者を分けられるほどエンジニアの人数がいない。開発した人が一番早く直せるというポリシーでやっている」とのことでした。

Cookpad Microservice Architecture Overview

クックパッドの技術部 SRE グループの吉川さん（@rrreeeyyy）による発表。

2013年頃からマイクロサービス化に取り組んできて、一進一退しつつ進んできたという話でした。開発者との恊働の話がいくつか出てきました。

例えば、今までは大統一 Terraform を作っていたが、これだと開発者にとってはプルリクを投げづらい。今後はチームごとにディレクトリを分けて、そのディレクトリ内の変更はチームの責任で実施できるようにしたいと思っている、など。

各サービスのチームを巻き込んだ SLI/SLO の導入はまだこれからで、今後の課題とのことでした。

最近、既存サービスのマイクロサービス化について悩んでいたので、懇親会でマイクロサービス化の良い進め方について相談しました。以下はそのときのメモです。

• モノリシックなサービスの一部をマイクロサービスとして切り出したいとしても、最初は新しいサービスでマイクロサービスの作り方を確立して、開発者自身が自信を付けてからにするのがいい
• データの切れ目でサービスを分割するといい。例えばクックパッドなら、レシピのデータとユーザのデータは別のもの（レシピの作成者としてユーザ ID が入る程度）なので、そこで分割するとか
• 作業が SRE だけでほぼ完結するから、データベースの分割からやるのがやりやすいかもしれない。データベースをレプリケーションして、あるタイミングで writer をバタンと切り替える

ちなみに、マイクロサービス化は開発者のほうがモチベーションが高く、運用側から説き伏せて、みたいなことは全然なかったそうです。

割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話

はてなの id:hokkai7go さんによる発表。プレゼン資料に加えて、以下のブログ記事で詳細が補足されていました。

blog.hokkai7go.jp

10名程度のはてな SREs（共通基盤）チームで実施中の活動で、以下のようにやっているそうです。

• 割れ窓（技術的負債）を見つけたら issue を作成して記録
• 取り組みやすそうな issue を「週刊割れ窓マガジン」という記事にリストアップ
• 週に一度、1時間の作業時間を取る（2時間だとダレた。現在は1.5時間に伸ばす試みをしてる）
• 振り返りやすいよう、終わった issue はスプレッドシートで一覧にしておく

僕は勝手に、開発者も入ってる活動なのかな……と思いながら聞いてたのですが、SRE だけでやっている活動とのこと。最低でもチームの半分くらいは集まって実施するそうです。

SRE の活動のなかで、SLO には現れないけど重要な、運用の品質とでも言うべきものはあると思っていて、最近こういうブログ記事を書いたりしてました。

muziyoshiz.hatenablog.com

はてなの他の取り組みで、PWG（Performance Working Group）という活動も以前聞いたことがあって、自社でも少し実施し始めています。この PWG と併せて、割れ窓タイムも導入してみたいと思いました。

次回の SRE Lounge

次回は5月に、サイバーエージェントで開催予定とのことです。

また、SRE Lounge とは違う、特定のテーマに沿ったディスカッションの場として「SRE Session」というイベントが新たに企画されています。初回は 4/10 で、テーマは SLO と Monitoring です。テーマに興味のある方はこちらも是非どうぞ。

sre-lounge.connpass.com

SRE はサービス品質に影響しない程度の異常をどう扱うべきか？

今回の記事は、最近考えていたことのメモです。

ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。

障害と異常の定義

話の前に、障害（failure）および異常（anomaly）という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。

• 障害：サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント
• 異常：サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント

この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。

これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった（例えば10秒以上になった）場合は障害です。

一方、サーバが1台だけダウンしたものの、ロードバランサのヘルスチェック機能によって、ダウンしたサーバは自動的に切り離されたとします。その結果、ユーザにはほとんどサーバダウンが気づかれなかったとしたら、それは異常です。

障害は計測しやすく、対応しやすい

障害は、その定義からして、明確なユーザ影響が出るため、測定しやすいです。

SRE は、障害の発生度合いを表すサービスレベル指標（SLI）を定義します。例えば、サービスのダウンタイムであったり、リクエストの成功率、応答時間の95パーセンタイルなど。

また、SLI を定義したら、最低限満たすべき SLI の目標値も設定します。例えば、サービスのダウンタイムは1ヶ月あたり3.6時間、など。その目標値はサービスレベル目標（SLO）と呼ばれます。

SLO に限らず、目標値というものは「ここまで頑張らないといけない」高い目標を示すものですが、逆に言うと「ここまでは手を抜いてもいい」下限と考えることもできます。

SLO を「開発・リリースの速度を上げるために、ここまでは手を抜いていいという下限」と捉えたものが、SRE 本で紹介されて有名になった「エラーバジェット」という考え方です。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

障害は、もちろん良くないものですが、それだけに計測しやすいものです。また、エラーバジェットという考え方を導入することで、チームとしての対応を議論することができます。

異常は計測しにくい、対応しにくい

その一方で、異常はその種類が無数にあり、サービスへの影響度合いも分かりづらく、測定しにくいものです。

上で挙げたアプリケーションサーバの例でいうと、例えばこういうものが異常です。

• OSやミドルウェアのメトリクスの異常な動き
  • 例：サーバの CPU 利用率が、よくわからないタイミングで 100% まで急上昇する。ロードバランサからすぐ切り離されるから、エラーになるリクエスト数は少ない。
• 普段は出ないエラーログ、あるいは普段とは違うログ件数
  • 例：通常時は出ないログが、時々頻繁に出る。特定のユーザが入力を間違えたときに出るログのはずだが、なにかそれを引き起こす原因があるのかもしれない。
• 普段とは違うサービスの利用状況
  • 例：アクセス数が普段よりも急激に増えている。ユーザの繁忙期で一時的に増えているだけかもしれないが、今後もこのまま増え続けることを想定したシステム増強が必要かもしれない。

もちろんこれらを SLO に含めることもできます。

とはいえ、SLO の数を増やしすぎると SRE にとってチェックしきれるものではなくなります。サービス影響に直結しないので、チームの方針を決めるためのエラーバジェットとしても説得力は得にくいでしょう。

異常の数が増えていくと、いずれ深刻な障害につながる（かも）

異常の原因調査に割く時間がないので、とりあえずサーバリソースを増やして時間稼ぎをする、という経験は自分にも何度かあります。

あるいは、エラーバジェットを導入している現場なら「障害にまで発展してから、エラーバジェットの範囲内で対応したら？」と考える人もいるかもしれません。

しかし、それぞれの異常がバラバラのタイミングで起きているときは良くても、それらの異常がいくつか同時に発生したタイミングで大きな障害につながる、という可能性を自分はどうしても心配してしまいます。例えば、サーバ1台が突然ダウンする問題があるなら、サーバ3台が同時にダウンすることもあり得るだろう、という心配です。

そういう、サービス品質に影響しない程度の異常については、どう扱うべきなのでしょうか？

あるいは、それが実態の伴わない不安だとして、なにか「エラーバジェット」のような仕組みでうまく解消できるものなのでしょうか？

もやもやと考えていること

最初に書いた通り、この疑問に対する結論はまだありません。ただ、現時点でなんとなく考えていることだけメモしておきます。

メトリクスやログを見て回って、人手で異常を探すのは難しい……というか費用対効果が悪すぎて時間を割けません。なので、原因調査をすべき異常があったときだけ、何らかのアラートが欲しい。

アラートを設定するにしても、

• 何を監視すべきなのか
• 閾値をどう設定すべきなのか

という問題があります。これは異常検出（anomaly detection）や傾向分析（performance prediction）と呼ばれる技術の領域です。機械学習で、完全に設定ゼロで導入できたりしたら素晴らしいですが、そこまで実現できている現場ってあるんでしょうか……？

ちなみに、「未知のログが一定数以上発生した場合だけ、日次でレポートを送信する」といった単純な異常検出であれば、ツールを自作すればできるのでいまの現場にも導入しています。実際に使ってみると、その程度でも意外と役に立つものです。ただ、やはり障害のアラートほど重要ではないので、忙しいときは無視されがちではあります。

あるいは、異常が多いと感じるなら、それは異常の数よりも、ソフトウェアメトリクスやテストの量など、コードの品質の方を見たらいいんでしょうか。そういう、遠回りに感じるものの、障害・異常とは別の観点で見るべき話なんでしょうか？

なにかもうちょっとまとまった話が書けそうになったら、そのうちまた書きます。

「入門 監視」を読みました

入門 監視 ―モダンなモニタリングのためのデザインパターン

あまりにシンプルなタイトルで話題になっていた「入門 監視」を読みました。

プログラミング本で言うと「リーダブルコード」くらいの判型と厚さでサッと読めて、自分たちがやっている監視を見直すきっかけになる良書でした。

内容の簡単な紹介と、個人的な感想（というか読みながら考えたこと）をメモしておきます。

内容の簡単な紹介

本書は二部構成です。

前半（第I部「監視の原則」）では、「監視」を考えるときに出てくる基本的な用語の解説と、監視でやりがちなアンチパターンとその逆（デザインパターン）が手短にまとめられています。メトリクス、ログ、インシデント管理といった基本的な用語から、中央値やパーセンタイルといった監視ツールでよく出てくる統計用語まで触れているので、いままで監視に関わっていないようなエンジニアでも読みやすいと思います。

後半（第II部「監視戦略」）では、いくつかの章に分けて、具体的な監視項目と、そのために使える手段を解説しています。本書の良いところは「ユーザ視点での監視」の重要性が強調されているところで、章の並び順もそうなっています。

• ビジネスを監視する（5章）
  • ビジネス KPI（月次経常利益など）や、コア機能が利用される頻度など
• フロントエンド監視（6章）
  • 実際のユーザが見ているページのロード時間など
• アプリケーション監視（7章）
  • アプリケーションのメトリクス・ログ、ヘルスチェック、分散トレーシング
• サーバ監視（8章）
  • OS のメトリクス、SSL 証明書、Web、データベースなどなど
• ネットワーク監視（9章）
  • SNMP の基本的な解説など
• セキュリティ監視（10章）
  • コンプライアンス規制を満たしていることを監視で確認する例

本書では全体を通して、監視の SaaS サービスを活用することを推奨しています。本書の付録には Mackerel プロダクトマネージャの @songmu さんによる「実践 監視 SaaS」がついていて、監視 SaaS を使ったことがない人向けのよい入門になっています。

感想

ビジネスに関する監視をもっと増やしてみたくなる

ユーザ視点での監視が重要、というのは常識として理解しているつもりでしたが、本書でビジネス KPI の話が最初に来たのはちょっと驚きました。

また、コア機能の利用頻度については、Yelpの例では「検索実行」「レビュー投稿」などの回数が監視対象に挙げられてました。ビジネス KPI はキャパシティプランニングにも直結するところなので、継続的に追うのは重要ですよね。

いまの現場でも運用コストについてはある程度可視化されているのですが（参考：re:dashでAWSのコストを分析してみた）、ビジネスに関する監視をもっと増やしてみたくなりました。

クラウドサービス前提の話はほとんどない

本書全体を通して、AWS や GCP に関する話はほとんどありませんでした。監視の基本は変わらないから、あえて触れていないのだろうと思います。

AWS などのクラウドサービスを使う場合、CloudWatch のようなビルトインの監視サービスが使えることと、ネットワークが抽象化されているので本書の「ネットワーク監視」の範囲はあまり関係ない、というくらいでしょうか。

分散トレーシングの監視は難しい

マイクロサービスと分散トレーシングについては、7章「アプリケーション監視」のなかに含まれていました。本書の著者は、分散トレーシングは非常に時間と労力がかかるので、他の手段で監視できるならそちらを用いるべき、というスタンスでした。

分散トレーシングは、正しく実装するのは非常に難しく時間がかかる監視の仕組みであり、業界内の一部でだけ役に立つものです。分散トレーシングは根気がない人や、スタッフ不足だったり過労気味のエンジニアリングチームには向いていません。必要なメトリクスやログはすべて取得していて、それでも分散システムにおけるサービス間のパフォーマンスを把握したりトラブルシューティングをするのに困るようなら、分散トレーシングを使うべきかもしれません。（p.106）

確かに、Zipkin を導入するためのコスト（監視システム側の構築・運用の複雑化に加えて、アプリケーション開発者での配慮も必要になる）が、そこから得られるメリットに見合うかどうかは、場合によるだろうなあと思います……。

監視システムの開発・維持は本書の対象外

本書を読んでいると監視を改善するアイディアはいろいろ浮かびますが、一度監視項目を設定しても、サービスを開発・運用していると状況は色々変わって、実態に合わなくなるものです。この監視の仕組み、システムをどう開発・維持するかは本書の対象外で、そこから先に興味を持ったら DevOps や SRE の本に移るのが良さそうです。

ともあれ、いろいろ考え直すきっかけになる良書でした。

入門 監視 ―モダンなモニタリングのためのデザインパターン