サーバーレスで作る モバイルアプリ向け Backend For Frontend
Timers inc.
椎名アマド
Ũâś{
! ħ¶<bV
! -./%+0(. µ¢ĩŦ 2-3
! 43
! )*+5%0(67(8&'%+(67(97:;(Ɠ
! ũºƚò<(=>?(@(?%#A+.,B(@(
C"&"D%/%&,(@().&"&#%
! -E.,,%+<(!"#"$%&'()*
-./%+0(. &!
! 97:9å¢ĩ
! Ő½ĒF7y G@pKW<HyI
! ×Ę<`l)"// J(ƚƎxĩ:ƐÀ
+"##<`l +"##bbLDrm +"##Ďî
Timers inc. について
Vision
古き良きを新しく
「次に何が流行るか」ではなく、
「人類として昔から未来まで変わらない価値観は何か」
家族
家族アプリ Famm について
「家族の絆を深める」というビジョン
写真を家族と共有し、印刷やDVDなど様々な形で届けられる
容量無制限
家族共有アルバム
毎月自動で送られる 写真印刷
DVD
×Ę<`l )"// &!
<`l"ğŎŨÒƭuų&IJĞŨ¥"Ɗ47
÷ 5&0ųÑū&0%6
÷ 5&0ųÑū&0%6
)"// 'zï
éŐ|xĩ#'Ǝč1Eor[mÞƘĖHr]LllrL"
)"//_kpV#!āƗ
はじめに
はじめに
本セッションはサーバーレスBFFの紹介だけでなく、
「課題解決のための技術導入プロセスのケーススタディ」
と捉えて欲しい
本セッションの構成
1. 我々の組織やプロダクトはどういう構造か 2. それによりどのような課題が発生しているか
3. その解決策としてサーバーレス&BFF をどう活用したか
Timers の組織構造
`oPDUƘʼn'ŜŢīƍ
4+*'A#,(3E&%+
.3?
M&D.&%%+
=&'+*.' M&D.&%%+
?%+N%+
M&D.&%%+
L%0.D&%+O P=O(L.+%#,*+
4+*'A#,(3E&%+
?%+N%+
M&D.&%%+
.")/0%1 .")/0%1
M&D.&%%+ P=O(L.+%#,*+
.")/0%1
4+*'A#,(3E&%+
?%+N%+
M&D.&%%+
4+*'A#,(3E&%+
.3?
M&D.&%%+
=&'+*.' M&D.&%%+
?%+N%+
M&D.&%%+
L%0.D&%+O P=O(L.+%#,*+
.")/0%1 .")/0%1
2130(
,(4(0%5#(6'
モバイルアプリ開発での
課題
モバイルアプリ開発での課題
サーバーはRESTfulなAPIを作りたい
クライアントはUIに対して使いやすいAPIが欲しい
Hr[rŲĻ
4U*,*0
=4T(%&'V*.&, L","5"0%
@VU*,*0
K.'%*0 @N.'%*0
W--4(/%,U*'
789 :;9
:<=9 ,8>898
789 :;9
:<=9 ,8>898
:(+%0*A+#%&<DML6:=4T&ēŁ"6'Ġ,
Dk><pUŲĻ
! :'Ňƣ"ŮĒ'lNrL4TrO:®ð6x06
! 93):Ňƣ:īā6'&:'=4TGrm"ĸ,
! 4&.3?J=&'+*.''uė"=4T4®ðTrO:
]KXLoKRD:đ%
@VU*,*0
@N.'%*0
ưBnpPrªĮŧ
:'Ňƣ&0'ûÅ ŭŏ7!6
! ¾¼`n]hr
! ăûÅ
! ÎřĿþ
ÎřĿþ&Ä ĔŶ'ŭŏ
\Orp(Ë 'oKRD(Dk><pU'Ƃ
¦
ưBnpPrªĮŧ
! 'Ňƣ:Dk><pUŮĒ=4T:»*ēí:!ŭŏ 6'(ÌÉ ":'àÌ%=4T&ƞř
! ĔŶŭŏ(.3?J=&'+*.''ƙ"á%3 &ı 1epS:6'(ÌÉ
@V+.&, qŎ
qă qÎřĿþ
q'|
.R(GÎřĿþXX(ġÎřI(Y Z
[(%S0%(.R(GÎřĿþXX(ŻI(Y Z
[(%S0%(.R(GÎřĿþXX(ÎřvI(Y Z
[
例：カレンダー印刷機能
• 様々な制約条件の中で改善を進めるため、 iOS-Android-Server 間でのコミュニケーションによる調整コストが増加
• 複数OS ＆複数バージョンの影響範囲を考慮しながら、いくつ ものリソースを内包した巨大APIをメンテするのは非常に困難
• エンジニアの頑張りがあっても、実際に不具合も起こしてしま いユーザーに迷惑をかけたこともある
課題まとめ
サーバーAPI 複雑化
iOS&Android間で複雑なAPIを扱うビジネ スロジックの分散
解決策の検討
1. 品質管理の徹底
• 自動テスト（Unit test, UI test 等）の網羅によりデグレを防ぐ
• API修正のたびに過去バージョンも考慮した手動テストを行う
不可能ではないが、テストパターンの量や開発生産性を 考えるとスマートな解ではない
サーバーAPI 複雑化 iOS&Android間で複雑なAPIを扱うビジ
ネスロジックの分散
2. ネイティブでコード共有
• Kotlin/NativeなどでiOS&Androidともに利用できるビジネスロ ジックをライブラリ化する案
• 整理が必要なことが多い
• 社内でのノウハウ不足のための技術調査コスト
• 共通ライブラリ修正時のCIフローの検討
一部で有効かもしれないが、コストが高い割に完全に幸 せにならない
iOS&Android間で複雑なAPIを扱うビジ ネスロジックの分散
3. API に表示ロジックを寄せる
• APIの方で契約状態に基づいた文言やUI表示の出し分け処理もしてしま い、実際の文字列を返す
• 住所もクライアント表示のために必要な整形を済ませて返す
• クライアント（iOS&Android）は受け取ったデータを表示するだけで済 むので、クライアントでのビジネスロジックコードを大幅に削減可能
• サーバーAPIでテストを充実させていれば品質担保も可能
方向性は悪くない。が、片方の課題しか解決できていない
iOS&Android間で複雑なAPIを扱うビジ ネスロジックの分散
3. API に表示ロジックを寄せる：懸念
• ビジネスロジック以外にもi18n対応、日付整形など、サーバー 側で行わなければいけない事が一気に増える
• 組織的にもサーバーエンジニアはこれまで負っていなかった
「画面表示」という責務を負うことになる
• ただでさえ現状のAPIアプリケーションは Monolithic なのに、そ こに責務の範囲がさらに増えていく方向に進んでしまう
→ このソリューションを、現状の API アプリケー
ション以外のところで実現できないか？
BFF(Backend-for-Frontend)
の登場
BFF とは
“One backend per user experience”
1つのユーザー体験に密結合なバックエンド
引用: https://samnewman.io/patterns/architectural/bff/
!)) #(
GL%0$,*VI!)) !))
GC*5.S%I
?%+N.#%
= ?%+N.#%
! ?%+N.#%
2
! Dk><pU#[RD@pV Hr]L'ƙ&Ĉ,6=4Tß
! Dk><pU(ōċ[RD@
pVHr]L:±&!)):
±
! !))(Dk><pU'ů&´
9!ĝƒ¨76
ĢMRJjp"(!""(w&#$%&'()*+(,ŋ
%<rCSDQg'0':vò&ż,
!)) #(
GL%0$,*VI!)) !))
GC*5.S%I
?%+N.#%
= ?%+N.#%
! ?%+N.#%
2
!))³[RD@
pVHr]L#
Ƌ
Dk><pU H>VŕŁ
[RD@pV ŕŁ
Dk><pU(
!))#Ƌ
!)) 'Ōŋ G:I ưƂ¦'Ơ
! Dk><pU#&8T1=4Tů
Ĭ%Æ´7:!
[RD@pVZpVlp E6'(ƢŀÖŋ
! Dk><pU#&ƕ´'Ū ƮƱÚş´%Ư=4Tß:Ņý 6#"Ƃ¦'Ơ"
6
! ư ^%,RS.a
!))
GC*5.S%I !))
GL%0$,*VI
!))
G-KI !))
Gc"/%(#*&0*S%I
-U.0(4U*,*5B(8&$&*E&(=A,U*+(.0(S.#%&0%'(A&'%+(22(!d\?=
!)) 'Ōŋ G9I ưƞřqÉČ
! Ĭ%[RD@pVHr]L
#Ƌ!TrOƞř
! 4&74'TrO:Dk
><pU&ƒí&ÉČ
! Dk><pU(!))#Ƌ
7)ƞřĸ-'TrOŤ ƈ!6'"ą1%
6
! C.#+*0%+N.#%:Ë FrL
"ĝƒ
!)) GC*5.S%I
?%+N.#%
= ?%+N.#%
! ?%+N.#%
2
!)) ư )"// 'Æ´
! C.#+*0%+N.#%"(%ŮĒ
'[RD@pV=4T4lNr L:®ð!ƞř
! ĔŶ%$'8ToKR D:!))&ƞř6#"
.3?J=&'+*.''ƙ"đ!
6oKRD:¸
irIrƩň%6Æ´(-./0#1234-2
"'!"":īŗ6\Orp05
!)) GC*5.S%I
4U*,* =''+%00 4"B/%&,
3<= 26$@%3$
BFF(Backend-for-Frontend)
の導入
BFF 導入にあたる取り決め
• BFF APIはクライアントエンジニアの管轄
• APIの作成や修正、管理はクライアントエンジニアが行う
• クライアントエンジニアが管理するなら、インフラ管理はした くない →サーバーレスでやろう
• サーバーレスで実現するための環境整備はサーバーサイドエン ジニアが行う
• サーバーレスの環境周りの課題があればサポートする
ĆŬƓÕưŶž
! -BV%?#+.V,:ƓÕ
! éŐ'+'Hr[rnL Ge"/5'"I"(c*:!6 (Dk><pU@p KW<#!1Ŷž :ƓÕ
ĆŬƓÕưłÇ G:I
e"/5'"<(=>?"Hr[rnL=4T 6%47
=4T(c",%E"B<(=>?"Hr[rnL
=4T 6%47
0%+N%+S%00<(e"/5'"f=4T c",%E"B' ŕŁ1T`o>ØĚ&%6'"
ĵŅ
ĆŬƓÕưłÇ G9I
A2BCD
W--4(/%,U*'
=4T(%&'V*.&,
@YV+*aBf[
=VVS.#",.*&
! cM-(@V+.&,
! cM-(@U*D%
! %,#Z
! =4T(c",%E"B(=^d"!'lD@LU:¯e"/5'"(:'MaV+%00<
`lFrJjp"ŮĒ@pVa>pU:ZpVlpE63 &
! =4T(c",%E"B f e"/5'"È6#ŕŁƐŅÌÉ&%6/'\Or
p:ĊŅ
ĆŬƓÕưłÇ G9I
A2BCD
W--4(/%,U*'
=4T(%&'V*.&,
@YV+*aBf[
=VVS.#",.*&
! cM-(@V+.&,
! cM-(@U*D%
! %,#Z
! ĢĤ(,5šƫ"(%Źŷ07%Ńńøq࣠1qzïÈ6"8 @pVa>pUĒ'űĭ:ť
!0Ïì#ĕ
īā
3<=
26$@%3$
!))(=4T
!"#$%&'(=4T(
M29(G=?cI Me! e"/5'" =4T(c",%E"B
Ž²qŽź
!))(=4T
!"#$%&'(=4T(
! =4T(c",%E"B(' =4T($%B##0&!"#$%&'(=4TŅ'UrDp0lD
@LU"ĺ!6
! ,5ŀĿ'īā(!"#$%&'(=4T&Úş´%Źŷ"6
! ŀĿéŐ&(+#;$C.#+*0%+N.#%%'"7"Ɔ5!6
zï!))4|C.#+*0%+N.#%:Grm6Ɲ&(Žź'Űō
óů
2:?EF(G 9%/(6
i18n
• i18n npmモジュールで特に不都合なく対応可能
• Backend APIアプリケーションの方であればライブラリ導入や管
理で悩んでいたところだったが、BFFなのでクライアントエン ジニアが自発的に意思決定＆導入できた
-%0,@2T@L%VS*B
! SLU( g%0,(:Ņ
! '%N%S*V@/"0,%+(& /%+D%(742.+#S%2TŞņ"77T`o
>Ƅ6
! 0%+N%+S%00(2eT(' '%VS*B(GbpV6'"2T0Ř©&īŗ
! 2.+#S%2T'T=CŹÕ:ô7&
/"0,%+
J(K' 'K) K(@4(@0(KKE
$(50%G
最後に
今後やりたいこと
• 今後Microserviceが増えた時に、BFFが複数Microserviceと通信で きるような設計（主に認証認可の課題）
• 現在はBFFは一度インターネットに出ていってBackend APIと通 信しているので、VPC内で通信を完結させるなどして速度の最 適化をしたい
• BFFを導入できてから「この画面もBFF化したい」というところ も見えてきたので、その移行をしていきたい
伝えたいこと
自分のチーム・プロダクトの課題は何なのかを考え、
それを解決するソリューションを導入すること
伝えたいこと
• 「それがモダンな技術トレンドだから」などの安易な理由で技 術導入をしてはいけない。必ず失敗します。
• 何事も「何の課題を解決したいのか？」という課題ドリブンで 思考し、技術選定→導入しましょう。
• 本セッションは技術の紹介だけでなく、Timersという1組織にお ける課題特定→解決プロセスのケーススタディと捉え、参考に していただければ幸いです。
ĊŅvƬ
! ŀÃ@pKW<ŒĪĊŅvƬ
! ľ&Hr[rH>V@pKW<
! ũº6ė( `93#(@Kb(1 `93#(@KE9()*E.0%1b(:ĨŚ
! -E.,,%+(!"#"$%&'()* 0^AorƧ,
