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

AWS DevDay Tokyo 2019 で発表したセッションです。

【概要】
運営期間と共に機能が増え続けるモバイルアプリでは、サーバーから取得した情報に合わせて複雑なビジネスロジックの処理を設計開発しようとすると色々な課題が出てきます。iOS, Androidでの仕様の同期問題、バックエンドAPI修正に対するアプリバージョンの考慮などに悩まされ、結果的に開発や機能の出荷スピードの低下に繋がります。
本セッションでは、こういった課題に対してBFF(Backend-For-Frontend)というアーキテクチャを用いて、小規模なチームでいかにインフラ構築・運用の手間なくバックエンドとクライアント間の連携の課題を解決するかを紹介します。API Gateway&Lambda&Serverless Frameworkを用いたサーバーレスアーキテクチャの各種技術選定の背景や、設計・開発の中で工夫した点についても説明します。

Transcript

1. サーバーレスで作る モバイルアプリ向け Backend For Frontend Timers inc. 椎名アマド
2. 自己紹介 • 椎名アマド • Timers inc. 共同創業者 CTO • 兼PO • Forbes 30 Under 30 2017 選出 • 興味関心: AWS / Security / Management / Finance • Twitter: @amado_tech
3. Timers inc. について • 2012年創業 • 社員数40人 (エンジニア9人) • 家族アプリFamm & 関連事業を運営 Fammアプリ Fammママスクール Famm撮影会
4. Timers inc. について Vision 古き良きを新しく 「次に何が流行るか」ではなく、 「人類として昔から未来まで変わらない価値観は何か」 家族
5. 家族アプリFammについて 「家族の絆を深める」というビジョン 写真を家族と共有し、印刷やDVDなど様々な形で届けられる 容量無制限 家族共有アルバム 毎月自動で送られる 写真印刷 DVD
6. 家族アプリFammについて アプリで共有した写真が自宅＆両親に毎月自動で送られ、 思い出づくりにも親孝行にもなる
7. Fammの今後 弊社他事業との連携やグローバル展開、新サービスリリースで Fammブランド全体として成長
8. はじめに
9. はじめに 本セッションはサーバーレスBFFの紹介だけでなく、 「課題解決のための技術導入プロセスのケーススタディ」 と捉えて欲しい
10. 本セッションの構成 1. 我々の組織やプロダクトはどういう構造か 2. それによりどのような課題が発生しているか 3. その解決策としてサーバーレス&BFF をどう活用したか
11. Timersの組織構造
12. プロダクト開発の組織構造 Product Owner iOS Engineer Android Engineer Server Engineer Designer, QA, Director Product Owner Server Engineer Backlog Backlog Agile Development
13. モバイルアプリ開発での 課題
14. モバイルアプリ開発での課題 サーバーはRESTfulなAPIを作りたい クライアントはUIに対して使いやすいAPIが欲しい
15. サーバー視点 Photos API endpoint Database /photos Videos /videos HTTP method GET PUT POST DELETE GET PUT POST DELETE 1 resourceにアクセスする1APIに整理できるのが望ましい
16. クライアント視点 • 1つの画面で複数のリソースからデータを取得する事もある • あわよくば1画面を構成するのに1つのAPIコールで済ませたい • さらに、iOS&Androidの両方でAPIから取得したデータを使った ビジネスロジックを分散したくない /photos /videos
17. 例：カレンダー印刷機能 1つの画面にいくつもの情報が 表示されている • 商品プレビュー • 住所情報 • 契約状態 契約状態に基づいた文言の表示 出し分けパターンは多く、そこ のロジックはクライアントの責 務だった
18. 例：カレンダー印刷機能 • この画面をクライアントが複数APIを呼び、整形をして表示す るのは大変 →1つの巨大なAPIに集約した • 文言表示出し分けはiOS&Androidの間で差分がないように修正 やメンテをするのは大変 /print ・写真 ・住所 ・契約状態 ・その他 if (契約状態 == 未契約) { … } else if (契約状態 == お試し) { … } else if (契約状態 == 契約中) { … }
19. 例：カレンダー印刷機能 • 様々な制約条件の中で改善を進めるため、 iOS-Android-Server 間でのコミュニケーションによる調整コストが増加 • 複数OS ＆複数バージョンの影響範囲を考慮しながら、いくつ ものリソースを内包した巨大APIをメンテするのは非常に困難 • エンジニアの頑張りがあっても、実際に不具合も起こしてしま いユーザーに迷惑をかけたこともある
20. 課題まとめ サーバーAPI 複雑化 iOS&Android間で複雑なAPIを扱うビジネ スロジックの分散
21. 解決策の検討
22. 1. 品質管理の徹底 • 自動テスト（Unit test, UI test 等）の網羅によりデグレを防ぐ • API修正のたびに過去バージョンも考慮した手動テストを行う 不可能ではないが、テストパターンの量や開発生産性を 考えるとスマートな解ではない サーバーAPI 複雑化 iOS&Android間で複雑なAPIを扱うビジ ネスロジックの分散
23. 2. ネイティブでコード共有 • Kotlin/NativeなどでiOS&Androidともに利用できるビジネスロ ジックをライブラリ化する案 • 整理が必要なことが多い • 社内でのノウハウ不足のための技術調査コスト • 共通ライブラリ修正時のCIフローの検討 一部で有効かもしれないが、コストが高い割に完全に幸 せにならない iOS&Android間で複雑なAPIを扱うビジ ネスロジックの分散
24. 3. APIに表示ロジックを寄せる • APIの方で契約状態に基づいた文言やUI表示の出し分け処理もしてしま い、実際の文字列を返す • 住所もクライアント表示のために必要な整形を済ませて返す • クライアント（iOS&Android）は受け取ったデータを表示するだけで済 むので、クライアントでのビジネスロジックコードを大幅に削減可能 • サーバーAPIでテストを充実させていれば品質担保も可能 方向性は悪くない。が、片方の課題しか解決できていない iOS&Android間で複雑なAPIを扱うビジ ネスロジックの分散
25. 3. APIに表示ロジックを寄せる：懸念 • ビジネスロジック以外にもi18n対応、日付整形など、サーバー 側で行わなければいけない事が一気に増える • 組織的にもサーバーエンジニアはこれまで負っていなかった 「画面表示」という責務を負うことになる • ただでさえ現状のAPIアプリケーションは Monolithic なのに、そ こに責務の範囲がさらに増えていく方向に進んでしまう →このソリューションを、現状のAPIアプリケー ション以外のところで実現できないか？
26. BFF(Backend-for-Frontend) の登場
27. BFFとは “One backend per user experience” 1つのユーザー体験に密結合なバックエンド 引用: https://samnewman.io/patterns/architectural/bff/
28. BFFとは BFF (Desktop) BFF (Mobile) Service A Service B Service C • クライアントとバックエンド サービスの間に挟まるAPI層 • クライアントは直接バックエ ンドサービスを叩かずにBFFを 叩く • BFFはクライアントの要件に合 わせて最適化される ※本セッションではBFFは主にAPI Gateway的 なアーキテクチャのものを中心に話します
29. BFFとは BFF (Desktop) BFF (Mobile) Service A Service B Service C BFFが各バックエ ンドサービスと 通信 クライアント サイドが管理 バックエンドが 管理 クライアントは BFFと通信
30. BFFの目的 (1)：責務の分離 • クライアントごとにUIやAPI要 件が様々な場合、それを全て バックエンド側がハンドリン グするのは非現実的 • クライアントごとに都合の良 い（＝密結合な）API層を用意 することで、責務の分離がで きる • 例： Netflix BFF (Mobile) BFF (Desktop) BFF (TV) BFF (Game console)
31. BFFの目的 (2)：集約・変換 • 様々なバックエンドサービス と通信してデータ集約 • さらにそれらのデータをクラ イアントに適した形に変換 • クライアントはBFFとだけ通信 すれば集約済みのデータ群が 返ってくるので扱いやすくな る • Microserviceを多く使うケース で最適 BFF (Mobile) Service A Service B Service C
32. BFF：Fammの場合 • Microserviceではないが、複数 のバックエンドAPIからリソー スを取得して集約 • 文言出し分けなどのUIロジッ クをBFFに集約することで、 iOS&Androidの間で分散してい るロジックを吸収 ※ユーザー体験が異なる場合はiOS&Android で別のBFFを構築するパターンもあり BFF (Mobile) Photo Address Payment iOS Android
33. BFF(Backend-for-Frontend) の導入
34. BFF導入にあたる取り決め • BFF APIはクライアントエンジニアの管轄 • APIの作成や修正、管理はクライアントエンジニアが行う • クライアントエンジニアが管理するなら、インフラ管理はした くない →サーバーレスでやろう • サーバーレスで実現するための環境整備はサーバーサイドエン ジニアが行う • サーバーレスの環境周りの課題があればサポートする
35. 技術選定：言語 • TypeScriptを選定 • 弊社のほかのサーバーレス (Lambda)ではGoを使っている が、ここはクライアントエン ジニアとして使いやすい言語 を選定
36. 技術選定：環境 (1) Lambda: AWSでサーバーレスAPI 作るならこれ API Gateway: AWSでサーバーレス API作るならこれ serverless: Lambda+API Gatewayの 管理やデプロイが容易になるので 活用
37. 技術選定：環境 (2) (ANY) HTTP method API endpoint /{proxy+} Application • GET /print • GET /hoge • etc… • API GatewayはANYで全てのリクエストを受け、Lambdaは1つのExpressア プリケーションで複数エンドポイントをハンドリングするように • API Gateway + Lambdaが増えると管理運用が大変になるため、このパター ンを採用
38. 技術選定：環境 (2) (ANY) HTTP method API endpoint /{proxy+} Application • GET /print • GET /hoge • etc… • 本来はあまり綺麗ではない設計かもしれないが、生産性・管理 しやすさ・今後増えるであろうエンドポイント数の規模を考え ても妥当と判断
39. 全体構成 iOS Android BFF API Backend API EC2 (ASG) ELB Lambda API Gateway
40. 認可・認証 BFF API Backend API • API Gateway の API keyとともにBackend API用のトークンもリク エストで渡している • つまり現状この構成はBackend APIに密結合な設計である • 現状弊社にはほとんどMicroserviceがないのでこれで足りている が、今後BFFから他Microserviceをコールする際には認証の見直 しが必要 API Key Token
41. i18n • i18n npmモジュールで特に不都合なく対応可能 • Backend APIアプリケーションの方であればライブラリ導入や管 理で悩んでいたところだったが、BFFなのでクライアントエン ジニアが自発的に意思決定＆導入できた
42. Test/CI/Deploy • テストは Jest を利用 • develop/master に merge されたらCircleCI経由でそれぞれデプロ イが走る • serverless CLI の deploy コマンドがあるのでCIも簡単に構築 • CircleCIのIAM設定を忘れずに master jest tsc serverless deploy
43. 最後に
44. 今後やりたいこと • 今後Microserviceが増えた時に、BFFが複数Microserviceと通信で きるような設計（主に認証認可の課題） • 現在はBFFは一度インターネットに出ていってBackend APIと通 信しているので、VPC内で通信を完結させるなどして速度の最 適化をしたい • BFFを導入できてから「この画面もBFF化したい」というところ も見えてきたので、その移行をしていきたい
45. 伝えたいこと 自分のチーム・プロダクトの課題は何なのかを考え、 それを解決するソリューションを導入すること
46. 伝えたいこと • 「それがモダンな技術トレンドだから」などの安易な理由で技 術導入をしてはいけない。必ず失敗します。 • 何事も「何の課題を解決したいのか？」という課題ドリブンで 思考し、技術選定→導入しましょう。 • 本セッションは技術の紹介だけでなく、Timersという1組織にお ける課題特定→解決プロセスのケーススタディと捉え、参考に していただければ幸いです。
47. 採用中！ • 現在エンジニア積極採用中！ • ※特にサーバーサイドエンジニア • 興味がある方は “Timers” や “Timers Tech Blog” を検索 • Twitter @amado_tech もフォローお願いします
48. Thank you!