SSHでログインしようとしても入れない。
ALTER SYSTEM を実行しようとしても通らない。
オンプレで使っていた SYSDBA 前提の操作が、そのまま使えない。

サーバーは動いている。Oracleも動いている。なのに、これまで当たり前に使っていた運用手順が通用しない。

原因は、DBの設定ミスでも権限設定の漏れでもありませんでした。

RDSがマネージドサービスとして設計された構造上、オンプレで「当たり前」だった低レイヤーへのアクセスが、そもそも提供されていないのです。

今回の記事で伝えたいのは、RDSが劣っているという話ではありません。

マネージドの恩恵とトレードオフは表裏一体です。RDSを選ぶ時点で、オンプレの運用設計をそのまま持ち込まない前提が必要になります。

ここがポイントです。

なぜRDSではオンプレと同じ運用ができないのか

RDSは、AWSがOSとDB基盤の管理を代行するサービスです。

パッチ適用、バックアップ、フェイルオーバー、レプリケーション。これらをAWS側に任せられる一方で、ユーザーはOSやDBの深いレイヤーに直接触れることができません。

オンプレのOracle運用では、DBAがOSにログインしてリソースを確認し、カーネルパラメータを見直し、SYSDBA権限でDBの内部状態を操作することがあります。しかし、RDS for Oracleではその前提が根本から変わります。

これは単なる制限ではなく、マネージドサービスとしての設計上の選択です。ただし、事前に把握していないと、開発中に次々と壁にぶつかります。

今回、開発中に見えてきたギャップを整理すると、大きく以下の領域に分かれます。

「オンプレの感覚と、RDSで必要になる考え方」

上の図は、オンプレでの感覚と、RDSで必要になる考え方の違いを整理したものです。

ここからは、開発中に実際に表面化した設計ギャップを、具体的に見ていきます。

開発中に見えた設計ギャップ

① ストレージは「空き容量」だけを見ていると詰まる

この案件では、REDOログ・ファイルのサイズを大きく設定していたこともあり、空き容量が少なくなった局面で Storage-Full が発生しました。

Storage-Full になると、インスタンス操作やSQL*Plusでの接続にも影響し、通常の手順では復旧しづらい状態になります。

ここで注意したいのは、「空き容量がまだ少し残っているから大丈夫」とは限らない点です。

Storage-Full になると、インスタンス操作やSQL*Plusでの接続にも影響し、通常の手順では復旧しづらい状態になります。

オンプレであれば、OSにログインして一時的に領域を空ける逃げ道があります。しかし、RDS for OracleではOS上で直接ファイルを操作できません。容量が詰まってから「中に入って何とかする」ことはできず、ストレージ拡張など、RDSとして提供されている操作で対応する必要があります。

そのため、REDOログやアーカイブログのサイズ、生成量、一時的な蓄積を含めてストレージ容量を設計する必要があります。REDOログのサイズを不用意に大きくすると、容量の小さい環境では問題が表面化しやすくなります。本番環境よりも開発環境で先に問題が出るパターンです。

② アーカイブログは「出した後」の挙動まで設計する

この案件では、アーカイブログが一度RDS側のストレージに出力され、その後S3へ転送される構成でした。ただし、S3へ転送されるまで、また転送後にRDS側から削除されるまでにはタイムラグがあります。アーカイブログは生成後すぐに容量影響がゼロになるわけではありません。

退避先を用意していても、転送されるまでの間、削除されるまでの間はRDS側のストレージを使います。

生成量が多いタイミングでは、特に容量の小さい開発環境で、この一時的な蓄積によって Storage-Full になるケースがありました。

アーカイブログは「出したら終わり」ではありません。RDSでは、出力、転送、削除まで含めて容量設計する必要があります。

③ ストレージは増やせるが、必要な分を即座に増やせるわけではない

ストレージを拡張する際、以下の2点に注意が必要です。

拡張サイズは現在の割り当てから10%以上でないとエラーになる
小刻みな拡張はできません。10%未満の増量を指定するとエラーで拒否されます。開発環境のように小さい容量で構築していると、この制約が意外と効いてきます。

ストレージ変更後、一定時間は再度の変更ができない
拡張後は `storage-optimization`（ストレージ最適化）ステータスになり、完了まで数時間から数十時間かかります。ストレージ最適化が完了するか、変更から6時間が経過するまでのいずれか長い方が経過するまで、次のストレージ変更はできません。

使用量が急増するケースでは、連続した拡張ができないため、「足りなくなったら少しずつ増やせばよい」という考え方が通用しない場合があります。初期サイジングを余裕を持って設計することが重要です。

④ オンプレで当たり前だった管理操作が、別の手段に置き換わる

RDS for Oracleでは、オンプレのように SYSDBA で接続してDB全体を自由に操作する前提ではありません。代わりに以下の2つが用意されています。

RDSのマスターユーザー（master_user）
DBA権限を持ちますが、システム変更に関する一部操作が制限されます。オンプレと同じSQLをそのまま実行できない場合があります。

RDSADMINユーザー
ユーザーが直接使用することはできません。ただし、AWSが用意したパッケージやプロシージャを経由することで、システム変更に関する操作が可能です。

たとえばログスイッチは、以下のように変わります。

-- オンプレ
ALTER SYSTEM SWITCH LOGFILE;

-- RDS for Oracle
EXEC rdsadmin.rdsadmin_util.switch_logfile;

対応コマンドは少しずつ増えていますが、現時点でもカバーされていない操作があります。「いつものコマンドが通らない」という場面は、移行後に発生し得る前提で考えておくべきです。移行前に、オンプレで使っているコマンド・操作の棚卸しとRDS側の代替確認が必須です。

⑤ 障害時に必要なファイルを、OS上から直接集められない

RDSではOSへのSSHログインができないため、ファイルへのアクセスは「Amazon RDSプロシージャ」経由に限定されます。

DATA_PUMP_DIR 配下のファイルなど、マネジメントコンソールからダウンロードできないファイルは、RDSプロシージャを使って一旦S3にアップロードしてからダウンロードする手順が必要です。

特に注意が必要なのがADRディレクトリです。オンプレであれば、障害時にADR配下のファイルを確認してOracleサポートへ提供することがあります。しかし、RDS for Oracleでは**「サポートから言われたファイルをOS上で探してzip化する」というオンプレの感覚では動けません。**

RDS for Oracleでは rdsadmin.rdsadmin_adrci_util などを通じてADR関連の情報取得やインシデントパッケージ作成の手段が用意されていますが、オンプレのようにOSログインでファイルを直接収集できるわけではありません。

OracleサポートやAWSサポートに調査資料の提供を求められた場合、何をどの手順で提供できるかは事前に確認しておく必要があります。本番障害が起きてから手順を確立しようとしても遅いです。

⑥ 監査ログや診断ファイルは、出力したまま放置すると障害要因になる

オンプレでは、監査ログやトレースファイルをOS上に出力し、必要に応じて整理・退避する運用を組めます。しかし、RDSではOS上で直接ファイル操作ができません。

この案件では、Oracleのログイン監査で監査証跡をファイルとして出力していたところ、RDS内部のファイル保持数の上限に引っかかり、ファイル書き込みエラーが発生しました。その結果、RDSにログインできなくなる障害につながりました。

RDS内部のファイル保持数には上限がありますが、その上限値はAWSから公開されておらず、ユーザーが変更することもできません。上限値が非公開である以上、「どこまで出力できるか」を事前に把握することはできません。

監査ログ、トレースファイル、ダンプファイルなどをRDS内部に出し続ける設計にする場合は、定期的なクリーンアップ処理を必ず組み込んでください。監査ログはセキュリティ要件を満たすために必要ですが、出力設計を誤ると、監査ログ自体が障害要因になります。

⑦ DBのタイムゾーン設定だけでは、Schedulerジョブの時刻は保証できない

RDS for Oracleでは、オプショングループでタイムゾーンを設定できます。しかし、それだけでOracle Schedulerジョブのタイムゾーンまで意図通りになるとは限りません。

この案件では、RDSのオプショングループでタイムゾーンを設定していても、Oracle Schedulerジョブのタイムゾーンは Etc/UTC のままでした。

日本時間でスケジュール実行したいジョブがある場合、Oracle Scheduler側にも追加でタイムゾーン設定が必要になります。設定漏れがあると、ジョブが意図した時刻に動きません。これは開発中には見落とされやすく、本番稼働後に発覚すると影響が大きい問題です。

-- Oracle Schedulerのデフォルトタイムゾーンを変更する例
BEGIN
  DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(
    attribute => 'default_timezone',
    value     => 'Asia/Tokyo'
  );
END;
/

RDSのタイムゾーン設定と、Oracle Schedulerのタイムゾーン設定は、分けて確認する必要があります。

⑧ Multi-AZは、配置が変わる前提で性能と運用を設計する

Multi-AZ構成では、プライマリが常に特定AZに固定され続ける前提では設計できません。障害時やメンテナンス時のフェイルオーバーにより、プライマリの配置先AZが変わる可能性があります。

この案件では、RDSとAPサーバーが異なるAZに配置された状態が発生し、AZ間のレイテンシによる処理遅延が問題になりました。一時対応として手動フェイルオーバーで配置を寄せた場面もありましたが、本来はAPサーバーとDBのAZ配置が変わり得る前提で、レイテンシ、接続先、リトライ、監視を設計しておくべきでした。

RDSを選ぶ時点で、「常に特定AZに固定され続ける」という前提ではなく、フェイルオーバーやメンテナンスで配置が変わり得る前提に切り替える必要があります。

⑨ 停止したRDSも、7日後には自動で起動する

RDSは、停止したまま放置できるサービスではありません。

Amazon RDSのDBインスタンスは、一時停止しても7日後に自動で起動します。これは、メンテナンス適用から長期間取り残されないようにするための仕様です。

この仕様を知らないと、開発環境や検証環境で思わぬコストが発生します。

たとえば、金曜夜に高スペックのRDSを停止したつもりでも、7日後に自動起動し、そのまま週末に誰も気づかず動き続けることがあります。停止中はインスタンス時間の課金は発生しませんが、ストレージやバックアップの課金は残ります。さらに、自動起動後は通常どおりインスタンス時間の課金も再開します。

オンプレやEC2の感覚で「止めておけば安心」と考えると、RDSではコスト事故につながります。

長期間使わない環境であれば、単に停止するだけでなく、自動起動後に再停止する仕組みや、不要環境の削除、スナップショット退避なども含めて設計する必要があります。

RDSでは、起動・停止も運用設計の一部です。

代替アプローチ：RDSでの運用をどう設計するか

オンプレの「低レイヤーを直接触る」アプローチはできません。しかし、RDSには別の手段が用意されています。重要なのは、オンプレのやり方を無理に持ち込むことではなく、RDSで提供されている手段に合わせて、運用設計を組み替えることです。

CloudWatch Database Insights / Performance Insights：AWR/ASHの代替として使う

オンプレのOracleでは、AWR（Automatic Workload Repository）やASH（Active Session History）でボトルネックを分析するのが定番でした。RDSでもEEライセンスのBYOL環境であればこれらは使えますが、SE2ライセンス込みモデルでは利用できません。

この代替として使えるのが CloudWatch Database Insights / Performance Insights系の可視化機能です。どのSQLが、どの待機イベントで詰まっているかをダッシュボードで可視化でき、問題のあるSQLをその場で特定できます。

以前はPerformance InsightsでボトルネックとなるSQLを特定した後、別途で実行計画の調査を実施する必要がありました。現在はCloudWatch Database Insights上でOracleの実行計画を直接確認できるようになっており、SQLの詳細情報と実行計画を同一画面で確認できます。インデックス作成前後など同一クエリの実行計画を並べて比較することも可能です。

ただし、利用できる機能や保持期間は、Database Insightsの設定モードや契約条件によって変わります。実行計画の確認まで運用で使う場合は、事前に対象インスタンスで有効化状態と利用可能な機能を確認しておくべきです。

パラメータグループ：init.oraの代替として使う

オンプレでは init.ora や SPFILE で初期化パラメータを自由に変更できましたが、RDSでは DBパラメータグループ 経由で変更します。変更不可のパラメータが存在する点と、一部パラメータの変更にインスタンス再起動が必要な点はオンプレと異なります。変更可能なパラメータの範囲を事前に確認しておくことが重要です。

拡張モニタリング：OSメトリクスの代替として使う

SSHログインができないため top や iostat は叩けませんが、拡張モニタリング を有効にすることで、OSレベルのCPU・メモリ・I/Oの詳細メトリクスをCloudWatchで確認できます。1秒間隔まで設定できるため、瞬間的な負荷スパイクの把握も可能です。

スケールアップ：チューニングより先に試す選択肢

クラウドの最大の強みは、数クリックでインスタンスクラスを変えられることです。チューニングに数日かけるより、インスタンスタイプをひとつ上げてCPUとメモリを倍にする、あるいはプロビジョンドIOPSを追加する方が、時間とコストの観点から合理的なケースがあります。問題の切り分けとして「リソース不足なのか」「SQLや設計の問題なのか」を早く見極めるための選択肢として、スケールアップも検討に入れてください。

SQLチューニング：最も重要な主戦場

インフラ側が触れない分、アプリケーション・SQLレイヤーでの最適化がオンプレ以上に重要になります。実行計画の確認（Explain Plan）、適切なインデックス設計、バインド変数の利用、統計情報の更新。これらはRDSでも変わらず有効で、かつ最も効果が出やすい領域です。

示唆：RDS採用時に設計へ織り込むべきこと

今回挙げたギャップの中には、ドキュメントを読めば事前に分かるものもあります。たとえば、SYSDBA前提の操作がそのまま使えないことや、RDS固有の管理手段を使う必要があることは、構築前の段階で把握できます。

一方で、Storage-Full、アーカイブログの一時蓄積、監査ログ出力、Schedulerの時刻設定、停止後の自動起動のように、実際に開発・検証環境で動かして初めて影響が見えやすいものもあります。

重要なのは、「PoCで動いたか」だけを見るのではなく、RDSを採用する時点で、運用設計・監視設計・コスト管理にこれらの制約を織り込んでおくことです。

容量・ストレージ挙動
ログの一時蓄積、Storage-Fullの発生条件、ストレージ拡張の制約を設計時に確認する。開発環境のサイジングは本番より小さくなりがちなため、これらが先に表面化しやすい。

ファイル操作・監査設計
大量ファイルを出力する設計がある場合、保持数の上限（非公開）と退避方法を確認する。監査ログ、トレース、ダンプファイルは、クリーンアップ処理まで運用設計に組み込む。

権限・管理操作
オンプレで使っているコマンド・権限がRDSで使えるかを一覧化し、代替手段まで確認する。「使えないことがわかった」で終わらず、「RDSではどう実現するか」まで詰めておく。

スケジューラと時刻設定
Oracle Schedulerを使うジョブがあれば、タイムゾーン設定を移行前に確認する。本番稼働後に発覚すると影響が大きい。

停止運用とコスト管理
開発・検証環境のRDSを長期停止する場合、7日後の自動起動を前提に再停止の仕組みや削除方針を決めておく。停止中も課金される項目（ストレージ、バックアップ）があることも把握しておく。

まとめ

今回のギャップを整理すると、こうなります。

RDSはAWSがOS・DB基盤を管理するトレードオフとして、ユーザーは低レイヤーに触れることができません。SYSDBA操作、OSアクセス、物理ファイル操作、一部の初期化パラメータ。これらはオンプレでは当然使えていたものが、RDSでは使えないか、別の方法に置き換わっています。

一方、CloudWatch Database Insights / Performance Insightsによる実行計画の可視化、拡張モニタリング、パラメータグループといった代替手段は年々充実しています。「以前はできなかった」ことが、アップデートで可能になっていくサービスでもあります。

重要なのは「RDSでできないことを嘆く」ことではなく、**「RDSで何ができて、何はできないのかを移行前に把握しておく」**ことです。

「起動した」「接続できた」「SQLが流れた」だけでは、RDS for Oracleを業務で使える確認にはなりません。障害時に調査できるか、容量が逼迫したときに復旧できるか、監査ログが障害要因にならないか、停止したつもりのRDSが自動起動していないか。そこまで確認して初めて「運用できる」と言えます。

ただし、これはRDSが不便だという話ではありません。OSやDB基盤の管理をAWSに任せることで、パッチ適用、バックアップ、フェイルオーバー、監視連携といった運用負荷を下げられるのがRDSの価値です。

