ゼンリンデータコムのビッグデータチームが指南、AWSマネージドHadoopの勘所とは？：「AWS Summit Tokyo 2015」リポート：ゼンリンデータコム（2/2 ページ）

[石田 己津人]

EMRを使いこなすための4つの基本方針

　EMRがマネージド型といっても当然、それをどのような構成でどう使いこなすかはユーザー次第である。行動分析チームにはAWSを研究してきた末にたどり着いた基本方針がある。それは以下の4つだ。

1. 少数のサービスを徹底活用
2. 単体システム同士は疎結合
3. 並列処理で処理時間を短縮
4. 細かなことは気にしない。

　1について高山氏はこう説明する。「われわれのチームはエンジニアが少ない。AWSには興味深いサービスが幾つもあるが、あまり手を広げず、使いこなせる自信のあるサービスだけをとことん使い倒す」。行動分析チームが選び抜いたサービスとは、EC2や「Amazon Simple Storage Service」（S3）のような基本的なものを除けば、EMRの他に分散キューイングの「Amazon Simple Queue Service」（SQS）、メッセージングの「Amazon Simple Notification Service」（SNS）、そしてNoSQLデータベースの「Amazon DynamoDB」（DynamoDB）である。

　2〜4については、「AWSはいろんな車が走っている公道のようなもの。周囲の影響を受けることを前提にしないといけない」という考えにもとづく。密結合システムで1つのリクエストを長時間、安定処理するという従来の大規模バッチの考えを捨てるべきというわけだ。鈴木氏がこう語る。「どんなバッチ処理でも2時間以内に終わらせるようにしている。処理時間が短ければ障害リスクが減り、再実行もやりやすい。AWSは掛けるコストに合わせて処理時間がリニアに下がり、総コストは変わらない」。例えば、10ノード（EC2×10台）のEMRクラスタで20時間かかる処理量なら10倍の100ノードを使う。通信障害などでデータ欠損が発生しても気にせずに処理を貫徹し。後でその部分だけをやり直すというのだ。

図3　Amazon EMR中心のバッチ処理型データ分析システム（出典：ゼンリンデータコム）《クリックで拡大》

　こうした基本方針の基、行動分析チームが運用する分析システムは次のような構成だ。AWSで常時稼働させているコンソール用サーバからオンデマンド（必要なときに必要なノード数）でEMRクラスタを起動する。同時にEC2上に地図情報データベースのglidも立ち上げる。そしてS3より位置情報の点列データをEMRクラスタに送信し、glidと交信しながら分析を行い、その結果をS3に返す流れだ。分析処理が終われば、ボトルネック解析に使うための各種ログをコントローラーが回収してEMRクラスタとglidを停止する。高山氏は「120ノードのEMRを2時間稼働させてもコストは3万円で済む。同じインフラを自前で持つのと比べたら格安」と話す。

SQS／SNSを活用したリアルタイム処理型システム

　リアルタイム処理ではSQSとSNS、DynamoDBを活用している。移動体から断続的に取得する位置情報をSQSでキュー（待ち行列）化し、分析ロジック（バッチ処理で使っているものと同じだが、EMRは非介在）でglidと交信しながら順次処理していく。分析した移動体の行動情報（未確定／確定）はDynamoDBに格納される。そして特定イベントが発生するとSNS経由で他システムと連係する仕組みだ。

図4　SQS／SNSを活用したリアルタイム処理型システム（出典：ゼンリンデータコム）《クリックで拡大》

　高山氏は「SQSには日に数億件の位置情報が入ってくるが、ボトルネックになったり、障害が発生したことはない」とSQSの分散処理性を評価する。また、EC2のオートスケール機能を使い、SQSのキュー量やEC2のリソース使用率をトリガーに分析ロジック、glid、DynamoDB、EC2を自動拡張しているが、「コストを抑えるために、ログを分析してオートスケール条件を細かく設定している」（同氏）という。

　ゼンリンデータコムの行動分析チームは、AWS活用により柔軟で効率的なデータ分析基盤を手に入れたといえよう。その分、コア資産である分析ロジックやglidの改良に力を注げるようになっている。鈴木氏は「新たなマネージドサービスの採用を含め、さらにAWSを活用して、統計データのリアルタイム生成や特異現象の自動検出など分析を高度化していきたい」と抱負を語る。