Amazon EBS gp3 ボリュームで Amazon OpenSearch Service のストレージコストを削減する

本記事は 2022 年 11 月 23 日 に公開された「Lower your Amazon OpenSearch Service storage cost with gp3 Amazon EBS volumes」を翻訳したものです。

Amazon OpenSearch Service を使用すると、インタラクティブなログ分析、リアルタイムアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できます。OpenSearch は、分散検索および分析エンジンである OpenSearch と、UI および可視化ツールである OpenSearch Dashboards で構成されるオープンソースの分散検索および分析スイートです。Amazon OpenSearch Service を使用する場合、インデックスを保存しクエリを処理するデータノードのセットを設定します。このサービスは、さまざまなストレージオプションを持つデータノード用のインスタンスタイプをサポートしています。R6GD や I3 などの一部のサポートされている Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプには、ローカル NVMe ディスクがあります。その他のインスタンスタイプは Amazon Elastic Block Store (Amazon EBS) ストレージを使用します。

2022 年 7 月、OpenSearch Service は次世代の汎用 SSD (gp3) EBS ボリュームのサポートを開始しました。OpenSearch Service のデータノードは、高速なインデックス作成とクエリを提供するために、低レイテンシーで高スループットのストレージを必要とします。gp3 EBS ボリュームを使用すると、以前提供されていた gp2 EBS ボリュームタイプよりも 9.6% 低いコストで、より高いベースラインパフォーマンス (IOPS とスループット) を得られます。gp3 を使用すると、ボリュームサイズとは独立して追加の IOPS とスループットをプロビジョニングできます。gp3 ボリュームはバーストクレジットを使用しないため、より安定しています。gp3 ボリュームの OpenSearch サポートには、データノードあたりのボリュームサイズ制限の 2 倍化も含まれています。これらのより大きなボリュームにより、パッシブデータのコストを削減し、ノードあたりのストレージ量を増やすことができます。

価格/パフォーマンスと柔軟性の面で、gp3 を最適な Amazon EBS オプションとして検討することをお勧めします。この記事では、gp3 の基本とさまざまなコスト削減のユースケースについて説明します。以前の世代のストレージ (gp2、PIOPS、マグネティック) ボリュームから最新世代の gp3 ボリュームに移行することで、月額ストレージコストを削減し、インスタンス使用率を最適化できます。

gp2 と gp3 の比較

gp3 は汎用 SSD gp2 ボリュームの後継です。gp3 の主な利点には、より高いベースラインパフォーマンス、9.6% 低いコスト、ボリュームに関係なくより高いパフォーマンスをプロビジョニングできる機能があります。次の表は、gp2 と gp3 の主な違いをまとめたものです。

gp3 で月額料金を削減する

ボリュームサイズとは独立して IOPS とスループットをプロビジョニングできる機能と、より高密度 (2 倍の大きさ) のボリュームサイズのサポートは、gp3 採用の 2 つの大きな利点です。これらの利点を組み合わせることで、月額料金を削減するための複数のユースケースが可能になります。このセクションでは、OpenSearch ドメインの料金比較の例をいくつか紹介します。

gp2 vs. gp3

これは最も一般的なシナリオで、既存の gp2 のお客様が gp3 に切り替えると、gp3 ストレージの GB あたりの月額料金が低いため、すぐに 9.6% の節約を開始できます。また、gp3 は R5、R6g、M5、M6g インスタンスファミリーで 2 倍大きいボリュームサイズをサポートしているという事実からも恩恵を受けることができます。これは、より高密度のストレージ要件のために新しいインスタンスを起動する必要がなく、同じインスタンスでより多くのストレージを実現できることを意味します。OpenSearch Service は現在、R6g.12Xlarge インスタンスで最大 24 TiB の gp3 ストレージをサポートしています。

PIOPS (io1) vs. gp3

