マイクロサービスの原動力

さまざまなビジネス機能を互いに独立して開発、展開、および拡張できることは、マイクロサービスアーキテクチャに切り替えることの最も一般的な利点の1つです。

思考の達人はまだこの声明が真実かどうかを判断することはできませんが、マイクロサービスはすでに流行しています-そして、ほとんどのスタートアップにとって事実上デフォルトのアーキテクチャになるほどで​​す。

ただし、マイクロサービスのテスト （または、さらに悪いことに開発 ）に関しては、ほとんどの企業が、すべてのコンポーネントを一緒にテストするという時代遅れの方法にまだ固執しています。 複雑なインフラストラクチャの作成は、 各サービスの一連のテストを実行する必要があるエンドツーエンドテストを実行するための前提条件と見なされます。これは、サービスに回帰や互換性のない変更がないことを確認するために行われます。

翻訳者から。 で Cindy Sridharanによるオリジナルの記事は、確立されたロシアの対応するものがない多くの用語を使用しています。 場合によっては、使用されている英語を使用しますが、ロシア語で書くのが合理的であると思われます。論争のある場合は、誤った解釈を避けるために、元の用語を書きます。

今日、世界にはソフトウェアテストのベストプラクティスに関する書籍や記事があります。 ただし、本日の記事では、バックエンドサービスのテストのトピックのみに焦点を当て、デスクトップアプリケーション、特別な技術的なセキュリティ要件を備えたシステム、GUIツール、およびその他の種類のソフトウェアのテストには触れません。

さまざまな専門家が「分散システム」の概念に異なる意味を入れていることは注目に値します。

今日の記事の一部として、「分散システム」とは、それぞれが異なる保証と種類の障害を持つ多くの可動部品で構成されるシステムを指し、これらの部品は特定のビジネス機能を実装するために連携して動作します。 私の説明は、分散システムの古典的な定義に非常に似ているかもしれませんが、私が定期的に遭遇するシステムに適用されます-そして、私たちの大多数はそのようなシステムを開発しサポートしているに違いありません。 さらにこの記事では、今日では「マイクロサービスアーキテクチャ」と呼ばれる分散システムについて説明しています。

「ボックス内のフルスタック」：注意事項

開発者のラップトップでローカルにサービストポロジを完全に再現しようとしている企業に対処しなければならないことがよくあります。 Vagrantボックスにスタック全体を展開しようとした最後の作業場所で、私はこのエラーに個人的に直面しなければなりませんでした。 Vagrantリポジトリは「ボックス内のフルスタック」と呼ばれていました。 ご想像のとおり、1つのシンプルな浮浪者チームが、社内のエンジニア（フロントエンドおよびモバイル開発者も含む）が、作業用ラップトップにスタック全体を完全にデプロイできるようにするという考えでした。

実際のところ、これはAmazon規模の本格的なマイクロサービスアーキテクチャではなく、何千ものサービスを含んでいます。 バックエンドには2つのサービスがありました。geventベースのAPIサーバーと、バックグラウンドで実行される非同期Pythonワーカーで、 C ++のブーストを含むネイティブの依存関係がたくさんありました。 Vagrantの新しいボックスが起動するたびにゼロから作成します。

この会社での私の最初の週は、ローカルでのみ仮想マシンを作成し、非常に多くのエラーを打ち負かしただけです。 最後に、金曜日の夕方までにVagrantを動作させることができ、すべてのテストは私のPCで正常に動作しました。 最後に、他の開発者がそのような問題をより少なくするために、私が直面しなければならないすべての問題を文書化することにしました。

そして、新人の開発者がVagrantの設定を始めたとき、彼はまったく異なるエラーに遭遇したと思います。 実際、この壊れやすい設計はすべてラップトップでも息を吹き込みました.Pythonのライブラリを更新するのが怖かったのは、一度pipをインストールするとVagrantの設定が壊れ、ローカルで起動したときにテストの実行が停止したためです。

飛行報告会の過程で、VagrantはモバイルおよびWeb開発チームのプログラマーと同様の状況にあったことが判明しました。 Vagrantを使用したトラブルシューティングは、サポートチームに頻繁に依頼されるようになりました。 もちろん、Vagrantの設定をすべて「修正」するために一度だけ多くの時間を費やさなければならないと誰かが言うかもしれません。私の防衛では、説明されたストーリーはスタートアップで行われたと言います。エンジニアリングサイクルは永遠に何かを見逃しています。

フレッド・エバーはこの記事の素晴らしいレビューを書いて、私の気持ちを正確に説明する発言をしました。

...開発者のマシンでクラウドを起動するという要求は、これまでに遭遇した最悪の事態である新しいクラウドプロバイダーをサポートする必要性に相当します。

「コードとしてのインフラストラクチャ」、不変のインフラストラクチャ-最も最新の操作方法に従ったとしても、クラウド環境をローカルにデプロイしようとしても、それを引き上げて長期的なサポートを提供するための努力に見合ったメリットは得られません。

友人と話した後、説明した問題は、スタートアップで働く人々だけでなく、大規模な組織で働く人々にとっても人生を害していることがわかりました。 過去数年間、この設計が簡単にバラバラになり、運用と保守にどれほど費用がかかるかについて多くのジョークを耳にしました。 現在、会社の規模に関係なく、スタック全体を開発用ラップトップに展開するという考えは悪質であると確信しています。

