Amazon Web Services ブログ

オープンソースの PACS ソリューション Dicoogle を AWS で実行する (第 1 部)

この記事は、“Running Dicoogle, an open source PACS solution, on AWS (part 1)” を翻訳したものです。

このブログは、AWS で安全な DICOM サーバーをホストする方法を説明する 2 部構成のシリーズの第 1 部です。 PACS (picture archiving and communication system) の機能を提供するオープンソースソフトウェアである Dicoogle を利用します。PACS は、DICOM 医用画像ファイルを保存およびインデックスを作成し、DICOM プロトコルを使用して簡単にDICOM検査のアップロード、ダウンロード、検索が可能です。

第 1 部には、DICOM、DICOM 機能、Dicoogle の追加機能、ネットワーキング、セキュリティに関する簡単な紹介と、ソリューションで使用される AWS サービスの概要が含まれます。

第 2 部には、AWS でのソリューションデプロイの詳細なウォークスルーと、順番に実施するテストが含まれます。

ソリューションのアーキテクチャは、次のコンポーネントで構成されています。

  • DICOM サーバとして、その DICOM クライアントにサービスを提供する Dicoogle。
  • DICOM 画像をマネージドなファイルシステムに格納し、AWS のコンテナ型アプリケーションとしてホスティングされる Dicoogle サーバ。
  • DICOM DIMSE (DICOM message service element) protocol を実装するネットワークサービスの公開と、DICOM 検査のアップロード、ダウンロード、検索などのサービスを提供する Dicoogle サーバー。
  • DIMSE プロトコルに依存しない DICOM ファイルの一括アップロード。AWS のネイティブサービスを利用したファイル転送と Dicoogle サーバーを利用したファイルインデックス作成により動作します。
  • ブラウザと標準的な HTTPS 接続を介した、Dicoogle アプリケーションの管理の実行。
  • TLS トンネルを使用した DICOM DIMSE オペレーションの転送中の暗号化。
  • 標準的な DICOM ノードの例として dcmtk DICOM ソフトウェアを使ってクライアント機能を提供します。通常はユーザーの施設内に配置されます。

DICOM の紹介

DICOM は、患者-検査-シリーズ-インスタンスの順序で構成されたデータモデルです。患者には1つ以上の検査があり、試験または処置と呼ばれることもあります。検査は、同じモダリティ (スキャナーなど) で実行されるシリーズを 1 つ以上もちます。シリーズには 1 つ以上のインスタンスがあり、各インスタンスは 2D 画像または 3D 画像のスライスを表します。各DICOM 画像には、患者、検査、シリーズ、およびインスタンスに関するメタデータ (UID とテキスト記述) を格納するヘッダーセクションが含まれています。辞書に関する詳しい情報はこちらでご覧いただけます。

DICOM ソフトウェアは、ディスクに保存されている個々のファイルの階層を維持し、インデックスを作成する必要があります。このようなインデックス作成機能は、リレーショナルデータベースを使用することで実現できます。Dicoogleの場合、デフォルトの Apache Lucene ベースのインデックス作成機能に加え、リレーショナルデータベースによるインデックス作成機能の利用をサポートするプラグイン・アーキテクチャを備えています。

DICOM には、サービスクラスユーザー (SCU: Service Class User) とサービスクラスプロバイダー (SCP: Service Class Provider) の概念があります。2 つの DICOM ノードは、一方のノードが SCU の役割を果たし、他方のノードが SCP の役割を果たすとき、アソシエーションを形成できます。SCU はオペレーション (画像の転送など) を呼び出し、SCP はオペレーションを実行します。DIMSE は、2 つの DICOM ノード間で画像を転送するための DICOM プロトコルです。

このブログでは、C-FIND、C-STORE、C-MOVE の3つの DIMSE サービスを使用します。それぞれの詳細な定義については、こちらをご覧ください。

C-FIND は検索を実行していると考えてください。レスポンスとして、クエリ条件に一致する画像のリストを取得します。C-STORE が、DICOM クライアントから DICOM サーバーに画像をアップロードし、DICOM サーバーに画像を保存するように依頼していると想像してください。C-MOVE は、DICOM サーバーに画像、シリーズ、または検査を宛先となる DICOM ノードにダウンロードするように依頼する DICOM クライアントと考えてください。C-MOVE の前提条件として、宛先となる DICOM ノードが DICOM サーバーで宛先として設定されている必要があります。

