モノリシックから分散型へ: 進化するapplicationsが ADC に与える影響
applicationsはデジタル生産性の原動力であり、生の処理能力を日常生活を楽にする便利なツールに変え、仕事、旅行、エンターテイメント、産業を変革する主力製品です。 これらのソフトウェア プログラムは、食品の配達を注文するのに役立つアプリ、宇宙で衛星を誘導するアプリ、組み立てラインに電力を供給するアプリ、このブログを書くのに役立ったワードプロセッサを提供するアプリなど多岐にわたります。
applicationsは時間の経過とともに大きく進化し、特定の計算タスク用に設計された基本的なプログラムから、AI を搭載し、分散環境全体の入力によって駆動される動的な最新アプリへと発展してきました。 近年のapplicationsの進化を振り返ることで、変化するユーザーのニーズ、ビジネス要件、技術革新にコンピューティングがどのように適応し、デジタル世界を形作ってきたかについての洞察が得られます。 しかし、アプリがより複雑になり、接続性、パーソナライズ性、アクセス性、インテリジェント性が高まるにつれて、applicationの攻撃対象領域が拡大し、アプリが悪意のある脅威や悪用にさらされるリスクが高まっています。 簡単に言えば、攻撃対象領域の拡大は、最新かつ最高のサイバー防御を突破するための独自の技術革新に遅れを取らないサイバー犯罪者にとって、より大きなチャンスをもたらします。
applicationsが物理データセンターのモノリシック アプリから今日の高度に分散された AI アプリへと進化するにつれ、高性能なアプリ セキュリティとアプリ配信機能を単一のプラットフォームに統合する新世代の ADC が必要になっています。
ますます複雑化、拡大する脅威の状況は、一貫したアプリと API の配信とセキュリティを提供できるプラットフォームが不足していることでさらに複雑化しています。 application配信コントローラ (ADC) は、アプリケーション配信機能を有効にするスタックで中心的な役割を果たしてきましたが、今日の環境の変化するニーズを満たすために ADC を進化させる必要があります。 これらの要因により、アプリ セキュリティとapplication配信サービスを組み合わせて、多様な IT エコシステム全体にわたってより完全な保護と、よりシンプルで統合された管理を提供する、新しい、より包括的な戦略に対する需要が高まっています。
1940 年代の最も初期のアプリから始めて、どのようにしてこの地点に到達したかを探ってみましょう。
applications1.0: モノリシック アプリと 3 層アプリ
1940 年代や 1950 年代の初期のコンピューターでは、今日私たちが理解しているようなapplicationsは実際には採用されていませんでした。 これらは主に機械語とパンチカードを使用してプログラムされていました。 最初のapplications(いわゆるapplications1.0) は、給与計算、在庫管理、基本的なデータ処理などのタスクを処理するために設計されたモノリシックapplicationsを実行する、1960 年代と 1970 年代の集中型メインフレーム コンピューターの傍らで成長しました。 これらの初期のapplicationsは、単一のコードベース、つまり分離されたデータ センターまたは企業オフィス内で動作する非常に大規模な単一コード ブロックに限定されていました。 高い壁と堀で守られた丘の上の遠く離れた城を想像してください。労働者はそこへ行き、FORTRAN や COBOL などのコンピュータ言語を使用して集中化されたコンピューティング リソースにアクセスします。
モノリシックapplicationモデルの進歩は、3 層applicationsによってもたらされました。3 層アプリケーションでは、コンピューティング リソースが 3 つの異なる機能層に分割され、各層に個別のapplicationsが相互接続されています。 プレゼンテーション層、つまりユーザー インターフェイスは、従業員の生産性向上ソフトウェア (WordStar など) などのデスクトップapplicationsによって制御されていましたが、ビジネス ロジック層には、ユーザー要求を処理して計算を実行するapplicationサーバーが含まれていました。 データ層、つまりデータベースはデータを保存および管理します。
3 層applicationsはモノリシック アプリケーションよりも高いモジュール性と柔軟性を提供しましたが、このモデルは依然として物理的なデータ センター インフラストラクチャとオンプレミスのリソースに依存していました。 医療、銀行、政府などの一部の業界では、レガシー システムが厳格な規制要件を満たし、ミッション クリティカルなapplicationsにダウンタイムが許容されないため、モノリシックおよび 3 層applicationsが依然として標準となっています。
applications2.0: クラウド、マイクロサービス、コンテナ
1990 年代の電子商取引の台頭により、ドットコム時代が到来しました。 applicationサービス プロバイダー (ASP) は、World Wide Web 上でクラウドのような Web ホスティング サービスを提供しました。これにより、企業は独自のインフラストラクチャを構築することなく、HTML Webapplicationsを起動できるようになりました。 Web アプリは、ユーザーがダイヤルアップまたはブロードバンドにアクセスできる場所であれば、世界中で利用できました。 これらのapplicationsは3 つのレイヤーに分割されました。 消費者は自宅のコンピュータでインターネットと Web ブラウザ ソフトウェアを使用して、ASP サイトでホストされている Webapplicationsにアクセスし、ASP のデータベース サーバーが顧客データの購入と保存を処理していました。 ウェブ アプリは依然としてオンライン小売業で主流であり、ウェブ上での電子商取引事業の運営を推進する上で重要な役割を果たしてきました。
2010 年代初頭はクラウドの混乱の時代であり、多くの予言者がオンプレミス データ センターの終焉とクラウド ベースのコンピューティングの台頭を予測していました。 すべてのコンピューティングをクラウドに移行するという議論の中で、多くのアプリがクラウド環境で稼働するように最新化されるか、クラウド自体で開発されました（クラウド ネイティブapplications）。
これらのクラウド ネイティブ アプリは、クラウドのスケールとパフォーマンスに合わせて最適化されており、マイクロサービス アーキテクチャに基づいてゼロから構築されており、アプリの進化に新たなパラダイム シフトをもたらしました。 マイクロサービス ベースのapplicationsは、もはやスタンドアロンの統合されたコード ブロックではなく、それぞれが単一の機能を実行し、API を介して他のマイクロサービスと通信できる、独立して展開可能な小さなマイクロサービスから組み立てられました。 モジュール式マイクロサービスは、ポータブル コンテナー内のapplicationsにオーケストレーションされました。ポータブル コンテナーは、自己完結型で、さまざまな環境にわたって一貫して動作できる仮想化されたコンピューティング インスタンスです。 マイクロサービス ベースのapplicationsは、モノリシック アプリや 3 層アプリに比べて、アプリ開発の高速化、スケーラビリティの向上、柔軟性の向上、サービスの再利用性など、多くの利点があります。
ただし、これらのコンポーネント マイクロサービスは、パブリック クラウド ライブラリやその他のリモート プラットフォームから取得され、API やその他の通信メカニズムを介して中継されます。 これらの分散した要素は管理が難しく、API を公開するとアプリの攻撃対象領域が拡大し、データ転送中のネットワーク侵入やサードパーティ ライブラリの潜在的な脆弱性が生じる可能性が高まりました。
applications3.0: 分散型アプリと AI
今日、applicationsは新たなパラダイムシフトを経験しています。 データ センターの終焉という予測は誇張されたもので、今日の組織のポートフォリオの多くは、ハイブリッド環境で実行され、オンプレミス、エッジ、クラウド リソースから引き出される従来のアプリと最新のアプリが混在しています。 これにより、アプリと API の配信とセキュリティを、その場所に関係なく統合するための一貫したプラットフォームの必要性がさらに複雑になります。
さらに、アプリはますます複雑になり、クラウドベースのマイクロサービスだけでなく、リアルタイムのデータフローや新しい形式の入力にも依存するようになっています。 典型的な旅行ウェブサイトのapplicationについて考えてみましょう。 選択した目的地に関する魅力的な写真やコンテンツに加えて、ホテルの部屋、航空便、レンタカーを予約するためのリアルタイムの API アクセス エンジン、ライブ天気予報へのリンク、インタラクティブなマッピング機能もあります。 これらの最新のapplicationsは、高度に相互接続され、複数のソースから取得され、動的であり、ハイブリッド クラウドと分散環境からのデータを利用して堅牢な顧客エクスペリエンスを提供します。
すでに高度に統合されているapplicationsに AI が追加されると、複雑さと攻撃対象領域は増加するだけです。 相互接続されたネットワークやデバイスからのデータを活用する AI 搭載サービスには、推奨エンジンやチャットボットが含まれる場合があります。旅行ウェブサイトでは、リアルタイムのユーザー プロファイルと予測分析に基づいてパーソナライズされた目的地やアクティビティを提案したり、動的な価格設定アルゴリズムの監視を提供したりする場合があります。
AIapplicationsは膨大な量のデータを処理し、複雑なトラフィック パターンを採用して、AI ファクトリーに格納されているエンタープライズ データ ストアや AI モデルに対して大量かつ頻繁なリクエストを行います。 AI ワークロードは通常、パブリック クラウド、エッジ デバイス、ハイブリッド システムなどの分散インフラストラクチャに展開されるため、applicationsはデータ セキュリティとプライバシーのリスク、AI モデルに対する敵対的攻撃、インフラストラクチャの脆弱性にさらされます。 こうした課題により、どこに展開されていても最新の AI アプリとワークロードをサポートする高性能なトラフィック管理およびアプリ配信サービスと統合された、API が豊富なapplicationsに対する包括的なセキュリティを提供する必要性が高まっています。
applicationの進化: 機能の向上、複雑さの増大
applicationsの歴史は、多くの点でコンピューティング自体の歴史であり、1940 年代の基本的な数学計算の解決から、AI を搭載し、無数のリモート システムからの入力によって駆動される今日の複雑で動的なアプリへと進化してきました。 applicationの歴史は、コンピューティング ハードウェアのアクセシビリティと普及の増加にも反映されています。 applicationsは、専門家しか操作できない部屋サイズのメインフレーム コンピューターから、個人使用や娯楽用のグラフィカル インターフェイスを備えたデスクトップ コンピューターやラップトップ、さらにはどこからでもアクセスでき、タッチ スクリーンと音声コマンドの両方で動作する Web アプリやモバイル アプリによって駆動されるモバイル デバイスへと移行しました。
しかし、ますますインテリジェントかつ動的になるこれらのapplicationsは、さまざまなセキュリティ リスクの影響を受けやすいネットワークと接続に依存しており、常に進化するセキュリティ緩和策と分散環境向けに最適化された ADC が必要です。 必要なのは、分散環境全体で動作する従来のアプリ、最新のアプリ、AI を活用したアプリのこの新しい環境をより適切に管理するために、重要なアプリ配信機能とセキュリティ機能を統合することです。 ADC はこれを管理するのに適したテクノロジーであると考えています。 しかし、この役割を果たすには、ADC が進化し、今日の分断されたデジタル エコシステムに関連する運用上の複雑さとリスクを軽減する必要があります。
詳細については、シリーズの以前のブログ投稿「進化するアプリケーション インフラストラクチャの要求を満たすための ADC の再構築」をお読みください。また、applicationアーキテクチャの変化に合わせてapplicationセキュリティがどのように進化してきたか、そしてこれがなぜ新しい時代の ADC を必要とするのかを学ぶ次のブログもお楽しみに。