DroidKaigi 2025 参加レポート

Android

はじめに

こんにちは、TVerのAndroidアプリエンジニアの根岸です。

TVerは今年、DroidKaigi 2025にゴールドスポンサーとして協賛させていただきました。今回はTVerブースでの取り組みやTVerのエンジニアが聴講し印象に残ったセッションを紹介します。

techblog.tver.co.jp

DroidKaigiについて

DroidKaigiはエンジニアが主役のAndroidカンファレンスです。Android技術情報の共有とコミュニケーションを目的に、2025年9月10日(水)〜12日(金)の3日間、ベルサール渋谷ガーデンで開催されました。

TVerブースでの取り組み

今回TVerではDroidKaigiのブース出展は初めてで、新たにテーブルクロスやロールアップバナーを用意したり、新しいノベルティを作成するなど準備を頑張りました！

ブースでは以下の取り組みを実施しました。

  • TVerアプリの展示
  • ガチャガチャコーナー
  • アンケートコーナー

Android TVやAndroid/iOSアプリを展示し、来場された方々に実際にTVerアプリを触っていただきました。

また、今回新たにTVerロゴの入ったオリジナルのタンブラーやハンディファンなど、ここでしか手に入らないアイテムが当たるガチャガチャを用意しました。実用的な景品であり、当たった方々にとても喜んでいただきました！ガチャガチャ自体も、実際に100円玉を入れて回すという体験がレトロで面白いと好評でした！

最後に、QRコードを用意してアンケートに答えていただくようにしました。任意にもかかわらずみなさんその場で回答していただき、参加者の方々の優しさを感じました！ありがとうございました！

ブースでの成果

まずアンケートの結果ですが、回答してくださった方の半数以上がAndroidエンジニアでしたが、バックエンドエンジニアやiOSエンジニアなど多種多様な職種の方が参加されていることが分かりました。

アンケート内の質問「TVerの社内に開発組織があることをご存知ですか？」に対しては半数以上の方が既に知っていただいてました。一方、「TVerのTech Blogを読んだことはありますか？ 」に対しては「読んだことがある」と回答された方は少なかったです。TVerは近年開発組織が急拡大していることもあり、サービスを内製化していることもまだ広く認知されていません。今後もTech Blogなどで積極的に情報発信し、TVerの開発組織やTech Blogの認知を広げていきたいです。

また、ブースに来ていただいた方々と、TVerのサービスや利用技術についてディスカッションすることができました。 利用しているプログラミング言語、自動テストの導入状況、Jetpackライブラリの活用状況、動画配信の仕組みに関する話題が多かったです。

印象に残ったセッション

聴講したセッションの中から、印象に残ったセッションを紹介します。

1. 基礎から学ぶ大画面対応 〜「Large screen differentiated」認定アプリの開発知見〜

2025.droidkaigi.jp

大画面対応が必要な背景から、その対応ステップを分かりやすく解説されていました。Foldable端末やXRデバイスなど多種多様なデバイスが普及してきているため、今後重要な技術だと思いました。Viewベースのアプリも考慮されたお話しで、多くのサービスで開発時に参考になる内容だと思いました。

実際にU-NEXTさんのブースにてFoldable端末でのアプリのUIの変化を拝見し、綺麗にUIが最適化されていました。TVerでもTier1を目指して積極的に取り組んでいきたいと思います。

2. Cache Me If You Can

2025.droidkaigi.jp

GradleとAGPのライフサイクルや、キャッシュ戦略を分かりやすく解説されていました。決定論的にタスクを実行させるなど、キャッシュを効かせるためのコツを詳しく紹介されていました。セッション中におすすめされていたDevelocity Pluginはさっそく使ってみようと思います。

3. EncryptedSharedPreferences が deprecated になっちゃった！どうしよう！

2025.droidkaigi.jp

EncryptedSharedPreferencesの代替方法や非推奨になった背景が具体的に解説されていて分かりやすかったです。 移行方法も参考になったのですが、特に印象的だったのは「永久に失われて困るものは保存しない」というフレーズです。スマホアプリ内部にデータを保存すると、開発のしやすさユーザーの利便性に繋がることもあります。しかし、そのデータが本当に保存する必要があるのか、意味があるのか、今後より深く考えたいと思いました。

まとめ

ブース出展とセッションを通じて、TVerサービスの現在地や今後取り組みたいことを再確認することができました。 個人的にブース出展側での参加は初めてでしたが、色んな方と会話させていただき、非常に楽しかったです。

今回得られた学びを活かし、より良いアプリ開発に取り組んでいくとともに、エンジニアコミュニティへの貢献も継続していきます。

