Clever Geek Handbook

分散システムのテスト-Andrey Satarin、Yandexのインタビュー







分散システムのテストは、集中システムのテストとは大きく異なります。 この分野で真剣な知識と経験を誇るテスターはほとんどいません。



ハイゼンバグ2016年モスクワ会議Andrei Satarin （ twitter.com/asatarin ）のスピーカーと話をしました。 AndreiはMail.ru、Kaspersky Lab、Deutsche Bankのテストプロジェクトに参加し、現在Yandexの分散システムをテストしています。 この記事は、テストに携わっている人だけでなく、開発者にも役立ちます。 分散システムのテストの問題に対処したことがない場合は、内部で歓迎されます。



アンドレイ・サタリン：



...彼らは勤務時間中にノードを強制終了し、開発者は監視しています...



分散システムをテストする方法と機能



-分散システムをテストするための方法と戦略はありますか？ それらはどう違うのですか？



-分散システム用のよく知られている古典的なアプローチ（単体テスト、システムテスト、統合テスト）に加えて、複雑な欠陥を検出するために設計された追加のアプローチがあります。



障害挿入アプローチは非常に一般的です。 システムが機能する場合、特別なプログラムとメカニズムを使用して障害を追加します。ディスクまたはマシン全体の障害、おそらくネットワーク障害、テスト対象システムの内部コンポーネントの障害です。 分散システムの大部分は、少なくともある程度はそのような障害に耐える必要があるため、システムは作業を停止したり、作業の異常を示したりしないでください。 実際、これは分散システムの最も重要な非機能要件の1つであるため、フォールトトレランステストです。 動作するマシンが多いほど、それらのマシンで個々の問題が発生する可能性が高くなります。 たとえば、1000台の車が関与している場合、比較的言えば、ディスクは週に1回飛び出します。 システムはそのような状況に気づかないで生き残る必要があります。



正式な検証など、より学術的なアプローチがあります。 分散システムには、動作を可能にする内部アルゴリズムとプロトコルがあります。 それら自体は非常に複雑ですが、システム内の障害、ネットワーク上のパケットの並べ替えなどに関係なく、常に達成されるべき不変条件を保証します。 アプローチの本質は、特別な言語でのアルゴリズムの記述のみに基づいて、その正確性がチェックされるということです。 これにより、使用されているアルゴリズムが正しく実装されていれば機能するという確信が得られます。



2015年、Microsoft Researchの学術論文「 Proving Practical Distributed Systems Correct 」が公開されました。そこでは、分散ストレージシステムのモデルについて説明し、その後、特別なツールを使用してこのモデルの正確性をチェックし、すぐに機能するコードを生成しました。



-分散システムをテストする際に考慮すべき機能は何ですか？



-特異性は、テスト対象のシステムがどの不変式を保証するかを正確に理解することが重要であることです。 たとえば、nosqlデータベースは現在では人気があり、より高いパフォーマンスが得られる可能性がありますが、トランザクションはサポートしていません。 つまり、それらの一貫性レベルは、従来のもの（MySql、PostgreSQL、Oracle）よりも低くなっています。 また、nosqlデータベースなどのそのような分散システムをテストする場合、サポートする不変式を正確に理解することが重要です。 テストで観察される異常はこれに依存します。 複雑なテストでは、たとえば、競合するライターやリーダーが複数いる場合、さまざまな条件を確認できます。 つまり、システムで観察できる効果とそうでない効果を理解する必要があります。



機能以外の要件が最も重要な役割を果たします。



-分散システムをテストするときに人々が犯す典型的な間違いは何ですか？



-最も一般的な間違いは、システムが提供すべきすべての保証をチェックすることではありません。その場合、システムは十分にテストされなくなります。 高価になる可能性のある2番目の間違いは、システムのどの部分の障害についてもテストしないことです。 経験によれば、分散システムで一部のサブシステムの障害挿入がテストされていない場合、多くのバグよりも少し多くのバグがあります。



-分散システムのどのメトリックと特性をテストすることが重要であり、その理由は何ですか？



-非機能要件のうち、これは、第一に、耐障害性（耐障害性）であり、第二に、パフォーマンス（性能）です。 分散システムでは、機能要件に比べて非機能要件が最も重要な役割を果たします。 システムが最初に動作する必要があるため、フォールトトレランスが最初になります。システムが動作しない場合、残りはそれほど重要ではありません。



