なぜクラウドの信頼性は「不完全なソフトウェア」に依存するのか？

• 近年のシステム障害がさまざまな業界で深刻な混乱を引き起こしていることからもわかるように、クラウドの信頼性はかつてないほど重要になっています。

• 障害は、オペレーターのミスやサイバー攻撃だけでなく、潜在的なソフトウェアの欠陥によって引き起こされることが多々あります。

• クラウドソフトウェアが持つ本質的な複雑さと多層的な構造により、バグのない完璧なシステムを実現することは不可能です。

• 信頼性の高いクラウドサービスを提供するためには、高品質なソフトウェアの担保が不可欠ですが、同時に「ソフトウェアの欠陥は避けられないもの」として受け入れ、それでも高可用性を確保できるようなシステム設計が求められます。

• 本連載の今後の記事では、この複雑さを管理し、回復力（レジリエンス）の高いクラウドシステムを構築するための戦略について解説します。

近年、広範囲に影響を及ぼすクラウドやITサービスの深刻な障害が多発しており、実社会に多大な影響を与えています。私たちは多少の技術的なトラブルには慣れっこになっていますが、近年の障害はその影響の広さと深さがこれまでとは異なっていました。フライトの欠航、業務の停止、家庭内のコネクテッドデバイスの誤作動など、さまざまな形で混乱を招いています。

業界全体でなぜこれほどまでに障害が増加しているのか。そして今後はどうなっていくのか。AkamaiのCloud Technology部門担当CTOとして、私は最近、この疑問を抱くジャーナリストや同僚、業界のリーダーたちと対話を重ねてきました。

Akamaiにとって、信頼性は最重要のテーマです。私たちは、クラウドコンピューティング、セキュリティ、コンテンツ配信のための世界で最も分散されたプラットフォームを運用しており、お客様のビジネスをオンラインで円滑に稼働させ続けるという重責を担っています。本記事を皮切りとする連載では、Akamaiの知見をもとにソフトウェアの複雑性やシステムの根本的な性質からこの問題を捉え直します。

読者の皆様は、ソフトウェアやシステムの複雑性、組織における信頼性の文化、いわゆる事故発生の「スイスチーズ・モデル」、ヒューマンファクター（人的要因）など、幅広いトピックを通じて実践的な視点を得ることができるはずです。ここで共有する内容は、世界中のビジネスに不可欠なオンライン体験を支えるため、4,400以上の配信拠点（PoP：Points of Presence）に展開された数十万台規模のサーバーネットワークを25年以上にわたり運用してきた私たちの経験に基づいています。

最近起きた広く報道されたクラウド障害の際、私は世界中でどの程度の影響が出ているのかを把握しようとテレビのニュースを見ていました。そこで解説に招かれた専門家が、「今回の障害の原因がオペレーターのミスなのか、それともサイバー攻撃なのかを判断するにはまだ早すぎる」とコメントしたのを聞き、私は驚きました。

選択肢はその2つしかないのでしょうか？ 確かにオペレーターのミスは技術的なインシデントの一般的な引き金であり、サイバー攻撃も実際に発生します。しかし、障害の原因はそれだけではありません。頻繁に元凶となるのは「潜在的なソフトウェアの欠陥」です。数カ月前、あるいは数年前にコーディングされデプロイされたミスが、まさにその身を現すための完璧な条件が揃うのをひっそりと待っているのです。私はテレビに向かってこの可能性について叫んでいましたが、後になって、やはり原因が潜在的なソフトウェアの欠陥だったことが判明しました。

クラウドサービスの信頼性においてソフトウェアが果たす役割は、主に以下の3つの理由から、見落とされがちであったり誤解されていたりします。

1. クラウドサービスを動かすソフトウェアは、エンドユーザーの目に触れるアプリケーションのコードだけにとどまりません。アプリケーションの裏側には何層にも重なるインフラが存在し、それぞれが独自のソフトウェアスタックで稼働しています。

2. ソフトウェアの役割は、アプリケーションやインフラの機能を提供することだけではありません。独立した複数のコンポーネントが互いに通信し、複雑で時に予測不可能な形で互いの挙動に影響を与え合うような、動的なシステムを管理するという重要な役割も担っています。

3. バグのない完璧なソフトウェアを構築することは、信じられないほど困難です。ごく特殊な状況を除き、技術的にも経済的にも現実的ではありません。

