今日の企業は、ネットワーク内でのapplicationの認識と管理のレベルをさらに高めることを要求しています。 データ センターはapplicationsとサービスを提供するために構築されますが、依然として大規模なネットワークとして管理され、個々のネットワーク コンポーネントは分離された単一ポイント デバイスとして管理されます。 たとえば、従来のルーターは、IP トラフィックを空虚な空間でルーティングするだけのものとして管理されます。 ただし、applicationsが期待どおりに動作するには、そのルーターに完全に依存します。 現在、ほとんどの企業では、組織およびデータ センター ネットワークは、個々のグループによって管理される一連の個別のオブジェクトとして認識されていますが、それらのコンポーネントが互いに、またインフラストラクチャの残りの部分とどのように関連しているか、またはそれらのコンポーネントがすべて連携してユーザーにapplicationsを配信する方法についての包括的な見解はありません。
インフラストラクチャ全体を個別のコンポーネントとして管理すると、ユーザーやデータセンター内の他のサービスへのapplication配信を適切に管理および制御するために、さまざまなグループ内で可動部分が多すぎるため、IT の妨げになります。 その結果、IT 部門には、ネットワーク レベルでどのコンポーネントが何を実行しているかを詳細に記述した複雑なスプレッドシートが存在することがよくありますが、それらのコンポーネントがapplicationsにどのように結び付けられているかについての情報はありません。 インフラストラクチャのこの複雑で孤立したビューは、インフラストラクチャ コンポーネントがどのように連携してapplicationとなります。
データ センターに対するこの時代遅れの考え方は、依然として多くの組織の管理に影響を与えていますが、applicationsは進化しており、中心的な位置を占めるようになっています。 この変化により、企業の IT 部門は、デバイスやオブジェクトから始めてコンポーネントを組み合わせてapplicationを提供するのではなく、アプリケーション中心の視点で管理を開始せざるを得なくなりました。 この変化は、主にクラウド コンピューティングとサービスとしてのソフトウェア (SaaS) の導入の推進によって推進されており、applicationが最も重要なコンポーネントとなり、インフラストラクチャがコモディティ化されます。
しかし、applicationsの管理は、わずか 5 年前と比べてはるかに複雑になっています。 バックエンドでは、applicationsはエンタープライズ データ センターの内外を問わず、どこにでも配置できるようになりました。 管理者は、異なるクラウド プロバイダー間でアプリを展開し、SaaSapplicationsとして実行し、さらには異なる大陸のデータ センター間で地理的に分散させることもできます。 また、仮想化により、データ センターは 1 対 1 のサーバー対アプリケーションのモデルから離れつつあり、リソースは縮小する一方でサービスは拡大し続けています。 applications自体も、よりデータが豊富なモデルに移行しており、API を使用したアプリケーション間通信に依存するようになり、システムおよびネットワーク リソースの要件が増加しています。 しかし、アプリが主流となっているエンタープライズ IT の急速なコンシューマ化にもかかわらず、基本的なインフラストラクチャは適応していません。 application配信の管理は、ネットワーク コンポーネントだけの問題ではなく、コンテキストや、ユーザーがapplicationsとリアルタイムでどのように対話するかを理解することも重要です。
F5 iApps は、データ センターでのapplication配信をより効率的に設計できる、BIG-IP システムの強力な新機能セットです。iApps は、データ センターの内外およびデータ センターを超えてapplicationsを管理および配信する方法に対する総合的なアプリケーション中心のアプローチに基づいています。iApps テクノロジーは、ビジネスをサポートするapplicationサービスに関するコンテキスト ビューと高度な統計情報を提供するフレームワークを BIG-IP システム内に提供します。 これにより、application、セキュリティ、ネットワーク、システム、運用担当者は、application配信サービスを統合、簡素化し、より効果的に制御できるようになります。
iApps は、applicationの配信に必要な多数の個別のコンポーネントを抽象化し、これらのリソースを特定のアプリに関連付けられたテンプレートにグループ化します。 これにより、管理者がネットワーク上の個別のコンポーネントを管理する必要性が軽減されます。
ほとんどの企業の IT 部門では、ネットワークのさまざまな部分の管理責任をさまざまなグループに委任しています。 IP アドレス、ルーティング、DNS はネットワーク チームによって管理され、物理サーバーと仮想サーバー、OS ビルド、ウイルス管理はサーバー チームが所有し、API のやり取り、application標準、アクセス権はapplicationとセキュリティ チームが所有します。 その結果、通常、IT 部門には、「組織内で電子メールを配信するにはどのようなコンポーネントが必要で、それぞれのコンポーネントはどのように構成されているか」という質問に答えられる単一のグループは存在しません。 単純に、調整されていない可動部分が多すぎるのです。
iApps は、すべてをアプリケーション中心の観点から管理することでこれを変更します。 ノード、applicationモニター、プールなど、iApps を使用すると、これらのapplication配信サービス コンポーネントをまとめてクラスター化し、applicationワークフローの一部として管理できます。 これにより、application者とネットワーク管理者は、主要な管理タスクを自動化することで、applicationsを正常に配信するために必要なインフラストラクチャ コンポーネントを簡単に定義できます。
application配信サービスの設定と管理に加えて、iApps は追加のapplication配信リソースの導入などの自動化タスクを定義できます。iApps は、F5 の iRules エンジンを介して AAA セキュリティ インフラストラクチャに負荷分散ルールを適用することから、F5 の顧客向けサポート ポータルである iHealth にapplicationの診断データと可視性データを公開することまで、BIG-IP システムのさまざまな部分に依存して、application配信のすべての部分を管理します。
iApps では、すべてのapplication配信サービス コンポーネントがバンドルされ、applicationの拡張機能として扱われます。 たとえば、新しい SharePointapplicationには、SharePoint の Web フロントエンド、検索、およびデータベース コンポーネントの状態をチェックする特定のヘルス モニターが必要になります。 従来、これらのコンポーネントは個別に割り当てられ、管理される必要があり、エラーが発生する余地があり、展開時間が大幅に増加していました。 SharePoint 用の iApp を使用すると、これらすべての部分がapplication自体のコンポーネントとなり、一元化された 1 つの場所で展開および管理できるようになります。
内部的には、iApps は複数の個別のコンポーネントで構成されており、各コンポーネントはapplication配信インフラストラクチャの一部を管理する役割を担っています。 これらのコンポーネントは結び付けられ、統合された BIG-IPapplication配信コントローラ (ADC) の一部となります。
iApps は、配信中にapplicationの任意の部分に適用できる iAppsapplicationサービスを作成することにより、applicationコンポーネントをまとめて配信します。 たとえば、SharePoint 用の iAppsapplicationサービスは、最初は BIG-IP Local Traffic Manager (LTM) ポリシーと SSL 関連の iRule スイートに関連付けることができます。 その後、管理者は、単一の iApps ボックスをオンにすることで、BIG-IP Access Policy Manager (APM) アクセス ポリシーを同じ iApps Application Service for SharePoint に関連付け、それをネットワーク全体に再配布できます。iApps Application Service は、application配信インフラストラクチャ全体を把握し、applicationとネットワークの依存関係を 1 つの統合システムにまとめることで、運用コストを削減します。
オブジェクト指向プログラミングがapplicationsの記述方法を変えたのと同様に、iAppsapplicationサービスは、一般的なapplication配信サービスをapplicationの「前」に配置する方法のパラダイムを変えます。iAppsapplicationサービスは、配信中のどの時点でもapplication配信チェーンのどの部分にも適用できるため、組織はコンテキストに基づいて、applicationのどの部分がどのサービス コンポーネントによっていつ影響を受けるかを選択できます。iApps ポリシーは、負荷分散構成の構築だけに限定されません。 BIG-IP 統合 ADC プラットフォーム全体の一部として、iApps ポリシーには、BIG-IP APM を使用してapplicationにユーザー アクセス ポリシーを割り当てるなど、高度な BIG-IP システム モジュールと機能の構成設定も含めることができます。
テンプレートへのアクセスは、iApps の最も魅力的な利点の 1 つです。 applicationテンプレートはバージョン 10 以降、BIG-IP LTM で使用可能でしたが、新しいapplicationsの初期展開フェーズに限定されていました。 さらに、実行中の構成を後で変更することもできませんでした。
iApps テンプレートは、applicationサービスの導入と管理に柔軟かつ簡単に使用でき、すべての BIG-IP システム モジュールにわたるapplicationsの構築、管理、監視のための単一ポイント インターフェイスとして機能します。 管理者が既存のテンプレートを使用して新しい iApps 構成を構築すると、その結果得られる構成はデバイス サービス クラスタ内のすべての BIG-IP デバイスで使用され、F5 Analytics に必要な情報が提供されます。
iApps テンプレートを使用すると、BIG-IPシステム構成と管理だけでなく、IT 内の複数のグループがapplicationの配信と管理に必要なすべての設定を定義することもできます。 多機能なアーキテクト チームは、IP アドレス情報を提供するネットワーク チームから、キャッシュと圧縮ポリシーを構成するapplicationチーム、ユーザーとリージョンのアクセス ポリシーを定義するセキュリティ チームまで、applicationパラメータを定義し、iApps テンプレートで手順を展開できます。 その後、テンプレートを IT 運用部門に提供し、テストまたは実稼働の BIG-IP デバイスに展開できます。 一度確立された iApps テンプレートは、該当するグループによって変更でき、ビジネスおよび IT のニーズが進化するにつれて組織全体で再利用できます。
iApps のもう 1 つの重要な利点は、ADC およびインフラストラクチャ全体に新しいアプリを展開する際の「専門家」の障壁を取り除くことです。 application所有者は、可用性のために個別の BIG-IP LTM デバイスを導入したり、セキュリティのために BIG-IP ASM デバイスを導入したりする必要がなくなりました。 iApps を使用すると、application所有者は iAppsapplication構成の一部としてそれらのサービスを追加するだけで、BIG-IP プラットフォームが適切なサービスとそのサービスに関連するすべての可動部分を展開します。 application所有者は通常、BIG-IP システム アプライアンスを通じて配信されるapplicationsの構成に多大な時間を費やします。 iApps テンプレートを使用すると、事前の作業を組織全体で再利用できます。 カスタマイズ可能な iApps テンプレートを使用すると、applicationポリシーを一度微調整して一度テストし、その後、構成をエクスポートして追加の BIG-IP デバイスや他の IT 組織と共有することでその作業を再利用できるため、組織は運用コストを節約できます。
iApps 構成ポリシーは、BIG-IP システム間およびユーザー間で移植できるように設計されています。iApps テンプレートはアプリケーションごとにエクスポートでき、applicationネットワーク全体で再利用できます。 さらに、F5 のコミュニティ サイトである DevCentral の iApps エコシステムを通じてエクスポートおよび共有することもできます。ここで、BIG-IP システム管理者と開発者は、他のapplications用に独自の iApps テンプレートを作成、変更、共有したり、既存の iApps テンプレートを調整したりできます。
F5 は、DevCentral の iApps エコシステムを通じて、新しいapplications用の公式 iApps テンプレートを定期的にリリースしています。これにより、Microsoft、IBM、Oracle などの F5 パートナーによる新しいapplicationsのエンジニアリング作業や、金融、政府、医療などの垂直市場に特化したapplicationテンプレートが活用されます。
iApps ポリシーの大部分は、applicationsの配信に必要なトラフィック管理コンポーネントの構成に向けられています。 ただし、BIG-IP プラットフォームにはapplicationsを監視するツールも含まれており、リアルタイムのapplicationパフォーマンス統計も提供されます。 また、application応答時間、ネットワーク遅延、application全体、仮想サーバー、プール、ノードの接続統計などの診断およびトラブルシューティング情報も提供します。
従来の監視ツールとは異なり、F5 Analytics はapplicationレベルでパフォーマンス データを収集し、その情報を個々のインフラストラクチャ コンポーネントではなくapplication自体にバインドします。 application所有者は、applicationからapplicationサーバー、さらにはネットワークに至るまでのパフォーマンスを監視できます。 これにより、組織は、applicationの応答、ネットワークの状態、およびユーザーのコンテキストに基づいて、applicationのパフォーマンスをリアルタイムで正確に監視できます。
F5 Analytics は、BIG-IP システムからの統計データとログデータを活用します。 このデータを取得して JSON オブジェクトとしてフォーマットし、F5 BIG-IQ などのデータ コンシューマーや Splunk などのapplicationsで使用できるようにエクスポートします。
F5 Analytics を使用すると、エクスポートするデータの複数のカテゴリを設定できます。 Splunk などのデータ コンシューマーの場合、データが送信されるネットワーク エンドポイントを構成できます。
データ センターのハードウェア デバイスは通常、アクティブ/スタンバイ (1 つのシステムが 100% の作業を管理し、別のシステムは最初のシステムがオフラインになるまで待機してから作業を引き継ぐ) またはアクティブ/アクティブ (両方のシステムがデバイス間でワークロードを分散) のいずれかの冗長ペアで実行されます。 どちらの冗長構成も、ミッションクリティカルなハードウェアの導入におけるベストプラクティスですが、1 つの大きな設計上の欠陥があります。この冗長アーキテクチャは、デバイス全体の障害を前提としています。
より良いアプローチは、デバイス全体がオンラインかダウンしているかではなく、application配信中の任意の時点でデバイスが何を実行しているかに基づいて、フォールト トレラント アーキテクチャを構築することです。 BIG-IP デバイスは、applicationレベルでスケーラブルでフォールト トレラントなアーキテクチャを実現し、デバイス間のapplication構成のフェイルオーバー保護を実現します。 BIG-IP デバイス サービス クラスターは、次の 2 つの異なる構成オプションで実行されます。 同期のみモードと同期フェイルオーバー モード。
BIG-IP デバイス サービス クラスターの同期のみモードを使用すると、複数の BIG-IP ハードウェアおよびソフトウェア アプライアンスが、アプリケーション固有の配信構成とテンプレートをデバイス間で動的に共有できます。 これにより、何か変更があったときに管理者がデバイス構成全体を手動で更新する必要がなくなります。 BIG-IPapplicationポリシーはハードウェア構成から分離されているため、管理者は BIG-IP 構成ファイル全体を複製するのではなく、デバイス間でapplicationとネットワーク情報を同期できます。 これにより、IT 部門は異なる構成のさまざまな BIG-IP デバイスを実行しながら、それらのデバイス間で固有のapplication構成とポリシーを同期できるようになります。 たとえば、BIG-IP Application Security Manager (ASM) ポリシーは、各デバイスの他のapplicationポリシーに影響を与えずに、またセキュリティ チームが各デバイスに個別の BIG-IP ASM ポリシーを手動でインストールする必要もなく、BIG-IP デバイス間で同期できます。
デバイス間の同期に加えて、application構成では、デバイス間でアクティブなアプリケーション トラフィックとライブapplicationトラフィックをフェイルオーバーできるため、アクティブ/アクティブの概念がapplication層に適用されます。 BIG-IP デバイス サービス クラスターの同期フェイルオーバー モードは、アクティブ/アクティブの 1:1 概念を N:1 に拡張し、リソースの制約と可用性に応じて、必要な数のアクティブ デバイスがapplication負荷を共有できるようになります。 これは、必要性と冗長性に基づいてディスクの数を決定できる RAID 5 ストライピングの考え方と非常に似ています。
より多くのapplication配信リソースが必要な場合、管理者はアクティブな BIG-IP デバイスをデバイス サービス クラスターに追加できます。 クラスターは、新しいデバイスがオフラインになった場合に備えて、2 番目の専用スタンバイ デバイスを追加することなく、全体的なapplication配信負荷の一部を引き受けます。 BIG-IP デバイス サービス クラスターを使用すると、グループ内のすべての新しいデバイスは、デバイスの 1 つがオフラインになった場合に追加のapplication負荷に対応できるため、ある程度の冗長性を持ちます。 デバイス サービス クラスターの一部となる BIG-IP デバイスが増えるほど、利用可能なすべてのデバイス間でapplicationの負荷をより効率的に分散できます。
iApps の 2 つの重要な原則は、可視性と制御です。iApps は、インフラストラクチャ全体にわたってそれぞれ前例のないレベルの可視性と制御を提供します。ただし、可視性と制御をどの程度提供するかは、ユーザー、applications、およびデータ間の調整された仲介層を使用して、すべてのapplication配信ロジックをすべての双方向applicationトラフィックに動的に適用できる戦略的なポイントに配置するかどうかに依存します。 このレイヤーは、現在の場所に関係なく、すべてのapplicationsとデータに使用できる一貫したインターフェースとサービス セットを提供します。 このレイヤーは、コンテキスト(誰がどこから何になぜアクセスしているか)をインテリジェントに理解することで、ユーザー、applications、データ間の最適な接続を決定します。 さらに、コンテキストを深く理解することで、基盤となるapplicationとデータ要素に現在のリソース要件を通知し、インフラストラクチャにリアルタイムで適応するように指示して、applicationとデータへのアクセスを最適化します。
application情報のこの戦略的なフローは、iApps 構成の一部になります。 iApps テンプレートを使用した初期構成は、applicationを理想的なアーキテクチャで配信する方法に基づいています。applicationは、配信ライフサイクル全体を通じて iApps テンプレートと BIG-IP デバイス サービス クラスターを通じて管理され、何をどこに配信するかが示されます。 F5 Analytics は、理由の部分を提供し、その情報を IT 部門に報告して分析します。iApps は戦略的な制御ポイントにあり、このようなきめ細やかで広範なapplication配信管理を可能にする唯一の場所です。
組織がよりモジュール化されたクラウドおよび SaaS モデルに移行するにつれて、インフラストラクチャの構築よりもapplicationsの管理がより重要になりました。 より機敏なモデルへの移行によって得られるメリットの多くは、インフラストラクチャの管理とは関係ありません。しかし、アプリケーションは依然としてインフラストラクチャに結びついているため、クラウドおよび SaaS 環境でのapplicationの展開、パフォーマンス、および可用性の管理は困難な場合が多くあります。iApps は、applicationの制御、可視性、および管理を、データ センターを超えてapplicationsとサービスを提供するために必要なインフラストラクチャに結び付けます。
iApps は、ネットワークを、分離されたコンポーネントで構成される静的リソースから、applicationまたはサービスに直接関連付けられた、統合された柔軟性と回復力のあるリソース プールに変換するアーキテクチャをサポートします。 この変革により、application層での迅速なネットワークの展開、統合、管理、および可視性が可能になります。iApps は、ネットワークをapplicationに適合させることにより、application配信インフラストラクチャ全体を完全に制御します。 結果として、迅速な導入と単一ポイントの機能により運用コストが削減されます。 F5 iApps を使用すると、組織は戦略的な制御ポイントでセキュリティ、高速化、可用性サービス用の共通の、再利用性の高いカタログを作成し、F5 BIG-IP デバイスの組織の俊敏性と効率を大幅に向上させることができます。