実際、このようなマイクロサービスへのアプローチは、分散モノリスの作成と同等です。


^{2020年の予測：モノリシックアプリケーションは、人々が分散モノリスの不利な点に慣れた後、流行に戻りました。}

ブロガーの タイラー・トリスは次のように述べています。

彼はHacker Newsでのマイクロサービスの議論を心から笑った。 「開発者は環境をローカルに展開できる必要があります。他のすべては悪いツールの兆候です。」 ええ、もちろん、賢い人、異なるデータベースとMacBookに依存する20個のマイクロサービスを実行してみてください。 そうそう、docker composeがすべての問題を解決することを忘れていました。

どこでも同じこと。 人々は「モノリシック」なメンタリティを変えることなく、マイクロサービスの作成を開始します。そして、これは常に不条理の本当の劇場で終わります。 「1つの変更をテストするために、選択したサービス構成を使用してマシンでこれらすべてを実行する必要があります。」 私たちに何が起こったのか...

神が禁じている誰かが偶然くしゃみをすると、私のコードはすぐにテストできなくなります。 さて、このアプローチで頑張ってください。 多数のサービスを含む大規模な統合テストはアンチパターンですが、他の人を納得させるのは依然として困難です。 マイクロサービスへの切り替えとは、適切なツールとテクニックを使用することを意味します。 新しいコンテキストでの古いアプローチの使用を停止します。

業界全体を通して、私たちはまだ私たちから遠く離れた時代に発明されたテスト方法論に執着していますが、これは現在の現実とは非常に異なっていました。 完全なテストカバレッジ （一部の企業では、新しい機能を備えたパッチまたはブランチがコードベースカバレッジを一定の割合以上低下させると合併がブロックされるほど）、 テストによる開発 、システムレベルでの完全なエンドツーエンドテスト。

そのような信念は、複雑なCIパイプラインと複雑なローカル開発環境の構築に大きなエンジニアリングリソースが投資されるという事実につながります。 すぐに、このような拡張システムのサポートは、インフラストラクチャを作成、保守、トラブルシューティング、および開発するチームを含める必要性に変わります。 そして、 大 企業 がこのような高度な洗練度に余裕がある場合は、他の全員がそのままテストを実施する必要があります。これは最高のシステム検証です。 選択した価値の評価に賢明にアプローチし、妥協する場合、これが最良の選択肢になります。

試験範囲

テストはリリース前に行われることが一般に受け入れられています。 一部の企業では、開発チームが作成したソフトウェアの手動または自動テストを実行することが主な責務である個別のテストチーム（QA）があり、現在も存在しています。 ソフトウェアコンポーネントがQAに合格するとすぐに、起動のために（サービスの場合）運用チームに転送されるか、製品（デスクトップアプリケーションおよびゲームの場合）としてリリースされます。

このモデルはゆっくりですが、確かに過去のものです-少なくともサービスの面では。 サンフランシスコのスタートアップからどれだけ判断できるか。 現在、開発チームは、作成したサービスのテストと運用の両方を担当しています。 サービスを作成するためのこの新しいアプローチは非常に強力です。これにより、開発チームは、テスト方法の全範囲にわたって 、現実的な方法で、スコープ、目標、トレードオフ、および補償について真に考えることができます。 サービスがどのように機能するかを完全に理解し、それらの作業が正しいことを確認するために、可用性、信頼性、およびサービスの正しい操作に必要なパラメーターを考慮して、テスト方法とツールの適切なサブセットを選択する機能が明らかに必要です。


^{舌を外したように。 展開前のテストは、実稼働環境でのテストの部分的な準備です。 ステートメントを言い換えると、展開前にテストすることで、システムの偏ったメンタルモデルを教え、リハーサルし、強化することができ、実際に製品であなたに反して、現実に免疫を与えます。}

概して、「テスト」の概念は、従来「リリースエンジニアリング」、運用、またはQAの領域と呼ばれていたいくつかのタイプのアクティビティをカバーできます。 厳密に言えば、下の表にリストされている方法の一部はテスト形式とは見なされません。たとえば、 カオスエンジニアリングは 公式の定義では 実験形式として分類されています 。 さらに、上記のリストは決して網羅的なものではありません。 脆弱性テスト 、 侵入テスト 、 脅威モデリング （ 脅威モデリング ）およびその他のテスト方法は含まれていません。 ただし、この表には、私たちが毎日遭遇する最も一般的なテスト方法がすべて含まれています。



もちろん、表のテスト方法の分類は現実を完全には反映していません。実践が示すように、一部のテスト方法は一度に両方のカテゴリに分類できます。 したがって、たとえば、「プロファイリング」は本番環境でのテストに関連していますが、開発中によく使用されるため、本番環境でのテストに起因する可能性があります。 同様に、シャドーイング-プロダクションからの少量のトラフィックが少数のテストインスタンスで実行される方法-は、プロダクションでのテスト（実際のトラフィックを使用するため）およびプリプロダクションでのテスト（実際のユーザーには影響しないため）と見なすことができます。

