📑

Amazon Elasticsearch Service でクラスタステータスが赤のまま、ドメインを編集したら...

2023/02/04に公開

AWS

Elasticsearch

todoker

tech

はじめに

こんにちは。トドケールでプロダクトマネージャーをしています、hayata-yamamoto です。

今回は、開発環境で遭遇し、個人的に少しヒヤヒヤした Elasticsearch についての反省＋学びの共有をしていきます。端的に言うと、

開発環境 の Elasticsearch の設定に不足があったこと
問題が発生した時に、十分にドキュメントを読まなかったこと

によって、Elasticsearch のクラスタが赤のまましばらく使えなくなった話です。どんなことが起こったのか、そこからどんなことを学んだのかを記録する事で、もし仮に他の開発者の皆さんが同じ状況に陥った際に、助けとなるような内容になっていれば嬉しいです。

なお、本番稼働してる ES は適切に設定されています。何度も言いますが、今回は開発環境での話です、ご安心を。

誰に向けて書いた記事か

Amazon Elasticsearch Service を運用している人に向けて。

どんなことが起こったか

ある日、開発環境で Elasticsearch から 500 エラーが返却されるようになりました。コンソールから見てみると、ノードの数は、1 しか用意されていませんでした。クラスタステータスは赤でした。

「あー、これはノードに障害が起こってエラー出してるな。ノードの数が足りてない...」

そう思った私はおもむろに、「ドメインの編集」からノードの数を拡張する変更を実行。
「まあ、いずれ直るだろう」と思っていました。

...数時間後、コンソールをあらためてみると、ステータスは赤。直っていません。

いくつかドキュメントを調べたところ、操作ミスに気づきました。Elasticsearch のステータスを緑に戻す事なく、ドメインの編集処理を行うと、Elasticsearch の処理に時間がかかるとのこと。すぐさま、AWS のサポートに連絡し、事情を説明、対応を依頼しました。

翌日午後、別の開発者から「Elasticsearch 直ってるよー」と連絡を受け、復旧したことを確認しました。

何が起こっていたのか

弊社では、検索機能を Elasticsearch を用いて提供しています。メインのデータベースとしては、DynamoDB を使用していますが、DynamoDB のイベントで Lambda を実行することによって、Elasticsearch にもデータ反映される仕組みを採用しています。これ自体は、しばしば採用されるアーキテクチャではあると思います。コマンドとクエリをうまく分離しきれているか、と言う質問には "Yes and No" と答えます。（まだ、改善の余地がありますね）

alt

Elasticsearch の運用に当たって、本番環境やステージング環境については、マルチ AZ や、マスターノード・データノードの数を十分に用意してサービスの耐久性や信頼性を高めた設定をしています。自社独自の何か設定があるわけではないですが、AWS が公開しているベストプラクティスには目を通して、なるべく従うようにしています。

一方で、主に開発者しか使わない開発環境に関しては、マルチ AZ をオフにしたり、使用するノード数を少なく設定して、なるべく安価に開発できるように設定を変更して使っています。特に Elasticsearch を利用するバックエンドの開発では、docker-compose で Elasticsearch のローカルシミュレーターも導入しているため、正直常に使うわけではなかったりします。今回のケースに関しては、ノードの数を節約するため 1 に設定してたことがまず良くないポイントでした。ノードを 1 に設定してしまうと、そのノードが単一障害点になる、レプリカシャードが作成されず、障害発生時にデータロストが起こる可能性がある、などデメリットがあります。

次に、クラスタステータスをしっかり確認せず、ドメインの変更を実施したこともよくないポイントです。公式にはトラブルシューティングのページも用意されており、適切に対応していれば復旧は容易だったと考えています。（一方で、ステータス赤のまま、ドメインを編集してしまった際の記事がほとんど出てこず、今回このブログを書く動機にもなっています）

AWS のサポートからは以下のようなアドバイスを最後にいただきました。

なお、今回は開発環境ということですが、本番環境では信頼性の要件次第で以下をご検討ください。

- インデックスごとに少なくとも 1 Replica Shard を設定
- 専用マスターノードを 3 ノード配置
- 3 つのアベイラビリティーゾーンを設定
- T2, T3 系のインスタンスタイプを使用しない

今回からの学び

Elasticsearch を開発環境で使う時は、ケチらずちゃんとノードを複数用意する
1. Elasticsearch で単一ノードを使用すると、そのノードが単一障害点(SPOF)になるため。参考
2. データノードを複数台立てても増えるコストはたかがしてれている。
Elasticsearch のクラスタステータスを赤から、緑に戻す際には原因となっているインデックスの特定し、削除するのが一般的な方法
1. AWSによると、インデックスが赤になる → シャードが赤になる → クラスタが赤になる、と言う関係性らしい。特定のための、API もいくつか用意されている
2. （開発環境だからと言って適当にせず）トラブル対応する前にトラブルシューティングのページをちゃんと読む
仮に、インデックスが削除できない場合も、対処方法がいくつかある。
1. "スナップショットを復元する、インデックスからドキュメントを削除する、インデックスの設定を変更する、レプリカの数を減らす、または他のインデックスを削除してディスク領域を解放することができます。"とのこと。
2. AWS のサポートからは、手動バックアップをとっていれば、そのバックアップを用いて新しいドメインにデータを複製する方法もある、と教えてもらった
Elasticsearch に詳しくない、直せない、と思ったらすぐにサポートに聞く方が良い。
1. AWS のサポートを受ける場合は、開発者より上のサポートを購入して問い合わせる。
2. 私は今回 Business サポートを使って問い合わせました。サポートの料金は、AWS の利用状況によって異なります。
3. Elasticsearch のクラスタ復旧は、状況に応じて復旧に時間がかかることもある。（今回は、事象発生の翌日には直していただきました）

おわりに

今回は、開発中に起こった失敗を共有する内容でしたが、他にも弊社ではプロダクトを使ってくださるユーザーさんに価値を提供するために、さまざまな開発を行なっています。
ご興味持ってくださった方はぜひ一度、カジュアル面談や DM 等でやりとりしたいです！

トドケールでは、一緒に働いてくれるエンジニアを募集しています!