JAZUG7周年総会でお話ししたAzure Searchの適用パターンのお話しです。

1. Azure Serach クックブック
JAZUG 7周年総会
2017.9.9

2. 「三宅@ZEN」
 株式会社ゼンアーキテクツ共同創業者CTO
﹣常時5〜10のAzure導入プロジェクトに参画
 コミュニティ等
﹣Microsoft MVP (Data Platform)
﹣「PaaSがかり」ブログやってます
﹣Xamarin、Vue.jsなども好き
 その他どうでもいいこと
﹣ 元銀行員
﹣趣味はラジコンのレース（わりとガチ）
Blog: k-miyake.github.io/blog/
Twitter: @kazuyukimiyake

3. Azure Search使ってますか？
 世の中的にあまり使われている気がしない..
 最近、記事やセッションもあまりみかけない..
• 自分のプロジェクトでは約8割でSearchを利用してます

4. Azure Search利用事例
API Apps
Search
Cosmos
DB
Blob
Storage
認証
App Service
Microsoft Azure
Storage
Queue
Blob
Storage
Functions
Storage
Queue
Cosmos
DB
Cognitive
Services
Machine
Learning
Functions
PC Clients(Windows/Mac)Mobile Clients(iOS/Android)
API Gateway
外部システム
Application
Insights
Azure
Monitor
Web Apps
Token
.NET
Identity Framework
REST/OAuth2
SPA (Browser App)SPA (Browser App)
負荷モニター/オートスケール
「一覧」「絞り込み」「全文検索」
などのフロント機能はAzure Searchを利用
富士フイルム「IMAGE WORKS」

5. IMAGE WORKS：一覧画面
一覧表示
全文検索

6. Azure Searchおすすめコンテンツ
de:codeセッション資料
﹣日本MSブラックベルトの川崎さん
﹣2016と2017どちらも参考になります
• 2016: https://channel9.msdn.com/Events/de-code/2016/DEV-018
• 2017: https://channel9.msdn.com/Events/de-code/2017/DI08
日経クラウドファースト9月号
﹣全文検索サービス特集（AWSの記事もあり）
﹣Azrure Searchの執筆はZEN岡・三宅で担当しました

7. 本日のAgenda
1. Azure Searchおさらい
2. Azure Search適用パターン
3. デモなどその他

8. 1. Azure Searchおさらい

9. Azure Searchの位置付け
Azure PaaS(SaaS説あり)の検索サービス
﹣検索エンジン
﹣インデックス（データ）
﹣インデクサー（クローラー）
Elasticsearchがベース
﹣Azure上のFess的位置付け
• Fess: Apache Solrを使った検索サーバ

10. Azure Searchの全体像
Blob StorageTable StorageAzure
SQL Database
Cosmos DBAzure VM の
SQL Server
Index
Indexer
Search Engine
Parser
Analyzer
Azure Search
検索文字列
検索クライアント
検索対象データソース
検索処理
インデクシング
データ蓄積 テキスト解析

11. Azure Searchの処理フロー
Parser
Search
Engine
Analyzer
Indexer
インデックス
Analyzed
terms
Query
terms
Query
tree
Query
text
Documents
terms
Analyzed
terms
Retrieve Ingest
Analyzer
検索処理
• トークンの引き当て
• ランキング処理• クエリ文の解析
• 内部クエリ―形式に変換
テキスト解析、トークンの展開
転置インデックス
インデクシング
JSON
ドキュメント

12. Azure Searchの特長
OSSの技術を応用
﹣Elasticsearch、 Lucene
インデクサーがある
﹣Azureの各データストアと連携
選択可能なアナライザー
検索クライアントの各種サポート機能
﹣フィルタ、ファセット、サジェスト etc..

13. インデクサー（Index Writer）
インデックス（データ）を作成する処理系
﹣≒クローラー
﹣全文検索システムでわりとハードルが高い分野
Azureの各データストアと連携
﹣SQL DB、Cosmos DBなど
﹣基本はコード不要
カスタムインデクサー
﹣コードによるカスタマイズ
Indexer
Documents
terms
Analyzed
terms
Analyzer
インデクシング
インデックス

