SS-MIX2のクラウドにかかわる調査を読んで①
目次
SSMIX-2のクラウド検証が厚労省の方で行われたようで、資料を読んでみました。
以下のでは5つの検証が行われていて、
【抜粋-SS-MIX2ストレージのクラウド化に関わる調査一式 報告書-】
実証① SS-MIX2 ストレージのクラウド保存、相手地域の情報を含む情報閲覧
・ 地域医療連携ネットワークもしくは医療機関にて作成・保存された SS-MIX2 データをクラウドに確実にアップロードできることを確認す
る。また、差分データのアップデート方法を含めて、各医療機関のデータが確実にクラウドにアップロードされることを検証する。
・保健医療記録共有サービスの共通のビューワ（以下、「共通ビューワ」）で、クラウドに保存された SS-MIX2 データ、及びクラウドにア
ップロードされていない各拠点の SS-MIX2 データを参照してシームレスに患者情報を閲覧できることを検証する。
実証② データ保存におけるセキュリティ
クラウドに SS-MIX2 データを保存する際に、医療機関ごとのデータ保存領域を論理的に分離し、他の拠点からのアクセスを制限でき
ることを検証する。
実証③ データ形式の変換
最大で全国民のデータをクラウドに蓄積している前提のもと、SS-MIX2 データを RDB、NoSQL のデータベース形式に変換、保存し、
共通ビューワから閲覧することをシナリオとして比較検証を行う。
他の医療機関や他の患者データにアクセスできないよう、SS-MIX2 データを安全に保存するために求められるテーブル構造を検討す
る。
RDB、NoSQL に保存したデータに、複数の条件を用いてクエリーを行い、レスポンス速度を比較する。
実証④ 保健医療記録共有サービスでの名寄せについての考察
患者基本情報の名寄せについて、世帯単位の被保険者番号、個人単位の被保険者番号の２パターンで技術検証を行い、名寄せ
の効率性を机上検討する。
名寄せが完了するまでの代替案もしくは推奨案を机上検討する。
実証⑤ 患者ポータルにおける同意管理
SS-MIX2 データに含まれる患者情報の閲覧において、各患者のデータにアクセスする際に必要となる同意管理を行うための方法を
机上検討する。特に、患者ポータルにて同意／同意撤回を行う際の技術面／運用面での課題、要件について検討する。
今回はそのうちの①検証のアップロードのところまで読んだのでメモ的に雑感を書いていきます。
5年間分のSS-MIX2データのシステム案。
SS-MIX2 ストレージの保存、情報の閲覧
SS-MIX2のビューア側は見たことがないので、イメージしかないですが。（フリーのものがあれば試してみることはできそう）
まぁ、ビューア側は要件にそったディレクトリ構成なら問題はないのではないだろうか。というのが感想。
ストレージの選抜
AWS では大きく２つのストレージがあると切り分けていた。
ブロックストレージ（EBS）とオブジェクトストレージ（S3）
要件的にS3に軍配があがるだろうなぁと思ってはいたが、そうなったらしい。
主要な要因としては「要領に対するコストメリット」であろう。
【抜粋-SS-MIX2ストレージのクラウド化に関わる調査一式 報告書-】
全国の医療機関で作成される SS-MIX2 データをすべてクラウドにアップロードする場合、「表 3 ストレージに保存されるデータ件数の見
積もり」に記載の値より、5 年間の保存に必要となるデータ量は 922TB となる。
てな具合でSS-MIX2のデータ保存にはいかれた容量が必要になる。容量に関するバリューではS3だろうし、EBSには容量の限界もある。
診療データはどうしても「ずいぶんアクセスしていないデータ」ができがちだが
S3ならGlacier やら、S3のオプションやらでアクセス頻度に応じてさらにコストをえぐることもできそう。ということでS3だろうなぁ。
SS-MIX2では以下のようなフォルダ構成をとる必要があるが・・・
gyazo.com
論理的にはS3もフォルダ構成をサポートしているので、S3で問題ないだろう。
某所では「幻想」であるとされていますが。。。とにかく上記の形式で置くこと、ビューアが読み取れるところに意味があるので「論理的」であっても問題はないはずです。
dev.classmethod.jp
締めくくりとしては以下のように書かれている
【抜粋-SS-MIX2ストレージのクラウド化に関わる調査一式 報告書-】
まず、ブロックストレージについて、「表 2 ストレージの特徴」に記載の通り、ブロックストレージには容量制限があるため、必要な容量を一
括で確保することができない。AWS の場合、１つのブロックストレージとして確保できる容量が最大 16TB に制限されるとともに、アカウント
あたり最大 300TB に制限されるため、複数のアカウントを管理し、各アカウントに複数のブロックストレージを作成して必要な容量を確保す
る必要がある。また、データ容量922TB は保存期間を 5 年間とした場合の試算であるが、保存期間の増加や、SS-MIX2 ストレージに保
存されるデータが増加するような仕様改定が発生した場合に、ブロックストレージでは必要な容量を追加確保することが困難になる可能性
が残る。
最終報告書
～平成 30 年度 SS-MIX2 ストレージのクラウド化に関わる調査一式～
14 / 149
一方、オブジェクトストレージは、必要な容量を一括で確保することが可能なうえ、可用性、耐久性、拡張性で優位であり、かつ、コスト
比較においては圧倒的に優位である。SS-MIX2 データは頻繁に書き換えが発生するデータではないので、ブロックストレージのもつ更新頻
度が高いデータの保存に向いているという特徴にも該当しないため、積極的にブロックストレージを選択する理由もない。
以上より、本実証ではオブジェクトストレージを採用して実証を行うこととする。
なげーわい。容量についてはS3のほうが柔軟だし、特にEBS使う目的もないからS3ね。ということと解釈しました。
ということでストレージは「S3」に決定です。
クラウドへの転送方式
さぁ、ストレージは「S3」決まったわけだけど、オンプレに抱えているSS-MIX2データをどうやってアップロードしようかね。
という話。
ここでも大きく２つに切り分けて検証をしている。
・「同期方式」
・「ゲートウェイ方式」
正直、いまいちわかってはいないんだけど。アップロードに関しては伝送経路を保護しないといけない。
要は第３者がデータを盗み見れてはいけない。また確実にアップロードできないといけない（破損してり、失敗は許されない）という要件がついてくる。
そのうえで、一番費用の負担が少ないもの。。。という形で選抜していったように読み取れた。
gyazo.com
みたいな感じでS3も構築していくわけなので、よそ様のものが見れると色々とまずい。クラウドにはつきものの懸案点でもあると思う。
クラウドとしてのベストプラクティス、費用、技術的な課題などを加味して検討。AWSツヨツヨオジサンたちの目から見たらどう映るのか気にはなるところだが・・・
【抜粋-SS-MIX2ストレージのクラウド化に関わる調査一式 報告書-】
この構成は、「表 6 SS-MIX2 ファイルを各拠点からクラウドに転送する方式案ゲートウェイ方式案 2-2」の構成に AWS 特有の制限事
項を回避するために一部変更を加えたものになっている。AWS では、オブジェクトストレージ（Amazon S3）への接続を VPC からの接
続に限定する場合で、かつ、各拠点からクラウドに Internet VPN を使用してアクセスする場合、各拠点からオブジェクトストレージに直接
アクセスすることができない。この制限を回避して各拠点からオブジェクトストレージに至るネットワーク経路を疎通させることを目的として VPC
内にプロキシ（パケット転送装置）を設置した構成を最終的な技術検証の構成とした。
みたいな形に落ち着いたらしい。ここで上げている「VPC->S3がだめよ」
というのがなんのことかよくわからなかったが・・・
dev.classmethod.jp
こちらの方法２のようなことを言っているのではないかと推測しています。ざっと記事を読ましていただく限り、
StrageGatewayだと高すぎるし、同期処理は採用方式が「ゲートウェイ」といっているので違うだろうしの消去法で「方法２」かな。というところ。
全然別のはなしですけど、S3ってあんがいセキュアに経路を構築するのが面倒な感じなんですね・・・S3そのものは安全でも経路の防護が面倒。
要件まとめ
最後のページの方に要件がまとまってました。気になるところだけつまむと
アップロード要件案
・少なくとも 1.9 PB のファイル保存が可能であること。
・3240億のファイルを保存できること。
桁がぶっ壊れてる感じがしていてとても楽しいです。
セキュリティ案件
・全国の医療機関（12 万）アカウントを作成できること。なお、ストレージのみでアカウント管理をす
る必要はなく、必要に応じて認証機能を持った別システムと連携すること。
・全国の医療機関ごとにストレージ領域を持つことができ、他の医療機関からアクセスできないこと。
・ストレージのアカウントを設定でき、アカウントごとに設定されたストレージ領域に書き込めること。
とかとか。いやー単位がえぐい。
以上。つづきはそのうち・・・AWSつよつよおじさんたちの意見が効きたい。
僕のレベルでは「へーなるへそー」としかならない。鍛錬がたりませんねぇ・・・
