VMwareがマルチクラウドロードバランシングのAvi Networksを買収

VMwareは、ユーザーのデータセンターの仮想マシンの構築と管理を助ける企業から、オンプレミスでもパブリッククラウドでも仮想マシンがどこにあってもそれらの管理を助ける企業へと変わる努力を続けてきた。米国時間6月13日に同社が買収を発表した設立6年のスタートアップであるAvi Networksは、クラウドとオンプレミスの全域にわたってアプリケーションのデリバリを均衡化するサービスで、まさに今のそんなVMwareに合ってる企業と言える。なお、買収の価額は公表されていない。

Aviは、うちは昔のロードバランサーの現代版だ、と主張する。彼らが昔と呼ぶ時代には、アプリケーションは頻繁に変わることもなく、企業のデータセンターにオンプレミスで棲息していた。しかし、企業がますます多くのワークロードをAWS、Azure、Google Cloud Platformなどのパブリッククラウドに移行させている今日では、Aviのような企業がもっと現代的なロードバランシングツールを提供しなければならない。それらのツールは、ロケーションやニーズに応じてソフトウェアのリソース要求を均衡化するだけでなく、要求の背後にあるデータを調べる必要がある。

図表提供: Avi Networks

VMwareもユーザー企業のインフラストラクチャを、それらがクラウドやオンプレミスのどこにあっても顧客企業が一貫したやり方で管理できるよう努めてきた。Aviの買収もその努力の一環であり、今回は主にモニタリングとロードバランシングのツールを手に入れたことになる。VMwareのネットワーキングとセキュリティ事業担当上級副社長を務めるTom Gillis氏は、この買収が同社のそういうビジョンによくフィットしている、と言う。「この買収は弊社のVirtual Cloud Network(仮想クラウドネットワーク)ビジョンをさらに前進させる。そこでは、ソフトウェア定義の分散ネットワークアーキテクチャがすべてのインフラストラクチャに行き渡り、そのすべてのパーツを、パブリッククラウドにあるオートメーションとプログラマビリティで統合する。Avi NetworksとVMware NSXが結びつけば、企業は新たな機会への対応力を増し、脅威に対して強く、新しいビジネスモデルを作ってすべてのアプリケーションとデータにサービスを届けられるようになる。それらがどこにあっても」。

Aviの共同創設者たちはブログ記事でこれと同様の気持ちを表明し、さらに強力に前進できる企業になる、と期待している。彼らは曰く、「VMwareとの合体を決意したのは、両者のビジョンとプロダクトと技術と強力なマーケティングと企業文化の相性がきわめて良いと判断したからだ。私たちはこれからも継続して弊社のミッション遂行に努め、マルチクラウドのデプロイメントをオートメーションとセルフサービスで加速化して、顧客のアプリケーションサービスの現代化を助けていきたい」。というわけなので今後に期待しよう。

今後はVMwareの一部になるAviの顧客の中には、Deutsche Bank、Telegraph Media Group、Hulu、Ciscoなどがいる。Aviは2012年に創業され、Crunchbaseによればこれまでに1億1500万ドルを調達している。主な投資家は、Greylock、Lightspeed Venture Partners、Menlo Venturesなどだ。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Kafkaクラスターの自動ロードバランシングツールCruise ControlをLinkedInが発表

今日(米国時間8/28)サンフランシスコで行われたKafka SummitLinkedInが、KafkaのクラスターのためのロードバランサーツールCruise Controlを発表した。

LinkedInが開発したオープンソースのメッセージストリーミングツールKafkaは、それを使えば、ネットワーク上で大量のデータをアプリケーション間でリアルタイムに送受するタスクが簡単にできる。Cruise ControlのプロジェクトをリードしたソフトウェアエンジニアJiangjie Qinによると、Kafkaは今、ほとんど必須のツールになっているので、今LinkedInには専用のサーバーが1800台、それらが…つまりKafkaが…一日に2兆あまりのトランザクションを動かしている。

これだけの量であれば当然、Kafkaのクラスターを正常に動かし続けることはユーザーの企業にとってミッションクリティカルであり、そこで今年早期にチームは、クラスターの異状を見つけるツールを作ろうとした。そしてそのツールは、既定の一連のルールに従ってクラスターを自動的に構成し、適正な数のリソースを使用し、不具合を自己修復して動き続けるようにする。そのツールが、Cruise Controlになった。

Cruise Controlを作る前には、クラスターがダウンするたびにそれを手作業で再構成しなければならず、しかもQinによると、再構成に不正があると将棋倒しのようにほかのクラスターたちに悪影響が及ぶ。若干の人間の監視のもとに、マシン自身にクラスターの管理をやらせれば、その過程が大幅に単純化され、成長するネットワークのニーズに合わせてクラスターの修復作業のスケーリング(規模拡大)も可能になり、技術者たちが手作業でやっていたときに比べると仕事は大幅に効率化される(人力では不可能なほどに)。

