最新の革新は効率向上を通じて組織の成功に寄与しますが、その対価は存在します。現在のソフトウェア開発分野が急速に発展する中、複雑な構造は性能問題の解析と解決を非常に困難にします。
これらの問題が顧客体験に影響すると、コストが高騰する恐れがあります。解決策は何かとお考えでしょうか。
経営者、ソフトウェアリーダー、DevOpsエンジニア、またはCEOの方は、その役割や活用時期を理解することで、望ましい競争優位性を確保できます。
観測性は、全体像を掴むための重要な手法であり、分散トレーシングを中心にログ、トレース、メトリクスを通じて実現されます。
分散システムで構築されたアプリのトラブルシューティングでは、従来のトレーシング手法に課題が見られます。
マイクロサービスは個別に拡大・縮小が可能なため、ひとつのサービスが複数の地域、サーバ、環境で同時に動作し、リクエストが複雑なネットワークを経由することが一般的です。
つまり、従来の単一サービス向けの方法ではこれらのリクエストを追跡することができません。そのため、プロジェクト全体をシンプルにし、顧客に影響が出る前に分散システム内のボトルネックやエラーに対応できるようになります。
ここで、アプリ解析の有力な手法である分散リクエストトレーシングが登場します。これはマイクロサービスにおける分散トレーシングとも呼ばれ、各種ログと併せて、アプリの動作情報を収集するために用いられます。
要するに、分散トレーシングは分散システム間を行き来するリクエストを解析・追跡するための欠かせない手法で、以下のことが可能となります。
企業が分散システムに移行する中、個々のマイクロサービスやリクエスト全体の流れを明確に把握する必要性が高まったため、分散トレーシングが有効な手法として定着しました。
ソフトウェア開発チームは、トレーシングの実装、データの収集・表示に多大な労力が必要で、分散トレーシング機能を実装するコード作成は、他の機能に振り分けるはずの時間とリソースを消費することに気づき、その後、2つの選択肢が生じました。
#1 - New Relic のような優れたソリューションを利用すれば、最小限の作業でアプリにトレーシング、データ収集、解析、可視化の機能を実装できます。
#2 -オープンスタンダードを策定することで、様々な計測および観測ソリューションと連携させることが可能となりました。
DevOpsコンテナ、サーバーレス、分散トレーシングなど、コードから本番環境への移行を容易にする要素は、新たな課題も生む傾向にあります。ソフトウェアの複雑性が増すと、故障原因も多様化し、システム修復にかかる平均時間も長くなります。
つまり複雑になるほど、問題の解析に多くの時間と労力を費やすため、革新に充てられる時間が減少します。報告後の問題解決に要する平均時間(MTTR)がその一例です。
分散トレーシングをエンドツーエンドの観測体制に組み込むことで、ソフトウェアチームはより効果的に作業できます。その結果、チームは次のことが可能になります。
しかし、分散トレーシングの重要性について他にも理由があり、以下に示します。
多くのアプリやプログラミング言語に対応しているため、開発者は任意のマイクロサービスシステムに分散トレーシングツールを組み込み、ひとつのトレーシングアプリでデータにアクセスできます。
モノリシックなアプリと比べ、分割されたマイクロサービスでは故障の検出や修正に時間とコストがかかります。さらに、障害データの伝達方法が明確でないため、開発者は複雑なエラー内容を解読する必要があります。これにより、分散システム全体を俯瞰でき、リクエストの問題特定と解決にかかる時間を短縮し、原因の究明も効率的に行えます。
マイクロサービスでは、各サービスが異なる専門チームによって管理されるため、どこでエラーが発生し、どのチームが修正すべきかを特定するのが難しい場合があります。分散トレーシングはデータの隔たりや生産性低下の原因を解消し、迅速な対応とチーム連携を促進します.
分散トレーシングを通して、各サービスの因果関係を理解し、例えばデータベースリクエストのスパンから上流サービスの遅延を把握するなど、パフォーマンス改善に役立ちます。
さらに、前述の利点に加えて、以下の課題も存在します。
エンドツーエンドの分散トレーシングプラットフォームを利用しない場合、リクエストに対しトレースIDが生成されるのは最初のバックエンドサービスのみとなり、フロントエンドのユーザーセッションは確認できません。そのため、リクエストの根本原因の特定と、どのチームが対処すべきかの判断が難しくなります。
一部のソリューションでは、リクエストのトレーシング開始のためにコードの変更や設定の手動調整が必要となります。しかし、これは使用する言語やフレームワークによって求められる場合があります。その欠点として、手動作業は時間を要し、アプリに不具合が発生する恐れや、計測箇所の統一が原因でトレースが欠落する可能性もあります。
専門家は分散トレーシングとログの両方を用いて性能問題の監視・対応に取り組みます。システム内の各タイムスタンプ付きログはそれぞれの事象を記録し、アプリ、インフラ、ネットワーク各層から出力されます。
例えば、コンテナがメモリ不足に陥るとログが生成される場合があります。一方、リクエストが各サービス境界を越える際の可視化は分散トレーシングによって提供され、これはアプリ層でのみ行われます。
トレースによりリクエストの全体の流れを確認し、どこでボトルネックやエラーが発生しているかを特定できますが、問題の原因を深く追求するにはログの調査が必要な場合もあります。
サンプリングは、蓄積される膨大なトレースデータの保存と転送の手間やコストを抑えるための手法です。マイクロサービスの増加やリクエスト数の増大に伴い、全データではなく一部を抽出して保存することで解析に活用します。
サンプリングには以下の2つの方法があります。
ヘッドベースサンプリングは、データ量が膨大な場合に分散トレーシングでよく用いられます。トレース開始時に、完了前にランダムに一つのトレースを抽出し、サンプルとして扱います。この単純な方法により、データは保存または破棄されます。
大規模な分散システムでは、すべてのエラーに対応することが重要です。ヘッドベースの欠点を補うため、テールベースサンプリングの方が適している場合があります。
この方法では、トレースが完了した後に全体を評価し、問題箇所を正確に特定できるため、「藁の中の針探し」の問題が解消されます。
マイクロサービスやクラウドシステムの利用が急増している現状では、観測性がこれまで以上に重要です。システムデータは多様な方法で記録されます。
この全体戦略では、分散システム内で発生する多様なイベントの連なりを示すために、必ずトレーシングが含まれます。ログの一形態であるトレースは、リクエストの流れや構造を明らかにします。
トレーシングは、例えばELKスタックなどのアプリ層を横断する個々のユーザーの動きを記録し、アプリの流れを常に監視するプロセスです。従って、分散トレーシングとELKスタックの比較において、観測性は分散リクエストトレーシングへと進化し、クラウドアプリの健全性を支える基盤となります。
一方、これはマイクロサービスアーキテクチャ内のリクエストの流れをログに記録する手法であり、整然としたデータトレーシング形式により、DevOpsチームがシステムの技術的問題を迅速に把握するのに役立ちます。
プログラムトレースは、アプリが動作する間に実行されたコマンドや参照されたデータの一覧です。デバッグの際、プログラムトレースに表示されるプログラム名、記述言語、実行されたソース文などの情報が利用されます。
デバッガーの自動機能に頼らず、各コード行の実行結果をプログラマーが解析し、その影響を手動で記録する方法です。全体を実行せずに小さな変更の影響が把握できるため、部分的なコードトレースは有効です。
データトレースは、重要なデータ要素(CDE)の正確性や品質を検証し、統計手法を用いてCDEを追跡・管理する手法です。これまで大規模な運用にはコスト面で難がありましたが、ソースデータと照合することで正確性を確認する最良の方法となります。もしくは、統計的工程管理(SPC)でCDEを追跡・監視・制御することも可能です。
コードに計測が実装されると、強力なツールは各リクエストのスパンデータの収集を開始します。
リクエストの流れを追跡するため、まずコードの調整が必要です。現代のトレーシングソリューションは自動計測を提供し、手動修正の手間を省くとともに、多様な言語やフレームワークに対応しています。
各スパンはひとつの分散トレースに統合され、ビジネス上有用なタグが付与されます。利用するツールにより、フレームグラフなどの図表で視覚的に表示されることもあります。
分散トレーシングは、システム内で発生した事象を詳細に伝え、予期しない問題に迅速に対処する助けとなります。今後、技術やソフトウェアが複雑化するにつれて、この手法やメトリクス監視、ログ管理といった戦略の重要性は増していくでしょう。
分散システムにおけるトレーシングの効果を考えれば、予測不可能な挙動の発見により、障害の防止と回復が容易になる点に驚かれるでしょう。
導入方法や、分散トレーシングが複雑なシステムの問題検出にいかに有用かをご理解いただけたなら、今こそ導入を検討する時です。
最新情報を購読