クラウドネイティブなCIを目指すCircleCIの未来とは？　CEOとカントリーマネージャーに訊いてみた

CircleCIのCEOであるJim Rose氏と、日本のカントリーマネージャーである森本健介氏にインタビューを実施する機会を得た。

自己紹介をお願いします。

CircleCIのCEO、Jim Rose氏（左）と森本健介氏（右）

私はCircleCIのCEOですが、CircleCIには2014年に参加しました。買収を通じてCircleCIの一員になったことになります。CircleCI自体は2011年からビジネスを行っていますが、元はWordPressを使ってWebシステムを開発していました。その当時は、多くの顧客がモバイル用のサイトやアプリケーションを開発していました。そこからCIツールの重要性を認識して、CIツールにフォーカスすることにしたのです。CircleCIの創業者はエンジニアで、その当時のビルド、テストのプロセスの自動化が必要だということには気付いていました。しかし、その頃のツールはJenkinsしかありませんでした。そして残念ながら、Jenkinsはデベロッパーフレンドリーではありませんでした。使うのも難しいし、管理するのも困難でした。

そこでJenkinsを置き換える新しいソリューションを作ろうとして開発したのが、CircleCIなのです。当時のユーザーは主に小さなスタートアップ企業でしたが、彼らがCircleCIを使い始めてくれました。そのようなスタートアップでも、クラウドでソフトウェアを開発するというのが当たり前で、GitHubにコードを置いておいてCircleCIでビルドとテストを行い、AWSにデプロイする、というスタイルですね。つまりCircleCIは、最初からクラウドネイティブだったと言えます。

CircleCIのビジネスはCircleCIをSaaSとして使ってもらうことで使用料を受け取ることだと思いますが、他のCIツールがオープンソースであるのに対してプロプライエタリである理由は？

確かにオープンソースとして公開しているCIツールもありますが、我々はクローズドなソフトウェアにorbという他のソフトウェアと連携するための仕組みを公開しています。orbはパッケージマネージャーで、RubyGemsと同じようなものですね。orbには多くのオープンなコードが開発されており、それを使って他のソフトウェアとの連携が可能になっています。つまりクローズドなコアとオープンなエッジソフトウェアの組み合わせ、「オープンシェル」とも呼んでいますが、そのような構成になっています。

課金についてはcircleci.comに接続して使う他に、オンプレミスのサーバーにインストールして使うことも可能です。基本的に毎月1,000分までのビルドは無償で利用可能です。また、オープンソースソフトウェアを開発する場合には、さらに4コンテナまで無償で提供しています。

クローズドなコアにしている理由の大きなものは、スケーラビリティですね。数十台のサーバーを使う小さな規模のCIであれば、誰でもツールを作ることはできると思いますが、それを数百、数千という規模でCIを稼働させるとなると、多くのノウハウと経験が必要です。

FacebookやGoogle、Netflixという巨大なクラウドサービスの中でCircleCIが使われているのは、そういうスケーラブルなソリューションであるということの証だと思います。

RedisやElastic、MongoDBなどがパブリッククラウドプロバイダーたちによるフリーライドを防ぐためにライセンスアグリーメントを書き換えてフリーライドできないようにしていますが、それに対してコメントは？

これは複雑な問題です。オープンソースソフトウェアを使う時には多くの場合、管理や運用が複雑なものが多いのですが、パブリッククラウドプロバイダーがその面倒な管理や運用を肩代わりする形でサービスを提供するというのは良いことだと思います。そのようなサービスの例としてEKS（Amazon Elastic Container Service for Kubernetes）が挙げられます。EKSは、複雑なKubernetesをサービスとして提供しています。またパブリッククラウドプロバイダーがそのオープンソースソフトウェアに貢献を行っているのであれば、それは妥当といえるでしょう。

オープンソースソフトウェアを開発して公開し、その上でビジネスとして成り立たせないといけないというのは難しいことです。普通であればオープンソース版の他にエンタープライズ版を作ってそれを買ってもらう、もしくはマネージドサービスを作ってそれを使って課金するというやり方になります。ですが、その場合はパブリッククラウドとの差異化が必要になります。そしてそれは、必ずしも簡単なことではありません。そういう企業はフリー版とエンタープライズ版を開発し、エンタープライズ版を例えば金融機関に使ってもらい、そこから売上を上げるというやり方をするしかありません。

一方CircleCIは、もっとボトムアップの手法を用います。デベロッパーに使ってもらって、規模が拡大したらその時からお金をもらうという発想です。つまり逆の方向性と言えますね。

多くのCI/CDツールがありますが、この混み合ったマーケットで生き残っていくためには何をしようとしているのですか？

確かに混み合ったマーケットですし、これは最初からそうだったのです。CIツールを作るというのは難しいですが、不可能ではありません。CircleCIも最初にツールを作ったのですから不可能ではないのです。しかしその中で生き残っていくためには2つの要因が必要だと思います。

1つ目は、非常に巨大なシステムにスケールできることです。CircleCIはFacebook、Google、Microsoft、Amazon、Netflixという、世界でもトップレベルと言える巨大なシステムを持つ企業をユーザーとしていることからも分かるように、スケールするCIツールを作るというのはとても難しいのです。我々はそれを可能にしています。

そして2つ目は、我々がクラウドネイティブなアプリケーション開発にこれからの未来を賭けたということです。今後もさらにその分野を進化させたいと思っています。

