COVID-19 の濃厚感染を安全に追跡するアーキテクチャー

新型コロナウィルスの感染者との濃厚接触を追跡する各国の試み

世界中で感染拡大が続いている新型コロナウィルスですが、ワクチンや治療薬ができるまで、感染を抑えるには濃厚接触を避けることが重要です。

濃厚接触を避けるために「ステイホーム」は重要ですが、感染のクラスターを早期に発見して対処する必要があります。感染者への聞き取り調査だけでは不十分なため、スマホなどを使ったるデータ収集に向けての取り組みが進んでいます。

世界で開発が進む濃厚接触の追跡アプリ、ロックダウン解除後の救世主になれるか https://xtech.nikkei.com/atcl/nxt/column/18/01279/041600001/

その中でも最近話題になったのは、Apple と Google が共同で iPhone、Android のスマホに追跡用のアプリを開発し、最終的にはプラットフォームに組み込むというものでした。

AppleとGoogle、
新型コロナウイルス対策として、
濃厚接触の可能性を
検出する技術で協力
https://www.apple.com/jp/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology/

韓国や中国では位置情報を使用して感染者を追跡し、濃厚接触を追跡できるような仕組みが使われています。これは強力ですが、個人情報が保護されるのか?という観点から見ると不安な方も多いでしょう。

一方欧州では、「GDPRを完璧に満たす」アプリを開発を目指し、プライバシーに配慮しながらもデータを収集する方針のようです。AppleとGoogleも同様の方針ですが、日本を含め、多くの国ではこちらのアプローチの方が好まれることは間違いありません。

An Architecture for Secure COVID-19 Contact Tracing

さて、エンジニアとしては、どういう実装になるのかに関心があります。このアプローチを実装するにはどうすれば良いかという観点について技術的に説明しているブログがあったので簡単に紹介します。
(いずれは翻訳したいですが、、、時間があるかどうか。)

An Architecture for Secure COVID-19 Contact Tracing - Cloudera Blog
This post describes an architecture, and associated controls for privacy, to build a data platform for a nationwide proactive contact tracing solution. Backgrou...

データモデル

  1. アプリのインストールごとに UUID を発行。個人情報は収集しない
  2. デバイスのBluetooth情報、アクセスしたBluetoothのMacアドレスへのアクセスが必要
  3. UUIDはユーザーが取り消すことが可能。それには秘密鍵や生体認証が利用される
  4. 観測した日付
  5. 追加データセットとして、加入者属性や位置情報(加えて、体温が高いといった情報も)

システムアーキテクチャー

OSS プロジェクトを使ったアーキテクチャーは、一貫性、整合性、可用性、セキュアである必要がある。

データの収集

ヨーロッパの国での3000万人を対象とし、一人が1日あたり200人を超える接触の可能性があると想定。つまり、1日あたり60億イベントが想定される。高可用性のような耐障害性も必須。

スマホ -> Web Farm -> HTTP(REST-API ) -> Apache NiFi -> HTTP(REST-API) -> データレイク

スマホから Web FARM にデータが送られ、そこから REST-API 経由でKafka へと送られる。Kafka のメッセージを RESTーAPI 経由で NiFi が消費し、データレイクへと転送する。セッションはTLSで保護される

ストリーミングでの分析が必要な場合、Spark Structured Streaming や Flink、Kafka Streams などが使用できる。

データストレージ

データウェアハウスレイヤーには、高スループットでの取り込みができ、ランダムアクセスも可能でスキャンも速い、Kudu を使用する。(構造化データなので)
Kuduに保存されたデータは、

  • Impala でSQLによるインタラクティブなデータ分析
    • Ranger による属性ベースのアクセス制御が可能
    • SQL クエリの監査も可能
    • Navigator Encryptによるディスク暗号化
    • SparkとHiveでのクエリも可能

アラート

感染が疑われることを示すアラートメッセージを受信すると、感染先を追跡するアルゴリズムが実行される。感染者のUUIDとBruetooth情報により、観測されたBluetoothのMacアドレスを簡単に追跡できる。逆方向の検索も可能。

優先度を分類してアラートを送るリストを作成し、該当する個人のデバイスにアラートを生成。

アラートの仕組みは Kafka の pub/sub の仕組みを使う。Kafkaはデータの保持期間を指定できるので、48時間など潜伏期間を超えたメッセージを自動削除可能。

分析と機械学習

感染率のモニタリングやデータ人対して機械学習をなどを行う場合、蓄積したデータへのアクセスが必要になる。セキュアにするため以下を満たさなければならない

  • データは全て(転送中、保存後)暗号化される
  • システム管理者はデータセットにアクセスできない
  • アクセスは認証および承認された個人によって行われる
  • 全てのアクセスは監査される

このアーキテクチャーでは全てのアクセスはImpalaを使用し、Rangerで権限の設定、監査を行う。

ガバナンス

AtlasやNavigatorを使用した適切なデータガバナンスが重要。

  • 関連するデータはどこにある
  • そのデータをどう解釈して使用するか
  • データがどのように作成され変更された可能性があるか
  • データアクセスはどのようにセキュア化し、保護されているか
  • データアクセス権を持つ人とその使用の監査

詳細は原文をご覧ください。

詳細は原文をご覧ください。

Apache NiFi と Apache Kafka を

コメント