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 のエラーとタイムアウト、リソース可用性の低下などがあります。ランダムなフォールト インジェクションを使用して、サービスの依存関係で断続的な障害（フラッピング）をテストします。このような動作は、本番環境で検出して軽減することが困難です。
カオス エンジニアリングにより、このようなテストからの影響を最小限に抑えることができます。このようなテストは、実際に停止が発生した場合の対応を目的に実施するもので、収集したすべての情報を使用して停止時の対策策を改善します。
次のステップ
- 効率的なアラートを作成する（このシリーズの次のドキュメント）
- アーキテクチャ フレームワークの他の柱の推奨事項を確認する。