クラウド ワークロードに信頼性の高いインフラストラクチャを構築するための最初のステップは、ワークロードの信頼性要件を特定することです。Google Cloud インフラストラクチャ信頼性ガイドのこのパートでは、Google Cloud にデプロイするワークロードの信頼性要件を定義するためのガイドラインについて説明します。
ワークロード固有の要件を決定する
アプリケーションの信頼性の要件は、アプリケーションが提供するサービスの性質や、アプリケーションで実行するプロセスによって異なります。たとえば、銀行に ATM サービスを提供するアプリケーションでは、99.999% の可用性が必要になる場合があります。オンライン取引プラットフォームをサポートするウェブサイトは、99.999% の可用性と迅速なレスポンスを必要とする場合があります。毎日の終わりに銀行取引を会計ソースに書き込むバッチプロセスでは、データの更新頻度の目標を 8 時間に設定する場合があります。
アプリケーション内の個々のコンポーネントや操作の信頼性の要件は異なる場合があります。たとえば、注文処理アプリケーションでは、読み取りリクエストと比較して、注文データベースにデータを書き込むオペレーションの信頼性が高い可能性があります。
ワークロードの信頼性要件を細かく評価すると、ビジネスにとって重要なワークロードに費用と労力を集中させることができます。
重要な期間を特定する
他の時間よりもアプリケーションの重要度が増す場合があります。このような期間は、多くの場合、アプリケーションの負荷がピークになります。これらの期間を特定し、十分な容量を計画して、ピーク負荷の条件に対してアプリケーションをテストします。負荷のピーク時のアプリケーションの停止のリスクを回避するには、本番環境のコードを凍結するなどの適切な運用方法を使用します。
季節的な負荷の急増が発生するアプリケーションの例を次に示します。
- 財務会計アプリケーションのインベントリ モジュールは、通常、月次、四半期、または年次在庫監査がスケジュールされる日に頻繁に使用されます。
- e コマース ウェブサイトでは、ショッピングの繁忙期やプロモーション イベントに負荷が大幅に急増します。
- 大学の学生入学モジュールをサポートするデータベースでは、毎年特定の月に大量の書き込みオペレーションが発生します。
- オンラインの税務申告サービスは、税務申告の時期に負荷が高くなります。
- オンライン取引プラットフォームは、99.999% の可用性と迅速な応答時間を必要とする場合がありますが、ただし、取引時間内のみです（たとえば、月曜日から金曜日までの午前 8 時から午後 5 時など）。
その他の非機能要件を検討する
信頼性要件以外にも、エンタープライズ アプリケーションには、セキュリティ、パフォーマンス、費用、運用効率に関する重要な非機能要件がある場合があります。アプリケーションの信頼性要件を評価する際は、これらの他の要件との依存関係やトレードオフを考慮してください。
信頼性ではなく、信頼性要件とのトレードオフが伴う可能性のある要件の例を次に示します。
- 費用の最適化: IT 費用を最適化するために、特定のクラウド リソースに対して割り当てを制限している場合があります。たとえば、サードパーティ ソフトウェア ライセンスの費用を削減するために、プロビジョニング可能なコンピューティング コアの数の割り当てを設定できます。保存できるデータ量とクロスリージョン ネットワーク トラフィックの量には、同様の割り当てを使用できます。これらの費用の制約が、信頼性の高いインフラストラクチャを設計するためのオプションに与える影響を考慮してください。
- データ所在地: 規制要件を満たすために、アプリケーションが世界中のユーザーにサービスを提供する場合でも、特定の国でデータを保存して処理する必要があります。アプリケーションをデプロイできるリージョンとゾーンを決定する際は、このようなデータ所在地の制約を考慮してください。
他の要件を満たすために行う設計上の決定は、アプリケーションの信頼性の向上に役立ちます。以下に、いくつかの例を示します。
- デプロイの自動化: クラウドのデプロイを効率的に運用するために、Infrastructure as Code（IaC）を使用してプロビジョニング フローを自動化することもできます。同様に、継続的インテグレーションと継続的デプロイ（CI/CD）パイプラインを使用して、アプリケーションの構築とデプロイのプロセスを自動化することもできます。IaC と CI/CD パイプラインを使用すると、運用効率だけでなく、ワークロードの信頼性を向上させることもできます。
- セキュリティ管理: セキュリティ管理を実装すると、アプリケーションの可用性の向上にも役立ちます。たとえば、Google Cloud Armor セキュリティ ポリシーにより、サービス拒否（DoS）攻撃を受けたときにアプリケーションの可用性を維持できます。
- コンテンツ キャッシュ: コンテンツ提供アプリケーションのパフォーマンスを改善するために、ロードバランサの構成の一部としてキャッシュを有効にできます。この設計により、ユーザーはコンテンツに迅速にアクセスできるだけでなく、可用性も高くなります。送信元サーバーがダウンしている場合でも、キャッシュに保存されたコンテンツにアクセスできます。
要件を定期的に再評価する
ビジネスの成長と成長に伴い、アプリケーションの要件も変化する可能性があります。信頼性要件を定期的に再評価し、組織の現在のビジネス目標と優先事項に沿っていることを確認します。
すべてのユーザーに標準レベルの可用性を提供しているアプリケーションについて考えてみましょう。フロントエンドをリージョン ロードバランサとして、リージョン内の 2 つのゾーンにアプリケーションをデプロイする場合があります。組織で高可用性を提供するプレミアム サービス オプションのリリースを計画している場合、アプリケーションの信頼性要件は変更されています。新しい可用性の要件を満たすには、アプリケーションを複数のリージョンにデプロイし、Cloud CDN を有効にしたグローバル ロードバランサを使用する必要があります。
アプリケーションの可用性要件を再評価するもう 1 つの方法は、サービス停止の発生後です。サービスの停止により、ビジネス内のさまざまなチーム間で不一致が予想される可能性があります。たとえば、1 つのチームは 1 年に 45 分の停止（つまり、99.99% の年間可用性）を許容している場合があります。ただし、別のチームは、1 か月 4.3 分の最大ダウンタイム（つまり、99.99% の月間可用性）を想定している場合があります。可用性の要件をどのように変更または明確にするかに応じて、新しい要件を満たすようにアーキテクチャを調整する必要があります。