さらに厄介なことに、オペレーターのミスやハードウェアの故障といった他の障害の引き金も、ソフトウェアの問題によって被害が拡大することがあります。一部のオペレーターのミスが甚大な影響を及ぼすのは、それがソフトウェアの潜在的な欠陥を誘発するからです。あるいは、故障したハードウェアを迂回するように設計されたソフトウェアシステムそのものがダウンしてしまうこともあります。

今後の連載記事では、上記のうち最初の2つのトピック、つまり「インフラとシステムの複雑性」について詳しく掘り下げていきます。今回の記事では、そもそも「なぜ完璧なソフトウェアを作るのがそれほどまでに難しいのか」という点に焦点を当てます。

ちなみに、私はここまで「バグ（bug）」という言葉を避け、「ソフトウェアの欠陥（software defects）」という表現を使ってきました。これは、ソフトウェアの問題を種類ごとに区別するためです。

• ソフトウェアの作成者が意図した通りの手順で正確に実行されるようにコーディングしたものの、そのアプローチ自体が目の前の課題解決において根本的に間違っている場合、そのミスは「設計上の欠陥（design flaw）」と呼ぶのが正確です。

• 一方で、アプローチ自体は根本的に妥当であるものの、コード内で「1つずれる（off-by-one）」ような計算ミスがあるなど、命令に小さな不具合がある場合は、明確に「バグ」と呼ぶことができます。

その違いが常に明確であるとは限りませんが、今後の記事で扱うシステムの複雑性については「設計上の欠陥」に焦点を当て、本記事の残りの部分では「バグ」について解説します。

フロッピーディスクやCD-ROMを覚えている世代なら、クラウドが存在するずっと前から、世界がソフトウェアのバグに慣れ親しんでいたことを知っているでしょう。これほど多くの技術分野で目覚ましい進歩があったことを考えれば、「なぜ何年経ってもソフトウェアにはこれほど多くのバグが存在するのか」と疑問に思うのは当然のことです。この問いに対する多面的な答えは、ソフトウェアそのものの性質と、それを取り巻くエコシステムの両方に起因しています。

ソフトウェアの概念は、「単一目的の機械」と「多目的の機械」の違いに根ざしています。人類の歴史の大部分において、道具やデバイスは、たったひとつの作業、あるいはごく少数の特定の作業をこなすためだけに作られてきました。

時が経つにつれ、発明家たちは、多くの作業を実行できるように柔軟に再構成できる機械を作る方法を発見しました。その初期の例がジャカード織機（Jacquard loom）です。これは穴の開いたカードの束を使って、布に織り込む模様を制御していました。この進化の行き着く先が最新のCPUであり、そのサイズや計算速度だけでなく、いとも簡単に別の機械へと「再プログラム」できる点で驚異的です。

この柔軟性がもたらす利点は計り知れません。ソフトウェアのおかげで、私たちは月へ行き、命を救う新薬を開発し、ヒトゲノムを解読し、かつてない規模とスピードで世界中に情報を発信・共有できるようになりました。

また、この柔軟性によって、改善や欠陥の修復にかかるコストも劇的に下がりました。高額な現地作業や物理的なデバイスの発送にかかるコストを負担する代わりに、CD-ROMの送付へ、さらにインターネット経由でのソフトウェアアップデートへ、そして最終的にはエンドユーザーが何もしなくてもクラウドサービスの裏側でソフトウェアを更新できる世界へと移行してきました。

しかし、欠陥の修復コストが下がったことには、目に見えない代償が伴います。機械の修理が難しかったり高額な費用がかかったりする場合、修理の必要性を減らす、あるいは回避するために事前の予防に投資しようという強力なインセンティブが働きます。

一方で、修復コストが十分に低くなると、インセンティブの構造が変化します。展開前の投資（事前品質）を少し犠牲にしてでも、展開後の修正（事後修理）に頼ることが、、単に有利なだけでなく、ほぼ必然となってしまうのです。言い換えれば、「初期品質を多少犠牲にしてでも、問題は後で修正する」というアプローチが定着します。

これは「市場に先に出した者が勝つ」というよく言われる決まり文句にも一部表れていますが、事態はもっと深刻です。今日、私たちがソフトウェアに要求しているタスクは、もしそれを物理的、機械的なシステムに組み込もうとすれば（そもそも構築可能だとして）、気が遠くなるほど複雑なものになっています。

