re:Invent 2024: GeisingerのEpicシステムAWS移行事例 - 性能向上とセキュリティ強化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Geisinger's epic journey: Scaling EHR operations on AWS (HLS207)
この動画では、GeisingerのEpicシステムをAWSに移行した事例について詳しく解説しています。1992年からEpicに関わってきた経験を持つAWSのMichael Hegyiと、Geisinger HealthのMarlin Moyerが、クラウド移行の具体的な取り組みを紹介します。Epicシステムの移行により、応答時間が20%以上改善し、Workflow例外の数が大幅に減少した点や、FinOpsを活用したコスト最適化の実践例が示されています。また、クラウド移行に際してのセキュリティ強化策として、アカウントの分離やファイアウォールの強化、CrowdStrikeの導入などが具体的に解説されており、医療システムのクラウド移行における実践的な知見が豊富に盛り込まれています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
GeisingerのEpic on AWSプロジェクト：概要と背景
こんにちは。HLS 207へようこそ。本日は、GeisingerのEpicシステムをAWSに移行した臨床システムの取り組みについて紹介する3部作の最終回です。私はAWSのMichael Hegyiです。この後すぐに、Geisinger HealthのMarlin Moyerが登壇する予定です。
まず、会場の皆様についてお伺いしたいと思います。挙手でお答えください。まず、医療機関にお勤めの方はいらっしゃいますか？ ありがとうございます。では、そのまま手を挙げていただいて、Epicをご利用の医療機関の方は？ 次に、サービスやソリューション、コンサルティングを提供している技術系企業にお勤めの方は？ ありがとうございます。本日のセッションは、どちらの立場の方にとっても有益な情報をご提供できると思います。
これから60分間、以下のような内容でお話を進めていきます。まず、EpicのAWSコミュニティの現状と、彼らが達成した成果についてご紹介します。その後、Marlinが登壇し、Geisingerについてお話しします。最初の2つのセッションに参加されなかった方のために、Geisinger Healthの取り組みについて振り返るとともに、本番稼働から1年以上が経過した今での学びについてもお話しします。その後、MarlinとPrivateで対談形式のディスカッションを行い、より詳しい内容についてお話しするとともに、時間が許せば皆様からのご質問にもお答えします。最後に、月曜日にオフィスに戻られた際に考えていただきたいポイントをお伝えします。
Epicの歴史とAWS移行の意義
先ほど申し上げた通り、私はAWSのEHRリーダーとして、医療機関がEpicをAWS上で効果的に運用できるようサポートしています。Amazonでの経験は約3年半ですが、Epicとの関わりはそれよりもずっと長く、1992年にまで遡ります。
当時、Epicは30人の優秀なスタッフ（正確には私を除く29人が優秀でした）で構成される小さな会社でした。この写真は1992年9月、第13回Epic年次ユーザーグループミーティングで、実際にフィルムカメラで撮影されたものです。右側が私で、左側はCarlという方です。皆さんの中にはCarlをご存知の方もいらっしゃるかもしれません。彼は1985年に入社し、新しい電子カルテシステムの開発を担当していました。その時点までのEpicソフトウェアは、Chroniclesという運用データベースと、CadenceやResoluteといったアプリケーションを、テキストベースの端末を使って提供していました。
私たちは、Legacyという新しい電子カルテシステムの新しいグラフィカルユーザーインターフェースをユーザーグループミーティングで発表する準備をしていました。これはクライアントサーバーアプリケーションでした。私の前にあったポータブルコンピュータは、Microsoft DOS上で動作するData Tree M上でLegacyとChroniclesを実行しているデータベースサーバーでした。Carlの前にあったのはアプリケーションのクライアントサイドで、Legacy Windowsアプリケーションでした。これは本当にユニークなもので、大ヒットとなりました。92年当時、特に外来診療領域ではこのようなものは誰も作っていませんでした。病院向けはありましたが、外来診療所向けはなかったのです。
1993年の春、私は最初にLegacyをインストールした2人のうちの1人でした。このシステムは本当に普及しました。私たちはLegacyからEpicCareに名前を変更しました。主な理由は、当時の人々がLegacyシステムを実装するのではなく、置き換えようとしていたからです。それ以来、技術は大きく変化しました。
私はEpicのTechnical Fellowとなり、新しい技術の出現に注目し、開発者向けのターゲットプラットフォームを生み出して、これらのプラットフォームが互換性を持ち、高速で安全で信頼性の高いEpicを提供できることを確認しました。多くのことが変化しました。私はEpicで約30年、正確には30年弱を過ごし、2021年にEpicを退職しました。しかし、私は引退があまり得意ではないことが分かり、今でもこの旅を楽しんでいます。
クラウド移行の目的とGeisingerの取り組み
私はテクノロジーに胸が躍ります。AWS上のEpicに興奮を覚えます。誰もがこれを採用すべきだと思います。しかし、時には医療システムの真のNorth Starに立ち返る必要があります。組織はQuintuple Aimを達成するために、ワークフローの改善、ケースマネジメント、医療の改善、科学的な進歩、そしてテクノロジーの改善など、様々な戦略と手法を用いるでしょう。そしてその重要なテクノロジーの1つがEHRであり、Epicは3ヶ月ごとに新機能を提供し続けて革新を続けています。
私は、Epicが医師にとって本当に効果的であるためには、高速で信頼性が高く、安全なインフラストラクチャー上で動作する必要があると考えています。歴史的に、ヘルスケアITはそれを高速で信頼性が高く安全なものにするための重労働を担ってきました。そして彼らは本当に素晴らしい仕事をしてきました。しかし、それには多くの時間と労力が必要です。適切なハードウェアを選択し、その上で動作するゴールデンイメージを作成し、適切なファームウェアが最新であること、ドライバーが最新であること、オペレーティングシステムの設定が適切であること、アプリケーションの設定が適切であること、そしてプレゼンテーションアプリケーションの設定が適切であることを確認して、高速で信頼性の高いものにする必要があります。これには時には数ヶ月かかることがあり、一度作成してしまうと変更を加えたくなくなります。
パンデミックを経て、多くのヘルスシステムから、ビジネスの観点からより俊敏性が求められているという声を聞いています。しかし、オンプレミス環境では俊敏性を確保することは困難です。適応性の高いビジネスモデルを採用しながら、コストの適切な管理を行うことは容易ではありません。そのため、オンプレミスで優れた実績を持つヘルスシステムでさえ、自社のEpicオンプレミス環境をAWSに移行する動きが増えています。この動きの背景には、Epicコミュニティとの協力関係があり、優れた成果を上げながら、AWSで高速で信頼性の高い安全な環境を提供し、同時にFinOpsとコスト最適化を通じて適切なコスト管理を実現できるようサポートしています。
私たちのEpic on AWSコミュニティでは、すでに2年以上にわたってEpicの本番環境を運用しているユーザーがおり、その成果を共有し始めています。信頼性の観点から、AWSで本番環境のEpicを運用しているすべてのヘルスシステムが、医療従事者に患者記録への継続的なアクセスを提供できていると報告しています。これはどのように実現されているのでしょうか？まず第一に、非常に高いサービス回復力を持つAWSを利用しているからです。このチャートでは、発生したダウンタイムや大規模な障害イベントについて、影響を受けたサービス数と影響を受けたリージョン数を掛け合わせて測定しています。そして、主要な4つのクラウドプロバイダーそれぞれについて、年間のサービス停止時間を合計しています。
AWSでは、私たちは顧客に徹底的にこだわっています。他のベンダーにこだわることはないので、単に「クラウドプロバイダー」として匿名化しています。2023年、AWSは引き続き、どのプロバイダーと比較しても最も少ないサービス中断時間を記録しました。2番目に回復力の高いクラウドプロバイダーでさえ、AWSの3.83倍の障害を記録しています。これは、AWSの誕生の経緯に起因していると考えられます。AWSはAmazon.comの継続的な信頼性と可用性を確保する必要性から生まれました。「経験値には圧縮アルゴリズムがない」とよく言いますが、
私たちは最も長い期間これに取り組んできており、大規模な障害が発生するたびに、再発防止のために徹底的な根本原因分析を行っています。ゼロではないことにお気づきかと思いますが、サービスが障害を起こした場合でも、完全な読み書きアクセスであれ、読み取り専用アクセスであれ、システムを稼働し続けられるようにアプリケーションの回復力を計画する必要があります。これは、AWS Well-Architected Frameworkから生まれたEpic on AWS リファレンスアーキテクチャの一部です。
オンプレミスのEpic本番環境と代替本番環境は通常2つのデータセンターに分散されていますが、AWSでは2つのリージョンに分散し、各リージョン内で3つのアベイラビリティーゾーンを使用します。これは6つのデータセンターにリスクを分散するようなものであり、信頼性の向上に大きく貢献します。信頼性に関して、もう1つのフィードバックはアプリケーションの速度についてです。AWSで本番環境のEpicを運用しているすべてのヘルスシステムが、平均応答時間が少なくとも20%改善されたと報告しています。さらに重要なことに、応答時間目標を満たさないワークフローの数が少なくとも50%削減されたと報告しています。
なぜそうなのでしょうか？ほとんどの場合、これらの組織は古いオンプレミスのハードウェアから、より新しく高速なサーバーやストレージに移行しているからです。オンプレミスの場合と同様、新しいハードウェアを導入すると、確かに処理は非常に高速になります。しかし、オンプレミスで運用する場合、設備投資を正当化するために通常3〜4年間サーバーを使用し、できる限り長く使おうとします。そうすると、新しい機能を古くなっていくハードウェアで実行することになるため、システムは次第に遅くなっていきます。一方、AWSクラウドでは、新しい高性能なAMDやIntelプロセッサーが利用可能になった時点で、システム全体を刷新することができます。毎月のメンテナンスウィンドウ時にシステム全体を更新し、技術の進歩に合わせて6〜9ヶ月ごとにそれを繰り返すことができます。私たちはそうすることをお勧めしています。なぜなら、この新しい技術はより優れたパフォーマンスを発揮し、コストを削減し、サステナビリティの目標を達成することができるからです。そしてその節約分はお客様に還元されます。
例として、AWSで2年間Epicを運用しているあるお客様は、プレゼンテーション層を新しいEC2インスタンスにアップグレードしたところ、応答時間が改善され、インスタンスあたりのセッション密度がほぼ2倍になりました。これにより必要なインスタンス数がほぼ半分になり、年間120万ドルのコスト削減が見込めると私たちに報告してくれました。特に素晴らしいのは、医療従事者に一貫して優れた応答時間を提供できることです。
高速化のもう一つの理由は、Nitroシステムです。AWS以外では、Epicはソフトウェアベースの仮想化サーバー上で実行され、ストレージやネットワークの暗号化/復号化の仮想化はホスト上で行われます。AWSでは、Nitroシステムがそれを担当します。これらのサブシステムをファームウェアに組み込み、ホストから負荷を取り除くことで、より高速な処理が可能になり、ホストは必要なワークロードの実行により多くのリソースを使用できます。私たちはこれを大規模に実現しています。Epicは、スケールアップ型の対称型マルチプロセッシング（SMP）システムとスケールアウト型の構成の両方において、ネイティブクラウドサービスを使用して、他のクラウドプロバイダーよりも大規模なワークロードのサイジングを行っています。
これまで信頼性と速度について説明してきました。セキュリティに関して、まず最も重要なのは、これはお客様のデータだということです。私たちにはそのデータへのアクセス権はありません。共有セキュリティモデルにおいて、私たちはクラウドのセキュリティを提供し、HIPAA対応サービスとHITRUST認証サービスを提供して、お客様がクラウド内でセキュリティを確保できるようにしています。患者記録へのアクセス権限の決定や、お馴染みの方法での監査は、引き続きお客様が行います。これまで信頼性、速度、セキュリティ、コスト最適化について説明してきました。新しい技術を検討する際には、コスト削減について話すことが一般的です。
コスト削減は確かに重要ですが、それは一時的な取引のように感じられます。これは一度きりで終わることではありません。ITニーズが変化する中で、私たち全員がコストの適切な管理者である必要があります。ここで、FinOpsのチャンピオンであるGeisinger Healthの話に移りましょう。Geisinger EpicのJourneyについて、もう少し詳しく説明するために、Marlin Moyerさんをお迎えしたいと思います。
Geisingerの移行プロセスと得られた成果
皆様、こんにちは。私たちの経験についてお話しさせていただく時間を取っていただき、ありがとうございます。特に、皆様が私たちの経験をどのように活かせるかについてお伝えできればと思います。私はGeisingerに約19年間在籍しています。Geisingerは1995年に契約を結び、その翌年の1996年に最初のEpic導入を行い、Epicの非常に早期の採用者であり、また技術全般においても先駆者でした。私たちは常に限界に挑戦し、病院を最高のものにすることに情熱を注いできました。1915年、私たちの創設者は「最高のものにせよ」という言葉を残しました。これは、10年以上にわたって患者へのケア提供、次世代の医療提供者の教育、そしてコミュニティのメンバーへのヘルスケア提供を行ってきた私たちのIT部門と組織全体の目標となっています。
では、どこから始めたのでしょうか？これが私たちの計画です。しかし、その前に、クラウドへの移行を決定するまでには多くの計画が必要です。Geisingerがやったからとか、他の組織がやったから今はそれがクールだからという理由でやるのではなく、それが意味のあることだからこそ実行するのです。各組織は、なぜそれが自分たちにとって意味があるのか、そしてこのような取り組みによって何を達成したいのかを理解する必要があります。これは、コストの面でもマンアワーの面でも決して安価な取り組みではありません。しかし、目標を達成できるのであれば、それは価値のある投資であり、私たちはそれを実感しています。
最初に行ったことの一つは、この取り組みを支援してくれるパートナーを見つけることでした。Deloitteがそのパートナーとして選ばれ、AWSがクラウドプロバイダーとして、長年投資してきたオンプレミスのデータセンターからクラウドへの移行を支援してくれることになりました。計画を立てる際、私たちにとってはEpicだけが対象ではありません。これは包括的な取り組みです。私たちの目標は、クラウドファーストで、オンプレミスは最後の手段としています。これは、システムが稼働してからの2年間、そしてこの取り組みを開始して以来、クラウドで実感してきた価値です。
Epicに関して具体的に見ると、成功に確信が持てる方法で実行することを重視しました。この話が出た時点で、私たちは20年以上にわたって、医療提供者、患者、そしてコミュニティの医療提供者にEpicインスタンスを提供してきました。私たちは非常に強固な計画を立てました。実際、Epicを移行する前に、他の臨床アプリケーションの移行から始めました。トレーニングインスタンス全体を構築しましたが、Epicをご存知の方ならわかると思いますが、これは1つの環境だけではなく、クラウド上のトレーニングスタック全体を意味します。
私たちは、それが機能することを確認するためにテストを行いました。印刷に至るまですべてを検討しました - ペーパーレスを実現していると感じている方はどれくらいいらっしゃいますか？誰も手を挙げていませんね。なぜなら、それは現実的ではないからです。常に紙は存在します。なくしたいと思いますが、常に紙は必要です。この点について言えば、実際に最も帯域幅を必要とするのは印刷なのです。そこで、周辺機器から印刷まで、あらゆるものをテストしました。最終的には、Proof of Concept環境、テスト環境、そして本番環境をクラウドに移行することになりました。私たちのクラウドへの移行の興味深い点は、本番環境の移行です。当初の計画では、9月に本番環境をクラウドに移行し、1週間そこで運用した後、約3ヶ月間オンプレミスに戻す予定でした。
その間、私たちはリリースアップグレードを実施し、リージョン2の準備を進める予定でした。しかし、クラウドに移行して3日目に、プロバイダーやアナリストから電話が入り始めたことで、すべてが変わりました。珍しいことに、ヘルスケア業界では珍しい、喜びの声ばかりでした。システムの動作が素晴らしく、作業時間が短縮され、レスポンスが向上したという報告が次々と寄せられたのです。通常、システムが遅くなった時は必ず連絡が来ますが、「すごく良く動いている」という連絡を受けるのは非常に珍しいことです。
リーダーシップチームとして、私たちは急遽方針を変更し、インスタンスをクラウドに残すことを決定しました。テストしていないアップグレードを実施するというプランBを策定しました。私たちは通常、徹底的なテストを行うのですが、今回はクラウド上でアップグレードを実施することにしました。当初3ヶ月かけて移行する予定だったハイブリッドサーバーの移行も継続して進めました。12月までその状態を維持し、12月にはリージョン2にフェイルオーバーを行い、1週間後にリージョン1に正常にフェイルバックしました。これらすべては、安定性、拡張性、セキュリティを備えたシステムを構築するために、Epic、AWS、Deloitteとのパートナーシップのもと、特定、テスト、検証を徹底的に行ったからこそ可能となりました。
コスト最適化とFinOpsの重要性
コストと適切なサイジングについてお話ししましょう。Mikeが説明したように、新しいテクノロジーを活用する能力は、クラウドにおける代替テクノロジーの活用にも及びます。移行時には、オンプレミスで見ていた構成と同じ構成を使用しましたが、キャパシティが過剰であることが分かりました。そこでサーバー数を削減することができました。また、リリースアップグレードとシステムの需要増加に備えてサーバーを追加していましたが、これも同様にスケールバックすることができました。
全体として、本番稼働後の予想コストは、適切なサイジングと代替インスタンスタイプの活用により実際には削減できることが実証されました。より多くのインスタンスタイプと新しいテクノロジーについて議論する中で、需要に合った適切な組み合わせを見つけることが重要です。これがFinOpsにつながります。必要なものを特定し、環境を適切にサイジングすることが重要なのです。 EC2インスタンス数の推移を見ると、減少傾向にあることがわかります。これは素晴らしいことです。サーバー数を削減できましたが、サーバー数の削減が常にコスト削減につながるでしょうか？それは場合によります。
現在、私のチームは約100台のサーバーを追加する計画を立てています。しかし、新しいテクノロジーを活用し、インスタンスサイズを適切にダウンサイジングできるため、サーバー数が増えてもコストを削減できる見込みです。これこそがFinOpsがプロジェクトではなく、プログラムとなる理由です。一度きりで終わるものではありません。FinOpsチームには、日々の業務として財務運営を管理する人々だけでなく、必要なものを理解し、使用状況を把握し、機会を認識して実行できるアナリストやサーバー管理者も必要です。
ご覧いただけるように、1年以上にわたって、私たちのWorkflowの数は増加または横ばいを続けていました。重要なのは、グラフの線が全体として一度も下がらなかったということです。しかし、8月にEpicのHyperdriveプラットフォームに移行した際、Workflow例外の数が減少したことにお気づきでしょう。これは素晴らしい結果で、私たちも喜んでいました。ところが、9月に見られた2度目の大きな落ち込みは予想外でした。これは単にクラウドへの移行によるものでした。その後も、サーバー数の適正化や容量の最大化を進めていく中でも、Workflow例外の数を維持、あるいはさらに減少させることができました。
これは医療提供者にとって非常に意味のあることです。ちなみに、医療提供者というのは、受付担当者、看護師、医師、検査室、放射線科など、医療提供システムに関わるすべての人々を指します。彼らの時間はすべて貴重であり、私たちはそれを最大限に活用する必要があります。本番環境のコスト削減について見てみると、リリースアップグレードに向けた計画のためにコストが上昇したことがわかります。サーバー数を増やしたためです。しかし、すぐにそれらすべてが必要ないことに気づきました。アップグレードのために追加したものだけでなく、当初持っていたものさえも必要なかったのです。私たちは運用を最適化するためにコスト削減計画を実行し、それを削減することができました。
次のセッションでは質問を受け、議論を展開していくことを楽しみにしています。皆様からのご質問もお待ちしております。ありがとうございます、Marioさん。素晴らしい発表でした。皆様から寄せられた信頼を当然のものとは考えておらず、これからも皆様のために尽力していきます。情報共有ありがとうございました。いくつか質問があります。公平を期すために申し上げますと、これらは事前にMarlonさんにお伝えしてある質問です。
医療システムの関係者と話をすると、既存のテクノロジーを管理しながら新しいテクノロジーを導入することの難しさについてよく耳にします。移行プロセスに話を戻しますが、クラウド移行中の重要な医療アプリケーションのシームレスなサポートを確保するため、Geisingerはどのようなアプローチを取られましたか？サポートは私たちにとって興味深い側面でした。それは非常に早い段階から始まり、全員への教育が含まれていました。私たちは上級幹部にクラウドとは何かを教育しました。彼らは非常に賢明な方々ですが、私たちが何を実現しようとしているのかを理解できるよう、さらに一歩踏み込んで説明しました。実際の移行をサポートする人々、つまりサーバーアナリスト、ネットワークアナリスト、アプリケーションアナリストにも教育を行いました。
これが最も重要なポイントだったと思います。これは特定のプロジェクトのためだけに行う必要があったわけではありません。今後20年、30年、40年と続く運用に向けて、私たちがどのように準備するかということが本質でした。今朝のキーノートで見たように、AWSには多くの変化があります。新しいことを学び続けることになりますが、重要なのは私たち自身の準備でした。全員への教育が最初のステップでした。Deloitteのパートナーと協力し、特に私が強く支持している「見て一つ、やって一つ、教えて一つ」という哲学を用いました。これはDeloitteのパートナーとの関係で重要でした。なぜなら、彼らに全ての作業をしてもらうだけでは簡単すぎるからです。どうやってサポートするのか？その期間中に何が行われたかを理解することで、より良いサポートが可能になります。これが他の重要な点でした。プロセス全体を通じて人々を参加させ、自ら作業を行うという哲学です。完璧に物事が進むことは期待できないとおっしゃいましたが、アプリケーション運用に影響を与える可能性のある出来事やインシデントに対して、Geisingerはどのように事前に準備されたのか、例を挙げていただけますでしょうか。
私たちは、ユーザーがデータにアクセスするあらゆる場所、Electronic Health Record（EHR）が関わるすべてのウェブサイトや相互作用について、聴衆の皆様に質問を投げかけることができます。これは私たちが自問自答し、多くの時間を費やして取り組んだことの一つです。なぜなら、相互運用性によって、そしてEHRシステム同士がどのように通信するかという点で、現在では多くの接点があるからです。Apple Health Kitなどとの統合を含む外部連携の量は、私たちが進むべき方向性を考えさせてくれました。
私たちが準備する必要があったのは、これらの接点を理解することでした。クラウドへの移行において、単にオンプレミスのデータセンターで行っていたことを再現するだけではない目標を掲げていたからです。私たちは、自社内でもデータを分離するために、より多くのアカウントを実装することを決めました。ファイアウォールの数を増やし、Epicは独自のアカウントに配置され、他のすべてのシステムからファイアウォールで分離されています。システム間で何らかの相互作用を行う場合は、それらのファイアウォールポートを開く必要がありました。これが私たちの最大の課題の一つでした - すべてを理解することが本当に重要だったのです。臨床部門では約900のアプリケーションをサポートしており、それらすべてを統合し、実際にどこでデータを交換しているのかを理解することが重要でした。
Geisingerがクラウド環境と重要なアプリケーションのセキュリティと回復力を強化するために取った具体的な対策として、異なるアカウントへの分割とファイアウォールの強化は間違いなく最優先事項の一つでした。自社のデータセンターでは必要ないと感じるかもしれない対策も実装しました。Change Healthcareの事象以前から意識はしていましたが、小さな問題が引き起こす影響について、今では誰もがより意識的になっていると思います。
保護ソフトウェアについては、CrowdStrikeを選択肢として使用し、すべてのインスタンスにそれを確実に展開することから、クラウド移行のためのより良いプロセスの確立まで、あらゆる面を検討しました。これは単なるリフト＆シフトではなく、最終的にどうありたいかを総合的に考えることが重要です。より具体的なプロセスの開発、追加のファイアウォールの導入、接続の開放と承認のためのプロトコルの確立に焦点を当てました。これは単なる官僚主義ではありません - 多くの人が「なぜこんなに面倒な手続きが必要なのか」と言いますが、これは保護であり、そのように捉えることが本当に重要だと考えています。
FinOpsに関して言えば、もしやり直せるなら、プロセスの早い段階でFinOpsにもっと投資していたでしょう。これは学んだ教訓です。主な理由は、本番環境に移行した直後から見えてくるものに対応する機会があるからです。FinOpsプログラムがまだ確立されていない場合、そういった機会を活用することができません。私たちはそれをすぐに認識し、改善のために導入を進め、現在も継続的に発展させています。完璧ではありません。組織の一人のプログラムディレクターがこれを担当しており、彼女はプログラムの開発と機会の探索に素晴らしい仕事をしています。FinOpsについて考えるとき、Compute Savings Planのように一定量のストレージ使用を約束するような、相反する要素もあります。
それは素晴らしいことです - コストを削減できますね。しかし、他の誰かがコンピュート使用量の削減に取り組んでいる場合、お互いの効果を相殺してしまう可能性があります。そのため、包括的なプログラムを見ることが重要です。私としては、この分野についてもっと皆さんに教育できたのではないかと考えています。
クラウド移行後の改善点と今後の課題
ここでコンピュートの話題から少し離れますが、本当に考え抜く必要がある別の機会としてバックアップ戦略があります。私たちはそこから多くの恩恵を受けました。複数のバックアップを持っていましたし、今でもそうですが、利用可能な新しいテクノロジーと新たな脅威を考慮する必要があります。バックアップの方法、保持期間、完全コピーの保持日数などを見直すことで、バックアップコストを大幅に削減することができました。クラウドにいる利点として、誰もが起こってほしくないと願っているものの、決して起こらないと想定してはいけない事態に備えて、オフラインバックアップやセキュアなスナップショットを取れることも、私たちがより低コストで改善できた分野の一つです。
最近、クラウド上のEpicに関するクラスレポートが出ましたが、そのコメントを見るのが興味深かったです。ほぼすべての回答者がAWSに移行後、応答時間が改善したと述べており、実際に75%が大幅な改善があったと回答しています。一方で、まだコスト削減は実感できていないという声もありました。おっしゃる通り、まだFinOpsの側面を十分に活用していないのだと思いますが、プロバイダーの応答時間を改善しながらコスト最適化のバランスを取ることについて、もう少し詳しくお聞かせいただけますか。
コスト最適化の観点からすると、データセンターの運用コストをどのように算出するかによります。ここで私がFinOpsプログラムを早期に開始することの重要性に立ち返るのですが、ほとんどの組織は個々のサーバーの運用コストを実際には把握していません。セキュリティの固定費は？建物の運用費、電力費、冷却費は？AWSでは、そういった細かい計算を行った上で、すべてを含む総コストが見えます。私たちはサーバーごとのコストを正確に把握できていなかったので、本当のコスト削減を考える際の最初のポイントとなります。
私たちにとって、そのバランスを取る上で、患者さんを第一に考え、医療従事者を通じて患者さんにサービスを提供することを確実にしなければなりません。新しいインスタンスタイプに移行する前に、かなりの量のテストと検証を継続して行っています。そのインスタンスタイプが実際に大規模に展開する前に、どのようなパフォーマンスを発揮するかを確認します。EC2インスタンスタイプの全体をアップグレードで置き換えることは確かに可能ですが、私たちは通常、いくつかをテストして検証してからパフォーマンスを確認するというアプローチを取っています。
私がもう一つ特に強調したいポイントは、ユーザーの声に耳を傾けることの重要性です。システムのパフォーマンスをダッシュボードで確認することはできますが、実際のユーザー体験について直接話を聞かない限り、それらは全く異なる可能性があります。エンドユーザーとの強いつながりを持つことが重要です。そのため、私たちは医師Informatician、看護師Informatician、そして現場で状況を把握する担当者を通じてそれを実現しています。なぜなら、財務的に適切な判断を下しながら、必要なニーズに応えていきたいからです。
組織と連携して、満たすべきニーズを理解する必要があります。あと2つ質問があり、その後、できれば会場からの質問を受け付けたいと思います。
EpicのAWS上での本番環境が稼働して1年以上が経過した今、これによってGeisingerはケアサービスやソリューションの提供においてどのように機敏さやイノベーションを実現できているのでしょうか？この言葉を使うのは気が引けますが、「Fail Fast」という考え方です。私たちには大規模な研究部門もあり、そこではEpicから出力される匿名化されたデータを活用してコンプライアンスを維持しています。実現できたことの一つは、研究用インスタンスや研究作業をスケールアップし、それを継続すべきかどうかを判断できるようになったことです。
現在、私たちは追加の統合を進めており、それがより管理しやすくなっています。新しいサーバーセットの納期が3ヶ月や6ヶ月、パンデミック時には12ヶ月もかかっていた心配をする必要がなくなりました。患者の病室での電子ホワイトボード、オンラインメディアやApple TV、統合プラットフォームを通じた患者教育の提供など、組織のニーズに応じてスケールアップできるようになりました。バーチャルケアの機会も別の選択肢として提供しています。
私たちはペンシルベニア州の田舎に位置しています。サービス提供エリアには比較的大きな都市部もありますが、Danvilleがある地域では、長年の伝統として、ほとんどの学校が月曜日と火曜日を休みにしています - 生徒たちは両親と狩りに行くのです。これが私たちの「田舎」の実態です。しかし、これは同時に、クリニックへの接続を提供するISPが1社しかないような地域全体にサービスを提供するという課題も伴います。クラウドに移行したことで、データセンターの運用に気を取られる時間が減り、クリニックでの患者体験の改善や、組織が前進するために何が必要かということにより多くの時間を費やせるようになりました。
Epic on AWS導入のためのアクションプラン
月曜の朝、現在Epic on AWSを運用している方々に、オフィスに戻った月曜日にどのようなアドバイスをしますか？まず最初に、これらの質問をする際には私の名前は出さないでください。AWS Cost Explorerを使用しているスタッフを見つけ、Epicのシステムパルス分析、あるいはクラウドで実行している任意のアプリケーションのパフォーマンスメトリクスを担当している人を特定してください。彼らに「改善の機会は何か？」と尋ねてみてください。クラウドを使用している場合、少なくともそういった改善の可能性を示すツールがすぐそこにあるからです。「これは必要だ」と分かることもあれば、「週末はこのサーバーを稼働させる必要はないから、電源を落として、また立ち上げればいい」と気付くこともあるでしょう。まず最初に申し上げたいのは、情報を見つけることです。情報がなければ何も変えられませんが、利用可能な情報は豊富にあります。
では、やっていただきたい4つのことを見ていきましょう。キャパシティ評価については、先ほど触れました。インスタンスタイプの見直しも、これらの改善機会の中に含まれています。インスタンスタイプについて重要なのは、単に「小さくする必要があるか？」だけでなく、「大きくする必要があるか？」「別のタイプにする必要があるか？」など、あらゆる側面から検討することです。
私たちの例を挙げると、4XLは必要ありません。実際、コスト面から見ると、一部のサービス提供には2XLを複数用意する方が効率的だということが分かりました。
FinOpsモデルについては、もしFinOpsを正式な肩書きとして率いる人がいない場合、FinOps部門やチームを監督する専任の役割を持つ人がいなければ、それを確立してください。強力なプログラムを持つことで、すぐに効果が表れると思います。私たちのFinOpsリーダーであるAmy Evansさんを紹介させていただきますが、私たちも完璧ではありません。重要なのは、誰も完璧ではないということです。私たちは互いに学び合うことができ、それがここに集まって共有する意味の一つです。
クラウドを使用していない、あるいはEpicやその他の大規模システムをクラウドで運用していない場合は、本当に検討を進めるべきです。クラウドに移行することを推進するのではなく、なぜクラウドを使用していないのか、使用した場合にどのようなメリットがあるのかを理解することを推進してください。これらの質問に対する答えが分からなければ、必要な情報を持っていないということです。答えは「このシステムは現時点ではクラウドに移行できない」かもしれません。2年前まで、PAシステムや放射線画像システムのほとんどは、画像転送に大きな帯域幅が必要なため、クラウドベースではありませんでした。しかし今では、そのような帯域幅を大量に必要とするシステムでさえもクラウドに移行できるベンダーやシステム、ソリューションが登場し始めています。
基調講演でも見てきたように、AIのすべての機能が揃っています - その力はすでにそこにあります。ベンダーと協力して、新しいテクノロジーを最大限活用するよう働きかけていく必要があります。ベンダーパートナーを特定し、目標達成に向けて彼らの支援を活用することが重要です。しかし、何よりもまず自分たちがどこに向かいたいのかを理解することが最優先です。
現在、EpicをクラウドやAWS上で運用していない方々に向けて、4つのアクションをお勧めします。まず、AWS Account ExecutiveにコンタクトしてImmersion Dayをスケジュールし、Epic on AWS Reference Architectureについて話し合うことです。次に、Epic認定システム管理者やOperational Database Administrator、Epic Client System Administrator、そしてESECの方々がEpic on AWSの運用に慣れるための、AWSが厳選したトレーニングカリキュラムを用意しています。
最近では、多くの組織がAWS上でEpicを実装する際に、AWS上に独立したリカバリー環境（Isolated Recovery Environment）を構築することでビジネスリスクを軽減することに関心を示しています。これは本番環境のEpicの第三のコピー、つまり本番環境とAlternate Production環境に加えて、別の場所に設置するレプリカです。もしランサムウェア攻撃によってオンプレミスのEpicシステムがオフラインになった場合でも、このIsolated Recovery Environment で患者記録へのアクセスを確保できます。これは主要パートナーの一社と協力することで、8週間以内という短期間で構築可能です。
この取り組みは、臨床業務の回復力を向上させ、ビジネスリスクを軽減することが確認されています。多くの場合、サイバー保険料の削減にもつながっています。これは比較的リスクの低い、素早く始められる方法で、私たちが「Two-way Door」と呼ぶものです。つまり、うまくいかない場合は単に使用を停止して終了すれば、それ以上の費用は発生しません。これに慣れてきたら、ご指摘の通り、他に何ができるかを検討し、FinOpsをプロセスのより早い段階で実施することが重要です。これには教育も含まれており、どのようなレバレッジがあるか理解し、パートナーやAWSと協力することが大切です。私たちは確実にそのサポートができます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion