Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 20180922 jazug8 cosmosdb_search
Semelhante a 20180922 jazug8 cosmosdb_search (20)
20180922 jazug8 cosmosdb_search
- 1. Cosmos DB + Searchを利用した 検索システム構築 2018/9/22 和田 一洋 Japan Azure User Group 8周年イベント
- 2. 自己紹介 和田 一洋（わだ かずひろ） • グロースエクスパートナーズ（株）所属 https://gxp.co.jp/ • Azure歴２年くらい • http://qiita.com/khwada 1
- 3. 今日の話 • Azureのマネージドサービスを組み合わせて検 索システムを構築した事例 • Cosmos DB / Search / SQL Database / App Service / Storage • 検索インデックス作成処理での非機能面の工 夫を紹介 • 検索の機能面での試行錯誤について紹介 2
- 4. アジェンダ • システム概要紹介 • 検索インデックス作成 • 検索＆スコアリング • まとめ 3
- 5. システム概要紹介 4
- 6. 検索システム • 企業名、住所、電話番号などから、取引先を 特定するための検索システム • 検索対象データ数は1,000-2,000万件 • 業務要件で、定期的に全件再インデクシング が必要 5
- 7. Azure構成 6 オンプレ環境 検索インデックス作成 検索エンジン Blob Storage Storage Queue WebJobs SQL Database Storage Queue WebJobs CosmosDB Search AppService インデック 元データ ユーザー
- 8. 検索インデックス作成 7
- 9. 検索インデックス作成 8 オンプレ環境 検索インデックス作成 検索エンジン Blob Storage Storage Queue SQL Database Storage Queue WebJobs CosmosDB Search AppService インデック 元データ ユーザー WebJobs
- 10. 検索インデックス作成 9 オンプレ環境 Blob Storage Storage Queue WebJobs SQL Database Storage Queue WebJobs Search インデック 元データ 基幹システムからのファイ ル受信＆Blob Storageアップ ロードがトリガー 差分抽出、処 理分割 並列処理で index更新
- 11. イベント駆動処理 10 WebJobs SQL Database Storage Queue WebJobs Search ①処理対象データを分割して、 処理対象データIDをqueueに投入 ②queueトリガーで WebJobsを並列起動 ③対象データをselect して加工し、Search のindexをAPI更新 自動リトライ ④queue単位で異常終 了分は自動リトライ CosmosDB
- 12. イベント駆動処理 • リランの単位を小さくして、インデックス作成の 取り回しをしやすく • 異常終了時に、1,000万件の再処理は避け たい • 処理を冪等にする前提で、自動復旧（自動リ ラン）したい • 一部データを対象に手軽にインデックス再作成 したい • 並列処理化して、全件再インデクシング時の 処理速度向上を容易に 11
- 14. 性能チューニング • とはいえ、アプリのスケールアウトは容易だが、 各種ストレージのIO性能がボトルネックになる 13 WebJobs SQL Database Storage Queue WebJobs Search 自動リトライ CosmosDB
- 15. 性能チューニング • 当然のことながら、現実的に許容できる課金 額にはキャップがある • 各種ストレージのIO性能をバッチ処理中だけス ケールアップするにも、スケールアップ自体が容易 でないリソースもある（SearchやSQL Database） • アプリケーション観点でも作りこみは必要 • 処理を分割してあると、ボトルネックを検出した あとのチューニングはしやすい 14
- 16. 性能チューニング 15 WebJobs SQL Database Storage Queue WebJobs Search 自動リトライ CosmosDB ①100件ごとに分割してqueue投入 ※1件ずつ処理だと、WebJobsでの DB Connection確立～selectがボトル ネックに
- 17. 性能チューニング 16 WebJobs SQL Database Storage Queue WebJobs Search 自動リトライ CosmosDB ②Searchのindexと同等の 内容を保持、旧インデッ クスの削除要否を判定 ※Searchを読むと性能が 出なかった
- 18. 性能チューニング 17 WebJobs SQL Database Storage Queue WebJobs Search 自動リトライ CosmosDB ③API経由でSearchをpush更新 ※Cosmos DBをソースとした自動 indexerは制御しづらかった
- 19. 性能チューニング • 日々のバッチ処理は、各種リソースをスケール アップ／スケールアウトせずに処理 • 全件再インデクシング処理は、開発初期は 48時間以上かかっていたものを、10時間以 下まで短縮 • WebJobsは8インスタンスにスケールアウト、スト レージ系もスケールアップして処理 18
- 20. 自動復旧 • 業務的に、At Least Onceは担保が必要 • WebJobsのエラーは一定頻度で発生するが （一時的なDB接続エラーなど）、基本的に は自動リトライにより自動復旧 • 複数回リトライしても処理に成功しなかった場 合、リトライが停止して、Poison Queueに残 る ⇒ 調査の上で、手動リカバリ 19
- 22. 監視 • 最終的にPoison Queueに残がなければ正 常終了と判断している • WebJobsのExceptionはログをモニタリングし ているが、 Exception内容は後から確認 21
- 23. 監視 • 遅延監視的な監視は拾いづらい • 「起動されるべき処理が起動されていない （例：ファイル未到着）」「想定時刻までに処 理が完了していない」 • Queue数やWebJobsログをモニタリング • 人手確認＆リカバリ要否判断に工夫が必要 22
- 24. Azureでのイベント駆動処理 • AzureのQueueとWebJobsを利用すること で、イベント駆動処理の構築は容易 • 自動リトライやモニタリングも仕組みが整ってい る • ストレージIOを含めた性能／課金額のバラン ス、モニタリング＆監視を調整 23
- 25. 検索＆スコアリング 24
- 26. 検索＆スコアリング 25 オンプレ環境 検索インデックス作成 検索エンジン Blob Storage Storage Queue SQL Database Storage Queue WebJobs CosmosDB Search AppService インデック 元データ ユーザー WebJobs
- 27. Azure Search • LuceneベースのAzureフルマネージド全文 検索サービス • 検索結果が、「関連性が高い」ものからソート して返却される • 手軽に導入できため、インデックス＆クエリの設 計に注力できる 26
- 28. Azure Search • Search参考資料 • Azure Search Deep Dive https://www.slideshare.net/decode2 016/dev018azure-search-deep-dive • その情報うまく取り出せていますか? https://www.slideshare.net/decode2 017/di08-azure-search • Azure Search 大全 https://www.slideshare.net/dahatake /azure-search-114345418 • Azure Search クックブック https://www.slideshare.net/kazuyuki miyake/azure-search-79578438 27
- 29. 検索 「検索」のユースケース • 条件に合致するもの１件を見つけたい 「Japan Azure User Group 8周年イベント」 • 条件でフィルターしてリストアップしたい 「品川 休日 ランチ」 • 不完全な情報を補完して目的のもの1件を見つけたい 「Azure NoSQL」 28 今回のユースケース
- 31. 検索での検討ポイント • 検索ヒット • 特に日本語固有名詞のヒット • 検索漏れがないことを優先したい • スコアリング • Searchのスコアリングと、業務ロジックのスコアリ ングは異なる • 特定 • 検索結果を正しい１件に特定できたと言い切 れるかどうかの判断 30
- 34. 検索ヒット テキスト解析Analyzer • ”Analyze API”でAnalyzer単体を動作確認 可能 • https://docs.microsoft.com/en- us/rest/api/searchservice/test-analyzer 33 Analyzerの種類 解析結果 standard “グロースエクスパートナーズ”, “株”, “式”, “会”, "社" ja.lucene “グロースエクスパートナーズ”, “株式”, “株式会社”, " 会社" ja.microsoft “グロース”, “エクス”, “パートナーズ”, “パトナズ”, “株式”, "会社"
- 35. 検索ヒット • 転置インデックスをクエリーで検索 • 次ページ以降の例は、企業名のインデックス フィールドに”ja.microsoft“のAnayzerを指定 した場合の例 • クエリの種類 • 通常の検索 • フレーズ検索 • ワイルドカード検索／正規表現検索 • あいまい検索 34
- 36. 検索ヒット クエリの種類（1/4） 通常の検索 • 検索文字列はAnalyzerで解析されて、転 置インデックスを検索 35 “name:三菱東京UFJ銀行“ ⇒”三菱” ,”東京” ,”UFJ”, ”銀行” ⇒HITする “name:グロースエ“ ⇒”グロー” ,”スエ” ⇒HITしない トークン ドキュメント 三菱 三菱UFJ銀行 UFJ 三菱UFJ銀行 銀行 三菱UFJ銀行 グロース グロースエクスパートナーズ株式会社 エクス グロースエクスパートナーズ株式会社 パートナーズ グロースエクスパートナーズ株式会社 パトナズ グロースエクスパートナーズ株式会社 株式 グロースエクスパートナーズ株式会社 会社 グロースエクスパートナーズ株式会社
- 37. 検索ヒット クエリの種類（2/4） フレーズ検索 • 同様に検索文字列はAnalyzerで解析され て、転置インデックスを検索するが、トークン順 が一致した場合にHITとなる 36 トークン ドキュメント 三菱 三菱UFJ銀行 UFJ 三菱UFJ銀行 銀行 三菱UFJ銀行 グロース グロースエクスパートナーズ株式会社 エクス グロースエクスパートナーズ株式会社 パートナーズ グロースエクスパートナーズ株式会社 パトナズ グロースエクスパートナーズ株式会社 株式 グロースエクスパートナーズ株式会社 会社 グロースエクスパートナーズ株式会社 “name:¥”三菱東京UFJ銀行¥”“ ⇒”三菱” ,”東京” ,”UFJ”, ”銀行” ⇒HITしない（間に”東京”が 入っているため） “name:¥”三菱UFJ銀¥”“ ⇒”三菱”, “UFJ”, “銀” ⇒HITしない（”銀”はない）
- 38. 検索ヒット クエリの種類（3/4）ワイルドカード検索／正規 表現検索 • 検索文字列は解析されずに転置インデックス を検索 37 トークン ドキュメント 三菱 三菱UFJ銀行 UFJ 三菱UFJ銀行 銀行 三菱UFJ銀行 グロース グロースエクスパートナーズ株式会社 エクス グロースエクスパートナーズ株式会社 パートナーズ グロースエクスパートナーズ株式会社 パトナズ グロースエクスパートナーズ株式会社 株式 グロースエクスパートナーズ株式会社 会社 グロースエクスパートナーズ株式会社 “name:三菱UFJ銀*“ ⇒HITしない “name:銀*“ ⇒HIT（”銀行” ）
- 39. 検索ヒット クエリの種類（4/4）あいまい検索 • 解析されずに転置インデックスを検索、指定し た文字数の不一致を許容する 38 トークン ドキュメント 三菱 三菱UFJ銀行 UFJ 三菱UFJ銀行 銀行 三菱UFJ銀行 グロース グロースエクスパートナーズ株式会社 エクス グロースエクスパートナーズ株式会社 パートナーズ グロースエクスパートナーズ株式会社 パトナズ グロースエクスパートナーズ株式会社 株式 グロースエクスパートナーズ株式会社 会社 グロースエクスパートナーズ株式会社 “name:グロウス~1“ ⇒HIT（“グロース”と１文字 違いのため） “name:グロウスエクスパート ナーズ~1 “ ⇒HITしない（転置インデッ クスは分割されているため） ※Analyzerにja.luceneを選択 している場合は分割されない ためHIT
- 41. 検索ヒット • 日本語固有名詞については、SQLのlike検 索（%query%）に比べて、必ずしも検索 精度は高くならない • なぜヒットする／しないのかを説明しづらい、と いう課題も大きい 40
- 42. 検索ヒット • 「入力の末尾欠落」「１文字打ち間違え」な ど優先して救いたいパターンを考えて、複数の インデックスフィールド＆クエリを組み合わせる • クエリであいまい検索を使うのであれば、分割さ れすぎないAnalyzerを使う方が有利なケース も • 複数のクエリを組み合わせる場合は、ノイズが 増えるだけでなく、性能面も検証が必要 41
- 44. スコアリング • TF-IDF • たとえば「株式会社」「銀行」のような単語は多くの企業 名に含まれるため、単語の特徴度は低く、スコアに対す る影響度は小 ⇒ 今回の要件との合致度は高い 43 https://www.slideshare.net/decode2016/dev018azure-search-deep-dive/30
- 45. スコアリング • TF-IDF • たとえば「株式会社」「銀行」のような単語は多くの企業 名に含まれるため、単語の特徴度が低くなり、スコアに 対する影響度は小 ⇒ 今回の要件との合致度は高い 44 https://www.slideshare.net/decode2016/dev018azure-search-deep-dive/30 イメージ 検索条件 ・グロースエクスパートナーズ株式会社 スコア順 ①グロースエクスパートナーズ株式会社 ②グロースエクスパートナーズ有限会社 ③日本マクロソフト株式会社
- 47. スコアリング • Searchの検索結果のスコアリングと、業務ロ ジックのスコアリングは異なる • Searchが返却した上位100件を、業務ロ ジックでスコアリングして並び替えて返却 • Searchのスコアリングで上位100件に入らない と、業務ロジックのスコアリング対象にならず、返 却候補から漏れるリスクはある • Searchスコアリングでのソート順を、なるべく業 務ロジックに近づけたい 46
- 48. スコアリング • スコアリングプロファイルで、各フィールドに対し てウェイトを設定 • 例）企業名の重みづけを大きくしている • 「同一企業名で別住所」「同一住所で別企業 名」 ⇒ユニーク度が住所 ＞企業名と判定され、 「同一住所で別企業名」が優先されすぎたため • 実データを使って試行錯誤して、Searchの ソート順を、業務ロジックでのスコアリング結果 になるべく近づけている 47
- 49. 特定 • 今回の検索システムでは、検索結果を１件の取 引先に特定できたかどうか（検索結果を人が チェックする必要があるかの判定）が重要 • 例）同じ粒度の検索条件を入力しても、「三越 伊勢丹 東京都」「三越伊勢丹 京都府」では１ 件に特定できた度合いは異なる • 例）検索条件の企業名に多少の入力誤りが あっても、住所と電話番号が一致していれば特 定としたい 48
- 50. 特定 • １位のレコードのスコア自体が十分に高いこと、 ２位以下とのスコア差が大きいこと、のような 「特定」の定義を整理 • この際、Searchのスコアは利用していない • Searchの外の業務ロジックとして実装 49
- 51. Searchを使った検索＆スコアリング • 全文検索エンジンがよろしくやってくれること ⇔ 仕様として説明できること（なぜこの結果が返っ てくるのか）、にはトレードオフがある • どこまでSearchに委ねるか？ • （Search完全依存）Searchの返却結果を、そ のまま返却 • （中間）Searchの返却結果を、業務ロジックで スコアリングして並び替えて返却 ⇒ 今回 • （完全自前処理）検索都度、検索対象全デー タを分散処理にて業務ロジックでスコアリング、上位 を返却 50
- 52. まとめ 51
- 53. まとめ • Azureのマネージドサービスを組み合わせて検 索サービスを構築 • 検索インデックス作成は、イベント駆動バッチ 処理で構築して、非機能面を調整（処理時 間、回復性＆監視） • マネージドサービスを利用することで、コアであ る「検索」の調整に注力できた 52
- 54. 53 ありがとうございました。