Amazon Web Services ブログ

Amazon OpenSearch Serverless が一般利用可能になりました

この記事は、Amazon OpenSearch Serverless is now generally available! を翻訳したものです。

私たちは re:Invent で Amazon OpenSearch Serverless のプレビューでのリリースを行い、2022 年を締め括りました。そして本日、インフラストラクチャの管理を考える必要なく、検索や分析のワークロードを簡単に実行できる Amazon OpenSearch Service のサーバーレスオプションである Amazon OpenSearch Serverless の一般公開を発表できることを嬉しく思います。この投稿では、OpenSearch Serverless のアプローチと高レベルのアーキテクチャをご紹介します。

背景

セルフマネージド OpenSearch とマネージド OpenSearch Service は、ペタバイト級のデータの検索と分析に広く利用されています。どちらのオプションもクラスタ内の CPU、メモリ、ストレージの構成を完全に制御できるため、アプリケーションのコストとパフォーマンスを最適化することができます。

しかし、使用状況が常に把握できないような、変動が激しいアプリケーションを実行することも多いでしょう。このようなアプリケーションでは、データの取り込みが突然急増したり、 不規則で予測不可能なクエリのリクエストが発生することがあります。安定したパフォーマンスを維持するには、常にクラスタのチューニングとサイズ変更を行うか、ピーク時の需要に合わせてオーバープロビジョニングする必要があり、その結果、過剰なコストが発生してしまいます。多くのお客様は、バックエンドのインフラストラクチャやデータ管理を気にすることなくビジネスアプリケーションに集中できるような、よりシンプルな体験を求めていました。

「よりシンプル」とはどのような意味なのでしょうか。それは、以下のタスクに煩わされないということです。

  • インスタンスの選択とプロビジョニング
  • シャードとインデックスのサイズ管理
  • サイジングと運用を目的としたインデックスとデータの管理
  • ワークロードの需要を満たすための継続的な設定の監視とチューニング
  • システム障害やリソースの閾値違反に備えたプランニング
  • セキュリティアップデートとサービスソフトウェアアップデート

これらの課題を、以下のプロダクトテーマのもと、要件と目標に変えていきました。

  • シンプルかつセキュア
  • オートスケーリング、耐障害性、耐久性
  • コスト効率
  • エコシステムの統合

OpenSearch Serverless がこれらのニーズにどう対応しているかを掘り下げる前に、OpenSearch Serverless の対象となるユースケースを確認しましょう。これらのユースケースの特徴は、我々の設計のアプローチとアーキテクチャに大きく影響を与えているからです。

対象となるユースケース

OpenSearch Serverless の対象となるユースケースは OpenSearch と同様です。

  • 機械が生成する大量の半構造化データをリアルタイムで分析し、運用、セキュリティ、ユーザー行動の洞察を得ることに重点を置いた時系列分析 (一般にログ分析とも呼ばれる)
  • 内部ネットワーク内の顧客アプリケーション (アプリケーション検索、コンテンツ管理システム、法的文書など) や、インターネット向けのアプリケーション (E コマースサイトやコンテンツ検索) を強化するためのログ分析

典型的な時系列ワークロードと検索ワークロードの違いを理解しましょう。(例外は異なる可能性があります)

  • 時系列ワークロードは書き込みが多いのに対し、検索ワークロードは読み取りが多い
  • 検索ワークロードは時系列ワークロードと比較してデータコーパスが小さい
  • 検索ワークロードは、レンテンシーに対してより敏感であり、時系列ワークロードよりも高速なレスポンスを求められる
  • 時系列データへのクエリは最近のデータに対して実行されるのに対し、検索クエリはコーパスの全体に対して実行される

これらの特徴は、ワークロードのシャード、インデックス、データの扱いや管理のアプローチに大きく影響を与えました。次のセクションでは、OpenSearch Serverless がこれらのワークロードの特徴に効率的に対応しながら、どのようにしてお客様の課題を解決するかについて説明します。

シンプルかつセキュア

