OpenSearch 最適化インスタンス (OR1) はインデクシングパフォーマンスとコストを革新

この記事は、 OpenSearch optimized instance (OR1) is game changing for indexing performance and cost を翻訳したものです。

Amazon OpenSearch Service は、アプリケーション監視、ログ分析、オブザーバビリティ、Web サイト検索などのユースケースで、ビジネスデータや運用データのリアルタイム検索、監視、分析を安全に実現にします。

この記事では、2023 年 11 月 29 日に導入された、OpenSearch 最適化インスタンスである OR1 について検討します。

OR1 は Amazon OpenSearch Service のインスタンスタイプで、大量のデータを保存するためのコスト効率の高い方法を提供します。OR1 インスタンスを使用するドメインでは、Amazon Elastic Block Store (Amazon EBS) ボリュームをプライマリストレージとして使用し、データが書き込まれるとすぐに Amazon Simple Storage Service (Amazon S3) に同期的にコピーされます。OR1 インスタンスは、高い耐久性と共に、インデクシングのスループットも向上します。

OR1 の詳細については、紹介ブログ記事をご覧ください。

インデックスに対して書き込みを行っている間は、レプリカを 1 つ維持することをお勧めします。ただし、ロールオーバー後にインデックスに対する書き込みが行われなくなった後は、レプリカを 0 に切り替えることができます。

これは、データが Amazon S3 に永続化されているため、安全に行えます。

ノードの障害と交換が発生した場合、データは Amazon S3 から自動的に復元されますが、修復操作中は一部のデータアクセスができなくなるため、アクティブに書き込まれていないインデックスの検索に高可用性が必要な場合は、レプリカを 0 にしないでください。

ゴール

このブログ記事では、OR1 が OpenSearch ワークロードのパフォーマンスにどのような影響を与えるかを探ります。

OR1 インスタンスは、セグメントレプリケーションを提供することで、プライマリシャードでのみインデックス作成を行うため、CPU サイクルを節約できます。これにより、ノードは同じ計算リソースで、より多くのデータをインデックス化できるか、インデックス作成に使用するリソースを減らし、検索やその他の操作に使えるリソースを増やすことができます。

この記事では、インデックス作成の負荷が高いワークロードを想定し、パフォーマンステストを行います。

従来、Amazon Elastic Compute Cloud (Amazon EC2) の R6g インスタンスは、Amazon EBS ストレージに依存するインデックス作成の負荷が高いワークロードに適した高性能な選択肢でした。Im4gn インスタンスは、高スループットと低レイテンシーのディスク書き込みに向いた、ローカル NVMe SSD を提供します。

この記事の範囲では、インデクシングのパフォーマンスのみに焦点を当て、OR1 のインデクシング性能を、これら 2 つのインスタンスタイプと比較します。

設定

パフォーマンステストでは、次の図に示すように複数のコンポーネントを設定しました。

Architecture diagram

テストプロセスについては以下の通りです:

AWS Step Functions は、環境のクリーンアップとインデックスマッピングのセットアップ、およびバッチテストの実行のための初期化ステップを調整します。
AWS Batch は、OpenTelemetry JSON 形式のログデータをインデックス化するための並列ジョブを実行します。
ジョブは、OpenSearch Rust Client と AWS Identity and Access Management (IAM) 認証を使用して、ランダム化されたログを生成するカスタム Rust プログラムを実行します。
OpenSearch Service ドメインは、OpenSearch 2.11、2 つのアベイラビリティーゾーン、きめ細かいアクセス制御、AWS Key Management Service (AWS KMS) による保存時の暗号化、TLS による転送時の暗号化で設定されています。

インデックスマッピングは、初期化ステップの一部で、次のようになります。

{
  "index_patterns": [ 
    "logs-*"
  ],
  "data_stream": {
    "timestamp_field": {
      "name": "time"
    }
  },
  "template": {
    "settings": {
      "number_of_shards": ,
      "number_of_replicas": 1,
      "refresh_interval": "20s"
    },
    "mappings": {
      "dynamic": false,
      "properties": {
        "traceId": {
          "type": "keyword"
        },
        "spanId": {
          "type": "keyword"
        },
        "severityText": {
          "type": "keyword"
        },
        "flags": {
          "type": "long"
        },
        "time": {
          "type": "date",
          "format": "date_time"
        },
        "severityNumber": {
          "type": "long"
        },
        "droppedAttributesCount": {
          "type": "long"
        },
        "serviceName": {
          "type": "keyword"
        },
        "body": {
          "type": "text"
        },
        "observedTime": {
          "type": "date",
          "format": "date_time"
        },
        "schemaUrl": {
          "type": "keyword"
        },
        "resource": {
          "type": "flat_object"
        },
        "instrumentationScope": {
          "type": "flat_object"
        }
      }
    }
  }
}

