サーバーレスで作るモバイルアプリ向け Backend for Frontend / serverless_bff

Slide 1

Slide 1 text

サーバーレスで作るモバイルアプリ向け Backend For Frontend Timers inc. 椎名アマド

Slide 2

Slide 2 text

自己紹介 • 椎名アマド • Timers inc. 共同創業者 CTO • 兼PO • Forbes 30 Under 30 2017 選出 • 興味関心: AWS / Security / Management / Finance • Twitter: @amado_tech

Slide 3

Slide 3 text

Timers inc. について • 2012年創業 • 社員数40人 (エンジニア9人) • 家族アプリFamm & 関連事業を運営 Fammアプリ Fammママスクール Famm撮影会

Slide 4

Slide 4 text

Timers inc. について Vision 古き良きを新しく「次に何が流行るか」ではなく、「人類として昔から未来まで変わらない価値観は何か」家族

Slide 5

Slide 5 text

家族アプリFammについて「家族の絆を深める」というビジョン写真を家族と共有し、印刷やDVDなど様々な形で届けられる容量無制限家族共有アルバム毎月自動で送られる写真印刷 DVD

Slide 6

Slide 6 text

家族アプリFammについてアプリで共有した写真が自宅＆両親に毎月自動で送られ、思い出づくりにも親孝行にもなる

Slide 7

Slide 7 text

Fammの今後弊社他事業との連携やグローバル展開、新サービスリリースで Fammブランド全体として成長

Slide 8

Slide 8 text

はじめに

Slide 9

Slide 9 text

はじめに本セッションはサーバーレスBFFの紹介だけでなく、「課題解決のための技術導入プロセスのケーススタディ」と捉えて欲しい

Slide 10

Slide 10 text

本セッションの構成 1. 我々の組織やプロダクトはどういう構造か 2. それによりどのような課題が発生しているか 3. その解決策としてサーバーレス&BFF をどう活用したか

Slide 11

Slide 11 text

Timersの組織構造

Slide 12

Slide 12 text

プロダクト開発の組織構造 Product Owner iOS Engineer Android Engineer Server Engineer Designer, QA, Director Product Owner Server Engineer Backlog Backlog Agile Development

Slide 13

Slide 13 text

モバイルアプリ開発での課題

Slide 14

Slide 14 text

モバイルアプリ開発での課題サーバーはRESTfulなAPIを作りたいクライアントはUIに対して使いやすいAPIが欲しい

Slide 15

Slide 15 text

サーバー視点 Photos API endpoint Database /photos Videos /videos HTTP method GET PUT POST DELETE GET PUT POST DELETE 1 resourceにアクセスする1APIに整理できるのが望ましい

Slide 16

Slide 16 text

クライアント視点 • 1つの画面で複数のリソースからデータを取得する事もある • あわよくば1画面を構成するのに1つのAPIコールで済ませたい • さらに、iOS&Androidの両方でAPIから取得したデータを使ったビジネスロジックを分散したくない /photos /videos

Slide 17

Slide 17 text

例：カレンダー印刷機能 1つの画面にいくつもの情報が表示されている • 商品プレビュー • 住所情報 • 契約状態契約状態に基づいた文言の表示出し分けパターンは多く、そこのロジックはクライアントの責務だった

Slide 18

Slide 18 text

例：カレンダー印刷機能 • この画面をクライアントが複数APIを呼び、整形をして表示するのは大変 →1つの巨大なAPIに集約した • 文言表示出し分けはiOS&Androidの間で差分がないように修正やメンテをするのは大変 /print ・写真・住所・契約状態・その他 if (契約状態 == 未契約) { … } else if (契約状態 == お試し) { … } else if (契約状態 == 契約中) { … }

Slide 19

Slide 19 text

例：カレンダー印刷機能 • 様々な制約条件の中で改善を進めるため、 iOS-Android-Server 間でのコミュニケーションによる調整コストが増加 • 複数OS ＆複数バージョンの影響範囲を考慮しながら、いくつものリソースを内包した巨大APIをメンテするのは非常に困難 • エンジニアの頑張りがあっても、実際に不具合も起こしてしまいユーザーに迷惑をかけたこともある

Slide 20

Slide 20 text