プログラミング言語が異なれば、実稼働環境でのアプリケーションテストのサポートの度合いも異なります。 Erlangで記述している場合、仮想マシンプリミティブを使用して運用中のシステムをデバッグするための仮想マシンプリミティブの使用に関するFred Eberのガイダンスに精通している可能性があります。 Goなどの言語には、実行中のプロセス（実稼働環境でのテスト）または単体テストの実行（これは実稼働前のテストとして認定できます）のヒープ、ロック、CPU、およびゴルーチンのプロファイリングの組み込みサポートが付属しています。

実稼働環境でのテスト-実稼働環境でのテストに取って代わりますか？

前回の記事では、主に観測可能性の観点から、「ポストプロダクション」でのテストに多くの注意を払いました。 このような形式のテストには、監視、アラート、調査、および動的インスツルメンテーション（分析手順の実行可能コードへの挿入）が含まれます。 おそらく、実稼働環境でのテストには、 ゲーティングや機能フラグ（ 機能フラグ 、構成を使用してコードの機能を有効/無効にできる機能）の使用などの手法が含まれる場合があります。 ユーザーインタラクションとユーザーエクスペリエンスの評価-たとえば、A / Bテストと実際のユーザーモニタリングは 、 実稼働テストにも適用されます。

狭い円では、このようなテスト方法が実稼働前の従来のテストに取って代わることができるという議論があります。 最近、同様の挑発的な議論がTwitter Sarah Mayで始まりました。 もちろん、彼女はすぐにいくつかの難しいトピックを取り上げます。私はすべてに同意しませんが、彼女の発言の多くは私の気持ちに正確に対応しています。 サラは次のように述べています。

人気のある知恵は次のように述べています：コードをリリースする前に、回帰テストの完全なセットは「グリーン」であるべきです。 変更によってアプリケーションの他の部分が破壊されないことを確認する必要があります。 しかし、一連の回帰テストに頼らずにこれを検証する方法があります。 特に今、複雑な監視システムの全盛期と運用側のエラー率の理解で。

十分に高度な監視と大規模な場合、現実的な戦略は、コードを記述して製品にプッシュし、エラーの数を監視することです。 その結果、アプリケーションの別の部分で何かが壊れた場合、エラーの増加数から非常に迅速に明らかになります。 問題を修正するか、ロールバックできます。 簡単に言えば、監視システムが回帰テストと同じ役割を果たし、他のチームで継続的に統合できるようにします。

多くの人は、実稼働前にテストを完全に削除する価値があるかのように考えましたが、それはアイデアではなかったと思います。 これらの言葉の背景には、多くのソフトウェア開発者やプロのテスターが我慢できないという事実があります。多くの場合、手動テストまたは自動テストだけでは不十分な場合があります 。

本「 ソフトウェアテストで学んだ教訓 」（ロシア語への公式翻訳はありませんが、アマチュア語があります）には、「 自動テスト 」と呼ばれる章があり、著者はごく少数のバグのみが自動回帰テストを見つけると主張しています。

非公式の世論調査によると、自動テストを使用して検出されるバグの割合は驚くほど低いです。 適切に設計された自動テストが多数あるプロジェクトは、回帰テストがバグの総数の15％を検出できると報告しています。

通常、自動回帰テストは、後続のステージでのテストの実行中よりも、テスト自体の開発中に多くのバグを検出するのに役立ちます。 ただし、回帰テストを実行して、異なる環境（たとえば、異なるプラットフォームまたは異なるドライバー）でそれらを再利用する方法を見つけた場合、テストは問題を検出する可能性が高くなります。 実際、この場合、これらは以前にテストされていない構成をテストするために使用されるため、もはや回帰テストではありません。 テスターは、この種の自動テストでは30〜80％のエラーを検出できると報告しています。

もちろん、この本は少し時代遅れになり、回帰テストの有効性に関する最近の研究を見つけることはできませんでしたが、ここでは、自動テストの絶対的な優位性に基づいて最高のテストプラクティスと規律に基づいているという事実に慣れています。疑う試みは、あなたが異端者とみなされるという事実につながります。 サービスがどのように失敗するかを数年間観察して何かを学んだ場合、これは次のとおりです：運用前テストは、システム保証の小さなセットの可能な限り最高の検証ですが、同時に、それだけでは十分ではありません。長時間動作し、頻繁に負荷が変化するシステムのチェック。

サラが書いたことに戻る：

この戦略は多くの前提に基づいています。 これは、ほとんどの開発チームにはない複雑なオペレーティングシステムがチームにあるという事実に基づいています。 それだけではありません。 ユーザーをセグメント化し、異なるセグメントの各開発者の進行中の変更を表示し、各セグメントのエラー率を決定できることを前提としています。 さらに、このような戦略には、実際のトラフィックで実験するときに快適に感じる製品組織が含まれます。 繰り返しになりますが、チームが既にライブトラフィックの製品の変更についてA / Bテストを行っている場合、開発者が行った変更にアイデア自体を拡張するだけです。 これをすべて実行し、変更に関するフィードバックをリアルタイムで取得できれば、それは素晴らしいことです。

私の選択は、作成中のシステムに大きな信頼を得るための道の最大のブロックであるように思えます。 ほとんどの場合、より包括的なテストアプローチに移行するための最大の障害は、思考の必要なシフトです。 プリプロダクションでの習慣的なテストのアイデアは、キャリアの最初からプログラマーに浸透してきましたが、ライブトラフィックで実験するというアイデアは、運用エンジニアの特権であるか、アラームのようなひどいものに遭遇したかのいずれかです。

