[ GCP ] アーキテクト構成例を色々集めてみる(1)

[ GCP ] アーキテクト構成例を色々集めてみる(1)

こんばんは、七色メガネです。

小生はGCP関連のお仕事をしているのですが、まだいまいちアーキテクトを意識する機会に恵まれず、GCPの全容に対する理解が甘いなあと常々思っていました。

ので今回は、GCPのアーキテクトの構成図を集めて、俯瞰して、勉強してみたいと思います。

収集対象は、主にGoogleCloudPlatform公式ホームページでの紹介事例と、あとはネットで公開されているアーキテクト図をメインとし、適宜その他の公開資料を織り交ぜるものとします。

アーキテクト構成例

ユーザからアップロードされた画像や動画をフィルタリングする

用途

ユーザからアップロードされた画像や動画が、不適切なコンテンツであるかどうかの判定を行うなど

構成

Cloud Strage

スケーラブルなデータストレージ。バケット(CloudStrageにおけるコンテンツの具体的な保存場所)のイベントをキャッチしメッセージを送信することができるため、後続処理へのトリガーとして利用できる。

Cloud Pub/Sub

スケーラブルなメッセージングサービス。Cloud Strage がファイルのアップロードを検知し作成された通知メッセージは Pub/Sub トピックに届く。トピックへのメッセージ到達がトリガーとなり、Cloud Functions が呼び出される。

Cloud Functions

軽量のサーバレスアプリケーション。該当の Pub/Sub にメッセージが配信されることをトリガーとして次の処理を呼び出す。今回はアップロードされたコンテンツの内容に応じて、動画処理または画像処理のAPIをコールする。

Video Intelligence API

GCPで提供される動画処理AIのAPI。デフォルトで「不適切なコンテンツの検出」機能を持つ。

Vision API

GCPで提供される画像処理AIのAPI。デフォルトで「セーフサーチ」機能を持つ。

BigQuery

サーバレスでスケーラブルなデータウェアハウス。コンテンツの分類結果を格納する。今回の用途に関して言えば必ずしもBigQueryである必要はなく、別のストレージサービスでも代用できる。

出典

https://cloud.google.com/solutions/processing-marketing-submissions-using-video-intelligence?hl=ja

 

リアルタイムに生成されるデータを処理する

用途

ゲーム内のイベント情報を解析する時など。
リアルタイムに生成されるデータを取り込み、構造化データに変換した後にデータ格納する。

構造

1 データ生成源

実ゲームなど、リアルタイムにイベントデータが生成される場所。

2 認証

認証サーバ。

3 Cloud Pub/Sub

スケーラブルなメッセージングサービス。データ発生源(パブリッシャー)から流れてきたデータ(メッセージ)をキャッチ・一時保存し(at トピック)、適切なデータ処理機構を持つ Cloud Dataflow (サブスクライバー) へと配信する。

4 Cloud Dataflow

大規模データの処理を行うフルマネージドなエンジン。Pub/Sub のトピックから配信されたデータに対し、ユーザが規定した処理ロジックを適用し、JSONなどの構造化されたデータへ変換、ストレージへの格納を行う。

5 BigQuery

サーバレスでスケーラブルなデータウェアハウス。Cloud Dataflow により格納可能な形式になったデータを受け取り、格納する。

出典

https://cloud.google.com/solutions/mobile/mobile-gaming-analysis-telemetry

 

モノシリックなサービスをマイクロサービスに移行する

移行前

移行後

構成

Apigee

APIの管理プラットフォーム。
公開APIの場合は、Apigee を経由させ負荷分散させる。画像などのアセットの場合は、CDN経由で直接LoadBalancerへ繋ぎこむ。

Cloud CDN

コンテンツ配信ネットワーク。世界中に分散されたGoogleのエッジ拠点のキャッシュにコンテンツを保存することで、コストを削減しながらより早くユーザにコンテンツを提供する。

Cloud Load Balancing

スケーラブルな負荷分散装置。

Google Kubernetes Engine

コンテナ化されたアプリケーションをデプロイするための Kubernetesプロダクト。このアーキテクトでは、GKE内で作成されたコンテナがマイクロサービスとして機能する。

ストレージ

選択肢は多数。典型的なeコマースサイトのタイプであれば、Cloud Strage のストレージ適性が高い。他には、全世界での使用を考慮するのであれば Cloud Spanner 、集計や計算を多用するのであれば Cloud SQL などが選択肢に上がる。

バックエンドシステムとの接続

今回のアーキテクチャでは、バックエンドシステムはオンプレミスに据え置きを想定している。
バックエンドシステム側でサービスを提供するAPIを用意できるのであれば、マイクロサービスとバックエンドシステムとの連携に Apigee を使用することができる。
APIを用意できないのであれば、Cloud VPN や Cloud Interconncet を使用することで相互接続を実現する。

Cloud VPN

IPsec VPN トンネルを使用して、オンプレミスネットワークとGCPネットワークとを安全に接続する技術。

Cloud Interconnect

オンプレミスネットワークとGCPネットワークとの接続を、高可用性・低レイテンシで実現する技術。

出典

https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke

 

マイクロサービスのデプロイ2例

1. App Engine を使用する

App Engine (フレキシブル)

フレキシブル構成の App Engine は、自動スケーリング機能と負荷分散機能を備えたフルマネージドサービス。この構成では、着信トラフィックに基づいてアプリケーションのインスタンス数を自動で増減させることができる。サービス毎に別の App Engine 環境を作成しているため、各サービスは他サービスを気にせずにスケーリングすることができる。

Google Kubernetes Engine を使用する

Google Kubernetes Engine (GKE)

GKEを使用する場合、各GKE内でデプロイされるDockerコンテナがマイクロサービスとして機能する。
コンテナを構成するクラスタやポッドといった昨日群はGKEによる自動スケールの対象であり、CPU利用率などの指標に基づいてマイクロサービスをスケーリングすることができる。

出典

https://cloud.google.com/solutions/architecture/scaling-commerce-workloads-architecture

 

終わり

今回はここまでー。

プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで

GoogleCloudPlatformカテゴリの最新記事