個々のマイクロサービスではなくプロセスにフォーカスすること

分散システムを基にしたマイクロサービスに取り組む際の成功の鍵は、マイクロサービス自体ではなく、総じて分散プロセスにフォーカスすることだ。サービスは重要性が最も低いパートである、とEric Ess氏は主張した。彼は最近ロンドンで行われたMicroservices Conferenceで、jet.comにおいて分散プロセスをでどう監視しているかというプレゼンテーションを行った。

Jetでは、ユーザによって開始されたプロセスは、完了するために少なくともいくつかマイクロサービスが必要であり、分散プロセスと呼ばれている。技術ディレクターであるEss氏は、これはシステムがユーザのリクエストをどう処理するかを検査する場合のキータームであると説明した。

Jetは今日およそ800のマイクロサービスを稼働させ、非常に複雑なコミュニケーショントポロジーを持っている。この複雑性により、どのチームもスコープ外で何が起っているのか知ることができず、また個々人にとってもシステムアーキテクチャを完全に理解することは不可能である。この複雑性にも関わらず、問題が起っている間は、根本原因が何か、どのサービスで生じているのかを正確に知ることが不可欠となる。

これを乗り越えるために、達成したい鍵となることが2つある。

• シングルプロセスがどう動いているか、どのマイクロサービスをパスしたか、現在何を行っているのかを理解すること。基本的には相互作用するマイクロサービスを介してシステム内を移動するとき、異なるタイプのプロセスに従うことができる。
• 特定のプロセスに期待されるワークフローを定義することでプロセスを確認し、実行時にそのパスを辿ることを検証すること。Ess氏は、たとえプロセスがエラーを起こしていなくても、なお間違った動作をする可能性があると指摘した。例えば、A/B テストにあるバグである。プロセスを間違った方法でルーティングし、テストデータに欠陥を起こしたりする。

Ess氏は、マイクロサービス自体ではなく、総じて分散プロセスにフォーカスすることで、サービスのことは無視できると説いた。それはプロセスを次のサービスに動かす手段であり、プロセス完了に向けたステップである。プロセスの現状と、それに対して起こっていることが関心なのだ。

これにはマインドセットの切り替えと、そしてマイクロサービスではなく、システムに関するプロセスの動作と、メッセージを受け取ったときにそれがどんな動作をするべきかにフォーカスするエンジニアが必要である。あるチームは個々のマイクロサービスではなく、周辺のサービスと相互作用するマイクロサービスを建てている。

マイクロサービスやシステムを評価できるツールは多くあっても、実行中のプロセスやその動作を評価するものはない。加えて、JetはF#を使っており、それに合うツールが見つからなかったため、自身でツールボックスを開発した。

稼働中のシステムとそのプロセスの概観を示すため、彼らは通信プロトコル(Dr Orpheus)を生み出した。各メッセージに入るヘッダのメタデータのセットと、マイクロサービスがメタデータと共にメッセージを受けたときに何をすべきかというルールを提供している。また、基本的な複合イベント処理(CEP)を行い、各マイクロサービスがメッセージ処理時に出力するデータを集めるテレメトリプロセス / データストリーミングエンジン(XRay)を構築した。エンジニアとビジネスマンは今や全てのプロセスを監視し、あらかじめ定義されたフローに従わない、処理が遅い、サービスを阻害しているといったように、何らかの形で間違った動作をした場合にも反応することができる。

来年のMicroservices Conferenceはロンドンで、2017年11月6-7日に予定されている。