これは何？
- WebアプリケーションがOpenSearchとの接続でいきなりエラーになった時の原因と解消方法のメモ
- OpenSearchは(ElasticSearchも)日本語の情報が少なく、同様のトラブルシューティングで困っている人の助けになれば幸いです。
経緯
- 開発していたWebアプリケーションにて、急に、エラーが発生。
- ログを見たところ、Web アプリケーションとOpenSearchとの接続にて、
401, 'Unauthorized'エラーを発見。 - OpenSearh自体は特になんの設定変更もしていないため、原因の特定に時間がかかりました。
結論
OpenSearchをシングルノードで稼働していたことにより、障害発生？時に内部データベースが失われ、内部ユーザーデータベースと HTTP基本認証を用いた接続ができなくなっていた模様。
調査詳細
-
まずはWebアプリケーション側のエラーを疑ったが、同様のコードベースで動いている環境が存在 && エラー前にこれといった変更が見られませんでした。
-
続いて OpenSearchに何か変更が加わり、エラーとなった可能性を検討。CloudTrail と CloudWatch にてログを確認するも、OpenSearch自体への設定変更は特になかった。またWebアプリケーションからOpenSearchに変更をかけるようなリクエストなども見つけることができませんでした。
-
とすると、OpenSearch自体に何かエラーが起きているのではないかと思い、AWSコンソールから OpenSearchのヘルスチェックを確認。その結果、エラーが起き始めたタイミングから内部ドキュメントが消失していることが判明しました。
詳細を見ると、約1時間半ほど、ログデータ自体が取得できておらず、その後、ドキュメントが失われた状態となっていました。
ログが失われる原因としては、CPU/RAM/IO枯渇、ネットワークエラーなど色々考えられるが、ドキュメント自体が消失しているため、内部でハードウェア or OpenSearch自体に障害が発生した可能性が高いと推測。ここで初めて、原因と思われる事象を特定できました。
その場合、内部ユーザーデータベースのデータも失われたのではないかと思い、コンソール画面から、新しいマスターユーザーを追加で登録。新しく登録した認証情報を使用したところ、再接続が可能となりました.
その後
調べたところ、同様の事象を経験している記事が1つだけ見つかりました。
https://blog.ecbeing.tech/entry/2024/01/09/080000#OpenSearch%E7%A0%B4%E6%90%8D
この記事によると、
- ノードに問題が発生した場合、新しいノードに入れ替えが行われる。
- シングルノードで起動していたため、レプリカが存在せず問題が発生したノードのデータが失われた。
- 内部ユーザーデータベースもその際に失われる可能性がある。
とのことです。
今回は開発中のものだったため、大事にはなりませんでしたが、シングルノードを使う時はデータが消失する可能性を考慮した使用が大切だと実感しました。最低限、スタンバイノードを1つ作っておき、障害時にフェールオーバーさせるようにしておくのが良さそうです。
なお、AWSのベストプラクティスでは、スタンバイ込みのマルチAZ設定が推奨となっています。
https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/bp.html
最後に
今回は、AWSの内部リソースのエラーが原因と推論を出しました。OpenSearchのエラーを調べると、どうしてもOpenSearchのアプリケーション起因のエラーについての情報が多く、今回の事象について情報はあまり見つかりませんでした。
個人的には開発でシングルノードを利用する機会は割と多いと思ったため、そういった方たちの役立つ情報になればと思っています。
最後まで読んでいただきありがとうございました。