[[2022__CLOUD__Localizing and Explaining Faults in Microservices using Distributed Tracing]] ### A. Set-up > 故障がアクティブになり顕在化するためには，故障のあるマイクロサービスと対話するユーザ要求がなければならない．そこで、我々はTrain-Ticketのユーザーフローを作成しました。これは、ユーザーとアプリケーションのインタラクションをシミュレートし、バックエンドへの一連のカスケード要求を生成するものです。我々のユーザーフローはTrain-Ticketの41のマイクロサービスのうち33をカバーしています。注文、ルート、ユーザー、駅、列車、価格などを管理するadminロールによるアクションのシミュレーションはユーザーフローに含まれておらず、結果として対応するマイクロサービスはユーザーフローによってカバーされないままとなっています。 > 故障の種類。FSFを検証するために、以下の故障を注入する。 - (a) http-service-unavailable (HTTP 503) これはマイクロサービスの障害を模倣したものである．この故障では、注入されたマイクロサービスへ向けられたすべてのリクエストは失敗する。このような障害は、アプリケーションの障害（ハングやクラッシュなど）、インフラの障害（ポッドの障害/再起動など）、デプロイの問題（サービスが開始できないなど）により発生します。 - (b) http-bad-request (HTTP 400) これは，リクエストの破損を模倣したものである．この故障では、注入されたマイクロサービス（クライアント）は、サーバーマイクロサービスに対して不正なHTTPリクエストを送信する。このような障害は、不正なリクエスト構文（例えばバグ）、無効なリクエストメッセージフレーム（例えばネットワークエラー）、または不正なリクエストルーティング（例えばセッションハイジャック）により発生する可能性があります。 - (c) http-resource-not-found (HTTP 404) これは、再ソースが見つからない障害を模倣するものです。この故障では、サーバーマイクロサービスは利用可能ですが、クライアントマイクロサービスによって要求されたリソースは、サーバーマイクロサービスによって見つけられません。このような障害は、間違ったAPI仕様、不正なコード、またはバージョンアップの問題によって発生する。 > 我々は上記の3つの故障タイプを使用する。なぜなら、(i)これらはクライアント(HTTP 400/404)とサーバー(HTTP 503)の両方の故障をカバーし、(ii)これらの故障タイプは運用、誤った設定またはコードの問題により発生し得るからである。 > 故障の注入。Istioは、その特定のサービスに向けられたすべてのリクエストをインターセプトし、HTTP 503エラーコードを返すことができるので、http-service-unavailableをシミュレートするためにIstioの故障注入機能[23]を使用し、それによって、マイクロサービスが実行されているコンテナを実際に終了する必要性を避けることができます。ユーザーインターフェースに関連するマイクロサービスを除き、ユーザーフローがカバーするさまざまなマイクロサービスそれぞれにhttp-service-unavailableを注入し、合計32個の故障を発生させました。 > アプリケーションのソースコードに変更を加え、変更された各マイクロサービスの故障のあるバージョンを構築することによって、http-bad-requestとhttp-resource-not-foundを注入しています。宛先のマイクロサービスに到達する前にリクエストをインターセプトし、4xxクラスのHTTPエラーコードを返すと、スパンとログが欠落することになるため、これら2種類の故障をシミュレーションするためにIstioを使用しません。http-bad-requestとhttp-resource-not-foundは、コールチェーンの末端にあるマイクロサービス（すなわち、コールチェーンのリーフノード）ではエミュレートできません。そのため，マイクロサービスのサブセット（合計18個）のみにhttp-bad-requestとhttp-resource-not-foundを注入することができ，これらの故障の種類を合わせて36個の故障を発生させることができた． > 故障は一度に1つずつ順番に注入されたので、同時に複数の故障がアプリケーションに注入されることはありませんでした。各障害注入実験の間、マイクロサービスの1つに1つだけ故障が注入され、固定セットのユーザーフローが常にバックグラウンドで実行されました。各故障は、注入された故障が顕在化し、ユーザーリクエストに影響を与えることを確実にするために、数分間シミュレートされました。各故障注入の後，注入された故障は，次の故障注入実験を開始する前に，アプリケーションから除去された．各故障注入期間の終了時に、アプリケーションによって生成されたすべてのログとトレースを収集しました。 --- > FSFは、あらゆるアプリケーションの故障を、故障が発生したときに、リアルタイムで検出、局所化、診断することができる。これは、FSFが教師なし因果推論（セクションIII参照）を使用するためで、ステージング環境でも本番環境でも、トレーニングは一切必要ありません。FSFは、私たちがTrain-Ticketを使い始めた瞬間に、内部故障（非注入）を診断し修正するのに役立ち、この能力を実証しました。 > 我々の実験では、Train-Ticketアプリケーションは、一定期間操作が行われなかった後にユーザーフローを実行し始めると、リクエストエラーを示すことに気づきました。このエラーは1分ほどで解消されます。このため、実験では常に一定時間待ってから故障の注入を開始するようにした。しかし、FSF はこの警告期間中のトレースを拾い上げ、これらのエラーの根本原因を自動的に解明することができた。特に、FSFはMongoDBデータベースインスタンスに接続されているすべてのマイクロサービスで、同じタイプの故障を発見しました。それぞれのログから、マイクロサービスがMongoDBデータベースに接続しようとしたときに発生したMongoDB Socket ExceptionによるHTTP 500 Internal Server Errorsという故障が確認されました。これらのログの詳細からこの問題の解決策を探ったところ、ソケットの設定を変更することで接続が維持され、問題が解決することがわかりました。 > 我々は、セクションIV-Bの同じ32のhttp-service-unavailable故障注入について、各アルゴリズムの位置推定の損失を計算した（図2参照）。損失値が低いほど、より良い推定値を意味することに注意。我々は、アルゴリズム1が、因果推論をトレースではなくログデータのみで推論するように制限した他の2つのアルゴリズムより明らかに優れていることが分かる。また、性能の劣るアルゴリズムの結果は、ログデータのみを用いて故障箇所を特定する最新のアプローチと同等である。同じベンチマークアプリケーションであるTrain-Ticketで、41のマイクロサービスのうち17にhttp-service-unavailable故障を注入し、ログベースのさまざまな手法を評価した結果、最もパフォーマンスの高い手法（14）は、8.24以下の平均損失を達成しました。私たちのログを使った素直な因果推論では、平均損失は10.84、テキスト分析で改善した場合は5.69という結果になりました。アルゴリズム1では平均損失が0と完璧な結果が得られた。