しかし、ソフトウェアの世界では、物理的なシステムで求められるような、リリース前の完璧さを担保する手段が一般的に存在しません。数百万行に及ぶコードの塊よりも、機械式の腕時計が正確に動くことを保証するほうがずっと簡単なのです。仮にリリース前に完璧な状態を目指したいと考えたとしても、そのためには技術的進歩の多くの重要な側面を逆行させる必要があります。

ソフトウェアエンジニアがこのような複雑性を管理するための主要な手段のひとつが、「抽象化の壁（abstraction barrier）」の利用です。これは、問題の一部を明確な入出力インターフェースを持つ独立した小さな「ブラックボックス」として切り出し、その処理に必要なすべての複雑さを箱の中に閉じ込めて隠蔽するという概念です。

抽象化の壁は、圧倒的に複雑な問題を管理可能な単位に分割するための極めて強力なツールであり、ある程度の複雑さを持つプロジェクトのほぼすべてでこの手法が採用されています。ソフトウェアの内部構造から、日付処理や文字列操作といった共通機能として依存する外部ライブラリ、さらにはソフトウェアを実行するための抽象化された環境を提供するオペレーティングシステム自体に至るまで、スタックのあらゆる層で活用されています。実際、「コンピュータエンジニアリングにおける難しい問題はすべて、抽象化のレイヤーをもう1つ追加することで解決できる」という古い格言があるほどです。

しかし、これにも2つの問題に根ざした欠点があります。

1. まれに、抽象化の壁が期待したほどきれいな境界になっていないことがあります。極端な例が「Spectre」の脆弱性です。これはブラックボックスの「内側」に留まるはずの情報がわずかな隙間から漏れ出す可能性があり、セキュリティ上の重大な問題をはらんでいました。もう1つの例は「Shellshock」の脆弱性です。こちらは抽象化の壁の両側をつなぐインターフェースが想定ほど厳格に制御されておらず、世界中のウェブサーバーに深刻な脆弱性をもたらしました。

2. 前述の理由により、欠陥を修復するために、抽象化の壁の両側にあるソフトウェアを継続的にアップデートする必要があります。

これら2つの問題が組み合わさることで、あらゆるソフトウェアの周囲には常に変化し続ける環境が生まれます。この絶え間ない進化こそが、ソフトウェアが永遠に「完成」せず、常に何らかのメンテナンスコストを伴う最大の理由です。

仮に、ソフトウェアの役割とアプローチを固定して機能追加を凍結（フィーチャーフリーズ）したとしても、その周辺のシステムが変化することで、予期せぬ動作が引き起こされる可能性があります。しかも、それはあくまで理想化されたケースの話です。現実には、ユースケースが広がるにつれてタスク自体も進化していくことがほとんどです（この話題については、技術的負債に関する今後の記事で詳しく解説します）。

Akamaiの同僚なら、ここまでの話を読んで「ずいぶんと『問題の分析』にばかり時間を割いたね」と指摘するかもしれません。重要なのは、これに対してどう行動するかです。諦めて「難しすぎる」と投げ出してしまうのでしょうか？ もちろんそんなことはありません。エンジニアリングという学問の半分は、自分が望む条件ではなく、今ある条件の下で望ましい品質レベルをいかに達成するか、ということにあります。

当然ながら、ソフトウェアの品質を向上させる技術がその出発点となります。安全なコーディング手法の採用、正確性を検証するツール、テスト戦略、レビューやチーム体制のアプローチ、適切なプログラミング言語の選択など、このテーマについては数え切れないほどの書籍や講座で深く掘り下げられています。

しかし、極めて信頼性の高いクラウドサービスを構築するためには、これらは出発点にすぎません。高品質なソフトウェアを担保することは絶対条件ですが、それだけではまったく不十分なのです。もし、どんなに高品質なソフトウェアであってもバグは存在すると仮定するならば（そしてそれは正しい仮定ですが）、問うべきは「そのバグが大規模な障害につながらないようにするにはどうすればよいか？」ということになります。

この問いに答えることこそが私たちの使命であり、本連載の今後の記事における中心的なテーマとなります。どうぞご期待ください。