ソリューション デザインパターン とは

ソリューション デザインパターンでは、 ワークロードごとに Google Cloud のアーキテクチャを 2 つの観点でまとめています。 1 つ目は、様々な業界で利用できる共通のソリューション デザインパターンとして「エンタープライズ向けの組織、 IAM、請求管理」、「インフラストラクチャとマイグレーション」、「アプリケーションおよびデータベースのモダナイゼーション」などを用意しています。

2 つ目は、ゲーム業界や小売業といった、業界ごとのワークロードに適したデザイン パターンです。

皆様が Google Cloud を活用するときのガイドブックとしてご活用ください。 

カテゴリー別ソリューション一覧

共通ソリューション

〉エンタープライズ組織の基本

〉インフラストラクチャ / データベース / ネットワーク

〉Google Cloud での SAP

〉アプリケーションおよびデータベースのモダナイゼーション

〉データ プラットフォーム（分析 / AI）

業界別ソリューション

〉ゲーム

〉流通・小売

〉医療、ライフ サイエンス

〉公共機関

エンタープライズのお客様が Google Cloud を利用する際の組織、IAM、課金に関する設計については様々なパターンが考えられますが、今回は下記のような要件を抱えたペルソナ企業を想定した組織、IAM、課金の設計例を紹介します。 このパターンを参考に適切な制約を設定することで、エンタープライズでのご利用に適した、IAM 権限・課金管理などを実現できます。

このパターンを用いて適切な制約を設定することで、よりセキュアに、かつリソース管理の運用負荷を抑えて Google Cloud をご活用頂くことができます。 まず、適切な組織・フォルダ構成と権限付与を実現する考え方についてご説明し、フォルダ構成を決定する上で必要となる観点についてご説明します。 フォルダ構成を決定する上で必要となる観点とはすなわち、リソースの制御や権限管理が該当します。

• 適切な組織・フォルダ構成と権限付与を実現する

組織のポリシーを用いて実現できる制限の一例は下記になります。これらは、フォルダ構成を決定する上で必要となる観点となります。  

• 利用できるリージョンを制限する 許可される
• Google Cloud API とサービスを制限する
• Cloud IAM ポリシーに追加できる一連のメンバーを制限する

デザイン パターン詳細

• リージョンを制限する
• API ・サービスを制限する
• Cloud IAM のメンバーを制限する

関連デザイン パターンにおいては、共通のペルソナ企業の要件を元に記述しています。

【前提：ペルソナ企業の抱える要件】 

• 組織のポリシー・IAM 権限 
  • Google Cloud の主管チームがあり、Google Cloud を利用したい部署は主管チームにプロジェクトとユーザーを払い出す申請を行う手続きとなっている
  • 大半がユーザーについて国内からの利用が見込まれることと法制度上の観点から、国内リージョンのリソースのみを利用することが好ましい
  • 利用者は自部署のサービスについての権限のみを持つことができ、他部署の管轄するサービスについては、いかなる権限も持たせたくない
  • 本番、開発、評価、Sandbox 環境を作りたい
  • Cloud IAM ポリシーに追加できる一連のメンバーを制限したい
  • 期間・時間限定でアクセスを許可したいユースケースがある

これらの前提となる要件を元に、事前定義ロールの果たす役割について説明して参ります。

デザイン パターン詳細 

• 事前定義ロールを使用する

関連デザイン パターンにおいては、共通のペルソナ企業の要件を元に記述しています。

【前提：ペルソナ企業の抱える要件】

• 組織のポリシー・IAM 権限
  • Google Cloud の主管チームがあり、Google Cloud を利用したい部署は主管チームにプロジェクトとユーザーを払い出す申請を行う手続きとなっている 
  • 大半がユーザーについて国内からの利用が見込まれることと法制度上の観点から、国内リージョンのリソースのみを利用することが好ましい 
  • 利用者は自部署のサービスについての権限のみを持つことができ、他部署の管轄するサービスについては、いかなる権限も持たせたくない 
  • 本番、開発、評価、Sandbox 環境を作りたい
  • Cloud IAM ポリシーに追加できる一連のメンバーを制限したい
  • 期間・時間限定でアクセスを許可したいユースケースがある 

これらの前提となる要件を元に、具体的に求められる要件をベースとして、 IAM Conditions の利用モデルについて説明して参ります。

