OpenStackRをテストしよう!
OpenStackプロジェクトで用意されている各種の試験ツールを、NTTソフトウェアの実績をもとにご紹介します。
テクノロジーコラム
- 2017年02月24日公開
本記事に関するお問い合わせ先: /products/privatecloud/index.html
OpenStackクラウドを検討中/構築中/運用中のみなさま、こんにちは。
環境を構築したとき、構成や設定を変更したとき、ソースコードに手を入れたとき......OpenStackに限らずとも、システムのあらゆる階層において、テストは必要不可欠の工程です。
更に、アジャイル開発や環境構築自動化など、開発~デプロイにスピード感が要求される現代においては、テストの自動化も求められるようになっています。
実は、OpenStackプロジェクトでは、各種テストの自動化を支援するツールが種々用意されていることをご存知でしょうか。
これらをうまく使えば、OpenStackクラウドの品質を効率よく向上させることが可能です。
NTTソフトウェアでは、これらツールを利用してOpenStackクラウドの各種検証を行ってきました。
また、既存テストツールを利用するだけに留まらず、要件に応じた試験コードの追加や、それらをコミュニティへフィードバックするといった活動の実績もございます。
本記事では、我々の経験を踏まえて、各々のツールの概要と位置づけをご紹介したいと思います。
単体テスト
Unit Test
各種OpenStackコンポーネントのコードを(基本的には)関数単位で実行し、期待する結果が得られることを確認する、ホワイトボックス試験です。
設定ファイル等の環境要因によって結果が変わることはありませんので、環境構築のチェックには使えません。
なんらかの理由でOpenStackコードに修正を加えた場合に利用する試験となります。
(逆に言えば、ソースコードの改変を行っていない限り、本試験を実施する必要はないでしょう。コミュニティでマージされたコードは全てUT通過済みのコードです)
テストコードは、各コンポーネントのソースコードリポジトリ[1]の、基本的にtests/unit/下に配置されています。
実行方法はこちらをご覧ください。
[1]たとえばnovaなら https://github.com/openstack/nova
Functional Test
ユニットテストと、後に紹介するTempestの、中間的な立ち位置のテストです。
テスト対象コンポーネントが必要とする他コンポーネント(NovaであればKeystoneやGlanceなど)なしで、疑似的にサービスを動かすことでブラックボックス試験を行います。
こちらも結局は実際にサービスを起動するわけではないため、環境構築のチェックには使えず、コードを改修した際に実施する試験となります。
このテストも各種コンポーネントのソースコードリポジトリ下で管理されており、たとえばnovaの場合はnova/tests/functional下にテストコードが配置されています。
Unit Testと異なり実装のないコンポーネントもありますが、コアサービス[2]のコンポーネントではいずれも実装済みです。
テストコードがあるコンポーネントの場合、ソースコードをgit cloneし、作成されたディレクトリ直下で「tox -efunctional」とコマンドを打つと実行できます。
[2]コアサービス=Cinder, Glance, Keystone, Neutron, Nova, Swift
機能テスト
Tempest https://github.com/openstack/tempest
OpenStackの機能テストを行うツールです。
基本的にはAPIを実行し、戻り値や資源のステータスを確認します。試験の中には、作成した仮想マシンにSSHログインするなど、実際に資源の状態を確認するものも存在します。
また、リポジトリの「scenario」ディレクトリ下にはシナリオ試験が納められています。これは各種コンポーネントのAPIを組み合わせて、ありそうなユースケースを再現した試験となります。
OpenStackクラウドを正しく構築できていることを確認するのに最適なツールといえるでしょう。
ただし、システム障害や処理競合などの異常系試験は含まれていませんので、ご注意ください(APIパラメータやステータス不整合の異常試験は一部存在しますが)。
Tempestの実行方法および設定方法は、Tempest Testing Project をご覧ください。
なお、Tempestリポジトリには現状、Cinder, Keystone, Glance, Heat, Neutron, Nova, Swiftの試験のみ配置されています。
それ以外のコンポーネントの試験(と、上記コンポーネントの一部異常系試験)については、各コンポーネントのソースコードリポジトリで管理されている場合があります(ディレクトリ位置は一定ではないのですが、大抵ディレクトリ名に"tempest"の文字列が含まれているため見分けられます)。
これらTempestリポジトリ外の試験の実行方法は、大体の場合テストコードと同じディレクトリにREADME.rstのかたちで記載されていますので、必要に応じて確認をしてみてください。
Defcore https://github.com/openstack/defcore
OpenStackを利用したプロダクトが「OpenStack Powered」ロゴ[3]を使用するにあたり、必ずパスすべきTempest試験を規定したものがDefcoreです。
Defcore自体はただのTempest試験リストを記載したJSONファイルですが、このJSONファイルを読み込み実際にTempestを実行するためのツールとして、Refstackというソフトウェアが用意されています。
Refstackは試験実行するだけでなく、試験結果の保管と表示などの機能も有しています。
上記のとおりなので、「OpenStack Powered」ロゴを使用したい場合以外には基本的には関係ないツールなのですが、一般的に最低限パスすべき試験が規定されていますので、Tempestに含まれている試験数が多すぎて辟易......という方は参考にしてみると良いかもしれません。
Refstackを用いたDefcore実行方法はこちらをご覧ください。
[3]OpenStack Poweredの詳細についてはこちらをご覧ください。
性能テスト
Rally https://github.com/openstack/rally
OpenStackクラウドのベンチマークを行うツールです。
試験コードを(要件によっては並行で)実行し、API応答時間やAPIの非同期処理(VM削除など)完了時間などの性能や、成功確率の測定をして、グラフィカルなレポートを出力する機能を持っています。使い方によってはOpenStackのデプロイも行うことが可能です。
環境のSLAを測定するために利用すると良いでしょう。
試験コードはTempestを利用することもできますし、自作することもできます。自作する場合に向けて、Rallyには共通的に利用できる機能を持つクラスが予め用意されています。
Rallyのインストール方法と使い方はこちらをご覧ください。
終わりに
いかがでしたでしょうか。
これまでご紹介した他にも、OpenStackのRBACの正常性を確かめるPatroleプロジェクトの開発が進んでいたり、従来コミュニティ側で試験できていなかった異常系試験をカバーするためにシステム障害試験を自動化する動きが出てきていたり、OpenStackプロジェクトの試験ツールは今後ますます充実していく見通しです。
OpenStackクラウドの品質担保や試験自動化について興味お持ちの方は、ぜひ弊社までお問い合わせください。
詳細およびお問い合わせ先は、本記事冒頭のリンク先をご覧ください。
品質担保、試験自動化以外にも、クラウドに関する各種ソリューションを取り揃えております。
※OpenStack(R)はOpenStack, LLCの登録商標又は商標です。