マルチAWSアカウント間のストリーミングによるデータ同期/AWS SaaS Builders Forum 2024

2024年9月27日に開催された「AWS SaaS Builders Forum 2024」の登壇資料です。
https://pages.awscloud.com/eib-saas-240927-reg.html

-----
Visionalのエンジニアリングに関する最新情報はTwitter、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING Twitter
https://twitter.com/VISIONAL_ENG

Transcript

1. マルチ AWS アカウント間の
 ストリーミングによるデータ同期
 
 
 @AWS SaaS Builders Forum 2024/09/27
 株式会社ビズリーチ（Visionalグループ）
 リクルーティングプロダクト本部 検索基盤グループ
 中瀬 貴晴

2. 2008〜 日本ユニシス株式会社（現 BIPROGY株式会社）
 • 主にtoBの物流系システム開発・保守業務を担当 
 • 某ネット銀行へ出向し、クライアント側での基幹システム開発も経験 
 2019〜 株式会社ビズリーチ
 • 2019〜 キャリトレ
 ◦ グロースを通してインフラからフロントまでの開発経験を積む 
 • 2022〜 ビズリーチ 検索基盤グループ
 ◦ ビズリーチプロダクトの検索に関わる基盤の刷新、保守運用を担当 
 ◦ SIerの経験を活かし、中長期案件の推進なども担当 
 自己紹介
 中瀬 貴晴
 息子にバスケットボールを教えるのが趣味 🏀
 ※「キャリトレ」は 2022年12月にサービス終了しました。 

3. 即戦力人材と企業を繋ぐ転職サイト「ビズリーチ」 C（求職者様）とB（直接採用企業様 / ヘッドハンター）を繋ぐ転職プラットフォームを提供
 即戦力人材と企業を繋ぐ転職サイト「ビズリーチ」

4. 検索基盤グループの役割
 事業成長優先で着手できていなかった検索システムの負債解消や、検索品質の向上に取り組むた め、2022年に組成された組織

5. 本日お話する内容
 検索エンジンとして使用しているElasticsearchにRDBのデータを同期する仕組み（indexer）
 旧indexerが抱えていた課題と、それを解決するための技術的なアプローチをご紹介
 indexer
 一次データ
 ソース(RDB)
 求職者様向けの プロダクト
 検索エンジン
 (Elasticsearch)
 レジュメの更新 
 更新データの取得 
 更新データの同期 
 企業様向けの
 プロダクト
 求職者を検索 
 閲覧状態など企業側の行動データ更新 

6. 1. 旧indexerの課題（As-Is）
 2. 解決方法（To-Be）
 3. 各技術要素の選定理由
 4. 工夫した点
 5. 成果
 6. 今後の展望
 目次

7. 旧indexerの課題（As-Is）
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧
 事業成長に伴い増え続ける求職者様、および企業様のデータ
 同期処理が追いつかずデータ鮮度が悪化（平均10分、Max1時間強）
 データ鮮度
 RDBが更新されてから Elasticsearchに同期されるま でのタイムラグのこと

8. 旧indexerの課題（As-Is）
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧
 スループットを向上させにくいアーキテクチャ

9. 旧indexerの課題（As-Is）
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧
 ORマッパーによる暗黙的なキューイング処理の移行漏れ
 トリガーとLoad処理の元となるRDSインスタンスのズレ
 
 

10. やり直しが効かない構成
 何かあったらRDBから全件同期し直しという状態（所要時間: 15時間）
 旧indexerの課題（As-Is）
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧

11. 諸々の問題が顕在化している根本原因は、indexerに対し責任を持ち、保守・改善する組織が不在 であること
 旧indexerの課題（As-Is）
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧
 オーナー不在

12. 解決方法（To-Be） ~ オーナーの明確化 ~
 検索基盤グループのAWSアカウントを作成し、環境ごとindexerを移すことで、オーナーを明確化
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧
 オーナー不在

13. 解決方法（To-Be） ~ 構成の概要 ~
 DMSのCDC（変更データキャプチャ）をトリガーにした分散ストリーミング処理によるETL

14. 解決方法（To-Be）
 分散処理の効率化、ストリーミングによる逐次処理、不要なRDBアクセスの排除
 
 As-Is
 落ちていくデータ鮮度 ->
 頻発する同期漏れ
 ままならない障害復旧

15. 解決方法（To-Be）
 DMSのCDCでリードレプリカの変更を継続的に検知する
 
 As-Is
 落ちていくデータ鮮度
 頻発する同期漏れ ->
 ままならない障害復旧

16. 解決方法（To-Be）
 Kinesisから時間指定でストリームを再取得することで、障害発生時の再処理を容易に
 
 
 
 As-Is
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧 ->

17. 解決方法（To-Be）
 Kinesisの柔軟性を活用し、様々なケースに対応した復旧オペレーションを自動化
 
 
 As-Is
 落ちていくデータ鮮度
 頻発する同期漏れ
 ままならない障害復旧 ->

