マイクロサービス指向のアプリケーションのテスト

こんにちは、Habr！ マイクロサービス



のトピックの調査を継続し、 MOA（マイクロサービス指向のアプリケーション）のテストに関する記事の翻訳を提供することにしました。最近、テストのトピックについてはすでに取り上げました が、マイクロサービスの場合、定期的な単体テストでは不十分であり、CI / CDやこの記事で説明するその他の事項に関連する側面も考慮する必要があります。







マイクロサービスは、分散システムの作成に使用される新しいスタイルのソフトウェアアーキテクチャであり、最大のものを含め、Web上で動作する企業にますます実装されています。たとえば、NetflixとAmazonは、ソフトウェア製品のリリースを大幅に加速するためにマイクロサービスアーキテクチャを採用しています。同時に、古いモノリシックシステムは、現代の課題に対応できる速度で拡張することはできません。



ただし、マイクロサービスアーキテクチャがもたらすメリットは、それをサポートするためのベストプラクティスをテストできる場合に限られます。マイクロサービスシステムを検証するためのテストを設計する場合、リリースレートは非常に高速であると説明できますが、ミクロレベルとマクロレベルの両方で革新的な考え方が必要です。



次に、3種類のマイクロサービス指向のアプリケーションについて説明し、それらをテストするために取り組む必要のあるいくつかの課題について説明し、マイクロサービスの利点を十分に理解するためにテストを作成する方法について説明します。

マイクロサービスについて簡単に

マイクロサービスのテストを設計する際の複雑な作業に入る前に、マイクロサービスとは何かを見てみましょう。マイクロサービスは、明確なセマンティック定義が与えられた詳細なソフトウェアコンポーネントです。ただし、マイクロサービスは独自のデータセットを伝送し、他のデータ構造やデータソースに依存しません。各マイクロサービスには独自のデプロイメントサイクルがあるため、マイクロサービスに変更を加えた後、このマイクロサービスが実行されているアプリケーションのスコープ内の他のマイクロサービスの作業を中断することなく、マイクロサービスを解放できます。

モノリシックアプリケーションに対するマイクロサービスの利点

また、マイクロサービスが何でないかを見てみましょう。次の図は、典型的なモノリシックアプリケーションの例を示しています。







図： 1：モノリシックアプリケーションアーキテクチャは通常、強力なコンポーネントの結束を持っています



Customers、Products、Orders、および（Comments）コンポーネントは、JavaやC＃などのオブジェクト指向言語で記述されたクラスのセットと考えることができます。ここで、customersは、顧客、製品に対応するオブジェクトの配列です。製品等に対応するオブジェクトの顧客オブジェクトは、顧客オブジェクトと製品オブジェクトの両方を使用できます。または、モノリシックアプリケーションのすべてのコンポーネントが同じデータベースにアクセスするため、注文オブジェクトはデータベースに直接アクセスして、タスクを完了するために必要な製品と注文に関するすべての情報を取得する場合があります。データベースへの直接アクセスが可能であるだけでなく、オブジェクトリレーショナルマッピングに基づくオブジェクト指向プログラミングの精神とどれほど矛盾しているか ORM-しかし、特に合意された日付までに既製の機能に対する需要が高い分野では、どのようなコストであっても、積極的に使用されています。



その結果、緊密に結合された、場合によっては脆弱なシステムが作成されます。新しいバージョンのアプリケーションをリリースするには、そのシステムの開発に関与するすべての開発チーム間で大幅な調整が必要です。強い結合があるため、リリースサイクル全体は、依存関係を再ネゴシエートする最も遅い作業よりも速く進むことはできません。つまり、アプリケーションを更新して、顧客による新機能と製品による新機能をアプリケーションに追加するときが来た場合、これらの機能の両方の準備が整うまで、リリースは行われません。製品の更新に1日、顧客の変更に3週間かかる場合、リリースは3週間以内に行われます。さらに、状況をさらに悪化させるため、リリース中に、顧客と商品に関する新しいコードを調整するだけでなく、ただし、データベーススキーマにも変更を加えます。これも、リリースプロセス中に管理する必要があります。



データベースへの変更をリリースすることは、非常にデリケートな作業です。データベースの構造を変更すると、意図しない副作用が発生するリスクが常にあります。コンポーネントがデータベースにアクセスできる場合、そのコンポーネントはデータベースにアクセスし、このコンポーネントの範囲外のデータに対して操作を実行することさえあることを忘れないでください。このような「エリア外操作」は、他のコンポーネントの障害につながる可能性があり、災害が発生するまで、このような障害は見過ごされる可能性があります。このコードが本番環境にリリースされる直前に、コードに潜在的な危険が見つかる場合があります。残念ながら、これは常に発生します。