TVerでは幅広い職種で積極採用中です！ もしご興味をお持ちいただけましたら、ぜひTVer採用サイトもご覧ください！

Choosing NLB Use Cases and Real-Life TVer

AWS NewRelic web SRE

増え続けるアクセスによる選択

TVerのSREチームでインフラ周りを担当しています西尾です。 前回は現状のTVerサービスの提供環境に関して取り上げましたが、今回は直近にありましたインフラ構成変更について書いていきたいと思います。 TVerの動画配信に関しましてはありがたいことに着実にユーザー数が増えて、皆様に身近なサービスとして認知がされていってるのではないかと思っております。 その上でサービスに関するトラフィックも増え続けることにより、この増加に起因する問題に対して改めて取り組む必要が出てきました。

現在の構成

現在のサービス構成に関しましては、AWS上で動いていましてそのリクエストを捌くためにAPIの手前には一般的な構成としてALBが置かれています。

User-ALB-API

Prewarmingをめぐる課題

TVerのサービスに関しましては負荷状況によってリソースは自動的に調整されるようにはなっていますが、多数の視聴が予測されるコンテンツに関しましてはサービスの安定配信の観点からAWSリソースのスケールを配信前に事前に行っています。 作業対象はAPIサービスのスケールアウト(コンテナの増加)、DBについてのスケールアウト(RDSレプリカの追加)などがあります。 その中に今回取り上げますApplication Load Balancer(以下ALB)のPrewarmingがあります。 ALBのPrewarmingとはLCUを予約する事であり、この作業も他のスケールアウトと同じタイミングで実施していました。 このPrewarming機能に関しましては昨年末からALBのコンソール画面やAPIを通して操作できるようになりましたが、それに伴いPrewarmingによる費用に関しても正式にAWS費用として請求されるようになりました。

＊実際利用した分のLCUのキャパシティーユニットに対するコストに関しては以前から発生していました。

ALB-Cost

上記から分かるように今まで意識してこなかったPrewarmingコストに対して面と向かって取り組む必要がコスト面の課題として出てきまして、それに合わせてALBと付随するAPI周りの構成変更をこのタイミングで行う事にしました。

＊Prewarmingのコストに関してはAWS側に今まで負担してもらってたので、個人的にはあくまで来る時がきたという感覚なので仕方ない事かと思っています。

NLBへの道

コスト増に対しては毎回コンテンツの視聴者数などを元に適切なLCUを算出設定し、必要なコストとして計上するのが通常かと思います。 ただしコンテンツによってはどれくらい視聴されるか予測が難しいものもあり、現状ではある程度余裕を見てバッファを含めてLCUを設定しています。 そのため安心料としてコストを多めに支払っている感があるのは否めなく、この点を含めて併せて課題を解決することはできないかとなりNetwork Load Balancer(以下NLB)を検討するに至りました。 ALBとNLBに関しては違いが幾つかありますが、ここではスケールの違いにフォーカスして簡単に説明します。

ALBスケーリング -　5分以内にワークロードを2倍にサポートするようにスケールアップされる。例えば、1 Gbps のトラフィックを処理している ALB は、5分以内に2 Gbps まで増加し、次の5分で4 Gbps まで増加することが期待される。

NLBスケーリング - 帯域幅のあらゆる側面に基づいてスケーリングを行い、ワークロードに必要な容量を正確にプロビジョニングを行う。NLB は3 Gbpsの帯域で起動し、1分あたり3Gbps のペースで容量を増加する。

ポイントになるのはこのスケール時間と処理できる帯域幅で、TVerのサービス性質で枠切れ(地上波からTVerへの流入)というイベントがあります。 これは地上波の配信終了前後からTVerへ視聴者が移ってくることを指していまして、これにより数分以内にそれまでTVerで視聴していたユーザー数が一気に2-10倍ぐらいになることがあります。 そのため、1分以内にどれだけLBがスケール出来るかは重要な点で、ここ最近の枠切れイベントのユーザー数とトラフィック量の確認を行うことでNLBのスケーリングで対応出来るという判断になりました。 このスケールの速度やAWS側から保証されている処理帯域により、今後はNLBへの切り替えによってPrewarming作業が不要な場面が多くなると想定しています。 これにより本当に必要になる帯域に合わせられたスケールが行われ、実際の利用に則したコストを支払うだけでPrewarmingによって発生していた膨れ上がったコストを削減できると期待しています。

＊Prewarming作業を行うケースは主に２パターンあり、一つは明らかに多くの視聴者数が想定されるコンテンツに対応する場合と、もう一つは地上波からの流入で一気に視聴者数が増えるケースに対応する場合があります。 明らかに多くの視聴者数が見込まれるコンテンツに関しては今まで通りPrewarming作業を実施するのでサービスの安定は保ちますが、後者の枠切れに対してはNLBへの置き換えでその作業がなくなることを期待しています。

