200ミリ秒の検索APIをMicrosoft Azureでデザインする

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で実現するシステムデザインを紹介しました。

「えっ、実際の作り方は書かないの?」という声が聞こえてきそうですが、その辺は公式ドキュメントや有志のブログに書いてあることしかやっていません。

強いてあげるとすれば、前回のエントリで書いたようなはまりどころがあるくらいですので、そちらを見ていただきたいと思います。

参考にしたドキュメント・ブログ

YAPC::Fukuoka 2017 Hakataにて登壇することが決まりました

7/1(土)に開催されるYAPC::Fukuoka 2017 Hakataへの登壇が決まりました。

発表タイトルはBe PaaS Monger – クラウドエンジニアの三大美徳、またはIaaSを使わない3つの理由となります。

上記のセッションでは、PaaSを使ったシステム設計・構築におけるマインドセットを、プログラマの三大美徳になぞらえて解説します。

クラウドの運用に人手がかかっていてお悩みの方、PaaSという物がよくわからないという方などに向けた内容となる予定です。

Tumblrに引越しました

横着しに来ました。

今まで技術系エントリをRiji + Docker Cloud + Digital Ocean と言う構成でちょいちょい頑張ってきました。

技術的には結構チャレンジングで面白い構成でしたし、何だかんだでそこそこ安定稼働していた構成だったのですが、後述する様な問題があって、ちょっとそのまま継続するのもなんか無駄があるなぁと思い立ち、この度Tumblrにメインの技術系ブログをお引越しすることに決めました。

そもそもブログのためにコンテナを起動するのは大鉈

「ブログサービスがいっぱいある世の中ですし、それらのうちのどれかを使えばいいじゃないの」と言うのが正直な感想です。

ただ、そこそこの期間Dockerで安定稼働させたという実績は作れたのかなぁ・・・

まあ今となってはどうでもいいですね。

更新のたびにリロード作業を行うのが面倒

Riji自体がそもそも多分Staticなコンテンツを生成して使ってくださいね、という代物だと思うんですが、それをわざわざ riji serve して頑張ってたのはちょっと無駄が過ぎましたね。

そんなもんで、何かエントリを書いた後はコンテナのリロードが必要だったりしたんです。まぁ本当に無駄な労力ですね。我ながらご苦労さんなこった、と思います。

とはいえこちとら趣味でやってるだけなんで、無駄だろうがなんだろうが知ったこっちゃないんですがねw

Digital Oceanに微量ながらお金がかかる

Digital Oceanは確かにやっすいんですが、いちいち利用料をチャージしておくのがだるいし、1ヶ月で牛丼並盛りが1杯食えるくらいのお金を持って行かれるので、じゃあその分牛丼に回したほうがQoL高いんじゃね?と思ったわけです。

Dockerコンテナのご機嫌を見るのがだるい

そんなにコンテナがご機嫌を悪くすることってないんですけど、高々ブログの運営に、何らかの技術的問題を自力でどうにかするのってちょっと省エネではないなぁって思いました。

時折あったのが、haproxy:latestがなぜか固まってしまって、全くブログが見れなくなってしまうという現象。多分これはdigital oceanのdroplets(kvm?)との食い合わせの問題なのかなぁ?と考えてますが、もう使わないしいいや・・・

まとめ

技術的な趣味というか実験というか、そういうのを兼ねてDockerを使ってブログを公開してきましたが、億劫になってしまったのでTumblr寄せすることにしました。

なお、過去のブログは新しい順に以下の通りとなっております(引越し2回目)。

それでは今後もよろしくお願いします。