Google Cloud Well-Architected Framework のオペレーショナル エクセレンスの柱におけるこの原則は、クラウド ワークロードの運用準備とパフォーマンスを確保するうえで役立ちます。サービス パフォーマンスに関する明確な期待とコミットメントの確立、堅牢なモニタリングとアラートの実装、パフォーマンス テストの実施、容量ニーズの事前計画を重視します。
原則の概要
組織によって運用準備の解釈が異なる場合があります。運用準備とは、組織が Google Cloudでワークロードを正常に運用するための準備を行うことです。複雑な多層クラウド ワークロードの運用を準備するには、リリースと day-2の運用の両方について慎重に計画する必要があります。このようなオペレーションは、多くの場合、CloudOps と呼ばれます。CloudOps
運用準備の重点分野
運用の準備状況は、4 つの重点分野で構成されています。各重点分野は、 Google Cloudで複雑なアプリケーションや環境を運用するための準備に必要な一連のアクティビティとコンポーネントで構成されています。次の表に、各フォーカス エリアのコンポーネントとアクティビティを示します。
| 運用準備態勢の重点分野 | アクティビティとコンポーネント |
|---|---|
| 従業員 |
|
| プロセス |
|
| ツール | CloudOps プロセスをサポートするために必要なツール。 |
| ガバナンス |
|
推奨事項
CloudOps を使用して運用体制とパフォーマンスを確保するには、次のセクションの推奨事項を検討してください。このドキュメントの各推奨事項は、運用準備の重点分野の 1 つ以上に関連しています。
SLO と SLA を定義する
クラウド オペレーション チームの重要な責任は、すべての重要なワークロードのサービスレベル目標（SLO）とサービスレベル契約（SLA）を定義することです。この推奨事項は、運用準備のガバナンスの重点分野に関連しています。
SLO を定義する:
SLO は、具体的、測定可能、達成可能、関連性があり、期限付き（SMART）である必要があります。また、目標とするサービスレベルとパフォーマンスを反映している必要があります。
- 具体的: 必要なサービスとパフォーマンスのレベルを明確に示します。
- 測定可能: 定量化可能で追跡可能。
- 達成可能: 組織の能力とリソースの範囲内で達成可能であること。
- 関連性: ビジネス目標と優先事項に沿っている。
- 期限がある: 測定と評価の期間が明確に定められている。
たとえば、ウェブ アプリケーションの SLO は「99.9% の可用性」や「平均返信時間が 200 ミリ秒未満」などになります。このような SLO は、ウェブ アプリケーションに必要なサービスレベルとパフォーマンスを明確に定義し、SLO は経時的に測定および追跡できます。
SLA を定義する:
SLA では、サービスの可用性、パフォーマンス、サポートに関するお客様へのコミットメントが規定され、不履行に対する罰則や救済策も含まれます。SLA には、提供されるサービス、期待されるサービスレベル、サービス プロバイダと顧客の責任、不遵守に対するペナルティまたは救済策に関する具体的な詳細を含める必要があります。SLA は、両当事者間の契約として機能し、クラウド サービスに関連する期待と義務を両者が明確に理解できるようにします。
SLO を追跡する:
Cloud Monitoring とサービスレベル指標（SLI）を使用して SLO を追跡します。Cloud Monitoring は、包括的なモニタリングとオブザーバビリティ機能を提供します。これにより、組織はクラウドベースのアプリケーションとサービスの可用性、パフォーマンス、レイテンシに関連する指標を収集して分析できます。SLI は、SLO を測定して経時的に追跡するために使用できる特定の指標です。これらのツールを活用することで、クラウド サービスを効果的にモニタリングして管理し、SLO と SLA を満たすことができます。
すべての重要なクラウド サービスの SLO と SLA を明確に定義、伝達、追跡することで、デプロイされたアプリケーションとサービスの信頼性とパフォーマンスを確保できます。
包括的なオブザーバビリティを実装する
クラウド環境の健全性とパフォーマンスをリアルタイムで把握するには、Google Cloud Observability ツールとサードパーティ ソリューションを組み合わせて使用することをおすすめします。この推奨事項は、運用準備のプロセスとツールの重点分野に関連しています。
オブザーバビリティ ソリューションを組み合わせて実装すると、クラウド インフラストラクチャとアプリケーションのさまざまな側面をカバーする包括的なオブザーバビリティ戦略を立てることができます。Google Cloud Observability は、さまざまなGoogle Cloud サービス、アプリケーション、外部ソースから指標、ログ、トレースを収集、分析、可視化するための統合プラットフォームです。Cloud Monitoring を使用すると、リソースの使用率、パフォーマンス特性、リソースの全体的な健全性に関する分析情報を取得できます。
包括的なモニタリングを確保するには、CPU 使用率、メモリ使用量、ネットワーク トラフィック、ディスク I/O、アプリケーションの応答時間など、システムの健全性指標に沿った重要な指標をモニタリングします。ビジネス固有の指標も検討する必要があります。これらの指標を追跡することで、潜在的なボトルネック、パフォーマンスの問題、リソース制約を特定できます。また、潜在的な問題や異常について、関連チームに事前に通知するアラートを設定することもできます。
モニタリング機能をさらに強化するには、サードパーティ ソリューションを Google Cloud Observability と統合します。これらのソリューションは、高度な分析、ML を活用した異常検出、インシデント管理機能などの追加機能を提供できます。Google Cloud Observability ツールとサードパーティ ソリューションを組み合わせることで、特定のニーズに合わせてカスタマイズ可能な堅牢なモニタリング エコシステムを構築できます。この組み合わせのアプローチを使用すると、問題を事前に特定して対処し、リソース使用率を最適化し、クラウド アプリケーションとサービスの全体的な信頼性と可用性を確保できます。
パフォーマンス テストと負荷テストを実装する
パフォーマンス テストを定期的に実施することで、クラウドベースのアプリケーションとインフラストラクチャがピーク時の負荷を処理し、最適なパフォーマンスを維持できることを確認できます。負荷テストでは、現実的なトラフィック パターンがシミュレートされます。ストレステストでは、システムを限界までプッシュして、潜在的なボトルネックとパフォーマンスの制限を特定します。この推奨事項は、運用準備のプロセスとツールの重点分野に関連しています。
パフォーマンスをテストする: Cloud Load Balancing と負荷テスト サービスを使用して、実際のトラフィック パターンをシミュレートし、アプリケーションのストレステストを行います。これらのツールは、さまざまな負荷条件でのシステムの動作に関する貴重な分析情報を提供し、最適化が必要な領域を特定するのに役立ちます。
パフォーマンスを最適化する: パフォーマンス テストの結果に基づいて、最適なパフォーマンスとスケーラビリティを実現するようにクラウド インフラストラクチャとアプリケーションを最適化する意思決定を行うことができます。この最適化には、リソース割り当ての調整、構成のチューニング、キャッシュ メカニズムの実装などが含まれます。
たとえば、トラフィックの多い期間にアプリケーションの速度が低下していることがわかった場合は、アプリケーションに割り当てられている仮想マシンまたはコンテナの数を増やす必要があるかもしれません。また、パフォーマンスを向上させるために、ウェブサーバーまたはデータベースの構成を調整する必要がある場合もあります。
パフォーマンス テストを定期的に実施し、必要な最適化を実装することで、クラウドベースのアプリケーションとインフラストラクチャが常に最高のパフォーマンスで実行され、ユーザーにシームレスで応答性の高いエクスペリエンスを提供できます。そうすることで、競争優位性を維持し、顧客との信頼関係を築くことができます。
容量を計画して管理する
クラウド システムを稼働させ、需要の変化に応じてスケーリングするには、クラウド リソースの容量を積極的に計画して管理する必要があります。この推奨事項は、運用の準備状況のプロセスとツールの重点分野をサポートしています。
サービスの上限を考慮してリソース割り当てを管理する: クラウド リソースの容量を計画するには、使用する予定のサービスのハード上限（固定制約）から始めます。
- 必要なコンピューティング、ストレージ、API 上限などのリソースの割り当て要件を見積もります。リソースが必要になる前に、適切な割り当て調整をリクエストします。
- Cloud Monitoring から BigQuery に指標を読み込み、指標を使用してトラフィック パターンを特定し、システム負荷を長期にわたって追跡します。
- 今後のマーケティング キャンペーン、ユーザー登録、機能のリリースに基づいて、リソースの需要を予測します。また、現在および計画中の SLA コミットメントも考慮してください。
柔軟性と効率性を考慮した設計: クラウド デプロイの容量を計画するときは、アプリケーション コンポーネントを特定のマシンタイプから切り離します。ワークロードを単一のマシンタイプに固定すると、新しいクラウド ハードウェアやリージョン容量の変更を利用できなくなります。
- 大容量メモリ インスタンスや GPU などの専用ハードウェアが必要なワークロードの場合は、必要に応じてリソースを取得できるようにします。将来の予約を使用すると、重要なマシンタイプの容量を 1 年先まで確保できます。
- 開始時間の変動を許容できるバッチ処理やモデル トレーニングのワークロードの場合は、Flex Start VM を使用して容量を動的にスケジュールします。これらの VM は、動的ワークロード スケジューリング（DWS）を使用してリクエストをキューに登録し、コンピューティング コストを削減します。
- 一時的な開発環境用に古いマシン ファミリーやリソースを予約しないようにします。
- 障害復旧（DR）のために効率的にフェイルオーバーできるように、セカンダリ リージョンのリソースを計画します。
自動スケーリングを実装する: クラウド リソースをリアルタイムのワークロードの変動に動的に適応させるには、自動スケーリング ポリシーを実装します。自動スケーリング アルゴリズムは、CPU 使用率、メモリ使用量、キューの深さなどの指標を評価します。評価に基づいて、トラフィックのピーク時にはリソースがスケールアウトされ、使用率の低い期間にはスケールインされるため、クラウド リソースの費用を最適化できます。
- 現行世代と新世代のマシンタイプを組み合わせた混合インスタンス テンプレートを使用して、マネージド インスタンス グループ（MIG）を構成します。
- MIG 構成に、インスタンスの柔軟性（複数の互換性のあるマシンタイプの指定）とロケーションの柔軟性（リージョン内の複数のゾーンにターゲットを分散）の両方が含まれていることを確認します。現在の容量要件に応じて、システムはフォールバック リストから次の優先マシンタイプを自動的にプロビジョニングします。リクエストをドロップしたり、コンピューティング リソースを制限したりすることはありません。
継続的にモニタリングして最適化する
クラウド ワークロードを管理して最適化するには、パフォーマンス指標を継続的にモニタリングして分析するプロセスを確立する必要があります。この推奨事項は、運用準備のプロセスとツールの重点分野に関連しています。
データを追跡して収集する:
継続的なモニタリングと分析のプロセスを確立するには、クラウド環境のさまざまな側面に関連するデータを追跡、収集、評価する必要があります。このデータを使用すると、改善の余地がある領域を事前に特定し、リソース使用率を最適化して、クラウド インフラストラクチャがパフォーマンスの期待値を常に満たすか、上回るようにすることができます。
ログとトレースを確認する:
ログは、システム イベント、エラー、警告に関する貴重な分析情報を提供します。トレースは、アプリケーションを通過するリクエストのフローに関する詳細情報を提供します。ログとトレースを分析することで、潜在的な問題を特定し、問題の根本原因を特定し、さまざまな条件下でのアプリケーションの動作をより深く理解できます。サービス間のラウンドトリップ時間などの指標は、ワークロードのボトルネックを特定して理解するのに役立ちます。
パフォーマンスを調整する:
パフォーマンス チューニング手法を使用して、アプリケーションのレスポンス時間と全体的な効率を大幅に最適化します。使用できる手法の例を次に示します。
- キャッシュ保存: アクセス頻度の高いデータをメモリに保存して、データベースのクエリや API 呼び出しを繰り返す必要性を減らします。
- データベースの最適化: インデックス作成やクエリの最適化などの手法を使用して、データベース オペレーションのパフォーマンスを向上させます。
- コード プロファイリング: リソースを過剰に消費したり、パフォーマンスの問題を引き起こしたりするコード領域を特定します。