子供の頃から、私たちは皆、生産の不可侵な神聖さに慣れてきました。これは私たちがサービスをチェックする機会を奪っていても、私たちが遊ぶべきではありません。そして、私たちの多くに残っているのは他の環境であり、本質的には生産の薄い影にすぎません。 生産に「可能な限り類似した」環境でのサービスのテストは、ドレスリハーサルに似ています-それは良いことのように思えますが、満室と空室で話すことには大きな違いがあります。

サラの対話者の多くがこの意見を共有したことは驚くことではありません。 それらに対する彼女の答えは次のとおりでした。

彼らは私に次のように書いています：「しかし、あなたのユーザーはより多くのエラーを見るでしょう！」この声明は直接明白ではない誤解から成り立っています-私はどこから始めればよいかさえ知りません...

実稼働環境でのモニタリングテストから回帰を見つける責任を移すと、ユーザーはシステムでより多くのエラーを生成する可能性が高くなります。 これは、それに応じてコードベースを変更せずにこのアプローチを使用する余裕がないことを意味します-すべてがユーザーのエラーが目立たなくなるように機能する必要があります 実際、これはユーザーエクスペリエンスをより良くするのに役立つ有益なプレッシャーです。 「ユーザーはより多くのエラーを生成します」->「ユーザーはより多くのエラーを表示します」->「ユーザーは気にしません！」と言う人もいます。いいえ、これは絶対にそうではありません。

ここで、頭の爪に当たります。 運用後に回帰テストを監視に移行する場合、そのような変更には考え方の変更だけでなく、リスクを冒す意欲も必要になります。 さらに重要なことは、システム設計の完全な再設計と、高度なリリースエンジニアリングの実践とツールへの重大な投資が必要になることです。 言い換えれば、これは単にフェイルセーフアーキテクチャに関するものではありません。実際、 フェイルセーフプログラミングがここにあります。 一方、ゴールドスタンダードは、常にスムーズに実行されるソフトウェアプログラミングでした。 そして、ここで、開発者の大多数は間違いなく不快を感じるでしょう。

実稼働環境で何をテストし、実稼働前環境で何をテストしますか？

サービスのテストはスペクトル全体で表されるため、システム設計時には両方の形式のテストを考慮する必要があります（さらに、ここではアーキテクチャとコードの両方を意味します）。 これにより、システムのどの機能を生産前にテストする必要があるか、およびその特徴のうち、 機能の長い尾を連想させるものを、適切なツールとツールを使用して生産で既に最もよく研​​究することができます。

これらの境界がどこにあるのか、どのテスト方法がシステムの1つまたは別の機能に適しているのかを判断する方法は？ これは開発と運用によって一緒に決定されるべきであり 、これもシステム設計の段階で行われるべきです。 この段階の後のテストと監視に適用されたトップダウンアプローチは、その失敗を証明することができました。


^{「SREチーム」を雇用しても、サービスの信頼性は向上しません。 信頼性と安定性に対するトップダウンアプローチは機能しません。ここでは、ボトムアップアプローチが必要です。 これらの目標を達成するには、搾取をいじり続けるのではなく、SWEを信じなければなりません。}

チャリティーメジャーズは昨年Strangeloopでプレゼンテーションを行い、観測可能性とモニタリングの違いが「既知の未知数」と「未知の未知数」にどのように影響するかについて話しました。


2017年のStrangeloopに関するCharity Majorのレポートからのスライド

慈善団体の権利-スライドにリストされている問題は、理想的に監視したいものではありません。 同様に、これらは、運用前にテストしたい問題ではありません。 分散システムは病理学的に予測不可能であり、さまざまなサービスやサブシステムが出現する可能性のある沼地のすべての可能な沼地を予測することは不可能です。 サービスを実行できるすべての方法を事前に予測する試みとそれに続く回帰テストケースの作成は馬鹿げた仕事であるという事実にすぐに近づき、より機能不全の少ないテストに取り掛かるようになります。

この記事のレビューでフレッド・エバーが指摘したように：

...多数のマシンを使用する大規模なサービスが成長するにつれて、システムが100％稼働する可能性がなくなる可能性もあります。 部分的な障害は常にそのどこかで発生します。 テストで100％のパフォーマンスが必要な場合、問題が生じていることに留意してください。

過去に、「すべてを監視する」ことはアンチパターンであると主張しました。 今では、同様の記述がテストにも当てはまるように思えます。 すべてを完全にテストすることはできないため、試してはなりません 。 SREの本は以下を主張しています：

一定のポイントを過ぎると、信頼性の向上は、生活を改善する代わりに、サービス（およびそのユーザー）に悪影響を及ぼします。 極端な信頼性には代償が伴います：安定性を最大化すると、新しい機能の開発速度とユーザーへの提供速度が制限され、コストが大幅に増加するため、チームが実装してユーザーに提供できる機能の数が減少します。

私たちの目標は、サービスが受けるリスクと、ビジネスが負担する準備ができているリスクとの間の明確な境界を見つけることです。 私たちは、サービスの信頼性を十分に高めるよう努めていますが、それは私たちに必要なものに過ぎません。

上記の引用で「信頼性」を「テスト」に置き換えた場合、このアドバイスはそれほど有用ではなくなりません。

