LightbendがOpsClarity買収について語る

コンサルティングファームBoldRadiusを９ヶ月前に買収したLightbendが、リアクティブアプリケーション監視を専門とする企業であるOpsClarityの買収を発表した。

2011年にTypeSafeとして設立されたLightbendは昨年、社名をLightbendに変更した。BoldRadiusとOpsClarityの買収に伴い、同社は130人の社員を所有する企業になった。2015年12月時点に比較して２倍の増員となる。社長兼最高経営責任者(CEO)であるMark Brewer氏は、同社のこの成長に関する質問に対して、InfoQに次のように答えている。

Mark Brewer: 大変素晴らしいことですし、楽しみでもあります。自分たちが何を開発しているのか、自分たちの信念は何なのかを理解し、文字通り全身全霊で取り組んでいる専門チームを迎え入れるという、この規模拡大の手法については非常に満足しています。間もなくここから製品が生まれます。そのチームのみでなく、私たちが市場を獲得するための製品です。当社のユーザはすでに積極的に使用していますし、製品化を心待ちしてもいます。

Lightbendでクラウドサービス担当VPとなったAlan Ngai氏は、2012年末にOpsClarityを共同で設立した。リアクティブアプリケーション監視に関する同社の専門知識は、DevOpsの４つの領域にLightbendと同社のユーザが対応する上で、新たな価値を提供するものだ。

• コンテナ
• マイクロサービスとリアクティブフレームワーク
• 継続的インテグレーション
• SMACKスタックのテクノロジ

Mark Brewer、Alan Ngai両氏に、今回の新たなパートナシップについて詳しく聞いた。

InfoQ: お二方のLightbendでの現在の責務について教えてください。つまり、毎日どのような仕事をしているのですか？

Alan Ngai: 買収から日が浅いので、当面はOpsClarityをLightbendにうまく統合すること、OpsClarityのロードマップにある洞察をLightbendの技術に加えていくこと、一般的な意味において、Lightbendが提供するサービスに統合するための適切な方法を見つけること、などに重点を置いています。日常的な業務としては、Lightbendがより多くのクラウドサービスを提供することに注力しています。

Mark Brewer: Alanの役割は、当然のことですが、OpsClarityチームのマネジメントの継続です。彼と彼のチームは、これまでLightbendが持っていなかったエクスペリエンスを提供してくれます。私たちにはクラウドサービスの運用経験がないのですが、ユーザが開発するアプリケーションにクラウド上で運用されるものが多いことは事実です。ですから私たちには、そのための知識が必要なのです。私たちにクラウドサービスを運用した経験がない、というよりも、OpsClarityが当社の一部になるまではなかった、と言った方が正確でしょう。ですから私たちは、さらなるエクスペリエンスに大きな期待を持っています。この会社から、さらに多くのクラウドサービスが提供されるでしょう。

 

CEOである私の役割は、この会社を運営することです。私がここに来て5年になりますが、当社はその約１年前に生まれました。2011年2月の設立ですから、ちょうど6年前になります。私はその1年後に、会社運営と市場への参入手段を考えるプロのCEOとして参画し、これまでに何度か実践してきました。当社については、TypeSafeという名前だった頃から知っていました。VMWareとSpringSourceを使っていた私たちのユーザのもとに、ScalaとAkkaを持って訪れていたからです。

InfoQ: SpringのPivotalへの移行に関係していたのですか？

Brewer: 私はSpringSourceにいましたが、2009年にVMwareに会社を売却しました。Pivotalはそのスピンアウトで、2013年に設立されています。私はそのPivotalのスピンアウト計画に参加していました。

InfoQ: OpSclarityの歴史とトピックについて教えてください。

