Red Hat Summit 2019で訊いたAPI管理と開発ツールがRed Hatにとって重要な理由

Red Hat Summit 2019ではRHEL 8とOpenShift 4のアップデートが大きな話題となったが、他にも注目するべき製品があった。今回はAPI管理ツールであるという3Scaleと、Red Hatが2017年に買収したWebIDE製品であるCodenvyについて、各担当者に個別に行ったインタビューを通してRed Hatが指向するデベロッパー向け戦略を探ってみたい。

API管理ツールの3Scale

では最初にRed Hatが2016年に買収した3Scaleについて紹介しよう。今回のインタビューに応えてくれたSteven Willmott氏は3Scaleの創業者であり、買収以降はRed HatにおけるAPI管理製品の責任者を務めている。2017年のRed Hat Summitとその前にもインタビューを行っており、今回で3回目ということになった。

2017年1月に行われたセミナーの記事は、以下を参照されたい。

参考：レッドハット、API管理ソリューションの3scaleの日本展開を発表

また2018年のRed Hat Summitで行ったインタビューに関しては、以下を参照されたい。

参考：サービスメッシュ時代のAPIマネージメントのあり方を3Scaleに訊いた

これらのインタビューで分かるように、買収後に2年ほどかけて3Scaleが100％オープンソースのプロジェクトとしてRed Hatの中で熟成されてきたことが理解できる。通常のオープンコアのビジネスモデルを取っていたベンダーがRed Hatによって買収され、プロプライエタリな部分を100％オープンソースにする過程を経て、ようやくRed Hatの製品としてインテグレーションを行える段階に入ってきたということになる。

Willmott氏と同じく3Scaleの買収によってRed Hatに参加したDirectorでProduct Management担当のMark Cheshire氏も同席して、インタビューに対応してくれた。

3Scale由来の製品の責任者Willmott氏（左）とCheshire氏（右）

まずCheshire氏は、API管理においてデベロッパーエクスペリエンスが重要であると言う。これはツールの使い勝手だけではなく、ライフサイクルを管理できるかどうかがポイントであると語った。その次のポイントとしてサービスメッシュ、そしてマイクロサービス化についても語ったが、サービスメッシュについてはRed Hatの戦略としてIstioを前提にして統合を進めているとして、ここでもIstioがサービスメッシュの最有力のプロジェクトとして挙げられていた。

一方Willmott氏は、多くの企業が「サービスメッシュとAPI管理を混同している」として、API管理はデベロッパーに対してキャッシュやゲートウェイ機能を提供するものであり、サービスメッシュはプロセスを細分化してアジャイルなソフトウェアを目指すものと解説した。そして理解のポイントとして、API管理はクラスター間のゲートウェイ、サービスメッシュはクラスター内の通信にフォーカスしていると説明し、全体としてシステムを俯瞰することで全容を理解した上で、システムのどこの部分にどのような技術が必要なのかを見極めることが重要だと語った。

Willmott氏は「多くのベンダーは、クラウドネイティブなシステムにはサービスメッシュだけを提供し、APIゲートウェイは別のレガシーなシステム用として分けて考えている。だが、抽象化のレベルでみればどちらも重要だ。全体を通してシステムを連携できるRed Hatは、良いポジションにいると思う」と語った。ややもするとサービスメッシュとマイクロサービスだけに集中しがちな業界の潮流を牽制する形となった。つまり100％クラウドネイティブなシステムだけでエンタープライズのアプリケーションが構成されているわけでもなく、レガシーなアプリケーションとの統合も必要という提言だ。

その上で「重要なのはコントロールプレーン。つまりどうやってゲートウェイとコンテナ全体を制御するのか？　その鍵を握っているのはコントロールプレーンがどういう機能を備えているのか。その意味ではデータプレーンはEnvoyでも良いし、Linkerdや他のツールが出てくればそれに対応するだけだ」と解説し、やや過熱気味のサービスメッシュについてもニュートラルな姿勢を見せた。

WebIDEのCodenvy

次にCodenvyの製品責任者であり、Red Hatにおいてはデベロッパー向け製品のシニアディレクターであるBrad Micklea氏とのインタビューをお届けする。Micklea氏はEclipse Cheの開発リードでもあり、買収後はCodeReady Workspacesの責任者ということになる。Red HatはRed Hat版のEclipse CheであるOpenShift.ioを持っている。またCodenvyが開発していたWebIDEをRed Hat版にブランディングし直したのが、CodeReady Workspacesであることを考えると、今後のRed Hatが考えるデベロッパー向けツールの方向性が見えてくるように思える。CodeReady Workspacesについては以下の記事を参照されたい。

