AWSが支えるCOVID-19との闘い③─刻々と変わる可視化ニーズをAWSクラウドでどう実現したか？― IQVIAジャパンに訊くELT処理・BIダッシュボードの実装・運用

全4回に渡ってお届けする連載ブログ「AWSが支えるCOVID-19との闘い」。前回に引き続き、第3回では、システム実装を担当したIQVIAジャパン様に実装の工夫、AWSクラウドによるサーバーレスな実装の詳細についてご説明いただきます。

プロジェクトへの参画と難局打開を志すデータサイエンティストによるチーム結成

「LINEパーソナルサポートに集積された情報を解析して都道府県にフィードバックしたいが、これを手伝ってもらうことは可能か？」と宮田先生から電話いただいたのは土曜の朝でした。新型コロナウィルスという難局の打開に貢献したいと思っていた矢先だったので即決で快諾しました。

すぐに社内のデータサイエンティストや技術者に声をかけたところ、休日だったにも関わらず、皆から参加表明の返信があったのに感動したのを覚えています。

まずは都道府県へのフィードバック内容を決める必要があったので、慶應義塾大学の先生方と打ち合わせを繰り返しながら、フィードバックレポートのイメージ（図１参照）を数日で作り上げました。

図１：実装前の議論に利用したフィードバックレポートの提案資料

当初は週単位でのレポートでのフィードバックを想定していましたが、陽性患者数が急増するという切迫した状況だったため、「日単位での更新」「都道府県のユーザーによる自由解析」が望ましいというのが関係者の総意となりました。

そこで、IQVIAジャパンは医療ビッグデータの解析ツールを多く開発していたので、そのノウハウを活かしたBIツールによるダッシュボード開発を慶應義塾大学に提案し、その方針について快諾いただいたところから開発が始まりました。

各都道府県に迅速に展開できるBIツール/ダッシュボードの選定

開発にあたってまず決断しなければならなかったのは、各都道府県に公開するダッシュボードを何で作るか、ということでした。社内に豊富なナレッジが蓄積されたBIツールを中心に検討していたところ、AWS に造詣の深い部門からAmazon QuickSight (WEB/ブラウザベースのクラウド駆動の高速なビジネスインテリジェンスサービス)の機能および、SPICE (インメモリ計算エンジン) によるパフォーマンス向上について情報共有をしてもらったことをきっかけに、QuickSight に興味を持つようになりました。データ処理基盤と同じプラットフォームのサービスの一つとして運用できる点にも魅力があり、プロトタイピングという位置づけで QuickSight を使ったレポートを作り始めました。

実際に作業を始めてみると、Web ベースでありながら、動作はデスクトップのソフトウェアと同じくらい軽快で、操作結果がリアルタイムにフィードバックされるので、開発効率という観点では嬉しい驚きでした。また、ダッシュボード、チャート、フィルタなどの機能は他の BI ツールと遜色なく、一部の複雑なビジュアルを除いて機能面で困ることはありませんでした。このため、当初想定していたよりも形になるスピードが速く、また各方面からのフィードバックが良かったこともあって、QuickSight で開発を維持することに決めた、という経緯がありました。

都道府県の担当者の方々からは、公開当初から「直感的で分かりやすい」というフィードバックをいただいていました（図２参照）。アマゾンウェブサービスジャパンのコンサルタントから、QuickSight 自体、ユーザーが直感的・探索的に操作できることを重視してデザインしていると伺いましたが、今回はこのデザインポリシーがうまく機能した好例と言えます。

この分かりやすさを最大化するため、表示する内容にもこだわりました。1つのダッシュボードに掲載する情報を都度十分に吟味し、回答者数・有症率・推定感染率という指標を、デモグラフィック・時系列・地理の3つの観点に分類して表示することで、1つ1つのダッシュボードが明確なメッセージを提供するようになっています。

図２：Quicksightにより各都道府県の担当者へ提供したダッシュボード（サンプル）

一方、各都道府県が他県のデータが見られないようにしたい、というセキュリティ要件もありました。これについては QuicksightのRLS機能（Row-Level Security：行レベルセキュリティ）や QuickSight の動的パラメータ機能を使うことで実現でき、わずか数クリックの設定だけで実装できるため、優位性がある機能だと思います。