データストリームを使用して、ロールオーバー構成を簡素化し、ベストプラクティスに従って、プライマリシャードのサイズを 50 GiB 以下に抑えています。

不要なインデクシングアクティビティを回避し、flat_object フィールドタイプを使用してフィールドマッピングの爆発を回避するようにマッピングを最適化しました。

参考までに、使用した Index State Management (ISM) ポリシーは以下の通りです。

{
  "policy": {
    "default_state": "hot",
    "states": [ 
      {
        "name": "hot",
        "actions": [ 
          {
            "rollover": {
              "min_primary_shard_size": "50gb"
            }
          }
        ],
        "transitions": [] 
      }
    ],
    "ism_template": [ 
      {
        "index_patterns": [ 
          "logs-*"
        ] 
      }
    ] 
  }
}

平均ドキュメントサイズは 1.6 KiB で、バルクサイズは 1 バルクあたり 4,000 ドキュメントのため、1 バルクあたり約 6.26 MiB (非圧縮時) になります。

プロトコルのテスト

プロトコルのパラメータは次のとおりです。

データノードの数: 6 または 12
ジョブの並列処理数: 75、40
プライマリシャード数: 12、48、96 (12 ノードの場合)
レプリカの数: 1 (合計 2 コピー)
インスタンスタイプ (それぞれ 16 vCPU):
- or1.4xlarge.search
- r6g.4xlarge.search
- im4gn.4xlarge.search

Cluster	Instance type	vCPU	RAM	JVM size
or1-target	or1.4xlarge.search	16	128	32
im4gn-target	im4gn.4xlarge.search	16	64	32
r6g-target	r6g.4xlarge.search	16	128	32

im4gn クラスターのメモリ容量は他の 2 つの半分ですが、それでも各環境の JVM ヒープサイズはおよそ 32GiB で同じです。

パフォーマンステストの結果

パフォーマンステストでは、最初にクライアントごとに 75 の並列ジョブと 4,000 ドキュメントの 750 バッチ (合計 2 億 2,500 万ドキュメント) から始めました。その後、シャード数、データノード数、レプリカ数、ジョブ数を調整しました。

構成 1 : 6 データノード、12 プライマリシャード、1 レプリカ

この構成では、データノードを 6 つ、プライマリシャードを 12 個、レプリカを 1 つ使用しました。そして、次のようなパフォーマンスを観測しました。

Cluster	CPU 使用率	所要時間	インデックス作成速度
or1-target	65-80%	24 分	156 kdoc/s	243 MiB/s
im4gn-target	89-97%	34 分	110 kdoc/s	172 MiB/s
r6g-target	88-95%	34 分	110 kdoc/s	172 MiB/s

この表で強調表示されているように、im4gn クラスターと r6g クラスターの CPU 使用率が非常に高く、アドミッションコントロールがトリガーされ、ドキュメントが拒否されています。

OR1 は、CPU 使用率が 80% 未満で持続していることを示しており、これは非常に良いターゲットです。

注意すべき点 :

本番環境では、エクスポネンシャルバックオフを使ってインデクシングを再試行し、一時的な拒否によるドキュメント欠落が起きないようにしてください。
バルクインデクシング操作は 200 OK を返しますが、一部失敗する可能性があります。すべての文書が正常にインデックスされたことを確認するには、レスポンスの本文をチェックする必要があります。

並列ジョブの数を 75 から 40 に減らしながら、クライアントごとに 4,000 ドキュメントの 750 バッチ (合計 120M ドキュメント) を維持すると、次のようになります。

Cluster	CPU 使用率	所要時間	インデックス作成速度
or1-target	25-60%	20 分	100 kdoc/秒	156 MiB/秒
im4gn-target	75-93%	19 分	105 kdoc/秒	164 MiB/秒
r6g-target	77-90%	20 分	100 kdoc/秒	156 MiB/秒

スループットと CPU 使用率は減少しましたが、Im4gn と R6g の CPU 使用率は高い状態が続いており、一方で OR1 には余剰の CPU 容量があることがわかります。

構成 2 : 6 データノード、48 プライマリシャード、1 レプリカ

この構成では、プライマリシャードの数を 12 から 48 に増やしました。これにより、インデックス作成のための並列処理能力が向上します。

Cluster	CPU 使用率	所要時間	インデックス作成速度
or1-target	60-80%	21 分	178 kdoc/s	278 MiB/s
im4gn-target	67-95%	34 分	110 kdoc/s	172 MiB/s
r6g-target	70-88%	37 分	101 kdoc/s	158 MiB/s

OR1 のインデックス処理スループットは向上しましたが、Im4gn と R6g は CPU 使用率がまだ非常に高いため、改善は見られませんでした。

並列ジョブを 40 に減らし、プライマリシャードを 48 に保ったところ、OR1 の最小 CPU が 12 のプライマリシャードから増加し、やや負荷がかかることがわかります。一方で、R6g の CPU 使用率は大幅に改善されました。しかし Im4gn の CPU 使用率はまだ高い状態です。

