Google Cloud アーキテクチャフレームワーク

Last reviewed 2023-11-09 UTC

Google Cloud アーキテクチャフレームワークは、アーキテクト、デベロッパー、管理者、およびその他のクラウドの実務担当者が、安全で効率的、復元性が高く、高パフォーマンスで費用対効果に優れたクラウドトポロジを設計および運用するためのベストプラクティスと最適化案を提供します。Google Cloud アーキテクチャフレームワークは、Google Cloud による適切に設計されたフレームワークです。

Google の複数の部門にまたがるエキスパートのチームが、アーキテクチャフレームワークを構成する設計の最適化案とベストプラクティスを検証します。チームがアーキテクチャフレームワークをキュレートし、Google Cloud の拡張機能、業界のベストプラクティス、コミュニティの知識、ユーザーからのフィードバックを反映させます。主な変更の概要については、最新情報をご覧ください。

アーキテクチャフレームワークの設計ガイダンスは、クラウド用に構築されたアプリケーションと、オンプレミスから Google Cloud に移行されたワークロード、ハイブリッドクラウドのデプロイメント、マルチクラウド環境に適用されます。

次の図に示すように、Google Cloud アーキテクチャフレームワークは 6 つのカテゴリ（別名柱）に編成されています。

Google Cloud アーキテクチャフレームワーク

システム設計: このカテゴリは、Google Cloud アーキテクチャフレームワークの基盤を構成するものです。クラウドシステムの要件を満たすために必要なアーキテクチャ、コンポーネント、モジュール、インターフェース、データを定義し、システム設計をサポートする Google Cloud のプロダクトと機能について確認します。
オペレーショナルエクセレンス: クラウドワークロードを効率的にデプロイ、運用、モニタリング、管理します。
セキュリティ、プライバシー、コンプライアンス: クラウド内のデータとワークロードのセキュリティを最大化し、プライバシーを考慮した設計を行い、規制要件と標準に対応します。
信頼性: クラウドで復元性と高可用性を備えたワークロードを設計し、運用します。
費用の最適化: Google Cloud への投資のビジネス上の価値を最大化します。
パフォーマンスの最適化: パフォーマンスが最適化されるようにクラウドリソースを設計、調整します。

Google Cloud プロダクトの概要とそれらの相互関係の仕組みについては、Google Cloud のプロダクト、機能、サービスを簡潔に説明をご覧ください。

Google Cloud アーキテクチャフレームワーク: システム設計

システム設計は、Google Cloud アーキテクチャフレームワークの基礎となるカテゴリです。このカテゴリでは設計に関する推奨事項を提示し、クラウドプラットフォームのアーキテクチャ、コンポーネント、モジュール、インターフェース、データを定義して、システム要件を満たすためのベストプラクティスと原則について説明します。また、システム設計をサポートする Google Cloud のプロダクトと機能についても説明します。

システム設計カテゴリのドキュメントでは、基本的なシステム設計の原則を理解していることを前提としています。クラウドのコンセプトと Google Cloud プロダクトに関する知識があることは前提としていません。

複雑なクラウドの移行とデプロイのシナリオでは、Google Cloud コンサルティングサービスの利用をおすすめします。Google のコンサルタントがベストプラクティスと指針についての専門知識を提供し、お客様のクラウド移行の成功を支援します。Google Cloud にはパートナーの強力なエコシステムもあります。大規模なグローバルシステムインテグレータから ML のような特定分野を専門とするパートナーまで、さまざまなパートナーが参加しています。デジタルトランスフォーメーションを加速し、ビジネスの成果の向上のために、Google Cloud パートナーと連携することをおすすめします。

アーキテクチャフレームワークのシステム設計カテゴリーでは、次の方法を学びます。

システム設計の基本原則

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、システム設計の基本原則について説明します。堅牢なシステム設計とは、安全性、信頼性、拡張性、独立性を備えたものです。これにより、システムを停止することなく、反復と取り消しが可能な変更を行い、潜在的なリスクを最小限に抑え、運用効率を向上させることができます。堅牢なシステム設計を実現するには、以下の 4 つの基本原則に沿うことをおすすめします。

すべてを文書化する

ワークロードのクラウドへの移行やアプリケーションの構築を開始する際に、システムのドキュメントが不足していることが成功を妨げる主な要因となります。現在のデプロイのアーキテクチャを正しく可視化するには、ドキュメントが特に重要です。

クラウドアーキテクチャを適切に文書化することで、共通の言語と標準が確立され、部門横断的なチーム間でのコミュニケーションとコラボレーションを効果的に行いやすくなります。また、将来的な設計上の意思決定を促し、指針にするために必要な情報も提供します。設計上の意思決定に対応する内容を提供するため、ユースケースを念頭に置いてドキュメントを作成する必要があります。

時間の経過とともに、設計上の意思決定は進化、変化していきます。変更履歴があれば、チームが構想を調整し、重複を避け、時間の経過に沿ったパフォーマンスの変化を効果的に測定するために必要な背景情報が得られます。現在のシステム設計、戦略、過去の経緯をよく理解していない新しいクラウドアーキテクトをオンボーディングする場合、変更ログは特に役立ちます。

設計を簡素化し、フルマネージドサービスを利用する

システム設計にはシンプルさが重要です。アーキテクチャが複雑すぎて理解しにくい場合、設計を実装して時間の経過とともに管理することが難しくなります。可能であれば、フルマネージドサービスを使用して、ベースラインシステムの管理とメンテナンスに伴うリスク、時間、労力を最小限に抑えてください。

本番環境ですでにワークロードを実行している場合は、マネージドサービスでテストして、運用の複雑さがどのように軽減されるかをご確認ください。新しいワークロードを開発している場合は、単純なものから最小実装製品（MVP）を確立して、オーバーエンジニアリングへの抵抗感を和らげてください。特殊なユースケースを特定し、イテレーションを行い、時間をかけて段階的にシステムを改善していくことができます。

アーキテクチャを分離する

分離とは、アプリケーションやサービスコンポーネントを、独立して動作できる小さなコンポーネントに分離するために使用される手法です。たとえば、モノリシックアプリケーションスタックを個別のサービスコンポーネントに分割できます。分離されたアーキテクチャでは、さまざまな依存関係に関係なく、アプリケーションは機能を個別に実行できます。

アーキテクチャを分離することで、柔軟性が向上し、次のことが可能になります。

独立したアップグレードを適用する。
特定のセキュリティ管理を実施する。
サブシステムごとに信頼性の目標を設定する。
正常性をモニタリングする。
パフォーマンスとコストのパラメータをきめ細かく制御する。

分離は、設計段階早期から始めることも、規模の拡大に伴うシステムアップグレードの一部として行うこともできます。

ステートレスアーキテクチャを使用する

ステートレスアーキテクチャでは、アプリケーションの信頼性とスケーラビリティの両方を向上させることができます。

ステートフルアプリケーションは、ローカルのキャッシュに保存されたデータなど、さまざまな依存関係を使用してタスクを実行します。ステートフルアプリケーションでは、多くの場合、進捗状況をキャプチャして正常に再起動するための追加のメカニズムが必要です。ステートレスアプリケーションは、共有ストレージやキャッシュサービスを使用することで、ローカルの依存関係をさほど利用することなくタスクを実行できます。ステートレスアーキテクチャを使用すると、ブート依存関係を最小限に抑え、アプリケーションを迅速にスケールアップできます。アプリケーションは強制的な再起動に耐え、ダウンタイムを短縮し、エンドユーザーのパフォーマンスを高めることができます。

システム設計のカテゴリでは、アプリケーションをステートレスにするための推奨事項、すなわちステートフルアプリケーションのためのマシン状態の取得を改善するためにクラウドネイティブの機能を利用する方法について説明しています。

次のステップ

Google Cloud デプロイアーキタイプを選択する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、6 つのデプロイアーキタイプ¹（ゾーン、リージョン、マルチリージョン、グローバル、ハイブリッド、マルチクラウド）について説明します。これらを使用して、可用性、コスト、パフォーマンス、運用効率の要件に基づいてクラウドワークロード用のアーキテクチャを構築できます。

デプロイアーキタイプとは

デプロイアーキタイプは、プロバイダに依存しない抽象化されたモデルです。これを基盤として使用することにより、ビジネス要件と技術要件を満たすアプリケーション固有のデプロイアーキテクチャを構築できます。各デプロイアーキタイプは、アプリケーションを実行できる障害発生ドメインの組み合わせを表します。これらの障害発生ドメインは 1 つ以上の Google Cloud ゾーンまたはリージョンにすることができます。また、オンプレミスデータセンターや他の障害発生ドメインが含まれるように拡張することもできます。

次の図は、Google Cloud にデプロイされた 6 つのアプリケーションを示しています。各アプリケーションは、特定の要件を満たすデプロイアーキタイプを使用します。

異なるデプロイアーキタイプを使用してデプロイされた Google Cloud のアプリケーション

上の図に示すように、ハイブリッドまたはマルチクラウドのデプロイアーキタイプを使用するアーキテクチャは、クラウドトポロジはゾーン、リージョン、マルチリージョン、またはグローバルの基本アーキタイプのいずれかをベースにしています。この意味で、ハイブリッドデプロイとマルチクラウドデプロイアーキタイプは、基本的なアーキタイプの一つを含む複合型のデプロイアーキタイプと考えることができます。

デプロイアーキタイプを選択すると、使用すべき Google Cloud プロダクトと機能に関するその後の決定を簡単に行うことができます。たとえば、高可用性のコンテナ化されたアプリケーションで、リージョンデプロイアーキタイプを選択した場合は、ゾーン GKE クラスタよりもリージョン Google Kubernetes Engine（GKE）クラスタのほうが適切な選択肢となります。

アプリケーションのデプロイアーキタイプは、可用性、費用、運用の複雑さなどのトレードオフを考慮して選択する必要があります。たとえば、アプリケーションが複数の国のユーザーにサービスを提供し、かつ高可用性が求められる場合は、マルチリージョンデプロイアーキタイプを選択します。一方、単一リージョンの従業員が使用する内部アプリケーションの場合は、可用性よりもコストを優先し、リージョンデプロイアーキタイプを選択したほうがかもしれません。

デプロイアーキタイプの概要

以下のタブでは、各デプロイアーキタイプの定義と、ユースケースの概要および設計上の考慮事項について説明します。

ゾーン

次の図に示すように、アプリケーションは単一の Google Cloud ゾーン内で実行されます。

ユースケース	開発環境とテスト環境。高可用性を必要としないアプリケーション。アプリケーションコンポーネント間の低レイテンシのネットワーキング。コモディティワークロードの移行。ライセンス制限付きソフトウェアを使用するアプリケーション。
設計上の考慮事項	ゾーン停止中のダウンタイム。ビジネスの継続性のために、アプリケーションのパッシブレプリカを同じリージョン内の別のゾーンにプロビジョニングできます。ゾーンが停止した場合は、パッシブレプリカを使用してアプリケーションを本番環境に復元できます。
詳細	次のセクションをご覧ください。ゾーンデプロイアーキタイプデプロイアーキタイプの比較分析

ユースケース

開発環境とテスト環境。
高可用性を必要としないアプリケーション。
アプリケーションコンポーネント間の低レイテンシのネットワーキング。
コモディティワークロードの移行。
ライセンス制限付きソフトウェアを使用するアプリケーション。

設計上の考慮事項

ゾーン停止中のダウンタイム。

ビジネスの継続性のために、アプリケーションのパッシブレプリカを同じリージョン内の別のゾーンにプロビジョニングできます。ゾーンが停止した場合は、パッシブレプリカを使用してアプリケーションを本番環境に復元できます。

詳細

次のセクションをご覧ください。

リージョン

次の図に示すように、アプリケーションは単一の Google Cloud リージョン内の複数のゾーンで独立して実行されます。

ユースケース	地域内でユーザーにサービスを提供する高可用性アプリケーション。データ所在地と主権の要件の遵守
設計上の考慮事項	リージョン停止中のダウンタイム。ビジネスの継続性のために、アプリケーションとデータを別のリージョンにバックアップできます。リージョンが停止した場合は、他のリージョンのバックアップを使用して、アプリケーションを本番環境に復元できます。冗長リソースのプロビジョニングや管理にかかる費用と労力。
詳細	次のセクションをご覧ください。リージョンデプロイアーキタイプデプロイアーキタイプの比較分析

ユースケース

地域内でユーザーにサービスを提供する高可用性アプリケーション。
データ所在地と主権の要件の遵守

設計上の考慮事項

リージョン停止中のダウンタイム。

ビジネスの継続性のために、アプリケーションとデータを別のリージョンにバックアップできます。リージョンが停止した場合は、他のリージョンのバックアップを使用して、アプリケーションを本番環境に復元できます。
冗長リソースのプロビジョニングや管理にかかる費用と労力。

詳細

次のセクションをご覧ください。

マルチリージョン

アプリケーションは、2 つ以上の Google Cloud リージョンの複数のゾーンで独立して実行されます。DNS ルーティングポリシーを使用して、受信トラフィックをリージョンロードバランサにルーティングできます。次の図に示すように、リージョンロードバランサは、トラフィックをアプリケーションのゾーンのレプリカに分散します。

ユースケース	地理的に分散したユーザーが使用する高可用性アプリケーション。エンドユーザーの低レイテンシエクスペリエンスを必要とするアプリケーション。ジオフェンス DNS ルーティングポリシーによるデータ所在地と主権の要件の遵守。
設計上の考慮事項	クロスリージョンのデータ転送とデータレプリケーションのコスト。運用の複雑さ。
詳細	次のセクションをご覧ください。マルチリージョンデプロイアーキタイプデプロイアーキタイプの比較分析

ユースケース

地理的に分散したユーザーが使用する高可用性アプリケーション。
エンドユーザーの低レイテンシエクスペリエンスを必要とするアプリケーション。
ジオフェンス DNS ルーティングポリシーによるデータ所在地と主権の要件の遵守。

設計上の考慮事項

クロスリージョンのデータ転送とデータレプリケーションのコスト。
運用の複雑さ。

詳細

次のセクションをご覧ください。

グローバル

アプリケーションは、グローバルに分散された（ロケーション非認識の）スタックまたはリージョンに分離されたスタックとして、世界中の Google Cloud リージョンで実行されます。グローバルエニーキャストロードバランサが、ユーザーに最も近いリージョンにトラフィックを割り当てます。アプリケーションスタックの他のコンポーネント（データベース、キャッシュ、オブジェクトストアなど）もグローバルにできます。

次の図は、グローバルデプロイアーキタイプの、グローバルに分散されたバリアントを示しています。グローバルエニーキャストロードバランサは、複数のリージョンに分散され、グローバルに複製されたデータベースを使用するアプリケーションスタックにリクエストを転送します。

次の図は、リージョンに分離されたアプリケーションスタックでのグローバルデプロイアーキタイプのバリアントを示しています。グローバルエニーキャストロードバランサは、いずれかのリージョンのアプリケーションスタックにリクエストを転送します。すべてのアプリケーションスタックは、グローバルに複製された単一のデータベースを使用します。

ユースケース	グローバルに分散したユーザーにサービスを提供する高可用性アプリケーション。リージョンリソースの複数のインスタンスではなく、グローバルリソースを使用することで、費用の最適化と運用の簡素化を実現する機会が得られます。
設計上の考慮事項	クロスリージョンのデータ転送とデータレプリケーションのコスト。
詳細	次のセクションをご覧ください。グローバルデプロイアーキタイプデプロイアーキタイプの比較分析

ユースケース

グローバルに分散したユーザーにサービスを提供する高可用性アプリケーション。
リージョンリソースの複数のインスタンスではなく、グローバルリソースを使用することで、費用の最適化と運用の簡素化を実現する機会が得られます。

設計上の考慮事項

クロスリージョンのデータ転送とデータレプリケーションのコスト。

詳細

次のセクションをご覧ください。

ハイブリッド

次の図に示すように、アプリケーションの特定の部分は Google Cloud にデプロイされ、他の部分はオンプレミスで実行されます。Google Cloud のトポロジでは、ゾーン、リージョン、マルチリージョン、またはグローバルのデプロイアーキタイプを使用できます。

ユースケース	オンプレミスワークロードの障害復旧（DR）サイト。クラウドアプリケーションのオンプレミス開発。レガシーアプリケーションのクラウドへの段階的移行。クラウド機能によるオンプレミスアプリケーションの機能強化。
設計上の考慮事項	セットアップの労力と運用の複雑さ。冗長リソースのコスト。
詳細	次のセクションをご覧ください。ハイブリッドデプロイアーキタイプデプロイアーキタイプの比較分析

ユースケース

オンプレミスワークロードの障害復旧（DR）サイト。
クラウドアプリケーションのオンプレミス開発。
レガシーアプリケーションのクラウドへの段階的移行。
クラウド機能によるオンプレミスアプリケーションの機能強化。

設計上の考慮事項

セットアップの労力と運用の複雑さ。
冗長リソースのコスト。

詳細

次のセクションをご覧ください。

マルチクラウド

次の図に示すように、アプリケーションの一部は Google Cloud にデプロイされ、他の部分は他のクラウドプラットフォームにデプロイされます。各クラウドプラットフォームのトポロジは、ゾーン、リージョン、マルチリージョン、グローバルのデプロイアーキタイプを使用できます。

ユースケース	Google Cloud をプライマリサイトに、別のクラウドを DR サイトに。 Google Cloud の高度な機能によるアプリケーションの機能強化
設計上の考慮事項	セットアップの労力と運用の複雑さ。冗長リソースとクロスクラウドネットワークトラフィックの費用
詳細	次のセクションをご覧ください。マルチクラウドデプロイアーキタイプデプロイアーキタイプの比較分析

ユースケース

Google Cloud をプライマリサイトに、別のクラウドを DR サイトに。
Google Cloud の高度な機能によるアプリケーションの機能強化

設計上の考慮事項

セットアップの労力と運用の複雑さ。
冗長リソースとクロスクラウドネットワークトラフィックの費用

詳細

次のセクションをご覧ください。

地理的ゾーンとリージョンを選択する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、地理的要件に基づいてシステムをデプロイするためのベストプラクティスについて説明します。ここでは、可用性のサポートと近接性に基づいて最適な地理的ゾーンとリージョンを選択して、コンプライアンスをサポートし、費用の最適化とロードバランシングの実装を行う方法を学習します。

ビジネスアプリケーションに 1 つまたは複数のリージョンを選択する場合は、サービスの可用性、エンドユーザーのレイテンシ、アプリケーションのレイテンシ、コスト、規制またはサステナビリティ要件などの基準を考慮します。ビジネスの優先順位とポリシーをサポートするには、これらの要件のバランスを取り、最適なトレードオフを特定します。たとえば、最も規制を遵守しているリージョンが最も費用対効果の高いリージョンとは限りません。また、二酸化炭素排出量が最も少ないリージョンでない可能性もあります。

複数のリージョンにデプロイする

リージョンは、複数のゾーンから構成された地理的に独立したエリアです。ゾーンは、リージョン内にある Google Cloud リソースのデプロイエリアです。各ゾーンは、リージョン内の単一障害発生ドメインとなります。

予想されるダウンタイム（メンテナンスを含む）から保護し、インシデントなどの予期しないダウンタイムから保護するには、高可用性を備えたフォールトトレラントなアプリケーションをデプロイし、1 つ以上のリージョンの複数のゾーンにアプリケーションをデプロイすることをおすすめします。詳細については、地域とリージョン、アプリケーションのデプロイに関する考慮事項、Compute Engine リージョンの選択に関するベストプラクティスをご覧ください。

費用やその他の考慮事項が原因でマルチリージョンデプロイが制限されている場合、マルチゾーンデプロイにより復元力を実現できます。このアプローチは、ゾーンまたはリージョンの停止を防ぎ、障害復旧とビジネスの継続性の問題に対処する際に特に役立ちます。詳細については、スケールと高可用性のための設計をご覧ください。

地理的な近接性に基づいてリージョンを選択する

レイテンシはユーザーエクスペリエンスに影響を与えるだけでなく、外部ユーザーへのサービス提供に関連するコストにも影響します。外部ユーザーにトラフィックを提供する際のレイテンシを最小限に抑えるには、ユーザーと地理的に近いリージョンまたはリージョンセットを選択し、サービスがコンプライアンスを遵守した方法で実行されるようにします。詳細については、Cloud のロケーションとコンプライアンスリソースセンターをご覧ください。

利用可能なサービスに基づいてリージョンを選択する

ビジネスで使用可能なサービスに基づいてリージョンを選択します。ほとんどのサービスはすべてのリージョンで利用できます。一部のエンタープライズ向けサービスでは、最初のリリースがリージョンのサブセットに限定されている場合があります。リージョンの選択を確認するには、クラウドのロケーションをご覧ください。

コンプライアンスをサポートするリージョンを選択する

一般データ保護規則（GDPR）やデータ所在地など、特定のリージョンの使用を必要とする地理的規制またはコンプライアンスの規制を満たすため、特定のリージョンまたはリージョンセットを選択します。安全なシステムの設計の詳細については、コンプライアンスサービスと Google Cloud の欧州のお客様向けのデータ所在地、運用の透明性、プライバシーをご覧ください。

主要なリソースの料金を比較する

同じサービスでもリージョンによって料金が異なります。費用対効果の高いリージョンを特定するには、使用する予定の主要なリソースの料金を比較します。コストに関する考慮事項は、バックアップの要件や、コンピューティング、ネットワーキング、データストレージなどのリソースによって異なります。詳細については、コスト最適化のカテゴリをご覧ください。

Cloud Load Balancing を使用してグローバルユーザーにサービスを提供する

グローバルなユーザーにサービスを提供する際のユーザーエクスペリエンスを向上させるには、Cloud Load Balancing を使用して、アプリケーションにルーティングされる単一の IP アドレスを提供します。信頼性の高いシステムの設計の詳細については、Google Cloud アーキテクチャフレームワーク: 信頼性をご覧ください。

サステナビリティをサポートする Cloud Region Picker を使用する

Google は 2007 年からカーボンニュートラルを達成し、2030 年までにカーボンフリーを目指しています。二酸化炭素排出量に基づいてリージョンを選択するには、Google Cloud リージョン選択ツールを使用します。サステナビリティに向けた設計について詳しくは、クラウドのサステナビリティをご覧ください。

次のステップ

Google Cloud のリソース階層である Resource Manager と組織のポリシーサービスを使用してクラウドリソースを管理する方法を確認する。

アーキテクチャフレームワークの他のカテゴリ（信頼性、オペレーショナルエクセレンス、セキュリティ、プライバシー、コンプライアンスなど）を確認する。

クラウドリソースを管理する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud でリソースを整理および管理するためのベストプラクティスについて説明します。

リソース階層

Google Cloud のリソースは、組織、フォルダ、プロジェクトに階層的に配置されています。このような階層を使用することで、アクセス制御、構成設定、ポリシーなどリソースに共通する要素を簡単に管理できます。クラウドリソースの階層を設計するためのベストプラクティスについては、Google Cloud ランディングゾーンのリソース階層を決定するをご覧ください。

リソースラベルとタグ

このセクションでは、ラベルとタグを使用して Google Cloud リソースを整理するためのベストプラクティスについて説明します。

シンプルなフォルダ構造を使用する

フォルダを使用すると、プロジェクトとサブフォルダを任意に組み合わせることができます。Google Cloud リソースを整理するシンプルなフォルダ構造を作成します。必要に応じてレベルを追加して、ビジネスニーズをサポートできます。フォルダ構造は柔軟で拡張可能です。詳細については、フォルダの作成と管理をご覧ください。

フォルダとプロジェクトを使用してデータガバナンスポリシーを反映させる

組織内のデータガバナンスポリシーを反映するように、フォルダ、サブフォルダ、プロジェクトを使用してリソースを分離できます。たとえば、フォルダとプロジェクトの組み合わせを使用して、財務、人事、エンジニアリングを分離できます。

プロジェクトを使用して、同じ信頼境界を共有するリソースをグループ化してください。たとえば、同じプロダクトやマイクロサービスのリソースは、同じプロジェクトに含めることができます。詳細については、Google Cloud ランディングゾーンのリソース階層を決定するをご覧ください。

プロジェクトの開始時にタグとラベルを使用する

Google Cloud プロダクトを初めて使うときにラベルとタグを使用できます（必ずしもすぐに使う必要はありません）。後でラベルとタグを追加する作業は手作業で行う必要があり、エラーが発生しやすくなります。

タグを使用すると、リソースに特定のタグが付加されているかどうかに基づいて、条件付きでポリシーの許可や拒否を行えます。ラベルとは、Google Cloud のインスタンスを整理する際に役立つ Key-Value ペアです。ラベルの詳細については、ラベルの要件、ラベルをサポートするサービスのリスト、ラベルの形式をご覧ください。

Resource Manager が提供するラベルとタグは、リソースの管理やコストの割り当てとレポートに役立ちます。また、きめ細かいアクセス制御を行うために、異なるリソースにポリシーを割り当てる際にも役立ちます。たとえば、ラベルとタグを使用して、さまざまなテナントリソースとサービスにきめ細かいアクセス権と管理の原則を適用できます。VM ラベルとネットワークタグの詳細については、VM ラベルとネットワークタグの関係をご覧ください。

ラベルは、次のようなさまざまな用途に使用できます。

リソースに対する課金の管理: 課金システムでラベルを使用して、コストをラベル別に分割できます。たとえば、異なるコストセンターや予算にラベルを付けることができます。
類似した特性または関係に基づいたリソースのグループ化: ラベルを使用して、アプリケーションライフサイクルのさまざまなステージや環境を分離できます。たとえば、本番環境、開発環境、テスト環境にラベルを付けることができます。

ラベルを割り当てて費用と請求のレポートをサポートする

統合レポート構造（プロジェクトごと、プロダクトごとなど）以外の属性に基づいて、詳細な費用と課金レポートをサポートするには、リソースにラベルを割り当てます。ラベルは、コストセンター、部門、特定のプロジェクトへの費用の割り当てや内部的な費用の振り替えに役立ちます。詳細については、費用最適化のカテゴリをご覧ください。

大量のラベルを作成しない

大量のラベルを作成しないでください。プロジェクトレベルでラベルを作成することをおすすめします。また、サブチームレベルではラベルを作成しないでください。必要以上に詳細なラベルを作成すると、分析にノイズが入る可能性があります。ラベルの一般的なユースケースについては、ラベルの一般的な使用例をご覧ください。

ラベルに機密情報を追加しない

ラベルは、機密情報を処理するように設計されていません。個人名や役職など、個人を特定できる情報もラベルには含めないでください。

プロジェクト名で情報を匿名化する

プロジェクト名は COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME のようにしてください。ここで、プレースホルダは一意なものとし、会社名やアプリケーション名は公表しないでください。チーム名やテクノロジーなど、将来変更される可能性がある属性は含めないでください。

タグを適用してビジネスディメンションをモデル化する

タグを適用すると、組織構造、リージョン、ワークロードの種類、コストセンターなど、追加のビジネスディメンションをモデル化できます。タグの詳細については、タグの概要、タグの継承、タグの作成と管理をご覧ください。タグをポリシーで使用する方法については、ポリシーとタグをご覧ください。タグを使用してアクセス制御を管理する方法については、タグとアクセス制御をご覧ください。

組織のポリシー

このセクションでは、クラウドリソース階層全体にわたる Google Cloud リソースにガバナンスルールを構成するためのベストプラクティスについて説明します。

プロジェクトの命名規則を確立する

SYSTEM_NAME-ENVIRONMENT（dev、test、uat、stage、prod）のように、標準化されたプロジェクト命名規則を設定します。

プロジェクト名の長さは 30 文字に制限されています。

COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG のような接頭辞を適用できますが、企業の再編があると、プロジェクト名が過去のものになる場合があります。プロジェクト名から識別可能な名前をプロジェクトラベルに移すことを検討してください。

プロジェクトの作成を自動化する

本番環境や大規模な企業向けのプロジェクトを作成するには、Deployment Manager や Google Cloud プロジェクトファクトリ Terraform モジュールのような自動プロセスを使用します。これらのツールは、次の処理を行います。

開発環境、テスト環境、本番環境を作成し、適切な権限のあるプロジェクトを自動的に作成します。
ロギングとモニタリングを構成する

Google Cloud プロジェクトファクトリ Terraform モジュールは、Google Cloud プロジェクトの作成を自動化する際に役立ちます。大企業では、Google Cloud でプロジェクトを作成する前に、プロジェクトを確認して承認することをおすすめします。このプロセスにより、次のことを保証できます。

費用を関連付ける。詳細については、費用最適化のカテゴリをご覧ください。
データアップロードの承認を行う。
規制やコンプライアンスの要件を満たす。

Google Cloud プロジェクトとリソースの作成や管理を自動化すると、整合性、再現性、テスト容易性の面でメリットを得られます。コードとして構成を扱うことで、ソフトウェアアーティファクトと一緒にバージョニングして、構成のライフサイクルを管理できます。自動化により、リソースに一貫した命名規則やラベル付けを行うなど、ベストプラクティスに対応できます。自動化により、要件の変化に合わせて、プロジェクトのリファクタリングを容易に行うことができます。

システムを定期的に監査する

新しいプロジェクトに対するリクエストが監査、承認されるようにするには、企業のチケットシステムや監査を提供するスタンドアロンシステムを統合します。

一貫性を保ってプロジェクトを構成する

プロジェクトは、組織のニーズが一貫して満たされるように構成します。プロジェクトを設定するときは、次のものを含めます。

プロジェクト ID と命名規則
請求先アカウントのリンク
ネットワーク構成
有効な API とサービス
Compute Engine のアクセス構成
ログのエクスポートと使用状況レポート
プロジェクト削除リーエン

ワークロードや環境を切り離す

割り当てと上限は、プロジェクトレベルで適用されます。割り当てと上限を管理するには、ワークロードや環境をプロジェクトレベルで切り離します。詳細については、割り当ての操作をご覧ください。

環境の分離は、データ分類の要件とは異なります。データをインフラストラクチャから分けることは、実装が高コストで複雑になるため、データの機密性とコンプライアンス要件に基づいてデータの分類を実装することをおすすめします。

課金の分離を適用する

課金の分離を適用して、異なる請求先アカウントに対応し、ワークロードや環境ごとの費用の可視性をサポートします。詳細については、セルフサービス Cloud 請求先アカウントの作成、変更、閉鎖とプロジェクトの課金の有効化、無効化、変更をご覧ください。

管理の複雑さを最小限に抑えるため、プロジェクトレベルの重要な環境や、複数のプロジェクトにまたがるワークロードに対して、詳細なアクセス管理を行います。重要な本番環境のアプリケーションにアクセス制御を作成すると、ワークロードを保護して安全に管理できます。

組織のポリシーサービスを使用してリソースを制御する

組織ポリシーサービスでは、ポリシー管理者に組織のクラウドリソースの一元管理と、プログラムによる制御権が与えられます。これにより、リソース階層全体にわたる制約を構成できます。詳細については、組織のポリシー管理者の追加をご覧ください。

組織のポリシーを使用して規制ポリシーを遵守する

コンプライアンス要件を満たすには、組織ポリシーサービスを使用して、リソースの共有とアクセスにコンプライアンス要件を適用します。たとえば、外部関係者との共有を制限したり、クラウドリソースを地理的にデプロイする場所を決定します。その他のコンプライアンスシナリオとしては次のものがあります。

制御の集中化により、組織のリソースの使用方法を定義する制限を構成する。
開発チームがコンプライアンスを遵守できるようにポリシーを定義して確立する。
規制遵守を維持し、さらにコンプライアンスルール違反の懸念を最小限に抑えながら、プロジェクトオーナーとチームがシステムを変更できるように支援する。

ドメインに基づいてリソースの共有を制限する

共有に関する制限された組織のポリシーを使用すると、Google Cloud リソースが組織外の ID と共有されるのを防ぐことができます。詳細については、ドメイン別の ID の制限と、組織のポリシーの制約をご覧ください。

サービスアカウントとキーの作成を無効にする

セキュリティを強化するには、Identity and Access Management（IAM）のサービスアカウントと対応するキーの使用を制限します。詳細については、サービスアカウントの使用を制限するをご覧ください。

新しいリソースの物理的な場所を制限する

リソースロケーションを制限して、新しく作成されたリソースの物理的なロケーションを制限します。組織のリソースを制御するための制約のリストについては、組織のポリシーのサービスの制約をご覧ください。

次のステップ

コンピューティングを選択して管理する方法を確認する。次のものを確認します。

コンピューティングを選択して管理する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、コンピューティング要件に基づいてシステムをデプロイするためのベストプラクティスについて説明します。コンピューティングプラットフォームと移行方法の選択、ワークロードの設計とスケーリング、オペレーションと VM 移行の管理を行う方法について説明します。

カスタムビジネスロジックの実行や、データセットに対する複雑な計算アルゴリズムの適用など、コンピューティングは多くのワークロードの中核となります。ほとんどのソリューションではなんらかの形でコンピューティングリソースが使用されます。そのため、アプリケーションのニーズに合ったコンピューティングリソースを選択することが重要です。

Google Cloud には、CPU 時間を使用するためのオプションがいくつか用意されています。オプションは、CPU タイプ、パフォーマンス、コードの実行スケジュール（使用量に対する課金を含む）に基づきます。

Google Cloud には、次のコンピューティングオプションが用意されています。

ライブマイグレーションなどのクラウド固有のメリットがある仮想マシン（VM）。
CPU を共有可能なクラスタマシン上のコンテナのビンパッキング。
関数とサーバーレスアプローチ。CPU 時間は、単一の HTTP リクエスト中に実行される作業で測定できます。

コンピューティングを選択する

このセクションでは、コンピューティングプラットフォームを選択して移行する際のベストプラクティスについて説明します。

コンピューティングプラットフォームを選択する

ワークロードにコンピューティングプラットフォームを選択する際は、ワークロードの技術要件、ライフサイクル自動化プロセス、リージョン指定、セキュリティを考慮してください。

アプリとサポートシステム全体による CPU 使用状況を評価します。たとえば、コードをパッケージ化してデプロイ、分散、呼び出す方法を評価します。複数のプラットフォームオプションとの互換性があるシナリオもありますが、ポータブルワークロードは、さまざまなコンピューティングオプションに対応し、高いパフォーマンスを実現する必要があります。

次の表に、さまざまなユースケースで推奨される Google Cloud コンピューティングサービスの概要を示します。

コンピューティングプラットフォーム	ユースケース	推奨プロダクト
サーバーレス	アプリを初めてデプロイする場合に使用します。インフラストラクチャオペレーションの維持ではなく、データと処理ロジック、アプリの開発に集中できます。	Cloud Run: このフルマネージドのサーバーレスオプションを使用して、ビジネスロジックをコンテナに格納します。Cloud Run は、コンピューティング負荷が高いものの、常時稼働しているわけではないワークロード向けに設計されています。コストゼロでトラフィックを効果的にスケーリングし、タスクとサービスの CPU と RAM を定義できます。1 つのコマンドでデプロイするだけで、Google によって適切な量のリソースが自動的にプロビジョニングされます。 Cloud Functions: ロードバランシング、更新、認証、スケーリングなどのインフラストラクチャに関する懸念なしに、コードを柔軟なビジネスロジックに分離します。
Kubernetes	サービスメッシュコントロールを管理するために Istio などの追加サービスを必要とする複雑なマイクロサービスアーキテクチャを構築します。	Google Kubernetes Engine: コンテナ化されたアプリのデプロイ、スケーリング、管理を自動化するオープンソースのコンテナオーケストレーションエンジン。
仮想マシン（VM）	アプリケーションやワークロードの要件を満たすだけでなく、サードパーティのソフトウェアとサービスにも対応している、カスタマイズ可能な事前定義の VM ファミリーから VM を作成して実行します。	Compute Engine: グラフィックプロセッシングユニット（GPU）を VM インスタンスに追加します。これらの GPU を使用して、インスタンスで実行される機械学習やデータ処理などの特定のワークロードを高速化できます。要件に基づいて適切なマシンタイプを選択するには、マシンファミリーに関する推奨事項をご覧ください。

詳細については、コンピューティングオプションの選択をご覧ください。

コンピューティングの移行アプローチを選択する

既存のアプリケーションを別のクラウドまたはオンプレミスから移行する場合は、次のいずれかの Google Cloud プロダクトを使用して、パフォーマンス、スケール、コスト、セキュリティを最適化します。

移行目標	ユースケース	推奨プロダクト
リフト＆シフト	VMware ワークロードを数分で Google Cloud に移行または拡張できます。	Google Cloud VMware Engine
リフト＆シフト	VM ベースのアプリケーションを Compute Engine に移行します。	Migrate to Virtual Machines
コンテナへのアップグレード	従来のアプリケーションを Google Kubernetes Engine の組み込みコンテナにモダナイズします。	Migrate to Containers

内部チームを連携させながらワークロードを移行する方法については、VM Migration のライフサイクルと Google Cloud を使用した大規模な移行プログラムの構築をご覧ください。

ワークロードの設計

このセクションでは、システムをサポートするワークロードを設計する際のベストプラクティスについて説明します。

シンプルなロジックのサーバーレスオプションを評価する

シンプルなロジックは、特別なハードウェアや CPU 最適化マシンなどのマシンタイプを必要としないコンピューティングタイプです。Google Kubernetes Engine（GKE）または Compute Engine の実装に投資して運用上のオーバーヘッドを抽象化し、コストとパフォーマンスを最適化する前に、軽量ロジック用のサーバーレスオプションを評価してください。

アプリケーションを分離してステートレスにする

可能であれば、アプリケーションを分離してステートレスにすることで、サーバーレスコンピューティングオプションを最大限に活用できます。このアプローチでは、マネージドコンピューティングサービスを使用して、需要に応じてアプリケーションをスケーリングするので、費用とパフォーマンスを最適化できます。アプリケーションを切り離してスケーリングと高可用性を実現するように設計する詳しい方法については、スケーリングと高可用性を設計するをご覧ください。

アーキテクチャの分離にキャッシュロジックを使用する

アプリケーションがステートフルに設計されている場合は、キャッシュロジックを使用して分離し、ワークロードをスケーラブルにします。詳しくは、データベースに関するベストプラクティスをご覧ください。

ライブマイグレーションを使用してアップグレードを促進する

Google のメンテナンスアップグレードを容易にするために、インスタンスの可用性ポリシーを設定してライブマイグレーションを使用します。詳細については、VM ホストメンテナンスポリシーの設定をご覧ください。

ワークロードのスケーリング

このセクションでは、システムをサポートするためにワークロードをスケーリングする際のベストプラクティスについて説明します。

起動スクリプトとシャットダウンスクリプトを使用する

ステートフルアプリケーションの場合は、可能であれば起動スクリプトとシャットダウンスクリプトを使用して、アプリケーションの起動と停止を正常に行います。正常な起動とは、コンピュータがソフトウェアによって起動され、オペレーティングシステムがプロセスを安全に開始して接続を開始できる状態を意味します。

ステートフルアプリケーションは、コンピューティングリソース（ローカルディスク、永続ディスク、RAM など）の近くにあるデータをいつでも利用できる状態にしておく必要があるため、正常な起動とシャットダウンは重要です。起動のたびにアプリケーションデータを最初から読み込まないようにするには、起動スクリプトを使用して、最後に保存したデータを再度読み込みし、シャットダウン時に前回停止した場所からプロセスを実行します。シャットダウン時に進行状況が失われるのを回避するため、シャットダウンスクリプトを使用して、アプリケーションのメモリの状態を保存します。たとえば、ダウンスケーリングや Google のメンテナンスイベントにより VM がシャットダウンされる予定がある場合に、シャットダウンスクリプトを使用します。

MIG を使用して VM 管理をサポートする

Compute Engine VM を使用する場合、マネージドインスタンスグループ（MIG）は、自動修復、ロードバランシング、自動スケーリング、自動更新、ステートフルワークロードなどの機能をサポートしています。可用性の目標に基づいて、ゾーン MIG またはリージョン MIG を作成できます。MIG は、ステートレスサービスやバッチワークロードのほか、各 VM に固有の状態を保持する必要があるステートフルアプリケーションに使用できます。

Pod オートスケーラーを使用して GKE ワークロードをスケーリングする

水平および垂直 Pod オートスケーラーを使用してワークロードをスケールし、ノードの自動プロビジョニングを使用して基盤となるコンピューティングリソースをスケールします。

アプリケーショントラフィックを分散する

アプリケーションをグローバルにスケーリングするには、Cloud Load Balancing を使用してアプリケーションインスタンスを複数のリージョンまたはゾーンに分散します。ロードバランサは、Google Cloud エッジネットワークから最も近いゾーンへのパケットルーティングを最適化することで、トラフィックの処理効率を高め、コストを最小限に抑えます。エンドユーザーのレイテンシを最適化するには、Cloud CDN を使用して、静的コンテンツを可能な限りキャッシュに保存します。

コンピューティングの作成と管理を自動化する

コンピューティングの作成と管理を自動化することで、本番環境で人為的エラーを最小限に抑えます。

運用の管理

このセクションでは、システムをサポートするための運用管理のベストプラクティスについて説明します。

Google 提供の公開イメージを使用する

Google Cloud が提供する公開イメージを使用します。Google Cloud の公開イメージは定期的に更新されます。詳細については、Compute Engine で利用可能な公開イメージのリストをご覧ください。

特定の構成と設定で独自のイメージを作成することもできます。可能であれば、組織内の承認済みユーザーと共有できる別のプロジェクトでイメージの作成を自動化し、一元化します。別のプロジェクトでカスタムイメージを作成してキュレートすると、独自の構成で VM の更新、パッチ適用、作成を行うことができます。その後、キュレートされた VM イメージを関連プロジェクトと共有できます。

インスタンスのバックアップにスナップショットを使用する

スナップショットを使用すると、インスタンスのバックアップを作成できます。スナップショットは、予期しないシャットダウンが発生したときに状態の維持や進行状況の保存ができない、柔軟性のないステートフルアプリケーションに特に有効です。スナップショットを頻繁に使用して新しいインスタンスを作成する場合は、そのスナップショットからベースイメージを作成することでバックアッププロセスを最適化できます。

マシンイメージを使用して VM インスタンスの作成を有効にする

スナップショットはマシン内のデータのイメージのみをキャプチャしますが、マシンイメージはデータに加えてマシンの構成と設定をキャプチャします。マシンイメージを使用すると、VM インスタンスを作成するために必要な構成、メタデータ、権限、1 つ以上のディスクのデータをすべて保存できます。

スナップショットからマシンを作成する場合、新しい VM インスタンスでインスタンスを構成する必要がありますが、これには多くの作業が必要です。マシンイメージを使用すると、既知の設定を新しいマシンにコピーするので、オーバーヘッドを削減できます。詳細については、マシンイメージを使用する状況をご覧ください。

容量、予約、分離

このセクションでは、システムをサポートするために容量、予約、分離を管理するためのベストプラクティスについて説明します。

確約利用割引を使用して費用を削減する

確約利用割引を使用することで、常時稼働しているワークロードの運用コスト（OPEX）を低減できます。詳細については、費用最適化のカテゴリをご覧ください。

費用とパフォーマンスをサポートするマシンタイプを選択する

Google Cloud では、費用とパフォーマンスのパラメータに基づいてコンピューティングを選択できるマシンタイプが用意されています。低パフォーマンスのプロダクトを選択してコストを最適化することも、高コストで高パフォーマンスのコンピューティングオプションを使用することもできます。詳細については、費用最適化のカテゴリをご覧ください。

単一テナントノードを使用してコンプライアンスのニーズに対応する

単一テナントノードは、プロジェクトの VM のみをホストする専用の物理的な Compute Engine サーバーです。単一テナントノードは、次のような物理的な分離のコンプライアンス要件を満たすのに役立ちます。

VM を他のプロジェクトの VM から物理的に分離する。
同じホストハードウェア上の VM をグループ化する。
支払い処理のワークロードを分離する。

詳細については、単一テナントノードをご覧ください。

予約を使用してリソースの可用性を確保する

Google Cloud では、ワークロードの予約を定義して、これらのリソースを常に使用できます。予約の作成には追加料金は発生しませんが、予約したリソースを使用しない場合でも、予約されたリソースに対して料金が発生します。詳細については、予約の使用と管理をご覧ください。

VM の移行

このセクションでは、システムをサポートするために VM を移行する際のベストプラクティスについて説明します。

組み込みの移行ツールを評価する

組み込みの移行ツールを使用して、ワークロードを別のクラウドまたはオンプレミスから移行します。詳細については、Google Cloud への移行をご覧ください。Google Cloud には、ワークロードの移行と費用とパフォーマンスの最適化に役立つツールやサービスが用意されています。現在の IT 環境に基づく移行コストを無料で評価するには、Google Cloud 高速評価および移行プログラムをご覧ください。

仮想オペレーティングシステムの OS をカスタマイズする

カスタマイズされたサポート対象のオペレーティングシステムをインポートするには、仮想ディスクのインポートをご覧ください。単一テナントノードでは、コアごとまたはプロセッサごとのライセンスで、ハードウェアに対するお客様所有のライセンスの使用要件を満たすことができます。詳細については、お客様所有のライセンスの使用をご覧ください。

アーキテクチャフレームワークのガイダンスを独自の環境に適用するには、次のことをおすすめします。

Google Cloud Marketplace サービスを確認して、サポートされているベンダーのリストにアプリケーションが含まれているかどうか確認します。Google Cloud は、さまざまなオープンソースシステムとサードパーティソフトウェアの実行をサポートしています。
VM ベースのアプリケーションを GKE で実行しているコンテナ化アプリケーションとして抽出してパッケージ化するには、Migrate to Containers と GKE を検討してください。
Compute Engine を使用して、Google Cloud でアプリケーションを実行します。VM ベースのアプリケーションで以前の依存関係を実行している場合は、ベンダーの要件を満たしているかどうかを確認します。
Google Cloud の内部パススルーネットワークロードバランサを使用して評価し、分離されたアーキテクチャをスケーリングします。詳細については、内部パススルーネットワークロードバランサの概要をご覧ください。
従来のオンプレミスユースケース（HA Proxy の使用など）から移行するオプションを評価します。詳細については、フローティング IP アドレスのベストプラクティスをご覧ください。
VM Manager を使用して、Compute Engine 上で Windows と Linux を実行する大規模な VM フリート用のオペレーティングシステムを管理し、一貫性のある構成ポリシーを適用します。
GKE Autopilot を使用して、Google SRE でクラスタを完全に管理できるようにすることを検討してください。
GKE クラスタ全体のポリシーと構成の管理には、Policy Controller と Config Sync を使用します。
特定のリージョンとゾーンのマシンの可用性とスケーラビリティを確保します。Google Cloud では、コンピューティングニーズに応じたスケーリングが可能です。ただし、特定のリージョンやゾーンで特定のマシンタイプを増やす必要がある場合は、アカウントチームと協力して可用性を確保してください。詳細については、Compute Engine の予約をご覧ください。

次のステップ

次のようなネットワーク設計の原則について学習する。

ワークロード VPC アーキテクチャを設計する。
VPC 間の接続を設計する。

ネットワークインフラストラクチャを設計する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、ネットワーク設計に基づいてシステムをデプロイするためのベストプラクティスを説明します。Virtual Private Cloud（VPC）の選択と実装の方法、ネットワークセキュリティのテストと管理の方法を説明します。

基本原則

ネットワーク設計は、パフォーマンスを最適化し、内部サービスと外部サービスとのアプリケーション通信を保護するうえで役立つことから、システム設計を成功させるために不可欠です。ネットワークサービスを選択する際は、アプリケーションのニーズを評価し、アプリケーション間の通信方法を評価することが重要です。たとえば、一部のコンポーネントではグローバルサービスが必要ですが、他のコンポーネントは特定のリージョンで位置情報を設定しておく必要があります。

Google のプライベートネットワークでは、リージョンのロケーションが 100 を超えるグローバルネットワーク拠点に接続されています。Google Cloud は、ソフトウェア定義ネットワーキングと分散システムテクノロジーにより、世界中でサービスをホストし、配信しています。Google Cloud 内のネットワーキングに関する Google のコア要素は、グローバル VPC です。VPC は、Google のグローバル高速ネットワークを使用して、プライバシーと信頼性をサポートしながら、リージョンをまたいでアプリケーションをリンクします。Google では、ボトルネック帯域幅およびラウンドトリップ伝搬時間（BBR）の輻輳制御インテリジェンスなどのテクノロジーを使用して、高スループットでコンテンツを配信します。

クラウドネットワーキングの設計では、次のステップを行います。

ワークロードの VPC アーキテクチャを設計する。先にどれだけの Google Cloud プロジェクトと VPC ネットワークが必要かを特定する。
VPC 間の接続を追加する。ワークロードを異なる VPC ネットワーク上の他のワークロードと接続する方法を設計する。
ハイブリッドネットワークの接続を設計する。ワークロードの VPC をオンプレミスおよび他のクラウド環境に接続する方法を設計する。

Google Cloud ネットワークを設計するときは、以下を考慮します。

VPC には、Compute Engine、Google Kubernetes Engine（GKE）、サーバーレスコンピューティングソリューション上で構築されたサービスの相互接続を実現するためのクラウド内のプライベートネットワーク環境が用意されています。VPC を使用して、Cloud Storage、BigQuery、Cloud SQL などの Google マネージドサービスにプライベートでアクセスすることもできます。
VPC ネットワーク（その関連ルートやファイアウォールルールを含む）はグローバルリソースです。特定のリージョンやゾーンには関連付けられていません。
サブネットはリージョンリソースです。同じクラウドリージョン内の異なるゾーンにデプロイされた Compute Engine VM インスタンスは、同じサブネットの IP アドレスを使用できます。
インスタンス間のトラフィックは、VPC ファイアウォールルールを使用して制御できます。
ネットワーク管理は、Identity and Access Management（IAM）のロールを使用して保護できます。
ハイブリッド環境の VPC ネットワークは、Cloud VPN または Cloud Interconnect を使用して安全に接続できます。

VPC 仕様の完全なリストについては、仕様をご覧ください。

ワークロードの VPC アーキテクチャ

このセクションでは、システムをサポートするワークロード VPC アーキテクチャを設計する際のベストプラクティスについて説明します。

VPC ネットワーク設計を早期に検討する

Google Cloud での組織の設定を設計する初期段階で VPC ネットワーク設計を行います。組織レベルでの設計の選択内容は、後で簡単には元に戻せません。詳細については、VPC 設計のためのおすすめの方法とリファレンスアーキテクチャと Google Cloud ランディングゾーンのネットワーク設計を決定するをご覧ください。

単一の VPC ネットワークで開始する

要件が共通するリソースが含まれる多くのユースケースでは、単一 VPC ネットワークによって必要な機能が提供されます。単一 VPC ネットワークは、簡単に作成、維持管理、理解できます。詳細については、VPC ネットワークの仕様をご覧ください。

VPC ネットワークトポロジをシンプルに保つ

管理しやすく、信頼性が高く、十分に理解されるアーキテクチャを実現するには、VPC ネットワークトポロジの設計を可能な限り簡素化します。

VPC ネットワークをカスタムモードで使用する

Google Cloud ネットワーキングが既存ネットワーキングシステムとシームレスに統合されるよう、VPC ネットワーク作成時にはカスタムモードを使用することをおすすめします。カスタムモードを使用することで、Google Cloud ネットワーキングを既存の IP アドレス管理スキームに統合し、どのクラウドリージョンを VPC に含めるかを管理できるようになります。詳細については、VPC をご覧ください。

VPC 間の接続

このセクションでは、システムをサポートする VPC 間の接続を設計する際のベストプラクティスについて説明します。

VPC 接続方法を選択する

複数の VPC ネットワークを導入する場合は、これらのネットワークを連結する必要があります。VPC ネットワークは、Google の Andromeda ソフトウェア定義ネットワーク（SDN）内の独立したテナントスペースです。VPC ネットワークは、複数の方法で互いに通信できます。帯域幅、レイテンシ、サービスレベル契約（SLA）の要件に従い、ネットワークをどのように接続するかを選択してください。接続オプションの詳細については、コスト、パフォーマンス、セキュリティのニーズを満たす VPC 接続方式を選択するをご覧ください。

共有 VPC を使用して、複数のワーキンググループを管理する

組織内に複数のチームがある場合、共有 VPC は、単一 VPC ネットワークのシンプルなアーキテクチャを複数の作業グループに拡張するための効果的なツールになります。

わかりやすい命名規則を採用する

直感的にわかりやすく、一貫性のある命名規則を選択してください。これにより、管理者とユーザーが各リソースの目的、各リソースの配置、各リソースが他のリソースとどのように区別されるかを理解しやすくなります。

接続テストを行って、ネットワークセキュリティを検証する

ネットワークセキュリティを確保するため、接続テストを実施することで、2 つのエンドポイント間で遮断したいトラフィックが遮断できているかを検証できます。トラフィックが遮断されているか、なぜ遮断されているかを確認するために、2 つのエンドポイント間での試験を定義し、結果を評価してください。たとえば、トラフィックのブロックをサポートするルールを定義できるようにする VPC 機能をテストできます。詳細については、接続テストの概要をご覧ください。

Private Service Connect を使用して、プライベートエンドポイントを作成する

自社の IP アドレススキームを使用して Google サービスにアクセスするプライベートエンドポイントを作成するには、Private Service Connect を使用します。VPC 内から、VPC に終端されたハイブリッド接続を介してプライベートエンドポイントにアクセスできます。

外部接続の保護と制限を行う

インターネットへのアクセスは、このアクセスを必要とするリソースのみに許可します。限定公開の Google アクセスを使用すると、プライベートの内部 IP アドレスしかないリソースでも多くの Google API やサービスにアクセスできます。

Network Intelligence Center を使用してクラウドネットワークをモニタリングする

Network Intelligence Center では、すべてのリージョンにわたる Google Cloud ネットワークの包括的なビューを利用できます。運用上のリスクやセキュリティリスクを引き起こす可能性があるトラフィックパターンとアクセスパターンを特定するのに役立ちます。

次のステップ

以下を含む、ストレージ管理に関するベストプラクティスについて確認する。

ストレージの種類を選択する。
ストレージアクセスパターンとワークロードタイプを選択する。

ストレージ戦略を選択して実装する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、ストレージに基づいてシステムをデプロイするためのベストプラクティスについて説明します。ストレージ戦略を選択する方法と、ストレージ、アクセスパターン、ワークロードを管理する方法について取り上げます。

データ交換を促進し、データのバックアップと保存を安全に行うには、ワークロード、1 秒あたりの入出力オペレーション（IOPS）、レイテンシ、取得頻度、場所、容量、形式（ブロック、ファイル、オブジェクト）に基づいてストレージプランを選択する必要があります。

Cloud Storage は、次のような信頼性の高い安全なオブジェクトストレージサービスを提供します。

組み込みの冗長性オプションによって機器の故障からデータが保護され、データセンターのメンテナンス中でもデータの可用性を確保。
次のようなデータ転送オプション:
ワークロードをサポートするストレージクラス。
Google が読み取りと書き込みを検証できる、すべての Cloud Storage オペレーションに対して計算されたチェックサム。

Google Cloud では、IOPS はプロビジョニングされた保存容量に応じてスケールします。Persistent Disk などのストレージタイプはゾーンストレージまたはリージョンストレージであるため、手動でのレプリケーションとバックアップが必要になります。反対にオブジェクトストレージは可用性が高く、1 つのリージョンやマルチリージョン全体で、自動でデータを複製します。

ストレージの種類

このセクションでは、システムをサポートするストレージタイプを選択するためのベストプラクティスについて説明します。

高性能ストレージニーズのオプションを評価する

高性能ストレージを必要とするコンピューティングアプリケーション向けの永続ディスクもしくはローカル SSD（ソリッドステートドライブ）を評価します。Cloud Storage は、バージョニング可能なイミュータブルオブジェクトストレージサービスです。Cloud Storage を Cloud CDN とともに使用すると、特に頻繁にアクセスされる静的オブジェクトについてコストを最適化できます。

Filestore は、高性能の共有スペースを必要とするマルチライトアプリケーションをサポートします。Filestore は、ネットワークファイルシステム（NFS）のマウントを介した POSIX のようなファイル操作を必要とするレガシーアプリケーションと最新のアプリケーションもサポートします。

Cloud Storage は、データレイクの作成やアーカイブ要件への対処などのユースケースをサポートします。特に保持ポリシーを構成する際は、アクセスコストと検索コストによる Cloud Storage クラスの選択に基づいてトレードオフを決定します。詳細については、クラウドワークロードに最適なストレージ戦略の設計をご覧ください。

どのストレージオプションでも、デフォルトでは保存時と転送時に Google が管理する鍵を使用してデータが暗号化されます。Persistent Disk や Cloud Storage などのストレージタイプの場合、独自の鍵を指定することも、Cloud Key Management Service（Cloud KMS）を使用して鍵を管理することもできます。このような鍵を本番環境データで使用する前に、鍵の処理方法を確立してください。

Google Cloud サービスでストレージデザインをサポートする

ストレージ設計をサポートする Google Cloud サービスについては、次の表をご覧ください。

Google Cloud サービス	Description
Cloud Storage	世界中のどこからでも、いつでもデータを保存、取得でき、データの量に制限はありません。Cloud Storage は、ウェブサイトコンテンツの配信や、アーカイブおよび障害復旧を目的としたデータの保存、直接ダウンロードによるユーザーへの大規模なデータオブジェクトの配布など、複数のシナリオで利用できます。詳しくは以下をご覧ください。 Cloud Storage のベストプラクティスバケットのロケーションストレージクラス Cloud Storage FUSE
Persistent Disk	Google Cloud 向けの高性能なブロックストレージPersistent Disk は、Compute Engine または Google Kubernetes Engine で実行されているインスタンスに接続可能な SSD ストレージとハードディスクドライブ（HDD）ストレージを提供します。リージョンディスクを使用すると、同じリージョン内の 2 つのゾーン間で耐久性の高いデータストレージとデータレプリケーションを実現できます。より高い IOPS と低レイテンシが必要なケースに対しては、Google Cloud は Cloud Filestore を提供します。ローカル SSD は、仮想マシンのインスタンスをホストするサーバーに物理的に接続されます。一時的なディスク容量としてローカル SSD を使用できます。
Filestore	データ用のファイルシステムインターフェースと共有ファイルシステムを必要とするアプリケーション向けのマネージドファイルストレージサービスです。Filestore を使用することにより、Compute Engine や GKE のインスタンスでマネージドネットワーク接続ストレージ（NAS）をシームレスに活用できるようになります。
Cloud Storage for Firebase	写真や動画のようなユーザー作成コンテンツを保存し配信する必要のあるアプリデベロッパー向けに構築されています。すべてのファイルは Cloud Storage バケットに保存されているので、Firebase と Google Cloud の両方からアクセスが可能です。

ストレージ戦略を選択する

アプリケーションの要件に合ったストレージ戦略を選択するには、次の表をご覧ください。

ユースケース	推奨事項
最小限のコストで大規模にデータを格納する必要があり、アクセスパフォーマンスが問題にならない。	Cloud Storage
即時ストレージを必要とするコンピューティングアプリケーションを実行している。詳細については、Persistent Disk とローカル SSD のパフォーマンスの最適化をご覧ください。	Persistent Disk またはローカル SSD
共有スペースに対する読み取りと書き込みのアクセス権が必要な高パフォーマンスワークロードを実行している。	Filestore
ハイパフォーマンスコンピューティング（HPC）またはハイスループットコンピューティング（HTC）のユースケース。	クラウド上でのクラスタを利用した大規模なテクニカルコンピューティング実行

ストレージアクセスのニーズに基づいてアクティブストレージまたはアーカイブストレージを選択する

ストレージクラスは、すべてのオブジェクトで使用されるメタデータです。可用性が高く、高頻度で提供されるデータの場合は、Standard Storage クラスを使用します。アクセス頻度が低く、やや可用性が低くてもよいデータには、Nearline Storage クラス、Coldline Storage クラス、Archive Storage クラスを使用します。ストレージクラスを選択する際の費用に関する考慮事項については、Cloud Storage の料金をご覧ください。

Cloud Storage についてストレージの場所とデータ保護に関するニーズを評価する

リージョンに配置された Cloud Storage バケットの場合、バケット内に含まれるデータはリージョン内のゾーン間で自動的に複製されます。ゾーン間でのデータレプリケーションは、リージョン内でゾーン障害が発生した場合にデータを保護します。

Cloud Storage にはリージョン間で冗長なロケーションも用意されています。つまり、データは地理的に離れた複数のデータセンターに複製されます。詳細については、バケットのロケーションをご覧ください。

Cloud CDN を使用して静的オブジェクトの配信を向上させる

オブジェクトの取得コストを最適化し、アクセスレイテンシを最小にするには、Cloud CDN を使用します。Cloud CDN は、Cloud Load Balancing の外部アプリケーションロードバランサを使用して、ルーティングとヘルスチェックを行い、エニーキャスト IP アドレスをサポートします。詳細については、クラウドバケットを使用して Cloud CDN を設定するをご覧ください。

ストレージアクセスパターンとワークロードタイプ

このセクションでは、システムをサポートするストレージアクセスパターンとワークロードタイプを選択する際のベストプラクティスについて説明します。

Persistent Disk を使用して高性能ストレージへのアクセスをサポートする

データアクセスパターンは、システムパフォーマンスをどのようにデザインするかによって変わります。Cloud Storage はスケーラブルなストレージを提供しますが、大量のデータに高いスループットでアクセスする必要のある重い計算ワークロードを実行する場合は、理想的な選択ではありません。高性能ストレージアクセスには、Persistent Disk を使用します。

リトライロジックの実装時に指数バックオフを使用する

5XX、408、429 エラーを処理するために、リトライロジックの実装時に指数バックオフを使用します。各 Cloud Storage バケットには、初期 I/O キャパシティが設定されています。詳細については、リクエストレートとアクセス配信のガイドラインをご覧ください。リトライ要求の段階的な立ち上げを計画する。

ストレージ管理

このセクションでは、システムをサポートするためのストレージ管理のベストプラクティスについて説明します。

すべてのバケットに固有の名前を設定する

すべてのバケット名を Cloud Storage 名前空間内で一意にします。バケット名には機密情報を含めないでください。推測しにくいバケット名とオブジェクト名を選択してください。詳細については、バケットの命名ガイドラインとオブジェクトの命名ガイドラインをご覧ください。

Cloud Storage バケットを非公開の状態に保持する

ビジネス上の理由がない限り、Cloud Storage バケットに匿名アクセスまたは一般アクセスができないようにしてください。詳細については、アクセス制御の概要をご覧ください。

ランダムなオブジェクト名を割り当てて、負荷を均等に分散する

ランダムなオブジェクト名を割り当てて、パフォーマンスを改善し、ホットスポットを回避します。可能であれば、オブジェクトの接頭辞をランダムにします。詳細については、命名規則を使って負荷をキーの範囲に均等に分散するをご覧ください。

公開アクセス防止を使用する

組織、フォルダ、プロジェクト、バケットレベルのアクセスを防止するには、公開アクセスの防止を使用します。詳しくは、公開アクセスの防止の使用をご覧ください。

次のステップ

Google Cloud データベースサービスと、次のようなベストプラクティスについて確認します。

データベースを選択して移行する。
データベースの暗号化を管理する。
データベースのネットワークとアクセスを管理する。

データベースを最適化する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、データベース設計に基づいてシステムをデプロイするためのベストプラクティスを説明します。データベースの設計、移行、スケーリング、データベース情報の暗号化、ライセンスの管理、データベースのイベントのモニタリングを行う方法が学べます。

主なサービス

このアーキテクチャフレームワークのシステム設計カテゴリのドキュメントでは、さまざまな Google Cloud データベースサービスを含むベストプラクティスについて説明します。次の表に、これらのサービスの概要を示します。

Google Cloud サービス	説明
Cloud SQL	フルマネージドデータベースサービス。Cloud SQL for PostgreSQL、Cloud SQL for MySQL、Cloud SQL for SQL Server を使用するリレーショナルデータベースを設定、維持、管理できます。Cloud SQL は高いパフォーマンスとスケーラビリティを実現します。Google Cloud 上でホストされる Cloud SQL では、どこでもアプリケーションを実行できるデータベースインフラストラクチャを利用できます。
Bigtable	数十億行、数千列の規模にスケーリングできるテーブル。最大でペタバイト規模のデータを保存できます。各行の単一の値がインデックスに登録され、この値が行キーとなります。Bigtable を使用すると、非常に低いレイテンシで大量の単一キーデータを保存できます。低レイテンシで高い読み取り / 書き込みスループットを実現できます。また、MapReduce オペレーションのデータソースです。
Spanner	リレーショナルデータベース構造と非リレーショナルデータベースの水平スケーラビリティを含む、クラウド用に構築されたスケーラブルでグローバルに分散されたエンタープライズデータベースサービス。この組み合わせにより高パフォーマンスのトランザクションと、行、リージョン、大陸をまたぐ整合性が実現します。Spanner により 99.999% の可用性 SLA、計画的ダウンタイムの排除、エンタープライズクラスのセキュリティが実現します。
Memorystore	Google Cloud 向けのフルマネージド Redis サービス。Google Cloud で実行されるアプリケーションでは、複雑な Redis デプロイを管理することなく、可用性が高くスケーラブルで安全な Redis サービスを使用して、パフォーマンスを向上できます。
Firestore	自動スケーリングと高性能を実現し、アプリケーション開発のために構築された NoSQL ドキュメントデータベース。Firestore のインターフェースは従来のデータベースと同じ機能を多数備えていますが、NoSQL データベースであり、データオブジェクト間の関係を表現する方法が異なります。
Firebase Realtime Database	クラウドでホストされるデータベース。Firebase ではデータを JSON として保存し、接続されたすべてのクライアントとリアルタイムで同期します。Google、iOS、Android、JavaScript SDK を使用してクロスプラットフォームアプリを構築した場合、すべてのクライアントが、1 つのリアルタイムデータベースインスタンスを共有して、最新のデータによる更新を自動的に受信します。
オープンソースデータベース	Google パートナーは、MongoDB、MariaDB、Redis など、さまざまなオープンソースデータベースを提供しています。
AlloyDB for PostgreSQL	要求の厳しいエンタープライズワークロード向けの PostgreSQL 対応のフルマネージドデータベースサービス。標準の PostgreSQL と比べて、トランザクションワークロードのパフォーマンスが最大で 4 倍、分析クエリの処理速度が最大で 100 倍になります。AlloyDB for PostgreSQL は、ML 対応の自動パイロットシステムによって管理を簡素化します。

データベースの選定

このセクションでは、システムをサポートするデータベースを選択するためのベストプラクティスについて説明します。

マネージドデータベースサービスの使用を検討する

独自のデータベースやデータベースクラスタをインストールする前に Google Cloud のマネージドデータベースサービスについて検討してください。独自のデータベースをインストールすると、パッチやアップデートのインストール、モニタリングやバックアップなど日々の運用を管理するメンテナンス費用が発生します。

データベースの選択には、機能的および非機能的なアプリケーション要件を使用します。低レイテンシアクセス、時系列データ処理、障害復旧、モバイルクライアントの同期を検討してください。

データベースを移行するには、次の表に示すプロダクトのいずれかを使用します。

Database 移行プロダクト	説明
Cloud SQL	リモートリージョンのリードレプリカ、低レイテンシの読み取り、障害復旧をサポートするリージョンサービス。
Spanner	外部整合性、グローバルレプリケーション、99.999% のサービスレベル契約（SLA）を提供するマルチリージョンサービス。
Bigtable	最大 99.999% の可用性で大規模な分析ワークロードにも運用ワークロードにも対応できる、フルマネージドでスケーラブルな NoSQL データベースサービス。
Memorystore	2 つの一般的なオープンソースキャッシュソリューションである Redis と Memcached のマネージドバージョンを提供するフルマネージドデータベースサービス。
Firebase Realtime Database	Firebase Realtime Database は、リアルタイムでデータを保存してユーザー間で同期できる、クラウドホスト型 NoSQL データベースです。
Firestore	自動スケーリングと高性能を実現し、アプリケーション開発を簡素化するように構築された NoSQL ドキュメントデータベース。
オープンソース	MongoDB や MariaDB などの代替データベースオプション。

データベースの移行

既存のワークロードを Google Cloud に移行する際にユーザーがアプリケーションのダウンタイムをゼロにするには、要件をサポートするデータベース技術を選択することが重要です。データベース移行オプションとベストプラクティスについては、データベース移行ソリューションと同種データベースの移行のためのベストプラクティスをご覧ください。

データベース移行の計画には、次の作業が含まれます。

現在のデータベースの評価と調査。
移行の成功基準の定義。
移行とターゲットデータベースの環境設定。
ターゲットデータベースでのスキーマの作成。
ターゲットデータベースへのデータの移行。
すべてのデータが正しく移行され、データベースに存在することを確認する移行の検証。
ロールバック戦略の作成。

移行戦略を選択する

適切なターゲットデータベースを選択することは、移行成功の重要な鍵となります。以下の表は、いくつかの使用例での移行戦略のオプションを示します。

ユースケース	推奨事項
Google Cloud における新しいデプロイ	Cloud SQL、Spanner、Bigtable、Firestore のようなクラウド向けのマネージドデータベースから、ユースケースの要件を満たすものを選んでください。
リフト＆シフト移行	Cloud SQL、MYSQL、PostgreSQL、SQLServer のような互換性のあるマネージドデータベースサービスを選んでください。
アプリケーションで、Cloud SQL でサポートされていないデータベースに対するきめ細かいアクセスを必要とする	Compute Engine の VM でデータベースを実行します。

Memorystore を使用してキャッシュ保存データベースレイヤをサポートする

Memorystore は、数ミリ秒を下回るレイテンシをサポートするフルマネージドの Redis および Memcached データベースです。Memorystore は、オープンソースの Redis および Memcached と完全互換性があります。アプリケーションでこれらのキャッシュ保存データベースを使用する場合、コード内のアプリケーションレベルの変更をせずに Memorystore を使用できます。

ベアメタルサーバーを使用して Oracle データベースを運用する

ワークロードが Oracle データベースを必要とする場合、Google Cloud 提供のベアメタルサーバーを使用します。このアプローチはリフト＆シフト移行戦略に該当します。

ワークロードを Google Cloud に移行して、ベースラインワークロードが稼働した後にモダナイズする場合は、Spanner、Bigtable、Firestore などのマネージドデータベースオプションの使用を検討してください。

クラウド用に構築されたデータベースは、クラウドインフラストラクチャ上にボトムアップして構築された、最新のマネージドデータベースです。これらのデータベースではスケーラビリティや高可用性など、独自のデフォルト機能を使用できますが、独自のデータベースを運用する場合、その実現は困難です。

データベースをモダナイズする

クラウドで新しいアプリケーションを設計する場合、または既存のデータベースをクラウドに移行する場合でも、システム設計の早い段階でデータベース戦略をご検討ください。Google Cloud は、Cloud SQL for MySQL や Cloud SQL for PostgreSQL のようなオープンソースデータベース向けのマネージドデータベースオプションを提供します。この移行を、データベースをモダナイズし、将来のビジネスニーズに備える機会だと捉えましょう。

既製のアプリケーションで固定データベースを使用する

商用オフザシェルフ（COTS）アプリケーションは、固定型データベースと固定の構成を必要とします。リフト＆シフトは、COTS アプリケーションに対して最適の移行アプローチです。

チームのデータベース移行スキルセットを確認する

チームのデータベース移行能力とスキルセットに基づいて、クラウドデータベースを移行する方法を選択してください。Google Cloud Partner Advantage で移行全体をサポートするパートナーを探します。

HA と DR の要件を満たすデータベース設計

高可用性（HA）と障害復旧（DR）の要件を満たすようにデータベースを設計する場合、信頼性とコスト間のトレードオフを検討します。クラウド向けに構築されたデータベースサービスは、データベースと構成に応じて、リージョン内もしくはマルチリージョンにデータのコピーを複数作成します。

BigQuery や Spanner など、一部の Google Cloud サービスにはマルチリージョンのバリアントがあります。リージョンの障害に対する復元力を確保するため、可能であれば、マルチリージョンサービスを設計してください。

Google Cloud のマネージドデータベースを使用せずに Compute Engine VM でデータベースを設計する場合は、データベースの複数のコピーを実行するようにしてください。詳細については、信頼性カテゴリのスケーラビリティと高可用性を実現する設計をご覧ください。

データ所在地をサポートする特定のクラウドリージョン

データ所在地とは、データが物理的に存在している場所のことです。データ所在地要件に基づいたデータベースをデプロイする特定のクラウドリージョンを選択することを検討してください。

マルチリージョンでデータベースをデプロイする場合、構成によってはリージョン間でデータレプリケーションが行われる場合があります。保管時に希望のリージョン内にデータを保持する構成を選択してください。Spanner などの一部のデータベースでは、デフォルトでマルチリージョンレプリケーションを使用できます。リソースロケーションの制約を含む組織のポリシーを設定して、データ所在地を適用することもできます。詳細については、リソースロケーションの制限をご覧ください。

障害復旧を含むデータ所在地設計

データ所在地設計に目標復旧時間（RTO）と目標復旧時点（RPO）を含み、RTO / RPO と障害復旧ソリューションコスト間のトレードオフを検討します。RTO / RPO の数値が小さいほどコストは高くなります。中断から早く回復させたい場合、システム運用コストは高くなります。また、障害復旧アプローチと顧客の満足度を突き合わせ、信頼性への投資が適切かどうかを確認します。詳しくは、100% の信頼性を目指す必要はないと障害復旧プランニングガイドをご覧ください。

データベースを Google Cloud 対応にする

ワークロードに合わせてデータベースを選択する場合、選択したサービスが運用されているリージョンやデータが物理的に保存されている場所のコンプライアンスを遵守していることを確認してください。Google の認証とコンプライアンス基準については、コンプライアンス状況をご覧ください。

暗号化

このセクションでは、暗号化の要件を特定し、システムをサポートする暗号鍵戦略を選択するためのベストプラクティスについて説明します。

暗号化要件を決定する

暗号化要件は、企業のセキュリティポリシーやコンプライアンス要件などのさまざまな要因によって決定されます。Google Cloud に保存されているデータはすべて、静止時にデフォルトで AES256 を使用して暗号化されており、ユーザーの対応は不要です。詳細については、Google Cloud での保存時の暗号化をご覧ください。

暗号鍵に関する戦略を選択する

暗号鍵を自分で管理するかマネージドサービスを利用するか決めることができます。Google Cloud は両方のシナリオをサポートします。Google Cloud で暗号鍵を管理するためにフルマネージドサービスが必要な場合は、Cloud Key Management Service（Cloud KMS）を選択してください。ご自身で暗号鍵のライフサイクルをより詳細に管理したい場合は、顧客管理の暗号鍵（CMEK）を使用できます。

Google Cloud 外部で暗号鍵を作成し管理するには、次のオプションからひとつ選んでください。

パートナーソリューションを使用して鍵を管理する場合は、Cloud External Key Manager を使用します。
オンプレミスで暗号鍵を管理し、その鍵を使用して Google Cloud 上のデータを暗号化したい場合は、暗号鍵を KMS 鍵もしくはハードウェアセキュリティモジュール（HSM）鍵として Cloud KMS にインポートします。鍵を使用して Google Cloud 上のデータを暗号化します。

データベースの設計とスケーリング

このセクションでは、システムをサポートするデータベースを設計し、スケーリングするためのベストプラクティスについて説明します。

モニタリング指標を使用してスケーリングニーズを評価する

既存のモニタリングツールや環境からの指標を使用して、データベースのサイズとスケーリングの要件（データベースインスタンスの適切なサイズ設定とスケーリング戦略の設計など）の基礎事項を理解します。

新しいデータベース設計では、提供されるアプリケーションから予測される負荷とトラフィックパターンに基づいてスケーリング数を決定します。詳細については、Cloud SQL インスタンスのモニタリング、Cloud Monitoring によるモニタリング、インスタンスのモニタリングをご覧ください。

ネットワーキングとアクセス

このセクションでは、システムをサポートするためのネットワークとアクセスを管理するためのベストプラクティスについて説明します。

プライベートネットワークでデータベースを運用する

プライベートネットワークでデータベースを運用し、データベースにアクセスする必要のあるクライアントにのみ、制限されたアクセスを許可します。VPC 内に Cloud SQL インスタンスを作成できます。Google Cloud は、Spanner、Bigtable のデータベースに VPC Service Controls for Cloud SQL を提供し、これらのリソースへのアクセスが、承認された VPC ネットワークのクライアントだけに制限されるようにします。

ユーザーに最小限の権限を付与する

Identity and Access Management（IAM）はデータベースサービスを含む Google Cloud サービスへのアクセスをコントロールします。未承認のアクセスによるリスクを最小限に抑えるために、ユーザーに最小限の権限を付与します。データベースへのアプリケーションレベルのアクセスには、最小限の権限があるサービスアカウントを使用します。

自動化と適正サイズ設計

このセクションでは、自動化を定義し、システムをサポートするための適切なサイズを設定するためのベストプラクティスについて説明します。

データベースインスタンスをコードとして定義する

Google Cloud に移行する利点の一つは、インフラストラクチャと、コンピューティングやデータベースレイヤなどのワークロードの他の側面における自動化の実現です。Google Deployment Manager や Terraform Cloud などのサードパーティ製ツールによって、データベースインスタンスをコードとして定義できます。これにより、データベースの作成と構成に対し、一貫した繰り返し可能なアプローチを適用できます。

Liquibase を使用してデータベースをバージョン管理する

Cloud SQL や Spanner のような Google データベースサービスは、データベースのためのオープンソースバージョン管理ツールである Liquibase をサポートしています。Liquibase は、データベーススキーマの変更を追跡、ロールバックし、反復可能な移行を実行します。

スケーリングをサポートするデータベースのテストと調整

データベースインスタンスで負荷テストを実行し、テスト結果に基づいてアプリケーションの要件を満たすように調整します。データベースの初期スケールは、重要業績評価指標（KPI）の負荷テストのに基づいて判断するか、現在のデータベースから取得したモニタリング KPI を使用して決定します。

データベースインスタンスを作成するときは、テスト結果または過去のモニタリング指標に基づくサイズから始めます。クラウドで予想される負荷でデータベースインスタンスをテストします。次に、データベースインスタンスの予想される負荷に対して必要な結果が得られるまでインスタンスを微調整します。

スケーリング要件に適したデータベースを選択する

データベースのスケーリングは、コンピューティングレイヤコンポーネントのスケーリングとは異なります。データベースには状態があります。データベースの 1 つのインスタンスで負荷を処理できない場合は、データベースインスタンスをスケーリングするための適切な戦略を検討してください。スケーリング戦略はデータベースの種類によって異なります。

次の表に、スケーリングのユースケースに対応する Google プロダクトを示します。

ユースケース	推奨プロダクト	説明
処理能力とストレージをスケールアップする必要がある場合は、データベースにノードを追加して、データベースインスタンスを水平方向にスケーリングします。	Spanner	クラウド用に構築されたリレーショナルデータベース。
ノードを追加してデータベースをスケールします。	Bigtable	フルマネージドの NoSQL ビッグデータデータベースサービス。
データベーススケーリングを自動的に処理します。	Firestore	モバイル、ウェブ、サーバー開発向けの柔軟でスケーラブルなデータベース。
より多くのクエリを処理するには、Cloud SQL データベースインスタンスを垂直方向にスケールアップしてコンピューティング容量とメモリ容量を増やします。Cloud SQL ではストレージレイヤはデータベースインスタンスから分離されています。ストレージ容量が容量に近づくたびに、ストレージレイヤを自動的にスケーリングできます。	Cloud SQL	リレーショナルデータベースの設定、維持、管理、運営をサポートする Google Cloud 上のフルマネージドデータベースサービス。

運用

このセクションでは、システムをサポートするための運用のベストプラクティスについて説明します。

Cloud Monitoring を使用してデータベースをモニタリングし、アラートを設定する

Cloud Monitoring を使用してデータベースインスタンスのモニタリングとイベントの適切なチームを知らせるアラートの設定を行う。効果的なアラートのベストプラクティスについては、効率的なアラートを作成するをご覧ください。

クラウド用に構築されたすべてのデータベースは、ロギングとモニタリングの指標を提供します。各サービスは、ロギングとモニタリングの指標を可視化するためのダッシュボードを提出します。すべてのサービスのモニタリング指標は、Google Cloud のオペレーションスイートと統合されています。Spanner は、デバッグと根本原因の分析のために Key Visualizer のようなクエリイントロスペクションツールを提供します。Key Visualizer の機能は次のとおりです。

データベース用のビジュアルレポートを生成することで、Spanner 使用パターンの分析をサポートします。レポートは使用パターンを時系列で行の範囲別に表示します。
使用パターンの大規模な分析情報を提供します。

Bigtable には、Bigtable インスタンスの使用パターンの分析に役立つ Key Visualizer 診断ツールも用意されています。

ライセンス

このセクションでは、システムをサポートするライセンスのベストプラクティスについて説明します。

オンデマンドライセンスか既存のライセンスかを選択する

Cloud SQL for SQL Server を使用したい場合、お客様所有ライセンスの使用はサポートされていません。ライセンス費用はコアタイムごとの使用量に基づいています。

既存の Cloud SQL for SQL Server ライセンスを使用したい場合は、Compute VM で Cloud SQL for SQL Server を実行することを検討してください。詳細については、Microsoft ライセンスとオンデマンドライセンスか既存ライセンスの使用かを選択するをご覧ください。

Oracle を使用していて、Oracle 向け Bare Metal Solution に移行する場合は、お客様所有ライセンスを使用できます。詳細については、Bare Metal Solution を計画するをご覧ください。

移行のタイムライン、方法、ツールセット

このセクションでは、システムをサポートするデータベースの移行を計画およびサポートするためのベストプラクティスについて説明します。

データベースのモダナイゼーションの準備状況を判断する

組織がデータベースをモダナイズし、クラウド用に構築されたデータベースを使用する準備ができているかどうかを評価します。

モダナイゼーションはアプリケーション側に影響する可能性があるため、ワークロードの移行タイムラインを計画する場合は、データベースのモダナイゼーションを検討してください。

ステークホルダーを移行計画に関与させる

データベースの移行では、次のことを行います。

ターゲットデータベースを設定する。
スキーマを変換する。
ソースデータベースとターゲットデータベースの間のデータレプリケーションを設定する。
移行中に発生した問題をデバッグする。
アプリケーションレイヤとデータベースの間のネットワーク接続を確立する。
ターゲットデータベースセキュリティを実装する。
アプリケーションがターゲットデータベースに接続していることを確認する。

多くの場合、これらのタスクではさまざまなスキルセットが必要であり、組織内の複数のチームが協力して移行を完了します。移行を計画するときに、アプリデベロッパー、データベース管理者、インフラストラクチャチームやセキュリティチームなど、すべてのチームの関係者を含めます。

チームにこのタイプの移行をサポートするスキルがない場合は、Google のパートナーが移行を支援します。詳細については、Google Cloud Partner Advantage をご覧ください。

同種移行と異種移行のためのツールセットを特定する

同機種の移行とは、同じデータベーステクノロジーを使用するソースデータベースとターゲットデータベースの間のデータベースの移行です。異機種の移行とは、ターゲットデータベースがソースデータベースと異なる場合の移行です。

異機種の移行では、通常、ソースデータベースからターゲットデータベースのエンジンタイプへのスキーマ変換が必要になります。スキーマ変換はソースデータベーススキーマの複雑さに依存するため、データベースチームは関連する課題を評価する必要があります。

データ移行の各ステップのテストと検証

データの移行には複数の手順が必要です。移行エラーを最小限に抑えるには、次のステップに進む前に移行の各ステップをテストして検証します。移行プロセスを促進する要因は次のとおりです。

移行が同種か異種か。
移行の実行に必要なツールやスキルセットのタイプ。
異機種移行の場合、ターゲットデータベースエンジンの経験。

継続的なデータレプリケーションの要件を決定する

最初にデータを移行し、その後、ソースからターゲットデータベースにデータを継続的にレプリケートする計画を作成します。ターゲットが安定し、アプリケーションが新しいデータベースに完全に移行されるまでレプリケーションを続行します。この計画は、データベースの切り替え中に発生する可能性のあるダウンタイムを特定し、それに応じて計画を立てるのに役立ちます。

データベースエンジンを Cloud SQL、Cloud SQL for MySQL、または Cloud SQL for PostgreSQL から移行する場合、Database Migration Service を使用して、フルマネージドの方法でこのプロセスを自動化します。他の種類の移行をサポートするサードパーティツールについては、Cloud Marketplace をご覧ください。

推奨事項

アーキテクチャフレームワークのガイダンスを独自の環境に適用するには、次のことをおすすめします。

データベースのマルチテナンシーでは、複数のお客様のデータを共有インフラストラクチャ（この場合はデータベース）に保存します。SaaS（Software as a Service）ベースのサービスをお客様に提供する場合は、さまざまな顧客に属するデータセットを論理的に分離し、そのアクセスをサポートする方法を理解する必要があります。また、分離レベルに基づいて要件を評価します。

Spanner や Cloud SQL などのリレーショナルデータベースには、データベースインスタンスレベル、データベースレベル、スキーマレベル、またはデータベーステーブルレベルなど、複数のアプローチがあります。他の設計上の決定と同様に、隔離度と費用やパフォーマンスなどの他の要因との間にはトレードオフがあります。IAM ポリシーではデータベースインスタンスへのアクセスを制御します。
データモデルの要件に適したデータベースを選択します。
適切なキー値を選択してキーのホットスポット化を回避します。ホットスポットは、テーブル内で他のロケーションよりも多くのアクセスがあるロケーションのことです。ホットスポットについては、スキーマ設計ベストプラクティスをご覧ください。
可能な限りデータベースインスタンスをシャーディングします。
接続プーリングや指数バックオフなどの接続管理ベストプラクティスを使用します。
あまりにも大規模なトランザクションは避けてください。
データベースのメンテナンス更新に対するアプリケーションのレスポンスを設計し、テストします。
データベースへの接続を保護し、分離します。
データベースのサイズ指定と成長の期待値によって、データベースが要件をサポートするようにします。
HA と DR のフェイルオーバー戦略をテストします。
処理に慣れるために、バックアップと復元、エクスポートとインポートを実行します。

Cloud SQL の推奨事項

プライベート IP アドレスネットワーキング（VPC）を使用します。セキュリティを強化するため、次の点を考慮してください。
- Cloud SQL Auth Proxy を使用してプライベートネットワーキングをサポートします。
- パブリック IP アドレスのアクセス constraints/sql.restrictPublicIp を制限します。
パブリック IP アドレスネットワーキングが必要な場合は、次の点を考慮してください。
- 組み込みファイアウォールで制限付きの IP アドレスリストを使用し、Cloud SQL インスタンスの受信接続で SSL の使用を必須にします。詳しくは、SSL / TLS 証明書の構成をご覧ください。
セキュリティを強化するため、次の点を考慮してください。
- 汎用アクセス権を付与するのではなく、Cloud SQL Auth プロキシを使用してください。
- 承認済みネットワークを制限します（constraints/sql.restrictAuthorizedNetworks）。
データベースユーザーの権限を制限します。

次のステップ

以下をはじめとするデータ分析のベストプラクティスについて学びます。

データ分析の基本原則と Google Cloud 主要サービスについて学習する。
データライフサイクルについて学習する。
データの取り込み方法を学習する。
データストレージを選択して管理する。
データを処理して変換する。

データを分析する

Google Cloud Architecture Framework のこのドキュメントでは、Google Cloud におけるデータ分析の基本原則とベストプラクティスについて説明します。さらに、主要なデータ分析サービスの詳細と、これらのサービスがデータライフサイクルのさまざまな段階でどのように役立つかについて説明します。これらのベストプラクティスは、データ分析のニーズを満たし、システム設計を作成する際に役立ちます。

基本原則

どの企業も、データを分析して、その結果から行動につながるインサイトを得たいと考えています。Google Cloud では、データの取り込みからレポートや可視化まで、データのライフサイクル全体をサポートするさまざまなサービスを提供しています。これらのサービスのほとんどはフルマネージドサービスであり、一部はサーバーレスです。Apache Hadoop または Beam をセルフホストするなど、Compute Engine VM 上にデータ分析環境を構築し、管理することもできます。

特定の重点分野、チームの専門知識、戦略的視点があれば、データ分析のニーズに対応するためにどの Google Cloud サービスを採用するかを判断するのに役立ちます。たとえば、Dataflow ではサーバーレスアプローチで複雑な変換を記述できますが、コンピューティングと処理のニーズに対応する独自のバージョンの構成を使用する必要があります。または、Dataproc を使用しても同じ変換を実行できますが、クラスタの管理やジョブの微調整は自分自身で行います。

システム設計では、抽出 / 加工 / 読み込み（ETL）や抽出 / 読み込み / 変換（ELT）など、自社のチームで採用する処理戦略を検討します。また、バッチ分析またはストリーミング分析のどちらが必要かも考慮する必要があります。Google Cloud では、統合されたデータプラットフォームを提供しているため、これにより、ビジネスの要件に合わせてデータレイクやデータウェアハウスを構築できます。

主なサービス

次の表に、Google Cloud の分析サービスの概要を示します。

Google Cloud サービス	説明
Pub/Sub	ストリーム分析とイベントドリブンコンピューティングシステム向けの、シンプルで信頼性の高いスケーラブルな基盤。
Dataflow	ストリーム（リアルタイム）モードとバッチ（履歴）モードでデータを変換、拡張するフルマネージドサービス。
Dataprep by Trifacta	分析用の構造化データと非構造化データを視覚的に探索、クリーニング、準備できるインテリジェントデータサービス。
Dataproc	高速で使いやすいフルマネージドクラウドサービスであり、Apache Spark クラスタと Apache Hadoop クラスタを実行します。
Cloud Data Fusion	クラウド向けに構築されたフルマネージドのデータ統合サービス。ETL/ELT データパイプラインを構築し、管理できます。Cloud DataFusion は、グラフィカルなインターフェースや、事前構成されたコネクタと変換を含む幅広いオープンソースライブラリを提供します。
BigQuery	ストレージと処理能力のニーズに合わせてスケールする、Google のフルマネージドで低コストのサーバーレスデータウェアハウスです。BigQuery では、テラバイト規模からペタバイト規模のデータを分析できるカラム型の ANSI SQL データベースを利用できます。
Cloud Composer	フルマネージドなワークフローオーケストレーションサービス。クラウドとオンプレミスデータセンターにまたがるパイプラインの作成、スケジューリング、モニタリングを実現します。
Data Catalog	フルマネージドでスケーラブルなメタデータ管理サービス。すべてのデータをすばやく検出、管理、把握できます。
Looker Studio	インタラクティブなダッシュボードを通じてデータから分析情報を引き出すために役立つ、フルマネージドビジュアル分析サービス。
Looker	マルチクラウド環境でデータを接続、分析、可視化するエンタープライズプラットフォーム。
Dataform	データパイプラインのコラボレーション、作成、デプロイを行い、データ品質の確保に役立つフルマネージドプロダクト。
Dataplex	一貫性のあるコントロールを使用して、データレイク、データウェアハウス、データマートのデータを横断的に管理、モニタリング、運営するマネージドデータレイクサービス。
AnalyticsHub	組織全体でデータ分析アセットを効率的かつ安全に交換し、データの信頼性とコストの課題を解決できるプラットフォーム。

データライフサイクル

システム設計の段階で、任意のシステムまたはデータライフサイクルでの一般的なデータ移動を中心に、Google Cloud データ分析サービスをグループ化できます。

データライフサイクルには、次のステージとサンプルサービスが含まれます。

取り込みには、Pub/Sub、Storage Transfer Service、Transfer Appliance、BigQuery などのサービスが含まれます。
ストレージには、Cloud Storage、Bigtable、Memorystore、BigQuery などのサービスが含まれます。
処理と変換には、Dataflow、Dataproc、Dataprep、センシティブデータの保護、BigQuery などのサービスが含まれます。
分析とウェアハウジングには、BigQuery などのサービスが含まれます。
レポートと可視化には、Looker Studio や Looker などのサービスが含まれます。

次のステージとサービスが、データライフサイクル全体を通して実行されます。

データ統合には、Data Fusion などのサービスが含まれます。
メタデータの管理とガバナンスには、Data Catalog などのサービスが含まれます。
ワークフロー管理には、Cloud Composer などのサービスが含まれます。

データの取り込み

以下に挙げるデータの取り込みのベストプラクティスを、実際の環境に適用します。

取り込むデータソースを特定する

通常、データは別のクラウドプロバイダまたはサービスから、またはオンプレミスのロケーションから提供されます。

他のクラウドプロバイダからデータを取り込むには、通常、Cloud Data Fusion、Storage Transfer Service、または BigQuery 転送サービスを使用します。
オンプレミスのデータの取り込みでは、取り込むデータの量とチームのスキルセットを考慮してください。チームでローコードのグラフィカルユーザーインターフェース（GUI）を使用したい場合は、Cloud Data Fusion と Java Database Connectivity（JDBC）などの適切なコネクタを使用します。大量のデータを処理する場合は、Transfer Appliance や Storage Transfer Service を使用できます。

取り込み後にデータをどのように処理するかを検討してください。たとえば、Storage Transfer Service は Cloud Storage バケットにのみデータを書き込みますが、BigQuery Data Transfer Service は BigQuery データセットにのみデータを書き込みます。Cloud Data Fusion は複数の宛先をサポートしています。

ストリーミングデータソースまたはバッチデータソースを特定する

データの使用方法のニーズを考慮し、ストリーミングまたはバッチのユースケースの場所を特定します。たとえば、グローバルストリーミングサービスを低レイテンシで実行する必要がある場合は、Pub/Sub を使用できます。分析やレポート作成で使用するデータが必要な場合は、データを BigQuery にストリーミングできます。

オンプレミスまたは他のクラウド環境で Apache Kafka などのシステムからデータをストリーミングする必要がある場合は、Kafka to BigQuery Dataflow テンプレートを使用します。バッチワークロードの場合、最初のステップは通常、Cloud Storage へのデータの取り込みになります。データの取り込みには gsutil ツールまたは Storage Transfer Service を使用します。

自動化ツールでデータを取り込む

他のシステムからクラウドに手動でデータを移動するのは容易なことではありません。可能であれば、データ取り込みプロセスの自動化が可能なツールを使用してください。たとえば、Cloud Data Fusion の場合、GUI のドラッグ＆ドロップ操作で外部ソースからデータを取り込めるコネクタやプラグインが用意されています。チームでコードを作成する場合は、Data Flow または BigQuery でデータの取り込みを自動化できます。Pub/Sub は、ローコードまたはコードファーストのアプローチで役立ちます。データサイズが 1 TB までであれば、gsutil を使用して、データをストレージバケットに取り込みます。取り込むデータ量が 1 TB を超える場合は、Storage Transfer Service を使用します。

移行ツールを使用して別のデータウェアハウスから取り込む

Teradata、Netezza、Redshift など、別のデータウェアハウスシステムからの移行が必要な場合は、BigQuery Data Transfer Service の移行支援を利用できます。BigQuery Data Transfer Service は、スケジュールに従って外部ソースからデータを取り込むことができるサードパーティ転送も提供しています。詳細については、各データウェアハウスの詳細な移行方法をご覧ください。

データ取り込みの要件を評価する

取り込む必要があるデータの量は、システム設計で使用するサービスを決定するのに役立ちます。データをストリーミングで取り込む場合、Pub/Sub では 1 秒あたり数十ギガバイトにスケーリングされます。データの容量、ストレージ、リージョンの要件は、Pub/Sub Lite がシステム設計に適しているかどうかの判断に役立ちます。詳細については、Pub/Sub または Pub/Sub Lite の選択をご覧ください。

データのバッチ取り込みでは、転送するデータの合計量と転送速度も評価します。時間の見積もりやオンライン転送とオフライン転送の比較など、利用可能な移行オプションを確認してください。

適切なツールを使用してスケジュールに沿って定期的にデータを取り込む

Storage Transfer Service と BigQuery Data Transfer Service のどちらも、取り込みジョブをスケジュールで実行できます。取り込みのタイミング、または送信元と宛先のシステムを詳細に制御するには、Cloud Composer のようなワークフロー管理システムを使用します。手動のアプローチが必要な場合は、Cloud Scheduler と Pub/Sub を使用して Cloud Functions の関数をトリガーします。
コンピューティングインフラストラクチャを管理し、最大 1 TB のデータ転送を行う場合は、cron とともに gsutil コマンドを使用できます。Cloud Composer ではなく、この手動アプローチを使用する場合は、本番環境への転送スクリプトの作成に関するベストプラクティスに従ってください。

FTP / SFTP サーバーのデータ取り込みの要件を確認する

FTP / SFTP サーバーからデータを取り込む際にコードフリーの環境が必要な場合は、FTP コピープラグインを使用できます。長期的なワークフローソリューションをモダナイズして作成する場合、Cloud Composer はさまざまなソースやシンクからの読み取りと書き込みが可能なフルマネージドサービスです。

Apache Kafka コネクタを使用してデータを取り込む

Pub/Sub、Dataflow、BigQuery のいずれかを使用している場合、いずれかの Apache Kafka コネクタを使用してデータを取り込めます。たとえば、オープンソースの Pub/Sub Kafka コネクタを使用すると、Pub/Sub または Pub/Sub Lite からデータを取り込むことができます。

参考情報

データストレージ

以下に挙げるデータストレージのベストプラクティスを実際の環境に適用します。

ニーズに適したデータストアを選択する

使用するストレージソリューションのタイプを選択するには、データのダウンストリームの使用状況を確認して把握します。このデータの一般的なユースケースを次に示します。これにより、使用する Google Cloud プロダクトに関する推奨事項が提供されます。

データのユースケース	推奨のプロダクト
ファイルベース	Filestore
オブジェクトベース	Cloud Storage
低レイテンシ	Bigtable
時系列	Bigtable
オンラインキャッシュ	Memorystore
トランザクション処理	Cloud SQL
ビジネスインテリジェンス（BI）と分析	BigQuery
バッチ処理	Cloud Storage Bigtable（受信データが時系列で、低レイテンシのアクセスが必要な場合） BigQuery（SQL を使用する場合）。

データ構造の要件を確認する

非構造化データ（ドキュメント、テキストファイル、音声ファイル、動画ファイル、ログなど）の場合、通常はオブジェクトベースのストアが最適な選択肢となります。必要に応じて、オブジェクトストレージからデータを読み込んで処理できます。

XML や JSON などの半構造化データの場合は、ユースケースとデータアクセスパターンを利用して選択肢を確認してください。このようなデータセットを BigQuery に読み込むと、スキーマの自動検出が可能になります。低レイテンシが要求される場合は、JSON データを Bigtable に読み込むことができます。従来の要件がある場合や、アプリケーションがリレーショナルデータベースに対応している場合は、リレーションストアにデータセットを読み込むこともできます。

CSV、Parquet、Avro、ORC などの構造化データは BigQuery で使用できます（SQL を使用する BI 要件と分析要件がある場合）。詳細については、データのバッチ読み込み方法をご覧ください。オープン標準とテクノロジーでデータレイクを作成する場合は、Cloud Storage を使用できます。

データを移行して HDFS のコストを削減する

Hadoop 分散ファイルシステム（HDFS）のデータをオンプレミスまたは他のクラウドプロバイダからより低価格なオブジェクトストレージシステムに移動する方法について説明します。Cloud Storage は代替のデータストアとして多くの企業で選択されています。この選択のメリットとデメリットの詳細については、HDFS と Cloud Storage の比較をご覧ください。

push または pull 方式でデータを移動できます。どちらのメソッドでも hadoop distcp コマンドを使用します。詳しくは、オンプレミスから Google Cloud への HDFS データの移行をご覧ください。

オープンソースの Cloud Storage コネクタを使用して、Hadoop と Spark ジョブが Cloud Storage 内のデータにアクセスできるようにすることもできます。デフォルトでは、コネクタが Dataproc クラスタにインストールされます。これは、他のクラスタに手動でインストールできます。

オブジェクトストレージを使用して統一性のあるデータレイクを構築する

データレイクは、大量の構造化データ、半構造化データ、非構造化データを保存、処理、保護するための、一元化されたリポジトリです。Cloud Composer と Cloud Data Fusion を使用してデータレイクを構築できます。

最新のデータプラットフォームを構築するには、Cloud Storage の代わりに BigQuery を中央データソースとして使用します。BigQuery は、ストレージとコンピューティングを分離した最新のデータウェアハウスです。BigQuery で構築されたデータレイクを使用すると、Cloud Console で BigQuery から従来の分析を実行できます。また、Apache Spark などの他のフレームワークから保存されているデータにアクセスすることもできます。

参考情報

データを処理して変換する

データを処理して変換するときに、実際の環境に独自のデータ分析に関する以下のベストプラクティスを適用します。

Google Cloud で使用できるオープンソースソフトウェアについて確認する

多くの Google Cloud サービスは、オープンソースソフトウェアを使用して移行をシームレスに行います。Google Cloud は、Open API を使用して、オープンソースフレームワークと互換性があるマネージドソリューションとサーバーレスソリューションを提供し、ベンダーロックインを削減します。

Dataproc は、操作の負荷がほとんどなく、オープンソースソフトウェアをホストできる Hadoop 対応のマネージドサービスです。Dataproc は、Spark、Hive、Pig、Presto、Zookeeper をサポートしています。また、Hive メタストアをマネージドサービスとして提供し、Hadoop エコシステム内の単一障害点をなくします。

現在、Apache Beam をバッチおよびストリーミング処理エンジンとして使用している場合は、Dataflow に移行できます。Dataflow は、Apache Beam を使用するフルマネージドのサーバーレスサービスです。Dataflow を使用して Beam にジョブを作成しますが、Google Cloud で実行環境を管理します。

データ統合プラットフォームとして CDAP を使用している場合は、Cloud Data Fusion に移行してフルマネージドエクスペリエンスを実現できます。

ETL または ELT のデータ処理要件を特定する

チームの経験と好みは、データ処理の方法に関するシステム設計の決定に役立ちます。Google Cloud では、従来の ETL または最新の ELT データ処理システムのいずれかを使用できます。

ETL パイプラインでは、Data Fusion、Dataproc、Dataflow のいずれかを使用できます。
- 新しい環境では、バッチとストリーミングのアプリケーションを統合する方法として Dataflow をおすすめします。
- Data Fusion のフルマネージドアプローチでは、ドラッグ＆ドロップの GUI を使用してパイプラインを作成できます。
ELT パイプラインには、バッチとストリーミングの両方のデータ読み込みをサポートする BigQuery を使用します。BigQuery にデータを保存したら、SQL を使用してすべての変換を行い、ビジネスユースケースで新しいデータセットを導出します。
ETL から ELT に移行してモダナイズする場合は、Dataform を使用できます。BigQuery で BI をサポートするには、Fivetran などのサードパーティサービスも使用できます。

データのユースケースに適したフレームワークを使用する

使用するツールとフレームワークは、データのユースケースによって異なります。一部の Google Cloud プロダクトは、以下のすべてのデータユースケースを処理するように構築されていますが、他のユースケースでは特定のユースケースしかサポートされない場合があります。

バッチデータ処理システムの場合、使い慣れた SQL インターフェースを使用して BigQuery でデータの処理と変換を行います。既存のパイプラインが Apache Hadoop または Spark のオンプレミス、または別のパブリッククラウドで実行されている場合は、Dataproc を使用できます。
- また、Dataflow では、バッチとストリーミングの両方のユースケースに統一されたプログラミングインターフェースを使用できます。そのため、ETL には Dataflow を、ELT には BigQuery をモダナイズして使用することをおすすめします。
ストリーミングデータパイプラインでは、ウィンドウ処理、自動スケーリング、テンプレートを提供する Dataflow などのマネージドでサーバーレスのサービスを使用します。詳細については、Dataflow を使用した本番環境データパイプラインの構築をご覧ください。
- 分析と SQL に重点を置いたチームと機能がある場合は、BigQuery にデータをストリーミングすることもできます。
時系列分析やストリーミング動画分析など、リアルタイムのユースケースの場合は、Dataflow を使用します。

実行エンジンを将来にわたって管理する

ベンダーのロックインを最小限に抑え、将来別のプラットフォームを使用できるようにするには、Apache Beam プログラミングモデルおよび Dataflow をマネージドサーバーレスソリューションとして使用します。Beam プログラミングモデルを使用すると、Dataflow から Apache Flink または Apache Spark への変更など、基盤となる実行エンジンを変更できます。

Dataflow を使用して複数のソースからデータを取り込む

Pub/Sub、Cloud Storage、HDFS、S3、Kafka などの複数のソースからデータを取り込むには、Dataflow を使用します。Dataflow は Dataflow テンプレートをサポートするマネージドサーバーレスサービスで、さまざまなツールからテンプレートを実行できます。

Dataflow Prime は、パイプラインの実行プロセスで使用されるマシンの水平および垂直の自動スケーリングを提供します。また、問題を特定して修正する方法を提案するスマートな診断と最適化案も示します。

機密データの検出、識別、保護を行う

機密データ保護を使用して、構造化データと非構造化データを検査し、変換します。機密データ保護は、Cloud Storage やデータベースなど、Google Cloud のあらゆる場所にあるデータに対応しています。ダウンストリームの処理で機密データを安全に使用し続けるために、機密データの分類、マスキング、トークン化を行うことができます。機密データ保護を使用して、BigQuery データのスキャンや大規模なデータセットの PII の匿名化と再識別を行います。

データ変換プロセスをモダナイズする

Dataform を使用してデータ変換をコードとして書き込み、デフォルトでバージョン管理の使用を開始します。また、CI / CD、単体テスト、バージョン管理などのソフトウェア開発のベストプラクティスを SQL コードにも採用できます。Dataform は、PostgreSQL など、主要なクラウドデータウェアハウスプロダクトとデータベースをすべてサポートしています。

参考情報

データ分析とウェアハウス

独自のデータ分析とウェアハウスのベストプラクティスを実際の環境に適用します。

データストレージの要件を確認する

データレイクとデータウェアハウスは相互に排他的ではありません。データレイクは、非構造化および半構造化データの保存と処理に役立ちます。データウェアハウスは分析と BI に最適です。

データの要件を調査して、データの保存場所と、データの処理および分析に最適な Google Cloud プロダクトを判断します。BigQuery などのプロダクトは PB 単位のデータ処理が可能で、要件に合わせて拡張できます。

従来のデータウェアハウスから BigQuery に移行する機会を特定する

お客様の環境で現在使用されている従来のデータウェアハウスを確認します。複雑さを解消し、可能であれば費用を削減するために、従来のデータウェアハウスを BigQuery などの Google Cloud サービスに移行する機会を特定します。詳細とサンプルシナリオについては、BigQuery へのデータウェアハウスの移行をご覧ください。

データへの連携アクセスを計画する

データの要件と、他のプロダクトやサービスと連携する方法を確認します。データ連携の要件を特定し、適切なシステム設計を作成します。

たとえば、BigQuery では、Bigtable、Cloud SQL、Cloud Storage、Google ドライブなどの他のソースからデータを読み取ることができる外部テーブルを定義できます。これらの外部ソースは、BigQuery に保存するテーブルと結合できます。

BigQuery Flex Slots を使用してオンデマンドのバースト機能を提供する

実験的分析や探索的分析で多くのコンピューティングリソースが必要になり、追加容量が必要になることがあります。BigQuery では、Flex Slots の形式で追加のコンピューティング容量を取得できます。これらの Flex Slots は、需要の多い時期や重要な分析を完了する必要がある場合に役立ちます。

BigQuery に移行する際のスキーマの違いについて

BigQuery は、スタースキーマとスノーフレークスキーマの両方をサポートしていますが、デフォルトではネストされたフィールドと繰り返しフィールドを使用します。ネストされたフィールドと繰り返しフィールドは、他のスキーマよりも読みやすく、相関関係がある場合もあります。データがスタースキーマまたはスノーフレークスキーマで表現されているときに、BigQuery への移行を検討する場合は、システム設計を見直し、プロセスや分析に必要な変更を行ってください。

参考情報

レポートと可視化

レポート作成と可視化に関する以下のベストプラクティスを実際の環境に適用します。

BigQuery BI Engine を使用してデータを可視化する

BigQuery BI Engine は高速なインメモリ分析サービスです。BI Engine を使用すると、BigQuery に保存されたデータを分析できます。クエリのレスポンス時間は 1 秒未満で、同時実行性にも優れています。BI Engine は、BigQuery API に統合されています。BI Engine の予約済みの容量を使用して、必要に応じてオンデマンド料金または定額料金を管理します。BI Engine は、1 秒未満のレスポンス時間を必要とする他の BI アプリケーションやカスタムダッシュボードアプリケーションと連携できます。

Looker を使用して BI プロセスをモダナイズする

Looker は、BI、データアプリケーション、埋め込み分析向けの最新のエンタープライズプラットフォームです。データから整合性のあるデータモデルを高速かつ正確に作成でき、トランザクションデータストアや分析データストア内のデータにアクセスできます。Looker では、複数のデータベースとクラウドでデータを分析することもできます。既存の BI プロセスとツールがある場合は、Looker などの中央のプラットフォームをモダナイズして使用することをおすすめします。

参考情報

ワークフロー管理ツールを使用する

データ分析には、多くのプロセスとサービスが含まれます。データ分析のライフサイクル中に、さまざまなツールと処理パイプラインの間をデータが移動します。エンドツーエンドのデータパイプラインを管理および維持するには、適切なワークフロー管理ツールを使用します。Cloud Composer は、オープンソースの Apache Airflow プロジェクトに基づくフルマネージドのワークフロー管理ツールです。

Cloud Composer を使用して Dataflow パイプラインを起動し、Dataproc ワークフローテンプレートを使用できます。Cloud Composer は、DAG をテスト、同期、デプロイするための CI / CD パイプラインの作成や、データ処理ワークフローでの CI / CD パイプラインの使用にも役立ちます。詳細については、Cloud Composer: 開発のベストプラクティスをご覧ください。

移行に関するリソース

すでにデータ分析プラットフォームを実行していて、ワークロードの一部またはすべてを Google Cloud に移行する場合は、次の移行リソースでベストプラクティスとガイダンスを確認してください。

移行に関する一般的なガイダンス
- Google Cloud への移行: 移行パスの選択
- Twitter の広告エンゲージメント分析プラットフォームをモダナイズする例
Cloud Storage の移行
- オンプレミスから Google Cloud への HDFS データの移行
- VPC Service Controls と Storage Transfer Service を使用して Amazon S3 から Cloud Storage にデータを転送する
Pub/Sub の移行
- Kafka から Pub/Sub への移行
Bigtable の移行
- HBase から Bigtable へのデータの移行
- Aerospike から Bigtable への移行
Dataproc の以降
BigQuery の移行
Composer の移行
- Airflow 2 に環境を移行する

次のステップ

Google Cloud AI と機械学習のシステム設計について、次のようなベストプラクティスについて学習する。

システム設計をサポートする Google Cloud AI と機械学習サービスについて学習する。
ML データ処理のベストプラクティスを確認する。
モデルの開発とトレーニングのベストプラクティスについて学習する。

ML を導入する

Google Cloud Architecture Framework のこのドキュメントでは、Google Cloud におけるデータ分析の基本原則とベストプラクティスについて説明します。主要な AI サービスと機械学習（ML）サービスと、それらが AI と ML のライフサイクルのさまざまな段階でどのように役立つかについて説明します。以下のベストプラクティスは、AI と ML のニーズを満たし、システム設計を作成するのに役立ちます。このドキュメントは AI と ML の基本的なコンセプトを理解していることを前提としています。

Google Cloud で ML モデルを構築する際の開発プロセスを簡素化してオーバーヘッドを最小限に抑えるには、ユースケースに対して意味がある最高レベルの抽象化を検討します。抽象化のレベルは、システムを考えるまたはプログラムする複雑さの度合いとして定義されます。抽象化レベルが高いほど、閲覧者が認識できる細部は少なくなります。

ビジネスのニーズに基づいて Google AI や ML サービスを選択するには、次の表を使用します。

ペルソナ	Google サービス
ビジネスユーザー	Contact Center AI Insights、Document AI、ディスカバリ AI、Cloud Healthcare API などの標準ソリューション。
ML の経験があまりないデベロッパー	事前トレーニング済み API が、視覚、動画、自然言語などの一般的な知覚タスクに対処します。これらの API は、事前トレーニング済みモデルでサポートされており、デフォルトの検出項目を提供します。これらの API は、ML の専門知識やモデルの開発作業なしですぐに使用できます。トレーニング済みの API には、Vision API、Video API、Natural Language API、Speech-to-Text API、Text-to-Speech API、Cloud Translation API などがあります。
デベロッパーのための生成 AI	Vertex AI Search and Conversation により、開発者はすぐに使用できる機能を使用して chatbot を数分、検索エンジンを数時間で構築、かつデプロイできます。複数の機能をエンタープライズワークフローに統合することを必要とするデベロッパーは、Gen App Builder API を使用して直接統合できます。
デベロッパーとデータサイエンティスト	AutoML を使用すると、独自の画像、動画、テキスト、または表形式データによるカスタムモデルを開発できます。AutoML では、モデルの開発を加速させるために、Google の Model Zoo による最も効率の良いモデルアーキテクチャの自動検索がサポートされています。したがって、モデルを構築する必要はありません。AutoML では、モデルアーキテクチャの選択、ハイパーパラメータの調整、トレーニングとサービス提供に向けたマシンのプロビジョニングなど、共通のタスクを扱います。
データサイエンティストと ML エンジニア	Vertex AI カスタムモデルツーリングは、カスタムモデルをトレーニングして提供し、ML ワークフローの運用を可能にします。Compute Engine VM のようなセルフマネージドコンピューティングで ML ワークロードを運用できます。
データサイエンティスト、ML エンジニア	Vertex AI での生成 AI サポート（別名 genai）では、Google の大規模な生成 AI モデルにアクセスできるため、AI を活用したアプリケーションにて、モデルのテスト、調整、デプロイが可能です。
SQL インターフェースに詳しいデータエンジニア、データサイエンティスト、データアナリスト	BigQuery ML を使用すると、BigQuery に保存されたデータを基に SQL ベースのモデルを開発できます。

主なサービス

次の表に、AI と ML サービスの概要を示します。

Google サービス	説明
Cloud Storage と BigQuery	ML のデータとアーティファクト用に柔軟なストレージオプションを提供します。
BigQuery ML	BigQuery 内部に格納されたデータから ML モデルを直接構築できます。
Pub/Sub、Dataflow、 Cloud Data Fusion、Dataproc	バッチおよびリアルタイムのデータの取り込みと処理をサポートします。詳細については、データ分析をご覧ください。
Vertex AI	データサイエンティストと ML エンジニアは、単一世代のプラットフォームを使用して、生成 AI から MLOps まで、あらゆる ML モデルを作成、トレーニング、テスト、モニタリング、調整、デプロイできます。ツールには次のものが含まれます。正確なデータラベルを得るための Vertex Data Labeling。移植可能かつ一貫性のある環境でモデルを構築してデプロイするための Deep Learning Containers。マネージドまたはユーザーマネージドの JupyterLab 環境向け Vertex AI Workbench。フルマネージドのトレーニングサービス用 Vertex Training。テストを追跡するための Vertex AI TensorBoard。ハイパーパラメータを調整するための Vertex AI Vizier。カスタムトレーニング、BigQuery ML、AutoML モデルをサポートする統合デプロイフレームワークの Vertex Prediction。モデル予測の説明を表面化させるための Vertex Explainable AI。本番環境へのモデルのデプロイを迅速化する Vertex Experiments。迅速なモデル選択が可能になりました。オーケストレーション用の Vertex AI Pipelines や、フルマネージドなリポジトリ用の Vertex AI Feature Store などの MLOps ツール。
Vertex AI Search and Conversation	ウェブサイトやエンタープライズデータ全体で使用するための chatbot と検索エンジンを構築できます。 Vertex AI Search and Conversation の Conversational AI によって、ジェネレーティブ AI を活用した chatbot とデジタルアシスタントによる顧客や従業員のやり取りを刷新できます。たとえば、これらのツールを使用すると、チャットエクスペリエンス内からトランザクションを有効にすることで、情報以上のものが提供できます。 Vertex AI Search and Conversation での Enterprise Search を使用すると、企業はパブリックまたはプライベートなウェブサイトで、顧客と従業員向けの検索エクスペリエンスを構築できます。Enterprise Search は、高品質なマルチモーダル検索結果の提供に加えて、結果を生成 AI で要約し、対応する引用を提示できます。
Vertex AI の生成 AI	Google の大規模生成 AI モデルにアクセスして、AI 搭載のアプリケーションで使用するためにテスト、調整、デプロイを行うことができます。Vertex AI の生成 AI は genai とも呼ばれます。生成 AI モデル（基盤モデル）は、生成するコンテンツのタイプによって分類されます。このコンテンツには、テキストとチャット、画像、コード、テキストエンベディングが含まれます。 Vertex AI Studio を使用すると、Google Cloud コンソールで生成 AI モデルのプロトタイプを迅速に作成してテストできます。サンプルプロンプトのテスト、独自のプロンプトの設計、基盤モデルのカスタマイズを行い、アプリケーションのニーズを満たすタスクを処理できます。モデルのチューニング - 入出力例のデータセットを使用して調整することで、特定のユースケースに合わせて基盤モデルをカスタマイズできます。 Model Garden は、エンタープライズ向け基盤モデル、タスク固有のモデル、API を提供します。
事前トレーニング済み API	トレーニング済みの API には、Vision API、Video API、Natural Language API、Speech-to-Text API、Text-to-Speech API、Cloud Translation API などがあります。
AutoML	ML モデルを構築、デプロイ、スケールするためのカスタムモデルツールを提供します。デベロッパーは、独自のデータをアップロードし、適切な AutoML サービスを使用してカスタムモデルを構築できます。 AutoML Vision: 画像データに対して画像分類とオブジェクト検出を行います。 AutoML Video: 動画データに対するオブジェクト検出、分類、アクション認識を行います。 AutoML Text: テキストデータに対して言語分類、エンティティ抽出、感情分析を行います。 AutoML Translation: 言語ペアを検出して翻訳します。 AutoML Tables: 回帰、分類、予測のモデルを構築できます。構造化データを対象としています。
AI Infrastructure	AI アクセラレータを使用して、大規模な ML ワークロードを処理できます。これらのアクセラレータを使用すると、費用対効果の高い方法でディープラーニングモデルや ML モデルからトレーニングし、推論を行うことができます。 GPU により、ディープラーニングモデルの推論や、スケールアップまたはスケールアウトによるトレーニングの費用対効果を高めることができます。Tensor Processing Unit（TPU）は、ディープニューラルネットワークをトレーニングして実行するための、カスタム開発された ASIC です。
Dialogflow	会話体験を実現する仮想エージェントを提供します。
Contact Center AI	人間のエージェント向けに Agent Assist の機能を使用して、自動化されインサイトを多用したコンタクトセンター体験を提供します。
Document AI	ドキュメント全般、および融資関連や調達関連のドキュメントなど、具体的なドキュメントの種類に対して大規模なドキュメント理解を提供します。
Lending DocAI	担保のドキュメント処理を自動化します。規制とコンプライアンスの要件に対応しながら、処理時間を短縮し、データキャプチャを合理化します。
Procurement DocAI	請求書や領収書などの非構造化ドキュメントを構造化データに変換して運用効率を高め、カスタマーエクスペリエンスを向上させ、意思決定に情報を提供することで、調達データのキャプチャを大規模に自動化します。
推奨事項	パーソナライズされたおすすめ商品情報を提供します。
Healthcare Natural Language AI	医療文書を確認、分析できます。
Media Translation API	音声データからのリアルタイムの音声翻訳を有効にします。

データ処理

以下に挙げるデータストレージのベストプラクティスを実際の環境に適用します。

データが ML 要件を満たすようにする

ML に使用するデータは、データの種類に関係なく特定の基本要件を満たす必要があります。要件には、ターゲットを予測するデータの能力、トレーニングに使用されるデータと予測に使用されるデータの粒度の整合性、トレーニング用に正確にラベル付けされたデータなどがあります。また、十分な量のデータが必要になります。詳細については、データ処理をご覧ください。

表形式データを BigQuery に保存する

表形式のデータを使用する場合は、すべてのデータを BigQuery に保存し、BigQuery Storage API を使用して、データを読み取ってください。API とのインタラクションを容易にするためには、データの読み取り方法に応じて、以下の追加ツールオプションからひとつ選んで使用してください。

Dataflow を使用する場合は、BigQuery I/O コネクタを使用してください。
TensorFlow や Keras を使用する場合は、BigQuery 用の tf.data.dataset リーダーを使用します。
画像や動画などの非構造化データを使用する場合は、すべてのデータを Cloud Storage に保存することを検討します。

入力データタイプによって、使用可能なモデル開発ツールが決定されます。事前トレーニング済みの API、AutoML、BigQuery ML は、特定の画像、動画、構造化データのユースケースに対して、より費用対効果が高く、時間効率の良い開発環境を提供できます。

ML モデルを開発するために十分なデータを確保する

利便性の高い ML モデルを開発するには、十分なデータが必要です。カテゴリを予測する場合、各カテゴリの推奨サンプル数は、機能数の 10 倍になります。より多くのカテゴリを予測するには。より多くのデータが必要です。データセットがアンバランスだと、さらに多くのデータが必要です。ラベル付けされたデータが不足している場合は、半教師あり学習を検討してください。

データセットサイズにはトレーニングや提供という意味も含みます。小規模なデータセットの場合は、Notebooks インスタンス内で直接トレーニングできます。分散トレーニングが必要な大規模なデータセットの場合は、Vertex AI custom training service を使用してください。Google 側でデータモデルをトレーニングすることを希望される場合は、AutoML を使用してください。

使用するデータを準備する

適切に準備されたデータはモデルデプロイを加速させます。データパイプラインを構成するときは、両方のタイプのデータから一貫した結果が得られるように、バッチデータとストリーミングデータの両方を処理できるようにしてください。

モデルの開発とトレーニング

以下に挙げる独自のモデル開発と、トレーニングのベストプラクティスを実際の環境に適用します。

マネージドモデル開発またはカスタムトレーニングモデルの開発を選択する

モデルをビルドする場合、最高レベルの抽象化を検討してください。可能であれば、AutoML を使用して、開発およびトレーニングのタスクを処理してください。カスタムトレーニング済みのモデルについては、セルフマネージドオプションの代わりにスケーラビリティと柔軟性のためのマネージドオプションを選択してください。モデル開発オプションについては、推奨されるツールとプロダクトを使用するをご覧ください。

Compute Engine VM や Deep Learning VM コンテナのセルフマネージドトレーニングではなく、Vertex AI Training サービスを検討してください。JupyterLab 環境の場合は、マネージドとユーザーマネージドの両方の JupyterLab 環境を提供する Vertex AI Workbench を検討してください。詳細については、ML 開発と運用化されたトレーニングをご覧ください。

カスタムトレーニングされたモデル用にビルド済みコンテナやカスタムコンテナを使用する

Vertex AI 上のカスタムトレーニングモデルの場合、ML のフレームワークとフレームワークバージョンに応じて、事前にビルドされたコンテナやカスタムコンテナを使用できます。事前にビルドされたコンテナは、TensorFlow、scikit-learn、PyTorch、XGBoost のいずれかのバージョン用に作成された Python トレーニングアプリケーションに使用できます。

それ以外の場合は、トレーニングジョブ用のカスタムコンテナを作成することを選択できます。たとえば、ビルド済みのコンテナでは利用できない Python ML フレームワークを使用してモデルをトレーニングしたい場合、もしくは Python 以外のプログラミング言語を使用してトレーニングしたい場合は、カスタムコンテナを使用してください。カスタムコンテナ内で、トレーニングアプリケーションとそのすべての依存関係をイメージにプリインストールします。このイメージを使用して、トレーニングジョブを実行します。

分散トレーニングの要件を検討する

分散トレーニング要件を検討します。TensorFlow や PyTorch のような ML フレームワークでは、複数のマシンで同一のトレーニングコードを実行できます。これらのフレームワークは、各マシンに設定された環境変数に基づき、自動で作業分担を調整します。フレームワークによっては、追加のカスタマイズが必要になる場合があります。

次のステップ

AI と ML の詳細については、以下をご覧ください。

環境のサステナビリティを重視した設計

この Google Cloud アーキテクチャフレームワークのドキュメントでは、Google Cloud でワークロードの環境のサステナビリティにアプローチする方法が要約されています。Google Cloud で二酸化炭素排出量を最小限に抑える方法に関する情報が含まれています。

二酸化炭素排出量を把握する

Google Cloud を利用した二酸化炭素排出量を把握するには、Carbon Footprint ダッシュボードを使用してください。Carbon Footprint ダッシュボードではさらに、お客様が所有する Google Cloud プロジェクトとお客様が使用するクラウドサービスへの排出量に基づいています。

詳しくは、「Google Cloud 二酸化炭素排出量を削減する」の二酸化炭素排出量を理解するをご覧ください。

最適なクラウドリージョンを選択する

二酸化炭素排出量を削減するための簡単で効果的な方法の一つは、二酸化炭素排出量の低いクラウドリージョンを選択することです。この選択をサポートするために、Google はすべての Google Cloud リージョンの二酸化炭素データを公開しています。

リージョンを選択する場合は、料金やネットワークレイテンシなどの他の要件と排出量の削減とのバランスを取ることが必要になる場合があります。リージョンを選択するには、Google Cloud リージョン選択ツールを使用します。

詳細については、「Google Cloud 二酸化炭素排出量を削減する」の最適なクラウドリージョンを選択するをご覧ください。

最適なクラウドサービスを選択する

既存の温室効果ガス排出量を削減するために、オンプレミス VM ワークロードを Compute Engine に移行することを検討してください。

また多くのワークロードでは VM が不要であることも考慮してください。多くの場合、代わりにサーバーレスサービスを利用できます。これらのマネージドサービスは、クラウドリソースの使用量を自動的に最適化し、同時にクラウドの費用と温室効果ガス排出量を削減できます。

詳細については、「Google Cloud 二酸化炭素排出量を削減する」の最適なクラウドサービスを選択するをご覧ください。

アイドル状態のクラウドリソースを最小限に抑える

アイドル状態のリソースにより、不要なコストと排出量が発生します。リソースがアイドル状態になる一般的な原因は、次のとおりです。

アクティブなクラウドリソースが未使用（VM インスタンスがアイドル状態であるなど）。
リソースがオーバープロビジョニングされている（VM インスタンス数がワークロードで必要な数を超えているマシンタイプなど）。
効率化のための最適化が必ずしも行われていないリフト&シフト移行など、最適ではないアーキテクチャ。これらのアーキテクチャを段階的に改善することを検討してください。

クラウドリソースの無駄を最小限に抑えるための一般的な戦略は次のとおりです。

アイドル状態のリソースまたはオーバープロビジョニングされたリソースを特定し、それらを削除するか、サイズの適正化を行う。
アーキテクチャをリファクタリングして、より最適な設計を組み込む。
ワークロードをマネージドサービスに移行する。

詳しくは、「Google Cloud 二酸化炭素排出量を削減する」のアイドル状態のクラウドリソースを最小限に抑えるをご覧ください。

バッチワークロードの排出量を削減する

二酸化炭素排出量の少ないリージョンでバッチワークロードを実行します。さらに削減するには、電力網の炭素強度が可能な限り低い時間帯にワークロードを実行します。

詳細については、「Google Cloud 二酸化炭素排出量を削減する」のバッチワークロードの排出量を削減するをご覧ください。

次のステップ

Carbon Footprint データを使用してクラウドの二酸化炭素排出量を測定、報告、削減する方法を学習する。
Google Cloud 二酸化炭素排出量を削減する方法を学習する。

Google Cloud アーキテクチャフレームワーク: オペレーショナルエクセレンス

Google Cloud アーキテクチャフレームワークのこのカテゴリでは、Google Cloud でサービスを効率的に運用する方法について説明します。ビジネス価値を実現するシステムを運用、管理、モニタリングする方法について解説します。また、オペレーショナルエクセレンスをサポートする Google Cloud プロダクトと機能についても説明します。オペレーショナルエクセレンスの原則を使用することは、信頼性の基盤を構築することに役立ちます。これは、オブザーバビリティ、自動化、スケーラビリティなどの基本的な要素を設定することで行います。

このアーキテクチャフレームワークでは、ベストプラクティスについて解説し、実装上の推奨事項を示しながら、オペレーショナルエクセレンスの実現に役立ついくつかのプロダクトとサービスについて説明します。このフレームワークは、ビジネスニーズに合わせて Google Cloud 環境を設計できるようにすることを目的としています。

アーキテクチャフレームワークのオペレーショナルエクセレンスのカテゴリでは、次の方法を学習します。

デプロイを自動化する

Google Cloud Architecture Framework のこのドキュメントでは、ビルド、テスト、デプロイを自動化するためのベストプラクティスについて説明します。

自動化を行うと、コードの更新などの繰り返しのプロセスに人間が関与することによるエラーを排除することで、ビルド、テスト、デプロイの標準化が進みます。このセクションでは、自動化する際にさまざまな検査と安全確保の仕組みを使用する方法について説明します。標準化されたマシン制御のプロセスにより、デプロイが安全に適用されるようになります。また、ユーザーエクスペリエンスに大きな影響を与えることなく、必要に応じて以前のデプロイを復元する仕組みも提供されます。

コードを中央のコードリポジトリに保存する

コードは、タグ付けされたバージョン管理システムと、コード変更のロールバック機能がある中央のコードリポジトリに保存します。バージョン管理を使用すると、ファイルを整理して、チームや組織全体にわたってアクセス、更新、削除を管理できます。

さまざまな開発段階では、必要に応じてリポジトリのバージョニングやラベル付けを行います。たとえば、ラベルは、test、dev、prod などになります。

Google Cloud では、コードを Cloud Source Repositories に保存して、バージョニングや他の Google Cloud プロダクトと統合することが可能です。コンテナ化されたアプリケーションを構築する場合は、コンテナ用のマネージドレジストリである Artifact Registry を使用します。

バージョン管理の詳細については、バージョン管理をご覧ください。リポジトリを使用してトランクベース開発を実装する方法の詳細については、トランクベース開発をご覧ください。

継続的インテグレーションと継続的デプロイ（CI / CD）を使用する

デプロイは、継続的インテグレーションと継続的デプロイ（CI / CD）を使用して自動化します。CI / CD の手法は、開発チームが従っている構成や処理のパイプラインを組み合わることです。

CI / CD 手法では、ソフトウェア開発チームの生産性を改善することで、デプロイのスピードを上げます。この手法により、デベロッパーは、入念にテストされた小規模な変更をより頻繁に行うことができる一方で、変更のデプロイにかかる時間を削減できます。

CI / CD 手法の一環として、コードのビルド、テスト、デプロイのすべてのステップを自動化します。次に例を示します。

新しいコードがリポジトリに commit されるたびに、その commit によって自動的にビルドとテストのパイプラインが呼び出されます。
統合テストを自動化します。
ビルドが特定のテスト基準を満たした後に変更がデプロイされるように、デプロイを自動化します。

Google Cloud では、CI / CD パイプラインに Cloud Build と Cloud Deploy を使用できます。

Cloud Build を使用すると、アプリケーションパッケージのパッケージ化とビルドに使用できる依存関係とバージョンを定義できます。ビルド構成をバージョニングしてすべてのビルドに一貫性を持たせ、必要に応じて以前の構成にロールバックできるようにします。

Cloud Deploy を使用すると、アプリケーションを Google Cloud の特定の環境にデプロイして、デプロイメントパイプラインを管理できます。

CI / CD の実装の詳細については、継続的インテグレーションとデプロイの自動化をご覧ください。

Infrastructure as Code でインフラストラクチャをプロビジョニングして管理する

Infrastructure as Code とは、VM などのインフラストラクチャとファイアウォールルールなどの構成を管理する記述モデルを使用することです。Infrastructure as Code を使用すると、次のことを行えます。

CI / CD パイプラインのデプロイ環境やテスト環境など、クラウドリソースを自動的に作成する。
インフラストラクチャの変更を、アプリケーションの変更と同じように扱う。たとえば、構成の変更がレビュー、テスト、監査されるようにします。
クラウドインフラストラクチャに関する信頼できる唯一の情報源を確保する。
必要に応じて、クラウド環境を複製する。
必要に応じて以前の構成にロールバックする。

この Infrastructure as Code のコンセプトは、Google Cloud のプロジェクトにも適用されます。この方法を使用すると、プロジェクト内に共有 VPC 接続や Identity and Access Management（IAM）アクセスなどのリソースを定義できます。この方法の例については、Google Cloud Project Factory Terraform モジュールをご覧ください。

Terraform などのサードパーティツールを使用すると、Google Cloud にインフラストラクチャを自動的に作成できます。詳細については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。

重要なリソースを誤って削除することや、不正に削除されることから保護するために、プロジェクトリーエン、Cloud Storage の保持ポリシー、Cloud Storage バケットのロックなどの Google Cloud の機能の使用を検討してください。

ソフトウェアデリバリーのライフサイクル全体にテストを組み込む

ソフトウェアのリリースを成功させるには、テストが不可欠です。継続的なテストにより、チームが高品質のソフトウェアを迅速に作成でき、ソフトウェアの安定性が強化されます。

テストの種類は次のとおりです。

単体テスト。単体テストは高速で、迅速なデプロイに役立ちます。単体テストはコードベースの一部として扱い、ビルドプロセスの一部として追加します。
統合テスト。統合テストは、特にスケールするように設計され、複数のサービスに依存するワークロードにとって重要です。相互接続されたサービスとの統合をテストする際は、そのテストが複雑になることがあります。
システムテスト。システムテストは時間がかかり、複雑ですが、デプロイ前にエッジケースを特定して問題を修正するのに役立ちます。
その他のテスト。静的テスト、負荷テスト、セキュリティテスト、ポリシー検証テストなど、他にも実行すべきテストがあります。これらのテストは、アプリケーションを本番環境にデプロイする前に実行します。

テストを組み込むには、次のようにします。

ソフトウェアデリバリーライフサイクル全体にわたって、全種類のテストを継続的に実施する。
これらのテストを自動化し、CI / CD パイプラインに含める。いずれかのテストが失敗した場合は、パイプラインを失敗させます。
デプロイを継続的に更新し、新しいテストを追加して、デプロイの運用状態を改善する。

テスト環境の場合は、次のようにします。

使用するテスト環境ごとに個別の Google Cloud プロジェクトを使用する。アプリケーションごとに個別のプロジェクト環境を使用します。この分離により、本番環境のリソースと下位環境のリソースが明確に区別されます。また、ある環境内での変更が、誤って他の環境に影響を与えることがなくなります。
テスト環境の作成を自動化する。この自動化を行う方法の 1 つは、Infrastructure as Code を使用することです。
合成本番環境を使用して変更内容をテストする。この環境では、エンドツーエンドのテストやパフォーマンステストなど、アプリケーションのテストと、ワークロードに対するさまざまな種類のテストを行う、本番環境に似た環境を提供します。

継続的なテストの実装の詳細については、テストの自動化をご覧ください。

デプロイを段階的に開始する

エンドユーザーの中断を最小化、ローリングアップデート、ロールバック方法、A/B テスト方法などの重要なパラメータに基づいて、デプロイ方針を選択します。ワークロードごとにこれらの要件を評価し、ローリングアップデート、Blue/Green デプロイ、カナリアデプロイなどの実証済みの手法からデプロイ方針を選択します。

変更は、CI / CD プロセスによってのみ、本番環境に push されます。

不変のインフラストラクチャの使用を検討してください。不変のインフラストラクチャとは、変更も更新もされないインフラストラクチャのことです。新しいコードをデプロイする必要がある場合や環境内の他の構成を変更する場合は、環境全体（VM や Pod のコレクションなど）を新しい環境に置き換えます。Blue/Green デプロイは、不変のインフラストラクチャの一例です。

変更をデプロイする際には、カナリアテストを行ってシステムのエラーを確認することをおすすめします。強力なモニタリングとアラートのシステムがあれば、このタイプのモニタリングは簡単です。A/B テストやカナリアテストには、Google Cloud のマネージドインスタンスグループを使用できます。その後、必要に応じて低速ロールアウトや復元を行います。

デプロイを自動化し、デプロイパイプラインを管理するには、Cloud Deploy の使用を検討してください。また、Google Cloud での自動デプロイとデプロイパイプラインの作成には、Spinnaker や Tekton のようなさまざまなサードパーティツールも使用できます。

以前のリリースをシームレスに復元する

復元方法は、デプロイ方針の一部として定義します。デプロイメントやインフラストラクチャ構成は、以前のバージョンのソースコードにロールバックできるようにします。以前の安定したデプロイメントを復元することは、信頼性とセキュリティ両方のインシデント管理における重要なステップです。

また、デプロイプロセスの開始前の状態に環境を復元できるようにもします。これには次のものが含まれます。

アプリケーションのコード変更を元に戻す機能。
環境に加えた変更を元に戻す機能。
不変のインフラストラクチャを使用して、デプロイによって環境が変更されないようにする。こうすることによって、構成の変更を元に戻しやすくします。

CI / CD パイプラインをモニタリングする

自動化されたビルド、テスト、デプロイプロセスをスムーズに実行するため、CI / CD パイプラインをモニタリングします。いずれかのパイプラインで障害が発生したことを示すアラートを設定します。パイプラインが失敗した場合に根本原因を分析できるように、パイプラインの各ステップでは適切なログステートメントを書き出す必要があります。

Google Cloud では、すべての CI / CD サービスが Google Cloud のオペレーションスイートに統合されています。次に例を示します。

Cloud Source Repositories は、Pub/Sub サービスと統合されています。
Cloud Build は、Pub/Sub と統合され、監査ログとビルドログも保存されます。ビルドログに含まれる特定のキーワードや他の多くの指標に関するアラートは、Cloud Monitoring サービスを使用して設定できます。
Cloud Deploy は監査ログを保存します。

モニタリングとロギングの詳細については、モニタリング、アラート、ロギングを設定するをご覧ください。

アプリケーションを安全にデプロイする

アーキテクチャフレームワークのセキュリティ、コンプライアンス、プライバシーのカテゴリにある「アプリケーションを安全にデプロイする」セクションを確認してください。

バージョンリリースのための管理ガイドラインの確立する

エンジニアによるミスを防ぎ、ソフトウェアの配信スピードを上げるには、新しいソフトウェアバージョンをリリースするための管理ガイドラインが明確に文書化されている必要があります。

リリースエンジニアは、ソフトウェアがどのように構築され、配信されているかを監督します。リリースエンジニアリングシステムは、次の 4 つの手法に基づいています。

セルフサービスモード。 ソフトウェアエンジニアがよくある間違いを避けるためのガイドラインを確立します。これらのガイドラインは一般に、自動プロセスにコード化されています。
頻繁なリリース。 高速化はトラブルシューティングに役立ち、問題の修正を容易にします。頻繁なリリースは自動化された単体テストに依拠します。
ハーメティックビルド。ビルドツールとの整合性を確保します。バージョンのビルドに使用するビルドコンパイラのバージョンを 1 か月前と比較します。
ポリシーの適用。すべての変更には、コードの審査が必要です。セキュリティを強化するための一連のガイドラインとポリシーを含めることが理想的です。ポリシーの適用により、コードのレビュー、トラブルシューティング、新しいリリースのテストが改善されます。

次のステップ

モニタリング、アラート、ロギングを設定する（このシリーズの次のドキュメント）
アプリケーションを安全にデプロイする（アーキテクチャフレームワークのセキュリティ、コンプライアンス、プライバシーのカテゴリにあります）
コンテナ構築のおすすめの方法を確認する
技術的機能について学習する
アーキテクチャフレームワークの他のカテゴリ（システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化）を確認する。

モニタリング、アラート、ロギングを設定する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、モニタリング、アラート、ロギングを設定し、システムの動作に基づいて動作させる方法について説明します。有用な指標を特定して追跡し、システムに関する情報が見やすくなるようにダッシュボードを構築します。

DevOps Resource and Assessment（DORA）の研究プログラムでは、次のようにモニタリングを定義しています。

「ビジネス上の意思決定を行うことを目的として、アプリケーションやインフラストラクチャをトラックして情報を収集、分析、使用するプロセス。モニタリングは、システムと作業に関する分析情報を提供する重要な機能です。」

Monitoring により、サービスオーナーは次のことができます。

サービスへの変更がパフォーマンスに影響する場合に、十分な情報に基づいて判断を行う。
インシデント対応に科学的アプローチを適用する
ビジネス目標との整合性を測定する

モニタリング、ロギング、アラートを使用すると、次のことが可能になります。

長期的な傾向を分析する
一定期間のテストを比較する
重要な指標に関するアラートを定義する
関連性の高いリアルタイムダッシュボードを作成する
振り返り分析を行う。
ビジネス主導の指標とシステムの健全性の指標の両方をモニタリングする。
- ビジネス主導の指標は、システムがビジネスをどの程度サポートしているかを理解するのに役立ちます。たとえば、指標を使用して次の対象をモニタリングします。
  - ユーザーにサービスを提供するためのアプリケーションのコスト
  - デザイン刷新後のサイトのトラフィック量の変化
  - ユーザーがサイトで商品を購入するまでの時間
- システムの健全性の指標は、システムが正常に動作しているかどうかと、パフォーマンスが許容できるレベル内にあるかどうかを把握する助けになります。

システムをモニタリングするには、次の 4 つのシグナルを使用します。

レイテンシ。リクエストのレスポンスにかかる時間。
トラフィック。システムに対する需要はどれくらいか。
エラー。失敗したリクエストの割合です。失敗は、明示的（HTTP 500 など）、暗黙的（HTTP 200 の成功レスポンスが間違ったコンテンツと結合されているなど）、またはポリシー別（たとえば、commit のレスポンス時間が 1 秒である場合、1 秒を超えるリクエストはエラーになります）です。
飽和度。サービスの完全性。飽和度はシステムの割合の測定であり、最も制約のあるリソースを強調します（メモリ制約のあるシステムではメモリを表示し、I/O 制約のあるシステムでは I/O を表示）。

モニタリングプランを作成する

組織のミッションとその運用戦略に沿ったモニタリングプランを作成します。アプリケーション開発時のモニタリングとオブザーバビリティのプランニングを含めます。アプリケーション開発の早い段階でモニタリングプランを取り入れることで、組織のオペレーショナルエクセレンスを実現できます。

モニタリングプランには次の情報を含めます。

オンプレミスリソースやクラウドリソースなど、すべてのシステムを含めます。
クラウドコストのモニタリングを使用して、スケーリングイベントによって使用量が予算のしきい値を超えないようにします。
インフラストラクチャのパフォーマンス、ユーザーエクスペリエンス、ビジネスの重要業績評価指標（KPI）を測定するさまざまなモニタリング戦略を構築します。たとえば、静的なしきい値はインフラストラクチャのパフォーマンスを測定するのには適していますが、ユーザーエクスペリエンスを正確に反映していない場合などがあります。

モニタリング戦略が成熟したら、プランを更新します。システムの改善に向けてプランを継続的に見直します。

組織のあらゆる側面を測定する指標を定義する

デプロイの動作の測定に必要な指標を定義します。手順は次のとおりです。

ビジネス目標を定義する。
パフォーマンスを測定するための定量化可能な情報を提供する指標と KPI を特定する。指標の定義は、ビジネスニーズ（クラウドコストを含む）から技術コンポーネントまで、組織のあらゆる側面に対応するようにします。
これらの指標を使用して、アプリケーションのサービスレベル指標（SLI）を作成する。詳しくは、適切な SLI の選択をご覧ください。

各コンポーネントの共通指標

指標は、インフラストラクチャやネットワーキングからビジネスロジックまで、サービスのあらゆるレベルで生成されます。次に例を示します。

インフラストラクチャ指標:
- 仮想マシン統計情報。インスタンス、CPU、メモリ、使用率、カウントなど。
- コンテナベースの統計。クラスタ使用率、クラスタ容量、Pod レベルの使用率、カウントなど。
- ネットワーク統計。上り（内向き）/ 下り（外向き）、コンポーネント間の帯域幅、レイテンシ、スループットなど。
- ロードバランサによって測定される 1 秒あたりのリクエスト数
- ディスクあたりの合計読み取りディスクブロック数
- 特定のネットワークインターフェースを介して送信されたパケット
- 特定のプロセスのメモリヒープサイズ
- レスポンスレイテンシの分布
- データベースインスタンスによって拒否された無効なクエリの数
アプリケーション指標:
- アプリケーション固有の動作。秒間クエリ数、1 秒あたりの書き込み数、1 秒あたりの送信メッセージ数など。
マネージドサービス統計の指標:
- Google マネージドサービス（BigQuery、App Engine、Bigtable などの API またはプロダクト）の QPS、スループット、レイテンシ、使用率
ネットワーク接続統計の指標:
- オンプレミスシステムまたは Google Cloud 外のシステムへの接続に関する VPN / 相互接続関連の統計。
SLI
- システムの全体的な正常性に関連する指標。

モニタリングを設定する

オンプレミスリソースとクラウドリソースの両方をモニタリングするようにモニタリングを設定します。

次のようなモニタリングソリューションを選択してください。

プラットフォームに依存しない
オンプレミス、ハイブリッド、マルチクラウドの環境をモニタリングするための統一された機能を提供する

1 つのソースから取得したモニタリングデータを他のソースからのデータと統合することで、統合されたダッシュボードで指標と可視化を表示する

モニタリングを設定する際は、可能であればモニタリングタスクを自動化してください。

Google Cloud によるモニタリング

Cloud Monitoring などのモニタリングサービスを使用すると、モニタリングサービスを自分で構築するよりも簡単です。複雑なアプリケーションのモニタリングは、それ自体がエンジニアリングに多大な労力を要する作業です。インストルメンテーション、データの収集と表示、アラート設定の既存のインフラストラクチャがあったとしても、構築と保守は片手間でできるものではなく、フルタイムの仕事になります。

Cloud Monitoring を使用して、オンプレミスリソースとクラウドリソースの両方のアプリケーションおよびインフラストラクチャのパフォーマンス、可用性、正常性を可視化することを検討してください。

Cloud Monitoring は、Google Cloud のオペレーションスイートの一部であるマネージドサービスです。Cloud Monitoring を使用して、Google Cloud サービスとカスタム指標をモニタリングできます。Cloud Monitoring には、サードパーティのモニタリングツールと統合するための API が用意されています。

Cloud Monitoring は、システムのクラウドベースのインフラストラクチャからの指標、ログ、イベントを集約します。このデータは、デベロッパーとオペレーターにとって、豊富な観測可能シグナルのセットとなります。これらのシグナルにより、根本原因の分析を迅速に行い、解決までの平均時間を短縮できます。Cloud Monitoring を使用すると、ビジネス目標に応じたアラートとカスタム指標を定義し、システムの健全性の集計、可視化、モニタリングを行うことができます。

Cloud Monitoring は、クラウドとオープンソースアプリケーションサービス用のデフォルトのダッシュボードを提供します。指標モデルを使用すると、強力な可視化ツールでカスタムダッシュボードを定義し、Metrics Explorer でグラフを構成できます。

アラートの設定

優れたアラートシステムにより、機能のリリース能力が向上します。パフォーマンスを時系列で比較することで、機能のリリースの速度やロールバックの必要性を判断できます。ロールバックの詳細については、以前のリリースをシームレスに復元するをご覧ください。

アラートを設定する際に、アラートを重要な指標に直接マッピングします。これらの重要な指標としては、次のようなものがあります。

4 つのゴールデンシグナル:
- レイテンシ
- トラフィック
- エラー
- 飽和度
システムの健全性
サービスの使用状況
セキュリティイベント
ユーザーエクスペリエンス

解決までの時間を短縮するために、アラートから行動に移せるようにします。そのためには、アラートごとに以下のことを行います。

モニタリングの対象やビジネスへの影響など、明確な説明を記述します。
すぐに対処するために必要なすべての情報を用意します。アラートの意味を把握するのに数回のクリックやナビゲーションが必要であれば、すぐに行動を起こすのは難しいでしょう。
アラートの優先度を定義します。
アラートに対応するユーザーやチームを明確に定義します。

重要なアプリケーションやサービスに対しては、サービスの健全性の低下、構成の変更、スループットの急増など、一般的な障害条件によってトリガーされるアラートに自動修復を設定します。

アラートを設定する際は、手間を省くようにします。たとえば、よく発生するエラーへの対応をなくすには、こうしたエラーの修正を自動化し、アラートがトリガーされないようにします。これにより、担当のユーザーは、アプリケーションの運用コンポーネントの信頼性を向上させることに集中できます。詳細については、自動化の文化を創るをご覧ください。

モニタリングダッシュボードとアラートダッシュボードを作成する

モニタリングを実施したら、モニタリングとアラートのシステムからの情報を含む、関連性のある複雑でないダッシュボードを作成します。

信頼性の目標に関連付けるために、ダッシュボードを可視化する適切な方法を選択することが難しい場合があります。以下の両方を表示するダッシュボードを作成します。

短期的分析とリアルタイム分析
長期的分析

ビジュアル管理の実装の詳細については、機能に関する記事のビジュアル管理をご覧ください。

重要なアプリケーションのロギングを有効にする

ロギングサービスはシステムのモニタリングに不可欠です。指標はモニタリングする特定の項目の基礎となりますが、ログにはデバッグ、セキュリティ関連の分析、コンプライアンス要件に必要な、重要な情報が含まれます。

システムが生成したデータをログに記録することで、効果的なセキュリティ体制を実現できます。ロギングとセキュリティの詳細については、アーキテクチャフレームワークのセキュリティカテゴリにあるロギングと検出制御の実装をご覧ください。

Cloud Logging は、ログデータとイベントの保存、検索、分析、モニタリング、アラートに使用できる統合ロギングサービスです。Logging は、Google Cloud やその他のクラウドプロバイダのサービスからログを自動的に収集します。これらのログを使用して、モニタリング用の指標を作成し、Cloud Storage、BigQuery、Pub/Sub などの外部サービスにログをエクスポートできます。

監査証跡を設定する

Google Cloud プロジェクトで「誰がいつどこで何をしたか」を調べるには、Cloud Audit Logs を使用します。

Cloud Audit Logs には、次のような数種類のアクティビティがキャプチャされます。

管理アクティビティログには、リソースの構成またはメタデータを変更する API 呼び出しなどの管理操作に関するログエントリが含まれます。管理アクティビティログは常に有効です。
データアクセス監査ログには、ユーザー提供データを作成、変更、または読み込む API 呼び出しが記録されます。データアクセス監査ログは、非常に大きくなる可能性があるため、デフォルトでは無効になっていますが、データアクセスログを生成する Google Cloud サービスを構成できます。

監査ログを書き込む Google Cloud サービスの一覧については、監査ログ付きの Google サービスをご覧ください。Identity and Access Management（IAM）コントロールを使用して、監査ログにアクセスできるユーザーを制限します。

次のステップ

クラウドサポートとエスカレーションのプロセスを確立する（このシリーズの次のドキュメント）。
Google Cloud のオペレーションスイートの詳細を見る。
Cloud Monitoring をデプロイして、アプリケーションとインフラストラクチャのパフォーマンス、可用性、健全性を可視化する。
モニタリングとオブザーバビリティの詳細を確認する。
アーキテクチャフレームワークの他のカテゴリ（システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化）を確認する。

クラウドサポートプロセスとエスカレーションプロセスを確立する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、効果的なエスカレーションプロセスを定義する方法について説明します。エスカレーション管理を効果的に行うには、クラウドプロバイダやその他のサードパーティのサービスプロバイダからのサポートを確立することが重要です。

Google Cloud には、ライブサポートや、デベロッパーコミュニティ、プロダクトドキュメントなどの公開ガイダンスを通じたサポートをはじめとして、多様なサポートチャネルが用意されています。Cloud カスタマーケアが提供するサービスを利用することで、Google Cloud と連携してワークロードを効率的に実行できます。

プロバイダからのサポートを確立する

クラウドプロバイダまたは他のサードパーティのサービスプロバイダからサポート契約を購入します。運用上のさまざまな問題に迅速に対応して解決するには、サポートが不可欠です。

Google Cloud カスタマーケアを利用する場合は、Standard、Enhanced、または Premium のサポートを含むカスタマーケアサービスの購入を検討してください。主要な本番環境では、Enhanced サポートまたは Premium サポートの使用を検討してください。

エスカレーションプロセスを定義する

適切に定義されたエスカレーションプロセスは、システムの問題を特定、対処するための労力と時間を削減するための鍵となります。これには、Google Cloud プロダクト、または他のクラウドプロデューサーやサードパーティサービスのサポートが必要な問題が含まれます。

エスカレーションパスを作成するには:

問題を組織内でエスカレーションするタイミングと方法を定義します。
クラウドプロバイダまたは他のサードパーティサービスプロバイダでサポートケースを作成するタイミングと方法を定義します。
サポートを提供するチームとの連携方法について確認します。Google Cloud の場合は、お客様とその運用チームがカスタマーケアの使用に関するベストプラクティスを確認する必要があります。これらのプラクティスをエスカレーションパスに組み込みます。
アーキテクチャを説明するドキュメントを検索または作成します。これらのドキュメントに、サポートエンジニアに役立つ情報を記載するようにしてください。
停止中にチームがどのようにコミュニケーションするかを定義します。
サポートが必要なユーザーが、Google Cloud サポートセンターにアクセスしたり、他のサポートプロバイダと通信したりするために、適切なレベルのサポート権限を持っていることを確認します。Google Cloud サポートセンターの使用方法については、サポートの手順をご覧ください。
問題の発生時に必要な情報を取得できるように、モニタリング、アラート、ロギングを設定します。
インシデント報告のテンプレートを作成します。インシデントレポートに含める情報については、カスタマーケアの使用に関するベストプラクティスをご覧ください。
組織のエスカレーションプロセスを文書化します。エスカレーションに対処するためのアクションを明確に定義していることを確認してください。
新しいチームメンバーにサポートとのやり取りの方法を説明するための計画を含めます。

エスカレーションプロセスを内部で定期的にテストします。移行、新しいプロダクトのリリース、ピークトラフィックイベントなどの主要なイベントの前に、エスカレーションプロセスをテストします。Google Cloud カスタマーケアのプレミアムサポートをお持ちの場合は、テクニカルアカウントマネージャーがエスカレーションプロセスを確認して Google Cloud カスタマーケアとテストを調整できます。

サポートからの連絡を確実に受け取る

管理者は、クラウドプロバイダおよびサードパーティのサービスからの連絡を確実に受け取れるようにする必要があります。管理者はこの情報を利用して、大きな問題が発生する前に情報に基づいた意思決定を行い、問題を修正できます。次の条件を満たしていることを確認します。

セキュリティ、ネットワーク、システムの管理者が、Google Cloud や他のプロバイダやサービスから重要なメールを受信するように設定されている。
セキュリティ、ネットワーク、システムの管理者が、Cloud Monitoring などのモニタリングツールで生成されたシステムアラートを受信するように設定されている。
プロジェクトオーナーが、重要なメールを受信できるように、メールルーティングが可能なユーザー名を持っている。

Google Cloud からの通知の管理については、通知の連絡先の管理をご覧ください。

レビュープロセスを確立する

レビューまたは事後検証プロセスを確立します。新しいサポートチケットを提示するか、既存のサポートチケットをエスカレーションした後、以下のプロセスに従います。事後検証の一環として、得られた知見を文書化し、緩和策を追跡します。このような事後調査を行うことで、過失を責めない事後検証の文化が育まれます。

事後分析の詳細については、事後分析の文化: 失敗から学ぶをご覧ください。

センターオブエクセレンスを構築する

組織の情報、経験、パターンを wiki、Google サイト、または内部のサイトといった内部の知識ベースにキャプチャすることで、価値を生み出すことができます。Google Cloud では、新しいプロダクトや機能が継続的にロールアウトされています。こうした知識があれば、アプリケーションとサービスに特定の設計を選択した理由を追跡できます。詳細については、アーキテクチャ決定レコードをご覧ください。

組織内の Google Cloud のエキスパートやチャンピオンを指名することもおすすめします。エキスパートのスキル向上に役立つさまざまなトレーニングと認定資格が用意されています。Google Cloud のブログを購読すると、常に最新のニュース、お知らせ、お客様の事例を確認できます。

次のステップ

容量と割り当てを管理する（このシリーズの次のドキュメント）
アーキテクチャフレームワークの他のカテゴリ（システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化）を確認する。

容量と割り当てを管理する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、クラウドの容量と割り当てを評価して計画する方法について説明します。

従来のデータセンターでは、通常、四半期ごとに、現在のリソース要件を検討し、将来のリソース要件を予測します。物理関連、ロジスティクス関連、人材関連の問題を検討する必要があります。ラックスペース、冷却、電力、帯域幅、ケーブル配線、調達時間、出荷時間、新しい機器の設置に使用できるエンジニアの数などに関する懸念事項を検討する必要があります。また、容量とワークロードの分散を積極的に管理して、Hadoop パイプラインなど、リソースを大量に使用するジョブにより、高可用の必要があるウェブサーバーなどのサービスが妨げられないようにする必要があります。

一方、Google Cloud を使用すると、ほとんどのキャパシティプランニングが Google に任せられます。クラウドを使用すると、アイドル状態のリソースを不要時にプロビジョニングして維持する必要がなくなります。たとえば、必要に応じて VM インスタンスを作成、スケールアップ、スケールダウンできます。料金は使用した分だけ請求されるため、トラフィックのピーク時にのみ必要となる過剰な容量など、費用を最適化できます。Compute Engine では、使用率の低い VM インスタンスがあり、そのサイズ変更や削除が可能であることが検出された場合に、節約のために推奨マシンタイプを提示します。

クラウドの容量に関する要件を評価する

容量を効果的に管理するには、組織の容量に関する要件を把握する必要があります。

容量の要件を評価するには、まず上位のクラウドワークロードを特定します。これらのワークロードの平均使用率とピーク時使用率、現在と将来の容量のニーズを評価します。

これらの上位ワークロードを使用するチームを特定します。それらのチームと協力して、社内の需要計画プロセスを確立します。このプロセスを使用して、現在のクラウドリソースと予想されるクラウドリソースのニーズを把握します。

負荷パターンと呼び出しの分布を分析します。分析では、過去 30 日間のピーク、1 時間あたりのピーク、1 分あたりのピークなどの要素を使用します。

Cloud Monitoring を使用して、アプリケーションとインフラストラクチャのパフォーマンス、稼働時間、全体的な動作状況を可視化することを検討します。

インフラストラクチャの使用率の指標を表示する

キャパシティプランニングを容易にするために、自組織によるクラウドリソースの使用状況に関する履歴データを収集して保存します。

インフラストラクチャ使用率の指標を可視化します。たとえば、上位のワークロードについては、次の内容を評価します。

平均使用率とピーク時使用率
使用率の急上昇に関するパターン
小売業者にとっての休暇期間など、ビジネス要件に基づく季節的な急増
ピーク時のイベントに備え、潜在的なトラフィックの急増にすばやく対応するために必要なオーバープロビジョニングの量

割り当てと容量の上限に近づいたときに自動的に通知されるように、組織でアラートを設定していることを確認します。

Google のモニタリングツールを使用して、アプリケーションの使用状況と容量に関する分析情報を取得します。たとえば、Monitoring でカスタム指標を定義できます。これらのカスタム指標を使用して、アラートの傾向を定義します。Monitoring の柔軟なダッシュボードと豊富な可視化ツールにより、問題の兆候を発見できます。

キャパシティプランニングのプロセスを作成する

キャパシティプランニングのプロセスを確立し、このプランを文書化します。

このプランを作成するときに、次の操作を行います。

リソースの量が一定であるという前提で、負荷テストを実行し、システムがレイテンシ目標を満たしながら処理できる負荷量を決定します。負荷テストでは、実際のユーザーの本番環境トラフィックプロファイルと一致するリクエストタイプを組み合わせて使用する必要があります。均一またはランダムな組み合わせのオペレーションは使用しないでください。トラフィックプロファイルに使用率の急増を含めます。
容量モデルを作成します。容量モデルは、負荷テストによって決定された、サービス負荷の単位増加ごとに必要な増分リソースを計算するための一連の数式です。
将来のトラフィックを予測し、増加を説明します。Google がトラフィック予測を作成する方法の概要については、将来の負荷の測定をご覧ください。
容量モデルを予測に適用して、将来のリソースのニーズを求めます。
組織に必要なリソースの費用を見積もります。次に、財務部門から予算の承認を取得します。幅広いプロダクトにわたってコストとリスクのトレードオフを選択できるため、このステップは重要な業務です。これらのトレードオフは、ビジネスの優先順位に基づいて、特定の製品の予測ニーズよりも低いまたは高い容量を取得することを意味します。
クラウドプロバイダと協力して、割り当てと予約を使用して、適切な量のリソースを適切なタイミングで取得します。インフラストラクチャチームがキャパシティプランニングに関わり、運用担当者が信頼区間のある容量計画を作成するようにします。
四半期か半期ごとに上記の手順を繰り返します。

リソースの使用量を最適化しながら、キャパシティプランニングを行うプロセスの詳細なガイダンスについては、キャパシティプランニングをご覧ください。

割り当てが容量の要件と一致することを確認する

Google Cloud では、割り当てを使用して、使用できる特定の共有 Google Cloud リソースの量を制限しています。各割り当ては、特定のサービスへの API 呼び出し、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数など、特定のカウント可能なリソースを表します。たとえば、割り当てにより、少数のユーザーやプロジェクトが特定のリージョンやゾーンの CPU コアを占有しないように制限します。

割り当てを確認する際は、次の点を検討してください。

リソースの使用が予期せず制限されないように、プロジェクトの容量要件を事前に計画しておく必要があります。
割り当てと容量は、リージョン全体での障害に対応できるように設定します。
割り当ては、特定リソースの使用量を制限するために使用します。たとえば、1 つのプロジェクトが BigQuery を過剰に使用しないように、BigQuery API の最大の 1 日あたりのクエリ使用量の割り当てを設定できます。
使用量の急増に備えて計画を立て、これらの急増を割り当て計画の一部として含めます。使用量の急増は、1 日を通して予想される変動、予期しないピークトラフィックになるイベント、既知のピークトラフィックとリリースイベントなどがあります。ピークトラフィックとリリースイベントを計画する方法については、オペレーションエクセレンスの次のセクションのピークトラフィックとリリースイベントを計画するをご覧ください。

現在の割り当てが不十分な場合は、Google Cloud コンソールを使用して割り当てを管理できます。大容量が必要な場合は、Google Cloud のセールスチームにお問い合わせください。ただし、多くのサービスには、割り当てシステムとは無関係の制限も存在します。詳細については、割り当ての操作をご覧ください。

割り当てを定期的に確認してください。必要になる前に割り当てリクエストを送信してください。割り当てリクエストの評価方法とリクエストの承認または拒否方法については、割り当ての操作をご覧ください。

Google Cloud の割り当てを表示して管理するには、いくつかの方法があります。

Google Cloud コンソールの使用
Google Cloud CLI の使用
Service Usage API の使用
Monitoring を使用して割り当て指標を表示する
組織やフォルダ内の多数の Google Cloud プロジェクトの割り当てを管理するには、割り当てモニタリングダッシュボードソリューションの実装を検討してください。

次のステップ

ピークトラフィックとリリースイベントを計画する（このシリーズの次のドキュメント）
アーキテクチャフレームワークの他のカテゴリ（システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化）を確認する。

ピークトラフィックとリリースイベントを計画する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、ビジネスの中断を避けるために、ピークトラフィックとリリースイベントを計画する方法を説明します。

ピークイベントは、アプリケーションの標準ベースラインを超えてトラフィックの急増を引き起こす、ビジネス関連の主要なイベントです。これらのピークイベントには、計画的なスケーリングが必要です。

たとえば、オンラインプレゼンスを持つ小売業は、休日中にピークイベントを期待できます。米国では感謝祭の翌日に発生するブラックフライデーは、1 年のうちでショッピングが最も多忙になる日の一つです。米国の医療業界の場合、10 月と 11 月は、医療給付目的でオンライントラフィックが急増するため、ピークイベントが発生する可能性があります。

リリースイベントとは、本番環境での新機能の大規模なロールアウトまたは移行です。たとえば、オンプレミスからクラウドへの移行や、新しいプロダクトサービスまたは機能のリリースなどです。

新しいプロダクトをリリースする場合、発表中およびその後に、システムの負荷が増加することが見込まれます。こうしたイベントが発生すると、多くの場合、フロントエンドシステムで負荷が 5～20 倍（またはそれ以上）増加します。負荷の増加によりバックエンドシステムの負荷も増加します。多くの場合、フロントエンドとバックエンドの負荷は、ウェブトラフィックに対してイベントが開始されるため、短期間で急激にスケーリングされるのが特徴です。リリースイベント後は、トラフィックが通常の水準まで減少します。通常、減少の速度はピークに達するときの速度よりも遅い。

ピークイベントとリリースイベントには次の 3 つのステージがあります。

リリースまたはピーク時のトラフィックイベントの計画と準備
イベントのリリース
イベントパフォーマンスの確認とイベント後分析

このドキュメントで説明するプラクティスは、これらの各ステージをスムーズに行うために役立ちます。

リリースイベントとピークイベントに関する一般的なハンドブックを作成する

現在と将来のピークイベントの長期的な視点を含む一般的なハンドブックを作成します。学習した内容をドキュメントに継続的に追加するため、その内容が今後のピークイベントを基準となります。

リリースイベントとピークイベントに向けて計画する

事前に計画を立てます。次回のリリース、および予想される（および想定外の）ピークイベントに関するビジネス予測を作成します。システムがスケールの急増に備えることができるかどうかは、ビジネス予測の理解度によって変わります。以前の予測をより詳しく知ることができれば、新しいビジネス予測はより正確なものとなります。これらの新しい予測は、システムに対する需要の予測を行うための重要な入力情報となります。

組織全体で、またサードパーティベンダーと協力して、プログラム管理と調整された計画を確立することも成功の鍵となります。これらのチームを早期に設定することで、プログラム管理チームはタイムラインを設定して予算を確保し、インフラストラクチャの追加、テストのサポート、トレーニングに向けてリソースを収集できるようになります。

明確なコミュニケーションチャネルを設定することが重要です。コミュニケーションは、リリースイベントまたはピークイベントのどのステージにも不可欠です。リスクや懸念事項を早期に話し合い、問題が深刻化する前に全員で取り組みます。イベント計画のドキュメントを作成します。ピークイベントに関する最も重要な情報を要約して配布します。これにより、計画に関する情報が広く理解され、基本的な疑問を解決できます。この文書があれば、新しく参加した人でもピークイベントの計画をすぐに理解できます。

イベントごとに計画を文書化します。計画を文書化する際は、次のことを行ってください。

前提条件、リスク、不明な要因を特定する。
過去のイベントを確認して、次回のリリースイベントやピークイベントに関連する情報を特定します。どのデータが使用可能であるか、そのデータが過去にどのような価値をもたらしたかを判断します。
リリースイベントと移行イベントのロールバック計画の詳細を作成します。
アーキテクチャレビューを実施します。
- 主要なリソースとアーキテクチャコンポーネントを文書化します。
- アーキテクチャフレームワークを使用して、環境のあらゆる側面について、リスクとスケールに関する懸念事項を確認します。
- アーキテクチャの主要コンポーネントの接続方法を示す図を作成します。図を確認すると、問題を切り分けて迅速に解決できます。
必要に応じて、障害発生時にアラートアクションを使用して自動的に再起動するようにサービスを構成します。Compute Engine を使用する場合は、スループットの急増を処理するために自動スケーリングを使用することを検討してください。
必要なときに Compute Engine リソースを確実に使用できるようにするには、予約を使用します。予約を使用すると、Compute Engine ゾーンリソースのキャパシティを確実に確保できます。プロジェクトで利用可能なリソースの確保にも予約を使用できます。
追跡する指標とアラートを特定します。
- イベントをモニタリングするためのビジネス指標とシステム指標を特定します。指標またはサービスレベル指標（SLI）が収集されていない場合は、システムを変更してこのデータを収集します。
- 十分なモニタリング機能とアラート機能があり、通常のトラフィックパターンと以前のピークトラフィックパターンを確認します。アラートが適切に設定されていることを確認します。Google Cloud Monitoring ツールを使用して、アプリケーションの使用状況、容量、アプリケーションやインフラストラクチャの全体的な健全性を確認できます。
- モニタリングとアラートの関心レベルに応じてシステム指標がキャプチャされるようにします。
増加した容量の要件を Google Cloud アカウントチームとともに確認し、必要な割り当て管理を計画します。詳細については、割り当てが容量の要件を満たしていることを確認するをご覧ください。
適切なクラウドサポートレベルがあること、チームがサポートケースを開く方法を理解していること、エスカレーションパスが確立されていることを確認します。詳しくは、クラウドサポートプロセスとエスカレーションプロセスを確立するをご覧ください。
コミュニケーション計画、タイムライン、責任を定義します。
- 複数の職能にまたがる関係者と連携し、コミュニケーションとプログラムの計画を調整します。これらの関係者には、技術チーム、運用チーム、リーダーチーム、サードパーティベンダーの適切な関係者が含まれます。
- 重要なタスクとそのタスクを所有するチームを含む明確なタイムラインを作成します。
- チーム、チームリーダー、関係者、責任者の所有権を伝えるために、責任分担表（RACI）を確立します。
- 計画されたピークイベントには、プレミアムサポートのイベント管理サービスを使用できます。このサービスでは、カスタマーケアがお客様のチームと連携し、プランを作成して、イベント全体にわたるガイダンスを提供します。

レビュープロセスを確立する

ピーク時のトラフィックイベントやリリースイベントが終了したら、イベントを確認して、学習した内容を文書化します。その後、これらの内容でハンドブックを更新します。最後に、学習した内容を次の主要なイベントに応用します。以前のイベントから学ぶことは重要です。負荷の大きい状況下でシステムの制約が明らかな場合には特に重要となります。

ピーク時のトラフィックイベントやリリースイベントに関する事後調査（事後分析とも呼ばれます）は、データを収集し、発生したインシデントを理解するうえで役立つ手法です。ピーク時のトラフィックとリリースイベントのうち想定どおりのものや、問題が発生したインシデントについて事後調査を行ってください。このような事後調査を行うことで、過失を責めない文化が育まれます。

事後分析の詳細については、事後分析の文化: 失敗から学ぶをご覧ください。

次のステップ

自動化の文化を構築する（このシリーズの次のドキュメント）
アーキテクチャフレームワークの他のカテゴリ（システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化）を確認する。

自動化の文化を創る

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、トイルを評価し、システムとチームへの影響を軽減する方法について説明しています。

トイルは手動で、繰り返し作業には永続的価値はなく、サービスの拡大に伴い増加します。継続的にトイルの削減、排除を行います。そうしなければ、最終的にオペレーターの作業負担が大きくなり、プロダクトの使用や複雑さの増加によってスタッフを追加で割り当てる必要が生じる可能性があります。

自動化はトイルを最小限に抑えるための重要な方法です。また、自動化により、リリースのスピードが上がり、人的ミスを最小化できます。

詳しくは、卜イルの排除をご覧ください。

インベントリを作成して作業費用を評価する

最初にインベントリを作成し、システムを管理するチームのトイルのコストを評価します。これを継続的なプロセスにして、Google Cloud サービスとパートナーによってすでに提供されていることを拡張するためにカスタマイズされた自動化に投資します。多くの場合、Google Cloud の自動化（Compute Engine のオートスケーラーなど）を変更できます。

作業負担の排除を優先する

自動化は有用ですが、運用上の問題すべての解決策にはなりません。既知のトイルへの最初のステップとして、既存のトイルの項目を確認し、可能な限りトイルの削減を優先することをおすすめします。そうすることで、自動化に集中できます。

必要な作業を自動化する

システムの一部の卜イルは排除できません。既知の卜イルに対処するための 2 番目のステップとして、構成可能な自動化を通じて Google Cloud が提供するソリューションを使用して、この卜イルを自動化します。

以下は、構成可能な自動化またはカスタマイズされた自動化が、組織の卜イルの排除に役立つ領域です。

ID 管理（Cloud Identity や Identity and Access Management など）。
自己設計ソリューションとは異なり、Google Cloud がホストするソリューション。Google Kubernetes Engine（GKE）、リレーショナルデータベースの管理（Cloud SQL）、データウェアハウス管理（BigQuery）、API 管理（Apigee）など。
Google Cloud サービスとテナントのプロビジョニング（Terraform や Cloud Foundation Toolkit など）。
マルチステップオペレーションの自動ワークフローオーケストレーション（Cloud Composer など）。
複数の Google Cloud プロダクト（Compute Engine や GKE）など、追加の容量プロビジョニングにより、構成可能な自動スケーリングを実現できます。使用している Google Cloud サービスに、構成可能な自動スケーリングが含まれているかどうかを見極めます。
自動デプロイを備えた CI / CD パイプライン（Cloud Build など）。
デプロイを検証するためのカナリア分析。
（機械学習用の）自動モデルトレーニング（AutoML など）。

手動ワークフローを自動化または排除する際に、Google Cloud プロダクトやサービスが技術的なニーズを部分的に満たすだけの場合は、Google Cloud アカウント担当者に機能リクエストを提出することを検討してください。この問題は、他のお客様の優先事項である可能性もあり、すでに Google のロードマップの一部となっている場合もあります。そのような場合、機能の優先度とタイムラインを知ることで、独自のソリューションを構築することと、Google Cloud 機能として使用できるようになるのを待つことのトレードオフをより正確に評価できるようになります。

コストの高い作業向けのソリューションを構築または購入する

3 番目のステップとして、まだトイルのコストが高い場合（たとえば、本番環境システムを管理するチームのかなりの時間がかかる場合など）に、他のソリューションの構築または購入を評価します。このステップは、1 番目と 2 番目のステップと並行して行えます。

ソリューションを構築または購入する際は、統合、セキュリティ、プライバシー、コンプライアンスの費用を考慮してください。独自の自動化を設計して実装することは、初期の開発および設定コストを超えた、メンテナンス費用と信頼性のリスクが伴うため、このオプションは最後の手段として検討してください。

次のステップ

アーキテクチャフレームワークの他のカテゴリ（システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化）を確認する。

Google Cloud アーキテクチャフレームワーク: セキュリティ、プライバシー、コンプライアンス

Google Cloud アーキテクチャフレームワークのこのカテゴリでは、Google Cloud で安全なサービスを設計して運用する方法について説明します。また、セキュリティとコンプライアンスをサポートする Google Cloud プロダクトと機能についても説明します。

アーキテクチャフレームワークでは、ベストプラクティスを記載して、実装上の推奨事項を紹介し、利用可能ないくつかのプロダクトやサービスについて説明します。このフレームワークは、実際のビジネスニーズに合わせて Google Cloud のデプロイを設計できるようにすることを目的としています。

ワークロードを Google Cloud に移行するには、ビジネス要件、リスク、コンプライアンス義務、セキュリティ管理を評価する必要があります。このドキュメントは、Google Cloud での安全なソリューションの設計に関連する主要なベストプラクティスを検討する際に役立ちます。

Google のコア原則には、デフォルトで大規模な多層防御が含まれています。Google Cloud では、データとシステムは、IAM、暗号化、ネットワーキング、検出、ロギング、モニタリングで構成されるポリシーと制御により、多層防御で保護されています。

Google Cloud には、次のような多くのセキュリティ制御が構築されています。

転送中のデータの保護オプションと、保存データのデフォルトの暗号化。
Google Cloud のプロダクトとサービスの組み込みのセキュリティ機能。
地理冗長向けに設計されたグローバルインフラストラクチャ。情報処理ライフサイクル全体を通してセキュリティ制御を行います。
Infrastructure as Code（IaC）と構成ガードレールを使用する自動化機能。

Google Cloud のセキュリティ対策の詳細については、Google のセキュリティに関する文書と Google インフラストラクチャのセキュリティ設計の概要をご覧ください。デフォルトでセキュリティが確保される環境の例については、Google Cloud エンタープライズ基盤のブループリントをご覧ください。

アーキテクチャフレームワークのセキュリティカテゴリで、次の方法を学習します。

Google Cloud における責任の共有と運命の共有

このドキュメントでは、Google Cloud の責任共有モデルと運命の共有について扱います。責任共有モデルの課題および微妙な違いについて取り上げ、運命の共有とは何か、クラウドのセキュリティ課題に対処するために Google がどのようにお客様と連携するかについて説明します。

Google Cloud 上のデータとワークロードの最適な保護方法を判断するうえで、責任共有モデルの理解は不可欠です。責任共有モデルは、クラウド内のセキュリティに関して利用者が担うべきタスクと、クラウドプロバイダ側で行うべきタスクとの違いを表しています。

しかし、責任の共有を理解するのは容易ではありません。このモデルでは、使用する各サービス、各サービスが提供する構成オプション、サービスを保護するために Google Cloud が何をするかについて深く理解する必要があります。すべてのサービスに異なる構成プロファイルがあるため、最適なセキュリティ構成を決定するのは容易ではありません。Google では、クラウドのお客様がより優れたセキュリティを得られるように支援するだけでは、責任共有モデルは成立しないと考えています。責任を単に共有するだけではなく、運命の共有も必要だと考えています。

運命の共有には、ワークロード用の信頼できるクラウドプラットフォームの構築と運用が含まれます。Google では、安全な方法でワークロードをデプロイするために使用できるベストプラクティスのガイダンスと安全で実証済みのインフラストラクチャコードを提供しています。さまざまな Google Cloud サービスを組み合わせて、複雑なセキュリティ問題を解決するソリューションをリリースし、お客様が受け入れなければならないリスクを測定して軽減できるように革新的な保険オプションを提供しています。お客様が Google Cloud でお客様のリソースを保護していくために、より緊密に協力していくことが必要になります。

責任の共有

お客様は、ビジネスのセキュリティと規制の要件、そして機密データやリソースを保護する要件を把握するエキスパートです。Google Cloud でワークロードを実行する場合、機密データと各ワークロードを保護するために、Google Cloud で構成する必要のあるセキュリティコントロールを特定する必要があります。実装するセキュリティコントロールを決定するには、次の要素を考慮する必要があります。

法令遵守義務
組織のセキュリティ基準とリスク管理計画
お客様とベンダーのセキュリティ要件

ワークロードによる定義

これまで、責任は、実行するワークロードの種類と必要なクラウドサービスに基づいて定義されてきました。クラウドサービスには次のカテゴリがあります。

クラウドサービス	説明
Infrastructure as a Service（IaaS）	IaaS サービスには、Compute Engine、Cloud Storage のほかに、Cloud VPN、Cloud Load Balancing、Cloud DNS などのネットワークサービスが含まれます。 IaaS は従量課金制で、コンピューティング、ストレージ、ネットワークサービスをオンデマンドで提供します。IaaS は、リフト＆シフトで既存のオンプレミスワークロードをクラウドに移行する場合、または特定のデータベースまたはネットワーク構成を使用してアプリケーションを特定の VM 上で実行する場合に利用されます。 IaaS では、セキュリティ責任の大部分をお客様が負い、Google の責任は、主に基盤となるインフラストラクチャと物理的なセキュリティになります。
Platform as a Service（PaaS）	PaaS サービスには、App Engine、Google Kubernetes Engine（GKE）、BigQuery が含まれます。 PaaS は、アプリケーションの開発と実行に使用できるランタイム環境を提供します。PaaS は、アプリケーション（ウェブサイトなど）を構築していて、基盤となるインフラストラクチャではなく開発に集中したい場合に利用されます。 PaaS では、Google はネットワーク制御など、制御の責任を IaaS よりも多く負っています。お客様はアプリケーションレベルの制御と IAM の管理の責任を Google と共有します。データセキュリティとクライアント保護については、お客様が引き続き責任を負います。
Software as a Service（SaaS）	SaaS アプリケーションには、Google Workspace、Chronicle、Google Cloud Marketplace で入手できるサードパーティの SaaS アプリケーションが含まれます。 SaaS は、サブスクリプションできるか、なんらかの方法で決済が可能なオンラインアプリケーションを提供します。SaaS アプリケーションは、社内にアプリケーションを構築するための部門やビジネス要件を持たないものの、ワークロードを処理する能力が必要な場合に利用されます。 SaaS では、セキュリティの責任の大部分が Google にあります。アクセス制御とアプリケーションに保存するデータについては、引き続きお客様の責任となります。
Function as a Service（FaaS）またはサーバーレス	FaaS は、デベロッパーが特定のイベントに応答して実行される小規模な単一目的のコード（関数と呼ばれる）を実行するためのプラットフォームを提供します。FaaS は、特定のイベントに基づいて特定の処理を行う場合に利用されます。たとえば、データを Cloud Storage にアップロードするたびに実行され、データを分類する関数を作成する場合などに利用します。 FaaS には、SaaS と同様の責任共有リストがあります。Cloud Functions は FaaS アプリケーションです。

次の図は、クラウドサービスに対してクラウドプロバイダとお客様がどのように責任を共有するのかを示しています。

セキュリティの責任の共有

図が示すように、基盤となるネットワークとインフラストラクチャについてはクラウドプロバイダが常に責任を負います。お客様はアクセスポリシーとデータについて常に責任を負います。

業界と規制のフレームワークによる定義

さまざまな業界で規制のフレームワークが定められており、導入しなければならないセキュリティコントロールが定義されています。ワークロードをクラウドに移行する場合は、次のことを理解する必要があります。

ユーザー側で責任を負うべきセキュリティコントロール
クラウドサービスの一部として利用できるセキュリティコントロール
継承されるデフォルトのセキュリティコントロール

継承されたセキュリティコントロール（デフォルトの暗号化やインフラストラクチャ制御など）は、セキュリティ対策のエビデンスの一部として監査担当者や規制当局に提供できるコントロールです。たとえば、Payment Card Industry Data Security Standard（PCI DSS）では、決済代行業者の規制が定義されています。ビジネスをクラウドに移行すると、これらの規制がお客様と CSP の間で共有されます。PCI DSS の責任を Google Cloud と共有する方法については、Google Cloud: PCI DSS の共有責任マトリックスをご覧ください。

別の例として、米国では、医療保険の相互運用性と説明責任に関する法律（HIPAA）によって、電子個人健康情報（PHI）を処理するための標準が定められています。これらの責任も CSP とお客様の間で共有されます。HIPAA に基づく Google の責任を Google Cloud でどのように果たされているか、詳細は HIPAA - コンプライアンスをご覧ください。

他の業界（金融や製造など）にも、データの収集、処理、保存の方法に対する規制があります。これらに関連する責任の共有の詳細と、Google Cloud で Google の責任がどのように果たされているかについては、コンプライアンスリソースセンターをご覧ください。

場所による定義

ビジネス事例によっては、オフィス、顧客、データの所在地に応じて責任を考慮する必要があります。それぞれの国と地域では、お客様のデータの処理と保存の方法に対する規制が定められています。たとえば、EU に拠点を置く顧客に対するビジネスの場合、一般データ保護規則（GDPR）に記載されている要件を遵守する必要があります。また、顧客データを EU 域内に留めなければならない場合もあります。そのような状況では、収集したデータを EU 内の Google Cloud リージョン内に保持する責任があります。Google による GDPR 義務の遂行については、GDPR と Google Cloud をご覧ください。

リージョンに関連する要件については、コンプライアンスの提供をご覧ください。特に複雑なシナリオの場合は、セールスチームまたはパートナーに連絡して、セキュリティ責任の評価を受けることをおすすめします。

責任の共有での課題

責任共有は、ユーザーとクラウドプロバイダが担うセキュリティのロールを定義するのに役立ちますが、責任共有への依存には課題が生じる可能性があります。次のようなシナリオを考えてみましょう。

クラウドセキュリティ侵害のほとんどは構成ミスが原因で発生しています（Cloud Security Alliance の Pandemic 11 レポートでは 3 番目に多い原因と報告されています）。この傾向は今後さらに増加することが予想されます。クラウドプロダクトは絶えず変化しており、新しいプロダクトが常にリリースされています。絶え間ない変化に対応するのは大変な作業のように思えます。利用者には、デフォルトのベストプラクティスと、ベースラインとなる安全な構成を用意し、変化に対応できる独自のベストプラクティスを提供するクラウドプロバイダが必要です。
クラウドサービスで項目を分割することは便利ですが、企業の多くには、複数の種類のクラウドサービスを必要とするワークロードがあります。このような状況では、サービス間でさまざまなセキュリティコントロールがどのように影響しあうのかを検討しなければなりません（たとえば、サービス間で重複するかどうかなど）。Google Workspace を会社のメールシステムとして利用し、製品の品質向上のため BigQuery でデータを分析しているときに、オンプレミスアプリケーションを Compute Engine に移行するケースもあります。
ビジネスと市場は、規制の変化、新規市場への参入、他の企業の買収に伴い常に変化しています。新しい市場には異なる要件があり、新しく買収した企業は別のクラウドにワークロードをホストしているかもしれません。絶え間ない変更を管理するには、リスクプロファイルを継続的に再評価し、新しいコントロールを迅速に実装できるようにする必要があります。
データ暗号鍵をどこで、どのように管理するかは、データを保護する責任と結びついた重要な判断となります。選択するオプションは、ハイブリッドクラウド環境を実行しているのか、あるいはオンプレミス環境にあるのか、さらに処理、保存するデータの機密性に応じた規制要件によって変わります。
インシデント管理は、お客様の責任とクラウドプロバイダの責任を簡単に定義できない領域であり、重要ですが見落とされがちです。多くのインシデントでは、インシデントの調査と軽減のためにクラウドプロバイダとの緊密な協力とサポートが必要になります。クラウドリソースの構成ミスや認証情報の盗難によって発生するインシデントもあり、リソースとアカウントを保護するためのベストプラクティスを確実に実施することは容易ではありません。
高度な持続的脅威（APT）と新たな脆弱性により、クラウドトランスフォーメーションの開始時には想定していなかった影響がワークロードに生じる可能性があります。特に、組織に大規模なセキュリティチームがない場合は、変化する状況に応じて常に最新の状態に保ち、脅威軽減の責任者を確保することは至難の業です。

運命の共有

Google は、共有責任モデルで対応できない課題に対処するために、Google Cloud に運命の共有という考えを導入しました。運命の共有は、すべての関係者が継続的に協力してセキュリティを向上させる方法に重点を置いています。運命の共有は責任共有モデルの上に構築されるもので、クラウドプロバイダとお客様の関係を継続的なパートナーシップとして捉え、セキュリティを向上させることを目指しています。

運命の共有とは、お客様と Google が Google Cloud の安全性を高めるために責任を持つことです。運命の共有には、安全なランディングゾーンの構築の支援だけでなく、推奨されるセキュリティコントロール、設定、関連するベストプラクティスに対して明確さ、独自性、透明性を持たせることも含まれます。また、Google の Risk Protection Program を使用したサイバー保険でリスクを定量化し、管理することも含まれます。Google は運命の共有を使用して、標準的な責任共有フレームワークを進化させ、ビジネスを保護しながら Google Cloud での信頼関係を構築できる、より優れたモデルに発展させたいと考えています。

以下のセクションでは、運命の共有におけるさまざまなコンポーネントについて説明します。

サポート

運命の共有の主要なコンポーネントは、Google Cloud の安全な構成を利用するためのリソースです。安全な構成から始めることで、ほとんどのセキュリティ侵害の根本原因である構成ミスの問題を削減できます。

Google では、次のリソースを用意しています。

エンタープライズ基盤のブループリント。セキュリティ上の主な懸念事項と推奨事項について説明します。
セキュアなブループリント。Infrastructure as Code（IaC）を使用して安全なソリューションをデプロイし、維持するためのブループリントです。ブループリントでは、セキュリティの推奨事項がデフォルトで有効になっています。多くのブループリントは、Google のセキュリティチームが作成し、プロダクトとして管理しています。このサポートはつまり、ブループリントは定期的に更新され、厳格なテストプロセスを経て、第三者のテストグループから証明書を受け取っているということです。ブループリントにはエンタープライズ基盤のブループリント、安全なデータウェアハウスのブループリント、Vertex AI Workbench ノートブックのブループリントなどがあります。
設計にセキュリティを組み込む際の最善の推奨事項に対応するアーキテクチャフレームワークのベストプラクティス。アーキテクチャフレームワークには、エキスパートや同僚との接点として使用できるセキュリティセクションとコミュニティゾーンが用意されています。
ランディングゾーンのナビゲーションガイドには、リソース階層、ID オンボーディング、セキュリティ、鍵管理、ネットワーク構造など、ワークロードの安全な基盤を構築するために必要な基本的な決定事項が記載されています。

Risk Protection Program

運命の共有には、Risk Protection Program（現在プレビュー版）も含まれています。これはクラウドワークロードを単に管理する必要のあるリスクソースの一つとしてとらえるのではなく、Google Cloud の機能をリスク管理のプラットフォームとして使用できるように支援します。Risk Protection Program は、Google Cloud が大手サイバー保険会社である Munich Re および Allianz Global & Corporate Speciality と共同で開発したプログラムです。

Risk Protection Program には、実施しているクラウドセキュリティ対策をより深く理解するために使用できる、データドリブンな分析情報を提供する Risk Manager が含まれています。サイバー保険のカバレッジが必要な場合は、Risk Manager から得たこれらの分析情報を保険パートナーと直接共有して見積もりを取ることができます。詳細については、プレビュー版の Google Cloud Risk Protection Program をご覧ください。

デプロイとガバナンスに関するサポート

運命の共有は、お客様の環境へのガバナンスの継続にも役立ちます。たとえば、Google では次のようなプロダクトに注力しています。

Assured Workloads: コンプライアンスの遵守に役立ちます。
Security Command Center Premium。脅威インテリジェンス、脅威検出、ウェブスキャン、その他の高度な方法を使用して脅威をモニタリングし、検出します。また、これらの脅威の多くを迅速かつ自動的に解決する方法も提供されます。
組織のポリシーとリソース設定。フォルダとプロジェクトの階層全体でポリシーを構成できます。
Policy Intelligence ツール。アカウントやリソースへのアクセスに関する分析情報を提供します。
Confidential Computing - 使用中のデータを暗号化できます。
Sovereign Cloud。ドイツで利用可能なプロダクトで、データ所在地の要件を実装します。

責任の共有と運命の共有の実践

計画プロセスの一環として、適切なセキュリティコントールを理解して実装するため、次のアクションを検討してください。

Google Cloud でホストするワークロードタイプと、IaaS、PaaS、SaaS サービスが必要かどうかのリストを作成します。責任の共有の図をチェックリストとして使用して、検討が必要なセキュリティコントールを確実に把握します。
遵守する必要のある規制要件のリストを作成し、それらの要件に関連するコンプライアンスリソースセンターのリソースにアクセスします。
アーキテクチャセンターで利用可能なブループリントとアーキテクチャのリストで、特定のワークロードに必要なセキュリティコントロールを確認します。このブループリントは、アーキテクチャのデプロイに必要な推奨コントロールと IaC コードのリストを提供します。
ランディングゾーンのドキュメントとエンタープライズ基盤ガイドの推奨事項を使用して、要件を満たすリソース階層とネットワークアーキテクチャを設計します。安全なデータウェアハウスなど、独自のワークロードブループリントを使用することで、開発プロセスをスムーズに進めることができます。
ワークロードをデプロイしたら、Risk Manager、Assured Workloads、Policy Intelligence ツール、Security Command Center Premium などのサービスを使用して、セキュリティの責任を満たしていることを確認します。

詳細については、CISO のクラウドトランスフォーメーションガイドの文書をご覧ください。

次のステップ

セキュリティ原則（このシリーズの次のドキュメント）を確認する。
運命の共有のリソースを最新の状態に保つ。
セキュリティ基盤のブループリントや、安全なデータウェアハウスなどのワークロードの例など、利用可能なブループリントを理解する。
運命の共有の詳細を確認する。
Google インフラストラクチャのセキュリティ設計の概要で、Google の基盤となる安全なインフラストラクチャを確認する。
Google Cloud における NIST サイバーセキュリティフレームワークのベストプラクティス（PDF）で実装方法を確認する。

セキュリティ原則

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、安全でコンプライアンスに配慮したサービスを Google Cloud で実行するための主要な原則について説明しています。オンプレミス環境でよく知られているセキュリティ原則の多くは、クラウド環境にも適用されます。

階層化されたセキュリティアプローチを構築する

アプリケーションとインフラストラクチャの各レベルでセキュリティを実装し、多層防御を実現します。各プロダクトの機能を使用してアクセスを制限し、必要に応じて暗号化を構成します。

分離された安全なシステムを設計する

可能であれば、柔軟性に対応するためにシステム設計を簡素化し、各コンポーネントのセキュリティ要件を文書化します。復元性と復元を考慮して堅牢なセキュリティメカニズムを組み込みます。

重要なタスクのデプロイを自動化する

デプロイやその他の管理タスクを自動化し、人手による作業をなくします。

セキュリティモニタリングを自動化する

自動化ツールを使用して、アプリケーションとインフラストラクチャをモニタリングします。インフラストラクチャの脆弱性をスキャンしてセキュリティインシデントを検出するには、継続的インテグレーションと継続的デプロイ（CI / CD）パイプラインで自動スキャンを使用します。

リージョンのコンプライアンス要件を満たす

規制要件を満たすには、個人情報（PII）を難読化または秘匿化する必要があるので注意してください。可能であれば、コンプライアンスへの取り組みを自動化します。たとえば、新しいデータをシステムに保存する前に、機密データ保護と Dataflow を使用して PII 秘匿化ジョブを自動化します。

データ所在地と主権の要件を遵守する

内部または外部要件により、データストレージと処理のロケーションを制御する必要があります。これらの要件は、システムの設計目標、業界の規制に関する懸念、国内法、務上の影響、文化によって異なります。データ所在地は、データの保存場所を表します。データ所在地の要件を遵守するため、Google Cloud ではデータの保存場所、アクセス方法、処理方法を制御できます。

セキュリティを左にシフトする

DevOps とデプロイの自動化により、組織は製品提供をスピードアップできます。製品の安全性を維持するため、開発プロセスの最初からセキュリティプロセスを組み込みます。たとえば、次のことを行います。

デプロイパイプラインの早い段階で、コードのセキュリティ問題をテストします。
コンテナイメージとクラウドインフラストラクチャを継続的にスキャンします。
構成ミスとセキュリティアンチパターンの検出を自動化します。たとえば、自動化を使用して、アプリケーションまたは構成にハードコードされたシークレットを探します。

次のステップ

セキュリティに関する基本原則の詳細については、次のリソースをご覧ください。

リスクの制御と管理

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、クラウドのデプロイにおけるリスクを管理するためのベストプラクティスについて説明します。組織に適用されるリスクを慎重に分析することで、必要なセキュリティ管理を決定できます。Google Cloud にワークロードをデプロイする前にリスク分析を完了する必要があります。その後は、ビジネスニーズ、規制要件、組織に関連する脅威に応じて、定期的に分析を行う必要があります。

組織におけるリスクを特定する

Google Cloud でリソースを作成してデプロイする前に、リスク評価を実施して、内部セキュリティ要件と外部の規制要件を満たすために必要なセキュリティ機能を決定します。リスク評価は、関連するリスクのカタログを提供し、組織がセキュリティ上の脅威の検出と対処にどのように役立つかを示します。

クラウド環境におけるリスクは、オンプレミス環境におけるリスクとは異なります。これは、クラウドプロバイダが締結する責任を共有するためです。たとえば、オンプレミス環境ではハードウェアスタックの脆弱性を軽減する必要があります。一方、クラウド環境では、こうしたリスクはクラウドプロバイダが負担します。

また、リスクは Google Cloud の使用方法によって異なります。ワークロードの一部を Google Cloud に移行するのか、それともすべて移行するのかGoogle Cloud を障害復旧目的でのみ使用しているのかハイブリッドクラウド環境を設定しているのか

クラウド環境と規制要件に適用される、業界標準のリスク評価フレームワークを使用することをおすすめします。たとえば、Cloud Security Alliance（CSA）は Cloud Controls Matrix（CCM）を提供します。また、OWASP アプリケーションの脅威モデリングなどの脅威モデルもあります。これにより、潜在的なギャップのリストを提供し、検出されたギャップを修復するためのアクションを提案できます。Google Cloud のリスク評価を実施するエキスパートの一覧については、パートナーディレクトリをご覧ください。

リスクをカタログ化するため、Risk Protection Program の一部である Risk Manager を検討してください（このプログラムは現在プレビュー中です）。Risk Manager はユーザーのワークロードをスキャンし、ビジネスリスクを理解するうえで役立ちます。その詳細レポートはセキュリティのベースラインとなります。また、Risk Manager レポートを使用して、インターネットセキュリティ（CIS）ベンチマークに記載されているリスクとユーザーのリスクを比較できます。

リスクをカタログ化したら、どのようにリスクに対処するか（リスクを受け入れる、回避する、移転する、軽減する）を決定する必要があります。次のセクションでは、緩和策について説明します。

リスクを軽減する

リスクを軽減するには、技術的なコントロール、契約による保護、サードパーティの検証または証明を使用します。次の表は、新しいパブリッククラウドサービスを導入する際に、これらの緩和策を使用する方法を示しています。

緩和策	説明
技術的なコントロール	技術的なコントロール。環境の保護に使用する機能とテクノロジーのことです。これには、ファイアウォールやロギングなどのクラウドセキュリティコントロールが組み込まれています。技術的なコントロールには、セキュリティ戦略を強化またはサポートするサードパーティツールの使用も含まれます。技術的なコントロールには次の 2 つのカテゴリがあります。 Google Cloud には、適用されるリスクを軽減する、さまざまなセキュリティ管理機能が用意されています。たとえば、オンプレミス環境がある場合は、Cloud VPN と Cloud Interconnect を使用してオンプレミスとクラウドリソース間の接続を保護できます。 Google では、堅牢な内部管理と監査を実施して、インサイダーによるアクセスからお客様のデータを保護しています。Google の監査ログにより Google Cloud では、Google 管理者アクセスのログがニアリアルタイムで提供されます。
契約による保護	契約による保護とは、Google Cloud サービスに関して Google が行う法律上のコミットメントのことです。 Google Cloud は、コンプライアンスポートフォリオの維持と拡大に取り組んでいます。Cloud のデータ処理に関する追加条項（CDPA）のドキュメントでは、ISO 27001、27017、27018 の認証の維持と、12 か月ごとの SOC 2 および SOC 3 レポートの更新が定義されています。 DPST ドキュメントでは、Google サポートエンジニアによるお客様の環境へのアクセスを制限するアクセス制御の概要と、厳格なロギングと承認プロセスについても説明しています。 Google Cloud の契約管理について、法的および規制の専門家に相談して、要件を満たしていることを確認することをおすすめします。詳しくは、テクニカルアカウント担当者にお問い合わせください。
第三者による検証または証明	第三者による検証または証明とは、クラウドプロバイダがコンプライアンス要件を満たしていることをサードパーティベンダーに監査してもらうことです。たとえば、Google は ISO 27017 のコンプライアンスについて第三者機関の監査を受けています。現在の Google Cloud 認定資格と証明書は、コンプライアンスリソースセンターでご覧いただけます。

次のステップ

リスク管理の詳細については、次のリソースをご覧ください。

アセットを管理する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、アセット管理のベストプラクティスについて説明します。

アセット管理は、ビジネス要件分析の重要な構成要素です。所有するアセットと、そのすべてに関して、アセットの価値、アセットに関連する重要なパスやプロセスを十分に把握する必要があります。アセットを保護するセキュリティ管理などを設計する際は、事前に正確なアセットインベントリを用意しておく必要があります。

セキュリティインシデントを管理し、組織の規制要件を満たすには、履歴データを分析する方法を含め、正確で最新のアセットインベントリが必要です。リスクエクスポージャーが時間とともにどのように変化するかを含め、アセットを追跡できる必要があります。

Google Cloud への移行は、クラウド環境に合わせてアセット管理プロセスを変更する必要があることを意味します。たとえば、クラウドに移行する利点の 1 つは、迅速にスケールする組織の能力を向上させることです。ただし、迅速にスケールできると、従業員が適切に管理および保護できないクラウドリソースを作成して、シャドー IT の問題を引き起こす可能性があります。したがって、アセット管理プロセスは、従業員が仕事をするのに十分な柔軟性を確保しつつ、適切なセキュリティ管理を提供しなければなりません。

クラウドアセット管理ツールを使用する

Google Cloud のアセット管理ツールは、Google の環境と特にお客様のユースケースに合わせて調整されています。

そうしたツールの一つである Cloud Asset Inventory では、リソースの現在の状態に関するリアルタイム情報と 5 週間の履歴の両方を確認できます。このサービスを使用すると、さまざまな Google Cloud リソースとポリシーについてインベントリの組織全体のスナップショットを取得できます。自動化ツールでは、そのスナップショットをモニタリングやポリシーの適用に使用できます。また、コンプライアンス監査の目的でスナップショットをアーカイブすることも可能です。アセットの変更を分析する場合は、アセットインベントリでメタデータの履歴をエクスポートできます。

Cloud Asset Inventory の詳細については、アセットの変更に対応するカスタムソリューションと検出制御をご覧ください。

アセット管理を自動化する

自動化により、指定したセキュリティ要件に基づいてアセットを迅速に作成および管理できます。アセットのライフサイクルの点では、次の方法で自動化できます。

Terraform などの自動化ツールを使用してクラウドインフラストラクチャをデプロイする。Google Cloud には、エンタープライズ基盤のブループリントが用意されています。これは、セキュリティのベストプラクティスに沿ったインフラストラクチャリソースを設定する際に役立ちます。また、Cloud Asset Inventory では、アセットの変更とポリシーのコンプライアンス通知を構成します。
Cloud Run や Artifact Registry などの自動化ツールを使用してアプリケーションをデプロイする。

コンプライアンスポリシーからの逸脱をモニタリングする

ポリシーからの逸脱は、アセットのライフサイクルのすべてのフェーズで発生する可能性があります。たとえば、アセットが適切なセキュリティ管理なしで作成されることや、特権がエスカレーションされることがあります。同様に、適切な終了手順を踏まずに、アセットが破棄されることがあります。

こうしたシナリオを回避するため、アセットがコンプライアンスから逸脱していないかどうかをモニタリングすることをおすすめします。モニタリングする一連のアセットは、リスク評価の結果とビジネス要件によって異なります。アセットのモニタリングの詳細については、アセットの変更のモニタリングをご覧ください。

既存のアセット管理モニタリングシステムと統合する

SIEM システムなどのモニタリングシステムをすでに使用している場合は、Google Cloud アセットをそのシステムと統合します。統合することにより、組織では、すべてのリソースを環境に関係なく 1 つの包括的なビューで確認できます。詳細については、Google Cloud セキュリティデータを SIEM システムにエクスポートすると、Cloud Logging データのエクスポートシナリオ: Splunk をご覧ください。

データ分析を使用してモニタリングを強化する

インベントリは、BigQuery テーブルや Cloud Storage バケットにエクスポートしてさらに分析することが可能です。

次のステップ

アセット管理の詳細について、次のリソースを確認する。

ID とアクセスを管理する（このシリーズの次のドキュメント）
リソース管理
システム設計

ID とアクセスを管理する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、ID とアクセスを管理するためのベストプラクティスを提供します。

Identity and Access Management（一般に IAM と呼ばれます）を活用すると、適切なユーザーが適切なリソースにアクセスできるようになります。IAM は、認証と認可の次の側面に対処するものです。

プロビジョニングを含むアカウント管理
ID ガバナンス
認証
アクセス制御（認可）
ID 連携

環境が異なる場合や、複数の ID プロバイダを使用している場合は、IAM の管理が難しくなることがあります。ただし、リスクを軽減しながらビジネス要件を満たすシステムをセットアップすることが重要です。

このドキュメントの推奨事項は、現在の IAM のポリシーと手順を確認し、Google Cloud のワークロードで変更する必要があるものを判断するうえで役立ちます。たとえば、次の点を確認する必要があります。

既存のグループを使用してアクセスを管理できるかどうか、または新しいグループを作成する必要があるかどうか。
認証要件（トークンを使用した多要素認証（MFA）など）。
現在のポリシーに対するサービスアカウントの影響。
障害復旧に Google Cloud を使用する場合は、適切な職掌分散を維持します。

Google Cloud では、Cloud Identity を使用してユーザーとリソース、および Google の Identity and Access Management（IAM）プロダクトを認証して、リソースへのアクセスを指定します。管理者は、組織レベル、フォルダレベル、プロジェクトレベル、リソースレベルでアクセスを制限できます。Google IAM ポリシーには、「誰がどのリソースに対して何を行えるか」が規定されます。IAM ポリシーを正しく構成することで、リソースへの不正アクセスを防ぐことができます。

詳細については、Identity and Access Management の概要をご覧ください。

単一の ID プロバイダを使用する

多くのお客様のユーザーアカウントは、Google Cloud 外部の ID プロバイダによって管理、プロビジョニングされています。Google Cloud は、ほとんどの ID プロバイダや、Active Directory などのオンプレミスディレクトリとの連携をサポートしています。

ほとんどの ID プロバイダでは、ユーザーとグループに対してシングルサインオン（SSO）を有効にできます。Google Cloud にデプロイし、外部 ID プロバイダを使用するアプリケーションの場合、ID プロバイダを Google Cloud に拡張できます。詳細については、リファレンスアーキテクチャとハイブリッド環境で企業ユーザーを認証するパターンをご覧ください。

既存の ID プロバイダがない場合は、Cloud Identity Premium または Google Workspace を使用して従業員の ID を管理できます。

特権管理者アカウントを保護する

特権管理者アカウント（Google Workspace または Cloud Identity によって管理）を使用すると、Google Cloud 組織を作成できます。そのため、この管理者アカウントには高い権限が付与されています。このアカウントのベストプラクティスは次のとおりです。

この目的のために新しいアカウントを作成します。既存のユーザーアカウントを使用しないでください。
バックアップアカウントを作成して保護します。
MFA を有効にします。

詳しくは、特権管理者アカウントのベストプラクティスをご覧ください。

サービスアカウントの使用を計画する

サービスアカウントは、アプリケーションがサービスの Google API を呼び出すために使用できる Google アカウントです。

ユーザーアカウントとは異なり、サービスアカウントは Google Cloud 内で作成、管理されます。また、サービスアカウントはユーザーアカウントとは異なる方法で認証されます。

Google Cloud で実行されているアプリケーションがサービスアカウントを使用して認証できるようにするには、アプリケーションが実行されているコンピューティングリソースにサービスアカウントを接続します。
GKE で実行されているアプリケーションがサービスアカウントを使用して認証できるようにするには、Workload Identity を使用します。
Google Cloud の外部で実行されているアプリケーションがサービスアカウントを使用して認証できるようにするには、Workload Identity 連携を使用します。

サービスアカウントを使用する場合は、設計プロセスで適切な職掌分散を考慮する必要があります。必要な API 呼び出しを確認し、サービスアカウントと関連するロールを決定します。たとえば、BigQuery データウェアハウスを設定する場合は、少なくとも次のプロセスとサービスの ID が必要になります。

Cloud Storage または Pub/Sub は、バッチファイルを使用するか、ストリーミングサービスを作成するかによって異なります。
Dataflow とセンシティブデータの保護を使用して機密データを匿名化します。

詳しくは、サービスアカウントの使用に関するベストプラクティスをご覧ください。

クラウドの ID プロセスを更新する

ID ガバナンスを使用すると、アクセス、リスク、ポリシー違反を追跡して、規制要件に対応できます。このガバナンスでは、アクセス制御のロールと権限をユーザーに付与して監査できるように、プロセスとポリシーを導入する必要があります。プロセスとポリシーでは、テスト、開発、本番環境など、環境の要件を反映する必要があります。

Google Cloud にワークロードをデプロイする前に、現在の ID プロセスを確認し、必要に応じて更新します。組織に必要なアカウントの種類について適切に計画し、それらのロールとアクセス権の要件を十分に理解します。

Google Cloud では、Google IAM アクティビティを監査するために、以下を含む監査ログが作成されます。

管理者のアクティビティ。このロギングは無効にできません。
データアクセスアクティビティ。このロギングは有効にする必要があります。

コンプライアンス上必要な場合、または SIEM システムなどのログ分析を設定する場合は、ログをエクスポートできます。ロギングによってストレージ要件が増大する可能性があるため、費用に影響する場合があります。必要な操作のみをロギングし、適切な保持スケジュールを設定します。

SSO と MFA を設定する

ユーザーアカウントの認証は、ご利用の ID プロバイダによって管理されています。フェデレーション ID は、SSO を使用して Google Cloud に対する認証を行うことができます。特権管理者などの特権アカウントの場合は、MFA を構成する必要があります。Titan セキュリティキーは、フィッシング攻撃の防止に役立つ 2 要素認証（2FA）に使用可能な物理的トークンです。

Cloud Identity は、さまざまな方法で MFA をサポートしています。詳細については、会社所有のリソースに均一の MFA を適用するをご覧ください。

Google Cloud は、OAuth 2.0 プロトコルまたは自己署名 JSON ウェブトークン（JWT）を使用したワークロード ID の認証をサポートしています。認証の詳細については、認証の概要をご覧ください。

最小権限と職掌分散を実装する

適切なユーザーが、業務の遂行に必要なリソースとサービスのみにアクセスできるようにする必要があります。つまり、最小権限の原則に沿う必要があります。また、適切な職掌分散が存在することを確認する必要があります。

ユーザーアクセスをオーバープロビジョニングすると、内部の脅威、リソースの構成ミス、監査違反のリスクが高まる可能性があります。権限のアンダープロビジョニングでは、ユーザーが自分のタスクの完了に必要なリソースにアクセスできなくなる可能性があります。

オーバープロビジョニングを回避する方法の一つは、ジャストインタイムの特権アクセス（すなわち特権アクセスは必要な場合にのみ付与し、一時的に付与する）を実装することです。

Google Cloud 組織を作成すると、デフォルトでドメイン内のすべてのユーザーに請求先アカウント作成者とプロジェクト作成者のロールが付与されます。これらの職務を行うユーザーを特定し、他のユーザーからこれらのロールを取り消します。詳しくは、組織の作成と管理をご覧ください。

Google Cloud でのロールと権限の仕組みについては、IAM ドキュメントの概要とロールについてをご覧ください。最小権限の適用の詳細については、ロールの推奨事項を使用して最小権限を適用するをご覧ください。

アクセスを監査する

特権アカウントのアクティビティに対して、承認された条件からの逸脱をモニタリングするには、Cloud Audit Logs を使用します。Cloud Audit Logs は、Google Cloud 組織のメンバーが Google Cloud リソースに行ったアクションを記録します。Google サービス全体で、さまざまな監査ログタイプを操作できます。詳細については、Cloud Audit Logs を使用した内部リスクの管理（動画）をご覧ください。

IAM Recommender を使用して使用状況を追跡し、必要に応じて権限を調整します。IAM Recommender が推奨するロールは、ユーザーの過去の行動やその他の条件に基づいて、ユーザーに付与するロールを決定するために役立ちます。詳細については、ロールの推奨事項のベストプラクティスをご覧ください。

Google のサポート担当者とエンジニアリング担当者によるリソースへのアクセスの監査と制御を行うには、アクセスの透明性を使用します。アクセスの透明性では、Google の担当者による操作が記録されます。アクセスの透明性の一部であるアクセス承認を使用して、お客様のコンテンツにアクセスするたびに明示的な承認を付与します。詳しくは、データへのクラウド管理者のアクセス権を管理するをご覧ください。

ポリシー管理を自動化する

可能な限り、アクセス権をプログラムで設定します。ベストプラクティスについては、組織のポリシーの制約をご覧ください。エンタープライズ基盤ブループリント用の Terraform スクリプトは、サンプル基盤リポジトリにあります。

Google Cloud には、アクセス権限を自動的に確認および更新できる Policy Intelligence が含まれています。Policy Intelligence には、Recommender、Policy Troubleshooter、Policy Analyzer ツールが含まれています。これらは次の処理を行います。

IAM ロールの割り当てに関する最適化案を提供します。
モニタリングにより、過剰な権限を付与する IAM ポリシーの設定を阻止します。
アクセス制御関連の問題のトラブルシューティングを支援します。

リソースに制限を設定する

Google IAM で重要なのは「誰であるか」です。権限に基づいて特定のリソースを操作できるユーザーを承認します。組織ポリシーサービスでは、内容に重点が置かれており、リソースの制限を設定して構成方法を指定できます。たとえば、組織のポリシーを使用して次のことができます。

ドメインに基づいてリソースの共有を制限する。
サービスアカウントの使用を制限する。
新しく作成されるリソースの物理的なロケーションを制限する。

これらのタスクに組織のポリシーを使用するだけでなく、次のいずれかの方法でリソースへのアクセスを制限できます。

タグを使用して、各リソースのアクセス権限を定義することなく、リソースへのアクセスを管理します。代わりに、タグを追加して、タグ自体のアクセス定義を設定します。
IAM Conditions を使用して、リソースへのアクセスを条件付きの属性ベースで制御します。
VPC Service Controls を使用して多層防御を実装し、リソースへのアクセスをさらに制限します。

リソース管理の詳細については、リソース管理をご覧ください。

次のステップ

IAM の詳細については、次のリソースをご覧ください。

コンピューティングとコンテナセキュリティを実装する（このシリーズの次のドキュメント）
IAM の安全な使用
リファレンスアーキテクチャ
IAM Recommender: 手間をかけずに最小権限を実現する
Cloud データのプライバシー
Identity and Access Management の概要

コンピューティングとコンテナのセキュリティを実装する

Google Cloud には、コンピューティングリソースと Google Kubernetes Engine（GKE）コンテナリソースを保護するコントロールがあります。Google Cloud アーキテクチャフレームワークのこのドキュメントでは、主なコントロールと、それらを使用するためのベストプラクティスについて説明しています。

強化されたキュレート済み VM イメージを使用する

Google Cloud には、VM インスタンスを強化できる Shielded VM が含まれています。Shielded VM は、起動サイクル中に悪意のあるコードが読み込まれることを回避するように設計されています。ブートセキュリティを提供して整合性をモニタリングし、Virtual Trusted Platform Module（vTPM）を使用します。機密性の高いワークロードには Shielded VM を使用してください。

Shielded VM に加えて、Google Cloud パートナーソリューションを使用して VM をさらに保護できます。Google Cloud で提供されている多くのパートナーソリューションは、イベント脅威検出とヘルスモニタリングを提供する Security Command Center と統合されます。パートナーを使用して、高度な脅威分析やランタイムセキュリティの強化を行うことができます。

機密データの処理に Confidential Computing を使用します

デフォルトでは、Google Cloud はネットワーク上で保存時と転送時にデータを暗号化しますが、メモリ内で使用中のデータは暗号化されません。組織で機密データを扱う場合は、アプリケーションメモリまたはシステムメモリ内のデータの機密性と整合性を損なう脅威に対処する必要があります。機密データには、個人を特定できる情報（PII）、財務データ、健康情報が含まれます。

Confidential Computing は Shielded VM 上に構築されています。ハードウェアベースで高信頼実行環境で計算を行うことで、使用中のデータを保護します。このような安全で隔離された環境により、データが使用中の間はアプリケーションとデータの不正アクセスや変更を防ぐことができます。信頼性の高い実行環境を提供することで、機密データや規制対象データを管理する組織のセキュリティも向上します。

Google Cloud では、Confidential VMs または Confidential GKE Node を実行することで、Confidential Computing を実現できます。Confidential Computing は、機密のワークロードを処理する場合や、処理中に公開する必要がある機密データ（Secret など）がある場合に有効にします。詳細については、Confidential Computing Consortium をご覧ください。

VM とコンテナを保護する

OS Login を使用すると、従業員は SSH 認証鍵に依存することなく、Identity and Access Management（IAM）権限を信頼できる情報源として使用して VM に接続できます。したがって、組織全体で SSH 認証鍵を管理する必要はありません。OS Login では、管理者による従業員のライフサイクルへのアクセスが関連付けられます。つまり、従業員が別のロールに移動したり、退職した場合、そのユーザーのアクセス権はそのユーザーのアカウントで取り消されます。OS Login は 2 要素認証もサポートしています。これにより、アカウントの乗っ取り攻撃に対するセキュリティを強化できます。

GKE では、App Engine が Docker コンテナ内でアプリケーションインスタンスを実行します。定義済みのリスクプロファイルを有効にして、従業員がコンテナを変更できないようにするには、コンテナがステートレスで不変になるようにします。不変性の原則は、従業員がコンテナを変更したり、コンテナにインタラクティブにアクセスしないことを意味します。変更が必要な場合は、新しいイメージを作成して再デプロイします。特定のデバッグシナリオでのみ、基盤となるコンテナへの SSH アクセスを有効にします。

不要な外部 IP アドレスを無効にする

本番環境の VM で外部 IP アドレスの割り振りを無効にする（動画）と、外部ロードバランサの使用を防ぎ、組織のポリシーを使用できます。VM がインターネットまたはオンプレミスのデータセンターに到達する必要がある場合は、Cloud NAT ゲートウェイを有効にできます。

GKE には限定公開クラスタをデプロイできます。限定公開クラスタでは、ノードに内部 IP アドレスのみがあるため、ノードと Pod がデフォルトでインターネットから隔離されています。ネットワークポリシーを定義して、クラスタ内の Pod 間の通信を管理することもできます。詳細については、サービスのプライベートアクセスオプションをご覧ください。

コンピューティングインスタンスと GKE の使用状況のモニタリング

Cloud Audit Logs は、Compute Engine と GKE に対して自動的に有効になります。監査ログを使用すると、クラスタでのすべてのアクティビティを自動的に収集し、不審なアクティビティをモニタリングできます。

GKE をパートナープロダクトと統合してランタイムセキュリティを実現できます。これらのソリューションを Security Command Center と統合すると、アプリケーションをモニタリングするための単一のインターフェースが提供されます。

イメージとクラスタを最新の状態に保つ

Google Cloud では、定期的にパッチが適用される OS イメージを提供しています。カスタムイメージを用意して Compute Engine で実行することもできますが、実行した場合は自分でパッチを適用する必要があります。Google Cloud は、定期的に新しい OS イメージをアップデートして、セキュリティ情報で説明されている新しい脆弱性を緩和し、既存のデプロイの脆弱性を修正しています。

GKE を使用している場合は、クラスタノードに常に最新のパッチが適用されているように、ノードの自動アップグレードを有効にすることをおすすめします。Google では、GKE コントロールプレーンを管理し、自動更新を行ってパッチを適用しています。また、Google が選んだコンテナ最適化イメージをデプロイに使用します。Google はこれらのイメージのパッチと更新を定期的に行っています。

イメージとクラスタへのアクセスを制御する

インスタンスを作成および起動できるユーザーを把握しておくことが重要です。IAM を使用すると、このアクセスを制御できます。必要なアクセスワークロードを決定する方法については、ワークロード ID の計画をご覧ください。

また、VPC Service Controls を使用して、プロジェクトにカスタム割り当てを定義し、イメージを起動できるユーザーを制限することもできます。詳細については、ネットワークを保護するをご覧ください。

クラスタのインフラストラクチャのセキュリティを強化するため、GKE では IAM とロールベースのアクセス制御（RBAC）を使用して、クラスタと名前空間へのアクセスを管理できます。

サンドボックスでコンテナを分離する

GKE Sandbox を使用して、ホストカーネルから分離された追加のセキュリティレイヤを必要とするマルチテナントアプリケーションをデプロイします。たとえば、不明なコードや信頼できないコードを実行する場合は、GKE Sandbox を使用します。GKE Sandbox は、GKE 上でコンテナ化されたワークロード間の 2 番目の防御レイヤを提供するコンテナ分離ソリューションです。

GKE Sandbox は、低 I/O 要件でありながら高度にスケールされたアプリケーションを考慮して構築されました。このようなコンテナ化されたワークロードは、速度とパフォーマンスを維持する必要があり、セキュリティの強化を必要とする信頼できないコードが含まれる可能性もあります。コンテナのランタイムサンドボックスである gVisor を使用して、アプリケーションとホストカーネル間のセキュリティ分離を強化します。gVisor は、追加の整合性チェックを提供し、サービスに対するアクセススコープを制限します。これは、外部の脅威から保護するためのコンテナ強化サービスではありません。gVisor の詳細については、gVisor: 現実世界で GKE とサーバーレスユーザーを保護をご覧ください。

次のステップ

コンピューティングとコンテナのセキュリティの詳細については、次のリソースをご覧ください。

ネットワークを保護する

Google Cloud Architecture Framework のこのドキュメントでは、ネットワークを保護するためのベストプラクティスについて説明します。

既存のネットワークをクラウド環境に拡張する場合、セキュリティについて多くのことを検討する必要があります。多層防御のオンプレミスアプローチでは、インターネットと内部ネットワークとの間に明確な境界が存在する可能性があります。こうした境界は、物理的なファイアウォール、ルーター、侵入検知システムなどで保護できるかもしれません。境界が明確に定義されているため、侵入を簡単に監視し、それに応じて対応できます。

完全かハイブリッドかにかかわらず、クラウドへの移行はオンプレミス境界を越えることになります。このドキュメントでは、Google Cloud で組織のデータとワークロードの保護を継続する方法について説明します。コントロールでリスクを管理するで説明したように、Google Cloud ネットワークの設定方法と保護方法はビジネス要件とリスク許容度によって異なります。

このセクションでは、システム設計カテゴリのネットワーキングのセクションを読み、すでに Google Cloud ネットワークコンポーネントの基本的なアーキテクチャ図を作成していることを前提としています。サンプルの図については、ハブアンドスポークをご覧ください。

ゼロトラストネットワークをデプロイする

クラウドに移行するには、ネットワーク信頼性モデルの変更が必要になります。ユーザーとワークロードがオンプレミス境界の背後に存在するため、信頼性の高い内部ネットワークと同じ方法で境界を保護することはできません。ゼロトラストセキュリティモデルは、組織のネットワークの内か外かにかかわらず、デフォルトでは何も信頼しないことを意味します。アクセスリクエストを確認するには、ゼロトラストセキュリティモデルでユーザーの ID とコンテキストの両方を確認する必要があります。VPN とは異なり、アクセス制御は、ネットワーク境界からユーザーとデバイスにシフトします。

Google Cloud では、ゼロトラストソリューションとして BeyondCorp Enterprise を使用できます。BeyondCorp Enterprise は脅威からのデータ保護とアクセス制御を提供します。詳しい設定方法については、BeyondCorp Enterprise のスタートガイドをご覧ください。

Google Cloud では、BeyondCorp Enterprise 以外にも、Identity-Aware Proxy（IAP）も使用できます。IAP を使用すると、Google Cloud 内とオンプレミスの両方で、アプリケーションにゼロトラストセキュリティを拡張できます。IAP は、アクセス制御ポリシーを使用して、アプリケーションやリソースにアクセスするユーザーに認証と認可を提供します。

オンプレミス環境またはマルチクラウド環境への接続のセキュリティを確保します

多くの組織では、クラウド環境とオンプレミスの両方にワークロードがあります。さらに、復元力を確保するために、マルチクラウドソリューションを使用する組織もあります。このようなシナリオでは、すべての環境間の接続を保護することが重要です。

Google Cloud には、Cloud VPN や Cloud Interconnect によってサポートされている VM に対するプライベートアクセス方式があります。これには次のような方法があります。

マネージドサービスとして Cross-Cloud Interconnect を使用して、VPC ネットワークを、高速の直接接続を介して他のサポートされているクラウドプロバイダにリンクします。Cross-Cloud Interconnect を使用する場合、独自のルーターを供給したり、サードパーティのベンダーと連携したりする必要はありません。
Dedicated Interconnect と Partner Interconnect を使用して、VPC ネットワークを高速の直接接続を介してオンプレミスデータセンターや他のクラウドプロバイダにリンクします。
IPsec VPN を使用して、Virtual Private Cloud（VPC）ネットワークをオンプレミスデータセンターや他のクラウドプロバイダにリンクします。
組織または別のプロバイダから提供されている公開サービスにアクセスするには、Private Service Connect エンドポイントを使用します。
Private Service Connect エンドポイントを使用して、VM が Google API にアクセスできるようにするには、内部 IP アドレスを使用します。Private Service Connect を使用すると、VM では、Google サービスにアクセスするために外部 IP アドレスを持つ必要がありません。
GKE Enterprise を使用する場合は、Anthos Service Mesh Egress ゲートウェイの使用を検討してください。GKE Enterprise を使用しない場合は、サードパーティのオプションを使用します。

プロダクト間の比較については、Network Connectivity プロダクトの選択をご覧ください。

デフォルトネットワークを無効にする

新しい Google Cloud プロジェクトを作成すると、自動モードの IP アドレスを持つデフォルトの Google Cloud VPC ネットワークと、事前設定のファイアウォールルールが自動的にプロビジョニングされます。本番環境のデプロイの場合、既存のプロジェクトではデフォルトネットワークを削除し、さらに新しいプロジェクトでは、デフォルトネットワークの作成を無効にすることをおすすめします。

Virtual Private Cloud ネットワークでは、任意の内部 IP アドレスを使用できます。IP アドレスの競合を回避するには、まず、接続されたデプロイとプロジェクト全体でネットワークと IP アドレスの割り振りを計画することをおすすめします。プロジェクトで複数の VPC ネットワークを許可することもできますが、一般的には、アクセス制御を効果的に実施するために、これらのネットワークをプロジェクトごとに 1 つに制限することをおすすめします。

境界の保護

Google Cloud では、ファイアウォールや VPC Service Controls など、さまざまな方法を使ってクラウド境界をセグメント化し、保護できます。

共有 VPC を使用すると、単一の共有ネットワークを提供し、複数のチームで管理される個々のプロジェクトにワークロードを分離する本番環境デプロイメントを構築できます。共有 VPC は、複数のプロジェクトにまたがるネットワークとネットワークセキュリティリソースの一元的なデプロイ、管理、制御を可能にします。共有 VPC は、次の機能を実行するホストプロジェクトとサービスプロジェクトで構成されます。

ホストプロジェクトには、VPC ネットワーク、サブネット、ファイアウォールルール、ハイブリッド接続など、ネットワークとネットワークのセキュリティ関連のリソースが含まれます。
サービスプロジェクトは、ホストプロジェクトに接続されます。これを使用すると、Identity and Access Management（IAM）を使用してプロジェクトレベルでワークロードとユーザーを分離すると同時に、一元管理されたホストプロジェクトからネットワークリソースを共有できます。

組織、フォルダ、VPC ネットワークのレベルで、ファイアウォールポリシーとルールを定義します。VM インスタンスとの間で発生するトラフィックを許可または拒否するように、ファイアウォールルールを構成できます。たとえば、グローバルとリージョンのネットワークファイアウォールポリシーの例と階層型ファイアウォールポリシーの例をご覧ください。IP アドレス、プロトコル、ポートに基づいたルールの定義に加えて、VM インスタンスで使用されているサービスアカウントに基づいて、または、セキュアタグを使用して、トラフィックを管理し、ファイアウォールルールを適用できます。

Google サービス内のデータの移動を制御し、コンテキストベースの境界セキュリティを設定するには、VPC Service Controls を検討してください。VPC Service Controls は、IAM、ファイアウォールルールとポリシーに関係なく、Google Cloud サービスに対するセキュリティを強化します。たとえば、VPC Service Controls を使用すると、機密データと機密データ以外の間に境界を設定し、データの引き出しを防ぐコントロールを適用できます。

Google Cloud Armor のセキュリティポリシーを使用すると、着信トラフィックの送信元にできるだけ近い場所で Google Cloud Edge の外部アプリケーションロードバランサへのアクセスを許可、拒否、またはリダイレクトできます。このポリシーにより、望ましくないトラフィックによるリソースの消費や、ネットワークへの侵入を防ぐことができます。

Secure Web Proxy を使用して、下り（外向き）ウェブトラフィックにきめ細かいアクセスポリシーを適用し、信頼していないウェブサービスへのアクセスをモニタリングします。

ネットワークトラフィックを検査する

Cloud IDS と Packet Mirroring は、Compute Engine と Google Kubernetes Engine（GKE）で実行されているワークロードのセキュリティとコンプライアンスを確保するために使用できます。

Cloud Intrusion Detection System（現在はプレビュー版）を使用して、VPC ネットワークと送受信されるトラフィックの詳細を可視化できます。Cloud IDS は、ミラーリングされた VM のある Google 管理のピアリングネットワークを作成します。Palo Alto Networks の脅威対策技術により、トラフィックをミラーリングして検査します。詳細については、Cloud IDS の概要をご覧ください。

Packet Mirroring は、VPC ネットワーク内の指定された VM インスタンスのトラフィックを複製し、収集、保持、調査のために転送します。Packet Mirroring を構成すると、Cloud IDS やサードパーティツールを使用してネットワークトラフィックを大規模に収集し、検査できます。この方法でネットワークトラフィックを検査すると、侵入検知とアプリケーションのパフォーマンスモニタリングの実現が容易になります。

ウェブアプリケーションのファイアウォールを使用する

外部のウェブアプリケーションとサービスに対しては、Google Cloud Armor を有効にすることで、分散型サービス拒否攻撃（DDoS）からの保護と、ウェブアプリケーションファイアウォール（WAF）機能を提供できます。Google Cloud Armor は、外部 HTTP(S) ロードバランシング、TCP プロキシロードバランシング、または SSL プロキシロードバランシングを使用して公開される Google Cloud ワークロードをサポートします。

Google Cloud Armor には Standard と Managed Protection Plus の 2 つのサービスティアがあります。Google Cloud Armor の高度な機能を最大限に活用するには、主要なワークロードに Managed Protection Plus を使用してください。

インフラストラクチャのプロビジョニングを自動化する

自動化を行うと、プロビジョニング後に変更できない不変のインフラストラクチャを構築できます。これにより、運用チームは既知の正常な状態を把握し、高速ロールバックやトラブルシューティングを行うことができます。自動化を行う場合は、Terraform、Jenkins、Cloud Build などのツールを使用できます。

Google Cloud では、自動化を使用する環境を簡単に構築できるように、一連のセキュリティブループリントを用意しています。これは、エンタープライズ基盤のブループリントに基づいています。セキュリティ基盤ブループリントでは、安全なアプリケーション環境を構築するための Google 独自の設計を提供し、Google Cloud 資産の構成とデプロイの方法が記述されています。セキュリティ基盤ブループリントに記述されている手順とスクリプトを使用して、セキュリティのベストプラクティスとガイドラインを満たす環境を構成できます。このブループリントと追加のブループリントに基づいて構築することも、独自の自動化を設計することもできます。

自動化の詳細については、データ処理ワークフローに CI / CD パイプラインを使用するをご覧ください。

ネットワークをモニタリングする

ネットワークとトラフィックは、テレメトリーを使用してモニタリングします。

VPC フローログとファイアウォールルールのロギングを使用すると、Google Cloud 環境のトラフィックとファイアウォールの使用状況をほぼリアルタイムで可視化できます。たとえば、ファイアウォールルールのロギングでは、Compute Engine VM インスタンスに出入りするトラフィックをロギングできます。これらのツールを Cloud Logging や Cloud Monitoring と組み合わせると、トラフィックとアクセスパターンの追跡、アラート、可視化によってデプロイメントの運用面でのセキュリティを向上させることができます。

ファイアウォールインサイトを使用すると、受信接続と送信接続に一致したファイアウォールルールを確認できます。また、接続が許可されたのか、拒否されたのかも確認できます。シャドールール機能では、別のルールが常に最初にトリガーされるために一度もトリガーされないルールを確認し、ファイアウォール構成を調整できます。

ネットワークトポロジとアーキテクチャのパフォーマンスは、Network Intelligence Center を使用して確認します。ネットワークパフォーマンスに関する詳細な分析情報を取得し、デプロイメントを最適化してサービスのボトルネックを解消できます。接続テストでは、ネットワークパスに適用されるファイアウォールルールとポリシーに関する分析情報が提供されます。

モニタリングの詳細については、ロギングと検出制御の実装をご覧ください。

次のステップ

ネットワークセキュリティの詳細については、次のリソースをご覧ください。

データセキュリティを実装する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、データセキュリティを実装するためのベストプラクティスについて説明します。

デプロイアーキテクチャの一部として、Google Cloud で処理して保存するデータとデータの機密性を検討する必要があります。ライフサイクルの中でデータを保護する制御機構を設計します。これによって、データの所有権と分類が明らかになり、不正な使用からのデータの保護に役立ちます。

このドキュメントで説明するセキュリティのベストプラクティスを使用して BigQuery データウェアハウスをデプロイするセキュリティブループリントについては、機密データを格納する BigQuery データウェアハウスを保護するをご覧ください。

データを自動的に分類する

データの分類は、データマネジメントライフサイクルのできるだけ早い段階（理想的にはデータの作成時）に行います。通常、データの分類作業には、次のようなわずか数種類のカテゴリだけが必要です。

一般公開: 一般公開が承認されたデータ。
内部: 一般公開されない機密性が低いデータ。
機密: 一般的な内部配信に使用できる機密データ。
制限付き: 機密性の高いデータ、または制限された配信が必要な規制対象のデータ。

Google Cloud 環境全体にわたるデータを検出と分類には、機密データ保護を利用できます。センシティブデータの保護には、Cloud Storage、BigQuery、Datastore 内の機密データをスキャンして分類する機能が組み込まれています。また、追加のデータソースとカスタムワークロードをサポートするストリーミング API も用意されています。

センシティブデータの保護は、組み込みの infoType を使用してセンシティブデータを識別できます。機密要素（PII データなど）を自動的に分類、マスキング、トークン化、変換することで、データの収集、保存、使用のリスクを管理できます。つまり、データライフサイクルプロセスと統合することで、すべてのステージでデータを確実に保護できます。

詳細については、センシティブデータの保護を使用した大規模なデータセットにおける PII の匿名化と再識別をご覧ください。

メタデータを使ってデータガバナンスを管理する

データガバナンスは、データを安全に、非公開で、正確に利用できるようにするプロセスの組み合わせです。組織のデータガバナンス戦略を定義する責任はお客様にありますが、Google Cloud には、戦略の実践に役立つツールとテクノロジーが用意されています。また、Google Cloud では、クラウド内のデータガバナンス用フレームワーク（PDF）も用意されています。

Data Catalog でメタデータの検索とキュレートを行い、クラウド内のデータアセットを記述します。Data Catalog を使用してデータアセットを検索し、メタデータでそのアセットにタグを付けることができます。データの分類作業を高速化するには、機密データを自動的に識別するために、Data Catalog をセンシティブデータの保護と統合します。データにタグ付けした後は、Google Identity and Access Management（IAM）を使用して、ユーザーが Data Catalog ビューを介してクエリまたは使用できるデータを制限できます。

ワークロードのメタデータを管理するには、Dataproc Metastore または Hive メタストアを使用します。Data Catalog の Hive コネクタを使用すると、Hive メタストア内のメタデータを検出できます。

データ品質ルールは、コンソールで Dataprep by Trifacta を使用して、定義および適用します。Dataprep は、Cloud Data Fusion 内から使用するか、スタンドアロンサービスとして使用できます。

ライフサイクルのフェーズと分類に従ってデータを保護する

データは、ライフサイクルのコンテキストで定義し、その機密性とリスクに基づいてデータを分類した後、適切なセキュリティの制御機構を割り当てて保護できます。その制御機構によって、十分な保護が提供され、コンプライアンス要件を満たし、リスクが軽減されるようにする必要があります。クラウドに移行するときに、現在の戦略と、現行プロセスの変更が必要な部分を確認します。

次の表では、クラウドにおけるデータセキュリティ戦略の 3 つの特性について説明します。

特性	説明
識別	データを作成、変更、保存、使用、共有、削除するユーザー、リソース、アプリケーションの ID を把握します。データへのアクセス権は、Cloud Identity と IAM を使用して制御します。ID に証明書が必要な場合は、Certificate Authority Service を検討してください。詳細については、ID とアクセス権の管理をご覧ください。
境界とアクセス	データに、誰が、どのような状況下で、どのようにしてアクセスするかを制御する機構を設定します。データへのアクセス境界は、次のレベルで管理できます。ネットワークレイヤアクセス。Cloud ファイアウォールなどの制御機構を使用します。ネットワークレイヤについての詳しい分析情報については、Network Intelligence Center を使用してください。指定したサービスのリソースとデータを保護する境界は、VPC Service Controls を使用して作成します。 IAM を使用した IAM アクセス制御。IAM ロールの管理については、アクセス制御のためのリソース階層の使用をご覧ください。
公開設定	使用状況を監査して、データの制御方法とアクセス方法を示すレポートを作成できます。Google Cloud Logging とアクセスの透明性により、独自のクラウド管理者と Google の担当者の操作に関する分析情報が提供されます。詳細については、データをモニタリングするをご覧ください。

データを暗号化する

デフォルトでは、Google Cloud は保存されているお客様のデータを暗号化します。お客様が特別な操作を行う必要はありません。Google Cloud では、デフォルトの暗号化に加えて、エンベロープ暗号化と暗号鍵を管理できます。たとえば、Compute Engine の永続ディスクは自動的に暗号化されますが、独自の鍵を指定または管理することもできます。

ストレージ、コンピューティング、ビッグデータワークロード用の鍵の選択に関しては、鍵の生成、保管、ローテーションの要件にどのソリューションが最適かを判断する必要があります。

暗号化と鍵管理に関して、Google Cloud には次の選択肢があります。

顧客管理の暗号鍵（CMEK）Cloud Key Management Service（Cloud KMS）を使用して暗号鍵を生成し、管理できます。この選択肢は、暗号鍵を定期的にローテーションする必要があるなど、特定の鍵管理の要件がある場合に使用します。
顧客指定の暗号鍵（CSEK）独自の暗号鍵を作成して管理し、必要に応じて Google Cloud に送信できます。このオプションは、オンプレミスの鍵管理システムを使用して独自の鍵を生成し、独自の鍵を使用する場合（BYOK）に使用します。CSEK を使用して独自の鍵を指定すると、Google は鍵を複製し、ワークロードで使用できるようにします。ただし、顧客指定の暗号鍵はインスタンステンプレートや Google インフラストラクチャに保存されないため、CSEK のセキュリティと可用性はお客様の責任となります。鍵にアクセスできなくなった場合、Google は暗号化されたデータを復元できません。どの鍵を自身で作成および管理するのか慎重に検討してください。CSEK は機密情報のみに使用できます。また、クライアントサイドでデータの暗号化を実行し、暗号化されたデータを Google Cloud に保存することもできます。この場合、データは Google によって再度暗号化されます。
Cloud External Key Manager（Cloud EKM）を使用したサードパーティの鍵管理システム。Cloud EKM は、Google インフラストラクチャの外部で管理されているサードパーティの鍵管理システムに保存、管理されている暗号鍵を使用して、保存データを保護します。この方法により、組織外のユーザーがデータにアクセスできないことが保証されます。Cloud EKM を使用すると、安全な Hold Your Own Key（HYOK）モデルで鍵管理を実現できます。互換性情報については、Cloud EKM 対応サービスの一覧をご覧ください。

Cloud KMS では、ソフトウェア格納型の暗号鍵や、FIPS 140-2 レベル 3 検証済みのハードウェアセキュリティモジュール（HSM）を使用してデータを暗号化することもできます。Cloud KMS を使用している場合、暗号鍵はリソースをデプロイするリージョンに保存されます。Cloud HSM は、リージョン間で鍵管理のニーズを分散させ、鍵に冗長性とグローバルな利用可能性を提供します。

エンベロープ暗号化の仕組みについては、Google Cloud での保存時の暗号化をご覧ください。

データへのクラウド管理者のアクセスを管理する

Google のサポート担当者とエンジニアリング担当者による Google Cloud 上の環境へのアクセスは管理できます。Access Approval を使用すると、Google 社員が Google Cloud 上のデータやリソースにアクセスする前に明示的な承認を行うことができます。このプロダクトは、Google の担当者がお客様のデータを操作したときにログを生成するアクセスの透明性による可視性を補完するものです。このログには、オフィス所在地とアクセスの理由が含まれます。

これらのプロダクトを組み合わせて使用すると、どのような理由があっても Google によるデータの復号を拒否できます。

データの保存場所とアクセス可能なユーザー所在地を構成する

ユーザーがデータにアクセスできるネットワークロケーションは、VPC Service Controls を使用して制御できます。このプロダクトを使用すると、特定リージョンのユーザーのアクセスを制限できます。Google IAM ポリシーに従ってユーザーが承認されている場合でも、この制約を適用できます。サービスにアクセス可能な仮想境界線を定義するサービス境界を VPC Service Controls で作成し、データが仮想境界線の外に移動されることを防ぎます。

詳しくは以下をご覧ください。

Secret Manager を使ってシークレットを管理する

Secret Manager を使用すると、すべてのシークレットを一元管理できます。シークレットは、データベースパスワード、API キー、TLS 証明書などの構成情報です。シークレットの自動ローテーションや、最新バージョンのシークレットを自動的に使用するようにアプリケーションを構成できます。Secret Manager とのやり取りで監査ログが生成されるため、シークレットへのすべてのアクセスを確認できます。

センシティブデータの保護には、検出項目のカテゴリもあり、Secret Manager で保護できるデータの認証情報とシークレットの識別に役立ちます。

データをモニタリングする

管理者のアクティビティと鍵の使用ログを確認するには、Cloud Audit Logs を使用します。データの保護に役立てるため、Cloud Monitoring でログをモニタリングし、鍵が適切に使用されているかどうか確認します。

Cloud Logging は Google Cloud イベントをキャプチャし、必要に応じてソースを追加できます。リージョン別にログを分割し、バケットに保管して、ログを処理するカスタムコードを統合できます。例については、自動ログ分析のカスタムソリューションをご覧ください。

ログを BigQuery にエクスポートして、セキュリティとアクセスの分析を行い、組織のデータに対する不正な変更やアクセスを特定することもできます。

Security Command Center を使用すると、クラウドに保存されている機密性の高い組織データに対するアクセスの問題を特定して解決できます。1 つの管理インターフェースから、クラウドインフラストラクチャに対するさまざまなセキュリティの脆弱性やリスクをスキャンできます。たとえば、データの引き出しのモニタリング、ストレージシステムでの機密データのスキャン、インターネットに公開されている Cloud Storage バケットの検出などが可能です。

次のステップ

データセキュリティの詳細については、次のリソースをご覧ください。

アプリケーションを安全にデプロイする

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、アプリケーションを安全にデプロイするためのベストプラクティスについて説明します。

アプリケーションを安全にデプロイするには、設計、開発、テスト、デプロイの各ステージで適切なセキュリティチェックを行い、ソフトウェア開発ライフサイクルを明確に定義する必要があります。アプリケーションを設計するときは、認証、認可、アクセス制御に標準化されたフレームワークを使用する階層化されたシステムアーキテクチャをおすすめします。

安全なリリースの自動化

自動化されたツールを使用しない場合、一貫したセキュリティ要件を満たすために、複雑なアプリケーション環境のデプロイ、更新、パッチの適用を行うことは容易なことではありません。そのため、これらのタスクの CI / CD パイプラインを構築することをおすすめします。これにより、多くの問題を解決できます。自動化されたパイプラインを使用すると、手動によるエラーをなくすことができます。標準化された開発フィードバックループが提供されるので、プロダクトの迅速な反復が可能になります。たとえば、Cloud Build のプライベートプールを使用すると、金融や医療など、規制の厳しい業界向けに、安全性の高いマネージド CI / CD パイプラインをデプロイできます。

アーティファクトを作成するときに、自動化を使用してセキュリティの脆弱性をスキャンできます。さまざまな環境（開発、テスト、本番環境など）に対してポリシーを定義し、検証されたアーティファクトのみをデプロイすることもできます。

アプリケーションのデプロイが承認プロセスに従っていることを確認する

攻撃者が CI / CD パイプラインを侵害すると、スタック全体が影響を受ける可能性があります。パイプラインを保護するには、コードを本番環境にデプロイする前に、確立された承認プロセスを適用する必要があります。

Google Kubernetes Engine（GKE）または GKE Enterprise を使用する予定の場合は、Binary Authorization を使用して、これらのチェックとバランスを確立できます。Binary Authorization は、構成可能な署名をコンテナイメージに適用します。これらのシグネチャ（証明書）はイメージの検証に役立ちます。デプロイ時に、Binary Authorization はこれらの証明書を使用してプロセスの完了を判断します。たとえば、Binary Authorization を使用して次のことができます。

特定のビルドシステムまたは継続的インテグレーション（CI）パイプラインによってコンテナイメージが作成されたことを確認する。
コンテナイメージが脆弱性署名ポリシーを遵守していることを確認する。
コンテナイメージが次のデプロイ環境（デプロイから QA まで）に昇格するための基準を満たしていることを確認する。

デプロイ前に既知の脆弱性をスキャンする

コンテナを本番環境にデプロイする前に、コンテナイメージに対して継続的に脆弱性スキャンを実施できる自動化ツールの使用をおすすめします。

Artifact Analysis を使用して、Artifact Registry と Container Registry に保存されているコンテナに対して脆弱性スキャンを自動的に実行します。このプロセスには、スキャンと継続分析の 2 つのタスクがあります。

まず、Artifact Analysis は、Artifact Registry または Container Registry にアップロードされた新しいイメージをスキャンします。このスキャンにより、コンテナ内のシステムパッケージに関する情報が抽出されます。

Artifact Analysis は、イメージのアップロード時に脆弱性を探します。最初のスキャンの後、Artifact Analysis は、Artifact Registry と Container Registry 内でスキャンされたイメージのメタデータに新たな脆弱性がないか継続的にモニタリングを行います。Artifact Analysis は、新しい脆弱性情報と更新された脆弱性情報を脆弱性ソースから受け取ると、次の処理を行います。

スキャンしたイメージのメタデータを更新して、最新の状態に保つ。
新しいメモ用の新しい脆弱性オカレンスを作成する。
有効ではなくなった脆弱性を削除する。

アプリケーションコードで既知の脆弱性をモニタリングする

アプリケーションコードの既知の脆弱性（OWASP Top 10 など）を常にモニタリングできる自動化ツールの使用をおすすめします。OWASP Top 10 の回避策をサポートする Google Cloud プロダクトと機能については、Google Cloud の OWASP Top 10 の緩和策をご覧ください。

Web Security Scanner を使用すると、App Engine、Compute Engine、Google Kubernetes Engine ウェブアプリケーションの脆弱性を特定できます。このスキャナは、アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベントハンドラを処理しようとします。クロスサイトスクリプティング（XSS）、Flash インジェクション、混合コンテンツ（HTTPS 内の HTTP）、古いライブラリや安全でないライブラリなど、一般的な脆弱性を自動的にスキャンして検出できます。Web Security Scanner は、これらの脆弱性を正確かつ早期に特定します。

境界を越えるデータの移動を制御する

境界を越えるデータの移動を制御するために、Google マネージドサービスのリソースの周囲にセキュリティ境界を構成できます。VPC Service Controls を使用して、CI / CD パイプライン内のすべてのコンポーネントとサービス（Container Registry、Artifact Registry、Artifact Analysis、Binary Authorization など）をセキュリティ境界内に配置します。

VPC Service Controls を使用すると、Google マネージドサービスから不正なデータ転送やコピー（データの引き出し）が行われるリスクを軽減できます。VPC Service Controls を使用すると、Google マネージドサービスのリソースにセキュリティ境界を構成し、境界をまたがるデータの移動を制御できます。サービス境界が適用されると、境界ポリシーに違反するリクエスト（境界外部から保護されたサービスに対するリクエストなど）が拒否されます。サービスが自動適用境界で保護されている場合、VPC Service Controls は次の処理を行います。

サービスは境界の外にデータを送信できません。保護されたサービスは境界内で通常どおり機能しますが、境界からリソースやデータを送信することはできません。この制限により、境界内のプロジェクトにアクセスする悪意のある関係者がデータを漏洩するのを防ぐことができます。
境界外から保護されたサービスへのリクエストは、境界に割り当てられたアクセスレベルの条件が満たされている場合にのみ受け入れられます。
このサービスは境界ブリッジを使用して、他の境界内のプロジェクトにアクセス可能にすることができます。

コンテナイメージを暗号化する

Google Cloud では、顧客管理の暗号鍵（CMEK）を使用してコンテナイメージを暗号化できます。CMEK 鍵は Cloud Key Management Service（Cloud KMS）で管理されます。CMEK を使用する場合、鍵を無効化または破棄することで、暗号化されたコンテナイメージへのアクセスを一時停止または恒久的に無効にできます。

次のステップ

次のリソースを使用してサプライチェーンとアプリケーションのセキュリティを保護する方法を確認する。

コンプライアンス義務を管理する

Google Cloud アーキテクチャフレームワークにおけるこのドキュメントでは、コンプライアンスの義務を管理するためのベストプラクティスについて説明します。

クラウドの規制要件は、次のような要因の組み合わせによって異なります。

組織の物理的な場所に適用される法律および規制。
ユーザーのお客様の物理的な場所に適用される法律と規制。
業界の規制要件。

これらの要件に基づいて、Google Cloud のワークロードに対して有効にするセキュリティ制御に必要な意思決定を行います。

一般的なコンプライアンスの取り組みには、評価、ギャップの修復、継続的なモニタリングの 3 つのステージがあります。このセクションでは、各ステージで使用できるベストプラクティスを取り上げます。

コンプライアンスのニーズを評価する

コンプライアンス評価は、すべての規制義務と、それが企業でどのように実装されているかを徹底的に確認することから始まります。Google Cloud サービスの評価に役立つよう、コンプライアンスリソースセンターを使用します。このサイトでは、次のことについて詳しく説明します。

さまざまな規制に対応するサービスサポート
Google Cloud の認定資格と証明書

Google のコンプライアンスライフサイクルと要件の遵守について理解を深めるには、Google コンプライアンススペシャリストのサポートを依頼してください。

詳細については、クラウドでのコンプライアンスの保証（PDF）をご覧ください。

Assured Workloads をデプロイする

Assured Workloads は、Google Cloud 内の制御に基づいて構築された Google Cloud ツールであり、コンプライアンス義務の遵守を支援します。Assured Workloads では次のことができます。

コンプライアンスレジームを選択する。このツールは、ベースライン担当者のアクセス制御を自動的に設定します。
組織のポリシーを使用してデータのロケーションを設定し、保存データとリソースがそのリージョンにのみ保持されるようにする。
セキュリティとコンプライアンスの要件に最適な鍵管理オプション（鍵のローテーション期間など）を選択する。
FedRAMP Moderate などの特定の規制要件のために、Google サポート担当者によるアクセス基準を選択する（例: 適切なバックグラウンドチェックが完了しているか）。
Google が管理する暗号鍵が FIPS-140-2 に準拠し、FedRAMP Moderate への準拠をサポートしていることを確認する。制御レイヤの追加と職掌分散のため、顧客管理の暗号鍵（CMEK）を使用します。鍵の詳細については、データを暗号化するをご覧ください。

コンプライアンスレジームに適用するテンプレートとベストプラクティスのブループリントを確認します。

Google は、ベストプラクティスについて説明し、コンプライアンスの達成に役立つ環境をロールアウトするための Terraform モジュールを提供するブループリントとソリューションガイドを公開しています。次の表に、セキュリティとコンプライアンス要件への対応を説明するブループリントを示します。

スタンダード	説明
PCI	セキュリティブループリント: GKE での PCI PCI データセキュリティ基準の遵守 Google Cloud の PCI 環境に対するコンプライアンスの対象範囲の制限 GKE における PCI DSS コンプライアンス
FedRAMP	Google Cloud FedRAMP 実装ガイド（PDF） Google Cloud 上での FedRAMP に準拠した 3 層ワークロードの設定
HIPAA	Google Cloud における医療データの保護（PDF）データ保護ツールキットを使用した HIPAA 対応ワークロードの設定（PDF）

コンプライアンスをモニタリングする

ほとんどの規制では、アクセス制御を含む特定のアクティビティをモニタリングする必要があります。モニタリングのために、次の項目を使用できます。

アクセスの透明性。Google Cloud 管理者がお客様のコンテンツにアクセスした際に、ニアリアルタイムのログを提供します。
ファイアウォールルールロギング。ご自分で作成したルールに従って VPC ネットワーク内の TCP 接続と UDP 接続を記録します。これらのログは、ネットワークアクセスを監査する場合や、ネットワークが承認されていない方法で使用されていることを早期に警告する場合に活用できます。
VPC フローログ。VM インスタンスによって送受信されたネットワークトラフィックフローを記録します。
Security Command Center Premium。さまざまな標準への準拠をモニタリングします。
OSSEC（または別のオープンソースツール）。環境に対する管理者権限がある個人のアクティビティをログに記録します。
Key Access Justifications。鍵アクセスリクエストの理由を表示します。

コンプライアンスを自動化する

変化し続ける規制を遵守し続けるために、Infrastructure as Code にセキュリティポリシーを組み込むことで、セキュリティポリシーを自動化できる方法があるかどうかを判断します。たとえば、次の点を考えます。

セキュリティブループリントを使用して、インフラストラクチャのデプロイにセキュリティポリシーを組み込みます。
Security Command Center を構成して、コンプライアンス違反の問題が発生した場合のアラートを構成します。たとえば、ユーザーが 2 段階認証プロセスを無効にしている場合や、過剰な権限が付与されたサービスアカウントなどの問題をモニタリングします。詳細については、検出通知の設定をご覧ください。
特定の通知に対する自動修復を設定します。詳細については、Cloud Functions のコードをご覧ください。

コンプライアンスの自動化の詳細については、リスク・コンプライアンス管理のコード化（RCaC）ソリューションをご覧ください。

次のステップ

コンプライアンスの詳細については、以下のリソースをご覧ください。

データ所在地と主権の要件を実装する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、データ所在地と主権の要件の実装に関するベストプラクティスについて説明します。

データ所在地と主権の要件は、地域と業界固有の規制に基づいており、組織ごとにデータ主権の要件が異なる場合があります。たとえば、次のような要件が課せられます。

どの担当者がデータにアクセスできるか、どのリージョンからデータにアクセスできるかなど、Google Cloud によるデータへのすべてのアクセスを制御します。
クラウドインフラストラクチャとサービスに対する変更が検査可能であるため、データへのアクセスやデータのセキュリティに影響を及ぼす可能性があります。このような種類の変更に関する分析情報は、Google Cloud が制御を回避できないようにする、またはデータをリージョンから移動できないようにするのに役立ちます。
Google Cloud からソフトウェアの更新を受信できない場合に、時間を延長してワークロードを継続します。

データ主権を管理する

データ主権は、Google がユーザーのデータにアクセスできないようにするメカニズムを提供します。アクセスを承認するのは、ユーザーによる同意が必要なプロバイダの動作に限られます。

たとえば、次の方法でデータ主権を管理できます。

暗号鍵をクラウド外で保存および管理します。
詳細なアクセス理由に基づいて、これらの鍵にのみアクセス権を付与します。
使用中のデータを保護します。

運用主権を管理する

運用主権は、Google の従業員がユーザーのワークロードを侵害できないことを保証します。

たとえば、次の方法で運用主権を管理できます。

特定のプロバイダリージョンに、新しいリソースのデプロイ先を制限します。
市民権や地理的位置など、事前定義された属性に基づいて Google の従業員によるアクセスを制限します。

ソフトウェア主権を管理する

ソフトウェア主権は、単一のクラウドプロバイダに依存せずに（またはロックインされることなく）、ワークロードの可用性を制御し、任意の場所で実行できることを保証します。ソフトウェア主権には、ワークロードのデプロイ先や外部接続の許可レベルを即座に変更する必要が生じるイベントに対処できることが含まれています。

たとえば、Google Cloud はハイブリッドデプロイとマルチクラウドデプロイをサポートしています。また、GKE Enterprise では、クラウド環境とオンプレミス環境の両方でアプリケーションを管理およびデプロイできます。

データ所在地を制御する

データ所在地は、データが保存される場所を表します。データ所在地の要件は、システム設計の目標、業界の規制に関する懸念、国内法、税務上の影響、さらには文化によって異なります。

データ所在地の制御を開始する手順は次のとおりです。

データのタイプと場所の把握。
データに存在するリスクと適用される法規制の把握。
データの場所や保存先の管理。

データ所在地の要件を遵守するため、Google Cloud ではデータの保存場所、アクセス方法、処理方法を制御できます。リソースロケーションポリシーを使用して、リソースを作成する場所と、リージョン間でデータをレプリケートする場所を制限できます。リソースのロケーションプロパティを使用してサービスのデプロイ先とメンテナンスを行うユーザーを特定できます。

サポート情報については、リソースロケーションのサポート対象サービスをご覧ください。

次のステップ

データ所在地と主権について詳しくは、以下のリソースをご覧ください。

プライバシー要件を実装する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、プライバシー要件を実装するためのベストプラクティスについて説明します。

プライバシー規制を使うと、ユーザーデータの取得、処理、保存、管理の方法をそれぞれ定義できます。データ（ユーザーから受け取るデータを含む）の所有者であるため、プライバシー管理の多く（Cookie の管理、セッション管理、ユーザー権限の取得など）はお客様の責任です。

Google Cloud には、次に挙げるようなプライバシーを改善する管理の仕組みが含まれています。

デフォルトでの全データの暗号化（保存時、転送中、処理中）。
インサイダーアクセスに対する保護対策。
多数のプライバシー規制への対応。

詳細については、Google Cloud のプライバシーに対するコミットメントをご覧ください。

機密データを分類する

どのデータが機密であるかを定義し、その機密データを適切に保護する必要があります。機密データには、クレジットカード番号、住所、電話番号、その他の個人情報（PII）などが含まれる場合があります。

Sensitive Data Protectionを使用すると、適切な分類を設定できます。そうすると、Google Cloud にデータを保存する前に、タグ付けおよびトークン化ができるようになります。詳細については、データを自動的に分類するをご覧ください。

機密データへのアクセスを禁止する

VPC Service Controls を使って機密データをそのサービス境界に配置し、そのデータに対する Google Identity and Access Management（IAM）アクセス制御を設定します。機密データへのアクセスを必要とするユーザー全員向けに多要素認証（MFA）を構成します。

詳細については、境界を超えるデータの移動を制御するおよびSSO と MFA を設定するをご覧ください。

フィッシング攻撃をモニタリングする

メールシステムがフィッシング攻撃から保護されるように構成されていることを確認します。フィッシング攻撃は、詐欺やマルウェアの攻撃によく使用されます。

組織で Gmail を使用している場合は、高度なフィッシングおよびマルウェア保護を利用できます。この一連の設定により、メールを検疫し、異常な種類の添付ファイルを防御し、なりすましメールから保護できます。セキュリティサンドボックスは、添付ファイル内のマルウェアを検出します。Gmail は、最新のセキュリティ改善と保護機能を使用するよう継続的かつ自動的に更新されるため、組織のメールを安全に保てます。

ハイブリッドな勤務形態にゼロトラストセキュリティを拡張する

ゼロトラストセキュリティモデルとは、組織のネットワークの内か外かにかかわらず、ユーザーを無条件では信頼しないということを意味します。IAM システムがアクセスリクエストを確認する場合、ゼロトラストのセキュリティ体制とは、ユーザーの ID とコンテキスト（IP アドレスやロケーションなど）の両方が考慮されることを意味します。VPN とは異なり、ゼロトラストセキュリティでは、アクセス制御がネットワークの境界からユーザーとそのデバイスに移ります。ゼロトラストセキュリティによって、ユーザーはどこからでもより安全に作業できます。たとえば、自宅にいながらノートパソコンやモバイルデバイスから組織のリソースにアクセスできます。

Google Cloud では、BeyondCorp Enterprise と Identity-Aware Proxy（IAP）を構成し、Google クラウドリソースに対するゼロトラストを有効にできます。ユーザーが Google Chrome を使用していて、BeyondCorp Enterprise を有効にしている場合は、ゼロトラストセキュリティをユーザーのブラウザに統合できます。

次のステップ

セキュリティとプライバシーの詳細については、次のリソースをご覧ください。

ロギングと検出制御を実装する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、ロギングと検出制御を実装するためのベストプラクティスについて説明します。

検出制御では、テレメトリーを使用して構成ミス、脆弱性、クラウド環境に潜む不正アクティビティを検出します。Google Cloud では、ご利用の環境用に合わせたモニタリングと検出制御を作成できます。このセクションでは、こうした追加機能とそれらの機能を使用する際の推奨事項について説明します。

ネットワークパフォーマンスをモニタリングする

Network Intelligence Center では、ネットワークトポロジとアーキテクチャのパフォーマンスを視覚的に確認できます。ネットワークパフォーマンスに関する詳細な分析情報を取得し、取得した情報を使用してサービスに対するボトルネックを排除することで、デプロイを最適化できます。接続テストでは、ネットワークパスに適用されるファイアウォールルールとポリシーに関する分析情報が提供されます。

データの引き出しをモニタリングして防ぐ

データの引き出しは、組織にとって主要な懸念事項です。通常、データの引き出しは、認可された人物が安全なシステムからデータを抽出し、そのデータを認められていない関係者と共有する場合や、安全でないシステムに移動させる場合に発生します。

Google Cloud には、データの引き出しの検出と防止に役立つ複数の機能とツールが用意されています。詳細については、データ漏洩の防止をご覧ください。

モニタリングを一元管理する

Security Command Center を使用すると、Google Cloud にあるリソースとそのセキュリティの状態を可視化できます。Security Command Center は、脅威の阻止、検出、対応に役立ちます。具体的には、仮想マシン、ネットワーク、アプリケーション、ストレージバケットのセキュリティ構成ミスの特定に使用できる一元化されたダッシュボードを提供します。これにより、ビジネス上の損害や損失が発生する前に、こうした問題に対処できます。Security Command Center に組み込まれている機能により、Cloud Logging セキュリティログ内の不審なアクティビティや、仮想マシンの不正使用を明らかにできます。

実行可能な推奨事項の実施や、ログを SIEM システムにエクスポートして詳細な調査を行うことで、脅威に対応できます。Google Cloud での SIEM システムの使用については、Google Cloud でのセキュリティログ分析をご覧ください。

Security Command Center には、インフラストラクチャのセキュリティ分析に役立つ複数の検出機能も用意されています。これらの検出機能には次の機能が含まれます。

Google Cloud Armor ログなどの他の Google Cloud サービスでも、Security Command Center に表示する検出結果を確認できます。

ワークロードに必要なサービスを有効にして、重要なデータをモニタリングして分析するだけです。サービスのロギングの有効化について詳しくは、Google Cloud のセキュリティログ分析のログを有効にするセクションをご覧ください。

脅威をモニタリングする

Event Threat Detection は、ログストリーム内の脅威を検出する Security Command Center Premium のオプションのマネージドサービスです。Event Threat Detection を使用すると、リスクが高く被害が大きい脅威（マルウェア、クリプトマイニング、Google Cloud リソースへの不正アクセス、DDoS 攻撃、ブルートフォース SSH 攻撃など）を検出できます。ツールの機能を使用して大量のログデータから情報を抽出することにより、セキュリティチームはリスクの高いインシデントを速やかに特定して修復に専念できます。

組織内の不正使用された可能性のあるユーザーアカウントを検出するには、Sensitive Actions Cloud Platform ログを使用して、機密性の高い操作がいつ実行されたかを特定し、有効なユーザーが有効な目的のためにその操作を実行したことを確認します。機密情報に関する操作とは、悪意のある人物が行うとビジネスに損害を与える可能性がある操作（高い権限を持つロールの追加など）です。Cloud Logging を使用して、Sensitive Actions Cloud Platform ログを表示、モニタリング、クエリします。また、Sensitive Actions Service を使用して、機密情報に関する操作のログエントリを表示することもできます。これは、Security Command Center Premium の組み込みサービスです。

Chronicle では、すべてのセキュリティデータを 1 か所に保存して分析できます。攻撃の全体像を把握するため、Chronicle では、ログを共通のモデルにマッピングして拡充した後、タイムラインにリンクできます。さらに、Chronicle を使用すると、検出ルールを作成し、セキュリティ侵害インジケーター（IoC）の一致率を設定して、脅威探査アクティビティを実行できます。検出ルールは YARA-L 言語で記述します。YARA-L の脅威検出ルールの例については、Community Security Analytics（CSA）リポジトリをご覧ください。独自のルールを作成するだけでなく、Chronicle のキュレーションされた検出機能を活用できます。キュレーションされた検出機能には、脅威の識別に役立つ、事前定義された一連のマネージド YARA-L ルールがあります。

セキュリティ分析、監査、調査のためにログを一元化する際のもう一つのオプションは、BigQuery を使用することです。BigQuery では、SQL クエリ（CSA リポジトリ内のクエリなど）を使用し、一般的な脅威や構成ミスをモニタリングして、権限の変更、プロビジョニングアクティビティ、ワークロードの使用状況、データアクセス、ネットワークアクティビティを分析します。設定から分析までの BigQuery のセキュリティログ分析について詳しくは、Google Cloud でのセキュリティログ分析をご覧ください。

次の図は、Security Command Center の組み込みの脅威検出機能と、BigQuery、Chronicle、またはサードパーティの SIEM で行う脅威検出の両方を使用して、モニタリングを一元化する方法を示しています。

Google Cloud でさまざまなセキュリティ分析ツールとコンテンツがやり取りする様子。

図に示すように、モニタリングする必要があるさまざまなセキュリティデータソースが存在します。これらのデータソースには、Cloud Logging のログ、Cloud Asset Inventory のアセット変更、Google Workspace のログ、ハイパーバイザまたはゲストカーネルのイベントが含まれます。この図は、Security Command Center を使用してこれらのデータソースをモニタリングできることを示しています。Security Command Center で適切な機能と脅威検出機能を有効にしている場合、このモニタリングは自動的に行われます。また、この図は、セキュリティデータと Security Command Center の検出結果を BigQuery、Chronicle、サードパーティの SIEM などの分析ツールにエクスポートして、脅威をモニタリングできることも示しています。この図は、分析ツールにおいて、CSA で利用できるクエリやルールを使用して拡張することで、さらなる分析と調査を実施できることを示しています。

次のステップ

以下のリソースで、ロギングと検出についての詳細を確認する。

Google Cloud アーキテクチャフレームワーク: 信頼性

Google Cloud アーキテクチャフレームワークのこのカテゴリでは、クラウドプラットフォーム上で信頼性の高いサービスを設計、運用する方法について説明します。また、信頼性をサポートする Google Cloud プロダクトと機能についても説明します。

アーキテクチャフレームワークでは、ベストプラクティスを記載して、実装上の推奨事項を紹介し、利用可能ないくつかのプロダクトやサービスについて説明します。このフレームワークは、ビジネスニーズに合わせて Google Cloud 環境を設計できるようにすることを目的としています。

信頼性の高いサービスを実行するには、アーキテクチャに次のことを含める必要があります。

測定可能な信頼性の目標。目標とのギャップは迅速に修正します。
スケーラビリティ、高可用性、障害復旧、自動化されたチェンジマネジメントのための設計パターン。
可能な限り自己修復を行うコンポーネントと、オブザーバビリティのための計測を含むコード。
オペレーターの手動による作業と認知負荷を最小限に抑えてサービスを実行し、障害を迅速に検知して軽減できる運用手順。

信頼性は、開発、製品管理、運用、サイト信頼性エンジニアリング（SRE）など、エンジニアリングに携わる全員の責任です。すべての担当者に説明責任があり、アプリケーションの信頼性目標と、リスクおよびエラーバジェットを理解している必要があります。チームでは、作業に優先順位を付け、信頼性と製品機能の開発の優先度で対立が起きると適切にエスカレーションを行えるようにする必要があります。

アーキテクチャフレームワークの信頼性カテゴリでは、次の方法について説明します。

信頼性の原則

アーキテクチャフレームワークのこのドキュメントでは、クラウドプラットフォームで信頼性の高いサービスを実行するための基本原則をいくつか説明します。これらの原則は、一部の Google Cloud プロダクトと機能が信頼性の高いサービスにどのように対応しているかを示す、アーキテクチャフレームワークの追加のセクションを読む際に共通の理解を得るのに役立ちます。

主な用語

信頼性の手法に関連する一般的な用語がいくつかあります。多くの読者にはすでにおなじみかもしれませんが、必要に応じて、用語ページで詳細な説明をご確認ください。

基本原則

Google の信頼性に対するアプローチは、次の中心的原則に基づいています。

信頼性は最優先の機能

短期的には、新しいプロダクトの機能が最優先事項であることもあります。しかし、長期的には、信頼性が最も重要なプロダクトの機能となります。プロダクトの動作が遅すぎるか、長期にわたって利用できない場合は、ユーザーが離れ、他のプロダクト機能との関連性がなくなる可能性があるためです。

信頼性はユーザーによって定義される

ユーザー向けのワークロードの場合は、ユーザーエクスペリエンスを測定します。ユーザーがサービスのパフォーマンスに満足する必要があります。たとえば、CPU 使用率などのサーバー指標だけでなく、ユーザーリクエストの成功率を測定します。

バッチおよびストリーミングのワークロードでは、ディスク使用量などのサーバー指標ではなく、時間枠ごとにスキャンされる行などのデータスループットに関する重要業績評価指標（KPI）の測定が必要になる場合があります。スループット KPI を使用すると、ユーザーが要求した日単位または四半期単位のレポートを予定どおりに作成できます。

100% の信頼性を目指す必要はない

システムは、ユーザーが満足できるほど十分に信頼できるものでなければなりませんが、投資が正当化されないほど高い信頼性は必要ありません。必要な信頼性のしきい値を設定する SLO を定義し、エラーバジェットを使用して適切な変化率を管理します。

このフレームワークの設計と運用の原則をプロダクトに適用するのは、そのプロダクトまたはアプリケーションの SLO がコストを正当化する場合に限ります。

信頼性と迅速なイノベーションは相互補完的

エラーバジェットを使用すると、システムの安定性とデベロッパーのアジリティのバランスを取ることができます。以下のガイダンスを参考にして、迅速に動けるタイミングと速度を落とすべきタイミングを判断してください。

十分なエラーバジェットが利用可能であれば、迅速にイノベーションを実現し、プロダクトの改善や機能の追加を行うことができます。
エラーバジェットが減ったら、速度を落として信頼性機能に重点を置きます。

設計と運用の原則

システムの信頼性を最大限に高めるには、次の設計と運用の原則を適用します。この 3 つの原則については、以降のアーキテクチャフレームワークの信頼性カテゴリで詳しく説明します。

信頼性の目標を定義する

アーキテクチャフレームワークのこのセクションで説明するベストプラクティスは次のとおりです。

適切な SLI を選択する。
ユーザーエクスペリエンスに基づいて SLO を設定する。
SLO を反復的に改善する。
厳格な内部 SLO を使用する。
エラーバジェットを使用して開発速度を管理する。

詳細については、アーキテクチャフレームワークの信頼性カテゴリの信頼性の目標を定義するをご覧ください。

インフラストラクチャとアプリケーションにオブザーバビリティを組み込む

アーキテクチャフレームワークのこのセクションでは、次の設計原則について説明します。

コードを計測してオブザーバビリティを最大化する。

詳細については、アーキテクチャフレームワークの信頼性カテゴリのインフラストラクチャとアプリケーションにオブザーバビリティを組み込むをご覧ください。

スケーラビリティと高可用性を実現する設計

アーキテクチャフレームワークのこのセクションでは、次の設計原則について説明します。

冗長性を作成して高可用性を実現する。
障害復旧のために複数のリージョン間でデータを複製する。
リージョンの停止に対する耐障害性を確保するためにマルチリージョンアーキテクチャを設計する。
スケーラビリティのボトルネックを排除する。
過負荷状態の場合にサービスレベルを適切に下げる。
トラフィックの急増を回避し、軽減する。
入力をサニタイズして検証する。
機能を維持しながらフェイルセーフを実現する。
再試行できるように API 呼び出しとオペレーションコマンドを設計する。
システムの依存関係を特定して管理する。
重要な依存関係を最小化する。
すべての変更をロールバックできるようにする。

詳細については、アーキテクチャフレームワークの信頼性カテゴリのスケーリングと高可用性の設計をご覧ください。

信頼性の高い運用プロセスとツールを作成する

アーキテクチャフレームワークのこのセクションでは、次の運用原則について説明します。

アプリケーションとサービスに適切な名前を選択する。
カナリアテストの手順で漸進型ロールアウトを実装する。
期間限定のプロモーションやリリースのトラフィックを分散させる。
ビルド、テスト、デプロイのプロセスを自動化する。
オペレーターエラーに対して防御する。
障害復旧手順をテストする。
障害復旧テストを実施する。
カオスエンジニアリングを実践する。

詳細については、アーキテクチャフレームワークの信頼性カテゴリの信頼性の高い運用プロセスとツールの作成をご覧ください。

効率的なアラートを作成する

アーキテクチャフレームワークのこのセクションでは、次の運用原則について説明します。

アラートの遅延を最適化する。
原因ではなく症状をアラート対象にする。
平均ではなく、外れ値に関するアラートを作成する。

詳細については、アーキテクチャフレームワークの信頼性カテゴリの効率的なアラートを作成するをご覧ください。

共同インシデント管理プロセスを構築する

アーキテクチャフレームワークのこのセクションでは、次の運用原則について説明します。

明確なサービスオーナーを割り当てる。
適切に調整されたアラートによって検出時間（TTD）を短縮する。
インシデント管理計画とトレーニングによって軽減時間（TTM）を短縮する。
ダッシュボードのレイアウトとコンテンツを設計して TTM を最小化する。
既知の停止シナリオの診断手順と軽減策を文書化する
過失を責めない事後検証により、サービス停止の教訓を活かして再発を防止する。

詳細については、アーキテクチャフレームワークの信頼性のカテゴリに含まれる共同インシデント管理プロセスを構築するをご覧ください。

次のステップ

信頼性の目標を定義する（このシリーズの次のドキュメント）

アーキテクチャフレームワークの他のカテゴリ、たとえば、システム設計、オペレーショナルエクセレンス、セキュリティ、プライバシー、コンプライアンスなどを確認する。

信頼性の目標を定義する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、信頼性の高いサービスを実行するために、サービスのカスタマーエクスペリエンスを測定する適切な方法を定義するためのベストプラクティスについて説明します。定義したサービスレベル目標（SLO）をイテレーションし、エラーバジェットを使用して、追加の更新をリリースしたときに信頼性が損なわれる可能性がある場合を調べる方法を学習します。

適切な SLI を選択する

適切なサービスレベル指標（SLI）を選択して、サービスのパフォーマンスを完全に把握することが重要です。たとえば、アプリケーションに、複数の独立したユーザーが使用する SaaS アプリケーションで一般的なマルチテナントアーキテクチャがある場合、テナントごとのレベルで SLI をキャプチャします。SLI がグローバルな集計レベルでのみ測定される場合、1 人の重要なユーザーや少数のユーザーに影響するアプリケーションの重大な問題が見逃される可能性があります。代わりに、各ユーザーのリクエストにテナント ID を含めて、その ID がスタックの各レイヤに反映されるようにアプリケーションを設計します。この ID により、モニタリングシステムは、リクエストパスに沿ったすべてのレイヤまたはマイクロサービスにおいて、テナントごとのレベルで統計情報を集計できるようになります。

以下の例に示すように、実行するサービスの種類によって、モニタリングする SLI も決まります。

サービス提供システム

データを提供するシステムでは、次の SLI が一般的です。

可用性は、サービスが使用可能な時間の割合を示します。多くの場合、処理が成功する適切な形式のリクエストの割合（99% など）で定義されます。
レイテンシは、一定割合のリクエストが処理される速さを示します。多くの場合、50 以外のパーセンタイル（300 ミリ秒の 99 パーセンタイルなど）で定義されます。
品質は、特定のレスポンスの品質を示します。多くの場合、品質の定義はサービス別であり、リクエストに対するレスポンスのコンテンツが理想的なレスポンスのコンテンツとどの程度異なるかを示します。レスポンスの品質は、バイナリ（良好または不良）または 0～100% のスケールで表すことができます。

データ処理システム

データを処理するシステムでは、次の SLI が一般的です。

カバレッジは、処理されたデータの割合（99.9% など）を示します。
正確性は、正しいとみなされる出力データの割合（99.99% など）を示します。
鮮度は、ソースデータまたは集計された出力データがどれくらい新しいかを示します。通常は、更新が最近であるほど（20 分など）高くなります。
スループットは、処理中のデータ量を示します（500 MiB/秒、1,000 リクエスト/秒（RPS）など）。

ストレージシステム

データを保存するシステムでは、次の SLI が一般的です。

耐久性は、システムに書き込まれたデータを将来取得できる可能性を示します（99.9999% など）。永続的なデータ損失インシデントは耐久性指標を低下させます。
ストレージシステムのスループットとレイテンシも一般的な SLI です。

SLI を選択し、ユーザーエクスペリエンスに基づいて SLO を設定する

このアーキテクチャフレームワークセクションに含まれる中心的原則の 1 つは、信頼性がユーザーによって定義されることです。できるだけユーザーに近い信頼性の指標を測定します。たとえば、次のオプションを測定します。

可能であれば、モバイルまたはウェブクライアントを計測します。
- たとえば、Firebase Performance Monitoring を使用すると、iOS アプリ、Android アプリ、ウェブアプリのパフォーマンス特性を把握できます。
それができない場合は、ロードバランサを計測します。
- たとえば、外部アプリケーションロードバランサのロギングとモニタリングには Cloud Monitoring を使用します。
最後の手段として、サーバーで信頼性を測定します。
- たとえば、Cloud Monitoring を使用して Compute Engine インスタンスをモニタリングします。

SLO は、ほぼすべてのユーザーがサービスに満足する程度に設定し、それ以上には設定しません。ネットワークの接続性などのクライアント側の一時的な問題のために、アプリケーションで短時間に発生する信頼性の問題に気付けないことがあり、それにより SLO を下げることができます。

稼働時間やその他の重要な指標については、100% を超える設定はできませんが、それに近い目標を設定するようにしてください。サービスオーナーは、外部の契約レベルに基づいて目標を設定するだけでなく、ほとんどのユーザーが満足できる最小レベルのサービスパフォーマンスと可用性を客観的に評価する必要があります。

変更する頻度は、システムの信頼性に影響します。ただし、小さな変更を頻繁に行うことができるため、より迅速に、より高い品質で機能を提供できます。カスタマーエクスペリエンスに合わせて達成可能な信頼性の目標により、ユーザーが許容できる最大の変更頻度と変更範囲（フィーチャーベロシティ）を定義できます。

カスタマーエクスペリエンスを測定して目標を定義できない場合は、競合するベンチマーク分析を実施します。比較できる競合がない場合は、目標が未定義の場合でも、カスタマーエクスペリエンスを測定します。たとえば、システムの可用性や、ユーザーにとって意味のある成功したトランザクションの割合を測定します。これは、販売店における注文数、またはカスタマーサポートの問い合わせ数、カスタマーサポートのチケット数、それらの重要度などのビジネス指標や KPI と関連付けることができます。一定期間が経過すると、このような相関関係を使用して顧客満足度の妥当なしきい値に到達できます。このしきい値が SLO です。

SLO を反復的に改善する

SLO の設定を固定しないでください。四半期ごと、または少なくとも年に 1 回は SLO を見直し、ユーザーの満足度を常に正確に反映して、サービス停止との相関関係を保つようにしてください。現行のビジネスニーズと新しいクリティカルユーザージャーニーをカバーしていることを確認します。これらの定期的なレビューの後に、SLO を見直し、必要に応じて拡大します。

厳格な内部 SLO を使用する

外部 SLA よりも厳格な内部 SLO を使用することをおすすめします。SLA に違反すると信用状の発行や顧客への払い戻しが必要になる傾向があるため、財務上の影響が発生する前に問題に対処する必要があります。

これらのより厳密な内部 SLO を使用して、責任を追及されないように事後処理とインシデントのレビューを行うことをおすすめします。詳細については、アーキテクチャセンターの信頼性のカテゴリに含まれる共同インシデント管理プロセスを構築するをご覧ください。

エラーバジェットを使用して開発速度を管理する

エラーバジェットにより、一定期間において自システムの信頼性が必要とされる値を上回っているか下回っているかがわかります。エラーバジェットは、たとえば 30 日といった期間について「100% – SLO」で計算されます。

エラーバジェットに容量が残っていれば、引き続き改善または新機能をすばやくリリースできます。エラーバジェットがゼロに近い場合は、サービスの変更を停止または抑制し、エンジニアリングリソースを信頼性に関する機能の向上に投資します。

Google Cloud のオペレーションスイートには、SLO モニタリングが含まれていて、SLO とエラーバジェットを設定する手間を最小限に抑えることができます。オペレーションスイートには、SLO の手動構成に役立つグラフィカルユーザーインターフェース、SLO をプログラムで設定できる API、エラーバジェットのバーンレートをトラッキングするための組み込みダッシュボードが含まれています。詳細については、SLO の作成方法をご覧ください。

推奨事項

アーキテクチャフレームワークのガイダンスを実際の環境に適用するには、次の推奨事項に従ってください。

サービスの可用性やレイテンシなど、顧客を中心とした SLI を定義して測定します。
外部 SLA よりも厳しい顧客中心のエラーバジェットを定義します。本番環境の停止など、違反した場合の結果を含めます。
レイテンシ SLI を設定して外れ値（90 パーセンタイルや 99 パーセンタイルなど）をキャプチャし、最も遅いレスポンスを検出します。
少なくとも年に 1 回は SLO を見直し、ユーザーの満足度とサービス停止との間に十分な相関関係があることを確認します。

次のステップ

次のリソースで信頼性の目標を定義する方法を学習する。

インフラストラクチャとアプリケーションにオブザーバビリティを確立する（このシリーズの次のドキュメント）
Coursera - SRE: 信頼性の測定と管理
SRE Book の SLO に関する章と SLO を実装するための SRE ワークブック
SLI 指標を調整する

SLO を定義する

このドキュメントは、オンラインサービスを運営するチームがサービスレベル目標（SLO）を使用してサイト信頼性エンジニアリング（SRE）の文化の構築と導入を開始する方法を説明する 2 部構成ドキュメントのパート 1 です。SLO とは、サービスの信頼性目標レベルです。

Software as a Service（SaaS）では、プロダクトの開発速度とオペレーションの安定性との間に自然な緊張関係があります。システムを変更すればするほど、システムが破損する可能性が高くなります。モニタリングツールやオブザーバビリティツールを使用すれば、開発を加速してもオペレーションの安定性に対する信頼を維持できます。このようなツール（アプリケーションパフォーマンス管理（APM）ツール）は重要ですが、その用途で最も重要なものの 1 つに、SLO の設定があります。

SLO を適切に定義すれば、安定性を犠牲にすることなく、開発を加速するデータドリブンのオペレーション決定をチームが行えるようになります。SLO を使用することで、単一の合意形成された目標に沿うように開発チームと運用チームを配置することもできます。これにより、プロダクトの作成と反復（開発）およびシステムの整合性の維持（オペレーション）という 2 つの目標の間にある自然な緊張関係を緩和できます。

SLO の詳細については、SRE ブックと SRE ワークブックをご覧ください。その他の SRE プラクティスに関しても説明されています。このシリーズでは、SLO の理解と開発のプロセスを簡素化し、SLO をより簡単に導入できるようにすることを目的としています。これらの記事を読み理解すれば、上記の本でより多くを学習できるようになります。

このシリーズは、組織に SLO を実装するための明確な道筋を示すことを目的としています。

このドキュメントでは、SLO とは何かについて、およびサービスで SLO を定義する方法について確認します。
SLO の導入では、ワークロードの種類に基づく SLO のさまざまな種類、SLO の測定方法、SLO に基づくアラートの開発方法を説明しています。

このシリーズは、オンラインサービスの安定性と信頼性を担当する SRE、オペレーションチーム、DevOps、システム管理者などを対象としています。この記事では、インターネットサービスがウェブブラウザやモバイルデバイスと通信する方法を理解し、ウェブサービスのモニタリング、デプロイ、トラブルシューティングの方法の基本を理解されていることを前提としています。

State of DevOps で、ソフトウェアデリバリーのパフォーマンスを向上させると認められた機能が報告されています。このシリーズでは、次の機能について説明します。

SLO が必要な理由

SRE の文化を構築する際、SLO から始める理由は何でしょうか。その理由は端的に言えば、サービスレベルを定義しなければ、顧客がサービスに満足しているかを測定することが困難になるためです。サービスレベルが定義されていない場合、（サービスを改善できることがわかっている場合でも）改善のためにどこにどれだけ投資するかを決定することが困難になります。

ユーザー向けかどうかに関係なく、すべてのサービスで個別の SLO を開発したくなることがあります。たとえば、2 つ以上のサービス（たとえば、フロントエンドサービスとバックエンドデータストア）で、ユーザーが両方のサービスに依存しているが、それらを区別できない場合に、個別に測定してしまうことがよくある間違いです。よりよいアプローチは、プロダクト（サービスのコレクション）に基づいて SLO を開発し、ユーザーがこのプロダクトと行う最も重要なインタラクションに焦点を合わせることです。

そのため、効果的な SLO を開発するために、クリティカルユーザージャーニー（CUJ）と呼ばれる、ユーザーとサービスとのインタラクションを理解することが理想です。CUJ では、ユーザーの目的と、ユーザーがその目的の達成のためにサービスをどのように使用するかが考慮されます。CUJ は、サービスの境界線を考慮せずに顧客の視点で定義されます。CUJ が満たされていれば顧客は満足であり、顧客の満足度がサービスの成功の重要な尺度になります。

サービスに対する顧客の満足度の重要な側面は、サービスの信頼性です。サービスが信頼できるかどうかは、サービスの内容以前の問題です。そのため、いかなるサービスにおいても信頼性が最も重要となります。一般的な信頼性の指標に稼働時間があります。通常これは、システムが稼働していた時間の長さを意味します。しかし、より有用で正確な指標である可用性の使用をおすすめします。可用性も、システムが稼働しているかどうかに関する指標ですが、システムが停止してからの時間を測定するよりも正確に稼働状況を測定できます。今日の分散システムではサービスが部分的に停止することがあり、これは稼働時間の測定でうまく捉えることはできません。

可用性は、9 の数でしばしば表現されます。たとえば、99.9% の可用性（スリーナイン）や 99.99% の可用性（フォーナイン）などがあります。可用性の SLO を測定することは、システムの信頼性を測定するための最良の方法の 1 つです。

オペレーションの成功を定義する際に SLO は有用ですが、リソースを投資する対象を選択する際にも SLO を活用できます。たとえば SRE ブックでは、9 の桁数を増やすエンジニアリングの取り組みが、費用の増加と限界効用の問題に直面することが指摘されています。一般に、可用性に 9 をもう 1 つ加えるためには、その前の 9 でかかった費用の 10 倍の費用がかかると考えられています。

SLI を選択する

SLO を達成している（問題ない）かどうかを判断するには、測定を行う必要があります。この測定で得られる指標は、サービスレベル指標（SLI）と呼ばれます。SLI では、顧客に提供するサービスのレベルが測定されます。理想的には、SLI は承認済みの CUJ と結びついています。

最適な指標を選択する

SLI の開発の最初の手順は、測定する指標を選択することです。これには、1 秒あたりのリクエスト数、1 秒あたりのエラー数、キューの長さ、特定の期間内のレスポンスコードの分布、送信バイト数などがあります。

これらの指標は、以下の種類のいずれかになることがほとんどです。

カウンター。たとえば、ある測定ポイントまでに発生したエラーの数など。このタイプの指標は増加することはありますが、減少することはありません。
分布。特定の期間に特定の測定セグメントに入ったイベントの数など。たとえば、完了するまでに 0～10 ミリ秒、11～30 ミリ秒、31～100 ミリ秒かかったリクエストの数をそれぞれ測定できます。結果は、バケットごとのカウントになります（例: [0-10: 50]、[11-30: 220]、[31-100: 1103]）。
ゲージ。キューの長さなど、システムの測定可能な部分の実際の値。このタイプの指標は増加することも減少することもあります。

これらの種類の詳細については、Prometheus プロジェクトのドキュメントと Cloud Monitoring の指標の種類の ValueType と MetricKind をご覧ください。

SLI に関する重要な違いとして、すべての指標は SLI ではありません。実際、SRE ワークブックに次のような記載があります（強調付き）。

「SLI を 2 つの数値の比率として扱うことを通常はおすすめしています。すなわち、良いイベントの数をイベントの総数で割ります。」

「この場合の SLI の範囲は 0～100% であり、0% は何も動作していない、100% は何も壊れていないという意味になります。この尺度は直感的に理解できます。また、このスタイルはエラーバジェットのコンセプトに容易に適応します。」

ソフトウェア企業の多くが数百、数千の指標をトラックしていますが、SLI として適格な指標はその中のほんの一握りです。では、イベントの総数に対する良いイベントの割合の他に、良い SLI として使える指標には何があるでしょうか。適切な SLI 指標には以下のような特徴があります。

指標とユーザーの満足度が直接関係している。一般に、サービスが期待どおりに動作しない、動作に失敗する、動作が遅い場合、ユーザーの満足度は低下します。SLO がこれらの指標に基づいている場合、SLI をユーザーの満足度を示す他のシグナル（たとえば、苦情チケットの数、サポートの問い合わせの量、ソーシャルメディアの感情、エスカレーション）と比較することで、SLO の検証を行えるようになります。使用している指標がユーザーの満足度の指標に対応していない場合は、SLI として適した指標ではない可能性があります。
指標の悪化とサービスの停止が相関している。サービスの停止時に良好な状態であるとして表示される指標は、SLI に適した指標ではありません。通常のオペレーション中に良好な状態ではないとして表示される指標も、SLI に適した指標ではありません。
指標の信号雑音比が良好。偽陰性や偽陽性が高頻度で発生する指標は適切な SLI ではありません。
指標が、顧客の満足度に応じて単調に、ほぼ直線的にスケーリングされる。指標が改善するにつれて、顧客の満足度も向上します。

次の図のグラフについて考えてみましょう。サービスの SLI として使用される可能性がある 2 つの指標の時間に伴う変化がグラフ化されています。サービスが低下している期間は赤色で、サービスが良好である期間は青でハイライト表示されています。

SLI が適切ではない場合のグラフでは、ユーザーが満足していない期間とネガティブなイベント（サービスの低下、遅延、停止など）が直接対応していません。また、SLI はユーザーの満足度とは無関係に変動しています。SLI が適切な場合のグラフでは、SLI とユーザーの満足度は相関しています。また、満足度のレベルの違いが明確であり、無関係な変動がはるかに少なくなっています。

適切な数の指標を選択する

通常、1 つのサービスに複数の SLI が対応します。特にサービスが行う作業のタイプや、サービスを提供されるユーザーのタイプが異なる場合です。たとえば、読み取りリクエストと書き込みリクエストは別々の方法で動作する傾向があるため、これらを分離することは推奨されます。この場合、各サービスごとに適した指標を選択することが最適です。

一方で、多くのサービスはサービスどうしで類似した種類の作業を行うため、直接比較できます。たとえば、オンラインマーケットプレイスの場合、ユーザーはホームページを表示する、サブカテゴリやトップ 10 リストを表示する、詳細ページを表示する、または商品を検索することが考えられます。これらの各アクションで個別の SLI を開発して測定するのではなく、単一の SLI カテゴリ（たとえば、ブラウズサービス）に結合できます。

類似したカテゴリのアクション間でユーザーの期待が大きく変化することは実際にはありません。ユーザーの満足度は、ブラウジングするデータの構造（データがプロモーション商品の静的リストから取得されたか、巨大なデータセットに対する機械学習支援の検索による結果から動的に生成されたか）には関係しません。ユーザーの満足度は、「商品の全ページをすぐに表示できたか？」という質問の回答から定量化できます。

サービスの許容範囲を正確に表現できる、可能な限り少ない数の SLI を使用することが理想的です。通常、1 つのサービスには 2～6 個の SLI が必要です。SLI が少なすぎる場合、重要なシグナルを見落とす可能性があります。SLI が多すぎると、実用性がほとんどない数多くの指標をオンコールチームがトラックしなければならなくなります。SLI は、本番環境の健全性をシンプルに把握でき、対象を把握できているという感覚を与えるものであることが必要です。

SLO を選択する

SLO は以下の値で構成されます。

SLI。たとえば、レスポンスの総数に対する HTTP コード 200 のレスポンスの数の割合など。
期間。指標が測定される期間です。この期間は、カレンダーベース（月の最初の日から翌月の初日までなど）やローリングウィンドウ（過去 30 日間など）で指定できます。
目標。たとえば、特定の期間に達成することが期待されるイベント全体に対する適切なイベントの目標割合（99.9% など）。

SLO を開発する際、その期間と目標を定義することが難しい場合があります。このプロセスを始める際の 1 つの方法として、SLI を特定し、時間に伴う変化をグラフ化することがあります。使用する期間と目標を決定できない場合には、SLO をすぐに完璧なものにする必要はありません。SLO を繰り返し処理し、顧客の満足度と一致させ、ビジネスニーズに合うようにします。1 か月の間はツーナイン（99.0%）から始めてみてください。

デプロイ、停止、毎日のトラフィックパターンなどのイベント中の SLO コンプライアンスをトラッキングすると、どの目標が良いか、悪いか、許容可能かに関する分析情報を取得できます。たとえば、バックグラウンドプロセスの場合に、75% の成功で十分と定義するなどできます。しかし、ミッションクリティカルでユーザーと接触するリクエストの場合は、99.95% など、より積極的な目標を設定してもよいでしょう。

もちろん、すべてのユースケースに適用できる、ただひとつの SLO は存在しません。SLO は、いくつかの要素に応じて変化します。

顧客の期待
ワークロードタイプ
サービスの提供、実行、モニタリングのためのインフラストラクチャ
問題となるドメイン

このシリーズのパート 2 SLO を導入するでは、ドメインに依存しない SLO に焦点を当てます。ドメインに依存しない SLO（サービスの可用性など）は、高レベルのインジケーター（毎分販売されるウィジェット数など）に置き換わるものではありません。しかしながら、ビジネスユースケースにかかわらず、サービスの動作の有無について測定する際に活用できます。

ドメインに依存しないインジケーターは多くの場合、1 つの質問にまとめることができます（たとえば、「サービスは利用可能ですか？」、「サービスの速度は十分ですか？」）。可用性とレイテンシの 2 つの要素を考慮した SLO には、この質問の回答が含まれることがよくあります。SLO は、次のように記述できます。ここで、X = 99.9%、Y = 800 ms です。

有効なリクエストの X% が成功し、Y ms より早く成功しています。

次のステップ

SLO を導入するを読む。この記事では、これらの定義についての詳細を探索し、さまざまなワークロードの種類に対して、より適した他の SLI を紹介しています。
他の SRE リソースを確認する。
- SRE ブック
- SRE ワークブック
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。
DevOps に関するリソースを読む。
このシリーズに関連する DevOps 機能の詳細については、以下をご覧ください。
DevOps のクイックチェックを確認する。業界におけるご自身の立ち位置を把握できます。

SLO を導入する

このドキュメントでは、さまざまな種類の一般的なサービスワークロードに役立つサービスレベル目標（SLO）をいくつか定義します。このドキュメントは 2 部構成の後半です。パート 1 SLO を定義するでは、SLO について紹介し、サービスレベル指標（SLI）から SLO がどのように導出されるか、そしてどのような SLO が適切かについて説明しています。

State of DevOps で、ソフトウェアデリバリーのパフォーマンスを向上させると認められた機能が報告されています。これら 2 つのドキュメントでは、次の機能について説明します。

測定データ

ドメインにかかわらず、多くのサービスが共通の機能を共有し、一般的な SLO を使用できます。以下では、サービスタイプ別に一般的な SLO に関して考察しており、各 SLO に適用される SLI について詳しく説明します。

リクエスト主導型サービス

リクエスト主導型サービスは、クライアント（別のサービスまたはユーザー）からリクエストを受け取り、なんらかの計算を行い、ネットワークリクエストをバックエンドに送信し、続いてクライアントにレスポンスを返します。リクエスト主導型サービスは、多くの場合、可用性 SLI とレイテンシ SLI によって測定されます。

SLI としての可用性

可用性の SLI は、サービスが稼働しているかどうかを示します。可用性の SLI は次のように定義されます。

正常に処理された有効なリクエストの割合。

最初に、「有効」の定義を決める必要があります。基本的な定義としては、「長さがゼロでないこと」や「クライアントサーバープロトコルに準拠していること」などが考えられますが、「有効」の定義を決定するのはサービスオーナーです。有効性を評価する一般的な方法は、HTTP（または RPC）レスポンスコードを使用することです。たとえば、通常、HTTP 500 エラーは SLO にカウントされるサーバーエラーと判断され、400 エラーはクライアントエラーで SLO にカウントされません。

測定対象を決めたら、システムから返されたすべてのレスポンスコードを調べ、アプリケーションがそれらのコードを適切かつ一貫して使用していることを確認します。SLO のエラーコードを使用する場合は、コードがサービスに対するユーザーエクスペリエンスの正確な指標であるかどうかを確認することが重要です。たとえば、ユーザーが在庫切れの商品を注文しようとした場合、サイトは中断してエラーメッセージを返しますか、それとも類似商品を提案しますか。SLO で使用するには、エラーコードをユーザーの期待に関連付ける必要があります。

開発者がエラーの取り扱いを誤るということも考えられます。ユーザーが一時的に在庫切れの商品をリクエストした場合に、開発者が誤ってエラーを返すようプログラムしている場合があります。しかし、実際にはシステムは正しく機能しており、エラーは発生していません。コードはユーザーが必要なアイテムを購入できなくても、成功として返す必要があります。もちろん、このサービスのオーナーは商品が在庫切れであることを把握する必要があります。ただし、販売できないからといって、お客様にとってエラーが発生したわけではなく、SLO にカウントされるべきではありません。ただし、サービスがデータベースに接続できないためアイテムの在庫があるか判断できない場合は、エラーとなり、エラーバジェットにカウントされます。

サービスがより複雑である場合も考えられます。たとえば、サービスが非同期リクエストを処理している場合や、実行時間が長いプロセスをユーザーに提供している場合が該当します。このような場合は、別の方法で可用性を公開できます。ただし、やはり可用性は成功した有効なリクエストの割合として表すことをおすすめします。可用性は、お客様のワークロードがリクエストどおりに実行される時間（分）として定義できます（このアプローチは、可用性を測定するための「良好な時間」の方法と呼ばれることもあります）。仮想マシンの可用性は、VM に SSH でアクセスできる、VM の最初のリクエスト後の分数の割合で測定できます。

SLI としてのレイテンシ

レイテンシ（速度ともいいます）の SLI は、サービスの速度が十分かどうかを示します。レイテンシの SLI は可用性と同様に定義されます。

しきい値よりも速く処理された有効なリクエストの割合。

レイテンシを測定するには、リクエストタイプごとのタイマーの開始と停止までの時間差を計算します。重要なことは、ユーザーによってレイテンシが認識されるかどうかです。よくある間違いは、レイテンシを正確に測定しすぎることです。実際には、更新に 100 ミリ秒（ms）要する場合と 300 ミリ秒要する場合の差異をユーザーは識別できません。また、300～1,000 ミリ秒の範囲であれば許容範囲とする可能性があります。

代わりに、アクティビティベースの指標を開発することをおすすめします。そうすることで、ユーザーは次のプロセスに集中できます。

操作: 1,000 ミリ秒。ユーザーが要素をクリックした後、結果を待つ時間。
書き込み: 1,500 ミリ秒。基盤となる分散システムを変更する。システムには遅いとみなされますが、ユーザーには許容される傾向があります。指標に関しては、書き込みと読み取りを明示的に区別することをおすすめします。
バックグラウンド: 5,000 ミリ秒。データの定期更新やその他の非同期リクエストなど、ユーザーに表示されないアクション。

レイテンシは一般に分布として測定されます（このシリーズのパート 1 の SLI の選択をご覧ください）。分布に応じて、さまざまなパーセンタイルを測定できます。たとえば、過去の 99 パーセンタイルよりも遅いリクエストの数を測定できます。ここでは、過去の分布を調査することで設定されたこのしきい値よりも速いイベントを良好なイベントとみなします。このしきい値は、製品要件に基づいて設定することもできます。通常のレイテンシとテールレイテンシなど、複数のレイテンシの SLO を設定することもできます。

平均（または中央値）レイテンシのみを SLI として使用することは、おすすめしません。レイテンシの中央値が極端に遅い場合、ユーザーの半数が不満を感じていることを示します。つまり、長期的なエラーバジェットに対する現実的な脅威を発見できるまで、数日間にわたってレイテンシの悪化が続く可能性があります。したがって、SLO をテールレイテンシ（95 パーセンタイル）と中央値のレイテンシ（50 パーセンタイル）で定義することをおすすめします。

ACM の記事 Metrics That Matter では、Benjamin Treynor Sloss 氏が以下の内容を執筆しています。

「実用的なレイテンシの目安では、レイテンシの 99 パーセンタイルが中央値のレイテンシの 3～5 倍を超えてはいけません。」

Treynor Sloss 氏はさらに次のように続けています。

「サービスのレイテンシの 50 パーセンタイル、95 パーセンタイル、および 99 パーセンタイルは計測する価値があり、それぞれを中心に SLO を設定するのが理想的です。」

適切なモデルでは、続いて過去のパーセンタイルに基づいてレイテンシのしきい値を決めて、各バケットに該当するリクエストの数を測定します。詳しくは、このドキュメントの後半のレイテンシのアラートに関するセクションをご覧ください。

SLI としての品質

品質の SLI は、複雑なサービスに役立ちます。たとえば、依存関係が遅いときや使用できないときに、中断することで安全に失敗するよう設計されているサービスです。品質の SLI は次のように定義されます。

サービスの中断なしに処理された有効なリクエストの割合。

たとえば、ウェブページで 1 つのデータストアからメインコンテンツを読み込み、必要に応じて 100 個のサービスとデータストアから補助的なアセットを読み込むこともできます。オプションのサービス 1 つが使用不能であるか、遅すぎる場合であっても、補助的要素なしでそのページはレンダリングできます。中断したレスポンスが返されたリクエストの数（つまり、少なくとも 1 つのバックエンドサービスのレスポンスがないレスポンス）を測定すると、不正なリクエストの割合を報告できます。また、1 つのバックエンドからのレスポンスがないユーザーへのレスポンス数や、複数のバックエンドからのレスポンスがないユーザーへのレスポンス数を追跡することもできます。

データ処理サービス

一部のサービスはユーザーリクエストに応答するのではなく、入力からデータを消費し、そのデータを処理して出力を生成するよう設計されています。中間ステップでこれらのサービスがどのように実行されるかは、最終的な結果ほど重要ではありません。このようなサービスでは、最も強力な SLI は鮮度、カバレッジ、正確性、スループットであり、レイテンシと可用性ではありません。

SLI としての鮮度

鮮度の SLI は次のように定義されます。

しきい値よりも最近更新された有効なデータの割合。

たとえば、バッチ処理システムの鮮度は、特定の出力に対する処理の実行が正常に完了した後の経過時間として測定できます。より複雑なシステムまたはリアルタイムの処理システムの場合、パイプラインで処理された直近のレコードの経過時間をトラッキングできます。

たとえば、リアルタイムでマップタイルを生成するオンラインゲームについて考えてみましょう。マップタイルがすぐに作成された場合にはユーザーの気に留まらなくても、マップデータがない場合や、新しくないことには気が付くかも知れません。

または、在庫追跡システムからレコードを読み取って、e コマースのウェブサイト用に「在庫のある商品 X」というメッセージを生成するシステムについて考えてみましょう。鮮度の SLI は、次のように定義できます。

過去 1 分間に更新された在庫情報を使用したビューの割合。

鮮度の低いデータを提供するための指標を使用して、品質の SLI に通知することもできます。

SLI としてのカバレッジ

カバレッジの SLI は次のように定義されます。

正常に処理された有効なデータの割合。

カバレッジを定義するには、まず、入力を有効として受け入れるか、スキップするかどうかを決定します。たとえば、入力レコードが破損しているか、長さがゼロであり、処理できない場合、そのレコードをシステムの測定には無効とみなすことができます。

次に、有効なレコードの数をカウントします。この手順は、シンプルな count() メソッドまたは別のメソッドでも実施できます。この数字がレコードの合計数です。

最後に、カバレッジの SLI を生成するには、正常に処理されたレコードの数を計算し、その数を有効なレコードの総数と比較します。

SLI としての正確性

正確性の SLI は次のように定義されます。

正しい出力を生成した有効なデータの割合。

場合によっては、出力の正確性を判断するための方法を使用して、出力の処理を検証できます。たとえば、画像の回転や色付けを行うシステムでは、ゼロバイトの画像や、長さまたは幅がゼロの画像を生成することはできません。この検証ロジックは、処理ロジックそのものから分離することが重要です。

正確性 SLI を測定する 1 つの方法は、既知の正常なテスト入力データを使用することです。このデータには、既知の正しい出力データが含まれるようにします。入力データはユーザーデータを表している必要があります。場合によっては、画像を回転させる前の例のように、出力に対して数学的または論理的なチェックを行うこともできます。もう 1 つの例としては、トランザクション前後の残高の差額とトランザクションの金額が一致するかどうかを確認することで、トランザクションが有効かどうかを判断する課金システムがあります。

SLI としてのスループット

スループットの SLI は次のように定義されます。

データ処理率がしきい値よりも速い時間の割合。

データ処理システムでは、スループットは多くの場合、特定のリクエストのレイテンシ測定値の 1 つではなく、ユーザー満足度を表します。たとえば、各入力のサイズに大きな変化があれば、ジョブが許容速度で進んだ場合の各要素の実行にかかる時間を比較することは意味がありません。

1 秒あたりのバイト数は、データセットのサイズに関係なく、データの処理にかかる時間を測定する一般的な方法です。ただし、処理コストについてほぼ直線的にスケーリングされる指標であればどれでも機能します。

予想されるスループット率に基づいてデータ処理システムを分割することや、優先度が高い入力が処理され、優先度が低い入力がキューに追加されるようにサービス品質システムを実装することも検討の価値があります。いずれにしても、このセクションで定義されているスループットを測定することで、システムが期待どおりに機能しているかどうか判断できます。

スケジュールされた実行サービス

Kubernetes cron ジョブなど、定期的にアクションを実行する必要があるサービスについては、スキューと実行時間を測定できます。スケジュール済みの Kubernetes cron ジョブの例を次に示します。

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

SLI としてのスキュー

SLI の場合、スキューは次のように定義されます。

予想開始時刻の許容時間内に開始される実行の割合。

スキューは、ジョブの開始予定時刻から実際に開始するまでの時間差を測定します。たとえば、毎時間 0 分に開始されるように設定されている上記の Kubernetes cron ジョブの場合、毎時間 3 分が経過してから開始され、スキューは 3 分となります。ジョブが早く実行されると、負のスキューが生じます。

スキューは、適切なスキューを定義する許容範囲とともに、時間の経過に伴う分布として測定できます。SLI を決定するには、適切な範囲内の実行数を比較します。

SLI としての実行時間

SLI の場合、実行時間は次のように定義されます。

許容時間内に完了した実行の割合。

実行時間とは、ジョブが完了するまでにかかった時間です。1 つの実行でよく発生する障害の状態は、実際の実行時間がスケジュールよりも長くなることです。

この SLI の興味深い活用方法として、たとえば、終了しないジョブを検出するために使用する方法があります。これらのジョブは完了しないため、ジョブの完了を待つのではなく、特定のジョブの所要時間を記録する必要があります。このアプローチでは、最悪の場合であっても、完了までにかかる時間の正確な分布を把握できます。

スキューと同様に、実行時間を分布として追跡し、良好なイベントの許容範囲の上限と下限を定義できます。

他のシステムの指標の種類

他の多くのワークロードには、SLI と SLO の生成に使用できる独自の指標があります。以下の例を考えてみましょう。

ストレージシステム: 耐久性、スループット、最初のバイトまでの時間、blob の可用性
メディア / 動画: クライアントの再生継続時間、再生を開始するまでの時間、コード変換グラフの実行完了
ゲーム: アクティブなプレーヤーと対戦するまでの時間、マップを作成するまでの時間

測定方法

測定するものがわかると、測定方法を決定できるようになります。SLI はいくつかの方法で収集できます。

サーバー側のロギング

SLI を生成する方法

リクエストまたは処理データのサーバー側のログを処理する。

考慮事項

メリット:

既存のログを再処理して、過去の SLI レコードをバックフィルできます。
サービス間セッション ID を使用すると、複数のサービスにまたがる複雑なユーザージャーニーを再構築できます。

デメリット:

サーバーに届かなかったリクエストは記録されません。
サーバーのクラッシュを引き起こすリクエストが記録されない場合があります。
ログ処理の時間によっては、古くなった SLI が発生する可能性があります。このため、運用レスポンスには不十分なデータとなる可能性があります。
ログを処理するコードの記述は、エラーが発生しやすく時間がかかります。

実装方法とツール:

アプリケーションサーバーの指標

SLI を生成する方法

ユーザーからのリクエストを処理する、またはデータを処理するコードから SLI 指標をエクスポートする。

考慮事項

メリット:

通常、コードへ新しい指標を追加することはすばやく、低コストで可能です。

デメリット:

アプリケーションサーバーに届かなかったリクエストは記録されません。
マルチサービスリクエストは追跡が難しい場合があります。

実装方法とツール:

Cloud Monitoring
Prometheus
サードパーティの APM プロダクト

フロントエンドインフラストラクチャの指標

SLI を生成する方法

負荷分散インフラストラクチャ（Google Cloud のグローバルレイヤ 7 ロードバランサなど）の指標を使用する。

考慮事項

メリット:

通常、指標と過去のデータがすでに存在するため、エンジニアリング作業を軽減できます。
測定は、お客様の最も近くでありながらも、サービスを提供するインフラストラクチャ内で行われます。

デメリット:

データ処理の SLI では使用できません。
複数リクエストのユーザージャーニーの概算値です。

実装方法とツール:

Cloud Monitoring
CDN/LB の指標または Reporting API（Cloudflare、Akamai、Fastly）

合成クライアントまたはデータ

SLI を生成する方法

定期的に構築されたリクエストを送信するクライアントを構築し、レスポンスを検証する。データ処理パイプラインの場合は、既知の正常な入力データを作成し、出力を検証します。

考慮事項

メリット:

マルチリクエストのユーザージャーニーにおけるすべてのステップを測定します。
インフラストラクチャの外部からリクエストを送信することで、SLI のリクエストパス全体がキャプチャされます。

デメリット:

合成リクエストに対するユーザーエクスペリエンスの近似値であり、誤解を招く可能性もあります（偽陽性と偽陰性の両方）。
特殊なケースをすべてカバーするのは難しいため、統合テストが必要になります。
高い信頼性目標を実現するには、正確な測定を行うために頻繁に調べる必要があります。
プローブのトラフィックによって、実際のトラフィックが減少する可能性があります。

実装方法とツール:

Cloud Monitoring 稼働時間チェック
オープンソースソリューション:
- Cloudprober
- blackbox_exporter
ベンダーソリューション:

クライアントインストルメンテーション

SLI を生成する方法

ユーザーが操作できるオブザーバビリティ機能をクライアントに追加し、SLI を追跡するサービスインフラストラクチャにイベントをログに記録する。

考慮事項

メリット:

ユーザーエクスペリエンスを最も正確に評価できます。
CDN や決済機関などのサードパーティの信頼性を数値化できます。

デメリット:

クライアントログの取り込みと処理のレイテンシのため、運用上のレスポンスのトリガーには適しません。
SLI の測定値には、直接的な制御の対象外の可能性がある、変動が激しい要素が多数含まれます。
インストルメンテーションをクライアントに組み込むには、多くのエンジニアリング作業が必要になる場合があります。

実装方法とツール:

Google アナリティクス、Firebase
ユーザー分析: Amplitude および同様のツール
モバイル / フロントエンドのモニタリング: New Relic Browser、Raygun Real User Monitoring、Sentry
記録および追跡するカスタムクライアントとカスタムサーバー

測定方法を選択する

理想的には、サービスに対するお客様のエクスペリエンスに最も近い測定方法を選択し、労力を最小限に抑える必要があります。それには、上記の表のメソッドを組み合わせる必要が生じることもあります。以下に、時間の経過に伴い実装できる推奨アプローチを、手軽な順に示します。

アプリケーションサーバーのエクスポートとインフラストラクチャの指標を使用する。通常、これらの指標にはすぐにアクセスでき、値もすぐにわかります。一部の APM ツールには、SLO ツールが組み込まれています。
クライアントインストルメンテーションを使用する。レガシーシステムでは通常、エンドユーザーのクライアントインストルメンテーションが組み込まれていないため、インストルメンテーションの設定には多大な投資が必要になります。ただし、クライアントインストルメンテーションを提供する APM スイートまたはフロントエンドフレームワークを使用すると、顧客満足度に関する分析情報がすぐに手に入ります。
ログ処理を使用する。サーバーエクスポートやクライアントインストルメンテーションが実装できない一方でログが存在する場合、ログ処理が最適な可能性があります。もう一つは、エクスポートとログ処理を組み合わせる方法です。エクスポートを一部の SLI（即時の可用性など）の即時ソースとして使用し、ログ処理を長期間のシグナル（SLO とアラートで後述する低速バーンのアラートなど）ガイドに使用します。
合成テストを実装する。お客様がどのようにサービスを利用しているかについての基本を理解したら、サービスレベルをテストします。たとえば、テストアカウントに正常であることがわかっているデータをシードし、そのデータを照会します。このテストは、トラフィックが少ないサービスなど、容易に確認できなかったエラーモードを特定するのに効果的です。

目標を設定する

目標を設定する最善の方法の一つは、SLO とその開発方法を記述した共有ドキュメントを作成することです。SLO を実装し、反復作業を重ねるにあたり、チームがドキュメントを繰り返し使用できます。

ビジネスオーナー、プロダクトオーナー、エグゼクティブが、このドキュメントを確認することをおすすめします。このような関係者は、サービスの期待とプロダクトの信頼性のトレードオフに関する分析情報を提供できます。

会社にとって最も重要なユーザージャーニー（CUJ）用に、SLO を開発するためのテンプレートは次のとおりです。

SLI 仕様（可用性や鮮度など）を選択します。
SLI 仕様の実装方法を定義します。
計画に目を通し、CUJ がカバーされていることを確認します。
過去のパフォーマンスまたはビジネスニーズに基づいて SLO を設定します。

CUJ は、1 つのサービスまたは 1 つの開発チームまたは組織に制限しないでください。99.5% で動作する数百のマイクロサービスに依存しているもののエンドツーエンドの可用性をまったく追跡していなければ、顧客満足度は低い可能性があります。

ロードバランサ、フロントエンド、ミキサー、バックエンド、データベースの 5 つのサービスに順番に依存するクエリがあるとします。

各コンポーネントの可用性が 99.5% であれば、ユーザーにとっての可用性は最悪の場合、次のようになります。

99.5% × 99.5% × 99.5% × 99.5% × 99.5% = 97.52%

これは、5 つのサービスのいずれかにエラーが発生するとシステム全体がエラーとなるため、ユーザーにとって最悪のケースの可用性となります。このケースに該当するのは、スタックの全レイヤが各ユーザーリクエストを処理するためにすぐに使用でき、中間での再試行やキャッシュ、クエリなど復元力を高める要素がない場合のみです。このようにサービスを緊密に結合させるシステム設計は不適切であり、マイクロサービスモデルを否定するものです。

分散サービスの SLO に対してパフォーマンスを部分的に測定しても（サービス別）、お客様のエクスペリエンスは正確に反映されず、慎重すぎる解釈をしてしまう可能性があります。

代わりに、フロントエンドで SLO とパフォーマンスを比較して、ユーザーエクスペリエンスを把握します。コンポーネントサービスに障害が発生しても（クエリが自動的に再試行されるため）、ユーザークエリが成功しても、ユーザーには影響がありません。内部サービスを共有している場合、これらのサービスは、お客様とのやり取りとして機能するユーザー向けのサービスを使用して SLO のパフォーマンスを個別に測定できます。SLO は互いに独立して処理する必要があります。

スマート再試行、キャッシュ保存、キューイングなどの復元力を高める要素を使用することで、可用性の低いサービス（99.9% など）の上に高可用性サービス（99.99% など）を構築できます。

一般的に、統計学の実用的知識があれば、基盤となるサービスまたは組織のレイアウトを理解していなくても、SLO を読んで理解できます。

SLO ワークシートの例

SLO を開発する際には、次のことを実施するよう留意してください。

SLI でイベント、成功基準、成功と失敗の記録方法が指定されていることを確認します。
良好なイベントの割合で SLI 仕様を定義します。
SLO で、ターゲットレベルと測定機関の両方が指定されていることを確認します。
関係者が付随するトレードオフと細かい点を理解できるよう、アプローチのメリットとデメリットについて説明します。

たとえば、次の SLO ワークシートを検討してください。

CUJ: ホームページの読み込み
SLI タイプ: レイテンシ SLI 仕様: 100 ミリ秒未満で処理されるホームページリクエストの割合 SLI 実装: サーバーログのレイテンシ列から測定された、100 ミリ秒未満で処理されるホームページのリクエストの割合（デメリット: この測定では、バックエンドに到達できないリクエストは含まれません）。仮想マシン上で実行されているブラウザで JavaScript を実行するプローバーによって測定された、100 ミリ秒未満で処理されるホームページのリクエストの割合（メリットとデメリット: この方法では、リクエストがネットワークに到達できない場合のエラーは取得しますが、ユーザーのサブネットにのみ影響する問題は取得されません）。 SLO: 100 ミリ秒未満で処理された過去 28 日間のホームページリクエストの 99%

CUJ: ホームページの読み込み

SLI タイプ: レイテンシ

SLI 仕様: 100 ミリ秒未満で処理されるホームページリクエストの割合

SLI 実装:

サーバーログのレイテンシ列から測定された、100 ミリ秒未満で処理されるホームページのリクエストの割合（デメリット: この測定では、バックエンドに到達できないリクエストは含まれません）。
仮想マシン上で実行されているブラウザで JavaScript を実行するプローバーによって測定された、100 ミリ秒未満で処理されるホームページのリクエストの割合（メリットとデメリット: この方法では、リクエストがネットワークに到達できない場合のエラーは取得しますが、ユーザーのサブネットにのみ影響する問題は取得されません）。

SLO: 100 ミリ秒未満で処理された過去 28 日間のホームページリクエストの 99%

次のステップ

Google の顧客信頼性エンジニアリングチームが開発したワークショップである Art of SLO を読む。
SLO の作成に関するオンラインコース、Site Reliability Engineering: Measuring and Managing Reliability を試す。
サイト信頼性エンジニアリング: SLO の実装を読む。
サービスのモニタリングにおけるコンセプトを読む。
Cloud Monitoring を使った SLO の開発を読む。
Google の Professional Services Organization（PSO）からフレキシブルな SLO Generator を試す。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。
DevOps に関するリソースを読む。
このシリーズに関連する DevOps 機能の詳細については、以下をご覧ください。
DevOps のクイックチェックで、業界における立ち位置を把握する。

用語

このドキュメントでは、Google Cloud アーキテクチャフレームワーク: 信頼性セクションで使用される SLO 関連の用語の一般的な定義について説明します。

サービスレベル。特定のサービスがユーザーに対して期待される作業をどの程度行えているかに関する測定値。この測定値は、ユーザーの満足度という形で説明できます。その測定方法は、サービスの内容、ユーザーが何をサービスに期待しているか、サービスで実現できるとの説明を受けている内容などに基づきます。

例: 「ユーザーは、サービスが利用可能で高速であることを期待しています。」
クリティカルユーザージャーニー（CUJ）。ユーザーが 1 つの目的を達成するために行うサービスとの一連のインタラクション（1 回のクリックやマルチステップパイプラインなど）。

例: 「ユーザーが購入手続きボタンをクリックし、カートが処理されて領収書が返されるレスポンスを待ちます。」
サービスレベル指標（SLI）。定量的に測定可能な、サービスレベルに関するユーザーの満足度の指標。サービスレベルを測定するためには、そのサービスレベルに関するユーザーの満足度を表す指標（サービスの可用性など）を測定する必要があります。SLI は、サービスの改善や低下に伴い経時変化するグラフ上の線と考えることができます。多くの場合、単位なしのパーセンテージで表される「良好」/「合計」のラジオボタンになります。これらのパーセンテージを一貫して使用することで、チームは実装に関する深い知識がなくても SLI を理解できます。

例: 「直近 10 分間における成功したリクエストの数を、直近 10 分間の有効なリクエストの数で割った値を測定します。」
サービスレベル目標（SLO）。サービスがほとんどの時間帯で達成すると期待されるレベル。SLI は、これに対して測定されます。

例: 「14 日間で測定されたすべての有効なリクエストの 95% でサービスのレスポンスが 400 ミリ秒（ms）より早いこと。」
サービスレベル契約（SLA）。SLO が満足されなかった場合の対応に関する説明。通常、SLA はプロバイダと顧客との間の法的契約であり、補償の条項が含まれる場合もあります。SRE に関する技術的な議論においては、この用語はしばしば避けられます。

例: 「1 暦月の間にサービスによって 99.95% の可用性を実現できなかった場合、サービスプロバイダは、サービス内容についての規定を遵守できなかった時間に対して 1 分単位でお客様に補償します。」
エラーバジェット: SLO 違反となるまでに許容できる時間や好ましくないイベントの数。この測定値は、ビジネスでどの程度の数のエラーが想定されるか（許容できるか）を示します。エラーバジェットは、リスクを伴う可能性がある意思決定を行ううえで重要です。

例: 「SLO が 99.9% の可用性の場合、リクエストの 0.1% でインシデント、事故、試験運用のいずれかが原因のエラーが発生することが許容されます。」

SLO とアラート

このドキュメントの Google Cloud アーキテクチャフレームワーク: 信頼性セクションで、SLO に関するアラートについて詳しく説明しています。

SLO などの新しいオブザーバビリティシステムの導入における誤ったアプローチは、そのシステムで古いシステムを完全に置き換えることです。そうではなく、SLO は補完するためのシステムとして考えるべきです。たとえば、既存のアラートを削除する代わりに、ここで説明する SLO アラートと並行して実行することをおすすめします。このアプローチでは、SLO アラートを予測するレガシーアラート、SLO アラートと並行して実行されるアラート、起動しないアラートを特定できます。

SRE の原則は、原因ではなく、症状に基づいてアラートを出すことです。SLO は、その性質上、症状の測定値です。SLO アラートを導入すると、症状アラートが他のアラートとともに起動される場合があります。原因ベースのレガシーアラートが SLO や症状なしで起動する場合、これらを完全に停止することを検討し、チケット発行アラートに変更するか、後から参照するためにログに記録します。

詳細については、SRE ワークブックの第 5 章をご覧ください。

SLO バーンレート

SLO のバーンレートとは、障害が発生してから、ユーザーがエラーの影響を受け、エラーバジェットがすべて消費されるまでの速度を表します。バーンレートを測定すると、サービスが SLO に違反するまでの時間を判断できます。SLO のバーンレートに基づいたアラート作成は、有用なアプローチです。SLO は期間に基づくもので、きわめて長期間（数週間または数か月）にわたることもあるので注意してください。ただし、SLO 違反が実際に発生する前に、その違反につながる条件をすばやく検出することが目的です。

次の表は、秒間クエリ数（QPS）が一定であると仮定し、所定の期間内にリクエストが 100% 失敗した場合の、目標の達成までにかかる時間を示します。たとえば、30 日間で 99.9% の SLO を測定した場合、その 30 日間は 43.2 分のダウンタイムを許容できます。このようなダウンタイムは、たとえば一度にまとめて発生しても、複数のインシデントにわたって間隔を空けて発生してもかまいません。

目的	90 日	30 日	7 日	1 日
90%	9 日	3 日	16.8 時間	2.4 時間
99%	21.6 時間	7.2 時間	1.7 時間	14.4 分
99.9%	2.2 時間	43.2 分	10.1 分	1.4 分
99.99%	13 分	4.3 分	1 分	8.6 秒
99.999%	1.3 分	25.9 秒	6 秒	0.9 秒

実際には、高い成功率を達成するためには、100% の停止インシデントが発生しないようにする必要があります。ただし、多くの分散システムは、部分的に停止することや安全に低下する場合があります。SLO アラートは、このような部分的な障害であっても、人為的に阻止する必要があるかどうかを判断する方法を提供します。

アラートのタイミング

重要なのは、SLO のバーンレートに基づいて行動を起こすタイミングです。一般に、エラーバジェットが 24 時間で枯渇する場合、すぐに修正を依頼する必要があります。

失敗率の測定は必ずしも簡単ではありません。小さなエラーが続くと不安があおられてしまいますが、結局はすぐに解決して SLO への影響もほとんどない場合もあります。同様に、システムが長期間にわたってわずかに破損している場合、このようなエラーが SLO 違反につながることもあります。

理想的には、チームがこれらのシグナルに対応して、特定の期間に発生したエラーバジェットのほとんどを使い切るようにします（ただし、上限を超えないようにします）。エラーバジェットを使いすぎると、SLO に違反してしまいます。少なすぎると、十分なリスクを負っていないことになり、オンコールチームの負担が大きくなってしまいます。

そこで、人為的な介入を必要とするほどシステムが破損していると判断するタイミングを決定する方法が必要です。以下のセクションでは、この質問に対するアプローチについて説明します。

高速バーン

SLO バーンの種類の 1 つは、高速 SLO バーンです。エラーバジェットの消費ペースが速く、SLO 違反を避けるために介入を要求するからです。

サービスの通常の秒間クエリ数（QPS）が 1,000 であり、7 日間の測定結果で 99% の可用性を維持したいとします。エラーバジェットは、約 600 万のエラー（約 6 億のリクエストのうち）を許容しています。たとえば、エラーバジェットを使い切るまでに 24 時間あれば、毎秒約 70 個、または 1 時間に 252,000 個がエラー数の上限となります。これらのパラメータは、連絡可能なインシデントが四半期ごとのエラーバジェットの 1% 以上を消費する必要があるという一般的なルールに基づいています。

1 時間が経過する前に、エラーのレートを検出するかを選択できます。たとえば、次の図に示すように、1 秒あたり 70 エラーのレートが 15 分間観察された後に、オンコールエンジニアに連絡することもできます。

24 時間の予算のうち 1 時間を費やす前に、問題を解決するのが理想的です。このレートを短い時間枠（1 分間など）で検出すると、エラーが発生しやすくなります。検出目標時間が 15 分未満の場合は、この数値を調整できます。

低速バーン

もう 1 つの種類のバーンレートは、低速バーンです。たとえば、週のエラーバジェットを 5 日目または 6 日目までに使い切るバグや、月のバジェットを 2 週目までに使い切るバグが発生したとします。どのように対応することが最適でしょうか。

この場合、低速 SLO バーンアラートを導入し、アラートウィンドウが終了する前に、エラーバジェットすべてを使い切ることになると通知を受け取ります。もちろん、このアラートによって偽陽性が多数返される可能性もあります。たとえば、エラーは短時間であるものの、エラーバジェットをすばやく消費する速度で発生する条件がよく発生するとします。その場合、短時間しか継続せず、長期的にエラーバジェットを脅かさないため、条件は偽陽性になります。目標は、エラーのソースをすべて排除することではなく、エラーバジェットを超えないように許容範囲以内に収めることです。エラーバジェットを脅かすことのないイベントであれば、人の介入を促すアラートの作成は避けます。

低速バーンイベントの場合は、呼び出しやメールではなく、チケットキューでの通知をおすすめします。低速バーンイベントの発生は緊急事態ではありませんが、バジェットが枯渇する前に人間による対応が必要です。これらのアラートに、チームリストへのメールを使用することは避けてください。煩わしく、すぐに無視されてしまうからです。チケットは追跡可能、割り当て可能、および転送可能である必要があります。チームは、チケットの量、クローズ率、対応可能性、重複に関するレポートを作成します。対処できないチケットが多すぎる場合、過度の作業負担の好例です。

SLO アラートをうまく使用するには時間がかかり、チームの文化と期待によって決まります。SLO アラートは時間の経過とともに細かく調整できます。また、ニーズに合わせて、複数のアラート方法を導入してさまざまなアラートウィンドウを作成することもできます。

レイテンシアラート

可用性アラートに加えて、レイテンシのアラートを受け取ることもできます。レイテンシの SLO を使用すると、レイテンシ目標を満たさないリクエストの割合を測定できます。このモデルを使用すると、エラーバジェットの高速バーンまたは低速バーンを検出するのに使用するのと同じアラートモデルを利用できます。

レイテンシの中央値 SLO に関してすでに説明したように、リクエストの半数は完全に SLO 対象外となります。つまり、長期的なエラーバジェットに影響が出るまで、ユーザーが数日にわたってレイテンシの悪化を経験する可能性があります。代わりに、サービスではテールレイテンシ目標と通常のレイテンシ目標を定義する必要があります。通常のレイテンシに過去 90 パーセンタイルを使用し、テールレイテンシに 99 パーセンタイルを使用して定義することをおすすめします。これらの目標を設定したら、各レイテンシカテゴリで予想されるリクエストの数と、遅すぎると予想されるリクエスト数に基づいて SLO を定義できます。このアプローチは、エラーバジェットと同じコンセプトであり、同じように扱われます。その結果、「90% のリクエストが通常のレイテンシ内で、99.9% はテールレイテンシターゲット内で処理される」というような文になります。これらのターゲットを使用すると、ほとんどのユーザーが通常のレイテンシを体験する一方で、テールレイテンシターゲットよりも遅いリクエスト数もトラックできます。

サービスによっては、大きく変動する予想ランタイムになる場合があります。たとえば、データストアシステムからの読み取りと書き込みでは、パフォーマンスが大幅に異なることがあります。想定されるすべての可能性を列挙するのではなく、次の表のようにランタイムパフォーマンスバケットを導入できます。このアプローチでは、これらのタイプのリクエストが識別可能で、各バケットに分類済みであることを前提としています。リクエストがその場ですぐに分類されることはありません。

ユーザー向けウェブサイト
バケット	予想される最大ランタイム
読み取り	1 秒
書き込み / 更新	3 秒

データ処理システム
バケット	予想される最大ランタイム
小	10 秒
中	1 分
大	5 分
最大	1 時間
特大	8 時間

現在のシステムの状態を測定すると、これらのリクエストの実行に通常かかる時間がわかります。例として、動画のアップロードを処理するシステムについて考えてみましょう。非常に長い動画の場合、処理にさらに時間がかかると予想されます。次の表に示すように、動画の長さ（秒単位）を使用して、バケットに分類できます。この表では、バケットあたりのリクエスト数と、ランタイムの 1 週間にわたるさまざまなパーセンタイルの分布を記録しています。

動画の長さ	1 週間に測定されたリクエストの数	10%	90%	99.95%
小	0	-	-	-
中	190 万	864 ミリ秒	17 秒	86 秒
大	2,500 万	1.8 秒	52 秒	9.6 分
最大	430 万	2 秒	43 秒	23.8 分
特大	81,000	36 秒	1.2 分	41 分

そうした分析から、アラート用のパラメータをいくつか導き出すことができます。

fast_normal: 最大 10% のリクエストが今回よりも高速です。今回よりも高速なリクエストが多すぎる場合、ターゲットに問題があるか、システム自体が変更された可能性があります。
slow_commonly: 少なくとも 90% のリクエストが今回よりも高速です。この制限により、メインのレイテンシ SLO が発生します。このパラメータは、ほとんどのリクエストの速度が十分であるかどうかを示します。
slow_tail: 少なくとも 99.95% のリクエストが今回よりも高速です。この制限により、遅いリクエストが増えすぎないようにします。
deadline: ユーザーのリモートプロシージャコールまたはバックグラウンド処理がタイムアウトして失敗するポイント（通常、上限はシステムにハードコードされています）。これらのリクエストは本当に遅いわけではありませんが、実際にエラーが発生して、可用性の SLO にカウントされます。

バケットを定義する際のガイドラインは、バケットの fast_typical、slow_typical、slow_tail を互いの指標の範囲内に保つことです。このガイドラインでは、バケットの範囲が広すぎないようにしています。バケット間の重複やギャップを避けないようにすることをおすすめします。

バケット	fast_typical	slow_typical	slow_tail	deadline
小	100 ミリ秒	1 秒	10 秒	30 秒
中	600 ミリ秒	6 秒	60 秒（1 分）	300 秒
大	3 秒	30 秒	300 秒（5 分）	10 分
最大	30 秒	6 分	60 分（1 時間）	3 時間
特大	5 分	50 分	500 分（8 時間）	12 時間

これにより、api.method: SMALL => [1s, 10s] のようなルールになります。この場合、SLO トラッキングシステムでは、リクエストを確認し、バケットを判別します（メソッド名や URI を解析して、ルックアップテーブルと比較します）。次に、そのリクエストのランタイムを基に統計情報を更新します。700 ミリ秒の場合、slow_typical ターゲット内に含まれます。3 秒であれば、slow_tail 内に含まれます。22 秒の場合、slow_tail は超過しますが、エラーではありません。

ユーザー満足度の観点からは、テールレイテンシを満たさなかった場合は、使用不可能と同等であると考えることができます（つまり、レスポンスが非常に遅いため、失敗とみなされます）。そのため、可用性と同じパーセンテージを使用することをおすすめします。次に例を示します。

全リクエストの 99.95% は 10 秒以内に満たされる。

通常のレイテンシとみなされる範囲は、お客様次第です。Google 内の一部のチームでは 90% を適切な目標とみなしています。これは分析と、slow_typical の期間の選択に関連しています。例:

すべてのリクエストの 90% は 1 秒以内に処理される。

推奨アラート

これらのガイドラインを考慮し、SLO アラートの推奨ベースラインセットを次の表に示します。

SLO	測定期間	バーンレート	アクション
可用性、高速バーン通常のレイテンシテールレイテンシ	1 時間	SLO 違反から 24 時間未満	連絡する
可用性、低速バーン通常のレイテンシ、低速バーンテールレイテンシ、低速バーン	7 日間	SLO 違反から 24 時間超	チケットを作成する

SLO

測定期間

バーンレート

アクション

可用性、高速バーン

通常のレイテンシ

テールレイテンシ

1 時間

SLO 違反から 24 時間未満

連絡する

可用性、低速バーン

通常のレイテンシ、低速バーン

テールレイテンシ、低速バーン

7 日間

SLO 違反から 24 時間超

チケットを作成する

SLO アラートは、取得に時間のかかるスキルです。このセクションの期間は推奨値であり、独自のニーズと精度に応じて調整できます。アラートを測定期間やエラーバジェットの支出と一緒に利用することも、高速バーンと低速バーンの間に別のアラート層を追加して活用することもできます。

インフラストラクチャとアプリケーションにオブザーバビリティを組み込む

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、サービスのパフォーマンスをより深く理解し、問題を迅速に特定できるように、サービスのオブザーバビリティを改善するためのベストプラクティスについて説明します。オブザーバビリティには、モニタリング、ロギング、トレース、プロファイリング、デバッグなどのシステムがあります。

モニタリングは Google SRE ハンドブックのサービスの信頼性の階層における基盤です。適切なモニタリングがなければ、アプリケーションが正常に動作しているかどうかすら判断できません。

コードをインストルメント化してオブザーバビリティを最大化する

適切に設計されたシステムでは、その開発段階から適切なオブザーバビリティを備えています。アプリケーションが本番環境になるまでモニタリングを行わないことのないようにしてください。コードをインストルメント化して、次のガイダンスを考慮してください。

デバッグとトラブルシューティングを効率的に行うには、ログエントリとトレースエントリに何を書き出し、どの指標をモニタリングしてエクスポートするかについて検討します。システムで最も発生しそうな障害モードか、よく発生する障害モードを優先します。
モニタリングを定期的に検査およびプルーニングします。未使用または不要なダッシュボード、グラフ、アラート、トレース、ロギングを削除して、クラッターを除去します。

Google Cloud のオペレーションスイートでは、リアルタイムのモニタリング、ハイブリッドマルチクラウドのモニタリングとロギング（AWS や Azure など）に加え、トレース、プロファイリング、デバッグを行うことができます。Google Cloud のオペレーションスイートでは、App Engine または Istio などのサービスメッシュで実行されているマイクロサービスを自動的に検出してモニタリングすることもできます。

大量のアプリケーションデータが生成される場合は、BigQuery を使用して分析イベントログの大規模な取り込みを最適化できます。BigQuery は、モニタリングフレームワークからのカーディナリティの高い時系列データを永続化し、分析する場合にも適しています。この方法は、モニタリングを最初から完全に設計しようとするのではなく、低コストで任意のクエリを実行でき、レポートをモニタリングから切り離すことができるため有用です。レポートは、Looker Studio や Looker を使用してデータから作成できます。

推奨事項

アーキテクチャフレームワークのガイダンスを実際の環境に適用するには、次の推奨事項に従ってください。

移行を開始する前、または新しいアプリケーションを本番環境にデプロイする前など、モニタリングを早期の段階で実装します。
アプリケーションの問題と、基盤となるクラウドの問題を明確に区分します。Monitoring API などの Cloud Monitoring プロダクトと Google Cloud ステータスダッシュボードを使用します。
モニタリングだけでなく、トレース、プロファイリング、デバッグが含まれるオブザーバビリティ戦略を定義します。
実行不可能なアラートなど、使用していない、または価値のなくなったオブザーバビリティアーティファクトを定期的にクリーンアップします。
大量のオブザーバビリティデータを生成する場合、アプリケーションイベントは、BigQuery などのデータウェアハウスシステムに送信します。

次のステップ

スケーラビリティと高可用性を実現する設計（このシリーズの次のドキュメント）

スケーラビリティと高可用性を実現する設計

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、障害を許容し、顧客の需要に応じてスケーリングできるようにサービスを設計するための設計原則について説明します。信頼性の高いサービスは、サービスの需要が高い場合やメンテナンスイベントが発生した場合でも、顧客からのリクエストに継続的に対応します。次の信頼性設計の原則とベストプラクティスは、システムアーキテクチャとデプロイの計画に組み込む必要があります。

冗長性を作成して高可用性を実現する

信頼性の高いシステムには単一障害点がなく、リソースは複数の障害発生ドメイン間で複製される必要があります。障害発生ドメインとは、VM インスタンス、ゾーン、リージョンなど、独立して障害が発生する可能性のあるリソースのプールです。複数の障害発生ドメイン間でレプリケーションを行うと、個別のインスタンスよりも達成できる集計のレベルが高くなります。詳細については、リージョンとゾーンをご覧ください。

システムアーキテクチャの一部である冗長性の具体的な例として、DNS 登録で発生した障害を個々のゾーンに隔離するために、ゾーン DNS 名を使用して同じネットワーク上のインスタンスが相互にアクセスできるようにします。

高可用性のためにフェイルオーバーを備えたマルチゾーンアーキテクチャを設計する

複数のゾーンに分散されたリソースのプールを使用し、アプリケーションにデータレプリケーション、ロードバランシング、ゾーン間の自動フェイルオーバーを設計することで、ゾーン障害に対する復元力を高めます。アプリケーションスタックの各レイヤでゾーンレプリカを実行し、アーキテクチャ内のゾーン間の依存関係をすべて排除します。

障害復旧のために複数のリージョン間でデータを複製する

リモートリージョンにデータの複製やアーカイブを行い、リージョンの停止やデータ損失が発生した場合に障害復旧を可能にします。レプリケーションを使用すると、レプリケーションの遅延で少量のデータ損失が発生する可能性がありますが、リモートリージョンのストレージシステムに最新のデータが保存されているため、復旧時間を短縮できます。継続的なレプリケーションの代わりに定期的なアーカイブを使用する場合、障害復旧では、新しいリージョンでバックアップやアーカイブからデータを復元します。この手順は通常、継続的に更新されるデータベースレプリカを有効にする場合よりもサービスのダウンタイムが長くなり、連続するバックアップオペレーション間のギャップにより、失われるデータが増える可能性があります。どちらの方法を採用する場合も、アプリケーションスタック全体を再デプロイして新しいリージョンで起動する必要があります。この間、サービスは利用できなくなります。

障害復旧のコンセプトと手法の詳細については、クラウドインフラストラクチャの停止に対する障害復旧の設計をご覧ください。

リージョンの停止に対する耐障害性を確保するためにマルチリージョンアーキテクチャを設計する

まれなケースですが、リージョン全体で障害が発生してもサービスを継続的に実行する必要がある場合は、異なるリージョンに分散されたコンピューティングリソースのプールを使用するようにサービスを設計します。アプリケーションスタックの各レイヤでリージョンレプリカを実行します。

リージョン間でのデータレプリケーションを使用し、リージョンが停止したときに自動フェイルオーバーを使用します。Spanner など、一部の Google Cloud サービスにはマルチリージョンのバリアントがあります。リージョンの障害に対する復元力を確保するため、可能であれば、マルチリージョンサービスを設計してください。リージョンと利用可能なサービスの詳細については、Google Cloud のロケーションをご覧ください。

リージョンレベルの障害の範囲が対象リージョンに限定されるように、リージョン間の依存関係がない状態にしてください。

単一リージョンのプライマリーデータベースなど、アクセスできないときにグローバルな停止を引き起こす可能性があるリージョンの単一障害点を排除します。マルチリージョンアーキテクチャではコストが高くなることが多いため、このアプローチを採用する前に、コストに対するビジネスニーズを検討してください。

障害ドメイン全体での冗長性の実装については、クラウドアプリケーションのデプロイアーキタイプ（PDF）の調査報告をご覧ください。

スケーラビリティのボトルネックを排除する

単一の VM または単一のゾーンのリソース制限を超えて拡張できないシステムコンポーネントを特定します。垂直方向にスケーリングされるアプリケーションでは、負荷の増加に対応するため、単一の VM インスタンスにより多くの CPU コア、メモリ、ネットワーク帯域幅が追加される場合があります。これらのアプリケーションのスケーラビリティにはハードリミットがあり、成長に対応するために手動による構成が必要になります。

可能であれば、VM またはゾーン間でのシャーディングやパーティショニングなどの水平スケーリングを行うように、これらのコンポーネントを再設計してください。トラフィックや使用量の増加に対応するために、より多くのシャードを追加します。シャードごとの負荷の増加に対応するために、自動的に追加される標準の VM タイプを使用します。詳細については、スケーラブルで復元性の高いアプリのためのパターンをご覧ください。

アプリケーションを再設計できない場合は、ユーザー管理のコンポーネントをユーザーのアクションなしで水平方向にスケーリングするように設計されたフルマネージドクラウドサービスに置き換えることができます。

過負荷状態の場合にサービスレベルを適切に下げる

過負荷状態に耐えられるようにサービスを設計します。過負荷を検出し、サービスレベルを下げてレスポンスをユーザーに返すか、一部のトラフィックをドロップするように設計し、過負荷状態で機能不全にならないようにします。

たとえば、サービスでは、静的ウェブページでユーザーのリクエストに応答し、処理に費用がかかる動的な動作を一時的に無効にできます。この動作の詳細については、Compute Engine から Cloud Storage へのウォームフェイルオーバーパターンをご覧ください。また、サービスでは、読み取り専用オペレーションを許可してデータの更新を一時的に無効にすることもできます。

サービスが低下した場合は、エラー状態を修正するために、オペレーターに通知する必要があります。

トラフィックの急増を回避し、軽減する

クライアント間でリクエストを同期しないでください。同じタイミングでトラフィックを送信するクライアントの数が多すぎると、トラフィックが急増し、カスケード障害が発生する可能性があります。

スロットリング、キューイング、負荷制限またはサーキットブレーク、グレースフルデグラデーション、重要なリクエストの優先順位付けなど、トラフィック急増の軽減策をサーバー側に実装します。

クライアントでの軽減策には、クライアント側のスロットリングとジッターを伴う指数バックオフがあります。

入力をサニタイズして検証する

サービス停止やセキュリティ侵害の原因となる、誤入力、ランダム入力、不正な入力を防ぐため、API とオペレーションツールの入力パラメータをサニタイズして検証します。たとえば、Apigee と Google Cloud Armor はインジェクション攻撃からの保護に役立ちます。

定期的にファズテストを使用する。このテストでは、テストハーネスにより、ランダム入力、空の入力、または大きすぎる入力を使用して API を意図的に呼び出します。これらのテストは隔離されたテスト環境で行います。

運用ツールは、変更がロールアウトされる前に構成変更を自動的に検証します。検証が失敗した場合は変更を拒否する必要があります。

機能を維持しながらフェイルセーフを実現する

問題により障害が発生した場合は、システムコンポーネントで障害が発生しても、システム全体は引き続き機能します。こうした問題としては、ソフトウェアのバグ、入力や構成の誤り、計画外のインスタンス停止、人的エラーなどが考えられます。サービスプロセスによって、制限を過度に厳格にするのではなく、制限を大幅に緩和する、または単純化する必要があるかどうかを判断できます。

次のシナリオ例と、障害への対応方法を検討します。

通常は、構成が不適切または空であるファイアウォールコンポーネントがフェイルオープンであり、オペレーターがエラーを修正している短時間の間、未承認のネットワークトラフィックが通過できるようにすることをおすすめします。この動作により、フェイルクローズしてトラフィックの 100% をブロックする代わりに、サービスの可用性を維持できます。サービスは、すべてのトラフィックが通過している間、アプリケーションスタック内のより深い認証と認可チェックに依存して、機密領域を保護する必要があります。
ただし、ユーザーデータへのアクセスを制御する権限サーバーコンポーネントがフェイルクローズして、すべてのアクセスをブロックするように設定することをおすすめします。この動作により構成が破損するとサービスが停止しますが、フェイルオープンした際に機密データが漏洩するリスクを回避できます。

どちらの場合も、オペレーターがエラー条件を修正できるように、障害によって優先度の高いアラートが生成される必要があります。サービスコンポーネントによって、ビジネスに対する極端なリスクが生じない限り、フェイルオープン側でエラーが発生します。

再試行できるように API 呼び出しとオペレーションコマンドを設計する

API と運用ツールは、可能な限り呼び出しを安全に再試行できるようにする必要があります。多くのエラー条件に対する自然なアプローチは、前のアクションを再試行することですが、最初の試行が成功したかどうか不明な場合もあります。

システムアーキテクチャでは、アクションをべき等にする必要があります。オブジェクトに対して同じアクションを 2 回以上連続して実行した場合、1 回の呼び出しと同じ結果を生成する必要があります。べき等以外のアクションでは、システム状態の破損を防ぐため、より複雑なコードが必要になります。

サービスの依存関係を特定して管理する

サービスデザイナーとオーナーは、他のシステムコンポーネントへの依存関係の完全なリストを維持する必要があります。また、依存関係の障害からの復旧や完全な復旧が不可能な場合は、グレースフルデグラデーションもサービス設計に組み込む必要があります。システムで使用されるクラウドサービスと外部依存関係（サードパーティのサービス API など）への依存度を考慮し、どのシステムの依存関係にもゼロ以外の失敗率があることを認識する必要があります。

信頼性の目標を設定する場合、サービスの SLO は、すべての重要な依存関係の SLO によって数学的に制限されることに注意してください。いずれかの依存関係の最も低い SLO よりも信頼性が高くなることはありません。詳細については、サービス可用性の計算をご覧ください。

起動の依存関係

サービスは、起動時と定常動作では動作が異なります。起動の依存関係は、定常状態のランタイムの依存関係とは大きく異なる場合があります。

たとえば、起動時に、再度呼び出すことがあまりないユーザーメタデータサービスからユーザー情報またはアカウント情報を読み込むことが必要になることがあります。クラッシュまたは定期メンテナンスの後に多くのサービスレプリカが再起動すると（特にキャッシュが空で、再配置する必要がある場合）、レプリカが起動の依存関係の負荷を急増させる可能性があります。

負荷がかかった状態でサービスの起動をテストし、それに応じて起動の依存関係をプロビジョニングします。起動の重要な依存関係からサービスが取得するデータのコピーを保存することで、サービスレベルを正常に低下させる設計を検討してください。この動作により、重要な依存関係が停止した際にサービスを起動不能にせずに、古い可能性があるデータで再起動できるようになります。取得可能になった時点で新しいデータを読み込み、サービスを通常の動作に戻すことができます。

新しい環境でサービスをブートストラップする際には、起動の依存関係も重要です。レイヤ間の循環依存関係なしに、階層化されたアーキテクチャでアプリケーションスタックを設計します。循環環依存関係は、単一のアプリケーションに対する増分変更をブロックしないため、許容できるかもしれません。ただし、循環依存関係では、障害でサービススタック全体が停止した後に再起動することが困難または不可能になります。

重要な依存関係を最小化する

サービスの重要な依存関係、つまり、障害によって必然的にサービスが停止するコンポーネントの数を最小限に抑えます。依存する他のコンポーネントの障害や遅延に対するサービスの復元力を高めるには、次の設計手法と原則を考慮して、重要な依存関係を重要でない依存関係に変換することを検討してください。

重要な依存関係の冗長性レベルを上げます。レプリカが多いほど、コンポーネント全体が使用できなくなる可能性が低くなります。
レスポンスをブロックする代わりに他のサービスへの非同期リクエストを使用するか、レスポンスでブロックするのではなく、パブリッシュ / サブスクライブメッセージングを使用してレスポンスからリクエストを分離します。
他のサービスからのレスポンスをキャッシュに保存し、依存関係が短期的に使用不能な状態から復元します。

サービスのエラーまたは低下で、このサービスに依存する他のコンポーネントへの悪影響を軽減するには、次のような設計手法と原則の例を検討してください。

優先順位の高いリクエストキューを使用し、ユーザーがレスポンスを待機しているリクエストの優先度を高くします。
レイテンシと負荷を軽減するために、キャッシュからレスポンスを配信する。
機能を維持しながらフェイルセーフを実現する。
トラフィックが過負荷の状態に達した場合には、サービスレベルを適切に引き下げる。

すべての変更をロールバックできるようにする

特定のタイプの変更を元に戻せる方法が明確に定義できない場合は、ロールバックをサポートするようにサービスの設計を変更します。定期的にロールバックプロセスをテストします。API が進化しても前世代のクライアントが正しく動作するように、すべてのコンポーネントまたはマイクロサービスの API はバージョニングする必要があります。この設計原則は、API の変更を段階的にロールアウトし、必要に応じて迅速にロールバックできるようにするために不可欠です。

モバイルアプリの場合、ロールバックの実装にコストがかかる可能性があります。Firebase Remote Config は、機能のロールバックを容易にする Google Cloud サービスです。

データベーススキーマの変更をすぐにロールバックすることはできないため、複数のフェーズで実行します。各フェーズは、アプリケーションの最新バージョンと以前のバージョンで安全なスキーマの読み取りと更新を可能にするように設計します。この設計アプローチにより、最新バージョンで問題が発生した場合に安全にロールバックできます。

推奨事項

アーキテクチャフレームワークのガイダンスを実際の環境に適用するには、次の推奨事項に従ってください。

クライアントアプリケーションのエラー再試行ロジックで、ランダム化を使用して指数バックオフを実装
高可用性を実現する自動フェイルオーバーを備えたマルチリージョンアーキテクチャを実装します。
ロードバランシングを使用して、シャードとリージョンにユーザーリクエストを分散します。
アプリケーションのサービスレベルが過負荷状態で適切に下がるように設計します。部分レスポンスを配信するか、機能を制限することによって機能不全を回避します。
容量計画のためのデータドリブンプロセスを確立し、負荷テストとトラフィック予測を使用して、リソースをプロビジョニングするタイミングを決定します。
障害復旧手順を確立し、定期的にテストします。

次のステップ

信頼性の高い運用プロセスとツールを作成する（このシリーズの次のドキュメント）

信頼性の高い運用プロセスとツールを作成する

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 のエラーとタイムアウト、利用できるリソースの縮小などがあります。ランダムなフォールトインジェクションを使用して、サービスの依存関係で断続的な障害（フラッピング）をテストします。本番環境でこうした動作を検出して軽減することは困難です。

カオスエンジニアリングにより、このようなテストからの影響を最小限に抑えることができます。このようなテストは、実際に発生する障害の練習として捉え、収集したすべての情報を使用して障害発生時の対応を改善します。

次のステップ

効率的なアラートを作成する（このシリーズの次のドキュメント）

効率的なアラートを作成する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、信頼性の高いサービスの運用に役立つアラートを作成するための運用原則を説明します。サービスがどのように機能しているかに関する情報が多いほど、問題が発生した際に、より多くの情報に基づいて判断することが可能になります。ユーザーに影響を与えるシステムの問題をすべて素早く正確に検出するようにアラートを設計し、誤検出を最小限に抑えます。

アラートの遅延を最適化する

運用チームに負荷のかける早すぎるアラートと、サービスの長時間停止の原因となる遅すぎるアラートのバランスを取る必要があります。モニタリングシステムで問題を担当者に通知する前に、アラートの遅延を調整して、信号対雑音を最大化しながら検出時間を最小化します。エラーバジェットの消費率から、最適なアラート構成を導き出します。

原因ではなく症状をアラート対象にする

ユーザーエクスペリエンスへの直接的な影響に基づいてアラートをトリガーします。グローバル SLO または顧客ごとの SLO に関する違反は、直接的な影響があります。特に影響が単一のレプリカに限定されている場合は、障害の根本的な原因をすべてアラート対象にしないでください。適切に設計された分散システムは、単一レプリカの障害からシームレスに回復します。

平均ではなく外れ値をアラート対象にする

レイテンシをモニタリングするときは、SLO を定義し、平均または 50 パーセンタイルのレイテンシではなく、90 パーセンタイル、95 パーセンタイル、99 パーセンタイルのレイテンシのアラートを設定します（3 つのうちの 2 つを選択）。レイテンシの平均値または中央値が適切な値を使用すると、90 パーセンタイル以上で許容できない高い値が表示されないことがあり、ユーザーエクスペリエンスが大幅に低下する可能性があります。ウェブサーバーでのリクエスト / レスポンスのインタラクション、データ処理パイプラインでのバッチ完了、ストレージサービスでの読み取り / 書き込みオペレーションなど、重要なオペレーションのレイテンシをモニタリングする場合は、この原則を使用して外れ値に関するアラートを適用する必要があります。

共同インシデント管理プロセスを構築する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、サービスを管理し、インシデントに対応するプロセスを定義するためのベストプラクティスについて説明します。インシデントは、すべてのサービスで発生するため、効率的に対応してこの問題を軽減するには、詳細が文書化されたプロセスが必要です。

インシデント管理の概要

適切に設計されたシステムでも、いつかは SLO を下回ることになります。SLO がない場合でも、ユーザーにより過去の経験に基づいて許容可能なサービスレベルが大まかに定義されます。SLA の内容に関係なく、テクニカルサポートや同様のグループにエスカレーションされます。

ユーザーに適切なサービスを提供するため、インシデント管理計画を確立し定期的にテストします。その計画は、1 ページで 10 項目のチェックリストのような短いものでかまいません。このプロセスによって、チームは検出時間（TTD）と軽減時間（TTM）を短縮できます。

TTR ではなく TTM が推奨されます。TTR の R は、修復または復元を意味し、軽減策ではなく完全修正を意味するからです。TTM は、停止による顧客への影響を迅速に終了させる迅速な軽減を重視し、問題を完全に解決するために通常より長いプロセスを開始します。

優れた操作性を備えたシステムを設計すれば、故障間隔時間（TBF）が長くなります。つまり、優れたインシデント管理などの信頼性を確保するための運用原則は、障害の発生頻度を低くすることを目標とします。

信頼性の高いサービスを実行するには、インシデント管理プロセスに次のベストプラクティスを適用します。

明確なサービスオーナーを割り当てる

すべてのサービスとそれらの重要な依存関係には、SLO を遵守する明確なオーナーが必要です。再編成やチームの人員削減が行われる場合、エンジニアリングリードは、必要に応じてドキュメントやトレーニングとともに、所有権を新しいチームに明示的に引き継ぐ必要があります。サービスのオーナーが他のチームからも簡単にわかるようにする必要があります。

適切に調整されたアラートによって検出時間（TTD）を短縮する

TTD を短縮する前に、インフラストラクチャとアプリケーションへのオブザーバビリティ組み込みで最適化案を審査して実施し、アーキテクチャ・フレームワーク信頼性カテゴリのセクションを信頼性の目標と定義します。たとえば、アプリケーションの問題と基盤となるクラウドの問題を明確に区別します。

適切に調整された一連の SLI は、アラートの過負荷を発生させることなく、適切なタイミングでチームに通知します。詳細については、アーキテクチャフレームワーク信頼性カテゴリの効率的なアラートを作成するセクションまたは SLI 指標の調整: CRE ライフレッスンを調整するをご覧ください。

インシデント管理計画とトレーニングによって軽減時間（TTM）を短縮する

TTM を短縮するには、文書化され、十分に訓練されたインシデント管理計画を定義します。環境の変更点に関するデータは、すぐに入手できるようにしてください。迅速に適用して TTM を最小化できる一般的な緩和策をチームに周知してください。これらの緩和策には、ドレイン、変更のロールバック、リソースの規模拡大、サービス品質を低下させることが含まれます。

別のアーキテクチャフレームワークの信頼性カテゴリに関するドキュメントで説明されているように、信頼性の高い運用プロセスとツールを作成して、変更の安全性と迅速なロールバックをサポートします。

ダッシュボードのレイアウトとコンテンツを設計して TTM を最小化する

サービスダッシュボードのレイアウトとナビゲーションを整理して、サービスとそのすべての重要な依存関係が実行されているかどうかをオペレータが 1～2 分で判断できるようにします。問題の潜在的な原因をすばやく特定するには、ダッシュボード上のすべてのグラフをスキャンして、アラートの時点で大幅に変化するグラフをすばやく探し出すことができるようにする必要があります。

トラブルシューティングに役立つよう、以下に例示するようなグラフがダッシュボードに表示されることもあります。インシデント対応者は、単一のビューから以下を一目で確認できる必要があります。

サービスレベル指標（成功したリクエストを有効なリクエストの合計数で割ったなど）
構成やバイナリのロールアウト
システムへの 1 秒あたりのリクエスト数
システムからの 1 秒あたりのエラーレスポンス数
システムからその依存関係への 1 秒あたりのリクエスト数
依存関係からシステムへの 1 秒あたりのエラーレスポンス数

トラブルシューティングに役立つその他の一般的なグラフには、レイテンシ、飽和度、リクエストサイズ、レスポンスサイズ、クエリ費用、スレッドプール使用率、Java 仮想マシン（JVM）の指標（該当する場合）があります。飽和度とは、割り当てやシステムメモリサイズなど、一定の上限による完全性のことです。スレッドプールの使用率は、プールの枯渇による回帰を探します。

いくつかの停止シナリオに対してこれらのグラフの配置をテストし、最も重要なグラフが上部に近くなり、グラフの順序が標準の診断ワークフローと一致するようにします。また、ML と統計的異常検出を適用して、これらのグラフの適切なサブセットの表示もできます。

既知の停止シナリオの診断手順と軽減策を文書化する

ハンドブックを作成し、アラート通知にハンドブックへのリンクを追加します。アラート通知からこうしたドキュメントにアクセスできると、オペレータがトラブルシューティングと問題の軽減に必要な情報をすばやく入手できます。

過失を責めない事後検証により、サービス停止の教訓を活かして再発を防止する

過失を責めない事後検証の文化とインシデントのレビュープロセスを確立します。過失を責めないとは、チームが過失を責めることなく、問題点を客観的に評価して文書化することを意味します。

失敗は学習の機会とみなされ、批判の対象にはなりません。システムの復元力を高めて、人為的ミスから迅速に回復できるようにするか、さらには人為的ミスを検出して防止できるようにします。それぞれの事後分析からできるだけ多くの学習を抽出して事後分析のアクションアイテムに注意しながら対処し、サービス停止の回数を減らして TBF を増加させます。

インシデント管理計画の例

本番環境の問題が、アラートやページなどから検出された、または自分にエスカレーションされました。

他の誰かに委任する必要がありますか？
- 自分たちで解決できない場合は、「はい」です。
これはプライバシーやセキュリティの侵害ですか？
- 「はい」の場合、プライバシーチームまたはセキュリティチームに委任します。
この問題は緊急事態ですか、あるいは SLO が達成できなくなる恐れがありますか？
- 疑わしい場合は、緊急事態として処理します。
人員を増やす必要がありますか？
- お客様の X% 以上に影響が及ぶ場合、あるいは解決に Y 分以上かかる場合は、「はい」です。疑わしい場合は、（特に営業時間中には）より多くの人員で取り組みます。
メインの通信チャネル（IRC、Hangouts Chat、Slack など）を定義します。
次のような事前定義のロールを委任します。
- 全体的な調整を担当するインシデントコマンダー。
- 内部および外部のコミュニケーションを担当するコミュニケーションリーダー。
- 問題の軽減を担当するオペレーションリーダー。
インシデントがいつ終了するかを定義します。この決断には、サポート担当者や他の同様のチームからの承認が必要になります。
過失を責めない事後分析に協力します。
事後分析インシデントレビュー会議に参加して話し合い、タスクの割り当てを行います。

推奨事項

アーキテクチャフレームワークのガイダンスを実際の環境に適用するには、次の推奨事項に従ってください。

インシデント管理計画を確立し、それを使用するチームをトレーニングします。
TTD を短縮するには、インフラストラクチャとアプリケーションにオブザーバビリティを組み込むための推奨事項を実装します。
インシデントがあるときに一目で確認できる、「変更内容」ダッシュボードを作成します。
クエリスニペットを文書化するか、頻繁なログクエリを使用して Looker Studio ダッシュボードを構築します。
Firebase Remote Config を評価して、モバイルアプリケーションのロールアウトの問題を軽減します。
障害復旧のテストを実施し、バックアップからデータを復元するなどして、インシデントのサブセットの TTM を短縮します。
構成とバイナリのロールバックを設計してテストします。
障害復旧のためにリージョン間でデータを複製し、障害復旧テストを使用して、リージョンの停止後の TTM を短縮します。
TBF を増やすために、高可用性に対するビジネスニーズによりコストが正当化される場合には、リージョンの停止に対する耐障害性を確保するためのマルチリージョンアーキテクチャを設計します。

次のステップ

詳細については、次のリソースを使用して共同インシデント管理プロセスを構築する方法をご覧ください。

Google Cloud アーキテクチャフレームワーク: プロダクト信頼性ガイド

アーキテクチャフレームワークのこのセクションには、一部の Google Cloud プロダクトの信頼性、可用性、整合性に関するプロダクト固有のベストプラクティスガイダンスが記載されています。また、障害を最小限に抑えて復旧するための推奨事項と、負荷がかかった状態でアプリケーションを十分にスケーリングするための推奨事項も提供します。

プロダクト信頼性ガイドは次の領域で構成されています。

コンピューティング
ストレージとデータベース
- Cloud Storage
- Firestore
- Bigtable
- Cloud SQL
- Spanner
- Filestore
- Memorystore
ネットワーキング
データ分析

Compute Engine 信頼性ガイド

Compute Engine はカスタマイズ可能なコンピューティングサービスであり、ユーザーは Google のインフラストラクチャで仮想マシンをオンデマンドで作成、実行できます。

ベストプラクティス

Compute Engine API のベストプラクティス - Compute Engine API を使用し、API のレート上限の影響を緩和するための推奨のベストプラクティス。
復元性の高いシステムの設計 - 単一 VM の障害や再起動、ゾーンまたはリージョンの障害から復旧するように Compute Engine アプリケーションを設計する方法に関する詳細なガイダンス。
オーバープロビジョニングで可用性を向上させる方法 - ゾーンやリージョンの中断による容量の損失に直面したときにアプリケーションを実行し続けるために、冗長リソースを追加。
可用性の高いアプリケーションでのロードバランシングの使用 - Cloud Load Balancing と Compute Engine を使用して、ゾーン停止中であっても高可用性を実現する方法。
Compute Engine リージョン選択のベストプラクティス - Compute Engine リソースに使用する Google Cloud リージョンを選択し、価格とパフォーマンスのトレードオフを考慮しながらアプリケーションのレイテンシを最適化する方法
Migrate to Virtual Machines を使用した VM の移行に関するベストプラクティス - 評価、計画、移行の実施など、Migrate for Virtual Machines を使用して、サポートされている移行元の環境から Compute Engine に VM を移行する方法。また、移行の際に発生する可能性のある一般的な問題への対処方法についても説明します。
Compute Engine でフローティング IP アドレスを使用するパターン - アーキテクチャをユースケースのパターンに変更することで、Compute Engine 環境で共有または仮想 IP アドレスを実装する方法。パターンには、ロードバランシング、Google Cloud ルート、自動修復を使用するパターンが含まれます。
永続ディスクのスナップショットに関するベストプラクティス - スナップショットをより迅速に、より高い信頼性を確保しつつ作成します。
永続ディスクとレプリケーション - 永続ディスクが Colossus をストレージバックエンドとして使用し、VM から永続ディスクにアクセスする方法。また、永続ディスクレイテンシのモニタリング、リージョン間やゾーン間での永続ディスクの複製、レプリカの読み取りおよび書き込みリクエストの処理方法も確認します。
パフォーマンス要件を満たすようにディスクを構成する - VM インスタンスに接続されているブロックストレージボリュームのパフォーマンスに影響する要素です。
イメージ管理のベストプラクティス - ブートイメージの選択、イメージのカスタマイズ、イメージのライフサイクル、プロジェクト間でのイメージの共有など、Compute Engine イメージの管理に関する詳細なガイダンス。
イメージファミリーのベストプラクティス - 本番環境で使用する前にイメージファミリー内の最新のイメージをテストすることの重要性と、テスト手順の設定方法。
SQL Server インスタンスのベストプラクティス - Microsoft SQL Server を実行する Compute Engine インスタンスの最適化と SQL Server Enterprise Edition の最適化のベストプラクティス。さらに、オペレーティングシステムのデフォルトのネットワーク設定と運用アクティビティを使用してパフォーマンスと安定性を高める方法についても説明します。

Cloud Run 信頼性ガイド

Cloud Run は、コンテナ化されたアプリケーションのデプロイに適したマネージドコンピューティングプラットフォームであり、サーバーレスです。Cloud Run はすべてのインフラストラクチャを抽象化するため、ユーザーはアプリケーションの構築に注力できます。

ベストプラクティス

Cloud Run の一般的なヒント - Cloud Run サービスの実装、コンテナの迅速な起動、グローバル変数の使用、コンテナセキュリティの改善を行う方法。
負荷テストのベストプラクティス - 負荷テスト前の同時実行の問題への対処、最大インスタンス数の管理、負荷テストに最適なリージョンの選択、負荷に応じたサービスのスケーリングなど、Cloud Run サービスの負荷テストの方法。
インスタンスのスケーリング - コンテナインスタンスをスケーリングして制限する方法、および一部のインスタンスを停止せずにアイドル状態にすることでレスポンス時間を最小限に抑える方法。
最小数のインスタンスの使用 - 処理を実施するための準備が完了しているコンテナインスタンスの最小数を指定します。適度に高く設定されている場合は、コールドスタートの数を削減して平均レスポンス時間を最小化します。
Java アプリケーションを Cloud Run 用に最適化 - Java で記述された Cloud Run サービスの最適化に関するトレードオフを理解し、起動時間とメモリ使用量を削減します。
Python アプリケーションを Cloud Run 用に最適化 - WSGI サーバーの効率を高め、コンテナイメージを最適化し、スレッド数を減らすとともに起動タスクを並列に実行して、アプリケーションを最適化します。

Cloud Functions 信頼性ガイド

Cloud Functions はスケーラブルなイベントドリブン型のサーバーレスプラットフォームであり、サービスの構築と接続に役立ちます。Cloud Functions の関数は、HTTP リクエスト経由で呼び出すことも、バックグラウンドイベントに基づいてトリガーすることもできます。

ベストプラクティス

Cloud Functions のベストプラクティス - Cloud Functions の使用方法と操作方法、べき等性の実装、関数のデプロイ、パフォーマンスの最適化に関するガイドライン。

Google Kubernetes Engine 信頼性ガイド

Google Kubernetes Engine（GKE）は、コンテナ化されたアプリケーションをクラウドで大規模に運用するためのシステムです。GKE は、コンテナ化されたアプリケーションのリソースをデプロイ、管理、プロビジョニングします。GKE 環境は Compute Engine インスタンスで構成され、これらのインスタンスがグループ化されてクラスタを形成します。

ベストプラクティス

コンテナ運用のベストプラクティス - ロギングメカニズムの使用方法、コンテナのステートレス化と不変化、アプリケーションのモニタリング、実行状況と準備プローブの実行方法。
コンテナ構築のベストプラクティス - コンテナごとにアプリケーションを 1 つパッケージ化し、プロセス ID（PID）を処理する方法、Docker ビルドキャッシュを最適化する方法、アップロードとダウンロード時間を短縮するためにより小さいイメージをビルドする方法。
Google Kubernetes Engine ネットワーキングのベストプラクティス - VPC ネイティブクラスタを使用してスケーリングを容易にする、IP アドレスを計画する、クラスタ接続をスケールする、Google Cloud Armor を使用して分散型サービス拒否攻撃（DDoS）をブロックする、実装するコンテナネイティブのロードバランシングを実装してレイテンシを短縮する、外部アプリケーションロードバランサのヘルスチェック機能を使用して正常なフェイルオーバーを実現する、リージョンクラスタを使用してクラスタ内のアプリケーションの可用性を向上させる。
クラウドベースの Kubernetes アプリケーションを準備する - ベストプラクティスに沿って、アプリケーションのキャパシティを計画する、アプリケーションを水平方向または垂直方向に拡張する、メモリと CPU のリソースリクエストに対して相対的なリソース制限を設定する、コンテナの無駄を省いてアプリケーションの起動を高速化する、Pod Disruption Budget（PDB）を設定して Pod による中断を制限する。また、アプリケーションの正常な起動のために liveness プローブと readiness プローブを設定する方法、中断のないシャットダウンを確保する方法、再試行されたリクエストに対して指数バックオフを実装してアプリケーションの負荷が急増するのを防ぐ方法を理解する。
GKE マルチテナンシーのベストプラクティス - 高可用性と信頼性を備えたマルチテナントクラスタアーキテクチャを設計する方法、テナントごとの使用状況の指標に Google Kubernetes Engine（GKE）の使用状況測定を使用する方法、テナント固有のログを提供する方法、テナント固有のモニタリングを行う方法。

Cloud Storage 信頼性ガイド

Cloud Storage は高度なセキュリティと共有機能を備えた、耐久性と高可用性を備えたオブジェクトリポジトリです。このサービスは、Google Cloud インフラストラクチャでのデータの保存とアクセスに使用されます。

ベストプラクティス

Cloud Storage のベストプラクティス - アプリケーションの可用性の最大化と、レイテンシの最小化、アップロードオペレーションの信頼性の改善、大規模なデータ削除のパフォーマンス改善を実現するためのおすすめの方法を含む、Cloud Storage に関する一般的なベストプラクティス。
リクエストレートとアクセス分散のガイドライン - Cloud Storage の自動スケーリングの仕組みを理解して、非常に高いリクエストレートでの読み取り、書き込み、削除の各オペレーションのレイテンシとエラーレスポンスを最小限に抑える方法について説明します。

Firestore 信頼性ガイド

Firestore は NoSQL ドキュメントデータベースであり、モバイルアプリやウェブアプリケーションのデータの保存、同期、クエリをグローバル規模で行うことができます。

ベストプラクティス

Firestore のベストプラクティス - 信頼性向上のためのデータベースのロケーションの選択方法、インデックス登録のパフォーマンスの問題を最小限に抑える方法、読み取り / 書き込みオペレーションのパフォーマンスを向上させる方法、変更通知のレイテンシを短縮する方法、スケールの設計方法。

Bigtable 信頼性ガイド

Bigtable は、大規模な分析ワークロードにも運用ワークロードにも対応できる、フルマネージドのスケーラブルな NoSQL データベースです。スパースに格納されるテーブルとして設計され、数十億行、数千列の規模にスケール可能であり、低レイテンシで高スループットの読み取りと書き込みをサポートしています。

ベストプラクティス

Bigtable のパフォーマンスを理解する - Bigtable のスループットの見積もり、スループットとストレージ使用状況を確認して Bigtable の容量を計画する方法、レプリケーションを有効にすることで読み取りと書き込みのスループットに異なる影響が及ぶ仕組み、Bigtable が時間の経過とともにデータをどのように最適化するか。
Bigtable のスキーマ設計 - Key-Value ストアのコンセプト、計画された読み取りリクエストに基づく行キーの設計、列と行の処理、特別なユースケースなど、Bigtable スキーマの設計に関するガイダンス。
Bigtable レプリケーションの概要 - Bigtable を複数のゾーンまたはリージョンに複製する方法、レプリケーションのパフォーマンスへの影響、Bigtable が競合を解決してフェイルオーバーを処理する方法。
Bigtable のバックアップについて - Bigtable バックアップを使用してテーブルのスキーマとデータのコピーを保存する方法。これは、アプリケーションレベルのデータ破損や、テーブルを誤って削除するなどのオペレーターのエラーから回復するときに役立ちます。

Cloud SQL 信頼性ガイド

Cloud SQL は、MySQL、PostgreSQL、SQL Server 用のフルマネージドリレーショナルデータベースサービスです。Cloud SQL は、既存のアプリケーションや、Google Kubernetes Engine や BigQuery などの Google Cloud サービスと簡単に統合できます。

ベストプラクティス

Cloud SQL の高可用性 - リードレプリカの処理やフェイルオーバープロセスなど、Cloud SQL の高可用性構成の概要。また、データベースメンテナンスイベントのタイミングを制御する方法と、HA 構成でリージョン永続ディスクを使用するとデータベースのパフォーマンスにどのように影響するかについても説明します。このコンテンツは、次の 3 つのセクションに分かれています。
Cloud SQL データベースの障害復旧 - クロスリージョンリードレプリカを使用した Cloud SQL の障害復旧構成の概要。
Cloud SQL の一般的なベストプラクティス - インスタンスの構成、データアーキテクチャ、データのインポートとエクスポート、バックアップと復元に関するガイダンス。このコンテンツは、次の 3 つのセクションに分かれています。
データのインポートとエクスポートに関するベストプラクティス - Cloud Storage バケットを使用できない状況、データの圧縮によるコスト削減、データのインポートとエクスポートに関する既知の制限、エクスポートオペレーションの自動化方法、インポートとエクスポートのオペレーションのトラブルシューティング。

Spanner 信頼性ガイド

Spanner は、SQL の分散型データベース管理およびストレージサービスであり、グローバルトランザクション、高可用性の水平スケーリング、トランザクションの整合性などの機能を備えています。

ベストプラクティス

Spanner のバックアップと復元 - Spanner のバックアップと復元の主な機能、バックアップと復元およびインポートとエクスポートの比較、実装の詳細、Spanner リソースへのアクセスの制御方法。
リージョン構成とマルチリージョン構成 - Spanner が提供する 2 種類のインスタンス構成（リージョン構成とマルチリージョン構成）についての説明。説明には、各構成の違いやトレードオフについても含まれます。
Spanner の自動スケーリング - Spanner 用のオートスケーラーツール（オートスケーラー）の概要。このツールはオープンソースのツールであり、Cloud Spanner のコンパニオンツールとして使用できます。このツールを使用すると、各 Spanner インスタンスの利用率指標に基づいて、1 つ以上の Spanner インスタンスのノードまたは処理ユニットの数を自動的に増減できます。
ポイントインタイムリカバリ（PITR）について - Spanner データの偶発的な削除や書き込みを防ぐ Spanner のポイントインタイムリカバリ（PITR）の説明。たとえば、オペレーターがデータを誤って書き込みした場合や、アプリケーションロールアウトによってデータベースが破損した場合、PITR を使用すると、最長で過去 7 日前までのデータを復元できます。
Spanner のベストプラクティス - 一括読み込み、データ操作言語（DML）の使用、ホットスポットを回避するスキーマの設計、SQL のベストプラクティスに関するガイダンス。

Filestore 信頼性ガイド

Filestore は、Google Cloud アプリケーション向けのマネージドファイルストレージサービスで、データ用のファイルシステムインターフェースと共有ファイルシステムを備えています。Filestore は、Compute Engine および Google Kubernetes Engine のインスタンス向けに、ペタバイト規模のオンラインネットワーク接続ストレージ（NAS）を提供します。

ベストプラクティス

Filestore のパフォーマンス - パフォーマンス設定と Compute Engine マシンタイプの推奨事項、Linux クライアント VM インスタンスでのパフォーマンス最高の NFS マウントオプション、パフォーマンスのテストでの fio ツールの使用。複数の Google Cloud リソース全体でパフォーマンスを改善するための推奨事項が含まれています。
Filestore のバックアップ - Filestore のバックアップ、一般的なユースケース、バックアップの作成と使用に関するベストプラクティスの説明。
Filestore スナップショット - Filestore スナップショットの説明、一般的なユースケース、スナップショットの作成と使用のベストプラクティス。
Filestore ネットワーキング - Filestore を使用するために必要な、ネットワーキングと IP リソースの要件。

Memorystore 信頼性ガイド

Memorystore はフルマネージドのインメモリストアであり、Redis と Memcached という 2 つのオープンソースキャッシュソリューションのマネージドバージョンを提供します。Memorystore はスケーラブルで、プロビジョニング、レプリケーション、フェイルオーバー、パッチ適用などの複雑なタスクを自動化します。

ベストプラクティス

Redis の一般的なベストプラクティス - Redis データベース（RDB）バックアップのエクスポート、リソースを大量に消費するオペレーション、接続の再試行が必要なオペレーションに関するガイダンス。さらに、メンテナンス、メモリ管理、サーバーレス VPC アクセスコネクタの設定、プライベートサービスアクセス接続モード、モニタリングとアラートに関する情報も含まれています。
Redis メモリ管理のベストプラクティス - インスタンス容量や Maxmemory の構成などのメモリ管理のコンセプト、エクスポート、スケーリング、バージョンアップグレードオペレーション、メモリ管理指標、メモリ不足の解決方法。
Redis 指数バックオフ - 指数バックオフの仕組み、アルゴリズムの例、最大バックオフと最大再試行回数の仕組み。
Memcached のベストプラクティス - キャッシュミスに対応するアプリケーションの設計方法、ノードの IP アドレスへの直接接続、Memcached の自動検出サービス。また、max-item-size パラメータの構成、クラスタのバランス確保、Cloud Monitoring を使用した重要指標のモニタリングに関するガイダンスも含まれます。
Memcached メモリ管理のベストプラクティス - Memcached インスタンスのメモリの構成、予約済みメモリの構成、予約済みメモリを増やすタイミング、メモリ使用量の指標。

Cloud DNS 信頼性ガイド

Cloud DNS は、ドメインの登録、管理、提供に役立つ低レイテンシのドメインネームシステムです。Cloud DNS は、非常に多くの DNS ゾーンやレコードにまでスケールできるため、ユーザーインターフェースで数百万件もの DNS レコードを作成、更新できます。

ベストプラクティス

Cloud DNS のベストプラクティス - 限定公開ゾーンの管理、DNS 転送の構成、DNS サーバーポリシーの作成を行う方法を学習します。ハイブリッド環境で Cloud DNS を使用するためのガイダンスが含まれています。

Cloud Load Balancing 信頼性ガイド

Cloud Load Balancing はソフトウェア定義の完全分散型マネージドサービスで、あらゆるトラフィックに対応しています。Cloud Load Balancing では、シームレスな自動スケーリング、レイヤ 4 およびレイヤ 7 のロードバランシングに加え、IPv6 グローバルロードバランシングなどの機能もサポートしています。

ベストプラクティス

パフォーマンスに関するベストプラクティス - アプリケーションインスタンス間で負荷を分散して、最適なパフォーマンスを実現する方法。戦略には、トラフィックに最も近いリージョンへのバックエンドの配置、キャッシュ保存、転送ルールプロトコルの選択、セッションアフィニティの構成などが含まれます。
可用性の高いアプリケーションでのロードバランシングの使用 - Cloud Load Balancing と Compute Engine を使用して、ゾーン停止中であっても高可用性を実現する方法。

Cloud CDN 信頼性ガイド

Cloud CDN（コンテンツ配信ネットワーク）は、Google のエッジネットワークを使用してコンテンツをユーザーのできるだけ近くに配置することで、インターネットコンテンツ配信を加速するサービスです。Cloud CDN ではレイテンシが短縮され、費用が削減され、負荷が軽減されるため、ユーザーへのサービスのスケーリングが容易になります。

ベストプラクティス

コンテンツ配信のベストプラクティス - キャッシュキーを使用してキャッシュヒット率を最適化する方法、パフォーマンス向上のために HTTP/3 を有効にする方法、Cloud CDN カスタムモニタリングダッシュボードを使用してモニタリング指標を確認する方法について説明します。また、サードパーティパフォーマンステストでの可用性、レイテンシ、スループットに関するレポートを確認する方法を説明します。

BigQuery 信頼性ガイド

BigQuery は、大規模なデータを保存、分析するための Google Cloud のデータウェアハウスプラットフォームです。

ベストプラクティス

信頼性の概要 - 信頼性のベストプラクティスと、可用性、耐久性、データ整合性などのコンセプトの概要。
可用性と耐久性 - Google Cloud データセンターで発生する可能性のある障害発生ドメインの種類、BigQuery がデータストレージのロケーションに基づいてストレージの冗長性を提供する方法、クロスリージョンデータセットが障害復旧を強化する理由。
BigQuery でのマルチテナントワークロードに関するベストプラクティス - マルチテナントデータプラットフォームで使用される一般的なパターン。これらのパターンには、Software as a Service（SaaS）ベンダーのお客様の信頼性と分離の確保、BigQuery の重要な割り当てとキャパシティプランニングの上限、関連するデータセットを別のリージョンにコピーするための BigQuery Data Transfer Service の使用などがあります。
マテリアライズドビューを使用する - マテリアライズドビューに対してクエリを実行する、パーティションを配置する、スマートな調整（クエリの自動書き換え）を理解するなど、より低コストでより高速のクエリを実現するために BigQuery マテリアライズドビューを使用する方法。

Dataflow 信頼性ガイド

Dataflow は、オープンソースの Apache Beam ライブラリを使用した高速でシンプルなストリーミングデータパイプラインの開発を可能にするフルマネージドデータ処理サービスです。Dataflow は自動スケーリングとバッチ処理を介して、レイテンシ、処理時間、コストを最小限に抑えます。

ベストプラクティス

Dataflow を使用した本番環境対応データパイプラインの構築 - Dataflow パイプライン計画、開発、デプロイ、モニタリングなどの Dataflow の使用方法に関するドキュメントシリーズです。

概要 - Dataflow パイプラインの概要です。
計画 - SLO を測定し、パイプラインのスケーラビリティとパフォーマンスに対するデータソースとシンクの影響を把握して、Dataflow ジョブを実行するリージョンを指定するときに高可用性、障害復旧、ネットワークパフォーマンスを考慮します。
開発とテスト - デプロイ環境の設定して、エラー処理にデッドレターキューを使用することでデータ損失を防止し、費用がかかる要素ごとのオペレーションの最小化によってレイテンシとコストを削減します。また、バッチ処理を使用することで外部サービスに負担をかけずにパフォーマンスオーバーヘッドを削減します。不適切に融合されたステップの融合を解除して、パフォーマンス向上のためにステップが切り離されるようにします。本番前環境でエンドツーエンドテストを実行してパイプラインが引き続き SLO やその他の本番環境に対応していることを確認します。
デプロイ - 新しいバージョンのストリーミングパイプラインのデプロイに関して特別に考慮した継続的インテグレーション（CI）と継続的デリバリーとデプロイ（CD）について説明します。また、CI / CD パイプラインの例と、リソース使用量を最適化するいくつかの機能を紹介します。最後に、パイプラインの信頼性向上のための高可用性、地理的冗長性、ベストプラクティスについて説明します（リージョン分離、スナップショットの使用、ジョブ送信エラーの処理、実行中のパイプラインに影響するエラーと停止からの復旧など）。
モニタリング - パイプラインパフォーマンスの重要な指標であるサービスレベル指標（SLI）を確認し、サービスレベル目標（SLO）を定義して測定します。

Dataproc 信頼性ガイド

Dataproc は、Apache Hadoop と Spark のジョブを実行するためのフルマネージドでスケーラブルなサービスです。Dataproc を使用すると、必要に応じて仮想マシンをカスタマイズし、スケールアップまたはスケールダウンできます。Dataproc は、Cloud Storage、BigQuery、Bigtable、その他の Google Cloud サービスと緊密に連携されています。

ベストプラクティス

Dataproc 高可用性モード - インスタンス名、Apache ZooKeeper、Hadoop Distributed File System（HDFS）、Yet Another Resource Negotiator（YARN）について、Hadoop 高可用性モードとデフォルトの非 HA モードを比較します。また、高可用性クラスタの作成方法も説明します。
クラスタの自動スケーリング - Dataproc 自動スケーリングを使用するタイミング、自動スケーリングポリシーの作成方法、マルチクラスタポリシーの使用方法、自動スケーリング構成に関する信頼性のベストプラクティス、指標とログ。
Dataproc の高度な柔軟性モード（EFM） - 高度な柔軟性モードを使用したジョブの進行状況の遅延の最小化の例、パーティショニングや並列処理などの高度な構成、EFM クラスタでの YARN の正常なデコミッション。
正常なデコミッション - 正常なデコミッションを使用してクラスタからワーカーを削除した場合の影響を最小限に抑える方法、セカンダリワーカーでこの機能を使用する方法、正常なデコミッションのコマンドの例。
再実行可能なジョブ- オプションの設定を使用することで、メモリ不足の問題や Compute Engine 仮想マシンの予期しない再起動など、一般的な種類のジョブ失敗を軽減するために障害発生時に再実行するようにジョブを設定できます。

Google Cloud Architecture Framework: 費用の最適化

Google Cloud アーキテクチャフレームワークのこのカテゴリでは、Google Cloud のワークロードの費用を最適化するアーキテクト、デベロッパー、管理者、その他のクラウド使用者に向けの最適化案を設計し、ベストプラクティスについて説明します。

IT ワークロードをクラウドに移行すると、大規模なイノベーション、機能の迅速な提供、進化する顧客ニーズへの対応に役立ちます。既存のワークロードを移行する場合、またはクラウド向けに構築されたアプリケーションをデプロイする場合には、セキュリティ、復元力、オペレーショナルエクセレンス、コスト、パフォーマンスのために最適化されたトポロジが必要です。

アーキテクチャフレームワークの費用の最適化に関するカテゴリでは、次の方法を学習します。

FinOps の導入と実装: Google Cloud でリソースをプロビジョニングして管理する際に、費用への影響を従業員に検討させるための戦略。
費用のモニタリングと管理: Google Cloud のリソースの費用を追跡および管理するためのベストプラクティス、ツール、手法。
費用の最適化: コンピューティング、コンテナ、サーバーレス: Compute Engine、Google Kubernetes Engine、Cloud Run、Cloud Functions、App Engine のサービス固有の費用の最適化コントロール。
費用の最適化: ストレージ: Cloud Storage、Persistent Disk、Filestore の費用の最適化コントロール。
費用の最適化: データベースとスマートアナリティクス: BigQuery、Bigtable、Spanner、Cloud SQL、Dataflow、Dataproc の費用の最適化コントロール。
費用の最適化: ネットワーキング: Google Cloud のネットワークリソースの費用の最適化コントロール。
費用の最適化: Cloud Operations: Google Cloud でリソースのモニタリングと管理の費用を最適化するための推奨事項。

FinOps の導入と実装

Google Cloud アーキテクチャフレームワークのこのドキュメントは、Google Cloud でリソースをプロビジョニングして管理する際のアクションと決定事項が費用に与える影響を考慮するうえで役立つ戦略の概要を説明しています。このドキュメントで説明される FinOps とは、組織の規模、クラウド成熟度に関係なく、人、プロセス、テクノロジーを組み合わせて、組織の財務説明責任を促し、費用最適化の取り組みを推進する実践です。

このセクションのガイダンスは、CTO、CIO、組織のクラウド費用を管理する経営幹部を対象としています。このガイダンスは、個々のクラウド運用者が FinOps を理解し、導入するうえでも役立ちます。

組織内のすべての従業員は、ロール（アナリスト、アーキテクト、開発者、管理者）に関係なく、Google Cloud リソースの費用の削減に貢献できます。これまでインフラストラクチャ費用の追跡が不要だったチームの場合、集団的責任の必要性を従業員に教育する必要が生じることがあります。

一般的なモデルでは、中核となる FinOps チームまたは Cloud Center of Excellence（CCoE）が、すべてのクラウドワークロードの費用を最適化するプロセスを標準化します。このモデルは、中核チームに効率向上のための価値の高い機会を特定するうえで必要な知識と専門知識が備わっていることが前提です。

一元化された費用管理は、使用量が少ないクラウド導入の初期段階にはうまく機能する可能性がありますが、クラウドがさらに導入され使用量が増えたときに適切にスケーリングできません。中核チームはスケーリングに悪戦苦闘する可能性があり、プロジェクトチームはチーム外の人の意思決定を受け入れない可能性があります。

リソース最適化の意思決定については、中核チームがプロジェクトチームに委任することをおすすめします。中核チームは、組織全体で FinOps の導入を促進するより幅広い取り組みを推し進めることができます。中核チームは、個々のプロジェクトチームが FinOps を実践できるように、費用最適化のプロセス、報告方法、ツールを標準化する必要があります。中核チームは FinOps の実践に慣れてないチームに緊密に協力して、その意思決定プロセスにおける費用の検討を支援する必要があります。中核チームは、財務チームと個々のプロジェクトチームを仲介する役割も果たす必要があります。

次のセクションでは、中核チームが取り組む設計原則の推奨事項について説明します。

個人としての説明責任を促進する

クラウドリソースを作成して使用するあらゆる従業員が、それらのリソースの使用状況と費用に影響を及ぼします。組織が FinOps の実装を成功させるには、中核チームの働きかけにより、従業員の意識が費用は誰か他の人の責任であるという見かたから自分自身の責任であるという受け入れに移行する必要があります。この移行により、従業員は、ワークロード、チーム、組織に適した費用意思決定を自ら下すことになります。このオーナーシップは、データドリブンな費用最適化アクションの実施に至ります。

費用の説明責任を促進するために、中核チームは次のアクションを実施できます。

費用最適化の機会と手法をユーザーに教育します。
費用を最適化した従業員に報酬を与え、成功を称えます。
費用を組織全体で可視化します。

費用を可視化する

従業員がクラウドのリソースのプロビジョニングと管理を行う際に費用を考慮するには、関連データの可能な限りリアルタイムに近い完全な可視化が必要です。レポートとダッシュボードのデータとして、チームメンバーの決定が費用とビジネスに及ぼす影響を、関連する影響の発生時に示す必要があります。他のチームの使用状況データと費用データは、効率的なデプロイパターンを特定するためのベースラインとして使用できます。このデータは、クラウドサービスの最適な使用方法についての共通の理解を促すのに役立ちます。

組織が費用データの共有を奨励、促進しないと、従業員がデータの共有に消極的になる可能性があります。ビジネス上の理由から、組織が費用の元データの共有を許可しない場合もあります。このような場合でも、費用情報へのアクセスを制限するデフォルトポリシーは避けることをおすすめします。

組織全体で費用を可視化するために、中核チームは次のアクションを実施できます。

クラウドリソースの費用をもれなく計算するため、明確に定義された単一の方法を使用します。たとえば、この方法で、購入時の割引と共有費用（共有データベースの費用など）を基に調整した総クラウド費用を考慮できます。
従業員がクラウド費用を準リアルタイムで確認できるようにダッシュボードを設定します。
チームメンバーに各自が自分自身の費用を抱えているという意識を植え付けるため、チームの垣根を超えてクラウド支出を幅広く可視化します。

コラボレーション行動を可能にする

クラウドリソースの費用を効果的に管理するには、複数のチームが協力して技術プロセスや運用プロセスを改善する必要があります。コラボレーション文化により、複数のチームが一貫したビジネス目標と要素に基づいて費用対効果の高いデプロイパターンを設計できます。

コラボレーション行動を可能にするために、中核チームは次のアクションを実施できます。

他のエンジニアが提案したアーキテクチャのピアレビューを通じて、設計段階での高い費用対効果の保証に役立つワークロードオンボーディングプロセスを作成します。
費用対効果の高いアーキテクチャパターンを生み出すためにチーム横断的なナレッジベースを作成します。

過失を責めない文化を確立する

安心してリスクをとり、必要に応じて修正し、イノベーションを起こせるようにする学習と成長の文化を奨励します。ビジネスの他のあらゆるパートと同様に、IT 設計とデプロイのライフサイクルのどの段階でも、時に高額の費用を伴って、間違いを起こす可能性があることを認めます。

過剰な支出や浪費を行った人を非難するのではなく、費用超過や計算違いの原因を突き止めるうえで役立つ、過失を責めない文化を奨励します。このような環境では、チームメンバーが意見や経験を共有する可能性が高まります。間違いは匿名化され、再発防止のために会社全体で共有されます。

過失を責めない文化と説明責任の欠如を混同しないようにしてください。従業員は引き続き、自分が下した決定と支出に説明責任を負います。しかし、間違いを起こした場合は、ミスの再発を防止するための学習機会に重点が置かれます。

過失を責めない文化を確立するために、中核チームは次のアクションを実施できます。

重大な費用の問題に対して、人を責めない事後分析を行い、関係者よりも問題につながった構造的な根本原因に焦点を合わせます。
費用超過に対処するチームメンバーや、自分が学んだ教訓を他者と共有するチームメンバーを称賛します。チームの他のメンバーに、間違い、講じた対応、学んだ教訓を共有するよう促します。

ビジネス価値を重視する

FinOps の実践では費用の削減に重点が置かれることが多いですが、中核チームは、プロジェクトチームがクラウドリソースのビジネス価値を最大化する意思決定を行えるようにすることに重点を置く必要があります。サービスの最低水準が満たされる地点まで費用を削減する決定をしたいと思うかもしれません。しかし、このような決定により費用が他のリソースにシフトすることが多く、メンテナンス費用の増加につながる可能性や、総所有コストが増加する可能性があります。たとえば、費用削減のために、マネージドサービスではなく仮想マシン（VM）を使用する決定を行うことがあります。しかし、VM ベースのソリューションは、マネージドサービスに比べてメンテナンスにより多くの労力が必要になるため、正味のビジネス価値はマネージドサービスの方が高くなる可能性があります。

FinOps の実践により、プロジェクトチームは、クラウドリソースのビジネス価値を最大化するようにアーキテクチャや運用に関する決定を行ううえで必要な可視性と分析情報が得られます。

従業員がビジネス価値に注力できるように、中核チームは次のアクションを実施できます。

マネージドサービスとサーバーレスアーキテクチャを使用して、コンピューティングリソースの総所有コストを削減します。詳細については、コンピューティングプラットフォームを選択するをご覧ください。
クラウドの使用状況を、費用対効果、復元力、機能リリース速度、イノベーションなど、費用最適化の意思決定を促進するビジネス価値の指標に関連付けます。ビジネス価値の指標の詳細については、クラウド FinOps に関するホワイトペーパーをご覧ください。
クラウドで実行されているすべてのアプリケーションとサービスに単位ベースの費用を実装します。

次のステップ

費用のモニタリングと管理

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud のリソースの費用を追跡、管理するためのベストプラクティス、ツール、手法について説明します。

このセクションのガイダンスは、クラウドにあるリソースをプロビジョニングまたは管理するユーザーを対象としています。

費用管理の重点分野

Google Cloud のリソースにかかる費用は、使用するリソースの量と、それらのリソースに対して課金されるレートによって決まります。

クラウドリソースの費用を管理するには、次の領域に注目することをおすすめします。

費用の可視性
リソースの最適化
レートの最適化

費用の可視性

費用がビジネス成果に及ぼす影響を分析できるようにするため、実際にかかった費用と、リソースやサービスの料金がどのように発生しているかを追跡します。FinOps 運用モデルの使用をおすすめします。このモデルでは、組織全体で費用情報を可視化するために、次のアクションを提案しています。

割り当て: すべての費用項目にオーナーを割り当てます。
レポート: 費用データを利用可能にし、利用可能かつ実用的なものにします。
予測: 今後の費用の見積もりと追跡を行います。

リソースの最適化

クラウドリソースの数とサイズをワークロードの要件に合わせて調整します。可能であれば、マネージドサービスの使用や、アプリケーションの再設計を検討します。一般に、個々のエンジニアリングチームには、リソースのデプロイを最適化する機会と手法に関して、中央の FinOps（財務運用）チームよりも多くの背景があります。FinOps チームが個々のエンジニアリングチームと連携して、組織全体に適用できるリソース最適化の機会を特定することをおすすめします。

レートの最適化

FinOps チームは多くの場合、レートの最適化の決定を一元的に行います。個々のエンジニアリングチームは、中央の FinOps チームと連携して、予約による大幅割引、確約利用割引、Spot VM、定額料金、使用量と契約による割引を受けることをおすすめします。

設計に関する推奨事項

このセクションでは、費用のモニタリングと管理を行うために使用できるアプローチについて説明します。

請求とリソース管理を統合する

Google Cloud で請求とリソースを効率的に管理するには、組織で単一の請求先アカウントを使用し、内部チャージバックの仕組みを使用して費用を割り当てることをおすすめします。互いに影響を及ぼさないエンティティによって緩く結びついている企業グループや組織では、複数の請求先アカウントを使用します。たとえば、販売代理店は顧客ごとに個別のアカウントが必要になることがあります。別々の請求先アカウントを使用すると、国の税制を遵守することもできます。

もう一つのおすすめの方法は、管理するプロジェクトをすべて組織に移行することです。Resource Manager を使用して、次の目標の達成に役立つリソース階層を構築することをおすすめします。

各リソースとその直接の親の関係に基づいて、リソース所有権の階層を確立します。
アクセスポリシーと費用割り当てタグまたはラベルを、組織のリソースにアタッチし、継承する方法を制御します。

また、使用量に応じて、共有サービスの費用を比例配分することをおすすめします。ビジネス目標や優先事項の変更に基づいて、定期的に費用割り当てパラメータを確認し、調整します。

タグまたはラベルを使用して費用の追跡と割り当てを行う

タグとラベルは、Google Cloud リソースにアノテーションを付ける場合に使用できる 2 つの異なる方法です。タグにはラベルよりも多くの機能があります。たとえば、サポートされているリソースにタグが付いているかどうかを条件とする Identity and Access Management（IAM）ポリシーを作成することで、リソースに対するきめ細かい制御を実装できます。また、リソースに関連付けられたタグは、階層内のすべての子リソースに継承されます。タグとラベルの違いについては、タグの概要をご覧ください。

費用の割り当てと追跡に関する新しいフレームワークを構築する場合は、タグを使用することをおすすめします。

必要な粒度で費用データを分類するには、組織のチャージバックメカニズムに適したタグ付けスキーマまたはラベル付けスキーマを確立します。これにより、費用を適切に割り当てることができます。タグは、組織レベルまたはプロジェクトレベルで定義できます。プロジェクトレベルでラベルを割り当て、デフォルトですべてのプロジェクトに適用できる一連のラベルを定義することができます。

タグ付けとラベル付けの異常とラベルのないプロジェクトを検出して修正するプロセスを定義します。たとえば、Cloud Asset Inventory から、プロジェクト内のすべてのリソースのインベントリ（.csv ファイル）をダウンロードし、インベントリを分析して、タグやラベルが割り当てられていないリソースを特定できます。

共有リソースとサービス（一般的なデータストア、マルチテナントクラスタ、サポートサブスクリプションなど）の費用を追跡するには、特別なタグやラベルを使用して共有リソースを含むプロジェクトを特定することを検討してください。

請求のアクセス制御を構成する

Cloud Billing へのアクセスを制御するには、請求先アカウント管理者のロールを、請求連絡先情報を管理するユーザーのみに割り当てることをおすすめします。たとえば、財務、会計、運用部門の従業員はこのロールを必要とする可能性があります。

課金サポートの単一障害点を回避するため、請求先アカウント管理者ロールを複数のユーザーまたはグループに割り当てます。サポートには、請求先アカウント管理者ロールを持つユーザーのみ問い合わせることができます。詳細なガイダンスについては、Cloud Billing のアクセス制御の例と重要なロールをご覧ください。

課金へのアクセスを管理するには、次の構成を行います。

請求先アカウントをプロジェクトに関連付けるには、メンバーに、請求先アカウントに対する請求先アカウントユーザーのロールとプロジェクトに対するプロジェクト支払い管理者のロールが必要です。
チームが請求先アカウントを手動でプロジェクトに関連付けるには、組織レベルで、プロジェクト支払い管理者のロールと請求先アカウントユーザーのロールを請求先アカウントに割り当てます。プロジェクト作成中に請求先アカウントの関連付けを自動化するには、プロジェクト支払い管理者のロールと請求先アカウントユーザーのロールをサービスアカウントに割り当てます。請求先アカウント作成者のロールを制限するか、このロールのすべての割り当てを削除することをおすすめします。
プロジェクトの課金ステータスの意図しない変更による停止を防ぐために、プロジェクトと請求先アカウント間のリンクはロックできます。詳細については、プロジェクトと請求先アカウント間のリンクを保護するをご覧ください。

請求レポートを構成する

追跡する必要がある主要な指標のデータが得られるように請求レポートを設定します。次の指標を追跡することをおすすめします。

費用の傾向
最大の課金者（プロジェクト別およびプロダクト別）
費用が異常な領域
次のような組織全体にわたる主要な分析情報:
- 異常検出
- 傾向（時系列）
- 設定されたパターンで発生する傾向（たとえば、月次）
- 内部ワークロードと外部ワークロードの間の費用比較とベンチマーク分析
- ビジネスケースの追跡と価値実現（例: クラウド費用とオンプレミスリソースの費用の比較）
- Google Cloud の請求が想定どおり正確であることの検証

傾向を分析して費用を予測する

BigQuery Billing Export を使用して費用レポートのカスタマイズと分析を行い、Looker Studio を使用して費用データを可視化します。予測ツールを使用して、実際の費用の傾向と支出の予測額を評価します。

リソースの使用量と費用を最適化する

このセクションでは、Google Cloud サービス全体のリソースの使用と費用を最適化するためのベストプラクティスについて説明します。

過剰な支出を防ぐため、すべてのプロジェクトでデフォルトの予算とアラートに上限のしきい値を構成することを検討してください。予算内を守るため、次の操作を行うことをおすすめします。

無条件に使用量の上限を設定する必要があるプロジェクト（トレーニングプロジェクトやサンドボックスプロジェクトなど）の場合、予算とアラートを構成します。
予算は、追跡する必要がある財務予算に基づいて定義します。たとえば、部門にクラウドの予算全体がある場合、Google Cloud 予算のスコープには、追跡する必要のある特定のプロジェクトが含まれるように設定します。
予算を確実に管理するため、ワークロードを所有するチームに予算とアラートの構成を委任します。

費用を最適化するためには、次のこともおすすめします。

ビジネスへの影響が最小限またはまったくない場合の API の使用の上限を設定します。上限の設定は、サンドボックスプロジェクトやトレーニングプロジェクト、予算が固定されているプロジェクト（BigQuery でのアドホック分析など）で役立ちます。上限の設定によって、関連するプロジェクトからすべてのリソースとデータが削除されるわけではありません。
割り当てを使用して、リソースのデプロイを抑制するハードリミットを設定します。割り当てにより、コストを管理し、リソースの悪意のある使用や不正使用が防止されます。割り当ては、リソースタイプとロケーションごとにプロジェクトレベルで適用します。
おすすめハブで費用最適化の最適化案を確認して実装します。
確約利用割引（CUD）を購入することで、必要なリソース量を予測可能なワークロードの費用を削減できます。

ツールと手法

クラウドのオンデマンドプロビジョニングと従量課金制の特性は、IT 費用の最適化に役立ちます。このセクションでは、Google Cloud が提供するツールと、クラウド内のリソースの費用を追跡および管理するために使用できる手法について説明します。これらのツールと手法を使用する前に、Cloud Billing の基本コンセプトを確認してください。

請求レポート

Google Cloud では、Google Cloud コンソール内に請求レポートが用意されており、現在の費用と予測費用を確認できます。請求レポートを使用すると、費用データを 1 ページに表示し、傾向を見つけて分析できます。また、期間終了の費用を予測し、必要に応じて是正措置を取ることができます。

請求レポートには次のデータが含まれます。

特定の期間の費用と費用の傾向。次のように整理されています。
- 請求先アカウント別
- プロジェクト別
- プロダクト別（Compute Engine など）
- SKU 別（静的 IP アドレスなど）
割引クレジットまたはプロモーションクレジットを除外した場合の潜在的費用
予測される費用

BigQuery へのデータのエクスポート

請求レポートを BigQuery にエクスポートし、データ（ラベルまたはタグで分類されたデータなど）の詳細なビューや履歴的なビューを使用して費用を分析できます。BigQuery ML を使用すると、より高度な分析を行うことができます。Cloud 請求先アカウントを作成するとき、BigQuery へ請求レポートをエクスポートできるようにすることをおすすめします。BigQuery データセットには、Cloud Billing エクスポートの設定日からの課金データが含まれます。エクスポートを有効にする前の期間のデータは、データセットに含まれません。

費用データを可視化するには、BigQuery と統合するカスタムダッシュボードを作成します（テンプレートの例: Looker、Looker Studio）。

タグとラベルは、エクスポートされた課金データをフィルタリングするための条件として使用できます。課金データのエクスポートに含まれるラベルの数には上限があります。1 時間で最大 1,000 個のラベルマップが保持されます。請求書の PDF や CSV にラベルは表示されません。ビジネスユニット、内部チャージバックユニット、他の関連するメタデータを示すタグまたはラベルを使用して、リソースにアノテーションを付けることを検討してください。

課金のアクセス制御

特定のリソースに Identity and Access Management（IAM）ポリシーを定義することで、それらのリソースの Cloud Billing へのアクセスを制御できます。Cloud Billing へのアクセスを許可または制限するには、IAM ポリシーを組織レベル、請求先アカウントレベル、またはプロジェクトレベルで設定します。

請求とリソース管理のアクセス制御は、職務分散の原則に従います。各ユーザーは、自分のビジネスロールに必要な権限のみを持ちます。組織管理者ロールと請求先管理者ロールでは権限が異なります。

請求関連の権限を請求先アカウントレベルと組織レベルで設定できます。よく使用されるロールは、請求先アカウント管理者、請求先アカウントユーザー、請求先アカウント閲覧者です。

請求書発行を使用するか、予備のお支払い方法を構成することをおすすめします。請求とお支払いに関する連絡先と通知の設定を維持します。

予算、アラート、割り当て

予算は、予定支出額に対する実際の Google Cloud の費用を追跡するのに役立ちます。予算を作成する際に、実際の支出額または予測される支出額が定義されたしきい値を超えたときにメール通知をトリガーするようにアラートルールを構成できます。また、予算を使用して費用管理レスポンスを自動化することもできます。

予算によってアラートがトリガーされ、リソースの使用量と費用の傾向が通知されます。また、費用を最適化するためのアクションを行うように促すこともできます。ただし、実際の費用が予算またはしきい値に達した場合でも、予算によってサービスの使用や課金が妨げられることはありません。費用を自動的に制御するには、予算通知を使用して、プロジェクトの Cloud Billing をプログラム的に無効にします。API の使用量を制限して、定義した使用量のしきい値に達すると、それ以上費用が発生しないようにすることもできます。

請求先アカウントとプロジェクトのアラートを構成できます。アカウントには少なくとも 1 つの予算を構成します。

事前に定義されたレベルを超えるリソースのプロビジョニングを防ぐため、または特定のオペレーションの量を制限するために、リソースや API レベルで割り当てを設定できます。割り当ての使用例を次に示します。

1 秒あたりの API 呼び出し数を制御する。
作成する VM の数を制限する。
BigQuery で 1 日にクエリされるデータ量を制限する。

プロジェクトオーナーは、Service Usage API を使用して、特定の割り当て上限に対してユーザーによるオーバーライドを適用することで、割り当て上限に対して課金される割り当て量を減らすことができます。詳細については、コンシューマー割り当てオーバーライドの作成をご覧ください。

ワークロードの効率性の向上

Google Cloud のワークロードを費用対効果の高いものにするには、次の方法をおすすめします。

プロダクトの効率を向上させることで、リソースの使用を最適化する。
リソースの請求レートを減らす。
リソースの使用量と費用を管理して制限する。

費用削減の手法と Google Cloud 機能を選択する場合は、次のグラフに示すように、必要な作業と想定される費用を考慮してください。

費用の最適化戦略: 費用削減の図

上のグラフに示されている手法の概要は次のとおりです。

次の手法では、少ない労力で高い節約を実現できます。
- 確約利用割引
- 自動スケーリング
- BigQuery スロット
次の手法では、中程度から高程度の労力で大幅な費用削減を実現できる可能性があります。
- Spot VM
- サーバーレスアプリケーションまたはコンテナ化アプリケーションとして再設計
- マネージドサービスを使用するためにプラットフォームを再構築
次の手法では、適度な労力で中程度の費用削減を実現できる可能性があります。
- カスタムマシンタイプ
- Cloud Storage ライフサイクル管理
- サイズ適正化
- アイドル状態のリソースの再利用

次のセクションで説明する手法は、ワークロードの効率性の向上に役立ちます。

リファクタリングまたは再設計

Google Cloud プロダクトを使用するようにワークロードをリファクタリングまたは再設計すると、大幅なコスト削減を実現できます。たとえば、ゼロへのスケーリングをサポートするサーバーレスサービス（Cloud Storage、Cloud Run、BigQuery、Cloud Functions など）に移行すると、効率性を高めることができます。これらのプロダクトの費用を評価して比較する場合は、料金計算ツールを使用できます。

サイズ適正化

この手法は、インフラストラクチャの規模が意図した用途と一致するかどうか確認する際に役立ちます。この方法は、主に、基盤となるインフラストラクチャの料金を支払う Infrastructure as a Service（IaaS）ソリューションに適しています。たとえば、50 個の VM をデプロイしたが、VM は完全には使用されておらず、ワークロードは少ない（または小さい）VM で効率的に実行できるとします。この場合、一部の VM を削除またはサイズ変更できます。Google Cloud にはサイズの適正化に関する推奨事項が用意されています。小規模な VM をプロビジョニングすることによって、パフォーマンスに影響を及ぼすことなく、費用削減の機会を見つけ出すことができます。サイズ適正化は、本番環境にリソースをデプロイした後よりも設計フェーズで行うほうが簡単です。

自動スケーリング

使用するプロダクトが動的自動スケーリングをサポートしている場合は、自動スケーリングを利用して費用とパフォーマンスの面でメリットが得られるようにワークロードを設計することを検討してください。たとえば、コンピューティング負荷の高いワークロードの場合、Compute Engine でマネージドインスタンスグループを使用するか、アプリケーションをコンテナ化して、Google Kubernetes Engine クラスタにデプロイできます。

Active Assist の推奨事項

Active Assist は、データ、インテリジェンス、ML を使用してクラウドの複雑さを少なくし、管理上の負担を軽減します。Active Assist を使用すると、クラウドトポロジのセキュリティ、パフォーマンス、費用を簡単に最適化できます。費用と使用量を最適化するためのインテリジェントな推奨事項が提供されます。こうした推奨事項は、すぐに費用を削減して大幅に効率化するために使用できます。

Active Assist によって提供される推奨事項の例を次に示します。

Compute Engine リソースの適正化: VM インスタンスのサイズを変更して、使用量に基づいた費用とパフォーマンスに合わせて最適化します。アイドル状態の VM や永続ディスクを特定して削除またはバックアップすることで、インフラストラクチャの費用を最適化します。
確約利用割引（CUD）: Google Cloud は、過去の使用状況を分析し、ワークロードに最適なコミットメント量を見つけて、費用削減のためのわかりやすく実行可能な推奨事項を提案します。詳細については、確約利用割引 Recommender をご覧ください。
放置されたプロジェクト: 組織内で放置されたプロジェクトを見つけて、削除または回収します。詳細については、放置されたプロジェクト Recommender をご覧ください。

完全なリストについては、Recommender をご覧ください。

次のステップ

Cloud Billing のコンセプトについて学習する
予算と予算アラートを設定する
コンピューティングサービス、ストレージ、データベース、ネットワーキング、オペレーションの費用を最適化する
Google Cloud アーキテクチャフレームワークの他のカテゴリを確認する

費用の最適化: コンピューティング、コンテナ、サーバーレス

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud の仮想マシン（VM）、コンテナ、サーバーレスリソースのコストを最適化するための推奨事項について説明します。

このセクションのガイダンスは、クラウド内のワークロードのコンピューティングリソースについてプロビジョニングと管理を担当するアーキテクト、デベロッパー、管理者を対象としています。

コンピューティングリソースは、クラウドインフラストラクチャの最も重要な部分です。ワークロードを Google Cloud に移行する場合、一般的に第 1 候補となるのが Compute Engine です。これにより、クラウド内で VM を効率的にプロビジョニングして管理できるようになります。Compute Engine にはさまざまなマシンタイプがあり、すべての Google Cloud リージョンでグローバルに利用できます。Compute Engine の事前定義されたカスタムマシンタイプを使用すると、オンプレミスインフラストラクチャと同様のコンピューティング容量を提供する VM をプロビジョニングして、移行プロセスを高速化できます。Compute Engine には、ご利用いただいたインフラストラクチャに対してのみ料金が発生します。また、継続利用割引によって、コンピューティングリソースの使用量が増えたときに費用を大幅に節約できます。

Google Cloud では、Compute Engine に加えてコンテナとサーバーレスコンピューティングサービスを提供しています。サーバーレスアプローチにより、常時実行されるわけではない新しいサービス（API、データ処理、イベント処理など）に対して費用対効果を向上させることができます。

このドキュメントでは、一般的な推奨事項とともに、次のプロダクトを使用する際にコンピューティングリソースの費用を最適化するためのガイダンスについても説明します。

Compute Engine
Google Kubernetes Engine（GKE）
Cloud Run
Cloud Functions
App Engine

一般的な推奨事項

以下の推奨事項は、このセクションで説明する Google Cloud のすべてのコンピューティング、コンテナ、サーバーレスサービスに適用できます。

使用状況と費用を追跡する

リソースの使用状況と費用をモニタリングするには、以下のツールと手法を使用します。

おすすめハブで費用の最適化に関する推奨事項を確認し、対応する。
予算アラートを構成して、リソースの使用量と費用の増加の可能性を知らせるメール通知を受け取る。
Pub/Sub や Cloud Functions サービスを使用して、プログラムでアラートの管理と対応を行う。

リソースのプロビジョニングを制御する

クラウドにプロビジョニングされるリソースの量とリソースが作成されるロケーションを制御するには、次の推奨事項を使用します。

リソースの消費量と費用が予測を超えないようにするために、リソースの割り当てを使用します。
ワークロードのレイテンシ要件を満たす最低費用のリージョンでリソースをプロビジョニングします。リソースをプロビジョニングする場所を制御するには、組織のポリシーの制約 gcp.resourceLocations を使用します。

確約利用割引を取得する

確約利用割引（CUD）は、必要なリソース量が予測可能なワークロードに最適です。ワークロードを Google Cloud に移行後、必要なリソースのベースラインを見つけて、確約利用の大幅な割引を取得します。たとえば、1 年間または 3 年間の確約利用を購入し、Compute Engine VM の料金の大幅な割引を取得します。

ラベルを使用して費用追跡を自動化する

一貫性のあるラベルの定義と割り当てを行います。ラベルを使用して費用の追跡を自動化する方法の例を次に示します。

デベロッパーが営業時間中にのみ使用する VM の場合は、ラベル env: development を割り当てます。Cloud Scheduler でサーバーレスの Cloud Functions の関数を設定すると、営業時間後にこうした VM をシャットダウンして、必要に応じて再起動できます。
複数の Cloud Run サービスと Cloud Functions インスタンスを持つアプリケーションの場合は、すべての Cloud Run および Cloud Functions リソースに一貫したラベルを割り当てます。支出の多い領域を特定し、費用を削減するための措置を講じます。

請求レポートをカスタマイズする

Cloud Billing レポートを構成するには、必要なフィルタを設定し、必要に応じてデータをグループ化します（プロジェクト別、サービス別、ラベル別など）。

費用削減の文化を推進する

クラウドインフラストラクチャに関して開発者や運用担当者をトレーニングします。従来のクラスやオンラインクラス、ディスカッショングループ、ピアレビュー、ペアプログラミング、コスト削減ゲームを使用して、学習プログラムを作成し、プロモーションします。Google の DORA の調査で示されているように、組織文化は、パフォーマンスの改善、後戻り作業と燃え尽き症候群の削減、費用の最適化の重要な推進要因です。従業員がリソースの費用を把握できるようにすることで、従業員は優先事項とアクティビティをビジネス目標や制約に合わせることができます。

Compute Engine

このセクションでは、Compute Engine リソースの費用の最適化に役立つガイダンスを示します。このガイダンスに加えて、前述の一般的な推奨事項を適用することをおすすめします。

請求モデルを理解する

Compute Engine の請求オプションについては、料金をご覧ください。

リソース使用量を分析する

Compute Engine でのリソース使用量を把握するには、使用状況データを BigQuery にエクスポートします。BigQuery データストアにクエリを実行して、プロジェクトの仮想 CPU（vCPU）の使用傾向を分析し、再利用できる vCPU の数を決定します。プロジェクトあたりのコア数のしきい値を定義している場合は、使用傾向を分析して異常を特定し、是正措置を取ります。

アイドル状態のリソースを再利用する

降格された概念実証プロジェクトの VM など、未使用の VM とディスクを特定して再利用するには、次の推奨事項を使用してください。

アイドル状態の VM Recommender を使用して、使用状況の指標に基づき、非アクティブな VM と永続ディスクを識別できます。
リソースを削除する前に、削除によって生じる可能性のある影響を評価し、必要な場合にはリソースの再作成を計画してください。
VM を削除する前に、スナップショットの取得を検討してください。VM を削除する際、[ディスクを維持] オプションを選択しない限り、アタッチされたディスクが削除されます。
可能であれば、VM を削除するのではなく停止することを検討してください。VM を停止するとインスタンスは終了しますが、ディスクと IP アドレスは切断または削除するまで保持されます。

需要に合わせて容量を調整する

VM の起動と停止が自動的に行われるようにスケジュール設定します。たとえば、VM を 1 日 8 時間、週 5 日（週 40 時間）使用する場合、VM を使用していない間（週 128 時間）VM を停止することで、コストを 75% 削減できます。

マネージドインスタンスグループを使用して、需要に基づいてコンピューティング容量を自動スケーリングします。ビジネスにとって重要なパラメータ（CPU 使用率やロードバランシング容量など）に基づいて容量を自動スケーリングできます。

適切なマシンタイプを選択する

VM マシンタイプ Recommender を使用して、ワークロードのコンピューティング要件に合わせて VM のサイズを調整します。

リソースの要件が予測可能なワークロードの場合は、マシンタイプをニーズに合わせて、カスタム VM を使用すると費用を節約できます。

フォールトトレラントなバッチ処理のワークロードの場合は、Spot VM の使用を検討してください。ハイパフォーマンスコンピューティング（HPC）、ビッグデータ、メディアのコード変換、継続的インテグレーションと継続的デリバリー（CI / CD）パイプライン、ステートレスウェブアプリケーションなどが、Spot VM にデプロイ可能なワークロードの例です。プリエンプティブル VM（古いバージョンの Spot VM）を使用して衛星画像を処理することで、Descartes Labs が分析コストを削減した例については、Descartes Labs の事例紹介をご覧ください。

ライセンスオプションを評価する

サードパーティのワークロードを Google Cloud に移行する場合は、お客様所有ライセンスの使用（BYOL）で費用を削減できる可能性があります。たとえば、Microsoft Windows Server VM をデプロイする場合、サードパーティライセンスの追加費用が発生するプレミアムイメージを使用する代わりに、カスタム Windows BYOL イメージを作成して使用できます。この場合、料金は Google Cloud で使用する VM インフラストラクチャにしか発生しません。この戦略により、サードパーティライセンスに対するこれまでの投資の価値を継続的に現金化できます。

BYOL の手法を使用する場合は、次のことをおすすめします。

カスタムマシンタイプを使用して、必要な数のコンピューティング CPU コアをメモリとは独立してプロビジョニングし、サードパーティのライセンスの費用を必要な CPU コアの数に制限します。
同時マルチスレッディング（SMT）を無効にして、コアあたりの vCPU 数を 2 から 1 に減らし、ライセンス費用を 50% 削減します。

サードパーティワークロードが、セキュリティまたはコンプライアンスの要件を満たすために専用のハードウェアを必要とする場合は、単一テナントノードでお客様所有ライセンス（BYOL）を使用できます。

Google Kubernetes Engine

このセクションでは、GKE リソースの費用を最適化するためのガイダンスについて説明します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

GKE Autopilot を使用すると、GKE でクラスタのインフラストラクチャの効率が最大化されます。ノードの健全性のモニタリング、ビンパッキングの処理、ワークロードに必要な容量の計算は必要ありません。
ワークロードの要件に応じて、HorizontalPodAutoscaler（HPA）、VerticalPodAutoscaler（VPA）、クラスタオートスケーラー（CA）、またはノードの自動プロビジョニングを使用して、GKE 自動スケーリングをファインチューニングできます。
起動レイテンシに影響されないバッチワークロードの場合は、optimization-utilization 自動スケーリングプロファイルを使用してクラスタの使用率を向上させます。
ノードの自動プロビジョニングを使用して GKE クラスタオートスケーラーを拡張し、オーバープロビジョニングすることなく、保留中の Pod の仕様に基づいて効率的にノードプールの作成や削除を行います。
別々のノードプールを使用します。静的読み込みには静的ノードプールを、動的読み込みにはクラスタ自動スケーリンググループがある動的ノードプールを使用します。
Pod がフォールトトレラントで、25 秒未満で正常に終了できる場合は、Kubernetes ノードプールに Spot VM を使用します。この戦略を GKE クラスタオートスケーラーと組み合わせると、低コストの VM（この場合は Spot VM を含むノードプール）を搭載したノードプールを最初にスケーリングできるようになります。
費用対効果の高いマシンタイプ（例: E2、N2D、T2D）を選択すると、価格性能比が 20～40% 向上します。
GKE 使用状況測定を使用して、名前空間とラベルでクラスタの使用状況プロファイルを分析します。最も支出の大きいチームやアプリケーション、使用量や費用の急増を引き起こした環境やコンポーネント、リソースを浪費しているチームを特定します。
マルチテナントクラスタでリソースの割り当てを使用して、各テナントで使用されるクラスタリソースがそれぞれの割り当て量を超えないようにします。
営業時間後に開発環境とテスト環境の自動ダウンスケーリングをスケジュール設定します。
GKE でコスト最適化 Kubernetes アプリケーションを実行するためのベストプラクティスに沿って実施します。

Cloud Run

このセクションでは、Cloud Run リソースの費用を最適化するためのガイダンスを示します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

同時実行の設定（デフォルトは 80）を調整して費用を削減します。Cloud Run では、CPU とメモリの使用量に基づいて、インスタンスに送信されるリクエストの数が決定されます。リクエストの同時実行を増やすと、必要となるインスタンス数を削減できます。
デプロイ可能なインスタンス数の上限を設定します。
課金対象インスタンス時間指標を使用して、必要なインスタンス数を推定します。たとえば、指標に 100s/s と示されている場合、約 100 個のインスタンスがスケジュールされています。パフォーマンスを維持するために 30% のバッファを追加します。つまり 100 個/秒のトラフィックに対して 130 個のインスタンスにします。
コールドスタートの影響を軽減するには、最小のインスタンス数を構成します。こうしたインスタンスがアイドル状態の場合、10 分の 1 の料金が請求されます。
CPU 使用率を追跡し、それに応じて CPU の上限を調整します。
トラフィック管理を使用して、コスト最適化された構成を決定します。
静的アセットの提供には、Cloud CDN または Firebase Hosting の使用を検討してください。
リクエストをグローバルに処理する Cloud Run アプリの場合、大陸間のデータ転送が高コストになる可能性があるため、複数のリージョンにアプリをデプロイすることを検討してください。この設計は、ロードバランサと CDN を使用する場合におすすめします。
起動時間も課金対象になるため、インスタンスの起動時間を短縮します。
確約利用割引を購入すると、1 年間の確約利用の場合、オンデマンド料金が最大で 17% の割引となります。

Cloud Functions

このセクションでは、Cloud Functions リソースの費用を最適化するためのガイダンスを示します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

関数の実行時間を確認します。テストやベンチマークを行い、必要な性能を満たす最小の関数を設計します。
Cloud Functions のワークロードが常に実行されている場合は、GKE または Compute Engine を使用してワークロードを処理することを検討してください。常時実行されるワークロードの場合、コンテナまたは VM が低コストなオプションになる場合があります。
共存できる関数インスタンスの数の上限を設定します。
Cloud Functions プログラミング言語のランタイムのパフォーマンスを関数のワークロードに対してベンチマークします。コンパイル済み言語のプログラムでは、コールドスタートの時間が長くなりますが、実行速度は速くなります。インタプリタ言語のプログラムでは実行速度は遅くなりますが、コールドスタートのオーバーヘッドが少なくなります。頻繁に実行される短く簡単な関数は、インタプリタ言語では費用が抑えられる可能性があります。
メモリ内のファイルシステムであるローカルディスクに書き込まれた一時ファイルを削除します。一時ファイルは関数に割り当てられたメモリを消費し、次に呼び出されるまでそのまま残る場合もあります。こうしたファイルを削除しなければ、メモリ不足エラーが発生してコールドスタートがトリガーされ、実行時間が長くなって費用が増加する可能性があります。

App Engine

このセクションでは、App Engine リソースの費用の最適化に役立つガイダンスを示します。

以下の推奨事項に加えて、前述の一般的な推奨事項をご覧ください。

トラフィックとリクエストのレイテンシに基づいてインスタンス数の最大値を設定します。App Engine では通常、アプリケーションが受信するトラフィックに基づいて容量がスケーリングされます。App Engine で作成できるインスタンスの数を制限することで費用を制御できます。
アプリケーションで使用できるメモリまたは CPU を制限するには、インスタンスクラスを設定します。CPU 使用率が高いアプリケーションの場合は、より多くの CPU を割り当てます。いくつかの構成をテストして、最適なサイズを決定します。
複数のプログラミング言語で App Engine ワークロードのベンチマークを行います。たとえば、ある言語で実装されたワークロードは、別の言語でプログラムされた同じワークロードよりも、所定の時間でタスクを完了するために必要なインスタンス数とコストが低くなります。
コールドスタートが少なくなるように最適化します。可能であれば、グローバルスコープで発生する CPU を集中的に使用するタスクや実行時間の長いタスクを減らします。タスクを、リクエストのコンテキストに「遅延読み込み」できる小さなオペレーションに分割してみます。
トラフィックが急増することが予想される場合は、あらかじめ起動されておくアイドル状態のインスタンスの最小数を構成します。トラフィックが予想されない場合は、アイドル状態のインスタンスの最小数をゼロに構成できます。
パフォーマンスと費用のバランスをとるには、異なる構成の 2 つのバージョン間でトラフィックを分割して、A/B テストを実行します。各バージョンのパフォーマンスと費用をモニタリングし、必要に応じてチューニングして、トラフィックを送信する構成を決定します。
リクエストの同時実行を構成し、最大同時リクエスト数をデフォルトよりも高く設定します。各インスタンスが同時に処理できるリクエストが多いほど、既存のインスタンスを使用してトラフィックをより効率的に処理できます。

次のステップ

GKE リソースの費用を最適化する方法を学習する。
Cloud Run および Cloud Functions リソースの費用を最適化する方法を学習する。
ストレージ、データベース、ネットワーキング、運用の費用を最適化する:
Google Cloud アーキテクチャフレームワークの他のカテゴリを確認する

費用の最適化: ストレージ

Google Cloud アーキテクチャフレームワークのドキュメントでは、Cloud Storage、Persistent Disk、Filestore リソースの使用量と費用を最適化するための推奨事項を紹介しています。

このセクションのガイダンスは、クラウド内のワークロードのストレージをプロビジョニングおよび管理するアーキテクトと管理者を対象としています。

Cloud Storage

ワークロードの Cloud Storage を計画する場合は、パフォーマンス、データ保持、アクセスパターンの要件を考慮してください。

ストレージクラス

次の表に示すように、ワークロードのデータ保持とアクセス頻度の要件に適したストレージクラスを選択します。

ストレージ要件	推奨事項
頻繁にアクセスされるデータ（高スループットの分析、データレイク、ウェブサイト、ストリーミング動画、モバイルアプリ）。	Standard Storage
アクセス頻度の低いデータ（少なくとも 30 日間保存できる）用の低コストのストレージ（バックアップやロングテールのマルチメディアコンテンツなど）。	Nearline Storage
少なくとも 90 日間保存できる頻繁にアクセスされないデータ（障害復旧用のデータレプリカなど）。	Coldline Storage
アクセス頻度の低いデータ（少なくとも 365 日間保存できる）用の最低コストのストレージ（例: 法的アーカイブと規制アーカイブ）。	Archive Storage

ロケーション

パフォーマンス、可用性、データ冗長性の要件に基づいて、バケットのロケーションを選択します。

リージョンは、リージョンがエンドユーザーの近くにある場合に推奨されます。特定のリージョンを選択し、そのリージョン内の冗長性を確保できます。リージョンは、特定の地理的エリアのユーザーが頻繁にアクセスするデータセット用に、高速で冗長で手頃な価格のストレージを提供します。
マルチリージョンは、分散しているユーザーに高可用性を提供します。ただし、ストレージ費用はリージョンの場合よりも高くなります。コンテンツサービスを提供するユースケースとローエンド分析ワークロードには、マルチリージョンバケットをおすすめします。
デュアルリージョンは、高可用性とデータ冗長性を提供します。ハイパフォーマンス分析ワークロードや、コンピューティングとストレージが複数の場所に配置されている真のアクティブ-アクティブバケットを必要とするユースケースには、デュアルリージョンバケットをおすすめします。デュアルリージョンでは、データの保存場所を選択できるため、コンプライアンス要件を満たすことができます。たとえば、デュアルリージョンバケットを使用すると、クラウド内のデータのコピー間の物理的な距離に関する業界固有の要件を満たすことができます。

ライフサイクルポリシー

ライフサイクルポリシーを定義することで、Cloud Storage 内のオブジェクトのストレージ費用を最適化します。これらのポリシーでは、特定のオブジェクトのストレージクラスをダウングレードするか、設定した条件に基づいてオブジェクトを削除することで、費用を節約できます。

オブジェクトへのアクセス頻度と保存期間に基づいてライフサイクルポリシーを構成します。ライフサイクルポリシーの例を次に示します。

ダウングレードポリシー: データセットへのアクセス頻度は高いが、3 か月間程度が想定されています。このデータセットのストレージ費用を最適化するには、Standard Storage を使用し、90 日以上経過したオブジェクトを Coldline Storage にダウングレードするライフサイクルポリシーを構成します。
削除ポリシー: データセットは、特定の法的要件を満たすために 365 日間保持されなければならず、その期間が経過した後で削除できます。365 日以上経過したオブジェクトを削除するポリシーを構成します。

（法令または規制遵守のために）特定の日時まで保持しなければならないデータがその日時より前に削除されないようにするには、保持ポリシーのロックを構成します。

アカウンタビリティ

運用料金、ネットワーク料金、データ取得費用の説明責任を推進するには、必要に応じてリクエスト元による支払いの構成を使用します。この構成では、費用はオーナーではなく、データを使用する部門またはチームに課金されます。

すべてのバケットとオブジェクトに対して一貫したコストトラッキングラベルを定義して割り当てます。可能であればラベル付けを自動化します。

冗長性

次の方法を使用して、データの重複なしに、必要なストレージの冗長性を維持できます。

唯一の正確な情報源でデータの復元力を維持するには、異なるバケットにデータの冗長コピーを使用する代わりに、デュアルリージョンまたはマルチリージョンバケットを使用します。デュアルリージョンバケットとマルチリージョンバケットは、リージョン間の冗長性を提供します。データは 2 つ以上のロケーション間で非同期に複製され、リージョンの停止から保護されます。
オブジェクトのバージョニングを有効にする場合は、オブジェクトの新しいバージョンが非現行になる際に最も古いバージョンが削除されるようにライフサイクルポリシーを定義することを検討してください。オブジェクトの非現行バージョンは、オブジェクトのライブバージョンと同じレートで課金されます。
不要になったオブジェクトバージョニングポリシーを無効にします。
バックアップとスナップショットの保持ポリシーを定期的に確認し、不要なバックアップとデータ保持を回避するように調整します。

Persistent Disk

Compute Engine にデプロイするすべての VM インスタンスにブートディスクと（必要に応じて）1 つ以上のデータディスクがあります。各ディスクには、プロビジョニングされたサイズ、リージョン、ディスクタイプに応じて料金が発生します。ディスクのスナップショットは、そのサイズに基づいて課金されます。

永続ディスクの費用を最適化する際は、次の設計上の推奨事項と運用に関する推奨事項を参考にしてください。

ディスク容量を過剰に割り当てないでください。プロビジョニング後にディスク容量を減らすことはできません。小さなディスクから始めて、必要に応じてサイズを増やします。永続ディスクは、ディスクに保存されているデータではなく、プロビジョニングされた容量に対して課金されます。
ワークロードのパフォーマンス特性に見合ったディスクタイプを選択します。SSD は IOPS とスループットが高くなりますが、標準永続ディスクよりも費用がかかります。
リージョン永続ディスクは、ゾーンの停止からデータを保護する必要がある場合にのみ使用します。リージョン永続ディスクはリージョン内の別のゾーンに複製されるため、同等のゾーンディスクのコストが 2 倍になります。
Cloud Monitoring を使用して永続ディスクの使用状況を追跡し、使用率の低いディスクのアラートを設定します。
不要になったディスクを削除します。
将来必要とする可能性のあるデータを含むディスクの場合は、データを低コストの Cloud Storage にアーカイブしてから、ディスクを削除することを検討してください。
おすすめハブで推奨事項を探し、適切なものを選択します。

ハイパフォーマンスストレージにハイパーディスク、一時ストレージにエフェメラルディスク（ローカル SSD）を使用することも検討してください。

ディスクスナップショットはデフォルトで増分になり、自動的に圧縮されます。ディスクスナップショットのコストを最適化するための次の推奨事項を検討してください。

可能であれば、データを別々の永続ディスクに整理します。その後、ディスクを選択的にバックアップすることを選択し、ディスクスナップショットのコストを削減できます。
スナップショットを作成するときに、可用性の要件と関連するネットワークコストに基づいてロケーションを選択します。
ブートディスクスナップショットを使用して複数の VM を作成する場合は、スナップショットからイメージを作成し、そのイメージを使用して VM を作成します。このアプローチにより、スナップショットのロケーションと復元するロケーションの間で発生するデータ移動に対してネットワーク料金が発生しないようにできます。
ディスクスナップショットの長期保存コストを最小限に抑える保持ポリシーの設定を検討してください。
不要になったディスクスナップショットを削除します。チェーン内の各スナップショットは、前のスナップショットに保存されているデータに依存する場合があります。したがって、スナップショットを削除しても、そのスナップショット内のすべてのデータが削除されるとは限りません。スナップショットからデータを完全に削除するには、チェーン内のすべてのスナップショットを削除する必要があります。

Filestore

Filestore インスタンスのコストは、サービス階層、プロビジョニングされた容量、インスタンスがプロビジョニングされたリージョンによって異なります。Filestore インスタンスのコストを最適化するための設計と運用に関する推奨事項は次のとおりです。

ストレージのニーズに適したサービスティアとストレージタイプ（HDD または SSD）を選択します。
容量を過剰に割り当てないでください。小さなサイズから始めて、必要に応じて後でサイズを増やします。Filestore の課金は、保存されたデータではなく、プロビジョニングされた容量に基づいています。
可能であれば、データを個別の Filestore インスタンスで整理します。その後、インスタンスを選択的にバックアップすることを選択して、Filestore バックアップのコストを削減できます。
リージョンとゾーンを選択するときは、クライアントと同じゾーンにインスタンスを作成することを検討してください。Filestore インスタンスのゾーンからのデータ転送トラフィックは課金されます。
Filestore バックアップを保存するリージョンを決定する際は、ソースインスタンスとは異なるリージョンにバックアップを保存するためのデータ転送料金を検討してください。
Cloud Monitoring を使用して Filestore インスタンスの使用状況を追跡し、使用率の低いインスタンスに対するアラートを設定します。
使用率の低い Filestore インスタンスに割り当てられた容量をスケールダウンします。基本階層以外のインスタンスの容量を減らすことができます。

次のステップ

Cloud Storage におけるコスト最適化のベストプラクティスを確認する（ブログ）
コンピューティングサービス、データベース、ネットワーキング、運用の費用を最適化する。
Google Cloud アーキテクチャフレームワークの他のカテゴリを確認する

費用の最適化: データベースとスマートアナリティクス

Google Cloud アーキテクチャフレームワークのドキュメントでは、Google Cloud のデータベースと分析ワークロードのコストを最適化するための最適化案について説明します。

このセクションのガイダンスは、クラウド内のデータベースと分析ワークロードのプロビジョニングおよび管理を担当するアーキテクト、デベロッパー、管理者を対象としています。

このセクションでは、次のプロダクトに関するコスト最適化の最適化案について説明します。

Cloud SQL

Cloud SQL は、MySQL、PostgreSQL、SQL Server 用のフルマネージドリレーショナルデータベースです。

使用量のモニタリング

モニタリングダッシュボードで指標を確認して、デプロイメントがワークロードの要件を満たしていることを確かめます。

リソースを最適化する

Cloud SQL リソースの最適化に役立つ最適化案は次のとおりです。

目標復旧時間（RTO）および目標復旧時点（RPO）と整合性の取れた高可用性および障害復旧戦略を設計します。ワークロードに応じて、次のことをおすすめします。
- 短い RTO と RPO が必要なワークロードの場合は、高可用性構成とリージョンフェイルオーバー用のレプリカを使用します。
- 長い RTO と RPO に耐えられるワークロードの場合は、自動化されたオンデマンドのバックアップを使用します。これによって、障害発生後に復元するのに時間がかかることがあります。
必要最小限のストレージ容量でデータベースをプロビジョニングします。
データの増加に合わせてストレージ容量を自動的にスケーリングするには、ストレージの自動増量機能を有効にします。
ユースケースに適したストレージタイプ（ソリッドステートドライブ（SSD）またはハードディスクドライブ（HDD））を選択します。SSD は、ほとんどのユースケースで最も効率的でコスト効果の高い選択肢です。HDD は、レイテンシの影響を受けにくい大規模なデータセット（10 TB 超）や、アクセス頻度の低いデータセットに適しています。

レートを最適化する

リソースのニーズが予測可能なワークロードについては、確約利用割引の購入を検討します。1 年間の場合はオンデマンド料金の 25%、3 年間の場合は 52% の割引が適用されます。

Spanner

Spanner は、無制限のスケーリングと強整合性を備えたクラウドネイティブデータベースで、最大 99.999% の可用性を実現します。

使用量のモニタリング

以下は、Spanner リソースの使用状況を追跡するための最適化案です。

デプロイをモニタリングし、CPU の最適化案に基づいてノード数を構成します。
デプロイに対してアラートを設定して、ストレージリソースを最適化します。適切な構成を決定するには、ノードあたりの上限の推奨値をご覧ください。

リソースを最適化する

Spanner リソースの最適化に役立つ最適化案は次のとおりです。

処理ユニット（PU）とノードの間でリソースをプロビジョニングすることで、Spanner で小規模なワークロードをはるかに低コストで実行する。1 つの Spanner ノードは 1,000 PU に相当します。
クエリオプティマイザーを使用して、クエリ実行のパフォーマンスを向上させる。
効率的な実行プランを作成するためのベストプラクティスを使用して、SQL ステートメントを作成する。
オートスケーラーツールを使用して、Spanner のデプロイの使用量とパフォーマンスを管理する。このツールは、インスタンスをモニタリングし、ノードを自動的に追加または削除して、インスタンスを推奨される CPU とストレージの上限内にとどめるために役立ちます。
ポイントインタイムリカバリ（PITR）を使用して、不注意による削除や書き込みから保護します。バージョンの保持期間が長いデータベース（特に、データが頻繁に上書きされるデータベース）では、システムリソースの使用量と必要なノード数が増えます。
バックアップ戦略を確認し、次のいずれかのオプションを選択します。
- バックアップと復元
- エクスポートとインポート

レートを最適化する

Spanner ノードのロケーションを決定する際は、Google Cloud リージョン間の料金の違いを考慮してください。たとえば、us-central1 リージョンにデプロイされたノードは、southamerica-east1 リージョンのノードよりも 1 時間あたりのコストが大幅に削減されます。

Bigtable

Bigtable は、大規模で低レイテンシのワークロード向けのクラウドネイティブのワイドカラム型 NoSQL ストアです。

使用量のモニタリング

以下は、Bigtable リソースの使用状況を追跡するための最適化案です。

使用状況の指標を分析してリソース最適化の機会を特定します。
Key Visualizer 診断ツールを使用して、Bigtable クラスタのホットスポットとホットキーを特定します。

リソースを最適化する

Bigtable リソースの最適化に役立つ最適化案は次のとおりです。

レイテンシとストレージ容量のバランスの取れた CPU とディスクの使用量を確保するため、Bigtable クラスタのノード数とサイズを評価して調整します。
Bigtable クラスタをプログラムによってスケーリングし、ノード数を自動的に調整することで、可能な限り低い費用でパフォーマンスを維持します。
次の点を考慮して、ユースケースで最も費用対効果の高いストレージタイプ（HDD または SSD）を評価します。
- HDD ストレージは SSD よりも低コストですが、パフォーマンスも低くなります。
- SSD ストレージは HDD よりも費用がかかりますが、高速で予測可能なパフォーマンスが実現します。
HDD によるコスト削減は、非常に大きなデータを保存しない限り、Bigtable クラスタ内のノード費用に比べてごくわずかです。HDD ストレージは、大規模なデータセット（10 TB 超）で、レイテンシがあまり重要でない場合やアクセス頻度が低い場合に適切であることがあります。
ガベージコレクションを使用して、期限切れのデータと古くなったデータを削除します。
ホットスポットを回避するには、行キーの設計のベストプラクティスを適用します。
RPO に合わせて、費用対効果に優れたバックアッププランを設計します。
クラスタの使用量を減らし、ノード数を減らすには、Memorystore を使用して、キャッシュに保存可能なクエリの容量キャッシュを追加することを検討してください。

その他の情報

BigQuery

BigQuery は、ビジネスのアジリティを高めるように設計された、スケーラビリティと費用対効果に優れたサーバーレスのマルチクラウドデータウェアハウスです。

使用量のモニタリング

以下は、BigQuery リソースの使用状況を追跡するための最適化案です。

BigQuery の費用をプロジェクト別、ユーザー別に分けて可視化します。最も費用のかかるクエリを特定して最適化します。
INFORMATION_SCHEMA メタデータテーブルを使用して、プロジェクト、ジョブ、予約のスロット使用率を分析します。

リソースを最適化する

BigQuery リソースの最適化に役立つ最適化案は次のとおりです。

コンプライアンス戦略に基づいて、データのデータセットレベル、テーブルレベル、パーティションレベルの有効期限を設定します。
クエリあたりの課金されるバイト数を制限することで、クエリ費用を制限します。偶発的な人的ミスを防ぐには、ユーザーレベルとプロジェクトレベルでコスト管理を有効にします。
必要なデータのみをクエリします。クエリ全体のスキャンは避けます。データセマンティクスを探索して理解するには、無料のデータプレビューオプションを使用します。
処理費用を削減し、パフォーマンスを向上させるため、可能であればテーブルのパーティション分割とクラスタ化を行います。
クエリを早い段階で、できるだけ頻繁にフィルタリングします。
複数のソース（Bigtable、Cloud Storage、Google ドライブ、Cloud SQL など）からデータを処理する場合は、フェデレーションアクセスデータモデルを使用して、ソースから直接データのクエリを実行し、データの重複を回避します。
データを複製する代わりに、BigQuery のバックアップを使用します。データの障害復旧シナリオをご覧ください。

レートを最適化する

次の最適化案は、BigQuery リソースの課金レートの低減に役立ちます。

データの編集方法を評価し、低コストの長期ストレージ料金を活用します。
定額とオンデマンドの料金の違いを確認し、要件に適したオプションを選択します。
データワークフローでストリーミング挿入の代わりにバッチ読み込みを使用できるかどうかを評価します。BigQuery に読み込まれたデータがすぐに使用される場合は、ストリーミング挿入を使用します。
パフォーマンスを向上させ、データ取得のコストを削減するには、キャッシュに保存されたクエリ結果を使用します。

その他の情報

Dataflow

Dataflow は、統合ストリームおよびバッチデータ処理用の高速で費用対効果の高いサーバーレスサービスです。

使用量のモニタリング

以下は、Dataflow リソースの使用状況を追跡するための最適化案です。

小規模な負荷テストを実行してジョブの最適なパフォーマンスを検出し、スループット係数を推定することによって Dataflow ジョブの費用を予測します。
オブザーバビリティダッシュボードを使用して、スループットと CPU の使用状況を可視化します。
Dataflow モニタリングインターフェースを使用して、パフォーマンス、実行、健全性に関連するパイプラインの指標を確認します。

リソースを最適化する

Dataflow リソースの最適化に役立つ最適化案は次のとおりです。

ビッグデータを効率的に処理する場合は、Dataflow Prime を使用します。
自動スケーリングされるバッチパイプラインに Flexible Resource Scheduling（FlexRS）を使用することで、バッチ処理費用を削減できます。FlexRS は、高度なスケジューリング、Dataflow シャッフル、プリエンプティブル VM と通常の VM の組み合わせを使用して、バッチパイプラインのコストを削減します。
Persistent Disk やワーカーノードの代わりにメモリ内シャッフルサービスを使用して、パフォーマンスを向上させます。
レスポンスに優れた自動スケーリングのために、リソース使用量を減らすには、Streaming Engine を使用して、パイプラインの実行をワーカー VM から Dataflow サービスのバックエンドに移動します。
パイプラインとインターネットや他の Google Cloud ネットワーク間のアクセスが不要な場合は、パブリック IP アドレスを無効にします。インターネットアクセスを無効にすると、ネットワークコストを削減し、パイプラインのセキュリティを強化できます。
Dataflow による効率的なパイプライン化のベストプラクティスを適用します。

Dataproc

Dataproc は、バッチ処理、クエリ、ストリーミング、ML 用のマネージド Apache Spark / Apache Hadoop サービスです。

Dataproc リソースのコストを最適化するための最適化案を以下に示します。

ワークロードに適したマシンタイプを選択します。
自動スケーリングクラスタを使用して需要に応じて自動的にスケーリングし、必要なリソースに対してのみ支払います。
ジョブが完了したときにクラスタを削除できる場合は、マネージドクラスタワークフローテンプレートを使用するエフェメラルクラスタのプロビジョニングを検討してください。
非アクティブなクラスタに対して料金が発生しないようにするには、スケジュール設定された削除を使用します。これにより、指定したアイドル時間の後、指定した日時、または指定した期間が経過した後にクラスタを削除できます。
Dataproc での長時間実行クラスタの構築のベストプラクティスを適用します。
常時稼働ワークロードについては、確約利用割引を購入します。

次のステップ

コンピューティングサービス、ストレージ、ネットワーキング、運用の費用を最適化する。
Google Cloud アーキテクチャフレームワークの他のカテゴリを確認する

費用の最適化: ネットワーキング

Google Cloud アーキテクチャフレームワークのドキュメントでは、Google Cloud のネットワークリソースの費用を最適化するための推奨事項を紹介しています。

このセクションのガイダンスは、クラウド内のワークロードのネットワーキングをプロビジョニングおよび管理するアーキテクトと管理者を対象としています。

設計上の考慮事項

オンプレミスネットワークとクラウドネットワークの根本的な違いは、クラウドでは動的な使用量ベースのコストモデルが採用され、従来のデータセンターではネットワークの費用が固定されている点です。

クラウドネットワークを計画する場合は、以下のようにトラフィックの方向に基づいた料金モデルを理解することが重要です。

Google Cloud へのインバウンドのトラフィックに対しては、料金は発生しません。インバウンドのトラフィックを処理するリソース（Cloud Load Balancing など）には料金が発生します。
データ転送トラフィック（これには、Google Cloud の仮想マシン（VM）間のトラフィックと、Google Cloud からインターネットやオンプレミスホストへのトラフィックが含まれます）については、次の要因に基づいて料金が決まります。
- トラフィックで内部 IP アドレスと外部 IP アドレスのどちらを使用するか
- トラフィックがゾーンやリージョンの境界を通過するかどうか
- トラフィックが Google Cloud から出るかどうか
- Google Cloud から出る前にトラフィックが移動した距離

Google Cloud 内の 2 つの VM またはクラウドリソース間で通信が行われると、各方向のトラフィックは送信元でアウトバウンドのデータ転送、送信先ではインバウンドのデータ転送として識別され、それに応じて料金設定されます。

最適な費用でクラウドネットワークを設計するには、次の要素を考慮してください。

地理位置情報
ネットワークレイアウト
接続オプション
Network Service Tiers
ロギング

これらの要因については、以降のセクションで詳しく説明します。

地理位置情報

ネットワークの費用は、リソースがプロビジョニングされる Google Cloud リージョンによって異なります。リージョン間のネットワーク帯域幅を分析するには、VPC フローログと Network Intelligence Center を使用します。Google Cloud リージョン間で送受信されるトラフィックの場合、トラフィックがインターネットを経由しなくても、リージョンのロケーションによって料金が異なる場合があります。

Google Cloud リージョンのほかに、リソースをデプロイするゾーンも検討します。可用性の要件によっては、ゾーン内で内部 IP アドレスを使用して無料で通信するようにアプリケーションを設計できる場合があります。シングルゾーンアーキテクチャを検討する際は、ネットワーク費用の削減の可能性と可用性への影響を比較検討してください。

ネットワークレイアウト

ネットワークレイアウト、アプリケーションとユーザーの間でのトラフィックフロー、各アプリケーションまたはユーザーによって消費される帯域幅を分析します。ネットワークトポロジツールを使用すると、グローバル Google Cloud デプロイメントと、公共のインターネットとのやり取りを包括的に把握できます。これには、トポロジの組織全体のビューが含まれ、ネットワークパフォーマンスの指標が関連付けられています。非効率的なデプロイメントを特定し、リージョンでの、また大陸間のデータ転送費用を最適化するために必要な措置を講じることができます。

接続オプション

オンプレミス環境から Google Cloud に大量のデータ（TB または PB）を頻繁に push する必要がある場合は、Dedicated Interconnect または Partner Interconnect の使用を検討します。専用接続は、公共のインターネット経由や VPN の利用に比べると、より低コストです。

可能であれば、限定公開の Google アクセスを使用して、コストを削減してセキュリティを強化します。

Network Service Tiers

デフォルトでは、すべてのサービスで Google のプレミアムネットワークインフラストラクチャ（プレミアムティア）が使用されます。プレミアムティアで提供される高パフォーマンスと低レイテンシを必要としないリソースには、スタンダードティアの利用をおすすめします。

サービスティアを選択する際は、ティア間の違いとスタンダードティアの制限を考慮してください。アプリケーションのニーズに合わせてネットワークを微調整します。これにより、より大きいレイテンシを許容でき、SLA を必要としないサービスのネットワークコストを削減できます。

ロギング

VPC フローログ、ファイアウォールルールロギング、Cloud NAT ロギングを使用すると、ネットワークログを分析して費用最適化の機会を特定できます。

VPC フローログと Cloud Load Balancing では、サンプリングを有効にし、データベースに書き込まれるログの量を減らすことができます。サンプリングレートは 1.0（すべてのログエントリを保持）から 0.0（ログを保持しない）の間で設定できます。トラブルシューティングまたはカスタムユースケースの場合、特定の VPC ネットワークまたはサブネットのテレメトリーを常に収集するか、特定の VM インスタンスまたは仮想インターフェースをモニタリングするかを選択できます。

設計に関する推奨事項

ネットワークトラフィックを最適化するには、次のことをおすすめします。

アプリケーションをユーザーベースの近くに配置するようにソリューションを設計します。Cloud CDN を使用して、トラフィックの量とレイテンシを削減します。また、CDN の低価格を利用して、多くのユーザーが頻繁にアクセスするコンテンツを配信します。
エンドユーザーから離れているリージョン間、またはネットワークコストが高いリージョン間で、データをグローバルに同期することは避けてください。アプリケーションがリージョン内でのみ使用される場合は、クロスリージョンのデータ処理は避けてでください。
ゾーン内の VM 間の通信は、外部 IP アドレスではなく、内部 IP アドレスでルーティングされるようにします。
データ出力を圧縮することで、データ転送費用を削減しクライアントレイテンシを短縮します。
VPC フローログを使用して重要なプロジェクトのアウトバウンドとインバウンドのトラフィックフローをモニタリングすることで、支出パターンを分析し、費用を抑える機会を特定できます。
クラウドでネットワークを設計する場合は、分散ネットワークが提供する高可用性と、単一のゾーンまたはリージョン内でのトラフィックを一元化することで削減されるコストとのトレードオフを検討してください。

ネットワークサービスの料金を最適化するには、次のことをおすすめします。

サーバーのロケーションが制約ではない場合は、別のリージョンの費用を評価し、最もコスト効率の高いリージョンを選択します。ウェブサーバーのグループによって配信されるコンテンツなどの一般的なアウトバウンドトラフィックの場合、サーバーがプロビジョニングされるリージョンによって料金が異なります。
大量のデータをクラウドに頻繁に移動させるコストを削減するには、オンプレミスネットワークと Google Cloud ネットワークの間の直接接続を使用します。Dedicated Interconnect または Partner Interconnect の使用を検討してください。
各環境に適切なサービスティアを選択します。つまり、開発環境とテスト環境にはスタンダードティア、本番環境にはプレミアムティアを選択します。

次のステップ

ネットワークの料金体系情報を確認する
ネットワーク費用の最適化に関するベストプラクティスを確認する
コンピューティングサービス、ストレージ、データベース、オペレーションの費用を最適化する
Google Cloud アーキテクチャフレームワークの他のカテゴリを確認する

費用の最適化: Cloud Operations

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud のリソースのモニタリングと管理費用を最適化するための推奨事項について説明します。

このセクションのガイダンスは、クラウド内の組織のリソースの使用量と費用のモニタリングと制御を担当するクラウドユーザーを対象としています。

Google Cloud のオペレーションスイートは、Google Cloud のワークロードに関するパフォーマンスのモニタリング、トラブルシューティング、改善に使用できるマネージドサービスのコレクションです。このようなサービスには、Cloud Monitoring、Cloud Logging、Error Reporting、Cloud Trace、Cloud Profiler などがあります。Google Cloud のマネージドサービスの利点の一つは、サービスが従量制であるということです。料金は、使用した分とデータ量でのみ支払います。データ容量には毎月の無料割り当てがあり、Google Cloud 指標と監査ログには無制限にアクセスできます。

Cloud Logging

Logging オペレーションの費用を最適化するための推奨事項は次のとおりです。

請求レポートをフィルタリングして Logging の費用を表示する。
不要なログエントリを除外またはフィルタすることで、取り込まれるログと保存されるログの量を減らす。
Google Cloud コンソールで billing/bytes_ingested 指標と billing/monthly_bytes_ingested 指標をモニタリングして、除外フィルタが適切であることを確認する。
ログを低コストのストレージにオフロードおよびエクスポートする。
サードパーティアプリケーションからログをストリーミングする場合は、本番環境インスタンスでのみ Logging エージェントを使用するか、送信データを少なくするように構成して、ログのボリュームを減らす。

Cloud Monitoring

Monitoring オペレーションの費用を最適化するための推奨事項は次のとおりです。

ラベルの数を制限して、指標とラベルの使用を最適化する。カーディナリティの高いラベルは避ける。たとえば、IP アドレスをラベルとして使用すると、各 IP アドレスには 1 つの項目からなるラベル連続体が付くため、VM の数が多ければ、多数のラベルが生成されます。
特に必要のない環境では、これらの指標を必要としないアプリケーションの詳細な指標の量を減らすか、モニタリングエージェントを削除する。
アプリケーションから送信されるカスタム指標の数を減らして、取り込み量を最小限に抑える。

Cloud Trace

Trace オペレーションの費用を最適化するための推奨事項は次のとおりです。

Trace を OpenCensus トレース用のエクスポート先として使用する場合は、OpenCensus のサンプリング機能を使用して、取り込まれるトレースの数を減らす。
Trace の使用を制限し、割り当てを使用して費用を制御する。Google Cloud コンソールの API 固有の割り当てページでスパン割り当てを適用できます。

次のステップ

Google Cloud のオペレーションスイートの費用を最適化する
動画: Google Cloud のオペレーションスイートの費用を管理する
コンピューティングサービス、ストレージ、データベース、ネットワーキングの費用を最適化する
Google Cloud アーキテクチャフレームワークの他のカテゴリを確認する

Google Cloud アーキテクチャフレームワーク: パフォーマンスの最適化

Google Cloud アーキテクチャフレームワークのこのカテゴリでは、Google Cloud でワークロードのパフォーマンスを最適化するためのパフォーマンス最適化プロセスとベストプラクティスについて説明します。

このドキュメントに掲載されている情報は、Google Cloud でワークロードの計画、設計、デプロイ、管理を行うアーキテクト、デベロッパー、管理者を対象としています。

クラウド内のワークロードのパフォーマンスを最適化すると、組織の効率的な運用、顧客満足度の向上、収益の向上、費用の削減を実現できます。たとえば、アプリケーションのバックエンド処理時間が短くなると、レスポンス時間が短くなり、ユーザー維持率の向上と収益の増加につながります。

パフォーマンスとコスト間にトレードオフが存在する場合があります。ただし、パフォーマンスを最適化することで費用を削減できる場合もあります。たとえば、自動スケーリングでは、リソースが過負荷にならないようにすることで、負荷が増加したときに予測可能なパフォーマンスを提供できます。また、自動スケーリングにより、未使用のリソースを削除することで、負荷が低い期間の費用を削減することもできます。

このカテゴリのアーキテクチャフレームワークでは、次の方法を学習します。

パフォーマンス最適化プロセス

Google Cloud のアーキテクチャフレームワークのこのドキュメントでは、パフォーマンス最適化プロセスの概要について説明します。

パフォーマンスの最適化は継続的なプロセスであり、1 回限りのアクティビティではありません。次の図は、パフォーマンス最適化プロセスの各ステージを示しています。

パフォーマンス最適化プロセス

以降では、パフォーマンス最適化プロセスにおける各ステージの概要を説明します。

パフォーマンス要件の定義

クラウドにデプロイまたは移行するアプリケーションの設計と開発を開始する前に、パフォーマンス要件を明らかにします。アプリケーションスタックの各レイヤ（フロントエンドのロードバランシング、ウェブサーバーやアプリケーションサーバー、データベース、ストレージ）について、可能な限り詳細に要件を定義します。たとえば、ストレージレイヤについては、アプリケーションが必要とするスループットと 1 秒あたりの I/O オペレーション（IOPS）を決めます。

アプリケーションの設計とデプロイ

アプリケーションは、パフォーマンス要件を満たすことに役立つ柔軟でスケーラブルな設計パターンを使用して設計します。柔軟でスケーラブルなアプリケーションを設計する場合は、次のガイドラインに沿ってください。

最適なコンテンツの配置を目指してワークロードを設計する。
読み取りトラフィックと書き込みトラフィックを分離する。
静的なトラフィックと動的なトラフィックを分離する。
コンテンツのキャッシュ保存を実装する。内部レイヤにデータキャッシュを使用する。
マネージドサービスとサーバーレスアーキテクチャを使用する。

Google Cloud では、他のクラウドプラットフォームを使用した Google Cloud サービスのパフォーマンスをベンチマークするために使用できるオープンソースツールが用意されています。

パフォーマンスをモニタリングおよび分析する

アプリケーションをデプロイした後、ログとアラートを使用してパフォーマンスを継続的にモニタリングしてデータを分析し、パフォーマンスの問題を特定します。アプリケーションが成長し、進化するにつれて、パフォーマンス要件を再評価します。パフォーマンスを維持または改善するために、アプリケーションの一部を再設計する必要が生じる場合があります。

パフォーマンスを最適化する

アプリケーションのパフォーマンスと要件の変更に基づき、現在のパフォーマンス要件を満たすようにクラウドリソースを構成します。たとえば、リソースのサイズ変更や、自動スケーリングの設定を行います。リソースを構成する際には、最近リリースされた Google Cloud の機能とサービスを使用する機会を評価し、パフォーマンスをさらに最適化できるようにします。

パフォーマンスの最適化プロセスがここで終了するわけではありません。パフォーマンスのモニタリング、必要に応じて要件の再評価、クラウドリソースの調整のサイクルを継続して、パフォーマンスの維持と向上を図ります。

次のステップ

パフォーマンスをモニタリングおよび分析する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、ワークロードのパフォーマンスの記録、モニタリング、分析に使用できる Google Cloud のオペレーションスイートのサービスについて説明します。

パフォーマンス指標をモニタリングする

Cloud Monitoring を使用して、パフォーマンス指標の傾向分析、テストの影響分析、重要な指標に対するアラートの定義、事後分析を行います。

重要なデータとイベントをロギングする

Cloud Logging は、ログデータとイベントの保存、分析、モニタリング、アラート設定に使用できる、統合ロギングサービスです。Cloud Logging は、Google Cloud やその他のクラウドプロバイダのサービスからログを収集できます。

コードのパフォーマンスを分析する

パフォーマンスの悪いコードによって、アプリケーションのレイテンシと、実行コストが増加することがあります。Cloud Profiler は、アプリケーションが使用する CPU やメモリに負担のかかる関数のパフォーマンスを継続的に分析して、パフォーマンスの問題を特定し対処することに役立ちます。

レイテンシデータを収集する

複雑なアプリケーションスタックやマイクロサービスベースのアーキテクチャでは、サービス間通信のレイテンシの評価や、パフォーマンスのボトルネックの特定が困難な場合があります。Cloud Trace と OpenTelemetry ツールを使用すると、大規模にデプロイからレイテンシデータを収集できます。これらのツールは、レイテンシデータを効率的に分析することにも役立ちます。

ネットワークパフォーマンスをモニタリングする

Network Intelligence Center のパフォーマンスダッシュボードは、プロジェクトの Google ネットワークとリソースのパフォーマンス指標を包括的に確認できます。これらの指標は、ネットワーク関連のパフォーマンス問題の原因を特定することに役立ちます。たとえば、パフォーマンスの問題がプロジェクトの問題によるものか、Google ネットワークの問題によるものかを判断できます。

次のステップ

クラウドリソースのモニタリングに関するベストプラクティスを確認する。
Google Cloud リソースのパフォーマンスを最適化するためのベストプラクティスを確認する。

コンピューティングパフォーマンスを最適化する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Compute Engine、Google Kubernetes Engine（GKE）、サーバーレスリソースのパフォーマンスの最適化に役立つ推奨事項について説明します。

Compute Engine

このセクションでは、Compute Engine リソースのパフォーマンスの最適化に役立つガイダンスを示します。

リソースの自動スケール

マネージドインスタンスグループ（MIG）を使用すると、Compute Engine VM にデプロイされたステートレスアプリを効率よくスケールできます。自動スケーリングによって、負荷が増加してもアプリが引き続き予測可能なパフォーマンスを実現できるようになります。MIG では、Compute Engine VM のグループが定義したテンプレートに基づいて開始されます。そのテンプレートでは、グループをスケールするためにオートスケーラーが使う 1 つ以上のシグナルを指定する自動スケーリングポリシーを構成します。自動スケーリングのシグナルは、開始時間や期間などのスケジュールまたは平均 CPU 使用率などの目標指標をベースにします。詳細については、インスタンスのグループの自動スケーリングをご覧ください。

SMT を無効にする

Compute Engine VM に割り当てる各仮想 CPU（vCPU）は、単一のハードウェアマルチスレッドとして実装されます。デフォルトでは、2 つの vCPU が 1 つの物理 CPU コアを共有します。このアーキテクチャは、同時マルチスレッド（SMT）と呼ばれます。

高度に並列化されたワークロードや、浮動小数点計算を実行するワークロード（コード変換、モンテカルロシミュレーション、遺伝子配列分析、金融リスクモデリングなど）では、SMT を無効にしてパフォーマンスを向上させることができます。詳細については、コアあたりのスレッド数を設定するをご覧ください。

GPU を使用する

ML や可視化などのワークロードの場合は、VM にグラフィックプロセッシングユニット（GPU）を追加できます。Compute Engine では、NVIDIA GPU がパススルーモードで提供されるため、VM が GPU と関連メモリを直接制御できます。3D 可視化などのグラフィックを多用するワークロードの場合は、NVIDIA RTX 仮想ワークステーションを使用できます。ワークロードをデプロイしたら、GPU の使用状況をモニタリングし、GPU パフォーマンスの最適化のオプションを確認します。

コンピューティング最適化マシンタイプを使用する

ゲーム、メディアのコード変換、ハイパフォーマンスコンピューティング（HPC）などのワークロードでは、一貫して高い CPU コアあたりのパフォーマンスを必要とします。このようなワークロードを実行する VM には、コンピューティング最適化マシンタイプを使用することをおすすめします。コンピューティング最適化 VM は、不均一メモリアクセス（NUMA）などの機能を使用する、最適で信頼性の高いパフォーマンスを実現するアーキテクチャの上に構築されています。

密結合な HPC ワークロードには、パフォーマンスのピーク効率を達成するための固有の要件セットがあります。詳細については、以下のドキュメントをご覧ください。

適切なストレージを選択する

Google Cloud には、Compute Engine VM 用のさまざまなストレージオプション（永続ディスク、ローカル SSD（ソリッドステートドライブ）ディスク、Filestore、Cloud Storage）が用意されています。こうしたストレージオプションそれぞれのパフォーマンスを最適化する設計の推奨事項とベストプラクティスについては、ストレージパフォーマンスの最適化をご覧ください。

Google Kubernetes Engine

このセクションでは、Google Kubernetes Engine（GKE）リソースのパフォーマンスの最適化に役立つガイダンスを示します。

リソースの自動スケール

GKE クラスタ内のノードプールのサイズは、クラスタオートスケーラー機能を使用することで、現在の負荷に合わせて自動的に変更できます。自動スケーリングによって、負荷が増加してもアプリが引き続き予測可能なパフォーマンスを実現できるようになります。クラスタオートスケーラーは、実際のリソース使用率ではなく、ノードで動作している Pod のリソースリクエストに基づいて、ノードプールのサイズを自動的に変更します。自動スケーリングを使用する場合、パフォーマンスとコストにトレードオフがあります。クラスタの自動スケーリングを効率的に構成するためのベストプラクティスを確認してください。

C2D VM を使用する

C2D マシンタイプを使用すると、コンピューティング負荷の高いコンテナ化されたワークロードのパフォーマンスを向上させることができます。C2D ノードは、ノードプールで C2D マシンタイプを選択することで、GKE クラスタに追加できます。

SMT を無効にする

同時マルチスレッディング（SMT）は、一般的なコンピューティングタスクや、高い I/O を必要とするワークロードで、アプリケーションのスループットを大幅に向上させることができます。ただし、両方の仮想コアがコンピューティング能力による制約を受けるワークロードの場合、SMT によりパフォーマンスが安定しない可能性があります。パフォーマンスの予測可能性を向上させるには、コアあたりの vCPU 数を 1 に設定して、GKE ノードの SMT を無効にします。

GPU を使用する

画像認識や動画コード変換などのコンピューティング負荷の高いワークロードの場合は、GPU を使用するノードプールを作成することでパフォーマンスを高速化できます。詳細については、GPU の実行をご覧ください。

コンテナネイティブのロードバランシングを使用する

コンテナネイティブのロードバランシングにより、ロードバランサはトラフィックを直接かつ均等に Pod へ分散できます。この方法を使用すると、ネットワークパフォーマンスが向上し、ロードバランサと Pod 間のネットワークレイテンシの可視化が改善されます。このような利点のため、コンテナネイティブのロードバランシングが Ingress によるロードバランシングに推奨されるソリューションです。

コンパクトプレースメントポリシーを定義する

密結合されたバッチワークロードでは、GKE ノードプール内のノード間のネットワークレイテンシを低くする必要があります。コンパクトプレースメントポリシーを定義すると、このようなワークロードをシングルゾーンノードプールにデプロイして、ノードを物理的に近づけることができます。詳細については、GKE ノードのコンパクトプレースメントを定義するをご覧ください。

サーバーレスコンピューティングサービス

このセクションでは、Google Cloud のサーバーレスコンピューティングサービス（Cloud Run および Cloud Functions）のパフォーマンスの最適化に役立つガイダンスを示します。これらのサービスは自動スケーリング機能を備え、基盤となるインフラストラクチャが自動的にスケーリングを処理します。こうしたサーバーレスサービスを使用すると、マイクロサービスと関数のスケールにかかる労力を削減し、アプリケーションレベルでのパフォーマンスの最適化に集中できます。

詳細については、以下のドキュメントをご覧ください。

次のステップ

ストレージ、ネットワーキング、データベース、分析リソースのパフォーマンスを最適化するためのベストプラクティスを確認してください。

ストレージパフォーマンスを最適化する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud のストレージリソースのパフォーマンスを最適化するための推奨事項について説明します。

Cloud Storage

このセクションでは、Cloud Storage オペレーションのパフォーマンスを最適化するためのベストプラクティスについて説明します。

バケットのパフォーマンスを評価する

Cloud Storage バケットのパフォーマンスを評価するには、gsutil perfdiag コマンドを使用します。このコマンドは、さまざまなサイズのファイルで一連の読み取り / 書き込みリクエストを送信して、指定されたバケットのパフォーマンスをテストします。テストは、アプリケーションの使用パターンに合わせて調整できます。このコマンドで生成される診断レポートを使用して、パフォーマンスの予測値を設定し、潜在的なボトルネックを特定します。

アクセス頻度が高いオブジェクトをキャッシュに保存する

一般公開されており頻繁にアクセスされるオブジェクトの読み取りレイテンシを改善するには、このようなオブジェクトがキャッシュに保存されるように構成します。パフォーマンスはキャッシュ保存により改善できますが、キャッシュにオブジェクトの古いバージョンがあると、古いコンテンツが提供される可能性があります。

リクエストを効率的にスケールする

バケットのリクエストレートが増加すると、Cloud Storage は複数のサーバーにリクエストの負荷を分散し、バケットの I/O 容量を自動的に増やします。リクエストのスケーリング時に最適なパフォーマンスを実現するには、リクエストレートを増加させ、負荷を均等に分散するためのベストプラクティスに従ってください。

マルチスレッド処理とマルチプロセッシングを有効にする

gsutil を使用して多数の小さなファイルをアップロードする場合は、-m オプションを使用してオペレーションのパフォーマンスを改善できます。このオプションを使用すると、アップロードリクエストがバッチ並列処理（マルチスレッド処理とマルチプロセッシング）で実装されます。このオプションは、高速ネットワーク接続を介してオペレーションを実行する場合にのみ使用します。詳細については、グローバルコマンドラインオプションの -m オプションのドキュメントをご覧ください。

大きなファイルを合成物としてアップロードする

大きなファイルをアップロードするには、並列複合アップロードと呼ばれる方式を使用できます。この方式では、大きなファイルがチャンクに分割され、それらが並行してアップロードされてからクラウドで再構成されます。ネットワーク帯域幅とディスク速度が制限要因になっていない場合は、並列複合アップロードが通常のアップロードオペレーションよりも高速になる可能性があります。ただし、この方式にはいくつかの制限事項があり費用にも影響が及びます。詳細については、並列複合アップロードをご覧ください。

永続ディスクとローカル SSD

このセクションでは、Compute Engine VM にアタッチされている Persistent Disk とローカル SSD のパフォーマンスを最適化するためのベストプラクティスについて説明します。

永続ディスクとローカル SSD のパフォーマンスは、ディスクのタイプとサイズ、VM マシンタイプ、vCPU の数によって異なります。永続ディスクとローカル SSD のパフォーマンスは、次のガイドラインを使用して管理します。

VM にブロックストレージをプロビジョニングする場合は、ワークロードに適したディスクタイプとディスクサイズを選択します。詳細については、パフォーマンス要件を満たすようにディスクを構成するをご覧ください。
ブロックストレージのパフォーマンスをベンチマークします。詳細については、以下のドキュメントをご覧ください。
- 永続ディスクのパフォーマンスのベンチマーク
- ローカル SSD のパフォーマンスのベンチマーク
永続ディスクとローカル SSD のパフォーマンスを最適化します。詳細については、以下のドキュメントをご覧ください。
- 永続ディスクのパフォーマンスの最適化
- ローカル SSD のパフォーマンスの最適化

Filestore

このセクションでは、Filestore インスタンスのパフォーマンスを最適化するためのベストプラクティスについて説明します。Filestore を使用して、Compute Engine VM と GKE クラスタ用のフルマネージドネットワークファイルシステム（NFS）ファイルサーバーをプロビジョニングできます。

Filestore インスタンスをプロビジョニングする際には、ワークロードのパフォーマンスと容量の要件を満たすサービス階層を選択します。
キャッシュに依存するワークロードを実行するクライアント VM には、Filestore インスタンスのネットワークパフォーマンスを最適化できるマシンタイプを使用します。詳細については、推奨されるクライアントマシンタイプをご覧ください。
Linux を実行するクライアント VM の Filestore インスタンスのパフォーマンスを最適化するには、専用の NFS マウント設定をおすすめします。詳細については、Linux クライアントのマウントオプションをご覧ください。
ネットワークレイテンシを最小化するには、インスタンスを使用する予定の場所に近いリージョンとゾーンに、Filestore インスタンスをプロビジョニングします。
Filestore インスタンスのパフォーマンスをモニタリングし、Cloud Monitoring を使用してアラートを設定します。

次のステップ

コンピューティングリソース、ネットワーキングリソース、データベースリソース、分析リソースのパフォーマンスを最適化するためのベストプラクティスを確認します。

ネットワーキングと API のパフォーマンスを最適化する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud でネットワーキングリソースと API のパフォーマンスを最適化する際に役立つ推奨事項について説明します。

Network Service Tiers

Network Service Tiers を使用することで、ワークロードのネットワーク費用とパフォーマンスを最適化できます。以下のティアから選択できます。

プレミアムティアは、信頼性の高い Google のグローバルバックボーンを使用して、パケットロスとレイテンシを最小限に抑える効果があります。トラフィックは、エンドユーザーに近いグローバルエッジポイントオブプレゼンス（PoP）で Google ネットワークに出入りします。最適なパフォーマンスを得るには、デフォルトの階層としてプレミアムティアを使用することをおすすめします。プレミアムティアは、VM とロードバランサに対して、リージョンとグローバル両方の外部 IP アドレスをサポートしています。
スタンダードティアは、リージョン外部 IP アドレスを使用するリソースでのみ使用できます。トラフィックは、ワークロードが実行されている Google Cloud のロケーションに最も近いエッジ PoP で Google ネットワークに出入りします。スタンダードティアの料金は、プレミアムティアよりも低くなっています。スタンダードティアは、パケットロスの影響を受けない、低レイテンシの要件がないトラフィックに適しています。

スタンダードティアとプレミアムティアのネットワークレイテンシは、Network Intelligence Center のパフォーマンスダッシュボードで、クラウドリージョンごとに確認できます。

ジャンボフレーム

Virtual Private Cloud（VPC）ネットワークのデフォルトの最大伝送単位（MTU）は 1,460 バイトです。ただし、最大 8896（ジャンボフレーム）の MTU をサポートするように VPC ネットワークを構成できます。

MTU が高いほど、同じ量のデータを送信する際に必要となるパケットが少なくなるため、TCP/IP ヘッダーで使用される帯域幅が削減されます。これにより、ネットワークの有効帯域幅が向上します。

VPC 内の MTU と他の接続の最大 MTU の詳細については、VPC ドキュメントの最大伝送単位のページをご覧ください。

VM のパフォーマンス

Compute Engine VM の下り（外向き）の最大帯域幅は、マシンタイプによって部分的に異なります。適切なマシンタイプの選択における検討要素の一つは、VM が生成に予測されるトラフィック量です。

ネットワーク帯域幅のページには、Compute Engine マシンタイプのネットワーク帯域幅についての議論と表が記載されています。

VM 間の帯域幅の要件が非常に高い場合は、Tier_1 ネットワーキングをサポートする VM を検討してください。

Cloud Load Balancing

このセクションでは、Cloud Load Balancing インスタンスのパフォーマンスの最適化に役立つベストプラクティスについて説明します。

アプリケーションをユーザーの近くにデプロイする

ユーザートラフィックがロードバランサに到達すると想定するロケーションに近いアプリケーションバックエンドをプロビジョニングします。ユーザーやクライアントアプリケーションがワークロードサーバーに近いほど、ユーザーとワークロード間のネットワークレイテンシは小さくなります。世界中のさまざまなクライアントのレイテンシを最小化するには、バックエンドを複数のリージョンにデプロイする必要があります。詳細については、Compute Engine のリージョン選択に関するベストプラクティスをご覧ください。

適切なロードバランサの種類を選択する

アプリケーション用に選択するロードバランサの種類によって、ユーザーが経験するレイテンシを決定できます。各種のロードバランサに対するアプリケーションレイテンシの測定と最適化については、ロードバランシングに伴うアプリケーションレイテンシの最適化をご覧ください。

キャッシュ保存を有効にする

コンテンツ配信を高速化するには、デフォルトの外部 HTTP ロードバランサ構成の一部として、キャッシュ保存と Cloud CDN を有効にします。バックエンドサーバーが、静的レスポンスのキャッシュ保存に必要なレスポンスヘッダーを送信するように構成されていることを確認してください。

HTTPS が不要な場合は HTTP を使用する

Google では、パケットレベルでプロキシロードバランサとバックエンド間のトラフィックを自動的に暗号化します。ほとんどの場合、パケットレベルの暗号化では、ロードバランサとバックエンドの間で HTTPS を使用してレイヤ 7 の暗号化が行われます。ロードバランサとバックエンド間のトラフィックには、HTTPS や HTTP/2 ではなく HTTP を使用することを検討してください。HTTP を使用することで、バックエンド VM の CPU 使用率も低減できます。ただし、バックエンドがインターネットネットワークエンドポイントグループ（NEG）の場合は、ロードバランサとバックエンド間のトラフィックに HTTPS または HTTP/2 を使用します。これにより、公共のインターネット上でトラフィックが保護されます。最適なパフォーマンスを得るため、アプリケーションのトラフィックパターンをベンチマークすることをおすすめします。

Network Intelligence Center

Google Cloud Network Intelligence Center では、すべてのリージョンにわたって Google Cloud ネットワークのパフォーマンスを包括的に確認できます。Network Intelligence Center は、レイテンシの問題がプロジェクトまたはネットワークの問題が原因であるかどうかの判断に役立ちます。この情報を使用して、ワークロードをデプロイするリージョンとゾーンを選択し、ネットワークパフォーマンスを最適化することもできます。

Network Intelligence Center に備わっている次のツールを使用し、Google Cloud のワークロードのネットワークパフォーマンスをモニタリングして分析します。

パフォーマンスダッシュボードには、Google Cloud リージョン間、およびインターネット上の個々のリージョンとロケーション間のレイテンシが表示されます。パフォーマンスダッシュボードは、最適なレイテンシでどこにワークロードを配置するかを決定し、基盤となるネットワークの問題によってアプリケーションの問題を引き起こしている可能性があるタイミングを判断するのに役立ちます。
ネットワークトポロジでは、Virtual Private Cloud（VPC）ネットワーク、オンプレミスネットワークとのハイブリッド接続、Google マネージドサービスへの接続が視覚的に表示されます。ネットワークトポロジは、ネットワークパフォーマンスを分析して理解し、異常なトラフィックパターンの識別に使用できるリアルタイムの運用指標を提供します。
ネットワークアナライザは、自動構成モニタリングおよび診断ツールです。ファイアウォールルールの VPC ネットワーク構成、ルート、構成の依存関係、サービスとアプリケーションの接続性を検証します。ネットワーク障害を特定し、根本原因を分析して推奨事項を提示する作業をサポートします。ネットワークアナライザは、ネットワーク構成の問題（サブネット内の IP アドレスの使用率が高いなど）の分析に役立つ、優先順位付けされた分析情報を提供します。

API Gateway と Apigee

このセクションでは、API Gateway と Apigee を使用して、Google Cloud にデプロイされる API のパフォーマンスを最適化をサポートする推奨事項を示します。

API Gateway を使用すると、Cloud Functions、Cloud Run、App Engine などの Google Cloud サーバーレスバックエンド向けの API を作成して管理できます。これらのサービスはマネージドサービスであり、自動的にスケールします。ただし、これらのサービスにデプロイされるアプリケーションがスケールされるため、API ゲートウェイの割り当てとレート上限を引き上げる必要があります。

Apigee には、マネージド API のパフォーマンスのモニタリングに役立つ次の分析ダッシュボードが用意されています。

API プロキシパフォーマンスダッシュボード: API プロキシのトラフィックパターンと処理時間をモニタリングします。
ターゲットパフォーマンスダッシュボード: API プロキシバックエンドターゲットのトラフィックパターンとパフォーマンス指標を可視化します。
キャッシュパフォーマンスダッシュボード: Apigee のキャッシュのパフォーマンス指標（平均キャッシュヒット率やキャッシュに保存されている平均時間など）をモニタリングします。

Apigee Integration を使用している場合は、インテグレーションを構築および管理する際に、システム構成の上限を考慮してください。

次のステップ

コンピューティングリソース、ストレージリソース、データベースリソース、分析リソースのパフォーマンスを最適化するためのベストプラクティスを確認する。

データベースパフォーマンスを最適化する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud のデータベースのパフォーマンスを最適化するための推奨事項について説明します。

Cloud SQL

次の推奨事項は、SQL Server、MySQL、PostgreSQL の各データベースを実行する Cloud SQL インスタンスのパフォーマンスを最適化する際に役立ちます。

SQL Server データベースの場合は、特定のパラメータを変更し、一部のパラメータのデフォルト値を保持することをおすすめします。
MySQL データベースまたは PostgreSQL データベースのストレージタイプを選択する場合は、SSD ストレージと HDD ストレージのコストパフォーマンスのトレードオフを考慮してください。
PostgreSQL データベースのパフォーマンスの問題を特定して分析するには、Cloud SQL Insights ダッシュボードを使用します。
SQL クエリを実行する際のパフォーマンスの低下を診断するには、EXPLAIN ステートメントを使用します。

詳細については、以下のドキュメントをご覧ください。

Bigtable

このセクションでは、Bigtable インスタンスのパフォーマンスを最適化するための推奨事項について説明します。

パフォーマンス要件に基づいて容量を計画する

Bigtable は幅広いアプリケーションで使用できますが、アプリケーションごとに最適化の目標が異なります。たとえば、バッチデータ処理ジョブでは、レイテンシよりもスループットが重要になることがあります。ユーザーリクエストを処理するオンラインサービスの場合、スループットよりも低レイテンシを優先しなければならない場合もあります。Bigtable クラスタの容量を計画する場合は、スループットとレイテンシの間のトレードオフを考慮してください。詳細については、Bigtable の容量を計画するをご覧ください。

スキーマ設計のベストプラクティスに従う

テーブルは数十億行、数千列にまでスケールできるため、ペタバイト規模のデータを保存できます。Bigtable テーブルのスキーマを設計する場合は、スキーマ設計のベストプラクティスを検討してください。

パフォーマンスをモニタリングして調整する

インスタンスの CPU とディスクの使用状況をモニタリングし、各クラスタのパフォーマンスを分析して、モニタリンググラフに示されている適正サイズを確認します。

Spanner

このセクションでは、Spanner インスタンスのパフォーマンスを最適化するための推奨事項について説明します。

ホットスポットを防ぐ主キーを選択する

ホットスポットとは、多数のリクエストの処理を強いられる単一サーバーです。データベースの主キーを選択する場合は、スキーマ設計のベストプラクティスに従って、ホットスポットの発生を回避してください。

SQL コーディングのベストプラクティスに従う

Spanner の SQL コンパイラは、宣言型の SQL ステートメントを命令型のクエリ実行プランに変換します。Spanner は、実行プランを使用して SQL ステートメントを実行します。SQL ステートメントを作成するときは、SQL のベストプラクティスに従い、最適なパフォーマンスを発揮するような実行プランを Spanner が使用するようにします。

クエリオプションを使用して SQL クエリオプティマイザーを管理する

Spanner は、SQL クエリオプティマイザーを使用して、SQL ステートメントを効率的なクエリ実行プランに変換します。オプティマイザーによって生成されるクエリ実行プランは、クエリオプティマイザー自体が進化したとき、またはデータベース統計情報が更新されたときに、わずかに変更される可能性があります。クエリオプションを使用すると、クエリオプティマイザーまたはデータベースの統計情報が変更されたときのパフォーマンスの低下を最小限に抑えることができます。

クエリ実行プランの構造を可視化して調整する

クエリのパフォーマンスの問題を分析するには、クエリプランの可視化ツールを使用して、クエリ実行プランの構造を可視化してチューニングします。

オペレーション API を使用して長時間実行オペレーションを管理する

特定のメソッド呼び出しでは、Spanner によって長時間実行オペレーションが作成され、完了までにかなりの時間がかかることがあります。たとえば、データベースを復元する場合、Spanner は復元の進行状況を追跡するために長時間実行オペレーションを作成します。Spanner には、長時間実行オペレーションのモニタリングと管理に役立つオペレーション API が用意されています。詳細については、長時間実行オペレーションの管理をご覧ください。

一括読み込みに関するベストプラクティスを実施する

Spanner は、大量のデータを一括で読み込むためのオプションをいくつかサポートしています。一括読み込みオペレーションのパフォーマンスは、パーティショニング、書き込みリクエスト数、各リクエストのサイズなどの要因によって異なります。大量のデータを効率的に読み込むには、一括読み込みのベストプラクティスに従ってください。

CPU 使用率をモニタリングして制御する

Spanner インスタンスの CPU 使用率は、リクエストのレイテンシに影響する可能性があります。バックエンドサーバーが過負荷状態になると、リクエストのレイテンシが増加する可能性があります。Spanner は、高い CPU 使用率の調査に役立つ CPU 使用率の指標を提供します。パフォーマンス重視のアプリケーションでは、コンピューティング容量を増やして CPU 使用率を低減することが必要になる場合があります。

レイテンシの問題を分析して解決する

クライアントが Spanner に対してリモートプロシージャコールを行うと、まず、クライアントライブラリによって API リクエストが準備されます。リクエストは Spanner データベースに到達する前に、Google Front End と Cloud Spanner API Front End を通過します。レイテンシの問題を分析して解決するには、API リクエストが通過するパスの各セグメントでレイテンシを測定して分析する必要があります。詳細については、Spanner エンドツーエンドのレイテンシガイドをご覧ください。

データベースがウォーム状態に達した後にアプリケーションを起動する

Spanner データベースが大きくなると、データのキースペースがスプリットに分割されます。各スプリットは、テーブルのサブセットを含む行の範囲です。データベース全体の負荷を分散するために、Spanner は動的に個々のスプリットを個別に移動させ、異なるサーバーに割り当てます。スプリットが複数のサーバーに分散している場合、データベースはウォーム状態とみなされます。データベースがウォーム状態になると、並列処理が最大化され、パフォーマンスが向上します。アプリケーションをリリースする前に、テストデータを読み込んでデータベースをウォームアップすることをおすすめします。

次のステップ

コンピューティングリソース、ストレージリソース、ネットワーキングリソース、分析リソースのパフォーマンスを最適化するためのベストプラクティスを確認します。

分析パフォーマンスを最適化する

Google Cloud アーキテクチャフレームワークのこのドキュメントでは、Google Cloud の分析ワークロードのパフォーマンスを最適化するための推奨事項について説明します。

BigQuery

このセクションでは、BigQuery でクエリのパフォーマンスを最適化するための推奨事項について説明します。

クエリデザインを最適化する

クエリのパフォーマンスは、クエリで読み書きされるバイト数や、スロット間で渡されるデータ量などの要因によって異なります。BigQuery でクエリのパフォーマンスを最適化するには、次のドキュメントをご覧ください。

マテリアライズドビューを効率的に定義して使用する

一般的なクエリや繰り返しクエリを使用するワークロードのパフォーマンスを向上させるには、マテリアライズドビューを使用します。作成できるマテリアライズドビューの数には上限があります。クエリを置換するたびに、マテリアライズドビューを個別に作成しないでください。代わりに、クエリの複数のパターンに使用できるマテリアライズドビューを定義します。

`JOIN` のパフォーマンスを改善する

マテリアライズドビューを使用すると、JOIN 上で集計を行うクエリのコストとレイテンシを低減できます。大きなファクトテーブルをいくつかの小さなディメンションテーブルと結合してから、それを基に集計を行う場合を考えてみます。次のようにクエリを書き換えると実用的になる可能性があります。まず外部キーをグループ化キーとして使用して、ファクトテーブル上で集計を行います。次に、その結果をディメンションテーブルと結合します。最後に事後集計を行います。

Dataflow

このセクションでは、Dataflow パイプラインのクエリパフォーマンスを最適化するための推奨事項について説明します。

パイプラインを作成してデプロイするときに、Dataflow ワーカー VM に使用する Compute Engine マシンタイプなどの実行パラメータを構成できます。詳細については、パイプラインオプションをご覧ください。

パイプラインをデプロイすると、ジョブの実行に必要な Compute Engine リソースと Cloud Storage リソースを Dataflow が管理します。また、Dataflow の次の機能は、パイプラインのパフォーマンスの最適化に役立ちます。

並列化: Dataflow は、データを自動的に分割し、並列処理のためにワーカーコードを Compute Engine インスタンスに分散します。詳細については、並列化と分散をご覧ください。
最適化: Dataflow はパイプラインコードを使用して、PCollection オブジェクトとパイプライン内の変換を表す実行グラフを作成します。次に、最も効率的なパフォーマンスとリソース使用率を実現するためにグラフを最適化します。Dataflow は、データ集計など、コストがかかる可能性のある操作も自動的に最適化します。詳細については、融合の最適化と結合の最適化をご覧ください。
自動調整: Dataflow は、水平自動スケーリング、垂直自動スケーリング、動的作業再調整の実行時に動的にジョブを最適化します。

ウェブベースのモニタリングインターフェースまたは Dataflow gcloud CLI を使用して、Dataflow パイプラインのパフォーマンスをモニタリングできます。

Dataproc

このセクションでは、Dataproc クラスタのパフォーマンスを最適化するためのベストプラクティスについて説明します。

クラスタの自動スケール

Dataproc クラスタで安定したパフォーマンスを提供するには、自動スケーリングを有効にします。Dataproc は、Hadoop YARN メモリ指標と、クラスタ内のワーカー VM の数を自動的に調整するために定義した自動スケーリングポリシーを使用します。自動スケーリングの使用方法と構成方法については、クラスタの自動スケーリングをご覧ください。

適切なストレージをプロビジョニングする

パフォーマンスとコストの要件に基づいて、Dataproc クラスタに適したストレージオプションを選択します。

最小限の変更で、Hadoop と Spark のジョブで読み取り/書き込みを行える低コストの Hadoop 互換ファイルシステム（HCFS）が必要な場合は、Cloud Storage を使用します。Cloud Storage に格納されたデータは永続的であり、他の Dataproc クラスタや他のプロダクト（BigQuery など）からアクセスできます。
Dataproc クラスタに低レイテンシの Hadoop 分散ファイルシステム（HDFS）が必要な場合は、ワーカーノードにアタッチされた Compute Engine 永続ディスクを使用します。HDFS ストレージに格納されるデータは一時的なものであり、Cloud Storage のオプションよりもストレージコストが高くなります。
Compute Engine 永続ディスクのパフォーマンス上のメリットと、Cloud Storage がもたらすコストと耐久性のメリットを得るために、両方のストレージオプションを組み合わせることができます。たとえば、ソースデータセットと最終データセットを Cloud Storage に保存し、中間データセットに対して制限付きの HDFS 容量をプロビジョニングできます。HDFS ストレージのディスクのサイズとタイプを決定する場合は、永続ディスクとローカル SSD セクションの推奨事項を検討してください。

Cloud Storage 使用時のレイテンシを短縮する

Cloud Storage に保存されているデータにアクセスする際のレイテンシを短縮するには、次のことをおすすめします。

Dataproc クラスタと同じリージョンに Cloud Storage バケットを作成します。
Cloud Storage に保存されている Apache Hive 管理のテーブルに対して、auto.purge を無効にします。
Spark SQL を使用する場合は、利用可能な最新バージョンのイメージを使用して Dataproc クラスタを作成することを検討してください。最新バージョンを使用することで、Spark 2.x の INSERT OVERWRITE のパフォーマンスが低いなど、古いバージョンに残っている可能性のあるパフォーマンスの問題を回避できます。
さまざまなサイズまたは小さなサイズの多数のファイルを Cloud Storage に書き込む可能性を最小限に抑えるには、Spark SQL パラメータの spark.sql.shuffle.partitions と spark.default.parallelism または Hadoop パラメータ mapreduce.job.reduces を構成します。

ストレージの負荷と容量をモニタリングして調整する

Dataproc クラスタのワーカーノードにアタッチされている永続ディスクは、シャッフルデータを保持しています。最適なパフォーマンスを得るには、ワーカーノードに十分なディスク容量が必要です。ノードに十分なディスク容量がない場合、YARN NodeManager ログでノードに UNHEALTHY とマークされます。この問題が発生した場合は、影響を受けるノードのディスクサイズを増やすか、同時に実行するジョブを減らします。

EFM を有効にする

ダウンスケーリングやプリエンプションなどにより、実行中の Dataproc クラスタからワーカーノードが削除されると、シャッフルデータが失われる可能性があります。このような場合でのジョブの遅延を最小限に抑えるには、プリエンプティブル VM を使用するクラスタ、またはセカンダリワーカーグループのみを自動スケールするクラスタで、高度な柔軟性モード（EFM）を有効にすることをおすすめします。

次のステップ

コンピューティングリソース、ストレージリソース、ネットワーキングリソース、データベースリソースのパフォーマンスを最適化するためのベストプラクティスを確認します。

アーキテクチャフレームワークの新機能

このドキュメントでは、Google Cloud アーキテクチャフレームワークに対する重要な変更点について説明します。

2023 年 11 月 28 日

信頼性のカテゴリ:
- 読みやすさと整合性を高めるためにコンテンツを再編成
- SLO の定義: 「用語」セクションを新しいページ用語に移動しました
- SLO の導入: 「SLO とアラート」セクションを新しいページ SLO とアラートに移動しました。

2023 年 11 月 9 日

システム設計のカテゴリ:
- クラウドアーキテクト向けに、Google Cloud のワークロードのデプロイアーキタイプを選択するためのガイダンスを追加しました。

2023 年 9 月 8 日

費用最適化のカテゴリ:
- 費用の割り当てとガバナンスにタグを使用する方法に関する情報を追加しました。
- ラベル付けの異常を特定するためのガイダンスを更新しました。
詳細については、タグまたはラベルを使用して費用を追跡して割り当てるをご覧ください。

2023 年 8 月 28 日

システム設計のカテゴリ:
- Google Cloud の AI と ML サービスのリストを更新しました。

2023 年 8 月 23 日

費用最適化のカテゴリ:
- 小規模ワークロードの場合に、ノードではなく処理装置（PU）を使用して、Spanner リソースの使用量を最適化するガイダンスを追加しました。

2023 年 8 月 18 日

セキュリティ、プライバシー、コンプライアンスのカテゴリ:
- HIPAA 関連のガイダンスを追加しました。
オペレーショナルエクセレンスのカテゴリ:
- ピークトラフィックイベントの計画のベストプラクティスを更新しました。

2023 年 8 月 9 日

信頼性のカテゴリ:
- 次のプロダクトに関する信頼性関連のドキュメントに対するリンクを追加しました。
  - Dataproc
  - Bigtable
  - Cloud SQL
  - Spanner

2023 年 7 月 13 日

システム設計:
- Google Cloud のデータベースサービスのリストに AlloyDB for PostgreSQL を追加しました。
費用の最適化:
- Persistent Disk セクションに、Google Cloud Hyperdisk とローカル SSD に関するガイダンスを追加しました。

2023 年 6 月 23 日

パフォーマンスの最適化:
- ジャンボフレームと VM に適したマシンタイプを使用して帯域幅の使用量を最適化するガイダンスを追加しました。

2023 年 6 月 15 日

セキュリティ、プライバシー、コンプライアンス:
- Cross-Cloud Interconnect を使用したオンプレミス環境とマルチクラウド環境への接続の保護に関するガイダンスを追加しました。
- ファイアウォールポリシーとルールおよび Secure Web Proxy を使用したクラウドワークロードの境界の保護に関するガイダンスを追加しました。

2023 年 3 月 30 日

SLO に関する次の 2 つの記事をフレームワークに追加しました。
- SLO を定義する
- SLO を導入する

2022 年 9 月 16 日

パフォーマンスの最適化カテゴリを大幅に拡張しました。

2022 年 8 月 10 日

システム設計のカテゴリの変更:
- システム設計の基本原則を追加しました。
- Google Cloud コンサルティングサービスを使用してパートナーと協働するための推奨事項を追加しました。

2022 年 8 月 4 日

費用最適化のカテゴリに、次の機能に関する情報を追加しました。
- プロジェクトと請求先アカウントの間のリンクをロックすることで、請求に関する問題によるサービス停止を防止する。詳細については、請求のアクセス制御を構成するをご覧ください。
- Service Usage API を使用して割り当てを削減する。詳細については、予算、アラート、割り当てをご覧ください。
- 放置されたプロジェクトを特定して削除する。詳細については、Active Assist の推奨事項をご覧ください。

2022 年 7 月 13 日

オペレーショナルエクセレンスカテゴリの変更点:
- センターオブエクセレンスを構築するベストプラクティスを追加しました。
- 監査証跡を設定するベストプラクティスを追加しました。

2022 年 6 月 27 日

セキュリティカテゴリに、Google Cloud における責任と運命の共有に関する情報を追加しました。

2022 年 6 月 13 日

システム設計カテゴリに、環境のサステナビリティのためのクラウドワークロードの設計に役立つ推奨事項を追加しました。

2022 年 6 月 1 日

Spot VM に関する情報を費用の最適化: コンピューティング、コンテナ、サーバーレスのセクションに追加しました。

2022 年 5 月 7 日

デュアルリージョンのロケーションに関する情報を Cloud Storage のコスト最適化のベストプラクティスに追加しました。

2022 年 5 月 4 日

プロダクト信頼性ガイドを追加しました。各ガイドには、次のプロダクトに関する信頼性のベストプラクティスが記載されています。
- コンピューティング: Compute Engine、Cloud Run、Cloud Functions、Google Kubernetes Engine
- ストレージとデータベース: Cloud Storage、Firestore
- ネットワーキング: Cloud DNS、Cloud Load Balancing
- データ分析: BigQuery

2022 年 2 月 25 日

セキュリティカテゴリの変更:
- コンプライアンスのベストプラクティスを自動化について説明するように更新しました。

2021 年 12 月 15 日

Google Cloud コミュニティにアーキテクチャフレームワークスペースを開設しました。

2021 年 10 月 25 日

信頼性カテゴリの変更:
- 障害復旧のためにリージョン間でのデータの複製とリージョンの停止に対する耐障害性を確保するためのマルチリージョンアーキテクチャの設計のためのベストプラクティスを追加しました。
- エラーバジェットの計算方法を示す例を追加しました。
- アプリケーションとサービスの適切な名前の選択にベストプラクティスを追加しました。

2021 年 10 月 7 日

すべてのカテゴリを大幅に更新しました。

Anna Berenberg and Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 ↩

Google Cloud アーキテクチャ フレームワーク

Google Cloud アーキテクチャ フレームワーク: システム設計

システム設計の基本原則

すべてを文書化する

設計を簡素化し、フルマネージド サービスを利用する

アーキテクチャを分離する

ステートレス アーキテクチャを使用する

次のステップ

Google Cloud デプロイ アーキタイプを選択する

デプロイ アーキタイプとは

デプロイ アーキタイプの概要

ゾーン

リージョン

マルチリージョン

グローバル

ハイブリッド

マルチクラウド

地理的ゾーンとリージョンを選択する

複数のリージョンにデプロイする

地理的な近接性に基づいてリージョンを選択する

利用可能なサービスに基づいてリージョンを選択する

コンプライアンスをサポートするリージョンを選択する

主要なリソースの料金を比較する

Cloud Load Balancing を使用してグローバル ユーザーにサービスを提供する

サステナビリティをサポートする Cloud Region Picker を使用する

次のステップ

クラウド リソースを管理する

リソース階層

リソースラベルとタグ

シンプルなフォルダ構造を使用する

フォルダとプロジェクトを使用してデータ ガバナンス ポリシーを反映させる

プロジェクトの開始時にタグとラベルを使用する

ラベルを割り当てて費用と請求のレポートをサポートする

大量のラベルを作成しない

ラベルに機密情報を追加しない

プロジェクト名で情報を匿名化する

タグを適用してビジネス ディメンションをモデル化する

組織のポリシー

プロジェクトの命名規則を確立する

プロジェクトの作成を自動化する

システムを定期的に監査する

一貫性を保ってプロジェクトを構成する

ワークロードや環境を切り離す

課金の分離を適用する

組織のポリシー サービスを使用してリソースを制御する

組織のポリシーを使用して規制ポリシーを遵守する

ドメインに基づいてリソースの共有を制限する

サービス アカウントとキーの作成を無効にする

新しいリソースの物理的な場所を制限する

次のステップ

コンピューティングを選択して管理する

コンピューティングを選択する

コンピューティング プラットフォームを選択する

コンピューティングの移行アプローチを選択する

ワークロードの設計

シンプルなロジックのサーバーレス オプションを評価する

アプリケーションを分離してステートレスにする

アーキテクチャの分離にキャッシュ ロジックを使用する

ライブ マイグレーションを使用してアップグレードを促進する

ワークロードのスケーリング

起動スクリプトとシャットダウン スクリプトを使用する

MIG を使用して VM 管理をサポートする

Pod オートスケーラーを使用して GKE ワークロードをスケーリングする

アプリケーション トラフィックを分散する

コンピューティングの作成と管理を自動化する

運用の管理

Google 提供の公開イメージを使用する

インスタンスのバックアップにスナップショットを使用する

マシンイメージを使用して VM インスタンスの作成を有効にする

容量、予約、分離

確約利用割引を使用して費用を削減する

費用とパフォーマンスをサポートするマシンタイプを選択する

単一テナントノードを使用してコンプライアンスのニーズに対応する

予約を使用してリソースの可用性を確保する

VM の移行

組み込みの移行ツールを評価する

仮想オペレーティング システムの OS をカスタマイズする

推奨事項

次のステップ

ネットワーク インフラストラクチャを設計する

Google Cloud アーキテクチャフレームワーク

Google Cloud アーキテクチャフレームワーク: システム設計

設計を簡素化し、フルマネージドサービスを利用する

ステートレスアーキテクチャを使用する

Google Cloud デプロイアーキタイプを選択する

デプロイアーキタイプとは

デプロイアーキタイプの概要

Cloud Load Balancing を使用してグローバルユーザーにサービスを提供する

クラウドリソースを管理する

フォルダとプロジェクトを使用してデータガバナンスポリシーを反映させる

タグを適用してビジネスディメンションをモデル化する

組織のポリシーサービスを使用してリソースを制御する

サービスアカウントとキーの作成を無効にする

コンピューティングプラットフォームを選択する

シンプルなロジックのサーバーレスオプションを評価する

アーキテクチャの分離にキャッシュロジックを使用する

ライブマイグレーションを使用してアップグレードを促進する

起動スクリプトとシャットダウンスクリプトを使用する

アプリケーショントラフィックを分散する

仮想オペレーティングシステムの OS をカスタマイズする

ネットワークインフラストラクチャを設計する

VPC ネットワークトポロジをシンプルに保つ

共有 VPC を使用して、複数のワーキンググループを管理する

接続テストを行って、ネットワークセキュリティを検証する

Private Service Connect を使用して、プライベートエンドポイントを作成する

Network Intelligence Center を使用してクラウドネットワークをモニタリングする

高性能ストレージニーズのオプションを評価する

Google Cloud サービスでストレージデザインをサポートする

ストレージアクセスのニーズに基づいてアクティブストレージまたはアーカイブストレージを選択する

ストレージアクセスパターンとワークロードタイプ

リトライロジックの実装時に指数バックオフを使用する

マネージドデータベースサービスの使用を検討する

Memorystore を使用してキャッシュ保存データベースレイヤをサポートする

ベアメタルサーバーを使用して Oracle データベースを運用する

データ所在地をサポートする特定のクラウドリージョン

モニタリング指標を使用してスケーリングニーズを評価する

プライベートネットワークでデータベースを運用する

データベースインスタンスをコードとして定義する

オンデマンドライセンスか既存のライセンスかを選択する

継続的なデータレプリケーションの要件を決定する