特集記事と同時に、日本OpenStackユーザ会メンバーが超ホットでディープな最新情報をコラムスタイルで紹介していく@IT特集「OpenStack超入門」。コラム第4回は「Tempest」コアデベロッパーの井川征幸氏がOpenStackの品質を担保する「テストの仕組み」を紹介する。
皆さま初めまして。日本OpenStackユーザ会の井川と申します。OpenStackの開発コミュニティで「Tempest」のコアデベロッパーとして活動しています。
TempestはOpenStackにおける「テスト」を担当するプロジェクトです。「Nova」の仮想マシンや、「Neutron」の仮想ネットワークのように直接ユーザーが利用する機能と違い、Tempestを皆さまが意識することはほとんどないと思います。しかし、Tempestは、OpenStack全体にわたる品質維持を一手に担当している縁の下の力持ちといえるプロジェクトです。
今回はOpenStack の「テスト」とTempestを中心として、OpenStackの品質維持がどのように行われているのかをお話しします。
OpenStack には毎日、数十〜数百件のソースコード(パッチ)が提供されています。これらのソースコードは各コンポーネントのコアデベロッパー(コラム第2回を参照)をはじめとしたレビューアーによりレビューが行われています。しかし、日々多数のパッチが作成されるOpenStackでは、全てのパッチのコーディングスタイル(規約)チェック、レグレッション(回帰)テストなどを人力で行うことは不可能な状況です。
そこでOpenStackコミュニティでは、提供された全てのパッチに対し、コーディングスタイルチェック、単体テストをはじめ、インテグレーション(結合)テストを自動で行うための仕組みを構築しました。これらテストの中でインテグレーションテストをつかさどるプロジェクトが「Tempest」になります。このインテグレーションテストはクラウド上(「HP Cloud」「Rackspace Cloud」)で、インフラチームが中心となり構築・運用しており、現在のテスト状況もすぐに確認することができます。
参考リンク:OpenStack自動テスト状況
少し踏み込んだ内容になりますが、開発者から提供されたパッチが、どのようなフローで処理されるのかをご紹介しましょう。
開発者は「Gerrit」というコードレビューシステムにパッチをアップロードします。すると、「Jenkins」により自動的にテスト(コーディングスタイル、単体テスト、インテグレーションテストなど)が行われ、そのテストに合格すると、Jenkinsが「+1」のスコアを付けます。何らかのエラーが発生すると「-1」を付けコードがマージされることはありません。まずここが第一の関門になります。
そして、Jenkinsに「+1」をもらったパッチだけが、コアデベロッパー(+2の権限を持つ)のレビューを受けられます。ここで、2人のコアデベロッパーから「+2」のスコアとともに承認してもらえると、コードは再度Jenkinsにより自動テストが行われ、アップストリームのコードへマージされます。
このように、提供されたパッチは最低2回の自動テストと、2人以上のコアデベロッパーによるレビューを経てマージされています。そして、ここでJenkinsが行う自動テストに用いられているのが、Tempestになります。
皆さまの中に、実際に、Tempestを使ったことがある方はいらっしゃいますか? Tempestコアの私が言うのもなんですが、その方は、かなりの「OpenStack通」だと言ってよいと思います。というのも、Novaなどのコンポーネントとは異なり、Tempestには公式リリースというものがなく、リリースノートにも記載されないため、そもそも皆さまの目に触れる機会が圧倒的に少ないからです。
Tempestは、一言で説明するならば「OpenStackのためのインテグレーションテストスイート」です。QA(Quality Assurance)プログラム中の1プロジェクトとして位置付けられており、同列のものとして、(みんなが大好きな)「DevStack」、アップグレードテストを行う 「Grenade」などがあります。先ほどご紹介したJenkinsによる自動テストでは、このTempestをインテグレーションテストに使用しています。
Tempestのテストは現時点で以下の6種類で構成されています。
なお、Tempestは独自のRESTクライアントを実装して、これを使ってOpenStack APIへ接続し、テストを行っています。Novaなどのコンポーネントではそれぞれ、クライアントコマンドとともに、「Python」のライブラリ(python-novaclient)が提供されていますが、あえてTempestはこれを使用しません。これは、クライアントライブラリに品質上の問題が内在する可能性や、戻り値やエラー値などが暗黙的に丸められてしまう場合があり、厳密なテストが行えない可能性があるからです。
TempestのRESTクライアントは、毎日の自動テストで評価されており、実は「OpenStack界で一番多く使われているRESTクライアント」であるともいえます。技術的にも、Tempest自身でクライアントを保持しておくことにより、リファクタリングが容易になるメリットもあります。
ご存じの通り、OpenStackは機能が豊富で、しかもそれぞれの設定を有効/無効にすることで、テストパターンの数が膨大になります。そのため、テストを行う側としてはとても大変です。どの機能が使える状態なのか否かを把握し、きちんと定義しておかないと正しいテストができないためです。さらに、OpenStackの機能は日に日に増加しており、併せてTempestの設定項目も増えています。現在では、設定項目が200以上になるなど、セットアップ自体も難しくなってきています。
Tempestは、OpenStackのAPIを対象にテストするため、そのAPIがどのような仕様かを理解しないと、レビューすることができません。OpenStack全体として見ても、まだまだドキュメントの不足や記載ミス(説明誤り、古いままアップデートされていない)などもあります。こういった部分は、そのプロジェクトのコアデベロッパーへレビューを依頼するなどして対処しています。
最後に、最近の動向や、活発な議論があるトピックについて、個人的に興味深いものをいくつかご紹介しましょう。
Tempestは、開発コミュニティ内でのDevStackを前提とした自動テストで使われるだけではなく、既存のOpenStack環境に対するテストも行うことができます。しかし、Tempestは設定が多岐にわたるため、エキスパートでなければ使用するのが難しいのが現状です。
先月(2014年11月)フランス・パリで開催された「OpenStackデザインサミット」にて、「(DevStackではない)商用環境で Tempestを動作させるためには何が必要なのか?」について議論を行いました。結論としては、「まずはドキュメントを充実させよう」という話になり、設定項目に対するドキュメントが改善されてきています。
このような取り組みが進んでいますので、遠くない将来に、皆さまが自分で構築したOpenStackを、Tempestを使って正しく構築できているのかを(今よりも簡単に)テストできるようになると考えています。
OpenStackプロジェクト全体にいえることですが、Tempest自体のパッチはどんどん出てくるものの、そのパッチをレビューをするレビューアーが不足しています。Tempestは、Nova、Neutronに次いでレビューアー当たりのパッチ数が多いことが明らかとなりました(これは、先日開催されたOpenStackデザインサミットにて、QAプログラムリーダーのMatthew Treinish氏により明らかにされました)。
私も実感していますが、現状、明らかにパッチの数に対するコアデベロッパーの数が不足しており、慢性的にレビューされないパッチがたまっている状態となってしまっています。どんなに良いパッチが提供されても、それをレビューできる人がいなければ、いつまでたってもアップストリームへマージされることはなく、機能の向上も品質の強化も行われません。Tempestは、質の高いレビューを行える人を常に求めています!
OpenStackは伝統的に、XMLとJSONの2つの形式のREST APIを持っています。しかし、これは各コンポーネントの実装が複雑になる上、テストを行う観点からは、ほとんど同じようなテストを二重に実施する必要があり、テスト時間の増大を引き起こしていました。2014年11月、Sean Dague氏(Tempest/Nova コアデベロッパー)が、XMLのテストをTempestから完全削除する提案を行い、エンタープライズ向けにはXMLサポートも必要ではないかという懸念も出ましたが、あっという間に承認され、XML APIのテストコードが削除されました。
これにより、Tempest自体のコードがシンプルになり、実行時間の削減も実現できました。このため、バージョン「Kilo」では、各コンポーネントのXML APIはテストされない状態となりますので、利用は推奨されません。ご注意ください。
Tempestは、OpenStack唯一の公式テストスイートであり、多くのAPIに対応し、実際のユースケースを想定したシナリオテスト、ストレステストなどを備えています。「OpenStackをインストールしたが、本当にうまく構築できたのだろうか?」という確認に非常に威力を発揮すると思います(ただし、前述の通り、現状では初心者が簡単には使えませんが……)。
筆者の知人の開発者/運用者も、実プロジェクトの中で既にTempestを活用していると聞いています。まだまだ、使いづらい部分があるとは思いますが、そのような感想も含めてOpenStackコミュニティへフィードバックしていくことにより、より良いテストスイートになっていくと思います。
また、OpenStackの開発に興味があり、Pythonのコードを読み書きできる方は、ぜひ、Tempestからパッチの提供や、レビューに参加するのがおすすめです。TempestはOpenStack全てのコンポーネントのテストスイートであるため、それぞれの外部(API)仕様や開発状況を横断的に知ることができる、とても面白い位置にあるプロジェクトです。技術的にも、各OpenStackコンポーネントの外部仕様に着目し、比較的上位レイヤーでの視点になっています。プロジェクトのIRCミーティング(誰でも参加することが可能)が毎週開催されていますが、その開催時間も「二週に一度、朝7時から開始」と、日本のタイムゾーンにも配慮した開催となっています。
実際にパッチを作成するときには、最初から独力では難しいと思いますので、まずは周りの詳しい人や、日本のコミュニティで情報を集めるのが良いでしょう。2015年2月3〜4日に開催するイベント「OpenStack Days Tokyo 2015」では、OpenStack開発コミュニティに貢献できる人を増やし、支援していく「OpenStack Upstream Training」が併設される予定ですので、こちらへの参加もおすすめです(前回の「OpenStack Upstream Training」の様子)
2015年2月3〜4日に開催する「OpenStack Days Tokyo 2015」では二つのエンジニア向け体験型プログラム――OpenStackコントリビューター育成プログラム「Upstream Training」と、クラウドネイティブなシステムの構築技術を体験・学習できる「クラウドインテグレーション体験ラウンジ」を開催。詳細は以下をクリック!
「Upstream Training」「クラウドインテグレーション体験ラウンジ」参加概要ページ(OpenStack Days Tokyo 2015 オフィシャルページ)
2015年10月には「OpenStack Summit」が東京で開催されます。OpenStackの開発に過去1年以内に貢献した人は、Active Technical Contributor(略してATC)として、OpenStack Summitの参加費用約800ドルが無料となる特典があります。それに向けて、今から準備し始めても遅くはありません。興味のある方は、ぜひご参加ください。
井川 征幸(いがわ まさゆき)
Tempest コアデベロッパー
NECソリューションイノベータ株式会社に勤務
2012年よりOpenStack開発コミュニティでの活動開始。仕事はマネージャー、心はプログラマー。現在、OpenStack「Tempest」(QAプロジェクトのテストスイート)コア開発者として活動を行っている。メインフレームOS開発、Webシステム開発などさまざまな開発経験があり、社内アジャイルコミュニティリーダーも務める。妻、子二人(男)と共に暮らしており、趣味はサイクリング(愛車:BMC SLR02)。
スピーディなビジネス展開が収益向上の鍵となっている今、ITシステム整備にも一層のスピードと柔軟性が求められている。こうした中、オープンソースで自社内にクラウド環境を構築できるOpenStackが注目を集めている。「迅速・柔軟なリソース調達・廃棄」「アプリケーションのポータビリティ」「ベンダー・既存資産にとらわれないオープン性」といった「ビジネスにリニアに連動するシステム整備」を実現し得る技術であるためだ。 ただユーザー企業が増えつつある一方で、さまざまな疑問も噴出している。本特集では日本OpenStackユーザ会の協力も得て、コンセプトから機能セット、使い方、最新情報まで、その全貌を明らかにし、今必要なITインフラの在り方を占う。
Copyright © ITmedia, Inc. All Rights Reserved.