1.　はじめに

大阪大学では2018年9月から，文部科学省が実施する「Society 5.0実現化研究拠点支援事業」に採択された「ライフデザイン・イノベーション研究拠点事業」を理化学研究所と日本電気（株）とともに推進している[1]．本事業は，一般社会の様々な生活シーンにおける多種多様なデータを活用することに重きをおいている．データを活用し，生活の質（Quality of Life，QoL）の維持・向上を目指した「ライフスタイル」研究，心と体の健康増進を目指した「ウェルネス」研究，楽しみと学びを実現する「エデュテインメント」研究を並行して推進することで，人と日常の健康・生活の関わりから，身体の健康，心の健康，社会的健康（コミュニケーション），環境の健康を基軸にして輝く人生（高いQoL）をデザインし，様々な技術革新と社会経済環境の変革を大学から発信することを目指している．

本事業では図1に概要を示すシステムを構築してきた．ここで収集されるデータが個人情報を内包するデータであることから，主に「個人情報の保護に関する法律」[2]およびGDPR（General Data Protection Regulation）「データポータビリティ権」[3]に定められた個人の同意にもとづいたデータ利用を可能にすべく，個人の意思決定を必要な局面ごとに同意管理できる仕組みを実装したPLR基盤を構築した[4]．個人の健康や医療・介護に関するデータであるパーソナルヘルスレコード（PHR）や日常生活で発生する個人データや生活環境データであるパーソナルライフレコード（PLR）を，この仕組みを利用して活用することによって，今まで解決が難しかった個々人によって異なるそれぞれの課題により近く寄り添った対応ができる社会の構築が期待できる．

ここで，個人と研究プロジェクト，PLR基盤との関係を整理する．まず，PLRデータ^*1を提供する個人は，PLR基盤に利用者登録する（PLR基盤では口座を開設するという）．口座開設にあたっては，個人の本人確認をマイナンバーカードや免許証等の公的書面を用いて行っている．口座開設後に個人は研究プロジェクトに参加することになるが，その際に研究プロジェクトからインフォームドコンセントの一環として説明を受ける．個人はその理解のもとに，PLR基盤のWebインタフェースにて「口座開設時に登録した，本人性確認情報が申請先の組織に提示される」という点と，「あなたのMYPLR口座に，あなたのデータが蓄積される」という点に同意する．ここで同意が得られないPLRデータはPLR基盤には蓄積されない．

また，PLR基盤にはPLRデータを活用するデータ取引事業者のための取引機能が実装されている．PLRデータのデータカタログが事業者に提示され，必要なデータを活用するために必要なデータ量を当該事業者と取引できる．PLR基盤ではPLRデータを構成する各要素に関するメタデータをデータカタログと呼んでいる．PLR基盤からデータが取り出され活用される際にも，事前にその目的を個人に開示し同意を取得している．提供同意とよんでいる．ここでもPLR基盤のWebインタフェースを用いて，提供の必要性や目的が丁寧に説明され^*2，個人の意思決定の一環として同意がなされる．PLRデータの提供にあたっては，当該事業に係るコンソーシアム^*3を設立し，会員法人に限定した提供を行っている．また，法人が会員になる際にはコンソーシアムが厳正な審査を行っている．提供同意がなされた後に，取引事業者との間で取引が成立した場合には，報奨が個人に返される機能もPLR基盤は実装している．

各研究プロジェクトが収集したPLRデータはマルチモーダルなデータであり，PLR基盤に直接蓄積するには品質に関するリスクが残るとともに，PLRデータの利用者（2次利用者）にも負担をかけることになる．そこで，各研究プロジェクトが収集したPLRデータを一旦集約するデータハブを，SaaS（Software as a Service）として利用するPLR基盤にPLRデータを蓄積する前に配置する図1のアーキテクチャを採用した．データハブの主たる役割は，研究プロジェクトからの多種多様なデータの品質の一様化にある．

以下，本稿ではデータハブのアーキテクチャ策定からその実装，運用を通してのプラクティスを述べる．2章では，PLR基盤に前置されるデータハブに関する課題を議論する．3章では，それらの課題から導き出されたシステムに対する要求およびアーキテクチャ要素を述べるとともに，データハブの実装に関して述べ，本データハブの特徴をまとめる．4章では，関連研究を述べるとともに，本データハブの特徴と対比する．5章で3年間の運用期間中に発生したインシデントを層別化し，対応策のプラクティスに関して議論する．最後に6章で本稿をまとめる．