14. アナライザー
テキストを解析してトークン化する処理系
２つのアナライザーから選択可能
﹣Lucene Analyzer（ElasticsearchやSolrでも採用 ）
﹣Microsoft Analyzer
日本語サポート
﹣ja.lucene（kuromoji）
• 形態素解析ライブラリ
• https://github.com/atilika/kuromoji
Parser
Analyzer
Indexer
Analyzer
Analyzed
terms
Query
terms
Documents
terms
検索処理 インデクシング
テキスト解析、トークンの展開

15. スコアリング
検索ランキングの算出
﹣クエリに対するドキュメントの関連性の評価結果がソート
された結果
﹣SQLのLikeと最も異なる点
TF-IDFでスコアリング
﹣文書の中でのそのキーワードの重み、特徴度を表す値
スコアリングプロファイルのチューニング
﹣Tagブースト、freshnessブースト etc.

16. 基本的な検索
全文検索
﹣ドキュメントから文字列を評価
﹣アナライザーを使う
• Lucene query syntaxが使える
• “queryType”: “full”
フィルター
﹣特定フィールドの絞り込み
﹣SQLのWhere句に近い
﹣Odata式を使う
{
"wikipediaid": 1836865,
"name": "ホンダ・ビート",
"note": "ビート（Beat）は、本田技研工業がかつて生
産、販売していたオープン2シーターの軽自動車であ
る。",
"constructor": "ホンダ",
"drive": "MR",
"year": 1991,
"id": "3e3fba2d-5400-4dd9-9f83-dfdd1b4e830a"
}
“filter”: “constructor eq ‘ホンダ’ and year gt 1989”
“search”: “オープン 軽自動車"

17. ファセット・ナビゲーション
ドリルダウンナビゲーションを提供するフィルター処理の一種
スキーマで「facetable:true」で登録されているフィールドを使用
/indexes/rcindex/docs?...
&facet=review
&facet=price
&facet=condition
&search=タミヤ%20ラジコン

18. その他の検索サポート機能
サジェスト
ヒット文字列の強調表示（ハイライト）
ソート/ページング
地理空間検索

19. 検索トラフィック分析
Blobストレージへの出力
Application Insightsと連携
﹣検索要求が発行されるタイミングで、
Application Insights のカスタムイベントを発行する
appInsights.trackEvent( "Search", {
SearchServiceName: "<service name>",
SearchId: "<search id>",
IndexName: "<index name>",
QueryTerms: "<search terms>",
ResultCount: "<results count>",
ScoringProfile: "<scoring profile used>"
});

20. プロビジョニング
サービスの導入自体はシンプル
﹣リソース名とSKUを決めるくらい
リージョン
﹣国内は西日本のみ…
﹣データソースと同一が望ましい
リソースグループグループ
﹣データソースと同一だと、インデクシングで少し楽に

21. スケール
スケールアップ
﹣Free、Basic、Standard(S1, S2, S3)
スケールアウト(Standard)
﹣レプリカ: 検索サイドのスケール
﹣パーティション: データサイドのスケール
注意したいこと
• 料金は レプリカ x パーティションで算出される！
• スケールアップは再プロビジョニングが必要（残念・・）。

22. 2. Azure Search適用パターン

23. 適用パターン
パターン1: RDB負荷軽減パターン
パターン2: Cosmos DB併用パターン
パターン3: Office文書検索パターン

24. パターン1: RDB負荷軽減パターン
 解決する課題
﹣SQL DatabaseなどRDBへのクエリー負荷を軽減し、全文
検索も実現したい。
RDBにAzure Searchを組み合わせることで、絞り
込み検索や一覧表示に使うクエリー機能をAzure
Searchにオフロードする

25. RDB負荷軽減パターンのアーキテクチャ
Search
App Service
Web Apps
SQL Database
自動インデクサーによる
差分データ更新
検索結果・
ファセット・
スコア
・ 一覧・絞り込み、検索はSearchへ
・ 詳細データ取得・更新はSQL DBへ
絞り込み検索／
全文検索
詳細データ取得・更新
（キーによるアクセス）