その価値を活かすためには、オンプレと同じ操作権限を求めるのではなく、RDSで提供される仕組みに合わせて運用を再設計する必要があります。

オンプレの運用手法をそのまま持ち込むのではなく、RDSを選ぶ時点で、運用とチューニングのアプローチを切り替える。これが、RDS for Oracleを業務で使ううえで重要な前提になります。

参考リンク

• Amazon RDS DBインスタンスのストレージ拡張

• RDS for Oracleの一般的なDBAタスク

• RDS for OracleとS3のファイル転送

• RDS for Oracleのタイムゾーン設定

• RDS DBインスタンスの一時停止と7日後の自動起動

関連記事

今回の話は、RDS for Oracle固有の制約というより、クラウドリフトPoCで見落としやすい設計リスクの一例です。PoCで何を確認すべきかは、以下のシリーズでも整理しています。

【第2部・前編】クラウドリフトPoCで「動いた」は確認できた。しかし業務では使えなかった｜10の設計リスク①

システム開発や基盤設計に関わっていると、「監視」という言葉は必ず出てきます。

「サーバは生きています。 `ping` は通っています」

そう報告した10分後に、業務が止まった。

原因は、Webサーバのプロセス停止だった。

サーバ自体にはネットワーク的に到達できていたため、 `ping` 監視では異常を検知できなかった。

答えは単純です。 `ping` が通ることと、システムが業務として使える状態であることは、まったく別の話だからです。

死活監視。リソース監視。ログ監視。プロセス監視。ジョブ監視。URL監視。SNMP監視。

言葉としては聞いたことがあっても、実際に「監視の仕組み」を説明しようとすると、意外と難しいものです。

若手SEの中には、監視を「サーバが落ちたらアラートが出る仕組み」「CPUやメモリが高くなったら通知する仕組み」「ログにエラーが出たらメールが飛ぶ仕組み」と理解している人もいます。

もちろん、間違いではありません。

ただし、それだけでは監視設計はできません。

監視では、何を監視するのか、どこから監視するのか、どの方式で監視するのか、どの条件で異常と判断するのか、誰に通知するのか、通知を受けた人が何を確認するのかまで決める必要があります。

監視とは、単にアラートを出す仕組みではありません。

システムの異常や異常予兆を、運用で対応できる形で検知する仕組みです。

前編では、監視サーバー、監視対象サーバー、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB/OIDの基本を整理します。

監視を「設定」ではなく「運用で使える仕組み」として理解するために、まずは基本構造から見ていきます。

システム監視とは何か

監視をしていなければ、障害が起きても運用側は気づけません。

利用者から「画面が開かない」と問い合わせが来て、初めて障害を認識する。これは運用の失敗です。

システムが正常に稼働しているか。障害の予兆がないか。それを運用で対応できる形で検知する仕組みです。

システム監視の目的は、大きく2つあります。

• システムが正常に稼働しているかを確認する
• システムに障害予兆となる兆候がないかを確認する

業務システムでは、障害そのものを完全にゼロにすることはできません。

だからこそ、障害が発生したときに早く気づく。
影響範囲を把握する。
一次対応につなげる。
必要に応じてエスカレーションする。

そのために監視があります。

監視には「監視する側」と「監視される側」がある

まず押さえるべき基本は、監視には「監視する側」と「監視される側」があるということです。

一般的なオンプレミスや仮想基盤の監視構成では、次のような役割があります。

• 監視サーバー
• 監視マネージャー
• 監視対象サーバー
• 監視エージェント
• 運用端末
• 通知先

監視サーバー、または監視マネージャーは、監視する側です。

監視対象サーバーは、監視される側です。

Webサーバ、APサーバ、DBサーバ、ジョブ管理サーバ、ストレージ、ネットワーク機器などが該当します。

監視サーバーは、監視対象に対して定期的に確認を行います。

たとえば、Web/APサーバとの通信状況、DBサーバのCPU負荷、共有ストレージのディスク容量、ログの異常メッセージなどを収集し、異常があれば運用者や管理者へ通知します。

ここで重要なのは、監視は「何となく全体を見ている」のではないということです。

監視対象ごとに、何を、どの方式で、どの周期で、どの閾値で、どの通知先へ送るかを細かく決めています。

前編では、まず代表的な監視方式として、死活監視、エージェント監視、エージェントレス監視、SNMP監視を整理します。

これらは、どれか1つだけを選ぶものではありません。

実際のシステムでは、複数の方式を組み合わせます。

たとえば、次のような組み合わせです。

• ネットワーク疎通は死活監視
• OS内部のCPU、メモリ、ディスクはエージェント監視
• ネットワーク機器やストレージはSNMP監視
• Webサービスの応答はURL監視
• クラウドリソースはCloudWatchやOCI Monitoring
• アプリケーションログはログ監視
• バッチ処理はジョブ監視

つまり、監視方式は「どれが正解か」ではありません。

そのシステムで何を知りたいのか。
どこまで異常を検知したいのか。
どのタイミングで誰が対応するのか。

これに応じて選びます。

死活監視とは何か

死活監視とは、監視対象が生きているかどうかを確認する監視です。

代表的には、監視サーバーから監視対象サーバーへ `ping` を実行し、応答があるかを確認します。

システム開発では、死活監視というと、まず `ping` による疎通確認をイメージすることが多いです。

`ping` は、監視サーバーから監視対象のIPアドレスへ到達できるか、相手が応答を返すかを確認するためによく使われます。

ここで注意が必要です。

`ping` が通ることは、システムが正常に動いていることを意味しません。

少しネットワークの階層で見ると、`ping` で確認しているのは、ざっくり言えばネットワーク層レベルの到達性です。

つまり、監視サーバーから監視対象のIPアドレスへ届き、相手が応答している、ということを確認しているに過ぎません。

その上で動いているWebサーバ、APサーバ、DB、ジョブ、業務アプリケーションまで正常であることを確認しているわけではありません。

たとえば、次のような状態でも `ping` は通ることがあります。

• Webサーバプロセスが停止している
• APサーバのスレッドが枯渇している
• DBリスナーが停止している
• DB表領域が枯渇している
• 業務APが内部エラーを返している
• ログイン画面は開くが検索処理が失敗する
• バッチジョブが異常終了している
• ディスク使用率が100%に近い
• メモリ不足で処理が極端に遅い

つまり、死活監視は重要ですが、それだけでは不十分です。

`ping` による死活監視で分かるのは、「ネットワーク的に到達できるか」「機器やOSが応答しているか」という入口の状態です。

一方で、業務として使える状態かどうかを確認するには、ポート監視、プロセス監視、URL監視、ログ監視、DB接続監視、ジョブ監視など、より上位の状態を見る監視が必要になります。

なお、死活監視は `ping` だけとは限りません。

SNMPを使って機器の稼働状態を確認する場合もあります。ネットワーク機器やストレージ、UPSなどでは、SNMPでインターフェース状態、電源状態、ファン、温度、装置状態などを取得したり、SNMP Trapで機器側から異常通知を受けたりします。

エージェント監視とは何か

エージェント監視とは、監視対象サーバーに監視用ソフトウェアを導入し、そのエージェントがサーバ内部の状態を収集する方式です。

監視対象サーバーの中に入って、CPU、メモリ、ディスク、プロセス、ログ、サービス状態などを確認するイメージです。

たとえば、次のような情報は、エージェントを入れた方が取得しやすくなります。

• CPU使用率
• メモリ使用率
• ディスク使用率
• ディスクI/O
• 特定プロセスの起動状態
• 特定サービスの状態
• OSログの特定メッセージ
• ミドルウェアログのエラー
• アプリケーションログの異常
• ファイル数やファイルサイズ
• 独自スクリプトの実行結果

商用監視製品であれば、JP1、Systemwalker、Hinemosなどが代表例です。

エージェント監視のメリットは、監視対象サーバーの内部情報を細かく取得できることです。

たとえば、単にDBサーバに `ping` が通るかだけでなく、DBプロセスが起動しているか、DB関連ログにエラーが出ていないか、CPUやメモリが逼迫していないか、といった情報を取得できます。

一方で、デメリットもあります。

エージェントをインストールする必要があります。
監視対象サーバーのリソースを使います。
バージョン管理が必要です。
OS更改やパッチ適用時に影響確認が必要です。
エージェント自体が停止すると監視できません。
セキュリティ上、導入や通信許可の調整が必要です。

そのため、エージェント監視を使う場合は、「何を監視したいからエージェントが必要なのか」を明確にします。

一方、エージェント監視のデメリットを見ると、「エージェントを入れずに済む方法はないか」という発想が生まれます。それがエージェントレス監視です。

エージェントレス監視とは何か

エージェントレス監視とは、監視対象サーバーに監視用エージェントを導入せず、監視サーバー側からリモートで状態を確認する方式です。たとえば、サーバに到達できるかを確認するだけなら `ping` で確認できます。

プロセス起動確認とWebサービス応答確認は違う

Webシステムでは、Apacheの `httpd` やTomcatのプロセスが起動していることを確認して、Web/APサーバが正常だと判断してしまうケースがあります。

しかし、プロセスが起動していることと、Webサービスが正常に応答していることは別です。

`httpd` が起動していても、アプリケーションのデプロイに失敗しているかもしれません。Tomcatが起動していても、DB接続でエラーになっているかもしれません。ロードバランサやリバースプロキシの経路が誤っていて、利用者から見ると画面に到達できないこともあります。

そのため、Webサービスの正常性を確認するには、HTTP/HTTPSで対象URLへアクセスし、HTTPステータスコードやレスポンス内容を確認することがあります。

たとえば、監視サーバーから `/healthcheck` や `/login` などのURLへHTTP GETリクエストを送り、HTTPステータスコードが `200` で返るか、レスポンス本文に想定した文字列が含まれるか、応答時間が閾値内かを確認します。

この考え方は、現在でもWebサービスの正常性確認として一般的に使われます。

ただし、最近のシステムでは、確認の粒度を分けることが増えています。

ロードバランサでは、配下のサーバへHTTP/HTTPSのヘルスチェックを行い、正常なターゲットだけにリクエストを振り分けます。

コンテナやKubernetes環境では、コンテナが生きているか、リクエストを受け付けられる状態か、起動完了しているかを分けて確認します。

また、より利用者目線で確認したい場合は、単一URLのGET確認だけでなく、外形監視やSynthetic Monitoringを使い、ログイン、検索、API呼び出しなど、実際の利用者操作に近いシナリオを定期実行することもあります。

つまり、`/healthcheck` や `/login` のHTTP応答確認は今でも有効です。

ただし、それだけで十分かは、システムの特性によります。

重要なのは、`httpd` やTomcatのプロセス起動確認だけで「Webサービスが正常」と判断しないことです。

Webサービスが業務として使えるかを確認するには、少なくともHTTP/HTTPSで実際にアクセスし、期待した応答が返ることを確認する必要があります。

ネットワーク機器やストレージの状態を確認する場合は、SNMPで情報を取得できることもあります。クラウドサービスであれば、APIやクラウド側のメトリクスから状態を取得できる場合もあります。

つまり、監視対象の内部にエージェントを入れなくても、監視サーバー側からリモートで確認できる内容であれば、エージェントレス監視を選択できます。

一方で、OSログの詳細確認、独自スクリプトの実行結果、アプリケーションログの細かな異常検知、サーバ内部の詳細なメトリクス取得などは、エージェントを入れた方が扱いやすい場合があります。

そのため、エージェントレス監視は「エージェントを入れなくて済むから楽」というだけではありません。

監視したい内容が外部から取得できるのか。
取得に必要な認証や権限をどう管理するのか。
通信経路やファイアウォール設定はどうするのか。
取得できる情報の粒度で運用判断できるのか。

ここまで考えたうえで、エージェント監視にするのか、エージェントレス監視にするのかを決めます。

代表的には、次のような方式があります。

• ping
• TCPポート監視
• HTTP/HTTPS監視
• SNMP監視
• SSH経由のコマンド実行
• Windows WMIによる情報取得
• APIによる状態取得
• クラウドサービスのメトリクス取得

エージェントレス監視のメリットは、監視対象サーバーにソフトウェアを導入しなくてもよいことです。

サーバ台数が多い場合、エージェント導入やバージョン管理の負荷を抑えられます。

また、ネットワーク機器、ストレージ、アプライアンス製品、クラウドサービス、マネージドサービスでは、そもそもエージェントを入れられないこともあります。

その場合は、SNMP、API、クラウドメトリクスなどを利用して監視します。

ただし、エージェントレス監視には制約があります。

外側から見える状態は分かるが、OS内部やアプリケーション内部の詳細までは見えないことがあります。
ログファイルの中身までは見にくいことがあります。
独自スクリプトの実行や詳細なメトリクス取得に制約が出ることがあります。
監視サーバーやネットワーク経路に障害があると、監視できないことがあります。

つまり、エージェントレス監視は「エージェントが不要だから簡単」という話ではありません。

エージェントを入れない代わりに、監視サーバー側の接続方式、認証、通信経路、権限、取得できるメトリクスの範囲を設計する必要があります。

SNMP監視とは何か

オンプレミスの監視やネットワーク機器監視でよく出てくるのが、SNMPです。

SNMPは、Simple Network Management Protocolの略です。

ネットワーク機器、サーバ、ストレージ、UPS、アプライアンスなどの状態を監視・管理するために使われるプロトコルです。SNMPの管理情報を扱うMIBについては、RFC 3418でもSNMPエンティティの動作を説明する管理オブジェクトとして定義されています。(IETF Datatracker)

SNMP監視では、一般的に次のような役割があります。

• SNMPマネージャー
• SNMPエージェント
• MIB
• OID
• SNMP Get
• SNMP Trap

SNMPマネージャーは、監視する側です。

SNMPエージェントは、監視される機器側で動作し、機器の状態情報を持っています。

SNMP Getは、マネージャーがエージェントに対して「この情報を教えて」と問い合わせる方式です。

SNMP Trapは、機器側からマネージャーへ「異常が起きた」と通知する方式です。

たとえば、ネットワーク機器でインターフェースがDownした場合、機器側からSNMP Trapが飛ぶことがあります。

監視サーバーはそのTrapを受け取り、アラートとして運用者へ通知します。

SNMP監視でつまずきやすいOIDとMIB

SNMPの説明では、OIDやMIBという言葉が当たり前のように出てきます。

しかし、これを正しく理解していないと、

「MIBファイルを監視製品に読み込ませれば、監視できるんですよね」

という誤解につながります。

これは危険です。

まず、OIDから整理します。

OIDは、Object Identifierの略です。

一言でいえば、監視対象機器の中にあるデータの住所です。

ネットワーク機器やサーバは、人間が話すように「CPU使用率を教えてください」と理解してくれるわけではありません。

SNMPでは、監視マネージャーが、監視対象機器に対して、

「この番号の情報をください」

と問い合わせます。

たとえば、あるネットワーク機器のCPU使用率を表すOIDが、次のような番号だったとします。

1.3.6.1.4.1.9.9.109.1.1.1.1.5

copy

監視マネージャーは、このOIDを指定して、監視対象機器に問い合わせます。

すると、機器側のSNMPエージェントは、

80

copy

のように値を返します。

この場合、人間から見ると「CPU使用率が80%」という意味です。

しかし、機器や監視マネージャーのやり取りとしては、基本的には「どのOIDの値を取るか」という話になります。

つまり、OIDは、監視対象機器の中にある監視項目の住所です。

次にMIBです。

MIBは、Management Information Baseの略です。

一言でいえば、OIDという数字の住所と、人間が理解できる意味を対応づける辞書です。

人間が、毎回、

1.3.6.1.4.1.9.9.109.1.1.1.1.5

copy

という数字を見ても、それが何を意味するのかは分かりません。

そこで、ベンダーが提供するMIBファイルを使います。

MIBには、たとえば次のような対応関係が定義されています。

1.3.6.1.4.1.9.9.109.1.1.1.1.5
=
CPUの5分平均使用率

copy

実際には、製品ごとの正式な項目名や階層構造で定義されていますが、考え方としてはこのようなものです。

つまり、OIDは「住所」です。
MIBは「住所録」または「辞書」です。

OIDが分かれば、監視マネージャーは対象機器から値を取得できます。
MIBがあれば、そのOIDが何を意味するのかを人間が理解しやすくなります。

ここまでは、SNMP監視の基本です。

