詳細設計で決めること【後編①】｜OS設計の実務

※この記事は「詳細設計で決めること」3部作の後編①です。前編はこちら、後編②はnoteで公開しています。

前編では、詳細設計を単なるパラメータ表ではなく、基本設計で決めた方式を構築・テスト・運用・保守へ接続する工程として整理しました。

後編①では、その考え方をOS、Web/APサーバ、DB、ジョブの4領域に展開します。これらは、システムの処理方式と性能・可用性を直接左右する領域であり、設計の甘さが構築工程やシステムテストで手戻りとして現れやすい領域でもあります。

前編を読んでいない方は、先に前編をお読みいただくと、各章の「なぜその観点が重要か」が伝わりやすくなります。ただし、担当領域の章だけを辞書的に参照する使い方でも成立するように書いています。

詳細設計で具体化する主な領域

OS詳細設計では、サーバの基本的な設定を具体化します。

ホスト名、IPアドレス、ディスク構成、ファイルシステム、ユーザ、グループ、権限、時刻同期、名前解決、OSパッケージ、サービス起動設定、カーネルパラメータ、ログ設定、セキュリティ設定などが対象になります。

OS詳細設計は、単にOSをインストールするための設定表ではありません。そのサーバがシステム内でどの役割を担うのかを反映する設計書です。

Webサーバなのか、APサーバなのか、DBサーバなのか、運用管理サーバなのか。役割によって、必要なパッケージ、起動サービス、ファイアウォール設定、ログ、監視、権限は変わります。

また、OS詳細設計は、運用にも直結します。

こうした内容は、構築だけでなく、監視、ログ、セキュリティ、運用手順とつながります。

特にOSログのローテーションは、監視設計とセットで確認します。

たとえば、`/var/log/messages` のようなOSログをログ監視製品で監視している場合、ログローテーション方式によって、監視対象が意図せずずれることがあります。

ログローテーションには、ファイルをリネームして新しいログファイルを作る方式、コピーしてから元ファイルを空にする方式、アプリケーションやsyslogにログファイルを再オープンさせる方式などがあります。

一方、ログ監視製品によっては、単にファイル名だけを見ているのではなく、監視開始時点のファイル実体やファイルハンドルを追跡する挙動になることがあります。

この挙動を理解しないまま、`logrotate`、`cp`、`touch` などを組み合わせてログローテーションを設計すると、監視製品がローテーション後の古いファイルを追い続け、新しい `/var/log/messages` に出力されたエラーを拾えなくなる場合があります。

その結果、実際の /var/log/messages にはエラーが大量に出ているのに、監視製品はそのログを見ていないため、アラートが発報されない、という事態が起きます。

これは、OSログ設計だけを見ていると気づきにくい問題です。

ログローテーションの設計は、OS詳細設計、ログ詳細設計、監視詳細設計の境界にあります。

そのため、OSログをローテーションする場合は、次の点を確認します。

OSログのローテーションは、単に古いログを退避するだけの設定ではありません。

監視対象のログを、ローテーション後も監視し続けられるかまで含めて設計します。

ここを確認しないまま本番稼働すると、ログは出ているのに監視できていない、という非常に危険な状態になります。

実際の現場でも、ログローテーション後に監視製品が古いログファイルを追い続け、新しい messages を監視できていなかった、というトラブルは起こりえます。

OS詳細設計で検討すべき主な観点は以下のとおりです。

この章で確認したい問いは、次の3つです。