デザイン パターン詳細

• IAM Conditions を用いた条件付き権限付与 

本節では Google Cloud リソースを扱うために必要な課金の設定について記述します。 Google Cloud は階層型のリソース構造を構成することが出来、大きく、組織、フォルダ、プロジェクト、リソースがあることを前節で説明しました。具体的には、Google Cloud の中で作成する組織と呼ばれるルートノードの配下にプロジェクトを作成し、そのプロジェクトの中で作成したコンピュート リソースやオブジェクト ストレージ等のリソースがプロジェクトに紐づく形になります。一方、課金の概念はそれとは若干違い、組織の中で別に用意する請求先アカウントというリソースに対してプロジェクトを紐付けることで、プロジェクト内で作成されたリソースに対する支払いを実現します。

デザイン パターン詳細

• 請求情報へのアクセスを制限する
• 毎月の請求費用を BigQuery を用いて分析する

コンピュート リソースや、ストレージ、データベース、ネットワークのパターンを解説します。それぞれ、ワークロードに合わせて、適切なアーキテクチャ、プロダクトを組み合わせることで Google Cloud の技術を最大限に活用することができます。

ウェブサイトは最も基本的なシステム構成例として取り上げられることが多いですが、その構成は要件やワークロードによって異なる、大変奥深いものです。

求められる要件の例としては可用性、性能 / 拡張性、コスト パフォーマンス、アジリティなどが代表例ですが、これらのうち、何を重視するかによって、コンピュート、ストレージ、ネットワークといった各構成要素の適切なアーキテクチャを検討する必要があります。Google Cloud ではこれら要件を満たすためのソリューションをいくつか提供しています。これらを適切に採用し、各ワークロードに適した要件を実現することが重要となります。

コンピュートについては、Compute Engine、App Engine、Google Kubernetes Engine、Cloud Funtions、Firebase Hosting など多様な選択肢があり、非機能要件や、現行システムからの移行を考慮する場合は、移行難易度等も考慮して適切なオプションを選択する必要があります。

また、ストレージについても、保存するデータ形式やストレージ アクセスに求められるパフォーマンス等に応じて適切なオプションの選択が必要となります。 その他、データベース、ネットワークなどの要素についても同様に、ワークロード特性や求められる要件に応じて組み合わせは複数存在するため、ここではその全てを述べることは難しいですが、下記ドキュメントにて、それらサービス群の概要を整理しています。

デザイン パターン詳細

• Dynamic site hosting パターン
• キャッシュを活用したウェブホスティング

ほとんどのワークロードで可用性を考慮した設計は重要ですが、求められる要件はワークロードによって異なるため、ワークロードのアーキテクチャを考える上で、そのワークロードがどのレベルの可用性を実現する必要があるかを考えることが重要となります。Google Cloud では可用性を高めるためのソリューションをいくつか提供しており、これらを適切に採用し、各ワークロードに適した構成を選択すること可能です。 本節では自然災害によるリージョンやゾーン障害などを前提にした高可用性設計について、 Compute Engine などによるアプリケーション サーバと DB を組み合わせた一般的な ウェブサービスのワークロードを想定したアーキテクチャについて解説します。また、 Google Cloud の各ソリューションの網羅的な高可用性構成の解説については対象外のため、必要に応じてそれぞれのソリューションのドキュメントを参照ください。

本節では、アプリケーションのマイグレーション パターンについて解説をしていきます。なお、ここではコンテナライズされたアプリケーションではなく、物理サーバや VM の環境に構築された、比較的レガシーなアプリケーションをマイグレーションする前提で記載します。

デザイン パターン詳細

• 仮想マシンの Google Compute Engine（GCE）への移行

本節では、データのマイグレーション パターンについて解説します。他の環境から Google Cloud へ移行する場合、どのような方法でデータを持ってくるのかは、重要な事項です。移行要件に応じて、どのような方法を選択できるのかを整理する必要があります。ここでは、データの特性や保管するデータベース、ストレージの種類に応じたマイグレーション パターンを記載します。   

デザイン パターン詳細

• RDBMS データ マイグレーション パターン

デザイン パターン詳細

• 共有 VPC（Shared VPC）

