Upgrade to Pro — share decks privately, control downloads, hide ads and more …

JAWS DAYS 2022 - AWSのマネージドサービスで実現するニアリアルタイムな検索基盤

JAWS DAYS 2022 - AWSのマネージドサービスで実現するニアリアルタイムな検索基盤

JAWS DAYS 2022の登壇スライドです.
https://jawsdays2022.jaws-ug.jp/sessions/A11/

検索エンジン(OpenSearch)にデータを同期する(Glue)仕組みやパイプライン(Step Functions)を通して自動化するための方法を紹介しています.

Masataka Kashiwagi

October 08, 2022
Tweet

More Decks by Masataka Kashiwagi

Other Decks in Technology

Transcript

  1. 自己紹介 名前:柏木 正隆(Masataka Kashiwagi) 所属:コネヒト株式会社 - 機械学習エンジニア 出身:大阪府 お仕事 •

    レコメンドエンジンの開発 • 検索システムの開発 • MLOpsの推進 好きなAWSサービス • Amazon SageMaker • AWS Step Functions Twitter 友人とPodcastやってます @asteriam_fp @double_m2ml
  2. アジェンダ ☑ 自己紹介 ☑ コネヒトの会社・サービス紹介 □ ニアリアルタイムな検索基盤 • ママリで扱う「Q&Aデータ」とは? •

    検索システムのアーキテクチャ • AWS Glueで実現するデータ同期とは? • OpenSearchのインデックス管理 • データ同期パイプライン • AWS SAMを使ったワークフロー/パイプラインのコード管理 □ まとめ
  3. 本日話さないこと • 検索システム内製化プロジェクトの発足した背景 • 精度改善の取り組み(検索体験の向上) • AWSの各種サービスの細かい設定方法 この発表で得られること ※ 本資料は後ほど公開します!!

    • AWSのマネージドサービスを活用した検索基盤の構築方法 ◦ 検索エンジンのOpenSearchをどう使うか ◦ Step Functionsを活用したデータパイプラインの構築
  4. 検索システムのアーキテクチャ コネヒトでは全面的にAWSのマネージドサービスを採用 • 検索基盤は以下の構成 ◦ 検索エンジン:Amazon OpenSearch Service ◦ データベース:Amazon

    Aurora ◦ データ同期(ETL):AWS Glue ◦ ワークフロー・パイプライン:AWS Step Functions ◦ コード管理:AWS Serverless Application Model(AWS SAM)
  5. 検索エンジン - OpenSearchとは? OpenSearchは,Elasticsearchから派生したオープンソースの検索エンジン • AWSでは “ver.1.3” までサポートしている ◦ ML

    Commons pluginのサポート(機械学習モデルの学習ができる) ◦ Observabilityアプリの作成(システム状況を1ヶ所で確認することができる) ◦ etc… • OSS:最新版=ver.2.3.0(OpenSearch and Dashboards 2.3.0 Release Notes) 随時機能アップデートが入っているので, 今後のメジャーバージョンアップのサポートに期待! Ref. 1. OpenSearch and Dashboards 1.3.0 Release Notes 2. Amazon OpenSearch Service now supports OpenSearch version 1.3
  6. なぜAmazon OpenSearch Serviceを選択したか • Elasticsearchクラスタの運用は考慮ポイントが多く,独自で運用したくなかった ◦ チーム人数が少ないため,マネージドサービスが使えると嬉しい • 日本語全文検索のKuromojiプラグインに対応していた ◦

    (Sudachiにも対応してほしい) • VPC内に置くことができる • 他のAWSサービスとの親和性 ◦ Glue(データ同期)やStep Functions(パイプライン)との連携可能 Ref. 1. Operational best practices for Amazon OpenSearch Service
  7. AWS Glueを選択した理由 • 柔軟なデータ抽出が可能か ◦ 今回の必須要件である「差分抽出」の実装が容易で可能か ▪ Custom CodeでSQLを記述することで可能 ◦

    今後要件として出てくる「複数テーブル」を組み合わせたデータ抽出・同期が可能か ▪ 組み込みの変換処理・フィルター処理で実装可能 ◦ SQLやPythonで処理を実装することが可能か ▪ ETL Scriptsで自由に実装可能 • エラー発生時のリカバリーが容易か ◦ 再実行が容易に可能か ▪ コンソール,Step Functionsのアクションも用意されているため可能 ◦ 各種メトリクスを取ることが可能か ▪ APIを使ってジョブ実行時間を取得することも可能
  8. Glue Jobの設定 • Glue Studioを使ってジョブを作成 & 設定 ◦ 全量と差分の2つのデータ同期ジョブ ◦

    データソースとターゲットを決めるだけ • データソース ◦ Data Catalog(Aurora) ◦ 接続方法:JDBC接続 • ターゲットソース ◦ Elasticsearch Connector(OpenSearch) ◦ 接続方法:JDBC接続
  9. 全量と差分2つのデータ同期処理 • 全量データの同期処理 ◦ 頻度:数日に1回 ◦ 目的: ▪ 差分データ同期処理で取り逃がしたデータを拾う ▪

    バックアップ ◦ 特定のテーブルの全データを対象に総入れ替え(洗い替え)を行っている • 差分データの同期処理 ◦ 頻度:数分に1回 ◦ 目的:ニアリアルタイムな検索を可能にするため ◦ 直近で更新があったレコードを対象にDBからデータを同期する
  10. ニアリアルタイムな同期を実現するために • GlueのJob bookmarkというオプション機能を活用 ◦ ジョブの実行状態を保持する機能 ◦ 処理済みデータを再度処理しないようになる ◦ 重複処理や重複データを防ぐことができる

    • ジョブの実行時間が劇的に早くなります! Ref. 1. Tracking processed data using job bookmarks GlueのJob bookmarkオプション機能 引用)AWS Black Belt Online Seminar - AWS Glue
  11. Job bookmarkオプション機能でハマったところ • 予想以上に処理時間がかかった(初歩的な勘違い) ◦ 1回目のジョブ実行時はブックマークを作ることになるので,通常の実行になる ◦ 学び:dry-run的な形で一度動かしておく必要がある • KeysとKeysSortOrderの設定

    ◦ additional_optionsのKeysSortOrderをdescにすると意図した通りに上手く動かない → OpenSearchへのUpsertが効いていないことが発覚! ◦ 学び:タイムスタンプのように昇順で増加する場合,ascで指定する必要がある
  12. インデックスとは? • データを検索エンジンで検索するためには,“index” の作成が必要 ◦ An index is like a

    ‘database' in a relational database. It has a mapping which defines multiple types. ◦ An index is a collection of documents that are related to each other. • インデックス化は,検索エンジンが高速に検索できるよう にデータを整理する方法 Ref. 1. What is an Elasticsearch Index? 2. What is Elasticsearch?
  13. なぜインデックスの作り替えを毎回実施しているのか • OpenSearchのReindex APIを使わず,インデックスの削除→新規作成を実施 ◦ 数日に1回の全量データ洗い替え作業 • 洗い替え作業 ◦ データの漏れや欠損が発生していた場合の補完(保険的な役割)

    ▪ その時点での最新データを全て検索エンジンに投入する ◦ 不要なドキュメントを削除してインデックスをスリムにする → Reindex APIは既存のインデックスのコピーなので,それだけだと不十分!
  14. インデックスの切り替えフローの紹介 • 前提: ◦ indexAとindexBの2つ用意 ◦ エイリアスはindexBを向いている(エイリアス→indexB) ◦ 差分データの更新がindexBでアクティブで,indexAはスタンバイ状態 AWS

    Glueによるデータ同期 最新のデータ エイリアスの向き先が indexBからindexAに変更 • 上記のインデックスの切り替えフローをindex-Aとindex-Bで交互に行う • これをAWS Step Functionsでパイプラインに落とし込んで実装
  15. ワークフローの役割 • “パイプラインの制御” ◦ 前述の2つのインデックスに対して,どちらのデー タ同期パイプラインを実行するかを制御する役割 • “運用を意識した存在” ◦ EventBridgeによるスケジュール実行の対象を

    集約できる ◦ 現状のエイリアスの向き先を意識せずにこのワーク フローを実行するだけでインデックスの作成と切り 替えができる 2つのインデックスに対 応したパイプライン
  16. パイプラインの役割 • ワークフロー内にあるデータ同期処理の実態 • 処理内容 ◦ 辞書更新 ▪ ユーザー辞書 ▪

    シノニム辞書 ◦ 全量データの同期処理 ▪ インデックスの削除 ▪ エイリアスの切り替え ▪ 差分データ同期処理の有効化 / 無効化
  17. なぜワークフローとパイプラインで分けるのか? • “オペレーション” ◦ エラー時の再実行や手動実行を行うことが想定されたので,運用を考えると, 特に実行者が意識する設定(2つあるインデックスのうちどちらを実行すればいいか など)を減らしたかった • “設定したいスケジュールをEventBridgeで行えなかった(クリティカルな課題)” ◦

    要件:2つあるインデックスを数日おきに交互に実行したい ◦ 解決策:スケジュール設定をワークフローに対して1つ設定する ▪ 現在どのインデックスに対してエイリアスが接続しているかのチェックと, その後のどちらのパイプラインを流せば良いかを判断できる (ワークフロー側で判断)
  18. 辞書更新への対応 • なぜパイプラインに組み込んだのか? ◦ より良い検索を可能にするためには,辞書の整備が必要になってくる! ▪ 定期的に発生する辞書更新を自動化したい→パイプラインに組み込む ◦ OpenSearchへの辞書反映はインデックスが作られたタイミングのみ 1.

    インデックス新規作成時 2. インデックスオープン時 Ref. 1. 辞書の更新についての注意点 データの洗い替え時にはインデックスを新規で再作成している ので,そこに組み込むのがベスト!
  19. 辞書更新の流れ • パイプラインでの辞書更新の流れは以下の通り 1. S3に置いてある辞書ファイルの更新有無をLambdaでチェック ◦ 有:辞書更新へ,無:辞書更新の処理をスキップ 2. カスタムパッケージ(辞書ファイル)の更新 ◦

    ユーザー辞書 ◦ シノニム辞書 3. OpenSearchへ辞書ファイルの関連付け 4. インデックスを新規で再作成 ◦ Lambdaでインデックスの削除 ◦ Glueによるデータ同期時にインデックスの作成 Ref. 1. Custom packages for Amazon OpenSearch Service
  20. データ同期の流れ • 「インデックスの切り替えフロー」で紹介した処理をStep Functionsのアクションで 置き換えている 1. インデックスの削除(LambdaからOpenSearchのdelete APIを叩く) 2. Glueによる全量データ同期処理

    3. スタンバイ状態の差分データ同期パイプラインの有効化(EventBridge) 4. インデックスの切替(LambdaからOpenSearchのaliases APIを叩く) ◦ エイリアスの向き先を変更する 5. アクティブ状態の差分データ同期パイプラインの無効化(EventBridge)
  21. インデックスの切り替え • Blue/Greenデプロイ ◦ 動いているインデックスの更新 󰢃 ◦ 新しいインデックスへのデータ投入完了後に, エイリアスの向き先を変更 󰢏

    ▪ 安全なデプロイが実行できている • このインデックスの切り替え方法は,通称ペンギ ン本の「8.5.1 インデクサの更新」の章でも書か れている Ref. 1. 検索システム-実務者のための開発改善ガイドブック
  22. AWS SAMによるパイプラインのコード管理 • AWS SAMとは,AWS Serverless Application Model (AWS SAM)

    といい,サーバレスなAWSリ ソースを管理するツール ◦ サーバレスに特化したCloudFormation ◦ 今回使用したリソースは全てコード管理可能 ▪ Lambda, Glue, Step Functions (SFn) ...etc ディレクトリ構成
  23. コード管理の良いところ • 設定した内容を別環境に簡単に適用することが可能 ◦ ABテストを実施する際など,同一の環境をもう1セット用意する必要がある場合でも コード管理しておくこと,コマンド一発で環境を用意可能 • コードレビューが可能になり,設定ミスや漏れなどに気づきやすい ◦ 設定内容を透明化できる

    ◦ git管理できる • 環境依存部分をパラメータ化することで,template.yamlで管理切り替えが可能 • リソースの後片付けも容易に ◦ SAM or CloudFormationで作成すると,スタックというリソースの集合体で管理が できるので,削除する場合も一括で消すことができる
  24. まとめ • AWSの各種サービスを上手く使って検索基盤を1から構築した! ◦ 短期間で本番適用まで行けたのはAWSのマネージドサービスのおかげ • ニアリアルタイムなデータ同期はかなりチャレンジング ◦ GlueのJob bookmark機能

    • 検索基盤の構築方法 ◦ OpenSearchを活用した検索システム ▪ インデックスの切り替え / 運用方法 ◦ Step Functionsを活用したデータパイプラインの構築 ▪ ワークフロー/パイプラインの二段構成 ←オススメ😊 ◦ 再利用のためのコード管理も忘れずに!
  25. References URL • https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-releas e-notes-1.3.0.md • https://aws.amazon.com/jp/about-aws/whats-new/2022/07/amazon-opensearch-service-supports-ve rsion-1-3/ • https://docs.aws.amazon.com/opensearch-service/latest/developerguide/bp.html

    • https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html • https://www.elastic.co/blog/what-is-an-elasticsearch-index • https://www.elastic.co/what-is/elasticsearch • https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/ • https://docs.aws.amazon.com/opensearch-service/latest/developerguide/custom-packages.html • https://www.lambdanote.com/products/ir-system