Google Cloud

SRE のサポートを受けるべきアプリとは？ : CRE が現場で学んだこと

2017年7月7日

Google Cloud Japan Team

編集部注 : 社内で多くのアプリケーションやサービスが稼働するようになると、SRE（や運用）チームのサポートが追いつかないケースが出てきます。今回の『CRE が現場で学んだこと』シリーズでは、企業内のアプリケーションやサービスの中で何を SRE にサポートしてもらうかを、うまく原則に基づいて防御的に決める方法について見ていきます。

Google では幸いなことに、ストレージやネットワーク、ロードバランシングといった横断的なインフラはもちろん、Google 検索や Google マップ、Google フォトなどの主要なアプリケーションも含め、すべてを Site Reliability Engineering（SRE）チームがサポートしています。とはいえ、SRE にはソフトウェアエンジニアとシステムエンジニアの両方を組み合わせたスキルが求められるため、それを満たす人材を見つけて採用するのは容易ではなく、今も需要が供給を上回る状態が続いています。

SRE チームがサポートできるアプリケーションの数には実質的な制限があります。このことを、私たちは時間の経過とともに学びました。また、他よりもサポートに手間がかかるアプリケーションの特徴もわかってきました。多くのアプリケーションを稼働させている企業では、すべてを SRE チームがサポートすることは無理だと思われます。

Q : どうすれば自社の SRE チームが限界に達しているとわかるのですか？どうすればサポートすべきアプリケーションをうまく選べるのでしょう？ SRE チームはいつアプリケーションのサポートを止めるべきなのでしょうか？

いい質問ですね。これらの問題について詳しく見ていきましょう。

SRE によるサポートの実質的な限界

Google の場合、誰も燃え尽きることなくページャー担当者をローテーションさせるのに必要な SRE チームの最低人数は、経験則からいってエンジニア 6 人です。1 日 24 時間週 7 日のローテーションで待機し、目標とするレスポンス時間は 30 分以内、ページャーのアラートがエンジニアの睡眠を妨げることがないよう、待機時間は 1 人のエンジニアにつき連続 12 時間を超えないことが条件です。つまり、エンジニア 6 人のグループが 2 つ必要で、それぞれがページャーに対応する時間帯をほぼ日中に合わせられるよう、各グループは地理的に離れていることになります。

どんな場合においても、ページャーに対応する第 1 担当者が存在します。第 1 担当者にたまたま連絡がつかなかったり、第 1 担当者がインシデント対処中だったりして対応できないときは、第 2 担当者がページャーに応えます。

第 1 担当者と第 2 担当者は通常の運用業務をこなし、他のチームメンバーには、信頼性向上、より良いモニタリングシステムの構築、運用業務の自動化促進といったプロジェクト業務のために時間を費やしてもらいます。つまり、各エンジニアは 6 週間の中で 2 週間、そのうち 1 週間は第 1 担当者として、もう 1 週間は第 2 担当者として運用業務に注力することになります。

Q : エンジニアが 12～16 人いれば、開発チームが作成したアプリケーションすべてを確実にサポートできることになりますよね？

実はその答えはノーです。経験上、SRE チームが効率的に管理できるアプリケーションやサービスの数には明白な認知限界があることがわかっています。

個々のエンジニアが、それぞれのアプリケーションの稼働中に発生したトラブルに対応、診断して解決へと導くには、各アプリケーションのことを十分に知っておく必要があります。

したがって、複数のアプリケーションに対する同時サポートを簡素化するには、その複数のアプリケーションをできるだけ似たようなものにしておくとよいでしょう。共通のパターンやバックエンドサービスを使うように設計するとともに、ロールアウトやモニタリング、アラートなどの運用作業は共通のツールを使って標準化し、デプロイのスケジュールも同じようにしておくのです。もっとも、こうすることでアプリケーションあたりの認知的負荷は軽減できますが、なくなるわけではありません。

十分な人数の SRE を確保できたときは、2 チーム制にして（ここでも 2×6 という最低限の配属人数は守りましょう）、それぞれ異なる分野を担当させることも検討しましょう。

Google の場合、1 つの SRE チームがフロントエンドとバックエンドに分かれ、システムの規模が大きくなるにつれて、それぞれがフロントエンドのみ、バックエンドのみをサポートすることも珍しくありません（このようなチームを私たちは “mitosis” と呼んでいます）。

SRE チームがサポートできるサービスの上限は、以下のような要因によって大きく変わってきます。

サービスがきちんと稼働し続けるために必要な通常の運用タスク。たとえば、リリース、バグフィックス、緊急性のないアラートやバグなどがこれに相当します。自動化することで、こうしたタスクは（なくすことはできないものの）軽減できるでしょう。
予定外で重要度の低いリクエストによる「割り込み」。これを減らそうと努力しても無駄であることがわかっています。一番効率的な対処法は、頻繁にやって来るリクエストの 50～70 % をセルフサービスツールに任せることです。
緊急アラートへの対応、インシデント管理、その後のフォローアップ。これらに割く時間を減らす一番の方法は、サービスの信頼性を高め、アラートの精度を調整することです（アラートが発動したときは、サービスで実際に起こっている問題をきちんと示すようにするとよいでしょう）。

Q : 6 週間のうち 4 週間は SRE が運用作業を行っていないことになります。その時間を使って、SRE チームがサポートするサービスの量を増やせないでしょうか？

できないことはないですが、そのような行為は、Google では「種トウモロコシを自ら食べてしまうようなもの」と見なされます。機械ができることはすべて機械にやらせることがゴールです。それを実現するには、SRE に余裕を持ってもらい、サービスの新たな自動化といったプロジェクトに取り組んでもらいましょう。