どういうことかと言うと、かつては金融機関が業務用アプリケーションを作ろうと思ったら、それはデベロッパーを雇って半年間掛けてゼロからJavaのアプリケーションを書くということでした。しかし今や多くのオープンソースソフトウェアが関わっています。例えばJavaのフレームワークやライブラリーなど他の誰かが作ったモノの上に少しのコードを足し、それらを繋ぐ形でソフトウェアを構築します。そうすることで無駄な車輪の再発明を防ぐことができます。しかしどのライブラリーがどういう状態にあるのかを理解した上で、アプリケーションをビルドするわけではありません。Jenkinsなどはアプリケーションをビルドする時に単にそのライブラリーを使うということだけに留まっています。

一方CircleCIが目指しているのは、どのライブラリーがビルド、テストの成功率が高いのか、どのライブラリーに脆弱性があるのか、アプリケーションに組み込まれたAPIコール、例えばペイメントであればStripeのAPIが今どういう状況なのかをダイナミックに理解した上で、ビルドを行うという部分です。ライブラリーなどの脆弱性についてはBlackduckやSnyk、Twistlockなどのパートナーのソリューションを使うことでチェックができますが、それはスタティックなライブラリー解析と言えます。スタティック（静的）な解析を行うというのは、どのライブラリーに脆弱性があるのかを知ると言う部分です。

そこを我々はもっとダイナミックな解析に向かっています。つまりあなたのアプリケーションが50のライブラリーを使って、さらにそのライブラリーが50のライブラリーを使っているとします。しかし多くの場合、あなたのアプリケーションが使っているのはあるライブラリーの一部だけかもしれません。それをビルド時に理解していれば、不要なライブラリーはロードしないということも可能になります。また外部のAPIコールを使う場合も、そのサービスが今使えるのか？　応答時間は？　などをリアルタイムに理解した上で、アプリケーションのビルド、テストを行うわけです。これは巨大なシステムになればなるほど必要になります。これがクラウドネイティブなソフトウェア開発のプロセスだと思います。それをCircleCIで可能にしたいと考えています。

GitHubがソースコードに対してやろうとしていることと似ていますね。

確かに似ていますが、GitHubはもっとソースコードにフォーカスしています。最近、GitHubはDependabotを買収して依存関係を理解しようとしていますが、それでもあくまでソースコードのレベルに留まっています。一方CircleCIは、7年前から大量のビルドのプロセスに関する情報を持っています。それらを使ってライブラリーの依存関係とその状態を理解した上で、最適なビルドを行うためには何が必要なのか？　を知っており、その知見を深層学習を使って利用しようとしています。このようなレベルの解析を行うためには、アプリケーションがビルドされるプロセスとデータを持っていないと不可能なのです。

最近のクラウドネイティブなシステムでは、モノリシックなアプリケーションではなく、複数の小さなプロセスが繋がったマイクロサービス、サービスメッシュがもてはやされています。その時にCIツールの役割は変わるのでは？

サービスメッシュは確かに今、モメンタムが来ていると思います。ただまだ多くの企業は様子見という段階ではないでしょうか。企業にとってはサービスメッシュに行くのか、サーバーレスに行くのか、という部分の判断を下してはいないと言うレベルでしょうね。ただサービスメッシュになった時に、これまでと明確に違う点は、これまでの「開発～テスト～本番環境」というフローが意味を成さなくなってきているということです。

これはどういうことかと言うと、モノリシックなアプリケーションであれば、テスト環境と本番環境を全く同じにして動作確認をしてから本番にリリースするということは可能でした。しかしサービスメッシュのように多くのモジュールが常に更新されているような状況下では、テスト環境と本番環境を同じにするということは、もはや不可能です。となるとどういうことが起こるかというと「Test in Production」ということになります。つまりv1.0のアプリケーションとv2.0のアプリケーションを同時に本番環境にデプロイして、少しずつトラフィックを新しいバージョンに流して問題がなければv2.0に切り替えるというカナリアリリースのやり方ですね。こういう手法が今後は主流になっていくと思います。

5年後、CircleCIはどうなっていると思いますか？

現在の時点から未来を予測するというのは難しいですが、ひとつだけ言えるのはソフトウェア開発はこれから大きく変わるだろうということです。その最たるものが機械学習です。これまではソフトウェアはデベロッパーが宣言的、手続き的にコードを書いてそれが実装されて機能を果たしてきました。

しかし機械学習であれば、コードはデータと共に常に変化していきます。そうするとデベロッパーにとって「どうしてこの結果が出てきたのかが説明できない」という状況になります。そうすると「このソフトウェアは、こういう経路と通って結果としてこういう結果を出した」ということを実証する機能が必要になるだろうと思います。それがどんな形になるのかはわかりませんが。

最後に日本のカントリーマネージャーの森本さんに質問です。日本でのビジネスの今後は？

日本にオフィスができたのが2018年の6月ですから、ちょうど1年ですね。これまでは、予定通りのビジネス展開ができていると思っています。これからもCircleCIのコミュニティを盛り上げてデベロッパーの支援をしていくことを続けたいと思っています。CircleCIのビジネスはボトムアップで拡がってきたのはそのまま続けて、パートナーであるマクニカとも協力してビジネスを拡大してきたいと考えています。

クラウドネイティブなCIの未来について「動的な解析が必要」、APIについても「今どうなっているのか？　を理解した上で組み込むことが必要」と解説するRose氏は、他のCIツールとは明確に差別化が可能だと強調した。2011年から提供されているクラウドサービスとしてのCIの経験をベースにして、単なるビルド～テストツールを超えた未来を目指しているのは確実だ。今後もCircleCIの動向には注目するべきだろう。