Ngai: 私たちは2012年の終わりに、共同で会社を立ち上げました。この分野において、私たちがどのような価値を提供できるのかを模索していた頃です。それまではeBayとYahooで、 検索とクラウドのチームに在籍していました。共同設立者のひとりはGoogleとYahooで、もうひとりはCiscoでデータオペレーションビジネスに携わっていました。ですから私たちは、この分野がどのようなものかを十分に理解していました。私たちが注目したのは、オープンソースとクラウドの動向です。私たちの分野での専門知識とデータシステムの経験 – 大量のデータを取得して、そのデータから理解と利用の容易な方法で意味を見つけ出すこと – を提供できると考えたからです。そこで2013年から2014年にかけて、本格的なプラットフォームを開発しました。ベータ版ユーザは継続的にいたのですが、アプリケーションが非常にデータ集約型であったため、詳細なチューニングをして十分なデータを収集し、プラットフォームの正しい動作にある程度確証が持てるまでに時間がかかりました。その後しばらく、半年からほぼ１年間、ベータサイクルを続けた上で、2016年にGAに達しました。その時点で私たちは、データアプリケーションにより明確な重点を置くようになっていました。KafkaとSparkを使ったデータ中心型アプリケーションを開発するユーザ層の拡大という、Lightbendと同じトレンドに注目したからです。実際にそれが両社の接点となりました – Kafkaサミットで私たちは、この分野の監視機能について話をしました。 同じ分野に注目していたLightbendのBrad Murdochと私たちは、そこから対話を持つようになりました。両社が関わりを持つようになったのはその時からで、そこから、将来的なビジョンを共有していることが分かったのです。

InfoQ: Lightbendと合併したOpsClarityについて、一般的な評価やバックグラウンド情報を教えて頂けますか？

Brewer: 私たちがLightbendで追求している市場機会は、新しいタイプのアプリケーションと、現代化されたレガシアプリケーションとのコンビネーションです。新たに生まれたこの世界では、システムの新たな設計およびプログラム手法としてのマイクロサービスアーキテクチャと、旧式なモノリシックアプリを理解しやすく、スケーラブルで、管理の容易なものに分解する手法としてのマイクロサービスが両立しています。市場におけるもうひとつの興味深いトレンドは、ストリーミングを活用するアプリケーションを求めて私たちの元を訪ねて来るユーザ企業の存在です。アプリケーション自体としては、静的なデータではなく、変化するデータを扱うものです。この２つの市場トレンド、すなわちマイクロサービスとストリーミングは、現時点で最もホットなトレンドであると同時に、率直に言って、人々が私たちのプラットフォームに注目する最も大きな理由でもあります。これらのトレンドは、今日の現実的要件を満足する現代的アプリケーションの特徴を述べたリアクティブ宣言(Reactive Manifesto)に要約されています。

 

つまり、OpsClarityの買収には２つの理由があるのです。ひとつはLightbendの技術を採用して開発されたアプリケーションの内部、Akkaの内部、Akkaメールボックス間を転送されるメッセージやAkkaサービスのクラスタの動作、さらにはKafkaのようなストリーミング技術を監視するという彼らのビジネスが、私たちと近い関係にあったことです。彼らの製品を当社のプラットフォームにバンドルする、というパートナシップの結果として、企業の買収という機会を持つに至りました。両社がひとつになるというのは理に適っていました。当社のユーザが、当社製品とOpsClarityの製品を、単一のサービスとして入手できるようになったからです。

InfoQ: 今の話で、私たちの質問のひとつに対しては回答して頂けたと思いますが、もうひとつ、OpsClarityの資産について、同社のユーザがLightbendとの合併前に何を使用していたのかをお聞きしたいと思います。OpsClarityがLightbendに合流したことは自然な流れだった、というようにも思われますが。

Brewer: 自然な流れでしたね。もうひとつお伝えおきたいのは、OpsClarityのシステムの設計と開発にLightbendの技術が使用されていた、という点です。つまり、その多くがScalaとAkkaで記述されているのです。そのため、製品の統合が簡単になっただけでなく、企業としての統合の決断も容易でした。

Ngai: ひとつだけ付け加えるとすれば、ますます多くの企業がオープンソース技術を採用して、分散スタイルのソフトウェアスタックを構築するようになるという、私たちの市場認識がLightbendのものと極めて近いことです。それによって運用の面では、DevOpsやエンジニアにとって、自分たちの環境で実際に何が起きているのかを理解することが難しくなり、監視も困難になっていくことが予想されます。Lightbendがユーザによるこのような分散システム構築を支援する一方で、OpsClarityはシステム監視の面からユーザを支援してきました。ですから合併は自然な流れだったのです。

InfoQ: OpsClarityという企業と、リアクティブアプリケーションの監視における同社の意義について詳しく知らない読者のために、監視機能の概要とそこで使用されているテクノロジ – おそらくプロプライエタリなものではないと思いますが – について説明して頂けますか？

