gcp-aws

こんにちは。mikotoです。

Google Cloud Platform(GCP)の機能の一つとして、Google Cloud Dataflowの記事を書きました。
 ・Dataflowのパラメータ指定可能なテンプレートを作成する
 ・Dataflowで実行パラメータを指定する  
 ・DataflowでDatastoreをRead/Write/Deleteする

今回は、そのGCPに移行した経緯について、お話したいと思います。

移行の理由

弊社では、社内で扱うデータとして非常に多くの求人情報を持っていて、それが毎日リフレッシュされています。
掲載された求人情報はどんどん古くなっていくのですが、古いデータをマイニングすることで「過去どういう求人があったか」という情報自体価値を持つのではないかと思い、データ分析をはじめました。

データ分析環境をAWS EMR上に構築したのですが、古いデータを扱うことでデータ量は膨大になり、それに併せてAWSにかかる費用も上がっていきました。このことが移行を考え始めたきっかけになりました。

他システムの検討

インフラの費用を抑えるために、他のIaaSを検討しましたが、最終的にGCPを選択しました。
理由は3つあります。

Amazon EMRは最適なパラメータを手さぐりで探すことで元の速度の3倍まで高速化できたのですが、GCPのDataProcはノーチューニングで同等以上の速度を出せました。チームにSparkに詳しいエンジニアがいないため、このような「構築のしやすさ」は代えがたいものでした。また、起動が早いため試行錯誤をストレスなく実施できる点も良かったです。

第2の理由としてデータ処理に強い点、そして第3の理由、AWSよりもGCPのほうが低コストで環境構築可能であることが決め手となり、最終的にGCPに決定しました。

GCPの各環境について

App Engine(GAE)

gae240

App Engine は Google が提供する PaaS(Platform-as-a-Service)で、「スタンダード」と「フレキシブル」の2種類の環境があります。

「スタンダード」と「フレキシブル」どちらにしても、サーバーのスペックやスケーリングなどのインフラ設計を簡単に設定することができます。
「スタンダード」は、基本的な使い方においてはLambdaのようにビジネス価値を生むロジックのみに集中してコーディングできます。
「フレキシブル」では、各言語ランタイムで動作するライブラリをインストールすることができます。また、Dockerをベースに必要なアプリケーション環境を構築することも可能です。「フレキシブル」はAWS Elastic Beanstalkに近い使い方ですが、各種設定をよりシンプルに実現できます。
(「スタンダード」でもデプロイリソースに含めることで外部ライブラリを利用することは可能です。)

ただし、Beanstalkの方が、ネットワーク、ロードバランサー、セキュリティグループなどのインフラ構成に関する設定をより詳細にできるので、この点においては今のところAWSの方に優位性を感じました。

また、App Engineに関してLambdaと比較し、以下の2つの点で優れていると感じました。

一つはLambdaとは異なりしばらく使用していないと次の実行が許容できないレベルで遅くなるということがなく、レスポンスがとてもよかった点。
もう一つはアイドル状態のインスタンスを最低1つは確保するなどの使い方ができる点です。

Cloud Dataflow

dataflow

Dataflowはフルマネージドなデータ処理サービスです。Dataflowを利用すると、データソースに捉われることなくストリーム処理とバッチ処理のプログラミングモデルの切り替えをスムーズに実現でき、リソースのプロビジョニングが自動的に行われるため、ビジネスにとって最も重要なデータ処理のアルゴリズムに集中できるようになります。

データの処理状況を可視化する機能も便利です。
例えば、「行を読む」「ワードに区切る」「ワード毎に出現回数を数える」といったプロセスの、どのプロセスでどの程度のスピードで処理が進んでいるか、という状況がグラフィカルにわかります。
これにより、タスク管理ツールのように各タスクの繋がりが分かった上で、どの処理がボトルネックなのかまで判断できます。

Dataflowで一番良いと思ったポイントとして、「勝手にスケールする」という機能があります。公式では「スループットでスケールが変更される」とあるのですが、上記の処理状況グラフを見ると、遅いプロセスでワーカーを優先的にアサインすることで全体の処理速度を上げているような気がします。
一度Datastoreにテストデータを大量に入れ過ぎて、データ消去が出来なくなってしまったことがあったのですが、Dataflowで実施したところ、簡単に処理ができました。
こちらについては、「Cloud DatastoreのEntryを全件削除する方法」を参考にしてください。

Cloud Datastore

datastore

Cloud Datastoreは、必要に応じて自動的に拡張し、非リレーショナルデータを保存できるNoSQLデータベースです。
AWSだとDynamoDBにあたりますが、どちらもKVSではあるもののDynamoDBは秒間あたりの読み込み/書き込み数を指定する必要があるため、データ投入時などの一時的に変更したい場合にパラメータを変更する手間が面倒でした。
その点で、Datastoreはスケールまで勝手に行ってくれるので便利です。

開発環境という観点での比較

開発環境という観点で比較すると、AWS Lambdaはローカル環境を構築する手段が(公式では)存在しませんが、App Engineはローカル用のサーバが用意されていており、App Engineのアドバンテージが大きいと感じます。

ローカルサーバーを立ち上げた場合、ローカルでデータストアが用意され、データの読み書きはローカルの環境にのみ影響します。
テスト用のスタブを利用すれば、初期化やテストデータの投入も容易に行うことができます。開発が閉じた状態で他に影響を及ぼすことがありません。

デプロイも簡単です。コマンド1つでデプロイが可能で、デプロイする毎にバージョンが作成されます。デプロイが完了すると、古いバージョンから新しいバージョンにトラフィックが移されます。問題が発生した場合、過去のバージョンに戻すことも簡単です。
また、複数のバージョンに任意の比率でトラフィックを流すこともできます。

リージョンという観点での比較

GCPの大きな特性の1つとして、Googleの回線ですべてつながっている、マルチリージョナルな点が挙げられます。
リリースされた拠点でのみ使えるのではなく、新しいサービスが発表されたら、その瞬間全世界で使えるような環境は、大きな強みだと思います。

GCPに今後期待すること

ここまで、GCPの良い面を書いてきましたが、GCPはAWSと比較してセキュリティ面の弱さが見られますので、扱う情報がセンシティブな場合は、利用が厳しいかと思います。

また、AWSは先行優位性がありプレイヤーが多いので事例が沢山ありますし、サードパーティのAWSパートナーのサービスをすぐに導入できる利点があります。
1つのことを実現するのに、「自前でやる」「AWSのサービスを使う」「サードパーティのサービスを使う」など多くの選択肢があり、費用をかけて解決する道も開かれています。サービス間の連携もシームレスです。
これに比べてGCPではまだまだ情報が少なく、サービス間連携を行う際、そのようなサンプルが無い場合は非常に苦労するケースもまだ多いです。公式のドキュメントすら古い時があります。

私のプロジェクトのユースケースでは、AWSでいう所のCloudSearchにあたるフルマネージドな検索サービスが無いことも残念です。Cloud LauncherでElasticsearchクラスタを立ち上げることもできますが、どうしても運用は時前になってしまいます。
Googleが提供する検索サービスであれば、需要も高まると思うので、是非提供してほしいものです。

最後に

AWSからGCPに移行した経緯と検証したメリット・デメリットについて述べてきました。
我々も全てを移行したわけではなく、AWSが有利な部分もあります。

また、よくあるAWSとGCPのサービス対応表には見られない違いがあることにも言及しました。
実際にGCPを導入する場合は、まずは利用してみることが重要だと思います。