マイクロモビリティシェアサービスを支える プラットフォームアーキテクチャ

Transcript

1. 機密・専有情報 株式会社Luupによる個別の明示的な承諾を得ることなく、この資料を使用することを固く禁じます。 Wataru Tsuda / gr1m0h 2025.08.23 オープンセミナー2025@広島 マイクロモビリティシェア サービスを支える プラットフォームアーキテク チャ
2. Luup, Inc. - Confidential and Proprietary 2 whoami Wataru Tsuda / gr1m0h SWE, SRE @Luup,inc. 竹原市で生まれ育ち、広島市在住 広島商船高専→東京で6年くらい→2023年にUター ン
3. Luup, Inc. - Confidential and Proprietary 3 チャプター（最大1行） https://speakerdeck.com/grimoh/jun-hajian-teirugaguan-cha-siteinai-dekao-eruinsidentomanezimento オープンセミナー 2024@広島
4. Luup, Inc. - Confidential and Proprietary 4 チャプター（最大1行） 今日話すこと
5. Luup, Inc. - Confidential and Proprietary 5 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
6. Luup, Inc. - Confidential and Proprietary 6 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
7. Luup, Inc. - Confidential and Proprietary 7 Mission 街じゅうを「駅前化」する インフラをつくる 日本の過密化している都市圏では、駅から遠くアクセスが悪い立地にも多くの人口が存在しています。 「駅近」という言葉に象徴されるように、不動産価値には駅の近さが大きな影響を与えています。 LUUPは既存の交通インフラの隙間を埋めて補完する、新たな短中距離移動のインフラです。 鉄道網が大動脈だとすれば、LUUPは毛細血管のようにきめ細やかな移動網を張り巡らせていきます。 LUUPのポートは、毛細血管を繋いでいる小さな駅のようなものです。 LUUPのポートを至る所に設置することで、 徒歩だと遠いと感じる距離もLUUPを使えば数分で自由自在に移動することができます。 そのように街じゅうを「駅前」のように便利にすることで、街全体の価値が上がる未来を目指しています。 LUUPとは ミッション
8. サービス紹介 LUUPとは 電動マイクロモビリティを、スマホひとつで、 好きな場所で借りて好きな場所に返せるサービス
9. 全国ポート数 14,800 箇所以上 展開都市 東京 横浜 神⼾ 京都 ⼤阪 名古屋 宇都宮 東京 ⼤阪 横浜 京都 名古屋 神⼾ 宇都宮 ※2025年8⽉時点 広島 広島 仙台 仙台 福岡 福岡 北九州 浜松   岡崎  那覇 川崎 LUUPとは - サービス規模と展開都市 札幌  etc.
10. Luup, Inc. - Confidential and Proprietary 10 電動キックボード 電動シートボード coming soon 電動アシスト自転車 Luupが開発した日本最小クラスの 電動アシスト自転車です。 少し漕いだだけで快適に進める馬力があり、 誰でも疲れずに乗ることができます。 2017年から世界中で普及が進んでいる 電動マイクロモビリティです。 漕がずに乗ることができるため、スカートや スーツの方でも気軽に利用できます。 電動シートボードは、電動アシスト自転車や 電動キックボードが対応しきれていない 利用ニーズや幅広い世代の利用をカバーする、 新しいモビリティです。 ※車両区分：特定小型原動機付自転車 LUUPとは 取り扱いモビリティ
11. 「全ての⽅々の移動課題の解決」を実現するため、 多様なニーズに応えるマイクロモビリティの開発を⾏っています。 ※車両は現在開発中のものです。正式導入時には細かい仕様が変更になる可能性があります。 
 電動キックボード （特定⼩型原付） 電動アシスト⾃転⾞ ⾞両の展開について 電動シートボード （特定⼩型原付） ※順次導⼊予定 三輪‧⼩型のユニバーサルカー 「Unimo（ユニモ）」 LUUPの⾞両について