ただし、次の質問をする時が来ました。本番前にテストする方が良いのは何ですか？

探索的テストは、実稼働前のテストを目的としていません。

研究テストは、80年代から使用されてきたテスト手法です。 主にプロのテスターに​​よって実践されています。 このアプローチでは、テスターからのトレーニングが少なくて済み、重要なバグを見つけることができ、 「スクリプトテストを実行するよりも知的レベルで刺激的である」ことが実証されています。 私はプロのテスターではなかったし、別のテストチームを持つ組織で働いたこともないので、最近このタイプのテストについて学んだだけです。

既に述べた本「 ソフトウェアテストで学んだ教訓 」の「 テスターのように考える 」の章には、このように聞こえる非常に賢明なアドバイスが1つあります 。 テストするには、調査する必要があります 。

何かを適切にテストするには、それを操作する必要があります。 あなたはそれを理解する必要があります。 完璧な製品説明が手元にある場合でも、これは調査プロセスです。 頭の中をスクロールするか、製品自体を操作してこの仕様を調査するまで、作成するテストは表面的なものです。 製品をかなり深いレベルで研究した後でも、問題を見つけるために研究を続けなければなりません。 , , .

— , . ; , , .

«» «», , , , — , - .

, , , . , :

— . . . , . . .

: , , , .

: , , , , .

: , , , « », .

, , , , , , . , ; .

, , , - , . , , , , , / .

, . . , «» . , , , .

, . , — , — , .

, — . , , — . , «» , — , .


^{1000%, . , , ( , S3zure). — . «», Ops. .}

( !) . , ; - , « ».

, :

• ;
• ;
• .

, :

• , ;
• 0 ?
• ?
• ;
• service discovery ?
• ?
• , ;
• graceful restart ;
• — — ;
• (, , event driven , , );
• - (- ).

, . , - .

( ) . , , :

• Consul ( « », , );
• , RPC- TTL;
• Confluent Python Kafka Python;
• pgbouncer , ( LIFO) , Postgres.

, :

• ;
• — , , , , — ;
• , , .

, « » (, , « ») .

-

, , — .

. . , , — .

, ( , , ); , , . , — , , .

, — , , , — , .

, — , — . -, , ( , , , ), , «-» , «-» .

, , . , , , , .

, . - , . , - , , , .

, , .

-

- , , - . RPC-, .

, , , .

, () , , - . , ( JSON, , ), , - . - .

, « Succeeding with Agile » ( «Scrum. »), « Building Microservices: Designing Fine-Grained Systems ». -, , ( ), UI ( end-to-end ). , , , .




, . , , .

, ( , , ) - ( -), stateful- . , — — I/O ( , ), .

I/O

PyCon 2016で、 Corey Bandfieldは、ほとんどのライブラリがプロトコル解析とI / Oを分離しないという間違いを犯し、最終的にテストとコードの再利用を困難にするという素晴らしいレポートを発表しました。 これは本当に非常に重要なアイデアであり、私もそれに同意します。

ただし、すべてのタイプのI / Oを同等とみなせるわけではないと思います。 プロトコル解析用のライブラリ、RPCクライアント、データベースドライバー、AMQPクライアントなどはすべてI / Oを実行しますが、それらはすべて、マイクロサービスの限られたコンテキストによって決定される、異なるレートの異なる形式のI / Oを使用します。

たとえば、ユーザー管理を担当するマイクロサービステストを実施します。 この場合、データベースでユーザーが正常に作成されたかどうかを確認でき、HTTP解析が正常に機能するかどうかをテストしないことがより重要です。 もちろん、HTTP解析ライブラリのバグは、このサービスの単一障害点となる可能性がありますが、同時に、HTTP解析は一般的なスキームでサポートする役割のみを果たし、サービスの主な責任に二次的です。 さらに、HTTPを操作するためのライブラリは、すべてのサービスで再利用される部分であるため（この場合、 ファジングは非常に役立ちます）、 一般的な抽象化になるはずです。 ご存知のように、抽象化（最も「漏れやすい」もの）を扱う際のバランスを見つける最良の方法は、不本意ながら、約束されたサービス契約を信頼することです。 このような解決策は理想的な解決策とは言えませんが、私にとっては、少なくとも何かを解き放つためには、この妥協案が存在するすべての権利があります。

ただし、マイクロサービス自体に関しては、システムの他の部分に関する抽象化には、ビジネスまたはインフラストラクチャロジックの特定の部分に直接マッピングされる状態遷移が含まれるため、 この機能は封印されたユニットのレベルでテストする必要があります。

同様に、Zookeperとサービス検出を使用してリクエストを動的バックエンドに分散させるネットワークプロキシサーバーがあるとします。 この場合、プロキシがウォッチ値トリガーに正しく応答できるかどうかをテストし、可能であれば新しい制御値を設定できることがはるかに重要です。 これは、まさにテストする必要のあるユニットです。

上記のすべての意味は、マイクロサービス機能の最も重要な単位はI / Oの基礎となる抽象化であり、バックエンドとの対話に使用されるため、テストする基本機能の非常にタイトな単位になる必要があるということです。

最も興味深いのは、上記のすべてにもかかわらず、そのようなシステムをテストするための「ベストプラクティス」の大部分は、テストする必要があるが、モックの助けを借りて除去する必要がある干渉として、基礎となるI / Oマイクロサービスを参照できないことです。 最近のすべての単体テストは、mokaの積極的な使用と同義語になっています。

