Amazon Web Services ブログ

Amazon FSx for NetApp ONTAP を使用して電子健康記録を大規模に最適化する

このブログは 2023 年 11 月 7 日に Randy Seamans (Principal Storage Specialist and advocate for AWS) によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

電子健康記録 (EHR) アプリケーションの市場規模は、高い年間成長率で 400 億ドル規模に近づきつつあります。EHR の利用者は、革新的な医療の実現に引き続き注力しながら、運用上の負担、管理オーバーヘッド、資本支出、総所有コストを削減するクラウドベースのアプローチを採用することで恩恵を受けることができます。EHR の導入は本質的に複雑で、相互接続された多数のアプリケーションと周辺環境で構成されており、それぞれに独自のストレージとパフォーマンス要件があります。EHR の中核にある本番環境データベースのパフォーマンスは、オンプレミスでもクラウドでも制約要因になる可能性があります。ほとんどの場合、本番環境データベースのストレージ環境は、現在の要件だけでなく、3 ~ 5 年の成長も考慮して構築されています。

Amazon FSx for NetApp ONTAP (FSx for ONTAP)Amazon Elastic Block Store (EBS) は、医療機関がクラウド導入の過程で直面するあらゆる EHR のストレージ要件に対応できます。

このブログでは、EHR 環境が、使用したパフォーマンスに対してのみ料金を支払いながら、ストレージパフォーマンスを弾力的かつエレガントに、中断なく最適に拡張する方法を学ぶことができます。これにより、医療機関は予測不可能な成長期でもストレージコストを管理できます。まず、ランサムウェアや災害が発生した場合に EHR 環境のクラウドベースの読み取り専用コピーを拡張できる FSx for ONTAP のアーキテクチャについて説明します。次に、可用性が高く災害復旧が可能なクラウドベースの EHR 本番環境について、オンデマンドで拡張可能な FSx for ONTAP のアーキテクチャーを見ていきます。

規模拡大の機会

患者の負荷が増大し医療機関が業務を統合するにつれて、これらのワークロードを処理するためのコンピューティング、ネットワーク、ストレージのパフォーマンスに対する需要も高まります。これに応えて、AWS は最近、高度な新しい AWS インスタンスと EBS io2 Block Express を活用して、Epic のパフォーマンスの拡張性を向上させることを発表しました。これは、医療機関が現在導入している EHR 環境の大部分には十分すぎるほどのものです。ただし、医療機関は、合併、買収、または前例のない成長により、計画外の成長を経験することがよくあります。この課題に対処するために、本ブログでは、ストレージコストを制御しながら EHR ストレージ環境を拡張する最適な方法について説明します。

昨年、ストレージブログで、従来のブロックベースのデータベースワークロードを拡張する並列ストレージとしての FSx for ONTAP アーキテクチャを紹介しました。本日はこれと同じアプローチを使用して、EHR 関連のストレージパフォーマンスを前例のないレベルにまで高める方法について説明します。実際に、ブログの公開とより高速で新しい Amazon EC2 インスタンスの導入以降、現在では 1 台のサーバーで最大 200 万 IOPS (8K ランダム、サブミリ秒) を実現しています。

ただし、何度も実行できるような基礎的で継続性のあるストレージベンチマークパフォーマンスと、アプリケーション層のストレージパフォーマンスメトリクスを混同しないように注意する必要があります。多くの高度に統合されたアプリケーションがそうであるように、デプロイした EHR アプリケーションが、全体的なアプリケーションパフォーマンスへの影響を左右しない状態で動いていれば、それはストレージパフォーマンスのほんの一部しか利用していないことになります。実際の経験では、この要素は 40 ~ 60% の範囲になる可能性があります。つまり、8K で 200 万 IOPS 実行可能なストレージ環境では、アプリケーションスタック全体からデータベースの本番環境コピーまで含めると、約 100 万 IOPS がそのアプリケーションに対する事実上の実行可能な範囲になる可能性があります。もちろん、その他に関連ワークフローが存在すれば、AWS ストレージ層によって提供される残りのストレージパフォーマンスの余剰分を有効に活用できます。

