「まもりあいJapan」 開発試行錯誤の裏話 後編

引き続き、モンスター・ラボ CTO の平田です。接触確認アプリ「まもりあいJapan」プロダクト開発チームで開発をしています。「まもりあいJapan」は5/18にコードを公開しました。開発試行錯誤の裏話 ~前編はこちらです。

BLE の課題をクリアすればオッケーではなかった。個人情報保護、データプライバシーの課題

前編の通り BLE の課題は大きいですが、「まもりあいJapan」の開発で最も大きな課題となったのは個人情報保護やデータプライバシーの観点での設計方針だったと思います。総論としては企画チーム河津さんの記事をご参照ください。

接触確認アプリは設計によりいくつかの類型に分類されます。以下の会議で説明された「資料１－１：接触確認アプリの導入に向けた取組について（案）」がよくまとまっています。

第３回 新型コロナウイルス感染症対策 テックチーム Anti-Covid-19 Tech Team 開催 | 政府CIOポータル

当初、「まもりあいJapan」は、この分類でいうと、Bluetooth型-個人特定型-中央サーバ処理型に近く、個人情報として電話番号を取得する方針で進めていました。企画チーム/渉外チームが自治体/医療機関とのヒアリングを重ねた上で、クラスタ対策班や保健所での業務効率化・運用負荷軽減といったことも考慮して、電話番号をキーに陽性者を登録するというフローが最も現実的だろうという仮説を持っていました。
後に陽性患者は厚労省の新型コロナウィルス感染者等情報把握・管理支援システム（仮称）で管理されるため、接触確認アプリとしては個人情報保護、データプライバシーをより重視し、個人を特定する情報がより少なくなるBluetooth型-匿名型-スマホ端末処理型へと設計を変更しました。アプリの設計の根幹をなす部分であり、バックエンドで生成管理していたIDをフロントエンド側で生成するようにしたり、電話番号の取得をやめたことで生じるもろもろの設計変更がありました。データ構造やフローは何度も綿密に練り直され、仕様が毎日変わる、仕様が決めきれない混沌とした時期もありましたが、最終的にはデータプライバシーの配慮を強めた良いアーキテクチャになったと思っています。

Firebase Authentication SMS認証 -> 匿名認証

当初、電話番号の取得のためSMS認証を実装しましたが、フレキシブルなFirebase Authentication を採用しました。SMS認証では電話番号がユーザーのキーになるため、ユーザーが複数台のデバイスを使っていたり、電話番号がリサイクルされる場合の課題もありましたが、バックエンドの Firebase Admin SDK で認証フローを補強することで課題は解決できました。
その後の電話番号を取得しないという大きな仕様変更でも、認証部分については、Firebase Authentication の匿名認証に変更することで数時間の内に対応でき、やはり柔軟で素晴らしいサービスだと感心しました。

1億ユーザーが使うスケーラビリティとコスト

多くのユーザーに使われないと接触確認アプリとしての効果は限定的になります。どのように普及を後押しするかという課題は大きいですが、仮に1億人のユーザーが利用しても問題が起こらないバックエンドを構築する必要があります。これについては早くからスケーラブルな Serverless + Node.js で行くことで決まりました。メンバーお気に入りの NestJS を使用し、Serverless + Node.js + TypeScript + NestJS で開発しています。コードを実行する環境として、どのクラウドを選ぶかという議論は、技術以外の課題もあり二転三転しましたが、最終的には慣れている AWS を選ぶことにしました。AWS Lambda には Provisioned Concurrency の機能もありました。どの構成でも少しの変更で動く Serverless Framework の強力さに改めて感心しました。FaaS で REST API を作るデメリットにエンドポイントごとに Function をデプロイするために環境変数も含めて管理が煩雑になるというものがありますが、この構成ではルーティングはひとつの Lambda の中で行われるため、その問題はなくおすすめです。スケーラビリティで心配していたのはデータストアの Firebase Cloud Firestore ですが、16台のサーバインスタンスを使い負荷テストを行い 9500rps の負荷をかけましたが、API Error は1件のみで、Serverless のスケーラビリティには感心しました。

1億ユーザー到達時のインフラコストの試算を簡単に行いましたが、全ユーザーに対して感染者との濃厚接触を通知するための交換用のテンポラリデバイスIDを配信するためのネットワークコストが高いことが課題になりました。下図の赤丸の部分です。

コンテンツはユーザー毎にダイナミックではなく、アクセス数も多くなるので API ではなくファイルをクラウドストレージから配布するのが最もスケーラブルで安くなると考えました。それでも1億ユーザーから頻繁にアクセスがあり、それが従量課金となるとネットワーク配信コストは安くはありませんでした。ユーザー数が少ない内は問題にならないですが、増えるにつれて高くなります。現状、Firebase Cloud Storage での配信ですが、コスト重視でいくならば重量課金ではなく定額の CDN の Cloudflare でファイルを配信するような変更もできると考えています。Cloudflare は漫画村などのネガティブなイメージもありますが、コストが重要であるならば有力な選択肢と考えています。

おわりに

この一ヶ月半の間、作りながら仕様を固めるループはうまく機能し、UXUI、企画、開発を中心にチームが連動し非常にエキサイティングで濃密な日々でした。特にQAを含む開発チームのメンバーには、仕様確定が難しい中、土日、GW返上で開発を続け、仕様を形作ってくれたことに深く感謝しております。また自治体/医療機関/プライバシーやセキュリティ専門家の皆様/プラットフォーム開発者の皆様の方々にご支援いただき、接触確認アプリが今の形にたどり着くことができました。この場を借りて深く御礼申し上げたいと思います。Code for Japan が「まもりあいJapan」をリリースすることはなくなったのですが、この間のプロセスや議論が日本での接触確認アプリの土台になったと思います。日本における今後の取り組みは厚生労働省主幹で進められますので、最短でのリリースに向けてシビックテックの力で貢献させていただきたいと思います。