2.　課題

データハブではPLR基盤に記録されている同意状況に制約された形でPLRデータの取り扱いが必要であるので，データハブの構築にあたっては3省2ガイドライン[5], [6]に規定された内容を考慮する必要がある．本章では，データハブ構築に際しての課題を整理する．

• (1) 蓄積されるPLRデータの品質を一様に保つためのデータ管理方針の一元化
  各研究プロジェクトで扱われているPLRデータは，その種類，量，担当者の熟練度，等々プロジェクトごとに異なっている．PLRデータを蓄積する際には，各研究プロジェクトはデータカタログというデータの設計図を作成し，審査を受けなければならない．PLRデータはこのデータカタログのもとに統制されている．これは，管理ポリシーの一元化につながる．それが強制されることで，プロジェクトごとの差異を吸収することができ，プロジェクトアウトプットを一様化できる．
• (2) PLRデータの加工処理のための計算資源に対する多様な要求対応
  各研究プロジェクトでのデータ解析にはマルチモーダルなPLRデータが利用されている．計算資源に対して高性能を要求するデータもあれば，多くのストレージ資源を要求するデータもある．倫理審査委員会の審査は研究プロジェクトごとであり，これらの資源は研究プロジェクト間での無用なアクセスがないことを保証できなければならない．
• (3) 標準に準拠したセキュリティ基準への遵守
  3省2ガイドラインには，個人情報を含むデータを適切に扱うために，情報セキュリティマネジメントシステム（ISMS） [7]等の標準規格に準拠したセキュリティ基準を満たすことを要求している．同時に，基準に対する準拠を証明する監査ログを確実に収集し，監査に対する証跡として提供できることを要求している．
• (4) サイバー攻撃に対する回復力
  経産省のガイドラインでは対象システムのライフサイクルを合意形成から合意の維持までの観点から整理している（ [6]図3–4）．ここでは，この合意の維持を回復力（resilience）として定義する．サイバー攻撃はインターネットに繋がっている限り避けられないので，その影響を最小にするとともに，当該攻撃に対しても合意を維持するための回復力の実現が重要である．

これらの課題に対して次章でアーキテクチャ設計を行い対応を検討する．

3.　設計と構築

本研究ではマイクロサービスアーキテクチャの採用を基本方針とし，当該アーキテクチャが課題解決に与える影響を議論する．次に，構築に関して議論する．実装はLinux^*4上のKubernetes [8]を利用して構築する．実行中のプロセスのルートディレクトリを変更するchroot機能や計算資源に対する名前空間を隔離する機能を利用して実装されているDockerコンテナ（以下単にコンテナ）を基本に実装手段を検討する．表1にマイクロサービスアーキテクチャを実現するシステム要件とその実装案をまとめた．

3.1　アーキテクチャ設計

マイクロサービスアーキテクチャとは大規模なソフトウェアシステムを小さなソフトウェア部品（ここではマイクロサービスと呼称）から構成する手法であり，そこには次の3つの基本的特性がある[9]．

• (1) 無特権（no privilege）
• (2) メッセージ均一性（uniform communication）
• (3) 合成（composition）

無特権とは構成するマイクロサービスには特権を持つ部品がなく同様に重要であることであり，メッセージ均一性とはマイクロサービス同士は均質な方法で相互作用を行うことであり，合成とは1つのマイクロサービスが複数のマイクロサービスに分割可能なことであり，転じて複数のマイクロサービスを合成して別のマイクロサービスとすることが可能であることである．これらの基本的特性によりマイクロサービスアーキテクチャにより構築されたシステムには次の3つの性質が具備される．

1つ目は，マイクロサービスの独立性である．マイクロサービス間の独立性のみならず，マイクロサービスの実行環境依存を切り離す．これにより用語（terminology）の適用範囲が明確化される．大規模ソフトウェア開発では複数の責任境界が用語の誤用を招き品質に対するリスクを増大させている．この独立性により，課題（1）のデータ管理方針はマイクロサービスに対する方針として一元化できる．また，課題（3）のセキュリティ基準への遵守に際しては，マイクロサービスという一様な責任境界を考慮すれば良い．セキュリティリスクはマイクロサービス内部に閉じ込められ，外部に対しては一様なリスク管理方針を適用できる．

