マイクロサービスで医療における IT 統合をサポート

マイクロサービスを使用すると、医療やその他の業界の開発者は、疎結合のサービスから作られるアプリケーションを構築でき、開発、テスト、デプロイ、アップグレードを容易に行えます。これらのメリットにより、医療業界の開発者は前世代の IT 統合テクノロジーであるエンタープライズ・サービス・バス (ESB) よりも、マイクロサービスを採用するようになりました。

ESB の登場以来、アプリケーション開発は大幅に進化しました。最も重要な変化の 1 つは、アジャイル開発と DevOps への移行であり、これにより ESB は過去のテクノロジーとなりました。

DevOps パイプラインは、段階的な変更と継続的な自動テストに基づく開発ライフサイクルです。DevOps の時代において、かつて ESB が普及した要因であった特性はむしろ妨げになっています。ESB では、すべての統合が 1 つのモノリスにデプロイされます。これには以前は利点がありましたが、今では ESB が DevOps と両立できない要因であり、問題になっています。

先進的な開発環境において、ESB には次の制限があります。

• アジャイル開発者および DevOps ツールとの非互換性：現在、新卒の開発者の多くは DevOps 環境で教育を受けています。そのようなアジャイル開発者は、市販されている最新の DevOps ソリューションで使い慣れたツールを使用すると最高の生産性を発揮しますが、ESB はこれらのツールをサポートできる設計ではありません。
• 変更がシステム全体に影響：ESB のルールに変更を加える必要がある場合、たとえ小さな変更であっても、エンジン全体を一時停止する必要があります。つまり、ESB とやり取りするすべてのアプリケーションにおいて、破壊的かつ非生産的なダウンタイムが発生します。同様に、変更によって発生したエラーは、すべての統合に影響を与える可能性があります。その結果、チームはアップグレードや修正の適用を嫌がるなど、反生産的なメンタリティを持つようになってしまいます。
• 単一障害点：すべての統合が同じハブを介してルーティングされるため、ESB はエンタープライズ全体の単一障害点になります。ESB がダウンすると、すべての統合がダウンします。
• テストを自動化できない：テストの自動化は DevOps の重要な要素です。DevOps パイプラインでは、すべての更新が個別にテストされるため、開発プロセスが中断されることはありません。これは自動化によって可能になります。しかし、ESB では、プロプライエタリーの GUI とバージョン管理により、自動化が不可能です。

医療は、他の業界と同様に、マイクロサービス、DevOps、アジャイルといった新しい開発手法を採用しています。これは、医療の統合にも拡大しています。新しいアプリケーションとデジタルタッチポイントには、HL7、REST、その他のプロトコルへの統合が必要です。医療業界のマイクロサービス開発者は、彼らが開発する他のコード (データ、ストリーミング、GUI、コマンドアンドコントロールなど) とともに統合を制御し、CICD を通過するデプロイ可能なユニットにすべての変更をパッケージ化したいと考えています。上記の制限が、他のコードとの統合コードに関する CICD のこの目標の妨げになっています。

マイクロサービスは開発の未来であり、ESB とは全く両立できません。ESB はモノリシックですが、マイクロサービスはその逆で、開発者は疎結合サービスの構成要素を使用してアプリケーションと統合を構築できます。アプリケーションを独立したモジュールに分割することで、開発、テスト、変更、再テスト、修正、デプロイ、本番環境でのテスト、アップグレードなどが容易になります。

マイクロサービスではテストの自動化が可能なので、DevOps が可能になります。マイクロサービスは小さなコンポーネントなので、コンテナに簡単に収まり、テストプロセスを自動化して、継続的インテグレーションと継続的デリバリー (CI/CD) を促進できます。一方、モノリシックな ESB は大きすぎてコンテナに収まらず、コンポーネントに分割できないため、同じ方法でテストすることはできません。

