「LUUP」におけるFirebase活用事例。効率的な開発と長期運用で見えた課題
参考になった
1
株式会社Luup / slightair
テックリード / テックリード
| ツールの利用開始時期 | 事業形態 |
|---|---|
| 2018年10月 | B to C |
| ツールの利用開始時期 | 2018年10月 |
|---|---|
| 事業形態 | B to C |
アーキテクチャ
アーキテクチャの意図・工夫
モバイルアプリ中心のサービスで、アプリや車両IoTデバイスからの情報更新などを契機に様々な処理が走る、イベント駆動型のアーキテクチャとしてまとまっている。 FirebaseとGoogle Cloudのサービス群を組み合わせて構築し、フルマネージドサービスを中心に採用することで、管理コストの削減とスケーラビリティの確保を図っている。 一部車両ではIoTデバイスとの接点にAWS IoT Coreを利用しているが、アプリ側のバックエンドやフロントエンド開発のスピードを優先するためにFirebaseとGoogle Cloudのサービスを主に採用している。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
LUUPというサービスの形になる前から、色々な地域・自治体で車両のアドホックな実証実験を行なっていた。 サービスの形が定まらない中でも、実証実験の結果を受けてデータベースのスキーマや機能を頻繁に変更し、次の検証に進む必要があった。
どのような状態を目指していたか
サービスの形が定まらない中であっても、車両と連携するモバイルアプリの開発と検証を繰り返す必要があった。 スタートアップの立ち上げ前の段階で満足にエンジニアがいない中、モバイルアプリエンジニア中心で機動的に動くものを作りたかった。
比較検討したサービス
- AWS Amplify
比較した軸
- 「最少人数で」「機動的に」動く物を作り、実証実験を進められる
- マネージドサービスにインフラの管理を任せ、管理コストの削減やスケーラビリティ確保が容易にできる
- データベース、サーバサイドとの通信・処理をセキュアに実装できる
- IoTデバイスの操作と決済のためのバックエンド処理が実現できる
選定理由
- アプリ開発へ本格着手しているタイミングで、Firebaseはスタートアップ中心に採用事例が増えていた
- Firestoreが正式リリースされるなど、商用利用に耐えられると判断できるタイミングだった
導入の成果
改善したかった課題はどれくらい解決されたか
実証実験を繰り返しサービスの実現性と形が見えてきた後も、FirebaseとGoogle Cloudを中心としたサービス開発が進められた。 Firebase Authをユーザ認証に利用し、ポートなどのサービス運営に必要な情報を格納するデータベースとしてFirestoreを選択した。Cloud Functionsをバックエンド処理に用いてIoTデバイスとの通信や決済処理を実現できた。
IoT機器を搭載した車両との連携が必要不可欠なサービスにおいて、イベント駆動のサーバレスアーキテクチャは最適な選択だった。
どのような成果が得られたか
サービスのリリース後も、ユーザー数やポート数などのサービス規模の増加、アプリの機能追加・改修を繰り返してきたが、大規模なアーキテクチャ変更を必要とせずに今日まで継続できている。
サービス利用状況の分析などにBigQueryを用いたり、Google Cloudの各種サービスとの接続も容易で、サービスの拡大に寄与している。
導入に向けた社内への説明
上長・チームへの説明
当時は正社員エンジニアがCTO一人で、認証やデータベース、IoTデバイスの操作や決済を含むバックエンド処理を最少人数の限られたエンジニアで作る必要があった。 そのためCTOを中心に開発を進めながら、自らFirebaseのようなmBaaSを採用するのが良いと判断した。 当時はFirebaseとAmplifyが候補に挙がったが、採用事例や情報はFirebaseが圧倒的に多かった。
活用方法
よく使う機能
- Firebase Auth
- 電話番号によるユーザ認証
- Firestore
- ポートの位置情報やステータスなどのマスタ・動態管理
- Cloud Functions
- 車両IoTデバイスの操作・ステータス更新
- 決済処理などのバックエンド処理
- Cloud Storage for Firebase
- ポート写真や車両返却時の撮影画像の記録
- Remote Config
- モバイルアプリの機能の段階的リリース、A/Bテスト
ツールの良い点
- Firebase Authを起点に、FirestoreやCloudStorageのSecurityRulesの設定をコード管理できるうえ、柔軟でセキュアな構築が可能
- 一定の無料枠があるので新プロダクトのPoCに使いやすいのはもちろん、個人の学習やリアーキテクチャのPoCもハードル低く行える
- Firebase Extensionsというオープンソースの連携ツールがあり、データベース・言語モデル・外部サービスなどとシームレスに連携が可能
ツールの課題点
- 初期フェーズでの設計のミスが後々負債化し、便利な機能を使えなかったり、複雑な実装を迫られたりする。初期フェーズでも、一定規模での経験者や上級者に頼れると望ましい
- Firestoreのコレクション毎の費用計算など、コストの詳細なモニタリングは充実しているとは言えない。しっかりと、タイミングを作りコストをレビューしアプローチしないと、大きくなったコスト原因の特定がやや難しくなる
今後の展望
マイクロサービス化
Luupの開発組織も大きくなり、担当チーム間のコミュニケーションコストが増大している。また、車両運用も複雑化しており、適切な機能の切り出しを行い、開発サイクル速度の維持が課題となっている。
可観測性の向上
ユーザーがアプリを操作してから車両に反映されるまで、多くのコンポーネントを通る。車両ファームウェア側の制限などもあり、どの部分にどれだけ時間がかかっているかを完全には計測できていない。サービスの成長のために、今後もログの埋め込みやトレースの紐付けを徹底し可観測性を向上させる。
コスト最適化
ユーザー数も増え、現状のアーキテクチャがコスト最適とは呼べなくなってきている。ユーザー・車両との通信を注視し、サーバー・DB・IoT 部分のコストが最適になるように最適化に取り組む。
株式会社Luup / slightair
テックリード / テックリード
Web企業にてiOSアプリや基盤領域のエンジニアを経て、エンジニア統括マネージャーとして組織作りや採用に従事。現在は現場でのサービス作りに立ち返り、iOSアプリ開発を主軸としたサービス開発エンジニアとして活動しています。
株式会社Luup / slightair
テックリード / テックリード
Web企業にてiOSアプリや基盤領域のエ...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法