26. パターン1のねらい・期待効果
 RDB側へのクエリー負荷を軽減
﹣（余裕すぎる）パフォーマンスレベルの見直しが可能（かも）
 一覧、絞り込み機能のユーザビリティ改善
﹣一覧表示パフォーマンス向上
﹣ファセット・ナビゲーションの利用
 全文検索機能の提供
﹣Like検索では実現できなかった精度の高い全文検索
• 高精度: 関連性、スコアのある検索結果

27. 自動インデクサーの活用
 コード不要でインデックスの作成・更新が可能
﹣新規作成時は「データのインポート」機能で完結
• クエリである程度のデータ調整が可能
﹣更新はSearchに付属のスケジューラが定期実行
サポートされているデータソース
Blob StorageTable StorageAzure
SQL Database
Cosmos DBAzure VM の
SQL Server

28. データソースの設定
SQL DBは、GUIの場合、単一のテーブル
／ビューのみ選択可能。
データソースをカスタマイズしたい場合
は、REST API か SDKを使う

29. インデックススキーマの設定
フィールドの定義
﹣データ型
﹣各種プロパティ
作成方法
﹣ポータル（GUI）
﹣REST API, SDK
プロパティはを変更するには
インデックス全体の再作成となる。

30. インデクサーの設定
 スケジュール
﹣実行タイミング
﹣頻度
﹣開始時刻
 詳細オプション
﹣エラー関連
﹣バッチサイズ

31. クエリ例: 全文検索
// クエリ（REST）
POST https://*******.search.windows.net/indexes/carindex-sql/docs/search?api-version=2016-09-01
Content-Type: application/json
Accept: application/json
api-key: *************
{
"search": "オープン2シーター",
"select": "Name, Constructor, Note"
}
// 結果
{
"value": [
{
"@search.score": 0.8203498, "Name": "ホンダ・ビート", "Constructor": "ホンダ",
"Note": "ビート（Beat）は、本田技研工業がかつて生産、販売していたオープン2シーターの軽自動車である。"
},
{
"@search.score": 0.6801461, "Name": "S2000", "Constructor": "ホンダ",
"Note": "S2000（エスにせん）は、本田技研工業がかつて生産、販売していたFRオープン2シーターのスポーツカーである。"
},
{
"@search.score": 0.5865794, "Name": "トヨタ・MR-S", "Constructor": "トヨタ",
"Note": "トヨタ・MR-S（エムアール-エス）とは、オープンタイプ（手動ソフトトップ）のスポーツカーで・・・（以下省略）。"
}]
}
全文検索の文字列と、検索結果で表示し
たいフィールドを指定
アナライザーによってヒットしたと
思われる単語
検索結果スコア

32. クエリ例: フィルタとファセット
// クエリ（REST）
POST https://*******.search.windows.net/indexes/carindex-sql/docs/search?api-version=2016-09-01
Content-Type: application/json
Accept: application/json
api-key: *************
{
"filter": "Year gt 1987 and Year lt 1994",
"facets": [ "Year", "Constructor" ]
}
// 結果
{
"@search.facets": {
"Year": [
{ "count": 4, "value": 1989 },
{ "count": 4, "value": 1992 },
{ "count": 3, "value": 1990 },
（以下省略）
],
"Constructor": [
{ "count": 3, "value": "ホンダ" },
{ "count": 2, "value": "フェラーリ" },
{ "count": 2, "value": "ポルシェ" },
（以下省略）
]
}
}
フィルタの条件式（Odata式）とファセット
の結果を表示したいフィールドを指定
「Year」で絞り込まれた結果を、ファセッ
トの結果（Year毎の集計件数）
「Year」で絞り込まれた結果と、ファセット
の結果（Constructor毎の集計件数）