2つ目は，マイクロサービスの加算性である．マイクロサービスは追加しても既存の環境には影響を与えないという特性を有する．もはや本番環境とステージング環境という区別は必要ない．複数のバージョンのマイクロサービスが混在できる．この性質は，課題（2）の要求の多様化に対して有効である．新しい要求に対応したマイクロサービスを追加すれば良い．また，課題（3）に対しても修正や削除に対するセキュリティリスクは考慮しなくて良い．ただし，ISMS対応には注意を要する．ISMSは基本的に引き算が原則であり，この加算性とは相容れない．この加算性がISMS基準で何らセキュリティリスクに影響してないことの保証が必要になる．

そして3つ目が，マイクロサービスの検証可能性である．すなわち開発者の意図どおりにシステムがデプロイされていることをコンピュータが確認できるという特性を有する．開発者の意図はコード化され，IaS（Infrastructure as Code）としてシステムを構成するとともに自動化される．課題（4）に対しては，サイバー攻撃の侵入口はメッセージによるマイクロサービス間の相互作用のみであり，必要な回復力はコードにより実装できる．また，課題（3）に関して，ISMSはリスクは手動操作に内在しているとする立場であり，操作に対する計画と実行履歴の記録を要求している．以上のように，マイクロサービスアーキテクチャをデータハブを実装する際の基本的なアーキテクチャとすることで，前章の課題に対して適切に対応可能である．

3.2　実装概要

構築したデータハブの実装概要を図2に示す．オンプレミスにKubernetesクラスタを配置する．サービスメッシュにIstioを利用し，テナント分離によりマイクロサービス群を配置する．当該クラスタはGitOpsによりクラスタ制御を実行する．後述する回復力を実装するためにパブリッククラウド上にオンプレミスクラスタの複製を配置する．

本システムでマイクロサービスとして主に動作させたのは，複数の研究プロジェクトからのデータのアップロード要求を受け付け，PLR基盤に格納するアップローダサービスである．その構成は図3のとおりである．研究プロジェクト共通のサービスと研究プロジェクト固有のサービスに分けられる．

• (1) FTP Pod|研究プロジェクト共通にデータアップロードを受け付けるftpサービス
• (2) 研究プロジェクト固有サービス
  • (a)Service|管理DB（PostgreSQL）
  • (b)CronJob|オブジェクトデータ分割処理（Node.js）
  • (c)CronJob|オブジェクトデータ登録処理（Node.js）

FTP Podは，研究プロジェクトごとのストレージ領域へのデータ転送で用いるため，「研究PJごとのアップローダ」の数に関係なく全体で1つのPodの構成にした．プロトコルにはFTPSを利用しているので，SSL証明書の更新作業が発生する．

SSL証明書の有効期限を1年にしたので，更新作業は年に1回発生する．

結果として当該Podの運用には定期作業が発生することになり，運用コスト削減の観点でテナントを分離せずに一元管理することにした．ここでの構成は以下の3点を考慮して運用面・セキュリティ面のリスクは低いと判断した．

• ・当該Podは閉域網にデプロイされていること
• ・各研究プロジェクトからのアクセスに対しても通信経路が保護されていること
• ・研究プロジェクトごとに1つのIDとパスワードを配付し，「研究プロジェクトごとの隔離領域」へアクセスしていること

FTP Podは，システム内外の境界部分に位置しており，その提供している機能や全体ネットワーク構成を考慮し，同一テナントにしたほうが運用コストは下がると考える．トレードオフの関係にある．

各研究プロジェクトからアップロードされたPLRデータは，分割処理と登録処理の2つの処理を経てPLR基盤にアップロードされる．分割処理では，当該PLRデータを読み込み，PLR基盤に登録するための個人データ（オブジェクトデータ）に変換する．具体的には，csv形式ファイルを読み込み，PLR基盤に登録する個人単位データ（オブジェクトファイル（json））に分割する．分割処理に問題が発生した場合には，当該PLRデータすべてに対する処理を破棄する．正常に処理が行われると，登録処理にて当該PLRデータをPLR基盤に転送し登録する．登録処理で問題が発生した場合には，PLR基盤に登録中のものも含めてすべてロールバックされ，当該PLRデータはアップローダ内の「error」フォルダに格納し，エラーが記録される．成功した場合は「完了済」フォルダに格納される．これらはすべてバッチ処理にて行われ，障害時のログメッセージに対するアクションは，管理者向けと利用者向けに標準化された手順書^*5に記載された手順で対応できるようにした．

