Google Cloud Architecture Framework のこのドキュメントでは、更新のデプロイ、本番環境でのサービスの実行、障害のテストなど、信頼性の高い方法でサービスを実行するための運用の原則について説明します。信頼性の設計では、ソフトウェア設計だけでなく、サービスのライフサイクル全体を対象とする必要があります。
アプリケーションとサービスに適切な名前を選択する
本番環境の構成ファイルでは内部のコード名を使用しないでください。特に新しく入った従業員が混乱し、サービス停止の緩和に要する時間（TTM）が長くなる可能性があるためです。可能な限り、すべてのアプリケーション、サービス、重要なシステム リソース（VM、クラスタ、データベース インスタンスなど）に、それぞれ名前の長さの上限を条件として適切な名前を選択してください。適切な名前とは、エンティティの目的を示し、正確、具体的、明確な誰から見ても意味がわかりやすい名前です。適切な名前には、頭字語、コード名、略語、不適切である可能性がある用語を回避し、外部に公開される場合でも否定的な反応が発生しないようにします。
カナリアテストによる漸進型ロールアウトを実装する
サービスのバイナリや構成を全体で一度に変更することには、本質的に危険が伴います。実行可能ファイルの新しいバージョンと構成の変更は、段階的にロールアウトします。ゾーン内のいくつかの VM インスタンスなど、小さな範囲から始めて、徐々にその範囲を拡大していきます。変更が予定通りに機能しない場合や、ロールアウトのいずれかの段階でユーザーに悪影響を及ぼす場合は、直ちにロールバックする必要があります。目標は、全体に変更をロールアウトする前に、ユーザー トラフィックのごく一部にのみ影響するバグを特定して対処することです。
サービスの変化がわかり、変更されたサーバーとそれ以外のサーバーの指標の A/B 比較を行うカナリアテスト システムを設定します。このシステムでは、予期しない動作や異常な動作に目印を付ける必要があります。変更が想定どおりに機能しない場合には、カナリアテスト システムで自動的にロールアウトを停止する必要があります。ユーザーエラーや CPU 使用率の増加、メモリの肥大化などの問題が明確になる可能性があります。
トラブルの最初の兆候で停止してロールバックし、障害発生時の時間的な制約を設けずに問題の診断を行うことをおすすめします。変更がカナリアテストに合格したら、次にゾーン全体、続いて 2 つ目のゾーンといったように、より大きな範囲に少しずつ拡大します。変更したシステムが徐々に大量のユーザー トラフィックを処理するように時間を考慮して、潜在的なバグを発見できるようにします。
詳細については、アプリケーションのデプロイとテストの戦略をご覧ください。
期間限定のプロモーションやリリースのトラフィックを分散させる
決まった時間に始まり、多くのユーザーに同時にサービスへ接続するように働きかける販売などのプロモーション イベントを行う場合について説明します。そのような場合は、トラフィックを数秒に分散するようにクライアント コードを設計します。ユーザーがリクエストし始める前に、ランダムな遅延を使用します。
システムを事前にウォームアップすることもできます。システムを事前にウォームアップすると、予想されるユーザー トラフィックを前もってシステムに送信し、期待どおりに機能することを確認できます。この方法により、スケジュールされた開始時刻にサーバーをクラッシュさせる可能性がある瞬間的なトラフィックの急増を防止できます。
ビルド、テスト、デプロイを自動化する
継続的インテグレーションと継続的デリバリー（CI / CD）パイプラインを使用することで、リリース プロセスから手動の作業を排除できます。自動化された統合テストとデプロイを実行します。 たとえば、GKE を使用して最新式の CI / CD プロセスを作成します。
詳細については、継続的インテグレーション、継続的デリバリー、テストの自動化、デプロイの自動化をご覧ください。
安全性を重視した設計
無効な可能性がある構成は拒否するようにオペレーション ツールを設計します。構成バージョンの不備（空、一部しかないか切り捨てられている、破損している、論理的に間違っているか想定外、想定時間内に受信しなかった）を検出してアラートを発出します。また、以前のバージョンと大きく異なる構成バージョンもツールで拒否する必要があります。
スコープが広すぎて破壊的な結果をもたらす可能性がある変更やコマンドを禁止します。たとえば、「すべてのユーザーの権限を取り消す」、「このリージョンのすべての VM を再起動する」、「このゾーン内のすべてのディスクを再フォーマットする」などが該当します。このような変更は、構成をデプロイする際にオペレーターが緊急のオーバーライド コマンドライン フラグやオプション設定を追加することを条件として適用する必要があります。
ツールで、リスクのあるコマンドの影響の範囲（変更により影響を受ける VM の数など）を示す必要があります。また、ツールの実行前にオペレータによる明示的な確認が必要です。また、重要なリソースをロックし、Cloud Storage 保持ポリシーのロックなどによる誤削除や未承認の削除を防止する機能も使用できます。
障害復旧をテストする
サービスの障害から復旧するための運用手順は、定期的にテストします。定期的にテストを行わないと、実際の障害が発生したときにプロシージャが機能しない可能性があります。定期的にテストする項目には、リージョン フェイルオーバー、リリースのロールバック、バックアップからのデータの復元などを含めます。
障害復旧テストを実施する
障害復旧テストと同様、障害の発生を待たないでください。障害復旧の手順とプロセスは、定期的にテストして検証します。
高可用性（HA）を備えたシステム アーキテクチャを作成している場合について説明します。このアーキテクチャでは、障害復旧（DR）と完全に重複するわけではありませんが、リカバリ時間目標（RTO）とリカバリ ポイント目標（RPO）の値を検討する際は、高可用性を考慮する必要があります。
HA により、稼働時間など、合意した運用パフォーマンスを満たすか、またはそれ以上を実現できます。Google Cloud で本番環境のワークロードを実行する場合、2 番目のリージョンにパッシブまたはアクティブなスタンバイ インスタンスをデプロイすることがあります。このようなアーキテクチャでは、プライマリ リージョンで障害が発生しても、アプリケーションは、影響を受けないリージョンから引き続きサービスを提供します。詳細については、クラウドの停止に対する障害復旧の設計をご覧ください。
カオス エンジニアリングを実践する
予行練習では、カオス エンジニアリングの使用を検討してください。安全な環境で、負荷がかかった本番環境システムのさまざまなコンポーネントに、実際の障害を導入します。こうすることで、サービスが各レベルで障害を適切に処理し、システム全体に影響が及ばないことを確認できます。
システムに挿入する障害としては、タスクのクラッシュ、RPC のエラーとタイムアウト、利用できるリソースの縮小などがあります。ランダムなフォールト インジェクションを使用して、サービスの依存関係で断続的な障害（フラッピング）をテストします。本番環境でこうした動作を検出して軽減することは困難です。
カオス エンジニアリングにより、このようなテストからの影響を最小限に抑えることができます。このようなテストは、実際に発生する障害の練習として捉え、収集したすべての情報を使用して障害発生時の対応を改善します。
次のステップ
- 効率的なアラートを作成する（このシリーズの次のドキュメント）
アーキテクチャ フレームワークの他のカテゴリ（システム設計、オペレーショナル エクセレンス、セキュリティ、プライバシー、コンプライアンスなど）を確認する。