コストとしてはALBからNLBに置き換えることで、この後紹介するNginxなどのルーティング用のコンテナ費用を含めましても現在のコストの6−７割ぐらいになるのではないかと試算しています。

＊この費用の割合については継続的に追跡して今後どこかのタイミングで紹介できればと思っています。

Fast Fargate

NLBの切り替えによって、L7機能などを別の場所で対応する必要がでてきます。 元々APIではGoのAPIコンテナとNginxのコンテナを一つのECSサービスとして動かしていました。そのためNLBの後ろにNginxを置きルーティングを集約する構成にするとNginxが多段になるためAPI側のNginxを引き剥がしてそこでパスによるルーティングやCORS対応のヘッダー付与するようにしました。

User-NLB-Router-API

その他NLB移行での考慮点

  • ALB Log 利用した集計や監視を、Nginxのログを利用した方法に変更
  • ALBのウェイト機能を利用したカナリアリリースを、Nginx側に移行
  • Nginx、API側のスケーリング

カナリアリリースに関しましては、Nginx側でウェイトを設定して、それを環境変数でパーセンテージを調整できるようにしています。 これは割合の変更に対してECS Taskの再起動を必要としていますのでそれほど使い勝手がいいとは言えないものになっています。 ただし後述しますが、この構成は一時的なものになりますので今回はこの設定でカナリアリリースを実現しています。

NLBへの移行に伴ってNginxとAPIコンテナが分離したことによってその間の接続を考える必要がでてきました、いくつかコンテナ間のルーティングを実現する方法はありますが今回はECS Service Connectを利用することにしました。 これはECS Service間だけで利用できるName Spaceを利用してコンテナ間の接続をクライアントとサーバーの役割に分けてアクセス出来るようにしています。今回の構成ではNginxがクライアントで、APIがサーバーの扱いになります。 まずNginx側にサイドカーとしてproxy(コンテナ名:ecs-service-connect-xxxx)が埋め込まれ、クライアントの/etc/hostsファイルにはNameSpaceのドメインが書き込まれproxy経由で実体のサーバーにアクセスする流れになります。

127.0.0.1 localhost
127.255.0.1 canary-api.dev2a
2600:f0f0:0:0:0:0:0:1 canary-api.dev2a

NLBへの置き換えでLB自身のスケーリングスピードは上げることは出来ましたが、その後ろにあるコンテナ群(Nginx/API)が付いてこれないとどの道バックエンド503でアクセスを捌けなくなります。 もちろん既存のリソースベースのコンテナスケーリングを設定することで直ぐに対応出来なくても数分後にはスケールアウトしたコンテナ群でアクセスに対応することは出来ます。 ただしこれでは、先ほど紹介した枠切れ対応（数分以内のアクセス急増）に対して直ぐに対応出来ないことになります。

コンテナが外からリクエストを受けるまでには以下のような時間がかかります。

  1. メトリクスベースで検知する時間　1-5分
  2. fargateがrunning状態になるまでの時間 おおよそ60秒 image pullから起動まで
  3. コンテナ内のアプリケーションが起動してリッスンになるまでの時間 5-10秒(アプリケーションによるがTVer APIに関しは10秒以内)
  4. LB側のヘルスチェックがOKになるまでの時間 設定による

本来は時間がかかる２に関して手を入れたかったのですが、現在の構成を抜本的に変える必要がありこれに関しては別のアプローチで対応することにしましたので、本記事では割愛します。 今回は1に関して如何にスケールのスタートを速くするかを取り組むことにしました。

*3に関しては既にそれなりに速く、コンテナイメージもGoのアプリケーションなのでそれほど大きなサイズではないので特に今回は対応していません。4に関しましては微調整は行いました。

このスケールスタートを速くするために最初はメトリクスに頼らないaws-fargate-fast-autoscalerを検討しました。 ただこれに関しましてはもうメンテナンスも行われていなく、フォークして環境を上げようかと思いましたがそれであれば一からGoで作ったアプリケーションでECS Serviceとして作ろうということになりました。 基本的にこのアプリケーションはfargate-fast-autoscalerでやっている動作を機能として実装していまして、Nginx側のコネクションなどを数秒毎に確認して、急なアクセスがあった場合Nginx+APIのサービスを一気に立ち上げる動きをします。 無論スケールアウトだけでなく、スケールインにも対応していまして、アクセスが落ち着いたタイミングで行うようになっています。

fargate-fast-autoscaler

＊肝心のスケールの閾値・設定値は運用の中で蓄積されたデータで算出して設定する必要がありますが、現在は情報が少ないので決め打ちで多めに立ち上がるようにしています。

