OpenSearch （ ElasticSearch ） の利用料を最適化する 〜円安ドル高にちょっと抵抗してみる〜

はじめに

円安が止まりません。20数年ぶりの円安水準だそうです。ガソリン代も高騰していますが、ドルベースのAWS利用料も影響を受けてしまいます。AWS利用料には補助金は導入されませんので、自助努力するしかないですね。仕事の効率が落ちない程度に、コスト最適化を考えてみます。

OpenSearchの費用について

OpenSearchのデータノードは、マルチAZにすると2（または3）の倍数が必要で、シャード数も考慮すると、両方の公倍数にした方が良いです。となると、必然的にデータノード数はある程度多くなり、それに伴い費用もかさみがちだと思います。

OpenSearchの運用コストを最適化

商用環境には手をつけにくいので、検証環境（開発環境）にフォーカスします。コストを無視すれば、検証環境はできる限り商用環境と同じ環境であることが理想ではあると思いますが、ほとんどの時間で性能を持て余します。そこで、性能が必要な場合（性能テスト時など）のみ、商用レベルの性能を付与する（動的に設定変更する）ことにします。

最適化の方針

とはいえ、手間は増やしたくありません。データ量に依存するデータノード数やEBSサイズは据置とします。インスタンスタイプ、EBSタイプ（汎用 or IOPS）の変更によって性能を下げることで、単価を減らす方向性にします。これらの設定変更は30分程度（環境依存）かかりますが、基本的にダウンタイムなしなので業務を妨げることもないです。設定変更は楽にしたいので、lambda実行で済むようにします。

lambda実装

性能縮退する実装例。データノードのインスタンスタイプを小さく、EBSタイプを汎用にしています。API一本で済みます。

import json
import boto3
client = boto3.client('opensearch')

def downgrade():
    response = client.update_domain_config(
        DomainName='your domain name',
        ClusterConfig={
            'InstanceType': 't3.medium.search'
        },
        EBSOptions={
            'EBSEnabled': True,
            'VolumeType': 'gp2',
            'VolumeSize': 35
        }
    )

性能拡張する実装例。縮退時よりデータノードのインスタンスタイプを大きくし、EBSタイプをProvisioned IOPS（IOPSも指定）にしています。

import json
import boto3
client = boto3.client('opensearch')

def upgrade():
    response = client.update_domain_config(
        DomainName='your domain name',
        ClusterConfig={
            'InstanceType': 'm5.xlarge.search'
        },
        EBSOptions={
            'EBSEnabled': True,
            'VolumeType': 'io1',
            'VolumeSize': 35,
            'Iops': 1000
        }
    )

• lambdaの実行ロールにOpenSearchのアクセス権限が必要
• API実行に数秒かかるので、lambdaのタイムアウトは5〜10秒程度にしておくと良い

参考:Boto3Docs

おわりに

縮退するのを忘れてしまう場合は、EventBridgeから定期的にlambda実行しておけば良いと思います。設定変更中はブルーグリーンのためにインスタンスがむしろ増えるので、あまり頻繁に変更するのはおすすめできませんが、昼間・夜間で変更する、休日・平日で変更する程度であればアリだと思います。