Special Interview:Pete Abrams Co-founder and COO, Instana

 

2020年1月末にInstanaの共同創業者にしてCOOのPete Abrams氏が来日した。前年の11月にも来日しているところからも、Instanaの日本市場への意気込みが伺える。APMはアプリケーションパフォーマンス管理の略で、特にレスポンスの速さと確実性が求められるWebのトランザクション処理やネットワークゲームなどにおいて、パフォーマンスの低下を監視するソリューションだが、Instanaのそれは監視だけでなく開発の高速化にも寄与できるという。忙しいスケジュールを縫ってその秘密を聞いた。

Instana誕生の動機

――まずご自身とInstana社のスタートについて伺います。

APM(アプリケーションパフォーマンス管理)は2000年に開発されてから20年経ちました。最初に開発した会社はWilyで、後にCAに買収されました。2005年と2008年には、Dynatrace、New Relic、AppDynamicsが加わりました。私はAppDynamicsの初期の従業員でした、

私たちは創業5年になります。Instanaの創始者は私を含めて4人で、皆、ドイツでAppDynamicsや Dynatrace、Wily、Questのディストリビューターやコンサルタントでした。我々は2001年にドイツでCodecentricという会社を設立し、Wilyのナンバーワンディストリビューターになりました。2004年、我々は取り扱い製品をQuestに切り替え、ナンバーワンディストリビューターになりました。そして2007年に今度はDynatraceに切り替えました。我々は順調でしたが、2010年に私はAppDynamicsに移行しようとしました。2013〜14年に気付いたことは、AppDynamicsやNew Relic、Dynatraceはアジャイル、CI/CO、コンテナ、Kubernetesなどのために設計されてはいないということです。これらの企業は2007年に設立されたため、ソフトウェアはウォーターフォールスタイル用に設計されました。既存のAPMツールは前世代のもので、先端的なお客様はアジャイルへの移行を行おうとしていて、新しい監視ツールを探していました。そこで、新しい世代のAPMを私達自身で開発しようと考えたのです。

APMの世代変遷

顧客企業を紹介してください。

Instanaをリリースして3年になりますが、現在、世界中に約320の顧客がいます。日本には12社のお客様がいます。顧客にはDoCoMoやYahoo!、ダイムラー、ボッシュなどもいます。また、金融は私たちにとって非常に大きな業界で、約30の銀行や金融企業があります。小売ではウォールマート、アディダスなど。そして多くのeビジネスも。

お客様に共通するのは、第一に皆、独自のソフトウェアを構築していることです。アディダスは100%カスタムコードです。独自のソフトウェアを開発することは重要です。私達はお客様がソフトウェアをより速く開発し、より高品質で提供できるよう支援します。これが新しいAPMです。古いAPMは運用と監視のためのものでした。新しいAPMは、ソフトウェアの開発、運用、テスト、デプロイのサイクル全体を回すことができるようにします。

Instana採用企業

具体的にはどうのように動作するのですか?

これまでのAPMはホスト用に1つ、Javaマシン用に1つ、PHPサーバ用に1つのエージェントが要ります。これらはデータ収集だけを行うエージェントです。一方、Instanaのエージェントは、基本的にすべてを行う1つだけです。Instanaは常にシステムの状態を監視して、変更があればすぐに察知し、それによる全体への影響を分析します。つまり、エンジニアが新しいコードをプッシュすると、オペレーターは作業なしですぐに新しいコードを見ることができ、誰も指示する必要もなく、Instanaに通知する必要もありません。変更は自動的に検出され、ゼロコンフィギュレーションで自動的に問題を見つけるので、エンジニアはすぐに元に戻して修正できます。

システムのレイヤーを自動認識する

古いAPMと新しいAPMの違いをもう少し詳しく終えてください。

