パフォーマンスの確保は、アプリケーションにとって重要な課題です。特にモバイル アプリケーションでは最重要課題だと言っても過言ではないでしょう。これまで行われてきた数々の調査結果を見れば、誰でもこの結論に達することができるはずです。アプリケーションが5秒以内に反応しなければ、一般消費者も企業ユーザも、同じように苛立ちます。なかでも消費者がモバイル アプリケーションを使って購入などを行う場合には、パフォーマンスの低さが致命傷になる危険性があります。

 このようなパフォーマンスに対する要求への対応を念頭に入れて開発されたのがHTTP/2です。

HTTP/2には、これまで開発者がHTTP/1.1におけるパフォーマンス改善策として頻繁に使用した結果、標準的な手法になっていったものが数多く実装されています。例えば、小さな画像を文字列に変換してHTMLやCSSに埋め込むことでHTTPリクエストを削減するインライン化や、小さなファイルの結合(Concatenation)、静的ファイルを別のドメインから読み込むことで同時接続数の上限を最大化するドメイン シャーディングなどの手法です。これらはいずれもパフォーマンス改善に貢献しましたが、残念ながら開発者と運営者の双方に対し、大きな“技術的負債”をもたらす結果となりました。

HTTP/1.1が生み出した“技術的負債”

 ここで言う“技術的負債”とは、特定の技術や製品、アーキテクチャを採用することでもたらされた、その後の開発や運営へのマイナスの影響を意味しています。また特定のソリューションを、アーキテクチャ内のどこに実装するかの判断も、技術的負債の要因になる可能性があります。

 例えば、HTTP/1.1の制約を回避するために利用されてきたインライン化やファイル結合は、ネットワーク上のキャッシュの利用を不可能にしてしまいました。またこれらのインライン化されたイメージやファイル結合は、すべてのアプリケーションに反映する必要があるため、アプリケーションのライフサイクルにも注意を払う必要があります。つまりこれらの手法を使うことで、アプリケーションのモジュール性が失われてしまったのです。このような技術的負債は、対象となるアプリケーションが使われ続ける限り、開発者や運営者を悩まし続けることになるでしょう。

 金銭的負債と同様、技術的負債にも対応が必要です。そのまま放置しておけば“利子”が発生するからです。この利子はアプリケーションの変更やアップデートが行われるたびに蓄積され、開発者は必要以上の時間と注意力を費やすことになります。またテストのためのリソースも必要になり、ネットワークやコンピューティングのリソースも消費します。その結果、企業はイノベーションや成長のためではなく、負債への対応に時間を費やすことになり、競争力を生み出す新しい技術や手法、アーキテクチャ上のコンセプトなどを活用することが困難になります。

HTTP/2への移行が可能にする負債からの解放

HTTP/1.1で生じた技術的負債は、将来的にHTTP/2へと移行することで解消できます。HTTP/2は、技術上・プロトコル上の幅広い制約に取り組んだ結果、開発者が過去の迂回策を捨て、新たな選択肢を手に入れることを可能にしたからです。そしてこれらの新たな選択肢には、技術的負債は伴いません。もちろん既存アプリケーションはこれまでの負債を抱えたままになりますが、HTTP/2対応のアプリケーションへの移行や置き換えを進めることで、HTTP/1.1が生み出してきた制約から、開発者も運営者も解放されていくでしょう。

 このように、HTTP/2の意義は高速化だけではありません。技術的負債による制約から開発者や運営者を解放し、企業にパフォーマンス改善のための新たな手段を活用するチャンスをもたらすことも、重要な意義だと言えます。技術やアーキテクチャ面での負債を生じさせにくい手段を活用すれば、企業はアプリケーション競争において、勝利を収めやすくなるのです。

 

servicing_architectural_debt

 

新規予算のうち、イノベーションに使われた割合はわずか3分の1未満であり、その他は単なる改善に費やされているとCIO達は認めています。