OpenStackの土台を支えるインフラとQAが抱える深刻な悩みとは

プライベートクラウドを構築するためのオープンソースソフトウェアといえば最初に挙げられるのはOpenStackというのは今年のOpenStack Summit Tokyoの成功をみても明らかだろう。いまさらCloudStackやEucalyptusを検討する人はいない。OpenStackはSwift、Keystone、Nova、Neutron、Cinder、Glanceのコアサービスと呼ばれるコアコンポーネントからより上位のレイヤーにあるメータリングを行うCeilometer、ダッシュボードであるHorizon、アプリケーションに近いところのDBaaSであるTrove、HadoopであるSahara、ファイルシステムのManila、オーケストレーションのHeatなど様々な機能がコアなコンポーネントではなく別モジュールとして提供されていく形式をとっている。そんなOpenStackが実はかなり危機的な状況にあったというのはご存知だろうか？

様々なコンポーネントで構成されるOpenStackの土台を支えるのがインフラとQAというレイヤーのプロジェクトなのだが、実際にはあまりスポットライトが当たってこなかったというのが実情だ。QAつまりその品質を担保するためのプロジェクトのなかのインテグレーションテストツールであるTempestがボトルネックになってしまい、このままでは開発プロセスに危機的な状況が予想されたという。今回はOpenStackのインテグレーションテストツールであるTempestのコアレビューワーであるNECソリューションイノベータ株式会社 プラットフォーム事業本部 井川征幸氏、日本電気株式会社 BI統括ユニット 大道憲一氏にインタビューを行い、QAツールやインフラを支えるソフトウェア、さらにOpenStackの実情などについて赤裸々に話を聞いた（※所属はインタビュー当時のもの）

コアコミッターの井川氏（左）と大道氏（右）

－－年末のお忙しい時期にお時間を頂き、ありがとうございます。（注：今回のインタビューは2015年12月18日に行われた）今回はちょっと地味な部分のお話を伺おうと思いまして。何かというとOpenStackもこれだけコンポーネントが増えてくるとテストも含めてインテグレーション自体が大変なんじゃないかと。そもそもバージョンを上げるのも一苦労という話もあります。その辺をぶっちゃけどうなのか？をお聞きしたいんです。

井川：そうですね。その辺の深い話の前に「パッチを入れる」というのはどういうことなのか？という辺りから話をしましょうか。具体的な例がありますのでその辺は大道さんから。

大道：はい、実はOpenStackでパッチを書く、それをUpstreamに入れる、コミュニティに認めてもらうというのが実は大変なんですよ。コードを書くことそのものよりも何よりもその前後の苦労がありまして。例えばこのパッチはある構成の時のエラーを出なくするために一行だけコードを削除するというものなんですが、それだと単にValidation Checkを弱くするだけというか場当たり的なモノなんですよね。それよりももっとキッチリとしたコードを書かなければいけないんですが、それをパッチを書いた人とそれをレビューする人に納得してもらわないといけない。自分で書いたパッチのほうがずっと良いのはわかるし、実際にコードを書いたとしても30分程度の労力なんですが、それを説明する文章を書いたりレビュワーとコミュニケーションするほうがずっと面倒くさいという（笑）。

－－しかも全部英語で（笑）

大道：そうです。パッチを書いた人はとにかく現場でそれを直したい、動けばいいだけなのでコードが自分が書いたものではなくても直ればいいんでしょうけど、レビューワーとしてはコミュニティにとっての最適なコードかどうか？を気にしないといけないんですよね。あとこのパッチがいい例なんですが、マルチノードでのテストというのが実際は必要になってきてまして、単にDevStackをシングルのサーバーに入れてテストするだけでは出てこないバグというのがあるんですね、そのためにLibertyの頃からマルチノードのテストというのができるようになりつつあります。

－－つまり実際の運用環境に近い状態のインテグレーションテストができるようになっていると。でも実際に運用に近い構成でテストを行わないと本番稼働を検討している人たちからも評価されないんじゃないでしょうね。

井川：そうですね。なのでマルチノードのテストができるようになったのは大きな進歩だと思います。あとOpenStackにはサードパーティテストというのもありまして、例えばEMCのディスクアレイを使った構成の際にテストを流すとそのメーカーのサイトにあるサーバーを使ったテスト環境にJenkinsでジョブを流して実行するということもできます。

大道：Tempestは外部からAPIを叩いてテストを実行するだけなので実際にそのドライバーの向こうのデバイスまではテストはできないんですが、問題の切り分けを行うことはできますよね。ただまだまだ苦労がありまして。実際にOpenStackはIntegratedという発想から「ビッグテント」ということでコアプロジェクト以外にも様々な機能が外部のプロジェクトという形で追加できるようになったことでOpenStackのプロジェクトが相当増えました。現時点では400近いプロジェクトが立ち上がっているんです。そこで単体のテストではなくインテグレーションテストをしようとするとTempestを使う必要が出てきます。でも例えばあるプロジェクトに新機能を追加してそれがちゃんと動くかどうかをテストするためにはTempestのテストを書く必要があります。でもこれだけプロジェクトが立ち上がると全てのテストをTempestで面倒見るのは難しくなります。

