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

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

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

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

image-placeholder

ソリューション デザインパターンで紹介する内容です。

  • 概要
  • 解決する問題
  • Google Cloud アーキテクチャ
  • 機能要件 / 非機能要件
  • メリット
  • 注意事項
  • 推奨設定
  • 事例
  • 参照ドキュメント

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

devision

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

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

適切な組織、フォルダ構成と権限付与

image_placeholder

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

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

組織のポリシー設定

image_placeholder

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

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

デザイン パターン詳細

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

事前定義ロールの使用

image_placeholder

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

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

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

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

デザイン パターン詳細 

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

IAM Conditions の使用

image_placeholder

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

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

 

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

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

デザイン パターン詳細

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

請求アカウントの管理

image_placeholder

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

デザイン パターン詳細

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

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

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

ウェブサイトホスティング パターン

image_placeholder

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

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

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

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

デザイン パターン詳細

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

高可用性を確保する為のデザイン パターン

image_placeholder

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

アプリケーションマイグレーション パターン

image_placeholder

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

デザイン パターン詳細

  • 仮想マシンの Google Compute Engine(GCE)への移行

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

image_placeholder

デザイン パターン詳細

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

ネットワーク

image_placeholder

デザイン パターン詳細

  • 共有 VPC(Shared VPC)

メンテナンス

image_placeholder

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

 

デザイン パターン詳細

  • 監視 パターン
horizontalline

Google Cloud での SAP

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

高可用性構成

image_placeholder

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

デザイン パターン詳細

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

移行パターン

image_placeholder

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

デザイン パターン詳細

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

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

クラウドネイティブ アプリケーション

image_placeholder

デザイン パターン詳細

  • Cloud Run + Cloud Firestore

ハイブリッド クラウドとマルチクラウド

image_placeholder

デザイン パターン詳細

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

DevOps、アジャイル開発の為の CI/CD パイプライン

image_placeholder

デザイン パターン詳細

  • Google Cloud での CI / CD 
horizontalline

データ プラットフォーム(分析 / AI)

データ ウェアハウス

image_placeholder

デザイン パターン詳細

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

データ パイプライン

image_placeholder

デザイン パターン詳細

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

ゲーム業界

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

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

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

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

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

ゲーム関連 API + データベース サーバーの構築パターン

image_placeholder

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

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

デザイン パターン詳細

  • Google Kubernetes Engine + Cloud Spanner パターン

 

ゲームに関するデータ分析のパターン

image_placeholder

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

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

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

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

デザイン パターン詳細

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

 

horizontalline

流通・小売業界

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

E コマースサイト構築のパターン

image_placeholder

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

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

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

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

デザイン パターン詳細

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

店舗と本部をつなぐ全社横断データ基盤構築のパターン

image_placeholder

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

 

デザイン パターン詳細

  • 店舗システムとクラウド環境の閉域網接続のパターン
  • E コマースやアプリ情報の BigQuery へのデータ集約のパターン
  • エンタープライズ データウェアハウスとして BigQuery を活用するパターン
  • レポーティング、BI によるデータ活用のパターン
  • API による外部システムとのデータ連携パターン