新サービス立ち上げの裏側 - QUANT for Shopsで実践した開発から運用まで

GREE Tech Conference 2025で発表された資料です。
https://techcon.gree.jp/2025/session/TrackB-1

Transcript

1. 新サービス立ち上げの裏側 - QUANT for Shopsで実践した開発から運用まで - グリーエックス株式会社 エンジニア 濱口 眞佐志
2. 濱口 眞佐志 2023年にグリー株式会社（現：グリーホールディ ングス株式会社）へ新卒入社。おでかけ情報サー ビス「aumo」にて、バックエンドからフロントエ ンド、クライアントアプリまで幅広い領域で開発 を経験。2024年10月から飲食店向けグルメインフ ルエンサープラットフォーム「QUANT for Shops」の立ち上げ・開発に従事。現在は再び aumoにて、SREやインフラを含めた開発全般に携 わる。 グリーエックス株式会社 エンジニア 2
3. 目次・アジェンダ • プロダクトについて • 開発時の技術選択と取り組み • リリース後の課題 • 新規プロダクト開発で意識したこと 3
4. プロダクトについて 4
5. QUANT for Shopsについて 飲食店向けグルメインフルエンサープラット フォーム グルメインフルエンサーの投稿によって、SNS で話題になるメニューを創出するサービス。人 数や回数の制限なく、PR投稿をしてくれるイン フルエンサーを募集できるため、飲食店の魅力 を効果的に発信。誰でも手軽にインフルエン サーマーケティングを活用できるのが特徴。 インフルエンサー向けのクライアントアプリと 飲食事業者向けのWeb管理画面を提供 5
6. BaaS・ミドルウェア • Firebase • MySQL • Redis インフラ・監視 • AWS • Google Cloud • Docker • Datadog 技術スタック アプリケーション • Ruby on Rails • Next.js • Flutter 6 ※ 記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。
7. 開発時の技術選択と取り組み 7
8. 既存サービスとの共通ログイン 既存サービスのユーザーも新サービス上でログインできるようにするため、認 証基盤はFirebase Authenticationを採用 • クライアントアプリではClient SDKを使用してログインを行い、Firebase 側で発行されたIDトークンを取得 • サーバーへのAPIリクエスト時にBearerトークンとしてIDトークンをリク エストヘッダーに付与 • サーバー側で受け取ったIDトークンの検証を行う ※ FirebaseはIDトークンを検証するための公開鍵を提供しており、この公 開鍵とJWTライブラリを使用することでIDトークンの検証が可能 https://firebase.google.com/docs/auth/admin/verify-id-tokens?hl=ja 8
9. 社外の開発チームとの協業 Flutterでのクライアントアプリの開発は社外の開発チームに委託 • 現場レベルでは週次でミーティングを実施 • アプリデザインから提案していただき、実装・リリース申請まで • APIスキーマを共有して、サーバー・クライアントで並行して実装 • QA期間中は毎日ミーティングを行い、不具合を都度迅速に対応 Slack上でもラフにコミュニケーションをとり密に連携をとって進めた QA直前でクリティカルな問題が発生するも、なんとか予定通りにリリース準 備が完了 9
10. 新しく採用したgem 社内での採用例やメンバーの導入経験がないgemを積極的に採用 • alba（JSONシリアライザー） ◦ ActiveModelSerializersの代替として採用 ▪ 活発にメンテナンスが行われていないため導入を躊躇したことがきっかけ ◦ 高速なシリアライゼーション性能 ◦ Kaigi on Railsのチーフオーガナイザーである大倉雅史さんが開発を行っている • rswag（OpenAPI統合） ◦ RSpecテストからOpenAPIスキーマを自動生成 ◦ レスポンスの型チェック機能付き ◦ TDD的な開発手法を実現、テスト先行で実装 10 https://github.com/okuramasafumi/alba https://github.com/rswag/rswag
11. Apple Developerアカウントの移行（想定外の対応） グループ内の組織再編に伴い、Apple Developerアカウントの移行作業が発生 → アプリを他のDeveloperアカウントに譲渡すると、証明書などを発行し直す 必要がある。 譲渡IDを生成し、既存のDeveloperアカウントでログインしているユーザーを 移行先のDeveloperアカウントに移行することで解決。 これを通常のApple Sigininではなく、Firebase Authで実装しているケースが なく、作業手順の作成に苦労。 https://developer.apple.com/jp/help/app-store-connect/transfer-an-app/overview-of-app-transfer/ 11
12. リリース後の課題 12
13. リリース後の課題 セキュリティ・パフォーマンス面での課題が顕著に • リリース直後から探索・攻撃のリクエストが頻繁に発生 ◦ DDoS攻撃のようなリクエストによって、意図しないオートスケールが起動 ◦ 不正なクエリパラメータにより、意図しない5xxエラーが発生 ◦ 海外からのアクセスが発生 • クライアントアプリのファーストビュー表示が遅い ◦ ファーストビューの表示が約3秒程度 ◦ アプリケーション内で配信している画像のサイズが最適化されていない → AWSのWAF・CloudFront・Lambda@Edgeを使うことで解決 13
14. エッジコンピューティングを用いた最適化 • WAF ◦ AWS マネージドルールを適用 • CloudFront ◦ オリジナルアセットとリサイズ済み の画像をキャッシュ • Lambda@Edge ◦ URLを検証 ◦ クエリパラメータの値に応じて、予 め定めているサイズに画像をリサイ ズしてS3に保存する。 14 詳細はグリーエックス社テックブログを参照 https://tech.gree-x.com/edge-computing-application-optimization-aws-waf-cloudfront-lambda-edge/index.html
15. WAF リリース時に適用したルール • AWSManagedRulesCommonRuleSet （コアルールセット (CRS) マネージドルールグループ） • AWSManagedRulesKnownBadInputsRuleSet （既知の不正な入力マネージドルールグループ） • AWSManagedRulesAmazonIpReputationList （Amazon IP 評価リストマネージドルールグループ） • レートベースのリクエスト制限 15
16. WAF 16
17. Lambda@Edge CloudFrontのエッジロケーションで動作するLambda関数 ユーザーからのリクエストをエッジロケーションでハンドリングできる。 • Viewer Request ◦ URLを検証 ◦ リサイズ用のクエリパラメータをチェック、適切なパラメータが付与されている時はリク エストパスを変更 • Origin Response ◦ 403/404エラー時は画像のリサイズ・S3への保存を行い、保存先にリダイレクトするよ うに301レスポンスをユーザーに返す ※ 適切なハンドリングができないとリダイレクトループが発生するため注意 17
18. 新規プロダクト開発で意識したこと 18
19. 新規プロダクト開発で意識したこと • 立ち上げ期はスピードと品質のバランス ◦ QCDの中でも「スピード」を重視した意思決定 ◦ TDDのような開発手法で、スピードを保ちながら品質も担保 • 開発パートナーとの「フラットな関係性」 ◦ フラットなコミュニケーションが、問題の早期発見・解決につながった • リリース後の継続改善でプロダクトを成長させる ◦ セキュリティやパフォーマンスの問題は使われて顕在化 ◦ 変化に備えた設計が、想定外への対応力を生む 新規開発は想定外との戦い。立ち止まらず、打ち返し続けることが重要！ 19
20. ご清聴ありがとうございました 20