Magnetic.ioはVAMP(Very Awesome Microservices Platform)という名称の，オープンソースのマイクロサービスデプロイメント・プラットフォームを新たに開発中だ。マイクロサービスのデプロイメント，A/Bテスト，カナリアリリース，自動スケーリング，さらにはメトリクス収集やイベントエンジンを統合した，‘プラットフォーム非依存のマイクロサービスDSL’を提供する。
VAMPは今のところ，Apache Mesos/Mesosphere MarathonとMesosphereのDC/OS，Docker Swarmに展開可能だ。VAMPによるマイクロサービスのデプロイメントは ブリード(breed – 単一のサービスと依存性を記述した静的アーティファクト)，ブループリント(blueprint – ブリードが実行時にどのように動作するか(通常はクラスタとして定義される)，どのようなプロパティを所持すべきかを記述する)，デプロイメント(deployment – 実行中のブループリント)，ゲートウェイ(gateway – 着信トラフィック用のポートと発信用のルートによって定義された，静的なルーティング用ゲートポイント)で構成されている。
ルーティングは，同一クラスタ内のさまざまなサービス間での，トラフィックのルーティングに関する一連のルールを定義するものだ。各ルールは，トラフィックの比率による重み付け，１つ以上のフィルタ条件によるトラフィック選択，あるいはフィルタ条件に適合したトラフィックの比率によるフィルタの重み付けなどで構成することができる。
プラットフォームによるメトリクスとイベントの収集と集約，および自動スケールアップやスケールダウンのような，それに対応するSLA(Service Level Agreement)やエスカレーションを指定することが可能だ。‘ワークフロー’も定義できる。これはレシピのように，実行中のシステムやそのデプロイメントに対する一連の自動変更操作をグループ化するものだ。これを使って，例えばデプロイ，測定，対応というような，マイクロサービスプラットフォーム内のフィードバックループを実装することができる。
InfoQは先日，magnetic.io(VAMPの開発企業)のCEOで共同創業者のOlaf Molenveld氏と話す機会を得て，マイクロサービスプラットフォーム抽象化やコンテナスケジューリング，PaaS(Platform as a Service)のあるべき姿の探求について聞くことができた。
InfoQ: Olafさん，こんにちは。今日はInfoQに協力して頂いてありがとうございます。VAMPマイクロサービスプラットフォームの紹介をお願いします。
Molenveld: ありがとう！VAMPはコンテナとマイクロサービスをベースとしたシステムで，機能のカナリアテストとリリースを手軽に実施可能なオープンソースのソリューションです。さらに，サービスの適切なドレイニング(draining)を含む自動スケールなど，強力なワークフロー機能も提供しています。
スケーリングや市場投入時間に関する課題解決というと，(Docker)コンテナやマイクロサービス，API，ビッグデータ，継続的デリバリといった技術を拙速に取り入れようとするオンライン企業をよく目にします。このような技術に個別のメリットがあることは確かですが，潜在的なビジネス価値を本当の意味で解き放つには，これら独立した要素を組み合わせて継続的改善フィードバックループ(continuous improvement feedback-loop)を形成し，リーンやアジャイル，スクラムといった方法論にマッチさせることが必要になります。
継続的インテグレーションないしデリバリから，ITとビジネスの一体化した継続的改善ループへと成長させるためには，セーフティネットとして機能する試験的なシステムが不可欠です。NetflixやAirBnB，Facebookなど，オンラインで成功を収めた企業には，特定の基準で選択された少数のビジタを対象にソフトウェアの新バージョンをリリースしてオンラインで実験するという，カナリアパターンが共通して見られます。これによって技術面およびビジネス面でのパフォーマンスを計測し，必要ならば修正した後に，継続的なプロセスとしてスケールアップする – これはセーフティネットの実装としても，あるいはITとビジネスが協力してビジネス価値を獲得する上でも，非常に優れた方法です。
このようなカナリアパターンを実装して適用するのは，従来，非常に複雑で費用の掛かるものでした。VAMPの目標は，カナリアテストや機能のカナリアリリースを簡単かつ分かりやすく始められるような，オープンソースのソリューションを提供することです。
VAMPの開発は2014年始めから，アムステルダムを拠点とする経験豊富な技術者とアーキテクトによって行われています。現在では金融や医療，Eコマースから，SaaSやハードウェア製造に至る幅広い分野で，世界中の企業による利用あるいは評価が行われています。
InfoQ: 最近は数多くのマイクロサービスプラットフォームが登場していますが，VAMPはそれら既存の製品とどのような関係にあるのでしょう？また，プラットフォームとしての適切な抽象化の選択という面は，どのように考えていますか？
Molenveld: VAMPは，それ自体では完全なマイクロサービス/コンテナのPaaSあるいはスタックではありませんが，一般的なマイクロサービス/コンテナスタックに対して，高レベルのカナリアテストやカナリアリリース，自動スケール機能を提供することに重点を置いています。VAMPは，MesosphereのOpen DC/OS，Apache Mesos/Mesosphere Marathon，Docker Swarm，(近日中には)Kubernetesなどのコンテナやマイクロサービスプラットフォーム，CiscoのMantl，CapGeminiのApollo，Rancher LabsのRancherなどのスタック，MS Azure Container Serviceなどのコンテナクラウドと統合され，コンテナオーケストレータのひとつとして利用されます。
既存のコンテナやマイクロサービスプラットフォームは，単純なロードバランシングや“ローリングアップデート”機能などは備えていますが，VAMPのようなビジネス指向のカナリアテスト/リリース機能を提供していません。ビジネス関係者は‘Visual Website Optimizer’や‘Optimizely’といったA/Bテストツールに慣れているので，それらを利用可能なカナリアテスト機能を探しています。例えば，Androidデバイス上のChromeを使っている英国からのビジタの2.5%にソフトウェア新バージョンを提供する，というようにです。このような粒度を現在のコンテナやマイクロサービススタックで実現するには，相当なハッキングや手作業を行なわなければなりませんが，VAMPならば簡単な統合操作で，より高度な機能を追加することができます。
さらに，VAMPによってソフトウェアのカナリアテスト/リリースが簡単になれば，ビジタの数，すなわちソフトウェアのロードの上昇に対応して，サービスあるいはコンテナを自動スケールアップすることも必要になります。VAMPにはSLA(Service Level Agreement)とエスカレーションワークフローが組み込まれているので，レスポンス時間や毎秒の要求数など，ユーザが定義したメトリクスに基づいた自動スケールアップ/スケールダウンが簡単に実現できます。
VAMPはクラスタのメトリクスを集約(一般的に関心があるのは個々のインスタンスではなく，クラスタ内のインスタンスの集計値のみであるため)すると同時に，スケールダウンする場合には，スティッキーなセッションの存在や生存時間も考慮した上で，サービスの正常な停止を保証します。とは言っても自動スケールは，メトリクス起動の最適化ワークフローの１インプリメンテーションに過ぎません。VAMPのワークフローエンジンとメトリクスとイベントAPIを使えば，フォロー・ザ・サン(follow-the-sun)，ビンパッキング(bin-packing)，クラウドバースティング(cloud bursting)，コストないしパフォーマンスによる最適化，ブラウンアウト(brown-out)シナリオなど，あらゆる種類のカスタムイベント駆動あるいはメトリック駆動の最適化ワークフローを簡単に作成できます。
要約すると，継続的改善フィードバックループを提供するためには，フィードバックループの３つの主要素 – サービス/コンテナのオーケストレーションを行なうシステム，プログラマブルなルーティングとロードバランシング，ビッグデータのメトリクス集約 – が同時に存在する必要がある，ということです。VAMPはこの基準を満たすと信じています。
私たちの注目しているレベルの抽象化に関してVAMPでは，“コンテナクラウド”上で，コンテナPaaSないしCaaSとでも呼ぶべき，高レベルのカナリアおよび最適化ワークフロー機能を提供しています。VAMPの中核的な機能である，プログラマブルなルーティングおよびロードバランシング機能(例えば指定した条件において，トラフィックの一定の割合を別バージョンのソフトウェアにルーティングするなど)も，コンテナを使用せずに実行可能です。ただしリアルタイムかつダイナミックな自動スケーリング機能に関しては，コンテナのスケーリング機能やコンテナマネージャを使用しているため，これらのシナリオにはコンテナが必須となります。
InfoQ: VAMPはDockerとApache Mesos上で動作可能で，KubernetesとDocker Swarnも近くサポートされる予定ですが，当初プラットフォームとしてDockerとMesosを選択したのはなぜですか？
Molenveld: 私たちがVAMPの設計開発に着手した2014年初めの時点では，コンテナ-クラスタマネージャやオーケストレータに関して最も完成度の高いのはMesosであり，最も普及したコンテナユニットはDockerでした。ですから，これらのプラットフォームを使って統合に着手するのは，理に適った選択だったのです。Dockerが成熟するにつれ，Docker Swarmをクラスタマネージャとして導入することが合理的になりました。DockerとDocker Swarmが同じAPIを使っていたことも好都合でした。
その後Kubernetesの採用が爆発的に増加しました。それにKubernetesには，非常に興味深いポテンシャルがありました。今後も広く認知された，あるいは有望なコンテナプラットフォームについては，統合を継続していきたいと思っています。VAMPとの統合機能をアドオンとして提供するために，いくつかの企業と協力しています。例えば現在も，その中の１社とRancherとの統合に取り組んでいるところです。
InfoQ: コンテナの世界では，スケジューリングがホットな話題になっていますが，スケジューリング機能についてはどのように考えていますか？要求に応じて自分自身をスケールあるいはアレンジできるような，自己最適化型のマイクロサービスアーキテクチャに需要はあるのでしょうか？
Molenveld: そうですね，システム最適化の重要な部分として，スケジューリングには非常に興味を持っています。しかも私たちは，継続的な改善フィードバックループを重視していますから，必然的に自己最適化システムを実現するための機能に取り組むことになります。最適化ワークフローとして最も一般的なのは自動スケーリングですが，これは継続的なメトリクス駆動最適化システムの一例に過ぎません。
VAMPは継続的改善ループの主要な3領域(デプロイメントのオーケストレーションとスケーリング，プログラマブルなルーティング，メトリクスおよびビッグデータの集約)をオーケストレーション可能ですので，新たな最適化ワークフローを作成して提供するのは簡単です。これらの例としては，フォロー・ザ・サン(日中はリソースをスケールアップして，夜間はスケールダウンする)，ビンパッキング問題(利用可能なインフラストラクチャの最適利用)，ブラウンアウト・フィードバックループ(トラフィックを制限して，システム全体を許容されるレベルにスローダウンすることで，全体のサービス停止を回避する)などの方法があります。
ですから，システムの正常動作に責任を持つチームは遅かれ早かれ，高レベルな帯域定義，ビジネス的および技術的なパフォーマンス定義といったものを，これまで以上に重視することになるのは間違いありません。そうしたルールの中で，システムはコストとパフォーマンスの最適なバランスを実現し，チームはビジネスと顧客の提供に注力する，という区別を行なうことが重要と考えるようになるはずです。そしてもちろん，これはリアルタイムプロセスなので，システムは常に自分自身を定期的に監視し，測定し，修正し，改善することになります。
このようなシステムでは，ディープラーニングとAIが重要なコンポーネントになるでしょう。生成される大量のデータを処理することによって，そこから学習し，シミュレーションし，システムの性能を改善することが可能になるのです。
これにはもちろん，開発と運用とビジネスの連携が現在以上に必要となります。しかし，賢明な企業はすでにそれを行なっていますから，この領域では大きな進展が期待できます。そしてもちろん，私たちがVAMPで行なっているものも同じなのです。
InfoQ: VAMPはいくつかの点で，Cloud FoundryやRancher LabsのRancherなどのPaaSプラットフォームと共通点があるように思えます。VAMPを完全なPaaS製品に展開する考えはありますか？
Molenveld: 現時点ではありません。開発を始めた2014年頃には，もっと広範な目標を持っていました。コンテナやマイクロサービスソリューションのカンブリア紀的な爆発の中で，何が起きるかを予見するのは難しかったからです。現在はマーケットが明確になり，自分たちの主な目標や付加価値がどこにあるのか，以前よりはっきり分かるようになりました。VAMPはPaaSやコンテナプラットフォームの代替であったり，競合したりするものではありませんが，カナリアや最適化のワークフローパターンを採用する際には強力な付加機能となります。
一般的なほとんどのコンテナマネージャと統合可能であることから，VAMPの高レベルな機能は，さまざまなコンテナソリューションの間を結ぶことができます。そのため，マルチコンテナクラウドやマルチスケジューラなどの要件への対応も可能で，単一のコンテナクラウドやベンダへの依存性を低減できます。
InfoQ: 読者がVAMPへのコントリビューションを望む場合に，最もよい方法は何ですか？
単一で自己完結型のQuickStartパッケージが用意されています。これをWebサイトhttp://vamp.ioからダウンロードすれば，コマンドひとつで必要なコンポーネントをすべてインストール可能です。カナリア機能の強力さを体感するためのgetting-startedチュートリアルもあり，QuickStartを使って一通り実行することができます。
新しいオープンソースのMesosphere Open DC/OSを使っている人には，VAMPでもDC/OSユニバースパッケージを用意していますので，ダッシュボードからVAMPをDC/OSにインストールすることが可能です。
私たちのソフトウェアを気に入って，VAMPの改良やコントリビューションを希望するならば，どのような企業でもコラボレーションを歓迎しています！私たちのオープンソースプロジェクトはGitHubで公開しています。リアルタイムのチャットと支援の要請はGitterで可能です。直接のEメールももちろん受け付けています。info@magnetic.ioあるいはolaf@magnetic.ioまで送ってください。
InfoQ: InfoQにお話を頂いてありがとうございました。他に何か，読者に伝えておきたいことはありますか？
Molenveld: 説明の機会と素晴らしい質問を頂いて，ありがとうございました！コンテナとマイクロサービス，そして継続的改善フィードバックループを使うことによって，チームがビジネスやユーザへの現実的な価値の提供に集中することが可能となり，その結果，すべての関係者にメリットを与えられるような新たなレベルに達することができる，と私たちは強く信じています。
コラボレーションの成果として今回のバージョンを提供できることを，とても光栄に思っています。私たちのチームに興味があって，新しいクールな機能追加やコードベース全般の改善をしたい，あるいはVAMPを自身のプラットフォームに統合してカナリア機能や最適化機能を提供したいのであれば，ぜひお話したいと思います！そしてもちろん，VAMPのカナリアワークフローや最適化ワークフローの力を活用したいという企業には，積極的に協力したいと思っています。気軽に連絡してください！
VAMPマイクロサービスプラットフォームに関する詳細な情報は，vamp.io WebサイトあるいはVAMP GitHubリポジトリで入手可能だ。
この記事を評価
- 編集者評
- 編集長アクション