このことから、ストレージの拡張性が非常に要求されることがわかります。オンプレミスに設置された固定的なストレージ資産とは異なり、クラウドデプロイメントでは、要求するパフォーマンスレベルに対してのみ支払えば良く、前払い資本コストはありません。運用変更や中断もなく、ストレージパフォーマンスを 10 倍以上にすることができます。この拡張性により、組織は現在および将来の EHR 本番環境のストレージ要件を経済的に満たすことができるという確信が得られます。組織は、時間の経過とともにストレージパフォーマンスをゆっくりと拡張することも、災害時にパイロットライトレベルから完全な本番環境ワークロードに数分以内に拡張することもできます。最後に、ストレージのパフォーマンスをほぼリアルタイムで増減できるため、買収・合併やランサムウェアのような不可抗力の事態にも対応できます。

スケーラブルな EHR のストレージ環境に向けて

従来、ほとんどのアプリケーションでは垂直のストレージサイロが好まれていたため、アレイベースのスナップショットを使用して特定の時点でのストレージ IO の一貫性を確保していました。複数のストレージアレイ間の一貫性はサポートされていませんでした。ワークロードまたは環境全体が単一のアレイに収まらない場合、アプリケーション層またはミドルウェア層は、スナップショットとバックアップのために複数のアレイにわたって一貫性のあるタイミングを調整する必要がありました。この問題は、より現代的な並列ストレージアプローチを採用する上で、長い間障壁となっていました。ONTAP バージョン 9.1.1 以降、FSx for ONTAP は、クラスター間 (2 フェーズ) の整合性グループをサポートしています。この問題を解決することで、ストレージの一貫性を確保しながら、ONTAP の複数のインスタンスにわたってアプリケーションを拡張できるようになりました。これにより、一貫性、瞬時で容量効率の高いクローン、レプリケーション、およびその他の多くの ONTAP 機能を維持しながら、スケーラビリティを大幅に向上させ、次の図に示すように、250 万を超える 8K ランダム IOPS と 64 GB/秒を達成できます。

Scaled, IO consistent aggregate performance

図 1: IO の一貫性を確保しながら総合パフォーマンスをスケール

EHR の本番環境データベースやその他の周辺環境で 250 万 IOPS が必要ない場合は、16 個の FSx for ONTAP サービスのスループットと IOPS をそれぞれ低いレベルに設定できますので、コストを大幅に削減できます。各 FSx for ONTAP の IOPS は、デフォルトで SSD ストレージ 1 GB あたり 3 IOPS ですが、容量に関係なく最大 160,000 IOPS をプロビジョニングすることもできます。各 FSx for ONTAP の DRAM キャッシュに存在するデータでは、読み取り IOPS のレベルがさらに高くなります。また、IOPS は動的に上下に変更できます。同様に、各 FSx for ONTAP のスループットは 128 MB/秒から 4 GB/秒まで動的に設定できます。プロビジョニングするパフォーマンスの量によってコストを制御できます。特定の総合パフォーマンスと容量レベルでは、複数の FSx for ONTAP を利用しても追加料金は発生せず、コストのペナルティなしで極めて高いスケーラビリティを享受できます。このコストモデルは、並列化によってコスト上の利点が得られないオンプレミス環境とは大きく異なります。

パフォーマンス設定の動的な特性について説明したので、2 種類の EHR デプロイメントの例に戻り、パフォーマンスを拡張しながらコストを最適化する方法を説明します。

クラウドベースの EHR 読み取り専用コピー

オンプレミスで EHR を運用している組織が災害、悪意のある人物、またはランサムウェアのために追加の保護を必要とする場合、クラウドベースの EHR 資産の読み取り専用コピーを使用すると、オフサイトバックアップよりも迅速に回復できるだけでなく、他の高度なクラウドサービスを活用することもできます。EHR 環境では、クラウドに読み取り専用コピーを作成する方法が複数あります。次の図は、アプリケーション層やデータベース層のレプリケーションの使用方法を示しています。