Cluster	CPU 使用率	所要時間	インデックス作成速度
or1-target	40-60%	16 分	125 kdoc/s	195 MiB/s
im4gn-target	80-94%	18 分	111 kdoc/s	173 MiB/s
r6g-target	70-80%	21 分	95 kdoc/s	148 MiB/s

構成 3 : 12 データノード、96 プライマリシャード、1 レプリカ

この構成では、元の構成から始め、コンピューティング能力を増強しました。ノード数を 6 から 12 に増やし、プライマリシャード数を 96 に増やしました。

クラスター	CPU 使用率	所要時間	インデックス作成速度
or1-target	40-60%	18 分	208 kdoc/s	325 MiB/s
im4gn-target	74-90%	20 分	187 kdoc/s	293 MiB/s
r6g-target	60-78%	24 分	156 kdoc/s	244 MiB/s

OR1 と R6g は CPU 使用率が 80% 未満で良好なパフォーマンスを発揮しています。OR1 は R6g と比較して CPU 使用率が 30% 少なく、パフォーマンスが 33% 優れています。

Im4gn は CPU 使用率が 90% のままですが、パフォーマンスも非常に良好です。

並列ジョブの数を 75 から 40 に減らすと、次のようになります。

クラスター	CPU 使用率	所要時間	インデックス作成速度
or1-target	40-60%	11 分	182 kdoc/s	284 MiB/s
im4gn-target	70-90%	11 分	182 kdoc/s	284 MiB/s
r6g-target	60-77%	12 分	167 kdoc/s	260 MiB/s

並列ジョブの数を 75 から 40 に減らすと、OR1 と Im4gn インスタンスが同等になり、R6g も非常に近くなりました。

解釈

OR1 インスタンスは、レプリカがセグメントのコピーによって生成されるため、プライマリシャードのみを書き込めばよいため、インデックス作成を高速化します。Img4n インスタンスや R6g インスタンスと比較して高性能にも関わらず、CPU 使用率も低いため、追加の負荷 (検索) やクラスターサイズの削減の余地があります。

6 ノードの OR1 クラスターで 48 個のプライマリシャードを持ち、秒あたり 178,000 ドキュメントをインデックス化するのと、12 ノードの Im4gn クラスターで 96 個のプライマリシャードを持ち、秒あたり 187,000 ドキュメントをインデックス化するのと、12 ノードの R6g クラスターで 96 個のプライマリシャードを持ち、秒あたり 156,000 ドキュメントをインデックス化するのを比較できます。

OR1 は、より大きな Im4gn クラスターとほぼ同等のパフォーマンスを発揮し、より大きな R6g クラスターよりも優れたパフォーマンスを示します。

OR1 インスタンスを使用する場合のサイズ設定方法

結果から分かるように、OR1 インスタンスはより高いスループット率でデータを処理できます。しかし、プライマリシャードの数を増やすと、リモートバックドストレージのためにパフォーマンスが低下します。

OR1 インスタンスタイプから最高のスループットを得るには、通常より大きなバッチサイズを使用し、Index State Management (ISM) ポリシーを使ってサイズに基づきインデックスをロールオーバーすることで、インデックスごとのプライマリシャードの数を効果的に制限できます。また、OR1 インスタンスタイプはより多くの並列処理を処理できるため、接続数を増やすこともできます。

検索に関しては、OR1 はパフォーマンスに直接影響しません。しかし、図から分かるように、OR1 インスタンスの CPU 使用率は Im4gn インスタンスや R6g インスタンスよりも低くなっています。これにより、より多くのアクティビティ (検索やインジェスト) を実行できるか、インスタンスのサイズやカウントを削減して、コストを削減できる可能性があります。

OR1 の結論と推奨事項

新しい OR1 インスタンスタイプは、他のインスタンスタイプよりも強力なインデックス作成機能を提供します。これは、日々バッチ処理でインデックス作成を行う場合や、高い持続的なスループットを必要とする場合など、インデックス作成の負荷が高いワークロードにとって重要です。

OR1 インスタンスタイプでは、既存のインスタンスタイプよりもパフォーマンスに対する価格が 30% 優れているため、コスト削減も可能です。複数のレプリカを追加する場合、OR1 インスタンスでは CPU 使用率への影響がほとんどないため、パフォーマンスあたりの価格が下がります。一方、他のインスタンスタイプでは、インデックス処理スループットが低下します。

このrepost 記事を参照して、インデックス作成のためのワークロードの最適化の完全な手順を確認してください。

著者について

C é dric Pelvet は AWS プリンシパルソリューションアーキテクトです。リアルタイムデータと検索ワークロードに対するスケーラブルなソリューションの設計をお客様にご支援しています。プライベートでは、新しい言語を学んだり、バイオリンの練習をしています。

Amazon Web Services ブログ