200ミリ秒の検索APIとは
ここでは、httpクライアントからリクエストを受けてから全文検索を含む何らかの検索処理を行い、httpクライアントにレスポンスを返すまでの処理を、おおむね200ミリ秒(200ms、0.2秒)前後の時間でこなすWeb APIを指します。
検索という機能を考えたとき、200msという数字はまずまず軽快な応答速度ではないかと私は考えます。
今回はAzureの各種サービスを使って検索APIを作った時のノウハウを共有します。このAPIはデータサイズによって多少のばらつきはあるものの、ほぼ200ms前後の応答速度を実現することができております。
以下は、実際の処理履歴となります。おおむね200ms前後で処理が完了し、応答していることが分かると思います。
Microsoft Azureで作る
Microsoft Azure(以下Azure)で検索APIを作るにあたり、以下のようなシステムデザインを行いました。
ある程度Azureに詳しい方であれば、上記の図を見ただけで概ねの構成がご理解いただけると思います。
Azure CDN
いわゆるCDN(Contents Delivery Network)サービスです。今年から動的コンテンツの高速化にも利用できるようになりました。
今回のケースでも「動的コンテンツの高速化」がその利用目的となります。
Azure Functions
実際にhttpリクエストを受け付け、httpレスポンスを返すためのアプリケーション・ロジックをデプロイし、運用するためのFaaSとなります。最近v2がリリースされましたが、私のケースではv1を利用しました。
C#やF#、PHPなどの言語に対応していますが、今回はNode.jsをつかって作ってみました。実際の実装・はまりどころについては前回のエントリにまとめてありますので、そちらも併せてご参照ください。
Azure Search
Apache LuceneクエリやODataフィルタを利用可能な検索エンジンサービスです。
全文検索や緯度経度をもとにした距離検索、ファセットなどにも対応しているため、複雑な検索機能を実装するにはほぼ必須となります。
また、Azure CosmosDBやAzure Table Storageなどから定期的(最短で5分おき)にデータを取り込むIndexerという仕組みがついてきますので、検索結果にリアルタイム性を求めない限り、データのインポートをする仕組みを自分で作る必要がありません。
Azure CosmosDB (または Azure Table Storage)
どちらもスキーマレスなデータストアとして利用できるサービスです。
今回はAzure CosmosDBを利用し、Azure Search向けの一次データをストックしておくデータストアとします。
まとめ
200ms前後の応答速度の検索APIをAzureで実現するシステムデザインを紹介しました。
「えっ、実際の作り方は書かないの？」という声が聞こえてきそうですが、その辺は公式ドキュメントや有志のブログに書いてあることしかやっていません。
強いてあげるとすれば、前回のエントリで書いたようなはまりどころがあるくらいですので、そちらを見ていただきたいと思います。