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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

各技術要素の選定理由  ● 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処理に関する機能が豊富そうだった  

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

成果  短期的なビジネス観点だけでなく、長期的な事業成長を支えられる基盤作りが完了      ビジネス貢献  処理の効率化/復旧時間  属人化の解消と品質  データ鮮度  設定変更コスト  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に 

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

今後の展望  サービス分割、ドメイン整理が進み、業務ロジックの凝集度が高まった暁には、より疎結合な仕組みへ。  RDBから開放されることによる運用保守コストの低減、より機動的なグロースを実現したい。  将来を見越した設計 I/Fの差分さえ吸収できれば、基本的には今のアーキテクチャを踏襲できる設計

Slide 27

Slide 27 text

Appendix（index再構築）  indexのシャード数変更など、Elasticsearch単体ではオンラインで実現できないことを、無停止かつ自動で実行する仕組み。  今回ご紹介したアーキテクチャの柔軟性とGitHub Actions Hosted Runnerを活用して実現したワークフローをご紹介。 

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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