前回のあらすじ

【連載第4回】ITILの心臓部「SVS」をAWSで動かすための設計図

前回、私たちは戦略的パートナーと共に、市民の要望を価値ある公共サービスへと変換する、壮大な「クラウド都市の中枢システム」の設計図を広げました。このシステムは、私たちの都市が継続的に発展していくための、まさに市政運営のOSです。

しかし、どれほど優れた都市計画を描いても、それで終わりではありません。その都市の基盤となるインフラが、万が一の災害時に機能不全に陥ってしまうようでは、市民の生活は守れません。

都市を設計した私たちが次に問うべきは、「この都市インフラの『信頼性』と『回復力』を、どうやって科学的に証明し、継続的に強化していくのか？」です。

 

この記事でわかること

  • なぜ多くのインフラチームが、日々の「場当たり的な復旧作業（トイル）」に追われ、疲弊してしまうのか。
  • 市民サービスの品質を「感覚」ではなく「数字」で定義するSLO（サービスレベル目標）という考え方。
  • 都市の発展を加速させるための「攻め」の指標、エラーバジェットとは何か。
  • インフラの弱点を事前に発見し「防災力」を鍛える、AWS Fault Injection Service (FIS) を用いた具体的な実践法。

 

なぜ、私たちの都市は「トイルの沼」から抜け出せないのか？

「深夜2時のシステム障害で、冷めたコーヒーを片手にモニターとにらめっこ…」

「また同じような手順書をコピーして、サーバーを構築している…」

「報告書の作成に追われて、根本的な対策が後回しになっている…」

もし、あなたがインフラチームの一員なら、こうした情景に心当たりはないでしょうか。これらは、SRE（Site Reliability Engineering）の世界で「トイル（Toil）」と呼ばれます。

トイルとは、自動化が可能で、戦術的で、長期的な価値を生まない、繰り返しの手作業を指します。問題は、インフラチームの時間の大半がトイルに奪われ、より価値のある仕事、つまり都市のインフラをプロアクティブに強化するための活動に時間を割けなくなることです。

多くの組織では、インフラチームは「いかに早く災害から復旧したか（災害発生後に駆けつける消防隊）」で評価されます。しかし、本来評価されるべきは、「いかに災害の発生を防ぎ、被害を最小限に抑えたか（災害を未然に防ぐ都市防災設計士）」であるべきです。この評価指標のズレが、私たちを「トイルの沼」に縛り付け、疲弊させてしまう根本原因なのです。

SREは、この悪循環を断ち切るための強力な思想体系です。「インフラの問題を、ソフトウェアエンジニアリングの手法で解決する」というアプローチで、私たちを「消防隊」から「都市の防災設計士」へと変貌させてくれます（出典：サイト信頼性エンジニアリング (SRE) とは何ですか？）

 

「感覚」から「科学」へ。災害に強い都市を築くための2つの基本原則

SREの実践は、まず2つの重要な概念を条例として定めることから始まります。これらは、信頼できる都市を設計するための、揺るぎない基本原則となります。

原則1：サービスの「信頼性」を数字で定義する『SLO』

「私たちの市民サービスは安定しています」――この言葉は、どれくらい「安定」しているのでしょうか？感覚的な言葉では、市政と市民、あるいは部署間の会話はすれ違ってしまいます。

そこで登場するのがSLO（Service Level Objective）です。これは、市民が体験するサービスの品質を、具体的な数値目標として定義したものです。

  • SLA（サービスレベル合意）との違い
    • SLAは、市民との法的な契約であり、違反した場合にペナルティが発生する「守らねばならない最低限の防衛ライン」です。（例：月間稼働率99.9%）
    • 一方、SLOは市が自らに課す野心的な内部目標であり、「常に目指し続ける理想のサービス品質を示す攻撃ライン」です。（例：月間稼働率99.95%）

このSLO監視を実現するためには、高度な可観測性（Observability）プラットフォームが不可欠です。AWS環境であれば、まずはAmazon CloudWatchのSLO機能を活用するのが最もスムーズな第一歩となるでしょう（出典：CloudWatch Service Level Objectives (SLOs)）

もちろん、これらのSREの原則は、DatadogやNew Relicといった業界をリードするサードパーティ製ツールと組み合わせることで、さらに強力に推進することも可能です。

例えば、Amazon CloudWatchを使い、市民向けWebサイト（ALB）のレスポンスタイムや、各種申請API（AWS Lambda）のエラー率といった市民体験に直結する指標を監視し、「Webサイトへのリクエストの99.95%が、500ミリ秒以内に正常に表示されること」といった具体的なSLOを設定します。CloudWatchに新しく追加されたSLO作成機能を使えば、これを簡単に定義し、ダッシュボードで可視化できます。

これにより、私たちは初めて「信頼性」という曖昧な概念を、誰もが同じ基準で判断できる「条例」として手に入れるのです。

 

原則2：安定を守るほど「挑戦」が許される『エラーバジェット』という逆転の発想

SLOを99.95%と設定した時、残りの0.05%は何でしょうか？これがエラーバジェットです。

