CircleCIのCTOがクラウド時代のCI/CDについて語る

SaaSベースのCI/CDソリューションを展開するCircleCIのCTOであるRob Zuber氏に、サンフランシスコのオフィスでインタビューを実施した。CircleCIについては過去にCEOのJim Rose氏にインタビューを行ったが、それに続きCTOにクラウド時代のCI/CD、テストインプロダクションの意義などについてCTOに詳しく話を聞いた。

CEO、Jim Rose氏のインタビューはこちら：クラウドネイティブなCIを目指すCircleCIの未来とは？　CEOとカントリーマネージャーに訊いてみた

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

CTOのRob Zuber氏。日本語のTシャツがイカシている

私はかつてDistillerという会社でCIOを務めていましたが、2014年にDistillerがCircleCIに買収されたことでCircleCIに参加し、CTOとなりました。その頃のCircleCIは、まだ20人ぐらいの会社でしたが、今ではだいぶ大きくなりましたね。当時はiOSのアプリケーション開発におけるツールが不足していたということから、iOSの開発のためのツールを作っていたのです。CircleCIとして仕事を始めた時ですが、我々の最初のユーザーとなるRubyのコミュニティで、デベロッパーはテスト駆動型の開発を行っていました。そしてRubyのデベロッパーがiOSのアプリケーション開発にシフトした際に最初に気が付いたのは「これはおかしい。こんなツールでiOSのアプリケーションを開発しているのか？」ということだったのです。テストのためのツールが何もなく、「こんな環境で開発を行うのはまちがっている！」と感じたのですね。そしてそこから、iOSのアプリケーション開発のためのツールが多く開発されるようになりました。今でもiOSのツールの多くがRubyで書かれているのはそういう背景があったからなのです。

CEOのJimはCircleCIを作ろうとした一つの要因としてJenkinsの存在があったとコメントしていました。それについてのコメントはありますか？

そうです。Jenkinsは、その頃にはもう存在していて使われていました。当時のCI/CDはスクリプトが実行できればテストもビルドも可能というもので、それ自体は悪くないのですが、実際にはそのためのサーバーを準備したりする必要があり、その作業自体が非常に面倒くさいものだったのです。そういうJenkinsに対して、CircleCIが実現した「コードを書いてボタンをクリックすれば、あとはビルドもテストも自動的に実行される」という環境は画期的だったわけです。

そしてもう一つ、プロジェクトの期限が迫っている時にコードを書いてそれをCI/CDツールに渡したい時に「ビルドやテストのためには新しいエクステンションが必要で、それをインストールするためにはIT部門に申請が必要」というようなことが起こるのは本当に良くないと考えたことですね。そこでCircleCIでは、Orbというさまざまなプラットフォームで利用できる再利用可能なコードを共有するサービスを立ち上げて公開することで、そのような面倒な手続きを不要にする仕組みを推進しています。Orbはさまざまな企業やユーザーが自身で開発したCI/CDのスクリプトなどを公開する仕組みですが、それらはオープンソースとして公開されることになります。Orbを共有するのは、ベンダーでもユーザーでも良いのです。

例えばNetflixは多くのオープンソースソフトウェアを公開していますが、それは自社のビジネスの根幹に関わらないものだから可能な訳です。Netflixはビデオストリーミングやレコメンデーションに関するコードは公開していませんが、その理由はそれらが彼らのビジネスの根幹に関わるものだからですよね。でもその他のインフラストラクチャーに関するコードは公開することで、より良くすることもできますし、新しいアイデアを得ることもできます。それがオープンソースの良いところと言えるでしょう。

参考：CircleCI orbs

最近はモノリシックなアプリケーションではなくKubernetesに代表されるマイクロサービスが注目されています。そして本番環境が分散型に移行していくと、本番環境とまったく同じテスト環境を用意するというのが難しくなってきています。そこで「テストインプロダクション」というコンセプトが出てきていますが、それに関してコメントはありますか？

マイクロサービスとモノリシックなアプリケーションの違いは、ビジネスロジックとその他の機能をどのように分解するか？　という点にあります。良く書かれたアプリケーションであれば、ビジネスロジックのコードと、ビジネスロジックのためにデータを分解したり構成したりするコードはキレイに分かれているはずです。それをどのように構成するのか、モノリシックでビルドするのか、マイクロサービスで構成するのかはデベロッパーが決めることです。

