クラウドでマイクロサービスをデバッグする方法

[[390478]]

マイクロサービスのデバッグは作業者にとって困難に思えるかもしれませんが、適切なツールと戦略を導入することで作業が楽になります。

情報アーキテクチャの成長により、多くの組織がクラウドサービスを導入し、時間の経過とともに成長してきました。マイクロサービスはこの点で先頭に立っており、さまざまなアプリケーションを独立して展開可能なサービスとして設計する手法として急速に人気が高まっています。

O'Reilly の調査では、回答者の 50% 以上が、組織内の新規開発プロジェクトの 50% 以上でマイクロサービスが使用されていると回答しました。

シングルチップシステムでは、モジュール内の 1 つのエラーが原因でアプリケーション全体が失敗する可能性があります。独立したモジュールを使用すると、開発者は独立したモジュールへの影響を心配することなく、カスタマイズ可能なコードを編集および展開する柔軟性が高まります。

ただし、このアプローチでは、エラーが誤って発生した場合に特有の課題が生じます。クラウドでのマイクロサービスのデバッグは、情報アーキテクチャの複雑さと、開発フェーズから運用フェーズへの移行により、困難な作業になる可能性があります。

いくつかの課題と、それらをシームレスに対処する方法について見てみましょう。

マイクロサービスのデバッグの課題

（１）追跡と観察が不十分

マイクロサービス要件の増加に伴い、インフラストラクチャの複雑さも増しています。各クラウドコンポーネント、モジュール、サーバーレス呼び出しでは、インフラストラクチャの複雑さが隠れていることが多く、DevOps チームや運用チームが出力に基づいてマイクロサービスの内部状態を追跡および観察することが困難になります。独立して実行されるマイクロサービスでは、非同期モジュールに存在するユーザー要求を追跡することが困難であり、エラーの連鎖複製につながる可能性があります。これは、相互に検出して対話するサービスがこれらのバグの影響を受ける可能性があることも意味します。これらの要因により、バグやエラーの根本原因を特定することは開発者にとって困難な作業になります。

（２）複雑な環境下での状態監視

多くのマイクロサービスが集まってシステムを構築すると、それらのステータスの監視が複雑になります。システムにマイクロサービスコンポーネントが追加されるにつれて、各モジュールが独立して動作する複雑なサービスメッシュが進化します。これにより、他のモジュールの動作に影響を与えることなく、いつでも任意のモジュールが故障する可能性も生じます。

開発者は、特定のマイクロサービス内のエラーをデバッグするのが難しいと感じるかもしれません。これらはそれぞれ異なるプログラミング言語でコーディングでき、独自のログ記録機能を備えており、他のコンポーネントからほとんど独立しています。

（３）開発から生産への移行は予測不可能である可能性がある

コードを開発環境から本番環境に移行する場合、パフォーマンスや状態のエラーも予測できません。統合および単体テストを行った後でも、分散サーバー間で何千ものリクエストを処理するときにコードがどのように実行されるかを予測することはできません。コードが適切に拡張されなかったり、データベースがリクエストを処理できなかったりすると、開発者がシステム内の潜在的なバグを検出することはほぼ不可能になります。

クラウドでマイクロサービスをデバッグする方法

ここでは、組織が以下の課題に対処するのに役立つ、マイクロサービス固有のデバッグアプローチをいくつか紹介します。

（１）非侵入型デバッグオプション

従来のデバッグ方法とは異なり、サードパーティのツールを使用すると、DevOps チームはサービスを中断または一時停止してデバッグプロセスの実行に影響を与えないブレークポイントを設定できます。これらの方法は非侵入的であり、開発者はグローバル変数とスタックトレースを表示できるため、エラーをより効果的に監視および検出できます。また、開発者はコードを停止したりコードベースを再デプロイしたりすることなく、発生する可能性のある問題をテストすることもできます。

（２）可観測性向上ツール

多数のマイクロサービスを持つシステムでは、リクエストを追跡するのが困難になります。この問題の解決策として、可観測性のためのカスタムプラットフォームを構築することが考えられるかもしれませんが、開発プロセス中に多くの時間とリソースが消費されます。

幸いなことに、多くの最新のサードパーティツールはリクエストを追跡するように設計されています。マイクロサービスに広範な可観測性を提供します。これらのツールは、分散コンピューティング機能やサーバーレスコンピューティング機能など、多くの機能を提供します。

たとえば、Thundra のようなツールを使用すると、組織は運用中のインフラストラクチャを通過するユーザーリクエストを監視し、開発者がコーディング環境を完全に可視化し、エラーの原因を特定して、迅速にデバッグできるようになります。

（３）自律例外追跡

システムにとって、まず認識すべきことは、エラーを見つけることは難しい作業だということです。システムは、発生した異常を自動的に追跡し、うるう年のバグ、ブラウザのバージョン固有のバグ、奇妙なスタックオーバーフローなどの繰り返し発生するパターンや破壊的な動作をシステムが識別できるようにする必要があります。

ただし、これらのエラーを見つけることは戦いの半分にしか過ぎません。また、システムでは、エラーがいつ、どのような条件で発生したかを調べるために、変数とログを追跡する必要があります。これにより、開発者はバグを排除するための最も効果的なソリューションを見つけることができます。包括的な監視により、運用時のデバッグプロセスが大幅に簡素化されます。