Ngai: 核心は、アプリケーションの開発に使用されるオープンソース技術の範囲が広がっている点にあると思います。Lightbedのスタックを取ってみても、PlayやAkka、Lagom、Scalaなど、さまざまなものが存在します。それらに加えて、今日のほとんどのアプリケーションが、メッセージバスとしてKafka、NoSQLデータベース、あるいはSparkやFlinkなどのデータプロセッサといったパーツを必要としています。まさにそれが、私たちのデザインした環境なのです。どのようなエンジニアやDevOpsであれ、これらすべてのシステムに対して専門家にはなれないはずだ、と私たちは考えたのです。ましてや監視機能、監視対象の特定などは不可能です。OpsClarityのプラットフォームで最も重要なのは、こういったシステムに関する情報が製品内に組み込まれていることです。Kafkaの専門家がチームにいなくても、あるいはCassandraの専門家、Sparkの専門家、Akkaの専門家がいなくても、それらのシステムを監視する方法や障害のパターン、主要な監視指標、製品自体でそれらを監視する方法などに関するノウハウが用意されています。分散環境を運用する当社のユーザにとって、OpsClarityが最も価値を提供している部分はそこにある、と思っています。

Brewer: 当社が考え、OpsClarityも考えていると確信することのひとつは、実行時間の非常に短いコンテナやマイクロサービス機能などが構成するこの新しい世界が、常時稼働するサーバ上でアプリケーションが動作するという、WebSphereやWebLogicといったモノリシックなアプリサーバの時代とはまったく違うものだということです。その中には常時使用されるものもあれば、ごくまれに使用されるものもあるでしょう。分散され、分解されたこの新しい世界では、サービスはDockerのコンテナ上で動作するものや、短時間のみ存在するスタンドアロンするもの、さらには数秒動作するのみのものもあります。そういったものを監視したり、あるいは監視可能にすることは、第１に、非常に困難であり、第２に、これまでの監視ソリューションでは不可能なのです。この新しい世界では通用しません。

InfoQ: マイクロサービスはこの数年間で注目のトピックになりました。Enterprise Developers Trends 2016の報告によると、企業側の反応は、(a)実際にマイクロサービスを運用している、(b)導入を検討している、(c)サンドボックス環境で試験中である、(d)まったく興味がない、とさまざまです。“The Seven Deadly Sins of Microservices”など、開発者に警告を発している書き物はたくさんありますが、そのメッセージは“マイクロサービスの採用には注意が必要だ”、というように理解されます。こういった懸念に対処する上で、Lightbendとして何かできることはあるのでしょうか？

Brewer: 実際に取り組んではいます。ひとつは教育で、この種のシステムを適切に立案、開発、設計する方法を提供する、というものです。書籍も数多く出版しています。マイクロサービスの定義やシステムの考え方、マイクロサービス的なシステム企画の方法を紹介した、短くて簡単な読み物がほとんどです。もうひとつは開発者に適切なツールを提供する、というものです。この種のシステムを新たに開発する上で有用なシステムを提供するのです。その目的で、昨年の２月にLagomというプロジェクトをローンチしました。これは当社のマイクロサービスフレームワークです。スウェーデン語で“ちょうどいい”、あるいは“適当なサイズ”、といった意味なのですが、これは意図的なものです。マイクロサービスは必ずしもマイクロ(micro)でなくても構いません。サイズではなく、それが何を行なうか、ということが問題です。ひとつのことを適切に、しかも独立した状態で実行することにより、スケールアップが可能であると同時に、問題が発生してもシステム全体を停止することなく、孤立的にフェールすることができるのです。Lagonフレームワークは、システムあるいはマイクロサービスを適切な方法で開発し始められるように支援すること、それを純粋に目指して設計されています。改良の余地はありますが、スタートとしてはまずまずだと思います。

Ngai: システムの監視という点において、LagomとLightbebdのテクノロジは、企業によるストリーミングや非同期、メッセージ駆動といったアーキテクチャ構築を支援する活動のリーダ的な存在です。開発者によるこれらシステムの開発と自動監視を支援するに留まらず、分散システムにおいて発生するこのような新たな種類の重要課題に対して、市場を啓蒙することも必要です。例えば、Webサーバに関する人々の懸念は、歴史的に見れば、要求の遅延やスループットといったものでしたが、非同期メッセージ駆動の世界での測定対象はまったく違います。例えばバックプレッシャは、Logomにおいて、オペレータがシステムに関して注意を払うであろう大きな問題です。そのようなアーキテクチャに対して、監視および測定対象という面で、どのようなサービスを提供していくべきでしょうか？

