昨年私は，ある大規模Eコマース企業のアーキテクトに会いました。彼は"マイクロサービス"という言葉こそ使いませんでしたが，自分たちが正しいことをしており，自分たちのシステムをドメイン境界に沿って小さく分解している，と話しました。そして私たちは，サービス境界をまたいでビジネスロジックを実行するために，これらのサービスがコラボレーションする方法について議論しました。一般論としては，これは最も重要な部分です。彼は私に，彼らのサービスはイベントバス上にパブリッシュされたイベントを通じて通信している，と説明してくれました。これは通常，"コレオグラフィ(choreography)"と呼ばれる方法です(この概念については後ほど詳しく説明します)。彼らはこれを，サービス間の分離という面で最善の方法だと考えていました。一方で彼らは，システム内で何が発生しているかを理解するのが難しくなり，何かを変更しようとするとさらに難しくなる，という問題を抱えていました。"マイクロサービスの講演のスライドで見るような，演出された(choreographed)ダンスとは全然違って，手に負えないポゴジャンプ(pogo jump)なんだ！"
他のユーザからも同じような話を聞いています。例えばCredit SenseのJosh Wulf氏は，"私たちがリプレースしているシステムは，複雑なピアツーピアのコレオグラフィを使用しているため，複数のコードベースにわたって論理的に考えなければ理解できない代物になっている"，と話しています。
写真撮影: Pedobear19 — CC BY-SA 4.0ライセンスで公開
簡単な例を使って，もっと詳しく調べてみましょう。ある注文処理アプリケーションを開発するものとします。システムの実装にはイベント駆動アーキテクチャを採用して，例えば，Apache Kafkaをイベントバスに使用します。注文が発生すると，Checkoutサービスからイベントが発行され，Paymentサービスによってピックアップされます。このPaymentサービスが集金を行って，Inventoryサービスによってピックアップされるイベントを発行します。
コレオグラフィ・イベントフロー
この動作方法のメリットは，新しいコンポーネントのシステムへの組み込みが簡単なことです。顧客にEメールを送る通知サービスを構築したければ，新たにサービスを追加して，関連するイベントをサブスクライブするだけでよいのです。他のサービスに手を加える必要はありません。これで通信設定を管理すれば，複雑なGDPR(一般データ保護規則)に準拠したユーザ通知を，該当する場所で処理することが可能になります。
このアーキテクチャスタイルがコレオグラフィと呼ばれるものです。各サービスに何をすべきかを告げるようなオーケストレータは必要ありません。対照的に，すべてのコンポーネントがイベントを発行し，他のコンポーネントはそれに対応することができます。このスタイルでは，コンポーネント間の結合が減少し，システムの開発や変更が容易になるものと想定されます。先程説明した通知サービスにも同じことが当てはまります。
イベントの流れを見失う
今回の記事では，このアーキテクチャを議論する時に最も多く寄せられる，"イベントの流れを見失う(そしておそらくは，コントロールを失う)のを避けるにはどうすればよいのか？"という質問を取り上げたいと思っています。Camunda(私の所属する会社)が先日実施した調査で，マイクロサービスの採用について尋ねたところ，回答者の92パーセントが少なくとも検討中であり，64パーセントは何らかの形ですでに実施している，という結果になりました。もはや，単なるハイプではありません。しかしながら，同じ調査でその課題についても質問したところ，次のようなリスクの存在が明確になりました。すなわち，複数のサービスにまたがることで，エンドツーエンドのビジネス・プロセスに関する可視性が失われる，というものです。
データベーストリガを多用したアーキテクチャについて覚えているでしょうか？これを実行すると何が起きるのか，それを待った後では，なぜ今これが起きたのか，正確に知ることのできないアーキテクチャです。見当違いの比較であることは明らかですが，リアクティブなマイクロサービスに伴う課題は，ある部分でこれを連想させます。
可視性を確立する
しかし，私たちに何ができるのでしょう？以下のアプローチは，いずれも可視性を取り戻す上で有効ですが，それぞれメリットとデメリットがあります。
- 分散トレース (例: Zipkin，Jaeger)
- データレイクまたは分析ツール (例: Elastic)
- プロセスマイニング (例: ProM)
- ワークフロー自動化を使用したトラッキング (例: Camunda)
これらのアプローチはすべて，実行中のシステムを監視し，そこに流れるインスタンスを調査するものである点に注目してください。有効な情報を取得可能な静的解析ツールについては，寡黙にして知りません。
分散トレース
分散トレースは，さまざまなシステムやサービスにわたるコールスタックをトレースしようというものです。ユニークなトレースIDを生成して，通常は所定のヘッダ(HTTPヘッダやメッセージングヘッダ)に汎用的に追加することで，これを実現します。世界中のすべての人々がこれらのヘッダを理解するか，少なくともフォワードしてくれれば，もはやパンくず(breadcrumb)がなくても，リクエストはさまざまなサービスをホップできるようになるのです。
分散トレースは一般的に，システム内のリクエストの流れを理解するためや，障害のピンポイント，あるいはパフォーマンスボトルネックの根本を調査するために使用されます。分散トレースの優れた点は，成熟したツールと，それを取り巻く活発なエコシステムが存在することです。そのため，アプリケーションあるいはコンテナを(場合によっては非侵略的に)導入しなくてはならない状況であっても，比較的容易に採用することができます。
これほどメリットがありながら，システムのイベントフローを通じてビジネスプロセスを理解する手段として，分散トレースが実際に使用されていないのはなぜでしょうか？基本的には2つの理由が，このユースケースに分散トレースを適用することを困難にしているのです。
- エンジニア以外の人にとって，トレースは理解が困難です。個人的な試みとして，技術関係者以外の人たちにトレース情報を見せたことがありますが，まったくだめでした。時間を費やしてでも，同じ情報をボックスと矢印で書き直した方が，ずっとうまくいきます。また，メソッド呼び出しやメッセージに関するすべての情報が，全体として通信処理を理解する上で有効であることは間違いなくても，サービス間のビジネスプロセスの本質を理解するには粒度が細か過ぎます。
- 膨大な量の詳細データを管理するために，分散トレースではいわゆるサンプリングを使用しています。これはつまり，リクエストのごく一部のみが収集されている，ということに他なりません。一般的には，リクエストの90パーセント以上が記録されていないのです。"Three Pillars with Zero Answers - towards a New Scorecard for Observability"を読めば，これがよく理解できます。つまり，発生していることがすべて見えている訳ではないのです。
データレイクあるいは分析ツール
従って，トレースを最初から使用するのは，おそらくは不可能です。考えられる次のステップは，同等のことを当面の問題に合わせて行う，ということになります。基本的にこれは，トレースを収集する代わりに，何らかの形ですでに送信されている可能性のある，意味を持ったビジネスないしドメインイベントを収集する，ということを意味します。結果的には，すべてのイベントを監視して，それをデータストアに格納するサービスを開発することが多いのですが，これは相応の負荷を発生させることになります。現在は多くのユーザが，この目的のためにElasticを使用しています。
これは強力なメカニズムで，開発も比較的容易です。イベント駆動方式を採用しているユーザのほとんどは，すでにこのセットアップを実施しています。この方法を導入する上で最大の障害は，大規模な組織において，このようなツールを誰が運用するのかという問題です。中央部の機能として管理する必要があることは間違いありません。その上に独自のインターフェースを設けて，特定の問題を簡単に検索できるようにしておくことは，それほど難しくはありません。
イベントのリストを理解するためのグラフィックがないことは，このアプローチの欠点のひとつですが，例えばイベントをBPMNのような可視化に投影することで，このインフラストラクチャにグラフィックを組み込むことは可能です。
bpmn.ioのような軽量フレームワークを使えば，そのような図に簡単なHTMLページで情報を追加することができます (こちらにその例があります)。
このモデルはワークフローエンジンによって実行されるのではなく，別の方法でキャプチャしたイベントを視覚化するために使用される図です。その意味からは，描画の詳細度に関してはある程度の自由もあります。また，特に全体の概観に関心があるのであれば，さまざまなマイクロサービスからのイベントをひとつの図に表示するようなモデルにすることも可能です。都合のよいことに，この図は個々のサービスのデプロイを妨げることはないため，組織のアジリティの障害になることもありません。ただし，運用中のシステムの現在の状態に対して，図が古いものになるというリスクが発生する，というトレードオフもあります。
プロセスマイニングツール
上記のアプローチでは，視覚化に使用する図を明示的にモデル化する必要がありますが，イベントフローの性質が事前に分かっていない場合には，まずはそれを見つけ出さなければなりません。
この作業は，プロセスマイニングツールで行うことができます。プロセスマイニングツールは，全体的なブループリントを描き出してグラフィカルに示すだけでなく，場合によってはボトルネックないし最適化のためのポイントなど，多くの詳細な情報の掘り下げも可能にしてくれます。
これは私たちの問題にピッタリなように思えますが，残念ながら通常は従来アーキテクチャ内のプロセスフローを見つけ出すために使用されるツールであるため，ログファイルの分析が中心で，実行中のイベントストリームを取り込むのにはあまり適していません。もうひとつ問題なのは，非常に専門的で使いにくい(ProMのように) — あるいは非常に重い(Celonisのように)ツールであることです。そのため，私たちの経験からは，これらのツールを一般的なマイクロサービスの分野に導入するのは，実用的でないことが多いのです。
そうではありますが，イベントフローやビジネスプロセスを可視化する上で，プロセスディスカバリとマイニングは，いろいろな意味で興味深い機能を提供してくれます。これらと同等の機能を提供しながら，軽量で開発者にやさしく，採用の容易なテクノロジが，近い将来に現れるのではないかと期待しています。
ワークフロー自動化によるトラッキング
もうひとつの興味深いアプローチは，ワークフローをモデル化した後に，実際のワークフローエンジン上にデプロイして実行する，というものです。イベントをトラッキングするだけで，それ自体は積極的には何もしないという点において，ワークフローモデルには特別な意味があります。つまり，何もしない — 単に記録するのみ，ということです。私はこのアプローチについて，Kafka Summit San Francisco 2018で取り上げました。講演のビデオには，Apach KafkaとオープンソースのワークフローエンジンであるZeebeを使ったデモが含まれています。
ワークフローエンジン市場には多くのイノベーションがあり，その結果として軽量で開発者にやさしく，スケーラビリティの高いツールが登場しているという面において，このオプションは特に興味深いものです。このアプローチについては，"Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation"で詳しく説明しています。このアプローチの明らかな欠点は，ワークフローを事前にモデル化しなければならないことですが，イベントモニタリングと違うのは，このモデルがワークフローエンジン上で実行されるということです — 実際に受信イベントに対してワークフローインスタンスを起動したり，あるいはイベントへの関連付けを行うのです。現実がモデル化したものに適合しているか，という適合性チェックも可能です。
このアプローチではまた，ワークフロー自動化プラットフォームのツールチェーン全体を活用することができます。何が行われているのかを確認し，SLAを監視し，停止したインスタンスの検出や監査履歴情報の詳細な分析が可能になります。
ワークフローモニタリングの例(camunda.comより)
このアプローチをユーザと検証したところ，セットアップは非常に簡単で，イベントをバスから受け取る汎用コンポーネントを開発して，ワークフローエンジンに関連付けるだけでした。イベントを関連付けられない場合は，簡単なディシジョンテーブルを使って，受信したイベントが無視して構わないものか，後でチェックするインシデントの原因となるものなのかを決定することにしました。さらに，ビジネスロジックを実行するマイクロサービス内で使用されているワークフローエンジンで，全体像を把握するための特別なイベント(ワークフローインスタンスの開始，終了，マイルストン到達など)を生成するようにしました。
このようなワークフロートラッキングはイベントモニタリングに多少似ていますが，ビジネスプロセスに着目している点が異なります。トレースとは違い，ビジネスイベントを100パーセント記録して，さまざまな利害関係者に適したビューを提供することが可能です。
ビジネスの観点
ビジネスプロセスを監視に利用できることの大きなメリットのひとつは，その状況が理解できることです。あるインスタンスについて，それが現在の状態になった経緯や理由をいつでも確認することができます。これにより，(他のインスタンスが通るはずの)どのパスをたどらかなったのか，どのイベントないしデータがその決定につながったのかを理解することが可能になります。さらには，近い将来に発生するであろうことについてのアイデアも得ることができます。これは，他のモニタリングでは不可能なことです。さらには，ビジネスとITの間の整合性という面もあります。現時点ではあまり議論されていなくても，非エンジニアにとって，ビジネスプロセスやさまざまなマイクロサービス間をイベントがどのように流れているのかを理解することは，間違いなく必要なことなのです。
トラッキングからマネージングへの移行
アジリティを維持する上で重要な柱としての運用監視やレポート，KPIや可視性を実現する方法として，プロセストラッキングは適切なものです。しかし実行中のプロジェクトにおいて，このトラッキングアプローチは，マイクロサービス環境における管理とオーケストレーションの拡大に向けた第一歩に過ぎません。
単純な例として，エンドツーエンドのタイムアウトの監視を始めるものとしましょう。このタイムアウトが発生すると，いくつかのアクションが自動的に実施されます。以下の例では，14日後にユーザに対して遅延を通知しますが，その後も待機を継続して，２１日が経過すると注文をキャンセルします。
上の図で興味深い部分のひとつは，"Cancel Order"コマンドの送信です。これはオーケストレーションであって，しばしば物議を醸すものでもあります。
オーケストレーション
サービス間における結合性の発生やマイクロサービス個々の自立性喪失を理由に，オーケストレーションは回避するべきである，という主張をよく耳にします。オーケストレーションが適切に行われない可能性はもちろんありますが，マイクロサービスの原則に沿って，ビジネスに多くの価値をもたらすような方法で実施することも可能なのです。私はInfoQ New York 2018で，この誤解について具体的に説明しました。
本質的な意味で，私の考えるオーケストレーションとは，あるサービスが他のサービスに何らかの実行を指示できるということです。それだけです。結合性が強くなることはありませんし，逆に弱くなります。先程の注文処理を例にしましょう。Checkoutサービスは発注(order placed)イベントを発行するのみで，それを誰が処理するのかは知らない，というのはよい考え方です。発注イベントをリッスンするのはOrderサービスです。受信する側はそのイベントについて知っていて，何をするか判断します。つまり，結合点(decision to couple)は受信側にあるのです。
支払いはこれとは異なります。Paymentサービスが支払い対象が何であるかを知っているというのは，極めて不自然だからです。しかしながら，発注や注文作成(oreder created)といった適切なイベントに対応するためには，そのための情報が必要になります。これは同時に，新しい製品やサービスに対する支払いを受信したい場合には，その情報を変更する必要がある，という意味にもなります。多くのプロジェクトでは，支払い要求(payment required)イベントを発行することで，この不都合な結合を回避しています。しかしながらこれは，送信者が受信者に何かをするように求めているのですから，イベントではありません。コマンドなのです！OrderサービスはPaymentサービスに，代金を回収するように命令(コマンド)します。このケースでは，送信者が送信するコマンドを知っていて，その使用を判断しています。つまり，結合点は送信側にあるのです。
2つのサービス間の通信が意味を持つためには，ある程度の結合性は必要なのですが，どちらの側で結合性を持つのがより適切なのかは，直面している問題によります。
Oｒderサービスがその他のサービスのオーケストレーションを行って，注文に関する一連のステップを実行する責務を負うこともあります。そのメリットについては，前述の講演の中で詳しく説明しています。注意が必要なのは，よいアーキテクチャではオーケストレーションとコレオグラフィのバランスを取る必要がある，ということです。これは必ずしも容易ではありません。
しかし今回の記事では，可視性に重点を置きたいと思っています。ワークフローエンジンを用いたオーケストレーションには，明らかなメリットがあります。モデルはオーケストレーションを実行するコードだけではなく，フローの可視性においても直接使用することができるのです。
まとめ
ビジネスプロセスの可視化は，その実装方法が何であっても不可欠なものです。複数の可能性について議論しましたが，実際のほとんどの状況では，Elasticのようなツールを使って何らかのイベント監視を行うか，ワークフローエンジンを用いてプロセストラッキングを行うかのいずれかです。どちらを選択するかは，ユースケースや関係する役割に多少依存するかも知れません。ビジネスアナリストは，すべてのインスタンスから適切な粒度で収集されたデータを理解する必要がある一方で，運用担当者は，特定のひとつのインスタンスをさまざまな粒度で見る必要があると同時に，システムレベルの障害を迅速に解決可能なツールを用意したいと思うでしょう。
コレオグラフィを採用するサイトの場合は，プロセストラッキングによってさらなるオーケストレーションへと向かうことができます。長期的にビジネスプロセスをコントロールし続ける上で，これは非常に重要なステップだと思います。そうでなければ、 Martin Fowler氏が指摘するように 、"イベント通知を使って首尾よくシステムを分割できるかも知れませんが，全体的なフローに対する視点を失っていることに気付くことができず，結果として将来的なトラブルの種を蒔くことになる"のです。新規システムを開発しているのであれば，当初からオーケストレーションとコレオグラフィの適切なバランスを見つけておくべきです。
ただし、システムの実装の詳細とは無関係に、コラボレーションサービスによって実装されたビジネスプロセスには、ビジネスフレエンドリなビューを必ず用意するようにしてください。
著者について
Bernd Ruecker氏はCamundaの共同創設者であり，技術者です。氏は以前、T-Mobile、Lufthansa、Zalandoなどの世界的な企業で，拡張性の高いコアワークフロー自動化を支援する仕事をしていました。現在は分散システムやマイクロサービス、ドメイン駆動型設計、イベント駆動型アーキテクチャ、リアクティブシステムを中心に，現代的なアーキテクチャに適合する新たなワークフロー自動化パラダイムに注目しています。