こんにちは。 エキサイト株式会社の三浦です。
今回は、最近実際に私の身に起きた非常に困った話、AWS Elasticsearchエラー問題について説明していきます。
なおこの件は、とりあえず現状はエラーは収まっているものの、100%原因が判明したとは言い切れないものとなっています。 あらかじめご了承ください。
始まり
私が携わっているサービスでは、コスト削減のためにElasticsearchに対してReserved Instanceを購入しています。 Reserved Instanceは、簡単に言ってしまえば一定期間の料金を前払いする代わりに割引してもらう、というものです。
先日、以前購入したReserved Instanceの前払い期間が終了したのですが、その頃ちょうど 6g系インスタンス が発表されました。
お客様は、現世代 (M5、C5、R5) の対応する x86 ベースのインスタンスと比較して、最大 38% 向上したインデックス作成スループット、50% 削減されたインデックス作成レイテンシー、30% 向上したクエリパフォーマンスの恩恵を受けることができます。
Amazon Elasticsearch Service Graviton2 インスタンスでは、前世代のインスタンスに比べて費用対効果が最大 44% 向上しています。
とのことなので、これを使わない手はありません。
6g系インスタンスは使用できるバージョンが一定以上のものでないといけないので、テスト環境で検証した後に本番環境のバージョンをアップし、その後無事6g系のインスタンスタイプに変更が完了しました。
これでコストも下がるしパフォーマンスも上がるしいい事づくし！と思っていました。
それがそう簡単なことではないとわかったのは、それからしばらく経ったあとのことです。
問題発生
ある日突然、サービスに対するリクエストがエラーになっているという通知が届きました。 急いで調査してみると、なんとElasticsearchからのレスポンスが不安定になっているようです。
Elasticsearchのインスタンスタイプの増強やm5系への変更、不要なリクエストの削除による負荷低減等色々なことを試してみましたが、それでも断続的にエラーが起きる状態が続きました。
問題の解決？
色々と試していく中で、Elasticsearchへのアクセスを最初に受け付けるElasticsearch用APIに問題があるのでは、という考えから、そのAPI（dockerコンテナとして運用しています）の1コンテナあたりのリクエスト数を減らしてスケールアウトするようにしてみたところ、エラーが起きなくなりました。
とはいえそれまではエラーは出ていなかったので、エラー原因の可能性としてはAPI自体の問題というよりも、
- バージョンを上げたことによるElasticsearch側の何かしらの処理の変化
- 実は色々あってElasticseach自体を一度立て直したが、その際に過去に立ち上げたElasticsearchのインスタンスと何かしらの設定が変わってしまっており、処理が変化
したことによってAPIの1コンテナあたりのリクエスト数の上限が変化した、などが考えられますが、正直に言うと原因が完全に解明できたとは言えず、お手上げ状態です。
最後に
迂闊なバージョンやインスタンスタイプの変更などは、一見問題なさそうでも後々問題を引き起こす可能性がある、ということを身にしみて感じました。 どうすれば防げるかというとなかなか難しい話ですが、心構えだけは持っておくとなにかあった時に冷静に対処できるかもしれません。
みなさんも、バージョンアップ等をするときは不測の事態にくれぐれも注意しましょう。
