既存のシステムをマイクロサービスに移行するのは、新しいシステムを構築するのとは全く異なる。Joris Kuipers氏はプレゼンテーションで、大規模なモノリシックアプリケーションを分散型あるいはマイクロサービスベースのアーキテクチャ向けにリファクタ中であると述べている。
Trifork AmsterdamのアーキテクトであるKuipers氏は、6年前に作成された、ヘルスケアのための電子カルテシステムが、最初の2年間はいくつかの企業間（B2B）インテグレーションのある一枚岩のモノリシックアプリケーションであったと述べている。最初はAxonを使用するCommand Query Responsibility Segregation(CQRS)に基づいて構築された。CQRSはTriforkが開発したオープンソースフレームワークである。それは非常にうまく機能したが、システムと顧客数が増えるにつれて新たな要件が発生した。その1つが保険料についての要件であり、それは別のアプリケーションでなければならないが、現在のアプリケーションからのデータを必要とする。状態を共有する複数アプリケーションに移行する必要があったため、これは大きな変更であった。
現在、コアアプリケーションは依然として比較的大きく、その周りに、保険料のための3つの個別のアプリケーションと、12のデプロイ可能なアプリケーションに実装されている約40のサードパーティ・インテグレーションがある。約65のテナントと12,000人のユーザーを収容している。
多くのインテグレーションは、コアアプリケーションよりもはるかに短いライフサイクルとなるため、マイクロサービスに移行する主な理由は、これらの異なるライフサイクルに応じて開発が対応できる必要があることであった。開発チームの規模を拡大することで開発のペースを高速化できることが、この移行の大きな要因となった。
彼らはリファクタリングを開始するときにCQRSとイベントに基づいたアプリケーションを持っていたので、イベントをインテグレーションのポイントとして使用し、すべてのイベントをメッセージブローカを通じて他の関心を持つアプリケーションにブロードキャストした。彼らは、既存のB2Bのインテグレーション関連のコードをすべて別々のアプリケーションに分離し、それらをブローカに接続した。それによりブローカ経由で発信されたイベントをすべて取得可能となる。分離されたアプリケーションがコアアプリケーションと通信する必要があるとには、コアにすでに存在するCQRSコマンドを使用する。
データフローの典型的な例は、ユーザがコアアプリケーションを使用して一部のデータを変更するときである。この変更によりイベントが公開され、インテグレーションアプリケーションが非同期にそれを読み取り、また、変更にトリガされたロジックに基づいて外部パートナーに通知が送信される。Kuipers氏はこれを、コアアプリケーションをハブに見立て、それを小さなアプリケーションが囲むハブ＆スポークアーキテクチャと見ている。彼は、利用者による、このタイプの分離が、非常にうまく適合するマイクロサービスへの移行方法の1つであると述べている。
Kuipers氏にとっては、イベントは本質的に非同期であるため、システムを分離する際の大きな助けとなる。イベントとは、起こったことを記述し、他のシステムがそれを聞いて、それに対して何等かのアクションを取るものである。彼は、イベントの使用にはいくつかの課題があり、特に、イベントがインテグレーションの中核になるときに検討することが重要であると述べている。
- それらは共有データ構造であるため、連携させるかもしれない
- 一部のイベントは、アプリケーションまたはサービス内でプライベートにする必要があるかもしれない
- イベントハンドラがより多くのデータを要求するのを防ぐために必要なデータの量と型の粒度
- クライアントを妨げることなく時間の経過とともにイベントがどのように進化するか
結論として、Kuipers氏はコアアプリケーションとは独立して新しいインテグレーションを迅速に開発しデプロイできるようになると述べている。また、コアシステムを触らずに済みためリスク軽減になると述べている。Kuipers氏が述べていることは、重要な競争上の優位性となる。
Rate this Article
- Editor Review
- Chief Editor Action