サーバーへの同居設計 — 1台に何を載せ、どこで分けるか

サーバーの同居設計で最初に問うべきは「何を分けるか」ではなく「何を一緒に落としてよいか」という許容の定義です。役割の境界を引かないまま機能を積み上げると、障害時の影響範囲が読めなくなり、スケールアップの判断軸も失われます。この記事では同居と分離の判断基準・陥りやすいアンチパターン・比較表・設計チェックフレームを実装担当者の視点で整理します。

とりあえず1台に全部載せて影響範囲が読めない構造

「一旦1台に」が招く依存の複雑化

プロジェクト初期に「とりあえず1台」という判断をすること自体は珍しくありません。問題はその後にあります。WebサーバーとDBとバッチと監視ツールを同じOSに積み上げると、どのプロセスが何に依存しているかが設定ファイルの中にしか存在しなくなります。構築を任されたある担当者が「nginx再起動でバッチが落ちた」という報告を受けて調査したところ、バッチが/var/www/html配下のファイルを直接参照していたことが判明した、という話は珍しくありません。依存が明示されていない構造は、変更のたびに全体の調査コストを要求し続けます。

リソース競合が設計問題として顕在化しない理由

CPUとメモリは共有されているため、あるプロセスが負荷を高めると他のプロセスが遅くなります。この遅延は最初のうち「一時的な詰まり」として処理されがちで、設計の問題として認識されるまでに時間がかかります。バッチ処理が深夜に走るタイミングでWebの応答が悪化する、という現象は典型例です。3〜5台構成のステージング環境でさえ、役割の境界を引かずに構築すると、負荷の発生源を特定するのに半日以上かかることがあります。根本原因がリソース競合だと気づいた時点では、すでに別の問題として運用が固まっていることも少なくありません。

影響範囲が「感覚」でしか語れない状態

全部同居の最大の問題は、何かが壊れたときに「どこまで影響が出るか」を事前に答えられない点です。障害対応の場で「たぶんWebだけ落ちてる」「バッチも止まってるかも」という推測が飛び交う現場は、同居設計の問題を引き継いでいます。影響範囲を事後に特定しようとすると、ログを横断で追いながらプロセスの起動順序も確認するという作業が重なり、MTTR（平均復旧時間）が伸びます。設計段階で「この役割が落ちたらここまで影響する」という単位を決めておくことが、障害対応の速度に直結します。

同居させてよい役割と必ず分ける役割の判断

同居を許容できる3条件の整理

役割を同居させてよいのは、次の3条件がそろっているときです。まず「片方が落ちても、もう片方を止めてよい」という可用性の合意があること。次に「リソースの奪い合いが起きても業務上許容できる」という要件が確認されていること。そして「デプロイ・再起動の単位が一致している」ことです。たとえばWordPressのWebとPHPを同じサーバーに置くのは典型的な許容パターンです。両者はセットで動き、一方だけのリリースはほぼ発生しません。この3条件を一つでも満たさない組み合わせは、同居のコストが上がりはじめるサインと見てください。

必ず分けるべき役割の見極め

セキュリティ要件・可用性要件・リリースサイクルのいずれかが大きく異なる役割は、同居の対象から外します。DBとWebフロントを同居させると、Webの脆弱性をついた攻撃がDBに直接到達するリスクが高まります。バッチとAPIを同居させると、月次バッチの実行中にAPIのレスポンスタイムが劣化し、SLAに影響します。デプロイ頻度が週複数回のAPIと月1回のバッチを同じサーバーで管理すると、リリースのたびにバッチの停止確認が必要になり、工数が積み上がります。「リリース単位が異なる」という基準は、実務上もっとも見落とされやすい分離の根拠です。

セキュリティ境界と可用性要件が判断を変える局面

社内システムと外部公開サービスを同じサーバーに置くことは、ネットワーク設計によっては許容できる場合もありますが、セグメント分離ができていない環境では避けることを推奨します。高可用性が求められるサービスにフェイルオーバーを組む場合、同居しているプロセスが多いほど構成が複雑になり、フェイルオーバーの動作確認コストも増えます。PCI DSS準拠やISMS審査を伴う環境では役割ごとの分離がほぼ必須になるため、要件確認のタイミングで分離の方針を固めることが重要です。要件が後から追加されると、分離のやり直しコストは設計段階の数倍に膨らみます。

