spark streaming on aws -s3からkinesisへ-

Spark Streaming on AWS

-S3からKinesisへ- !

2015-09-25 JAWS-UG Meguro #2

自己紹介• 島本 多可子（@chibochibo03）

• 株式会社ビズリーチ CTO室

• ここ数年はScalaを書いてます

• 一応、GitBucketのコミッタです

• https://github.com/takezoe/gitbucket

検索エンジン作ってます

アーキテクチャ概要

• 主要言語はScala

• 検索部分はElasticsearch

• サービスのほとんどはAWS上に構築

どこにSpark使ってる？

求人データの投入

新鮮な求人を

リアルタイムに検索結果へ

求人の投入

• 元ネタはクロールで取得

• クロールデータを？？へ投入

• Spark上で抽出・加工して検索用ESへ投入

??クロール

Spark Streaming

• EC2に自前でStandalone Clusterで構築

• 規模としてはミドルデータ

• Apache Stormのような本当のストリーム基盤までは(今のところ)求めてない

？？って何

求人の投入

• 元ネタはクロールで取得

• クロールデータを？？へ投入

• Spark上で抽出・加工して検索用ESへ投入

??クロール

この部分 （Sparkのインプット）

選定に右往左往した

その１：

S３

なぜS3を選定した？

• ロストが許されない求人が混在していた

• 耐障害性を考えるとSparkのストレージはファイルがいいのではという過信

• 1コア(--total-executor-cores)でもプロセス起動可能

しかし

毎日ログをチェック

理由• （当然ながら）S3はバッチ向け

• ある程度サイズのあるファイルが少数の方が向いている

• サイズの小さいファイルが多数の場合はスキャンにかかる時間がボトルネックになる

• ウインドウ幅の時間にスキャン時間も含まれる

タスクが遅れ始めた

つらい

その２：

Kinesis

なぜKinesisを選定した？

• ロストが許されない求人は別で担保

• Spark1.4でKafkaとKinesisのサポートが強化されたのも魅力だった

• シャード増減でスケールにも対応できそう

そして

幸福が訪れる

ちなみに

監視

• mackerelに集約

• バッチ間隔ごとの進捗状況はStreamingListenerを継承した独自リスナを使って通知

ありがとうございました