－－それはそうですよね。コアの6つだけじゃなくて残りの全てを網羅するのは難しいだろうというのは素人でも分かります（笑）

大道：そこで問題なのは、新しい機能を追加した場合などはその機能を網羅するようにテストを書かないといけないんですね。でもその場合、その役目はTempestの仕事になってしまうわけで、そうするとTempestのチームには「このテストを追加してくれ！」というテスト追加パッチのレビューが降ってくるんです。でもプロジェクト自体が増えてくると、特に最近始まった新しいプロジェクトなどはドキュメントを読んでもどういうAPIがあって何をすれば何が返ってくるのかがわからない場合があります。実際にコードとドキュメントが合っていない場合もありますし、最終的にソースコードを読んで理解したうえでテスト追加パッチのレビューを行う、という非常に手間のかかる仕事が増えるわけです。結果的にTempestがボトルネックになって開発が遅くなってしまう。実際にQAチームのPTLはOepnStack Summitなどのイベントの際に「いつも他のプロジェクトからテストに組み込んで欲しいという類のリクエストを毎日聞かされて大変だ」みたいな状況になるんです。それがバンクーバーのSummitの時には相当やばい状況になっていました。

井川：イベントの時にはQAのPTLのところにエンジニアが列を作って話をするのを待ってるみたいな感じで（笑）。

－－もう陳情団ですね（笑）

大道、井川：（笑）

大道：そこでTempestとしては全てをTempestの中に取り込まないで各プロジェクトのリポジトリの中でTempestの機能を実装するようになりました。それがTempest-libとExternal Pluginです。これによってプロジェクトに新たに実装された機能はそのプロジェクトの中で解決できるようになったんです。

井川：これはOpenStackのテスト環境であるDevStackから取り入れられた考え方でそれにTempestが倣ったという感じですね。

－－そうすると各プロジェクトは今までとにかくTempestにお願いしなければいけなかったテストを独自に回すことができるようになったと。

大道：そういうことですね。ただプロジェクトによってはTempestのテストの書き方がわからないという場合もありますし、逆に元Tempestのチームにいたエンジニアがそのプロジェクトに移っていたりするとスムーズに話が進んで効率がよく開発が進む場合もあります。

－－なんか凄い属人的な側面もあるんですね（笑）

井川：そうですね、PTLの個人的な経験やつながりで変わってしまう場合も多々あります（笑）。

大道：あとこれ、あまり他の人には知られていないことなんですが、OpenStackっていろんなモジュールがありますよね？でもそんな中で一番力を持っているというか頑張っているのはレイヤーで言えば一番下のインフラのチームなんです。例えばこのOpenStackのアナリティクスであるStackalystics（http://stackalytics.com/）のMitakaリリースのCommitの状況を見てみると、一番Commitが多いのがこのproject-configというインフラのモジュールなんです。ネットワークのNeutronよりもCommit数が多いんですよね。それぐらいにMitakaではインフラのプロジェクトがコードを書いているわけです。

Commitが一番多いのはproject-configというインフラモジュール

井川：実際にTempestやアップグレードテストを行うGrenadeはQAチーム、それにレビューシステムのGerritやパッチやテストのパイプラインを管理するZuulやテスト環境のインフラ、これはIBMやRackspaceがホスティングしているんですが、こういうプロジェクトがより上位のプロジェクトを支えるために日夜頑張っているわけなんですよね。なのでもしもこういうインフラの部分で何か障害が起こるとそれだけでOpenStackの開発がストップしてしまうという。

－－なんかIBMやRackspaceの人は大変ですよね？世界中から投げられるテストをちゃんと回すサーバー環境を止まらないように提供しないといけないという。

大道：でもそういう環境を提供することで自社のOpenStackに対するノウハウが積み重ねられるわけでそういう意味ではタダで環境を提供するだけでテスターを世界中から集めて耐久テストができるっていう側面もあるんですよね。

－－そういう意味ではOpenStackはホントに単にコミュニティで開発がされているというよりも、なんていうか、月にロケットを打ち上げるんだけど、それに関わっているエンジニアはNASAの従業員じゃなくて世界中のまだ顔も見たことがないエンジニアたちの時間と技術を使って月面着陸させようとしている、みたいな感じがありますよね（笑）。とてつもなく冒険的とも言える気がします。本日はありがとうございました。

今回はエンタープライズやキャリアー、サービスプロバイダー向けのクラウドプラットフォームとしてのOpenStackという側面ではなく巨大なソフトウェア開発を日夜止まることのなく続けていくオープンソースソフトウェアエンジニアたちのエンドレスジャーニーであり、生身の人間たちが議論をぶつけながら協力して発展していく「プロジェクトX」という側面でも非常に興味深く、これからもOpenStackを追いかけて行こうと思わせるインタビューであった。