re:Inventで発表されたOpenSearch OR1インスタンスファミリーについて

技術本部 サービスリライアビリティグループ(SRG)の松田(@mm_matsuda816)です。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、OpenSearch OR1インスタンスファミリーの既存インスタンスファミリーに対する優位性を整理します。執筆にあたり、AWS SAの方からも情報提供していただきました。ご協力くださりありがとうございました。
CyberAgent Group SRE Advent Calendar 2023の6日目の記事になります。
 

OR1インスタンスファミリーとは


re:Inventで発表された新しいOpenSearchのインスタンスファミリーです。
従来のインスタンスファミリーとは設計が大きく異なることがポイントで、プライマリストレージにS3を使用することでイレブンナインの耐久性を実現しており、ベンチマーク結果では既存のインスタンスファミリーに対して30%のコスト効率向上が確認されています。
OpenSearch 2.11以降をサポートしています。
 
参考

既存のインスタンスファミリーとのコスト比較


まずvCPU/Memory数で比較してみましょう。
vCPU:Memory 比率は 1:8なのでrシリーズと比較します。rシリーズに対して約1.25倍の料金設定となっています。
or1 インスタンスファミリー料金(ap-northeast-1 12/18時点) https://aws.amazon.com/opensearch-service/pricing/?nc1=h_ls より引用
or1 インスタンスファミリー料金(ap-northeast-1 12/18時点) https://aws.amazon.com/opensearch-service/pricing/?nc1=h_ls より引用
 
r6g インスタンスファミリー料金(ap-northeast-1 12/18時点) https://aws.amazon.com/opensearch-service/pricing/?nc1=h_ls より引用
r6g インスタンスファミリー料金(ap-northeast-1 12/18時点) https://aws.amazon.com/opensearch-service/pricing/?nc1=h_ls より引用
 
また、S3バックアップストレージ分の料金が追加で発生します。
 
このように単純に置き換えるだけだとコスト削減にはなりません。
OR1の特徴を活かしたチューニングを行う必要があります。

OR1の特徴を活用したチューニング


レプリカ数の削減

データの耐久性がS3で担保されているため、レプリカ数を1まで減らすことが出来ます。
レプリカ数を減らすことによって以下のメリットを享受できます。
  • indexing負荷低減
  • EBSサイズの減少
  • データの冗長化のために倍数のノードを作成しているケースでは台数を削減

CPU数の削減

前述の通りindexing負荷を低減させられるため、ノード台数の削減・インスタンスサイズのスケールダウンなどでCPU数を減らすことが出来ます。

OR1の注意点


他のインスタンスファミリーに変更出来ない

OR1で構築したOpenSearchは後から他のインスタンスファミリーに変更できません。
同様に他のインスタンスファミリーからOR1への変更もできません。

1シャードのサイズは100GB以下にする必要がある

シャードサイズは100GB以下とクォータで定められており、それ以上になる場合は書き込みできなくなります。
AWS Supportから上限緩和申請することも可能なようです。

セグメント単位のS3への同期になるため、更新から一定期間内は検索結果の不整合が発生する可能性がある

従来のドキュメント方式のレプリケーションからセグメント方式のレプリケーションになっており、セグメント作成時間によるレプリケーション遅延が発生します。refresh_intervalという値で設定出来ますが最小値が10秒となっています。
このため、書き込んだデータと読み取ったデータの一貫性が一定期間は保証されません。
Segment replication https://opensearch.org/blog/segment-replication/ より印象
Segment replication https://opensearch.org/blog/segment-replication/ より印象

レプリカ数は自動で削減されない

S3が耐久性を保証しているためレプリカ数を1まで減らせることがメリットですが、ユーザ自身がレプリカ数を減らす必要があります。
index templateでレプリカ数を1に設定しましょう。
 

OR1が適したワークロード


レプリカ数を減らし、indexingにおけるCPU負荷を低減できることが大きなメリットと言えるため、write heavyなワークロードが適しています。
ログ検索用途などが向いているのではないでしょうか。
 
反対にレプリカ数を減らすため、read heavyなワークロードの場合は今までよりも多少のレスポンス悪化が発生する可能性があります。
 
また、read/writeにおける厳密な一貫性を求めるケースでは前述したように、検索結果の不整合が発生する可能性があるため利用を避けるべきのようです。

参考資料


終わりに


弊社ではOpenSearchのindexing負荷が高いために台数・CPU数を増やしているサービスがあるため、コスト削減としてOR1インスタンスファミリーを活用していく予定です。
 
SRG では一緒に働く仲間を募集しています。 ご興味ありましたらぜひこちらからご連絡ください。
 
SRG では最近出たホットなIT技術や書籍などについてワイワイ雑談するポッドキャストを運営しています。ぜひ、作業のお供に聞いていただければ幸いです。
このエントリーをはてなブックマークに追加