18. 各技術要素の選定理由
 • AWS DMS Serverless
 ◦ マルチAWSアカウントでのデータ同期が可能であった 
 ◦ CDCでElasticsearchに同期が必要なデータ更新を確実に捕捉することができた
 ◦ EC2インスタンスを自前で保守する必要がなかった 
 • Amazon Kinesis Data Streams On-Demand
 ◦ DMS経由のCDCをストリームとして処理したかった 
 ◦ DMS以外からのデータ同期が必要になった場合の拡張性を考慮 
 ◦ 時間指定でストリームを再取得することができるため、障害復旧が容易 
 • AWS Fargate
 ◦ 必要最小限の構成で実現したかった（EMR等の学習、運用コストを避けたかった） 
 ▪ 流量がある程度安定しているため動的なスケーリングが必要なかった 
 ▪ 結果整合性を担保すればよかった（チェックポイントによる厳密な再実行の仕組み等は不要） 
 • Apache Flink
 ◦ 社内で使える技術者が多いJVM系の言語で開発したかった
 ◦ 候補としてはApache Flink, Apache Beam, Apache Spark
 ◦ Flinkで書いたコードが読みやすかった 
 ◦ Flinkがストリーミング処理由来のフレームワーク で、window処理に関する機能が豊富そうだった 

19. 工夫した点（アーキテクチャ）
 ETLにおけるTransformとLoadの間にKinesisを挟み、アプリケーションを分離
 複数のクラスターに同じ情報を書き込めるように
 想定したユースケース
 • Elasticsearchのバージョンアップ作業 でのblue green deploy
 • 複数インデックス運用での ABテスト
 • インデックス再構築の自動化 （Appendix参照）

20. 工夫した点（Flinkアプリケーション）
 スループットを向上させるため、Window処理で求職者ごとにデータを集約

21. 工夫した点（Flinkアプリケーション）
 シャード間で時系列が順不同になるレコードを、結果整合性を担保しつつ処理する仕組み

22. 工夫した点（Flinkアプリケーション）
 シャード間におけるデータの偏りをなくす（1/2）

23. 工夫した点（Flinkアプリケーション）
 シャード間におけるデータの偏りをなくす（2/2）

24. 成果
 短期的なビジネス観点だけでなく、長期的な事業成長を支えられる基盤作りが完了
 
 
 ビジネス貢献
 処理の効率化/復旧時間
 属人化の解消と品質
 データ鮮度
 設定変更コスト
 RDBからElasticsearchへの同期処理 
 600 s → 30 s 
 1/6x 
 20x
 Elasticsearch の設定変更時間　 12 h → 2 h 
 日中も実行可能に
 RDBへの負荷（IOPS）
 1/10x
 日次インデックスの所要時間
 1/2 x
 5 h → 2 h 
 障害復旧時間
 15 h → 2 h 
 1/8 x
 • 社内に技術者の多い言 語への書き換え
 （Go -> Kotlin）
 
 • 設計に関するドキュメン トを集約
 
 • データ鮮度の低下によ る障害発生はリリース 後0に

25. 今後の展望
 マルチ AWS アカウント間のストリーミング処理を実現し、安定したデータ同期を達成
 これは将来のマイクロサービス化に向けた1step

26. 今後の展望
 サービス分割、ドメイン整理が進み、業務ロジックの凝集度が高まった暁には、より疎結合な仕組みへ。
 RDBから開放されることによる運用保守コストの低減、より機動的なグロースを実現したい。
 将来を見越した設計 I/Fの差分さえ吸収できれば、基本的には今 のアーキテクチャを踏襲できる設計
27. Appendix（index再構築）
 indexのシャード数変更など、Elasticsearch単体ではオンラインで実現できないことを、無停止かつ 自動で実行する仕組み。
 今回ご紹介したアーキテクチャの柔軟性とGitHub Actions Hosted Runnerを活用して実現した ワークフローをご紹介。

28. Appendix（index再構築）
 CodeBuildのGitHub Actions Hosted Runnerを活用
 workflowはGitHub Actionsに集約、実行はVPC内のCodeBuildで
 モチベーション
 • CI/CDはGitHub Actionsに集約したい
 • Elasticsearchの運用系workflowを定義したい
 • Elasticsearchにアクセスする許可をGitHub Actions に渡すのは心許ない

29. Appendix（index再構築）
 ① Elasticsearchのsnapshotから新しいindexをrestore

30. Appendix（index再構築）
 ② コード管理しているmapping.jsonの内容でreindexを行う（シャード数の変更等はここで行う）

31. ③ loaderをdeployし並行稼働させる（この時、snapshotの取得時間から巻き戻して取得する）
 Appendix（index再構築）

32. Appendix（index再構築）
 ④ loader-2の処理が現時点に追いついたら、indexのaliasを付け替えることで参照先を切り替え。
 

33. Appendix（index再構築）
 ⑤ 不要なリソースを削除