mokamiを使用したI / Oサービスのこのようなクリティカルのユニットテストは、サービスをテストするための「ブロック」です。これは、速度を犠牲にし、作成するシステムについて考えるのに慣れているためです。 。 ここでさらに進んで、mokasの助けを借りた単体テスト（用語"mokテスト"と呼ぶことができます）は、ほとんどの場合、システムの重要なビジネスコンポーネントの不完全で、おそらく間違いの多いメンタルモデルのテストです。その結果、私たちは最も陰湿な形の偏見の人質になります。


^{モッキングは思考に影響を与えるという考えが好きです。 モックは予測どおりに動作しますが、ネットワークとデータベースは動作しません。}

テストツールとしてのmokaの最大の欠点は、実行の成功とクラッシュをシミュレートする場合、mokaがプログラマのmi気楼であり、実際の生産の概観を反映することさえできないことです。

ここでは、この問題を別の方法で処理する方が良いと言う人もいます：ネットワークレベルで起こりうるすべての障害を追跡し 、それに応じて、以前無視したこれらすべてのテストケースをカバーする追加のモックでテストスイートに追加します。 さて、考えられるすべての問題を考慮することに加えて、それはほとんど不可能であるように思われ、このアプローチは、同様の機能を実行する多数の異なるモックを備えた過剰なテストのセットにつながる可能性が高い。 そして最終的には、これらすべてが、将来、この善を支援することに対処しなければならない人々の肩に大きな負担をかけることになります。

テストのサポートに関しては、ムックの別の欠点がここに積極的に現れています。テストコードが不必要に詳細になり、理解しにくくなります。 私の経験から、これはクラス全体がmokaになった場合に特に当てはまります。mokaの実装は、特定のクラスメソッドがn回または特定のパラメーターで呼び出されたことをmokが確認できるように、依存関係としてのみテストに導入されます。 この形式のmokは、サービスの動作をテストするテストを作成するときに積極的に使用されるようになりました。


<sup>私の概要は、テストでのモックオブジェクトの使用です。ほとんどすべてのテストケースで、動作ではなく実装のテストで終わります。 これは愚かです。トートロジークラブの最初のルールは、トートロジークラブの最初のルールです。

さらに、コードベースのサイズを時々増やします。 その結果、変更を加えるのがはるかに難しくなります。</sup>

Mokingとの調整

テストに関するGoogleブログ、二重オブジェクトに関する投稿から

モキ、スタブ、および偽物は、すべてのタイプのいわゆる「 テストダブル 」です。 以前にmokiについて書いたほとんどすべては、他の形式のテストダブルスに適用できます。 ただし、極端な話をせずに、moka（およびそのバリアント）には利点が含まれていないとは言いません。 同様に、すべてのユニットテストに常に I / Oテストを含める必要はありません。 単体テストでは、準備する必要のある副作用がなく、テストに単一の I / O操作が含まれる場合にのみI / Oを含めるのが理にかなっています（これが、サブスクリプションのテストにあまり意味がない主な理由です。同様の方法で出版物）。

マイクロサービスアーキテクチャの非常に妥当な例の次のトポロジを検討してください。



サービスAとサービスBの相互作用には、サービスBとRedisおよびサービスCとの通信が含まれます。ただし、テストされる最小単位 はサービスAとサービスBの相互作用であり、この相互作用をテストする最も簡単な方法は、サービスBのフェイクをデプロイし、サービスAとフェイクとの相互作用をテストすることです。 テスト契約は、このような統合のテストに特に役立ちます。 Soundcloud は、契約テストを使用して300を超えるすべてのマイクロサービスをテストすることで知られています。

サービスAもRiakと通信します。 この場合のテスト対象の最小ユニットには、 サービスAとRiakの間の実際のメッセージが含まれているため、テスト中にローカルRiakインスタンスをデプロイすることは理にかなっています。

GCP、AWS、Dropbox、Twilioなどのサードパーティサービスとの統合に関しては、理想的には、ベンダーが提供するバインダーまたはSDKには、テストスイートで使用できる既製の優れた偽物が既に含まれています。 さらに良いのは、ベンダーが実際のAPI呼び出しをテストモードまたはサンドボックスで実行できる場合、開発者はより現実的な方法でサービスをテストできるためです。 これらのサービスには、テストトークンを提供するStripeが含まれます。

そのため、テストはテスト範囲内で「倍増」する価値があることがわかりましたが、単体テストを実行したり、それらを使用してやりすぎたりする唯一の手段としてそれらに固執しないでください。

単体テストの目立たない利点

単体テストは、議論した方法に限定されません。 単体テストの議論を開始することは省略であり、 プロパティベースのテストとファジングについては話しません。 HaskellのQuickCheckライブラリ（後にScalaおよび他の言語に移植された）とPythonのHypothesisライブラリのおかげで人気が高まっています。プロパティベースのテストでは、プログラマが入力データの固定セットを生成することなく、異なる入力で同じテストを数回実行できますテストケース。 ジェシカカーがこのトピックに関する素晴らしいレポートを作成し、 フレッドエバー はこのトピックに関する全編を書いた 。 この記事のレビューで、Fredはプロパティベースのテストのためのさまざまなツールに対するさまざまなタイプのアプローチに言及しています。

