最新のソフトウェア開発は急速に進化しており、最新のイノベーションにより企業は効率を高めて成長することができますが、コストがかかります。 最新のアーキテクチャは非常に複雑であるため、パフォーマンスの問題を診断して修正することが困難になる可能性があります。
これらの問題が顧客体験に影響を与えると、その結果はコストがかかる可能性があります。
それで、解決策は何ですか？
可観測性—全体像の目に見える概要を提供します。 これは、分散トレースに重点を置いて、メトリック、ログ、およびトレースを通じて実現されます。
DevOpsエンジニア、ソフトウェアリーダー、CEO、またはビジネスリーダーのいずれであっても、分散トレースが果たす役割と、それをいつ使用するかを理解することで、求めている競争力を得ることができます。
分散トレースは、システムのデバッグ、開発、およびデプロイを容易にする新しいDevOpsプラクティスです。
分散トレースには、最新のアプリケーション環境の操作と監視が含まれます。 データがXNUMXつのサービスから別のサービスに移動するとき、分散トレースはサービス要求を追跡および監視する機能です。 ここでの目標は、要求のフローを理解して、障害やパフォーマンスの問題など、システムの弱点を特定できるようにすることです。
このリクエストの流れは、マイクロサービス環境または分散アーキテクチャを介して行われます。これについては後で触れます。
説明したように、トレースは、メトリックとログという他のXNUMXつの重要なタイプのデータと密接に関連しています。 これらのXNUMX種類のテレメトリデータを組み合わせることで、ソフトウェア環境の全体像を把握でき、さらに重要なことに、そのパフォーマンスを把握できます。
推奨書籍： テレメトリとは何ですか？
分散トレースの主な使用例には、運用、DevOps、およびソフトウェアエンジニアが含まれます。 目標は、主に分散環境に焦点を当てて、迅速に回答を得ることです。 マイクロサービス またはサーバーレスアーキテクチャ。 これらのアーキテクチャには多くの利点がありますが、非常に複雑でもあります。 これにより、問題の追跡と解決が困難になります。
日常のeコマースアプリケーションについて考えてみてください。 顧客が購入すると、一連の要求が分散サービスとデータベースを通過します。 店頭からショッピングカート、認証から支払い、配送、CRMまで、うまくいかないことがたくさんあります。 これらのサービスのいずれかで問題が発生した場合、顧客体験は悪くなり、おそらく販売の損失につながるでしょう。 定期的な顧客の喪失は言うまでもありません。 この研究は、否定的な経験に続いて、 95% のユーザーがウェブサイトを離れます。 一度やったら、戻ってくるのは難しいです。
分散トレースは複雑さを解消するのに役立ち、分散システムの問題とボトルネックのトラブルシューティングを可能にします 顧客が影響を受けます。 高度に分散されたコンテキストで可観測性を維持するためにオペレーターが使用するトレースは、遅延などの問題を特定し、根本原因と周囲のコンテキストを分析できます。これは非常に貴重です。
したがって、分散トレースは、分散システム全体でバウンスするため、すべてのサービスにわたって要求を追跡および分析するプロセスです。 これにより、次のことが可能になります。
モノリシックサービスアーキテクチャは、かつてはゴールデンスタンダードでしたが、現在ではますますまれになっています。
モノリシックアプリケーションが進化しました マイクロサービスに。 単一のサービスに一元化されたコードベースを含む従来のモノリシックアプリケーションの場合、障害の診断は、単一のスタックトレースをたどるのと同じくらい簡単です。 エラーのトラブルシューティングを行うには、ログメッセージを確認するか、標準のAPMツールを実装するだけです。 ただし、このタイプのアーキテクチャでは、ソフトウェア開発のスケーリングが面倒で骨の折れる作業になります。
テクノロジーが進化するにつれて、マイクロサービスなどの分散アーキテクチャが開発され、さまざまなプラットフォームとよりユーザーフレンドリーなシステム間の通信が改善されました。 その結果、効率と生産性が向上しました。
分散アーキテクチャまたはマイクロサービスベースのアプリケーションは、さまざまなホストで実行される数十、数百、さらには数千のサービスで構成されている可能性があるため、関係を理解するには、より深く、より複雑なレベルのテレメトリが必要です。 。
マイクロサービスを使用してアプリを開発することのメリットは膨大です。 このアプローチには、より簡単に展開、拡張、更新できる小規模なサービスが含まれます。 これにより、各コンポーネントに使用するテクノロジーとフレームワークの点で柔軟性が高まります。
多くの実際の環境では、マイクロサービスベースのアプリと一緒にモノリスアプリを組み合わせて使用していますが、劇的な変化がありました。 2018年現在、 研究ショー 従来の企業の63％がマイクロサービスアーキテクチャを使用しており、次のことを経験しています。
この調査は、51か国とXNUMXの業界にわたるエンジニアリングマネージャー、ソフトウェアアーキテクト、およびその他のアプリケーション開発の専門家の見解に基づいています。
別の2020年のレポート 組織の92％がマイクロサービスで成功を収めていることがわかりました。 これは、マイクロサービスのメリットを活用していない場合、取り残されるリスクがあることを意味します。
今日、最新のソフトウェアソリューションは通常、大規模で複雑な分散システムとして実装されています。 たとえば、マイクロサービスのアーキテクチャスタイルを使用します。 これらの最新のアプリケーションは、多くの場合、さまざまなチームによって開発されており、さまざまな言語プログラムを使用することもあります。 これらのアプリケーションが進化するにつれて、企業は、個々のマイクロサービスだけでなく、リクエストフロー全体を表示する方法が必要であることに気づきました。
上記の調査に基づくと、複数のマイクロサービスにわたるエンドツーエンドプロセスの可視性の欠如、およびチーム間のコミュニケーションは、マイクロサービスを使用する企業が直面すると予想される最大の課題の一部です。 最終的な目標は、プロセス全体でエラーを確実かつ一貫して処理することです。
ここで分散トレースが役立ち、最適な可視性と制御のためのベストプラクティスになりました。 分散トレースは、分散環境での要求の追跡と分析の難しさなど、一般的な問題に対処します。 システムが高度に分散している場合でも、トレースのおかげで、これらの問題のデバッグもかなり簡単です。
最初、この概念は非常に時間がかかりました。 データを収集して視覚化できることは、非常に労働集約的でした。 トレースに費やされていたリソースの数は、新機能の開発と企業の全体的な成長から奪われていました。 分散アーキテクチャを適切にサポートするにはツールの開発が必要であり、分散トレースへの依存度が高まっています。 これには、データトレースツールが含まれます。
分散トレースは、単一のモノリシックプロセスの視点を提供するために使用されたトレースの概念を採用し、単一の要求のジャーニーに含まれるすべてのプロセスの視点に拡張しました。
幸い、LogicMonitorなどの企業は完全に自動化されたアプローチを提供し始めました。 これにより、企業は、利用可能なデータの追跡、分析、および視覚化の生産性を向上させるソリューションを実装することが可能になりました。 識別できる コラボレー アプリケーションで発生する問題は、ゲームチェンジャーです。
2019年、OpenTracingとOpenCensusはOpenTelemetryに統合されました。
OpenTelemetryは、インフラストラクチャとクラウドネイティブアプリケーションからログ、メトリック、およびトレースをキャプチャしてエクスポートするための単一のオープンソース標準を提供します。 OpenTelemetryは、SDKとAPIの共通セットを含む、すべての実装が従うべき仕様を提供することで、分散トレースを支援します。
分散トレースはXNUMX年以上前から存在していましたが、分散トレースシステム間の相互運用性が広く採用されるようになったのはごく最近のことです。 OpenCensusとOpenTracingの間に相互運用性を生み出したのはOpenTelemetryです。
続きを読む： OpenTelemetryの紹介
LogicMonitorの分散トレースはOpenTelemetryベースの統合であり、インストルメントされたアプリケーションからトレースデータを転送できます。 これにより、分散サービスを通過するエンドツーエンドのリクエストを監視できます。 インストールの詳細 OpenTelemetryコレクター.
分散トレースは、ツリーのような構造と考えてください。 ルートまたは「親」スパンは、「子」スパンに分岐します。
エンドユーザーがアプリケーションと対話すると、トレースが開始されます。 HTTPなどの最初の要求が送信されると、その要求には一意のトレースIDが与えられます。 そのトレースは、その単一の要求の全過程を説明します。 リクエストがシステム内を移動すると、操作または「スパン」にその初期トレースIDのタグが付けられます。 また、一意のIDが割り当てられます。 現在のリクエストを最初に生成した操作に関連付けられたIDもあります。これは「親」スパンとも呼ばれます。
各スパンは、リクエストの過程におけるXNUMXつのステップを表し、タグからクエリ、詳細なスタックトレース、コンテキストを提供するログやイベントまで、すべてを含む重要なデータでエンコードされます。 これは、トレースが分散システムを移動するときに、プラットフォームが途中で必要な追加の操作ごとに子スパンを生成することを意味します。
次のようなツールを使用する LogicMonitorの分散トレース、エンドツーエンドのリクエストを監視しながら、データをより適切に視覚化できます。
以下を含む複数のステップのプロセスが含まれます。
このプロセスに基づいて、分散トレースはエンドユーザーのエクスペリエンスをリアルタイムで可視化できます。
まとめると、
マイクロサービスとクラウドベースのアプリケーションの使用が増えるにつれて、可観測性の必要性がかつてないほど重要になっています。 これは、システムデータをさまざまな形式で記録することによって実現されます。
上記では、メトリック、ログ、およびトレースについて説明しました。 一緒に、これらはしばしば呼ばれます 可観測性の柱。 これらの戦略を理解すると、より優れたシステムを構築および管理できます。
トレースは、この全体的な戦略のXNUMXつの重要なコンポーネントであり、分散システムを介した一連の分散イベントを表します。 トレースはログの表現であり、リクエストが移動するパスとリクエストの構造を可視化します。
トレースとは、アプリケーションのフローを継続的に監視し、アプリスタックを介したXNUMX人のユーザーの移動を追跡することです。 分散リクエストトレースは、可観測性の方法から進化し、クラウドアプリケーションが正常であることを保証します。 分散トレース マイクロサービスアーキテクチャのパスに関連付けられたデータを記録することにより、リクエストを追跡するプロセスが含まれます。 このアプローチは、さまざまな業界で活用される適切に構造化された形式のデータトレースを提供し、DevOpsチームがシステムインフラストラクチャを混乱させる技術的な不具合をすばやく理解するのに役立ちます。
繰り返しますが、これはOpenTelemetryなどのツールの使用に関連しています。
新しいテクノロジーと慣行の開発により、企業はかつてないほど急速に成長することができます。 ただし、マイクロサービス、コンテナー、DevOps、サーバーレス関数、クラウドなどの変数が速度を上げ、コードから本番環境への移行を容易にするため、これは新たな課題を生み出します。
ソフトウェアが複雑になるほど、アプリケーションスタック内の潜在的な障害点が増え、平均修復時間（MTTR）が増加します。これは、問題が報告されてからその問題が解決されるまでにかかる平均時間です。 。 複雑さが増すにつれて、問題の診断により多くの時間とエネルギーが費やされるため、革新する時間も少なくなります。
関連する MTTR、MTTD、MTTF、MTBFの違いは何ですか？
分散トレースをエンドツーエンドの可観測性戦略の一部にすることで、ソフトウェアチームははるかに効果的に運用できます。 その過程で、チームは次のことができます。
分散システムに一貫性をもたらすことは、分散トレースの主な利点です。 ただし、これは他のメリットのリストにつながり、企業の収益に直接影響します。
だから、理由 現在も将来も、 分散トレースソリューションが明確であることを求めますが、どのようにしたらよいでしょうか。
サービスがほんの一握りであっても、データの量は膨大になり、高速になる可能性があります。 痕跡をふるいにかけることは、干し草の山から針を見つけることによく似ています。 すべてのトレースをリアルタイムで適切に観察、分析、および理解するには、分散トレースツールが必要です。 これにより、次の点で最も有用な情報が強調表示されます。 コラボレー あなたは行動を起こすべきです。
サンプリングは、時間の経過とともに収集される膨大な量のトレースデータに基づいて機能します。 より多くのマイクロサービスがデプロイされ、リクエストの量が増えると、そのデータの保存/送信の複雑さとコストも増加します。 すべてのデータを保存する代わりに、組織は分析のためにデータのサンプルを保存できます。
分散トレースをサンプリングするには、XNUMXつのアプローチがあります。
大量のデータを処理する場合、分散トレースソリューションはヘッドベースのサンプリングを使用することがよくあります。 これには、パスが完了する前にサンプリングするトレースをランダムに選択することが含まれます。 これは、単一のトレースが開始されたときにサンプリングが開始されることを意味します。 そのデータは保持または破棄され、その単純さに基づいてサンプリングの好ましい形式です。
ヘッドベースのサンプリングには多くの利点があります。高速でシンプルであり、アプリケーションのパフォーマンスにほとんどまたはまったく影響を与えず、モノリスとマイクロサービスが混在する環境に最適です。 欠点は、データがランダムに選択されるため、関連するトレースデータやコンテキストがないため、貴重な情報が失われる可能性があることです。
ヘッドベースのサンプリングの制限に基づいて、テールベースのサンプリングは、すべてのエラーを観察する必要がある大量の分散システムに最適です。 この場合、サンプリングが行われ、トレースの100％が分析されます After トレースは完全にパスを完了しました。 これにより、問題がどこにあるかを正確に特定し、干し草の山の問題で針全体を解決することができます。
テールベースのサンプリングは、特にレイテンシー測定の場合、より多くの情報に基づいた決定につながります。 サンプリングの決定はワークフローの最後に行われるため、エラーやパフォーマンスの問題を視覚化するのが簡単になります。 このオプションの欠点は、大量のデータの送信と保存にコストがかかる可能性があり、追加のゲートウェイとプロキシが必要になることです。
分散トレース用語の短い用語集は次のとおりです。
分散トレースは、システムで何が起こったかを物語り、予測できない問題に迅速に対処するのに役立ちます。 テクノロジーとソフトウェアの将来がますます複雑になるにつれて、分散トレースの使用、およびメトリックの監視やロギングなどの手法がますます重要になります。 挑戦に立ち向かう時が来ました。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