ただし、実務で本当に重要なのはここからです。

MIBを登録しただけでは監視設計は終わらない

MIBファイルを監視製品に読み込ませると、製品固有のOIDやTrapの意味を解釈できるようになります。

しかし、それだけでは監視設計は終わりません。

MIBは、あくまで辞書です。

辞書を入れただけでは、

• どのOIDを監視するのか
• どの値を警告とするのか
• どの値を異常とするのか
• どのTrapを通知対象にするのか
• どのTrapは通知しないのか
• 何分継続したら異常にするのか
• 誰に通知するのか
• 通知を受けた人が何を確認するのか

は決まりません。

ここを決めるのが監視設計です。

たとえば、CPU使用率のOIDを監視するとします。

CPU使用率が80%になったら、必ず異常でしょうか。

そうとは限りません。

夜間バッチの時間帯だけ一時的にCPUが上がるシステムもあります。
バックアップ処理中だけCPUやI/Oが上がることもあります。
短時間のスパイクであれば、業務影響がない場合もあります。
一方で、CPU使用率が70%程度でも、長時間継続すれば性能劣化の予兆かもしれません。

つまり、単に「CPU使用率のOIDを監視する」だけでは不十分です。

次のように、運用で判断できる条件まで落とす必要があります。

CPU使用率が90%以上
かつ
5分以上継続した場合は警告

CPU使用率が95%以上
かつ
10分以上継続した場合は異常

ただし、夜間バッチ時間帯は別閾値とする

copy

もちろん、これは例です。

実際の閾値は、システムの特性、性能要件、通常時の負荷、ピーク時間帯、バッチ処理、運用体制に応じて決めます。

MIBを入れただけで監視を始めると何が起きるか

よくない進め方は、ベンダーのMIBファイルを監視サーバーに登録し、デフォルト設定に近い形で対象機器の監視を一斉に始めてしまうことです。

この場合、運用開始後にアラートが大量に出ることがあります。

いわゆる、アラートの大洪水です。

なぜそうなるのか。

主な理由は3つあります。

1つ目は、通知すべきイベントと、通知しなくてよいイベントを分けていないことです。

機器や製品は、さまざまなTrapや状態変化を出します。

その中には、本当に即時対応が必要な障害もあります。

一方で、単なる情報通知、状態変化、復旧通知、一時的な警告、運用上は無視してよいメッセージもあります。

これらをすべて同じように通知すると、運用者は大量のアラートを受けることになります。

2つ目は、閾値や継続時間をシステム特性に合わせていないことです。

CPU、メモリ、ディスクI/O、ネットワーク使用率などは、システムによって通常値が違います。

業務ピーク時にCPUが高くなるシステムもあります。
夜間バッチ中にI/Oが急増するシステムもあります。
月次処理の日だけ負荷が上がるシステムもあります。

それを考慮せず、一般的な閾値だけで監視すると、正常な業務処理まで異常として検知してしまいます。

3つ目は、テスト工程で実際のログやアラートを精査していないことです。

監視条件は、設計時点の机上検討だけでは決めきれません。

特に、ログ監視やTrap監視は、実際にシステムを動かしてみないと、どのメッセージがどれくらい出るのか分からないことがあります。

システムテスト、運用テスト、本番リハーサルで、業務データ、日次処理、月次処理、ピーク時のトランザクション、バックアップ、ジョブ、外部連携などを動かして初めて、大量のログやイベントが出てきます。

その中から、

• 本当に通知すべきもの
• 通知は不要だが記録しておくもの
• 除外してよいもの
• 閾値や継続時間を見直すべきもの
• 一次対応手順に落とすべきもの

を精査する必要があります。

これをやらずに本番稼働すると、運用開始後に大量のアラートが出ます。

すると、運用者はアラートを見切れなくなります。

最悪なのは、本当に重要な障害が、不要なアラートの中に埋もれてしまうことです。

監視は、アラートをたくさん出せばよいわけではありません。

運用者が判断できる形で、必要な異常を検知することが重要です。

SNMP監視も詳細設計の対象である

ここまで見ると分かるように、SNMP監視は単にMIBを登録する作業ではありません。

MIBを登録する。
OIDを選ぶ。
Trapを受ける。
閾値を決める。
重大度を決める。
通知先を決める。
除外条件を決める。
テスト工程で実際の発報状況を確認する。
運用手順と対応づける。

ここまで含めて、SNMP監視も詳細設計の中で決めるべき重要な領域です。

前編のまとめ｜監視の基本構造を押さえる

監視には「監視する側」と「監視される側」がある
監視サーバーが監視対象であるWeb/AP/DBサーバ、ネットワーク機器などに対して、定期的に状態を確認する構造が基本です。

`ping` が通ることと、システムが業務として使えることは別である
死活監視は、あくまでネットワーク的な到達性の確認です。プロセス、DB、アプリケーションまで正常かどうかは、別の監視で確認する必要があります。

監視方式は、監視したい内容に応じて組み合わせる
死活監視、エージェント監視、エージェントレス監視、SNMP監視は、どれか一つを選ぶものではありません。監視したい内容に応じて組み合わせます。

MIBを登録しただけでは監視設計は終わらない
OIDの選定、閾値、継続時間、通知先、除外条件まで決めて初めて、運用で使える監視になります。

アラートは多ければよいわけではない
閾値やシステム特性を考慮せず監視を始めると、アラートの大洪水が起きます。テスト工程で実際の発報内容を精査することが必要です。

監視は、製品を入れて設定するだけの作業ではありません。
監視対象、監視方式、閾値、検知条件、除外条件、重大度、通知先、一次対応手順まで決める設計作業です。

後編では、クラウド監視に進みます。

AWS CloudWatchやOCI Monitoringを使えば、自前の監視サーバーが不要になることもあります。

ただし、「クラウド監視サービスを使えば、監視設計が楽になる」は半分正解で半分誤解です。

クラウドでも、何を監視するか。どの値を異常とするか。誰に通知するか。一次対応をどうするか。これらは自分たちで決める必要があります。

むしろ、オンプレと違い「気づかないうちにコストが膨らむ」という、クラウド固有のリスクも監視の対象になります。

後編では、AWS CloudWatchやOCI Monitoringなどのクラウド監視、オンプレミスからクラウド移行時の監視Fit & Gap、監視設計で決めるべき項目を整理しています。

あわせて読みたい

機能要件と非機能要件の違い
システム開発の流れを現場目線で理解する｜前編
要件定義の正体

はじめに

基本設計では、要件をシステム構成、処理方式、運用方式に落とし込みます。

では、詳細設計では何をするのでしょうか。

詳細設計と聞くと、サーバのパラメータを決める、ミドルウェアの設定値を書く、クラウドサービスの設定項目を埋める、といったイメージを持つ人もいるかもしれません。

もちろん、それらは詳細設計の重要な要素です。

しかし、詳細設計は、単にパラメータ表を埋める工程ではありません。

基本設計で決めた方式を、実際に構築・設定・テスト・運用できる粒度まで落とし込む工程です。

たとえば、基本設計で「ログを1か月保持する」と決めたなら、詳細設計では、どのログファイルを対象にするのか、どのディレクトリに出力するのか、どの周期でローテーションするのか、圧縮するのか、何世代残すのか、バックアップ対象に含めるのか、容量監視をどうするのかまで具体化します。

基本設計で「7時までに業務を開局する」と決めたなら、詳細設計では、その運用要件をジョブ、スクリプト、監視、起動停止、開局前チェックに落とします。

どのジョブを何時に起動するのか。
どのスクリプトを実行するのか。
どの戻り値を正常とするのか。
終了遅延をどう検知するのか。
開局前チェックで何を確認するのか。
どの監視を再開するのか。

これは一見すると運用設計の話に見えます。

しかし、詳細設計では、この運用要件を実際の製品設定、ジョブ定義、スクリプト仕様、監視設定、手順書の粒度に落とします。ここで落とし込みが甘いと、運用試験や本番移行前に手戻りが発生します。

つまり、詳細設計とは、基本設計で決めた方針を、OS、ミドルウェア、DB、ジョブ、監視、バックアップ、クラウドサービス、運用スクリプト、手順、試験観点へ展開する工程です。

構築担当者が設定値を判断しなければならない。
テスト担当者が期待値を確認できない。
運用スクリプトが作られていない。
ジョブは定義されているが、異常時の分岐が分からない。
監視項目はあるが、閾値や通知先が決まっていない。
バックアップは設定されているが、リストア手順がない。

こうした問題は、詳細設計の時点で「構築できる粒度」「テストできる粒度」「運用できる粒度」まで落とし込めていないことから起きます。

この記事では、基盤SEの目線で、詳細設計で何を具体化するのかを整理します。

この記事で持ってほしい問い

詳細設計書を見るときは、設定値そのものだけを追ってはいけません。

ここで挙げる問いは、記事全体を通して持ってほしい視点です。
各章の末尾では、その領域ごとの確認観点を3つに絞って整理します。

この記事では、次の問いを持ちながら読んでください。

• この設定値は、基本設計のどの方針を受けているのか
• なぜこの値でよいと言えるのか
• 構築担当者が、この設計書を見て同じ設定を再現できるか
• テスト担当者が、期待値を判断できるか
• 運用担当者が、障害時に使える設計になっているか
• 監視、ログ、バックアップ、ジョブ、スクリプト、手順書とつながっているか
• この設計で品質を確保できると説明できるか

詳細設計は、設定値を埋める作業ではありません。

基本設計で決めた方式を、構築、テスト、運用、保守に接続し、「なぜこの設計でよいのか」を説明できる状態にする工程です。

この問いを持って読むと、詳細設計書の見え方が変わります。

詳細設計は基本設計の続きである

詳細設計は、基本設計と切り離された工程ではありません。

基本設計で決めた内容を、実際に構築・設定できるレベルに落とし込むのが詳細設計です。

基本設計では、たとえば次のようなことを決めます。

• システム構成
• 処理方式
• サーバ構成
• ネットワーク構成
• DB構成
• ストレージ方式
• ジョブ・バッチ方式
• 監視方式
• ログ方式
• バックアップ・リストア方式
• セキュリティ方式
• 運用方式

一方、詳細設計では、それらをより具体的な設定、パラメータ、ファイル、ジョブ、スクリプト、手順、テスト可能な期待値に落としていきます。

たとえば、基本設計で「Web/AP/DBの3層構成」と決めたなら、詳細設計では、各サーバのホスト名、IPアドレス、OS設定、導入ミドルウェア、待ち受けポート、接続先、タイムアウト、ログ出力先、起動停止順序を決めます。

基本設計で「監視する」と決めたなら、詳細設計では、監視対象、監視方式、監視間隔、閾値、検知条件、通知先、抑止条件、一次対応手順まで落とします。

基本設計で「バックアップを取得する」と決めたなら、詳細設計では、対象ファイル、対象DB、取得コマンド、実行ジョブ、取得時刻、世代数、保管先、削除条件、リストア手順、戻し先、確認方法まで落とします。

詳細設計は、基本設計で決めたことを「誰が見ても同じ構成で作れる状態」にするための工程です。

詳細設計を、構築担当者向けの設定メモにしてはいけません。

詳細設計書は、構築担当者だけのためにあるわけではありません。テスト担当者、運用担当者、レビュー担当者、障害対応者、後続保守担当者も参照します。

そのため、詳細設計では、単に設定値を書くのではなく、なぜその設定にしているのか、基本設計のどの方針を受けているのか、どのテストで確認するのか、運用上どの手順や監視とつながるのかを意識します。

詳細設計とパラメータ設計・環境定義

開発標準によっては、詳細設計、パラメータ設計、環境定義を分けて整理することがあります。

考え方としては、次のように整理できます。

詳細設計は、基本設計で決めた方式を、製品・ミドルウェア・クラウドサービスの設定や構築単位に落とし込む工程です。

パラメータ設計は、その中でも、OS、ミドルウェア、DB、ジョブ管理製品、監視製品、バックアップ製品、クラウドサービスなどの設定値を具体化する作業です。

環境定義は、実際に構築される環境ごとの設定値を一覧化する成果物です。

ただし、実務上は、詳細設計とパラメータ設計、環境定義を一体的に進めることも多くあります。特に基盤領域では、製品ごとの詳細設計書と、環境ごとのパラメータ一覧を合わせて管理することが一般的です。

ここで押さえるべきなのは、すべての製品パラメータを案件ごとにゼロから検証するわけではない、ということです。

OS、Web/APサーバ、DB、ジョブ管理、監視、バックアップ製品、クラウドサービスには、膨大な設定項目があります。これらをすべて個別に妥当性検証することは、現実的ではありません。

そのため、多くのプロジェクトでは、過去案件で実績のある標準構成や製品デフォルト値をベースにし、基本設計で定めた処理方式、性能要件、運用要件、セキュリティ要件に影響するパラメータを重点的に設計します。

「デフォルトだから見なくてよい」ではありません。

案件固有の要件に影響するパラメータを洗い出し、変更する項目については設定値と根拠を示します。

一方、変更しない項目についても、環境定義として値を明示しておくことで、構築後の確認、障害時の調査、後続保守で参照できる状態にしておきます。

詳細設計とは、全パラメータを網羅的に説明する工程ではありません。基本設計で決めた方式と、実際の製品設定・環境定義をつなぐ工程です。

詳細設計は品質保証ストーリーの一部である

詳細設計は、構築担当者のための設定表ではありません。

基本設計で決めた方式を、構築・テスト・運用へつなげることで、「なぜこの設計で品質を確保できると判断したのか」を説明する材料になります。

特に大規模プロジェクトでは、設計値やパラメータ値に対して、根拠を求められることがあります。

なぜこの値なのか。
なぜデフォルト値でよいのか。
なぜこの監視項目で足りるのか。
なぜこの試験で確認できたと言えるのか。
なぜこの構成で性能要件を満たすと判断したのか。

このとき、詳細設計書に設定値だけが並んでいても説明できません。

必要なのは、次の接続です。

• 基本設計で定めた方式
• 非機能要件
• 製品仕様
• 標準構成・過去実績
• 設定値の根拠
• テスト観点
• 監視・運用での確認方法

一方で、すべての製品パラメータやすべての操作パターンを案件ごとに完全検証することはできません。

製品内部の制御仕様、バージョン差分、特定条件でのみ発生する挙動まで、設計段階で完全に予見することは現実的ではありません。

たとえば、通常利用では問題が出ないものの、特定の処理タイミング、特定の負荷条件、特定の運用操作が重なった場合だけ、製品内部の制御仕様によって処理遅延やエラーが発生することがあります。

こうした事象は、要件や設計から自然に導けるものではなく、製品仕様、バージョン差分、既知不具合、過去事例に依存します。マニュアルやベンダー情報に明示されていなければ、設計段階で完全に予見することは困難です。

だからこそ、詳細設計では、次の項目を重点的に設計します。

• 基本設計で決めた処理方式に影響する項目
• 性能・可用性・運用・セキュリティに影響する項目
• 案件固有要件により変更する項目
• 過去実績や標準構成で注意点が分かっている項目

変更する項目には、設定値と根拠を残します。

変更しない項目については、製品デフォルト値または標準構成を採用し、環境定義として管理します。これは、すべてのデフォルト値を個別に検証したという意味ではありません。構築後の確認、障害時の調査、保守引継ぎのために、実際の設定状態を参照できるようにするためです。

テストも同じです。

テストは、見えない全パターンを無限に洗い出すものではありません。要件定義、基本設計、詳細設計で決めた内容に対して、Vモデルに沿って確認観点を展開するものです。

詳細設計で目指すべきなのは、トラブルゼロを保証することではありません。

要件と設計に基づいて、どこを重点的に設計し、どこを標準値として採用し、どこを試験で確認し、どこを運用監視で検知するのかを説明できる状態にすることです。

これが、詳細設計における品質保証ストーリーです。

詳細設計で見るべきなのは「設定値」ではなく「接続性」である

詳細設計というと、どうしても設定値に目が行きます。

OSのパラメータ。
ApacheやTomcatの設定。
DBの初期化パラメータ。
ジョブ管理製品のジョブ定義。
監視製品の閾値。
クラウドサービスの設定項目。

もちろん、これらは大事です。

しかし、詳細設計で見るべきなのは、設定値そのものだけではありません。

基本設計、構築、テスト、運用がつながっているかです。

たとえば、ログ設計であれば、以下がつながっている必要があります。

