コンテナが「暴走」しても大丈夫？リソース制限で守るサーバーの平和
こんにちは！インフラやセキュリティの現場にいると、たまに「サーバーが急に重くなって、何も操作できなくなった！」という悲鳴のような相談を受けることがあります。
実はこれ、「リソース枯渇型DoS（サービス拒否）攻撃」という、非常に厄介なトラブルの典型例なんです。今回は、新人エンジニアの方に向けて、コンテナという便利な仕組みを「安全に使いこなすための防波堤」について、身近な例えを交えてお話ししますね。
—
コンテナは「シェアハウス」、それとも「個室」？
まず、コンテナを「シェアハウス」に例えてみましょう。一つの大きなホストサーバーという建物の中に、いくつものコンテナ（住人）が暮らしている状態です。
もし、ある一人の住人がリビングのキッチンを占領して、24時間ずっと料理を作り続けたらどうなるでしょう？ 他の住人はご飯を作れなくなりますよね。これと同じことがサーバーの世界でも起きます。特定のコンテナがメモリやCPUを限界まで使い切ってしまうと、サーバー全体がダウンしてしまうのです。
これを防ぐのが「リソース制限（クォータ）」です。「君はキッチンを30分だけ使っていいよ」「冷蔵庫は半分までね」と、最初からルールを決めておくわけです。これができていないと、悪意のある攻撃者が「重い処理」をわざと送るだけで、あなたのサーバーは簡単に沈黙してしまいます。
—
メモリの「使いすぎ」を防ぐ設定（Docker Compose編）
では、具体的にどうやって制限をかければいいのでしょうか。Dockerを使っている場合、設定ファイルにほんの数行書き足すだけで、強固な防壁を築くことができます。
以下は、docker-compose.yml でコンテナのメモリ使用量を制限する例です。
version: '3.8'
services:
web-app:
image: my-app:latest
deploy:
resources:
limits:
# メモリを最大512MBまで使用可能にする（これを超えると強制終了）
memory: 512M
# CPUはホストの50%分まで使用可能にする
cpus: '0.5'
reservations:
# 起動時に最低限確保するメモリ量
memory: 128Mここで重要なのは、limits（上限）をしっかりと決めることです。泥棒（攻撃者）が「メモリを大量に食う攻撃コード」を送り込んできても、この設定があれば512MBに達した瞬間にOSがそのコンテナを強制終了させてくれます。
「えっ、強制終了したらサービスが止まりませんか？」と心配になりますよね。その通りです。でも、「個別のコンテナが止まる」ことと、「サーバー全体がフリーズして他のすべてのサービスが止まる」ことを天秤にかけたとき、選ぶべきは前者なのです。全体を守るための「安全装置」だと考えてくださいね。
—
「魔法の数字」を探す泥臭い現場の知恵
さて、ここで新人の方が陥りやすい罠があります。それは「適当な数字を入れてしまうこと」です。
- 制限が厳しすぎる： 正常なアクセスが来ても、すぐにメモリ不足でコンテナが落ちる（サービスにならない）。
- 制限が緩すぎる： 攻撃を防げない。
現場のプロは、まず「通常時の消費量」を計測します。docker stats というコマンドを叩くと、リアルタイムで各コンテナがどれくらいリソースを使っているか確認できます。
# 現在稼働中の全コンテナのリソース消費状況を表示する
docker statsこの数値を数日間観察し、「普段はこれくらい、スパイク（急増）してもこれくらい」というベースラインを見極めてから、少し余裕を持たせた上限値を設定するのが鉄則です。セキュリティは勘ではなく、観測とデータの上に成り立つものなんですよ。
—
セキュリティは「心の余裕」から
今回紹介した設定は、いわば「家のドアに頑丈な鍵をかけ、部屋ごとにパーテーションで区切る」ようなものです。
もちろん、これだけで全ての攻撃が防げるわけではありません。でも、「特定のコンテナが暴走しても、サーバー全体には影響を出させない」という境界線を引くだけで、インシデント発生時の被害範囲を最小限に抑えることができます。
セキュリティ対策は、完璧を目指すと苦しくなります。まずは「リソース制限をかける」という一歩から、一緒にサーバーの防犯レベルを上げていきましょう。
次に何かトラブルが起きたとき、この「リソース制限」という防波堤があることを思い出してくださいね。それだけで、あなたのエンジニアとしての安心感は大きく変わるはずです。
それでは、また次回のブログでお会いしましょう！安全なインフラライフを楽しんでくださいね。
コメント