Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

アンケートページ

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

最近の歴史 時期 できごと 技術要素 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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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