Pedago-Engineering #01 データ分析の基盤を設計する
42 Tokyoでは、データを溜めて、加工して、可視化して、分析するというプロセスを行っている。このプロセスを円滑に行うには、データ分析の基盤を設計する必要性がある。この記事の目的は、ある課題を通して、データ分析の基盤をAWSというクラウドプラットフォーム上で設計することである。
課題
Canvas LMSという学習管理システムについてご存知だろうか。
Canvas LMS は学習者や学習コンテンツの管理の手間が少なく、使い勝手が良いシステムであるため、AWS AcademyというAWSを学べる高等教育機関でも活用されている。
他の利点は、学習管理システムならではの、学習者の情報を保存して、学習者の状態を逐一把握できるダッシュボードなどが存在することだ。
しかし、オンラインで学習している場合、このツールを活用するだけでは、学習コミュニティを成り立たせるための大事な要素、コミュニケーションなどが物足りなく感じる。
なので、Canvas LMS(学習管理システム) ＋ Discord（コミュニケーションツール）といったツールを活用すれば、学習環境を整えることはできる。
必要に応じて、必要なツールを活用すれば、学習環境をより良くすることができる。しかし、必要なツールを増やせば増やすほど、学習者にまつわる情報は各ツールに分散していき、学生の状態を把握するのが困難となる。
学習者は、Canvasで学習しているのだろうか、はたまた、Discordで学習しているのだろうか、それともどっちもなのか、どっちでもないのだろうか。
このような状態から脱却するためには、まず様々なツールで観測できる学生の情報（データ）を一元化して、可視化できるようにならなければならない。
他のツールが増えた場合も想定して、この課題の解決策をどのように設計するかが本題である。
設計
今回は、AWSというクラウドプラットフォームが提供している様々なサービスを用いて課題を解決する（クラウドプラットフォームは、AWS以外にもあるのになぜAWSを選んだかというと、42Tokyoのデータ分析の基盤はGCPを活用しており、今回の課題をGCPで再現しても面白みがないため、AWSを選択した）。
以下の図は、自分がクラウドプラットフォームを課題解決に活用する際の自作フレームワークである。
Layer 1: 要件を具体化
Layer 2: アーキテクチャを設計
Layer 3: アーキテクチャの実現可能性を見極める
Layer 4: アーキテクチャを実装
Layer1からLayer4へと、抽象から具体へと行き来しながら課題解決を行う。
レイヤーよりもステップの方が適切では？と感じるかもしれないが、ステップは基本的に不可逆なのに対して、レイヤーは、上下のレイヤーに移動できる。Layer3における実現可能性が低いと判断した場合は、Layer2に移動して異なるアーキテクチャを活用する方向性で再度具体化する。各レイヤーは、必要に応じて抽象と具体を行き来するため、このような形式である。
Layer 1: 要件を具体化
今回の課題に対して、抽象化された状態の要件は、以下の図になる。
抽象度が高いと大まかな理解はできるが、その反面、まだ何も行動に移せない。具体的な行動に移すには、要件をより具体化していくほかない。どこまで具体化すればいいのか、という問いに関しては、人それぞれである。自分の場合、各要件がAWSのサービスと置き換えれると判断した場合、具体的である。「データを溜める」前に「データを抽出して転送する」という要件がないと、そもそもデータがどこから溜まってくるのか設計できないため、追加する。
Layer 2: アーキテクチャを設計
アーキテクチャを設計するには、各要件をAWSのサービスと置き換えて、結合を行わなければならない。
要件1: データを抽出して転送する
データを抽出する場合、まずは、データの参照元、データソースを見極めなければならない。
今回の場合、
- Canvas LMS
- Discord
という二つのツールがデータソースとなる。
これらのツールからデータを抽出するには、基本的に以下の二つの方法がある。
- バッチ処理：定期的にこちらのシステム側から、データソースのデータを抽出する方法
- ストリーミング：リアルタイムでデータソースからデータがこちらのシステム側に流れ込む方法
バッチ処理を行えるAWSのサービスには、以下のサービスなどが存在する。
ストリーミングを行えるAWSのサービスには、以下のサービスなどが存在する。
三つのサービスしか取り上げていないが、他にも存在する（年々、AWSのサービスが増えたり、アップデートされたりするので、AWSのサービスに関する新情報を追うのに一苦労）。
要件2: データを溜める
データを溜めるのに適しているサービスは Amazon S3というサービスなので、今回はこのサービスを活用する。
要件3: データを可視化する
データを可視化するのに適しているサービスは Amazon QuickSightというサービスなので、今回はこのサービスを活用する。
各要件（サービス）を結合する
各要件ををサービスに置き換えて結合すると以下の図のような一つのアーキテクチャになる（画像をクリックすると拡大化される）。
このようなアーキテクチャを実装すれば課題を解決できる目処が立つ。次のステップは、実現可能性を見極めることである。
Layer 3: アーキテクチャの実現可能性を見極める
layer2で設計したアーキテクチャをそもそも実現できるかを判断するレイヤーである。
一つ目の判断材料は、実装者の力量である。AWSのサービスを活用するのに手順書などが存在しないと実装できない場合、layer2に戻り、手順書が存在するAWSのサービスなどを選択した方が良い。
二つ目の判断材料は、アーキテクチャに関連するサービスのドキュメントの質と量である。例えば、データ分析の基盤に関するベストプラクティスなどが存在する場合、そのベストプラクティスに沿って、実装した方が実現可能性は高くなる。
今回の場合だと、以下のベストプラクティスの記事が大変参考になる。
実現可能性を高めるために、layer2で設計したアーキテクチャを、このベストプラクティスに沿って必要な箇所を最適化する。
今回、一番目立つ変更点は、データレイクに使用される三つのAmazon S3(正確にはバケット)である。Amazon S3に保存するデータを分析に適した形にする場合、保存するデータを以下の三つに切り分ける。
- 生データ（Canvas LMSやDiscordからそのまま持ってきたデータ）
- 加工データ(データ処理が行いやすい形に変換されたデータ)
- 分析データ(加工データから分析に必要なデータだけをまとめたデータ（Canvas LMSやDiscordのデータを結合したデータ)）
三つ目の判断材料は、各サービスの連携がシステム的に可能かどうかを判断することである。
例えば、ストリーミングを行えるAWSのサービスとデータソースをそもそも連携させることは可能なのだろうか。Canvas LMSやDiscordのサーバにアクセスできないとストリーミングが行えない場合、システム的に実現不可なので、アーキテクチャからストリーミング処理に付随する箇所を消去する。
次に、バッチ処理に関して確認する。Canvas LMSやDiscordはAPIを提供しているため、毎時間APIを叩いてデータを取得することは、システム的に可能である。AWS GlueでもAWS Lambdaでも実装できるが、今回はAWS Lambdaで実装する。このように各サービスの連携がシステム的に可能か確認する。
各連携を確認した後のアーキテクチャは以下の図となる。
このレイヤーの判断基準をまとめると、
- 実装者の力量
- アーキテクチャに関連するサービスのドキュメントの質と量
- 各サービスの連携がシステム的に可能か確認
の情報をもとに、実現可能性を総合的に判断する。
実現可能性が低いと判断した場合は、layer2に戻り、別のアーキテクチャを再度設計する。
Layer 4: アーキテクチャを実装
このレイヤーに関しては、実装するだけである。実装が思ったよりも難しい場合、 より抽象度の高いレイヤーに戻って実現可能性を高めてから、再度実装する。
実際の実装に関しては、省く。Layer 4が完了した状態をこちらの記事に追記したかったが、長くなりそうなので違う記事として出したい（それか、実装が完了した後に、この記事に追記する）。
まとめ
Layer1からLayer4へと、抽象から具体へと行き来しながら課題解決を行えば、データ分析の基盤を実装することが可能である。
データ分析の基盤を設計する場合や、他の課題をクラウドプラットフォーム上で解決する場合でも、自分は以下のフレームワークに沿って課題解決を行っている。クラウドプラットフォームを軸にどのように課題解決すればいいのか迷った場合は、ぜひ参考にしてみてください。