プロパティベースのテストに関して、私は次のように言います：ほとんどのツールはファジングに近づきますが、少し難しい場合は、より微妙なアプローチでホワイトボックステストのように行うことができます。 言い換えれば、ファジングがシステムの特定の部分が「落ちた」かどうかを調べる場合、プロパティベースのテストは、特定のルールまたはプロパティのセットが常にシステムで観察されるかどうかを確認するのに役立ちます。 プロパティテストには3つの大きなファミリがあります。

-Haskell QuickCheckファミリー 。 このバリエーションは、タイプ情報を使用して、テストが実行されるデータを生成することに基づいています。 主な利点：テストが小さくなり、テストの範囲と有用性が高くなります。 欠点：拡張が難しい。

-Erlang QuickCheckファミリー 。 このバリエーションは、複合関数である動的データジェネレーターに基づいています。 前のタイプの機能に加えて、このようなフレームワークではステートフルモデリングプリミティブを使用できます。 総当たり検索の代わりに確率的検索が実行されるため、モデルチェックを連想させます。 したがって、ここでは、ファジングから「モデルテスト」のゾーンに移動しています。これは、テスト方法のまったく異なるファミリです。 著者がさまざまなクラウドプロバイダーに対してこのようなテストを実行し、それらを使用して鉄のエラーを検出したレポートを聞く機会がありました。

- 仮説 ：ビジネスへのユニークなアプローチ。 これはファジングに似たメカニズムに基づいており、データはバイトストリームに基づいて生成され、複雑さの尺度でより軽く/より大きくなる可能性があります。 ユニークなデバイスがあり、リストされている最も適用可能なツールです。 私は仮説がどのように「フードの下で」機能するかについてあまり詳しくありませんが、このツールはHaskellの対応するツールよりもはるかに多くのことができます。

一方、ファジングを使用すると、無効な入力や迷惑な入力を事前にアプリケーションに送信して、アプリケーションが計画どおりに障害を完了できるようにすることができます。



ファジング用のさまざまなツールが多数あります： aflなどのカバレッジに基づくファザー、 アドレスサニタイザー 、 スレッドサニタイザー 、 メモリサニタイザー 、 未定義の動作サニタイザー 、 リークサニタイザーツールなどがあります。

単体テストは、特定の入力データセットに対して何かが意図したとおりに機能することを通常の検証に加えて、他の利点も提供できます。 テストは、アプリケーションによって公開されるAPIの優れたドキュメントとして機能します。 Goなどの言語を使用すると、 サンプルテストを作成できます。このテストでは、TestではなくExampleで始まる関数が、選択したパッケージの_test.goファイルの通常のテストの横に存在します。 これらのサンプル関数は、パッケージのテストスイートの一部としてコンパイル（およびオプションで実行）された後、パッケージドキュメントの一部として表示され、テストとして実行できるようになります。 ドキュメントによると、この意味は次のとおりです。

このアプローチにより、APIを変更しても、パッケージのドキュメントの有効期限が切れることはありません。

単体テストのもう1つの利点は、サードパーティのサービスで簡単に操作できるAPIを構築するようにプログラマーとデザイナーに圧力をかけることです。 テストに関するGoogleブログにすばらしい投稿「 変更の動機付けとしての不快感 」が公開されました。これは、APIの作成者が偽の形式で実装を提供するという要件により、このAPIを使用する人をよりよく理解し、その数を減らすことができるという事実に光を当てていますこの世界の痛み。


2016年、彼女はサンフランシスコでPython Twisted mitapsを組織することに関与しました。 人気のあるディスカッショントピックの1つは、Twistedグローバル（Python 3がasyncio実装で再現し、 Twistedコミュニティを恐怖に陥れる ）でイベントループを作成するのは間違いであり、 Reactor （明示的な依存関係としてコンシューマに渡される、ネットワーキング、ストリーミング、イベントスケジューリングなどを含む、すべてのタイプのサービスの基本的なインターフェースを提供します。

ただし、ここでは予約が必要です。 原則として、優れたAPIの設計と優れたテストは、互いに完全に独立した2つの目標であり、実際には（ただし、これを行うことはお勧めできません）、テストのない非常に便利で直感的なAPIを設計することは難しくありません。 ただし、 多くの場合、人々はテストで100％のカバレッジを達成しようとするAPIを設計します（コード行などで測定する方法は関係ありません）が、結局は、破産の時期尚早に抽象化された成果物であることが判明しました。 mochaベースのユニットテストは優れたAPI設計の方法ですが、コードが適切に実行されることを保証するものではありません 。

VCR-テスト応答をキャッシュまたは繰り返す

^{mokas / fakes / test twins / stubsを過度に使用することは、テスト技術の最も信頼できる選択ではありません（ただし、これでうまくいかないこともあります）が、VCRスタイルのキャッシングに関しては、失敗したテストのデバッグはさらに難しくなります。}

mokiの一般的な信頼性がないことを考えると、 個人が テストフィクスチャーとして回答を書き留めるためにさらに下に行くことは絶対にばかげていると思います。 この方法は、統合テストを高速化する方法として（このようなテスト方法を使用する場合はどのような統合であるとしても）、 単体テストを高速化するという観点からは効果がありません。 余分なレイヤーの山で失敗したテストのデバッグ中にあなたの脳の過度の過負荷はそれに費やす時間の価値がありません。

