Elasticsearchで「circuit_breaking_exception」に出会った

##環境
Amazon Elasticsearch 7
JVMヒープ 40%

##事の顛末

Elasticsearchで、凡そ大量データを一気に集計・整列するAPIを作成し、テストを行ったところ、
以下のようなエラーレスポンスが帰ってきた。

[

    {
        "type": "circuit_breaking_exception",
        "reason": "[request] Data too large, data for [] would be larger than limit of [8998512230/8.3gb]",
        "bytes_wanted": 10464007168,
        "bytes_limit": 8998512230
    }
]```

普通に初めて見るエラーだったので面食らう。


##どんなエラーか

ざっくり「OutOfMemory一歩手前」みたいなイメージらしい。
本格的にOutOfMemoryになってGCが頻発、システムダウン、、みたいな事を防ぐ為に、
「キャパの身の丈に合わないリクエストは拒否しますよ～。」
という機能で、Elasticsearch 7 ~追加された機能のよう。
目的は理解。


引用:
・https://www.elastic.co/jp/blog/improving-node-resiliency-with-the-real-memory-circuit-breaker
・https://www.elastic.co/guide/en/elasticsearch/reference/current/circuit-breaker.html


##対処の選択肢

結局OutOfMemoryの対策とそこまで相違なさそうなので、以下対策を考えた。

①ノード数を増やす。
②インスタンスタイプを強化。
③JVMヒープ割合を40%より大きくする。

各選択肢を検討してみたのだが、
まず①、②はインスタンスを増やすため、コストがかかる。
なので、出来れば設定値を変えるだけで済む③を採用したい。


##どう解決までもっていったか

負荷試験を行い、他機能に影響が無い事を担保した上で、各署と調整しJVMヒープの割合を40%から50%まで上げることで、上記エラーが解決した。

③の方法を取る懸念としては、JVM以外のメモリ領域が小さくなってしまうことだ。
JVMヒープを上げることで、他処理に影響が出てしまう可能性があった。

何にしても影響調査は必須だろうと思う。


##まとめ

半分備忘録。

実際にシステムダウンしちゃう前にこうして止めてくれるのは便利。
けど、挙動的にはエラーを返してきて、データが表示されない事に変わりはないので、
確実に防ぐべきエラー、という温度感で考えてよいかと思う。