ブログ

オープンソーススポットライト: F5、Red Hat OpenShift で A/B テストとブルー/グリーン デプロイメントを実現

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2018年2月22日公開
HALF-探索コンテナ-soad18
  • 今日のペースが速く、デジタル化されたデータ センターでは、トラフィックを分散するだけでなく、誘導する機能も必要です。
  • 「State of Application Delivery 2018」によると、回答者の 21% が Red Hat OpenShift を使用しています。
  • A/B テストとブルー/グリーン デプロイメントは、リクエストをインテリジェントに送信することでビジネス目標と運用目標の達成を支援する有益なデプロイメント パターンです。 
  • F5 Container Connector は、BIG-IP とコンテナ オーケストレーション環境のリアルタイム コントロール プレーンの統合を容易にし、Red Hat OpenShift を使用した A/B テストとブルー/グリーン デプロイメントを可能にします。
  • Red Hat OpenShift にはネイティブの Kubernetes ディストリビューションがあるため、OpenShift の F5 統合では、 DockerhubまたはGithubで入手できるKubernetes の F5 統合( k8s-bigip-ctlr ) と同じコントローラーが使用されます。

長い間、負荷分散プロキシの役割は、すべてのリクエストが迅速に応答されるようにすることだけでした。 プレーンオールドロードバランシング（POLB）。 POLB はアルゴリズムを使用して、リソース プール全体にリクエストを分散します。 ラウンドロビン。 接続が最も少ない。 最速の応答。 これらのアルゴリズムの焦点は常に宛先にあります。つまり、応答を迅速に提供し、せっかちなユーザーに返すために、利用可能で高速なリソースを選択することです。 目標は可用性であり、POLB は確かにその期待に応えます。

これは確かに便利ですが、最新のアプリケーションをスケーリングするには、適切なアルゴリズムを選択するだけでなく、アーキテクチャを有効にすることが重要です。 最新のアプリケーション、特にコンテナ環境にデプロイされたアプリケーションを拡張するには、リクエストを分散するだけでなく、直接リクエストする機能も必要です。 目標は、インフラストラクチャとビジネスの両方の効率性と俊敏性を実現することですが、これは POLB では実現できません。 ビジネスのニーズに合わせて迅速に運用を進めるのに役立つ A/B テストやブルー/グリーン デプロイメントなどの最新のデプロイメント パターンをサポートするには、POLB を超える必要があります。

AB-BG-説明

そのためには、リクエストを配布するだけでなく、クライアント、ネットワーク、および動作している環境から得られるさまざまな情報に基づいてリクエストを誘導できるスマート プロキシが必要です。 必要に応じて、L7 プロキシを使用します。 何と呼ぶにせよ、リクエストを上から (HTTP) から下から (IP) まで解析して理解し、リクエストをどこに送信すべきかを決定できるほどスマートです。

この投稿では、A/B テストとブルー/グリーン デプロイメント パターンを簡単に構成および実装する機能に焦点を当てています。どちらも、リクエストを適切なリソースにインテリジェントに送信するためにプロキシでのスマートさを必要とします。

コンテナ化された環境では、コンテナ オーケストレーション環境 (COE) と統合する機能と、トラフィックをインテリジェントに誘導する機能が必要です。

それが、Red Hat OpenShift 向け F5 Container Connector が現在提供しているものです。 OpenShift とF5 BIG-IP間のコンテナ化された「接着剤」により、トラフィックをアプリケーションのあるバージョンから別のバージョン (ブルーグリーン) にインテリジェントに移行したり、同じアプリケーションの 2 つのバージョン間の比較ベースのテストを可能にして、企業が実際の訪問者のデータに基づいて意思決定を行えるようになります。 

両方の詳細についてはドキュメントで読むことができます。または、 DockerhubまたはGithubで F5 Container Connector のコピーを入手して、今すぐこれらの高度なデプロイメントを開始してください。