比較: 全部同居・役割別分離・コンテナ分離の選定軸

3パターンが合う局面の整理

全部同居・役割別の物理/VM分離・コンテナ分離の3パターンは、規模とチームの運用能力によって使い分けが変わります。サーバー数が10台以下の小規模環境では全部同居か部分的な役割分離が現実解になることが多く、コンテナ分離はオーケストレーション層の管理スキルが伴わないと逆にリスクが上がります。一方で20〜30台以上の規模になると、役割別分離の設計コストよりも全部同居の運用コストが上回るケースが多く見られます。以下の比較表で選定の軸を整理します。

観点	全部同居	役割別分離（物理/VM）	コンテナ分離
障害の影響範囲	全プロセスに波及	役割単位で限定	コンテナ単位で限定
リソース競合	制御困難	OSレベルで分離	cgroupsで制限可
セキュリティ境界	境界なし	ネットワーク境界あり	プロセス境界（ホスト共有）
デプロイの独立性	低（全体停止リスク）	高	高（イメージ単位）
管理コスト	低（台数が少ない間）	台数比例で増加	オーケストレーション層が必要
向いている規模感	〜5台・プロトタイプ	5〜50台・本番環境	マイクロサービス・大規模

巻き添えの範囲とコストの折り合いのつけ方

「許容できる障害の単位」を先に定義する

分離設計を始める前に、まず業務側と「何が一緒に落ちてよいか」を合意することが先決です。「DBが落ちたらWebも停止してよい」という合意があれば、同居を選ぶ根拠になります。逆に「DBが落ちてもキャッシュで最低限のレスポンスを返したい」という要件があれば、DBとWebの分離とキャッシュ層の独立が設計課題に加わります。許容できる障害の単位を定義せずに分離設計を始めると、「念のため分ける」判断が続き、台数だけが増えて運用コストが上がります。業務要件と設計の間にこの定義を挟むことが、過剰分離を防ぐ起点です。

分離コストと運用コストの天秤の引き方

物理サーバーを1台追加すると、ラック・電源・ネットワーク・OS設定・監視設定・バックアップ設定がセットで増えます。環境数が3つ（本番・ステージング・開発）あれば、1役割の分離だけで最低3台の追加管理が発生します。VMやクラウドインスタンスを使えばハードウェアコストは下がりますが、管理する構成ファイルとセキュリティグループの数は台数に比例して増えます。「分けること自体のコスト」を分離の判断に含めないと、後から運用が行き詰まる設計になります。コストは決裁の根拠ではなく設計判断の材料として扱うことが重要です。

巻き添えリスクを下げる中間解の設計

すべてを分離できない場合は、「巻き添えを受けたときのリカバリ速度」を上げる設計で対処できます。同居するプロセスのsystemdユニットに依存順序を明示し、再起動時の順序を制御するだけでMTTRを大幅に短縮できます。プロセスを物理的に分けなくても、cgroupsでCPUとメモリの上限を役割ごとに設定しておけば、リソース競合による巻き添えを一定の範囲に限定できます。操作の詳細はLinux設定ドキュメントで補いながら、設計としては「完全分離・制限設定・許容」の3択で整理すると判断がしやすくなります。

分けた後の通信経路と依存関係をどう整理するか

分離後に発生するサービス間依存の可視化

物理的に分けても、プロセス間の依存関係はなくなりません。それがネットワーク越しになるだけです。分離後に「このサービスはあのサービスのどのポートに依存しているか」を図に起こさずに運用を始めると、ファイアウォールルール変更や証明書更新のたびに影響範囲の確認に時間がかかります。最初は手書きでも構いません。依存の向きと通信ポートを一枚の図に落とし、変更のたびに更新するルールにするだけで、障害時の調査速度が変わります。「図が描けるか」を確認することが依存整理の第一歩です。

内部ネットワーク通信かAPI境界かの設計判断

