概要
原因は結局わからないままだったので備忘録です。 想定される原因や、強制的に再起動する方法があったら教えてほしいです。。
何が置きたか
ある日突然エンドポイントの応答がなくなった
502 Bad Gateway だった気もするが、記憶があやふや。 Timeout だったかもしれない。
Web アプリケーションから Elasticsearch を呼び出していたが、アプリケーションとしては 60秒のタイムアウトでレスポンスが帰っていた。
原因の調査
マネージメントコンソールから確認すると、ドメインのステータスは「アクティブ」になっており、問題無さそうに見えた。
エラーログを確認してみると下記のような感じのログが吐かれていた。
[2019-XX-XXTXX:XX:XX,XXX][WARN ][o.e.m.j.JvmGcMonitorService] [XXXXXX] [gc][XXXXXX] overhead, spent [2.1s] collecting in the last [2.1s]
似たようなログが何度か吐かれた後、静かになっている。
Cloudwatch やらでメトリクスを確認すると、上記のログが最初に吐かれる 12h ほど前から突然取得できなくなっていた。
落ちる前と比べて、何かが跳ねるなどの目立つ傾向も見受けられなかった。
また、特定のリソースが落ちる前から逼迫しているということもなかった。
※最大メモリ使用率だけは90%越えをしているタイミングはあったが、落ちる前だけに限定した現象ではなかった
対応
エラーログの内容で調べてみると、Elasticsearch 関連の情報がいくつか引っかかった。
「メモリの割当サイズを増やして再起動する」ということだったが、Elasticsearch Service を手動で再起動する方法が見つけられなかった。
そのため、インスタンスサイズの変更を試してみることにした。
しかし、ドメインのステータスが「処理中」になったまま 24h 以上変化がなかった。
下記の記事を見つけたりもしたのだが、そもそも curl が 502 になって帰ってこない。
結局復旧は諦め、別ドメインで同じ構成のインスタンスを用意して、そちらを利用することにした。
ただの想像
- 開発用だったということもあり、インデックスの全件更新などを高頻度で実施していた
- サイジングなどのチューニングは行っておらず、デフォルトのまま利用していた
上記のようなことから何かしらの問題が発生したのかとは思いつつ、復旧しなかったことなど含め原因はよくわからない。