このサービスによりメトリクスベースのスケールアウトよりはスケール時間が短縮されているので、バックエンドで詰まる機会は減らすことは出来るのではないかと期待しています。

Monitoring

NLBへの移行により、NLB自体のメトリクスやECS Service Connectのメトリクス(後ろにあるNginx-API間の接続状況)をモニタリングする必要がありますが、まだこの構成で実際サービスを運用したことがなかったのでまずは負荷試験を実施し、エラーの発生状況とメトリクスの相関関係を探ることから始めました。

ECS Service Connect

基本的にエラー率が上がるタイミングで、バックエンドの5XXエラー(ECS Target 5xx Error Count)が出ます。その時の他のService Connectのメトリクスも跳ね上がるので基本はこのバックエンドエラーに対してアラートなどを設定すれば通信状況の把握はカバー出来そうなのがわかりました。

＊運用によってモニタリング対象は日々変わっていくので、これで固定されるものではありません。

Beyond NLB/ECS

今回紹介しましたNLB構成に関してはまだALBと並行運用中で完全には切り替わっていません。 また実はこの紹介しましたNLB構成はTVerのインフラでは一時的なものになります。抜本的なリアーキを併せて進行中で、そのリアーキでは主にスケールスピードにフォーカスした構成をEKS上で構築しています。 それによりNLB+Nginxの構成もingressコントローラーを利用することで見通しが良いものになっています。 これに関しましては絶賛検証中なので早く日の目を見せれるようにスピードを上げていきたいと思っています。

TVerはiOSDC Japan 2025にゴールドスポンサーとして協賛します！

スポンサー iOS

こんにちは、TVerでiOS/Android領域のエンジニアリングマネージャーをしている黒田です。 TVerは今年、iOSDC Japan 2025にゴールドスポンサーとして協賛させていただくことになりました！

iOSDC Japanとは

iOSDC Japan 2025はiOS関連技術をコアのテーマとした、ソフトウェア技術者のためのカンファレンスです。2025年は9月19日(金)〜21日(日)の3日間、有明セントラルタワーホール＆カンファレンスで開催されます。

国内外のiOSエンジニアが集まり、最新の技術トレンドや開発ノウハウ、実践的な知見を共有する場として、毎年多くの参加者で賑わっています。SwiftUI、各種デバイス対応、パフォーマンス最適化、アーキテクチャ設計など、iOS開発に関する幅広いトピックのセッションが行われ、エンジニア同士の交流も活発に行われます。

https://iosdc.jp/2025/

TVerのiOSエンジニア

TVerは民放公式のテレビポータルサービスとして、累計8,500万ダウンロードを超える大規模なアプリケーションを運営しています。iOSチームではモダンな技術スタックを活用し、より良いユーザー体験を提供するための開発に日々取り組んでいます。

現在、月間約5億回再生という多くのユーザーにご利用いただいているサービスとして、安定性とパフォーマンスを重視しながら、継続的な改善と新機能の開発を進めています。

現在のTVer iOSアプリにおける主な取り組み

TVerのiOSアプリでは、現在以下のような技術的な取り組みを進めています：

1. アーキテクチャの継続的改善

  • TCA (The Composable Architecture) を活用した大規模リアーキテクチャによる状態管理の統一化と保守性向上
  • SwiftUIとUIKitのハイブリッド実装により、iOS 15サポートを維持しながら段階的なモダナイゼーションを推進
  • デザインシステムを導入した開発効率化

2. 開発者体験の向上とプロセスの整備

  • Claude CodeやGemini Code Assistなど生成AIの活用により、開発速度や品質の向上
  • RemoteConfigを活用した段階的な機能リリース戦略
  • 複数のチームが平行して開発するためのリリースプロセスの整備と、リリース後のモニタリングを整備

3. ユーザー体験の最適化

  • 動画再生体験の改善と安定性向上
  • UI/UXの継続的な改善

iOSDC Japan 2025での取り組み

iOSDC Japan 2025では、TVerブースを出展予定です。実際の開発現場で培ったノウハウや技術的な取り組みについて、エンジニアと直接お話しいただける機会を設けています。

また、弊社からは2つのセッションで登壇します！

「あなたの知らない「動画広告」の世界 〜実装して理解する動画広告のしくみ」

  • 日時：9月20日(土) 10:50〜11:10
  • Track：Track B
  • レギュラートーク（20分）
  • 発表者：@ukitaka

動画広告の実装について深く掘り下げた内容となっていますので、ぜひお聞きください！