分離したサービス間の通信を「内部ネットワーク直接通信」か「APIを通じた境界通信」かで選ぶとき、判断の軸は「将来の独立デプロイを想定するか」です。内部ネットワーク直通はレイテンシが低く実装が単純ですが、呼び出し側が相手のデータ構造に直接依存します。API境界を設けると変更の影響範囲が境界で止まりますが、スキーマの維持と認証の設計が別途必要になります。小規模環境では内部通信の直通から始め、変更頻度が上がってきた段階でAPI境界を検討する段階的なアプローチが現実的です。

依存グラフを単方向に保つ重要性

サービスAがBに依存し、BがAに依存するという循環依存は、どちらかが落ちると両方が復旧できないデッドロックを招きます。構築段階では「依存は必ず一方向にする」という原則を守ることが、後のデプロイ順序・再起動順序・フェイルオーバー設計をすべて単純化します。循環依存が生まれる多くのケースは、ロールを分離した後に「どうしても双方向に呼び合う処理」が出てきたときです。その場合はメッセージキューや共有DBを仲介に置いて直接の循環を切ります。依存グラフのレビューを設計レビューの項目に加えておくと、実装後の発見を防げます。

分けすぎて台数と運用が回らなくなる境界

過剰分離が生む運用負荷の実態

「役割ごとに分ける」を徹底した結果、5人チームで30台以上のサーバーを管理することになり、OSパッチ適用だけで丸一日かかるという状況は現場でよく聞かれます。サーバーが増えると、証明書更新・OS更新・ミドルウェアバージョン管理・監視アラートの調整がすべて台数分だけ発生します。インフラ担当が1〜2名の組織で10台を超えるサーバーを個別管理しようとすると、自動化ツールを導入しても管理の認知負荷は確実に上がります。「分けること」が目的化した構成は、運用フェーズに入った時点で息切れします。

適切な粒度を見極める判断基準

適切な分離の粒度を決める基準は「チームが責任を持って継続管理できる単位か」です。可用性要件・セキュリティ要件・リリース頻度が同じ役割はまとめて1台に収めても問題ないケースが多くあります。たとえばログ収集エージェント・監視エージェント・バックアップエージェントは、監視対象サーバーに同居させるのが標準的な設計です。これらを個別サーバーに分けることはほぼありません。分離の必要性は「要件の差分」から生まれるものであり、ポリシーや慣例から一律に生まれるべきではありません。

縮退設計と分離粒度の両立

サービスを分離した後、どれかが落ちたときに縮退して動き続けられるかという観点も分離の粒度に影響します。APIサーバーとDBを分離した場合、DBが落ちたときにAPIをキャッシュ応答で縮退させるという設計は、分離があって初めて成立します。一方で分離台数が増えすぎると、縮退パターンの数も増え、テストしなければならない組み合わせが増加します。「落ちても影響が限定される境界線」を意識して分離の粒度を設定することが、過剰分離を防ぐ実践的な視点です。

同居設計チェックフレーム

設計レビューの場で使える確認項目を以下に示します。「はい」が続く組み合わせは同居を許容できる候補、「いいえ」が増えるほど分離の根拠が強まります。チェックの結果が拮抗するときは「リリース単位の一致」と「セキュリティ境界の有無」を優先の判断軸にします。

1. 片方が停止したとき、もう片方も停止してよいと業務側と合意できているか
2. リソース（CPU・メモリ・I/O）の奪い合いが発生しても業務上許容できるか
3. デプロイ・再起動の単位が一致しているか（リリース頻度が同程度か）
4. セキュリティ境界が同じレベルで要求されているか（外部公開と内部処理の混在がないか）
5. 障害が発生したとき「何が落ちているか」を短時間で特定できる構造になっているか
6. 現在のチーム人数・スキルで分離後の台数を継続管理できるか
7. 分離後のサービス間通信の依存グラフが単方向で描けるか
8. 縮退パターンが増えても、定期的に動作確認できる体制があるか

このチェックを設計段階で一巡させておくと、後から「なぜここを分けなかったのか」「なぜここを分けたのか」という問いに対して、設計の根拠を言語化して答えられる状態になります。同居設計の意思決定は一度下すと変更コストが高いため、要件定義と並行して判断を記録しておくことが長期の運用を支えます。