TL;DR
- OpenSearch がメモリ不足だと GC が走るタイミングで 400 エラー出ちゃうよ
- 専用マスタノードのインスタンスタイプは適切に設定しよう（公式ドキュメントに目安あり）
背景
レバテックでは、案件の検索に OpenSearch を利用しています。
昨年末 Elasticsearch から OpenSearch への移行を果たし、ぬくぬくと運用していました。
でもなんかめちゃくちゃコンスタントに 400 エラー出ててワロタ…
調査
ログを見る
OpenSearch は、下記 4 種のログを確認することが出来ます。
- 検索スローログ
- インデックススローログ
- アプリケーションエラーログ
- 監査ログ
今回は 400 エラーの調査のため、アプリケーションエラーログを有効にしてみました。
すると、こんな感じの Warn ログがたくさん出ていることが判明しました。
[2023-12-25T11:33:33,863][WARN ][o.o.m.j.JvmGcMonitorService] [66383a1d54e8805a7e3dca820a912bd8] [gc][1739418] overhead, spent [790ms] collecting in the last [1.5s]
[2023-12-25T12:28:12,864][WARN ][o.o.m.j.JvmGcMonitorService] [66383a1d54e8805a7e3dca820a912bd8] [gc][young][1742694][9422] duration [1.1s], collections [1]__PATH__[1.6s], total [1.1s]__PATH__[30.2m], memory [1.4gb]->[594.2mb]__PATH__[2gb], all_pools {[young] [902mb]->[0b]__PATH__[0b]}{[old] [591.2mb]->[591.2mb]__PATH__[2gb]}{[survivor] [3mb]->[3mb]__PATH__[0b]}
このログでぐぐってみると、OpenSearch が不要なメモリ領域解放のためガベージコレクション(GC)を実施した際に出力されるもののようです。
この GC の負荷が結構すごいらしく、上のログが出力され、400 エラーとなってキャッチされているみたい。
AWSに相談してみる
上のログについて調べてもなんだかぱっとしなかったので、AWSのサポートに相談してみました。
何事もプロに相談するのが一番ですからね！
答えは単純で 「専用マスタノードをもっとメモリの多いインスタンスに変えてみて」 とのことでした。
冒頭で Elasticsearch から移行したという話をしましたが、そのときの調査不足で専用マスタノードのインスタンスタイプをケチってしまっていたことがわかりました（すいません）
公式ドキュメントのベストプラクティスくらい目を通しておこうね…
（※m5.large.search or m6g.large.search にすべきと記載のあるところを確認せずより小さいインスタンスにしていました）
いざインスタンスタイプ変更
というわけで、専用マスタノードのインスタンスタイプを変更しようと思います。
OpenSearch では、Blue/Green デプロイが行われるときとそうでないときがあります。
この Blue/Green デプロイを使用しない更新というのは別に悪いものではなく、インスタンスを切り替えずにダウンタイムなくデプロイできるよ！というものです。逆に Blue/Green デプロイというのは、インスタンスを切り替える必要がある際にできるだけダウンタイムなくやろうとする方法ですね。
2023年7月のアップデートからマスターノードのインスタンスタイプ変更は Blue/Green デプロイを使用せずに行われるようになったみたいです（ドライランでも確認済み）
というわけで、胸を張ってインスタンスタイプを切り替えました。
やったか！？
これによって 400 エラーもなくなり平和になりましたとさ！
と言いたかったんですがそうは問屋が卸しませんでした。上述の GC のログは出なくなったのですが、400 エラーは未だ出続けているようです。グラフが冒頭の状態から全然変わってなくて悲しくなりました。
インスタンスタイプの変更はたしかに GC の負荷に対して有効だったのですが、今回の問題の原因はまだ他にもあるようです…🥲
俺たちの戦いはこれからだ！
Discussion