はじめに
第3回ではDocker Composeを取り上げ、「複数コンテナ構成を設計として管理する」考え方を整理しました。
しかし、コンテナが本当に評価されるのは本番運用に入ってからです。
Docker/Composeは「動かす」こと自体は難しくありません。
一方で本番では次のような課題が必ず出ます。
- 障害が起きたとき、どこを見ればよいか分からない
- ログが散らばっていて原因調査に時間がかかる
- 監視が不十分で、気づいたら止まっていた
- バックアップはあるが、復旧できる保証がない
コンテナ環境の運用は、VM運用と似ているようで違います。
特に情シス担当者が注意すべきなのは、「コンテナは消して作り直す前提」で設計する必要がある点です。
第4回では、コンテナを本番で扱ううえで最重要となる
ログ・監視・バックアップを、実務目線で解説します。
ログ設計：まず「出す場所」を決める
コンテナ運用で最初に整備すべきなのがログです。 ログがなければ、障害対応は「勘と経験」になります。
よくある失敗：ログがコンテナの中にしかない
Dockerを使い始めた直後によくあるのが、ログがコンテナ内に書き込まれている状態です。
この状態でコンテナを作り直すと、ログも消えることがあります。
業務システムでは、次のようなログは特に重要です。
- Webアクセスログ（誰が何をしたか）
- アプリケーションログ（例外・業務エラー）
- DBログ（接続・スロークエリ）
これらが残らないと、監査・調査・復旧のすべてが難しくなります。
基本方針：ログは「標準出力」に出す
Dockerのログ設計で最も重要な原則は、 ログはファイルではなく標準出力（stdout/stderr）に出すという考え方です。
これは一見、違和感があるかもしれません。
しかしDockerでは、標準出力に出したログをDockerが収集し、以下のように確認できます。
- docker compose logs
- docker logs
この方式なら、コンテナを作り直してもログ収集の流れを維持できます。
ログの保管期間を決める（運用ルール）
ログは残せば良いわけではありません。
本番運用では必ず「ログが肥大化してディスクが枯渇する」問題が起きます。
情シスが決めるべきルールは次の通りです。
- ログ保管期間（例：30日、90日、1年）
- 保存先（ローカル、クラウド、ログ基盤）
- 誰が閲覧できるか（権限）
コンテナ運用は「ログを貯めやすい」反面、
無計画だと「ログで障害が起きる」典型パターンに入ります。
監視設計：コンテナは「止まるもの」として扱う
本番運用で次に重要なのが監視です。 コンテナは、プロセスが落ちればコンテナごと停止します。
つまり監視対象は、従来のサーバ監視よりも明確になります。
監視は3層で考える
監視は次の3層で整理すると分かりやすいです。
- 死活監視：コンテナが起動しているか
- リソース監視：CPU、メモリ、ディスク、ネットワーク
- サービス監視：HTTP 200が返るか、DB接続できるか
特に重要なのは、死活監視だけでは不十分という点です。
コンテナが動いていても、アプリが内部でエラーを出し続けているケースがあります。
restartポリシーは「保険」だが万能ではない
Composeではrestartポリシーを設定できます。
例えばアプリが落ちたら自動で再起動する、といった設定です。
これは有効ですが、万能ではありません。
- 根本原因が解消されないと再起動ループになる
- DBが壊れている場合は再起動しても復旧しない
- ログが膨大になり、別の障害を誘発する
restartは「止まりっぱなしを防ぐ保険」として位置づけ、
本質的には監視とアラートで人が把握できるようにする必要があります。
healthcheckを本番で必ず使う理由
第3回でも触れたhealthcheckは、本番では特に重要です。
healthcheckがあると、
- コンテナが起動しているが、サービスとして死んでいる
- DBが起動したが、接続可能になっていない
といった「中途半端な状態」を検知できます。
情シス担当としては、
「起動している＝稼働している」ではない
という点を運用ルールに落とし込む必要があります。
バックアップ設計：最重要は「復旧できること」
バックアップは、コンテナ運用で最も誤解が多い領域です。
よくあるのが「ボリュームがあるから大丈夫」という誤解です。
バックアップ対象は3種類ある
コンテナ環境で守るべきものは、次の3つです。
- データ（DB、アップロードファイル）
- 設定（.env、Composeファイル）
- 構築情報（Dockerfile、イメージタグ）
この3つのどれが欠けても、復旧は難しくなります。
DBバックアップ：mysqldumpだけでは足りない場合がある
DBバックアップでよく使われるのはmysqldumpです。
これは有効ですが、業務規模が大きくなると課題が出ます。
- バックアップ時間が長い
- 復旧時間も長い
- 大容量だと失敗しやすい
この場合、スナップショット方式や、レプリケーションを含む設計が必要になります。
重要なのは、バックアップ方式を「技術」ではなく「復旧要件」で決めることです。
ファイルバックアップ：見落とされがち
業務システムでは、DBだけでなくファイルも資産です。
- 添付ファイル
- 帳票PDF
- 画像
これらが消えると、DBが無事でも業務は止まります。
特にクラウド移行や引継ぎの場面では、ファイル領域が漏れているケースが非常に多いです。
最重要：復旧テストを「定期的に」実施する
バックアップがあるだけでは意味がありません。
復旧できることが確認されて初めて、バックアップは価値を持ちます。
運用で最低限必要なのは、次の2つです。
- 復旧手順書（誰が見ても復旧できる形）
- 復旧テスト（年1回でもよいので実施）
情シスが本当に困るのは、障害時に「復旧できるはず」が崩れる瞬間です。
コンテナ運用では、復旧テストがしやすいという利点があります。
この利点を活かすべきです。
運用セキュリティ：コンテナだから安全、ではない
最後に、運用で必ず意識すべきセキュリティを整理します。
最低限押さえるべきポイント
- 不要なポート公開をしない（特にDB）
- .envの管理を徹底する（Gitに入れない）
- コンテナ内に秘密情報を埋め込まない
- イメージの更新（脆弱性対応）を止めない
コンテナ運用では「動いたら放置」が起きやすいですが、
それはそのまま脆弱性放置につながります。
次回予告
次回はいよいよ最終回として、 コンテナ導入を成功させるための実務ステップを扱います。
- PoCから本番への進め方
- 既存システムを止めずに移行する考え方
- 運用引継ぎで「必ず残すべきもの」
- チーム体制（情シス・開発・ベンダー）の作り方
単にDockerを導入するのではなく、
業務として継続運用できる形に落とすところまで解説します。