「4100万ユーザーを支えるTVer iOSアプリ開発 〜0人から始まったチームのAI活用による挑戦〜」

  • 日時：9月21日(日) 11:25〜11:45
  • Track：Track A
  • スポンサーセッション（20分）
  • 発表者：@mantaroufire

2023年に0人から始まったiOSチームが、2025年には3人体制となり、AI活用により開発効率を向上させてきた実例をご紹介します。実装やコードレビューだけでなく、プロジェクト管理や仕様策定プロセスでのAI活用についてもお話しします。

TVerは「テレビを開放して、もっとワクワクする未来を」というミッションのもと、テレビコンテンツの新しい楽しみ方を提供し続けています。 大規模動画配信サービスならではの技術的な課題や、それらをどのように解決してきたかについても共有させていただく予定です。iOS開発に関する技術的な相談や、TVerでの働き方についてもお気軽にご質問ください！

ブースに立ち寄っていただいた方にむけて、豪華ノベルティも用意させていただきました！

一緒に働く仲間を募集しています

TVerでは現在、iOSエンジニアを積極採用中です！大規模動画配信サービスの開発に携わりながら、最新技術に挑戦できる環境で一緒に働きませんか？

興味をお持ちいただいた方は、ぜひ採用サイトをご覧ください。カジュアル面談も随時実施しておりますので、お気軽にお問い合わせください。

https://recruit.tver.co.jp/

iOSDC Japan 2025でお会いできることを楽しみにしています！

#tver_iosdc2025

TVerはDroidKaigi 2025にゴールドスポンサーとして協賛します！

スポンサー Android

こんにちは、TVerでiOS/Android領域のエンジニアリングマネージャーをしている黒田です。 TVerは今年、DroidKaigi 2025にゴールドスポンサーとして協賛させていただくことになりました！

DroidKaigiとは

DroidKaigiはエンジニアが主役のAndroidカンファレンスです。Android技術情報の共有とコミュニケーションを目的に2025年9月10日(水)〜12日(金)の3日間、ベルサール渋谷ガーデンで開催されます。

国内外のAndroidエンジニアが集まり、最新の技術トレンドや開発ノウハウ、実践的な知見を共有する場として、毎年多くの参加者で賑わっています。Jetpack ComposeやKotlin Multiplatform、パフォーマンス最適化、アーキテクチャ設計など、Android開発に関する幅広いトピックのセッションが行われ、エンジニア同士の交流も活発に行われます。

https://2025.droidkaigi.jp/

TVerのAndroidエンジニア

TVerは民放公式のテレビポータルサービスとして、累計8,500万ダウンロードを超える大規模なアプリケーションを運営しています。Androidチームではモダンな技術スタックを活用し、より良いユーザー体験を提供するための開発に日々取り組んでいます。

現在、月間約5億回再生という多くのユーザーにご利用いただいているサービスとして、安定性とパフォーマンスを重視しながら、継続的な改善と新機能の開発を進めています。

現在のTVer Androidアプリにおける主な取り組み

TVerのAndroidアプリでは、現在以下のような技術的な取り組みを進めています：

1. アーキテクチャの継続的改善

2. 開発者体験の向上とプロセスの整備

  • Claude CodeやGemini Code Assistなど生成AIの活用により、開発速度や品質の向上
  • RemoteConfigを活用した段階的な機能リリース戦略
  • 複数のチームが平行して開発するためのリリースプロセスの整備と、リリース後のモニタリングを整備

3. ユーザー体験の最適化

  • 動画再生体験の改善と安定性向上
  • UI/UXの継続的な改善

DroidKaigi 2025での取り組み

DroidKaigi 2025では、TVerブースを出展予定です。実際の開発現場で培ったノウハウや技術的な取り組みについて、エンジニアと直接お話しいただける機会を設けています。

TVerは「テレビを開放して、もっとワクワクする未来を」というミッションのもと、テレビコンテンツの新しい楽しみ方を提供し続けています。 大規模動画配信サービスならではの技術的な課題や、それらをどのように解決してきたかについても共有させていただく予定です。Android開発に関する技術的な相談や、TVerでの働き方についてもお気軽にご質問ください！

ブースに立ち寄っていただいた方にむけて、豪華ノベルティも用意させていただきました！

DroidKaigi 2025でお会いできることを楽しみにしています！

OpenAPIを使ったTVer APIのスキーマ駆動開発

Go

こんにちは。 id:takanamito です。
以前書いた記事「TVerバックエンドAPIのリアーキテクチャ」では、TVerのAPIアーキテクチャを移行した背景と全体設計について紹介しました。
本記事では、アーキテクチャから1段ブレークダウンして、OpenAPIによるスキーマ駆動開発の実践について現場レベルの具体的な運用の話を書きます。

