モバイルアプリの API 管理を「サーバーレス × BFF」で改善した Timers に学ぶ、課題解決への取り組み方

2020-02-03
インタビュー

椎名アマド氏 (株式会社Timers CTO)

今回は、2019 年 10 月に開催された「 AWS DevDay Tokyo 2019 」の Call for Paper (公募) 部門で、「サーバーレスで作るモバイルアプリ向け Backend For Frontend」というテーマで講演を行っていただいた、アルバム共有サービス「 Famm (ファム)」の開発を手掛ける Timers の CTO 椎名 アマド 氏 (@amado_tech) にご登場願い、サーバーレスによる BFF を採用された背景や経緯について振り返っていただきます。

話題のポイント

課題

モバイルサービスの成長に伴い、サーバー API 複雑化し、複数の OS やバージョンの影響範囲を考慮しながら、巨大 API をメンテナンスすることが困難に。それに伴い、iOS、Android 開発を担うフロントエンドエンジニア、サーバーサイドエンジニア間の調整コストの増加も、見逃せない課題として顕在化しはじめていた。

解決策

AWS Lambda、Amazon API Gateway を導入し、新機能導入を機に UI にまつわる API 環境をサーバーレスと BFF に移行。

成果

クライアントごとに異なる文言の出し分けなど、UI ロジックを BFF に集約することで、 iOS と Android で分散していたロジックを吸収。フロントエンジニアは TypeScript を用い自らの手でAPIの作成、修正が可能になったほか、 AWS の活用でサーバーの管理も不要になった。

家族アプリ「Famm」が 抱えていた根源的な課題

「聴衆のみなさんの反応を通じて、サーバレスによる BFF に大きな可能性があると感じました。今後、モバイルアプリの普及とともに、認知はさらに広がると思います」 昨年の AWS DevDay Tokyo 2019 に登壇した椎名アマド 氏は、登壇の印象をそう振り返ります。

ここでいう BFF とは、「 Backends For Frontends 」を意味し、その名が示す通り「フロントエンドのためのバックエンドサーバー」を指します。

BFF はクライアントとバックエンドサービスの間に位置し、フロントエンドを支える役割に徹するバックエンドサーバーです。クライアントは BFF を叩くだけで、最適化されたデータを得ることができるため、たとえばクライアントごとに異なる UI や API 要件が必要な場合でも、整合性や信頼性を担保しつつ、容易に合理的な API 環境の構築が可能です。

では、なぜモバイルアプリの普及によって BFF の注目度が高まるのでしょうか。それは、モバイルアプリは、クライアントのバリエーションが増えるに従って、API サーバーがすべてのクライアントの要求に応えることが難しくなる宿命にあるからです。それは Timers が手掛けるモバイルアプリ「Famm」も例外ではありませんでした。

img_timers_01

「たとえば Famm のカレンダー発注画面には、商品プレビュー、配送先情報、契約状態など、複数データベースから集めた情報を成形し表示する必要があります。どのような形で実現するにしても、安易に解決を図ろうとすると、フロントエンドエンジニア、サーバーサイドエンジニアのどちらかに負荷を強いる選択をしがちです。しかしそれでは解決策として不十分。そこで 2015 年のリリースから 3 年目ほど経ったころから、エンジニアチームでこうした状況を改善するにはどうすべきか、検討をはじめました」

ブラウザのリロードで最新のアプリケーションが手に入るウェブアプリとは異なり、モバイルアプリのアップデートの可否はユーザーの判断と行動に委ねられるため、モバイルアプリのデベロッパーは、OS やクライアントのバージョンが上がるたび、これまでの経緯を踏まえた開発をしなければなりません。放っておくと管理コストは積み上がるばかりです。

「アプリを起動するたびに、最新バージョンにアップデートするよう促せば、バージョンの違いを考慮する必要はなくなりますが、Famm のユーザーには、ITリテラシーがそこまで高くない方が少なくありません。みなさんの負担を考えると、こうした手段を採りづらいのが現実です。そのため、リリースからしばらくは、クライアントが複数の API を叩いて UI を成形し、表示するのではなく、ひとつの大きなバックエンド API に情報を集約する形でサービスを運用していました」

しかし、サービスが成長するにつれて新機能の実装や改善要求も高まれば、自ずとサーバーサイドエンジニアの負担も増えてしまいます。かといってフロントエンジニアにその負担を押しつけるのもスマートな解決とはいえません。

「モバイルアプリの開発に携わるフロントエンドエンジニアは、通信環境が不安定な状況を想定して、なるべく大量の API をコールするのは避けたがるものです。それに対してサーバーサイドエンジニアは、メンテナンス性やレスポンスの速さを考慮し、リソースに対して RESTful な API を作りたいと考えるのが普通です。今後の成長を考えると、両者の異なる考え方や理想の間にある溝を埋めるような解決策がどうしても必要でした」

img_timers_02

さまざまな可能性を検討し、 サーバーレス × BFF を選択

img_timers_03

椎名氏のエンジニアチームが最終的に選択したのは記事冒頭で触れたように、サーバーレスによる BFF の導入でした。しかし最初から BFF ありきで改善に取り組んだわけではなかったといいます。