OpenSearch Service は PIOPS SSD (io1) EBS ボリュームタイプをサポートしています。gp3 に切り替えて、特定のパフォーマンス要件を満たすために追加の IOPS とスループットをプロビジョニングできます。次の表は、6 TiB のストレージ要件と 16000 IOPS を持つ R5.large.search インスタンスの PIOPS (io1) と gp3 ストレージの月額コストを比較しています。この例では、gp3 の採用により 65% 節約できます。

I3 vs. gp3

I3 インスタンスには、低レイテンシー、非常に高いランダム I/O パフォーマンス、高いシーケンシャル読み取りスループットに最適化された Non-Volatile Memory Express (NVMe) SSD ベースのインスタンスストレージが含まれており、高い IOPS を提供します。ただし、I3 は古い第 3 世代の CPU を使用しており、サポートされる最大ストレージサイズは i3.16xlarge.search インスタンスで 15 TiB です。I3 インスタンスよりも低コストで優れたパフォーマンスを得るために、gp3 ストレージを備えた R6g などの最新世代のインスタンスの使用を検討する必要があります。

コスト上の利点を理解するために、12 TiB のデータストレージニーズに対して I3 と gp3 を比較してみましょう。次の表の計算によると、gp3 と現行世代のインスタンスに切り替えることで、月額料金を 56% 削減できます。

UltraWarm vs. gp3

UltraWarm は、30 日以上経過したログなど、アクセス頻度の低いデータへの安価なアクセスを提供するように設計されています。ウォームストレージは、アクティブに書き込まれておらず、クエリ頻度が低く、高いパフォーマンスを必要としないインデックスに役立ちます。大規模でクエリ集約型のワークロードがあり、コストを最適化するために UltraWarm を使用しようとしているが、処理できる以上のクエリボリュームに遭遇している場合は、データボリュームの一部を gp3 ストレージを備えたホットノードに移動することを検討する必要があります。UltraWarm は、ウォームデータ (アクセス頻度の低いデータ) タイプのユースケースでは引き続き最も安価なオプションですが、ホットデータのユースケースには使用しないでください。低コストの gp3 ストレージと高密度インスタンスの組み合わせにより、ホットデータのコスト最適化された高パフォーマンスを実現できます。

次の表は、30 TiB の UltraWarm ワークロードを実行するための月額コストと、gp2 および gp3 の潜在的な月額コストとの比較を示しています。gp3 を使用すると、gp2 と比較して最大 36% 節約できます。UltraWarm のセットアップにはホットデータノードが必要ですが、gp2 と gp3 を使用したホットデータノードでの UltraWarm 置換コストに焦点を当てるため、UltraWarm 列ではそれらを除外しています。

上記のすべてのユースケースはコストの観点からのものです。本番環境に変更を加える前に、独自のワークロードに対してテスト環境でパフォーマンスを検証し、設定変更がパフォーマンスの低下につながらないことを確認することをお勧めします。

gp3 の高密度ストレージでインスタンスコストを最適化する

OpenSearch Service は、gp3 のベースラインパフォーマンスの向上により、R5、R6g、M5、M6g インスタンスファミリーで gp2 と比較してインスタンスあたりのサポートされる最大ボリュームサイズを 100% 増加させました。インスタンスあたりのストレージ増加を活用することで、インスタンスのニーズを最適化できます。例えば、R6g.large は gp3 で最大 2 TiB をサポートしますが、gp2 では 1 TiB のみです。12 TiB のデータストレージのサポートが必要な場合、インスタンスコストを削減するために、ドメインを 6 つのデータノードから 3 つの R6g.large に再構成できます。OpenSearch EBS インスタンス固有のボリューム制限については、EBS ボリュームサイズのクォータを参照してください。

gp2 から gp3 へのアップグレード