TVerにはcontents-api, user-api, manager-apiという3種のAPIが存在します。それぞれの詳細は前回の記事でご確認ください。
この記事ではcontents-apiを例に紹介を進めます。

  • OpenAPIを使った開発フロー
  • なぜOpenAPIなのか
  • OpenAPIスキーマ定義
    • ディレクトリ構造とスキーマファイル分割戦略
    • 細かいスキーマ設計のローカルルール
      • HTTPレスポンスのrootには必ずキーを持たせる
      • oneOf, anyOfを使わない
  • OpenAPIからのコード生成手法
    • redoclyを使ってymlファイル結合
    • Spectralを使ったLint
    • oapi-codegenを使ったGoのコード生成
    • 生成フローの自動化
  • モックサーバーの活用
  • 出てきた課題
    • モックサーバーのレスポンスの表現力不足
  • まとめと今後の展望
続きを読む

Google Cloud Next Tokyo '25 に登壇しました

はじめに

TVer 広告プロダクト本部の髙品です。8月5日と6日に東京ビッグサイト南展示場で開催された Google Cloud Next Tokyo '25 に登壇させていただきました。セッションタイトルは『月間動画再生数約 5 億回を誇る TVer の、広告配信基盤における Memorystore & Bigtable 併用戦略と実践的チューニング』です。

Google Cloud Next Tokyo '25 イベントウェブサイトに掲載されたセッション概要

この記事では、登壇の振り返りと、セッション内容の簡単な紹介を書こうと思います。後日、セッションのアーカイブと資料が Google Cloud Next Tokyo のイベントウェブサイト にて公開される予定なので、この記事をきっかけに、より多くの方にセッションのアーカイブと資料をご覧いただき、TVer の広告プロダクトにご興味を持っていただけたら幸いです。

追記 (2025年8月21日)

Google Cloud Next Tokyo のイベントウェブサイトにて、セッションのアーカイブと資料が公開されました。ご覧いただくには、イベント参加登録が必要です。

セッションアーカイブと資料

イベント参加登録しても上記の URL からご覧いただけない場合は、Google Cloud Next Tokyo のイベントウェブサイトのホームから、[セッション一覧]→[ソリューション]→[データベース] と進んで、セッションタイトルでお探しください。

登壇の振り返り

私には、Google Cloud Next Tokyo '25 のブレイクアウトセッションに登壇する目的が2つありました。

  1. TVer 広告というプロダクトの技術的なアピール、すなわち月間数十億にもなる大量の広告リクエストを低レイテンシで処理する大規模システムを開発・運用していて、広告配信というビジネスクリティカルなシステムを Google Cloud 上に構築したこと
  2. 広告配信基盤のように高いパフォーマンスを要求されるシステムのアーキテクト・開発者に向けて、(1) Key-Value 型にカテゴライズされる Google Cloud の NoSQL データベースである Memorystore for Redis Cluster (MRC) と Bigtable の併用戦略、(2) Bigtable の性能を十分に引き出す方法、の2つをお伝えすること。

結果としては、目的は2つとも達成できたと感じています。

1つ目の目的は、250 名を収容可能なセッションルームが満席になったことで達成されたと感じています。いままで TVer の広告プロダクトを支えている技術について、Google Cloud Next Tokyo のような大きなテックイベントで発表したことはありませんでしたが、今回は多くの方に TVer 広告の技術的な側面を知っていただくことができました。

250 名を収容可能な Room 6 が満席の様子

2つ目の目的も、個人的には達成されたと感じています。というのも、スピーカーはセッション終了後に Ask the Speaker ブースにて、セッション参加者のご質問に回答させていただくのですが、そのブースにて他の配信事業者や、数千万の登録者を抱える大規模なWebサービス事業者に所属されている開発者の方々から、お褒めの言葉やたくさんのご質問をいただけたからです。情報を発信した直後に、私と属性の近い開発者の方々から face to face でリアクションをいただけたのは非常に嬉しくて、登壇してよかったと感じられた出来事でした。

セッション内容

セッションの内容も簡単に紹介しておきましょう。私のセッションは、4 つのセクションで構成されていました。

  1. TVer と TVer 広告
  2. 広告配信と NoSQL DB
  3. MRC & Bigtable 併用戦略
  4. Bigtable 実践的チューニング

1 と 2 は導入部です。to C のプロダクトである TVer サービスに対して、TVer 広告は広告代理店様・広告主様のためのプロダクトなので認知度は高くないと考え、1 つ目のセクションでは TVer 広告の紹介をさせていただきました。2 つ目のセクションでは、TVer の広告配信基盤において、リレーショナルデータベースではなく、Key-Value 型にカテゴライズされる NoSQL データベースを採用した理由を取り上げました。弊社の広告配信基盤は、膨大な広告リクエストを低レイテンシで処理する必要があり、また、事業成長と共に合理的なコストでスケールできなければならないため、パフォーマンスと拡張性に優れた分散型の Key-Value データベース が最適な選択であった、とお話しました。

