Dockerの仮想ネットワークソリューションであるWeave を開発したWeaveworksが，Weave Scopeのプレアルファ版をリリースした。開発者をおもな対象とした，オープンソースのコンテナ監視ツールである。Weave Scopeはコンテナのマップを自動的に生成する。提供される情報によって技術者は，アプリケーション監視と管理，デプロイメントや運用上の判断を行うことが可能になる。Weaveworksでは，Weave Scopeの開発を進める上で，コミュニティからのフィードバックと協力を求めている。
Weave Scopeリリースを公表したブログ記事でWeaveworksは，現状のアプリケーションあるいはインフラストラクチャのモニタリングソリューションのおもな対象は運用担当者であって，開発者の要求には応えられていない，と主張する。DevOpsの台頭と‘書いた人が実行する’という哲学により，現在では，開発者主体の監視ツールのニーズが確実に存在している。Weave Scopeは，Dockerベースのデプロイメントを中心に，開発者にも運用担当者にも理解可能な監視アプリケーションの提供を目標としている。
Weave Scopeは，Weaveworkの既存製品であるWeaveをベースとして使用する。Weaveは，複数のホストに分散配置されたDockerコンテナ同士を接続するレイヤ２SDN(Software Defined Network)を提供し，自動ディスカバリを実現する。Dockerコンテナ内のアプリケーションが，あたかも同じネットワークスイッチにすべて接続されているかのようにネットワークを使用できる。ポートマッピングやコンテナリンクといった設定は一切不要だ。Weaveworksのブログでは，Weaveの重要なユースケースのひとつとして，‘クラウドネイティブ’なアプリケーション構築の支援が挙げている。コンテナにパッケージされ，動的にスケジュールされるような，マイクロサービス指向のアプリケーションは典型的な例だ。
[クラウドネイティブなマイクロサービスアプリケーションという]この発想により，開発者の生産性向上とともに，運用コストの大幅な削減が可能になります。アプリケーションの自動化とリソースに関する柔軟性の向上が，効率化を実現するのです。
ブログではさらに，クラウドネイティブなアプリケーション開発が企業に浸透しない理由として，２つの大きな問題点を指摘している。第1には，アプリケーションサービスの健全性の確保，キャパシティ計画のための情報収集，インフラストラクチャ管理といった運用上の問題である。第2には，アプリケーションの対処能力の欠如やインフラストラクチャの柔軟性といった，スケールアップに関する問題である。Weaveworksでは，Weaveを開発した同社の経験を活かすことで，これらの問題を克服するモニタリングソリューションを提供できると考えている。
Weave Scopeは，監視対象である個々の物理ホスト上で，'sudo probe'のように，システム権限でプローブプロセスを実行することで起動する。次にWeave Scopeのアプリケーションプロセスをホスト上で実行し，'app -probes="probe-host-1:4030, probe-host-2:4030"'のように，プローブプロセスとの通信を設定する。Weave Scopeのユーザインターフェースを見るには，実行中ホストのポート4040で動作するWebアプリケーションを，"http://scope-host:4040"のようにブラウザで参照する。コンテナ/アプリケーション監視グラフの表示は次の例のようなものだ。
Weave Scopeのコードは，関連するWeaveworksのGithubリポジトリで参照することができる。現在はWeaveに完全統合するための作業の最中だが，ブログによると，今後数週間のうちには完了する予定だ。現時点では他のSDN実装はサポートされていないが，Weaveworksチームではコントリビューションを募集している。
SDNベンダや，Weave以外のネットワークを使用中であっても，諦めないでください。そのような方々にも不都合なく，Weave Scopeを使って頂きたいと思っています。実際それは難しいことではありません。まずは始めるか，または連絡をください。自動化されたサービスディスカバリやアドレスアロケーションなどのフレンドリな機能により，Weaveは，Docker開発者の間でますます多く採用されています。お気に入りのネットワークとクラウドネイティブなアプリケーション開発を組み合わせるには，理想的な方法なのです。
InfoQはWeaveworksの創設者でCEOのAlexis Richardson氏とコンタクトを取り，Weave Scopeのリリースに関していくつかの質問をした。
InfoQ: Weave Scopeを発表したブログ記事の中であなたは，モニタリングソリューションの多くは開発者を対象としていない，という興味深い洞察をしていますが，開発と運用のコラボレーション(いわゆるDevOps)が普及している現在の状況でも，そのような問題がまだあるのでしょうか？また，どのような影響が考えられますか？
Richardson: そうですね，今も問題があることは間違いありません。開発者フレンドリであることは基本なのです。Scopeはアプリケーション開発者に対して，コンテナを使用する既存のアプリケーションの監視と視覚化を可能にします。
DevOpsについて言えば，重要なのは開発者がもっと運用上の責任を取ること，開発者のワークフローに運用を組み込むこと，この２つです。運用スタッフも開発者と同じようにアプリケーションを考えなくてはならないとか，あるいは監視ツールがいきなり開発者フレンドリになるとか，そういった意味のものではありません。
私たちの目標は，“開発(dev)”と“運用(ops)”の対話を実現することです。 技術と実践の組み合わせという意味から，これを“DevOpsモニタリング”と呼びたいと思います。古典的な例を考えてみましょう – 今，午前２時です。運用担当者が問題を解決しようと，何時間も悪戦苦闘しています。この問題を理解し解決する上で，もっとも適役なのは開発者でしょう。そこで開発者が呼び出されます。この時点で彼らは，既存のツールによって，往々にして窮地に立たされます。これらのツールが，彼らのインフラストラクチャとは根本的に違った見解に立脚している上に，そこに焼き込まれたイディオムも違うからです。Scopeで私たちは，開発者のアプリケーション中心の論理的な見方と，運用担当者のインフラストラクチャ中心の物理的な見方のギャップを埋めたいと考えました。結果として，どちらの担当者にも等しく使いやすいものができたと思っています！
InfoQ: DatadogやDataloop.IOなど，モニタリング・アズ・ア・サービスを提供する企業が現れていますが，貴社のツーリングはこれを補完するものなのでしょうか，あるいはこれらのツールを競合として見ていますか？
Richardson: 基本的には補完するものと思っていますが，Weave Scopeは革新的なアプローチを採用しているため，競合する面もいくつかあります。企業としては，InfluxDBやPrometheusのような，スタンドアロンの監視プロダクトを活用することのメリットもあると思います。
そういった意味でWeave Scopeは，(Datadogのような)既存の監視ツールを使用しているユーザに対して，アプリケーション全体のポートフォリオにおける，新たな選択肢を提供できるものだと思っています。要するにこれらのツールは，複数のデータソースからデータを引っ張って，相関や洞察，意思決定を可能にする，アグリゲータなのです。その意味では，Weaveは補完的な存在です。
それと同時に私たちは，新たなことを行おうとしています。その意味からは，これまでの，モニタリングの限界という一連の仮説に対しては，競合する存在でもあります。私たちは，これらの仮説を検証しようとしているのです。
InfoQ: Battery Ventures(元Netflix/eBay/Sun)のAdrian Cockcroft氏が，spigo/simianvizというアプリケーションで，マイクロサービスの可視化について興味深い仕事をしています。その表示がWeave Scopeに似ているのですが，氏の仕事についてどのように見ていますか？
Richardson: マイクロサービスという“手段”とDevOpsの適用との関係を解析した氏の成果は，称賛に値するものだと思います。これに興味をお持ちならば，Dockercon Amsterdam 2014での氏の講演のビデオ，あるいはその前のINGのCIOによる講演をお勧めします。特に後者は，マイクロサービスの採用が‘速度’のような単純な指標を越えたメリットを企業にもたらすという，素晴らしい実例のひとつと言えます。
ただし，ScopeとSpigoには，ひとつ大きな違いがあることも理解する必要があります。先に述べたようにScopeでは，コンテナを使用している既存のアプリケーションを対象として，開発者がその監視と可視化をすることができます。アプリケーションの変更は必要ありません – Scopeがそれを理解してくれるのです。これに対してSpigoでは，対話エージェントと関連プロトコルをセットにして，対象アプリケーションをモデリングすることによって，アプリケーションをシミュレートするツールを，新たに用意する必要があります。
InfoQ: いくつかの企業が，MesosやKubernetesといったクラスタのスケジューリングあるいはオーケストレーション技術の上に，自らのマイクロサービスプラットフォームを構築していることを公表しています。その中には，基本的な監視機能やヘルスチェックを備えたものも少なくありません。そのような場合でも，Weave Scopeを導入する価値があるのでしょうか？
Richardson: そうですね，MesosやKubernetesのユーザあるいは開発者にとっても，Weave Scopeは採用する価値のあるものだと思っています。注意して欲しいのは，私たちの製品をまだ存在していないものと比較するのは難しい，ということです。多くはまだこれからのことです。しかしながら，Weaveを採用するか，あるいは他のものにするかという選択は結局のところ，まったく新しい，そしてもちろん大きな価値のある私たちの製品を受け入れてもらえるかどうかの問題だ，と私たちは考えています。ブログ記事にも，いくつかの例を紹介しています。
InfoQ: ブログでは，マイクロサービスアプリケーション開発のための開発者ツールのサポートが欠けている点について，いくつかの優れた指摘をされていますが，これは，Weaveがネットワーク関連アプリケーションのための製品を越えて，開発者ツールとしてもっと広い範囲を含むようになるということを示唆しているのでしょうか？
Richardson: “イエス”でもあり，“ノー”でもあります。
“イエス” – 私たちは常に，動的なセットアップをを備えたアプリケーションを理解する上での中心的機能としてモニタリングを考えていますが，開発者の成功を支援するためには，その他の機能も提供していきたいと思います。
“ノー” – 私たちの目標は，オーケストレーションフレームワークやプラットフォームのような“ビルドツール”を提供することではありません。このようなツールの価値は，アプリケーション開発はいかにあるべきかという，特定のモデルあるいは”意見”による，開発者の生産性向上がもたらすものです。例えばHerokuはEC2のWebアプリ開発を簡略化してくれますが，12-factorアプローチを使ったEC2上のアプリを開発するならば，という前提があります。Weaveをそのような，規範的なものにはしたくありません。
要約すると – 開発者はアプリの開発方法をすでに知っているのですから，ツールはアプリケーションや環境を問わずに実行可能であるべきだ，ということです。
InfoQ: ブログの最後に，Weaveでは，WeaveScopeで他ベンダのネットワークソリューション監視も可能とするように積極的にサポートしていきたい，ということが述べられています。これはWeaveが直接開発していくものなのでしょうか，あるいはコミュニティ主体の開発を奨励することになりますか？
Richardson: Weave Scope用のサポート開発に難しい部分はありませんから，コミュニティ(他のベンダも)が積極的に関与して欲しいですね！ 強く結合した“モノシリック”なツールを提供しようとは思いません。それよりも“Unix哲学”を重んじたいのです。つまり，理想としては，すべての開発者がWeaveの任意の部分を自由に，有効に，そして簡単に利用できるべきなのです。私たちの提供するすべての機能を使う義務はありませんし，強制するべきでもありません。Weave自身が“マイクロサービス”の理想に近付こうとしているのは，そのような理由からなのです。
InfoQ: 最後になりますが，Docker Incが先日，自社のコンテナプラットフォーム製品のネットワーク改良を目的とした，Socketplaneの戦略的買収を発表しました。CoreOSも最近になって，同社のApp Container Specやrtkt開発に対する，他ベンダからのサポートを進める施策をとっています – CoreOSと提携して，この活動を後押しすることは検討していますか？
Richardson: すべてを実行することはできませんし，私たちのユーザからは，今のところDockerのサポート/統合を望む声が大きいのも事実です。実際に旧Socketplaneチーム，現在はDockerネットワークチームとは，密接な関係を持って開発をしています。非常に前向きですし，Dockerは”オープンプラットフォーム”として最善の仕事をしています。
APPCについては – 私たちとしては，APPCの仕様とDockerが，より密接な関係を持つことを歓迎したいと思います。この分野で市場は，さらなる標準化を求めています。.debや.rpmといった複数のパッケージについてではなく，コンテナの標準化です。コンテナの仕様がいくつも存在するより，ひとつの方が望ましいことは間違いありません。唯一のコンテナ仕様が存在すれば，必然的に，競合する複数の実装が存在するようになります。‘ワンサイズですべてにフィット’するような実装はあり得ませんので，これは間違いなく健全な姿です。
rktに関しては，現在のappcとrktに起こっているのは，“コンテナ仕様の主流を獲得するための競争”です。これはappcとrkt双方にとってよいことですし，Dockerにとっては脅威となり得ます。現時点ではDockerが主流として，独自仕様の唯一の実装となっています。これを継続するには，Dockerが市場とエコシステムにその仕様を提供することができなくてはなりません。ですから私たちは，唯一の仕様が存在する世界を支持したいと思います。２つの仕様が存在する”二面的”な世界に比べれば，Dockerにとっても都合がよいはずです。もし複数の仕様が2番手を競うか，あるいはニッチを占有するようであれば，このシナリオにおいてもDockerが明らかなリーダであり続けるでしょう。
Waeveworks ScopeのGithubリポジトリにあるREADME.mdには，現リリースはプレアルファ版であるため，バグや機能欠落が発生する可能性についての了解が必要である，ということが述べられている。Weave Scopeを試用してGithubあるいはEメールで問題を報告して欲しいと，同社では呼びかけている。