可観測性: IDE をデバッグする方法

[51CTO.com クイック翻訳] COVID-19パンデミックにより、多くの企業がクラウドネイティブおよび分散環境での業務拡大に向けて大きな推進力を得ています。企業が生き残り、繁栄するためには、使いやすく、市場投入までの時間を短縮し、再利用と共有を可能にするクラウド ネイティブ テクノロジー (API 管理および統合ソリューション、クラウド ネイティブ製品、サービスとしての統合プラットフォーム、ローコード プラットフォームなど) を真剣に検討する必要があります。ただし、これらのクラウド ネイティブ アプリケーションは分散型であるため、規模が大きくなるにつれて管理と拡張がより複雑になります。

アプリケーションに可観測性を組み込むことで、チームはデータを自動的に収集して分析し、アプリケーションを最適化し、ユーザーに影響を与える可能性のある潜在的な問題を解決できるようになります。さらに、アプリケーションの実行中に問題が発生した場合のデバッグ時間が大幅に短縮されます。これにより、開発者は新機能の開発などの制作タスクに集中できるようになります。

可観測性には、ログ、メトリック、トレースの 3 つの主要コンポーネントがあります。システムの動作を完全に理解するには、3 つのコンポーネントすべてを収集する必要がありますが、アプリケーションの複雑な動作をデバッグするには、1 つまたは 2 つのコンポーネントだけでは不十分です。

この記事では、可観測性の重要性について説明し、クラウド ネイティブ エンジニアリング向けのサービスとしての統合プラットフォームである Choreo によって、開発者がアプリケーションのパフォーマンスを観察し、異常を特定し、詳細な可観測性機能を使用して問題を解決できるようにする方法について説明します。

1. 自動観測

アプリケーションのパフォーマンスに影響を与えずに、運用環境でログ、メトリック、トレース データを収集したい場合、アプリケーションに可観測性を組み込むには多大な労力が必要です。可観測性がパフォーマンスに与える影響を最小限に抑えることを保証することは、可観測性フレームワークを開発する際の主な課題の 1 つです。すべてのリクエストを追跡する場合、パフォーマンスに大きなオーバーヘッドが発生します。

アプリケーションを監視可能にするには、開発者はパフォーマンスが最適化された監視コードを記述し、さまざまなトラフィック条件下でパフォーマンスのオーバーヘッドを動的に制御できるアダプティブ サンプリングなどのアルゴリズムを使用する必要があります。残念ながら、多くのアプリケーション開発者は、3 つの可観測性の柱すべてを収集するコードを実装していません。

これには 2 つの理由があります。まず、多くの開発者が必要なレベルの専門知識を持っていません。第二に、必要な作業量が膨大であるため、コストのかかる取り組みとなります。

アプリケーションに可観測性を統合するには、パフォーマンスに大きなオーバーヘッドがないことを確認するために、複数回の最適化と広範なテストが必要です。

2. Choreoがどのように役立つか

Choreo は、開発者が自分で可観測性を備えたアプリケーションを開発する必要がないように設計されています。 Ballerina は Choreo の基盤となるプログラミング言語であり、強力な可観測性フレームワークを備えています。 Ballerina で書かれたプログラムは完全な可観測性を実現できます。 Choreo は、Ballerina の可観測性フレームワークを使用して、サービスの可観測性データを収集します。

Ballerina の可観測性フレームワークはパフォーマンスのオーバーヘッドを最小限に抑えるように慎重に設計されているため、Choreo アプリケーションは可観測性を有効にした状態で本番環境で実行できます。観測可能性データは、さまざまな視覚化形式でユーザーに表示されます。ユーザーはこれらの視覚化を使用してアプリケーションを最適化し、ユーザー エクスペリエンスに悪影響を与える可能性のある問題を特定して解決できます。図 1 は、Choreo アプリケーションのメインの可観測性ページを示しています。

図 1. Choreo の可観測性ホームページ

（１）平均値を使用して応答時間が長い場合のデバッグ

応答時間は、ユーザー エクスペリエンスに直接影響を与える重要なパフォーマンス指標です。応答時間が長いとユーザーエクスペリエンスが低下し、ユーザーの離脱につながる可能性があります。残念ながら、開発者はアプリケーションの開発中にその応答時間（レイテンシ）にあまり注意を払っていません。このような問題は、アプリケーションが本番環境にデプロイされた後にのみ発見されます。

開発者が応答時間を最適化したとしても、ワークロード条件は時間の経過とともに変化し、応答時間の異常が発生する可能性があります。 Choreo は、さまざまなポイントでアプリケーションのレイテンシを収集し、ユーザーがコード内のボトルネックをすぐに特定できるようにします。応答時間が遅い場合は、コードの問題が原因の可能性があります。または、外部エンドポイントの呼び出しの遅延に関連している可能性があります。 Choreo では、開発者は何時間もデバッグに費やすことなく、これらの問題を特定して解決できます。図 2 は、Choreo で開発されたアプリケーションのレイテンシの内訳を示しています。さまざまな外部 (コネクタ) 呼び出しが全体のレイテンシにどのように影響するかに注意することが重要です。