ここでの処理過程では個人データDB，オブジェクトデータDB，ログDBから構成される管理DBに必要な記録を残している．個人データDBには，個人データを一時的に格納するとともに，分割処理により，データファイルの1行ごとに個人データとして登録される．なお，個人データは，オブジェクトデータ分割処理のデータ編集により，個人ID単位の編集処理終了後に削除される．オブジェクトデータDBには，PLR基盤に登録する際のスキーマ定義に修正したデータが格納される．個人ID単位に蓄積が行われ，登録処理終了後にデータが削除される．ログDBには処理の履歴を記録している．

3.3　コンテナ管理

本データハブでは，コンテナ管理にコンテナオーケストレーションを利用することにした．コンテナオーケストレーションとは複数のコンテナのライフサイクル管理を支援するソフトウェアである．代表的な実装には，Kubernetes，Docker Swarm [17]，Mesos [18]があるが，データハブでは後述する回復力の実装にパブリッククラウドを利用する関係でKubernetesを採用した．

データハブでは，複数の研究プロジェクトが計算資源を共有することになる．複数利用者がKubernetesを利用するための構成としては，1つのKubernetesクラスタを共有するマルチテナント型と，利用者ごとに複数のKubernetesクラスタを提供するマルチクラスタ型がある[19], [20]．データハブでは，マルチテナント型により名前空間に分けて単一のKubernetesクラスタを共用する形をとることにした．主な理由は計算機リソースの利用効率とKubernetesクラスタの管理コストである．

基本的に1つのKubernetesクラスタであるが，パブリッククラウド上は独立したクラスタを構築することにした．インターネットを経由してオンプレミスとパブリッククラウド間で単一のKubernetesクラスタを運用するには，遅延や通信障害時の動作などにリスクを抱えることになるため，独立したクラスタとして実装することを選択した．

3.4　サービスメッシュ

マイクロサービス間の通信制御にサービスメッシュ技術を利用することにした．これにより2章で述べた課題のうち，課題（3）のセキュリティと課題（4）の回復力に対する解決が期待できる．サービスメッシュを実装するオープンソースとして，本データハブでは以下の機能が実装できるIstioを選択した．

• ・トラフィック制御
  マイクロサービス間の通信をアプリケーション層で仮想化しサービスの発見，フロー制御，通信キャパシティ制御を実装可能にする．
• ・回復性，耐障害性
  サーキットブレーカや，タイムアウト処理，再実行などの機能を実装可能にする．
• ・セキュリティ
  通信の暗号化，IAM制御，およびAAAツールにより，セキュリティポリシーを適切に制御する機能を実装可能にする．
• ・可観測性
  ポリシーが適切に実施されていることの証跡となるメトリクスを計測でき，マイクロサービスのトラブルシュート，保守，最適化を実装可能にする．

3.5　システム運用監視

データハブの運用では，システム監視が必要な項目を次の4つに絞った．

• (1) ホストレベルでの死活監視，およびリソース利用量などのメトリクス
• (2) Podごとやサービスごと，あるいはサービスメッシュ
• (3) マイクロサービスの状態やログ情報
• (4) クラスタやホストマシンの操作履歴を含む監査ログ

これらの項目に対して，以下の方針で実装を行った．

• ・（1）に関しては，Prometheusによる監視を行い，収集したデータをGrafanaにより可視化する．
• ・（2）に関しては，（1）同様にPrometheusによる監視を行い，Grafanaにより可視化する．サービスごとのネットワーク利用状況に関してはIstioの機能（Kiali）を利用する．
• ・（3）に関しては，FluentdをKubernetesのDeploymentとしてノードごとに動作させ，ノードごとの標準出力を回収しElasticsearchに統合する．より複雑なログを回収したいアプリケーション用に，各アプリケーションにサイドカーとして動作させることも推奨する^*6．
• ・（4）に関しては，OSレベルのauditdでの監査ログ取得するとともに，GitOpsでクラスタ操作を記録する．

これらの構成について図4に概略を示す．監査ログについてはKubernetesの構成ノードすべての監査ログをauditdにより収集し，監査ログとして分離格納している．また，Kubernetesの操作ログをkubeapiサーバで取得することができる．現状ではKubernetesのマニフェストをArgoCD経由で操作させることによって，Gitリポジトリの履歴にクラスタ操作ログを残している．

