AWS Kinesis Streamに入るデータを、S3を経てRedshiftへロードする処理を、KCLを用いたワーカーをEB上で動かす仕組みからKinesis Firehoseに置き換えました。この過程で得られた知見をご紹介します。

1. Kinesis→Redshift連携を、
KCLからFirehoseに切り替えたお話
Hajime Sano (Data Technologist for Data & Marketing)
Data Team, Digital BU, Nikkei Inc.

2. ⾃⼰紹介
2
• ⽇経にいます。電⼦版40%、そのほか組織横断60% くらい
• データドリヴンな⽂化を醸成したり、それに必要なツールを作ったり
• https://www.slideshare.net/HajimeSano1/
• 元々はマーケティングテクノロジーの会社でCSMとして⽇経を担当
• その後、⽇経に⼊って中からかき回すことに

3. やってること
3
⽇経 読者

4. アクセスログ解析ツール
Realtime Stream Data Processing Platform
4
Web
App
Mail
APIs
Push
3rd Party
GeoIP API

5. アクセスログ解析ツール
Realtime Stream Data Processing Platform
5
Web
App
Mail
APIs
Push
3rd Party
GeoIP API

6. Challenges
6
• メンテナンスが微妙
• プラットフォーム、Nodeモジュール、カラム追加への対応、で環境の更新が必要
• EC2インスタンスのライフサイクル的に、「気付いて⼿動対応」がダサい
• 世の中の流れが、Server-less & Managed
• 何でもかんでもサーバーレスが良いみたい⾔われているし、EBでEC2ですと⾔うとモテない
• 「⼈間の時間が最も⾼単価」なので、作業の⼿間、ミスのリスク を最⼩化したい
• ⾊んな機能使ってケーススタディになりたい！
• そろそろ新しいサービス使って⾊々知⾒を共有したいな…

7. Kinesis - Redshift ： 構築当初
7
• 当初は、Kinesisからデータを読み出し、メモリーに蓄え、ファイルに書き出してS3にPUTする処理を、
node.jsでKCLを使い、EB/EC2で動かしていたい。
• r4.largeを16台使っていたが、r5.largeにしたら性能上がってコストが下がった。

8. Kinesis - Redshift ： Firehose化した
8
• Kinesis FirehoseをAWS コンソールからポチポチ構成した
• Redshiftへのロードまでをやってくれるので、バッチ処理を合理化できた
• EBでやっていた整形処理（ex. array→dict化）をData Transformation Lambdaに移植した

9. 収穫は？
9
• AWS利⽤料は増えたが、メンテナンスの⼼配は減った
• 雰囲気的には $1200/⽉ → $2000/⽉
• しかし想定外のコスト増があった…
• コンポーネントが減るとトラブルシューティングしやすい
• 従来はEB上で動くワーカー、ワーカーが使うDynamo、ワーカー監視のPrometheus、ロード処理の
Azkaban@EC2、バッチの履歴… 等気にしなければならなかった
• Firehoseだと、FirehoseのUIとCloudWatchでおよそ必要な情報が揃う
• 今⽇ここで発表するネタにできた
• 使っているコードをGitHubで公開しようとしているところ…

10. 10

11. 11

12. 課題が多かった
12
• Firehoseの処理を、⼀時停⽌したり再開したりできない（ですよね？）
• Iterator、チェックポイントの指定ができない
• スロットリングが発⽣→拡張ファンアウトがFirehoseでは使えず、「Firehose以外」に拡張ファンアウ
トを⼤量に適⽤する⽻⽬に
• S3→Redshiftのリトライ処理に柔軟性がなく、リトライのバッチ処理を別途作った
• Data Transformation Lambdaの障害で、S3に書き出されるレコードが破損しロードできなくなった
• KCL on EC2 by EB の時は、データの質における問題はゼロ、気にすることは多かったが障害耐性を⾼め
ていた（全体として、⼈が介在せずに⾃動復旧し、データロスをゼロにする設計思想）

13. どこから処理するか指定したい
13
• Lambdaのような⾃由度を期待していた
• 拡張ファンアウトを選択できたり
• 開始位置（iterator/checkpoint) を柔軟に指
定できたり
• 有効・無効を切り替えられたり
• Firehoseは、いずれも指定不可（ですよね？）

14. 障害耐性が低い
14
• ロンドン出張の最初の週末、Greenwichを散歩しているとSlackにいくつかアラートが
• Firehoseを調べると何やらエラーがあったらしい…

15. 障害耐性が低い
15
• FirehoseでLambdaということはData Transformationなので調べて⾒ると、⼀瞬availabilityがゼロ

16. 障害耐性が低い
16
• 68秒間で6件の不穏な動きがあった

17. レコード切れてる…
17

18. 分かったこと
18
• Data Transformation Lambdaで障害
• S3に書き出された6レコードで、JSONが途中で切れている
• FirehoseはRedshiftに対し、manifestファイルで1,000ファイルをまとめてCOPYコマンドを発⾏
• 1000ファイルのどれかに、破損した6レコードが含まれるので、1,000ファイルまとめてエラーする
• 処理に失敗したレコードは、S3にディレクトリが作られて保存される
• エラーした6件より、その6件が紛れ込んで処理出来ない1000ファイルに含まれる数百万レコードが
ロードできないことが問題

19. 対処した
19
• 破損したレコードの復旧は⾮現実的
• manifestファイルを分解して問題のレコードを含むファイルを⾒つけようとしたが、全体の処理に
時間がかかる
• バッテリー切れ、思い切りが必要
• Cityでカフェを渡り歩いて作業を続けたがバッテリー切れ
• Covent GardenにApple Storeがあるので、作業スペースと電源を借りた
• ロードできないmanifestファイルを破棄して、Source Record Backupから問題のあった時間分の
データを、改めてKinesis Streamに投⼊し直した
• すぐに問題は解消

20. 20

21. まとめ
21
• Kinesis Firehoseは⼿軽で便利
• UIで設定できてRedshiftへのロードまで⾃動化できる
• 検討すべきことは多い
• ⼀時停⽌できない、開始位置が決められない、1件でもData Transformartionがエラーすると泥沼
• スロットリングが発⽣するが拡張ファンアウトに対応出来ず、Firehose以外で対処が必要
（結果、$200/⽇ になってしまった…）
• ミッションクリティカルな⽤途に向かない
• 挙動に対して介⼊できることが少ないので、今ある性能・今ある耐久性を受け⼊れるしかない
• CSV/TSVの右端のカラムで同じ問題が起きたら、問題に気付かないのでは？？
• AWSに改良を期待…

22. 22

23. 23
オフィス⾒学歓迎
⽇経の技術に興味があれば
⾒学歓迎
エンジニア情報
https://hack.nikkei.com/
エンジニア向けTwitter
@nikkeideveloper
WE ARE HIRING!

24. 24