統合テスト

mokasを使用した単体テストの信頼性が低く、信じられない場合、これは統合テストが私たちの助けに駆けつけ、私たちを救うことを意味しますか？

これは私が過去にこの問題について書いたことです。


<sup>これは非常に過激に聞こえるかもしれませんが、優れた（および高速の）統合テスト（ローカルおよびリモート）と優れたインストルメンテーションの組み合わせは、多くの場合、100％のテストカバレッジを達成するという望みよりも優れています。


同時に、当社のサービスと相互作用する利用可能な各サービスの大規模な統合テストは、あまりうまくスケールしません。 デフォルトでは遅くなり、統合テストからのフィードバックを迅速に取得できる場合にのみ、統合テストが最大の利益をもたらします。
最適な分散システムテストパターンが必要です。</sup>

私のTwitterの読者の中には、私の2つの声明が互いに矛盾していることを指摘している人もいます。 一方では、単体テストではなく、より多くの統合テストを作成することをお勧めします。他方では、分散システムの場合、統合テストはうまくスケールしないと主張します。 これらの観点は相互に排他的ではなく、おそらく私の最初の声明には本当に詳細な説明が必要です。

ここでのポイントは、この場合の単体テストがエンドツーエンドのテストに置き換えられることではありません。 , «», , - , « », .

. , , , I/O. , , . , Uber, , , , , , , , c , : « ». , , , , , . , , -.

Event Sourcing — , Kafka. ( Command and Query Responsibility Segregation ) - 10 . ( writes ) ( reads ). , , , .

, , , , (, , ).


^{; , .}

, / . «» , «» ( ) , . , .

, , , . « ».

, , . , - ( I/O ), , — . :




, , , ( , observability ). , — ; , , — , , . , , .



, , , , . Consul . — API- ( ) , G .

, Macbook API, ( , ). . , , , , , .

-

80% API MongoDB, - MongoDB. E — LuaJIT, , , API. E , (watch) Consul , - Consul, , «» , . -, .

G, H, I K ( ).



G — Python, Kafka , , H, I K. G , H, I K, - 15-20 G ( 7). G — , , Kafka, H, K I.

H, K I — . H — nginx ( , Openresty ) ( ), , LevelDB write through cache ( ) , MySQL, , Go. K — HAProxy, I — HTTP- LuaJIT. , H, I K Kafka. , .

: (eventual consistency) ?

, , , end-to-end , Kafka G, H, I K . , « », , , :

• K — HAProxy ( HAProxy )
• H ( ) , - . , , - nginx H . H , - nginx «» , - , « »:

, NGINX , .

, HTTP2, «» , , , nginx . , H, I K — , .

, , . , , - , .

Service Meshes

, service meshes — , , «» . staging staging ( , HTTP- , IP- ), , . - .


^{「テスト」クラスターでの統合テストは実際には役に立たず、消滅するはずだと信じています-未来はライブトラフィックです。 今日、Facebookはかなり前からこのアプローチを実践していることを知りました。 https://t.co/zMrt1YXaB1
Service Meshesパラダイムにより、テストの真の可能性を引き出すことができます。}

もちろん、ここでは安全性、データの整合性などを維持することに注意を払う必要がありますが、実行されたテストの結果として良好な可観測性を備えたライブトラフィックでのテストは、マイクロサービステストの分野における未来への道であると心から信じています。

このテストモデルの選択は、サービス間の分離の改善を促進し、より高度なシステムを設計することで表される別の利点をもたらします。 エンジニアは、サービス間の依存関係と、データの整合性に与える可能性のある影響について真剣に考える必要があります。これにより、アーキテクチャ設計者は再考することになります。 さらに、1つのサービスを実稼働中の他のすべてのサービスでテストするためには、テスト対象のサービスに、アップストリームまたはダウンストリームの依存関係のいずれかに影響を与える可能性のある副作用がないことが必要です。これは、システムを設計する際の合理的な理由だと思います。

おわりに

この記事では、特定のテスト方法の利点を証明するという目標を設定しませんでした。 私はこのトピックの専門家とは言えません。なぜなら、私の考え方は、私が使用したシステムの種類の影響下で形成されたためです。リソース）、および企業自体の組織構造。 他のシナリオや状況では、私の記事で表明されたアイデアが意味を持たない可能性は十分にあります。


^{いわゆる「専門家」に耳を傾けるだけでなく、より頻繁に頭を回します。 「専門家」はしばしば過度に一般化されたアドバイスを提供します。 したがって、自分の頭で考えて、怠けてはいけません！}

テストの範囲がどれほど広いかを考えると、正しい方法でテストするための単一の「真の」方法はないことが明らかになります。 どのアプローチも妥協と犠牲の必要性を暗示しています。

最終的に、各チームはそれぞれの状況とニーズの専門家であり、あなたの考えは外注すべきものではありません。

---

個々の開発者だけでなく、ほとんどすべてのプロジェクトチームがこのような問題の解決に関与しているため、特に大規模な概念的な議論、特に私たちの例に精通していることが大好きです。 RIT ++ 2018で 講演するために 、ソフトウェア開発の哲学的問題について既に議論した経験のある専門家を招待します。