なお，上記の監視系サービスは，オンプレミスの隔離されたテナント内にデプロイした．提案するデータハブはハイブリット構成をとっているので，監視系サービスをパブリッククラウド上のマネージドサービスを利用することもできたが，今回は監査ログに対する責任範囲を外部には広げないという上位要求によりオンプレミス環境にデプロイした．

3.6　回復力の実装

本データハブでは，Gitリポジトリに格納されたKubernetesマニフェストをArgoCDを用いてKubernetesクラスタに同期する形でGitOps運用を行う．マイクロサービス開発者がGitリポジトリにマニフェスト変更をマージリクエストとして発行し，運用管理者がマージリクエストを確認することでクラスタの状態変更操作を承認して，クラスタ状態の修正を行う．このような形態とすることで，クラスタ状態の変更動作はマージリクエストのレビューによってチェックされ，クラスタ操作が基本的にGit更新履歴として保持される．また，操作ミスが発生した際には容易に過去の状態に戻すことが可能である．

このGitOpsの仕組みを用いて，オンプレミスクラスタからパブリッククラスタへの回復力を実現した構成図を図5に示す．オンプレミスクラスタとパブリッククラスタ間でのマニフェストの設定の差は，Kustomize（helmなどのパッケージマネージャでもよい）を用いて設定差を吸収するよう指定しておく．本構築システムでは，オンプレミス環境とパブリッククラウドの差は，nfsサービスのIPアドレスとpathのみである．その差分設定のみのマニフェストを用意し，Kustomizeツールを通すことで差分のみ変更されたマニフェストをパブリッククラウド側のクラスタに適用できる．ArgoCDサービスはあらかじめパブリッククラウドのクラスタでも動作するようにしておき，サイバー攻撃を含む外部要因によるオンプレミスサービスの停止時などサービスを移行する必要がある際に，ArgoCDサービスを立ち上げ，サービス切り替えを行う．インターネット向けサービスを運用している場合には，DNSを更新することでサービスIPアドレスをパブリッククラウド側に切り替えることが可能である．

3.7　セキュリティ実装

本データハブでは，Kubernetesのセキュリティ対策を実装する．CIS（Center for Internet Security）ベンチマーク[21]を実行し，121項目の内，7件のFAILと39件のWARNの内容を検討し，必要な対策をデプロイすることにした．また，セキュリティポリシーの適用をマイクロサービス開発者と運用管理者の2つのロールに分けて設定する．前者にはNameSpaceに対する操作権限のみを与える．後者にはクラスタを構成するホストへのログイン権限を与える．両者に共通のポリシーとして，VPN接続にてデータハブシステムにアクセスする際には，アクセス元IPアドレス制限による保護を追加するとともに，証明書によるKubeletへのアクセス権限を与える．また，より厳しい条件としては，運用途中から次の項目を追加することにした．

• ・一般的なマイクロサービス開発者にはGitへのアクセス権限のみ与える．
• ・運用管理者がレビュー，マージリクエスト承認により必要なマイクロサービスをデプロイする．

3.8　データハブの特徴

ここで，本稿で構築したデータハブの特徴を簡単に3つにまとめると次のようになる．

• ・各研究プロジェクトからのPLRデータの品質はデータカタログにより一様化され，PLR基盤を通して2次利用に供される．
• ・セキュリティ基準に準拠したPLRデータの加工処理に関する証跡が記録されている．
• ・PLRデータのライフサイクルにおける責任境界が個人の意思決定に基づくガバナンス下にある．

4.　関連研究

大阪大学病院では院内データの流通を管理する仕組みを，EHR（Electronic Health Record）の拡張としてPHR（Personal Health Record）を定義し，その1次利用と2次利用の両面に関して試行している[22]．ここでは，PHRデータの取り扱いに関しては，個人からの医療情報銀行への信託にもとづき，医療情報銀行に管理責任がある．本稿との関係では，本データハブとPLR基盤を含めた構成と対比され，院内に配置されたゲートウェイサーバが本データハブに対応する．データの2次利用まで考えた場合に1次利用でのデータ品質に対する2次利用での影響をどこまで吸収できるか懸念が残る．たとえば，DMBOK [23]では13章でデータの利用目的に合致した品質保証の重要性を指摘している．一方，本データハブではPLRデータの品質は研究プロジェクトによりデータカタログとして定義され，2次利用に際して利用者に提供される．その際の個人の2次利用に対する意思決定はあくまで本人にある点は同じである．

