このドキュメントは、Google Cloud の障害復旧（DR）について説明するシリーズの一部です。このドキュメントでは、地域制限があるワークロードの障害復旧の設計のドキュメントから、地域制限をデータ分析アプリケーションに適用する方法について説明します。具体的には、データ分析プラットフォームで使用するコンポーネントが、アプリケーションやデータに適用される地域制限を満足する DR アーキテクチャにどのように適合するかについて説明します。
このシリーズは、次のパートで構成されています。
- 障害復旧計画ガイド
- 障害復旧の構成要素
- データの障害復旧シナリオ
- アプリケーションの障害復旧シナリオ
- 地域制限があるワークロードの障害復旧の設計
- クラウド インフラストラクチャの停止に対する障害復旧の設計
- 障害復旧のユースケース: 地域制限があるデータ分析アプリケーション（このドキュメント）
このドキュメントは、システム アーキテクトと IT マネージャーを対象としています。次の知識とスキルがあることを前提としています。
- Dataflow、Dataproc、Cloud Composer、Pub/Sub、Cloud Storage、BigQuery などの Google Cloud データ分析サービスに関する基本的な知識。
- Cloud Interconnect や Cloud VPN などの Google Cloud ネットワーキング サービスに関する基本的な知識。
- 障害復旧計画に関する知識。
- Apache Hive と Apache Spark に関する知識。
データ分析プラットフォームの地域要件
データ分析プラットフォームは通常、保存データを格納する複雑な多層アプリケーションです。これらのアプリケーションが生成するイベントは、処理されて分析システムに格納されます。アプリケーション自体とシステムに格納されているデータの両方が地域規制の対象である場合があります。これらの規制は、国だけでなく業種によっても異なります。そのため、DR アーキテクチャの設計を開始する前に、データの地域要件を明確に理解しておく必要があります。
次の 2 つの質問に答えると、データ分析プラットフォームに地域的な要件があるかどうかを確認できます。
- アプリケーションを特定のリージョンにデプロイする必要がありますか？
- データの保存が特定のリージョンに制限されていますか？
両方の質問に対する答えが「いいえ」の場合、そのデータ分析プラットフォームには地域固有の要件はありません。プラットフォームに地域要件がないため、障害復旧計画ガイドに概説されている適合サービスとプロダクトについて、DR ガイダンスに従ってください。
一方、いずれかの質問に対する答えが「はい」だった場合、そのアプリケーションは地域が制限されます。分析プラットフォームには地域制限があるため、保存データの要件を軽減するために暗号化方式を使用できるか、を確認する必要があります。
暗号化方式を使用できる場合は、Cloud External Key Manager と Cloud Key Management Service のマルチリージョン サービスとデュアルリージョン サービスを使用できます。そして、データの障害復旧シナリオで概説されている標準の高可用性と障害復旧（HA/DR）の手法に沿うこともできます。
暗号化方式を使用できない場合は、DR 計画にカスタム ソリューションまたはパートナー提案を使用する必要があります。DR シナリオの地域制限に対処する手法については、地域制限があるワークロードの障害復旧の設計をご覧ください。
データ分析プラットフォームのコンポーネント
地域要件を理解したら、次のステップは、データ分析プラットフォームが使用するコンポーネントを理解することです。データ分析プラットフォームの一般的なコンポーネントには、次のリストで説明するように、データベース、データレイク、処理パイプライン、データ ウェアハウスがあります。
- Google Cloud には、異なるユースケースに適合する一連のデータベース サービスがあります。
- データレイク、データ ウェアハウス、処理パイプラインでは、定義がわずかに異なる可能性があります。このドキュメントでは、Google Cloud サービスを参照する一連の定義を使用します。
- データレイクは、複数のシステムからデータを取り込んで保存するためのスケーラブルで安全なプラットフォームです。一般的なデータレイクでは、中央ストレージ リポジトリとして Cloud Storage を使用する場合があります。
- 処理パイプラインは、1 つ以上のシステムからデータまたはイベントを取得し、そのデータまたはイベントを変換して、別のシステムに読み込むエンドツーエンドの処理です。パイプラインは、抽出、変換、読み込み（ETL）または抽出、読み込み、変換（ELT）処理のいずれかを実行できます。通常、処理されたデータが読み込まれるシステムはデータ ウェアハウスです。Pub/Sub、Dataflow、Dataproc は、処理パイプラインの一般的に使用されるコンポーネントです。
- データ ウェアハウスは、通常はオペレーショナル データベースから取得される、データの分析と報告に使用されるエンタープライズ システムです。BigQuery は、Google Cloud 上で一般的に使用されるデータ ウェアハウス システムです。
地域要件と使用しているデータ分析コンポーネントに応じて、実際の DR の実装は異なります。次のセクションでは、このバリエーションを 2 つのユースケースで示します。
バッチのユースケース: 定期的な ETL ジョブ
最初のユースケースでは、小売プラットフォームがさまざまな店舗からセールス イベントを定期的にファイルとして収集し、Cloud Storage バケットに書き込むバッチ処理を説明します。次の図は、この小売店のバッチジョブのデータ分析アーキテクチャを示しています。
このアーキテクチャには、次のフェーズとコンポーネントが含まれています。
- 取り込みフェーズは、店舗の POS（Point Of Sale）データを Cloud Storage に送信する店舗で構成されます。この取り込まれたデータは処理を待ちます。
- オーケストレーション フェーズでは、Cloud Composer を使用して、エンドツーエンドのバッチ パイプラインをオーケストレートします。
- 処理フェーズには、Dataproc クラスタ上で実行される Apache Spark ジョブが含まれます。Apache Spark ジョブが、取り込まれたデータに対して ETL 処理を実行します。この ETL 処理は、ビジネス指標を提供します。
- データレイク フェーズは、処理済みのデータを受け取り、次のコンポーネントに情報を保存します。
- 処理されたデータは一般的に、Parquet や ORC のような Cloud Storage のカラム型で保存されます。これらの形式を使用すると、分析ワークロードに対して効率的なストレージと高速アクセスが可能になるからです。
- プロセスデータに関するメタデータ（データベース、テーブル、列、パーティションなど）は、Dataproc Metastore で提供される Hive メタストア サービスに保存されます。
地域制限があるシナリオでは、可用性維持のための冗長な処理とオーケストレーションの容量を提供することが難しい場合があります。データはバッチで処理されるため、処理およびオーケストレーション パイプラインを再作成でき、障害シナリオが解決した後にバッチジョブを再起動できます。したがって、障害復旧では、実際のデータの復元が特に重要です。データには、取り込まれた POS データ、データレイ保存された処理データ、データレイクに保存されたメタデータが含まれます。
Cloud Storage への取り込み
最初に POS システムからデータを取り込むために使用される Cloud Storage バケットの地域要件を検討する必要があります。以下のオプションを検討する際は、この地域区分情報を使用します。
- 地域要件により、マルチリージョンまたはデュアルリージョンのいずれかのロケーションに保存データを配置できる場合は、Cloud Storage バケットを作成する際に対応するロケーション タイプを選択します。選択したロケーション タイプによって、保存データのレプリケートに使用する Google Cloud リージョンが定義されます。1 つのリージョンでサービス停止が発生しても、マルチリージョンまたはデュアルリージョンのバケットにあるデータにはまだアクセスできます。
- Cloud Storage はまた、顧客管理の暗号鍵（CMEK）と顧客指定の暗号鍵（CSEK）の両方もサポートしています。一部の地域区分ルールでは、鍵管理に CMEK または CSEK を使用する場合に複数のロケーションに保存データを保管できます。CMEK または CSEK の使用が地域区分ルールによって許可されている場合、Cloud Storage リージョンを使用するように DR アーキテクチャを設計できます。
- 地域要件により、ロケーション タイプと暗号鍵管理のどちらも使用できない場合があります。ロケーション タイプや暗号鍵の管理を使用できない場合、
gsutil rsyncコマンドを使用して別のロケーション（たとえば、別のクラウド プロバイダのオンプレミス ストレージまたはストレージ ソリューション）にデータを同期させることができます。
障害が発生した場合、Cloud Storage バケットに取り込まれた POS データに、まだ処理されてデータレイクにインポートされていないデータが含まれている場合があります。あるいは、POS データを Cloud Storage バケットに取り込めない場合があります。このような場合には、次の障害復旧オプションがあります。
POS システムに再試行させる。システムが POS データを Cloud Storage に書き込むことができない場合、データ取り込み処理は失敗します。この状況を緩和するには、切り捨て型指数バックオフ アルゴリズムを実装して、POS システムがデータ取り込みオペレーションを再試行できるようにします。Cloud Storage はイレブンナインの耐久性を提供するため、データ取り込みと後続の処理パイプラインは、Cloud Storage サービスの再開後、ほとんどデータ損失なしで再開します。
取り込まれたデータのコピーを作成する。Cloud Storage は、マルチリージョンとデュアルリージョンの両方のロケーション タイプをサポートしています。データの地域要件によっては、マルチリージョンまたはデュアルリージョンの Cloud Storage バケットを設定してデータ可用性を高めることができる場合があります。
gsutilなどのツールを使用して、Cloud Storage と別のロケーションの間でデータを同期することもできます。
取り込まれた POS データのオーケストレーションと処理
バッチのユースケースのアーキテクチャ図では、Cloud Composer が次の手順で動作します。
- 新しいファイルが Cloud Storage 取り込みバケットにアップロードされたことを検証します。
- エフェメラル Dataproc クラスタを起動します。
- Apache Spark ジョブを開始してデータを処理します。
- ジョブの最後に Dataproc クラスタを削除します。
Cloud Composer では、これらの一連のステップを定義する有向非巡回グラフ（DAG）ファイルを使用します。これらの DAG ファイルは、アーキテクチャ図には示されていない Cloud Storage バケットに保存されます。デュアルリージョンとマルチリージョンの地域区分に関して、DAG ファイル バケットの DR に関する考慮事項は、取り込みバケットで説明したものと同じです。
Dataproc クラスタはエフェメラルです。つまり、クラスタは処理ステージが実行されている間だけ存在します。このエフェメラルな特性により、Dataproc クラスタに関して DR に対して明示的に行うことは何もありません。
Cloud Storage を使用したデータレイク ストレージ
データレイクに使用する Cloud Storage バケットには、取り込みバケットで説明したものと同じ局所性に関する考慮事項（デュアルリージョンとマルチリージョンに関する考慮事項、暗号化の使用、gsutil rsync の使用）があります。
データレイクの DR 計画の設計時は、次の点を考慮してください。
データサイズ。データレイク内のデータ量は大きくなる場合があります。大量のデータを復元するには時間がかかります。DR シナリオでは、データレイクのボリュームが次の条件を満たすポイントにデータを復元するために要する
時間に与える影響を考慮する必要があります。- アプリケーションを利用できる。
- 目標復元時間（RTO）を満たしている。
- 復元ポイント目標（RPO）の値を満たすために必要なデータ チェックポイントを取得している。
現在のバッチのユースケースの場合、Cloud Storage をデータレイクのロケーションとして使用し、イレブンナインの耐久性を提供します。しかし、ランサムウェア攻撃は増加しています。このような攻撃から確実に復旧できるように、Cloud Storage がイレブンナインの耐久性を提供する方法で概説されているベスト プラクティスを活用することを推奨します。
データの依存関係。データレイク内のデータは通常、処理パイプラインなどのデータ分析システムの他のコンポーネントによって使用されます。DR シナリオでは、処理パイプラインとそれが依存するデータは同じ RTO を共有する必要があります。この状況では、システムを利用できない時間の長さに焦点を当てます。
データの存在期間。過去のデータによって RPO が高くなる場合があります。このタイプのデータは、その他のデータ分析コンポーネントによってすでに分析または処理された場合があり、独自の DR 戦略を持つ別のコンポーネントに保持されている場合があります。たとえば、Cloud Storage にエクスポートされる販売記録は分析のために BigQuery に毎日インポートされます。BigQuery の適切な DR 戦略では、BigQuery にインポートされた過去の販売記録が、インポートされていないものよりも復元の対象としての優先度が低い場合があります。
Dataproc Metastore を使用したデータレイクのメタデータ ストレージ
Dataproc Metastore は、フルマネージドで高可用性の、自動修復型でサーバーレスの Apache Hive メタストアです。メタストアによってデータ抽象化とデータ検出の機能が提供されます。障害の場合は、メタストアをバックアップして復元できます。Dataproc Metastore サービスでは、メタデータのエクスポートとインポートもできます。ETL ジョブとともにメタストアをエクスポートして外部バックアップを維持するタスクを追加できます。
メタデータの不一致がある状況では、MSCK コマンドを使用してデータ自体からメタストアを再作成できます。
ストリーミングのユースケース: ELT を使用した変更データ キャプチャ
2 番目のユースケースでは、変更データ キャプチャ（CDC）を使用してバックエンド インベントリ システムを更新し、リアルタイムの販売指標を追跡する小売プラットフォームについて説明します。次の図は、Cloud SQL などのトランザクション データベースからのイベントが処理されてから、データ ウェアハウスに保存されるアーキテクチャを示しています。
このアーキテクチャには、次のフェーズとコンポーネントが含まれています。
- 取り込みフェーズは、Pub/Sub に push された受信変更イベントで構成されます。メッセージ配信サービスとして、Pub/Sub はストリーミング分析データを確実に取り込み、配信するために使用されます。Pub/Sub には、スケーラブルでサーバーレスであるという両方の便益があります。
- 処理フェーズでは、Dataflow を使用して、取り込まれたイベントに対して ELT プロセスが実行されます。
- データ ウェアハウス フェーズでは、BigQuery を使用して、処理されたイベントを保存します。マージ オペレーションにより、BigQuery にレコードが挿入、または更新されます。このオペレーションにより、BigQuery に保存された情報をトランザクション データベースを使用して最新に保つことができます。
この CDC アーキテクチャは Cloud Composer に依存しませんが、一部の CDC アーキテクチャでは、バッチ ワークロードへのストリームの統合をオーケストレートするために Cloud Composer が必要です。それらの場合、Cloud Composer ワークフローは、レイテンシの制約が原因でリアルタイムに行うことができない整合性チェック、バックフィル、プロジェクションを実現します。Cloud Composer の DR 手法については、このドキュメントで前述したバッチ処理のユースケースで説明します。
ストリーミング データ パイプラインの場合、DR アーキテクチャの計画時に次の点を考慮する必要があります。
- パイプラインの依存関係。処理パイプラインは、1 つ以上のシステム（ソース）からの入力を受け取ります。その後、パイプラインはこれらの入力を処理、変換して、その他のシステム（シンク）に保存します。エンドツーエンドの RTO を達成するには、DR アーキテクチャを設計することが重要です。データソースとシンクの RPO が確実に RTO を満たすようにする必要があります。地域要件を満たすようにクラウド アーキテクチャを設計することに加えて、エンドツーエンドの RTO を満たすように送信元の CDC ソースを設計する必要もあります。
- 暗号化と局所性。暗号化で地域制限を緩和できる場合、Cloud KMS を使用して次の目標を達成できます。
- 独自の暗号鍵を管理する。
- 個々のサービスの暗号化機能を活用する。
- 緩和策を講じない場合は、地域制限により使用できないリージョンにサービスをデプロイする。
- 移動中のデータに関する地域ルール。一部の地域ルールは、保存データにのみ適用され、移動中のデータには適用されない場合があります。地域ルールが移動中のデータに適用されない場合は、その他のリージョンのリソースを活用するように DR アーキテクチャを設計して、復旧の目標を改善します。暗号化方式の統合によって、リージョン アプローチを補完できます。
Pub/Sub への取り込み
地域制限がない場合、グローバル Pub/Sub エンドポイントにメッセージを公開できます。グローバル Pub/Sub エンドポイントは、Google Cloud のすべてのロケーションに表示され、アクセスできます。
地域要件で暗号化の使用が許可されている場合は、グローバル エンドポイントと同等のレベルの高可用性を実現するように Pub/Sub を構成できます。Pub/Sub メッセージはデフォルトで Google 管理の鍵によって暗号化されますが、代わりに CMEK を使用するように Pub/Sub を構成できます。CMEK で Pub/Sub を使用すると、高可用性を維持しながら暗号化に関する地域ルールを満たすことができます。
一部の地域ルールでは、メッセージが暗号化後も特定のロケーションに留まることが求められます。地域ルールにこの制限がある場合、Pub/Sub トピックのメッセージ ストレージ ポリシーを指定し、それをリージョンに制限できます。このメッセージ ストレージ アプローチを使用すると、トピックに公開されるメッセージが、指定した一連の Google Cloud リージョン以外で保持されることは決してありません。地域ルールで複数の Google Cloud リージョンを使用できる場合は、Pub/Sub トピックでこれらのリージョンを有効にすることで、サービスの可用性を向上できます。Pub/Sub リソースのロケーションを制限するメッセージ ストレージ ポリシーの実装には、可用性に関するトレードオフが伴うことを認識する必要があります。
Pub/Sub サブスクリプションでは、確認応答されていないメッセージを最大 7 日間、メッセージ数に制限なく保存できます。サービスレベル契約で遅延データが許可されている場合、パイプラインの実行が停止すると、Pub/Sub サブスクリプションにデータをバッファリングできます。パイプラインが再び実行されると、バックアップされたイベントを処理できます。この設計には、RPO を低くするというメリットがあります。Pub/Sub のリソース上限の詳細については、Pub/Sub 割り当てのリソース上限をご覧ください。
Dataflow によるイベント処理
Dataflow は、さまざまなデータ処理パターンの実行に対応したマネージド サービスです。Apache Beam SDK は、バッチとストリーミングの両方のパイプラインの開発に対応したオープンソースのプログラミング モデルです。Apache Beam プログラムでパイプラインを作成し、Dataflow サービスで実行します。
地域制限の設計時は、ソース、シンク、一時ファイルのロケーションを考慮する必要があります。これらのファイルの場所がジョブのリージョン外にある場合、データがリージョンを越えて送信される可能性があります。地域ルールでデータを別のロケーションで処理できる場合は、他の Google Cloud リージョンにワーカーをデプロイするように DR アーキテクチャを設計して、高可用性を提供します。
地域制限によって処理が単一ロケーションに制限される場合は、特定のリージョンまたはゾーンに制限される Dataflow ジョブを作成できます。Dataflow ジョブを送信する際に、リージョン エンドポイント、ワーカー リージョン、ワーカーゾーンのパラメータを指定できます。これらのパラメータは、ワーカーのデプロイ先とジョブ メタデータの保存場所を制御します。
Apache Beam は、さまざまなランナーにわたってパイプラインを実行できるフレームワークを提供します。DR アーキテクチャを設計して、この機能を活用できます。たとえば、Apache Spark Runner を使用して、ローカルのオンプレミス Spark クラスタで実行されるバックアップ パイプラインを持つ DR アーキテクチャを設計できます。特定のランナーが特定のパイプライン オペレーションを実行できるかどうかを確認するには、Beam 機能マトリックスをご覧ください。
暗号化により地域制限を軽減できる場合、Dataflow の CMEK を使用して、パイプライン状態アーティファクトの暗号化と Cloud KMS 鍵で保護されているソースとシンクへのアクセスの両方を行うことができます。暗号化を使用すると、地域制限により利用できなかったリージョンを使用する DR アーキテクチャを設計できます。
BigQuery 上に構築されたデータ ウェアハウス
データ ウェアハウスは分析と意思決定をサポートします。データ ウェアハウスには、分析データベースに加えて、複数の分析コンポーネントとプロシージャが含まれています。
データ ウェアハウスの DR 計画の設計時は、次の特性を考慮してください。
サイズ。データ ウェアハウスは、オンライン トランザクション処理（OLTP）システムよりもはるかに大規模です。データ ウェアハウスにテラバイト規模からペタバイト規模のデータがあることは珍しくありません。RPO と RTO の値を達成するためには、このデータの復元にかかる時間を考慮する必要があります。DR 戦略の立案時には、テラバイト規模のデータの復元に関わる費用も考慮する必要があります。BigQuery の DR 軽減手法の詳細については、Google Cloud 上のマネージド データベース サービスのバックアップと復元のメカニズムに関する BigQuery の情報をご覧ください。
可用性。BigQuery データセットを作成するときに、データを保存するロケーションをリージョンまたはマルチリージョンから選択します。リージョン ロケーションは、アイオワ州（
us-central1）やモントリオール（northamerica-northeast1）などの単一の特定の地理的な場所です。マルチリージョン ロケーションは、米国（US）やヨーロッパ（EU）などの 2 つ以上の地理的な場所を含む広い地理的なエリアです。地域制限を満たすように DR 計画を設計すると、障害発生ドメイン（すなわち、マシンレベル、ゾーン、またはリージョンで障害が発生したかどうか）が、定義された RTO を満たすことに直接的な影響をもたらします。これらの障害発生ドメインとそれがどう可用性に影響するかについては、BigQuery の可用性と耐久性をご覧ください。
データの性質。データ ウェアハウスには履歴情報が含まれ、多くの場合、古いデータの大半が静的です。多くのデータ ウェアハウスは、追記専用として設計されています。データ ウェアハウスが追記専用の場合、追加するデータのみを復元することで RTO を達成できる場合があります。この方法では、この追加されたデータのみをバックアップします。障害が発生した場合は、追加されたデータを復元し、データ ウェアハウスを使用できるようにしますが、使用するのはデータのサブセットのみです。
データの追加と更新のパターン。データ ウェアハウスは通常、ETL または ELT のパターンを使用して更新します。更新パスを制御していた場合は、代替ソースから最近の更新イベントを再現できます。
地域要件によって、データ ウェアハウスに単一リージョンと複数リージョンのどちらを使用できるかが制限される場合があります。BigQuery データセットはリージョンのものですが、マルチリージョン ストレージは、障害が発生した場合にデータの可用性を確保するための最も簡単で費用対効果の高い方法です。マルチリージョン ストレージがリージョンで使用できないが、別のリージョンで使用できる場合は、BigQuery Data Transfer Service を使用してデータセットを別のリージョンにコピーします。暗号化を使用して地域要件を緩和できる場合は、Cloud KMS と BigQuery を使用して独自の暗号鍵を管理できます。
1 つのリージョンだけ使用できる場合は、BigQuery テーブルのバックアップを検討してください。テーブルをバックアップする最も費用対効果の高いソリューションは、BigQuery Export を使用することです。Cloud Scheduler または Cloud Composer を使用して、Cloud Storage に書き込むエクスポート ジョブを定期的にスケジューリングします。SNAPPY 圧縮を使用した Avro や GZIP 圧縮を使用した JSON などの形式を使用できます。エクスポート戦略を設計する際は、エクスポートの制限に留意してください。
BigQuery のバックアップを Parquet や ORC などのカラム型で保存することもできます。これらは高い圧縮率を実現するとともに、オンプレミス システムに使用される Hive や Presto などの多くのオープンソース エンジンとの相互運用性も提供します。次の図は、BigQuery データをオンプレミス ロケーションに保存するために、カラム型でエクスポートするプロセスの概要を示しています。
BigQuery データをオンプレミスのストレージ ロケーションにエクスポートするこのプロセスには、具体的に次のステップが含まれます。
- BigQuery データは Dataproc の Apache Spark ジョブに送信されます。Apache Spark ジョブを使用すると、スキーマ進化が可能になります。
- Dataproc ジョブが BigQuery ファイルを処理すると、処理されたファイルが Cloud Storage に書き込まれてから、オンプレミスの DR ロケーションに転送されます。
- Cloud Interconnect は、Virtual Private Cloud ネットワークをオンプレミス ネットワークに接続する目的で使用されます。
- オンプレミスの DR ロケーションへの転送は、Spark ジョブを通じて行うことができます。
ウェアハウスの設計が追記専用であり、日付でパーティション分割されている場合は、新しいテーブルで BigQuery Export ジョブを実行する前に、新しいテーブルに必要なパーティションのコピーを作成する必要があります。gsutil などのツールを使用して、更新されたファイルをオンプレミスまたは別のクラウドのバックアップ ロケーションに転送できます（Google Cloud からデータを転送する場合は、下り（外向き）料金が発生する可能性があります）。
たとえば、追記専用の orders テーブルで構成される販売データ ウェアハウスがあると、そこでは現在の日付を表すパーティションに新しい注文が追加されます。ただし、返品に関するポリシーにより、商品を 7 日以内に返却できる場合があります。したがって、過去 7 日以内の orders テーブルのレコードが更新される場合があります。エクスポート戦略では、返却に関するポリシーを考慮する必要があります。この例では、orders テーブルをバックアップするあらゆるエクスポート ジョブで、過去 7 日以内の注文を表すパーティションをエクスポートすることで、返却によって更新が失われることを避ける必要もあります。
次のステップ
- この DR シリーズの他の記事を読む。
- ホワイトペーパーを読む: Google Cloud のヨーロッパのお客様向けデータ所在地、運用の透明性、プライバシーをご覧ください。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。