Zstandard 圧縮による Amazon OpenSearch Service のストレージコスト最適化

この記事は、 Optimize storage costs in Amazon OpenSearch Service using Zstandard compression を翻訳したものです。

この記事は、インテルの Praveen Nischal、Mulugeta Mammo、Akash Shankaran と共同で執筆されました。

Amazon OpenSearch Service は、AWS Cloud 上で OpenSearch クラスターを大規模かつ安全に展開・運用することを容易とするサービスです。OpenSearch Service ドメインでは、データはインデックスの形式で管理されます。使用パターンに基づいて、OpenSearch クラスターには 1 つ以上のインデックスがあり、そのシャードはクラスター内のデータノードに分散されています。各データノードには固定のディスクサイズがあり、ディスク使用量はノードに格納されているインデックスシャードの数に依存します。各インデックスシャードは、ドキュメント数に応じて異なるサイズを占める可能性があります。ドキュメント数に加えて、インデックスシャードのサイズを決定する重要な要因の 1 つは、インデックスに使用される圧縮アルゴリズムです。

インデクシング操作の一部として、取り込まれたドキュメントはイミュータブルセグメントとして格納されます。各セグメントは、転置インデックス、block K dimensional tree (BKD)、用語辞書、格納フィールドなどのさまざまなデータ構造の集合体であり、これらのデータ構造は検索操作中にドキュメントをより速く取得する役割を担っています。これらのデータ構造のうち、セグメント内で最大のサイズとなる格納フィールドは、ディスクに格納される際に圧縮され、使用される圧縮方式によって圧縮速度とインデックスの格納サイズが変わります。

この記事では、OpenSearch v2.9 で導入された Zstandard アルゴリズムのパフォーマンスについて、OpenSearch で利用可能な他の圧縮アルゴリズムと比較しながら説明します。

OpenSearch における圧縮の重要性

OpenSearch では圧縮が重要な役割を果たします。圧縮は、パフォーマンス、ストレージの効率性、およびプラットフォームの全体的な使いやすさに大きな影響を与えるためです。OpenSearch で圧縮が重要な理由は次のとおりです。

ストレージの効率性とコスト削減
OpenSearch では、ログファイル、ドキュメント、分析データセットなど、膨大な量のデータを扱うことがよくあります。圧縮技術を使用すると、ディスク上のデータサイズが小さくなり、特にクラウドベース環境や分散環境で大幅なコスト削減につながります。
I/O 操作の削減
圧縮により、データの読み書きに必要な I/O 操作が削減されます。I/O 操作が少なくなれば、ディスク I/O が減り、全体的なシステムのパフォーマンスとリソース活用が向上します。
環境への影響
ストレージ要件を最小限に抑え、I/O 操作を削減することで、圧縮は省エネと炭素排出量の削減に貢献し、持続可能性と環境目標に沿ったものになります。

OpenSearch を構成する際は、特定のユースケースとリソースの制約に応じて、ストレージ効率とクエリパフォーマンスの適切なバランスを取るために、圧縮設定を慎重に検討することが不可欠です。

中心となる概念

OpenSearch が提供する様々な圧縮アルゴリズムに入る前に、圧縮アルゴリズムを比較する際によく使われる 3 つの標準的な指標を見てみましょう。

圧縮率
入力データの元のサイズと圧縮されたデータを比較し、1.0 以上の比率で表したもの
圧縮速度
データが小さくなる (圧縮される) 速度で、入力データの消費量を MBps で表したもの
解凍速度
元のデータが圧縮データから再構築される速度で、MBps で表したもの

インデックスコーデック

OpenSearch は、格納フィールドを圧縮するために使用できるコーデックをサポートしています。OpenSearch 2.7 までは、OpenSearch は LZ4 と Zlib の 2 つのコーデックまたは圧縮戦略を提供していました。LZ4 は best_speed に相当し、Zlib と比較して高速な圧縮を提供しますが、圧縮率は低く (ディスク使用量が多く) なります。明示的なコーデックが指定されない場合、LZ4 がデフォルトの圧縮アルゴリズムとして使用され、インデックス作成と検索速度が速いため、ほとんどの場合優先されます。ただし、Zlib よりも多くの空間を消費します。一方、Zlib は best_compression に相当し、LZ4 と比較して優れた圧縮率 (ディスク使用量が少ない) を提供しますが、圧縮と解凍に時間がかかるため、インデックス作成と検索操作の待ち時間が長くなります。LZ4 と Zlib の両方のコーデックは、Lucene コアコーデックの一部です。

Zstandard コーデック

Zstandard コーデックは、バージョン 2.7 で実験的機能としてOpenSearch に導入されました。Zstandard ベースの圧縮と解凍の API を提供します。Zstandard コーデックは、JNI を介して Zstd ネイティブライブラリにバインディングされています。

Zstandard は、Zlib と同等の圧縮率を提供しつつ、LZ4 と同等の高速な圧縮と展開速度を目指した高速な可逆圧縮アルゴリズムです。OpenSearch では、Zstandard 圧縮アルゴリズムが zstd と zstd_no_dict の 2 つのモードで利用できます。詳細は Index codecs をご覧ください。

どちらのコーデックモードも、圧縮率、インデックス、検索スループットのバランスを目指しています。zstd_no_dict オプションは、インデックスサイズがわずかに大きくなることを犠牲にして、zstd から辞書圧縮機能を除外します。

最近の OpenSearch 2.9 リリースで、Zstandard コーデックが実験的な段階から本番利用可能な段階に昇格し、本番環境での利用に適したものになりました。

Zstd コーデックを使用したインデックスの作成

index.codec を使用すると、インデックス作成時に Zstd コーデックを使ってインデックスを作成できます。以下は curl コマンドを使用した例です (このコマンドを実行するには、インデックスを作成する権限が必要です)。