エラーバジェット = 100% – SLO

これは「意図的に許容された、サービス品質の低下」の量であり、SREにおける最も革新的な概念と言えるでしょう。エラーバジェットは、市が新しい市民サービスのリリースや、意欲的なインフラ刷新といった「挑戦」に使える予算なのです。

  • エラーバジェットが残っている場合
    • 開発チームは新しい市民サービスを積極的にリリースできます。なぜなら、万が一小さな問題が起きても、許容範囲内だからです。
  • エラーバジェットを使い切った場合
    • 全ての新規リリースを凍結し、チーム全員でインフラの信頼性向上のための作業に集中します。

これにより、「安定した市政運営」と「革新的な都市開発」という、従来はトレードオフだと考えられていた2つの目標が、エラーバジェットという共通の指標で結びつきます。インフラの信頼性を守ることが、結果的に都市の発展スピードを加速させるのです。

 

設計図を信じるな。AWS FISで未来の障害を「予行演習」する

信頼性の原則（SLO）と挑戦のための予算（エラーバジェット）を定めた私たちは、いよいよ実践的な都市設計に着手します。

しかし、設計図を眺めているだけでは、災害に強い都市は作れません。

そこで、インフラの弱点を実際の災害が起こる前に発見し、プロアクティブに「防災力」を鍛えるために、都市全体で「防災訓練」を実施します。これを実現するのが、AWS Fault Injection Service (FIS)です（出典：Fault Injection Service AWS とは）

AWS FISは、AWS環境に対して意図的に擬似的な災害（サーバーダウン、ネットワーク遅延など）を発生させ、都市インフラがどう振る舞うかをテストするための防災訓練シミュレーターです。これは、もはや単なる「障害訓練」ではありません。都市の免疫力を高めるための「カオスエンジニアリング」という、最先端のSREプラクティスです（出典： AWS Well-Architected Framework REL12-BP04）

恐れる必要はありません。AWS FISは、その先進的な実践を、誰もが安全に行える「科学的な実験」へと変えてくれるのです。

例えば、次のような「防災訓練」を実践します。

  1. 訓練目標の設定
    • CloudWatchで定義した市民向けWebサイトのSLO（可用性99.95%）を、単一アベイラビリティゾーン（AZ）障害相当のインパクト発生時にも維持できるかを確認する。
  2. 訓練シナリオの計画
    • AWS FISで、「本番環境のWebサーバー群（Auto Scaling Group）のうち、ランダムに1台のEC2インスタンスを、平日の業務時間中に突然停止させる」という訓練シナリオを定義します。
  3. 防災訓練の実施
    • 計画したシナリオを実行します。
  4. 被害状況の分析
    • CloudWatchのSLOダッシュボードを監視します。サーバーダウン後、ロードバランサーは正常にリクエストを振り分け、代替サーバーは迅速に起動したか？SLOに影響は出たか？
  5. 防災計画の見直し
    • もしSLOが悪化した場合、その原因（ヘルスチェックの間隔が長すぎた、など）を特定し、インフラ設計や設定を改善します。そして、再度訓練を行い、都市の回復力を証明します。

このサイクルを回すことで、私たちは実際の災害を待つことなく、インフラの弱点を安全に、そして継続的に改善し続けることができるのです。

このSREによるプロアクティブなアプローチは、まさに従来のITILにおける『インシデント管理』や『問題管理』を、データと自動化によって進化させた現代的な実践手法と言えるでしょう。

 

まとめ：「消防隊」から「都市防災設計士」へ

災害対応に追われる「消防隊」から、SLOとエラーバジェットを手に未来の災害リスクを管理し、AWS FISで都市の防災力を設計する「都市防災設計士」へ。

SREとは、単なるツールセットではなく、都市運営のあり方そのものを変革する文化です。そして、AWSの豊富なマネージドサービスは、その文化を実践するための強力な武器を、私たちの手に与えてくれます。これこそが、次世代MSPが提供すべき、プロアクティブな都市インフラの姿なのです。

 

次回予告

災害に強いインフラ（信頼性）を科学する手法を手に入れた私たち。しかし、クラウド都市の運営にはもう一つ、市長から市民まで、誰もが頭を悩ませる大きな課題があります。それは「都市の財政（コスト）」です。

次回は、コストを単なる「歳出」ではなく、都市を発展させるための「投資」と捉え直す、FinOpsという文化に焦点を当てます。

【クラウド都市の設計思想 Vol.6】「クラウド貧乏」を卒業。コストを価値に変えるFinOps文化にご期待ください。

 

過去の連載はこちら

これまでのバックナンバーを見逃した方は、こちらからご覧いただけます。

クラウド運用に関するお悩みや、これからのパートナーシップのあり方にご興味をお持ちでしたら、どうぞお気軽にお声がけください。あなたのビジネスが直面している課題について、ぜひお聞かせいただけませんか。

クラウド導入実績 国内トップレベルの cloudpack クラウドの設計・開発・構築から 運用保守までトータルサポート