-テストのパフォーマンスはどれほど重要ですか？ 分散システムのテストを開発するときに、ネットワーク遅延の可能性を考慮する必要がありますか？



-問題のテストの種類によって異なります。 これらが単体テストである場合、パフォーマンスが重要です。 一般的なケースでは、もちろん、迅速なテストを行うことをお勧めします（彼らが言うように、健康で豊かな方が良いです）。 これは機能テストに当てはまります。 一貫性やフォールトトレランスなどをチェックする機能しないものの場合、より頻繁な欠陥に対してテストパフォーマンスが重要です。 たとえば、100万回の操作ごとに1回不具合が発生した場合、これらの操作が頻繁に発生するほど、不具合が頻繁に発生します。 1時間かかる場合、これはまったく問題ありません。 これに数日かかる場合、そのような欠陥を見つけることが問題になります。



すべての欠陥の98％がわずか3つのノードで再現可能



-テスト用に特別なクラスターを作成する必要がありますか、または実稼働中の「戦闘」クラスターを使用できますか？ テストクラスターの最適なサイズを決定する方法



-ほとんどの場合、テストクラスターが使用されます。 戦闘サーバーでのテストについて話す場合、最も広く知られている例はNetflixの会社です。これは、「 サル軍 」、つまり「マカク軍」と呼ばれるアプローチを積極的に推進しています。 それは、実稼働環境で障害挿入を行うという事実にあります。 彼らは勤務時間中にノードを直接殺し、開発者はシステムが決して劣化しないことを確認します。 しかし、ここでは、そのような機会はある程度の規模から始まっていることを理解する必要があります。 システムが10〜20個のノードで実行されている場合、同様の方法でテストすると、5〜10％の低下が発生します。 生産では、誰もがそのような犠牲の準備ができているわけではありません。 さらに、何らかのサービスレベル契約（SLA）が存在する場合があり、そのようなテストは違反のために費用がかかる可能性があります。 いずれにせよ、実稼働環境でテストを実施している場合でも、その前に巨大なテストインフラストラクチャがあり、ほとんどの欠陥をキャッチします。 実稼働環境でテストする利点は、生産的な環境を繰り返す必要がないことです。



テストクラスターのサイズについて。 システムが分散されている場合、複数のシステムである必要があります-これは以下からの制限です。 上記の制限のトピックには、「 簡単なテストで最も重大な障害を防ぐことができる 」という題名の記事があり、分散システムにどのようなエラーがあるのか​​を調べています。 記事によると、研究者は、すべての欠陥の98％がわずか3つのノードで再現できると結論付けました。 具体的には、通常、テストクラスターは8つのノードで構成されますが、これはシステムの内部構造によるものです。



-テスト中の分散システムの全体的または部分的な障害への対処方法



-テスト環境では規模がはるかに小さいため、おそらくこれに対処する特別な方法はありません。 不良鉄が大きく干渉する場合、テスト環境から単純に除外できます。 テスト用ハードウェアがクラッシュした場合がありましたが、異常な欠陥を見つけることができたため、喜んでいる可能性が高くなりました。 分散システムは障害に対して回復力がある必要があるため、テストでも問題を引き起こすことはありません。



-テスト環境を作成するために使用される特定の技術とツールは何ですか？ テストを自動化するには？



-テスト環境は、開発に使用されているテクノロジーと、チームに馴染みのあるテクノロジーに依存します。 たとえば、Pythonはそのようなタスクに適しているため、テスターはそれを知っているため、積極的にPythonを使用しています。 テストを書くという点では単純で、明確に書けるように十分なレベルです。 私の意見では、並行性に多少の「問題」がありますが、この問題は解決できます。 システム自体はC ++で開発されていますが、高速で簡単に動作せず、テストでは開発速度が重要であるため、高レベルのテストに使用することは非常に困難です。



テストの自動化について。 通常、テストのリポジトリが構築され、特別なサーバーで自動的に起動されます。 これには、TeamCityと社内開発の一部を使用します。



「この件について追加したいことはありますか？」



-分散システムのテストのトピックには、学術的および業界に近い膨大な量の資料があり、非常に多くのアプローチとテスト方法があることを付け加えたいと思います。 メソッドの検索と改善は、1日で終わりません。 このトピックは絶えず進化しています-それが興味深い理由です。





Heisenbagカンファレンスのラディソンスラビャンスカヤホテルで、12月10日にテストに関するより多くのレポートを聞くことができます。 登録はまだ開いています。



レポートのテーマ：





More articles:


All Articles