3 と 4 が本題です。3 つ目のセクションでは、弊社の広告配信基盤における MRC と Bigtable の併用戦略をお話しました。このセクションでは、広告配信・計測に必要なデータと Key-Value データベースの特徴を分析してデータストアを選ぶプロセスを紹介した後、性能試験で発生した課題をどのように解決したかをお伝えすることを通して、弊社における MRC と Bigtable の併用戦略を説明しました。弊社ではデータの一貫性、ストレージの上限、データベースの可用性のバランスを考慮して、MRC と Bigtable の強みを活かせるようにプロダクトを使い分けています。4 つ目のセクションでは、Bigtable の性能を十分に引き出すための実践的チューニング手法をお話しました。このセクションでは、アプリケーションから Bigtable にアクセスさせる負荷試験を実施した際に学んだ、Bigtable におけるデータ最適化の仕組みと、クライアント側のコネクションプールサイズと読み取りレイテンシの関係性の解説を通して、Bigtable に大量の読み取りをミリ秒で処理させるチューニング方法を説明しました。

以上がセッション内容の簡単な紹介です。気になった方はぜひセッションのアーカイブをご覧いただけると幸いです。

おわりに

Google Cloud Next Tokyo '25 では、広告配信基盤の設計〜開発のフェーズで学んだ（苦労した）出来事・経験から、MRC と Bigtable にスポットを当て、汎用的な知見を抽出してお話させていただきました。私のセッションが Google Cloud で大規模システムを設計・開発するアーキテクト・開発者の方のお役に立てば嬉しいです。

今後も TVer 広告の配信を支える技術について、テックブログや Google Cloud のイベントで発信したいと思っておりますので、ご注目いただけると嬉しいです。今回のセッションで話すことができたのは、TVer 広告を支える技術の一部です。Bigtable について様々な視点から話したように見えますが、実際は広告配信サーバーからの読み取りを高速化する手法について deep dive するセッションになっていたかなと思います。Bigtable だけ取り上げても、Bigtable に大量のデータをロードするアーキテクチャ、Bigtable のデータ集計手法、データ量の最適化など、別の角度から話したいことがありますし、GKE やログ収集/集計基盤など、データベース以外についても機会があれば発信したいと思っています。発信をきっかけに、また Google Cloud を大規模に利用しているユーザー同士で交流できたら良いなと思っています。

最後に、登壇準備に協力してくれた弊社の広報チーム、一緒に広告配信基盤を開発したチームメンバー、そして Google Cloud のご関係者の皆様に感謝を伝えて締めくくりたいと思います。Google Cloud Next Tokyo '25 のような晴れの舞台で素晴らしい発表ができたのは、皆様のおかげです。本当にありがとうございました。

PR単位の開発環境構築自動化によるWEBフロントエンド開発の生産性向上

みなさん、こんにちは！TVer SREチーム DevOps Unitの鈴木です！

TVerでは採用に非常に力を入れており、おかげさまで社員数が右肩上がりに増え続けています。 note.com

TVerでは、WEB、iOS/Androidアプリ、Fire TV Stickなどといった多様な端末でサービスを提供しており、それぞれに専門の開発チームが存在しています。 組織拡大に伴い、それぞれのチームで複数の新規機能開発や改善プロジェクトが同時に推進されるようになりました。

しかしながら、この急速な組織拡大に伴い開発環境の不足がボトルネックとなり、開発生産性向上を阻むという課題が浮き彫りになりました。

開発組織全体の生産性向上は、私たちSREチームの重要なミッションの一つです。

本記事では、この多岐にわたる開発チームの中でも、WEBフロントエンドチームが抱えていた「開発環境の課題」に焦点を当て、PR単位での自動開発環境構築というアプローチが、どのような効果をもたらしたのか紹介します。

なお、本記事は以下の記事から着想を得たものであり、@dtaniwaki さんにこの場を借りてお礼申し上げます。

techblog.jmdc.co.jp

1. 開発環境の課題

WEBフロントエンドチームでは、組織の拡大と並行して進むプロジェクトの増加に伴い、いくつかのボトルネックが顕在化していました。

開発環境利用における待機時間の発生

これまで、利用できる開発環境の数が限られていたため、複数の開発メンバー間で開発環境の利用が集中し、使いたい時に使えないという状況が常態化していました。これにより、自身のコードのテストや機能の確認を行う際に、不要な待機時間が生じていました。

レビュープロセスの遅延