Read only copy through EHR replication

図 2: EHR のレプリケーションによる読み取り専用コピー

次の図は、オンプレミスの NetApp ファイラーと、SnapMirror レプリケーションのアシスト役として FSx for ONTAP を組み合わせて活用する方法を示しています。AWS でヘルスケアアプリケーションをデプロイする場合は常に、信頼性の高い設計で AWS のベストプラクティスに準拠し、ヘルスケアワークロードの複数のグローバルコンプライアンスフレームワークと複雑なコンプライアンス要件に準拠している Landing Zone for Healthcare の利用を検討してください。オンプレミスのストレージ環境、リカバリの目標、計画に応じて、最適な読み取り専用アーキテクチャを選択してください。

Read only copy through NetApp SnapMirror

図 3: NetApp SnapMirror による読み取り専用コピー

いずれのシナリオでも、通常の運用中は、FSx for ONTAP を並列に複数用意することで、ランサムウェアイベントやその他の急増するユースケースで必要とされるよりもはるかに低い合計 IOPS とスループットに設定できることに注目してください。これにより、コストを抑えながら、オンデマンドでシームレスにパフォーマンスを向上できます。

クラウドベースの EHR 本番環境

FSx for ONTAP は、AWS で実行される完全な EHR 本番環境の基盤要素としても使用できます。オンプレミスの EHR 環境と比較すると、ハードウェアの更新サイクルが不要になり、総所有コスト (TCO) を削減しながら、中断のない従量課金制のスケーラビリティを実現できます。計画外の成長、合併、買収、または急増する要件に直面している医療機関は、AWS 上の FSx for ONTAP のスケーラビリティを活用してコストを管理しながら、同時に無数の高度なクラウドベースのヘルスケアアプリケーションの相互運用性を実現できます。

あらゆる EHR 本番環境の重要なコンポーネントは、災害復旧が可能な高可用性アーキテクチャです。AWS EHR FSx for ONTAP リファレンスアーキテクチャは、次の図に示すように、複数のアベイラビリティゾーン (AZ) (高可用性用) と複数の AWS リージョン (災害復旧用) を活用してこれを実現します。

Figure 4 Highly available EHR production with disaster recovery capability

図 4: 災害復旧機能を備えた高可用性の EHR 本番環境

本番環境リージョンでは、データベース、レポート、テストと開発、およびその他の統合された周辺アプリケーションが 1 つの AZ で実行されています。AZ 全体が使用できなくなる可能性は低いものの、FSx for ONTAP はマルチ AZ サービスとして構成されており、データの同期された独立したコピーが 2 つあるため (図には示されていませんが、各 AZ に 1 つのコピーがあります)、処理は 2 番目の AZ にフェイルオーバーできます。この構成により、オペレーションが大幅に簡素化されるとともに、災害を宣言することなく完全な単一 AZ 障害への対応を可能にします。

AWS リージョン全体が利用できなくなった場合は、災害が宣言され、セカンダリリージョンで処理が再開されます。上の図は、レプリケーションの 2 つの方法を示しています。いずれかまたは両方を使用して、目的の RPO/RTO を達成できます。ストレージ層のレプリケーション (FSx for ONTAP によって実行) は SnapMirror によって実行され、データベースレベルのレプリケーションはアプリケーションスタックによって実行されます。セカンダリリージョンにも FSx for ONTAP によって維持される 2 つの同期コピーがあり、レプリケートされたデータのコピーは合計 4 つあることに注目してください。コストを削減するために、セカンダリリージョンの FSx for ONTAP をはるかに低いパフォーマンスレベルに設定し、災害時またはテストのオンデマンド時にのみパフォーマンスを上げることを検討できます。たとえば、通常の運用中は、並列 FSx for ONTAP の合計パフォーマンスを 300,000 IOPS および 8 GB/秒に設定できます。

単一データベースサーバーのストレージパフォーマンス