• 基本設計：ログを1か月保持する
• 詳細設計：logrotate設定、退避先、圧縮有無、世代数
• 構築：設定ファイルの配置、権限設定、反映
• テスト：ログローテーション確認、容量監視確認
• 運用：ログ確認手順、障害調査手順、バックアップ対象

このつながりがないと、詳細設計書は単なる設定一覧になります。

一見すると設計書は埋まっているのに、後工程で漏れます。

ログ保持期間は決まっているが、ローテーション設定がない。
ログ出力先は決まっているが、容量監視がない。
バックアップ対象に含まれていない。
障害時にどのログを見るのか手順書に書かれていない。

こうした漏れは、詳細設計の段階で「設定値を決めること」だけを目的にしていると起きます。

詳細設計で見るべきなのは、設定値が正しいかだけではありません。

その設定が、基本設計の方針とつながっているか。
構築手順に落ちるか。
テストで確認できるか。
運用手順や監視とつながるか。
障害時に使えるか。

ここまで見て初めて、詳細設計として成立します。

詳細設計は製品・ミドルウェア単位で分かれやすい

基本設計では、処理方式や運用方式の単位で設計することが多くあります。

一方、詳細設計では、製品・ミドルウェア・クラウドサービス単位で設計書が分かれることが多くなります。

たとえば、次のような詳細設計書です。

• OS詳細設計書
• Webサーバ詳細設計書
• APサーバ詳細設計書
• DB詳細設計書
• ジョブ詳細設計書
• バックアップ詳細設計書
• 監視詳細設計書
• ログ詳細設計書
• ストレージ詳細設計書
• ネットワーク詳細設計書
• セキュリティ詳細設計書
• 運用スクリプト設計書
• クラウドサービス詳細設計書

これは、詳細設計が実際の構築対象に近づくからです。

構築担当者は、OSを設定し、Webサーバを設定し、APサーバを設定し、DBを設定し、ジョブ管理製品にジョブを登録し、監視製品に監視項目を設定します。

そのため、詳細設計も自然と製品・ミドルウェア・クラウドサービス単位になります。

ただし、ここで注意が必要です。

製品単位で詳細設計書を分けると、設計対象を管理しやすくなる一方で、処理方式としてのつながりが見えにくくなることがあります。

たとえば、バックアップ方式は、DB詳細設計、ストレージ詳細設計、ジョブ詳細設計、監視詳細設計、運用スクリプト設計にまたがります。

ログ方式は、OS詳細設計、ミドルウェア詳細設計、監視詳細設計、バックアップ詳細設計にまたがります。

ジョブ方式は、ジョブ管理製品の詳細設計だけでなく、実行スクリプト、ログ出力、異常終了時の通知、運用手順、運転スケジュールにまたがります。

つまり、詳細設計では、製品単位で分けることと、処理方式として横断的につなぐことの両方が必要です。

ここを意識しないと、各詳細設計書は存在するのに、全体としてつながっていない状態になります。

ここまで、詳細設計の考え方を整理してきました。

ここから先は、基盤SEが実際に詳細設計で具体化する領域を、OS、Web/AP、DB、ジョブ、監視、ログ、バックアップ、セキュリティ、運用スクリプトに分けて見ていきます。

特に、ジョブ管理規約とスクリプトの戻り値設計、正常系だけで終わらせない単体試験、特権IDや本番作業統制の考え方は、現場でトラブルを起こしやすいポイントです。

詳細設計を「設定表作成」で終わらせず、構築・テスト・運用で使える成果物にするための具体論を整理します。

この先、後編①ではOS・Web/AP・DB・ジョブを、後編②では監視・ログ・バックアップ・セキュリティ・運用スクリプトを扱います。

– OS詳細設計で見るべき観点
– Web/APサーバ詳細設計で性能・運用とつなげる考え方
– DB詳細設計で性能・バックアップ・セキュリティをどう見るか
– ジョブ詳細設計で事故りやすい戻り値設計
– ジョブ管理規約とスクリプトのコーディング規約をそろえる理由
– 監視・ログ・バックアップ設計で後工程に漏れを出さない見方
– セキュリティ詳細設計を技術設定だけで終わらせない考え方
– 運用スクリプトの設計・試験で見落としやすいポイント
– 詳細設計でやってはいけないこと

「前編まとめ｜詳細設計の本質」

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

設定値を埋めることではなく、基本設計、構築、テスト、運用がつながっているかを見ること。トラブルゼロを保証することではなく、どこを重点設計し、どこを試験で確認し、どこを運用監視で検知するかを説明できる状態にすること。

これが詳細設計の本質です。

その本質を踏まえて、詳細設計でやってはいけないことを4つ整理します。

基本設計とのつながりを見ない
詳細設計は、基本設計で決めた方式を具体化する工程です。基本設計との対応が見えない詳細設計は、ただの設定メモになります。

製品パラメータを埋めるだけで終わる
詳細設計では設定値を決めますが、それだけでは不十分です。構築、テスト、運用、障害対応までつながる粒度で設計します。

設定値の理由を書かない
なぜその値にしたのかが分からないと、レビューも保守もできません。推奨値なのか、性能要件から決めたのか、製品制約なのか、運用要件なのかを残します。

全パラメータを保証したつもりになる
詳細設計は、すべての製品パラメータやすべての組み合わせ挙動を案件ごとに完全検証する工程ではありません。要件・方式・リスクに影響する項目を重点的に設計し、標準構成やデフォルト値に依拠する範囲を明確にします。

領域ごとの具体的な注意点は、後編①・②で整理します。

後編①ではOS・Web/AP・DB・ジョブを、後編②では監視・ログ・バックアップ・セキュリティ・運用スクリプトを扱います。

扱う論点の多くは、「知っているか、知らないか」で後工程の品質が大きく変わるものです。設計書の体裁は整っているのに、システムテストや本番移行前に手戻りが発生する。その原因の多くは、詳細設計のこの段階で見落とされています。

監視には、監視する側である監視サーバーや監視マネージャーがあり、監視される側である

Webサーバ、APサーバ、DBサーバ、ストレージ、ネットワーク機器があります。

また、死活監視、エージェント監視、エージェントレス監視、SNMP監視といった方式があり、監視したい内容に応じて使い分ける必要があります。

前編で特に強調したのは、ping が通ることと、システムが業務として正常に使えることは別だという点です。

サーバに到達できること。
プロセスが起動していること。
ポートが待ち受けていること。
HTTP/HTTPSで応答が返ること。
業務シナリオが正常に完了すること。

これらは、それぞれ確認しているレベルが違います。

また、SNMP監視では、MIBやOIDを理解することも重要です。
ただし、MIBを登録しただけでは監視設計は終わりません。

どのOIDを監視するのか。
どの値を警告・異常とするのか。
どのTrapを通知対象にするのか。
どのアラートを除外するのか。
テスト工程で発報内容をどう精査するのか。

ここまで考えて初めて、監視は運用で使える仕組みになります。

後編では、クラウド監視に話を進めます。

AWS CloudWatchやOCI Monitoringのようなクラウドネイティブな監視では、自前の監視サーバーを構築しなくても、メトリクス、ログ、アラームを扱える場合があります。

しかし、クラウド監視サービスを使えば、監視設計が不要になるわけではありません。

標準メトリクスで足りるのか。 エージェントやプラグインが必要なのか。 どの条件でアラームを出すのか。 誰に通知するのか。 通知を受けた人が何を確認するのか。

クラウドでも、オンプレミスでも、監視の本質は同じです。

監視は、アラートを出すための設定ではありません。障害に気づき、判断し、対応につなげるための設計です。

クラウド監視とは何か

ここまで説明してきた監視構成は、どちらかというとオンプレミスや従来型の監視製品を前提にしています。

一方、クラウドでは考え方が少し変わります。

クラウドでは、クラウドベンダーが用意する監視サービスを使って、仮想サーバ、ストレージ、ロードバランサ、データベース、ネットワーク、サーバレス、コンテナなどのメトリクス、ログ、イベントを収集できます。

そのため、従来のように自前で監視サーバーを立てて、すべてのサーバに監視エージェントを導入し、監視製品を運用する、という構成が必ずしも必要ではありません。ただし、ここで誤解してはいけないことがあります。

クラウド監視サービスがあることと、監視設計が不要になることは別です。
クラウド監視サービスは、監視を実現するための部品です。

何を監視するのか。 どの値を異常とするのか。 どの条件で通知するのか。 通知を受けた人が何を確認するのか。 既存システムで行っていた監視を新システムでも継続するのか。

ここは、設計で決める必要があります。

特にオンプレミスからクラウドへ移行する業務システムでは、既存監視の引き継ぎが大きな論点になります。

クラウド監視サービスの代表例

クラウド監視サービスは、クラウドベンダーごとに用意されています。

AWSであれば、CloudWatch。 Azureであれば、Azure Monitor。 Google Cloudであれば、Cloud Monitoring。 OCIであれば、OCI Monitoring。

それぞれ名称や機能の範囲は異なりますが、基本的には、クラウド上のリソースからメトリクス、ログ、イベントを収集し、条件に応じてアラームや通知につなげるためのサービスです。

この記事では、AWSでよく使われるCloudWatchを中心に説明します。

あわせて、Oracle DatabaseやOracle製品を利用している業務システムではOCIが選択肢になることもあるため、OCI Monitoringについても簡単に触れます。

AWS CloudWatchの場合

AWS CloudWatchは、AWS上のリソースを監視するための代表的なサービスです。

EC2、RDS、ELB、EBS、Lambda、ECS、EKSなど、AWS上の多くのサービスはCloudWatchにメトリクスを出力できます。

たとえば、EC2であればCPU使用率、ネットワーク送受信量、ディスクI/Oなどを確認できます。

RDSであれば、CPU使用率、DB接続数、ストレージ容量、読み書きIOPSなどを確認できます。ELBであれば、リクエスト数、ターゲットの正常性、HTTPエラー数、レスポンスタイムなどを確認できます。

CloudWatchでは、こうしたメトリクスに対してアラームを設定できます。

たとえば、CPU使用率が一定時間以上高い状態が続いたら通知する。 RDSの空き容量が少なくなったら通知する。 ELB配下の正常ターゲット数が減ったら通知する。 アプリケーションログに特定のエラーメッセージが出たら通知する。

このように、CloudWatchはAWS上のシステム監視における基本的な部品になります。ただし、CloudWatchを使えばすべてが自動で完璧に監視されるわけではありません。

標準メトリクスで足りるのか。 詳細監視が必要なのか。 CloudWatch Agentを入れてOS内部のメモリやディスク使用率を取得するのか。 アプリケーションログをCloudWatch Logsへ送るのか。 ログのどの文字列を異常として拾うのか。 アラーム閾値をどう設定するのか。 通知先をどうするのか。 通知を受けた人が何を確認するのか。

これらは設計が必要です。

特にオンプレミスからAWSへ移行する場合、既存の監視をCloudWatchだけでそのまま置き換えられるとは限りません。

JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで見ていた監視項目が、CloudWatchの標準メトリクスだけで同じ粒度で取得できるとは限らないからです。

そのため、AWSへ移行する場合でも、CloudWatchで何が見えるかだけではなく、既存監視で何を見ていたのか、新システムでも同じ監視が必要なのか、必要ならCloudWatchで代替できるのか、できない場合は何で補うのかを整理する必要があります。

OCI Monitoringの場合

OCIでも、クラウドネイティブな監視サービスがあります。
代表的なのがOCI Monitoringです。

OCI Monitoringを使うと、OCI上のコンピュート、ストレージ、ロードバランサ、データベース、ネットワーク関連リソースなどのメトリクスを収集し、条件に応じてアラームを設定できます。

OCIのComputeインスタンスでは、プラグインを有効化することで、インスタンスの状態やメトリクスを取得できる構成もあります。
ただし、OCI Monitoringを使えば、Oracle Databaseの性能監視や既存の運用監視がすべて自動で置き換わるわけではありません。

Oracle Databaseを利用している業務システムでは、OCI Monitoringで見るもの、Oracle Database側の機能で見るもの、OEMで見るもの、ログ監視で見るもの、運用手順で確認するものを分けて考える必要があります。

特に、既存システムでOracle Database、Oracle Enterprise Manager、AWR、ASH、Performance Hub、PFM for Oracleなどを利用していた場合、クラウド移行後にどの監視を何で代替するのかを整理する必要があります。

Oracle系システムでは、DB性能、待機イベント、SQL、セッション、表領域、アラートログなど、DB内部の監視観点が重要になることがあります。
そのため、OCI Monitoringだけで考えるのではなく、Oracle Databaseの監視機能や既存運用を含めて、全体として監視設計を行う必要があります。

クラウド移行では、既存監視のFit & Gapが必要

クラウド移行といっても、完全な新規開発ばかりではありません。

実務では、既存のオンプレミスシステムをクラウドへ移すリフト＆シフトや、移行後に段階的にクラウドネイティブ化していくケースが多くあります。

その場合、移行前のシステムで行っていた監視を、移行後にどう引き継ぐかが大きな論点になります。

既存環境では、JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで、OS、ジョブ、ログ、DB性能、表領域、待機イベント、SQL、アラートログなどを監視していたかもしれません。

では、それをクラウド移行後に同じように見られるのでしょうか。答えは、簡単ではありません。

クラウド移行後の監視Fit & Gapでは、少なくとも次の3つに整理して考える必要があります。

1. 既存監視を標準機能で置き換えられるもの

PFM for Oracleや既存監視製品で見ていた内容を、OEM、AWR、ASH、Performance Hub、CloudWatch、Performance Insights、Database Insightsなどで代替できる場合は、新環境の標準機能に寄せる判断があります。

この場合、既存監視をそのまま機械的に移植するのではなく、新環境で標準的に提供されている監視機能を使い、運用をシンプルにできないかを検討します。

2. 標準機能だけでは置き換えられないもの

一方で、既存監視で見ていた項目が、新環境の標準機能では取得できない、または同じ粒度で監視できない場合もあります。

その場合は、代替方式を検討します。

別のメトリクスで代替できるのか。 ログ監視で拾えるのか。 スクリプトで補完できるのか。 外部監視製品やAPMを使うのか。 そもそも新環境でも本当に必要な監視なのか。

ここを整理せずに進めると、オンプレでは見えていた異常が、クラウド移行後に見えなくなることがあります。

3. 代替するか、捨てるか、運用でカバーするもの

標準機能で置き換えられない監視については、最終的に判断が必要です。

手組みしてでも実装するのか。 別製品を追加して実現するのか。 運用手順でカバーするのか。 監視対象から外すのか。

監視を外す場合は、障害検知が遅れる可能性、一次対応への影響、サービスレベルへの影響を説明し、リスク受容として顧客と合意する必要があります。

ここで重要なのは、プロジェクト側だけで勝手に決めないことです。

既存システムで実装されていた監視には、多くの場合、過去の障害、運用上の要請、監査対応、顧客側の不安、サービスレベル上の理由があります。

そのため、単に「新しい製品ではできないのでやりません」とは言いにくいことがあります。

技術的には実現できない。 実現はできるがコストが高すぎる。 手組みすれば可能だが保守性が悪い。 運用カバーで十分と判断できる。 リスクを受容して監視対象から外す。

こうした判断を、要件、コスト、運用負荷、障害時の影響、顧客の期待値を踏まえて整理します。

クラウド移行時の監視設計で重要なのは、既存監視を機械的に移植することではありません。

業務システムとして必要な異常検知、性能把握、一次対応、エスカレーションが、新システムでも成立するかを確認することです。

そのうえで、できること、できないこと、代替すること、やめることを顧客と合意する。ここまで含めて、新システムの監視設計です。

監視対象・目的で見た監視の種類

ここで重要なポイントは、「監視方式」と「監視対象・監視目的」を混同しないことです。

この中で、若手SEが特に理解しておくべきなのは、死活監視だけでは業務正常性は分からないという点です。

サーバに ping が通っていても、Web画面がエラーになっているかもしれません。 Web画面が開いても、検索処理が失敗するかもしれません。 DBプロセスが起動していても、表領域が枯渇して更新できないかもしれません。 バックアップジョブが正常終了していても、リストアできないかもしれません。

だからこそ、監視設計では「何をもって正常と判断するのか」を決める必要があります。

監視方式は「何を知りたいか」から選ぶ

監視方式を選ぶときに大事なのは、製品や流行から入らないことです。

まず決めるべきなのは、「何を知りたいのか」です。

