ブログ

アプリ アーキテクチャにとってネットワークが重要な理由

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2017 年 5 月 8 日公開
2965グループ

私は、アプリ アーキテクチャとネットワークの間の、時には混乱を招く関係というトピックについて、多くの記事を書いてきました。 これらは主に、アプリ アーキテクチャの変更が、速度、スケール、セキュリティを提供するために使用されるネットワークとアプリ サービスにどのような影響を与えるかに焦点を合わせています。 しかし、今日は、その関係を逆転させて、ネットワークがアプリケーション、ひいてはイノベーションにかなり大きな影響を与える方法について見ていきます。

High Scalability に関する最近の投稿で、そのことを思い出しました。その投稿では、ネットワークがなぜ重要なのか、そしてサーバーレスに至るまでの進化がどのように起こったのか、そしてインターネットが実質的にコンピューターである世界を実際に考えることができるのはなぜなのかが、著者によって説明されています。 長いですが、読み応えのある内容ですので、ぜひ時間を取って読んでみてください。 ここで要約しますが、ソース記事で興味深いと思われる内容がここには多く含まれています。

インターネットにダイヤルアップでアクセスしていた時代、Web サイトは主にテキストで構成され、1 つか 2 つの (低品質の) 画像が含まれていました。 インタラクティブな操作が必要な場合は、gopher または telnet を起動し、テキストベースの端末を使用します。 ダイヤルアップ経由のラストマイルで、より複雑なものを提供することは不可能でした。

ダイヤルアップの速度が上がり、最終的には最初の「ブロードバンド」サービスに置き換えられると、アプリはより多くの画像を表示するようになり、複数のページに分割され始めました。 なぜなら、ネットワークの速度が十分速かったため、消費者が退屈して Diablo をプレイしに行くことなく、その情報を送信できたからです。 このパターンは規模が問題になるまで続きました。 サイトの妨げとなっているのは、もはや速度ではなく規模でした。 負荷分散は突然金鉱になりました。

ネットワーク速度は、ラストマイルだけでなく、データセンター内やインターネットのバックボーン全体でも向上し続けました。 Web 2.0 は Web アプリの概念を世界に紹介し、交換されるデータの規模と速度を確保するネットワークの能力を活用した、応答性の高いインタラクティブな Web サイトを実現しました。

ネットワークの進歩により、アプリケーション アーキテクチャは変化しました。 スピードと規模がなければ、Web 2.0 の世界は決して生まれなかったでしょう。なぜなら、それはすべての消費者が本来持っているスピードへのニーズを満たすことができなかったからです。 しかし、これらのアプリは依然として、プレゼンテーション層、ロジック層、データ層で構成される従来の 3 層モデルでした。 それらは単にインターネットを通じて配布されただけです。

その後すぐに、SOA (若い人たちにはサービス指向アーキテクチャー (ちなみに私の庭からは立ち去ってほしい)) が大流行しました。 標準 (SOAP、XML) の組み合わせを使用し、既存のサービス指向の概念に基づいて構築された「Web サービス」が主流になりました。 Web サービスと SOA では、アプリケーションを個々のサービスに分解するという概念が導入されました。 それが聞き覚えのある話だとしたら、それは当然です。なぜなら、今日私たちはその概念を「マイクロサービス」と呼んでいるからです。

Web サービスの問題は、XML が大容量の形式であり、クライアント (またはサーバー) 上で解析するのに時間がかかることでした。 XML は SOA の中心であったため、各サービスはネットワーク経由での交換と処理に X 時間の消費を要しました。 消費者からのリクエストを処理するために利用できる時間は限られているため、アプリケーションを合理的に分解できるサービスの数は必然的に制限されます。  達成できると期待できるのはせいぜい 2 つまたは 3 つのサービスです。

今日、ネットワークは端から端までより高速かつ多様化しています。 データ センター (およびクラウド) ネットワークは、メガビット/秒ではなくギガビット/秒で測定され、ブロードバンド接続でさえ、初期の企業ネットワークの速度をはるかに上回るものになります。 つまり、ネットワーク上の転送が高速化されます。 コンピューティングと I/O 速度の驚異的な向上 (ムーアの法則が正しいため) と相まって、アプリケーションは数十、数百のサービスに分解でき、予想される応答パラメータ内で呼び出して実行できるようになりました。 これらをマイクロサービスと呼びます。

ネットワークにおけるこれらの変更により、最新のアプリケーション アーキテクチャと API が実現しました。 それは、2000 年代初頭には決して不可能だった方法で、リアルタイムの情報交換を促進しました。 テクノロジーが従来のサポート的な役割を担うのではなく、ビジネス戦略の重要な要素として考えられるようになったのと同様に、ネットワークもアプリケーションの重要な要素になりつつあります。 次世代のアーキテクチャ(サーバーレス)の波が押し寄せるのを見ると、スケールやセキュリティ イベントにほぼ瞬時に応答する、応答性に優れた統合ネットワークとアプリ サービス層がなければ、このようなコンピューティング モデルは実現不可能であることがわかります。

今では、ネットワークの速度 (光速の限界に達しつつあります) よりも、スケールアップやスケールダウン、進行中の攻撃の阻止、ネットワークやアプリ インフラストラクチャの問題の回避などのイベントに対応するネットワークの速度が重要になっています。 次世代のネットワークは、ソフトウェア定義、ソフトウェア駆動、ソフトウェア対応です。 また、コンテナでホストされているサービスへのアクセス、スケール、セキュリティを提供するサービスからのほぼ瞬時の反応速度を要求するジャストインタイム アプローチを採用したスケーラビリティ モデルへの移行も進んでいます。

私たちがよく言う「ネットワーク」は、さまざまなソフトウェアやハードウェアに存在するサービスで構成されています。 「ネットワーク」がジャストインタイム モデルで応答し、サービスを提供する能力は、これらの新しいアプリケーション アーキテクチャ モデルの成功を部分的に決定することになります。 

「ネットワーク」は今ほど重要になったことはありません。