DevOpsはソフトウェアの開発方法を変えました。それには理由があります。人々がDevOpsに興味を持つ理由はテクノロジーではありません。人々がDevOpsに興味を持つ理由は、彼らのビジネスがより良いソフトウェア、より良い革新を要求しているからです。取締役会はCIOにより速いソフトウェア開発を要求します。顧客のニーズに応えるために、ソフトウェアの市場投入までの時間が短縮され、ビジネスプロセスが効率的になり、利益を生み出します。これがニーズがテクノロジーではなくDevOpsである理由です。

テクノロジーがクールなのではない

アジャイルがクールだからではありません。コンテナがクールだからではありません。それは、企業がより速く動き、ソフトウェアをより速く開発できるようにするためです。さて、企業がソフトウェアをより速く開発するという決定を下したら、CIOとCTOはどうするでしょうか。最初のステップは、別のアプローチを採用することです。ウォーターフォールからアジャイルへの移行です。アジャイルは、より速いサイクル、より小さなステップを可能にします。ステップを小さくすると速度が向上します。アジャイルを導入すると、マイクロサービスの利用が自然になります。アプリケーションを大規模システムから多数の小規模システムに分解すると、変更が容易になるためです。そこでCI/CDです。CI/CDの概念は開発者が自動化を支援することです。ビルド、テスト、デリバリーを自動化して繰り返し、より高い品質を実現します。

さて、次はクラウドです。Amazonは安くはありません。Amazonの4CPUサーバは、富士通やHPの4CPUサーバよりも高価です。なぜ人々はより高価なプロセッサを購入したいのでしょうか。それはAPIから3秒でアクセスできるからです。価格ではなく速度。そこでコンテナとKubernetesの有利が明らかになります。CI/CDサークルをご覧になったことがあると思います。それは、設計、開発、テスト、デリバリー、運用のサイクルの標準化モデルです。このサイクルを速くすればするほど、より多くのソフトウェアを開発でき、より多くの価値をビジネスに提供できます。ビジネスは、ITチームに、これをより速く、より良くすることを望んでいます。しかし、古いAPMは運用と監視だけに特化しています。それは2010年、2015年には良いアイデアでした。しかし今は異なっています。ビジネスはソフトウェアに依存するようになりました。楽天を見てください。彼らはソフトウェア会社です。もちろん、彼らは自分たちをソフトウェア会社とは呼んでいませんが、楽天はソフトウェアなしではありえません。つまり、すべてのビジネスプロセス、すべてのビジネスサービスがソフトウェアに組み込まれているのです。

CI/CDの各ステップでInstanaが機能する

日本でもDXが盛んに叫ばれています。

これからの企業が生き残る条件です。しかし、問題がありました。アジャイル、マイクロサービス、クラウドネイティブの道を進むと、残念ながら物事は複雑になります。ソフトウェアはシンプルにはなりません。例えばアディダスには900のマイクロサービスがあります。年間収益10億ドルの米国の自動車販売会社edmunds.comには3000人の従業員、約500人の開発者と500のマイクロサービスがあり、継続的に開発を行っています。これらのエンジニアがソフトウェアを開発し、できるだけ早くデプロイできるようにする必要があります。

もう1つ問題があります。2000年にさかのぼってみましょう。私はサーバを購入します。大きなサーバは10万ドルです。さらに10万ドルのソフトウェアを追加しました。オラクル、BDA、オーマイゴッド!。セットアップするのに6カ月かかります。とてもデリケートなので、やったあとは触れたくありません。この旧世界のアップデートは年に1回です。やがて2010年にはサーバが10や20に増えました。変更は3〜4カ月に1回です。そして今現在は、アップデートは1日10回になりました。

ホスト層で変更が発生する可能性があります。ミドルウェア層で変更が発生する可能性があります。これは、Javaのバージョンを変更したり、新しいマイクロサービスを追加したり、マイクロサービスを新しいPHPのバージョンで実行したりするなど、単純なことかもしれません。クラスタの構築方法やマシンのスケーリングは絶えず変化し、マイクロサービスは継続的に追加され、アジャイルに更新されます。状況は全く変わりました。2007年にはAppDynamics、New Relic、Dynatraceが設計、構築され、3カ月か6カ月に1回の割合でシステムはアップデートされていました。新しい世界では絶え間なく変化し、10個や20個ではなく、数百、数千のAPIが走っています。