OpenSearch Serverless を始めるには、まずコレクションを作成します。コレクションは、ワークロードをサポートするために連携する、インデックス化されたデータを論理的にグループ化したものであり、物理的なリソースはバックエンドで自動的に管理されます。どれほどの計算資源やストレージが必要かを宣言したり、システムがうまく稼働しているかを監視したりする必要はありません。OpenSearch Serverless は、2 つの所要なワークロードを巧みに処理するために、異なるシャーディング戦略とインデックス戦略を適用しています。そのため、コレクションを作成するワークフローでは、コレクションの種類 (時系列または検索) を定義する必要があります。増大するデータサイズに対応するために、インデックスの再作成やロールオーバについて心配する必要はありません。なぜなら、それらはシステムにより自動的に処理されるからです。

次に、使用する暗号化キー、コレクションへのネットワークアクセス (パブリックエンドポイントまたは VPC)、ユーザーアクセスに関する設定を選択します。OpenSearch Serverless はコレクションとインデックスに対して階層的なポリシーをサポートする、使いやすくて非常に効果的なセキュリティモデルを持っています。全てのコレクションとインデックスに対して、きめ細かなコレクションレベルおよびアカウントレベルのセキュリティポリシーを作成することができます。アカウントレベルのポリシーを一元的に管理することで、包括的な可視化と制御が可能になり、大規模なコレクションが運用上容易になります。暗号化ポリシーでは、単一のコレクション、全てのコレクション、またはワイルドカードのマッチングパターンを使用して一部のコレクションに対して AWS Key Management Service (AWS KMS) キーを指定することができます。複数のポリシーのルールがコレクションに一致する場合、完全修飾名に最も近いルールが優先されます。また、ネットワークポリシーやデータアクセスポリシーでもワイルドカードのマッチングパターンを使用することができます。複数のネットワークポリシーおよびデータアクセスポリシーを 1 つのコレクションに適用することができ、許可は追加されます。コレクションのネットワークポリシーおよびデータアクセスポリシーはいつでも更新することができます。

OpenSearch Dashboards は、SAML および AWS Identity and Access Management (IAM) クレデンシャルを使用してアクセスすることができるようになりました。OpenSearch Serverless は、きめ細かな IAM 権限をサポートしており、誰が暗号化ポリシー、ネットワークポリシー、データアクセスポリシーを、作成、更新、削除できるかを定義し、それによって組織的連携が可能になります。OpenSearch Serverless の全てのデータは、デフォルトで転送時および保管時に暗号化されます。

オートスケーリング、耐障害性、耐久性

OpenSearch Serverless はストレージとコンピュートリソースを分離することで、ワークロードの需要に応じて各レイヤーを独立してスケールさせることができます。この分離により、インデックス用とクエリ用のコンピュートノードも分離され、フリートはリソースの競合なしに同時に実行することができます。CPU、ディスク使用率、メモリ、ホットシャードの状態などの計算リソースはサービスによって監視・管理されます。これらのシステムの値が閾値を超えると、サービスはキャパシティの調整を行います。したがって、リソースのスケーリングを気にする必要がありません。例えば、アプリケーション監視のワークロードで、可用性に関するイベント時に突発的に大量のログを受信すると、OpenSearch Serverless はインデックス用のコンピュートノードをスケールアウトします。これらのログアクティビティが減少し、コンピュートノードのリソース消費量がある閾値を下回ると OpenSearch Serverless はノードをスケールインします。同様に、ウェブサイトの検索エンジンで、ニュースイベントの後に突然大量のクエリを受け取ると、OpenSearch Serverless は自動的にクエリ用のコンピュートノードをスケールアウトして、データ取り込みのパフォーマンスに影響を与えることなくクエリを処理します。

次の図は、その高レベルのアーキテクチャを表しています。