しかし、マイクロサービスベースの統合を導入する最も重要な理由は、アジャイル開発者をサポートし、彼らが好む DevOps ツールを使用できるようにすることかもしれません。諸要素から ESB を取り除くことにより、開発者は、彼らが精通しているだけでなく、使用したいと考えるアジャイル開発環境で作業できるようになります。ESB がなければ、開発者はプロプライエタリー・システムに関するトレーニングを受ける必要がなく、より生産的な開発アプローチの方に専念できます。

さらに、ESB による統合はスペシャリストのチームにしか行えませんが、マイクロサービスであれば開発者が自分たちの統合のニーズを詳しく検討できるようになるため、統合が民主化されます。アプリケーション開発者以上にアプリケーションのデータ要件を理解している人はいないので、これはより理にかなっています。

マイクロサービスは API 管理もサポートしているため、必要に応じて API ベースの統合が可能です。

一方、マイクロサービスベースの統合には、グラフィカルな変換や、エンタープライズ内でのデータの流れに関する高度なルールを作成するロジックなど、ESB から得られるのと同じ利点があります。たとえば、ESB のグラフィカルな開発キャンバスが気に入っている場合は、マイクロサービスベースの統合をサポートする同様のキャンバスを見つけることができます。

マイクロサービスベースの統合は、最終的に次のようなメリットをもたらします。

包括的な監視と管理：マイクロサービスは、アジャイル開発者が好む最先端のツール (たとえば、Kibana、Elasticsearch、Grafana、Prometheus など) で監視を行い、障害点を特定できるため、ビジネスへの影響が生じる前に問題を解決できます。

テストの自動化：マイクロサービスと DevOps の最大の利点の 1 つは、テストを自動化できることです。各統合は、テストプロセスを通過する際に独立したコンポーネントとして扱われ、アプリケーションの他のコンポーネントや他のアプリケーションを中断することはありません。

優れたソフトウェア品質：プロセスの効率化とテスト結果の改善により、最終的に、ソフトウェアの品質が向上します。

開発の加速：DevOps と自動化で統合開発プロセスを効率化し、以前は手動で行っていたプロセスを排除することで、開発ライフサイクルを加速できます。

スケーラビリティの向上：アプリケーションは独立したモジュールで構成されているため、アプリケーションの他の部分に影響を与えることなく、各サービスを個別にスケールアップできます。

高度なイノベーション：マイクロサービスと DevOps を組み合わせることで、開発者は統合ソリューションを革新できるようになり、組織は新しいサービスを導入して、顧客により良いサービスを提供できるようになります。

ビジネスアジリティ：アジャイル開発は当然、ビジネスアジリティ、つまり市場の変化に迅速に対応する能力につながります。たとえば、アジャイル開発チームがマイクロサービスを活用してビジネス上の関係をサポートするために必要な統合を迅速に構築するので、データ共有を必要とする新しいパートナーやベンダーの迅速なオンボーディングが可能になります。

カスタマーエクスペリエンスの向上：医療組織の基本的な目標は顧客、つまり、毎日医療サービスを利用している患者にサービスを提供することです。プロセスを改善し、システムと部門間でデータをシームレスに共有することにより、最終的に満足度の高いペイシェント・エクスペリエンス (患者の医療体験) を提供できます。

統合をマイクロサービスに移行するのは、気が遠くなるほど膨大な作業だと思うかもしれません。なぜそのような変更が必要なのでしょうか。結局のところ、チームはすでに、組織が長年利用してきた ESB のプロプライエタリーな要素に精通しています。しかし、そこに問題があります。ESB の担当者のうちの 1 人、あるいは 2 人が組織を離れたら、どうなるでしょうか。そのレベルのスキルを回復するには何が必要でしょうか。

このモノリシックな ESB から移行するのは非常に面倒なことのように思えますが、まさにそれこそが移行すべき理由です。ESB による制限から解放されると、まったく新しい統合の世界が持つメリットを享受できます。