図2 Choreoで開発されたアプリケーションのレイテンシの内訳

（２）単一リクエストのレイテンシのデバッグ

メトリクスを使用して特定のレイテンシ動作をデバッグすることは可能ですが、レイテンシに関連するより複雑な問題は、図 2 に示す平均レイテンシ値を使用してデバッグすることはできません。このような問題の例としては、応答時間の段階的な増加、平均応答時間の突然の低下またはスパイク (レベル エクスカーションと呼ばれる)、ランダムな時点で発生するレイテンシ スパイクなどがあります。

Choreo を使用すると、開発者はデータをより細かくマイニングして、このような問題を検出できます。たとえば、Choreo の可観測性によって収集されたトレース データを使用すると、開発者は個々のリクエストのレイテンシの内訳を調査して、レイテンシの急増をデバッグできます。図 3 は、Choreo で開発されたアプリケーションのスループットとレイテンシの動作を示しています。

図3. Choreoで開発されたアプリケーションのスループットとレイテンシの動作

これは、ユーザーが特定のリクエストの遅延を認識していることを前提としています。これは、グラフ内の特定のポイントをクリックすることで実行できます。ポイントをクリックすると、単一のリクエストのレイテンシとレイテンシの内訳を取得できます (Choeo は、リクエスト パスのどこでリクエストが最も多くの時間を費やしたかを示します)。図4はこれを示しています。

図4: リクエストパス内でリクエストが最も時間を費やしている場所を表示する

（３）複雑な問題のデバッグ

多くの問題 (バックエンドの速度低下など) はレイテンシ データを分析することで解決できますが、一部の問題ではより詳細な分析が必要になります。このタイプの分析では、複数のメトリックとログを統合されたビューで表示する必要があります。これらのメトリックには、システム メトリック (CPU やメモリなど) とアプリケーション メトリック (スループット、レイテンシ、エラー率など) が含まれます。 Choreo の診断ビューがこれに役立ちます。これにより、開発者は、CPU 使用率が高いなどの動作を詳しく調べてデバッグし、CPU 使用率が高いことと、レイテンシの増加などの別のパフォーマンス メトリックの変化を関連付けることができます。図 5 は Choreo の可観測性の診断ビューを示しています。

図5 Choreo の可観測性の診断ビュー

（４）低構成環境でのデバッグ

開発者は、新しい機能の導入やバグの修正など、さまざまな理由から、新しいコードを記述したり、既存のコードを変更したりする必要があることがよくあります。このような状況が発生すると、パフォーマンス関連のバグがアプリケーションに導入される可能性があります。 Choreo を使用すると、低構成の環境でこのような問題を早期に検出できます。開発者は、低プロファイル環境でアプリケーションをテストし、パフォーマンスの動作を以前のバージョンと比較できます。問題が見つかった場合は、新しいバージョンが本番環境に展開される前に解決できます。まったく新しいアプリケーションの場合でも、開発者はサンプルのテスト データ/ケースを提供することで、より低い構成の環境でアプリケーションをテストできます。

（５）性能異常警報

アプリケーションの異常な動作を識別するために、可観測性ダッシュボードを継続的に監視することは現実的ではありません。そのため、多くのシステムには、パフォーマンスの異常を自動的に検出し、関係者に警告する方法が備わっています。多くのアラート システムでは、しきい値ベースのアプローチを使用してユーザーにアラートを送信します。たとえば、CPU 使用率が 80% を超えると、アラートが生成されて発生します。しきい値ベースの方法には既知の制限があります。まず、しきい値を決定するには人間による構成と専門知識が必要です。第二に、閾値ベースの方法は、アプリケーション内の複雑な異常パターンを検出できないため、精度が低くなります。

Choreo には、高度な機械学習と異常検出アルゴリズムを使用して Choreo ユーザー アプリケーションのパフォーマンス異常を検出する、洗練された異常検出フレームワークがあります。以前のアプリケーションから収集された観測データを使用して、これらの機械学習モデルをトレーニングします。

結論

サービス メッシュは、サービス可観測性データを収集するサイドカー マイクロサービスを通じて可観測性ソリューションを提供しようとしますが、これらのサイドカーによってデフォルトで収集されるデータは、クラウド ネイティブ アプリケーションの詳細なデバッグを実行するには不十分です。この種のデバッグでは、サービス内のより詳細なレベルでデータを収集する必要があります (たとえば、サービス内のさまざまなポイントでの特定のリクエストのレイテンシを分類するなど)。

Choreo には、サービス メッシュの問題を解決する強力な可観測性フレームワークがあります。 Choreo は、アプリケーションのパフォーマンスへの影響を最小限に抑えながら、アプリケーションの 3 つの可観測性の柱すべてを収集します。このデータは、アプリケーション パフォーマンスの異常を簡単にデバッグおよび検出できる形式でユーザーに提示されます。さらに、Choreo には、Choreo アプリケーションのパフォーマンス異常を正確に検出できる高度な機械学習ベースの異常検出テクノロジーが搭載されています。

原題: Observability: Let Your IDE Debug for You、著者: Malith Jayasinghe

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。