PRのレビューにおいては、実際に動く開発環境での確認が必須です。 しかし、開発者だけでなくPdM（プロダクトマネージャー）やQAチームのメンバーも動作確認を行うため、開発環境を占有する時間が長くなりがちでした。 結果として、開発環境の待機時間が発生し、レビュープロセス全体が滞る主要な原因となっていました。

構築・運用コストの高さ

従来の開発環境はバックエンドアプリケーション、データベース、外部サービスなど全ての機能を含むフルパッケージ構成でした。 この構成では構築・維持にコストがかかるため、需要に応じて柔軟に開発環境を増やすことができませんでした。

データの不整合

フルパッケージ構成の開発環境はそれぞれの開発環境でデータベースが独立しているため、参照できるデータが開発環境ごとに異なるという課題がありました。 これにより、フロントエンド開発者が特定のUI/UXやユースケースを検証したい際に、必要なテストデータが存在しないケースが頻発し、検証作業に支障をきたしていました。

2. 課題解決のためのアーキテクチャ

前述の課題解消にあたり、PR単位でWEBフロントエンド開発環境を自動で構築できる仕組みを用意しました。 アーキテクチャとしてはCloudFrontとS3を利用した非常にシンプルな構成になっております。

今回のアーキテクチャの特徴は以下になります。

  • CloudFront FunctionにてサブドメインのPR番号を取得し、PR番号に応じたパスに書き換える
  • ワイルドカードドメインで任意のPR番号で対象PRの画面を確認できるように
  • PRにdeploy-prラベルの付与をトリガーにS3のPR番号フォルダ配下に自動デプロイ
  • バックエンドはテストデータが充実した既存の開発環境を参照

新しく上記リソースをCDKで用意するだけだったため、少ない工数ですぐに構築することができました。

3. PR単位の開発環境構築がもたらした効果

今回の対応で以下の効果をもたらしました。

課題の解消

開発環境利用における待機時間の解消

新しい仕組みでは、PRに特定のラベルを付与するたびに、専用の開発環境がゼロから自動で構築されます。 これにより、誰もが「確認したい」と思ったその瞬間に、自身の変更が反映された独立した開発環境を利用できるようになりました。

レビュープロセスの効率化

PR単位でユニークなURLが発行されるため、開発者、PdM、QAメンバーは、確認したい時に、確認したいPRの開発環境へ直接アクセスし、独立して動作確認を行えるようになりました。 GitHub Actionsによる開発環境の自動作成は、構築時間を大幅に短縮し、すぐに検証を開始できるため、レビュープロセス全体が飛躍的に効率化されました。

構築・運用コストの最適化

従来のフルパッケージ構成の開発環境ではなく、WEBフロントエンド用開発環境のみを必要な時に即時かつ自動で構築できるようになったため、インフラの構築・維持にかかるコストを大幅に削減できました。

テストデータ不整合の解消

PR単位の開発環境はテストデータが充実しているバックエンド開発環境に接続するようにしました。 これにより、実施したいテストを確実に行えるようになり、検証の品質が向上しました。

データで見る開発生産性の向上

今回、PR単位の開発環境構築を自動化したことで、WEBフロントエンドチームの開発生産性がどのように向上したのかを、開発組織の生産性分析ツールであるFindy Team+のデータで見てみましょう。 この仕組みを本格的に導入した2025/06以降、PR作成数や開発者数に変化がない中で、開発フローにおける複数の重要な指標で顕著な改善が見られました。

変更のリードタイム

変更のリードタイムは約80%(前月比)ほど減少しました。 これは、コードの変更（コミット）してからmainブランチにマージされるまでの、開発サイクル全体のスピードが大幅に向上したと読み取れます。

PRオープンからレビューまでの平均時間

PRオープンからレビューまでの時間は約40%(前月比)ほど減少しました。 PRが作成されてから、レビュアー（開発者、PdM、QA）がレビューを開始するまでの時間が短縮され、開発環境の待機時間が解消されレビューに着手しやすくなったことを表しています。

もちろん、これらの数値改善は「PR単位の開発環境構築自動化」のみが要因ではありません。 開発チーム全体の継続的な努力や改善活動も大きく寄与していることを認識しております。

しかし、WEBフロントエンドチームから「従来の開発フローにはもう戻れない」という嬉しい声をいただいており、今回の対応が開発生産性向上に貢献できたと思っております。

4. まとめ

今回はWEBフロントエンド環境構築の自動化によってWEBフロントエンドチームの開発生産性が向上した話を紹介させていただきました。

SREチームでは組織全体の開発生産性向上をするためにまだまだたくさん解消しなくてはいけない課題が存在するため、興味がある方は以下からのご応募お待ちしております。

herp.careers