Azure+クラウド型電子カルテにおけるリソース利用効率の課題と改善への道すじ

電子カルテシステムのアーキテクチャ

ここからシステムの具体的なアーキテクチャをみていこう。

左から順にモノリシック、N階層アーキテクチャ、マイクロサービス、サーバレスと粒度が小さくなる。同社の電子カルテシステムは左から2番目のN階層アーキテクチャで設計されており、規模が大きくなるに従ってサーバ台数の増加は避けられず、各サーバ間でリソース使用率に差が生じていた。この差を均一化するために、バックエンドにあたるレセプトコンピュータ（診療報酬明細書を作成するソフトウェア、以降レセコン）をコンテナ化して集約し、負荷を分散することにチャレンジしている。ソースコードをなるべく変更せず移行するため、サーバレスではなく、コンテナを選択したとのこと。

同社が利用しているAzureサービス群の中で、コンテナ化のキーとなるのはAzure Kubernetes Service （以降、AKS）とAzure Container Instances（以降、ACI）の2つ。AKSは容易にコンテナのデプロイとスケーリングを実現する。ACIは単独のコンテナを必要なタイミングでインスタンスとして利用できる。Virtual Kubeletを使用することで、AKSの一部としてACIを利用することも可能だ。

サービス開始当初はマスターイメージを作成してVMにコピーし、手作業でソフトウェアを展開していた。作業漏れが発生しないように資料を作り、チェックシートをつけていたが、資料がすぐに陳腐化してしまうという課題を抱えていた。

Azureへの移行でシステム構成が大きく変わり、Azure Database for MySQLやAzure Virtual Machine Scale Setsなどマネージドサービスが随所に導入されていることがわかる。これにより、DBのバックアップ運用が不要になったり、DBの動的なスケールアップ、負荷に応じた電子カルテAPIのサーバ台数増減などを実現している。肝となるレセコンのコンテナ化は赤枠で囲われた部分で、Azure Container RegistryからAzure PipelinesでAKSにビルド、デプロイしている。

アーキテクチャ選定のポイントはクラウドネイティブ化とコンテナ化。クラウドネイティブ化は、大規模なスケーリングに加えてOSやDB運用の工数を削減でき、障害対応やバージョンアップなどインフラ固有のスキルが必要な作業をクラウド事業者にアウトソーシングして開発者主体で運用できるのがメリットだ。コンテナ化は、開発者環境でコンテナを利用していたことから、結合テストやステージング、本番環境にも採用してデプロイの品質を向上させ、ミドルウェアやライブラリなどのメジャーバージョンアップを低リスクで円滑に実施できる。

AKSを利用したレセコンのコンテナ運用

続いて、AKSを利用したレセコン（ORCA）のコンテナ運用について木下氏が解説した。コンテナ運用の必須要件は次の3つ。AKSのクラスタ内のノード1台で20台程度のORCAコンテナが稼働できること。コンテナの起動や破棄を繰り返しても、ORCAのデータが消失しないこと。セキュリティを高めるため、VPN経由でレセコンに接続できること。

アーキテクチャは仮想ネットワークをレセコン（ORCA）コンテナ用と管理用にサブネットで分けたものを目指している。コンテナ用のサブネットが前段で紹介した必須要件を満たせるか、検証を行なっている。システムを構築する技術的な要素とAKSのリソースは以下の通り。

技術的な要素

Ansible：オープンソースの構成管理ツール。ORCAのコンテナイメージをビルドする際に行われるミドルウェアのインストール・設定に使用
Packer：オープンソースのサーバイメージ作成ツール。ORCAのコンテナイメージを作成する際に使用
Azure CLI：Azureリソースを管理するためのコマンドラインツール。Azureリソース（リソースグループ、仮想ネットワーク、コンテナレジストリ、AKS）を作成する際に使用
Kubernetes：オープンソースのコンテナオーケストレーションシステム。コンテナ化したORCAのデプロイや管理に使用
Helm：オープンソースのKubernetes用パッケージ管理システム。Kubernetes上に特定のリソースをインストールするために使用

