レベル: 初級 Robert Williamson (robbiew@us.ibm.com), Software Engineer, Linux Technology Center, FIT Team, IBM China Development Lab
2004年 6月 30日 ソフトウェアのテストを自動化することにより、同一のテストを一定期間に渡って行うことができるようになります。また自動化によって同じ種類のテスト結果を比較することで、確実に正確な評価ができるようになります。この記事では、Linux Test Projectチームのメンバーがその方法論と考え方を紹介し、また彼らがLinux®カーネルのストレステストに使用しているスクリプトやツールについて説明を行います。
Linuxカーネル・リリースの安定性をテストするには、そのリリースがなぜ安定と言えるのか、逆に不安定と言えるのかを正確に説明し、文書化する必要が出てきます。ところが現状では、Linuxカーネル全体の、システムとしての安定性をテストできるような（文書化、実証済みの）ストレス・テストはありません。この記事ではLinuxシステム全体に対するストレス・テストを作り出す手法と、テスト結果の妥当性を検証する手法を紹介します。カーネル安定性のテストは、様々な開発者、ユーザー、またディストリビューションが、それぞれ独自の手法を使って行っています。ところが、どのテストを行うのか、どのカーネル・コードを対象としているのか、またどの程度のストレスを与えるのか、といった決定の根拠に関する情報は公開されておらず、そのためテスト結果に対する評価を大きく下げる結果になっています。
私たちはLinux Test Projectテスト・スイートの中からLinux用に使用できる研究所のマシンとテストを使い、システムリソースの利用率統計に基づいて、適切にストレスを与えられる組み合わせテストを開発しました。またこの組み合わせテストを分析して、テスト実行中にLinuxカーネルの内どの部分が動作しているのかを調査しました。その後でテストの組み合わせを変え、目標とするシステム・ストレスを高く保ちながらテスト対象範囲（code coverage）が最大になるようにしてテストを行いました。その最終結果として、Linuxカーネル全体を十分に網羅した、安定性評価に有効なストレステストが得られました。しかも、その内容を裏付けるだけのシステム使用データや、カーネルのテスト対象範囲を明示できるのです。
この組み合わせテスト手法に至るまでの４つのステップとして、テストの選択、システムリソース利用の評価、カーネルのテスト対象範囲の分析、そして最終的なテスト評価があります。
テストの選択
テストの選択としては、次の２つを達成できるようなものを選択することになります。
- メイン・カーネル領域（CPU、メモリー、I/O、ネットワークなど）に対してリソース利用率を高くできるようなテスト。
- テスト結果から得られる安定性を裏付けられるように、カーネルのテスト対象範囲が適切であること。
使用するテストとしては、可能な限り自動化したテスト、または容易に自動化できるテストとします。自動化することによりテストを高速に、かつ繰り返して行うことができ、人による間違いの要因を減らすことができます。テスト結果を無料で公開できるようなアプリケーションを使うのも、適切なテストを選択する上で考慮すべき重要な点です。オープンソースの方法論やGPLに従い、公開プロセスが容易なテストやテスト・スイートを選ぶことが大事です。
システム利用率を評価する
選択したテストの組み合わせで、システムのリソースに適切なストレスを与える必要があります。Linuxカーネルの中でシステム応答や実行時間に影響するような領域として、次の４つがあります。
-
CPU: マシンのCPUがデータ処理に費やす時間
-
メモリー: 実メモリーにデータを読み書きするために費やす時間
-
I/O: ディスク・ストレージにデータを読み書きするために費やす時間
-
ネットワーク: ネットワークにデータを読み書きするために費やす時間
リソース利用レベルを評価するために、（よく知られ広く使われている）次の2種類のオープンソースLinuxリソース・モニタリング・ツールを使用します。（このツールのダウンロードへのリンクは参考文献を見てください。）
-
top: Albert D. Cahalanがメンテするオープンソースのツールで、大部分のLinuxディストリビューションに含まれており、現在の2.4または2.6カーネルで動作します。
-
sar. もう一つのオープンソースのツールでSebastien Godardがメンテするもの。このツールも大部分のLinuxディストリビューションに含まれており、現在の2.4または2.6カーネルで動作します。
通常この方法でのシステムリソース利用評価フェーズでは、目標とする利用率を達成するまでに何回かの試みを行ってから適切なテスト組み合わせを作ります。テストの組み合わせを決める際には、リソースを使いすぎないかが常に懸念材料になります。例えばI/O使用が多すぎる組み合わせでは、CPUに対する結果が不満足なものになり、その逆も同じです。このフェーズでは、全てのリソースに対して目標とするストレスのレベルに達するまで、基本的に何度も試行錯誤を繰り返すことになります。
各テストがどのリソース（CPU、メモリー、またはI/O）に影響するか、どのくらい利用しているのかをリアルタイムで素早く判定するには、topツールが便利です。sarツールはネットワーク利用統計の集計や、一定時間に渡る全利用データのスナップショットをファイルに記録するのに便利です。
組み合わせを選択したら、リソース利用を正確に評価するために、テストをかなりの期間に渡って実行する必要があります。テストの実行時間は各テストの長さに依存します。複数のテストが並行で実行されていることを考慮すると、テスト時間は十分に長くとり、最も時間がかかるテストでも適切に終了するようにする必要があります。sarツールもこの評価中に実行している必要があります。評価用にテストを実行した後は、４つのリソース全ての利用レベルを集計して評価します。
次の例は、CPU、メモリー、ネットワーク利用に対するsar出力を示しています。
リスト1. sarの出力結果の例
10:48:27 CPU %user %nice %system %iowait %idle
10:48:28 all 0.00 0.00 0.00 0.00 100.00
10:48:29 all 3.00 0.00 1.00 0.00 96.00
10:48:30 all 100.00 0.00 0.00 0.00 0.00
10:48:31 all 100.00 0.00 0.00 0.00 0.00
02:27:31 kbmemfree kbmemused %memused kbswpfree kbswpused %swpused
02:29:31 200948 53228 20.94 530104 0 0.00
02:31:31 199136 55040 21.65 530104 0 0.00
02:33:31 198824 55352 21.78 530104 0 0.00
02:35:31 199200 54976 21.63 530104 0 0.00
02:27:31 IFACE rxpck/s txpck/s rxbyt/s txbyt/s
02:29:31 eth0 738.79 741.66 76025.55 136941.85
02:31:31 eth0 743.30 744.97 76038.82 136907.77
02:33:31 eth0 744.80 745.02 76135.53 136901.38
02:35:31 eth0 742.35 744.34 75947.45 136864.77
|
カーネルのテスト対象範囲を分析する
システムのストレステストでは、カーネルの対象範囲を適切に設定することも重要です。ある組み合わせで選択したテストでは４つの主なリソースを十分に利用しているかも知れませんが、実はカーネルのごく小さなサブセットを実行しているだけなのかも知れません。ですから対象範囲を分析して、その組み合わせがシステムのストレステストとして適切であること、システム負荷テスト生成器にはなっていないことを確認する必要があります。Linuxカーネルのテスト対象範囲分析に役立つオープンソースのツールとして、現在次の２つがあります。
-
gcov: Linux Test Projectがメンテするオープンソースのツールです。このツールはカーネルの対象範囲を分析し、対象となっているのがどの行や機能、分岐なのか、またそれらに対して何度アクセスしているかをレポートします。
-
lcov: IBMが開発し、Linux Test Projectがメンテするオープンソースのツールです。このツールはテキストベースのgcov出力の上に作られる一連のPerlスクリプトから成り、HTMLベースの出力を実装しています。この出力に含まれているのは、対象範囲のパーセント割合、グラフ、対象範囲のデータが素早く見られる概要ページなどです。どちらのツールもLinux Test Project (LTP)のホームページ（参考文献）に置かれています。
gcovモジュールをロードできたら、システム・ストレステストとしての組み合わせで実行するテストを、すべて実行する必要があります。元々のストレステストは並行実行ができ、また並行実行する必要があるかも知れませんが、この実行では繰り返しで行う必要があります。各テストは一度だけの実行で完了し、どのテストも繰り返しは行わずに、一つが終わったら次のテスト、という風に実行する必要があります。システム・ストレステストを複数、並行で実行すると、カーネルが負荷を平衡させようとして予期しないコードや対象範囲外のカーネルコードを実行する可能性があるため、その可能性を単一実行の繰り返しで極力防ごうとするわけです。最終ステップとして、分析用にデータを整備するためにlcovツールを実行し、gcovモジュールをアンロードします。
lcovツールは、カーネル中にある全てのコード行と、各行が（実行された場合は）何度実行されているのかのデータを含んだ完全なHTMLツリーを生成します。このツールは対象範囲のデータを数値化し、カーネルの各セクションやファイルに対して対象範囲のパーセント割合を生成します。下に挙げたのはテスト対象範囲の出力の例です。
図1. gcov出力の例
「適切な対象範囲（adequate coverage）」を緑色として定義しているのはlcovをメンテしている人たちなので、lcovの例は単なる意見にすぎません。ただし生のデータが含まれているので、それを見る人が自分なりの判断をすることができます。ですからテストを作成する人が、対象範囲の分析結果を評価した上で、対象範囲を変更/増加するためにテストの組み合わせを変更できるのです。
最終ストレステストを評価する
システム・ストレステストの検証が最終ステップの目的です。安定だと思われているカーネル上でストレステストを行います。ディストリビューションに含まれているカーネルは通常この要求を満足するものですが、常に満足するわけではありません。sarツールも実行しながら、長期間（最低でも24時間以上が推奨です）に渡ってストレステストを行いますが、これには２つの理由があります。
- 組み合わせの中に問題があった場合でも、においをかぐ程度の短時間テストでは気が付かず終わってしまうのが、長時間実行することで問題が見つけられる。
- sarで得られたデータが、将来のテスト実行のための比較の基礎となる。
長期間テストが終了すると、そのテストの組み合わせがシステム・ストレステストの候補として適切なものかどうかを、収集した全データに基づいて判断できるようになります。
図2. 設計プロセスの要約
Linux Test Projectでは、この設計手法を使ってLinuxカーネルのストレステスト・スクリプトltpstress.shを設計しました。このアプリケーションはLTPのテスト・スイートの様々な領域からの複数のテストを組み合わせており、メモリー負荷生成やネットワーク・トラフィック負荷生成等も含まれています。このテストは実行前に、システム中に実メモリーと仮想メモリーがどのくらいあるかによって、メモリーの使用量を調整しています。このテスト・スクリプトはLTPテスト・スイートで入手できます（参考文献）。このスクリプトはテスト結果が確実に正確なものとなるように、研究所で条件を調整した中で生成したものです。
IBM Linux Technology Centerのテスト部門では、Linuxカーネル・リリースの安定性検証を比較的素早くしかも手軽に行うための手段として、他のツールやテストと共にこのストレステストを使っています。対象範囲が適切なものになるように、研究所内での条件に加えて模擬的な顧客シナリオの元でもテストを行っています。
参考文献
- ストレステストのシェルスクリプトや、その他の便利なテストがLinux Test Project home pageにありますので、ダウンロードしてください。
-
IBM Linux Technology Centerの使命は、Linux開発コミュニティと直接協力しながら、Linux成功のための共通目標に向かって進むことです。
- OSDLのLinux Kernel Scalable Test Platform (STP)では、オンラインのパフォーマンスやスケーラビリティ・スイートに関して開発者がカーネル・パッチをテストできるようなフレームワークを提供しています。
- LTPのストレステストではユーティリティ
top（procpsパッケージの一部）とsar（systatの一部）を利用しています。
- またLTPストレステストは、GNUの対象範囲テストのプログラムgcovと、Perlベースで得られるgcovの結果をHTML化するlcovをうまく利用しています。
-
カーネル比較: 2.4から2.6へのカーネル開発における改善（developerWorks, 2004年2月）は、2.6がそれ以前のどれよりも優れたものとなったのはどのようなツールやテスト、手法等によるものなのかを解説しています。
-
カーネル比較: 2.4と2.6でのWeb処理（developerWorks, 2004年2月）は、IBM Linux Technology CenterによるWebサービスに関するテスト成果を紹介しています。
-
Linuxカーネルの性能と拡張性の改善（developerWorks, 2003年1月）では、一定期間に渡ってのテスト結果比較のためにLinuxのパフォーマンスを数値化するにはどうすべきかを、Linux Technology CenterのLinux Kernel Performanceチームが説明しています。
-
Putting Linux reliability to the test（developerWorks, 2003年12月）は、Linuxカーネルやその他のOSコンポーネントに対するテスト結果と分析をIBM Linux Technology Centerが文書化したものです。
-
Linuxカーネル・デバッガー内部（developerWorks, 2003年6月）はカーネル実行のトレース方法、またメモリーやデータ構造を調べる方法を説明しています。
- developerWorksLinuxゾーンにはLinux開発者のための資料が豊富に用意されています。
- Developer BookstoreのLinuxセクションではLinux関係の技術書を値引きして購入できます。
-
developerWorks Subscriptionを利用して得られる最新のIBMツールやミドルウェアを使って、Linuxアプリケーションの開発やテストを行ってください。WebSphere®やDB2®、Lotus®、Rational®それにTivoli®等のIBMソフトウェアと12ヶ月間使用可能なライセンスを、想像されるよりもはるかに安価に入手できます。
- Linux上で実行する、より抜きのdeveloperWorks Subscription製品の無料の試用版をダウンロードしてください。developerWorksのSpeed-start your Linux appセクションからWebSphere Studio Site DeveloperやWebSphere SDK for Web services、WebSphere Application Server、DB2 Universal Database Personal Developers Edition、Tivoli Access ManagerそれにLotus Domino Serverが入手できます。もっと手早くしたければ、ハウ・ツー記事や技術サポートが製品毎に集められていますので、ご自由に入手してください。
著者について  | | | Robbie WilliamsonはIBM Linux Technology CenterのStaff Software Engineerです。2000年にコンピューター・サイエンスの学位でテキサス大学を卒業し、サポート、検証技術者として、またUNIXの各種実装開発の領域で活躍してきました。Linux Test Projectの維持管理者の一人でもあります。 |
記事の評価
| 
