大手ガソリンメーカーでのアプリモニタリング

大手石油メーカーからリリースされたアプリ。
弊社とグループ会社での
僕たちは、そのアプリユーザー分析としてAWSのアプリ分析ツールであるAmprifyや顧客のデータ
これらのデータベース設計＆構築から、最終的にはLookerでのモニタリングレポート、そしてSendGridを用いた各営業店舗に向けた毎月のレポート配信の開発までを担当。

RedShift上でデータを貯めつつも、Lookerで繋ぎ可視化。そしてLookerではスケジュール配信の機能があり、
モニタリングのレポートとしてpdf化したものをメール配信する。
自分の構築イメージとしてはこのようにイメージをしておりました。

しかし、クライアントと要求定義を進めていくと、営業店は約2,000店舗あり、そこに一斉にメール配信をしようとするとLookerのメモリが足りず処理が回らないのではという仮説を立てました。
さらに、ただでさえダッシュボードも60個ほど作成するのに、スケジュールも2,000個ということで、
Lookerの画面での操作のサクサク度は失われ、全く操作できない状況にもなり得るのではと想定しました。

そのため、Googleと協力をして、
Lookerから直でメール配信を実行させるとLookerのメモリを圧迫させてしまい、メモリを積むと価格が大変なことになるので、
配信処理は別のソリューションで行うことに決め、SendGridというメール配信に特化したソリューションを使用。

Lookerから直接SendGridにリクエストして配信をするのではなく、
LookerからまずAWS上のlambdaにスケジュール配信でのリクエストを送信し、lambdaからSendGridに改めて配信情報を送り、メールを送信という座組を構築。
理由としては中間サーバとなるLambdaにて一部データの加工処理などが必要になったためです。
なのでlambda内で加工処理をして、SendGridで配信という実装を構築。
そしてクライアント様の開発環境に応じて、

lambdaやLookerのLookMLのソースコード管理は全てクライアントが契約をしているGithubにて行い、
CI/CDツールはクライアントが持っているCircle CIを使っての構築。
Githubにコードをpushし、Circle CIを通じてAmazon ECRにDockerイメージを作成、そしてLambdaにデプロイという座組を構築。

なかなかハードな案件であったが、自分がLookerやエンジニアリング系のリーダーとしてメンバーをサポートしつつ、Looker APIの箇所については自分で構築。
ダッシュボード周りの構築についてはサポートしてはいり、メンバーが基本的に作業を行うようなチーム編成で対応。

あとは、Lookerにはスケジュール配信機能はあるが、どこに配信するかについては幾つかしかない。
そして今回はAWSのlambdaのエンドポイントにリクエストをするというカスタムで作る必要があった。
そこでLooker APIを用いてLooker内に新たな配信先を構築し、Lookerのスケジュール配信からそのエンドポイントにレポートのcsvデータを載せてリクエストするように処理を構築。