システムを安定運用させるためには、現状のシステム状態を素早く正しく把握し、適切なアクションにつなげるための監視プロセスが必要不可欠です。Google Cloud では安定したシステム運用をサポートするための監視ソリューションがいくつか提供されています。これらを適切に選択し、各ワークロードに適したサービスレベルを維持することが重要となります。

デザイン パターン詳細

• 監視 パターン

本章では SAP システムを Google Cloud 上に構築するパターンを解説します。基幹系業務システムの中核となるケースが多 い SAP システム。導入する場合には、導入企業固有の信頼性や可用性についての要件があります。本デザイン パターン では、そういった要件を満たすために SAP システム を Google Cloud 上で如何に構築していくかについて解説します。

SAP システムを高い可用性で運用保持していくためには、単一障害ポイントの排除はデータベースのレプリケーションといった対策を行う必要があります。本節では、SAP システムを Google Cloud 上で構築する際に、どのような高可用性対策を行うべきかについて解説します。 

デザイン パターン詳細

• Google Google Cloud での SAP HANA の高可用性構成
• SAP HANA マルチ リージョン での システム レプリケーション 

SAP などの基幹システムのクラウド移行は、他のシステムの移行と比べてチャレンジングな作業になることが多くあります。それは、データサイズの大きさや、システムの複雑性、許容されるダウンタイムが短いことや、複数のチームを跨いだ検証が必要、など多くの事象に起因します。本節では、SAP システムの移行について解説をします。 

デザイン パターン詳細

• オンプレミスから Google Cloud への移行

多くの企業は、オンプレミス環境においてモノリシック アーキテクチャを使用してカスタム ソフトウェア サービスを構築しています。新しい変化に適用するために、機能追加や変更を加えていくと、アプリケーションがより複雑になってしまい、費用と時間がかかる上に、展開にはリスクも伴ってきます。 こうした課題を解決するには、コンテナベースのアプリケーション サービスとクラウド ネイティブのデータベースを合わせて利用することが有効です。アプリケーションに高い俊敏性、スケーラビリティ及び可用性など様々なメリットがあり、次の環境変化への適応性を高めることができます。 Google Cloud が提供するいくつかのマネージド サービスは、コンテナベース アプリケーションとスケール可能なデータベースの両方が含まれています。ここでは、クラウド ネイティブの組み合わせと全体構成についての詳細とユースケース、システム要件に合わせた最適なデザイン パターンと、本番におけるベスト プラクティスを紹介します。 

デザイン パターン詳細

• Cloud Run + Cloud Firestore

Google Cloud は「お客様が選択できること」を重視したサービス展開をしてきましたが、ハイブリッド / マルチクラウドの文脈においても、つまりオンプレミスや他社クラウドでも Google のソリューションがご選択いただけるよう、様々なソリューションを展開しています。

この節ではハイブリッド クラウドやマルチクラウドを、より効果的に実現するための手法をご案内します。特性が異なるアプリケーションとデータベースに対し、それぞれパターンごとに考慮点やベスト プラクティスをみていきましょう。

デザイン パターン詳細

• GKE + GKE On-Prem
• Cloud SQL とオンプレミス環境のデータベース同期

DevOps の考えにもあるように、開発とデプロイのサイクルを高速に、かつ継続的に回すことは、ビジネスを成功させる上で重要なポイントの 1 つとされています。

このサイクルを自動化するために、CI（Continuous Integration）と CD（Continuous Delivery）を構築します。CI と CD の構築方法は、Google Cloud のマネージドな環境の利用、サードパーティーのツール群を利用、または OSS を利用するなど多数存在します。 

デザイン パターン詳細

• Google Cloud での CI / CD 

Google Cloud のデータ プラットフォームにおける主要な構成要素は以下の通りです。

• データレイク
• データウェアハウス
• データパイプライン
• Enterprise BI

本稿では、上記の構成要素に関するデザイン パターンおよび、データ プラットフォームのユースケースから以下に該当するデザイン パターンを紹介します。（一部執筆中）

• Stream Analytics（リアルタイムデータの収集と活用）
• Marketing Analytics（マーケティング観点でのデータ収集・活用事例） 

ここで紹介するデザイン パターンを用いることで、データ ウェアハウスを安全に、妥当なコストで、そしてより高いパフォーマンスで運用することができます。 また、SQL を用いた機械学習モデルの構築や位置情報システム（GIS）データの活用など、Google Cloud のデータ ウェアハウスならではの活用方法も紹介します。

