GCPを活用して大規模解析サービスを構成する（1）
まずはGCPを活用したシステム構成について、オーソドックスな構成のtrackコンポーネントから順番に説明していきます。
trackコンポーネント
trackコンポーネントでは、エンドユーザからリクエストを受けて、レスポンスを返すことが必要となるので、Google Compute Engine（GCE）上にWebサーバを構築します。
GCPでは、コンピューティングリソースはGCEのほか、Google App Engine（GAE）、Google Container Engine（GKE）などがあります。それぞれ特徴があり、用途によって適切なリソースを選択することになりますが、KARTEではIaaSとしてコンピューティングリソースが提供されているGCEを利用しています。IaaSのレイヤーでサービスが提供されているので、カスタマイズ性が高いと同時に、何かがあった時に他のクラウドプラットフォームに移すことが比較的簡単にできるからです。
GCEを使ったWebサーバの一番シンプルな構成は、エンドユーザからのリクエストをGCEインスタンス1台が直接受けるというものになります。ですが、この構成ではGCEインスタンス1台のマシンスペックがボトルネックとなってしまいます。
そこで、Cloud Load BalancingとAutoscalingを使い、複数のGCEインスタンスを1つのコンピューティングリソースのように扱います。Cloud Load BalancingとAutoscalingは、具体的には以下の役割を担っています。
- Cloud Load Balancing：エンドユーザからのリクエストを複数のGCEインスタンスに分散
- Autoscaling：負荷に応じて自動的にGCEインスタンスを増減
エンドユーザからのリクエスト数の予測が難しく、データの欠損はできるだけ抑えないといけないという大規模解析サービスの特性上、この仕組みはとても重要になります。
trackコンポーネントはGCE＋Autoscaling＋Cloud Load Balancingで構成します。
adminコンポーネント
adminコンポーネントでは、trackコンポーネントと同様に、ユーザから直接リクエストを受けてレスポンスを返すことが必要となるので、Webサーバ（Admin）をGCE上に構築します。
ただ、リクエストを投げるユーザがエンドユーザではなく、サイト管理者となるので、trackコンポーネントよりリクエスト数は少なくなると考えられます。
したがって、trackコンポーネントと同じGCE＋Autoscaling＋Cloud Load Balancingで構成すれば問題ありません。
analyzeコンポーネント
analyzeコンポーネントではエンドユーザのデータを解析するサーバ（Analyzeサーバ）をGCEで構築します。
Analyzeサーバへのデータの受け渡しは、イベントの処理順序の担保、欠損の防止などを目的に、以下の流れでメッセージキューを用いています。
- Trackサーバが受け取ったエンドユーザのデータをメッセージキューに積む
- Analyzeサーバがメッセージキューからエンドユーザのデータを取得し、解析する
またこのメッセージキューは全Analyzeサーバから参照が可能で、この仕組みによりanalyzeコンポーネントではCloud Load Balancingを利用せずに負荷分散を実現しています。
メッセージキューはインメモリKVSであるRedisや、Google検索／Gmailでも使われているCloud Pub/Subなどで実現が可能です。それぞれ特性があるので用途において使い分けること、このキュー自体がボトルネックにならないようにすることが重要です。
インスタンスの増減については、track／adminコンポーネントと同様にAutoscalingを利用しています。
analyzeコンポーネントは、GCE＋Autoscaling＋メッセージキュー（redis、Cloud Pub/Subなど）で構成します。