課題まとめサーバーAPI 複雑化 iOS&Android間で複雑なAPIを扱うビジネスロジックの分散

Slide 21

Slide 21 text

解決策の検討

Slide 22

Slide 22 text

1. 品質管理の徹底 • 自動テスト（Unit test, UI test 等）の網羅によりデグレを防ぐ • API修正のたびに過去バージョンも考慮した手動テストを行う不可能ではないが、テストパターンの量や開発生産性を考えるとスマートな解ではないサーバーAPI 複雑化 iOS&Android間で複雑なAPIを扱うビジネスロジックの分散

Slide 23

Slide 23 text

2. ネイティブでコード共有 • Kotlin/NativeなどでiOS&Androidともに利用できるビジネスロジックをライブラリ化する案 • 整理が必要なことが多い • 社内でのノウハウ不足のための技術調査コスト • 共通ライブラリ修正時のCIフローの検討一部で有効かもしれないが、コストが高い割に完全に幸せにならない iOS&Android間で複雑なAPIを扱うビジネスロジックの分散

Slide 24

Slide 24 text

3. APIに表示ロジックを寄せる • APIの方で契約状態に基づいた文言やUI表示の出し分け処理もしてしまい、実際の文字列を返す • 住所もクライアント表示のために必要な整形を済ませて返す • クライアント（iOS&Android）は受け取ったデータを表示するだけで済むので、クライアントでのビジネスロジックコードを大幅に削減可能 • サーバーAPIでテストを充実させていれば品質担保も可能方向性は悪くない。が、片方の課題しか解決できていない iOS&Android間で複雑なAPIを扱うビジネスロジックの分散

Slide 25

Slide 25 text

3. APIに表示ロジックを寄せる：懸念 • ビジネスロジック以外にもi18n対応、日付整形など、サーバー側で行わなければいけない事が一気に増える • 組織的にもサーバーエンジニアはこれまで負っていなかった「画面表示」という責務を負うことになる • ただでさえ現状のAPIアプリケーションは Monolithic なのに、そこに責務の範囲がさらに増えていく方向に進んでしまう →このソリューションを、現状のAPIアプリケーション以外のところで実現できないか？

Slide 26

Slide 26 text

BFF(Backend-for-Frontend) の登場

Slide 27

Slide 27 text

BFFとは “One backend per user experience” 1つのユーザー体験に密結合なバックエンド引用: https://samnewman.io/patterns/architectural/bff/

Slide 28

Slide 28 text

BFFとは BFF (Desktop) BFF (Mobile) Service A Service B Service C • クライアントとバックエンドサービスの間に挟まるAPI層 • クライアントは直接バックエンドサービスを叩かずにBFFを叩く • BFFはクライアントの要件に合わせて最適化される ※本セッションではBFFは主にAPI Gateway的なアーキテクチャのものを中心に話します

Slide 29

Slide 29 text

BFFとは BFF (Desktop) BFF (Mobile) Service A Service B Service C BFFが各バックエンドサービスと通信クライアントサイドが管理バックエンドが管理クライアントは BFFと通信

Slide 30

Slide 30 text

BFFの目的 (1)：責務の分離 • クライアントごとにUIやAPI要件が様々な場合、それを全てバックエンド側がハンドリングするのは非現実的 • クライアントごとに都合の良い（＝密結合な）API層を用意することで、責務の分離ができる • 例： Netflix BFF (Mobile) BFF (Desktop) BFF (TV) BFF (Game console)

Slide 31

Slide 31 text

BFFの目的 (2)：集約・変換 • 様々なバックエンドサービスと通信してデータ集約 • さらにそれらのデータをクライアントに適した形に変換 • クライアントはBFFとだけ通信すれば集約済みのデータ群が返ってくるので扱いやすくなる • Microserviceを多く使うケースで最適 BFF (Mobile) Service A Service B Service C

Slide 32

Slide 32 text

BFF：Fammの場合 • Microserviceではないが、複数のバックエンドAPIからリソースを取得して集約 • 文言出し分けなどのUIロジックをBFFに集約することで、 iOS&Androidの間で分散しているロジックを吸収 ※ユーザー体験が異なる場合はiOS&Android で別のBFFを構築するパターンもあり BFF (Mobile) Photo Address Payment iOS Android

