予期せぬ事態を乗り切るために復元力のあるシステムを構築する
Google Cloud Japan Team
※この投稿は米国時間 2020 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。
私たちが日々利用している Google 検索、YouTube、Gmail、Google マップなどの数多くの Google サービスの実行は、グローバルなクラウドによって支えられています。インターネットの利用が増加し、さまざまなことが仮想的に行われるようになってきた今、この新しい需要のすべてにインターネットが追いつき、そして先取りできるのか疑問に思う方もいることでしょう。これに対する答えは「はい」です。そしてその実現において大きな役割を担っているのが内部チームと方法論を導く一連の原則であるサイト信頼性エンジニアリング（SRE）です。
約 20 年前、私は当時 7 人のエンジニアから構成される Google の「プロダクション チーム」のリーダーを任されました。現在、そのサイト信頼性エンジニアリング（SRE）チームは数千人の Google 社員を擁するまで成長を遂げました。SRE は、Google が突き進んでいくための秘密兵器の一つです。Google は長年にわたって計画と復元力について多くのことを学んできました。こうして培ってきた知見を、お客様独自のビジネス継続性や障害復旧シナリオに活かせることを光栄に思います。
SRE には従うべき一連のプラクティスと原則があり、エンジニアリング チームはこれらによって、ユーザーに対するサービスの信頼性を維持できます。20 年ほど前に前述の小さなチームが結成されて以来、SRE チームはプラクティスを進化させ、数多くのテストを実施し、3 冊の書籍を発行しました。また、Samsung などの他の企業が独自の SRE 組織を構築するのも目にしてきました。SRE の業務は、よく使われるこのフレーズに要約できます。「希望は戦略ではない。備えあれば憂いなし。」最悪のシナリオに直面せずに済むのが理想的です。しかし、そのような事態が起こったとしても準備ができているかどうかが、ビジネスの成功を左右するといえるでしょう。
10 年以上にわたり、大規模な障害復旧の計画とテストが、SRE のプラクティスにおける重要な部分を占めてきました。Google では、障害復旧テスト（DiRT）を定期的に実施しています。DiRT は全社を対象にインシデントやサービス停止の実例や架空例を定期的かつバランス良くまとめたもので、技術システムからプロセス、人員に至るまでそのすべてをテストします。ご推察のとおり、これらのテストの一環として、本番環境サービスの一部を意図的にダウンさせます。ユーザーへの影響を回避するため、テスト時には余剰となっているキャパシティを使用します。エンジニアが修正方法をすばやく見つけられない場合は、再度キャパシティが必要になる前にテストを停止します。また、さまざまな場所での自然災害もシミュレートしているため、従業員がオフィスに出勤できないという現在の状況下でも役立っています。
このようなテストには時間がかかりますが、長期的に見れば報われます。厳格なテストを行うことで、SRE チームは未知の弱点、見落としている問題、エッジケースを発見し、それらを修正するためのプロセスを作成できます。どのようなソフトウェアやシステムであっても障害は発生しますが、さまざまなシナリオに対応できるように準備しておけば慌てる必要はありません。SRE では人間がこれらのシステムを実行することが考慮されているため、非難なしの事後調査と多くの情報交換などにより、チームメンバーは建設的に連携できるようにしています。
障害復旧計画の策定に着手する場合、小規模なサービス固有のテストに焦点を当てるところから掘り下げることをおすすめします。これには、シフトの完了時にオンコール チームメンバー間で引き継ぎを行うだけでなく、同僚に渡す継続的な文書も含まれます。必要に応じてバックアップ要員にアクセスできるようにすることもできます。また、SRE における一般的な最初の課題とその対処方法についてのヒントを確認することもできます。
サービス障害の対応の詳細
ユーザー向けサービスでは、サービス障害が発生するかどうかではなく、いつ発生するかが問題といえます。ここで Google での対処方法をご紹介します。
まず、問題を検出したら直ちにその問題に着手することが重要です。大半の場合、Google の SRE メンバーは専用モバイル デバイスを所持しているため、重大なサービス障害やサービス停止についての連絡がすぐに入り、内部の管理チャネルに直ちに投稿できます。Google ではサービスレベル目標（SLO）を設定し、人間による対応が必要なものに限ってアラートを行うようにしており、お客様にも同様のアプローチをおすすめしています。
オンコール SRE チームメンバーの役割と責任を定義します。一部の SRE メンバーが実際の問題緩和にあたる一方で、他のメンバーはプロジェクト マネージャーやコミュニケーション管理者として行動し、お客様や SRE メンバー以外の同僚からの質問の更新や処理を行います。
問題の根本原因を検出して修正します。SRE チームはサービスの障害や停止の原因を探り、それを緩和します。同時に、チームのコミュニケーション管理者は作業の進捗状況を追跡して、お客様向けのチャネルに更新を追加します。
必要に応じて引き継ぎを行います。オンコールの SRE メンバーは進行状況を文書化し、問題解決が長引く場合には、シフトを開始する同僚または次のタイムゾーンの同僚に引き継ぎます。また、SRE メンバーはお互いに気を配り、必要であればバックアップを開始します。
最後に、事後調査を記録します。ここには、インシデントやその原因に加え、今後同様のインシデントを防ぐためにチームやビジネスが行うべき対策について詳しく記載します。SRE の事後調査では誰も非難しないことに留意してください。Google ではインシデントの関係者全員がスキルや誠意を持っているものと見なし、システムをより有効に機能させる方法に注力しています。
障害が発生した場合、コミュニケーションはどれだけしてもしすぎるということはありません。SRE メンバーは緩和作業を優先し、24 時間 365 日のサポートを維持するためにグローバル全体で対応するものの、それ以外のビジネスはいつもどおりに稼働しています。そのため、この間中 SRE チームは作業に対する明確なスケジュールを設定します。また、状況確認やシステムがダウンした場合に備えて、Google Meet、チャットルーム、Google ドキュメントなどの複数の通信チャネルも維持しています。
COVID-19（新型コロナウイルス感染症）期間中の SRE
新型コロナウイルスのパンデミックが世界中で発生している中、Google では通常のインシデント対応プロセスを少し変更する必要がありました。通常、SRE チームはすでに 2 つの地理的な場所に分割されていましたが、データセンターで働く従業員のためにスタッフ間の距離をあけると同時に、新型コロナウイルスへの濃厚接触の可能性を避けるために別の対策も講じました。健全な SRE チームを維持するにあたり大きな部分を占めるのは、ワークライフ バランスの維持とチームワークの文化です。従業員の心身の健康を保つうえで、これらの原則がますます重要になっています。
SRE の詳細と、自社のビジネスにおけるシステムの復元力を向上させるためのヒントについては、Google のインフラストラクチャ リーダーである Dave Rensin と Ben Lutch とともに撮影した最新の動画をご覧ください。パンデミックによって Google が新たに学んだ教訓について取り上げています。
計画してテストし、さらにテストを積み重ねることによって、実行しているサービスに関係なく、ユーザーの満足度や生産性、ユーザーに対する透明度が向上するという長期的な効果がもたらされます。SRE とは真にチームの努力であり、Google の SRE メンバーはその協調的で最後までやり遂げる真摯な取り組みを体現しています。皆様が自社の SRE プラクティスを開始することにより、信頼性の高いサービス、優れたコミュニケーション、迅速な問題緩和を実現できるよう願っています。
SRE の取り組みを始める際には、ぜひSRE における一般的な課題への対処方法をご覧ください。
-By Ben Treynor, VP, 24x7