従来の DICOM プロトコルが DIMSE であるのに対し、DICOMweb は Web ベースの医用画像処理用に開発された新しいプロトコルです。DICOMweb は、画像の検索、取得、保存の機能を満たすRESTfulなサービス群をもちます。DICOMWeb は Dicoogle によってサポートされており、開発者は使い慣れた Web ベースのツールを使用して DICOM サーバーと対話することができます。尚、本ブログでは DICOMweb は取り上げません。

DICOM 機能

DICOM クライアントソフトウェア dcmtk を使用して、DIMSE プロトコルで DICOM コマンドを Dicoogle サーバーに送信することができます。クライアントソフトウェアはユーザーのローカルファイルシステム上の DICOM ファイルにアクセスし、そこから 以下の 3 つのことを行うことができます。

  • C-STORE コマンドを使用して Dicoogle サーバーにこれらのファイルを送信する。
  • C-MOVE コマンドを使用して DICOM 画像を取得し、保存する。
  • C-FIND コマンドを使用して Dicoogle データベースを検索する。

Dicoogle サーバーは、ファイルシステムに個々の DICOM ファイルを保存し、インデックス作成機能を使用してファイルとDICOMシリーズ／検査の関連を格納します。DIMSE プロトコルで受信した DICOM 画像は、受信と同時にインデックスが作成され保存されます。

Dicoogle の追加機能

AWS の API 機能により、クライアントのファイルシステムから Dicoogle サーバーのファイルシステムへ DICOM ファイルを一括アップロードすることができます。Dicoogle サーバーは、Dicoogle ファイルシステムに格納された後、ファイルにアクセスする前にインデックスを作成する必要があります。

管理者は、Dicoogle サーバーのウェブサーバーを使って HTTPS で直接操作することができます。DICOM データストアを調べることができるグラフィカルなインターフェイスを使って、ファイルシステム上で直接受信したファイルのインデックスを構築するなどのアクションを制御します。

ここまでで説明した DICOM 機能と追加の Dicoogle 機能を以下の図に示します。

ネットワーク

このソリューションが提供する機能を理解いただいたところで、ソリューションでどのようにネットワークに取り組んでいるか詳しく説明します。

まず、DICOM 機能を実現するソリューションとしてのネットワークを見てみましょう。

あなたが PACS のサービスプロバイダーだと想像してみてください。Dicoogle を DICOM サーバー (プロバイダー) として選択し、サーバーへの制御されたネットワークアクセスを提供するために、AWS の Virtual Private Cloud (VPC) にデプロイします。Dicoogle の Web コンソールにアクセスして管理業務を行うために、サーバーへアクセスします。

あるお客様は、オンプレミス環境から PACS サービスを利用することに興味を持っています。下図のように、お客様のサービスにパブリック IP を割り当て、お客様にサービスを公開し、お客様がパブリックインターネットを通じてお客様のサービスに接続できるようにすることができます。ただし、この方法はセキュリティ上の懸念があるため、お勧めできません。

代わりに、AWS Privatelink を使って Dicoogle を VPC エンドポイントサービスとして公開することで、より安全でプライベートな方法で PACS サービスを顧客に提供できます。お客様は AWS に彼らの VPC をセットアップでき、AWS Direct Connect (DX) または Site to Site VPN を使ってオンプレミスから AWS へ接続することが可能です。そして、お客様は AWS 上の自分の VPC に VPC エンドポイントを作成して Dicoogle と通信できます。

なお、このブログでは、実際のオンプレミス環境を作ったり、DX/VPN を設定したりすることはありません。代わりに、DICOM クライアントをホストするオンプレミス環境をシミュレートするために、AWS 上に別の VPC を作成します。VPC ピアリングを使用して、DICOM クライアントをホストする VPC と VPC エンドポイントをホストする VPC 間の接続を確立します。

ネットワーク接続が確立されると、お客様は DICOM クライアントソフトウェアを使用して、その接続を介して Dicoogle に画像を送信できます。これは基本的に、上記の「DICOM の紹介」で説明した C-STORE の操作を行うものです。お客様は、同じ接続で C-FIND の操作を実行することもできます。

C-MOVE の操作は、DICOM 検査、シリーズ、またはインスタンスをある DICOM ノードから別の DICOM ノードに転送するために使用されます。転送先ノードの IP アドレスが、転送元となるノードで宛先として事前に設定されている必要があります。

