BIRのアーキテクチャと 技術選定

自己紹介 滝安純平（@juntaki） BIRエンジニアチームリーダー兼BIRカンパニー執行役員 バックエンドとWebフロントエンドエンジニア、兼プロダクトマ ネージャをやっています。 もともと組み込みLinuxのカーネル開発をしていました。最近 はFlutterでなにか作っています。 好きな言語はGoʕ◔ϖ◔ʔ 2

今日話すこと ● BIRのビジネスとシステムアーキテクチャ ● 技術選定の経緯 Go / Google Cloud 構成をシンプルにして、 やりたいことに集中する 3

BIRのビジネスと システムアーキテクチャ 4

BIR - ビジネスインテリジェンス&リサーチ 医療従事者の会員向けアンケート（国内最大の医師パネル）をベースに、製薬 会社へのマーケティング支援を提供する事業を行っています。 5

アンケートページ

アンケートビジネスの流れ 1. アンケートを作る 2. 配信・督促をがんばる 3. データを整理する 4. データを可視化する アンケートを集める データを活用できるよ うにする 7

アンケートシステムのアーキテクチャ 責務を分割して、依存関係を シンプルにする 8

アンケートシステムのアーキテクチャ 1.アンケートを作る 2.配信・督促をがんばる 3.データを整理する 4. データを可視化する アクセス量大 督促ロジックにフォーカス アクセスは比較的少ない UI/UX、管理・運用にフォーカス 9

もうすこし現実に近づけると… 実際はアンケートシステムがたくさんある。配信と督促や認証を集約することで、アンケート全体を通して の回収状況の可視化・督促ロジックの設計が可能になる。当然、機能の重複もへる 10

アンケートシステムがたくさんある理由 いろいろなアンケート形式があり、まとめると複雑になりすぎる →部分的には類似機能の再実装になるが、それぞれで最適を目指しやすい アンケート形式の例： ● 管理画面でアンケートを作れるふつうのアンケートシステム ● M3会員情報を付与して他アンケートへリダイレクトするシステム ● アンケートの回答に応じて他のアンケートが始まる ● 月に1回配信される日記形式のアンケート 11

システムアーキテクチャまとめ 責務・アンケート形式ごとにシステムを分割し、依存関係をシンプルにする →最適な実装を目指しやすくする 構成をシンプルにして、 やりたいことに集中する 12

技術選定の経緯 Go / Google Cloud 13

最近の歴史 時期 できごと 技術要素 2018年11月 集計システムリリース Racoon Go/App Engine（Go導入/App Engine導入） 2019年8月 アンケート新管理画面リリース Tiger Kotlin,Spring/オンプレ（後にAWSへ移行） 2019年9月 新アンケートシステムリリース Ibis Go/App Engine 2019年12月 配信システムリリース Dolphin Go/App Engine 2020年7月 新アンケートシステムリリース Coyote Go/Cloud Run（Cloud Run導入） 2020年8月 配信システムバックエンド Spanner化 Cloud Spanner 2020年12月 全アンケートシステムが配信システムへ統合 14

Goを導入した理由 Javaが多い中で、下記の特徴・メリットがあったため受け入れられた ● 静的型付＋オブジェクト指向的な考えで作れる ● いろんな書き方ができない（いい意味で） ● コンパイル・起動が高速 説明できればチームごと判断で柔軟に入る文化 15

Webフレームワークは使わない net/httpとコード自動生成の組み合わせ、Clean Architectureで整理 フレームワークは言語よりも寿命が短い、習得ハードルも高くなる 16 https://speakerdeck.com/juntaki/godeapisabawohayakutukuru → シンプルな構成で、キャッチアップや保守を効率化

Goを導入した結果 その後のプロダクトは基本的にGoが多め ※Go以外を使わないわけではない、適材適所 チームの感想 「言語仕様がとにかくシンプルなので参照しているライブラリの中までコードを追いたいと きも追いやすい」 「公式でSDKや実装サンプルが公開されていることが多い」 17

Google Cloudを導入した理由 エムスリーは全体的にAWSの利用が多かったが、BIRではサーバーレスなコンポーネ ント（App EngineとCloud Run）を中心に活用している 当時は… ● アンケートシステムの数よりもエンジニアが少ない ● SREチームとの連携ポイントを減らしてスピードアップ Google Cloudはコンポーネントを組み合わせなくてもWebサービスが成立する ※コントロールできる要素が少ないことがメリットになるようにシステムを組む必要はある 18

Google Cloudを導入した結果 その後のプロダクトは基本的にGoogle Cloud（以下略） ※オンプレサーバの移行など、サーバーレスのメリットを享受しにくい時などはAWSも使います。適材適所 チームの感想 「AWSと比べると一つ抽象化されている感じがする。Cloud Run便利」 「設定項目がすくない分、考えることが少なくて済んでいる。App EngineやCloud Runの 使い勝手が良い。」 19

全体のまとめ 責務・アンケート形式ごとにシステムを分割し、依存関係をシンプルにする さらにGo/Google Cloudの組み合わせで、Webサービスの機能開発にフォーカス 構成をシンプルにして、 やりたいことに集中する 20

アンケートのご協力をお願いします ※BIRで作っているアンケートシステム（ Tiger）です！ 　医療従事者でない方はめったに触る機会がないので、ぜひこの機会にどうぞ We’re hiring! 
 エムスリーのエンジニア 採用サイトはこちら アンケートはこちら ※現在は終了 しています