「サーバー API の複雑化を解消するだけなら、RESTful な API 環境を整備すれば済む話です。しかしそれでは、iOS と Android で同じようなコードを実装することによる、ビジネスロジックの分散という課題は残ってしまします。そこでチーム内でいろいろな可能性を検討しました」

人手による品質管理の徹底から、 Kotlin/Native を使い iOS と Android でわかれていたビジネスロジックをライブラリ化する案、また API に表示ロジックを寄せ、住所や会員ステータスなどの情報をサーバー側で成形し、クライアントに返す案なども検討されましたが、どれも学習コストや副作用の懸念を上回る利点が得られるとは思えませんでした。

「しかし、しかしひとつだけ可能性を感じる案がありました。それがサーバーレスによる BFF の導入です」
そこで早速、当時開発に着手することが決まっていた過去の写真ストックからカレンダーを注文する新機能で試してみることにしたといいます。

そこで早速、当時開発に着手することが決まっていた過去の写真ストックからカレンダーを注文する新機能で試してみたところ、結果は上々だったといいます。

「以前から使い慣れていた AWS LambdaAmazon API Gateway を選定し、言語には TypeScript を採用したことで、フロントエンドエンジニアは UI 表示に必要な情報を取得する API を自ら書いてデプロイできるようになりました。また、サーバーサイドエンジニアは、クライアントの UI の都合を気にせず、データを綺麗に返すだけの RESTful な API を書くことに集中できるようになり、双方にとって満足できる成果が出せたと感じています」

img_timers_04

一時は、ベストプラクティスを追求するため、ひとつの API ごとに Lambda と API Gateway を作り直すべきかもしれないと考えたこともあったそうですが、管理に割く時間が増えることを恐れ、この選択はあえて避けたと椎名さんはいいます。

「サービスの成長性を考慮に入れたとしても 100 を超える API を使う状況は考えにくいため、ひとつの Lambda、API Gateway で、すべての API を受けることにしました。ベストプラクティスに固執せず身の丈に合った選択をしたことも、BFF 化に成功した要因といえるかもしれません」 

トレンドだからというだけで新技術に飛びつくのは早計

新サービスの導入を契機に BFF 導入に踏み切ってから約 1 年。椎名 氏は、この試みに起因するトラブルは発生していないといいます。

「エンジニア組織も大きくなり、やれること、やるべきことが増えている状況の中、フロントエンドエンジニア、サーバーサイドエンジニアが、それぞれの専門性を発揮しやすい環境を整えるのが CTO としての責務です。これからの検討事項ですが、現在稼働中の機能についても、効果が見込める部分から徐々に BFF 化して、効率的な管理・運用ができる体制を整備していければと思っています」

最後に、モバイルアプリ開発の過程で Famm と同様の課題に直面し、打開策を探しているデベロッパーのみなさんが、「サーバーレス × BFF 」を導入するにあたって注意すべき点を聞いてみました。

「BFF のように、アーキテクチャーの変更によってシステムに新たな層が形成されるような場合、構成や技術選定と並行して、フロントエンジニア、サーバーサイドエンジニアの役割分担を明らかにしておくことが重要です。管掌する役割がはっきりすれば、チームの動きが速くなりますし、周囲も責任者が職務をまっとうできるようサポートしやすくなります。無用なトラブルを避ける上でも役割分担は、早い段階で明確に決めるべきだと思います」

img_timers_05

しかし、それ以上に大事なことがあると、椎名 氏は指摘します。

「登壇した際にも申し上げたのですが、それがモダンなテクノロジーだから、トレンドだからという理由で技術導入を行うと、いずれ後悔することになるでしょう。すべての事例に通用する解決策はありません。何事も “課題ドリブン” で考えることが大事だと思います」

安易な技術導入を避けることは、効果の薄い対策に時間的、金銭的コストをかけることにもつながります。これはサーバーレス × BFF の導入過程で得た実感のひとつのようです。

「今回の選択は、私たちの置かれている組織的な状況やサービスの方向性を精査した結果に過ぎません。チーム構成、サービスの性質が違っていたら、おそらく別の選択をしたことでしょう。とはいめ、同じ課題を抱えるデベロッパーのみなさん自身が、この事例をきっかけに、サービス改善の最適解を見つけていただけたらうれしいですね」

椎名 氏が指摘する通り、実情に合った対策を行うことが、迅速な課題解決につながります。話題や流行に踊らされることなく、課題の本質を正しく捉えて正しく判断することは、さまざまな課題解決に応用できる考え方といえそうです。


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

photo_timers

プロフィール

椎名アマド氏 (@amado_tech)
株式会社Timers CTO

1987 年東京生まれ。早稲田大学国際教養学部を卒業後、DeNA に入社。 モバゲースマートフォン版の立ち上げ、スマートフォンアプリ向けゲームエンジン開発マネジメントなどを担当。 2012 年 4 月に同社を退社し、Timers inc.を共同創業し現職に。

AWS Dev Day Tokyo 2019 で使用したスライドはこちら »

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する