C-MOVE は 2 段階の操作です。最初のステップでは、DICOM クライアントノードは、C-MOVE リクエストを転送元のノード (この場合は Dicoogle ) に送信する転送を開始します。これは、要求されたエンティティ (検査、シリーズ、またはインスタンス) と転送先の両方を送信する必要があることを示します。2 番目のステップでは、転送元ノード (Dicoogle) が要求されたエンティティを宛先に送信します。お客様は、上図と同じ接続を使用して C-MOVE の最初のステップを実行することができます。

2番目のステップで、接続を確立する方法を見てみましょう。

転送先の DICOM ノードがお客様のオンプレミス環境にあると仮定すると、転送先の DICOM ノードを指定するために、お客様の VPC に VPC エンドポイントサービスを作成することができます。次に、あなたの VPC に VPC エンドポイントを作成し、C-MOVE の宛先として VPC エンドポイントを使用するように Dicoogle を設定できます。

このブログでは、この逆方向のプライベートリンク接続を設定しません。その代わりに、オンプレミス環境をシミュレートした VPC に転送先の DICOM ノードを配置します。そして、Dicoogle をホストする VPC とオンプレミス環境をシミュレートしたVPC の間に VPC ピアリングを設定します。そして、Dicoogle が転送先 DICOM ノードのプライベート IP を宛先として使用するように設定します。

次に、Dicoogle の追加機能を実現する観点から、ネットワークを見てみましょう。

画像の一括アップロードを行うには、Amazon S3 バケットを作成し、お客様にアクセス権を付与する必要があります。お客様は、VPC 内にインターフェイス VPC エンドポイントを作成し、オンプレミス環境のソースから そのインターフェイス VPC エンドポイントを使用して、S3 バケットに画像をアップロードできます。

このブログでは、VPC を使用してオンプレミス環境をシミュレートするため、下図に示すように、ゲートウェイ VPC エンドポイントを使用して S3 サービスと通信することに注意してください。S3 のインターフェイス VPC エンドポイントとゲートウェイ VPC エンドポイントの詳細については、こちらを参照してください。

AWS までの帯域幅が限られている施設内の画像については、代替アプローチとして AWS Snow ファミリーを使用することを検討してください。

画像がバケットに入ったら、AWS Datasync サービスを使用して S3 バケットから Dicoogle が使用するマネージドなファイルシステムに画像を転送します。その後、Dicoogle にログインしてインデックス作成を実行します。Dicoogle が画像のインデックスを作成すると、お客様は DICOM C-FIND/C-MOVE の操作を実行できます。

VPC で Dicoogle アプリケーションを管理するには、2 つのネットワークセグメント (サブネット) を作成します。1 つはインターネット向けコンポーネント (アプリケーションロードバランサー) 用、もう 1 つはプライベートコンポーネント (Dicoogle アプリケーション、マネージドなファイルシステム) 用です。管理者はアプリケーションロードバランサーに接続し、トラフィックを Dicoogle アプリケーションに向けることできます。

セキュリティ

セキュリティは AWS の最優先事項です。本ソリューションでどのようにセキュリティに取り組んでいるか見てみましょう。

ネットワーク制御: 以下のアーキテクチャ図では、3 つの独立した VPC を作成しています。1つ目は「Simulated OnPrem」で、DICOM クライアントノードと宛先ノードをシミュレートした計算リソースをホストします。2つ目は「Consumer」と呼ばれるもので、VPC のエンドポイントをホストしています。3つ目は「 Provider」 と呼ばれるもので、Dicoogle をホストしています。3 つの VPC では、コンピューティング、マネージドなファイルシステム、VPC エンドポイントリソースにセキュリティグループを設定して、対象となる送信元と宛先との間のトラフィックを制限します。S3 バケットでは、意図したソースからのアクセスのみに制限するポリシーも定義します。

アクセス制御: Dicoogle 管理者の認証には AWS のネイティブサービス (Cognito) を使用します。AWS Identity and access management (IAM) サービスにより、AWS サービス間の認証・認可を行います。

シークレット管理: AWS ネイティブサービス (Secrets Manager) を使用して、SSL 証明書をシークレットとして保存します。

保管時のデータ暗号化: Simple Storage Service (S3) と Elastic File System (EFS) を使用して、AWS のデータストアの保管時の暗号化を有効にします。暗号化/復号キーの管理には AWS のネイティブサービス (KMS) を使用しています。

転送中のデータ暗号化: AWS ネイティブサービス (Certificate Manager) を使用して、インターネットに接続するアプリケーションロードバランサー (ALB: Application Load Balancer) に証明書を発行します。オープンソース版の Dicoogle は、デフォルトでは TLS 機能を提供していません。Dicoogle に TLS 機能を追加するために、nginx とghostunnel という 2 つのオープンソースツールを追加で使用しています。同様に、DICOM クライアントソフトウェアにTLS機能が必要な場合 (例えば、dcmtk のdcmsend ) には、ghostunnel を使用して TLS 機能を追加しています。

