1|2EMRを使いこなすための4つの基本方針EMRがマネージド型といっても当然、それをどのような構成でどう使いこなすかはユーザー次第である。行動分析チームにはAWSを研究してきた末にたどり着いた基本方針がある。細かなことは気にしない。1について高山氏はこう説明する。「われわれのチームはエンジニアが少ない。AWSには興味深いサービスが幾つもあるが、あまり手を広げず、使いこなせる自信のあるサービスだけをとことん使い倒す」。DynamoDB」(DynamoDB)である。2〜4については、「AWSはいろんな車が走っている公道のようなもの。周囲の影響を受けることを前提にしないといけない」という考えにもとづく。密結合システムで1つのリクエストを長時間、安定処理するという従来の大規模バッチの考えを捨てるべきというわけだ。「どんなバッチ処理でも2時間以内に終わらせるようにしている。処理時間が短ければ障害リスクが減り、再実行もやりやすい。AWSは掛けるコストに合わせて処理時間がリニアに下がり、総コストは変わらない」。10ノード(EC2×10台)のEMRクラスタで20時間かかる処理量なら10倍の100ノードを使う。通信障害などでデータ欠損が発生しても気にせずに処理を貫徹し。後でその部分だけをやり直すというのだ。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経由で他システムと連係する仕組みだ。高山氏は「SQSには日に数億件の位置情報が入ってくるが、ボトルネックになったり、障害が発生したことはない」とSQSの分散処理性を評価する。EC2のオートスケール機能を使い、SQSのキュー量やEC2のリソース使用率をトリガーに分析ロジック、glid、DynamoDB、EC2を自動拡張しているが、「コストを抑えるために、ログを分析してオートスケール条件を細かく設定している」(同氏)という。ゼンリンデータコムの行動分析チームは、AWS活用により柔軟で効率的なデータ分析基盤を手に入れたといえよう。その分、コア資産である分析ロジックやglidの改良に力を注げるようになっている。鈴木氏は「新たなマネージドサービスの採用を含め、さらにAWSを活用して、統計データのリアルタイム生成や特異現象の自動検出など分析を高度化していきたい」と抱負を語る。過去最高の投稿数達成でXは生き延びるか?2024年の米大統領選の当日、Xの利用者数が過去最高を記録した。米大統領選で共和党のトランプ前大統領が勝利した。製造IT流通IT医療ITTechTargetサービスホワイトペーパーホワイトペーパーキーワードRSS一覧プレゼント&モニターITmediaはアイティメディア株式会社の登録商標です。