処方箋データ基盤チームでエンジニアをしている岩佐 (孝浩) です。
2024年6月に入社し、薬局の処方箋データを扱うプラットフォームの構築に携わっています。カケハシには「岩佐」さんが複数名在籍しており、社内では「わささん」と呼ばれています。
この投稿では、処方箋データ基盤チームが提供する「しなやかなプラットフォーム」について、技術トピックも交えて紹介します。
この記事は秋の技術特集 2024の12記事目です。
処方箋データ基盤チーム紹介
処方箋データ基盤チームは、名前のとおり、薬局に保存されている処方箋データを収集・蓄積・連携するための基盤 (以降、プラットフォームと記載) を管轄するチームです。
カケハシは musubiをはじめとした薬局向けプロダクトを複数開発しており、それらのプロダクトに処方箋データを確実に連携することが、処方箋データ基盤チームのミッションの一つです。
プラットフォーム紹介
構成
プラットフォームは以下の構成になっており、私が入社する数年前から稼働している実績があります。(AWSのIoT CoreとIoT Device Shadowで管理する「レセハブ」の紹介)
処方箋データを収集するために、Raspberry Pi を設置させていただいており、AWS IoT Core X.509 クライアント証明書による認証で、Raspberry Pi を認証しています。
特長1: しなやかさ
カケハシでは、AWS を IaaS / PaaSとして採用しており、処方箋データ基盤チームも AWS を活用したクラウドネイティブなワークロードを数多く開発しています。クラウドネイティブな構成により、可用性が高くスケーラブルなワークロードを迅速に構築でき、しなやかな構成になっています。
特長2: 処方箋データの安全なアップロード
処方箋データは多くの個人情報を含むため、安全性の高い接続を通じて、AWS にアップロードする必要があります。
処方箋データ基盤チームのプラットフォームは、厚生労働省の「医療情報システムの安全管理に関するガイドライン 第6.0版>システム運用編 [Control]>１３．ネットワークに関する安全管理措置」に記載されている「クライアント証明書を利用した TLS クライアント認証」の要件を満たしており、処方箋データの安全なアップロードを実現しています。
オープンなネットワークにおいて、IPsec による VPN 接続等を利用せず HTTPS を利用する場合、TLS のプロトコルバージョンを TLS1.3 以上に限定した上で、クライアント証明書を利用した TLS クライアント認証を実施すること。
特長3: 処方箋データの高い耐久性
アップロードされた処方箋データは、S3 に蓄積されるため、データの耐久性は 99.999999999% (イレブンナイン)になります。
Amazon S3 は、クラウドで最も耐久性の高いストレージを提供します。S3 は、独自のアーキテクチャに基づいて、99.999999999% (イレブンナイン) のデータ耐久性を実現できるように設計されています。
余談ですが、年末ジャンボの1等当選確率は 2,000万分の1 = 1 / 20,000,000 * 100 = 0.000005%だそうです。一方で、S3 のデータが破損する確率は、100% - 99.999999999% = 0.000000001%です。つまり、年末ジャンボの1等当選確率のほうが5,000 倍高いということになります。
特長4: イベント駆動型アーキテクチャ (EDA)
処方箋データが S3 にアップロードされると、そのイベントに反応して様々な処理が実行されます。このようなアーキテクチャは、イベント駆動型アーキテクチャと呼ばれ、メッセージをインターフェースとして、プロデューサーとコンシューマーの疎結合を促進します。
特長5: Pub/Sub アーキテクチャ
EventBridge をメッセージブローカーとして、複数のプロダクトにメッセージをパブリッシュしています。このようなアーキテクチャは、Pub/Sub アーキテクチャと呼ばれ、非同期・並列処理により、ワークロードの疎結合を促進します。
今後の課題
以下は個人の見解であり、所属組織を代表するものではありません。
DR 対策
カケハシの各プロダクトに処方箋データを確実に連携するためには、DR 戦略に従ったアーキテクチャの実現が求められると思います。
データのバックアップ、複数の AZを活用した冗長化、ワークロードを迅速に再現するための IaC (Infrastructure as Code)、CI/CD によるデプロイの自動化、このような基本的な対策は、既に高いレベルで実現できています。今後、プラットフォームの SLO を定義するにあたり、ワークロードごとに RPO/RTO を検討し、場合によっては Multi-site Active/Activeのような、極めて高いレベルの DR 戦略に従う必要があるかもしれません。
処方箋データのアップロード手段
新型コロナウイルス感染症が世界中のサプライチェーンに影響を与えましたが、処方箋データ基盤チームが利用する Raspberry Pi も例外ではなく、入手が困難になった時期がありました。このようなケースが今後生じる可能性は低いと思いますが、お客様への影響がゼロではありません。
処方箋データのアップロード手段として、例えば、入手性の高い端末で代用したり、アップローダーをアプリケーションとして開発するなどの検討が必要になるかもしれません。
まとめ
処方箋データ基盤チームが提供するプラットフォームについて、技術トピックを中心に紹介してきました。
これまで、私がクラウドネイティブに取り組んできた理由をカケハシっぽい一言で表現するとしたら、「システムをしなやかにできるから」だと思います。
クラウドを全く使わない、あるいは、ほとんど活用しない従来のシステムは、非常に硬直的です。垂直・水平の両方におけるスケーリングの難しさ、予測が困難なキャパシティプランニング、多額の初期投資と減価償却、このような様々な困難に直面していたはずです。しかし、クラウドを活用することで、このような硬直性に「しなやかさ」がもたらされます。
カケハシのミッションである「⽇本の医療体験を、しなやかに。」を実現できるよう、「しなやかなプラットフォーム」の構築に全力で取り組みたいと思います。