一部の企業は、モノリシックアプリケーションでの作業に典型的な遅いリリースサイクルに我慢する用意があります。しかし、数十万人のユーザーをサポートし、同時に数千のコンポーネントを機能する形で維持する必要がある会社について話している場合、「最新のコンポーネントのリリースよりも速くない」というペースは受け入れられません。 。

マイクロサービス指向のアプリケーション

マイクロサービス指向のアプリケーション（MOA）では、各機能コンポーネントは、（妥当な制限内で）顕著な機能を備えた可能な限り最小のユニットに分解されます。この場合、そのような各機能コンポーネントはマイクロサービスとして編成されます。各企業には独自のレガシーコードの手荷物と、遵守すべき企業文化があるため、分解をどのように正確に実行するかを「メモのように」書くことは不可能です。



MOAでモノリシックアプリケーションを分解する場合、覚えておくべき重要な点は、最良のものは善の敵であるということです。各マイクロサービスがそのセマンティック定義に従って構造化されていること、マイクロサービスが独自のデータと独自のリリースサイクルを持っていることを確認してください。実装の深さは、利用可能な時間、従業員の経験、および利用可能なリソースに基づいて、会社が何を支払うことができるかによって異なります。一部のマイクロサービスには1つの機能しかない場合もあれば、多くの機能がある場合もあります。

MOAの3つのタイプがあります： 同期、 非同期、および ハイブリッド。

同期マイクロサービス指向のアプリケーション

図2は、同期MOAを示しています。サービス間通信は、WebでのHTTP対話に典型的な要求/応答の原則 です。







図2：同期サービス間通信に基づくマイクロサービス指向のアプリケーション



各マイクロサービスはHTTPサーバーの背後でセグメント化されているため、このマイクロサービスのロジックにアクセスできます。特定のマイクロサービスは、それ自体の責任範囲しか知りません。彼はまた、別のマイクロサービスと対話するためのインターフェースを知っているかもしれませんが、別のサービスの内部ロジックを見ることができません。さらに、マイクロサービスは自身のデータについてのみ知っています。他のマイクロサービスのデータストアは彼には知られていないため、彼は利用できません。別のマイクロサービスのデータウェアハウスに直接アクセスして、そのデータを「ハイジャック」することはできません。マイクロサービスからデータを取得して新しいデータをマイクロサービスに転送する唯一の方法は、パブリックインターフェイスを介してマイクロサービスとやり取りすることです。



同期MOAの利点の中には、その独立性があります。たとえば、上記のCustomersマイクロサービスは、必要に応じていつでも更新できます。これに調整する必要のある外部依存関係はありません。マイクロサービスがパブリックインターフェイスを変更せず、要求から消費して応答として返す予定のデータの構造を変更しない限り、MOAアーキテクチャ全体が破損するリスクは最小限に抑えられます。



その性質上、MOAアーキテクチャは、独自の構造的整合性を維持するようなものです。マイクロサービス自体が独自のデータを運ぶため、その作業は他のサービスのデータストアに影響を与えません。マイクロサービスは、要求と応答の原則に基づいて構築されたHTTP URLと関連データ構造のセットとして表されるため、マイクロサービスのインターフェイスの境界が明確に定義されます。



同期MOAはますます人気が高まっています。多くの同期MOAインターフェイスは、2000年から存在しているスタイルであるRESTパラダイムに基づいています。 今年の。しかし、MOAには人気がありますが、速度が遅いという欠点があります。同期マイクロサービスのコンシューマーは、このマイクロサービスが要求と応答を処理できるよりも速く実行されることはありません。これは、特にプロセスの実行に時間がかかるマイクロサービスを扱う場合に、大きなボトルネックになる可能性があります。例として、テラバイトのデータを消費および処理する複雑な分析サービスがあります。サービスがシャットダウンするまで数分続けて座って待つことに同意する顧客はほとんどいません。マイクロサービスに実行する必要のある作業を通知し、結果の準備ができたときに通知を受け取る方が便利です。



このような状況では、マイクロサービスの設計に非同期アプローチを採用する方が便利です。

非同期マイクロサービス指向のアプリケーション

以下の図3は、非同期MOA実装を示しています。ここでは、関係者間でメッセージを交換することにより、サービス間通信が提供されます。通常、この相互作用は「ファイアアンドフォーゲット」と呼ばれます。







図3：非同期MOAアーキテクチャはメッセージングに基づいて



います非同期MOAアーキテクチャでは、メッセージはランダムに生成することも、特定のイベントに応答して生成することもできます。たとえば、（上の図に示すように）Ordersマイクロサービスで注文が作成されると、このサービスはイベントorders_created