ビジュアル面では、プリセットされたテーマの中から「Midnight」を選択し、ダークネイビーをバックにネオン系のアクセントカラーという今風のテーマのおかげで、デザイナーが設計したかのようなモダンなダッシュボードを数クリックで作ることができました。

ダッシュボードの裏側のデータ処理は、データの規模や開発効率、運用のしやすさを考慮して、Amazon Relational Database Service(RDS)（クラウド上で稼働するリレーショナルデータベース）を使用した SQL ベースの ELT処理（Extract：抽出、 Load：書き出し、Transform：変換）で実装し始めました。33都道府県向け(11月末時点：自治体や省庁の公式アカウント一覧）のダッシュボードに必要な機能のうち、実に３分の２を、ボランティアの開発者２～3名と少ないメンバーでかつ、開始から2ヶ月というスピードで提供できたのは、QuickSight のWEBベースで開発/共有できる使い勝手の良さとインメモリエンジンSPICEによる動作の軽さ、形にこだわらず結果を出力し、先生方のフィードバックをすぐに反映する事を優先した実装メンバーの方式選択の賜物と言えます。ただ、その裏でバッチ処理のコントロールはすべて手動で行っていました。想定外のデータの混入によるエラーなどで開発者が夜間や土日を使ってサポートしていたこともあり、その負担の軽減が大きな課題でした。

運用負荷低減やユーザニーズへの柔軟な対応の為にサーバーレスアーキテクチャへ移行

開発がひと段落したところ見計らって、AWS の Solution Architect にアドバイスをいただきながら、AWS Step Functions、AWS Lambda、Amazon Simple Notification Service (SNS)、Amazon CloudWatch 等のサービスを結合したサーバーレス・アーキテクチャに移行することにしました（図３参照）。サーバーレス化よって、複数のファイルにまたがる SQL 文の連続実行のスケジューリングや各ステップのグラフ化（図４参照）、簡素化、エラー処理やリカバリー処理の自動化、Microsoft Teams へのエラー通知などを実現し、運用側の負担を軽減することができました。

本格運用が始まると、ユーザーのニーズにも変化が生じ、アンケート回答のスキーマが数回に渡って変更されました。変更自体は自然であり歓迎するべきものですが、この仕様変更を反映したデータフィードの詳細が開発側の手元に届くまでの時間が非常に長いという問題を抱えていました。また、一部にはドキュメントと現物の不一致もあったため、最終的には自分たちで実際のファイルを紐解いて、処理を変更しなければなりませんでした。処理の対象の合計ファイル数は 8,000 ファイル以上あり、変更されたファイルもタイミングも都道府県によってまちまち。ファイルごとのスキーマを正確にとらえるのは非常に困難でした。

この問題を解決するため、メインのバッチ処理とは別の State Machine を用いて、 Amazon Simple Storage Service (Amazon S3) 上のすべてのファイルのヘッダーをスキャンし、この結果から全ファイルのスキーマカタログを作成するバッチ処理を構築しました。続いてメインの State Machine からこのカタログデータベースを参照し、希望する情報を持つファイル群とそのスキーマを特定して動的にロードする仕組み（セマンティック・データ・ロード機構）を作り上げました。この機構は1日1回スキャンしカタログデータベースをアップデートすると共に、新しいスキーマを捉えた際にはその詳細を専用のファイルに出力しメンテナンスを促す仕組みを備えており、データ提供側からの変更通知を待たずしてその変更にリアルタイムに追随することができるという優れものです。

このセマンティック・データ・ロード機構のおかげで、回答の時期や都道府県によって異なる対象ファイルを透過的に扱うことができるようになり、データ処理のスピードやデータ品質の向上に大きく寄与しました。途中、慶應義塾大学の先生方からアドホックなデータ要請もありましたが、迅速に回答し続けることができたのは、この仕組みによるところが大きいと思います。

実装には、S3、Step Functions、 Lambda などのサーバーレスサービスのほか、boto3ライブラリ(Python用 AWS SDK )、AWS_S3 extension（RDSによって提供されるPostgreSQL用S3データインポート拡張機能）、ユーザー定義関数 (UDF) などを使用しています。今回の仕組みとしては、既存SQLの修正は最小限にとどめて、迅速にサーバーレス化することを念頭に設計しました。そのため、RDSのPostgreSQLから直接S3のデータをロードするaws_s3 extensionを採用し実現しました。こちらの処理はゆくゆくはLambda内での処理に変更しても良いかと考えています。また、もう1つの案として、Amazon Athena (サーバーレスなSQLクエリサービス) も検討しましたが、ファイルの構造、エンコーディング等の諸要件がうまく合致しなかったため、boto3 で1つ1つファイルを読むアプローチを採っています。結果として、サーバーレス機構の上に S3 ファイルの動的ローディング機構を作るという、いかにも AWS らしい、疎結合でスケーラブルなソリューションになったと思います。

図３: AWSのサーバーレスサービスおよびCloudFormationによるIaCで開発したELT処理

図４：Step Functionsにより複雑なSQLを1SQL/1Stepで管理し運用負荷低減を実現

より効率的な開発を目指しIaC (Infrastructure as Code) をベースとした開発へシフト

導入初期の本番運用と追加開発が並行していた時期には、開発中のプログラムで解決が困難な不具合に遭遇し、「〇〇が動いていたあの時点にロールバックしたい」というケースに度々見舞われました。当時はアウトプットを優先するがためにインフラ設定のコード化IaC (Infrastructure as Code)が遅れており、開発環境と本番環境の垣根もあいまいだったため、手動で変更箇所をロールバックして設定し直すということを繰り返して疲弊したこともありました。「急がば回れ」の典型です。元々 AWS の Solutions Architect から薦められていたこともあり、この経験をきっかけに AWS CloudFormation による IaC も実現しています。AWS 側から提供してもらっていたプロトタイプを拡張し、最終的に AWS Identity and Access Management (IAM)、 Amazon Elastic Compute Cloud (Amazon EC2)、 Amazon Virtual Private Cloud (Amazon VPC)、RDS、Lambda、Step Functions、CloudWatch、Events など、相当数のサービスの設定をコードで管理し、定義ファイルを AWS CodeCommit でバージョンを管理するようになりました。CloudFormationのおかげで開発環境と本番環境を VPC で完全分割することができ、環境の乗り合いによる運用エラーが大幅に減少しました。また、テスト環境の動的な立ち上げも容易にできるようになり、開発・運用の効率が大幅に上がりました。この経験を踏まえて、社内の AWS を使用したプロジェクトでは最初に CloudFormation を導入するよう啓蒙しています。

まとめ

切迫した状況の中で、ユーザーに使いやすいツールを短期間で開発できたのも、産学跨ぐ連携によってこそだと感じています。今回の経験を活かし、今後もIQVIAジャパンはデータとテクノロジーを最大活用して医療に貢献していきたいと思います。

WEBでの開発ミーティングの雰囲気

上左から：松井信智、吉田重人、飯塚智

下左から：Yushuan Chang、別府秀一、Andrew Craig、西裕志

＊＊＊＊＊

慶應義塾大学宮田教授からの実装相談に即応し、先生方とIQVIAジャパン社員のボランティアで結成した開発チームによりダッシュボードの素案を数日にて策定、「日単位での更新」「都道府県のユーザーによる自由な解析」という要件がある中、少人数の開発エンジニアにより2ヶ月で複数の都道府県（11月末時点で33都道府県：自治体や省庁の公式アカウント一覧）にフィードバックレポートを実際に提供した開発スピードは、IQVIAジャパン様の開発力の高さと医療への貢献に対する想いを物語っていると思います。また、その開発スピードに対してAWSの各サービスがお役に立てた事を嬉しく思います。

WEBベースなBIツールとしてQuickSight、サーバーレスなELT処理基盤としてLambda/Step Functions、IaCを用いた効率的な開発手法としてCloudFormation/CodeCommitをそれぞれご採用いただきましたが、実現に向けては幾つかの技術的な課題がありました。その課題に対して、IQVIAジャパン様のエンジニアとアマゾンウェブサービスジャパンのエンジニア（Professional ServiceおよびSolution Architect）がCOVID-19の状況下で行動が制限される中においても、チャットやWEB会議によるリモートでの議論や技術Q＆Aを重ねることにより、アイデアを即座に実現いただき、AWSクラウドへデプロイし形になっていくスピード感は、クラウドでなければ成し得なかったと考えています。

最後にアマゾンウェブサービスジャパン側のメンバーを紹介させていただきます。各都道府県のCOVID-19対策の意思決定に少しでもAWSの技術がお役に立てればと考え集まってくれたメンバーとなります。