Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。今回も参考になるお話が多かったです。ちなみに、会場はキッチン付きの勉強会スペースで、さすがクックパッド!という感じでした。Lounge会場、さすがクックパッドという感じ。五十嵐さん(インタビュー記事)による発表。書き間違いではありません。チームは運用作業省力化のための開発をするチームとのことです。チームが開発したロングセラーツールとして、以下のものが紹介されていました。エンジニアが開発、運用、サポートまで見るので、サポートが一人負けするようなシステムにはならない」と言っていたこと。開発と運用が一体なのは当たり前、という感じで、素直にうらやましいと思いました(個人的にはいつも悩んでいるところなので......)。基本的に開発者向けのサービスだからできる話かもしれません。「開発チームの中に開発担当と運用担当ができてしまうのでは?」という鋭い質問もありましたが、「まだ、両者を分けられるほどエンジニアの人数がいない。開発した人が一番早く直せるというポリシーでやっている」とのことでした。グループの吉川さん(@rrreeeyyy)による発表。2013年頃からマイクロサービス化に取り組んできて、一進一退しつつ進んできたという話でした。開発者との恊働の話がいくつか出てきました。作っていたが、これだと開発者にとってはプルリクを投げづらい。今後はチームごとにディレクトリを分けて、そのディレクトリ内の変更はチームの責任で実施できるようにしたいと思っている、など。導入はまだこれからで、今後の課題とのことでした。最近、既存サービスのマイクロサービス化について悩んでいたので、懇親会でマイクロサービス化の良い進め方について相談しました。以下はそのときのメモです。モノリシックなサービスの一部をマイクロサービスとして切り出したいとしても、最初は新しいサービスでマイクロサービスの作り方を確立して、開発者自身が自信を付けてからにするのがいいデータの切れ目でサービスを分割するといい。完結するから、データベースの分割からやるのがやりやすいかもしれない。切り替えるちなみに、マイクロサービス化は開発者のほうがモチベーションが高く、運用側から説き伏せて、みたいなことは全然なかったそうです。プレゼン資料に加えて、以下のブログ記事で詳細が補足されていました。SREs(共通基盤)チームで実施中の活動で、以下のようにやっているそうです。「週刊割れ窓マガジン」という記事にリストアップ週に一度、1時間の作業時間を取る(2時間だとダレた。やっている活動とのこと。最低でもチームの半分くらいは集まって実施するそうです。現れないけど重要な、運用の品質とでも言うべきものはあると思っていて、最近こういうブログ記事を書いたりしてました。Group)という活動も以前聞いたことがあって、自社でも少し実施し始めています。併せて、割れ窓タイムも導入してみたいと思いました。Lounge次回は5月に、サイバーエージェントで開催予定とのことです。Session」というイベントが新たに企画されています。テーマに興味のある方はこちらも是非どうぞ。SLO今回の記事は、最近考えていたことのメモです。ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。話の前に、障害(failure)および異常(anomaly)という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。障害:サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント異常:サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデントこの定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった(例えば10秒以上になった)場合は障害です。サーバが1台だけダウンしたものの、ロードバランサのヘルスチェック機能によって、ダウンしたサーバは自動的に切り離されたとします。その結果、ユーザにはほとんどサーバダウンが気づかれなかったとしたら、それは異常です。障害は計測しやすく、対応しやすい障害は、その定義からして、明確なユーザ影響が出るため、測定しやすいです。障害の発生度合いを表すサービスレベル指標(SLI)を定義します。サービスのダウンタイムであったり、リクエストの成功率、応答時間の95パーセンタイルなど。サービスのダウンタイムは1ヶ月あたり3.6時間、など。その目標値はサービスレベル目標(SLO)と呼ばれます。限らず、目標値というものは「ここまで頑張らないといけない」高い目標を示すものですが、逆に言うと「ここまでは手を抜いてもいい」下限と考えることもできます。本で紹介されて有名になった「エラーバジェット」という考え方です。見る障害は、もちろん良くないものですが、それだけに計測しやすいものです。エラーバジェットという考え方を導入することで、チームとしての対応を議論することができます。異常は計測しにくい、対応しにくいその一方で、異常はその種類が無数にあり、サービスへの影響度合いも分かりづらく、測定しにくいものです。上で挙げたアプリケーションサーバの例でいうと、例えばこういうものが異常です。ロードバランサからすぐ切り離されるから、エラーになるリクエスト数は少ない。例:通常時は出ないログが、時々頻繁に出る。特定のユーザが入力を間違えたときに出るログのはずだが、なにかそれを引き起こす原因があるのかもしれない。例:アクセス数が普段よりも急激に増えている。ユーザの繁忙期で一時的に増えているだけかもしれないが、今後もこのまま増え続けることを想定したシステム増強が必要かもしれない。含めることもできます。とってチェックしきれるものではなくなります。サービス影響に直結しないので、チームの方針を決めるためのエラーバジェットとしても説得力は得にくいでしょう。異常の数が増えていくと、いずれ深刻な障害につながる(かも)異常の原因調査に割く時間がないので、とりあえずサーバリソースを増やして時間稼ぎをする、という経験は自分にも何度かあります。エラーバジェットを導入している現場なら「障害にまで発展してから、エラーバジェットの範囲内で対応したら?」と考える人もいるかもしれません。それぞれの異常がバラバラのタイミングで起きているときは良くても、それらの異常がいくつか同時に発生したタイミングで大きな障害につながる、という可能性を自分はどうしても心配してしまいます。サーバ1台が突然ダウンする問題があるなら、サーバ3台が同時にダウンすることもあり得るだろう、という心配です。いう、サービス品質に影響しない程度の異常については、どう扱うべきなのでしょうか?あるいは、それが実態の伴わない不安だとして、なにか「エラーバジェット」のような仕組みでうまく解消できるものなのでしょうか?もやもやと考えていること最初に書いた通り、この疑問に対する結論はまだありません。現時点でなんとなく考えていることだけメモしておきます。メトリクスやログを見て回って、人手で異常を探すのは難しい......というか費用対効果が悪すぎて時間を割けません。原因調査をすべき異常があったときだけ、何らかのアラートが欲しい。何を監視すべきなのか閾値をどう設定すべきなのかという問題があります。prediction)と呼ばれる技術の領域です。機械学習で、完全に設定ゼロで導入できたりしたら素晴らしいですが、そこまで実現できている現場ってあるんでしょうか......?ちなみに、「未知のログが一定数以上発生した場合だけ、日次でレポートを送信する」といった単純な異常検出であれば、ツールを自作すればできるのでいまの現場にも導入しています。実際に使ってみると、その程度でも意外と役に立つものです。障害のアラートほど重要ではないので、忙しいときは無視されがちではあります。異常が多いと感じるなら、それは異常の数よりも、ソフトウェアメトリクスやテストの量など、コードの品質の方を見たらいいんでしょうか。いう、遠回りに感じるものの、障害・異常とは別の観点で見るべき話なんでしょうか?なにかもうちょっとまとまった話が書けそうになったら、そのうちまた書きます。プログラミング本で言うと「リーダブルコード」くらいの判型と厚さでサッと読めて、自分たちがやっている監視を見直すきっかけになる良書でした。内容の簡単な紹介と、個人的な感想(というか読みながら考えたこと)をメモしておきます。前半(第I部「監視の原則」)では、「監視」を考えるときに出てくる基本的な用語の解説と、監視でやりがちなアンチパターンとその逆(デザインパターン)が手短にまとめられています。メトリクス、ログ、インシデント管理といった基本的な用語から、中央値やパーセンタイルといった監視ツールでよく出てくる統計用語まで触れているので、いままで監視に関わっていないようなエンジニアでも読みやすいと思います。後半(第II部「監視戦略」)では、いくつかの章に分けて、具体的な監視項目と、そのために使える手段を解説しています。本書の良いところは「ユーザ視点での監視」の重要性が強調されているところで、章の並び順もそうなっています。サービスを活用することを推奨しています。使ったことがない人向けのよい入門になっています。話が最初に来たのはちょっと驚きました。コア機能の利用頻度については、Yelpの例では「検索実行」「レビュー投稿」などの回数が監視対象に挙げられてました。キャパシティプランニングにも直結するところなので、継続的に追うのは重要ですよね。いまの現場でも運用コストについてはある程度可視化されているのですが(参考:re:dashでAWSのコストを分析してみた)、ビジネスに関する監視をもっと増やしてみたくなりました。関する話はほとんどありませんでした。監視の基本は変わらないから、あえて触れていないのだろうと思います。ようなビルトインの監視サービスが使えることと、ネットワークが抽象化されているので本書の「ネットワーク監視」の範囲はあまり関係ない、というくらいでしょうか。分散トレーシングの監視は難しいマイクロサービスと分散トレーシングについては、7章「アプリケーション監視」のなかに含まれていました。本書の著者は、分散トレーシングは非常に時間と労力がかかるので、他の手段で監視できるならそちらを用いるべき、というスタンスでした。分散トレーシングは、正しく実装するのは非常に難しく時間がかかる監視の仕組みであり、業界内の一部でだけ役に立つものです。分散トレーシングは根気がない人や、スタッフ不足だったり過労気味のエンジニアリングチームには向いていません。必要なメトリクスやログはすべて取得していて、それでも分散システムにおけるサービス間のパフォーマンスを把握したりトラブルシューティングをするのに困るようなら、分散トレーシングを使うべきかもしれません。導入するためのコスト(監視システム側の構築・運用の複雑化に加えて、アプリケーション開発者での配慮も必要になる)が、そこから得られるメリットに見合うかどうかは、場合によるだろうなあと思います......。本書を読んでいると監視を改善するアイディアはいろいろ浮かびますが、一度監視項目を設定しても、サービスを開発・運用していると状況は色々変わって、実態に合わなくなるものです。本に移るのが良さそうです。考え直すきっかけになる良書でした。Mackerel12月は色々ありました。今回はそのへんを雑多に振り返る記事です。スタディストのかつひささんが企画したアドベントカレンダーです。2018)も作られてました。僕も11日目に投稿しました。qiita.comqiita.com1個目の方はみんなきっちり執筆して25日埋まってましたし、どちらも内容の濃い記事が多くてすごかったですね。記事を全部読み返して、個人的おすすめ記事をピックアップしてみました。組織体制に興味があるので、主にそのへんの記事に偏ってます。体制)と組織体制を見直してきた現場での、それぞれの体制のメリット・デメリットをまとめた記事です。メンバー)を組み合わせたもののようです。これは是非参考にしたいと思いました。プロダクト横断のSREチームを組成したい話qiita.comオプトの渋谷さんによる記事。チーム立ち上げについての話をされてました。複数のプロダクトチームを横断して活動するように変えていきたいという構想についてのものです。記事の最後の方にある「乗り越えるべき壁」のところは、僕もよくわかる悩みで......特に、プロダクトをまたぐことで「一人のSREが知るべき内容はすごく多岐に渡ってしまいそう」という点は、実際やってみた結果を是非お聞きしたいです。SLO設定/超過監視にまつわる活動の振り返りwww.m3tech.blogエムスリーテックブログの記事。超過時のプロセスまで、具体的なユースケースが詳細にまとめられた良記事です。導入しようという人は必読かと思います。クエリ投げて結果によって通知するツール)については僕も知らなかったので、今度使ってみます......。果たすべき役割に関する記事です。この記事では、データを処理するフローの途中で組織が分かれていたために、データの欠損や不整合が発生してしまった自社事例を紹介しています。各組織が「自分の見える範囲で手っ取り早く済ませよう」とした結果、そうなってしまったようです。ソフトウェア開発じゃなくて、データ基盤の開発でも「コンウェイの法則」が出てくることあるんですね......。SRE)が担うべきと結論づけています。SRE風のインフラエンジニアにならないためにkenjiszk.hatenablog.comはてブでバズってた記事。SREがどういうものかを知ってほしいときには、まずこのページを読んでもらおう!と思ったくらい、説明が必要十分で読みやすい記事でした。ちなみに、この記事の分類に従うと、僕の今年の仕事は「インフラエンジニアではなくSREとしてどう高速リリースを実現するか」のところにずっと注力してました。改善、リリースプロセスやリリース自動化ツールの改善、開発チームが監視に使えるツールの充実などなど......。終えてkths.hatenablog.com企画者のかつひささんによるまとめ記事です。全記事に一言コメントが付けられています。興味のある記事だけ読みたい人は、まずはここをざーっと読むのがいいかも。ちなみに、この記事の最後に「@katsuhisa__的ベスト3」のコーナーがあって、そこで僕の書いた記事を1位に選んでくれていました。予想してなかったのでびっくりしましたが、頑張って書いた甲斐がありました。ありがとうございます。整備した話が書かれています。)という言葉を引用しますが、まさにこの記事の事例には、一種の技芸を感じました。それ以外にもSREと組織構造にも詳しく触れられていて、今後も何回も読み返したくなるような内容でした。投稿した記事で、この流れで僕が投稿した記事も紹介。メンバを中心に試してきたサービスレベル指標と、それぞれについて感じたメリット・デメリットをまとめました。講演では時間の都合で話せなかったネタがあって、年内にアウトプットするならこれがラストチャンスだ!と思って飛びついて、なんとか書き上げられました。結果的には、発表時間が1時間あっても足りなそうなくらいに分量が膨らみましたね......。あまりにも泥臭すぎる内容だし、人によっては「この会社はレベルが低い」と思うのではないか......と思って、公開前には色々悩んで書いたり消したりしました。ついて考えるときには組織の話は外せないし、その具体的なケーススタディの価値は高い、と思うからでした。組織体制は、この記事に書いたものが最終形ではなくて、来年以降も徐々に改善していくことになりそうです。半年〜1年後には、また新たな話ができると思います。利用事例について発表しました。記事中にちらっと出てくる監視システムについて、もう少し詳しく話しています。ゆううきさんが東京に来るということで講演を聞いて、色々お話もできてよかったんですが、その数日後に退職ブログが出てびっくりしました。ゆううきさんが話していたことで、印象的だったのはこのあたりでした。書籍「Webオペレーション」には、運用は技芸で科学ではない、という趣旨の文がある。個人的にはむしろ、技芸から科学へ進んでいると思ってる。engineeringという分野が生まれてきている。トレードオフを取りやすい。チームが分かれているとそこがやりにくくなる(=変更速度が下がる)のでは。間で、お互いに業務を融通できるようになった。いまのトレンドはその方向なのかも。あるべき姿と、ゆううきさんの話が近かったので、その点は勇気づけられました。運用が科学に進んでいる、という点は、僕はあまりそうは思わないのですが、そうであったら面白い、とも思うので、ゆううきさんの今後の活躍に注目したいと思います。はてなブログProMuziとも呼ばれる人。いまはBacklogのSREやってます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。