サーバが起動しているかを知りたいなら、死活監視です。
Webサービスが応答しているかを知りたいなら、URL監視です。
OS内部のCPUやメモリを知りたいなら、リソース監視です。
DBプロセスが動いているかを知りたいなら、プロセス監視です。
DBとしてログインできるかを知りたいなら、DB接続監視です。
ログに異常メッセージが出ていないか知りたいなら、ログ監視です。
ストレージやネットワーク機器の状態を知りたいなら、SNMP監視や製品API監視です。
クラウドリソースの状態を知りたいなら、CloudWatchやOCI Monitoringなどのクラウド監視サービスです。

監視方式は、目的によって変わります。

逆に言えば、監視方式だけを決めても意味がありません。

「SNMPで監視します」では不十分です。

SNMPで何を監視するのか。
どのOIDを見るのか。
どのTrapを受けるのか。
重大度をどう判定するのか。
通知先はどこか。
一次対応手順は何か。

ここまで決めて初めて、監視設計になります。

監視設計で決めること

監視設計では、最低限、次のような項目を決めます。

• 監視対象
• 監視項目
• 監視方式
• 監視間隔
• 閾値
• 検知条件
• 除外条件
• 重大度
• 通知先
• 通知方法
• 監視抑止条件
• メンテナンス時の扱い
• 一次対応手順
• エスカレーション先
• 復旧確認方法
• 監視設定の変更手順
• 監視条件の見直しタイミング

たとえば、CPU使用率の監視でも、単に「CPUを監視する」では足りません。

CPU使用率が何％を超えたら警告なのか。 何分継続したら異常なのか。 瞬間的なスパイクは除外するのか。 夜間バッチ中は閾値を変えるのか。 警告と異常で通知先を分けるのか。 通知を受けたら、運用者は何を見るのか。 AP担当、DB担当、基盤担当のどこへ連絡するのか。

ここまで決める必要があります。

監視は、アラートを出すことが目的ではありません。

アラートを受けた人が判断できることが目的です。

監視でよくある誤解

監視でよくある誤解は、次の3つです。

そのため、監視設計は、設計時点で決めて終わりではありません。
システムテスト、運用テスト、本番リハーサル、本番稼働後の初期期間を通じて、見直す前提が必要です。

若手SEに持ってほしい監視の見方

若手SEにまず持ってほしいのは、「監視は設定項目ではなく、運用の入口である」という見方です。

監視アラートは、障害対応のスタート地点です。

アラートが出た瞬間に、運用者は判断を求められます。

これは本当に障害なのか。
無視してよい通知なのか。
すぐにエスカレーションすべきなのか。
まず手順書に沿って確認すべきなのか。
復旧したと言える条件は何か。

この判断ができるように設計するのが、監視設計です。

監視サーバーがある。
エージェントが入っている。
CloudWatchにメトリクスが出ている。
OCI Monitoringにアラームがある。 MIBを読み込ませた。

それだけでは、監視設計としては不十分です。
重要なのは、検知した後に運用が動けることです。

まとめ

クラウド監視サービスを使えば、メトリクス、ログ、アラームを扱いやすくなります。しかし、監視設計が不要になるわけではありません。

特にオンプレミスからクラウドへ移行する業務システムでは、既存監視をどう扱うかが重要です。

既存監視を標準機能で置き換えられるもの。
標準機能だけでは置き換えられないもの。
代替するか、捨てるか、運用でカバーするもの。

この3つに分けて、Fit & Gapを整理する必要があります。

監視で大事なのは、たくさん検知することではありません。
本当に検知すべき異常を、運用で対応できる形で検知することです。
監視は、アラートを出すための設定ではありません。
障害に気づき、判断し、対応につなげるための設計です。

詳細設計の中で監視をどう設計するか、ログ監視条件をシステムテスト以降にどう見直すか、監視と運用手順をどうつなげるかについては、以下の記事でも詳しく整理しています。

前編では、監視サーバーの構成、死活監視、エージェント監視、エージェントレス監視、SNMP監視の基本を整理しています。

あわせて読みたい

詳細設計で決めること 後編②｜監視・ログ・バックアップ・セキュリティ・運用スクリプト
機能要件と非機能要件の違い
システム開発の流れを現場目線で理解する｜前編
要件定義の正体

このエラーは、原因を一つに限定できるものではありません。

Cドライブの空き容量不足、Windows Updateのキャッシュ不整合、関連サービスの異常、システムファイル破損、WSUS配信側の問題など、複数の原因で発生する可能性があります。

ただし、まず確認したいのは Cドライブの空き容量 です。

実際の対応事例では、累積更新プログラム「KB5011495」の適用時に、Cドライブの空き容量不足が原因でエラー0x80080008が発生しました。

まず試す対処法

エラー0x80080008が発生した場合は、次の順番で確認します。

1. Cドライブの空き容量を確認する

2. 不要ファイルを削除する

3. 端末を再起動する

4. Windows Updateを再実行する

5. 更新履歴から失敗しているKB番号を確認する

6. Microsoft Update カタログから個別適用を試す

7. それでも直らない場合は、Windows Update関連サービスやシステムファイル破損を確認する

最初から複雑な解析に入るよりも、まずは容量不足や再起動待ちなど、簡単に確認できるところから見ていくのが現実的です。

発生したエラー

Windows Updateの実行中に、次のようなエラーが表示されました。

更新に失敗しました。
いくつかの更新プログラムのインストールに問題がありましたが、後で再試行します。
エラーコード：0x80080008

今回のケースでは、WSUSから更新プログラムをダウンロードするところまでは正常に完了していました。

しかし、クライアント端末側で更新プログラムを適用する段階で失敗していました。

つまり、ダウンロードではなく、インストール処理で問題が発生していたということです。

原因1：Cドライブの空き容量不足

最初に確認すべきなのは、Cドライブの空き容量です。

累積更新プログラムは、更新ファイルをダウンロードするだけではありません。

端末上で、展開、一時ファイル作成、バックアップ、ロールバック用データの保持などを行います。

そのため、更新プログラムのファイルサイズ以上に空き容量が必要になることがあります。

今回の事例では、更新プログラム「KB5011495」の適用に約6GB程度の空き容量が必要でした。

対象端末ではCドライブの空き容量が不足しており、その結果、0x80080008で更新に失敗していました。

対処

次のような方法でCドライブの空き容量を確保します。

• ダウンロードフォルダの不要ファイルを削除する

• デスクトップ上の大容量ファイルを移動する

• ドキュメント、ピクチャ、ビデオ配下の不要ファイルを整理する

• 一時ファイルを削除する

• 必要なファイルをDドライブや共有フォルダへ移動する

空き容量を確保したら、端末を再起動し、Windows Updateを再実行します。

原因2：Windows Updateのキャッシュ不整合

Cドライブの空き容量を確保しても失敗する場合は、Windows Updateのキャッシュ不整合を疑います。

過去の更新失敗、中断、ネットワーク切断、強制再起動などにより、更新プログラムの一時ファイルやダウンロード情報が中途半端な状態で残ることがあります。

この状態になると、Windows Updateを再実行しても同じエラーで失敗する場合があります。

対処

まずはWindows Updateトラブルシューティングツールを実行します。

Windowsの設定画面から、次の順番で確認します。

設定
→ システム
→ トラブルシューティング
→ その他のトラブルシューティングツール
→ Windows Update

環境によって表示名や場所が異なる場合があります。

企業端末の場合は、WSUSや端末管理ツールと連携していることがあります。

独断で更新キャッシュを削除すると、管理側の状態と不整合になる可能性があります。

社内端末では、社内の標準手順や保守サポートの指示に従って対応してください。

原因3：Windows Update関連サービスの異常

Windows Updateは、複数のサービスに依存しています。

代表的なサービスは次のとおりです。

• Windows Update

• BITS

• 暗号化サービス

これらのサービスが停止している、起動に失敗している、またはセキュリティソフトの影響を受けている場合、更新プログラムの適用に失敗することがあります。

確認ポイント

次の点を確認します。

• Windows Updateサービスが起動しているか

• BITSが起動しているか

• 暗号化サービスが起動しているか

• サービス起動時にエラーが出ていないか

• イベントログにWindows Update関連のエラーが出ていないか

個人PCであればサービスの再起動を試す方法もあります。

ただし、企業端末の場合は、管理ポリシーや端末管理ツールの影響を受けることがあります。

社内端末では、独断でサービス設定を変更せず、管理部門の手順に従ってください。

原因4：システムファイルやコンポーネントストアの破損

Windows Updateに必要なシステムファイルやコンポーネントストアに問題がある場合も、0x80080008が発生することがあります。

この場合、Windows Updateを何度再実行しても改善しないことがあります。

対処

管理者権限のコマンドプロンプトで、次のコマンドを実行します。

sfc /scannow

このコマンドは、Windowsのシステムファイルに破損がないかを確認し、修復を試みるものです。

完了までに時間がかかる場合があります。

処理中はコマンドプロンプトを閉じたり、端末を再起動したりしないでください。

必要に応じて、DISMによる修復も実行します。

DISM /Online /Cleanup-Image /RestoreHealth

DISMは環境によって数十分かかることがあります。

進行率が途中で止まっているように見える場合でも、すぐに中断せず、処理が完了するまで待つ必要があります。

ただし、これらの操作は端末の状態を変更します。

企業端末では、必ず社内の標準手順や保守サポートの指示に従って実行してください。

原因5：WSUS配信側の問題

WSUS環境では、クライアント端末だけでなく、配信側の状態も確認する必要があります。

特に、複数端末で同時にエラー0x80080008が発生している場合は、WSUSやグループポリシー側の問題も疑います。

確認ポイント

次の点を確認します。

• WSUS上で対象更新プログラムが承認されているか

• 必要な前提更新プログラムが配信されているか

• 端末が正しいコンピュータグループに所属しているか

• WSUSの同期やダウンロードが失敗していないか

• グループポリシーが正しく適用されているか

今回の事例では、更新プログラムのダウンロードまでは完了していました。

そのため、WSUS配信そのものではなく、クライアント端末側の容量不足が原因でした。

一方で、ダウンロード自体が始まらない、同じグループの端末で一斉に失敗する、といった場合はWSUS側も確認が必要です。

Microsoft Update カタログから個別適用する

Windows Updateを再実行しても失敗する場合は、Microsoft Update カタログから該当する更新プログラムを直接ダウンロードし、個別適用する方法があります。

確認するポイントは次のとおりです。

• 失敗しているKB番号

• 対象OSのバージョン

• 32bit / 64bit の違い

• サーバーOSかクライアントOSか

• 既に適用済みの更新プログラムとの関係

誤った更新プログラムを適用しようとすると、別のエラーにつながる可能性があります。

必ず対象端末のOSバージョンとKB番号を確認してください。

単独端末か、複数端末かで切り分ける

0x80080008が発生したときは、単独端末の問題なのか、複数端末で同時に起きている問題なのかを確認します。

単独端末だけで発生している場合

次のような端末固有の問題を疑います。

• Cドライブの空き容量不足

• 更新キャッシュ不整合

• 再起動待ち

• システムファイル破損

• 端末固有のサービス異常

複数端末で同時に発生している場合

次のような共通基盤側の問題を疑います。

• WSUS配信設定

• グループポリシー

• プロキシ

• ネットワーク

• セキュリティ製品

• 端末管理ツール

すべての端末で同じ作業を繰り返す前に、端末個別の問題なのか、共通基盤側の問題なのかを切り分けることが重要です。

まとめ

Windows Updateでエラー0x80080008が発生した場合、まず確認したいのはCドライブの空き容量です。

実際の事例では、累積更新プログラム「KB5011495」の適用時に、Cドライブの空き容量不足が原因で更新に失敗しました。

対処としては、不要ファイルを削除するか、Dドライブや共有フォルダへファイルを移動し、空き容量を確保したうえでWindows Updateを再実行します。

ただし、0x80080008は容量不足だけで発生するエラーではありません。

容量を確保しても解消しない場合は、次の観点を順番に確認します。

• Windows Updateのキャッシュ不整合

• Windows Update関連サービスの異常

• システムファイルやコンポーネントストアの破損

• WSUS配信側の問題

• グループポリシーや端末管理ツールの影響

まずは容量不足から確認する。

それでも直らなければ、端末側と配信基盤側を分けて切り分ける。

この順番で確認すると、原因を絞り込みやすくなります。

詳しい現場視点の解説について

この記事では、Windows Updateエラー0x80080008の対処手順を中心に整理しました。

実際の現場では、Windows Updateの失敗がOutlook、Teams、インターネット接続、業務システムの利用制限につながることがあります。

そのため、単なる端末トラブルではなく、運用設計として事前に潰しておくことも重要です。

WSUS運用、問い合わせ対応、FAQが機能しにくい理由、事前通知や自動削除の考え方については、別記事で詳しく整理する予定です。

前編では詳細設計の考え方を、後編①ではOS・Web/AP・DB・ジョブの設計観点を整理しました。

後編②では、監視、ログ、バックアップ・リストア、セキュリティ、運用スクリプトの5領域を扱います。これらは、システムを「作る」工程よりも「運用する」工程に深く関わる領域です。設計時点では正しく見えても、実際の業務データが入り、本番相当の運用サイクルが回り始めて初めて問題が見えてくる領域でもあります。

各章は独立して参照できますが、前編の品質保証ストーリーと後編①の設計観点を踏まえて読むと、各論点の背景が理解しやすくなります。

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

5. 監視詳細設計

監視詳細設計では、システムの異常をどのように検知し、誰に通知し、どのように一次対応へつなげるかを具体化します。

監視対象、監視方式、監視間隔、閾値、重大度、通知先、通知方法、抑止条件、メンテナンス時の扱い、一次対応手順との対応などが対象です。

監視詳細設計では、監視項目を増やせばよいわけではありません。

本当に検知すべき異常を、運用で対応できる形で検知することが目的です。

この「本当に検知すべき異常を見極める」という点で、最も設計が難しい領域がログ監視です。

前編で、詳細設計は「どこを試験で確認し、どこを運用監視で検知するかを説明できる状態にする」工程だと整理しました。ログ監視は、その考え方が最も問われる領域の一つです。

なぜなら、監視条件の正しさは、設計時点では確認できないからです。

設計時点では、システム全体に本番相当の負荷がかかっているわけではありません。業務データも十分に入っていないことが多く、日次処理、月次処理、ピーク時のトランザクション、本番相当の運用操作もまだ十分に流れていません。

そのため、監視対象のエラーログに、本来検知すべきメッセージが設計時点で出ているとは限りません。

`error`、`fail`、`fatal`、`exception` といったキーワードをベンダー確認や製品マニュアルをもとに監視条件へ入れることはできます。しかし、そのキーワードを含むログが、本当にアラートとして通知すべき異常なのか、あるいは製品やミドルウェアが通常運転の中で出力する無視可能なメッセージなのかは、設計時点だけでは判断しきれないことがあります。

システムテスト以降、業務データが入り、日回し、月回し、本番に近いトランザクションが流れるようになると、初めて大量のログメッセージが出てきます。

その中には、確実に検知すべきエラーもあります。
一方で、エラーのように見えても運用上は無視してよい標準的な出力もあります。

この見極めをしないまま本番稼働すると、運用開始後に大量のアラートが発生します。

監視設計で怖いのは、アラートが出ないことだけではありません。アラートが出すぎて、運用者が判断できなくなることも同じくらい危険です。

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

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

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

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

1. OS詳細設計

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

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

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

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

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

• OSログをどこに出すのか
• syslog や messages を何日保持するのか
• ログローテーションをどう行うのか
• rootログインを許可するのか
• sudo権限を誰に与えるのか。
• 時刻同期がずれた場合にどう検知するのか
• 不要サービスを停止しているか
• OSパッチ適用をどう行うのか

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

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

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

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

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

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

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

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

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

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

• ログ監視製品が、ファイル名で監視するのか、ファイル実体を追跡するのか
• ローテーション後に、監視対象が新しいログファイルへ正しく切り替わるのか
• copytruncate、リネーム、再オープンなど、どのローテーション方式を採用するのか
• syslogやアプリケーション側でログファイルの再オープンが必要か
• ローテーション後も、監視キーワードが検知されるか
• ログローテーション試験で、監視アラートまで確認しているか

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

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

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

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

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

