ブログ

DevOps の世界における F5 の位置づけ

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2015 年 11 月 16 日公開

カンファレンスで講演した後、F5 がこのレースでどのような立場にいるのかとよく聞かれます。 最近では、そのトピックは通常、DevOps または何らかの形で DevOps に関連しています。

現実には、負荷分散などのアプリケーション関連のサービスは、アプリケーション、つまり、アプリケーション ネットワークを構成する、より俊敏でソフトウェア主導の自動化された環境へと引き寄せられつつあります。 ここでは、キャッシュ ( memcachedや redis など)、データベース、コンテナーなどのコンピューティングおよびアプリケーション中心のシステムが、大量の自動化とオーケストレーションに依存する CI/CD (継続的インテグレーション/継続的デリバリー) 方法論を使用して導入されています。

F5、より具体的には BIG-IP は、負荷分散とほぼ同義です。 私たちは今世紀に入る前からこれを行っており、今日他のロード バランサーで使用されている多くのコア ロード バランシング アルゴリズムと概念は、実際にここで発明されました。 したがって、私たちが負荷分散アプリケーションについて多少の知識を持っていると言うのは控えめな表現です。 そして、私たちはそれを、カスタムビルドのハードウェアまたはクラウドに展開されたソフトウェアを使用して行います。 

このソフトウェアはAPIで有効化されています。iControl と呼ばれ、SOAP と REST の両方の形式で利用できるため、プログラム的に便利です。 この API を使用すると、誰でも (私でも)、あらゆるアプリケーションに対して BIG-IP の負荷分散 (およびその他の) サービスをプロビジョニング、構成、制御できます。

さて、先ほど申し上げたように、アプリケーションに適したサービスは日々アプリケーションへと移行しています。 スケーラビリティ（負荷分散）は、そのようなサービスの 1 つです。 これは今日、あらゆるアプリケーションにとって重要なコンポーネントであり、最新のアプリケーションを構成するマイクロサービスにとってもますます重要なコンポーネントとなっています。 Microsoft が 2015 年にサービスのスケーリングに関する論文で指摘したように、

多様で多数のマシンが存在する場合、開発者はアプリケーションのワークロードのパーティション分割と、各パーティション分割スキームをサポートするために必要なネットワーク接続について検討する必要があります。 接続性に関して非常に重要な側面が、外部ユーザーとサービス自体の間に存在します。 最も小規模なサービスを除き、FE ボックス上の着信接続の負荷を分散するには、何らかの形式の負荷分散メカニズムが必要です。 多くのメガサービスにはサブサービスもあり、それら自体も負荷分散されています。[強調追加]

http://research.microsoft.com/pubs/241970/MSR-TR-2015-29%20V1.1.pdf

負荷分散は後付けのものではありません。ユーザーを満足させ、ビジネスを継続させるために必要な規模 (および信頼性) を実現するために、今日のアプリケーションやサービスに自然に組み入れられたものです。 これにより、負荷分散が全体的なアプリケーション アーキテクチャの一部であることがますます真実になってきています。 実際、アプリケーション アーキテクチャにコンポーネントを追加すると、克服する必要がある問題や統合の問題が発生する可能性があるため、そうあるべきです。 アプリが本番環境に移行した後ではなく、移行する前に対処する必要がある問題。 運用環境で問題を発見して修正するのに必要な時間は、開発環境やテスト環境よりも何倍も長くなります。そのため、アプリケーション アーキテクチャに負荷分散を組み込むと、運用環境やユーザーの手元への移行がスムーズ (かつ迅速) になります。

しかし、それは、開発環境とテスト環境での統合と配信をますます推進する DevOps ツール チェーンによって自動化されたプロセスにロード バランサーを統合できる必要があることを意味します。 これは、インフラストラクチャをコードとして扱い、そのプロビジョニングと構成を自動化することを可能にする API やテンプレートなどの包括的なプログラム ツール セットを提供することを意味します。 これは、iControl (REST または SOAP) が F5 に対して行うことです。

BIG-IP は、ほぼすべての言語 ( Powershell 、 Python 、Perl など) を使用したネイティブ API を利用するか、 ChefやPuppetなどのフレームワークや Ansible やSaltStackなどのツールを使用することで、展開、テスト、リリースの各フェーズで DevOps に統合できます。アプリケーション サービス構成を記述するテンプレートであるiAppsは、コードのように扱うことができます。Github に保存し、そのまま取得して展開することも、スクリプトでカスタマイズすることもできます。

基本的に、ロード バランシングなどの BIG-IP アプリケーション サービスや、そのアプリケーション パフォーマンスおよびセキュリティ サービスの多くは、CI/CD プロセスの早い段階で統合し、これらの重要なサービスが期待どおりにアプリケーションとシームレスに連携するようにする必要があります。

アプリケーションをより速く、より頻繁に、より少ない中断で移行するというプレッシャーがビジネスおよび IT リーダーをアプリケーション経済に真っ向から駆り立て続けるため、最終的には、従来「ネットワーク」デバイスが DevOps の世界に適合することがますます増えていくでしょう。 

 

BIG-IP で使用できる DevOps ツールの詳細については、DevCentral の「 F5 Friday」の投稿をご覧ください。 DevOpsツールとF5