これはNFLaboratories Advent Calendar 2025 11日目の記事です。
研究開発部 研究開発担当の後藤です。
私たちが開発しているプロダクトでは、一部機能の実現のためにElastic Cloud HostedのElasticsearchを採用しています。この記事では、Elastic Cloud Hostedを約1年半使って経験した出来事、わかったことなどを共有できればと思います。
ディスク容量が枯渇したときの対応
ある日、Elasticsearchへの書き込みが失敗しているというシステムアラートが上がりました。
Elasticsearchではディスク領域が少なくなる（ディスク使用率がflood-stage watermark=95%を超える）と、そのノードにシャードを持つインデックスに書き込み制限（read_only_allow_delete）がかかり、書き込みが失敗するようになります。既存データの読み取りはできる状態です。以下のようなエラーが発生します。
disk usage exceeded flood-stage watermark, index has read-only-allow-delete block;
Elastic Cloudにログインしてみると、該当のDeploymentのステータス表示が真っ赤なUNHEALTHYになっています。
スケールアップを試す
こうなってしまった場合、対処方法としてはwatermarkの閾値を手動で上げる（一時対処）か、データノードを拡張するかです。
私たちはデータノードをスケールアップするという方法を取りました。 操作としてはElastic CloudではDeploymentのEditメニューから、該当のノードのサイズをより大きいものに変更してSaveするだけです。
うまくいけば、既存データ読み取り可能状態を維持したままスケールアップが完了し、すべての機能が回復します。
これまでの経験では、既存データのサイズに応じてスケールアップにかかる時間が増える傾向があるようです。
スケールアップが失敗した場合にはExtended maintenance
上記の方法ではうまくスケールアップができず、失敗してしまうことがあります。この場合はExtended maintenanceを有効にすると、成功する場合がありました。クラスタが過負荷になってしまっている場合に効果的なオプションのようです。
ただし、この場合はスケールアップ中に読み取りを含むすべてのリクエストを受け付けなくなるため、注意が必要です。
それでもスケールアップができないときは…
Extended maintenanceでもスケールアップが失敗する場合、Elasticサポートに連絡するのがおすすめです。
私たちの場合、Elasticサポートと連携して対応することで、無事にスケールアップを成功させ、正常動作まで持っていくことができました。
この件に限らず、Elasticサポートはさまざまなトラブルシューティングや対応で非常に丁寧にサポートしてくださいます。Elasticについての多くの知見を持つ技術者からのサポートを受けられるため、Elastic Cloudを使う大きなメリットだと感じます。
オートスケーリングの設定と注意点
DeploymentのEdit画面から、Hot / Warm / Cold / Frozen tierそれぞれの自動的なスケールアップを設定することができます。
設定項目としてはCurrent size per zone, Maximum size per zone, Forecast windowです。
ディスクの使用率が高まることによってダウンタイムなしでスケールアップされます。スケールアップのタイミングとして公式ドキュメントに明確な閾値の記載はありませんし、サイズ増加の予測状況も要素として絡みますが、ディスク使用率が70%前後と思ったよりも早い段階でスケールアップされていることがありました。
現時点ではスケールアップのみが対応しており、スケールダウンは対応していない点は注意が必要です。ディスク使用率が減っても自動的にスケールダウンは行われません。
注意点: オートスケーリングが行われない!?
あるとき、ディスク使用率が高まっても設定していたオートスケーリングが行われず、ステータスがUNHEALTHYになってしまうことがありました。
原因はおそらく、最後のElasticsearchへの変更が失敗していたことです。公式ドキュメントのGeneric limitationsとしても以下の記載があります。
The following are known limitations and restrictions with autoscaling: Autoscaling will not run if the cluster is unhealthy or if the last Elasticsearch plan failed.
実はその少し前にElasticsearchへのterraform applyが失敗しており、直近の変更が失敗状態になっていました。ステータスとしてはHEALTHYで動作も影響がなかったためそのままにしていたのですが、それがオートスケーリングが行われなかった原因だと思われます。一見正常に見える状態だったとしても、このような場合には正常に完了する構成を再適用しておく必要があるようです。
オートスケーリングを設定している際は、このような落とし穴にもご注意ください。
余裕を持ったディスク運用を
書き込み制限がかかるflood-stage watermark（デフォルト95%）以外にも、low watermark（デフォルト85%）, high watermark（デフォルト90%）があり、挙動への影響が段階的に出始めます。85%の段階で「残り15%あるから大丈夫」と思って油断していると、思わぬところで焦ることにもなりかねないので、これらのwatermarkの存在を理解したうえで余裕を持った運用をしたいところです。
ちなみに、Elastic CloudのUI上は75%を超えた段階でディスク使用率のバーが赤くなるようです。
そろそろ、Elastic Cloud Serverless？
ここまでElastic Cloud Hostedについて書きましたが、運用が大変そう…と思った方も多いのではないでしょうか。
2024年12月にリリースされたElastic Cloud Serverlessは、上記のような管理が不要でより運用負荷が低く使えるようですので、使い方（コストのかかり方）や要件を満たせるか次第ではありますが有力な選択肢となりそうです。Hostedにはある機能でもServerlessでは未提供（Planned）となっている機能がいくつかあるので、その点はご注意ください。
また、つい最近（2025年10月）ServerlessがAWS ap-northeast-1（東京）リージョンで利用可能になったそうです。
これからElastic Cloudの利用を考えている方は、Hosted / Serverlessをよく比較してみてください。
おわりに
Elastic Cloud Hostedを約1年半使ってきてわかったことを書いてみました。
現在では、上記の経験を活かして余裕を持ったindex lifecycle management policyの設定をする等、より安定した基盤となるように日々改善を進めています。実はそのあたりでもハマりどころはあって、Elasticサポートにたくさん助けていただきました。（そのあたりのより深い話はまた機会があればということで…）
Elastic Cloudの採用を考えている方、Elastic Cloud Hostedの運用をこれから始めていく方のお役に立てれば幸いです。