経験上、50 % という運用作業のしきい値をチームが超えると、すぐに坂道を下って 100 % 運用となってしまいます。こうした状況に陥ると、今後発生するインシデントの頻度や時間、影響などをエンジニアの努力によって削減することが難しくなり、中長期的な運用上のメリットをもたらすエンジニアリングの恩恵を得られなくなります。SRE チームを運用でほぼフル稼働させてしまうと、エンジニアの設計や開発スキルによって得られる利点を逃してしまうのです。

特に注意していただきたいのは、SRE のエンジニアプロジェクトが上に挙げたような要因に対応し、運用負荷を軽減できる点です。上記の要因こそ、SRE チームがサポートできるサービスの数に上限があることの理由なのです。

ここまで読めば、SRE チームに新たなサービスを担当してもらいたいと思いつつも、実際には継続してサポートしてもらうのが難しいことがおわかりいただけるのではないでしょうか。

SRE のサポートに限界が来たらどうするのか

Google の場合、SRE がサポートしていないサービスは、原則として開発を担当したチームがサポートすることになっています。新しいアプリケーションを開発するのに十分な開発者がいるのであれば、サポートする開発者も十分いるだろう、というのが Google の考えなのです。Google の開発者は、モニタリングやロールアウト、インシデント管理を行うにあたって担当 SRE と同じツールを使うことが多いため、運用サポートの負荷も SRE と似通っています。

いずれにしても、Google ではアプリケーションを作成した開発者にしばらくサポートを直接担当してもらいたいと考えています。そうすることで、お客様がどのような経験をされているのかを開発者も実感できます。開発者がそのとき得た情報は、のちに SRE がサービス担当者として加わった際にも役立ちます。

Q : では、開発者に作ってもらいたいと考えている次のアプリケーションの扱いはどうしましょう？現在のアプリケーションをサポートすることで手一杯なのではないですか？

確かにそうかもしれません。過度のアラートや自動化不足により、稼働中のアプリケーションの運用負荷が高くなっている可能性はあります。しかし、このことで開発チームには、よりサポートしやすいアプリケーションを作ることに時間を費やそうという実用的な動機が生まれます。サポートしやすいアプリケーションの開発は、アラートを調整し、自動化に開発時間を割き、機能変更のスピードを落とすことなどによって実現できます。

開発者が運用業務で手一杯になった場合でも、SRE が運用の専門知識や開発力を提供することで、何とか管理可能なレベルまで開発者の負荷を下げることができるかもしれません。ただし、SRE がサービスの運用責任を負うことになってはいけません。基本的な問題の解決にはつながらないためです。

1 つのチームがアプリケーションを開発し、別のチームが運用業務を引き受けると、モラルハザードが発生します。開発スピードを上げたいと考えている開発者は、たまにメモリ不足でサーバーの再起動が必要になるようなちょっとしたバグを探し出してやっつけることには興味がありません。一方、運用チームはその再起動を 1 日に何度も実行するために、そのつどページャーで呼び出されるのです。

運用チームにとっては、彼らの睡眠を妨げるバグの修復こそ大切なことなのです。当然のことながら、開発者が自分の開発したシステムの運用まで担当すると、彼ら自身もサポートしやすいシステムを作ることに時間を費やしたいと思うようになります。後で説明しますが、これは SRE チームに自身のアプリケーションをサポートするよう説得する際にも重要なことなのです。

どのアプリケーションをサポートするべきか

SRE がサポートするアプリケーションに優先順位を付ける最も簡単な方法は、売上げや事業の重要度に応じて決めることです。つまり、サービスがダウンするとどうなるかを考えるのです。結局のところ、SRE チームに自社サービスをサポートしてもらうことで、サービスの信頼性や可用性が向上するのですから。

Q : いい考えだと思います。つまり、ビジネスへの影響度に応じて優先順位を付ける方法が常に正しいということですよね？

そうとも限りません。実際にはあまりサポートの必要がないサービスも存在するからです。（分散キーバリューストアのように）成熟しており、かつ単純で、更新の頻度も高くないインフラサービスが良い例です。

このようなサービスは変更されることがほとんどないので、自発的に壊れる可能性も低いのです。そのサービスがユーザー向けアプリケーションと重要な依存関係にあったとしても、SRE が専属でサポートするほどではないでしょう。むしろ、サービスの開発者がページャーを持ち、たまに発生する運用作業を担当するようにしてください。

Google では、SRE チームが注力する分野は以下の 7 つだと考えています。これらは、開発者が通常はあまり注力しない分野です。

モニタリングと測定基準 : たとえば、レスポンスのレイテンシ、エラー、未対応となっているクエリの率、リソースの利用率がピークに達しているかどうかなどを検知することです。
緊急対応 : 交代でオンコールに対応することや、トラフィックが落ちたことの検知、第 1 担当者や第 2 担当者およびエスカレーション、作戦を練ること、“Wheel of Misfortune”（不運のルーレット）などです。
キャパシティプランニング : 四半期ごとの予測や、突然の持続的なスパイクへの対応、稼働率向上プロジェクトの実施などです。
サービス速度の上げ下げ : さまざまな場所で稼働しているサービスの場合、（エンドユーザーのレイテンシを低減するなどの理由から）場所に応じて対応速度を上げたり下げたりするスケジュールの計画を立て、そのプロセスを自動化することでリスクや運用負荷を軽減させます。
変更管理 : カナリアリリース、1 % experiments、ローリングアップグレード、不具合発生時の迅速なロールバック、エラーバジェットの査定などです。
パフォーマンス : ストレステストや負荷テスト、リソース利用の効率性監視と最適化のことです。
データの完全性 : 再構成できないデータを、読み込み時に復元性かつ可用性の高い状態で保存しておくこと。これには、バックアップから迅速に復元できるようにすることも含まれます。