読者です 読者をやめる 読者になる 読者になる

オールアバウト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の実装については次回の記事で公開します。  次の記事もよろしくお願いします。

パフォーマンス改善バトル!社内ISUCONを開催してみた

こんにちは! 社内ワークショップ運営チームの@C058です。

流行りの社内ISUCONを弊社でも開催しました! 今回は、社内ISUCONについて、準備したことと開催結果を報告します。

続きを読む

業務の定常化から始める継続的プロダクト改善

こんにちわ! wrbssです。オールアバウトでスマホアプリの開発を担当しています。 今回はオールアバウトでどのようにスマホアプリ開発を進めているかにフォーカスして紹介したいと思います。 主に新規でのアプリ開発にておこなっているやり方なので、それだけ留意いただければと!

はじめに

最初にどのようなチーム構成で開発しているかが分からないと 想像もしづらいと思うので、現在のアプリ開発チームの構成を軽く紹介します。

どんなチーム構成でやっているか

6人でチームを組んで開発しています。構成は以下のような感じです。

  • 企画3人

  • エンジニア3人

1つのジャンルに対して、広くアプローチしようとしているため企画側は営業も兼ねています。 またエンジニア側はiOS / Android / サーバーサイドと必要になればなんでもやる人材で固められております。 そんなチーム構成でどのようにアプリを開発しているかを今回は紹介します。

続きを読む

アップデートし続けるアプリのSwift移行

f:id:allabout-techblog:20170329090435p:plain

はじめに

初めまして!オールアバウトの @morimorimです。 2016年度入社新卒エンジニアの連載企画第三本目として、CafeSnapというアプリをObjective-CからSwiftへ移行している話をしたいと思います。

CafeSnapとは

CafeSnapとは、日本全国にある個性の光るカフェを探すことができる写真共有型アプリです。 タイムラインに流れている写真や、今いる場所、メニュー、特徴など多彩な条件からカフェを探すことができます。 ぜひご利用ください!

f:id:allabout-techblog:20170316230704j:plain:w200f:id:allabout-techblog:20170316230653j:plain:w200

なんでSwift移行を決めたの?

Swift移行しようとした理由は主に3つあります。

1つはSwiftの学習コストの低さと開発効率の良さです。 SwiftはObjective-Cに比べ学習しやすく、実際Objective-Cを書けるようになるまでの時間よりSwiftのほうが短いです。 また、構文の書き方も簡単になっており、記述するのがとても楽になっています。

続きを読む

新卒入社してから投稿し続けたQiita:Teamの日報を可視化してみた

f:id:allabout-techblog:20170315142553p:plain

Switchで筋肉痛になりました。@amymdです。

2016年度入社の新卒エンジニアが記事を投稿する連載企画!

ということで、今回は2本目の記事を、2016年度入社の開発エンジニアである@amymdが投稿いたします。 よろしくお願いいたします!

はじめに

突然ですが、みなさんは日報を書いていますか?
自分は2016年4月にオールアバウトに入社したのですが、配属された5月から12月28日まで、社内のQiita:Teamに日報を投稿し続けていました。

f:id:allabout-techblog:20170321163453p:plain:w500

せっかく書き続けたこの日報を、何かの役に立てたい……と思い、今回はこの約8ヶ月間書き続けた日報のデータをテキストマイニング等で分析してみて、この一年間の振り返りをしてみたいと思います。

続きを読む