• ホスト名、IPアドレス、名前解決
• ディスク構成、マウントポイント、ファイルシステム
• ユーザ、グループ、sudo権限
• 起動サービス、不要サービス停止
• 時刻同期、タイムゾーン
• OSログ、ログローテーション
• ログ監視製品との連携
• ローテーション後の監視継続確認
• パッケージ、リポジトリ、パッチ適用方針
• OSセキュリティ設定
• 監視対象となるプロセス・リソース

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

• サーバの役割に応じて、必要なOS設定・サービス・権限が整理されているか
• ログローテーション後も、監視製品が本来のログを監視し続けられるか
• パッチ適用、不要サービス停止、sudo権限はセキュリティ設計と整合しているか

「PoCでは問題なかったのに、構築に入ったら次々と課題が出てきた」

「接続確認はできていたのに、業務処理を流すと性能が出ない」

「バックアップは成功していたのに、戻す手順や時間を詰めていなかった」

「共有ストレージとして使えると思ったのに、既存アプリのファイル更新方式と合わなかった」

クラウドリフトでは、こうしたことが実際に起こります。

PoCでEC2上のアプリは起動した。EFS上のファイルは読み書きできた。FSx経由のファイル共有も確認した。RDS上で主要なアプリ機能も動いた。CloudWatch Logsにもログは出力された。バックアップジョブも正常終了した。

しかし、それだけでは、クラウドリフトPoCとしては足りません。

「動いた」という確認は、業務が回るという確認とは別だからです。

クラウドリフトで本当に怖いのは、PoCで「動いた」と判断したあとに、設計・構築・試験・運用の段階で後から手戻りになることです。

性能が出ない。名前解決が想定どおりに動かない。Auto Scaling後に監視やジョブ実行対象として認識されない。EFS上のファイル更新方式が既存アプリと合わない。CloudWatch LogsのS3エクスポートが運用時間内に終わらない。バックアップの保持期間が業務要件とずれる。ライセンスやデータ転送量のコストが見積から漏れている。

こうした問題は、現場では個別の設定ミスや確認不足に見えます。

しかし、多くのプロジェクトで、PoCや設計段階で潰すべきリスクが残ったまま後工程へ進み、結果として大きな手戻りや追加対応につながる場面を見てきました。

この記事は、クラウドリフトPoCを扱う全3部作の第2部前編です。

第1部では、クラウドリフトの失敗が構築後ではなく、構築前のPoC不足から始まることを整理しました。

【第1部】クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由

第2部では、その続きとして、クラウドリフトPoCで見落とすと手戻りになりやすい10の設計リスクを整理します。

第2部は、前編と後編に分けています。

前編で扱うのは、クラウド基盤として業務を受け止めるために必要な、次の5項目です。

１.可用性・信頼性
２.性能・キャパシティ
３.ストレージ
４.バックアップ
５.運用・監視

後編では、構築後に運用・保守・統制・コスト管理で詰まりやすい、次の5項目を扱います。

６.ジョブ管理・アプリ配布
７.セキュリティ・アクセス管理
８.ライセンス・製品サポート
９.DB・OS・ミドルウェア互換性
１０.コスト・キャパシティ管理

つまり第2部では、「PoCで動いたか」ではなく、「その方式で設計・試験・運用・見積まで成立するか」を、10の観点から確認していきます。

この記事で整理する設計リスクは、机上で作ったチェックリストではありません。

大規模なクラウドリフト案件で、PoCを実施し、有識者も交えてリスクを潰しにいった中で見えてきた論点をもとにしています。

RDS for OracleのDBA権限制約、EFS上での複数ノードによるファイル更新の競合、FSxのKerberos/SPN認証、名前解決経路とTTLの切替挙動、マネージドサービスのパッチ適用と自社セキュリティルールの整合などは、PoCで事前に確認しておくべき代表的な論点です。

一方で、事前に検証していても、後工程で表面化した問題もありました。

別AZ起動後のOS内ルート情報による通信不能、CloudWatch LogsのS3エクスポート制約、EBSの容量縮小、S3クロスアカウントのオブジェクト所有者問題、RHELとAmazon LinuxのOS設定差分、cloud-initによるSSH設定上書き、Auto Scalingの意図しないEC2再作成などです。

「PoCで潰せたこと」と「PoCで潰しきれなかったこと」。

その両方を踏まえて、現時点でクラウドリフトPoCに必要なチェック観点を整理したのが、この第2部です。

PoCは、AWSサービスが使えるかを確認する作業ではありません。

既存業務の処理方式、運用方式、復旧方式、名前解決、バックアップ、監視、ジョブ、ファイル更新方式、DB運用、ライセンス、コストが、クラウド上の構成で成立するかを確認する作業です。

以下の図は、クラウドリフトPoCで見るべき10の設計リスクを整理したものです。

それぞれ、単なるチェックリストではありません。

見落とすと、設計、試験、運用、見積、スケジュールにどう跳ね返るのかまで含めて整理します。

PoC観点を強化するきっかけになった個別事例

以下は、クラウドリフトPoCの観点を見直すきっかけになった個別事例です。

本記事では、これらの個別事例に加え、PoCで事前に潰せた設計論点も含めて、クラウドリフトPoCで見るべきリスクを整理しています。

• 【AWS】別AZで起動したWindowsが通信不能に｜原因はVPCではなく「OS内のルート情報」だった
• CloudWatch Logsのログエクスポートが失敗した話｜「ジョブは動く」と「運用で回る」は別物
• バックアップ設定の「5日保存」は、5営業日分とは限らない｜AWS Backupの保持期間から考える、詳細設計の落とし穴
• EBSは増やせても、簡単には減らせない｜RHEL環境で見落とした「容量縮小＝ディスク移行」という現実
• S3バケットにあるのに取得できない｜クロスアカウント構成で見落とした「オブジェクト所有者」の罠
• RHELで使えた設定方法が、Amazon Linuxでは使えなかった｜MTU設定に見る、OS差分と永続化確認の落とし穴
• EBSは見えているのにマウントできない？｜AMIコピーで起きた落とし穴
• AMIからRHELインスタンスを起動したらSSHログインできなくなった｜cloud-initが上書きする設定を知らないと、復旧以前に入れなくなる
• EC2を止めただけなのに再作成？Auto Scaling運用の落とし穴｜クラウドの自動化は、作業者の意図までは読んでくれない

なお、後編では購入者特典として、10項目全体を整理したExcel資料「クラウドリフトPoC設計リスクチェックリスト」も添付します。

PoC計画、設計レビュー、リスク洗い出しのたたき台として使えるようにしています。

1. 可用性・信頼性

EC2が起動しただけでは、業務復旧とは言えない

クラウドリフトでは、可用性設計が軽く見られることがあります。

EC2は再作成できる。
RDSはMulti-AZにできる。
Auto Scalingを使えば復旧できる。
ロードバランサー配下に置けば切り替えられる。

マネージドサービスがすべてやってくれるように見えるからです。

しかし、業務システムの復旧は、EC2が起動することではありません。

業務処理が再開できることです。

Auto Scalingを使う場合でも、EC2が新しく作られれば終わりではありません。

実際の復旧方式では、障害ノードをロードバランサー配下から切り離し、AMIから新規EC2を作成し、cloud-initやUser Dataを使って初期設定を反映し、ホスト名を付与し、DNSに登録し、監視エージェントやミドルウェアを起動する、といった一連の処理が必要になります。

ここで重要なのは、単にスクリプトを書けるかどうかではありません。

実行タイミングです。

ホスト名の付与が監視エージェントやミドルウェアの起動より後になると、誤ったホスト名でサービスが起動し、監視登録やジョブ実行対象の認識がずれることがあります。

そのため、cloud-initのどの段階で設定を反映するのか、User Dataで実行するのか、設定ファイル側で制御するのか、サービス起動順序をどうするのかまで確認しなければなりません。

さらに、ロードバランサーのヘルスチェックに戻す条件、監視対象への再登録、ジョブ実行対象としての認識、ログ収集先の切替、障害解析のために旧EC2を残すかどうかも決める必要があります。

Auto Scalingは復旧方式の一部であって、復旧方式そのものではありません。

AWS側が支援してくれるのは、インスタンスの再作成、ロードバランサーのヘルスチェック、マネージドサービスの切替といった基盤機能の部分です。

一方で、作り直されたEC2を業務システムとして使える状態に戻す設計は、利用者側の責任です。

ホスト名、DNS登録、監視エージェント、ミドルウェア起動順序、ジョブ実行対象への再登録、ログ収集先の切替、復旧後の業務確認は、クラウドが自動で判断してくれるわけではありません。

PoCでは、EC2が作られるかではなく、作られたEC2が業務システムの構成要素として正しく組み込まれるかを確認する必要があります。

この復旧の流れは、文章だけでは見落とされやすいため、図に整理すると次のようになります。

保守停止と障害検知は分けて考える

Auto Scalingでは、EC2が意図せず停止した場合に、期待する台数を維持するため、新しいEC2が作られることがあります。

これは可用性の観点では便利です。

しかし、運用の観点では注意が必要です。

保守作業としてEC2を停止したいだけでも、停止方法や事前の切り離し手順が適切でなければ、Auto Scaling側では障害や不足状態として扱われることがあります。

作業者は「保守のために止めた」と思っている。
しかし、Auto Scalingは期待台数を維持する仕組みとして、元の台数へ戻そうとします。

その結果、意図しないEC2が作られ、監視、ジョブ、ログ、ライセンス、コストの前提が崩れることがあります。

このようなことが起こります。

つまり、Auto Scalingを使うなら、障害時にどう復旧するかだけでなく、保守時にどう止めるかも設計しなければなりません。

保守作業時には、Auto Scalingグループの期待台数を変更するのか。
インスタンス保護を使うのか。
スケーリングを一時停止するのか。
ロードバランサーから切り離して作業するのか。
作業後にどう戻すのか。

この運用手順を決めずにAuto Scalingを使うと、「自動復旧」が「作業者の意図しない再作成」になります。

クラウドの自動化は、作業者の意図までは読んでくれません。

PoCでは、障害時の自動復旧だけでなく、保守停止、再起動、切り離し、再登録、戻し忘れの検知まで確認する必要があります。

別AZで起動できても、通信できるとは限らない

別AZでEC2を起動できたとしても、通信できるとは限りません。

VPC、サブネット、ルートテーブル、Security Groupが正しく見えていても、OS内に残っている静的ルート、永続ルート、NIC設定、メトリック設定が移行後のネットワーク構成と合わないことがあります。

その場合、AWS側のネットワーク設定だけを見ても原因にたどり着けません。

クラウド移行では、ネットワークの問題を見るときに、どうしてもVPC側へ目が向きます。

ルートテーブルは正しいか。
Security Groupは開いているか。
NACLで落ちていないか。
サブネットの関連付けは正しいか。
Transit GatewayやVPN経路は正しいか。

もちろん、それらは重要です。

しかし、OS内に固定で設定されていたルート情報、古いネットワークアダプタ前提の設定、特定AZや特定サブネットのIPを前提にした設定が残っていると、AWS側のネットワークが正しくても通信できないことがあります。

特にWindowsサーバでは、GUI上のネットワーク設定だけでなく、永続ルート、メトリック、複数NIC構成、過去に追加した静的経路などが影響することがあります。

PoCでは、EC2が起動するか、疎通確認が一度通るかだけでなく、OS内のルート情報、再起動後の永続化、AZ変更後の通信経路まで確認する必要があります。

「AWS側の設定は正しいのに通信できない」という状態は、原因調査に時間がかかります。

だからこそ、PoCの段階で、OS内のネットワーク前提まで確認しておく必要があります。

名前解決は、クラウドリフトにおける最重要設計論点

クラウドリフトでは、名前解決が非常に重要です。

オンプレでは、サーバ名、IPアドレス、DNS登録、参照経路が長期間固定されている前提で運用されていることがあります。

しかし、クラウドでは、EC2の再作成、AZ変更、復旧方式、切替方式によって、同じIPアドレス、同じ物理名、同じ参照経路で戻ってくるとは限りません。

そのため、必要に応じてDNSやRoute 53のレコードを書き換える設計が必要になります。

ここで注意すべきなのは、「DNSを書き換えればよい」という単純な話ではないことです。

参照元がAWS内のEC2なのか。
別VPCなのか。
オンプレミスのクライアントなのか。
AD DNSを見ているのか。
オンプレDNSからRoute 53へフォワードしているのか。
Route 53 Private Hosted Zoneを直接見ているのか。

この経路によって、復旧時に変更すべき場所が変わります。

特にハイブリッド構成では、Route 53 ResolverのInbound endpoint、Outbound endpoint、転送ルールの設計も重要になります。

オンプレ側からAWS内の名前を解決するのか。
AWS側からオンプレDNSへ問い合わせるのか。
どのドメインを、どのDNSへフォワードするのか。

また、名前解決は成功するか失敗するかだけでなく、問い合わせにどれくらい時間がかかるかも重要です。

オンプレDNS、Route 53 Resolver、AD DNS、別VPCのDNSをまたぐ構成では、フォワード先の設定、再帰問い合わせ、リトライ挙動によって、名前解決の遅延がアプリケーションの応答時間やタイムアウトに影響することがあります。

この設計を誤ると、AWS側では名前解決できているのに、オンプレ端末や業務サーバからは名前解決できない、という状態になります。

場合によっては、クラウド側のレコードを変更したつもりでも、参照元が別のDNSサーバを見ていて、期待した名前解決にならないことがあります。

ここを知らずに進むと、基盤結合試験まで発見されないことがあります。

システムテストのユースケースが甘いと、本番切替後に初めて通信できない、接続先が違う、名前解決できない、という形で発覚する可能性があります。

クラウドリフトでは、DNSは単なる付帯設定ではありません。

復旧方式、切替方式、運用方式そのものに関わる設計要素です。

DNSキャッシュとTTLも見落としやすい

切替直後は、クライアントやアプリケーションが古い名前解決結果をキャッシュしているため、一見すると通信できているように見えることがあります。

しかし、TTLが切れて再度名前解決が行われたタイミングで、参照先DNS、Route 53、オンプレDNS、Resolver経路、レコード状態のどこかに不整合があると、名前解決エラーや接続先誤りとして表面化します。

また、OS、JVM、ミドルウェア、接続プール、プロキシなどが名前解決結果や接続先情報を保持していると、Route 53側のTTLだけを見ていても切替挙動を説明できません。

DNS再解決を契機に接続先が変わり、TLS証明書のホスト名検証、DB接続、認証処理、接続プールの再接続で失敗することもあります。

特にアプリケーションサーバやバッチ処理では、起動時に解決した接続先情報をプロセス内で保持し続けることがあります。

その場合、DNSレコードを変更しても、アプリケーションが再起動されるまで新しい接続先を見に行かないことがあります。

逆に、TTL経過後に再解決された瞬間に、今まで見えていた接続先と別の接続先へ向かい、初めて問題が出ることもあります。

PoCでは、切替直後だけでなく、TTL経過後、キャッシュクリア後、アプリ再起動後、接続プール再作成後の挙動まで確認しておく必要があります。

DNSは、切替直後に疎通できればよいわけではありません。

TTLが切れた後、キャッシュが消えた後、アプリが再接続した後に、同じように業務が継続できるかを見る必要があります。

RDS Multi-AZも「切り替われば終わり」ではない

RDSがフェイルオーバーして待機系へ切り替わった場合、DBとしては復旧していても、Web/APサーバとのAZ配置が変わることがあります。

Web/APはAZ-A中心に残り、RDSのプライマリだけAZ-Bへ切り替わると、Web/APからDBへの通信がAZまたぎになります。

実務では、切替直後は一時的な縮退状態として許容し、業務影響を見ながらフェイルバックする方針を取ることもあります。

また、DBがフェイルオーバーしても、アプリケーション側が正しく再接続できるとは限りません。

コネクションプールが古い接続を保持したままになる。
接続リトライの回数や間隔が足りない。
DNS再解決が走らない。
一時的な接続断をアプリが異常終了として扱う。

このような場合、RDSとしては復旧していても、アプリケーションは接続エラーを出し続けることがあります。

PoCや障害試験では、DBの切替だけでなく、アプリ側の再接続、リトライ、コネクションプールの挙動まで確認する必要があります。

ここで重要なのは、切り替わるかどうかではありません。

切り替わった後の配置で、画面応答、バッチ処理、帳票処理、データ転送量、運用手順に問題が出ないかを確認することです。

PoCで見るべき観点