AWS の 200 Gbit 対応インスタンスが導入されて以来、クライアントネットワークを介して単一のインスタンスに最大 20 GB/秒、8K で 200 万 IOPS を超える FSx for ONTAP のパフォーマンスを集約することが可能になりました。これらのインスタンスは、EBS 最適化ネットワークを介して最大 8 GB/秒、350,000 IOPS にも対応しており、場合によっては、EBS インスタンスストアと呼ばれる NVMe がローカルに接続されていることもあります。その結果、これらのインスタンスの合計ストレージパフォーマンスは 30 GB/秒を超える可能性があります。ただし、極端なスケールを必要とするストレージのデプロイメントでは、データベース用に FSx for ONTAP ブロックデバイスを使用し、一時データベース用に EBS ボリュームを使用することもあります。つまり、テーブルスペース操作の実質的な制限は 20 GB/秒です。一時データベースにインスタンスストアを使用すると、インスタンスに直接接続されたストレージが活用されるためレイテンシーが低くなり、最適化された EBS ボリュームと FSx for ONTAP ブロックデバイスのいずれの場合でもパフォーマンスが高まります。本番データベースを FSx for ONTAP ブロックデバイスに限定すると、FSx for ONTAP スナップショットと FlexClone の使用が可能になり、容量コストが大幅に削減され、Amazon EBS と FSx for ONTAP ベースのスナップショット間の一貫性の問題が回避されます。

集約されたストレージパフォーマンスの分析

ピーク時に 8K で 100 万 IOPS に達する EHR 本番環境のデータベースを考えてみましょう。これは、単一の 200 Gbit 対応クライアントから約 10 GB/秒を消費します。ONTAP 環境全体で 16 個の FSx を利用すると、合計読み取り能力は 64 GB/秒を超え、8K で 250 万 IOPS になります。この総合パフォーマンスの余裕により、他のインスタンスに接続された FlexClone をレポート、クエリ、バックアップ、テスト、開発、またはその他のアクティビティに使用しても、本番環境のパフォーマンスに影響を与えず、全体的なストレージパフォーマンスを低下させる可能性のあるデータ移動 (コピー) も発生しません。これらの AWS アプリケーションインスタンスを組み合わせると、合計で 50 GB/秒、200 万 IOPS を超えるストレージレベルのパフォーマンスが得られます。

まとめ

このブログでは、FSx for ONTAP ブロックサービスを EBS と組み合わせて導入する独自の方法について説明しました。この方法では、電子健康記録アプリケーションのパフォーマンスニーズを満たしながら、現在世界最大規模の EHR 導入をはるかに超える拡張が可能です。クラウドの動的で従量課金の特性を活用してストレージレイヤーを最適化し、コストを制御して、EHR アプリケーションを中断したり意識させたりすることなくスケールアップとスケールダウンの両方が可能な環境を作成し、FSx for ONTAP の容量効率の高い FlexClone を活用できます。そのため、組織のストレージ要件が拡大または縮小しても、組織が遊休の資産にコストを支払う必要はありません。

従量課金制の経済性と FSx for ONTAP の高度なストレージ効率性の強力な組み合わせにより、AWS 上で構築された電子健康記録アプリケーション向けに、スケーラブルで信頼性が高く、高可用性、耐災害性を備えながらもコスト効率に優れたストレージソリューションを実現します。

EHR 環境向けに最適化されたストレージへの取り組みを今すぐ開始する方法については、AWS for Healthcare and Life Sciences にアクセスするか、AWS HCLS の担当者にお問い合わせください。

翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修はソリューションアーキテクトの宮城が担当しました。

Randy Seamans

Randy Seamans

Randy はストレージ業界のベテランであり、高性能ストレージ、コンピューティング (HPC)、および災害復旧を専門とする AWS のプリンシパルストレージスペシャリスト兼アドボケートです。彼のストレージに関する洞察や楽しみをさらに知るには、https://www.linkedin.com/in/storageperformance で彼をフォローしてください。