33. 参考: REST（POST）のRequest Body
{
"count": true | false (default),
"facets": [ "facet_expression_1", "facet_expression_2", ... ],
"filter": "odata_filter_expression",
"highlight": "highlight_field_1, highlight_field_2, ...",
"highlightPreTag": "pre_tag",
"highlightPostTag": "post_tag",
"minimumCoverage": # (% of index that must be covered to declare query successful; default 100),
"orderby": "orderby_expression",
"scoringParameters": [ "scoring_parameter_1", "scoring_parameter_2", ... ],
"scoringProfile": "scoring_profile_name",
"search": "simple_query_expression",
"searchFields": "field_name_1, field_name_2, ...",
"searchMode": "any" (default) | "all",
"select": "field_name_1, field_name_2, ...",
"skip": # (default 0),
"top": #
}
検索: https://docs.microsoft.com/ja-jp/rest/api/searchservice/search-documents
luceneクエリ: https://docs.microsoft.com/ja-jp/rest/api/searchservice/lucene-query-syntax-in-azure-search

34. [DEMO]
 SQL DBからのインデックス作成
 REST APIによるクエリ

35. パターン2: Cosmos DB併用パターン
解決する課題
﹣高速なNoSQLデータベースのCosmos DBを利用したい
が、コストはある程度抑えたい。
Azure Searchを併用することで、Cosmos DBへの直接クエ
リーを減らしスループットのコスト（RU）を平準化す
る

36. Cosmos DBのポータル
ポータルにメニューあり
Cosmos DBとSearchは
相性が良い
﹣Searchの利用が前提？

37. Cosmos DB併用パターンのアーキテクチャ
Cosmos DB
(DocumentDB API)
Search
App Service
Web Apps
絞り込み／
全文検索詳細データ参照
データ更新とほぼ同時に
インデックスが更新される
Storage Queue
更新トリガー
更新元
インデックス更新データ更新
Functions

38. パターン2の狙い・期待効果
 Cosmos DBではスループット(RU)が事前予約制
﹣スパイクなどに対応するのが（コスト面で）苦労する
﹣特に一覧・検索はRU消費が高くなりがち
 一覧・検索はSearchに逃がす
﹣Cosmos DBへの直接クエリーを減らす
﹣RU消費を安定させる
 ほぼリアルタイムのインデックス更新が可能
﹣非同期更新処理というCosmos DBの特性を生かす

39. リアルタイムにインデックスを更新
 Cosmos DB自体のデータ更新をトリガーにする
﹣キューを介した更新の連鎖
﹣Functions等でのインデックス更新処理
Cosmos DB
(DocumentDB API)
Search
Storage Queue
更新トリガー
Cosmos DBの更新処理
インデックス更新
データ更新

40. インデックス更新Function
public static void Run(string carsQueue, dynamic inputDocument, TraceWriter log)
{
// Searchサービス用クライアントの作成
string searchServiceName = Environment.GetEnvironmentVariable("SearchServiceName",
EnvironmentVariableTarget.Process);
string queryApiKey = Environment.GetEnvironmentVariable("SearchServiceQueryApiKey",
EnvironmentVariableTarget.Process);
SearchServiceClient serviceClient =
new SearchServiceClient(searchServiceName, new SearchCredentials(queryApiKey));
ISearchIndexClient indexClient = serviceClient.Indexes.GetClient("cars");
// CosmosDBから取得したデータをSearch用データ型に変換
var cars = new Car[] {
new Car
{
Id = inputDocument.id,
Wikipediaid = inputDocument.wikipediaid,
Name = inputDocument.name,
Constructor = inputDocument.constructor,
Drive = inputDocument.drive,
Year = inputDocument.year,
Note = inputDocument.note,
Thumbnail = inputDocument.thumbnail
}
};
// インデックスの更新
var batch = IndexBatch.MergeOrUpload(cars);
indexClient.Documents.Index(batch);
}
Cosmos DBのデータJSONからSearchのインデックス
更新用ドキュメントを生成
実際にAzure Searchに更新データを送信
ここまではAzure Searchへの接
続準備
Functionsのデータバインディング設定により入力
データとなるCosmos DBのデータ