• 障害時に、どの単位で、どこまで自動復旧するのか
• そのEC2は、自動で作り直してよいサーバなのか
• Auto Scaling後に、ホスト名、DNS登録、OS設定、監視エージェント、ミドルウェア起動まで再現できるか
• cloud-initやUser Dataの実行タイミングが、サービス起動順序と矛盾していないか
• ロードバランサーのヘルスチェック、切り離し、復帰の条件は明確か
• 保守作業としてEC2を停止した場合と、障害として停止した場合を、Auto Scalingがどう扱うか
• 保守時にスケーリング停止、期待台数変更、インスタンス保護などの運用手順が必要か
• 別AZ起動後に、OS内の静的ルート、永続ルート、NIC設定、メトリック設定が移行後の構成と合っているか
• 参照元ごとに、どのDNSサーバを経由して名前解決しているか
• DNS問い合わせの遅延、リトライ、再帰問い合わせがアプリケーション応答やタイムアウトに影響しないか
• Route 53 ResolverのInbound/Outbound endpoint、転送ルールがハイブリッド構成に合っているか
• EC2再作成、AZ変更、切替後に、DNSやRoute 53のレコード変更が必要になるか
• DNSキャッシュやTTL経過後に、参照元から再度正しく名前解決できるか
• OS、JVM、ミドルウェア、接続プール、プロキシが独自に名前解決結果を保持していないか
• RDSがフェイルオーバーした後、Web/APとのAZ配置や通信経路に問題が出ないか
• DB切替後に、アプリ側の再接続、リトライ、コネクションプールの再作成が正しく行われるか
• 縮退状態を許容するのか、フェイルバックするのか
• 復旧後に何を確認すれば業務再開と言えるのか

可用性は、サーバが再起動することではありません。

自動復旧できるものと、手動で戻すべきものを切り分けること。
切り替わった後の配置、性能、縮退運用、フェイルバック方針まで確認すること。
そして、業務が再開できる状態を説明できること。

ここまで見て、初めてクラウドリフトにおける可用性設計です。

2. 性能・キャパシティ

動いたことと、業務時間内に処理できることは違う

性能面において最も危険なのは、単純な正常系テストで『動いた』と満足してしまうことです。

EC2上でアプリが起動した。
DBに接続できた。
バッチが1回流れた。
ファイルを読み書きできた。

しかし、それだけでは性能要件を満たしたことにはなりません。

現場では、日次の夜間バッチだけが重いとは限りません。

週次処理、月次処理、締め処理、大量帳票、ファイル集計、洗い替え処理など、特定日だけ極端に重くなる処理があります。

通常日の軽いデータや単発の小さな検証だけで判断すると危険です。

性能が出るかどうかは、インスタンスタイプ選定とも切り離せません。

オンプレからクラウドへ移行する場合、既存サーバのCPU、メモリ、ディスクI/O、ネットワーク使用量をそのまま見ても、クラウド上の適切なインスタンスタイプが自動的に決まるわけではありません。

オンプレ環境では、CPU性能をSPECintや独自の換算指標で見ていたとしても、AWS上ではインスタンスタイプごとにvCPU数、メモリ量、ネットワーク性能、EBS帯域、CPU世代、ファミリー特性が異なります。

そのため、単純に「CPUが何個あるからこのタイプ」「メモリが何GBあるからこのタイプ」と決めるのは危険です。

バッチサーバのように、大量データを読み込み、ソートし、一時領域を使い、一定時間内にまとめて処理するサーバでは、CPUだけでなくメモリやI/Oが効いてくることがあります。

一方で、Web/APサーバのように、1件あたりの処理は軽くても、多数のリクエストやトランザクションをさばくサーバでは、vCPU数、同時実行性能、スレッド数、コネクションプールの設計が効いてくることがあります。

CPUが足りないのか。
メモリが足りないのか。
I/Oが詰まっているのか。
ネットワークが詰まっているのか。
同時実行数に対してスレッドやコネクションプールが足りないのか。

ここを見ずにインスタンスタイプだけを上げると、コストだけが増えて、性能問題が解消しないことがあります。

また、拡張性を残すことも重要です。

最初からそのファミリーの最大サイズ、または上限に近いタイプを選んでしまうと、負荷が増えたときに同じ考え方でスケールアップできません。

「性能が足りなければタイプを上げればよい」と考えていたのに、すでに上限に近いタイプを選んでいたため、設計変更、構成変更、スケールアウト方式の見直しが必要になることがあります。

PoCでは、今の負荷を処理できるかだけでなく、将来の増加分をどこまで同じ構成で吸収できるかも確認しておく必要があります。

同じファミリー内のサイズ変更で対応できるのか。
メモリ最適化、コンピューティング最適化、汎用系など、ファミリー選定から見直す必要があるのか。
スケールアップではなく、スケールアウトや処理分散を考えるべきなのか。

この判断は、性能設計であり、同時にコスト見積やキャパシティ管理の前提にもなります。

PoCで見るべきなのは、単に「このタイプで動いたか」ではありません。

このタイプで本番負荷に耐えられるのか。
将来の増加に対して拡張余地があるのか。
同じファミリー内で上げればよいのか、ファミリー選定から見直すべきなのか。
見積、性能試験計画、キャパシティ管理の前提として説明できるのか。

ここまで確認しないと、設計段階でインスタンスタイプを決められず、試験やサービス開始後に「タイプを変えれば済むと思っていたのに、そう簡単ではなかった」という状態になります。

EFSを使う場合、標準的なバースト前提では、重いバッチ処理を安定して処理できないことがあります。

EFSのバーストスループットは、クレジットの蓄積と消費で動きます。

軽い処理を続けている間はクレジットが回復しますが、重いバッチを集中的に流すとクレジットを一気に使い切り、ベースラインスループットまで落ちることがあります。

また、EFSの性能を見るときは、単純な転送量だけでは不十分です。

読み取り中心なのか、書き込み中心なのか。
大きなファイルを少数扱うのか、小さなファイルを大量に扱うのか。
`ls`、`find`、属性確認、ディレクトリ走査のようなメタデータ操作が多いのか。

この違いによって、同じデータ量でもボトルネックの出方は変わります。

特に小さなファイルが大量にあり、バッチ処理でディレクトリを再帰的に走査するような場合、データ転送量よりもメタデータ操作が効いてくることがあります。

そのため、通常日のPoCでは問題なかったのに、月次締め処理や大量ファイル処理だけ極端に遅い、という現象が起こります。

バッチ処理がEFSから大量のファイルを読み込み、CPUとI/Oを同時に使い切るような処理であれば、エラスティックスループットやプロビジョンドスループットを検討する必要があります。

重要なのは、単に性能が出るかどうかではありません。

最も重い処理を、最も重い条件で流したときに、どのスループットモードが必要なのか。
一時的に性能を上げる運用が可能なのか。
処理後に下げられるのか。
変更に制約はないのか。
戻し忘れた場合にどれだけ課金されるのか。
見積上、その運用を説明できるのか。

ここまで含めて検証する必要があります。

もし、インフラ側の調整だけでは性能要件を満たせない場合は、バッチ処理の分割、コミット単位の見直し、ソート処理の方式、DBアクセス方式、ログ出力方式など、アプリケーションや処理方式の見直しに波及します。

性能PoCの最大のポイントは、軽い処理で「動いた」と確認することではありません。

最も重い処理を、最も重い条件で流し、必要な性能、構成、課金、運用手順、そしてアプリ改修要否まで判断することです。

PoCで見るべき観点

• 週次・月次・締め処理など最も重いバッチを本番相当データで流せるか
• 既存サーバのCPU、メモリ、I/O、ネットワーク使用量をもとに、アプリケーション特性に合ったインスタンスタイプやファミリーを選べているか
• バッチサーバ、Web/APサーバ、DBサーバなど、役割ごとにvCPU、メモリ、I/O、ネットワークの見方を分けているか
• 最初から最大サイズや上限に近いタイプを選んでおらず、将来のスケールアップ余地を残しているか
• 同じファミリー内のサイズ変更で足りるのか、ファミリー変更やスケールアウト設計まで必要になるのか
• EFS、EBS、DB、ネットワーク、EC2インスタンスのどこがボトルネックになるか
• EFSを使う場合、バースト、エラスティック、プロビジョンドのどのスループットモードが必要か
• 一時的に性能を上げ、処理後に下げる運用が現実的にできるか
• インフラ側の性能調整で足りない場合、アプリ改修や処理方式変更が必要になるか
• 読み取り/書き込み比率、大量小ファイル、`ls`/`find`などのメタデータ操作が性能ボトルネックにならないか

性能は、CPUやメモリの数字だけで決まるものではありません。

業務処理が、必要な時間内に、必要な量を、安定して処理できるか。
そして、その性能を必要なときだけ使い、不要なときにはコストを抑える運用ができるか。

ここまで見て、初めてクラウドリフトにおける性能設計です。

3. ストレージ

共有できることと、業務で使えることは違う

ストレージは、クラウドリフトPoCで大きな手戻りになりやすい領域です。

「Lambdaで処理を起動できた」

「IAMロールでS3にアクセスできた」

「RDSに接続できた」

「EC2上で既存アプリが起動した」

「CloudWatch Logsにログが出た」

クラウドリフトPoCでは、こうした確認を行うことがあります。

もちろん、これらは必要です。

第2部・前編では、可用性、性能、ストレージ、バックアップ、運用・監視の観点から、「動いた」ことと「業務で使える」ことは違う、という話を整理しました。

後編で扱うのは、その続きです。

クラウド上で処理を起動できた。
権限を付ければアクセスできた。
製品はインストールできた。
DBには接続できた。
見積上はオンプレより安く見えた。

しかし、実際の運用・保守・統制・コスト管理に入ると、そこで初めて問題が見えることがあります。

ジョブの依存関係をどう管理するのか。
異常終了後にどこから再実行するのか。
EC2が再作成されたとき、ジョブ実行対象として正しく認識されるのか。
IAM権限は最小権限になっているのか。
本番作業の一時権限や証跡は残るのか。
オンプレで使っていた製品ライセンスは、AWS上でも同じ条件で使えるのか。
RDS for Oracleにした場合、既存のDBA運用はそのまま成立するのか。
RHELで使っていたOS設定やスクリプトは、Amazon Linuxでも同じように動くのか。
性能PoC前に、Reserved InstancesやSavings Plansを前提に見積を固めてよいのか。

これらは、AWSサービスを知っているだけでは整理できません。

既存業務の処理方式、ジョブ運用、権限設計、DB運用、ライセンス条件、保守手順、コスト管理を、クラウド上の構成にどう接続するかという話です。

PoCは、AWSサービスが使えるかを確認する作業ではありません。

既存業務の運用方式が、クラウド上でも成立するかを確認する作業です。

第2部・後編では、クラウドリフトPoCで見落とすと後工程で手戻りになりやすい、残りの5項目を整理します。

６.ジョブ管理・アプリ配布
７.セキュリティ・アクセス管理
８.ライセンス・製品サポート
９.DB・OS・ミドルウェア互換性
１０.コスト・キャパシティ管理

焦点は、クラウド上で「動いた」後に、実際の運用・保守・統制・コスト管理で使えるかです。

PoC観点を強化するきっかけになった個別事例

以下は、クラウドリフトPoCの観点を見直すきっかけになった個別事例です。

本記事では、これらの個別事例に加え、PoCで事前に潰すべき設計論点も含めて、クラウドリフトPoCで見るべきリスクを整理しています。

個別事象そのものを詳しく扱うのではなく、そこからどのようなPoC観点を抽出すべきかに焦点を当てています。

【AWS】別AZで起動したWindowsが通信不能に｜原因はVPCではなく「OS内のルート情報」だった

CloudWatch Logsのログエクスポートが失敗した話｜「ジョブは動く」と「運用で回る」は別物

バックアップ設定の「5日保存」は、5営業日分とは限らない｜AWS Backupの保持期間から考える、詳細設計の落とし穴

EBSは増やせても、簡単には減らせない｜RHEL環境で見落とした「容量縮小＝ディスク移行」という現実

S3バケットにあるのに取得できない｜クロスアカウント構成で見落とした「オブジェクト所有者」の罠

RHELで使えた設定方法が、Amazon Linuxでは使えなかった｜MTU設定に見る、OS差分と永続化確認の落とし穴

EBSは見えているのにマウントできない？｜AMIコピーで起きた落とし穴

AMIからRHELインスタンスを起動したらSSHログインできなくなった｜cloud-initが上書きする設定を知らないと、復旧以前に入れなくなる

EC2を止めただけなのに再作成？Auto Scaling運用の落とし穴｜クラウドの自動化は、作業者の意図までは読んでくれない

なお、後編では購入者特典として、10項目全体を整理したExcel資料「クラウドリフトPoC設計リスクチェックリスト」も添付します。

PoC計画、設計レビュー、リスク洗い出しのたたき台として使えるようにしています。

6. ジョブ管理・アプリ配布

Lambdaで起動できることと、ジョブ管理を置き換えられることは違う

クラウドリフトでは、ジョブ管理が軽く見られることがあります。

EventBridgeでスケジュール実行できる。
Lambdaで処理を起動できる。
Step Functionsで処理の流れを組める。
Systems Managerでコマンドを実行できる。
ECSやBatchでコンテナ処理を流せる。

確かに、クラウド上で処理を起動する手段は多くあります。

しかし、既存システムのジョブ管理は、単なる定時実行ではないことがあります。

たとえば、JP1/AJS3のようなジョブ管理製品を使っている環境では、ジョブネット、先行後続関係、異常時停止、再実行、保留、手動起動、カレンダー、休日、締め日、排他制御、通知、実行証跡、運用手順が一体になっていることがあります。

ここでJP1/AJS3を挙げているのは、特定製品の使い方を説明したいからではありません。

既存の業務ジョブでは、ジョブ管理製品が単なるスケジューラではなく、業務運用そのものを支えていることがある、という話です。

日次処理が終わったら、後続の集計処理を流す。
月末だけ別の処理を追加する。
締め日が休日なら前営業日にずらす。
異常終了したら、特定のリカバリポイントから再実行する。
二重起動を防ぐ。
一部の処理だけ保留し、運用判断後に再開する。
失敗時には監視へ通知し、運用手順書に沿って復旧する。

こうした制御まで含めて、業務ジョブは成立しています。

そのため、PoCで見るべきなのは、「AWS上で処理を起動できるか」ではありません。

既存ジョブネットの依存関係、異常時の止まり方、再実行単位、通知、証跡、運用手順まで含めて、クラウド上でも業務として回せるかです。

リトライと再実行は同じではない

クラウドサービスでは、失敗時のリトライを簡単に設定できることがあります。

しかし、リトライと業務上の再実行は同じではありません。

一時的な通信エラーで、同じ処理をもう一度実行すればよい場合もあります。

一方で、途中までデータを更新した後に失敗した場合、単純にリトライすると、二重更新、二重送信、二重集計になることがあります。

たとえば、ファイルを取り込んだ後にDB更新で失敗した場合。
DB更新後に帳票出力で失敗した場合。
外部システムへ送信した後にステータス更新で失敗した場合。
前半の処理で一時ファイルを作成し、後半の処理でそれを後続システムへ渡す場合。

このような処理では、どこまで完了しているのかを確認し、どの地点から再開するのかを決める必要があります。

ジョブ管理製品では、ジョブ単位、ジョブネット単位、ステップ単位で、再実行や保留の考え方が整理されていることがあります。

これをクラウド側のリトライ設定だけで置き換えると、業務データの整合性を壊す可能性があります。

PoCでは、異常終了を意図的に発生させ、どこで止まるのか、どこから再実行できるのか、二重起動や二重更新を防げるのかを確認する必要があります。

ここを確認しないまま「Lambdaで起動できた」「Step Functionsで流れを組めた」と判断すると、構築後のジョブ設計や運用設計で手戻りになります。

ジョブカレンダーは、単なる時刻指定ではない

ジョブ管理で見落としやすいのが、カレンダーです。

毎日2時に起動する。
毎週月曜に起動する。
毎月1日に起動する。

この程度であれば、クラウド側のスケジュール機能でも表現しやすいかもしれません。

しかし、業務システムのジョブは、単純な時刻指定だけで動いているとは限りません。

営業日だけ動かす。
休日なら前営業日に寄せる。
月末営業日に締め処理を動かす。
特定の祝日だけ別処理にする。
年末年始だけ停止する。
決算月だけ処理順序を変える。

