Public Preview中のAmazon OpenSearch Serverlessの仕組みやアーキテクチャを確認してみた #reinvent

2022.12.01

prismatixのとばち(@toda_kk)です。

現在開催中のAWS re:Invent 2022にて、Amazon OpenSearch ServerlessがPublic Previewとして発表されました。

すでにAWS公式ブログで概要や構築手順が解説されており、また公式ドキュメントにも記載が追加されています。

本記事では、上記ドキュメントの内容を確認しながらOpenSearch Serverlessの仕組みや制約について記載します。

なお、実際に構築手順を確認した内容については、下記の記事をご参照ください。

ClusterやDomainではなくCollection

通常のOpenSearchであれば"Cluster"、マネージドなAmazon OpenSearch Serviceでは"Domain"という単位でリソースを管理しますが、Serverlessでは"Collection"という単位になるようです。

Collectionは、特定のワークロードやユースケースに向けたIndexの集まりを差ます。おそらく、OpenSearchを構成するリソースであるノードを管理する必要がないため、Clusterとは別の概念としてCollectionという用語を用意したのではないかと思われます。

OpenSearch Serverlessを構築する際は、このCollectionを作成することになります。

Collection Type

また、Collectionには現在下記2つのTypeがあり、構築の際には2つのうちから1つを選択します。

  • Time series
    • 時系列データのログ分析用途
    • 頻繁にアクセスされるデータはhotストレージ、それ以外はwarmストレージに保存される
    • ドキュメントIDを指定したIndexingや検索ができない(APIが制限されている)
  • Search
    • 全文検索エンジンの用途
    • クエリのレスポンスタイムを維持するために全てのデータがhotストレージに保存される

なお、Collectionの作成後はTypeを変更できないようなので、ご注意ください。

OpenSearch Serverlessの仕組み

OpenSearch Serverlessがどのように実現されているのか、仕組みやアーキテクチャについて記載がありました。

OpenSearch Serverless Architecture
AWS公式ドキュメントより引用

通常のOpenSearchクラスターであれば、データの登録と検索は同じノード/インスタンスで実行されます。しかし、OpenSearch Serverlessでは、データの登録と検索とでコンピューティングリソースが分かれており、ストレージとしてS3が採用されています。

indexリクエストに対しては、データ登録用途のコンピューティングリソースが対応し、S3にデータを保存します。searchリクエストに対しては、検索用途のコンピューティングリソースが対応し、S3からデータを直接ダウンロードしローカルにキャッシュとして保持します。

コンピューティングとストレージでリソースを分けており、さらにデータの登録と検索でコンピューティングリソースを分けることで、用途に応じて柔軟かつ独立したスケーリングが可能となり一貫したパフォーマンスを維持を実現しています。

コンピューティングリソースのキャパシティは、OpenSearch Compute Units(OCUs)という単位で計算されます。各OCUは、6GiBのメモリとそれに対応したvCPUを持ち、最大で約180GiBまでのデータを保持できます。

利用料金

課金体系については、上述のOCUに対する料金と、データを保存するストレージに対する料金があります。

現在は、リージョンによらず一律で下記の金額になっています。

  • OpenSearch Compute Unit (OCU) - indexing: $0.24 / OCU / hour
  • OpenSearch Compute Unit (OCU) - Search and Query: $0.24 / OCU / hour
  • ストレージ: $0.024 / GB / month

最新の情報に関しては、公式ページからご確認いただけますと幸いです。

制約

OpenSearch Serverlessを利用する上で、いくつかの制約があります。詳細については、下記ページをご確認ください。

この中でも、次の点については特に注意が必要かと感じました。

  • 一部のOpenSearch API操作がサポートされていない
  • 一部のOpenSearchプラグインや、カスタムプラグインがサポートされていない
  • OpenSearch ServiceドメインからOpenSearch Serverlessに自動的に移行する方法が提供されていない
  • クロスリージョンやクロスアカウントがサポートされていない
  • Collectionのスナップショットの取得/復元ができない
  • Indexingにおいて、更新間隔(refresh interval)がリクエストのサイズに応じて10〜30秒になる場合がある

Production-Readyとなることに期待

いくつかの制約については今後のアップデートで解決されることを期待していますが、アーキテクチャの違いから発生する制約もあるかと推察されるため、すぐに解決するのは難しいかもしれません。

とはいえ、制約はあるもののクラスター管理が必要なくなることが運用がグッと楽になることが期待されます。

既にOpenSearchをご利用中の方、もしくは利用をご検討中の方など、お使いのワークロードにServerlessがマッチするかどうか、せひ検証してみてください。

以上、prismatixのとばち(@toda_kk)でした。

参考