デザイン パターン詳細

• データ ウェアハウス をクラウド上でセキュアに（IP 制限、専用線等）構築するパターン
• BigQuery Reservations によるワークロード管理

データ パイプラインとは、一連の連続した処理ステップによってデータを処理するアプリケーションで、システム間のデータ転送、ETL と呼ばれる抽出 (Extract)、変換 (Transform)、読み込み (Load) 処理、データ拡充やリアルタイムのデータ分析処理等に適用されるコンセプトです。

Google Cloud は、データ パイプラインを構築するマネージド サービスとして、Cloud Dataflow と Cloud Data Fusion を提供しています。Cloud Dataflowは、OSS の Apache Beam SDK を利用して開発したパイプラインを実行するフル マネージドのデータ処理サービスです。Cloud Data Fusion は、OSS の CDAP のマネージド サービスで、組み込みのコネクタや GUI を用いてデータ パイプラインを構築することができます。   

デザイン パターン詳細

• アプリケーションおよびウェブデータをデータ ウェアハウス に収集するパターン（ Firebase 向け Google アナリティクス ）

MMORPG に代表されるオンラインをメインとしたゲームだけでなく、近年ではスマートフォン向けゲームやコンソール向けゲームにおいてもネットワーク インフラの活用が進んでいます。

複数のプレイヤー動作を連携させるといったゲーム性に直接関わるものから、ユーザー管理、フレンド機能、セーブデータの保存などゲームのバックエンド機能としての利用や、ユーザーの行動分析、さらには分散ビルドやアセットの保存などゲームの開発環境まで、多くの場面でネットワーク インフラが利用されています。

プラネット スケールで低レイテンシーな Google のネットワーク、高速に起動しライブ マイグレーション機能を持つ仮想サーバーの Compute Engine、1 PB のデータも数十秒で処理可能な DWH の BigQuery、水平方向にスケール可能なリレーショナル データベースの Cloud Spanner など Google Cloud ではゲームのワークロードに対して非常に親和性の高い特徴を持ったサービスを提供しています。

また、専用ゲームサーバーをホスティングする Agones や マッチメイキング フレームワークの Open Match などゲーム専用の OSS を立ち上げ、開発を進めています。

本章では API サーバーやデータ分析などいくつかのゲーム ワークロードを例に、Google Cloud で構築する際のパターンを解説します。

多くのクライアント / サーバー型のゲーム アーキテクチャは、高度なゲーム機能を提供するサーバーのインターフェースとなる API サーバーと、プレイヤーのゲームデータを記録するデータベース サーバーによって構成されます。

ゲームにおける API + データベース サーバーを構成する際の考慮事項として、予想されるワークロードだけでなく、予期しないトラフィックの急増に対するスケーラビリティについても検討すべき点があげられます。

デザイン パターン詳細

• Google Kubernetes Engine + Cloud Spanner パターン

ゲーム アーキテクチャはインターネットに接続しクライアントからサーバーに接続することを前提とした作りになってなっているものが多くあります。このため、ゲームの状況を分析し、継続的に改善を行うことは、ゲームを運営する上で重要な要素となってきています。ゲーム クライアントのログやサーバー処理のログを収集し、集約、分析することでその結果を用いて、ゲームの改善などにフィードバックさせることができるようになります。

何を分析するかについては、例えば以下のようなユースケースが考えられます。

• 離脱ユーザーの予測
• ゲーム内アイテムなどのレコメンド
• ユーザー セグメンテーションによる広告配信の最適化
• ゲームプレイ履歴による悪質な行動を取っているユーザーの検知

これらの分析をすることでユーザーの体験を向上させる施策につなげたり、売上につなげるような施策を検討して実施することができるようになります。

デザイン パターン詳細

• モバイルゲーム分析プラットフォームの作成

FPS（First person shooter）や MMO（Massively Multiplayer Online）など、オンライン マルチプレイを提供する際には、プレイヤーのステートを管理するための DGS（Dedicated Game Server ）が必要です。

通常 DGS は、インターネット上のどこかでホストされ、プレーヤー間のゲームの状態を同期します。DGS において、中央集権的にサーバーでゲームの処理をすることで、ユーザーの不正行為を防ぐことができます。また、DGS をスケールアウトすることで、同時に接続するユーザー数を増やすことができます。そのため、オンライン マルチプレイ ゲームを開発する際に有効な構築パターンの 1 つといえます。