InfoQ: Alanさんはプレスリリースで、“Lightbendとの協力を通じて、リアクティブなプラットフォームにおける計測値のリアルタイム収集と分析、分散システム上の動的コンポーネントの自動検出、特定のオープンソースフレームワークへのインテリジェンスの組込みといった、高度な監視機能の提供が可能になります”、と述べていますが、この内容について、読者に詳しく説明して頂けますか？

Ngai: 監視とは単なる測定値収集ではありません。APIやJMXエンドポイントと通信してメトリックを集めて、ダッシュボードに表示するだけが監視ではないのです。ほとんどの監視ツールができるのはそれだけだと思います。私たちが開発者や運用担当者に提供したいのは、基本的には洞察力です。サービスに関して、彼らが実際に気にしているのは何なのか？今日では、すべてのサービスが数百というメトリックを公開しています – トピック名称やパーティション名称など、その種類もさまざまです。しかしながら、どの測定値が、どのパフォーマンス特性が、これらシステムで実際に問題なのでしょうか？DevOpsや技術者は何に注意しておくべきでしょう？彼らが注意を払うべき４つあるいは５つの測定値は何であって、それらはどのような特性を示しているのでしょうか？グループ化された測定値や遅延の測定値、バックプレッシャの測定値など、さまざまな種類の監視対象があります。監視の方法もそれぞれ違います。 つまり、OpsClarityの提供するインテリジェンスが提供するのは、基本的にはこれら測定値の内容や監視方法に関する知識であり、それが設定の必要なく利用可能なのです。今後はLightbendのコンポーネントをより重視すると同時に、LagomやPlay、Akkaなどを使用したアーキテクチャの構築方法に加えて、システムのパフォーマンスや運用上の特性において、ユーザが何に注意を払うべきかという点においても、理解を深めていきたいと思っています。

InfoQ: Enterprise Development Trends 2016の報告には、“現在でも12～18ヶ月の間隔でソフトウェアをリリースしているのならば、ウォーターフォールに戻るという手段もあり得る”、とも述べられています。一方のプレスリリースでは、４つの一般的なユースケースのひとつとして、“継続的インテグレーションを備えたダイナミックな環境を運用している、すなわち、新たなコードを頻繁に、毎日ではなくても週に数回というペースでプッシュしている場合”があげられています。ソフトウェア更新の最適な開発サイクルは、どの程度だと思いますか？

Brewer: 組織によって、アジャイル開発実施に関する経験あるいは専門知識、開発中のプロジェクトの種類によって違うのは明らかだと思います。さらに頻繁なアップデートないしリリースという要請も一部ではあります。１時間に最低１回、場合によってはもっと多いという、LinkedInのような企業も存在します。彼らは絶えずアップデートをプッシュしています。それが彼らのやり方なのです。何年もそうやってきましたし、その方法を運用しています。チームはほぼ毎時、新たなコードをプッシュするという方法を認識しています。全員が毎時、コードを修正する必要があるというのではありません。 反映したい変更があれば、そのサイクルをキャッチしてコードをコミットする、という意味です。また、企業やユーザの一部には、実際に月１回のリリースの実施を推進しているところもあります。彼らは18～24時間ごとのリリースに慣れています。それが理想的かどうかは分かりませんが、コードをプッシュする頻度に関して言うならば、一貫して“これが理想的なアジャイル開発の方法だ”、というものはありません。

Ngai: まさに状況次第ですね。チームが構築している技術スタックによってまったく違うと思います。前世代的なレガシ色の強い開発ならば、サイクルは長くなる傾向がありますし、DockerやMesos、あるいはその類いのテクノロジを使い始めれば、ほぼ間違いなくサイクルは短くなります。こういった環境では、コマンドひとつで環境全体を立ち上げることが可能だからです。

InfoQ: １時間に１回というのは凄いですね。LinkedInはどのようなコードをプッシュしているのでしょう？単なるバグ修正以上のものなのでしょうか？

Brewer: 機能的なものも、バグフィックスもあります。Twitterも同じです。同社のWebビジネスの大部分では、それが慣習になっています。ほとんどにとって、１日１回のサイクルでは遅過ぎるのです。彼らの多くが１日に複数回のプッシュを行なっています。

InfoQ: とても参考になります。多くの人たちが知っていることなのでしょうか？

Brewer: いくつかのコンテンツがありますが、これらのチームの中には驚くようなものもあります。彼らがこのような方法を運用しているのは、プッシュすべき変更が常に存在するからなのです。私たちLightbendにおいても、非常に早いペースでアジャイル開発を実践しているチームもありますし、もう少しスローなチームもあります。