Qinの説明によると、それらはロードバランシングの問題に帰結する。クラスターは、他のクラスターに迷惑をかけずに、正しい数のリソースで動いているか? 彼によるとこの問題はさらに、よくある構成上の問題を見つけ、ひとつひとつのクラスターに適正な目標を適用することに帰結する。人間でなく機械なら、クラスターのニーズを素早く評価し、一連の一般的な構成および目標と比較対照し、正しいものを選ぶ。

Cruise Controlはその際、この最適化プランでよろしいか?と人間に尋ねる。

なぜそんなツールが、もっと前からなかったのか、それについてQinは、技術者の数を最近増やすまでは、そっちにリソースを回す余裕がなかった、と答えた。

クラスターの構成とリソースの使用量を機械にチェックさせる今回のソリューションが完成するまでに、約半年を要している。同社はこのツールをオープンソースでリリースし、Kafkaクラスターのロードバランシングを改善するだけでなく、そのほかの分散システムにも同じロードバランシングの原理を適用できるようにしたい、と考えている。いろんなユースケースで、便利に使えるはずだ、とQinは述べている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSの新しいロードバランサーはユーザーによるきめ細かいコントロールが可能

aws-alb

ニューヨークで行われたAmazonの顧客向けイベントで今朝(米国時間8/11)、AWSのCTO Werner Vogelsが新しいロードバランサーを発表した。それはコンテンツを複数のサーバーに分散する場合、もっときめの細かい分散の仕方をデベロッパーや管理者が指示できる、という負荷分散ツールだ。

それはAWS Application Load Balancerと呼ばれ、これまでの(2009年からある)Elastic Load Balancingツールのように、何をどこに置くかということをロードバランサーが自分のアルゴリズムで勝手に決めるのではなく、人間管理者が決められる。

この新たに加わった制御方式は、これまでのアプリケーションを動かしているだけのユーザーにはあまり関係ないかもしれないが、複数のコンテナに収めた現代的なタイプのアプリケーションを使っているユーザーには、プロセスに対するより強力なコントロール能力を与えるだろう。コンテナ化したアプリケーションは複数のマイクロサービスで構成されることが多いので、個々のマイクロサービスごとにトラフィックを制御できた方がありがたいのだ。

Vogelsはこう言う: “これにより、ユーザーのシステムの個々の部位ごとに、トラフィックの送り方を完全に制御できる”。

たとえば、APIコンテンツ(のリクエスト)はすべてそれ専用のサーバーへ行かせ、モバイルコンテンツは別の専用サーバーが担当する。この新しいツールを発表しているブログ記事は、こう述べている: “こうやってリクエストをルーティングしてやれば、複数のマイクロサービスから成るアプリケーションをそれぞれ個別に、独立的に動かし、またスケールできる”。

ユーザー(デベロッパーや管理者)にはElastic Load Balancing Consoleというコンソールが提供されるので、その上で新しいロードバランサーを使うのか、従来ので十分か、を決めて指示できる。

技術的には、新旧の違いは大きい。前のツールは“Layer 4”のロードバランサーといって、ネットワークプロトコルのレベルで動作し、ネットワークのパケットの内部で起きていることを表す詳細な情報にはアクセスできない。そこでこのツールは今後、Classic Load Balancerと呼ばれることになる。

そして新顔のApplication Load Balancerツールは“Layer 7”のロードバランサーと呼ばれる。それはパケットの内部を覗くことができ、より詳しい情報へのアクセスにより、より高度な仕事ができる。たとえば、パケットの性質に基づいて行き先を仕分けする、といったことも可能だ。

また新しい情報に伴う測度も、CloudWatchメトリクスをはじめ、新しいより詳しい測度だ。たとえばトラフィックはGBで表され、現在のアクティブコネクションの数や、毎時のコネクションレート(1時間あたりの接続数)なども分かる。

この新しいロードバランシングツールは、WebSocketとHTTP/2をサポートしている。これらはどちらも、ネットワークトラフィックを扱うためのより現代的な方法を提供しているから、一部のユーザーにとっては、ありがたいだろう。

Application Load Balancerは今すでに可利用であり、機能が増えているにも関わらず料金は従来品より10%安い。課金の単位は、使用した時間プラス、Load Balancer Capacity Unitsと呼ばれるややこしい測度で、それは毎秒の新しい接続の数や、アクティブコネクションの数、ユーザーが送信するデータの量、などをベースとする単位だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))