新しいコードを投入してすぐに結果が分かる

私たちのアイデアは、パフォーマンスと品質に関するフィードバックを即座に提供するソリューションです。エンジニアは新しい世界ではいつでも何かを変えることができます。エンジニアが変更を加えるにはどうすればいいか。答えは、すぐにフィードバックを提供するマシンを提供したらどうでしょうか? フィードバックとは、変更の結果を正確に理解することを意味します。当社のソリューションは、テストサイクル、開発サイクル、デプロイサイクル、運用サイクルで活躍します。その理由は、パフォーマンスと品質の即時フィードバックです。即時フィードバックとは、状況、スタックのすべてのレイヤーの品質を理解することです。

変更があってもエラーレート、レーテンシーなどを即座に表示

優れたサービスを提供するには、このスタック全体が完全に稼働している必要があります。何らかのレベルで何かが変わった場合、状況を即座に正確に理解できるようにしなければなりません。Instanaでは誰も何にも触れる必要はありません。誰もツールを再プログラムする必要はありません。Instanaに教える必要もありません。変更は自動的に検出されます。開発者は何かを開発し、テストを開始します。彼らは問題を見つけます。彼らは戻ってそれを修正します。彼らは前進します。今度は別の問題が見つかりました。彼らはまた戻ってきます。

今はテスト環境で順調に動作しています。実稼働環境へのデプロイを開始しました。たぶん、皆さんはブルーグリーンテストという最新のDevOpsのデプロイアプローチについて聞いたことがあるでしょう。ほんの少しデプロイします。問題が見つかったので、戻ります。デプロイして戻る。もう一度デプロイして戻る。今度は大丈夫です。完全に動作しますが、観察は怠りません。即時のフィードバックはとても貴重です。新しいコードが本番環境またはテスト環境に入ります。15、30秒で技術的状況の完全な理解と品質の理解ができます。つまり問題を修正するまでの時間がずっと短くなります。

仕組みは次のとおりです。自動で完全に理解していると言っても、環境から情報を収集する必要があります。Instanaのエージェントの最初の仕事は、このホストで実行されているものを発見することです。環境は絶えず変化するため、継続的に監視する必要があります。

次に、見つけたものを提示します。ホスト、クラウド、コンテナ、Kubernetes、サービス、ミドルウェア。継続的でリアルタイムの検出と監視を行い、即時の可視性、即時の理解を実現します。情報を取得するために少ししなければならないことはあります。たとえば、MySQLでは、パスワードを教えてください。一度設定すると、再び触れることはありません。

アプリケーション層はどうでしょう。サービスの品質とアプリケーションの品質も知りたいのです。したがって、エージェントは、Javaマシン、PHPサーバ、PythonやNode.jsのようなものを検出すると、トレースを開始します。ワークロードを節約するためのサンプリングは行いません。すべてのトレースをキャプチャし、サーバにオーバーヘッドを引き起こさない機能について特許を申請しました。システムを通じてすべてのトレースをキャプチャすることができ、そこからアプリケーションサービスを理解し、サービスの品質を理解し、それらのサービスをインフラストラクチャにマップできます。そして、それこそがエンジニアに正確な理解を与える方法です。


Pete Abrams(ピート・エイブラムス)

Instanaの共同創立者・COO。ITテクノロジーソリューションのマーケティングおよび販売に25年の経験をもつ。技術的な競争上の優位性を発見しそれを収益に結びつけることを得意とする。NASAの衛星望遠鏡の校正システム関連企業を皮切りに、Sun Microsystemsなど数々のテクノロジー企業で技術面でのマーケティングやセールスの要職を経験する。カリフォルニア州サン・マテオ在住。