Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/02/28)へのリンク昨年私は,ある大規模Eコマース企業のアーキテクトに会いました。彼は"マイクロサービス"という言葉こそ使いませんでしたが,自分たちが正しいことをしており,自分たちのシステムをドメイン境界に沿って小さく分解している,と話しました。私たちは,サービス境界をまたいでビジネスロジックを実行するために,これらのサービスがコラボレーションする方法について議論しました。一般論としては,これは最も重要な部分です。彼は私に,彼らのサービスはイベントバス上にパブリッシュされたイベントを通じて通信している,と説明してくれました。これは通常,"コレオグラフィ(choreography)"と呼ばれる方法です(この概念については後ほど詳しく説明します)。彼らはこれを,サービス間の分離という面で最善の方法だと考えていました。一方で彼らは,システム内で何が発生しているかを理解するのが難しくなり,何かを変更しようとするとさらに難しくなる,という問題を抱えていました。jump)なんだ!"他のユーザからも同じような話を聞いています。Wulf氏は,"私たちがリプレースしているシステムは,複雑なピアツーピアのコレオグラフィを使用しているため,複数のコードベースにわたって論理的に考えなければ理解できない代物になっている",と話しています。簡単な例を使って,もっと詳しく調べてみましょう。ある注文処理アプリケーションを開発するものとします。Kafkaをイベントバスに使用します。注文が発生すると,Checkoutサービスからイベントが発行され,Paymentサービスによってピックアップされます。このPaymentサービスが集金を行って,Inventoryサービスによってピックアップされるイベントを発行します。コレオグラフィ・イベントフローこの動作方法のメリットは,新しいコンポーネントのシステムへの組み込みが簡単なことです。顧客にEメールを送る通知サービスを構築したければ,新たにサービスを追加して,関連するイベントをサブスクライブするだけでよいのです。他のサービスに手を加える必要はありません。これで通信設定を管理すれば,複雑なGDPR(一般データ保護規則)に準拠したユーザ通知を,該当する場所で処理することが可能になります。このアーキテクチャスタイルがコレオグラフィと呼ばれるものです。各サービスに何をすべきかを告げるようなオーケストレータは必要ありません。対照的に,すべてのコンポーネントがイベントを発行し,他のコンポーネントはそれに対応することができます。このスタイルでは,コンポーネント間の結合が減少し,システムの開発や変更が容易になるものと想定されます。先程説明した通知サービスにも同じことが当てはまります。イベントの流れを見失う今回の記事では,このアーキテクチャを議論する時に最も多く寄せられる,"イベントの流れを見失う(そしておそらくは,コントロールを失う)のを避けるにはどうすればよいのか?"という質問を取り上げたいと思っています。Camunda(私の所属する会社)が先日実施した調査で,マイクロサービスの採用について尋ねたところ,回答者の92パーセントが少なくとも検討中であり,64パーセントは何らかの形ですでに実施している,という結果になりました。単なるハイプではありません。同じ調査でその課題についても質問したところ,次のようなリスクの存在が明確になりました。複数のサービスにまたがることで,エンドツーエンドのビジネス・プロセスに関する可視性が失われる,というものです。データベーストリガを多用したアーキテクチャについて覚えているでしょうか?これを実行すると何が起きるのか,それを待った後では,なぜ今これが起きたのか,正確に知ることのできないアーキテクチャです。見当違いの比較であることは明らかですが,リアクティブなマイクロサービスに伴う課題は,ある部分でこれを連想させます。可視性を確立するしかし,私たちに何ができるのでしょう?以下のアプローチは,いずれも可視性を取り戻す上で有効ですが,それぞれメリットとデメリットがあります。Camunda)これらのアプローチはすべて,実行中のシステムを監視し,そこに流れるインスタンスを調査するものである点に注目してください。有効な情報を取得可能な静的解析ツールについては,寡黙にして知りません。分散トレース分散トレースは,さまざまなシステムやサービスにわたるコールスタックをトレースしようというものです。ユニークなトレースIDを生成して,通常は所定のヘッダ(HTTPヘッダやメッセージングヘッダ)に汎用的に追加することで,これを実現します。世界中のすべての人々がこれらのヘッダを理解するか,少なくともフォワードしてくれれば,もはやパンくず(breadcrumb)がなくても,リクエストはさまざまなサービスをホップできるようになるのです。分散トレースは一般的に,システム内のリクエストの流れを理解するためや,障害のピンポイント,あるいはパフォーマンスボトルネックの根本を調査するために使用されます。分散トレースの優れた点は,成熟したツールと,それを取り巻く活発なエコシステムが存在することです。そのため,アプリケーションあるいはコンテナを(場合によっては非侵略的に)導入しなくてはならない状況であっても,比較的容易に採用することができます。これほどメリットがありながら,システムのイベントフローを通じてビジネスプロセスを理解する手段として,分散トレースが実際に使用されていないのはなぜでしょうか?基本的には2つの理由が,このユースケースに分散トレースを適用することを困難にしているのです。エンジニア以外の人にとって,トレースは理解が困難です。個人的な試みとして,技術関係者以外の人たちにトレース情報を見せたことがありますが,まったくだめでした。時間を費やしてでも,同じ情報をボックスと矢印で書き直した方が,ずっとうまくいきます。メソッド呼び出しやメッセージに関するすべての情報が,全体として通信処理を理解する上で有効であることは間違いなくても,サービス間のビジネスプロセスの本質を理解するには粒度が細か過ぎます。膨大な量の詳細データを管理するために,分散トレースではいわゆるサンプリングを使用しています。これはつまり,リクエストのごく一部のみが収集されている,ということに他なりません。一般的には,リクエストの90パーセント以上が記録されていないのです。Observability"を読めば,これがよく理解できます。発生していることがすべて見えている訳ではないのです。データレイクあるいは分析ツール従って,トレースを最初から使用するのは,おそらくは不可能です。考えられる次のステップは,同等のことを当面の問題に合わせて行う,ということになります。基本的にこれは,トレースを収集する代わりに,何らかの形ですでに送信されている可能性のある,意味を持ったビジネスないしドメインイベントを収集する,ということを意味します。結果的には,すべてのイベントを監視して,それをデータストアに格納するサービスを開発することが多いのですが,これは相応の負荷を発生させることになります。現在は多くのユーザが,この目的のためにElasticを使用しています。これは強力なメカニズムで,開発も比較的容易です。イベント駆動方式を採用しているユーザのほとんどは,すでにこのセットアップを実施しています。この方法を導入する上で最大の障害は,大規模な組織において,このようなツールを誰が運用するのかという問題です。中央部の機能として管理する必要があることは間違いありません。その上に独自のインターフェースを設けて,特定の問題を簡単に検索できるようにしておくことは,それほど難しくはありません。イベントモニタUIの例イベントのリストを理解するためのグラフィックがないことは,このアプローチの欠点のひとつですが,例えばイベントをBPMNのような可視化に投影することで,このインフラストラクチャにグラフィックを組み込むことは可能です。(こちらにその例があります)。このモデルはワークフローエンジンによって実行されるのではなく,別の方法でキャプチャしたイベントを視覚化するために使用される図です。その意味からは,描画の詳細度に関してはある程度の自由もあります。全体の概観に関心があるのであれば,さまざまなマイクロサービスからのイベントをひとつの図に表示するようなモデルにすることも可能です。都合のよいことに,この図は個々のサービスのデプロイを妨げることはないため,組織のアジリティの障害になることもありません。運用中のシステムの現在の状態に対して,図が古いものになるというリスクが発生する,というトレードオフもあります。プロセスマイニングツール上記のアプローチでは,視覚化に使用する図を明示的にモデル化する必要がありますが,イベントフローの性質が事前に分かっていない場合には,まずはそれを見つけ出さなければなりません。この作業は,プロセスマイニングツールで行うことができます。プロセスマイニングツールは,全体的なブループリントを描き出してグラフィカルに示すだけでなく,場合によってはボトルネックないし最適化のためのポイントなど,多くの詳細な情報の掘り下げも可能にしてくれます。イメージ引用これは私たちの問題にピッタリなように思えますが,残念ながら通常は従来アーキテクチャ内のプロセスフローを見つけ出すために使用されるツールであるため,ログファイルの分析が中心で,実行中のイベントストリームを取り込むのにはあまり適していません。非常に重い(Celonisのように)ツールであることです。そのため,私たちの経験からは,これらのツールを一般的なマイクロサービスの分野に導入するのは,実用的でないことが多いのです。イメージ引用そうではありますが,イベントフローやビジネスプロセスを可視化する上で,プロセスディスカバリとマイニングは,いろいろな意味で興味深い機能を提供してくれます。これらと同等の機能を提供しながら,軽量で開発者にやさしく,採用の容易なテクノロジが,近い将来に現れるのではないかと期待しています。ワークフロー自動化によるトラッキングもうひとつの興味深いアプローチは,ワークフローをモデル化した後に,実際のワークフローエンジン上にデプロイして実行する,というものです。イベントをトラッキングするだけで,それ自体は積極的には何もしないという点において,ワークフローモデルには特別な意味があります。記録するのみ,ということです。2018で取り上げました。KafkaとオープンソースのワークフローエンジンであるZeebeを使ったデモが含まれています。ワークフローエンジン市場には多くのイノベーションがあり,その結果として軽量で開発者にやさしく,スケーラビリティの高いツールが登場しているという面において,このオプションは特に興味深いものです。Automation"で詳しく説明しています。実際に受信イベントに対してワークフローインスタンスを起動したり,あるいはイベントへの関連付けを行うのです。現実がモデル化したものに適合しているか,という適合性チェックも可能です。このアプローチではまた,ワークフロー自動化プラットフォームのツールチェーン全体を活用することができます。何が行われているのかを確認し,SLAを監視し,停止したインスタンスの検出や監査履歴情報の詳細な分析が可能になります。ワークフローモニタリングの例(camunda.comより)このアプローチをユーザと検証したところ,セットアップは非常に簡単で,イベントをバスから受け取る汎用コンポーネントを開発して,ワークフローエンジンに関連付けるだけでした。イベントを関連付けられない場合は,簡単なディシジョンテーブルを使って,受信したイベントが無視して構わないものか,後でチェックするインシデントの原因となるものなのかを決定することにしました。ビジネスロジックを実行するマイクロサービス内で使用されているワークフローエンジンで,全体像を把握するための特別なイベント(ワークフローインスタンスの開始,終了,マイルストン到達など)を生成するようにしました。このようなワークフロートラッキングはイベントモニタリングに多少似ていますが,ビジネスプロセスに着目している点が異なります。トレースとは違い,ビジネスイベントを100パーセント記録して,さまざまな利害関係者に適したビューを提供することが可能です。ビジネスの観点ビジネスプロセスを監視に利用できることの大きなメリットのひとつは,その状況が理解できることです。あるインスタンスについて,それが現在の状態になった経緯や理由をいつでも確認することができます。これにより,(他のインスタンスが通るはずの)どのパスをたどらかなったのか,どのイベントないしデータがその決定につながったのかを理解することが可能になります。近い将来に発生するであろうことについてのアイデアも得ることができます。これは,他のモニタリングでは不可能なことです。ビジネスとITの間の整合性という面もあります。現時点ではあまり議論されていなくても,非エンジニアにとって,ビジネスプロセスやさまざまなマイクロサービス間をイベントがどのように流れているのかを理解することは,間違いなく必要なことなのです。トラッキングからマネージングへの移行アジリティを維持する上で重要な柱としての運用監視やレポート,KPIや可視性を実現する方法として,プロセストラッキングは適切なものです。実行中のプロジェクトにおいて,このトラッキングアプローチは,マイクロサービス環境における管理とオーケストレーションの拡大に向けた第一歩に過ぎません。単純な例として,エンドツーエンドのタイムアウトの監視を始めるものとしましょう。このタイムアウトが発生すると,いくつかのアクションが自動的に実施されます。以下の例では,14日後にユーザに対して遅延を通知しますが,その後も待機を継続して,21日が経過すると注文をキャンセルします。Order"コマンドの送信です。これはオーケストレーションであって,しばしば物議を醸すものでもあります。オーケストレーションサービス間における結合性の発生やマイクロサービス個々の自立性喪失を理由に,オーケストレーションは回避するべきである,という主張をよく耳にします。オーケストレーションが適切に行われない可能性はもちろんありますが,マイクロサービスの原則に沿って,ビジネスに多くの価値をもたらすような方法で実施することも可能なのです。2018で,この誤解について具体的に説明しました。本質的な意味で,私の考えるオーケストレーションとは,あるサービスが他のサービスに何らかの実行を指示できるということです。結合性が強くなることはありませんし,逆に弱くなります。先程の注文処理を例にしましょう。placed)イベントを発行するのみで,それを誰が処理するのかは知らない,というのはよい考え方です。発注イベントをリッスンするのはOrderサービスです。受信する側はそのイベントについて知っていて,何をするか判断します。couple)は受信側にあるのです。支払いはこれとは異なります。Paymentサービスが支払い対象が何であるかを知っているというのは,極めて不自然だからです。created)といった適切なイベントに対応するためには,そのための情報が必要になります。これは同時に,新しい製品やサービスに対する支払いを受信したい場合には,その情報を変更する必要がある,という意味にもなります。required)イベントを発行することで,この不都合な結合を回避しています。これは,送信者が受信者に何かをするように求めているのですから,イベントではありません。コマンドなのです!OrderサービスはPaymentサービスに,代金を回収するように命令(コマンド)します。このケースでは,送信者が送信するコマンドを知っていて,その使用を判断しています。結合点は送信側にあるのです。2つのサービス間の通信が意味を持つためには,ある程度の結合性は必要なのですが,どちらの側で結合性を持つのがより適切なのかは,直面している問題によります。Orderサービスがその他のサービスのオーケストレーションを行って,注文に関する一連のステップを実行する責務を負うこともあります。そのメリットについては,前述の講演の中で詳しく説明しています。注意が必要なのは,よいアーキテクチャではオーケストレーションとコレオグラフィのバランスを取る必要がある,ということです。これは必ずしも容易ではありません。今回の記事では,可視性に重点を置きたいと思っています。ワークフローエンジンを用いたオーケストレーションには,明らかなメリットがあります。モデルはオーケストレーションを実行するコードだけではなく,フローの可視性においても直接使用することができるのです。まとめビジネスプロセスの可視化は,その実装方法が何であっても不可欠なものです。複数の可能性について議論しましたが,実際のほとんどの状況では,Elasticのようなツールを使って何らかのイベント監視を行うか,ワークフローエンジンを用いてプロセストラッキングを行うかのいずれかです。どちらを選択するかは,ユースケースや関係する役割に多少依存するかも知れません。ビジネスアナリストは,すべてのインスタンスから適切な粒度で収集されたデータを理解する必要がある一方で,運用担当者は,特定のひとつのインスタンスをさまざまな粒度で見る必要があると同時に,システムレベルの障害を迅速に解決可能なツールを用意したいと思うでしょう。コレオグラフィを採用するサイトの場合は,プロセストラッキングによってさらなるオーケストレーションへと向かうことができます。長期的にビジネスプロセスをコントロールし続ける上で,これは非常に重要なステップだと思います。"イベント通知を使って首尾よくシステムを分割できるかも知れませんが,全体的なフローに対する視点を失っていることに気付くことができず,結果として将来的なトラブルの種を蒔くことになる"のです。新規システムを開発しているのであれば,当初からオーケストレーションとコレオグラフィの適切なバランスを見つけておくべきです。システムの実装の詳細とは無関係に、コラボレーションサービスによって実装されたビジネスプロセスには、ビジネスフレエンドリなビューを必ず用意するようにしてください。Ruecker氏はCamundaの共同創設者であり,技術者です。氏は以前、T-Mobile、Lufthansa、Zalandoなどの世界的な企業で,拡張性の高いコアワークフロー自動化を支援する仕事をしていました。現在は分散システムやマイクロサービス、ドメイン駆動型設計、イベント駆動型アーキテクチャ、リアクティブシステムを中心に,現代的なアーキテクチャに適合する新たなワークフロー自動化パラダイムに注目しています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。