[論文レビュー] FaaSter Troubleshooting -- Evaluating Distributed Tracing Approaches for Serverless Applications

Maria C. Borges, Sebastian Werner+1 more|arXiv (Cornell University)|Oct 7, 2021

Software System Performance and Reliability参考文献 17被引用数 11

ひとこと要約

本稿では、サーバessアプリケーションにおける障害のトラブルシューティングを改善するため、開発者主導型とプラットフォーム支援型の2つの分散トレーシング手法を評価するための障害可視性モデルを提案する。両手法とも、最小限のパフォーマンスオーバーヘッドで障害の曖昧性を顕著に低減することを示しており、特に開発者主導型トレーシングは、ほとんど無視できる遅延を伴い、プラットフォームトレーシングが利用できない場合の本番環境での利用が推奨される。

ABSTRACT

Serverless applications can be particularly difficult to troubleshoot, as these applications are often composed of various managed and partly managed services. Faults are often unpredictable and can occur at multiple points, even in simple compositions. Each additional function or service in a serverless composition introduces a new possible fault source and a new layer to obfuscate faults. Currently, serverless platforms offer only limited support for identifying runtime faults. Developers looking to observe their serverless compositions often have to rely on scattered logs and ambiguous error messages to pinpoint root causes. In this paper, we investigate the use of distributed tracing for improving the observability of faults in serverless applications. To this end, we first introduce a model for characterizing fault observability, then provide a prototypical tracing implementation - specifically, a developer-driven and a platform-supported tracing approach. We compare both approaches with our model, measure associated trade-offs (execution latency, resource utilization), and contribute new insights for troubleshooting serverless compositions.

研究の動機と目的

• サーバessアプリケーションにおける可視性の制限という課題に対処する。これは、管理サービスの複雑で分散された構成のため、障害が特定しにくいためである。
• サーバーレス関数の組み合わせにおける、障害の可視性が異なるコンponentでどのように特徴づけられるかを定量化するための障害可視性モデルを開発する。
• 障害診断の改善を目的とした、開発者主導型とプラットフォーム支援型の2つのトレーシング手法の実装と評価を行う。
• 実世界のサーバーレスワークロードにおける、可視性の向上とパフォーマンスオーバーヘッド（遅延、リソース使用量）のトレードオフを定量化する。
• 開発者およびプラットフォームプロバイダーが、サーバーレス障害トラブルシューティングに効果的なトレーシングソリューションを選定・導入するための実用的知見を提供する。

提案手法

• ログおよびトレースにおける証拠の一貫性と曖昧性に基づいて、障害の可視性を分類するサーバーレス障害可視性モデルを提案する。
• OpenWhiskにおけるカスタムインストルメンテーションを用いたプロトタイプ実装を通じて、開発者主導型トレーシングを設計し、アプリケーションコード内でエンドツーエンドのトレース収集を可能にする。
• OpenWhiskコントローラーおよびインベーター・ノードのインストルメンテーションにより、プラットフォーム支援型トレーシングアプローチを設計し、関数呼び出し全体で自動的にトレースをキャプチャする。
• 複数の関数呼び出しと外部サービスを含む実世界のeコマースバッチインポートユースケースを用い、両手法を現実的な条件下で評価する。
• 実行遅延、CPUおよびメモリ使用量、トレースの完全性を測定し、パフォーマンスと可視性のトレードオフを比較する。
• 実験では100%のサンプリングレートを採用し、パフォーマンスへの影響を最大限に評価するため、最悪のシナリオをシミュレートする。

実験結果

リサーチクエスチョン

• RQ1 どのようにして、特に可視性と曖昧性の観点から、サーバーレスアプリケーションにおける障害可視性を体系的に特徴づけられるか？
• RQ2 サーバーレスプラットフォームにおける、開発者主導型とプラットフォーム支援型の分散トレーシングの実装におけるパフォーマンスのトレードオフは何か？
• RQ3 分散トレーシングは、関数の組み合わせにおける障害の曖昧性とログの不整合性をどの程度低減するか？
• RQ4 実際のサーバーレスデプロイメントにおいて、異なるトレーシング手法を採用した場合、実行遅延およびリソース使用量はどのように変化するか？
• RQ5 トレーシングを導入することで、開発者およびプラットフォームプロバイダーにどのような実用的影響が生じるか？

主な発見

• 開発者主導型トレーシングは、パフォーマンスオーバーヘッドがほとんどなく、ベースライン比で平均実行時間の増加が0秒、最大で3秒にとどまるため、非常に効率的である。
• プラットフォーム支援型トレーシングは、より高いパフォーマンスコストを伴い、平均実行時間の増加が2秒、最大で82秒に達する。これは主にコアコンponentでの100%サンプリングとインストルメンテーションに起因する。
• プラットフォーム支援型アプローチは、測定可能なリソースコストを引き起こし、追加で128〜256MBのメモリを消費し、1関数あたりの利用可能なランタイムを1〜2%低下させる可能性がある。
• パフォーマンスコストがあるにもかかわらず、両手法とも、関数境界を越えた障害証拠の曖昧性と不整合性を顕著に低減することで、障害可視性を大幅に向上させる。
• プラットフォームトレーシングが利用できない場合、開発者主導型トレーシングは、最小限のオーバーヘッドと強力な可視性の利点から、本番環境での利用が推奨される。
• 本研究では、分散トレーシングが、特に複数の関数で構成される複雑な環境において、サーバーレスアプリケーションの障害診断を改善するための実用的で効果的なソリューションであることを示している。