41. 参考: データソースの作成（REST）
POST https://****************.search.windows.net/datasources?api-version=2016-09-01
Content-Type: application/json
api-key: ****************
{
"name": "mydocdbdatasource",
"type": "documentdb",
"credentials": { "connectionString": "****************” },
"container": {
"name": "myDocDbCollectionId",
"query": "SELECT c.id, c.name, c.car.drive, c.car.year, c._ts
FROM c WHERE c._ts >= @HighWaterMark"
},
"dataChangeDetectionPolicy": {
"@odata.type": "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
"highWaterMarkColumnName": "_ts"
}
}
データソースが構造化されている場合はここで
クエリをカスタマイズしてフラット化する
（c.car.drive, c.car.yearはフラット化した例）
データ更新の検出ポリシーを定義
（タイムスタンプを使用した 増分更新）

42. [DEMO]
 Azure Functionsによるインデックス更新

43. パターン3: Office文書検索パターン
 解決する課題
﹣一般的な文書ファイル(Excelや Word、PowerPointといっ
たOffice文書 、PDF、プレーンテキスト、CSVなど)の全
文検索環境を簡単に構築したい
Azure SearchのBlobインデクサーを使うことて
゙文書の全文検索を容易に実現する

44. Office文書検索パターンのアーキテクチャ
Search
検索クライアント
Web Appsなど
文書内
全文検索
自動インデクサーによる
文書インデックス作成
検索結果
サポートされている文書
• PDF, HTML, XML, RTF, ZIP
• DOCX/DOC、XLSX/XLS、PPTX/PPT
• MSG , EML
• プレーンテキスト ファイル,
• JSON, CSV
Blob
Storage

45. Blobインデックスの設定
 インデックスに設定するフィールド
﹣idとcontent のみで良い
 クエリ結果には自動的にメタデータが含まれる
﹣ファイル名、パス、サイズ等
﹣コンテンツ種類毎のメタデータ
• PDF: language , author, title
• DOCX: author, character_count, page_countなど
• PPTX: slide_count, title など

46. クエリ例: Blobインデックス
// クエリ（REST）
POST https://*******.search.windows.net/indexes/carindex-sql/docs/search?api-version=2016-09-01
Content-Type: application/json
Accept: application/json
api-key: *************
{
"search": "レガシー",
"highlight": "content"
}
// 結果
{
"value": [
{
"@search.score": 0.105222605,
"@search.highlights": {
"content": [
“『変わらない開発現場』を変えていくためにnn～エンプラ系<em>レガシー</em> SIer のための DevOps 再入門
～n#decode17 #DO08n赤間 信幸nhttp://blogs.msdn.com/b/nakama/
・・・（以下省略）,
"metadata_storage_name": "DO08.pptx",
"metadata_storage_path": “aHR0cHM6Ly9taXl ha2VzZXJjaGRlbW8uYmxvYi5jb3JlLndpbmRvd3Mubm....”,
"metadata_title": "PowerPoint プレゼンテーション"
ヒットした文字列は<em>タグで、ハ
イライト表示されている
Blobの検索対象、ハイライト対象は
通常「content」となる
PPTX用のメタデータが出力される

47. 3. Searchを本気で使うために

48. 高負荷対策
レプリカ
﹣検索サイドのスケール
• クエリ操作の負荷分散
パーティション
﹣データサイドのスケール
• インデックスのストレージと I/O

49. 高可用性設計
 レプリカによる対応
﹣クエリの高可用性
• 2レプリカ以上
﹣クエリ、インデックス更新の高可用性
• 3レプリカ以上
 DR対応
﹣Geoレプリケーションなどの仕組みはない
﹣各リージョンで同一インデクサーを動かすことで実現

50. Searchクライアントの設計アプローチ
 Web API（ + SDK）経由
﹣.NET SDK限定
﹣WebAPIにて統合が可能（認証、他のデータ）
 ダイレクト（+ REST API）
﹣JavaScriptでブラウザからAzure Searchに直接クエリー
﹣クエリーキー（読み取り専用）を事前にWebAPI等で配布

51. まとめ
 Azure Searchは圧倒的に導入の敷居が低い
 データとサービスは適材適所で使い分ける
Azure Application Architecture Guide > Technology Choices > Choose the right data store
https://docs.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/data-store-overview#search-engine-databa

53. ご清聴ありがとうございました。