Google Cloud アーキテクチャ フレームワークのこの柱では、クラウド プラットフォーム上での信頼性の高いサービスを設計して運用するために必要な設計原則について概要レベルで説明します。
アーキテクチャ フレームワークでは、ベスト プラクティスを記載して、実装上の推奨事項を紹介し、利用可能ないくつかのプロダクトやサービスについて説明します。このフレームワークは、実際のビジネスニーズに合うように Google Cloud のデプロイメントを設計する支援を目的としています。
AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、アーキテクチャ フレームワークの AI と ML の視点: 信頼性をご覧ください。
信頼性の高いサービスを実行するには、アーキテクチャに次のことを含める必要があります。
- 測定可能な信頼性目標（逸脱が発生したときは速やかに修正する）
- 次の事項を考慮した設計パターン:
- スケーラビリティ
- 高可用性
- 障害復旧
- チェンジ マネジメントの自動化
- 自己修復するコンポーネント（手動による介入なしで問題を修復できる）
- オブザーバビリティのための計測が含まれているコード
- ハンズフリー運用（たとえば、サービスを実行するときの手動作業とオペレーターの認知負荷を最小限に抑えるとともに、障害を迅速に検出して軽減する）
サービスの信頼性に対してはエンジニアリング組織全体が責任を負い、これには開発、プロダクト管理、運用、サイト信頼性エンジニアリング（SRE）の各チームが含まれます。チームは、アプリケーションの信頼性目標、リスク、エラー バジェットを理解し、これらの要件に責任を負う必要があります。信頼性とプロダクト機能開発との間に生じる競合については、優先度を上げて対応し、適切にエスカレーションする必要があります。
信頼性の基本原則
このセクションでは、信頼性の高いサービスの基本原則について説明します。ここでの内容は、後続の詳細なドキュメントの基礎となります。このトピックについてのさらに詳しいドキュメントで説明している、Google の信頼性に対するアプローチは、次に示す信頼性の原則に基づいています。
信頼性は最優先の機能
エンジニアリング チームは、新プロダクトの開発を優先することもあります。ユーザーはお気に入りのアプリケーションに新しい、魅力的な更新が追加されるのを期待していますが、プロダクトの更新はユーザーにとっての短期的な目標です。ユーザーは常に、サービスの信頼性は高いのが当然と考えていますが、本人はそれに気づいていないこともあります。アプリで使えるツールや派手なグラフィックが増えたとしても、ユーザーがサービスにアクセスできなかったり、サービスのパフォーマンスが低かったりしたら意味はありません。アプリのパフォーマンスが低いと、このような拡張された機能は重要性を失います。
信頼性はユーザーによって定義される
要約すると、顧客が満足しているときはサービスの信頼性が高いといえます。ユーザーのことは常に予測できるとは限らず、ユーザーを満足させるために何が必要かを開発側が過大評価することもあります。
今日の標準では、ウェブページは約 2 秒で読み込まれる必要があります。読み込み時間が 1 秒長くなったときのページ離脱率は約 53% ですが、読み込み時間が 3 秒長くなると 87% に増加します。しかし、サイトのページを 1 秒で配信しようとすることは、おそらく最適な投資とは言えません。顧客に適したサービス信頼性のレベルを判断するには、次のことを測定する必要があります。
- ユーザー向けワークロード: ユーザー エクスペリエンスを測定します。たとえば、CPU 使用率などのサーバー指標だけでなく、ユーザー リクエストの成功率を測定します。
- バッチとストリーミングのワークロード: データ スループットの重要業績評価指標（KPI）を測定します。たとえば、時間枠あたりのスキャン行数です。この方法は、ディスク使用量などのサーバー指標よりも有益です。スループット KPI は、ユーザーからリクエストされた処理を時間どおりに確実に完了するのに役立ちます。
100% の信頼性を目指す必要はない
これは、前述の原則の延長です。ユーザーが満足しているときは、システムの信頼性は十分に高いといえます。一般的には、ユーザーは信頼性 100% を求めてはおらず、それ以下でも満足します。したがって、ユーザーを満足させるのに必要な信頼性のしきい値をサービスレベル目標（SLO）として定義してから、エラー バジェットを使用して適切な変更の速さを管理してください。
このフレームワークの設計と運用の原則をプロダクトに適用するのは、そのプロダクトまたはアプリケーションの SLO がコストを正当化する場合に限ります。
信頼性と迅速なイノベーションは相互補完的
エラー バジェットを使用すると、システムの安定性とデベロッパーのアジリティのバランスを取ることができます。安定性と開発のどちらを重視すべきかを判断するには、次のガイダンスを参考にしてください。
- エラー バジェットが減ったら、速度を落として信頼性機能に重点を置きます。
- エラー バジェットが十分に残っているときは、迅速にイノベーションを実現し、プロダクトの改善や機能の追加を行うことができます。
設計と運用の原則
アーキテクチャ フレームワークの信頼性の柱についての残りのドキュメントでは、システムの信頼性を最大限に高めるための設計と運用の原則について説明します。以降のセクションの内容は、このシリーズの各ドキュメントで説明する設計と運用の原則の要約です。
信頼性の目標を明確にする
前述のとおり、ユーザーの満足度によって信頼性が定義され、信頼性の目標は SLO として表されます。SLO を設定する際は、次の点を考慮してください。
- 適切なサービスレベル指標（SLI）を選択する。
- ユーザー エクスペリエンスに基づいて SLO を設定する。
- SLO を反復的に改善する。
- 厳格な内部 SLO を使用する。
- エラー バジェットを使用して開発速度を管理する。
詳細については、サービスレベル目標のコンポーネントをご覧ください。
インフラストラクチャとアプリケーションにオブザーバビリティを組み込む
コードを計装してオブザーバビリティを最大化します。詳細については、インフラストラクチャとアプリケーションにオブザーバビリティを組み込むをご覧ください。
スケーラビリティと高可用性を実現する設計
スケーラビリティと高可用性（HA）については、次の原則を考慮してください。
- HA のために冗長性を作る
- 障害復旧（DR）のためにリージョン間でデータを複製する
- リージョンの停止に対する耐障害性を確保するためにマルチリージョン アーキテクチャを設計します。
- 過負荷状態の場合にサービスレベルを適切に下げる
- システム機能を維持するようにフェイルセーフを実現する
- 再試行できるように API 呼び出しとオペレーション コマンドを設計する
- 依存関係を考慮する
- システムの依存関係を特定して管理する
- 不可欠な依存関係を最小化する
- どの変更も確実にロールバック可能にする
加えて、次のことはサービスの信頼性を高めるのに役立ちます。
- スケーラビリティのボトルネックを排除する
- トラフィックの急増を回避し、軽減する
- 入力をサニタイズして検証する
詳細については、スケールと高可用性のための設計をご覧ください。
信頼性の高いツールと運用プロセスを作成する
次のことを行って信頼性をツールと運用プロセスに組み込みます。
- アプリケーションとサービスの名前は、論理的で意味がわかりやすいものを選ぶ
- カナリアテストを使用して手順の漸進型ロールアウトを実装する
- プロモーションとリリースについては、トラフィックが分散されてシステムの過負荷が軽減されるようにタイミングを選ぶ
- プログラムによるビルド、テスト、デプロイのプロセスを開発する
- 意図的かどうかにかかわらず人為的なインシデントに対して防御する
- 障害対応アクティビティを開発、テスト、文書化する
- 障害復旧の手順を作成して定期的にテストする
- カオス エンジニアリング: サービスのフォールト トレランスとレジリエンスを判断するために、システムへのフォールト インジェクションを習慣付ける
詳細については、信頼性の高い運用プロセスとツールを作成するをご覧ください。
効率的なアラートを作成する
アラートを作成する際は、次のことをおすすめします。
- 適切な遅延が得られるようにアラートを最適化する
- 原因ではなく、症状についてアラートを作成する
- 平均ではなく、外れ値についてアラートを作成する
詳細については、アーキテクチャ フレームワークの信頼性の柱の効率的なアラートを作成するをご覧ください。
共同インシデント管理プロセスを構築する
インシデント対応と管理（IRM）は、サービスの復旧と損害の最小化に不可欠です。効果的な IRM には、次の要素が含まれます。
- 所有権: 明確なサービス オーナーを割り当てます。
- 適切に調整されたアラート: インシデント対応（IR）を改善するとともに検出時間（TTD）を短縮するように、アラートを慎重に設計します。
- IRM の計画とトレーニング: 包括的な計画、ドキュメント、トレーニングによって、緩和に要する時間（TTM）を短縮します。
- ダッシュボード: TTM を最小限に抑えるために、問題発生時に効率的にアラートを生成できるようにダッシュボードのレイアウトとコンテンツを設計します。
- ドキュメント: サービス サポートのあらゆる側面について（これには診断手順やサービス停止時の緩和策も含まれます）、明確で簡潔なコンテンツを作成して維持します。
- 非難しない文化:
- 非難しない環境を組織内に構築します。
- 「誰」ではなく「何」に焦点を当てたポストモーテム プロセスを確立します。
- 適切に調査し、改善と再発防止が必要な領域を特定することで、サービス停止から学びます。
詳細については、アーキテクチャ フレームワークの信頼性の柱に含まれる共同インシデント管理プロセスを構築するをご覧ください。
次のステップ
- SLO のコンポーネントについて学習する。
- アーキテクチャ フレームワークの他の柱の推奨事項を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。