Slide 33

Slide 33 text

BFF(Backend-for-Frontend) の導入

Slide 34

Slide 34 text

BFF導入にあたる取り決め • BFF APIはクライアントエンジニアの管轄 • APIの作成や修正、管理はクライアントエンジニアが行う • クライアントエンジニアが管理するなら、インフラ管理はしたくない →サーバーレスでやろう • サーバーレスで実現するための環境整備はサーバーサイドエンジニアが行う • サーバーレスの環境周りの課題があればサポートする

Slide 35

Slide 35 text

技術選定：言語 • TypeScriptを選定 • 弊社のほかのサーバーレス (Lambda)ではGoを使っているが、ここはクライアントエンジニアとして使いやすい言語を選定

Slide 36

Slide 36 text

技術選定：環境 (1) Lambda: AWSでサーバーレスAPI 作るならこれ API Gateway: AWSでサーバーレス API作るならこれ serverless: Lambda+API Gatewayの管理やデプロイが容易になるので活用

Slide 37

Slide 37 text

技術選定：環境 (2) (ANY) HTTP method API endpoint /{proxy+} Application • GET /print • GET /hoge • etc… • API GatewayはANYで全てのリクエストを受け、Lambdaは1つのExpressアプリケーションで複数エンドポイントをハンドリングするように • API Gateway + Lambdaが増えると管理運用が大変になるため、このパターンを採用

Slide 38

Slide 38 text

技術選定：環境 (2) (ANY) HTTP method API endpoint /{proxy+} Application • GET /print • GET /hoge • etc… • 本来はあまり綺麗ではない設計かもしれないが、生産性・管理しやすさ・今後増えるであろうエンドポイント数の規模を考えても妥当と判断

Slide 39

Slide 39 text

全体構成 iOS Android BFF API Backend API EC2 (ASG) ELB Lambda API Gateway

Slide 40

Slide 40 text

認可・認証 BFF API Backend API • API Gateway の API keyとともにBackend API用のトークンもリクエストで渡している • つまり現状この構成はBackend APIに密結合な設計である • 現状弊社にはほとんどMicroserviceがないのでこれで足りているが、今後BFFから他Microserviceをコールする際には認証の見直しが必要 API Key Token

Slide 41

Slide 41 text

i18n • i18n npmモジュールで特に不都合なく対応可能 • Backend APIアプリケーションの方であればライブラリ導入や管理で悩んでいたところだったが、BFFなのでクライアントエンジニアが自発的に意思決定＆導入できた

Slide 42

Slide 42 text

Test/CI/Deploy • テストは Jest を利用 • develop/master に merge されたらCircleCI経由でそれぞれデプロイが走る • serverless CLI の deploy コマンドがあるのでCIも簡単に構築 • CircleCIのIAM設定を忘れずに master jest tsc serverless deploy

Slide 43

Slide 43 text

最後に

Slide 44

Slide 44 text

今後やりたいこと • 今後Microserviceが増えた時に、BFFが複数Microserviceと通信できるような設計（主に認証認可の課題） • 現在はBFFは一度インターネットに出ていってBackend APIと通信しているので、VPC内で通信を完結させるなどして速度の最適化をしたい • BFFを導入できてから「この画面もBFF化したい」というところも見えてきたので、その移行をしていきたい

Slide 45

Slide 45 text

伝えたいこと自分のチーム・プロダクトの課題は何なのかを考え、それを解決するソリューションを導入すること

Slide 46

Slide 46 text

伝えたいこと • 「それがモダンな技術トレンドだから」などの安易な理由で技術導入をしてはいけない。必ず失敗します。 • 何事も「何の課題を解決したいのか？」という課題ドリブンで思考し、技術選定→導入しましょう。 • 本セッションは技術の紹介だけでなく、Timersという1組織における課題特定→解決プロセスのケーススタディと捉え、参考にしていただければ幸いです。

Slide 47

Slide 47 text

採用中！ • 現在エンジニア積極採用中！ • ※特にサーバーサイドエンジニア • 興味がある方は “Timers” や “Timers Tech Blog” を検索 • Twitter @amado_tech もフォローお願いします

Slide 48

Slide 48 text

Thank you!