こうした運用が、既存のジョブカレンダーや運用手順に組み込まれていることがあります。

クラウド側でスケジュール実行できることと、既存の業務カレンダーをそのまま表現できることは違います。

特に、月末、締め日、休日、営業日判定が絡む処理は、単純なcron式や固定スケジュールだけでは表現しきれないことがあります。

PoCでは、通常日の起動確認だけでなく、月末、休日、締め日、年末年始など、業務上意味のある日付条件でジョブが期待どおりに動くかを確認する必要があります。

ジョブ実行サーバーは、クラウド上で同じ名前とは限らない

前編の可用性・信頼性でも触れたAuto Scaling後の登録問題は、ジョブ管理にも直結します。

オンプレでは、ジョブ管理マネージャーとエージェントの関係が、固定されたホスト名やIPアドレスを前提に設計されていることがあります。

ジョブ管理マネージャーは、特定のジョブを、特定のジョブ実行サーバーに投入する。
そのジョブ実行サーバーには、エージェントが導入されている。
ホスト名、IPアドレス、エージェント名、監視対象名が、長期間変わらない前提で運用されている。

オンプレでは、この前提が自然に成立していたかもしれません。

しかし、AWSでは、Auto Scalingや復旧方式によってEC2が入れ替わることがあります。

AMIから新しいEC2を作る。
User Dataやcloud-initで初期設定を流す。
ホスト名を付与する。
DNSに登録する。
監視エージェントを起動する。
ジョブ管理エージェントを起動する。

ここで順序や登録内容がずれると、EC2は起動しているのに、ジョブ実行対象として正しく認識されないことがあります。

ホスト名が期待どおりに戻っていない。
DNS登録が更新されていない。
ジョブ管理エージェントが古い名前で登録されている。
監視対象名とジョブ実行対象名がずれている。
Auto Scalingで作られたEC2が、ジョブ投入先として登録されていない。

この状態では、サーバーは動いていても、業務ジョブは流せません。

クラウドでは、EC2が起動すれば終わりではありません。

ホスト名、DNS登録、監視対象、ジョブ実行対象、エージェント登録まで含めて、業務システムの構成要素として戻っているかを見る必要があります。

オンプレ側ジョブ管理とAWS側処理が混在する期間もある

クラウドリフトでは、すべてのジョブを一度にAWSネイティブへ置き換えられるとは限りません。

オンプレ側のジョブ管理製品から、AWS上のEC2やLambdaを起動する。
AWS側の処理完了を、オンプレ側の後続ジョブへ返す。
一部のバッチは既存ジョブ管理に残し、一部の処理だけStep FunctionsやEventBridgeへ寄せる。

このような混在期間が発生することがあります。

このとき問題になるのは、単なる通信ではありません。

ジョブの完了をどう判定するのか。
異常終了コードをどう返すのか。
タイムアウトをどちらで管理するのか。
AWS側でリトライした結果を、オンプレ側ジョブ管理へどう伝えるのか。
オンプレ側で再実行した場合、AWS側の処理が二重に動かないか。
ネットワーク断や認証エラーを、業務異常として扱うのか、基盤異常として扱うのか。

こうした運用上の境界を決めないままPoCを終えると、後工程でジョブ設計と運用設計が止まります。

PoCでは、オンプレ側ジョブ管理とAWS側処理が混在する前提で、起動、完了判定、異常通知、再実行、タイムアウト、証跡を確認する必要があります。

アプリ配布もPoC対象になる

ジョブ管理と合わせて、アプリケーション配布も確認が必要です。

オンプレでは、配布専用ソフト、共有フォルダ、運用スクリプト、手順書を使って、アプリケーション資材、設定ファイル、バッチ、帳票定義、ジョブ定義を各サーバーへ配布していることがあります。

クラウド移行後に、これをどう扱うのかを決めなければなりません。

AMIに含めるのか。
起動時にS3から取得するのか。
User Dataやcloud-initで展開するのか。
CodeDeployやSystems Managerを使うのか。
既存の配布ツールをそのまま使うのか。
一部でCI/CD基盤を使う場合は、CodePipeline、CodeBuild、GitHub Actionsなどとどう接続するのか。
コンテナ化を伴う移行であれば、ECR上のイメージタグやデプロイ対象の世代をどう管理するのか。
ジョブ定義や設定ファイルの世代管理をどこで行うのか。

特にAuto ScalingやEC2再作成を使う場合、あとから作られたEC2にも、正しい資材が反映される必要があります。

既存EC2には最新版が配布されている。
しかし、新しく作られたEC2には古い資材しかない。
設定ファイルだけ世代が違う。
バッチは新しいが、ジョブ定義が古い。
ロールバックしたつもりでも、一部のEC2だけ前の状態に戻っていない。

このような状態になると、クラウド上ではサーバーが起動していても、業務処理としては正しく動きません。

アプリ配布は、単なるリリース作業ではありません。

クラウドリフトでは、復旧方式、Auto Scaling、ジョブ実行対象、監視対象、ロールバック手順とつながる設計論点です。

PoCでは、初回配布だけでなく、更新、切り戻し、EC2再作成後の自動反映、世代管理、差分確認まで見る必要があります。

PoCで見るべき観点

既存ジョブの踏襲と代替の整理

単純な定時実行なのか、ジョブネット、依存関係、異常時停止、再実行、保留まで必要なのか

EventBridge、Lambda、Step Functions、Systems Manager、ECS、Batchで代替できる処理と、既存ジョブ管理製品に残す処理を切り分けているか

異常系・カレンダー運用の担保

リトライと業務上の再実行を区別しているか

異常終了時に、どこで止まり、どこから再実行できるか

二重起動、二重更新、二重送信を防ぐ仕組みがあるか

ジョブカレンダー、休日、月末、締め日、営業日判定をどう扱うか

動的環境・ハイブリッド運用の壁

オンプレ側ジョブ管理とAWS側処理が混在する期間の起動、完了判定、異常通知、タイムアウトを整理しているか

Auto ScalingやEC2再作成後に、ホスト名、DNS登録、監視対象、ジョブ実行対象、エージェント登録が正しく戻るか

リリースと資材統制

アプリケーション資材、設定ファイル、バッチ、帳票定義、ジョブ定義をどの方式で配布するか

新規起動したEC2にも、最新の資材と設定が自動で反映されるか

リリース失敗時に、どの単位でロールバックできるか

ジョブ管理やアプリ配布は、クラウド化で自動的に整理されるものではありません。

AWS上で処理を起動できることと、既存業務のジョブ運用を置き換えられることは違います。

ジョブの依存関係、異常時の再実行、カレンダー、実行対象、配布方式、ロールバックまで含めて確認して、初めてクラウドリフトPoCとして意味があります。

ここまで見たジョブ管理・アプリ配布は、運用方式の問題です。

ただし、クラウドリフトで後工程に効いてくる論点は、これだけではありません。

権限設計、クロスアカウントアクセス、ライセンス条件、DB・OS・ミドルウェアの互換性、そしてコスト管理も、PoC段階で見ておかないと設計後半で手戻りになります。

7. セキュリティ・アクセス管理

IAMロールでアクセスできることと、業務上安全に統制できることは違う

クラウドリフトでは、セキュリティ設計も後回しにされがちです。

EC2からS3にアクセスできた。
LambdaからRDSに接続できた。
IAMロールを付けたら処理が動いた。
踏み台経由でサーバーにログインできた。
KMSで暗号化したデータを復号できた。

こうした確認は必要です。

しかし、それだけでは、業務システムとして安全に運用できるとは言えません。

クラウドでは、権限を付ければ多くのことができます。

だからこそ、誰に、どの権限を、どの範囲で、どの期間だけ与えるのかを設計しなければなりません。

はじめに

「Vモデルってウォーターフォール時代の話でしょ？」

こう話すエンジニアに、現場でたびたび出会います。アジャイルやスクラムが当たり前になった今、Vモデルは時代遅れだと思われがちです。しかし、これは大きな誤解です。

Vモデルは特定の開発手法の話ではありません。要件定義や設計で決めたことを、対応するテストで確認するという、品質保証の基本的な考え方です。この考え方を持てているかどうかが、システム開発の品質を大きく左右します。

この記事では、システム基盤開発を例にとりながら、Vモデルの本質をテスト工程の視点から解説します。教科書的な図の説明ではなく、現場でどう使うかに焦点を当てています。

Vモデルとは何か

Vモデルとは、開発工程とテスト工程を対応づけて考えるモデルです。

名前の由来は見た目の形にあります。左側に開発工程が並び、右側にテスト工程が並ぶ。その形がアルファベットの「V」に見えることから、Vモデルと呼ばれています。

ただし、大事なのは形ではありません。本質は次の一文に集約されます。

「ある工程で決めたことは、対応するテスト工程で確認する」

このイメージを図にすると、次のようになります。

ただし、工程の名称や対応関係はプロジェクトごとに異なります。ここで示すのはあくまで一例です。その前提で、システム基盤の開発に当てはめると次のような対応関係になります。

• 環境定義（実際の設定値・パラメータ）→ 単体テスト
• 詳細設計（製品ごとの設計内容）→ 結合テスト1（基盤に閉じた接続確認）
• 基本設計（処理方式・システム構成・採用製品）→ 結合テスト2（プロトタイプアプリを用いた確認）
• 要件定義・運用設計（可用性・性能・セキュリティ・運用要件など）
  → システムテスト・運用テスト・受入テスト

結合テストを2段階に分けているのは、確認の観点が異なるからであり、教科書的なVモデルをそのまま当てはめたものではなく、基盤開発の成果物粒度に合わせた整理です。

結合テスト1は基盤に閉じた機器間・システム間の接続確認です。結合テスト2はプロトタイプの業務アプリケーションを使い、基本設計で定めた処理方式や構成が実際に機能するかを確認します。基本設計の内容を検証するには、アプリが一部でも動く状態でないと確認できないため、この段階にアプリが入ってきます。

システムテストは「総合テスト」とも呼ばれ、基盤とアプリケーションが合流して行う最終的な全体検証です。プロジェクトによっては、運用テストや受入テストがシステムテストの一部として扱われることもあれば、システムテスト後の別工程として実施されることもあります。なお、運用テストは手順・承認フローの確認、受入テストはお客様がシステムを本番として受け入れるかの判断が目的であり、両者は異なります。

この対応関係が崩れると、品質の抜け漏れが発生します。「要件定義で決めたのにテストしていない」「テストしたが根拠となる設計が存在しない」。そういう状況を防ぐための考え方が、Vモデルです。

なぜ段階的なテストが必要なのか

テストを「最後に一度まとめてやればいい」と思っている人が、現場に一定数います。完成したシステムに対して動作確認をすれば十分、という考え方です。

しかし、これには重大なリスクがあります。

システムは複数の要素の集合で成り立っています。クライアント端末、ネットワーク、ネットワーク機器、サーバ、ストレージ。これらが組み合わさって、一つのシステムとして動作します。

この状態で一気にテストしようとすると、何が起きるでしょうか。

問題1：原因の特定に時間がかかる

想定どおりに動作しなかった場合、どこが悪いのかを特定するのが困難になります。ネットワークの設定ミスなのか、サーバのパラメータが間違っているのか、アプリケーションの処理が悪いのか。複数の要素が絡み合うため、原因の切り分けに膨大な時間がかかります。

本来であれば、単体テストで「このサーバの設定値は正しいか」を確認し、結合テストで「このサーバとあのサーバは正常に通信できるか」を確認する。問題が発生したときに、どの段階のどの要素が原因かを絞り込みやすい状態を作っておくことが重要です。

問題2：たまたま動いて終わってしまう

逆のパターンも怖いです。本来は網羅すべき条件を確認していないのに、たまたまテストが通ってしまうことがあります。

例えば、単体・結合テストでフェイルオーバーの検証をスキップし、システムテストでも正常系しか確認しなかったとします。システムが正常に動いているうちは問題が表面化しません。しかし本番で障害が発生したとき、初めて「フェイルオーバーが機能しない」と発覚する。これは最悪のシナリオです。

単体テスト、結合テスト、システムテストと段階を踏むことで、確認すべき項目を体系的に洗い出すことができます。

問題3：テスト項目が後から書けない

設計内容が曖昧なまま進むと、テスト工程で「何を確認すれば合格なのか」がわからなくなります。

「バックアップを取得すること」とだけ書かれていた場合、何をテストすればよいでしょうか。取得対象は何か。何時に取得するのか。何世代保持するのか。何時間以内に終わる必要があるのか。これが決まっていなければ、テスト項目に落とせません。

テスト項目は、テスト工程で突然生まれるものではありません。要件定義や設計で決めた内容から導き出されるものです。

そして、本来その工程で検出すべきバグが後続工程で発見されることを「すり抜け」と呼びます。

これは単なる発見タイミングのずれではありません。単体テストで見つかるべき設定ミスが結合テストやシステムテストで出てきた場合、「他にも同じ観点でのすり抜けがあるのではないか」という疑義が生じます。結果として、同じ観点の横並び確認が必要になり、場合によっては設計書、設定値、テスト項目の見直しが全体に波及します。

品質報告の場では、T型マトリックスという管理表が使われることがあります。

一般的には、縦軸に「実際に不具合を発見した工程」、横軸に「本来その不具合を摘出すべき工程」を置き、不具合がどの工程で検出され、どこですり抜けたかを可視化するものです。

対角線上に並ぶものは、本来の工程で適切に検出できた不具合です。一方、後続工程側にずれて計上されるものは、前工程で摘出できずに流出した不具合、つまりすり抜けを意味します。

たとえば、本来は単体テストで摘出すべき設定ミスが、結合テストやシステムテストで発見された場合、それは後工程へのすり抜けとして扱われます。このマトリックスを見れば、どの工程で検出力が弱いのか、どの工程で不具合が後ろ倒しになっているのかが一目でわかります。

「単体テストで検出すべき不具合が、なぜ結合テストやシステムテストまで残っていたのか」。その問いに答えられるかどうかが、テスト設計や品質分析の力を問われるポイントです。

テスト工程を段階的に設計し、各工程で検出すべき項目を明確にしておくことは、すり抜けリスクを下げるための最も基本的な手立てです。すり抜けの詳細なメカニズムと対策については、テスト編で改めて解説します。

バックアップ4時間以内という要件を例に考える

ここで、具体的な例を見てみましょう。お客様と次のような非機能要件を合意したとします。

DBおよびログのバックアップ時間は4時間以内とする

一見すると、シンプルな要件に見えます。しかし、この要件を実現し、テストで確認するためには、複数の工程にわたる設計が必要です。

要件定義の段階

この段階では「4時間以内」という目標を合意します。具体的な方式はまだ決まっていません。重要なのは、この数字が「何の性能要件か」を明確にしておくことです。性能・拡張性の要件であり、後工程のシステムテストで確認する項目です。

基本設計の段階

要件を実現するための方式を決めます。

• バックアップ対象は何か（DBのみか、ログも含むか）
• 取得先はどこか（サーバ内ディスクか、共有ストレージか、クラウドストレージか）
• 取得経路はどうするか（専用VLANを用意するか、本番ネットワークを使うか）
• 本番処理と同じ時間帯に実行しても問題ないか

これらを決めることで、システム構成と採用製品が固まります。

詳細設計の段階

採用する製品やミドルウェアを前提に、具体的な処理内容を決めます。

• バックアップジョブをどう構成するか
• どの順番で取得するか
• 圧縮・暗号化はするか
• エラー時の再実行ロジックはどうするか
• 失敗時の通知先はどこか

環境定義の段階

実際のパラメータを確定します。

• バックアップ対象のフォルダパス・ファイルパス
• 保存先のパス
• 実行スケジュール
• 保持世代数
• タイムアウト値

テストの段階

ここまで設計が積み上がって初めて、テスト項目が具体的に書けます。

• 本当に4時間以内に完了するか
• 対象ファイルに漏れはないか
• バックアップ失敗時にアラートが上がるか
• リストアできるか
• 本番相当のデータ量でも時間内に終わるか

Vモデルを理解していないと、「要件に4時間以内と書いてある」「バックアップジョブは作った」「テストで何となく動いた」で終わってしまいます。しかし現場では、それでは足りません。

ここまでは、Vモデルの基本的な考え方を整理しました。
以降では、現場でこの考え方をどう使うか、工程ごとの留意点、よくある失敗パターン、運用テストの位置づけまで踏み込んで整理します。