EBS gp3 ボリュームタイプを使用するには、いくつかの手順を実行する必要があります。まず、ドメインのインスタンスが gp3 をサポートしていない場合は、サポートされているインスタンスタイプにアップグレードする必要があります。OpenSearch Service でサポートされているインスタンスのリストについては、EBS ボリュームサイズのクォータを参照してください。次に、マスターインスタンスノードのサイズ、シャードの数、ノードあたりのシャードのサイズの観点からクラスターを適切にサイジングする必要があります。詳細については、OpenSearch のベストプラクティスを参照してください。第三に、gp2 から gp3 への移行は簡単ですが、インスタンスサイズとボリュームの変更により一時的な停止が発生する可能性があるため、通常の変更管理メンテナンスウィンドウの一部として調整する必要があります。OpenSearch Service コンソールまたは UpdatedomainConfig API を使用して、gp2、マグネティック、PIOS (io1) などの既存の EBS ボリュームタイプから gp3 にドメイン設定をアップグレードできます。これらの設定変更により Blue/Green デプロイメントが開始され、バックグラウンドで実行されます。オンライントラフィックに影響を与える可能性があり、データサイズによっては数時間以内に完了します。

gp3 のベースラインパフォーマンスと追加プロビジョニング制限

gp3 の主要な機能の 1 つは、ボリュームとは独立して IOPS とスループットをスケーリングできることです。アプリケーションがより多くのパフォーマンスを必要とする場合、追加料金で最大 16,000 IOPS と 1,000 MiB/s のスループットにスケールアップできます。OpenSearch Service EBS gp3 は、任意のボリュームサイズで 3,000 IOPS と 125 MiB/s のスループットのベースラインパフォーマンスを提供します。さらに、OpenSearch Service は最適なパフォーマンスを確保するために、より大きなボリュームに追加の IOPS とスループットをプロビジョニングします。1,024 GiB を超えるボリュームでは 3 IOPS/GiB を受け取り、170 GiB を超えるボリュームでは 3 TiB のストレージごとに 250 MiB/s の増分を得られます。

次の表は、OpenSearch Service のベースライン IOPS とスループット、およびプロビジョニングできる最大量を示しています。インスタンスタイプには、24 時間の期間でこれらのパフォーマンスベースラインをどの程度、どのくらいの期間サポートできるかに関する追加の制限がある場合があることに注意してください。インスタンスとその制限の詳細については、Amazon EBS 最適化インスタンスを参照してください。

お客様がプロビジョニングできる追加パフォーマンス

追加パフォーマンスは必要ですか？

ほとんどのユースケースでは、追加の IOPS とスループットをプロビジョニングする必要はなく、gp3 のベースラインパフォーマンスで十分です。Amazon CloudWatch メトリクスを使用して使用パターンを確認し、現在の IOPS とスループットの制限がインデックスとクエリのパフォーマンスのボトルネックになっていることが観察された場合は、追加のパフォーマンスをプロビジョニングする必要があります。詳細については、EBS ボリュームメトリクスを参照してください。

まとめ

この記事では、OpenSearch Service の汎用 SSD gp3 ボリュームが月額ストレージおよびインスタンスコストを大幅に削減し、gp2 ボリュームよりもコスト効率が高くなる方法について説明しました。gp2 と同じサイズとパフォーマンス設定で gp3 ボリュームに移行することが、コストを削減する最も迅速で簡単な方法です。さらに、gp3 のデータノードあたりの高密度ストレージのサポートを活用して、インスタンスコストの削減も検討する必要があります。

詳細については、Amazon OpenSearch Service の料金と Amazon OpenSearch Service の設定 API リファレンスをご覧ください。

著者について

Siddhant Gupta は、インドのハイデラバードを拠点とする Amazon Web Services のシニアテクニカルプロダクトマネージャーです。Siddhant は Amazon に 5 年以上在籍しており、現在は OpenSearch Service チームで新しいリージョンの立ち上げ、料金戦略、EC2 および EBS のイノベーションを OpenSearch Service のお客様に提供する業務に携わっています。分析と機械学習に情熱を持っています。余暇には、旅行、フィットネス活動、家族との時間、ノンフィクションの読書を楽しんでいます。

この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。