# index の作成 
 curl -XPUT "http://localhost:9200/your_index" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "index.codec": "zstd"
  }
}'

Zstandard 圧縮レベル

Zstandard コーデックを使用する場合、index.codec.compression_level 設定を使って圧縮レベルを [1, 6] の範囲の整数で指定できます。圧縮レベルが高いほど、圧縮率が高くなり (ストレージサイズが小さくなりますが)、速度が低下する (圧縮と解凍の速度が遅くなり、インデックス作成と検索の待ち時間が長くなります) というトレードオフがあります。詳細については、Choosing a codec を参照してください。

# index の作成 
 curl -XPUT "http://localhost:9200/your_index" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "index.codec": "zstd",
    "index.codec.compression_level": 2 
  }
}
'

インデックスコーデック設定の更新

index.codec と index.codec.compression_level の設定は、インデックスの作成後いつでも更新できます。新しい設定を反映するには、インデックスを閉じて再度開く必要があります。

インデックスの設定を更新するには、PUT リクエストを使用します。次は curl コマンドを使用した例です。

インデックスを閉じる:

# index を閉じる 
 curl -XPOST "http://localhost:9200/your_index/_close"

インデックス設定を更新します:

# index.codec と codec.compression_level の設定を更新 
 curl -XPUT "http://localhost:9200/your_index/_settings" -H 'Content-Type: application/json' -d' 
{ 
  "index": {
    "codec": "zstd_no_dict", 
    "codec.compression_level": 3 
  } 
}'

インデックスを再オープンする:

# index を再オープン 
 curl -XPOST "http://localhost:9200/your_index/_open"

インデックスコーデックの設定を変更しても、既存のセグメントのサイズには直ちに影響しません。更新後に作成された新しいセグメントのみが、新しいコーデック設定を反映します。セグメントサイズと圧縮率を一貫させるには、再インデックス化やマージなどの他のインデックス処理を実行する必要がある場合があります。

OpenSearch における圧縮の圧縮性能ベンチマーク

Zstandard コーデックのパフォーマンス上の利点を理解するために、ベンチマーク演習を行いました。

セットアップ

サーバーのセットアップ :

ベンチマークは、データノードとコーディネータノードの役割を兼ねる単一のデータノードと、専用の cluster_manager ノードで構成された OpenSearch クラスターで実行されました。
データノードのインスタンスタイプは r5.2xlarge で、cluster_manager ノードは r5.xlarge でした。いずれも、タイプが GP3、サイズが 100GB の Amazon Elastic Block Store (Amazon EBS) ボリュームがアタッチされています。

ベンチマークの設定 :

このベンチマークは、クライアント側のリソース制約に遭遇しないようにGP3 タイプ、サイズ 500GB の EBS ボリュームがアタッチされた十分に大きな c5.4xlarge タイプの単一ノードで実行されました。
クライアント数は 16、バルクサイズ は 1024 でした。
ワークロードは nyc_taxis でした。

インデックスの設定 :

シャード数: 1
レプリカ数: 0

結果

実験から、zstd は Zlib (best_compression) と比較して、より優れた圧縮率を提供し、書き込みスループットがわずかに向上し、LZ4 (best_speed) と同程度の読み取りレイテンシーになることがわかりました。zstd_no_dict は、LZ4 (best_speed) よりも 14% 優れた書き込みスループットを提供し、Zlib (best_compression) よりもわずかに低い圧縮率になります。

次の表に、ベンチマーク結果の概要を示します。

制限事項

Zstd は圧縮率と圧縮速度の両方で優れていますが、以下の制限があります:

一致するすべてのドキュメントの格納フィールド全体を取得するクエリの一部では、レイテンシの増加が見られる可能性があります。詳細については、インデックスコーデックの変更を参照してください。
k-NNまたはSecurity Analyticsインデックスでは、zstdおよびzstd_no_dict圧縮コーデックを使用できません。

まとめ

Zstandard 圧縮は、ストレージサイズと圧縮速度のバランスが良く、ユースケースに基づいて圧縮レベルを調整できます。Intel と OpenSearch Service チームは、Zstandard を OpenSearch の圧縮アルゴリズムの 1 つとして追加するため協力しました。Intel は、オープンソースでの圧縮プラグインの初期バージョンの設計と実装に貢献し、OpenSearch v2.7 で実験的な機能としてリリースされました。OpenSearch Service チームは、さらなる改善を行い、パフォーマンス結果を検証し、OpenSearch サーバーのコードベースに統合しました。OpenSearch v2.9 で一般提供機能としてリリースされました。

OpenSearch に貢献したい場合は、GitHub の issue を作成し、アイデアを共有してください。また、OpenSearch Service での Zstandard の経験についても教えていただけると幸いです。質問があれば、コメント欄でお気軽にご質問ください。

著者について

Praveen Nischal はクラウドソフトウェアエンジニアで、Intelのクラウドワークロードパフォーマンスフレームワークを主導しています。

Mulugeta Mammo は Senior Software Engineer で、現在 Intel の OpenSearch 最適化チームをリードしています。

Akash Shankaran は、Intelの Xeon ソフトウェアチームでソフトウェアアーキテクトおよびテックリードを務めています。OpenSearch などのデータサービスに最適化を施す機会を見つけ、可能にする仕事をしています。

Sarthak Aggarwal は、Amazon OpenSearch Service のソフトウェアエンジニアです。主な関心分野はインデックス作成とストレージのパフォーマンスで、オープンソース開発に貢献しています。

Prabhakar Sithanandam は、Amazon OpenSearch Service の Principal Engineer です。主に OpenSearch のスケーラビリティとパフォーマンスの側面に取り組んでいます。

Amazon Web Services ブログ