【ITニュース解説】I Ran a Whole Content Pipeline on a $7 VPS With 2GB of RAM (And the 3am Crash That Taught Me Why)

システムエンジニアを目指す皆さんが、サーバーの運用で直面する可能性のある重要な教訓について説明する。ある開発者が、わずか2GBのメモリを搭載した月額7ドルのVPS（Virtual Private Server）でコンテンツの生成から配信までを行うパイプラインを構築・運用していた時の出来事だ。彼は、夜中にサーバーが突然クラッシュし、完全に停止するという深刻な問題に直面した。深夜3時にcronジョブ、つまり定期実行される自動処理が動き始め、そのわずか2分後にはサーバーへのアクセスが一切できなくなった。SSH接続はタイムアウトし、ログファイルにも何も記録が残されていなかった。これは、ログを書き出すためのプロセス自体が、サーバーによって強制終了されてしまったためである。

このトラブルの原因は、プログラムのバグではなかった。問題は、サーバーのメモリ容量と処理に必要なメモリ量との間の単純な計算ミス、つまり「算術」的な問題だった。開発者のラップトップ上では問題なく動作していたバッチ処理が、VPS上では利用可能なメモリよりも多くのメモリを必要としていたのだ。サーバーのOSカーネルは、メモリが不足すると、システム全体の安定性を保つために、最も多くのメモリを消費しているプロセスを強制的に終了させる機能を持っている。これをOOM Killer（Out Of Memory Killer）と呼ぶ。今回の場合、このOOM Killerによって、パイプラインの処理だけでなく、ログを記録する仕組みまでもが停止させられてしまったため、サーバーは沈黙してしまったのである。

安価なサーバーと高性能なサーバーでは、メモリ不足時の挙動が大きく異なるという点も、この経験から学べる重要なポイントだ。大規模な高性能サーバーであれば、メモリが逼迫しても、通常は処理が遅くなるというパフォーマンスの問題として現れることが多い。しかし、2GBといった限られたメモリしかない安価なサーバーの場合、メモリ不足は「パフォーマンス低下」ではなく、即座に「完全な停止」という可用性の問題を引き起こす。サーバーは単に動作が遅くなるのではなく、完全に機能しなくなってしまうのだ。そして、こうした事態は常に、最も避けたい深夜3時といった時間帯に発生するものだ。

このような突然のサーバー停止のほぼ常に根本原因となるのは、複数の処理が同時に実行される「並行性」である。特に画像処理やファイル操作といったメモリを多く消費する処理を複数同時に実行すると、一時的に必要なメモリ量が大幅に増加する。ここで重要になるのは、処理全体の「平均」メモリ使用量ではなく、「ピーク」時のメモリ使用量だ。例えば、平均して300MBのメモリしか使わないように見えるジョブでも、一時的に2.4GBものメモリを必要とする瞬間があれば、2GBのサーバーは確実にクラッシュしてしまう。平均値はあたかも問題ないかのように見せる「心地よい嘘」であり、ピーク時の値こそが「真実」なのである。

この問題に対して開発者が導入した解決策は、以下の通りだ。まず、最も効果的だったのは「一度に一つのプロセスだけを実行する」という方法だった。これだけで、それまで頻繁に発生していたクラッシュはぴたりと止まった。複数の処理を並行して実行していた時よりも感覚的には遅く感じるかもしれないが、サーバーが完全に停止して一晩中復旧作業に追われる事態を考えれば、実際にははるかに効率的だった。次に、「ピークメモリ使用量を測定する」という取り組みを始めた。各処理ステップで最も多くメモリを消費する量を具体的に計測し、把握するようにしたのだ。この情報に基づいて、サーバーのリソースに合わせた設計が可能になる。さらに、Pythonなどのプログラミング言語では、不要になった大きなオブジェクトがすぐにOSにメモリを返さないことがあるため、「処理ステップ間に明示的にメモリを解放する」という対策も行った。具体的には、ガベージコレクタを強制的に実行し、OSが利用できるメモリを増やすことで、ピークメモリ使用量を抑えることができた。最後に、「入力データのサイズを制限する」という工夫も重要だった。クラッシュの原因となったバッチ処理は、必要以上に大きなデータセットを一度に処理しようとしていた。これをより小さなチャンク（塊）に分割して処理することで、一度の実行で消費するピークメモリ量を大幅に削減することができた。これにより、全体として処理するデータの総量は変わらないにもかかわらず、サーバーへの負荷を適切に管理できるようになった。

これらの経験から、小さなサーバーで運用する際に従うべき明確なルールが生まれた。第一に、「重いジョブは一度に一つだけ実行する」こと。これには例外を設けてはならない。第二に、「各処理ステップのピークメモリ使用量をスケジュールする前に把握しておく」こと。これにより、予期せぬメモリ不足を防げる。第三に、「入力データをチャンク化し、一度の実行でメモリ予算を超えないようにする」こと。大きなデータは分割して処理することが鉄則だ。第四に、「ジョブをべき等にする」こと。べき等とは、何度実行しても同じ結果になる性質を指す。これにより、もし途中でジョブが失敗しても、安全に再実行できるため、システムの回復力が高まる。そして最後に、「スワップの使用状況を監視する」こと。スワップは、物理メモリが不足した際に一時的にディスクをメモリの代わりに使う機能だが、これが頻繁に発生している場合は、クラッシュが起きる前の初期警告と捉えるべきだ。

最終的に開発者が得た教訓は、非常にシンプルなものだった。彼は一週間もの間、コードのどこかにバグがあるのではないかと疑い、修正を試みた。しかし、実際にはコードに問題はなかったのだ。彼がしていたのは、2GBのサーバーに16GBのサーバーのような振る舞いを期待するという、根本的に無理な要求だった。どんなに巧妙なプログラミングのテクニックを使っても、物理的なリソースの限界を乗り越えることはできない。結局のところ、一番退屈に思えるような解決策、つまり「一度に一つのプロセスだけを実行し、より小さなバッチで処理する」という方法が、最初から効果を発揮したのだ。安価なインフラは、知恵や工夫で「出し抜く」ことができるような制限ではない。それは、私たちが「尊重すべき予算」であり、その限界を正しく理解し、それに合わせてシステムを設計・運用することが、安定稼働への鍵となる。この経験は、システム開発や運用に携わる上で、リソースの制約を現実的に捉え、それに基づいた堅実な設計を行うことの重要性を強く示している。