PHRデータを個人が所有するスマートフォン等のデバイスに記録する分散PDSに関する研究がある[24]．ここでは，PHRデータそのものは，個人が保有し，管理する点で，すべての責任が個人に帰属していることを特徴とする．その点で個人情報保護法の改定に対する耐性が最も高い方法でもあると言える．一方でデータ品質に対しては，個人の責任を超えるケースもあり，またフェイクデータの懸念が残る．PHRデータのアクセス可能性を保証するにも何らかの対応を必要とする．さらに，自分のPHRデータが漏洩しないように防御するのも個人の責任である．一方，本データハブではデータはPLR基盤に蓄積され，個人の関心は本人のPLRデータの利用目的に対する同意のみである．

個人情報を内包するPHRデータを蓄積するためには，蓄積に至る過程におけるデータ管理に，規制の改正を含む環境の変化に対する耐性を始め，セキュリティに対する個人起点のガバナンスが必要である．Ohmuraらは，責任境界を超えてデータを集積する仮想データレイクと，データレイク内のデータをサンドボックス内で処理する仕組みを提案している[25]．ここでは，仮想データレイクに集積されるのはデータそのものではなく，データへのリンク情報を含むメタデータである点に特徴がある．しかし，責任境界は法人と法人の間の境界であり，個人を起点とするデータガバナンスに懸念が残る．一方，本データハブでは個人がデータガバナンスの起点であるが，個人は利用目的に関しての同意のみに関心をもち，データガバナンスに係る他のことは本データハブ（およびPLR基盤）が責任を負う．Ohmuraらのサンドボックスの仕組みは本データハブとテナント分離と同じ概念である．

Riscoらはオンプレミス環境とクラウド環境を連続体（continuum）として捉えたサーバーレスのFaaS（Functions as a Service）環境を構築し，データサイエンスワークフローを実行する仕組みを提案している[26]．個人情報を含むデータの処理は規制遵守のためオンプレミス環境で行い，高度の弾力性を必要とする計算をクラウド環境で行うことができる．PHRデータを対象としたデータガバナンスに関しては，クラウド環境の厳密に管理されたサービスを用いて実装できる．しかし，責任の境界が複雑になるため，説明責任の遂行リスクを高める．一方，本データハブではRiscoらとはパグリッククラウドの位置付けに違いがあるとともに，FaaSより下位に制御層を置いており，より多様な計算資源要求に対応できる（たとえば，AWS LambdaではCPU性能はメモリ量と連動している[27]）．

5.　議論

本章では，構築したデータハブの妥当性を次の3つの観点から議論する．

• ・サービス運用，特にデータ蓄積に関するプロセスの観点
• ・情報セキュリティマネジメントシステム（ISMS）認証取得の観点
• ・運用期間中に発生したインシデント対応の観点

図6に本データハブの運用期間のイベントを時系列で並べた．以下，この系列にそってにプラクティスを議論する．

5.1　データ蓄積

PLR基盤への研究プロジェクトからのデータ蓄積に関する一連のプロセスを支援する目的で図3に示した構成で複数のマイクロサービスを実行した．データをPLR基盤に蓄積するには，研究プロジェクトは適切な事前承認を得る必要がある．その際に，研究プロジェクトはデータカタログを準備する．データカタログは，データ提供者が蓄積同意の際の確認目的で利用されるほか，データ利用者が購入するデータを検討するためにも利用される．データハブ管理者は当該承認を待って，共有ストレージからプロジェクト固有領域を払い出し，データを一時蓄積するために研究プロジェクトに対してアクセスアカウントを発行する．そして，複数のPodから構成され，当該アカウント権限で実行されるアップローダサービスをデプロイする．また，研究プロジェクトでは，研究データを蓄積するにあたって，データをPLR基盤蓄積に適した形式に整形する．実験の参加者の個人名は被験者IDに置き換え，データはCSV形式で記述する．マルチメディアデータや時系列データはCSV形式では扱い難いので，データをハッシュ化し，ハッシュ値をデータとして蓄積する．その際の原データは研究プロジェクトで保管する．

上記にて準備されたデータは，図3記載のFTP Pod経由で研究プロジェクトごとの固有領域にFTPアップロードする．分割機能PodはCronJobとして定期的に起動され，固有領域にあるデータをPLR基盤に蓄積する適切な単位に分割する．別途CronJobとして定期的に起動される登録機能PodがPLR基盤が提供する登録APIを利用してPLR基盤に蓄積する．

3年間の運用期間を通して，4つの研究プロジェクトのアップロード処理を行った．上記3.5節のシステム運用監視によりアップロード処理のログを検証した．システム動作の健全性，およびPLR基盤の蓄積状況とアップロードデータの整合性を確認した．上記プロセスでは，もっぱらデータハブ運用組織の人手に頼っている処理が多かった．理由の1つに，扱うデータが機微なデータであるために，上述するISMS認証取得に十分な証跡を残す必要があったからである．一方で，研究プロジェクト側のデータ整形作業は自動化が可能であったがプログラム開発のリソースが不足しておりシステム化は実現できなかった．

5.2　ISMS認証取得

データハブにて取り扱うデータには個人情報を含むので，適切なデータハンドリングがデータハブ運用組織によりなされていることを第3者機関が認証することで，セキュリティに関しての対外的信頼性を確保することを目的に，ISMS認証を取得することになった．その際にシステムに対する変更要件は発生しなかった．主な理由として，上記3.5節で構築したデータハブシステムを構成する要素技術が既にISMSの求める要求に対応可能な手段を提供済みであったことが挙げられる．上記3.7節でのセキュリティポリシーの設定により，認証にあたって設定した認証スコープに対して適切な証跡を残すことができた．課題としては，証跡の記録を監査にあたって別途準備する必要があった．図7に設置したISMS推進体制を図示する．

ISMSは責任境界を明確にし，国際規格ISO 31000 [28]に基づいたリスクマネジメントとしてセキュリティ対策を実装するフレームワークと考えることができる．一方で，マイクロサービスアーキテクチャでは明確な責任境界が織物のように絡まっている．APIによるサービス同士の接続という横の糸と，仮想化によるレイヤー間の接続という縦の糸である．ISMSが想定する説明責任の構造と，マイクロサービスアーキテクチャによる説明責任の構造とは，粒度が違い，複雑度も違う．その影響が証跡の記録と監査との関係に具現化し，課題になったと考えられる．

5.3　インシデント対応

2020年4月から2023年3月までの運用期間を通してインシデントは20件あった．大きく次の5つに分類できる．各々に関して代表的なインシデントの内容とその対策，および再発防止策を議論する．

更新　システム要素を更新する際に発生

キャパシティプランニング　リソース不足により発生

構成管理　構成情報のエラーにより発生

通信何らかの原因で通信不可の障害発生

セキュリティパッチ　緊急セキュリティ修正更新が必要になった

5.3.1　更新

多くのインシデントは，何らかのシステム構成要素を更新する際に発生した．最も影響の大きかったのはKubernetesの更新時に発生したインシデントであった．この更新は以下の大きな変更を伴っていた．

• ・サポートコンテナランタイムの変更（dockerからcontainerd）
• ・API名称の変更

このような大きな影響を及ぼすアップグレードの場合，原因調査，対策などに数時間程度の時間を必要とすることがあった．バックアップクラスタでの事前検証は行っていたが，オンプレミス環境でのみ発生した現象もあり，ローリングアップグレードなどダウンタイムを引き起こさない方法で行う必要がある^*7．

また，各種証明書更新忘れによりkubeapi操作ができなくなった．実際にデプロイなどを行わないと気づかないため，管理者が認識できないことがあった．対策として，年オーダの更新計画を立て，アップグレード時期を年間線表に組み込んだ．

本システムは約3年以上動作し，その際にKubernetesのアップグレードを繰り返しながら運用を行った．Kubernetesの動作に問題は発生しなかったが，Istioは途中で動作しなくなってしまった．その時点でIstioは構築当初と比べ，インストール方法・構成など大きく異なっており，初期構築時のマニフェストを自力で修正して対応することは困難であった．本システムにおいてIstioの必要性は低かったため，その時点でIstio関連サービスを取り除くなどの対処を行った．Kubernetesは頻繁にアップグレードされ，長期にわたりアップグレードを繰り返した場合の検証などが行われているとは考えにくいため，本来は定期的に新規クラスタを構築しなおし，サービスを移植するといった対策が必要なのではないかと考える．

5.3.2　キャパシティプランニング

