Amazon Web Services ブログ
Amazon OpenSearch Service で長期ロギング費用を 4,800% 削減
この記事は、 Reducing long-term logging expenses by 4,800% with Amazon OpenSearch Service を翻訳したものです。
サーバーログ、サービスログ、アプリケーションログ、クリックストリーム、イベントストリームなどの時間制限のあるデータに Amazon OpenSearch Service を使用する場合、ストレージコストはソリューション全体における主要なコストの 1 つです。昨年、OpenSearch Service では、ログデータを様々な階層に保存できる新機能がリリースされ、データの待機時間、耐久性、可用性のトレードオフが可能になりました。2023 年 10 月、OpenSearch Service は最大 30TB の NVMe SSD ストレージを備えた im4gn データノードのサポートを発表しました。2023 年 11 月、OpenSearch Service は OpenSearch 最適化インスタンスファミリー or1 を導入し、社内ベンチマークで既存インスタンスに比べ最大 30% のパフォーマンス価格比の改善を実現し、Amazon Simple Storage Service (Amazon S3) を使用してイレブンナインの耐久性を提供しました。最後に、2024 年 5 月、OpenSearch Service は Amazon OpenSearch Service と Amazon S3 の zero-ETL 統合 の一般提供を発表しました。これらの新機能は、既存の UltraWarm インスタンス (GB あたりのストレージコストを最大 90% 削減) と、UltraWarm のコールドストレージ オプション (UltraWarm インデックスを分離し、アクセス頻度の低いデータを Amazon S3 に永続的に保存できる) に加わります。
このポストでは、コスト、レイテンシー、スループット、データの永続性と可用性、保持期間、データアクセスにおける選択肢のトレードオフを理解できるように、例を用いて説明します。これにより、データの価値を最大化し、コストを最小化するための適切なデプロイメントを選択できるようになります。
要件の検討
ロギングソリューションを設計する際は、適切なトレードオフを行う前提条件として、要件を明確に定義する必要があります。レイテンシー、耐久性、可用性、コストに関する要件を慎重に検討してください。さらに、OpenSearch Service に送信するデータ、データの保持期間、そのデータへのアクセス計画を検討する必要があります。
この議論の目的のために、OpenSearch インスタンスのストレージをエフェメラルストレージと Amazon S3 バックドストレージの 2 つのクラスに分けます。エフェメラルドストレージクラスには、Nonvolatile Memory Express SSDs (NVMe SSDs) と Amazon Elastic Block Store (Amazon EBS) ボリュームを使用する OpenSearch ノードが含まれます。Amazon S3 バックドストレージクラスには、UltraWarm ノード、UltraWarm コールドストレージ、or1 インスタンス、および Amazon S3 との Zero-ETL で利用できる Amazon S3 ストレージが含まれます。ロギングソリューションを設計する際は、次の点を考慮してください。
- レイテンシ – ミリ秒単位で結果を必要とする場合は、エフェメラルストレージをバックエンドに使用する必要があります。秒または分単位の結果で許容できる場合は、Amazon S3 をバックエンドに使用することでコストを削減できます。
- スループット – 一般的に、エフェメラルストレージをバックエンドに使用したインスタンスの方がスループットが高くなります。im4gn のように NVMe SSDs を搭載したインスタンスは通常最高のスループットを提供し、EBS ボリュームも良好なスループットを提供します。or1 インスタンスは、プライマリシャードに Amazon EBS ストレージを利用しながら、Amazon S3 とセグメントレプリケーションを活用することで、レプリケーションのコンピューティングコストを削減し、NVMe ベースのインスタンスと同等またはそれ以上のインデックス作成スループットを提供します。
- データ耐久性 – ホット層 (データノード) に格納されたデータは最も低いレイテンシーですが、耐久性も最も低くなります。OpenSearch Service は、レプリカを通じてホット層のデータの自動復旧を提供し、コストを伴いながら耐久性を確保します。OpenSearch が Amazon S3 (UltraWarm、UltraWarm コールドストレージ、Amazon S3 との zero-ETL、or1 インスタンス) に格納するデータは、Amazon S3 のイレブンナインの耐久性の恩恵を受けます。
- データ可用性 – ベストプラクティスでは、エフェメラルストレージのデータにレプリカを使用することを推奨しています。少なくとも 1 つのレプリカがあれば、ノードの障害が発生しても、すべてのデータにアクセスできます。ただし、各レプリカはコストの増加を伴います。一時的な利用不可を許容できる場合は、or1 インスタンスと Amazon S3 ストレージを使用することで、レプリカを削減できます。
- 保持期間 – すべてのストレージ層のデータにはコストがかかります。分析のためにデータを長期間保持するほど、そのデータの 1GB あたりの累積コストが高くなります。すべての価値が失われるまでにデータを保持しなければならない最長期間を特定してください。場合によっては、コンプライアンス要件によって保持期間が制限される可能性があります。
- データアクセス – 一般に、Amazon S3 をバックエンドに使用したインスタンスは、コンピューティングに対するストレージの比率がはるかに高く、コスト削減につながりますが、大量のワークロードには十分なコンピューティング能力がありません。クエリ量が多い、またはクエリが大量のデータにまたがる場合は、エフェメラルストレージをバックエンドに使用するのが適切です。ダイレクトクエリ (Amazon S3 ストレージをバックエンドに使用) は、頻繁にクエリされないデータに対する大量のクエリに最適です。
これらの観点から要件を検討すると、その回答が実装の選択肢を導き出すことになります。トレードオフを判断するために、次のセクションで詳細な例を説明します。
OpenSearch Service のコストモデル
OpenSearch Service のデプロイのコストを理解するには、コストの特徴を理解する必要があります。OpenSearch Service には、マネージドクラスターとサーバーレスの 2 つの異なるデプロイオプションがあります。この投稿ではマネージドクラスターのみを考慮します。Amazon OpenSearch Serverless はすでにデータを階層化し、ストレージを管理してくれるためです。マネージドクラスターを使用する場合は、データノード、UltraWarm ノード、専用マスターノードを構成し、それぞれの機能に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプを選択します。OpenSearch Service はこれらのノードをデプロイ、管理し、REST エンドポイントを介して OpenSearch と OpenSearch Dashboards を提供します。Amazon EBS バックドインスタンスまたは NVMe SSD ドライブ付きインスタンスを選択できます。OpenSearch Service は、マネージドクラスターのインスタンスに対して時間単位の料金を請求します。Amazon EBS バックドインスタンスを選択した場合、サービスはプロビジョニングされたストレージと、構成した プロビジョニング IOPS に対して料金を請求します。or1 ノード、UltraWarm ノード、または UltraWarm コールドストレージを選択した場合、OpenSearch Service は Amazon S3 で消費されたストレージに対して料金を請求します。最後に、転送されたデータに対するサービス料金がかかります。
使用例
コストとパフォーマンスのトレードオフを検討するために、使用例を使用します。この例のコストとサイズは、ベストプラクティスに基づいており、方向性を示すものです。同様の節約効果が期待できますが、すべてのワークロードはユニークであり、実際のコストは本記事で示すものとは大きく異なる可能性があります。
架空の大手清涼飲料メーカー Fizzywig のユースケースを見ていきましょう。飲料の製造工場が多数あり、製造ラインからは膨大なログが出力されています。当初はすべてホットデプロイで 1 日 10 GB のログを生成していましたが、今日では 1 日 3 TB のログデータが発生し、経営陣はコスト削減を求めています。Fizzywig はログデータをイベントのデバッグと分析、および 1 年分のログデータの履歴分析に使用しています。OpenSearch Service でそのデータを保存し利用するコストを計算しましょう。
エフェメラルストレージの導入
Fizzywig の現在のデプロイメントは、エフェメラルストレージを備えた 189 個の r6g.12xlarge.search データノード (UltraWarm 層なし) です。OpenSearch Service でデータをインデックス化すると、OpenSearch はインデックスデータ構造を構築し、ソースデータよりも通常 10% 大きくなります。また、運用オーバーヘッドのために 25% の空き領域を残す必要があります。毎日 3TB のソースデータがある場合、オーバーヘッドを含めてプライマリ (最初のコピー) に 4.125TB のストレージが必要になります。Fizzywig は、最大のデータ耐久性と可用性を確保するため、OpenSearch Service Multi-AZ with Standby オプションを使用して 2 つのレプリカコピーを作成するベストプラクティスに従っています。これにより、1 日あたりのストレージ需要は 12.375TB に増加します。1 年分のデータを保存するには、365 日を掛けて 4.5PB のストレージが必要になります。
このストレージ容量をプロビジョニングするには、im4gn.16xlarge.search インスタンスまたは or1.16.xlarge.search インスタンスを選択することもできます。次の表は、これらのインスタンスタイプごとに、データのコピー数に応じて必要なインスタンス数を示しています。
| . | ノードあたりの最大ストレージ (GB) | Primary (1 Copy) |
Primary + Replica (2 Copies) |
Primary + 2 Replicas (3 Copies) |
| im4gn.16xlarge.search | 30,000 | 52 | 104 | 156 |
| or1.16xlarge.search | 36,000 | 42 | 84 | 126 |
| r6g.12xlarge.search | 24,000 | 63 | 126 | 189 |
前の表と次の説明は、ストレージニーズに厳密に基づいています。or1 インスタンスと im4gn インスタンスの両方とも、r6g インスタンスよりも高いスループットを提供するため、さらにコストを削減できます。計算の節約額は、ワークロードとインスタンスタイプによって 10 〜 40% 異なります。これらの節約は直接利益に反映されるわけではなく、インデックスとシャード戦略のスケーリングと変更を行って初めて実現できます。前の表と後続の計算では、これらのデプロイメントはコンピューティングリソースが過剰にプロビジョニングされており、ストレージに制限があると一般的に想定されています。コンピューティングリソースをさらに拡張する必要がある場合、r6g に比べて or1 と im4gn でより多くの節約が見込めます。
次の表は、指定された 3 つの異なるデータストレージサイズにわたる 3 つの異なるインスタンスタイプの合計クラスターコストを表しています。これらはオンデマンド米国東部 (バージニア北部) AWS リージョンのコストに基づいており、インスタンス時間、or1 インスタンスの Amazon S3 コスト、および or1 インスタンスと r6g インスタンスの Amazon EBS ストレージコストが含まれています。
| . | Primary (1 Copy) |
Primary + Replica (2 Copies) |
Primary + 2 Replicas (3 Copies) |
| im4gn.16xlarge.search | $3,977,145 | $7,954,290 | $11,931,435 |
| or1.16xlarge.search | $4,691,952 | $9,354,996 | $14,018,041 |
| r6g.12xlarge.search | $4,420,585 | $8,841,170 | $13,261,755 |
この表は、4.5 PB のワークロードに対する 1 コピー、2 コピー、3 コピーのコスト (該当する場合は Amazon S3 と Amazon EBS のコストを含む) を示しています。この投稿では、「1 コピー」とは、レプリケーション数をゼロに設定した最初のデータコピーを指します。「2 コピー」にはデータのレプリカコピーが含まれ、「3 コピー」にはプライマリと 2 つのレプリカが含まれます。ご覧のとおり、各レプリカはソリューションのコストを倍増させます。もちろん、各レプリカはデータの可用性と耐久性を高めます。1 コピー (プライマリのみ) の場合、単一ノードの障害で (or1 インスタンスを除いて) データを失うことになります。1 つのレプリカがある場合、2 ノードの障害で一部またはすべてのデータを失う可能性があります。2 つのレプリカがある場合、3 ノードの障害でのみデータを失うことになります。
or1 インスタンスはこの規則の例外です。or1 インスタンスは、1 コピーのデプロイをサポートできます。これらのインスタンスは、Amazon S3 をバッキングストアとして使用し、すべてのインデックスデータを Amazon S3 に書き込み、レプリケーションと耐久性を実現します。確認された書き込みはすべて Amazon S3 に永続化されるため、ノードの停止時にデータの可用性を失うリスクはありますが、1 コピーで実行できます。データノードが利用できなくなった場合、通常10~20分程度の復旧時間が必要になり、その間はインデックスが利用できなくなります (ステータスが赤色表示になります)。システム (例: 取り込みパイプラインバッファ) だけでなく、顧客に対してもこの可用性の低下を許容できるかどうかを慎重に評価する必要があります。許容できる場合は、前の表に示されている 1 コピー (プライマリ) の列に基づいて、コストを 1,400 万ドルから 470 万ドルに削減できます。
リザーブドインスタンス
OpenSearch Service では、1 年契約と 3 年契約の Reserved Instance (RI) がサポートされています。これには、前払い費用なし (NURI)、一部前払い (PURI)、全額前払い (AURI) があります。すべての RI 契約でコストが下がりますが、3 年契約の全額前払い RI が最も割引率が高くなります。Fizzywig のワークロードに 3 年契約の全額前払い RI の割引を適用した場合の年間コストは、次の表のようになります。
| . | Primary | Primary + Replica | Primary + 2 Replicas |
| im4gn.16xlarge.search | $1,909,076 | $3,818,152 | $5,727,228 |
| or1.16xlarge.search | $3,413,371 | $6,826,742 | $10,240,113 |
| r6g.12xlarge.search | $3,268,074 | $6,536,148 | $9,804,222 |
RI は、コードやアーキテクチャの変更を行うことなく、コストを削減する簡単な方法を提供します。この作業負荷に RI を採用すると、3 コピーの im4gn コストが 570 万ドルに、or1 インスタンスの 1 コピーコストが 320 万ドルになります。
Amazon S3 バックドストレージの導入
前述のデプロイメントはベースラインとの比較のために役立ちます。実際には、コストを管理可能な範囲に抑えるために、Amazon S3 バックドストレージオプションのいずれかを選択するでしょう。
OpenSearch Service の UltraWarm インスタンスは、すべてのデータを Amazon S3 に保存し、UltraWarm ノードをこの完全なデータセットの上の ホットキャッシュ として利用します。UltraWarm は、6 か月前の 1 日分のデータに対して複数のクエリを実行するなど、小さな時間範囲のデータに対する対話型クエリに最適です。アクセスパターンを慎重に評価し、UltraWarm のキャッシュのような動作があなたのニーズに合うかどうかを検討してください。UltraWarm の最初のクエリのレイテンシは、クエリする必要があるデータ量に応じて拡大します。
OpenSearch Service ドメインを UltraWarm 用に設計する際、ホット保持期間とウォーム保持期間を決める必要があります。ほとんどの OpenSearch Service のお客様は、ホット保持期間を 7 ～ 14 日間程度に設定し、ウォーム保持期間で全保持期間の残りを構成しています。Fizzywig のシナリオでは、ホット保持期間を 14 日間、UltraWarm 保持期間を 351 日間に設定しています。また、ホット層では、 2 コピー (プライマリと 1 つのレプリカ) のデプロイを使用しています。
14 日間に必要なホットストレージ (1 日の取り込み量 4.125 TB に基づく) は 115.5 TB です。3 種類のインスタンスタイプのいずれかを 6 つデプロイすれば、このインデクシングとストレージをサポートできます。UltraWarm は Amazon S3 に単一のレプリカを格納し、追加のストレージオーバーヘッドは必要ありません。そのため、351 日間のストレージニーズは 1.158 PiB となります。これは 58 台の UltraWarm1.large.search インスタンスでサポートできます。次の表は、ホット層に 3 年間の AURI を適用したこのデプロイメントの総コストを示しています。or1 インスタンスの Amazon S3 コストは S3 列に含まれています。
| . | Hot | UltraWarm | S3 | Total |
| im4gn.16xlarge.search | $220,278 | $1,361,654 | $333,590 | $1,915,523 |
| or1.16xlarge.search | $337,696 | $1,361,654 | $418,136 | $2,117,487 |
| r6g.12xlarge.search | $270,410 | $1,361,654 | $333,590 | $1,965,655 |
さらにコストを削減するには、データを UltraWarm コールドストレージに移行できます。コールドストレージは、データの可用性を下げることでコストを削減します。データを照会するには、対象のインデックスを UltraWarm 層に再アタッチするための API 呼び出しを発行する必要があります。1 年分のデータの典型的なパターンは、14 日間ホット、76 日間 UltraWarm、275 日間コールドストレージです。このパターンに従うと、6 つのホットノードと 13 の UltraWarm1.large.search ノードを使用します。次の表は、Fizzywig の 3TB の日次ワークロードを実行するコストを示しています。Amazon S3 の使用料金は、UltraWarm ノード + S3 列に含まれています。
| . | Hot | UltraWarm nodes + S3 | Cold | Total |
| im4gn.16xlarge.search | $220,278 | $377,429 | $261,360 | $859,067 |
| or1.16xlarge.search | $337,696 | $461,975 | $261,360 | $1,061,031 |
| r6g.12xlarge.search | $270,410 | $377,429 | $261,360 | $909,199 |
Amazon S3 バックドのストレージオプションを利用することで、単一コピーまたは 1 デプロイで 33 万 7,000 ドル、1 インスタンスで最大年間 100 万ドルと、さらにコストを削減できます。
OpenSearch Service の Amazon S3 との zero-ETL 統合
OpenSearch Service zero-ETL for Amazon S3 を使用すると、すべての二次データと古いデータを Amazon S3 に保持できます。二次データとは、VPC フローログや WAF ログなど、直接検査する価値は低い大量のデータです。このようなデプロイメントでは、頻繁にクエリされないデータの大部分を Amazon S3 に保持し、最新のデータのみホット層に保持します。場合によっては、二次データの一部をサンプリングし、ホット層にも一定割合を保持します。Fizzywig は、すべてのデータの 7 日分をホット層に保持することにしました。残りのデータはダイレクトクエリ (DQ) でアクセスします。
ダイレクトクエリを使用する場合、データを JSON、Parquet、CSV 形式で保存できます。Parquet 形式はダイレクトクエリに最適で、データに対して約 75% の圧縮が行われます。Fizzywig は Amazon OpenSearch Ingestion を使用しており、これにより Parquet 形式のデータを直接 Amazon S3 に書き込むことができます。毎日 3 TB のソースデータが 750 GB の Parquet データに圧縮されます。OpenSearch Service はダイレクトクエリ用のコンピューティングユニットのプールを維持しています。これらの OpenSearch コンピューティングユニット (OCU) は時間単位で課金され、アクセスするデータ量に基づいてスケーリングされます。この会話では、Fizzywig がデバッグセッションを行い、1 日分のデータ (750 GB) に対して 50 件のクエリを実行すると想定しています。次の表は、毎日 3 TB のワークロードを 7 日間ホットで、358 日間 Amazon S3 に保存する場合の年間コストの概要を示しています。
| . | Hot | DQ Cost | OR1 S3 | Raw Data S3 | Total |
| im4gn.16xlarge.search | $220,278 | $2,195 | $0 | $65,772 | $288,245 |
| or1.16xlarge.search | $337,696 | $2,195 | $84,546 | $65,772 | $490,209 |
| r6g.12xlarge.search | $270,410 | $2,195 | $0 | $65,772 | $338,377 |
大変な旅路でした! Fizzywig 社のロギングコストは、年間最高 1,400 万ドルから、Amazon S3 からの zero-ETL によるダイレクトクエリを使用することで年間 28 万 8,000 ドルまで下がりました。これは 4,800% の節約です!
サンプリングと圧縮
この投稿では、データサイズに焦点を当て、そのデータへのアクセス方法に応じてトレードオフを行うことができる 1 つのデータフットプリントを見てきました。OpenSearch には、保存するデータ量を削減することで、さらに経済性を変えることができる追加機能があります。
ログワークロードの場合、OpenSearch Ingestion サンプリングを利用して、OpenSearch Service に送信するデータのサイズを削減できます。サンプリングは、全体のデータが統計的特性を持ち、一部が全体を代表できる場合に適しています。たとえば、オブザーバビリティワークロードを実行している場合、システムでのリクエスト処理のトレースを代表するサンプリングを取得するために、データの 10% 程度を送信するだけで十分な場合があります。
ワークロードに応じて、圧縮アルゴリズムを使用することもできます。OpenSearch Service では最近、デフォルトの最高圧縮に比べて、より高い圧縮率と低い伸張待ち時間を実現できる Zstandard (zstd) 圧縮のサポートがリリースされました。
結論
OpenSearch Service を使うことで、Fizzywig は、コスト、レイテンシー、スループット、耐久性と可用性、データ保持、そして好ましいアクセスパターンのバランスを取ることができました。彼らはロギングソリューションのコストを 4,800% 削減することができ、経営陣は大喜びでした。
全体的に見ると、im4gn インスタンスの絶対金額が最も低くなります。ただし、いくつか注意点があります。まず、or1 インスタンスは、特に書き込み集中型のワークロードで、より高いスループットを提供できます。これにより、コンピューティングの必要性が低減され、追加の節約につながる可能性があります。さらに、or1 の高い耐久性により、レプリケーションを減らして可用性と耐久性を維持できるため、コストが削減されます。もう 1 つの検討事項は RAM です。r6g インスタンスは追加の RAM を備えているため、クエリの待ち時間が短縮されます。UltraWarm と組み合わせ、ホット/ウォーム/コールドの比率を変えることで、r6g インスタンスも優れた選択肢となります。
大量のロギングワークロードがありますか? これらの方法の一部またはすべてから恩恵を受けましたか? ご意見をお聞かせください!
著者について
Jon Handler は、カリフォルニア州パロアルトに拠点を置く Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。Jon は OpenSearch と Amazon OpenSearch Service を担当し、ベクトル、検索、ログ分析のワークロードを AWS Cloud に移行したいさまざまな顧客に対して支援とガイダンスを提供しています。AWS に入社する前は、ソフトウェア開発者として 4 年間大規模な EC サイトの検索エンジンをコーディングしていました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号と博士号を取得しています。