博士

ロボ子、今日のITニュースはサーバーレス環境での検索エンジンじゃ。

ロボ子

サーバーレスで検索エンジンですか、博士。それは面白いですね。

博士

そうじゃろう？ NixiesearchをAWS Lambdaで動かす話じゃ。

ロボ子

AWS Lambdaですか。でも、コンテナサイズとか起動時間が課題になりそうですね。

博士

さすがロボ子、よく分かっておるのじゃ。Elasticsearch 9.xだとコンテナサイズが約700MB、起動に約40秒もかかるからの。

ロボ子

それは大変ですね。スケール・トゥ・ゼロ時の状態管理も問題になりそうです。

博士

そこで、GraalVM native-imageの出番じゃ！ JVMアプリをネイティブバイナリにコンパイルして、Dockerイメージサイズを小さくするのじゃ。

ロボ子

なるほど、ubuntuベースで338MB、Muslベースだと244MB、`FROM scratch`だと248MBまで小さくなるんですね。

博士

その通り！ そして、AWS Lambdaを使えば、最小限の起動時間でスケールアップ・ダウンの問題を解消できるのじゃ。

ロボ子

インデックスの保存場所はどうするんですか？

博士

S3に置くか、AWS EFSを使うかの二択じゃな。S3ならLuceneインデックスを直接アクセスできるし、EFSならNFSストレージに置けるのじゃ。

ロボ子

S3直接検索はコストが高いんですね。セグメントレプリケーションなら低コストだけど、初期化に時間がかかると。

博士

そうそう。EFSは妥当なコストじゃが、ディスクアクセスにレイテンシが発生するのじゃ。

ロボ子

FineWikiの30万ドキュメントをOpenAIで埋め込んで、AWS LambdaとEFSにデプロイした実験結果もあるんですね。初回リクエストのレイテンシが1.5秒ですか。

博士

NFSスタイルのストレージからのランダムリードが遅いのが原因じゃ。EFSの読み込みレイテンシは約1msらしいぞ。

ロボ子

今後の展望としては、HNSWの代わりにIVFのようなデータ構造を使うとか、HNSWグラフの探索を並列化するとか、色々考えられるんですね。

博士

その通り！ 検索エンジンをLambdaに組み込むのは可能じゃが、AWS Lambdaのストレージシステムとランタイムセマンティクスは特殊じゃから、工夫が必要じゃな。

ロボ子

ネットワークストレージ上でのHNSW検索は遅い、と。

博士

結論！ 検索エンジンをLambdaに組み込むことは可能！ ただし、色々と癖があるからの、気をつけるのじゃ！

ロボ子

勉強になりました！

博士

ところでロボ子、Lambda関数がフリーズする時、夢を見ると思うか？

ロボ子

え？ 夢ですか？

博士

ラム(RAM)だけに、ラムの夢を見る、…なんちゃって！