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

2019年6月13日(木)
小林 和正

4月16日、コンテナをはじめとするクラウドネイティブをテーマとしたテックカンファレンス「CloudNative Days Fukuoka 2019」が開催された。本稿では、きりんカルテシステム株式会社のクラウド型無料電子カルテ「カルテZERO」の基盤をMicrosoft Azureに移行する取り組みを紹介したセッションのレポートをお届けする。スピーカーはマイクロソフトコーポレーション グローバル ブラックベルト テクノロジー ソリューション プロフェッショナルの井上 章氏、きりんカルテシステム株式会社のプラットフォーム・スペシャリストの安部 勇輝氏とSREエンジニアの木下 真哉氏。

左からマイクロソフトの井上氏、きりんカルテシステムの安部氏、木下氏

井上氏は約3年に渡るマイクロソフトときりんシステムの協業を振り返った。Azure Database for MySQLの早期導入、Azure Kubernetes Service によるマイクロサービス化などにおいて、技術とアーキテクチャのPoC(概念実証)をマイクロソフトがサポートし、クラウドネイティブに取り組んでいる。

続いて安部氏が同社が提供するサービスの概要、技術選定やアーキテクチャについて紹介した。きりんカルテシステムは医療系のベンチャーで、電子カルテ開発が主な事業内容だ。現在、全国に約10万あるクリニック(一般診療所)では電子カルテの普及率がわずか35%に留まっている。電子カルテの導入が進まない原因は主にコストの問題だという。

紹介先の病院で前の病院と同じ検査を受けたり、医師が患者の履歴を見たくても別病院のカルテで見れないことがあるのだが、全ての一般診療所に導入できる電子カルテがあればこれらの問題は解決できる。さらに、患者が自身のカルテをスマートフォンで参照できれば、健康に対する意識を高める効果も期待できる。このように、電子カルテの導入はクリニックと患者の双方にメリットがあると考えられる。

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

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

左から順にモノリシック、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

エンジニア、ライター。アクセンチュア株式会社 ソリューション・エンジニア。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています