YOJOのアプリケーション・インフラ構成図 / 技術スタックを公開します！

YOJOは、生理痛や不妊・更年期などに悩む女性を中心に、LINEでいつでもどこでも簡単に薬剤師に相談ができ、体質に合わせた市販薬や健康食品をお届けする「YOJO」というサービスを展開しています。

まずは主となるアプリケーションから！

アプリケーション

① 機能・インターフェースの提供

ポイント

• フロントエンド

YOJOでは、薬剤師（カスタマーサクセス）チームが、ユーザーと会話するための管理画面とユーザーがLINE上でひらくwebアプリ（LIFF、LINEミニアプリ）を内製してしています。

1. 基本的に、フロントエンドはNext.js（React）を採用しています。 後述しますが、ライティングページ（LP）など、一部にはNuxt.js（Vue.js）を採用しています
• Next.js（React）を使う理由については、下記の記事もご参照ください https://ueniki.tokyo/Why-React-Next-js-2424d8a0ce714d4c9144f46f6dd4614b
2. YOJOのJSはほぼすべて、TypeScriptを使って書いています。
3. 詳細は後述しますが、Firestoreにユーザーとのトーク内容を保存しており、トーク内容をFirestoreのリアルタイムリスナーを使って取得することで、ユーザーからのメッセージをリアルタイムに薬剤師の使う管理画面に表示しています。
4. インフラは、Next.jsと相性のいいVercelを使っています。今後必要があれば、他のインフラに載せ替えることはあるかなと思っています。
5. YOJOでは、BFFを置く構成を採用していて、フロントエンドとBFFの間はGraphQLで通信を行っています。

YOJOが管理画面を内製する理由について私が書いた記事もご参考にしていただければ！

なぜYOJOは薬剤師がチャットする管理画面を内製するのか

管理画面を作るということはオペレーションを創造するということである

ueniki.tokyo

• BFF
• BFFはNode.jsをTypeScriptで書いています。
• BFFはApollo Serverとして、バックエンドにREST APIでリクエストを投げ、フロントエンドからきたGraphQLの要求に答えます。
• 上述のようにフロントエンド⇄BFFはGraphQL、BFF⇄バックエンドは、REST APIです。

• バックエンド
• 今後、必要に応じてマイクロサービス化を行いますが、バックエンドは基本的にはRailsで書かれています。
• Herokuに載っていますが、今後必要があれば別のインフラに載せ替えることも検討しています。
• バックエンドでLINEへのメッセージの送・受信や、データ分析基盤への吐き出しなどを行います。

次は、LINEのメッセージの送受信だけに着目した場合のインフラ構成図です！

②（LINE APIを用いた）チャットメッセージの送受信

こちらは、メッセージの送受信に必要な構成だけを抜き出したインフラ構成図になります。

ポイント

• Pub/Sub
• メッセージを受信する際にまずPub/Subを介することで、バックエンドが落ちていたり、エラーが起きた場合でも、 メッセージが落ちないようにしています。
• Firestore
• ①でも述べましたが、Firestoreにメッセージを保存することで、管理画面にメッセージをリアルタイムで保存しています。

データ分析基盤

こちらにも記載してあるのでご覧ください（リンク先の方が更新されている可能性は高いです）

YOJOのデータ分析基盤の構成

YOJOの分析基盤の構成を公開します（現在進行系で作成中なので、一部未完成な部分も含みます。）

ueniki.tokyo

構成図

全体像

ログ収集

設計方針・概要

• 方針としては、BigQueryに全てのデータを一旦集約する。
• 中間生成物は、BigQueryからScheduling queriesやMaterialized Viewを使ってBigQueryに保存
• Materialized Viewは便利だが多少制約があるので、用途によってScheduling queriesやMaterialized Viewを使い分ける。
• もっと処理の依存関係が複雑になってきたら、Cloud Composer or Cloud Dataflowで
• 広告データは、サーバレスでAPIを叩いて、BigQueryに流す・
• GASでBigQueryに流すこともできるが、あえてGASでやる必要はないだろう。
• 構成はCloud Scheduler → Pub/Sub → Cloud Functions / Cloud Run(event trigger) → BigQuery（図参照）
• 手書き管理している寄稿記事にかかった費用などのマーケティングデータや原価マスターなどはもうしばらくspreadsheetで管理する。
• 上記のサーバーレス構成で、spreadsheetも読み込んで、BigQueryに流す。
• BigQueryからredashに書かれてあるqueryを上記のサーバーレス構成で定期的にspreadsheetに
• GASで自動化する方が楽ではあるが、GASは管理が後々面倒なので、一旦Redash APIを叩くようにしてみる。
• spreadsheetに出力された最終生成物をdata portalで可視化する

LP

最後に一応、LPの構成も載せておきます！

ポイント

これと言ったポイントはあまりないですが、あえてあげるとすると以下になるかなと。

• Nuxt.js（Vue.js）
• アプリケーションと違って、こちらはNuxt.jsで書かれています。これは、Reactに比べるとVueの方が書きっぷりが比較的簡単で、そこまで技術の高くないエンジニア・デザイナーの方々にもいじってもらいやすいかなと考えたからです。
• GAE
• LPは頻繁にdeployされるし、アクセスも多くなりがちでありながら、そこまでカスタマイズする必要はないので、マネージドなGAEを使っています。

まとめ

ざっくりと大枠の技術構成を公開してみました！

こうやって改めて整理してみると、かなりモダンな技術を使っているかなと思います。

少しでもご興味があれば、是非DMいただければと思います！