GCPを活用して大規模解析サービスを構成する（2）
dbコンポーネント
大規模解析サービスでは、今まで説明してきたコンポーネントに対応する以下のようなDBが必要となります。
- リアルタイムな解析に利用するDB
- ニアリアルタイムな解析に利用するDB
- サイト管理者の管理画面で利用するDB
- 更新頻度が比較的高くないデータを高速に読み出すためのキャッシュDB
- 解析処理など、一時格納で使うキューイング用のDB（先ほど説明した解析キューもここに入ります）
ここでのポイントは、用途に応じて利用するDBを使い分けることです。例えば、リアルタイムな解析に利用するDBでは、さまざまな構造のデータの解析をリアルタイムに行わなければいけないという特性から、以下が要件になります。
- スキーマレスで高いスループット、低レイテンシで読み込み、書き込みができる
また、負荷（データのスループット）が想像できないことから、以下の2点が要件になります。
- DBのパフォーマンスアップが比較的簡単にできること
- データ容量を比較的簡単に増やせること
この要件をふまえると、リアルタイムな解析に利用するDBにはCloud Bigtableが適していそうです。
KARTEではCloud Bigtable、BigQuery、Cloud Pub/Sub、MongoDB、Redis、CloudSpanner、CloudDatastoreなどを使い分けています。どのように使い分けているかは次回紹介します。
trackerコンポーネント
trackerというJavaScriptのファイルを、エンドユーザに配布するための仕組みはどう実現すればいいでしょうか。自分たちでGCE＋Autoscaling＋Cloud Load Balancingをという仕組みを構築し、Webサーバから配信することも可能ですが、Content Delivery Network（CDN）という仕組みを使うのが一般的だと思います。
GCPではCloud CDN という形でCDNがフルマネージドで提供されており、trackerを保存するGoogle Cloud Storage（GCS）と Cloud Load Balancingとを組み合わせることで比較的簡単にCDNから配信が可能です。
trackerコンポーネントはGoogle Cloud Storage（GCS）＋Cloud Load Balancing＋Cloud CDNで構成します。
監視について
各コンポーネントでは、アベイラビリティをできるだけ高められるような構成を取っているという説明をしてきました。
問題が起きた時には人手を介さず自動で復旧するように構成していくのが理想になりますが、全てを自動化するのはとても難しいことです。
現実的にはいくつかの問題においては人が何らかの対応をすることになると思いますが、問題に気づくことができなければ、対応のしようがありません。
つまり、大規模解析サービスを提供していく上で「サービスを監視し、問題を通知する」仕組みはとても重要になります。
GCPにはStackdriverという監視サービスが存在します。Stackdriverでは外形監視、症状監視からログ監視までが可能で、監視結果に応じてSMSやslackなどの通知先に通知することができます。
このような監視サービスを利用することで、予期できない問題に素早く気づくことが可能となり、大規模解析サービスのコンポーネントで何か問題が起きた時に、素早い対応が可能となります。