を公開し、 それをコンパニオン メッセージキューに配置できます。、別のマイクロサービスをリッスンし、請求（図には示されていません）を行い、着信メッセージを受け入れます。請求マイクロサービスは、注文情報メッセージを取得し、請求の観点から適切な方法で処理します。



マイクロサービス指向のアプリケーションを設計するための非同期アプローチの利点は、そのようなシステムにボトルネックがないため、非常に効率的であるということです。欠点は、そのようなシステムを作成して管理することが非常に難しいことです。 Uberの

ような大規模な非同期システムの場合 、1秒あたり数千のメッセージを処理するのが普通です。そのようなシステムのデバッグは、そのワークフローに明確な軌道がないために困難です。最初に1つのアクションを実行してから、別のアクションを実行することではありません。ロジックは、受信したメッセージに応じてトリガーされます。つまり、いつでも何でも発生する可能性があります。



これは、テスト戦略を開発するときに留意する必要があります。たとえば、非同期システムは実用的ではなく、そのパフォーマンスは要求時間と応答時間に依存します。これは、「1つの要求と1つの応答」という1対1の対応がないためです。

ハイブリッドマイクロサービス指向のアプリケーション

マイクロサービス指向のアプリケーションを実装するためのバランスの取れたアプローチはハイブリッドです。サービスは同時に同期されます。つまり、サービス間で直接の要求と応答の通信がサポートされ、同時に非同期になります。つまり、一部のメッセージは、同期メッセージングと組み合わせて、または同期メッセージングの結果として生成されます。



図4は、マイクロサービス指向のアプリケーションへのハイブリッドアプローチで使用される通信パターンを示しています。Customersマイクロサービスは、HTTPサーバーに関連付けられたURLと、メッセージブローカーのキューの両方として表されます。







図4：サービスとコンシューマーの間で同期通信オプションと非同期通信オプションの両方を使用するマイクロサービス指向のアプリケーションを設計するためのハイブリッドアプローチ。

標準のHTTP要求/応答通信を使用して、クライアントをマイクロサービスに追加できます。要求が受信されて処理された後、応答が生成されます。ただし、応答が生成される前に、新しいクライアントに関する情報を含むメッセージがコンパニオンメッセージキューに公開され、他の関心のあるサービスがそれを利用できるようになります。メッセージキューに送信される情報は、マイクロサービスの裁量により、HTTP応答で生成されたものと同じにすることも、わずかに異なる場合もあります。それはすべて、マイクロサービスがどのように設計されているか、およびマイクロサービスが実施しなければならないQoS契約に依存します。



GraphQLコンシューマーとサービス間の同期通信と非同期通信の両方をサポートするAPIテクノロジーです。この技術とGraphQLサブスクリプションの詳細情報こちら。



ハイブリッドアプローチの最も重要な特徴は、他の2つのアプローチのメリットを組み合わせていることです。ただし、付随する欠点、特にパフォーマンスを低下させる潜在的なボトルネックと、マイクロサービスの「イン」と「アウト」で使用される2つの根本的に異なるタイプのインターフェイスをサポートする必要性に関連する追加の複雑さがあります。

マイクロサービスのテストを設計するときに問題が発生します

このようなアプリケーションのテストに関して、最初に覚えておくべきことは、単一のマイクロサービスが複数のMOAによって共有されることは非常にまれであるということです。通常、マイクロサービスは、アプリケーション内の特定のドメインにある多くのサービスの1つです。アプリケーションアーキテクチャ設計へのマイクロサービス指向のアプローチの利点は、本番環境との間のコード転送が高速になることです。たとえば、Netflixには 1日あたり4,000を超える展開があります。）このリリース率は、従来のモノリシックアプリケーション環境では不可能です。



MOAテストはミクロレベルとマクロレベルの両方で行う必要があることも覚えておく必要があります。

マイクロレベルのテスト

ミクロレベルでは、各サービスはその責任範囲内で徹底的にテストする必要があります。いくつかの解釈によれば、関数はマイクロサービスの境界と見なされます。

従来の単体テストを超える

マイクロサービスは単一の機能としてのみ提示されるべきであるというサーバーレスパラダイムの人気が高まっていることを考えると、マイクロサービス内の機能に特別な注意を払うことをお勧めし ます。しかし、多くの実践的なテスターは、マイクロサービスを使用する場合、単体テストに限定する傾向があります。単体テストは通常​​、非常に限られたテスト環境で機能する単一の機能を対象としていますが、マイクロサービスはWeb全体のオーディエンスにサービスを提供するように設計されています。したがって、テスト条件は極端でなければなりません。



たとえば、優れたマイクロレベルのテストの一環として、マイクロサービスの10万のインスタンスを同時に実行し、それらがその規模でどのように動作するかを確認できます。単一の単体テストを適用して、一度に1つの関数だけをテストするだけでは不十分です。作業する必要のあるホスティング環境の指標を考慮に入れて、関数の何千ものインスタンスで同時にこのようなテストを実行する必要があります。

