「早く失敗する」は、スピードが重視される現代の合言葉です。DevOpsであれビジネスであれ、デジタル経済で事業を展開するには、可能な限り100%に近い稼働率が求められます。
この考え方は理論上は優れていますが、実際には失敗を増やすだけに終わることも少なくありません。根本原因の特定（MTTR）ではなく、可用性（稼働率）の確保だけに注力すると、かつてない勢いで貴重なデータが失われます。現実を直視しましょう。稼働率だけを重視すれば、MTTRは平均解決時間（Mean-Time-to-Reboot（再起動））ではなく、平均Resolution（解決）時間を意味するはずが、平均再起動時間（Mean-Time-to-Reboot）になってしまいます。そして、ダウンタイムの理由を解明できなければ、再発を防ぐことはできません。
このアプローチはビジネスに悪影響を及ぼします。
失っているのはパケットではなく、1セントにも満たないわずかな金額です。取引の端数を少しずつ抜き取って数百万ドルを築くという古典的な犯罪の筋書きが示すように、1セント未満の端数も積み重なれば無視できません。コンポーネント、サービス、サーバーが応答しない時間が1秒増えるたびに、体験面でも事業の存続という面でも価値が失われます。消費者はパフォーマンスの低下やダウンタイムを容認せず、企業の収支もそのどちらにも耐えられません。
スループットと帯域幅について理解していれば、どちらの計算も、基盤システムが1秒間に処理できるパケット数を基準としていることがわかります。これはネットワークだけでなく、トランザクションに関与するすべてのコンポーネントに当てはまります。アプリ、アプリケーションサービス、ルーター、スイッチ、データベースなどです。ネットワークに接続されているものはすべて同じ計算に従い、パケットを転送できる容量によって制約されます。
警告：この先、数式あり
今日のネットワークは高速であるため、まさにこれを毎秒数百万パケットという速度で行っています。もちろん、ビジネストランザクションは主にHTTPトランザクションが文字どおり網の目のように連なる中で実行され、その一つひとつがビジネスの遂行に不可欠な情報を伝達します。1件のトランザクションに必要なパケット数は、必要なデータ量によって異なります。平均的なパケットが伝送するデータ量は1,500バイトです（これがMTUです）。したがって、トランザクションを表すJSONペイロードを含むHTTPベースのメッセージが、暗号化後に4,500バイト必要だとすれば、約3パケットになります。余裕を持たせて、一般的なデジタルビジネストランザクションには5パケットが必要だとしましょう。10 Gbpsのネットワークでは、毎秒1,500万弱のパケットを処理できます。十分なコンピューティング能力があれば、これは300万件のトランザクションに相当すると言えます。各トランザクションの価値を1セントの3分の1と仮定すると、毎秒100万ドルになります。
実際には、この速度や規模でトランザクションを処理している組織はありません。多くの企業には必要のない速度でデータを処理していることに疑いの余地がないVisaでさえ、その処理能力は毎秒約24,000件のトランザクションだとしています。各トランザクションの価値を同じく1セントの3分の1と仮定しても、毎秒8,000ドルになります。
つまり、ルーター、スイッチ、ネットワークおよびアプリケーションサービスのインフラストラクチャ、アプリケーションインフラストラクチャ、各種コンポーネントで構成されるトランザクションチェーンの障害は、「極めて深刻な事態™」だということです。障害が発生するとパケットが処理されず、それが表す金銭的価値も処理されないため、大きな損失につながります。デジタル経済のあらゆる領域が、パケットの転送に依存しています。
これまでの答えは、「フェイルファスト」という考え方でした。X、Y、Zなど、障害が発生したコンポーネントの新しいインスタンスを立ち上げればよい、というものです。しかし、そのコンポーネントに障害が発生したのは「何らかの理由があるから」です。その理由を突き止め、対処することが極めて重要です。しかも、迅速に行わなければなりません。障害の発生から復旧までの数秒間にも、ビジネス価値が失われ続けるからです。一度障害が発生すれば、再び発生する可能性があります。何度でも。
可視性：MTTRを支える要
だからこそ、デジタル経済で成功するには可視性が極めて重要です。可視性があれば、あらゆる運用チームが障害の原因を特定し、修正できます。しかし残念ながら、可視性はスピードのために犠牲にされがちです。ここでいうスピードとは、文字どおりのトランザクション速度ではなく、価値実現までの時間を指します。アプリをより迅速かつ頻繁に市場へ投入しようと急ぐあまり、障害の影響を軽減するために必要な可視性の確保に十分な投資をしてきませんでした。
実際、DevOpsの「フェイルファスト」という考え方は、この問題への対応だともいえます。障害の原因を特定して対処できないのであれば、時間を浪費するよりも可用性を回復する方がよい、というのがDevOpsの判断です。しかし、アプリケーションのデプロイにマルチクラウドのアプローチを採用する組織が増えるにつれ、原因を特定して対処することはますます困難になっています。
2018年には、可視性をマルチクラウドの課題として挙げた回答者は3分の1未満（31%）でしたが、2019年には3分の1を超える39%に増加し、パフォーマンスおよびセキュリティと並んで、マルチクラウドにおける最大の課題となりました。可視性は、監視、分析、アラートを統合し、システムの状態についていつでも有用なインサイトを提供する、包括的な「オブザーバビリティ」の重要な要素です。これは障害発生時に特に重要です。システムの状態に関する情報が複数のIT部門に分散しており、単なる再起動ではなく迅速な解決につながる情報共有が可能とは限らないためです。
サービスメッシュが分散トレーシングを通じて価値をもたらす機能は、可視性を確保する優れた例です。しかし、その対象を、コンテナ化された環境で実行されるアプリケーションのスケーリングとセキュリティ確保を担う、アプリケーションサービスのチェーン全体にまで拡張する必要があります。これには、実行チェーンの一部となり得る分散コンポーネントや、パブリッククラウドで稼働するアプリケーションも含まれます。ダウンタイムやパフォーマンス低下の原因となる問題を特定して対処するには、環境、インフラストラクチャ、アプリケーションを横断する可視性が必要です。
組織が成功の指標をMTT再起動ではなくMTT解決に戻すには、可視性が不可欠です。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
SOAS 2025：足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。
WebAssemblyが重要な理由
WebAssembly（Wasm）は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ＆ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。