オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

Google Cloud Platformをフル活用してNo-Opsでビッグデータ処理基盤を構築した

オールアバウトシステム部技術基盤Gの@takkyです。
オールアバウトの技術基盤Gではコンテナを利用した開発の推進やクラウドを活用した開発のサポート、DevOpsの推進をしています。
詳しくはこちら: 今回はそのなかでもGoogle Cloud Platform(GCP)のサービスをフル活用してほぼNo-Opsビッグデータ処理基盤の構築を行ったのでそのアーキテクチャについて説明します。

ビッグデータ処理基盤構築のきっかけ

案件の詳細に関しての記載はここでは伏せますが、フロント側でビッグデータを処理した結果を使用したいという要望が上がってきました。もちろんフロントで使用するため高速化・スケール化できることは最低条件となります。
GCEなどでオートスケールする手も考えたのですが障害時にOpsチーム(インフラチーム)に任せっきりになってしまい運用工数が増えてしまいます。また、開発者はインフラ側がなかなかわからないですし、インフラ側もデプロイされたアプリケーションがわからないということもあり問題の切り分けや障害対応が難しいという課題がありました。
そのため、今回はマネージドサービスを活用して開発者が運用面まで出来るようにする設計にする必要がありました。開発者はインフラの専門家ではないので上手くマネージドサービスを使用していく必要があります。

なぜGCPを使用するのか

読者の皆様は御存知の通りBigQueryに代表されるビッグデータ処理基盤がGCPにはあります。Google Cloud Next'17 in San Franciscoのようなカンファレンスでも述べられているとおり、GCPビッグデータ処理基盤が整っているクラウドサービスです。
BigQueryを始めとして、Datastore/DataflowやCloud PubSubなどビッグデータ処理に使用出来るマネージドサービスが多く用意されていることもメリットの1つとなります。
また、フロント側のアプリケーションはGKE(Google Container Engine)にデプロイしているためシステム面の連携がし易いというメリットもあります。
上記の理由からGCPを使用しています。

ビッグデータ処理基盤アーキテクチャ

今回構築したビッグデータ処理基盤のアーキテクチャは以下のようになります。 f:id:allabout-techblog:20170510182850p:plain

図のアーキテクチャの説明の前に使用しているGCPの各サービスについて紹介したいと思います。

BigQuery

BigQuery - Analytics Data Warehouse  |  Google Cloud Platform

大量のデータの格納やクエリでの高速処理が出来る(TBなら数秒PBでも数分)、安い(クエリ実行ならば5$/TB)データウェアハウス。
フルマネージドなのでシステムに関して考える必要がありません。
上記システムではいわゆる生ログを格納しています。

Google Cloud Datastore

Google Cloud Datastore Documentation  |  Cloud Datastore  |  Google Cloud Platform

NoSQLドキュメントデータベースです。AWSのDynamoDBに相当するNoSQLDBです。
こちらもマネージドサービスでシャーディングやレプリケーションを自動的に実行してくれる他、 オートスケールもしてくれます。
エンティティ(KVSにおけるvalue)に複数の型(int,array…)を挿入することができます。
また、以下のURL通り無料枠も多くなっています。

料金と割り当て  |  Cloud Datastore のドキュメント  |  Google Cloud Platform

SDKやwrapperも用意されているためfrontアプリケーションからの利用も簡単にできます。

Cloud Datastore Client Libraries  |  Cloud Datastore Documentation  |  Google Cloud Platform

Google Cloud Dataflow

Google Cloud Dataflow Documentation  |  Cloud Dataflow  |  Google Cloud Platform

分散処理をしてくれる実行基盤です。
マネージドサービスでGCPは実行基盤を提供しています。
そのため、リソース管理やパフォーマンス最適化を行う必要がありません。
特定のプログラムを自動で分散処理をしてくれるわけではなく、Dataflow専用のプログラムを書く必要があります。
SDKOSS(Apache beam)でJavaPythonが使用できます。

github.com

上記プロジェクトではDataflow SDK for Pythonを使用しています。
導入検討中はPythonSDKがβだったため実運用で導入して大丈夫かどうか心配でしたが、Google Cloud Next'17でGAになったため安心して使えるようになりました。 cloud-ja.googleblog.com

Google Cloud Dataflow ドキュメント  |  Cloud Dataflow  |  Google Cloud Platform

上記の日本語のドキュメントは更新が遅くまだBetaになっていますが、英語だとBetaは消えています。
(https://cloud.google.com/dataflow/docs/?hl=en を参考にして下さい)

分散処理をフルマネージドで行ってくれるサービスで機械学習と相性のよいPythonも使えます。
欠点はPython2.7というところです。
(Cloud SDKやApp Engine等Google系のサービスはPython3に対応しておらずPython2.7というのが多いです…)

Google Container Engine(GKE)

Google Container Engine (GKE) for Docker Containers  |  Google Cloud Platform

GKEはkubernetesのマネージドサービスです。
コンテナを実行するための環境として使用しています。
yamlによって設定の管理が可能なためInfrastructure as codeが実現できますし、rolling updateなどの仕組みを用いてデプロイも容易にできます。
今回のビッグデータ処理基盤では使用しておらず、Dataflowで分析しDatastoreに溜め込んだデータを使用するフロントアプリのデプロイ先として使用しています。

アーキテクチャの説明

次に今回構築したアーキテクチャについて説明します。
ビッグデータ処理で大切となる"データ"に関しては、fluentdでBigQueryに投入しています。
既存のシステムでデータを収集するためにfluentdを使用していました。そのため、fluentdのBigQueryのプラグインを使用することで利用する準備はすぐ行えました。

github.com

Cloud DataflowではPythonSDKでBigQueryとのつなぎこみや、機械学習アルゴリズム、Datastoreへ処理結果の格納などの実装を行っています。 今回はストリーミング処理ではなく、バッチ処理で行いました。
バッチ処理のため定期的に実行するためにGCEインスタンスを立てcronでDataflowを実行しています。
処理を行って得られた結果はDatastoreに格納しているため、Frontアプリケーションから利用するのは容易にできました。
上記アーキテクチャはDataflowを実行するGCEインスタンスのみインフラチームに準備して頂きそれ以外はNo-Opsで構築できました。cronで定期的に実行しているのですが、App Engineのscheduled jobsなどを使用するとインスタンスも必要なく完全にNo-Opsでできそうです。

コストメリット

4月の実績ですが、 Cloud Dataflowが約1,000円/月、 Datastoreが約3,000円とかなりコストが抑えることができました。
GCE標準のn1-standard-1,東京リージョンでインスタンスを1ヶ月動作させると$31.17 ≒ 3,500円なのでインスタンス複数台立てて分散させるよりかなり安く済ませることができました。

終わりに

今回はNo-Opsで構築するビッグデータ処理基盤について説明しました。 GCPの力を借りるとNo-Opsビッグデータ処理基盤を構築できます。
フルマネージドサービスは最高で特にスケール等意識しなくてもいい感じにやってくれます。 何か障害が起きてもインフラチーム抜きで対応できるようになっておりNo-Ops化できているのかなと思います。
ちょうどいいタイミングでGAになったDataflow SDK for Pythonを用いたDataflowの実装については次回の記事で公開します。  次の記事もよろしくお願いします。