はじめに
AWS OpenSearch（ElasticSearch）でError 429 (Too Many Requests)が大量に発生してかなり困ったので、原因と対処方法についてのメモ。
前提条件
HTTP 429 エラーに対しては、アプリケーションで再送ロジックを組み込んでおくことが推奨されています。低頻度の429エラーは再送で対処したほうが良いです。
429エラー多発時のメトリクスについて
HTTP429の問題発生時に、下記のメトリクスに異常値が見られました。症状が同じであれば、本対策で解消する可能性があります。
-
ThreadpoolWriteRejected Maximum
ThreadpoolWriteRjectedのメトリクスが急増していました。標準のメトリクスなのでCloudwatchから確認できます。
-
WriteIOPS/ReadIOPS
過去日比較でかなり高い値を継続的に推移していました。ただし、問題発生と同時刻に異常があったわけではなく、直接問題と紐づけるのは難しいです。 -
他のメトリクスには特に目立った異常はなかったです。
原因
AWS OpenSearch（ElasticSearch）のデータノードに使っているEBSのIOPS不足です。EBSは、ボリュームサイズに対して3IOPS/GiBのベースライン性能（gp2の場合）がありますが、バースト可能なのでIOPSを超過しても即時問題にはなりません。また、本記事の掲載時点ではOpenSearch（ElasticSearch）のEBSがバースト超過していることを示すメトリクスが存在しません。よって、バースト性能を含めたEBSのIOPS超過が原因であるとすぐに特定することはちょっと難しいと思います。
WriteIOPS＋ReadIOPSの値が、設定しているEBSのベースライン性能を大きく超えていた場合は、これが原因であることを疑ってみると良いと思います。
対処
OpenSearch（ElasticSearch）のEBSボリュームタイプを、汎用（SSD）からプロビジョンドIOPS（SSD）に変更し、適切なIOPSを設定しました。
どの程度IOPSが必要かについては、WriteIOPSおよびReadIOPSのメトリクスを確認すれば良いです。WriteIOPSとReadIOPSを合算した値を加味して、EBSのIOPSを決める必要があります。
EBSボリュームタイプの変更、プロビジョンドIOPSの値の変更は、Blue/Green デプロイが適用されるため、基本的にはダウンタイムなしで適用可能です。
AWS OpenSearch（ElasticSearch）のEBSには、プロビジョンドIOPSでシステムに適切なIOPSを設定しておくことがおすすめ
その後の監視について
WriteIOPSとReadIOPSの合算値に対して、Cloudwatchアラートを設定しました。プロビジョンドIOPSを1000とした場合、例えば800、900などを閾値としたアラートを設定しておけば問題発生前に気付き、EBSのIOPSを増やす対処が可能だと思います。
WriteIOPS/ReadIOPSメトリクスに対してアラーム設定しておくのがおすすめ