12. ユーザー向けモバイルアプリ以外にも、社内システムや車両管理系の基盤も自社開発 ▶オペレーション開発 ▶ユーザー向けアプリ ▶IoTバックエンド iOS, Android toCモバイルアプリ ポート巡回中や倉庫の作業で使うアプリケーション ポートの営業活動を支援するツール、 etc. 車両に搭載 SIMを通じて通信する基盤 30,000台以上ある車両の管理システムも Luupの組織 ソフトウェアプロダクト全景
13. Luup, Inc. - Confidential and Proprietary 13 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
16. Luup, Inc. - Confidential and Proprietary 16 チャプター（最大1行） 現在のサービスアーキテクチャ 主な構成要素について紹介 - Firebase https://firebase.blog/posts/2019/01/cloud-firestore-in-general-availability 「最少人数」「最速」で動くものを求められた環境での判断だったのでmBaaSを選択した - 事業としては、ソフトウェア以外の要素（ポート獲得、車両調達、実証実験の運営な ど）が多い - 早期に仮説検証を行うため、まず動く形にすることが重要 - 当時、正社員エンジニアはCTO1人のみ Firebase選定理由 - マルチテナント特性を持ったFirestoreを利用すれば、バックエンドなしにできる - IoTと決済はバックエンド処理が必要なので、Cloud Functions for Firebaseを使った - Firebase Authenticationを認証に使えば、FirestoreやCloudFunctionsとの認証をセ キュアに作りやすい - 2019/2にFirestoreがGAし、スタートアップ中心に採用事例も増えてきて商用利用に 耐えられると判断した
17. Luup, Inc. - Confidential and Proprietary 17 チャプター（最大1行） 現在のサービスアーキテクチャ 主な構成要素について紹介 - IoTバックエンド https://mosquitto.org/ https://www.emqx.com/en/blog/why-emqx-is-your-best-google-cloud-iot-core-alternative Managed MQTT BrokerがGoogleに無いので、AWSを利用している - Eclipse Mosquittoの自前運用をしていたが、運用負荷軽減のためにManaged Serviceへ移行 - 2023/8/16にCloud IoT Coreは廃止 車両でSORACOM IoT SIM/Air を利用している SORACOM Beamを経由して各クラウドに接続している 通信プロトコルによって接続先が異なる - MQTT: SORACOM Beam（MQTT→MQTTS）→AWS IoT Core - TCP: SORACOM Beam（TCP→TCPS）→Backend Server(GCE)
18. Luup, Inc. - Confidential and Proprietary 18 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
19. Luup, Inc. - Confidential and Proprietary 19 チャプター（最大1行） “SRE” を取り組むようになった経緯 事業計画をきっかけにSREが誕生 Before: - モバイルアプリファースト、Firebaseファーストで作られたサービス - バックエンド開発とインフラ運用管理が渾然一体となっていた - インフラ運用管理に専任担当者が居ない状態だった →インフラがアグレッシブなグロース計画に耐えられなくなりそうだった Project 10xと呼ばれる、10xグロースに耐えるためのインフラ整備計画が作られた - 事業計画が5xなら、インフラは10xスケールへの準備を考えたい...!!!
20. Luup, Inc. - Confidential and Proprietary 20 チャプター（最大1行） “SRE” を取り組むようになった経緯 Project 10x https://speakerdeck.com/0gm/srede-teamkai-fa-tipstobesutopurakuteisutupoihe-ka?slide=57 信頼性を上げて、グロースおよびハイパーグロースに持っていくための計画
21. Luup, Inc. - Confidential and Proprietary 21 チャプター（最大1行） “SRE” を取り組むようになった経緯 Project 10x https://speakerdeck.com/0gm/srede-teamkai-fa-tipstobesutopurakuteisutupoihe-ka?slide=57 信頼性を上げて、グロースおよびハイパーグロースに持っていくための計画 - 10x 以上のリクエストに耐えられるインフラを用意する - Observability （監視）を強化する - MTTD, MTTR 改善および Capacity Planning のため - SREsを増やす - 開発組織全体へのSRE啓蒙、実践 - 先に監視の強化を行う - SREは、セキュリティやテストと同じく一定水準以上はサービス開発者側も実践が 必要
22. Luup, Inc. - Confidential and Proprietary 22 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
25. Luup, Inc. - Confidential and Proprietary 25 チャプター（最大1行） SREチームの取り組み IoTバックエンド - 車両との通信の不通期間が発生したときにIoTバックエンドで問題が起きていた - AWS IoTからCloud Functionsを叩いていたが、インシデントから回復したときに一斉 にリクエストが投げられて、サーバーに負荷がかかる状況にあった 課題
26. Luup, Inc. - Confidential and Proprietary 26 チャプター（最大1行） SREチームの取り組み IoTバックエンド - Amazon SQS + AWS Lambdaを追加してExponential Backoff Retryを実現 - 関数実行を遅延させることで、一時的な負荷を軽減し、効率的に処理する 対応
27. Luup, Inc. - Confidential and Proprietary 27 チャプター（最大1行） SREチームの取り組み オブザーバビリティ 課題 - 監視対象・アラートが整理できていない - 複数のクラウドプロバイダーのテレメトリーデータを統合的に確認したい 対応 - Datadogの採用 - SLOの設定 - ダッシュボード・アラートの整理
28. Luup, Inc. - Confidential and Proprietary 28 チャプター（最大1行） SREチームの取り組み オブザーバビリティ - Datadogの採用 https://www.datadoghq.com/ja/ 「最少人数」「最速」でオブザーバビリティの課題を解決するためDatadogを採用 - 正社員エンジニアで有識者が居ないなか、パートタイムエンジニアで有識者が多い Datadogを採用した - ダッシュボードやアラート設定、SLO、APMなど実現できることがある程度わかって いるので、検証時間を減らしナレッジを活用できる - 既に他社で運用しているので、運用状態もイメージできる状態だった
29. Luup, Inc. - Confidential and Proprietary 29 チャプター（最大1行） SREチームの取り組み オブザーバビリティ - SLOの設定 以下の目的でSLOを設定している - お客様目線でサービス監視を行う - 機能開発と信頼性のコントロールを行う SLO: サービスの品質指標の目標値 - e.g., 一定期間のうち、有効なリクエストの成功率が何％あるか SLOに基づいたアラートを設定することで、本当に対応が必要なアラート が発報される様 になる SLOとして、信頼性を計測することで、信頼性を損なわずリリースを早めるということが できるようになる
30. Luup, Inc. - Confidential and Proprietary 30 チャプター（最大1行） SREチームの取り組み オブザーバビリティ - SLOの設定 通知 SLO Monitor作成 ︙ テレメトリーデータ 送信
31. Luup, Inc. - Confidential and Proprietary 31 チャプター（最大1行） SREチームの取り組み オブザーバビリティ - ダッシュボード・アラートの整理 デプロイメトリクス - Cloud Run Functions, Firestore, Firebase hostingのデプロイ情報を表現 - エラー率やレイテンシー等を見ながら、デプロイ情報を確認できる - インシデントがあった際、直前のデプロイ状況に気付ける
32. Luup, Inc. - Confidential and Proprietary 32 チャプター（最大1行） SREチームの取り組み オブザーバビリティ - ダッシュボード・アラートの整理 https://zenn.dev/luup_developers/articles/sre-gr1m0h-20241111 モバイルアプリの新バージョンのパフォーマンス劣化に気づくためのアラート設定
33. Luup, Inc. - Confidential and Proprietary 33 チャプター（最大1行） SREチームの取り組み インシデントマネジメント 課題 - オンコール体制が整備されていない - インシデント情報が管理されていない 対応 - WaroomとPagerDutyの採用 - オンコール体制の整備と一次対応のサポート
34. Luup, Inc. - Confidential and Proprietary 34 チャプター（最大1行） SREチームの取り組み インシデントマネジメント - Waroomの採用 https://waroom.com/ 「最少コスト」「最速」でインシデントの課題を解決するためWaroomを採用 - コスト - 多くのインシデントマネジメントサービスがユーザー単位の料金体系 - Waroomはユーザー単位ではなく組織単位の料金体系 - サポート - Slack Connectを使ったコミュニケーション - 日本企業のサービスなので、日本語でサポートしてもらえる - 機能の適合性 - サービスローンチ段階からインシデントマネジメント・レスポンス周りの困りご とを概ねカバーできていた - オンコール対応も楽になった部分がある（後述）
35. Luup, Inc. - Confidential and Proprietary 35 チャプター（最大1行） SREチームの取り組み インシデントマネジメント - オンコール体制の整備と一次対応のサポート オンコール体制が整備されていなかったので、以下の体制を整えた - PagerDutyによる24/7のPager - 休日日中のオンコールシフト Waroomの機能で以下を実現し、一次対応をサポートした - Waroomでインシデントを起票したら自動的にSlackチャンネルを作成する - Slackチャンネル作成時に指定したメンバーを招集する - Slackチャンネルの情報をサマライズしてドキュメントを作成する
36. Luup, Inc. - Confidential and Proprietary 36 チャプター（最大1行） SREチームの取り組み インシデントマネジメント - オンコール体制の整備と一次対応のサポート Slack Appを開発 - 当番のオンコールメンバーだけにメンションする - 当番ではないオンコールメンバーにメンションしないようにした - Cloud Runでオンコール当番表（Google Spreadsheet）を読んでメンションをリダイ レクト
37. Luup, Inc. - Confidential and Proprietary 37 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
38. Luup, Inc. - Confidential and Proprietary 38 チャプター（最大1行） 今後の展望 SREとして....Qualityチームとして.... オブザーバビリティシステムの整理 - Google Cloud Observability, Firebase, Superset, Datadog, Sentryを利用中 - コスト、データ管理、データ鮮度、ユーザービリティの観点で最適な形を模索する 品質チェックのシフトレフトの確立 - 機能、パフォーマンス、セキュリティ等 - 自動テストツールの導入・改善 - ASPM/CSPM等の導入検討 その他、アーキテクチャ変更...
39. Luup, Inc. - Confidential and Proprietary 39 1. サービス/事業紹介 2. 現在のサービスアーキテクチャ 3. “SRE” に取り組むようになった経緯 4. SREチームの取り組み 5. 今後の展望 6. まとめ
40. Luup, Inc. - Confidential and Proprietary 40 チャプター（最大1行） まとめ LUUPアーキテクチャの特徴 - FirebaseをはじめとするGoogle Cloudを基本としたアーキテクチャ - AWS IoT Coreを核としたAWSサービス活用 LUUPアーキテクチャに対するSREの活動 - IoTバックエンド - リクエストの集中による高負荷をSQSで平準化 - オブザーバビリティ - DatadogとSLOを導入し、顧客視点での監視を実現 - インシデントマネジメント - オンコール体制を整備し、Waroomを導入してプロセスを効率化 インシデントマネジメント上の課題やプラクティスについて語りましょう！ - #OSH2025, @gr1m0h で
41. 一緒に、街じゅうを「駅前化」する インフラをつくりませんか？ 詳細は採用ページをご覧ください https://recruit.luup.sc/