【クラウドネイティブ会議】オンプレミス中心の病院システムのクラウド化のため、複雑系に挑むk3s、Helm、OpenTelemetryの実践

「クラウドネイティブ会議」に、株式会社ispec取締役CTOの山田佑亮氏が登壇した。セッションのテーマは「クラウドネイティブ技術を総動員してオンプレミス中心の病院システムのクラウド化を推進する挑戦」である。医療業界では、患者データを慎重に扱う必要性や、システム停止が人の健康や生命に関わり得る事情から、現在もオンプレミス中心の構成が多い。山田氏は、こうした環境にクラウドを段階的に取り入れる「CloudSail」の仕組みと、複雑なドメインで技術を選ぶ際の考え方を紹介した。

SailCubeを橋渡しに院内とクラウドをつなぐ

ispecは「医療DXを加速させる」を掲げ、医療機関と医療システムベンダーに向けて、病院システムのクラウド化を支える基盤「CloudSail」を開発・提供している。「他の業界ではクラウドをベースにシステムを簡単に連携できますが、医療業界では、どうしても閉じた世界の中でシステムが動いているのが現状です」と山田氏は語る。

CloudSailでは小型サーバー「SailCube」を医療機関内に設置し、その上でコンテナアプリケーションを動かす。既存のオンプレミス環境を一度にクラウドへ置き換えるのではなく、院内ネットワークを維持しながら、段階的にクラウドサービスを利用できるようにする仕組みである。

CloudSailが提供する仕組みの一つが「Sail Bridge」だ。病院では、電子カルテ端末がインターネットへ接続できない電子カルテネットワーク内に置かれている場合が多い。クラウドサービスを利用するには、インターネットへ接続できる別の情報系端末を使う必要があり、ネットワーク間でコピー＆ペーストもできない。そのため、生成AIなどを導入しても、電子カルテの情報を使った業務効率化につなげにくい。

Sail Bridgeでは、電子カルテネットワークと情報系ネットワークをSailCubeへ接続し、その上でリバースプロキシを動かす。通信を中継することで、電子カルテ端末からクラウドサービスへアクセスできるようにする。

Sail Bridge：ネットワークを中継しクラウドサービスにアクセス

さらにCloudSailの次の展開として開発を進めているのが「Sail Engine」である。医療システムでは、電子カルテや調剤システムなど、院内の複数システムとの連携が求められる。クラウドサービスを導入する場合にも、院内のオンプレミスシステムと接続するため、ベンダーが病院内に専用の端末やサーバーを設置し、連携アプリケーションを運用することがある。

Sail Engineでは、クラウドベンダーがSailCube上へコンテナアプリケーションをデプロイできる環境を提供する。講演時点では顧客への提供前で、山田氏はその構想を「病院版ECS」と表現した。「クラウドベンダーが院内のサーバーまで面倒を見るのではなく、クラウド側の開発に集中できる環境を作りたいと考えています」と山田氏は語った。

開発途上の製品を複雑系として探索する

CloudSailは、すでに完成した製品を多数の病院へ展開する段階にあったわけではない。ispecは自社プロダクトとしてCloudSailを立ち上げ、開発を進めながら、並行して医療機関への導入にも取り組んでいた。

しかも病院向けのプロダクトを提供した経験はなく、院内にどのようなネットワークや運用上の制約があるのかも、導入前には十分にわかっていなかった。同様の事業を手掛ける先行企業も見当たらず、製品、技術、事業のいずれについても手探りで進める必要があった。

「病院さんに対してプロダクトをまだ提供したこともなく、院内でどういう制約があるのかもわかりませんでした。同じようなビジネスをしている会社もなかったので、本当に手探りでやるしかない状況でした」と山田氏は振り返った。

そこで山田氏が示したのが、意思決定を支援する「クネビン・フレームワーク」である。同フレームワークでは、置かれた状況を単純系、煩雑系、複雑系、混沌系などに分類し、それぞれ異なる行動を取る。

意思決定を支援するクネビン・フレームワーク

山田氏は、CloudSailの事業環境を「複雑系」に位置付けた。複雑系とは、何を知らないのかさえ十分にわかっていない「未知の未知」の領域である。病院内の制約や運用上の課題だけでなく、開発中のCloudSailにどのような機能や仕組みが必要になるのかについても、最初から正解を導き出すことはできなかった。

複雑系で求められるプロセスは「探索」「検知」「対応」である。まず安全な実験を行い、その結果を観察する。そこから関連事項やパターンを検知し、得られた情報に基づいて次の対応を決める。「最初から正解がわからない中で、いきなり大きな技術を導入したり、思い切った意思決定をしたりすることは、複雑系ではアンチパターンになり得ます」と山田氏は指摘した。

