アップタイムだけでは不十分。ITの新たな「ファイブナイン」は短いMTTR

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

システム停止には多大なコストがかかります。最終的な原因が攻撃であれ、ソフトウェアやハードウェアの障害であれ、大きな違いはありません。現代のデジタル経済ではAPIやWebアプリへの依存が高まっているため、ダウンタイム1分当たりのコストも増加しています。

企業によっては、そのコストは驚くほど高額です。2013年にAmazonで発生した40分間のダウンタイムは、264万ドルの損失をもたらしたと推定されています。計算するまでもなく、1秒あたり1,100ドルです。これでも恐ろしいと思うなら、Googleの例を見てみましょう。同年に発生した5分間のダウンタイムによる損失は1分あたり10万9,000ドル（つまり1秒あたり1,816.67ドル）で、総額は実に54万5,000ドルに上りました。わずか5分間で、です。厳密に言えば、被害がそれだけだったとすれば、IT部門が達成を求められる、いわゆる「ファイブナイン」に相当します。

障害はどのくらいの頻度で発生するのでしょうか。どうやら、あまりにも頻繁に起きているようです。まだご覧になったことがなければ、pingdomのリアルタイム障害マップをご覧ください。世界中の70万人を超えるユーザーから収集したデータを基に作成されています。この不気味なほど興味深いマップには、過去1時間に世界各地で発生した障害が表示されます。障害を示す明るい点滅も効果的で、ユーザーに与える影響の大きさを実感させます。

つまり、望ましくない影響ということです。

デジタル経済は、この問題をさらに深刻化させています。今年初めには、AmazonのS3障害により、多数のお客さまのアプリやWebサイトが停止しました。しかし、この問題をパブリッククラウドプロバイダーのせいだと考えているなら、builtwith.comを少し調べるだけで、その考えはすぐに覆るでしょう。CDNやAPIを利用しているサイトの割合は、他社の稼働状況に依存することを考えると、驚くほど高いかもしれません。少なくとも1つの外部APIやサービスに依存していないサイトを見つけるのは困難です。外部サービスが停止すれば自社サイトも停止するため、ダウンタイムが発生する可能性が高まります。

そもそも、100%の可用性を実現することは不可能なため、IT部門は「ファイブナイン」を目標としてきました。経済のデジタル化によって1秒当たりのコストが急増している現在、重要なのはダウンタイムを最小限に抑えることです。つまり、平均解決時間（MTTR）を短縮する目標を設定することは、ダウンタイムの解消を目指すのと同じくらい、あるいはそれ以上に重要です。

Puppet Labsの「2016 State of DevOps Report」では、「高パフォーマンス組織」を評価する主要指標の1つとしてMTTRを挙げています。MTTRとは、サービスインシデント（計画外の停止やサービス品質の低下など）が発生してからサービスを復旧するまでの時間です。同レポートの評価で最もパフォーマンスが高い組織では、復旧に要する時間が1時間未満であるのに対し、中程度および低パフォーマンスの組織では「1日未満」です。同レポートは、「つまり、高パフォーマンス組織のMTTRは、低パフォーマンス組織より24倍短い」と指摘しています。

ここで注目すべきは、サービスインシデントが発生する「かどうか」ではなく、「いつ」発生するかが問題になっている点です。インシデントは発生するものと想定されているため、解決までの時間を最小限に抑えることが重要です。IHSが2016年に実施した調査では、「調査回答者は平均して月に5回のダウンタイムを経験し、月間のダウンタイムは27時間に上る」と報告されています。そのコストは、平均的な中規模組織で$1、大規模組織では最大$60Mに達します。

マーフィーの法則が今なおムーアとコンウェイの法則に勝ると考えるなら、避けられないダウンタイムに伴う時間（およびコスト）を削減するには、MTTRを最小限に抑えることが重要です。

つまり、可視性が極めて重要であり、そのためには徹底した監視が必要です。ただし、Webサイト、Webアプリ、APIだけではなく、スタック全体を監視する必要があります。ネットワークからアプリサービス、アプリケーション自体までが対象です。しかし、誰もが実施しているわけではなく、実施していても一貫性に欠けるようです。

2017年に実施された「xMatters|Atlassian DevOps成熟度調査」では、回答者の50%が、運用部門から重大インシデントの宣言が出るまで対応を開始しないと回答しています。さらに驚くべきことに、企業の1/3がサービス停止を顧客から知らされています。

デジタル経済では、一刻を争います。損失が生じるだけでなく、将来の収益にも悪影響を及ぼすためです。ブランド価値と顧客からの信頼が低下すれば、購入やユーザーが減少し、やがて成長が停滞します。組織が進むべき方向ではありません。

停止を引き起こす問題を検出するには、まず監視が必要です。しかし、監視だけではMTTRの改善にはつながりません。重要なのはコミュニケーションです。関係者にできるだけ早く通知し、問題のトラブルシューティングに必要な情報を提供することで、解決までの時間を短縮できます。つまり、共有はDevOpsを支える4つの主要な柱の1つであり、MTTRの改善に欠かせません。組織全体でDevOpsのほかの側面をまだ導入していない場合でも、共有は最優先の取り組みとして検討すべきです。ChatOps経由でも、メール、モバイルアプリ、動的に更新されるWikiページでも、監視から得られた情報を組織全体で広く共有することが不可欠です。

スイッチやサーバーの一時的な不具合は無害に見えるかもしれませんが、放置すると、重要なアプリが依存するサービスの半数が停止する可能性があります。Viaviが実施した「2017 State of the Network」調査」では、ネットワークおよびシステム管理者の65%が、アプリケーションの問題をトラブルシューティングする際の最大の課題として、「問題の原因がネットワーク、システム、アプリのいずれにあるかを特定すること」を挙げています。この課題に対処する方法の1つは、可視性を高め、フルスタック監視を行うことです。これにより、根本原因の特定を担当する人が、データパス上のすべてのコンポーネントのステータスと健全性について、可能な限り多くの情報を利用できるようになります。

可視性はITの未来を左右する鍵です。可視性がなければ、障害が発生する前に対処するために必要なレベルの自動化を実現できません。また、MTTRを有意に短縮することも、持続可能なペースで事業を成長させ続けることもできません。

可視性は、セキュリティと同様に、ITの進化を支える戦略スタックの中核に据えるべきです。障害は起こり得ますが、可視性を確保することで、ブランドや収益への影響を最小限に抑えながら、迅速かつ効率的に復旧できます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事