Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Kinesis→Redshift連携を、KCLからFirehoseに切り替えたお話
Similaire à Kinesis→Redshift連携を、KCLからFirehoseに切り替えたお話 (20)
Dernier
Dernier (7)
Kinesis→Redshift連携を、KCLから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として⽇経を担当 • その後、⽇経に⼊って中からかき回すことに
- 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は、いずれも指定不可（ですよね？）
- 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
- 24. 24