CloudSailでは、医療機関への導入を進める過程そのものを探索と捉えた。初期段階からすべてを自動化するのではなく、手作業も受け入れる。実際の導入作業を通じて課題を可視化し、並行して利用できる技術や解決策を調査した上で、自動化の対象と採用技術を判断したのである。

つまり、技術を先に選んで現場の課題へ当てはめたのではない。CloudSailを開発し、病院へ導入する中で課題を探索し、その解決策も並行して探しながら、段階的にアーキテクチャを固めていった。この考え方が、後に紹介されたk3s、Helm、OpenTelemetryの選定にもつながっている。

手作業で課題を探りk3sとHelmへ移行

CloudSailでは、リバースプロキシに加え、SailCubeの死活状態やネットワーク接続を確認する管理用エージェントなど、複数のアプリケーションを動かす必要があった。さらにSail Engineでは、外部ベンダーのコンテナアプリケーションも安全にデプロイできなければならない。

コンテナオーケストレーション基盤には、軽量なKubernetesディストリビューションである「k3s」を採用した。病院内のネットワークでは、クラウドから院内へのインバウンド通信を自由に許可できるとは限らない。そこで、クラウド側からSailCubeを直接操作する経路を増やすのではなく、k3s上のコンテナアプリケーションからクラウドのAPIを呼び出す方向へ通信を統一した。「AWSから院内へのアクセス経路を極力減らし、k3s上のコンテナアプリケーションがクラウドのAPIをたたく形に、通信の方向を統一しました」と山田氏は説明した。

ただし、当初からデプロイを完全に自動化したわけではない。1つめの病院へのリリースの際にはエンジニアがすべて手作業で行い、作業上の負荷や問題を可視化した。同時に、Argo CDなどの技術調査やSail Engineのプロトタイピングを進め、課題だけでなく解決策についても探索した。

その結果、課題はアプリケーションの配布だけでなく、病院ごとに異なる設定値の管理にもあることがわかった。そこで採用したのが、Kubernetes向けパッケージ管理ツール「Helm」である。共通する構成をHelm Chartとして管理し、ネットワークや接続先など病院ごとの差分をValuesとして分離する。これにより、共通部分を維持しながら、医療機関ごとの設定を管理できるようになった。「最初は手動でデプロイしながら、何が大変なのかを探りました。その上で、Helm Chartによる管理へ移行しています」と山田氏は振り返った。

Helmを中心に院内へのコンテナアプリのリリース基盤を実装

OpenTelemetryで検知と選択の余地を確保

もう一つの重要な技術領域が、オブザーバビリティである。CloudSailでは、複数の医療機関へSailCubeを配布し、それぞれを遠隔から管理する。導入先が増えるほど、個々のサーバーやアプリケーションの状態を把握する難易度も高まる。「オブザーバビリティは、探索と検知の中でも、特に検知を支える重要なピースです」山田氏はこの点を強調した。

CloudSailでは、テレメトリーデータを収集する基盤としてOpenTelemetryを採用した。SailCube上のLocal Collectorがアプリケーションやサーバーのテレメトリーを収集し、AWS上のGateway Collectorへ送信する。Gateway Collectorは、複数の医療機関から受け取ったデータをHoneycombへ転送する。

Local CollectorからHoneycombへ直接送信せず、間にGateway Collectorを置くことで、SailCubeと特定製品との結び付きを弱めた。送信先を変更する場合にも、医療機関ごとのSailCubeではなく、Gateway側の設定変更で対応しやすくなる。

山田氏がOpenTelemetryを評価した理由は、特定ベンダーに依存しない仕組みを先に整えることで、最終的な製品選定を後ろ倒しにできる点にある。「ベンダー中立の技術を先に入れておけば、開発を止めずに、ツールの選定を後からゆっくり考えられます。意思決定を遅らせることで、探索に使える時間を長くできます」と山田氏は語った。

講演の最後に山田氏は、複雑さに立ち向かうクラウドネイティブ技術の思想を整理した。複雑系の意思決定で重要なのは、探索と検知である。

オブザーバビリティ・パイプラインの全体像

探索のためには、初手から技術を導入せず、最初は手作業も受け入れ、課題と解決策の両面を調べる。一方、検知のためには、システムで何が起きているのかを把握するオブザーバビリティ基盤へ投資しておく必要がある。

またOpenTelemetryのようなベンダー中立の技術は、特定製品を選ぶ意思決定を遅らせ、探索の時間を最大化する。

クラウドネイティブは、コンテナやKubernetesを利用するためだけの技術ではない。未知の要素が多い複雑なドメインにおいて、変更可能性を残しながら学習を続け、アーキテクチャや技術選定の意思決定を支える思想でもある。CloudSailの取り組みは、その思想を病院とクラウドのハイブリッド環境へ適用した事例といえる。