Brad Micklea氏

参考：Red HatがクラウドベースのIDE、CodeReady Workspacesを発表

Micklea氏によれば、Red Hatのデベロッパー製品には3つのフォーカスがあるという。「1つ目がCodeReady Workspaces、これはOpenShiftそしてKubernetesを使い始める際に最も簡単で効率良く開発を行う選択肢になる。しかしデベロッパーによっては使い慣れたツール、IDE、ミドルウェアを選択したくなるかもしれない。例えばIntelliJとかVisual Studio Codeが挙げられる。そしてフレームワークだと、SpringBootやJBossなどを使うこともあるだろう。その場合に役に立つのがプラグインだ。他にも巨大なYAMLファイルのためのプラグインなども用意している。だからこれまでそういうツールを使ってきたデベロッパーは、それらをそのまま使い続けることができる。これが2つ目。そしてもっとマニアックなデベロッパーのために、コマンドラインツールも開発している。OpenShiftを操作するのocコマンドやKubernetesのkubectlコマンドはどちらかというと運用者向けだよね。それをもっとシンプルにデベロッパー向けにラップしたのがodo、これが3つ目だ。この3つで、ソフトウェアを開発するフェーズのデベロッパーをサポートできる」と語った。つまりWebIDEとしてSaaSでもオンプレミスでも使えるCodeReady Workspacesと、他のIDEを補完するプラグイン、それにインテリジェントなコマンドラインツールodoを加えることで、デベロッパー向けのオファリングになるという提案だ。

OpenShiftを補完するツールたち

次に開発に必要となるCI/CDについても以下のように語った。「CodeReady Workspacesもodoも、要はデベロッパーがgit mergeを行うまでのステップだ。次に必要なのはCI/CD。いかに開発したコードを実装するのか？　というフェーズになる。多くのデベロッパーが使っているJenkinsについても、OpenShift.ioで使ってCI/CDを回していたが、実際のところこれはとても苦労が多かった。悪いツールではないが、向いていない。だからできなくはないが、とても面倒なものになってしまっていたというのが現実だ。そのため、よりクラウドネイティブなCI/CDを作ろうということで、GoogleやCloudBee（Jenkinsの開発元）とも共同でKubernetesに最適化したCI/CDを作った。これがTektonだ。これはKnativeのCI/CDとしても使われているもので、Kubernetesにネイティブで対応する」。

このように、開発ツールだけではなく、実装段階のツールもKubernetesに対応し、セキュリティなどについても同じように扱えることの重要性を訴求した。

参考：Tekton

コンテナに特化したアプリケーションが増えて、変化により対応しやすいシステムになったとして、モノリシックなアプリケーションから比べると「大量のムービングパーツ（多くのPod）のお陰で、全体としては変化に対応できるようになることがサービスメッシュの目的」と語るMicklea氏に、カオスエンジニアリングに質問を投げてみた。

Red Hatブースで配布していたデベロッパー向けのTシャツ

カオスエンジニアリングは、システムを構成するプロセスやアプリケーション、外部サービスが増えるに従って、動かなくなるパーツ（Podやプロセス）が発生することを予め演習し、耐障害性を高めるためのツール群と方法論をまとめたものの総称だ。意図的に様々なプロセスを殺すツール群として用意されており、元はNetflixの社内ツールから発生したものだ。オープンソースで公開されているものもあるし、商用サービスとして提供されているもの存在しており、クラウドネイティブなシステムでは急速に注目が集まっている。KubeCon Seattle 2018でもセッションが開催されている。

参考：KubeCon Seattleでも耳目を集めたカオスエンジニアリング

これに対してMicklea氏は「カオスエンジニアリングは興味深いテクノロジーだし、注目している。ただ、単に壊すだけでは開発組織の中にネガティブな感情が生じかねない。カオスエンジニアリングを正しく使うためには『バグを見つけてくれてありがとう』『（ユーザーが使う前に）復旧できないシステムを試験できてよかった』と思えるような開発組織の文化がないと導入は難しい」と答えた。つまり、「単にツールを入れるだけで耐障害性の高いシステムが手に入ると思わないほうが良い」ということだ。

今回は、API管理と開発ツールの責任者のインタビューをお届けした。OSとインフラストラクチャーの会社と思われていたRed Hatが、真剣にデベロッパーに対して魅力的かつ実用的なポートフォリオを提供し始めているのは間違いない。一方で、AWSやMicrosoft、Googleなどに比べると、現状でのRed Hatの日本でのデベロッパー支援活動に今ひとつ物足らなさを感じてしまうのも確かだ。今後の日本法人の活動に注目していきたい。