Andrey Satarinは、Yandexで分散システムのテストを行っています。 彼はまったく異なるプロジェクトに参加しました。彼は、Kaspersky Labのクラウド検出システムであるMail.ruと、ドイツ銀行の通貨価格計算システムでゲームをテストしました。
-フォールトトレランスは、分散システムの最も重要な非機能要件の1つです。 フォールトトレランスはどのようにテストされますか？
Andrey Satarin：テスト環境で失敗をエミュレートできます。これは、Kyle Kingsburyによって作成された有名なJepsenツールの仕組みです。 2番目のアプローチは、生産的な環境での障害の導入を伴い、通常、Netflixのカオスモンキーに関連付けられています。 製品環境の繰り返しの問題から私たちを救い、システムのパフォーマンスに高い信頼を与えますが、より危険であり、製品の一定の成熟度が必要です。
TLA +などの特別なツールを使用してコードを記述する前でも、アルゴリズムのパフォーマンスを確認できる3番目のアプローチがあります。 最もよく知られている2つの使用例は、 Amazon Web ServicesとAzure Cosmos DBです。
-テストクラスタまたは稼働中のシステムを使用する方が良いと思いますか？ 各アプローチの長所と短所は何ですか？
アンドレイ・サタリン：すべてのアプローチは受け入れられますが、テストクラスターでは何でもでき、システムにさらに危険な状況を作り出すことができます。作業環境に多くの障害を導入する価値はありません。 。 ここで、たとえばハードウェアやその他のクラスターリソースを並べ替える必要があります。 一方、実稼働環境でのテストでは、使用する構成の操作性に対する信頼が追加されます：多くの場合、作業環境はハードウェアだけでなく、テストクラスター内のシステムの同様の動作を実現することが常に可能であるとは限りません。
テストでは通常合成負荷を使用しますが、システムはかなり複雑な動作をする他のシステムと連携できます。 この相互作用をエミュレートすることは難しく、本番環境では機能の幅に関してより多くのカバレッジを達成できます。 しかし、繰り返しますが、このアプローチはよりリスクが高く、使用するには成熟した製品が必要です。 開発された応答システムが必要です。つまり、たとえば午前3時に本番環境で障害を引き起こすことは不可能です。これは人々にとって非常に困難です。 通常、これはチーム全体が利用できる営業時間中に行われ、複雑な問題でさえ比較的迅速に解決できます。
-分散システムのフォールトトレランスをテストする際の最も一般的なエラーは何ですか？
Andrei Satarin：私の意見では、最も重要な間違いはシステムの誤解です。 システムが何をするのか、どのような制限があるのか、どのようにテストするのかを明確に理解する必要があります。 たとえば、稼働時間の要件がある場合、障害が発生した場合にそれらを確認する方法は？
データの損失につながらない小さな問題でも、SLAを破ることができます。 実際にどのような障害が発生するかを理解する必要があります。それらを実装する可能性は非常に高いためです。しかし、システムは特定のクラスの障害に対して設計上準備が整っていない場合があります-状況を分けて、システムをテストしないでください原則は機能しません。
-分散システムのパフォーマンスをチェックする主な方法は何ですか？ どのような微妙な点、落とし穴がありますか、テスト中にどのような間違いがありますか？
Andrei Satarin：ここでのアプローチは、単一ノードで構成されるシステムをテストする場合とほぼ同じですが、動作のみが少し複雑です。 パフォーマンステストの結果を分析するには、システムの動作を十分に理解する必要があり、これを一人の人間の頭の中に収めることはできません。
非常に重要なポイントは、実験結果を同僚に伝えることです。 私たちの実践では、誰かがシステムの一部のパフォーマンスを調べてから、データと結論を一般ニュースレターに送信するとよく起こります。他のチームメンバーが実験を分析し、いくつかの側面を追加します。 システムの他の部分をよく知っている同僚と協力して、さまざまな角度からそれを見ることが重要です。
分散システムのパフォーマンスをテストする際のもう1つの重要なポイントは、スケーラビリティの指標です。 多くの場合、テストクラスター内の10個のノードでシステムが正常に機能する状況がありますが、100個のノードで運用環境で実行しようとすると、ボトルネックが発生し、ワーキングクラスターのパフォーマンスが、たとえば2倍しか高くないことが明らかになります。 この問題を小規模で先験的に評価することは非常に困難です。通常、食品環境はテスト環境よりも1桁大きくなります。 コストが高いため、同じ規模のテストクラスタを作成することはほとんど不可能であり、システムのスケーラビリティをテストするための特別なアプローチを考え出す必要があります。
-非機能要件の充足をテストする場合、他にどのようなニュアンスがありますか？
Andrey Satarin：システムの一部のノードは、ハードウェアの問題や、他のサービスによるリソース消費が多すぎるなどの理由で動作が遅くなる場合があります。 多くの場合、このようなマシンはシステム全体の速度を大幅に低下させます。問題のあるノードをオフにするだけでパフォーマンスが回復しますが、製品環境ではそれらを自動的に検出することは困難です。
もう1つの重要なポイントは、システム構成のテストです。 コードは正常に機能する可能性がありますが、複雑な分散システムでは多くの構成パラメーターがあり、それらの誤った構成により、パフォーマンスの低下、またはデータ損失が発生する可能性があります。 この状況の良い例は、 Paxos Made Live-An Engineering Perspectiveで説明されています 。 5つのノードで動作するように構成されたクラスターが4つのノードで動作するGoogle Chubbyの状況についてです。 もともとシステムに配置されていたフォールトトレランスシステムのおかげで、サービスは機能しましたが、2つのノードの損失に耐えることができなくなりました。
-テスト自体のパフォーマンスはどのくらい重要ですか？また、どのように改善できますか？
Andrei Satarin：古典的なテスト（モジュラー、システム、統合）について話せば、それらは十分に速いはずです。 分散システムでの高レベルのテストには、はるかに時間がかかります。 たとえば、これらが障害のランダムな実装である場合、障害の可能性のあるスペースを長時間ソートする必要があり、時間を削減する基本的な方法はありません。通常は数時間または数日です。
特に実際のハードウェアで行う場合、さまざまな組み合わせの障害を短時間でエミュレートすることはできません。 しかし、システムに与える負荷が大きいほど、欠陥を見つける可能性が高くなります。 負荷生成部分は迅速に動作するはずです-これは本当に重要です。 ここでは、テストを並行して実行するか、システムを集中的にロードするためのいくつかのトリックを実行することのみをアドバイスできます。
-分散システムの非機能パラメーターのテストを自動化するツールはありますか？
Andrei Satarin： Apache Cassandra、MongoDBなど、かなり幅広いクラスのさまざまなシステムに使用される有名なJepsenツールがあります。残念ながら、ボックスから起動することはできません。プログラムする必要があります。 テスト中のシステムに合わせて既存のツールを研ぐ必要があり、それらのエントリのしきい値は非常に高くなります。 パフォーマンスの観点からは、すでに説明したCassandraやMongoDBなどのさまざまなリポジトリをチェックするYahoo Cloud Server Benchmarkなど、さまざまなベンチマークがあります。
-分散システムのテストの分野でまだ解決されていない問題は何ですか？ この分野の主な開発動向について教えてください。
Andrei Satarin：この分野は成熟しつつあり、多くの企業はJepsenのような洗練されたテストを使用して、システムの一貫性レベルのチェックで障害を導入し始めています。 最近、すでに述べた形式的な方法が積極的に使用されています-TLA +および分散システムに組み込まれたアルゴリズムの形式的な検証。
もちろん、ここには落とし穴があります：正式な仕様からコードが生成された完全に検証された分散システム（Microsoft Researchにそのような開発があるなど）でさえ、とりわけシステムのフォールトトレランスとセキュリティに影響する欠陥が残っています 。
Heisenbug 2017では、Andrei Satarinがサニタイザーの使用について説明します。サニタイザーは、C ++プログラムの複雑な欠陥を見つけることができる素晴らしいツールです。 Yandexでは、分散システムのテストに積極的に使用されています。
食事の前に手を洗ったり、テスト中に消毒剤を洗う
完全な会議プログラムはサイトで入手できます 。