はじめに
LuupでSWEをしている、ぐりもお（@gr1m0h）です。
8/23に広島県で開催されたオープンセミナー2025@広島に登壇しました。
毎年テーマが変わるこのイベントですが、今年は「君はどこで動かすか？」がテーマでした。
今回は、LuupのSREチームがビジネスやサービスの特性、そしてその変化に対してどのような課題認識を持ち、どういう対応をしてきたのかをお話ししました。オブザーバビリティツールの選定やインシデント対応の仕組み作りといった具体的な取り組みを紹介しています。
ちなみに昨年は「XRE エンジニアを支える組織」というテーマで行われ、インシデント対応に必要な能力についてお話ししました。
登壇資料は公開していますが、話した内容が資料にすべて反映されているとは言えないので、記事を書こうと思います。
資料は以下です。
現在のアーキテクチャ
以下が現在のアーキテクチャの全体像です。ユーザー向けのモバイルアプリ、車両と通信するIoTバックエンド、そして各種社内システムが連携して動作しています。
中でも主要な構成要素である「Firebase」と「IoTバックエンド」を中心に紹介します。
Firebase
サービスの立ち上げ期、LUUPの正社員エンジニアはCTO1名のみでした。事業の仮説検証を最速で回すため、バックエンドの開発・運用コストを最小限に抑えられるmBaaSを採用しました。
特に当時GAを迎えたFirestoreを中心にスタートアップでの採用事例も増えていたFirebaseを選択しました。
Firebase Authenticationによる認証、Firestoreによるデータベース、そしてCloud Functionsによるサーバーレスなバックエンド処理。
この構成が、最小の人数と時間でサービスを形にする上で最適解でした。
IoTバックエンド
車両にはSORACOMのIoT SIMを搭載しており、SORACOM Beamを経由してクラウドに接続しています。
ここで特筆すべきは、MQTTブローカーにAWS IoT Coreを採用している点です。
当時、Google CloudのCloud IoT Coreはまだサービス提供中でしたが、技術的な制約がマッチせず、Eclipse Mosquittoの自前運用していました。
そんななか、運用負荷軽減のためにManaged Serviceへ移行することになり、AWS IoT Coreを採用しました。
MQTTでの接続はAWS IoT Coreと接続しており、TCPでの接続はGCEのバックエンドサーバーと接続しています。
LUUPの車両には複数のモデルがあり、それぞれで仕様が異なります。基本的には、各モデル標準の通信形式やプロトコルに合わせてサーバー側の開発をしています。
複数の仕様を管理する運用コストはかかりますが、仕様策定のコストも加えた独自の開発費と比べ、低コストだと判断しています。
“SRE” に取り組むようになった経緯
私たちがなぜ「SRE」という役割を設け、信頼性向上を本格的に取り組むようになったのか、その経緯を紹介します。
サービス開始当初は、Firebaseファーストで開発を進めてきましたが、事業が急拡大するにつれて、インフラの運用管理が大きな課題となってきました。
専任の担当者がおらず、バックエンド開発とインフラ運用が一体となっていたため、このままでは事業の成長スピードにインフラが耐えられなくなるとの危機感がありました。
そこで立ち上がったのが「Project 10x」です。
これは、事業計画の5倍の成長に対し、インフラはさらにその先の10倍のスケールに耐えられるよう準備を進める、という計画でした。
このプロジェクトを推進するため、Day1から「SREチーム」と名付けられた専門チームが発足しました。
Project 10x
Project10xは、信頼性を上げて、グロース及びハイパーグロースに持っていくための計画です。
https://speakerdeck.com/0gm/srede-teamkai-fa-tipstobesutopurakuteisutupoihe-ka?slide=57
以下の実現が私たちSREチームに与えられたミッションでした。
- 10x 以上のリクエストに耐えられるインフラを用意する
- Observability（監視）を強化する
- MTTD, MTTR 改善および Capacity Planning のため
- SREsを増やす
- 開発組織全体へのSRE啓発、実践
- 先に監視を強化する
- SREは、セキュリティやテストと同じく一定水準以上はサービス開発者側も実践が必要
SREチームの取り組み
取り組みとしていくつか紹介しましたが、いくつかは既にブログ記事で紹介している取り組みです。ここでは、それらの記事を紹介し、ブログ記事になっていない部分をメインで紹介します。
「IoTバックエンド」の取り組み
当初、車両との不通期間から回復した際、保留されていた車両からのリクエストがCloud Functionsへ一斉に送られ、サーバーが高負荷状態に陥るという課題がありました。
この課題を解決するため、AWS IoTとCloud Functionsの間にSQSとLambdaを挟む構成に変更しました。このアーキテクチャが車両からのリクエストを一度キューイングし、Exponential Backoffを用いてリトライ処理を制御することで、突発的な負荷を吸収・平準化し、システム全体の安定稼働を実現しています。
「オブザーバビリティ」の取り組み
当初は監視対象やアラートが整理されておらず、複数のクラウドに散らばったデータを統合的に見る仕組みもありませんでした。
この課題に対して、Datadogの採用、SLOの設定、ダッシュボード・アラートを整理しました。
私達は、Google Cloud、AWSのテレメトリーデータを統合的に見るためにオブザーバビリティプラットフォームとしてDatadogを採用しました。いくつかこの領域のSaaSがあるなかでDatadogを採用したのは、エンジニアの中に有識者が多く、ダッシュボード作成やSLO設定などの知見を迅速に活用できると判断したためです。また、既にDatadogでの運用経験が有るので、運用状態もイメージできる状況でした。
SLOやダッシュボード・アラートの整理については、以下の記事で紹介しています。
「インシデントマネジメント」の取り組み
SREチーム発足以前は、障害発生時の対応フローが確立されておらず、オンコール体制が整備されていませんでした。
この課題を解決するため、私たちはWaroomを導入し、インシデントマネジメント体制を整備し、インシデント対応の簡略化を実現しました。
まず、私達はインシデント対応プロセスそのものを効率化するため、Waroomを採用しました。Waroomを採用しました。いくつかこの領域のSaaSがあるなかでWaroomを採用したのは、コストメリットが大きいです。
次に、オンコール体制の整備のためにPagerDutyを導入し、24時間365日のオンコール体制を構築しました。これにより、インシデント発生時には必ず誰かが一次対応するという状態を実現しました。
また、休日日中に一次対応するエンジニアを設置するようなオンコールシフトを整えました。
Waroomの採用理由の詳細やWaroomの機能によるインシデント対応の効率化については、以下の記事で紹介しています。
今後の展望
今後は、以下のような取り組みを進めていく予定です。
オブザーバビリティシステムの整理
Google Cloud、AWS、Firebase、Datadog、Sentryなど、複数のクラウドサービスに分散しているオブザーバビリティシステムを整理し、統合的に管理できるようにしたいと考えています。
また、BIツールであるSupersetも導入しているため、テレメトリーデータとビジネスデータの連携・分析を視野に入れて以下の観点でより最適な形を模索していきます。
- 観点：コスト、データ管理、データ鮮度、ユーザービリティ
品質チェックのシフトレフトの確立
現在、体制変更によって、QAチームとSREチームがMergeしてQualityチームとして活動しています。これに伴って、品質チェックのシフトレフトを確立し、開発プロセスの早い段階で品質を担保する仕組みの構築も検討しています。
機能やパフォーマンス、セキュリティーなどを対象に、自動テストの導入・改善、ASPM/CSPMなどセキュリティチェックシステムの導入検討を行っていきます。
さいごに
弊社のプロダクト開発やSRE、QA、使用技術に興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください！私のX(Twitter)アカウントでもDMを受け付けています。
副業や転職をお考えの方だけでなく、気軽に話を聞きたいという方も大歓迎です！
Discussion