インフラストラクチャ チームからアプリケーション チームへ、コントロール権がシフトします。市場投入までのスピードを改善するため、DevOpsでは開発および保守するアプリケーションを支えるインフラストラクチャを制御する必要があります。

DevOpsがプロビジョニングにかかる時間を短縮します。最新のアプリケーション インフラストラクチャは自動化されている必要があり、プロビジョニングまでの時間を飛躍的に短縮しなければなりません。そうしないと、特に重要な修正や機能強化の導入が遅れる恐れがあります。

インフラストラクチャがソフトウェアをハードウェアから切り離します。ソフトウェア ディファインド インフラストラクチャ、Infrastructure as Code、およびコンポーザブル インフラストラクチャはすべて、コモディティ化されたハードウェアまたはパブリック クラウド コンピューティング リソース上でプログラム可能なソフトウェアが実行される新しい導入アーキテクチャを表しています。

企業は、すべてのアプリケーション トラフィックを管理する高度な機能を備えた中央ロード バランサーを採用し、導入時のスループットと安定性を強化しています。企業環境の入口に設置されたF5アプライアンスが手間のかかる作業を引き受け、ローカル トラフィック管理、グローバル トラフィック管理、DNS管理、ボットからの保護、DDoS攻撃対策、SSLオフロード、IDおよびアクセス管理などの高度なアプリケーション サービスを提供します。

DevOpsチームは、新しいアプリの導入、既存アプリへの新機能の追加、スケールの改善のため、ロード バランサーの変更を実装しなければならいことがめずらしくありません。従来のプロセスでは、DevOpsはロード バランサーの構成変更および本番環境への再デプロイを、インフラストラクチャおよび運用（I&O）チームに頼らなければなりません。

I&Oチームは、集中型ロード バランサーを使用して数百、数千にも及ぶアプリケーションをサポートしなければならないため、通常は慎重なアプローチをとります。万が一エラーが発生すると、企業のアプリケーション全体のパフォーマンスとセキュリティに壊滅的な被害を及ぼしかねません。そのため、I&Oチームはまずテスト環境で変更を行い、最終的に本番環境に展開します。このような運用手順は、変更による悪影響がアプリケーション ポートフォリオに及ばないようにするうえで効果的ですが、手順に従うことで、開発とイノベーションのペースが遅くなってしまうことがあります。

F5 BIG-IPインフラストラクチャをNGINXで拡張するには、3つの一般的な導入モデルがあります。

• F5アプライアンスの背後にNGINXをデプロイして、DevOpsに適した抽象化レイヤーとして機能させます。
• アプリケーションごと、さらには顧客ごとにNGINXインスタンスをプロビジョニングします。
• クラウドネイティブ アプリケーションのマルチクラウド アプリケーション ロード バランサーとしてNGINXを実行します。

プログラム可能なNGINXロード バランサーは軽量であるため、消費するコンピューティング リソースが非常に少なく、インフラストラクチャに余計な負担をかけることはほとんどありません。

NGINXのロード バランサーでアプリケーションのパフォーマンスを向上させる方法について詳しくは、こちらをお読みください。