BT

InfoQ ホームページ ニュース ElasTestで実現するテスト時の可観測性

ElasTestで実現するテスト時の可観測性

ブックマーク

原文(投稿日:2019/03/14)へのリンク

分散アプリケーションでは,非分散アプリケーションで一般的に使用されているデバッグテクニックを使うのは困難である。テスト環境においても運用時のような可観測性を実現すれば,バグの検出が容易になる,とFrancisco Gortázar氏は,European Testing Conference 2019で主張し,可観測性を使って複雑な分散システムのテストと評価を行うツールとして,ElasTestを紹介した。

可観測性は,アプリケーションの振る舞いに関する理由を理解するのに役立つ,とGortázar氏は言う。分散システムの振る舞いを理解する唯一の手段は,それが生成するデータ(外部出力)を見て内部状態を把握することである。可観測性の目的は,観測対象のアプリケーションからテスタや開発者にとって有用な情報を取り出すことだ,とGortázar氏は主張する。

ビジネスに近い高レベルの抽象化を構築することにより,関心の対象とするイベントを,ユーザに直接的な影響を与えないと思われるものから区別することが可能になる,とGortázar氏は提案する。運用時においては,最初は生の測定値から始めるのが通常だが,少し経てば独自のメトリクスが設定され,それにアラームが設定されるようになる,と氏は言う。すべてのものを常に収集するには,膨大な情報を管理する必要がある。そのためGortázar氏は,動的なサンプリングを使用して関係性の低いイベントの収集を回避し,問題点に集中するように提案する。異常が起きた場合には,より多くの情報を収集することで,問題のより正確な診断と,場合によっては解決方法を見つけることが可能になる。

ElasTestはテスト環境における可観測性を提供するオープンソースツールで,複雑な分散システムのテストと評価の支援を目的とする。提供する機能はELKスタックと同等だが,テストプロセスを意識していることが大きな違いだ。ElasTestはテストの何たるかを理解しており,必要に応じて関係する情報を収集し,個別のバグやテストを簡単に確認できる方法で表示することができる。

ElasTestプロジェクトはEUの出資による公的資金によって運営されている。プラットフォームは欧州内にある学術機関や研究センタ,大企業や中小企業からなるコンソーシアムによって開発されており,オープンソースのソフトウェアコミュニティで一般的なツールやサービスが使用されている。

InfoQではEuropean Testing Conference 2019についてお伝えするとともに,テストの可観測性についてFrancisco Gortázar氏から話を聞いた。

InfoQ: 分散システムやクラウドネイティブなアプリケーションの中で起きていることに関する情報の収集が難しいのはなぜでしょう?

Francisco Gortázar: 基本的には2つの大きな問題があります。ひとつは,異なるマシン上で動作しているさまざまなサービスから情報を集めなくてはならない,という点です。オンラインないしオフラインで調査を行うには,すべての情報を中央のデータベースに送信する,特別なソフトウェアを用意する必要があります。もうひとつは,生成されるデータの量に関わる問題です。大量のデータが発生するので,データを削除するための適切なポリシが必要です。

これに加えて,テスト環境には運用環境とは異なる,特有の性質がいくつかあります。運用で使用されているものと同じツールでは,デプロイや設定に非常に苦労する場合もありますし,企業がテスト環境への投資には積極的でない,という事情もあります。運用チームは一般的に運用システムの管理に忙殺されているので,その他の環境に時間を割くことはできないのです。

InfoQ: 可観測性を確立する上で,何かアドバイスはありますか?

Gortázar: 運用システムには,適切なレベルの可観測性の設定を支援するさまざまなツールがありますが,これらをすべてまとめて,必要とする視覚化や抽象化を実現するには,多大な労力を必要とします。

理想を言えば,運用で使用しているものと同じツールをテスト環境でも使用するべきです。しかしながら,こういった可観測システムを担当するチームは,通常は同じツールセットを他の環境にデプロイするような時間を持ち合わせていません。そのような場合,少なくとも開発者やテスト担当者であれば,もっと単純なツールを使って,ある程度の可観測性をテスト環境で実現することが可能です。

InfoQ: エンドツーエンドテストで可観測性を向上するには,どのようなツールがあるのでしょうか,それはどのように使用できますか?

Gortázar: いわゆるELKスタック(ELKはElastic Search Logstash and Kibanaの略で,Elastic co.が提供する,生ログとメトリクスを管理する共通ツールセット)と,同じ会社が開発したBeatエージェントを使用すれば,システムのログやメトリクスの収集が非常に簡単になります。テスト対象とするシステムにこれらのエージェントをデプロイして,情報をElasticSearchデータベースに送信させるのは,さほど難しい作業ではありません。フェールしたテストについては,Kibanaを使って問題を詳細に調査することができます。Kibanaでは,収集したメトリクスをグラフ化したり,ログをクエリしたりすることが可能です。この2つの機能は,バグをローカライズする上で役に立ちます。

ただし,これらのツールをテスト環境で使用する場合には,いくつかの制限があります。特に継続的インテグレーションシステムに関しては,状況はまったく異なります。通常,情報が収集できるのは,この統合プロセスの一部として実行されるテストの間のみです。しかもこの情報は,テストがフェールした場合,つまりは,アプリケーションの一部が期待どおり動作しない場合にのみ有効なのです。この情報が調査されるのは,通常は,問題の根本原因を探している場合に限られます。ただし,この情報の内容からシステムの動作を理解するのは非常に困難です。例えば,ダッシュボードは一般的に,テストのバウンダリ(いつ始まったか,いつ終わったのか)を理解していません。開始時点と終了時点が分からなければ,関連性のないテスト情報を除外することはできないのです。ですから,関心のある情報を分離することが,標準的な監視ツールの問題のひとつになります。

InfoQ: バグの根本原因を見つけるためには,何ができるでしょうか?

Gortázar: 分散システムでは,バグの根本原因を探すことが簡単でないのは間違いありません。問題に直面した時,私は,成功した時と失敗した時の実行結果を並べて比較するようにしています。ログは実行毎に大きく違う可能性があるため,これが困難なのです。このようなツールには,共通パターンを認識して,実行毎に異なる可能性のある無関係な情報を排除できることが求められます。

このような比較機能は,他の種類のメトリクスでも使用できる必要があります。2回連続して実行した場合のメモリ使用量やリクエストのレイテンシが比較できれば,2回目が失敗した理由が分かるかも知れません。

一般論として,このタスクにはもっと専門的なツールが必要です。テスト環境では,保存するデータに関しては比較的コントロールが可能ですが,テストプロセスに関するツールへの認識をもっと高くする必要があります。この方法で,テスト実行中に必要な情報を収集して,そのテストがフェールした理由を理解するために必要な抽象性を提供することが可能になります。私たちは現在,ElasTestで収集した情報を視覚化して,バグの特定をより短時間で,より正確に行えるような方法を検討しています。継続的インテグレーション環境に関しては,まだ改善の余地が多いと思っています。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。