server-management

サーバー管理

本番運用のためのサーバー管理の原則です。 コマンドを暗記するのではなく、考え方を学びましょう。

---

1. プロセス管理の原則

ツールの選択

シナリオ	ツール
Node.js アプリ	PM2（クラスタリング、リロード）
あらゆるアプリ	systemd（Linux ネイティブ）
コンテナ	Docker/Podman
オーケストレーション	Kubernetes、Docker Swarm

プロセス管理の目標

目標	意味
クラッシュ時の再起動	自動復旧
ダウンタイムなしのリロード	サービスの中断なし
クラスタリング	すべての CPU コアを活用
永続化	サーバー再起動後も維持

---

2. 監視の原則

監視対象

カテゴリ	主要メトリクス
可用性	稼働時間、ヘルスチェック
パフォーマンス	応答時間、スループット
エラー	エラー率、種類
リソース	CPU、メモリ、ディスク

アラートの重大度の方針

レベル	対応
Critical	即時対応
Warning	早めに調査
Info	毎日確認

監視ツールの選択

ニーズ	選択肢
シンプル/無料	PM2 メトリクス、htop
包括的な可観測性	Grafana、Datadog
エラー追跡	Sentry
稼働監視	UptimeRobot、Pingdom

---

3. ログ管理の原則

ログの方針

ログの種類	目的
アプリケーションログ	デバッグ、監査
アクセスログ	トラフィック分析
エラーログ	問題の検出

ログの原則

1. ディスクの枯渇を防ぐためにログをローテーションする
2. 解析しやすいように構造化ログ（JSON）を使う
3. 適切なレベル（error/warn/info/debug）を使う
4. ログに機密データを含めない

---

4. スケーリングの判断

スケーリングのタイミング

症状	解決策
CPU 使用率が高い	インスタンスを追加（水平）
メモリ使用量が多い	RAM を増やすかリークを修正
応答が遅い	まずプロファイリングし、その後スケール
トラフィックの急増	自動スケーリング

スケーリングの方針

種類	使用するタイミング
垂直	手早い対応、単一インスタンス
水平	持続可能、分散型
自動	トラフィックが変動する場合

---

5. ヘルスチェックの原則

正常とみなす条件

チェック	意味
HTTP 200	サービスが応答している
データベース接続	データにアクセスできる
依存関係が正常	外部サービスに到達できる
リソースが正常	CPU/メモリが枯渇していない

ヘルスチェックの実装

• シンプル: 単に 200 を返す
• 詳細: すべての依存関係を確認する
• ロードバランサーの要件に応じて選択する

---

6. セキュリティの原則

領域	原則
アクセス	SSH キーのみを使用し、パスワードは使わない
ファイアウォール	必要なポートのみを開放する
アップデート	定期的にセキュリティパッチを適用する
シークレット	ファイルではなく環境変数で管理する
監査	アクセスと変更をログに記録する

---

7. トラブルシューティングの優先順位

何か問題が発生した場合:

1. 実行中か確認する（プロセスの状態）
2. ログを確認する（エラーメッセージ）
3. リソースを確認する（ディスク、メモリ、CPU）
4. ネットワークを確認する（ポート、DNS）
5. 依存関係を確認する（データベース、API）

---

8. アンチパターン

❌ やめるべきこと	✅ 推奨
root で実行する	root 以外のユーザーを使う
ログを無視する	ログのローテーションを設定する
監視をしない	初日から監視する
手動での再起動	自動再起動の設定
バックアップがない	定期的なバックアップのスケジュールを作る

---

覚えておきましょう: 適切に管理されたサーバーは退屈なものです。それこそが目標です。