デプロイメントユニットをテストします

マイクロサービスの機能をテストするだけでなく、マイクロサービスがリリースされるデプロイメントユニットのテストにも注意を払う必要があります。通常、マイクロサービスは、Kubernetesや DockerSwarmなどのオーケストレーションテクノロジーの一部としてコンテナーとして デプロイされ ます。コンテナオーケストレーションの重要な側面は、マイクロサービスの長期的な復元力を確保することです。



マイクロサービスは、ホストの障害とマイクロサービス自体のエラーの両方が原因で、さまざまな理由で失敗する可能性があると考えられています。何千ものコンテナの同時操作中に、ある種の現在の誤動作が発生するのはごく普通のことです。テストの重要性は、ゲームからのマイクロサービスの正しい 終了が、その正しい機能と同じくらい重要であるということです。マイクロレベルのテストにより、システムのあらゆる規模で、マイクロサービスが適切に機能し、適切に停止することが保証されます。

あなたに起こるすべてが絶対に記録されていることを確認してください

テストでは、マイクロサービスで発生するすべての重要なイベントが適切にログに記録されることも確認する必要があります。同様に重要なこととして、これらのログエントリを理解することもできます。マイクロサービスの世界では、特に動作の順次実行がない非同期MOAの場合、ロギングは非常に重要です。多くの場合、ログデータのみが、アプリケーションで何が起こっているかを理解するのに役立ちます。

マクロテスト

MOAが同期、非同期、ハイブリッドのいずれであっても、厳密なテストモードが表示されます。マイクロサービスをマクロレベルでテストする場合、満足できるものとして、サービス間通信とデプロイメントプロセスの2つの側面があることを確認する必要があります。

インテリジェントなサービス間通信の確保

マイクロサービスは、定義上、互いに独立しています。受信した情報に基づいて何をすべきかを決定するため、サービス間通信の精度は、マイクロサービス指向のアプリケーションの全体的な運用にとって重要です。



サービス間通信を提供するということは、適切な情報が必要な場所に確実に届くようにすることを意味します。テストでは、メッセージがどのように交換され、どのように処理されるかを追跡できる必要があります。これは、HTTP要求/応答通信と、メッセージブローカーを介して伝播される非同期メッセージの交換の両方に当てはまります。テストは、確実なシステムパスを確保するためにメッセージ形式がサポートされていることを確認するのに役立つはず です。、および誤ってフォーマットされたメッセージは拒否され、十分な説明があります（「不正なメッセージ」エラーだけではありません）。

継続的インテグレーションと継続的デプロイのテスト

組織化された継続的インテグレーションと継続的デプロイメント（CI / CD）プロセスは、ソフトウェア開発パラダイムに不可欠ですが、マイクロサービスアプリケーションに関しては、効率的で正確かつ高速なCI / CDプロセスが重要です。MOAは、毎日数百回の更新の割合で改訂される可能性があるため、ビルドが遅れている単一のマイクロサービスがボトルネックになり、リリースプロセス全体の速度が低下する可能性があります。



安全にプレイするための最良の方法は、CI / CDパイプラインテストに他の高レベルテストモードと同じ優先順位を与えることです。コード内のアーティファクトによるビルドマイクロサービスの遅延、マイクロサービスがホストされているランタイムのプロビジョニングの遅延、既にデプロイされているマイクロサービスのアップリフトの遅延などの問題を特定して修正することは、健全なCI / CDパイプラインの前提条件です。マイクロサービスがシャトルのように複雑であっても、運用ユニットを迅速にデプロイおよびデプロイできない場合は、ほとんど役に立ちません。

結論

マイクロサービスは本当のワイルドカードです。マイクロサービス指向のアプリケーションは、新機能をほぼ超高速でオンラインにするために必要な柔軟性と速度を提供します。今日、何百万ものユーザーをサポートする大企業がこれを学びましたが、アプリケーションがWeb全体の規模に達すると、毎日ますます多くの企業がこのアーキテクチャスタイルを採用しています。



多くの企業がマイクロサービス指向のアーキテクチャの精神を開発プロセスに真剣に取り入れようとしていますが、これらのMOAは、もともとモノリシックアプリケーションを対象とした手法を使用してテストされることがよくあります。これは近視眼的なアプローチです。

それどころか、企業は、マイクロサービスの独立性と、これらのマイクロサービスを使用するアプリケーションの俊敏性を確保するために設計された最新のテスト手法を学ぶ必要があります。開発チームとテスターがマイクロサービスアプリケーションの設計の背後にある原則を同期させることができれば、会社全体がマイクロサービスの長所にさらに依存することができます。