• GKE + Agones を用いた DGS 構築のパターン 

小売インダストリーにおけるシステム構築のパターンを解説します。本デザイン パターンでは、店舗を運営しており、E コマースサイトも運営しており、自社製品開発を行っていない典型的な小売企業のシステムを想定しています。ハイレベルな全体像としては下図のようなシステム群を想定しています。

E コマースサイトは顧客との重要なタッチポイントです。顧客体験（カスタマー エクスペリエンス: CX）を高めるためには、商品検索や商品詳細などを軽快に動作させることで、スムーズな購買体験ができるようにします。そのためには、レスポンス タイムを可能な限り少なくするなどのパフォーマンスが求められます。

E コマースサイトはアクセス数が急激に増加することに配慮する必要があります。例えば人気商品の発売、テレビ番組や CM での紹介、SNS 上での話題性など、予測し切れない場合も含まれます。そのため静的コンテンツやキャッシュの活用、スケーラビリティのあるデータベースの選択などが必要です。.

また顧客属性に合わせた商品のリコメンドやクーポンの配信を行うことで、コンバージョン率を高めることができます。そのためマーケティング アナリティクスや CRM（Customer Relationship Management: 顧客関係管理）との関連度が高い領域となります。E コマースサイトからユーザーデータやユーザー行動データを Firebase と Google アナリティクス を利用して取得し、ユーザーごとのデータをベースとしたセグメントの作成、または機械学習を活用した予測結果を適用するなどといったアクションを実施します。

商品データの文脈では、E コマースサイトでカートに入れられた商品の在庫を確保するため、店舗ごとの在庫情報のリアルタイム性が求められます。在庫管理システムとのシームレスな連携を行うことで、顧客が確実に商品を購入できるような購買体験の提供を目指します。

デザイン パターン詳細

• クラウドとのハイブリット環境を使って可用性が高くスケーラブルな E コマース サイトを構築するパターン
• E コマースサイトのホスティングのパターン 

小売企業が取り扱うデータには、店舗などのリアルな世界から得られるデータと、E コマースなどのデジタルな世界から得られるデータの2種類があります。これらの 2 種類のデータと、本部で保有する商品や店舗などに関するマスタデータをかけ合わせることで、リアルとデジタルを横断した統一的なデータ基盤を構築することができます。また、データ基盤に蓄えられたデータをAPIを通じて提供することで、レポーティングや BI によるデータ分析をはじめとして、社内の新規サービスや、社外とのデータ連携などデータの活用シーンが広がり、効果的な打ち手を必要なタイミングで実施することができるようになります。

デザイン パターン詳細

• 店舗システムとクラウド環境の閉域網接続のパターン
• E コマースやアプリ情報の BigQuery へのデータ集約のパターン
• データパイプライン構築による活用目的別データマート作成のパターン
• Dynamic Pricing を実現するデータ活用パターン
• BigQuery に蓄積したデータ活用のパターン
• API による外部システムとのデータ連携パターン 

真の DX を通じて、わくわくする未来のリテーラーへと変革するために、Google Cloud は 8 つの経営テーマを解決する小売業向けソリューションを提供します。

[ 本社編 ]
1 - データドリブンによるビジネス変革
2 - コスト構造の再編成による新たな経営基盤
3 - バックエンドのデジタルシフト

[ 店舗編 ]
4 - 次世代デジタル サービスの店舗導入
5- AI / 機械学習テクノロジーの店舗活用

[ 顧客編 ]
6 - デジタル活用で顧客への真の価値提供
7 - 顧客起点発想の商品開発

[ 物流（倉庫）編 ]
8 - エンド ツー エンドの デジタル サプライ チェーン  

医療のパラダイムを進化させ、研究の柔軟な拡大を推進しながら、組織内の誰もがイノベーションと変革を支援する Google Cloud の医療とライフ サイエンス業界向けソリューションのデザイン パターンをご紹介します。

医療とヘルスケアの組織は、依然としてセキュリティ、プライバシー、法令遵守義務への対応を余儀なくされています。このような組織がそのアプリケーションを確実かつ適切に管理できるようにするため、現在、Google では最近公開したソリューション ガイドやホワイトペーパーなどの各種アセットを重点的に紹介しています。

