はじめに｜「基盤はクラウドに任せれば安心」という誤解
クラウドリフトの提案局面で、必ずといっていいほど出てくる言葉がある。
「ハード障害はクラウド側が吸収してくれるので、運用負荷が下がります」
間違いではない。でも、完全に正しいわけでもない。
クラウド環境で運用経験の知見がないプロジェクトでは、この言葉の重要な前提が抜けている。
「吸収しきれなかった副作用は、ゲスト側に漏れてくることがある」
これは理論の話ではない。実際に起きた話だ。
何が起きたか｜ストレージ障害が引き起こした連鎖
あるクラウド環境（OCI/Exadata構成）で、ストレージサーバーに物理障害が発生した。
クラウドベンダーからの通知はこうだった。
「可用性による障害部分への対応なので、実害なし」
たしかに、DBは守られていた。冗長化が機能し、ストレージ障害そのものはクラウド側で吸収された。
しかし現場では、まったく別の問題が起きていた。
ストレージ障害の影響で、DBサーバー上のASM（Oracle自動ストレージ管理）がアラートを大量に出力し始めた。そのエラーがイベントDBファイル（IMEvent[0-1].dat）に次々と書き込まれ、ファイルが異常肥大化。やがてDBサーバーの/var領域が枯渇した。
今回の環境では、このイベントDBファイルが/var配下に配置されていた。Oracle関連のログや診断ファイルが常に/varに出るという意味ではない。重要なのは、DBデータ領域ではなく、OS側の管理領域に障害時ログの副作用が流れ込んだ点だ。
/varが枯渇すると、OSやミドルウェアはログ出力、一時ファイル作成、状態管理ファイルの更新に失敗し始める。今回の環境では、その影響でジョブネットの新規実行が不能になった。
整理するとこうなる。
ストレージ物理障害（IaaS層）
↓
ASMアラート大量出力
↓
IMEventファイル肥大化
↓
/var領域枯渇（ゲストOS層）
↓
ジョブネット停止（アプリ層）
クラウドベンダーが言う「実害なし」は、IaaS層の視点から見た見解でしかない。
しかしゲストOS層・アプリ層から見れば、確実に実害が発生していた。
なぜこうなるのか｜責任境界の構造的な問題
この種の問題が起きる背景には、クラウドサービスの**責任分担モデル（Shared Responsibility Model）**の曖昧さがある。
一般的に、IaaS型クラウドの責任分担はこう説明される。
この図式でいえば、「ストレージ障害はベンダー責任、/var枯渇は利用者責任」となる。
でも、障害の波及経路はその境界線を無視して動く。
ベンダーが吸収した障害の「余波」が、ゲストOS側に流れ込んでくる。ログが爆発的に増える。一時ファイルが詰まる。ジョブが止まる。
そして重要な根拠がある。Oracleの公式ドキュメントがこれを裏付けている。
Exadata Cloud環境のドキュメントには、ログ・診断ファイルはすべて自動でアーカイブ・パージされるわけではなく、ファイルストレージが枯渇しないよう管理することが重要な運用タスクだと明記されている。cleandblogsスクリプトは日次cronで実行されるが、それでも「対象外のログがないか」「保持期間は妥当か」「実行に失敗していないか」を利用者側で確認する必要がある。
つまり、ログ・診断ファイルの管理は利用者の運用タスクとして残ると、Oracle自身が設計上明確にしている。
少なくとも、ログ・診断ファイルが増え続ける可能性と、その管理が利用者側の運用タスクとして残ることは、Oracle公式ドキュメントからも読み取れる。今回のように障害を契機としてログが急増するケースでは、この責任境界がそのまま業務影響につながる。
参考：Oracle公式ドキュメント
Managing the Log and Diagnostic Files on Oracle Exadata Database Service on Dedicated Infrastructure
AWSとの比較で見えてくること
正確に言うと、「AWS全般ではこの問題が起きない」というわけではない。EC2上にOracleを載せていれば、ゲストOSの/varが枯渇するリスクは当然ある。EC2はIaaSであり、OS以上の管理責任は利用者側に残るからだ。
比較として適切なのは、RDS for OracleのようなマネージドDBだ。RDS for Oracleでは、アラートログや診断ファイルをRDSコンソール・API経由で確認でき、CloudWatch Logsへ発行する仕組みも用意されている。ログ管理がホストOSの直接操作ではなく、マネージドサービスの管理面に寄せられている。
一方、OCIのExadataはオンプレミスExadataの設計思想を色濃く引き継いでいる。オンプレ時代は「全部自分で管理するのが当たり前」だったから、ログ管理の責任がゲスト側に残る構造になっている。
設計思想の違いと言えばそれまでだが、正直に言うと釈然としない。
障害時にどれだけログが出るかは、利用者側だけでは見積もりにくい。にもかかわらず、「利用者側で管理してください」と整理されるなら、容量設計や監視設計の前提をどこに置くのかが問題になる。
ここに、クラウドリフト案件の難しさがある。
ベンダー側の責任範囲では障害を吸収していても、その副作用がゲストOS側に出るなら、利用者側はそこまで含めて非機能要件に落とさなければならない。この「設計思想のギャップ」こそが、リフト案件における大きな運用リスクだ。
釈然としない部分はある。それでも現実としてそうなっている以上、利用者側が知ったうえで設計に組み込むしかない。それがSIerとして止めないシステムを構築することだと割り切っている。
PoCで見えない理由｜運用設計で見ておくべきポイント
この問題は、通常のPoCでは見えにくい。
DBが起動する。アプリから接続できる。ジョブが一度流れる。監視通知が飛ぶ。
ここまで確認しても、障害時にASM関連ログが急増し、/varを圧迫するかどうかまでは見えない。
だからこそ、クラウドリフトPoCでは「動くか」だけでなく、「異常時にどの領域へ副作用が出るか」まで確認する必要がある。
クラウドリフト後の環境で、この種の問題を防ぐための観点を整理する。
① ログ書き出し先の責任境界を確認する
どのログがゲストOSの領域に書かれるのか。自動パージの対象になっているか。障害時にログが爆発する可能性があるか。設計段階でベンダーに確認する。
特に、次の観点は見ておきたい。
- DBログ、ASMログ、Clusterwareログ、監査ログ、診断ファイルの出力先
- 自動パージ対象と対象外
- パージスクリプトの実行状況
- 実行失敗時の検知方法
- 障害時に急増しやすいログの種類
「ログ削除の仕組みがある」だけでは不十分だ。
それが何を対象にしていて、何を対象にしていないのかまで確認する必要がある。
② /varなどのOS領域に監視アラートを設定する
「ディスク使用率80%」といった閾値アラートは、DBデータ領域だけでなく/varにも設定する。
見落とされやすい領域だが、ここが枯渇するとOSやミドルウェアの動作に影響する。ログ出力、状態管理、一時ファイル作成、ジョブ管理製品の動作などに波及するため、DBデータが守られていても業務影響が発生する。
また、ディスク使用率だけでなく、inode使用率も見るべきだ。ファイルサイズではなくファイル数で詰まるケースもある。
③ 「基盤障害ゼロ＝アプリ影響ゼロ」ではないことをSLAに反映する
ベンダーのSLAは「ハード障害を吸収する」ことを保証するが、「ゲストOS領域への副作用が出ない」ことは保証していない。
この差を発注者・運用担当者と認識合わせしておく必要がある。
ベンダーから「実害なし」と言われても、それはベンダーの責任範囲における見解である。利用者側では、次のような観点で自システムへの影響を確認しなければならない。
- OS領域の使用率
- DB・ASM関連ログの急増
- ジョブネットの起動可否
- アプリケーションログの異常
- 監視製品の通知状況
- バッチ処理の実行状況
「基盤側は正常」と「業務影響がない」は同じではない。
④ 障害時のログ肥大化を想定したディスク容量設計をする
平常時の使用量ベースで/varの容量を決めると、障害時の爆発的なログ出力に対応できない。
通常時には数GBしか使っていなくても、障害時に短時間で急増することがある。特に、基盤側の異常を契機としてミドルウェアが再試行やアラート出力を繰り返す構成では、ログ領域の増加を軽く見てはいけない。
容量設計では、次の観点を含めるべきだ。
- 平常時使用量
- 障害時の増加余地
- 保持期間
- 自動削除の実行周期
- 一時退避先
- 手動削除手順
- 枯渇時の一次対応手順
「クラウドだから物理障害は吸収される」ではなく、「吸収された結果、どこに副作用が出るか」まで設計する必要がある。
まとめ｜「クラウドが守ってくれる」の範囲を正確に理解する
クラウドが物理障害を吸収してくれるのは本当だ。でも、その吸収プロセスで発生した副作用まで面倒を見てくれるとは限らない。
IaaS層で守られた障害が、ゲストOS層・アプリ層に「余波」として到達することがある。
これはクラウドの欠陥ではなく、責任分担モデルの構造的な特性だ。理解して設計に組み込めば防げる。理解せずに「クラウドに任せれば安心」と思い込むと、思わぬところで事故る。
クラウドリフトの設計フェーズで「失敗は構築前に始まっている」という記事でも述べた通り、この問題もまさにそうだ。
運用後に慌てる前に、設計段階で責任境界を明確にしておく。
どのログがどこに出るのか。
どこまでがクラウドベンダーの責任なのか。
どこからが利用者側の運用責任なのか。
障害時にどの領域へ副作用が出るのか。
ここまで見ておくことが、SIerとしての基本的な仕事だと思っている。
本記事は、クラウドリフトPoC設計リスクシリーズの関連コンテンツです。
「PoCで動いた」だけでは本番運用に耐えられない理由を、次に示す10の設計リスクで整理しています。
- 可用性・信頼性
- 性能・キャパシティ
- ストレージ
- バックアップ
- 運用・監視
- ジョブ管理・アプリ配布
- セキュリティ・アクセス管理
- ライセンス・製品サポート
- DB・OS・ミドルウェア互換性
- コスト・キャパシティ管理
コメント