「メモリ上限を掛けたから安全」と思って打ったコマンドで、本番が約2時間止まった

無料枠の小さいインスタンスで、更新があるかどうかを確認するだけのコマンドを実行しました。以前このコマンドでメモリを使い切ったことがあったので、使用量に上限を掛けてから打ちました。安全策のつもりでした。結果として本番の全サービスが外から届かなくなり、復旧まで約2時間かかりました。

やったこと

実行したのはインストールではなく、更新の有無を調べるだけのコマンドです。何も変更しないので、安全な部類だと考えていました。

ただ以前、同じ系統のコマンドでメモリを使い切って落ちた経験があったので、今回は使えるメモリの量に上限を設定して実行しました。上限を超えたらそのコマンドだけが失敗して終わるはずです。他のサービスには影響しません。理屈としては、これで安全になります。

起きたこと: 全部が外から届かなくなった

しばらくして、公開しているページが開かなくなりました。1つのサービスではなく、そのサーバーで動かしているもの全部です。管理用の接続も通りません。中で何が起きているのか見ることもできない状態でした。

結局、クラウドのコンソールから強制的に再起動して復旧させました。再起動後はサービスが自動で立ち上がり、正常に戻りました。止まっていたのは約2時間です。

あとから記録を見ると、指標は全部正常だった

ここが一番の学びでした。復旧後に、その時間帯のシステム記録を掘り返しました。普段見ている指標は、どれも異常値を示していませんでした。

CPU使用率 ─ 正常の範囲
ディスク待ちの割合 ─ 正常の範囲
負荷の平均 ─ 特に高くない

つまり「サーバーは元気に動いているのに、外からは全滅している」という状態でした。もし障害の最中にこれらの数字だけ見ていたら、「サーバーは正常です」と結論していたはずです。

監視というのは、見ている指標の範囲でしか異常を教えてくれません。「主要な指標が全部正常」は「正常である」ことの証明ではなく、「見ている範囲には異常が無い」という意味でしかない、と体で理解した一件でした。

本当に詰まっていたのは、メモリではなく通信の帯域だった

記録と挙動を突き合わせて、いちばん筋の通る説明はこうでした。

更新の確認は、外部から大量の情報を取ってくる処理です。何が更新されているかの一覧を丸ごと落としてきます。この機体は非常に小さい構成で、使える通信の帯域も相応に小さいものでした。そこへ大量のダウンロードが走ったため、帯域が埋まって、他の通信が通れなくなったという説明です。

これなら症状と一致します。CPUもメモリ待ちも正常なのは、計算資源では詰まっていなかったからです。外からのアクセスが全部届かないのは、入り口の通路が塞がっていたからです。

そして重要なのは、私が上限を掛けたのはメモリだけだったということです。帯域には何の制限も掛けていません。制限した資源と、実際に枯渇した資源が違っていました。

なぜ「上限を掛ければ安全」が間違いだったのか

この考え方には隠れた前提がありました。「危ないのはメモリだ」という前提です。前回メモリで落ちたので、そう思い込んでいました。

しかし実際に起きたのは、前回と同じコマンドが、前回と違う資源を枯渇させたという事象です。同じ処理でも、そのときのネットワーク状況や取得量によって、どこが先に限界に達するかは変わります。

整理すると、こうなります。

「上限を掛ければ安全」が成り立つのは、限界に達する資源を正しく当てられたときだけ
資源は1種類ではない。CPU、メモリ、ディスク、帯域、接続数、ファイル記述子…
そして実際に詰まる場所は、機体の構成によって変わる。大きい機体で問題にならなかった資源が、小さい機体では最初に尽きる

メモリに上限を掛けたことは、間違いではありませんでした。足りなかっただけです。そして「対策した」という感覚が生まれたぶん、実行の心理的なハードルは下がっていました。

結論: この機体では「安全に試す」が成立しなかった

この件のあと、対策として検査を追加する方向は採りませんでした。そのコマンドの使用自体を、確認だけの用途も含めて全面的にやめることにしました。

理由は、そもそも試す行為のコストが、機体の容量を超えていたからです。「もっとうまく制限を掛ければ安全に試せる」を追いかけても、その試行そのものが本番を止めます。安全に試す方法を探す作業自体が、安全でない状態でした。

禁止のルールを書くときは、「なぜ効かないか」まで一緒に書くようにしました。「使用禁止」とだけ書くと、数か月後の自分が「上限を掛ければ大丈夫では」と思いつきます。実際に一度そう思って、それで止めたのです。禁止した理由に、既に試して駄目だった対策まで含めておかないと、同じ発想が戻ってきます。

本筋の解決は、もっと余裕のある機体へ移すことでした。実際、後日そちらへ移行しています。小さすぎる機体は、動かすことはできても保守ができません。更新の確認すらできないというのは、そういう意味です。

復旧手段を、事前に確かめていなかった

もう1つ反省があります。接続できなくなってから、「どうやって強制的に再起動するんだったか」を探すところから始めました。

クラウドのコンソールから操作できることは知っていましたが、実際にやったことはありませんでした。どのメニューにあるのか、どういう名前の操作なのか、対象をどう指定するのか。全部、障害の最中に調べました。この時間は完全に無駄です。

今は、緊急時に使う操作の手順を手元から読める場所に一箇所だけ書いて置いています。サーバーの中に置いても、繋がらないときには読めません。

持ち帰れること

「上限を掛けたから安全」は、限界に達する資源を当てられたときだけ成り立つ。前回落ちた資源と、次に落ちる資源は同じとは限りません
主要な指標が全部正常でも、外からは全滅していることがある。「見ている範囲に異常が無い」を「正常」と読み替えないようにします
小さい機体では、計算資源より先に帯域が尽きることがある。大きい機体の経験がそのまま通じません
「安全に試す方法」を探す行為そのものが危険な場合がある。試行のコストが容量を超えているなら、やめるのが正解です
禁止ルールには「既に試して駄目だった対策」まで書く。書かないと、同じ思いつきが数か月後に戻ってきます
緊急時の操作は、平常時に一度やっておく。手順を探す時間が、そのまま停止時間になります

この件でいちばん効いたのは、「対策した」という感覚が判断を甘くするという部分でした。何も対策せずに打つときは慎重になりますが、上限を掛けた瞬間に安心してしまいました。対策は、それが効く範囲を確かめて初めて対策になります。