InfoQ: ウォーターフォールは過去のものであってほしいですね。

Brewer: それについては、モノリシックなアプリや旧式の大規模アプリを開発している場合、昨日と同じ技術を継続して使用している場合には議論の余地があります。アジャイルへの切り換えや採用を強制される理由はありませんから、ウォーターフォールを使い続けるのもよいでしょう。提唱する訳ではありませんが、そうすることも可能です。

InfoQ:今の話は、アジャイルに向けての心強い支援になると思います。アジャイルへの移行には反発も少なくありません。15年前にXP(eXtreme Programming)が現れた時の、ペアプログラミングなどに対してもそうでした。OracleがJ2EE 8のサポートに熱心でないように思われることから、今日では、特に既存のJ2EEアプリを抱えた多くの企業がアジャイルに向かうのではないかと予想されます。今後どの程度の企業がJ2EEを使い続けるのか、興味のあるところですね。

Brewer: あなたの想像する以上のものです。J2EEを運用中の企業の大部分が新たな技術に着手している、と言っても過言ではありません。彼らは新しいプロジェクトでLightbendの技術などを使用していますが、すでに運用中のサービスも多数抱えています。古いスタイルで記述された、WebSphereやWebLogicといった旧式のアプリケーションサーバで動作する多くのアプリケーションもメンテナンスしなくてはなりません。

Ngai: 継続的開発、継続的インテグレーションといった技術動向が理解されているのは間違いありません。私が話した技術者のほとんどが、現時点では１時間単位や日単位のリリース、あるいは週単位のリリースさえ実行できていない場合でも、それについて認識はしています。あなたが話した方向は、現状はどうであれ、すべての人たちが目指す方向であるという理解もあります。そのための動機があるのです。

InfoQ: SMACK、すなわちSpark、Mesos、Akka、Cassandra、Kafka。興味深いのは、Akkaを除いてすべてがApache関連であることです。Webサイトにも説明されていますが、LoghtbendはこれらApache製品をすべて活用していますね。

Brewer: AkkaはApacheのものではありません。Apacheライセンスでライセンスしてはいますが、Lightbendが所有しています。ですからApacheプロジェクトではないのですが、ご指摘のとおり、それ以外はすべてApacheプロジェクトです。それらに共通するのは、Apacheプロジェクトであるということだけではなく、いずれもストリーミングベースの新しいタイプのアプリケーションに数多く採用されている点です。今回LightbendのものとなったOpsClarityの製品についても、大部分がSMACKスタック上に構築されています。同じテクノロジを集結して、次世代の監視プラットフォームを作り上げているのです。当社のユーザ、特に大量の動的データを扱っているユーザについても、同じことが言えると思います。データがディスクに書き込まれるまで待って、その後で読み出すのではなく、アプリケーション内のデータをリアルタイムに扱いたいのです。もうひとつの共通する点としては、あまり知られていないかも知れませんが、それらの大部分がScalaで記述されていることです。ご存知のとおり、当社はScalaの支援企業でもあります。

InfoQ: BoldRaduisとOpsClarityが今回チームに加わったことによって、今後のLightbendの展望はどのようなものになるのでしょう？

Brewer: この2社の組み合わせは、当社が約束を果たす上で有効だと考えています。ひとつは、先にあげた技術をユーザが習得し、実装し、活用するための支援を提供するサービスチームになることです。ただし当社は、開発作業を請け負うコンサルティングショップではありません。ベストプラクティスやトレーニングといった、ノウハウの提供とサービス実現を支援する専門知識を持った企業なのです。その前提の上で、私たちはOpsClarityと共に、自らのアプリケーションとその動作に対する洞察力の向上、アプリケーションの今後の運用に関する計画などを支援するコマーシャルプロダクトを提供します。その後ですか？現在積極的に取り組んでいることの一覧といったものはありませんが、先程述べたように、より多くのクラウドベースのサービスを提供することになると思います。監視機能はその第一歩ですが、その他にも、当社の技術を使ってアプリケーションを開発する企業向けに、より価値の高いサービスを提供するつもりです。ユーザの開発を成功させるだけではなく、開発したアプリケーションを最大限に利用できるようにすることが、私たちの使命なのです。

関連資料

• Alan Ngai、Premal Shah両氏によるビデオ“Monitoring and Troubleshooting Real-Time Data Pipelines”
• Oliver White氏のビデオ“Lightbend Acquires OpsClarity: Interview with CEO Mark Brewer”