Amazon OpenSearch Serviceでクラスタを立ち上げてみた（入門）

Amazon OpenSearch Serviceの超初歩的なやってみた系記事です。なんやかんやあってAmazon Elasticsearch Serviceから名称が変わりましたAmazon OpenSearch Serviceですが、良くも悪くもDevelopersIOにはディープな記事しかなく、意外とネットにも落ちてなかったので手順を残しておきます。

ドメイン作成

早速AWSマネジメントコンソールからOpenSearchのページに行きます。ドメインの作成をクリックします。

ドメインの設定画面です。かなり細かく設定できるみたいなので、一つずつ解読していきます。

まずドメイン名とカスタムエンドポイントです。ドメイン名は任意の値を入力します。カスタムエンドポイントは、OpenSearchが自動生成するエンドポイントでなく、AWS Certificate Managerに登録した自身のエンドポイントを使用するための設定項目です。今回は使用しません。

続いてはデプロイタイプです。今回はマルチAZでの挙動を見てみたかったので、本番稼働用を選択しました。バージョンは2021年11月5日時点でのOpenSearchの最新バージョン1.0、Elastic系の他製品との互換性は特に意識しないので、チェックマークは入れません。

自動調節（Auto-tune）は、ワークロードに応じてクラスタのパフォーマンスを自動でチューニングしてくれる機能です。一部のチューニングではBlue/Greenデプロイメントが実施されますが、あらかじめメンテナンスウィンドウを定めることができます。

データノードで、インスタンスタイプやノード数を決めます。今回は2AZ構成のr6g.large.searchを選択しました。r6gはメモリ最適化のインスタンスタイプで、largeの場合$0.202/hourかかります。一番安いt3.small.searchは$0.056/hourですが、メモリハングリーなElasticsearchでもちゃんと動んですかね…？それ以外の項目は全てデフォルトの設定のままにしました。

ちゃんとしたサイジングが知りたい方は、AWS公式のSizing Amazon OpenSearch Service domainsをご参照ください。

OpenSearch Serviceの専用マスターノードでは、分散クラスタが採用されており、可用性の観点からノード数3がおすすめみたいです（贅沢）。というより、本番用では3未満は選べないようになっています。

UltraWarmは、大量のデータを高コスパで補完できるストレージ層です。Amazon S3とAWS Nitro Systemによって実現されている技術です。詳細は以下をご覧ください。

今回のケースでは追加ストレージは不要なので有効化しません。スナップショットは毎時で固定されているので変更できません。

ネットワークの設定です。今回はVPCに配置されるように設定しています。

きめ細かなアクセスコントロールでは、マスターユーザーを既存のIAM ARNを使って設定するか、手動で作成するか選択できます。今回は既存のIAM Roleを設定します。

OpenSearch DashboardsとKibana用にSAML認証やAmazon Cognito認証が設定できます。またドメインレベルのアクセスポリシーでは、セキュリティグループで許可されクラスタに到達したリクエストに対して、さらにIAMベースのアクセス制御を行うことができます。今回はいずれも設定しません。

最後に暗号化です。きめ細かなアクセスコントロールを有効にすると、暗号化も自動的に全て有効化されるようです。AWS所有キーとKMS管理のキーのどちらかを選択できます。デフォルトのAWS所有キーを選択したままにします。

以上で設定は完了です。作成をクリックするとクラスタが開始します。しばらくするとActiveに変わります。

UIからわかること

まず、トップの一般的な情報にあるOpenSearch Dashboardsのエンドポイントへは、VPCに配置されているクラスタの場合アクセスできません。プロキシサーバーを立てるなどして工夫する必要があります。とはいえそれ用にサーバー立てるのも面倒なので、今後のアップデートに期待ですね。

クラスターのヘルスでは、各種メトリクスのモニタリングが可能です。検索関連のパフォーマンスも見れます。

インスタンスのヘルスでは、ノード単位でCPU利用率やメモリプレッシャーを確認することができます。

あとは先ほど設定した項目が並ぶ感じです。このUIは設定項目の変更やメトリクスの確認などに使うぐらいでしょうかね。基本、クライアントからエンドポイントに対してアクセスするだけのシンプルな使い方になりそうです。

所感

結果、まだElasticsearchからフォークしただけのサービスだなという印象でした。今後、AWSネイティブの検索エンジンとしてアーキテクチャが刷新され、最適化されていくと使い勝手が良くなりそうですね。実績はあるので現段階でも実用には足りますが、今後の動向に期待という感じです。