デザイン パターン詳細

• Google Cloud のセキュリティ
• セキュリティのベスト プラクティス
• コンプライアンスとホワイトペーパー
• ソリューション ガイド 

ヘルスケア プロバイダが取り扱う医療データには、CT・MRI・内視鏡・超音波などのデジタル画像データや被診察者の診療データがあり、独自のデータ フォーマットで、データの交換や管理が行われています。また、機微な情報を取り扱うケースも多く、データの取り扱いに注意する必要があります。 これらのデータを安全に統合管理し、分析・活用を可能とするデータ基盤を構築することで、患者の容態把握や将来の疾患発症予測をはじめとした、新たな価値提供を目指す第一歩となります。

デザイン パターン詳細

• 医療分析プラットフォーム
• 同意管理プラットフォーム

Google Cloud のソリューションによって、ライフ サイエンス コミュニティは大規模な生物医学データの処理が可能になります。費用対効果に優れ、拡大するパートナー エコシステムによってサポートされた Cloud Life Sciences では、データの解析と結果の再現に専念でき、後は Google Cloud に任せることができます。

デザイン パターン詳細

• ゲノム データの変異解析（二次解析）
• ゲノム データの変異解析(三次解析)
• HPC (High Performance Computing) を使ったゲノム データ解析
• Hail を使ったゲノム データ解析

本ドキュメントは公共機関のお客様が Google Cloud 上に Infrastructure as a Service（IaaS）ベースのシステムを構築する際、信頼性を確保するために参考となるガイドラインおよび自動化のためのテンプレートを提供することを目的としています。 公共機関におけるシステムは高い信頼性が求められます。このドキュメントでは信頼性を確保するためにどのようなアーキテクチャを設計するか、使用するサービスはどの様に構成するかのガイドラインを提供するとともに、ベスト プラクティス ベースのクラウド サービスの作成にあたり、自動化のためのテンプレートを提供することによって、生産性の向上と属人的なミスの軽減に貢献します。

一般の利用者向けにインターネット経由でサービスを提供するウェブ アプリケーションを例に、リファレンス アーキテクチャを図示します。

本アーキテクチャで使用しているクラウド サービスと設計のポイントを、下記で解説します。

デザイン パターン詳細

• Google Compute Engine
• ストレージ
• Virtual Private Cloud（VPC）
• ファイアウォール ルール 
• Cloud Load Balancing
• Cloud Interconnect
• Cloud NAT 
• Cloud IAM
• Cloud Operations）
• Config Connector 

責任共有モデルに基づき、クラウド事業者の責任の範囲について、どのようにセキュリティが確保されているかを理解することは重要です。

デザイン パターン詳細

• Google Cloud のセキュリティ
• Google Cloud のコンプライアンス
• アクセス制御
• 監査証跡
• Google Cloud セキュリティ サービス 

ミッション クリティカルなシステムの稼働時間を維持するには、障害や予期しない負荷の変化にも対応できる、復元性の高いアプリケーションを設計する必要があります。高可用性とは、システム内のコンポーネントに障害が発生しても機能し続けるアプリケーションの能力を意味します。高可用性のアーキテクチャでは、通常コンピューティング リソースを分散し、負荷分散やデータのレプリケーションが行われています。

デザイン パターン詳細

• Google Cloud のリージョン
• Compute Engine の計画メンテナンス 

大地震のような大規模な自然災害が発生した場合、 1 つのリージョンのすべてのゾーンで障害が発生する可能性があります。 このような広域災害が発生した場合に備えて、一般的には事業継続計画（BCP : Business Continuity Plan）と呼ばれるシステムの復旧計画についても立案する必要があります。 システムの性質によっては、災害時にすぐに必要とせず、メイン リージョンの復旧を待つことができるものもあります。災害時における全体的な優先度や、スタンバイ システムにかかる維持コストを考慮して、必要性を検討することが重要です。 

システムの安定化とセキュリティの確保のためには、システムの運用監視が重要です。ここでは、アプリケーションだけでなく、クラウドプロバイダー側で発生した問題をいち早く把握する方法を理解することも必要になります。

デザイン パターン詳細

• Google Cloud サービスの状況把握
• システムの監視