キャパシティプランニングに関して，特に性能見積もりが十分でなかったことが要因で発生したインシデントがあった．当初はElasticsearchの中長期的な運用を想定しておらず，sharding数など初期設定のまま運用していた．これにより，メモリ利用量の肥大化やElasticsearchコンテナが起動しなくなる，などの問題を引き起こした．システムやインデックス構成を見直し，サービスを再構築して復旧を行った．

5.3.3　構成管理

構成管理に関して，特にPodのマニフェストファイルのエラーにより発生したインシデントは，Kubernetesの更新によりAPI名変更（古い名称での利用が不可）になり，マニフェストの修正が必要になった．

5.3.4　通信

ホストネットワークの一時的障害が発生し，サービス性能が一時的に低下することがあった．コンテナサービスとしては安定的に動作していたため，問題に気づくのが遅れたことがあった．ホストネットワークレベルの監視などを増やす必要がある．

Kubernetes内のCoreDNSの障害が発生し，Kubernetes内でServiceの名前解決ができなくなることがあった．CoreDNSのstatusとしては正常動作している，毎回名前解決ができない訳ではない，など原因が不明であり，NodeLocal DNSCacheを導入することで解決した．

5.3.5　セキュリティパッチ

運用期間中には多くの脆弱性が報告され対策が必要になった．Apache Log4jの脆弱性（CVE-2021-44228）はその代表であり，データハブもその影響を受けた．具体的には，データハブで動作しているPodのシステムソフトウェア調査を行い，脆弱性対応の必要性の有無の確認作業を行った．実際にElasticsearchとKibanaの更新作業を行った．

5.4　内省と後続システムに向けて

5章の議論を通しての内省として次の3点を記す．1つ目は，パブリッククラウド上に構築したバックアップクラスタは，災害対策という観点のほかに，本番サイトでのホストOSやKubernetesの更新を事前検証ができるという利点があった点である．ただ，バックアップクラスタはKubernetesの導入に別のツールを利用^*8したことにより，バックアップ側で起きなかった問題が，本番サイトで発生することがあった．このような観点ではできる限り同じ環境を用意することが望ましいと考える．

2つ目は，3年間の運用を通して障害やエラーなどのSlack通知が効果的だった点である．省工数で運用する都合もあり，日々管理ページや管理アプリにアクセスするのは難しく，通知に基づいてログや実際のシステムを確認するという順になりがちであった．実際のオフィスではディスプレイに常時ダッシュボードを表示するなどのアプローチも考えられるが，コロナ禍でリモート勤務が増えると，常に表示し続ける環境を用意することが困難であるため，その点でも通知機構は有用性が高いと考える．

3つ目は，仮想マシンのオーバーヘッドに関するリスクを考慮し，データハブをベアメタルサーバー上に構築したが，Kubernetesの更新に際してのインシデントの際も，仮想マシン上であればダウンタイムを最小にできたと考えられる．

以上の内省にたつと，様々な後続システムが構想される中で，ここでは，次の3点を記す．

• ・個人の意思決定に基づく同意管理は，多様な要求を考慮する必要があるため俊敏性を高める必要があり，データハブの機能とPLR基盤の機能はUX含めた一貫性のあるアーキテクチャのもとに構築する．
• ・ハイブリッド構成はTCOを考慮すると本支援事業の目的には合致した構成ではなかったので，パグリッククラウド上にマネージドサービスとセルフマネージドサービスのバランスのもとに構築する．
• ・データを提供するという視点に欠けていたので，データの2次利用という利用目的の観点からのデータマネジメントを組み込む．

6.　まとめ

本稿では「Society 5.0実現化研究拠点支援事業」において構築されたPLR基盤に対して個人情報を含むデータを蓄積するためのデータハブに関して述べた．本データハブは，高品質のデータを2次利用目的で蓄積するために必要な処理を実行する環境であり，マイクロサービスアーキテクチャに基づいて構築した．3年間の運用期間で得られたプラクティスは我々が次のシステムを構築するに際して十分なインサイトを与えてくれた．現在，後続のシステムを構築中であり，そこでのプラクティスが得られ次第，本誌で発表する予定である．

謝辞　原稿を注意深くお読みいただき適切な助言をいただいたことに対して査読者の皆様に感謝します．本研究活動は，文部科学省によるSociety 5.0実現化研究拠点支援事業（グラント番号：JPMXP0518071489）によって行われたものである．