OpenSearch Serverless は、アベイラビリティゾーンの停止やインフラストラクチャの障害に備えて冗長性を持たせた本番環境ワークロード向けに設計されています。デフォルトでは、OpenSearch Serverless はアベイラビリティゾーンの間でインデックスを複製します。インデックス用のコンピュートノードは、アクティブ – スタンバイ構成で実行されます。サービスのコントロールプレーンも、冗長性と自動的な障害回復機能を備えて構築されています。インデックス化された全てのデータは Amazon Simple Storage Service (Amazon S3) に保存され、Amazon S3 と同じデータ耐久性 (イレブンナイン) を提供します。クエリ用のコンピュートインスタンスは、Amazon S3 から直接インデックス化されたデータをダウンロードし、検索処理を実行し、集計を行います。クエリ計算インスタンスは、障害時にも可用性を維持するために、アクティブ – アクティブ構成でアベイラビリティゾーンに渡って冗長化してデプロイされます。リフレッシュ間隔 (OpenSearch Serverless に文書が取り込まれてから検索可能になるまでの時間) は、現在 15 秒以下です。

コストとコスト効率

OpenSearch Serverless では、リソースのサイズ調整やプロビジョニングを前もって行う必要がなく、本番環境でのピークの負荷に備えてオーバープロビジョニングする必要もありません。ワークロードが消費するコンピュートとストレージのリソースに対してのみ支払いが発生します。データの取り込みと検索クエリに使用されるコンピュートキャパシティは OpenSearch Compute Unit (OCU) で測定されます。OCU の数は、データの取り込みやクエリの実行に必要な CPU、メモリ、Amazon Elastic Block Store (Amazon EBS) ストレージ、I/O リソースに直接対応します。1 つの OCU は、6 GB の RAM、1 つの vCPU、120 GB の GP3 ストレージ (非常に頻繁にアクセスされるデータへの高速アクセスを提供するために使用)、そして Amazon S3 へのデータ転送で構成されています。データが取り込まれた後、インデックス化されたデータは Amazon S3 に保存されます。API を使用してデータの保持や削除を制御することもできます。

アカウントに最初のコレクションエンドポイントを作成すると、OpenSearch Serverless は 4 つの OCU (プライマリとスタンバイを含む 2 つの取り込み用のものと、高可用性のための 2 つの複製を含む 2 つの検索用のもの) をプロビジョニングします。これらの OCU は、コールドスタートの遅延を避けるために、エンドポイントにアクティビティがない場合でもインスタンス化されます。そのアカウント内で同じ KMS キーを使用する全てのコレクションは、これらの OCU を共有します。オートスケーリングの間、OpenSearch Serverless はコレクションが必要とする計算をサポートするために OCU を追加します。これらの OCU は、インデックスやクエリのリクエストへの応答を開始する前に、Amazon S3 からインデックス化されたデータをコピーします。同様に、OpenSearch Serverless のコントロールプレーンは、OCU のリソース消費を継続的に監視しています。インデックス作成や検索のリクエストレートが低下し、OCU 消費が一定の閾値を下回ると、OpenSearch Serverless は OCU 数をワークロードに必要な最小容量まで削減します。最小限の OCU により、コールドスタートの遅延を防ぐことができます。

また、OpenSearch Serverless は時系列ワークロードのための組み込みのキャッシュ層を提供し、より良いコストパフォーマンスを提供します。OpenSearch Serverless は、最新のログデータ (通常は直近 24 時間分) をエフェメラルディスクにキャッシュします。24 時間より古いデータについては、OpenSearch Serverless はメタデータのみをキャッシュし、クエリアクセスに基づいて必要なデータブロックを Amazon S3 から取得します。このモデルは、コストを抑制しながらより多くのデータを詰め込むのにも役立ちます。検索コレクションの場合、クエリ用のコンピュートノードは、データコーパス全体をエフェメラルディスクにローカルにキャッシュし、ミリ単位の高速なクエリレスポンスを実現します。

エコシステムの統合