しかしCI/CDの観点から見れば、それぞれの機能に対するユニットテストやシステムテストなど多くのパターンが必要になります。モノリシックの場合はユニットテストもシステムテストも実施するには巨大なアプリケーションのビルドが必要になりますので、そこにコストが掛かるわけです。一方マイクロサービスであれば、小さな部品の開発、ビルド、テストなどのステップにはそれほど時間もリソースもかかりません。

そのため、CI/CDにかかるコストの点ではマイクロサービスのほうが低いと言えます。しかしマイクロサービスは組み合わせを行った時に何が起こるのか？　この点の検証が実は難しいのです。多くのサービスが連携することで一つのアプリケーションを構成する場合は、組み合わせによって発生する不具合の検知が難しくなります。

そうすると本番環境でテストを実施するテストインプロダクションが意味を持ってくると。

カナリアデプロイメントやA/Bテスト、フィーチャーフラッグなどを使って本番環境で最新バージョンをテストすることで、複雑な構成となるマイクロサービスでもテストとデプロイメントの自動化は可能です。そして何か不具合があれば、すぐに前のバージョンに戻すという作業も可能でしょう。ソフトウェア開発の歴史を振り返ってみると、これまではリスクを減らすためにいかに完璧なソフトウェアを作るか？　この点に注力してきました。しかしそれは実態とは合っていないということが分かってきていると思います。

そこで最近は、不具合があってもそれをどうやって防ぐかという点に注力するようになっていると思います。それはつまりCost of ProductionとCost of Preventionの違いですね。完璧なものを作ろうとするコストと、バグが発生したらすぐに修正するコストとの比較という意味です。

エンタープライズ企業においてさまざまなオープンソースソフトウェアで構成されているシステムの場合、ビジネスロジックを書いたコードで発生するバグよりも、オープンソースのミドルウェアやライブラリーなどの更新によって不具合が発生するという状況が多いのではないかと思います。例えば、イギリスのMonzo BankはgRPCなどのバグによってオンラインバンキングが停止しました。そのような事態の回避は企業に所属するデベロッパーには難しいのでは？　CircleCIとしての回答は？

参考：KubeConで紹介されたMonzo Bankの事例：KubeConで失敗を紹介したMonzo Bankのキーノート

その通りですね。デベロッパーが何も変更していなくても、下層レイヤーであるライブラリーに脆弱性があれば多くのシステムが危険に晒されます。一人のデベロッパーがそれを理解して回避するのは難しいです。しかしCircleCIはSaaSモデルとして多くのビルドプロセスを処理していますから、何か問題があればそれをアラートとして検知することができます。あるライブラリーを用いたビルドのフェイル（失敗）が頻発したら、そこに何らかの問題があることは明らかです。そこで他のライブラリーを探す、バージョンを変えるなどの対処方法をCircleCIのユーザーに知らせることができるわけです。

これまでのサーバーとブラウザというプラットフォーム以外に、IoTなどの発展でエッジデデバイスを含めた多くのプラットフォームでのビルドやテストが必要になってくると思いますが、それについての対応は？

コンピュータシステムはかつてのメインフレームと緑色の文字の端末の時代から、現在はクラウドとブラウザというように変わり、複雑さは増しています。IoTを例に出さなくても、ブラウザの中にはさまざまなフレームワークが存在しており、それ自体が複雑なシステムになっています。ですから、エッジデバイスが増えたからと言っても実施するテスト自体は複雑にはなっていると思いますが、本質的にはあまり変わらないと思います。ただ、テストインプロダクションは難しいでしょうね。火星探査機のソフトウェアを更新する時に「とりあえず現地で動かしてみよう」というのはあり得ないですから（笑）。

最近、GitHubがGitHub Actionsの上で動くCI/CDソリューションを発表しました。これに関してのコメントは？

GitHubはソースコードのリポジトリとして多くのユーザーを獲得しましたが、それはあくまでもソースコードがメインであってCI/CDが主体のビジネスではありません。なので初期のCI/CDのツールのように複数のスクリプトを動かすことができる、というレベルなのではないかと思います。ですので、CircleCIのような経験を持っていないということは言えると思います。

サンフランシスコオフィスのエントランスで

ソフトウェア開発について多くの経験を持つZuber氏らしく話題は多方に拡がり、時に脱線することもしばしばだったが、CircleCI Orbsはユーザーの知見をエコシステムとして活用しようという試みとして興味深い。同じようにサードパーティのソリューションカタログとしてのGitHub Actionsと、どのように競争もしくは共存していくのか、注目していきたい。