DevOpsの「障害を前提とした設計」という考え方はセキュリティリスクか？

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

「ベタリッジの見出しの法則」に反して、端的に言えば答えは「はい」です。しかし、今日のテクノロジーに関するあらゆる事柄と同様、詳しく説明すると、そう単純ではありません。

DevOpsは、あらゆる業界にかなり広く浸透していると思います。すべての組織がこのアプローチのあらゆる側面を採用しているわけでも、Netflixのようにその原則を熱心に徹底しているわけでもありませんが、DevOpsが確実に広がっていることは間違いありません。

直接的な裏付けとは言えませんが、F5の「State of Application Delivery 2018」で3,000人を超える回答者に、デジタルトランスフォーメーションがアプリケーションに関する意思決定にどのような影響を与えているかを尋ねたところ、上位3つの回答のうち2つは、「ITシステムとプロセスに自動化とオーケストレーションを導入する」と「アプリケーションの開発方法を変える（アジャイルへの移行など）」でした。私には、どちらも最新のアーキテクチャでアプリケーションを開発、提供する際に、DevOpsアプローチの少なくとも一部を採用したことによる反応だと推察されます。

つまり、組織がDevOpsに関連するツールや手法の一部を採用しているなら、ほかのものも採用していると考えられます。その1つは、（ここでドラマチックな音楽）「障害を前提とした設計」かもしれません。

ただし、この表現はやや正確さに欠けます。システムが障害を起こすように設計する人はいないからです。実際に行われているのは、障害に対してレジリエントなシステムを設計することです。たとえば、インスタンス（サーバー）がクラッシュした場合、システムは停止したインスタンスを削除し、代わりとなる新しいインスタンスを起動することで、状況に自動的に対処できる必要があります。

これで完成です！障害を前提とした設計です。

これは確かに望ましい反応です。特にシステムに高い負荷がかかり、需要が増大している場合にはなおさらです。しかし、このアプローチには、検討したうえで対処することが望まれるリスクがあります。

2017年初頭に発生したCloudflareの脆弱性について考えてみましょう。Cloudflareは、この問題に関する自社の報告で称賛に値するほど高い透明性を示しており、問題の本質は、HTTPパーサーの拡張機能の不具合によって生じたメモリリーク（データ漏えいにつながる可能性がある）だったと説明しています。要するに、不具合がメモリリークを引き起こし、その結果、インスタンスがクラッシュしました。障害の発生を前提に設計されていたため、これらのインスタンスは停止され、再起動されました。

念のため申し添えると、これは「バグを理由にCloudflareを非難する」記事ではありません。開発者として、自分の不具合がこれほど公にさらされることには強く同情します。一方で、何かがクラッシュしたり、メモリリークを起こしたり、完全に機能しなくなったりしている原因の究明がほとんど重視されていない状況には、あまり共感できません。

それが今回の記事の主題です。DevOpsの理念を信奉するあまり、障害発生後の調査に対して放任的な姿勢を取ってしまうことがあるからです。

サービスやアプリの障害が発生した際、可用性を確保するためにサービスを停止して再起動するのは、まったく妥当な対応です。ただし、その後にクラッシュの原因を調査することが前提です。アプリが理由もなくクラッシュすることはありません。倒れたのなら、何かが倒したのです。10回のうち9回は、悪用できないエラーのようなもので、ブログ記事にするほどではありません。しかし、残る1回が悪用されるおそれのある深刻な脆弱性なら、一見無駄に思えるほかの9回の調査にも十分な価値があります。それこそ、ブログ記事にすべきことだからです。

これを無視するのは適切ではありません。

障害やその他の問題を監視し、アラートを発することも、バランスの取れたDevOpsプログラムの重要な要素です。これは、包括的なDevOpsアプローチを構成するCAMS（Culture、Automation、Measurement、Sharing）の「S」に当たります。DamonとJohn（2010年にこの頭字語を考案）は、単にピザとビールについて語っていたわけではありません（もっとも、これはDevOps文化を表す「C」を促進する良い方法ではあります）。データやシステムの状態も共有の対象です。知ることでメリットを得られる人に、確実に情報を伝えることが重要です。これには、システム障害も含まれます。

障害、特にクラッシュを放置してはなりません。パイプライン内のシステムがクラッシュした場合は、担当者がそれを把握し、調査する必要があります。放置すれば、セキュリティリスクになります。さらに深刻なのは、それが回避可能なリスクであることです。自社の環境、システム、コードであり、すべてを管理できる以上、放置する理由はありません。

つまり、「障害を前提とした設計」は、アプリケーション、ひいてはビジネスをセキュリティリスクにさらす可能性があります。ただし、その理念が書面上だけの「障害を前提とした設計」にとどまり、実際には「障害を無視する設計」になってしまわないよう徹底すれば、こうしたリスクは十分に管理できます。

可用性を高く維持するために再起動する場合でも、クラッシュしたものを放置せず、注意を払ってください。そうすることで、望ましくない理由でTwitterのトレンドに取り上げられる事態から、ご自身とビジネスを守れる可能性があります。

著者について

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

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

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