クラウド移行後の運用設計

2026.02.14
クラウド移行後の運用設計

クラウド移行後の運用設計

移行直後にまず固めるべき運用の土台

クラウドは「作って終わり」ではなく「動かし続ける設計」が本番です。最初に決めるのは、SLA/SLO/SLI、責任分界、監視対象の粒度の3点です。SLOは「月間可用性99.9%、p95レイテンシ300ms以下、エラーレート0.5%未満」など、顧客体験に直結する指標で定義します。エラーバジェット(例:99.9%なら月間約43分の障害許容量)を可視化し、消費が速いときは新機能のリリースを一時的に緩める意思決定規則を明文化します。

監視は「ゴールデンシグナル」(レイテンシ、トラフィック、エラー、サチュレーション)を軸に、サービスごとにSLIを持たせます。APIならHTTP 5xx率、キューなら滞留数、バッチなら完了遅延、データパイプラインならデータ鮮度などが対象です。ダッシュボードは「ビジネス視点(受注、課金、MAU)」「アプリ視点(p95/エラー率)」「インフラ視点(CPU/メモリ/IO)」の3層で役割分担し、同一の指標を複数層で重複させないのがノイズ抑制のコツです。

責任分界ではRACIを作ります。例:クラウド基盤(IaaS/PaaS)のパッチはプラットフォーム担当がResponsible、アプリ設定変更は各サービスチームがResponsible、監視ルールの標準化はSREがAccountable。これをオンボーディング資料に組み込み、属人化を防ぎます。

監視と自動化の設計:人手を増やさずに信頼性を上げる

運用はIaCとタグで始めます。全リソースに「Service」「Owner」「Criticality」「Environment」「CostCenter」などを必須タグ化し、監視テンプレートをタグで自動適用します。新規サービスがタグを付けるだけでアラート・ダッシュボード・バックアップ・コスト計測が有効化される状態が理想です。

アラートは「人が今すぐ起きるべき」ものだけに限定します。推奨ルールは以下です。

  • 症状ベース:p95レイテンシ500ms超が5分継続、HTTP 5xxが1分間に2%超など。
  • 依存関係の抑制:下流DB障害時は上流APIのアラートをサプレッション。
  • メンテナンス窓口:デプロイ/バッチ時間帯の抑止を自動適用。
  • 構成逸脱:重要タグ欠落、公開ストレージ、過剰権限をポリシー違反として検知。

自動復旧は小さく始めます。例:Webプロセスのヘルスチェック失敗→プロセス再起動、キュー滞留閾値超→ワーカー自動スケール、ディスク逼迫→ログローテーションと古い一時ファイル削除。Runbookは「検知→一次切り分け→暫定対処→恒久対策」の4段構成で、誰が読んでも同じ手順になるよう時系列で書きます。チャットOpsでの可観測性も有効です。障害チャネルにメトリクス/ログのスナップショットを自動投稿し、要約はChatGPTやClaudeで生成、IaCの差分レビューはCopilot、事後分析の分類はGeminiに補助させるとMTTAが短縮します。

インシデント対応プロセスと当番のまわし方

重大度は影響面(顧客/収益/規制)と範囲/回復見込みで決めます。例:SEV1=課金不可やデータ損失懸念、SEV2=主要機能の一部停止、SEV3=退避策ありの性能劣化。SEVごとにMTTA/MTTR目標(例:SEV1は5分/60分)と役割(Incident Commander、コミュニケータ、サブジェクトマター)を固定します。タイムラインは5分毎に自動生成、外部向け更新は15分間隔のテンプレを用意します。

当番は一次受けと二次受けの二層に分け、一次はプラットフォーム横断、二次は各サービスの深掘り担当。週替わりローテーションにし、夜間はページャ閾値を厳しく、平日日中は広めにとると疲弊しにくいです。緊急度の低いタスク(ディスク拡張提案など)はチケット化して就業時間内に回します。四半期ごとにGameDayで障害訓練(DBフェイルオーバ、リージョン隔離、秘密鍵ローテーション)を実施し、Runbookの穴を洗い出します。

身近な企業活用例:地方アパレルECの失敗と改善

従業員80名のアパレルEC「カスミファッション」は、オンプレからクラウドへ移行後、週末セール時にアラート嵐とカート遅延が多発。監視はCPUとディスク中心、タグ未整備、誰が見るべきかわからない状態でした。結果、SEV2が月6件、売上機会損失が推計300万円。

改善では、サービスタグ標準化とゴールデンシグナルの再定義を実施。p95 400ms超5分継続を症状アラート、DB接続枯渇は自動でコネクションプール拡張、画像変換バッチは夜間に平準化。Runbookには「カート遅延時の一次切り分け(AP/DB/外部決済)」を追加し、セール開始30分前のCanaryとスループット試験をCIに組み込みました。障害時の初動はチャットにメトリクスとログ要約を自動投稿(要約はChatGPTとClaude)。3カ月後、SEV2は月1件に減少、MTTRは平均47分→18分、セール時の転換率は1.3倍となりました。コストも、アイドル時の自動スケールダウンで月20%削減。

コストとセキュリティを“運用”として回す

コストは「予算・削減・説明責任」の3点管理です。予算はサービス別に月次予実をタグ集計、変動が20%を超えたら翌日レビュー。削減はRightsizing(CPU/メモリ利用率p50/ p95のギャップ縮小)、スケジューリング(営業時間外の停止)、ストレージ階層化でKPI化します。説明責任はChargeback/Showbackで可視化し、プロダクト側の判断材料にします。

セキュリティはガードレール先行が有効です。最小権限IAMのテンプレ、公開ストレージ禁止、KMS暗号化必須、脆弱性スキャンの自動化、パッチ適用SLO(重要パッチは7日以内)、秘密情報のローテーション(90日)を「違反時は自動検知→チケット発行→一定時間で強制是正」の流れで徹底します。バックアップはRPO/RTOをSLO化(例:RPO 15分、RTO 2時間)、月1回のリストア訓練と監査証跡の保管を定例運用に組み込みます。

クラウド移行は、設計の良し悪しが運用のラクさに直結します。SLOとタグ基盤、症状ベースのアラート、Runbookと自動復旧、小さな改善の継続。この地道な積み重ねが、監視運用の価値を最大化します。私たちの事業区分であるサーバ監視運用事業は、こうした設計と運用の橋渡しを日々の仕事として磨き続けています。