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 の本に移るのが良さそうです。

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

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

SRE Advent Calendar 2018 の個人的おすすめ記事（おまけ：Mackerel Drink Up の話）

12月は色々ありました。今回はそのへんを雑多に振り返る記事です。

SRE Advent Calendar 2018 の個人的おすすめ記事

SRE Advent Calendar 2018 は、スタディストのかつひささんが企画したアドベントカレンダーです。1個目のカレンダーがすぐ埋まってしまったので、2個目（SRE 2 Advent Calendar 2018）も作られてました。僕も11日目に投稿しました。

qiita.com

qiita.com

1個目の方はみんなきっちり執筆して25日埋まってましたし、どちらも内容の濃い記事が多くてすごかったですね。

冬休みに入ったので、この機会に SRE Advent Calendar の記事を全部読み返して、個人的おすすめ記事をピックアップしてみました。どれも面白かったのですが、個人的にはいま SRE の組織体制に興味があるので、主にそのへんの記事に偏ってます。ご了承ください。

Day 10: DevOps文化の組織にSRE活動を導入した話

kusuwada.hatenablog.com

（記事を読み限りおそらく）過去5年かそれ以上の間に、

• 開発チームとインフラチームが分離していた体制
• 各開発チームにインフラメンバーを送り込む体制（DevOps 体制）
• インフラメンバーを組織横断で繋ぐSREを導入した体制（SRE 体制）

と組織体制を見直してきた現場での、それぞれの体制のメリット・デメリットをまとめた記事です。

最新の体制は、SRE チームと開発チームを兼務する SRE と、SRE チーム兼任の SRE（Core メンバー）を組み合わせたもののようです。これは是非参考にしたいと思いました。

Day 14: プロダクト横断のSREチームを組成したい話

qiita.com

オプトの渋谷さんによる記事。

渋谷さんは SRE Lounge #5 で SRE チーム立ち上げについての話をされてました。この記事は、その今後の展開についての話で、SRE が複数のプロダクトチームを横断して活動するように変えていきたいという構想についてのものです。

記事の最後の方にある「乗り越えるべき壁」のところは、僕もよくわかる悩みで……特に、プロダクトをまたぐことで「一人のSREが知るべき内容はすごく多岐に渡ってしまいそう」という点は、実際やってみた結果を是非お聞きしたいです。

ちなみに、

SREのマトリックス的な配置についてはヌーラボさんの取り組みを参考にしています

とのことで、参考にしてもらえて嬉しい！

Day 16: SLO設定/超過監視にまつわる活動の振り返り

www.m3tech.blog

エムスリーテックブログの記事。SLI の測定方法から、SLO 超過時のプロセスまで、具体的なユースケースが詳細にまとめられた良記事です。

SLO を超過したかどうかの検知から、超過した場合のチケット作成まで自動化されており、これから SLO を導入しようという人は必読かと思います。あと、elastalert（Elasticsearch にクエリ投げて結果によって通知するツール）については僕も知らなかったので、今度使ってみます……。

Day 4 (SRE 2): データ基盤をHadoopからBigQueryに移管するときのアンチパターン

yuzutas0.hatenablog.com

Hadoop のようなデータ基盤を持つサービスで、SRE が果たすべき役割に関する記事です。

この記事では、データを処理するフローの途中で組織が分かれていたために、データの欠損や不整合が発生してしまった自社事例を紹介しています。

各組織が「自分の見える範囲で手っ取り早く済ませよう」とした結果、そうなってしまったようです。ソフトウェア開発じゃなくて、データ基盤の開発でも「コンウェイの法則」が出てくることあるんですね……。

最終的に、このような問題を解決するには「プロダクト」と「分析」の間を取り持つ DataOps ロールが必要で、そのロールはシステム全体を最適化する部隊（つまり SRE）が担うべきと結論づけています。

Day 24: SRE風のインフラエンジニアにならないために

kenjiszk.hatenablog.com

はてブでバズってた記事。SREがどういうものかを知ってほしいときには、まずこのページを読んでもらおう！と思ったくらい、説明が必要十分で読みやすい記事でした。