セキュアなDICOMサーバーをAWSでホスティングするために使用するAWSサービス

このソリューションは、次の AWS サービスに基づいて構築されています。

  • Amazon Virtual Private Cloud (Amazon VPC): サービスプロバイダーとコンシューマーにネットワークの分離を提供します。
  • Elastic Load Balancing (ELB): 本ソリューションでは、アプリケーションロードバランサー (ALB) とネットワークロードバランサー (NLB) の 2 種類の ELB で構成されます。ALB は、管理ユーザートラフィックを Dicoogle アプリケーションに振り分けます。NLB は、インターフェイス VPC エンドポイントを介して、VPC エンドポイントサービスとして公開されている Dicoogle アプリケーションに DIMSE トラフィックを分散します。
  • Amazon Cognito: ALB と統合して、Dicoogle 管理者を認証するための ID 管理を提供します
  • Amazon Elastic Compute Cloud (EC2): コンピュートインスタンスとして機能します。このソリューションでは 2 つの EC2 インスタンスを使用します。1 つ目 (クライアント EC2) は、C-FIND、C-STORE、および C-MOVE リクエストを開始する DICOM クライアントノードをシミュレートすることです。2 つ目 (ストレージ EC2) は、要求されたエンティティを C-MOVE 送信先として受け取る DICOM 送信先ノードをシミュレートすることです。
  • AWS Fargate: Dicoogle、 Nginx、および Ghostunnel を実行するDockerコンテナをホストします。このソリューションでは、1つの Nginx コンテナをリバースおよびTLS終端プロキシとして使用し、ALB と Fargate 間のトラフィックの転送中の暗号化を行います。このソリューションでは、2 つの Ghostunnel コンテナを使用します。1つ目はリバースプロキシおよび TLS 終端プロキシとして実行され、クライアント EC2 インスタンスから Fargate に画像をアップロードする際の転送中の暗号化を容易にします。2 つ目はフォワードプロキシとして実行され、Fargate からストレージ EC2 インスタンスに画像を転送するための転送中の暗号化を行います。
  • Amazon Elastic Container Registry (ECR): Docker イメージをホストするリポジトリを提供します
  • Amazon Elastic File System (EFS): Dicoogle アプリケーションで使用される Dicoogle 設定、画像、およびインデックスのファイルシステムとして機能します
  • Amazon Simple Storage Service (S3): 2 つの S3 バケットを使用します。1 つは DICOM 画像の一括アップロードを受信する中間ストアとして機能し、2 つ目は ELB アクセスログと VPC フローログを保存します。
  • AWS DataSync: 画像ファイルを S3 から EFS に転送します
  • Amazon Route53: ホストゾーンで DNS レコードをホストし、DNS 解決を実行します
  • Amazon Cloudwatch: ソリューションで使用されるサービスと統合し、メトリクスとログを管理します
  • AWS Certificate Manager (ACM): ALB が使用する証明書を発行します
  • AWS Key Management Service (KMS): 暗号化/復号に使用されるキーを管理します
  • AWS Secrets Manager: シークレットとして保存された SSL 証明書を管理します
  • AWS Identity and Access Management (IAM): ソリューションで使用されるサービスのIDおよびアクセス制御を提供します。

さらに、以下の補助的な AWS サービスにより、ソリューションのデプロイが容易になります。

  • AWS Cloud9: デプロイする成果物を準備する IDE として機能
  • AWS CloudFormation: ソリューションのデプロイをオーケストレーションします
  • AWS Lambda: Cloudformation スタックの作成中にカスタムリソースとして機能し、S3 に関連付けられたプレフィックスリストを取得します

以下がアーキテクチャ図です。

まとめ

この投稿では、DICOM、DICOM 機能、および本ソリューションが提供する Dicoogle の追加機能について簡単に紹介することから始めました。次に、このソリューションで考慮すべきネットワークとセキュリティの設計について説明しました。最後に、このソリューションで使用されている AWS サービスとそれぞれの機能、そしてアーキテクチャ図について説明しました。

このブログシリーズの第 2 部では、AWS 上にソリューションをデプロイし、DICOM および Dicoogle の機能を実現する方法を実証するテストに必要な手順を詳しく説明します。

翻訳は Solutions Architect 今井と窪田が担当しました。原文はこちらです。