Developer's Summit 2019 【15-B-5】Site Reliability Engineering at Google 聴講メモ

講演資料

• 資料公開なし。

概要

• GoogleにおけるSRE(Site Reliability Engineering)の実践について。

スピーカー

• Google Cloud Japanの中井さん。

SRE(Site Reliability Engineering)とは

• 元々はGoogleの中のシステム運用。
  • 10年ぐらい前にGoogleの中の人が出版。
• Google外でも考え方を取り入れていこうという流れ。
• Googleの中で生まれた考え方なので、社内文化に依存した面はたくさんある。
  • そのまま外で実践しようとすると、合う合わないは出てくると思う。
  • どう実践していくかはこれから知見が増えていくところだろう。
  • 今日はその出発点として、どうやっているのか、どういう背景に支えられているのか知って欲しい。

Googleについて

• Google社内では技術者同士の情報共有がかなり緩やか。

  • 社内のエンジニアは社内のソースコード見放題。
  • 全てのプロダクトコードを一つのリポジトリに格納。
  • Google社内では独自のバージョン管理システムを使っている。
  • ディレクトリを分けて全てのコードを保持している。
  • 全く関係ないプロジェクトのコードをインクルードしたり、修正したりできる文化。

• 建前上、今日の話は公開情報に基づいて行われる。

  • 口を滑らせたものについてはツイートしないようにお願いしたい¹。

Googleのグローバルインフラストラクチャー

• ミッションステートメント『世界中の情報を整理し、世界中の人々がアクセスできて使えるようになる』

  • 『世界中の人々』がキーワード。
  • Googleのエンジニアが開発するアプリのターゲットユーザは『世界中の人々』。
  • 特定の人向けのアプリはなるべく作らない。

• Google社内のプライベート回線で繋がってるのでGCPは速い。

• コンテナのシステムで全部統一化されている。ダサい言い方だが標準化。

  • 徹底してて世界中のデータセンターが全て全く同じ仕組みで作られている。
    • アプリは確実にどのデータセンターでも動くことが保証される。
  • 世界中のデータセンタにKubernetesっぽいものが展開されている。
    • Borgのこと。
    • Borgのマスターにコードを投げつければ勝手にデプロイしてくれる。
  • ミドルウェアが全て標準で用意されていて、アプリのエンジニアはこれを使わなければならない。
    • オレオレルールを禁止している。
  • 最近はパブリッククラウドが浸透してきて、ミドルウェアレベルの標準化は浸透してきているのでは。
    • そもそもGCPはもともとGoogle社内で使っていたインフラを公開したもの。

GoogleのSREチーム

• いわゆるシステム運用のチーム。

  • 最初はフルスタック的な運用をしていた。
  • 規模が大きくなって人が増えてくると、開発と運用のチームを分けた。

• そのチームの最初のマネージャーがGoogleらしい人だった。

  • 運用者を雇うことをしなかった。
  • 『運用も開発者目線でやりたい。開発者に理想の運用を考えさせたらどうだろう』と考えた。

• ゴールを明確にすることが重要。

  • システム運用、サービス運用のゴールは？ →安定的にサービスを提供すること。
  • 安定運用のための開発を考えるチーム。

• ソフトウェア開発以外の作業もたくさん存在する。

  • 50％ルール
    • 業務時間の50％以上を、ソフトウェア開発を含むシステム安定化に関わるプロジェクト活動に当てる。
    • 半分はデベロッパーとしてワクワクする業務に当てて欲しい。
    • 残り半分は一般的な運用作業。
    • 実際問題守れるのか？→一応守れている。

• バーンアウト(Burnout)の防止。

  • SREチームは運用を開発に突き返す権利を持っている。
  • 50％ルールを守れない場合は、開発チームに突き返す権利がある。
    • 実際には簡単に突き返さない。
    • 突き返されると困るので開発側も協力して安定化に協力する。
    • あるいはマニュアル運用を減らせるように、デベロッパーとSEがいっしょに動く。

• 全てのシステムをSREが面倒を見ているわけではない。

  • 共通のミドルウェアと重要度の高いアプリは面倒を見ている。
  • 小規模で重要度が低いアプリは開発チームが面倒を見る。
  • SREチームが関わる必要がないほど安定しているアプリは面倒を見ない。
    • SREの究極のゴールは、自分たちが運用するシステムをなくすこと。
    • が、現実はそうはならない。機能追加が多いので、新しい機能をリリースすると大抵トラブルが起きる。
    • 『世の中から病気がなくなれば医者は職業を失う』のと似ている。

SREの活動原則

• SLO(Service Level Objective)

  • チームを超えた『安定』の共通認識。何を持ってシステムが安定してるかの共通認識を作る。
  • 数値レベルで安定度を客観判断する。
    • 例えば、
      • 『99％のリクエストに対して、サクセスステータスを返す』とか。
      • 『サクセスステータスの99％は、1000ms以内に応答を返す』とか。
  • こういうのを淡々とモニタリングしていく

• エラーバジェット(Error Budget)

  • 1ーSLOで算出。
  • SLOの計算期間内でエラーバジェットを決めておく。

  • エラーバジェットの消費状況をモニタリングして、なくなる可能性がある場合は抜本的対策を講じる。

    • この場合は開発チームを巻き込む。
      • 開発とSLEがいっしょになって頑張ることが重要。
    • やってみないとわからないこと、本番デプロイしてみないとわからないことが山ほどある。
      • どうなるかはSREの方が知っていることが多い。
    • デベロッパーはその間、新機能リリースはフリーズする。
      • SLOを守るために注力する。
      • 困る人が出てくる場合もある。この場合、SLOの設定が悪い。

  • いろんな人が納得するSLOを議論して決定していくことが重要になってくる。

    • 実際には一発で決まらない。
    • 新規運用の場合は大雑把に決めておいて、後から調整するプロセスが走る。

• デザインレビューの提供

  • アプリの設計段階から、安定化をゴールとしたレビューを実施。
  • SREチームが知っている安定化の知識を渡す。
    • デベロッパーのオレオレルールで作ったものを持ってこられても困る。
    • 自分たちがよく知っている標準的な設計にできる。
  • 設計の標準化、共通化が実現できるため、SREへの引き継ぎ後も人手をかけない運用ができる。

• その他

  • Toil(労力のかかる作業)の削減。
    • Toilは悪である、というのが共通認識。
    • 削減する努力が美しいとされる。
    • 自動化で面倒な作業をなくす。

• SRE本の英語版を読むと印象的な単語(Burnout)が出てくる。

  • システム運用の世界では嫌になる作業が山のようにある。
  • デベロッパーにつまんない仕事をさせたらみんな会社を辞めちゃうので、Burnoutを防ぐことは非常に重要。
  • 普通の発想だと、システム運用はつまらないのが当たり前になっちゃう。
  • 優秀なエンジニアにやらせると、転職先を見つけてどっかに行ってしまう。
  • ワクワクしながらやってもらうルールを考える必要がある。

障害対応のプロセス

• 障害対応システムがGoogle社内にある。

  • 細かい障害は山のように起きている。
  • 障害対応に電話番が付いている。問題が起きたらその人に電話して障害対応が始まる。
  • 障害報告を受けた人がインシデントコマンダーになってチームに役割を割り当てる。
  • 割と自分たちでコードを見て根本原因の解決に当たろうとする。
  • SREの中だけで解決するルールは全くないので、デベロッパーに相談することも行われている。

• 問題解決を最優先して、他人に頼ることを本人のスキル不足とは認識しないことを徹底。

• Postmortem(事後検討)

  • 重大障害対応後、google docsで文書を開いて、記憶をダンプする。
  • 『何が問題で何が起きたのか』をダンプアウトする。
  • 言い訳をするものではなく、障害対応で得られた知見を未来に繋げる。
  • 書いていく中で改善案は出てくるので、改善のためのアクションアイテムが最後に書かれている。
  • 個人を非難する内容は絶対に書かない。
    • 個人のミスを誘発するシステムを設計したSREの責任。
    • コマンドの打ち間違いで障害が発生したのなら、コマンドの打ち間違いで問題を起こす設計が悪いと考える。
  • Google社内の全てのエンジニアに共有されている。見放題。
    • 社内の問題データベースを見ると大きな問題に対するPostmortemが出ていて、リアルタイムに皆が一斉に書き込んでいる様を眺めることもある。
    • 読んでいると勉強になる。エンジニアの教育材料としてすごく役立つ。
  • うわさによるとPostmortemを読む同好会が社内にあるらしい。
  • SREチームの中で障害対応の再現、実地訓練を行うためのシナリオとして使ったりもするらしい。

最後に

• 同じことを外部の企業でやるのは難しいと思うが、合理性は徹底しているので、つまみ食いしてもらえればいいんじゃないか。

• トレーニングコースがあるらしい(coursera)。

  • 日本語版は出てないので、日本語化早くしろとリクエストしてほしい。

• GCPをせっかく使うのであれば、開発した後の運用についても、SREのエッセンスを取り込んで使ってほしい。

  • それぞれの企業文化に合わせて、どのように実践していくかのディスカッションが広がっていくといいんじゃないかと思っている。

---

1. もし口を滑らせた内容を気づかず私が記述していたら、こっそり教えてください。しかるべく処置します。↩