ちなみに、この記事の分類に従うと、僕の今年の仕事は「インフラエンジニアではなくSREとしてどう高速リリースを実現するか」のところにずっと注力してました。CI の改善、リリースプロセスやリリース自動化ツールの改善、開発チームが監視に使えるツールの充実などなど……。

Day 25: [SRE Advent Calendar] SRE Advent Calendar 2018 を終えて

kths.hatenablog.com

企画者のかつひささんによるまとめ記事です。SRE Advent Calendar の全記事に一言コメントが付けられています。興味のある記事だけ読みたい人は、まずはここをざーっと読むのがいいかも。

ちなみに、この記事の最後に「@katsuhisa__的ベスト3」のコーナーがあって、そこで僕の書いた記事を1位に選んでくれていました。まったく予想してなかったのでびっくりしましたが、頑張って書いた甲斐がありました。ありがとうございます。

ヌーラボSREの吉澤さんのこちらの記事が、SRE Advent Calendar 2018 の@katsuhisa__ 的1位でした。

SREの文脈では、一般的に、SLI といえば、レイテンシやエラーレートを指すことが多いですが、この記事では、自社のチームの課題に焦点を当て、社内向けSLI を整備した話が書かれています。

私が登壇する資料では、度々「ウェブオペレーションは、技芸であり、科学ではない」（ by 『ウェブオペレーション ―サイト運用管理の実践テクニック』 ）という言葉を引用しますが、まさにこの記事の事例には、一種の技芸を感じました。

また、それ以外にもSREと組織構造にも詳しく触れられていて、今後も何回も読み返したくなるような内容でした。

SRE Advent Calendar 2018 に投稿した記事

で、この流れで僕が投稿した記事も紹介。SRE Advent Calendar 11日目の記事として、Backlog プロジェクトにて SRE メンバを中心に試してきたサービスレベル指標と、それぞれについて感じたメリット・デメリットをまとめました。

nulab-inc.com

9月の SRE Lounge #5 の講演では時間の都合で話せなかったネタがあって、年内にアウトプットするならこれがラストチャンスだ！と思って飛びついて、なんとか書き上げられました。結果的には、発表時間が1時間あっても足りなそうなくらいに分量が膨らみましたね……。

あまりにも泥臭すぎる内容だし、人によっては「この会社はレベルが低い」と思うのではないか……と思って、公開前には色々悩んで書いたり消したりしました。それでも最終的に公開したのは、SRE について考えるときには組織の話は外せないし、その具体的なケーススタディの価値は高い、と思うからでした。

SRE の組織体制は、この記事に書いたものが最終形ではなくて、来年以降も徐々に改善していくことになりそうです。半年〜1年後には、また新たな話ができると思います。

おまけ：Mackerel Drink Up の LT 発表

あと、この記事の公開日にちょうど Mackerel Drink Up #8 Tokyo というイベントがあり、Backlog での Mackerel 利用事例について発表しました。Advent Calendar の記事中にちらっと出てくる監視システムについて、もう少し詳しく話しています。

ゆううきさんが東京に来るということで講演を聞いて、色々お話もできてよかったんですが、その数日後に退職ブログが出てびっくりしました。

ゆううきさんが話していたことで、印象的だったのはこのあたりでした。

• 書籍「Webオペレーション」には、運用は技芸で科学ではない、という趣旨の文がある。しかし、個人的にはむしろ、技芸から科学へ進んでいると思ってる。一例として、reliability engineeringという分野が生まれてきている。
• チーム内に SRE がいると、Dev と Ops のトレードオフを取りやすい。チームが分かれているとそこがやりにくくなる（＝変更速度が下がる）のでは。同じチームに SRE がいることで、開発者と SRE の間で、お互いに業務を融通できるようになった。
• メルカリのアドベントカレンダーの記事にも、1つのチーム内で開発と運用に責任を持つという話があった（マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog）。いまのトレンドはその方向なのかも。

個人的に考えている SRE のあるべき姿と、ゆううきさんの話が近かったので、その点は勇気づけられました。運用が科学に進んでいる、という点は、僕はあまりそうは思わないのですが、そうであったら面白い、とも思うので、ゆううきさんの今後の活躍に注目したいと思います。