全3648文字
PR

 分散システム環境では、ハードウエアやソフトウエアの不具合、トラフィックの急増といった様々なトラブルが発生する。これらを前提としてサービスの可用性を高めるためのデザインパターンが「レジリエンスプログラミング」だ。これまで「タイムアウト」や「リトライ」、「サーキットブレーカー」といった手法を紹介してきた。

 もっとも、これらを有効に機能させるには、繊細なチューニングが必要になる。本番環境の性能とデータサイズ、到着するトラフィックの分布といった実際のデータでアプリケーションの動的な挙動を観察したうえで、同時接続数の上限やタイムアウトの時間などの最適値を割り出さなければならない。

 ここで問題になるのが、動いているシステムの内部の挙動をどうやって観察するかということだ。

 一般的に最も利用されている手法は「ログ」だ。システムの内部で発生した事柄を時間とともに出力するログを追いかければ、システムの内部で何がどのような順番で発生したのかを確認できる。ただし、ログの分析には極めて高い集中力と粘り強い根気が求められる。

 そこで最近、注目されつつあるのが「分散トレーシング」というテクノロジーだ。

 次に示したのは、筆者がプロダクション環境で導入している「New Relic」という分散トレーシング対応製品の画面だ。あるHTTPリクエストが内部でどのように処理されたのかを表している。

[画像のクリックで拡大表示]

 どの処理に時間がかかり、どこが非同期処理として並行で動作し、処理ごとにどのようなパラメーターで呼び出されたのかを「スパン」として記録し、可視化できる。

 ログも統合されているので、特定のリクエストに起因するログメッセージだけを抽出して表示するといったことも可能だ。

 分散トレーシングを導入することで、本番環境におけるレジリエンスプログラミングの効果を確認でき、各種の制限値を適切に設定できるようになる。

 今回の記事のために、分散トレーシングを実際に試すことができる環境と、レジリエンスプログラミングのためのJavaライブラリー「Resilience4J」を利用したサンプルコードを用意した。

GitHubリポジトリーのURL: https://github.com/nebosuke/resilience-sample

 今回はこのコードを基に、本番環境に分散トレーシングを導入し、タイムアウトやリトライ、サーキットブレーカーなどの効果を確認する方法を解説する。