Kubernetes（AKS）のリソース

Persistent Volume（pv）：永続化ボリュームを提供するオブジェクト。ORCAで使用しているPostgreSQLのデータストレージとして使用
Persistent Volume Claim（pvc）：永続化ボリュームを利用要求するためのオブジェクト。Pod作成時に永続化ボリュームをORCAコンテナに割り当てる際に使用
Storage Class（sc）：ストレージの種類を示すオブジェクト。Azure Fileを永続化ボリューム
Pod（pod）：Kubernetesにデプロイできるリソースの最小単位となるオブジェクト。ORCAコンテナを稼働させるために使用
Replica Set（rs）：指定されたPodの稼働を保証するためのオブジェクト。ORCAコンテナを含んだPodが常に1つ稼働している状態にして信頼性を向上するために使用
Deployment（deploy）：Replica SetをKubernetesにデプロイする際の制御を行うオブジェクト
Service（svc）：コンテナを外部に公開するためのエンドポイント（IPアドレス）を提供するオブジェクト
Ingress（ing）：HTTP/HTTPSベースでコンテナを外部に公開するためのエンドポイント（FQDN）を提供するオブジェクト。レセコン（ORCA）のクライアントからサーバに接続する際に使用

今回使用するORCAというレセコンはクライアントサーバシステムで、主な仕様はOSがUbuntu 16.04 LTS、データベースはPostgureSQL 9.5となっている。Ubuntuのパッケージ管理システム（apt）からORCAをインストールする際に、PostgureSQLも同時にインストールされる。永続化が必要なデータストアはマネージドサービスに配置するのが一般的だが、短期間でレセコンのコンテナ運用を実現するため、通常の導入に近い構成、すなわち1コンテナにORCAのプログラムとPostgureSQLをインストールした状態で運用する方針をとっている。

Dockerのコンテナイメージ作成といえばDokerfileが定石だが、レセコンのコンテナイメージはPackerとAnsibleで作成している。同社ではDevOpsを推進していて、その取り組みの1つとしてインフラ構築のコード化を進めている。既にレセコンを構築するAnsibleの定義ファイルがあり、これを有効活用するためにPackerとAnsibleを採用したというわけだ。

続いて、アーキテクチャの検証が3ステップで紹介された。ステップ1はグローバルIPアドレスでレセコンのクライアントからサーバへの接続。外部ロードバランサー型のServiceを導入し、レセコンのコンテナが消失したり再生成しても既存のデータが消えないようにPersitent Volumeを導入している。

ステップ2はプライベートIPアドレスでVPN経由でレセコンのクライアントからサーバへの接続。内部ロードバランサー型のServiceを導入し、レセコン内のデータ担保は前段と同様にPersistent Volumeを導入している。

ステップ3はFully Qualified Domain Name（FQDN）を使用してVPN経由でレセコンのクライアントからサーバへの接続。構成はステップ2とほとんど同じだが、FQDNでレセコンのコンテナに接続するためにIngressを導入している。Ingressを使用するためにIngress Controllerが必要なので、HelmでNginx Ingress Controllerをインストールしている。

データの永続化を実現するためのデータストレージ選定は、直接ノードに接続するAzure Managed DiskとSMBプロトコルで接続するAzure Filesの検証を行った。結果はAzure Managed Diskはコンテナ起動できたが、Azure FilesはPostgreSQLが起動できなかったため、コンテナ起動できなかった。

最後に安部氏が今回の取り組みについてまとめた。現在はアーキテクチャ選定や技術検証が進んできて、これから本番に寄せていくところだが、実際にコンテナを使ってみて手応えを感じているという。レガシーなシステムをAzureに移行することは困難ではないので、データの永続化など引っかかりそうなポイントは今回の内容を参考にチャレンジしてほしいと述べ、セッションを締めくくった。

写真提供: https://photos.app.goo.gl/ZkLVWEy67HYPc43J7

講演資料とアーカイブ動画

Azure ＋クラウド型電子カルテにおける、リソース利用効率の課題と改善への道すじ