OpenSearch と連携するほとんどのツールは OpenSearch Serverless とも連携します。既存のパイプラインやアプリケーションを書き換える必要はありません。OpenSearch Serverless は、OpenSearch と同じ論理データモデルとクエリエンジンをもっているので、使い慣れたデータ取り込みとクエリの API を使用することができ、サーバーレスの OpenSearch Dashboards でインタラクティブなデータ分析と可視化を行うことができます。OpenSearch Serverless は、その互換性のあるインターフェースにより、既存の豊富な OpenSearch エコシステムである高レベルのクライアントとストリーミング取り込みパイプライン (Amazon Kinesis Data Firehose、FluentD、FluentBit、Logstash、Apache Kafka、 Amazon Managed Streaming for Apache Kafka (Amazon MSK)) をサポートしています。詳細については、Ingesting data into Amazon OpenSearch Serverless collections を参照してください。また、AWS CloudFormation や AWS CDK を使用して、コレクション作成のプロセスを自動化することができます。Amazon CloudWatch の統合により、OpenSearch Serverless の主要なメトリクスを監視し、アラームを設定して閾値の違反を通知することができます。

マネージドクラスターと OpenSearch Serverless のどちらを選ぶか

マネージドクラスターと OpenSerach Serverless は共に、OpenSearch Service のデプロイオプションであり、オープンソースの OpenSearch プロジェクトによって支えられています。OpenSearch Serverless は、周期的、断続的、または予測不可能なワークロードを、OpenSearch クラスターのサイジング、モニタリング、およびチューニングについて考えることなく簡単に実行することができます。しかし、クラスター構成や特定のカスタマイズを厳密に制御する必要があるシナリオでは、マネージドクラスターを使用する方が良いでしょう。マネージドクラスターでは、好みのインスタンスとバージョンを選択でき、リフレッシュ間隔の短縮やデータのシャーディング戦略などの設定をより細かく制御できます。これは OpenSearch Serverless がサポートする典型的なパターンから外れるようなユースケースにとっては重要なことかもしれません。また、OpenSearch Serverless は現在、アラート、異常検知、k-NN などの高度の OpenSearch の機能やプラグインを全てはサポートしていません。OpenSearch Serverless がこれらの機能をサポートするようになるまで、これらの機能のためにマネージドクラスターを使用することができます。

プレビュー版からのアップデート

一般利用可能なリリースでは、OpenSearch Serverless は、ワークロードをサポートするために必要な最小限のリソースへのスケールアウトおよびスケールインするようになりました。1 アカウントあたりの OCU の上限は、インデックス用とクエリ用の OCU の両方とも 20 から 50 に増加しました。さらに、高レベルの OpenSearch クライアントを使用したデータの取り込みやクエリを実行できるようになった他、Logstash を使用して OpenSearch クラスターからデータを移行することも可能です。また、OpenSearch Serverless は追加で 3 つのリージョンをサポートするようになり、現在、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) の世界 8 つのリージョンで利用できます。

要約

サーバーレスの旅はまだ始まったばかりです。初期の努力のほとんどは、増大するパフォーマンスとスケールの要求を効率的にサポートできる適切なサービスアーキテクチャを定義して構築することに費やされました。OpenSearch Serverless はストレージとコンピュートリソースのコンポーネント、そしてインデックス用とクエリ用のコンピュートリソースを分離し、それぞれ独立して管理・スケールすることができます。OpenSearch Serverless はインデックスのプライマリストレージとして Amazon S3 を使用しているため、耐久性を心配する必要はありません。構成の選択と、リソースの適切なプロビジョニングを切り離したため、構成のミスで障害が発生することはありません。OpenSearch Serverless は、将来的にセキュリティとソフトウェアのアップデートも適用しますが、ワークロードを中断させることはありません。この柔軟なマイクロサービスアーキテクチャにより、定期的に新機能を提供し続け、スケールとパフォーマンスの水準を高め、例えば、アクティビティのない時は完全にコンピュートノードを停止させるなど、さらなるコストダウンを推進することができます。

OpenSearch Serverless をぜひお試しいただき、ユースケースや質問などコメント欄でご意見をお寄せください。OpenSearch Serverless を始めるためのリソースは多く用意されています。