Androidエンジニアとして入社した最初の数ヶ月

こんにちは。TVerでAndroidエンジニアをしている西田です。2025年1月に入社し、早くも数ヶ月が経ちました。 今回は、入社後のオンボーディングを通して感じたことや取り組んだことについて紹介したいと思います。

バックエンド側のオンボーディングの取り組みについての記事もあるのでそちらもぜひ合わせて御覧下さい。

techblog.tver.co.jp

オンボーディング中

入社初日は、まずTVer社内全体でのオンボーディングがありました。そちらは入社時期が一緒のメンバーとオフィスの会議室に集まって、社用携帯とPCのセットアップ、セキュリティ講座や、TVerの社内制度や事業について説明を受けました。

このオンボーディング中に、開発に使う検証端末として、Androidスマホ1台、Androidタブレット1台、Chromecast1台、iPhone1台の計4台を貸与していただきました。これだけ多くの端末を貸与していただき、開発体制の充実ぶりに感動しました。

AndroidチームのオンボーディングではSmartHR上に3ヶ月後の目標や、所属チームの説明、あなたに期待することなどをまとめた資料がありそちらに沿って進めました。

次にオンボーディング中、特に印象に残っているものについて詳しく説明します。

バディ制度

TVerにはバディ制度という、新しく入社された社員に対して先輩社員がメンターになる制度があります。この制度のおかげで誰に質問をすればいいか明確でとても安心感がありました。

他にも、メンターの方が定期的に1on1の時間を設けてくださり、業務の進め方や技術的な疑問点の相談以外にも雑談などができたのがとても嬉しかったです。私が初めての転職かつ、入社直後で分からないことも多く不安もありましたが、メンターの方が親身になってサポートしてくださったおかげで、安心して業務に取り組むことができました。

1on1

バディとの1on1以外にも業務で関わりのありそうなメンバーや上長と1on1をしていただきました。こちらの1on1のメンバーもオンボーディング資料でピックアップされており、そちらに沿って進めました。

1on1はAndroidチームに限らず、ディレクターやQA、iOS、Web、コネクテッドTV、マネージャーなど様々な方としていただきました。皆さん、多種多様なバックグラウンドを持っている方がいらっしゃって非常に楽しかったです。

この1on1を通してTVerの歴史や、各プラットフォーム毎にどのような施策に取り組んでいるかなど幅広く知ることができました。 例えば、QAチームの方との1on1では画面仕様書やQAレビューの資料を教えいただき、以降の業務でも非常に役に立ちました。QAレビューの資料ではかなり細かく記述されており、QAチームの方はこのような観点でレビューしていただいているんだなと非常に勉強になりました。

広告説明会

TVerの広告がどのような仕組みで流れているか説明会を開いていただきました。この説明会では、動画広告の規格としてVAST（Video Ad Serving Template）があることや、広告を表示する位置としてVMAP（Video Multiple Ad Playlist）があることなどを知りました。

広告は非常に複雑で完全に理解したとは言えませんが、説明会に参加したことで後続のタスクで広告関連のコードに触れる際に、それが広告のどの部分に関わっているのかを理解する時に、スムーズに把握できました。

開発周り

開発環境のセットアップに加えて、Figmaを使った開発に関する説明動画も用意されておりそちらの視聴もしました。この動画を見て初めてFigmaのDev Modeの有用性を知ることができました。

開発環境の準備が整った後、最初の開発案件として5つほど小さなIssueをピックアップしていただきました。これらのタスクは、ライブ画面やVOD画面など、TVerの主要な機能に関わるもので、難易度も無理なく取り組めるレベルでした。おかげで、各機能の概要を把握しながら、スムーズに開発を進めることができました。

バディ以外にも、開発中、技術的に分からないことがあったらAndroidチームのメンバーに、仕様周りでわからないことがあったらディレクターに質問をしながら業務を進めました。 Slackでの質問はもちろん、より込み入った内容や、文章だけでは伝えにくいニュアンスがある場合は、Google Meetを使って直接質問をしました。ちょっとした疑問でもすぐに質問できる雰囲気がありとても良かったです。

オンボーディング後

オンボーディングでの業務や、1on1でメンバーと話した中で見えてきた課題もあったので以下のような取り組みをオンボーディング後に行いました。

ドキュメントを書く

分からないことや、社内にドキュメントが見当たらない場合はできるだけドキュメントを書くようにしました。 1on1の際に、ドキュメントが不足しているために理解が難しい点があるという話を聞いたことも、ドキュメント作成を意識するようになったきっかけの一つです。そのため、些細なことでもドキュメントにまとめるようにしました。

このドキュメントをまとめたおかげでタスクの引き継ぎ時や、詰まってそうな時にドキュメントを見合わせながら説明をできたりと非常に役立ったので、今後も継続していきたいと思いました。

手を上げればチャレンジできる

チームで取り組んでいるタスク以外にも他に課題があれば自分から手を上げて取り組むことができました。 私はテストカバレッジの可視化に取り組んでみました。

TVerのAndroidアプリではあまりテストコードが多くない状態でした。そこでまずは現状のカバレッジがどの程度か把握しやすくするためPull Requestにカバレッジレポートをコメントする仕組みを提案し、導入しました。

具体的には、GitHub Actions上でKoverを使ってカバレッジレポートを生成し、octocovで生成したカバレッジレポートを解析後Pull Requestにコメントをするようにしました。

octocovがカバレッジレポートをコメントしているスクリーンショット

最後に

この記事では、私が入社してからのオンボーディングや、その後取り組んできたことについて紹介しました。 入社当初は初めての転職で不安な点もあったのですが、皆さんの手厚いサポートのおかげでスムーズに業務に取り組むことが出来ました。

今後はこの経験を元に、ユーザへ品質の高いサービスをスピード感を持って提供できるように取り組んでいきたいと思います！

TVerでは積極採用中です！ この記事を読んでTVerに少しでも興味を持っていただけたなら、ぜひお話しましょう！

herp.careers

NAB Show 2025 参加レポート

参加レポート カンファレンス 広告

はじめに

こんにちは。広告プロダクト担当の 大野です。 2025年4月6日から9日にかけて、米国ラスベガスで開催されたNAB Show 2025に、TVerからは今回3名で参加しました。

NAB Showは、毎年ラスベガスで開催される世界最大級の放送・映像・メディア業界向け展示会・カンファレンスです。世界中の企業が最新技術や製品を発表し、業界の最新トレンドや未来像を学ぶことができる場として、日本からも多くの放送関連企業が出展・参加しています。

このブログ記事では、NAB Show 2025での私の参加内容についてご紹介します。

今回NAB Showに参加した経緯

日本では、AVOD（広告付きビデオオンデマンド）サービスの数が、米国や欧州と比較してまだ少ない状況にあり、技術的な最新情報の収集も主に英語圏からの情報に頼らざるを得ない側面があります。そのため、最新トレンド、特に広告関連やVOD配信に関する技術動向を直接把握することを目的として、今回NAB Showに参加しました。

NAB Showでは、多くの企業がブースを出展しており、最新の製品や技術トレンドを直接確認できますが、私は展示ブースの見学は最小限とし、同時開催されているカンファレンスへの参加を中心に行動しました。カンファレンスでは、グローバルな放送業界の動向や、それに関連する広告技術に関する貴重な情報を得ることができました。

NAB Show 2025トピック

個人的に気になった3つのポイントでNAB Show 2025トピックを紹介します。

AI関連

NAB Showではここ数年、AI関連のブースやセッションが増加傾向にありましたが、今年も多くのAI関連セッションが開催されていました。私が参加したセッションも大半がAIに関するもので、特に業務効率化を支援するAIエージェント（Agentic AI）に関する内容が目立った印象です。

中でも特に印象的だったのはDecentrix社のセッションで、地上波広告とCTV等のデジタル広告では、広告購入システムやデータ管理の方法が異なるため、従来のエクセルベースの作業では広告のバイイングやプランニングの作業が複雑化している課題に対し、ユーザーがクライアントからの与件の指示を出すだけでAIエージェントが最適なメディアプランを自動で作成・提示するというデモンストレーションが紹介されました。

配信プランニングのような複雑な作業や定型的な反復作業をAIエージェントに任せることで、人間はより戦略的・クリエイティブな業務に集中できるようになり、結果として広告の価値をさらに高められる可能性があると感じました。ただし、セッション内でも強調されていましたが、AIに全ての作業を委任するわけではなく、最終的な意思決定は人間が担うという部分は残るので、全ての業務がAIに代替されるわけではないことを留意する必要がありそうです。

続いて、Interra Systems社のセッションでは、字幕制作の効率化が主要テーマでした。AIを活用してASR（自動音声認識）やリップシンク（口の動きとの同期分析）技術の精度と速度を高め、さらにAI翻訳による多言語展開を通じて品質向上を目指すという同社の取り組みが紹介されました。既にOpenAIのWhisperなど生成AI技術により音声認識精度はかなり向上しているので、これらの作業も効率化と高精度化の恩恵は受けやすい部分かと思いました。

また、Genies社、Run3TV社、NVIDIA社のセッションでは、AI技術が多言語吹き替えの際に俳優の口の動きを再合成して自然に修正ができる技術が実用化しつつあったり、将来的にはAIアバターがニュースキャスターなどの役割を担う可能性について活発な議論が交わされていました。

さらに、これらの議論の中で、 今後ATSC 3.0対応テレビ（NextGen TV）が普及すれば、地上波放送と連携したゲームやAIアシスタントなど、インタラクティブなコンテンツ提供が本格的に可能となり、これがテレビ広告収益の更なる拡大につながる可能性が示唆された点も、今後のテレビ端末や放送の進化を考える上で非常に興味深い内容でした。

SVOD、AVOD、FASTの状況

SVOD（定額制ビデオオンデマンド）のコスト増と解約のしやすさを背景に、複数のSVODサービスのバンドル提供、広告付きVOD（AVOD）への移行、FAST（無料広告付きストリーミングテレビ）を入口としたSVODへの誘導など、様々な戦略が模索されているとの内容がありました（Fastly社、Crunchyroll社、Storyful社、BB Media社のセッションより）。これらの動きは、日本におけるNetflixやAmazon Prime Videoの広告付きプラン導入、通信キャリアと連携したSVODバンドルパッケージの提供などと同様の状況と言えるかと思います。

また、LGなどのテレビメーカーも自社プラットフォーム上でFASTサービスを展開していますが、数百ものチャンネルが乱立する一方で、実際に利用されるのは数十チャンネル程度という課題があり、この点について、AIによるレコメンデーションなどでいかにユーザーに選ばれるサービスにするか、といった最適化に関する議論もなされていました。

このようなAVOD・SVODの最適化が求められる中で、個人的に興味深かったのがEvergent社のサービスです。同社はNAB Showにもブースを出展しており、日本でも事業展開しています。提供内容としてはサブスクリプションの収益最適化に特化したサービスで、ユーザーの解約予兆や有料会員化促進、柔軟な価格設定などのサービスを提供しています。今後のSVOD事業において、このようなユーザー毎に最適化したSVODサービスのニーズはますます高まるのではないでしょうか。

ショッパブル広告の可能性

Google社（YouTube担当）のセッションでは、動画本編の映像を解析するショッパブル広告の可能性に関する技術紹介がありました。これはAI映像認識技術を活用し、ライブ配信中の番組内に表示される物体を認識して、視聴者がそれを購入可能にするというものです。VOD配信においては、ライブ配信よりも高精度な物体認識が可能になり、より効果的なショッパブル広告の配信が期待できるとのことでした。

まだYouTubeやAmazonで広く実装されているわけではないようですが、この技術の登場により、現在GoogleレンズやApple Intelligenceなどで提供されている、写真に写ったものを購入できる体験が、動画配信においても番組視聴中に気になる商品があったら、その場で気軽に購入できる世界が、遠くない未来に訪れるかもしれません。

個人的には、このセッションでSCTEやVMAPといった既存の広告技術に、ショッパブル広告をどのように実装していくのか、その詳細を聞けたことがマニアックな内容で非常に参考になりました。

NAB Showまとめ

冒頭の参加経緯で述べたとおり、NAB Showでは日々の情報収集だけではなかなか得られない、放送業界や関連アドテクの最新トレンドに触れることができ、非常に刺激的な経験となりました。特に、AIやクラウド活用による放送業界・広告業界の業務最適化については、検証・導入を進めていく必要性を改めて感じました。

これらのトレンドを踏まえてTVerとしてもコンテンツ運用や広告運用におけるAIを活用した業務効率化や高度化をできる余地はあるなと感じました。特に自分は広告領域の担当なので、AIによる広告関連業務の全般の最適化やインストリーム広告を中心にした広告展開をしつつ、新しいフォーマット開発や新しいマネタイズポイントを増やす施策は海外情報も参考にしつつ、模索を続けたいと思いました。

今回のNAB Show参加を通じて、改めて世界的にも放送業界の変化が非常に激しいと感じました。来年のNAB Showはもちろん、今後、放送業界、広告業界でどのような進化が見られるのか、今から楽しみです。

そんな変化の激しい状況ですが、TVerの広告プロダクト開発チームでは一緒に広告プロダクトを開発するメンバーを絶賛募集中です。もちろん広告以外のエンジニアポジションも募集中です。

ご興味のある方は、是非弊社採用サイトをご確認ください。

try! Swift Tokyo 2025に参加しました！

参加レポート iOS

こんにちは、TVerでiOSエンジニアを担当している福島です。 先日開催された try! Swift Tokyo 2025 に参加してきました！

今回、私たちはスポンサーとして企業ブースを出展し、セッション聴講や他社のエンジニアの方々との交流など、非常に充実した時間を過ごすことができました。この記事では、当日の様子を簡単にご紹介したいと思います。

try! Swift Tokyoとは？

try! Swift Tokyo は、Swiftに特化した国際カンファレンスで、日本国内だけはなく海外からも多くのエンジニアが一堂に会するイベントです。

セッションの多くは英語で行われ、最新技術の共有や、開発に関するナレッジの発表、エンジニア同士の交流の場としても毎年大きな注目を集めています。

今回のイベントも、業界の第一線で活躍されている方々による知見が詰まったセッションばかりで、大きな刺激を受けました。

企業ブースでの様子

TVerとして企業ブースを出展しました。ブースでは、TVerというプロダクトへのご意見ご感想や、開発に使っている技術スタックについての情報交換など、エンジニア同士での交流を楽しむことができました。

ユーザーの声

多くの方に「TVer使ってますか？」と伺うと、嬉しいことに利用してくださっている方が大半でした。 普段視聴している番組の話から、アプリの使い勝手や新機能への期待まで、ユーザーの生の声を直接聞く貴重な機会となりました。

日頃からアプリを使っていただいている方々の期待に応えるため、より一層真摯に開発に取り組んでいきたいと思います！

技術交流

TVerで現在取り組んでいるリアーキテクチャで採用しているTCAやSwiftUIに関心のある方も多く、画面遷移や状態管理等、踏み込んだ具体的な実装方法について情報交換できたことは非常に有意義でした。

TVerではiOS 15までサポートしていることから、SwiftUIの新機能を使えないケースでの代替アプローチや互換性の確保など、「iOS 15サポートあるある」で他社エンジニアと共感し合う場面もありました。

同じ技術スタックを使用している企業のエンジニアとの情報交換は、今後の開発にとって大変参考になりました。

ノベルティ

ブースを訪れていただいた方へのノベルティとして、「TVerのなかみ」（TVer内部の様子をお届けするX公式アカウント）をフォローしていただいた方には、タンブラーや充電アダプタなどノベルティをプレゼントするキャンペーンを実施しました。

この施策は予想以上の反響をいただき、多くの方に喜んでいただけたようでした。実際にノベルティを受け取られた方からは、Xでこのようなお声もいただきました。

こうした反響もあり、「TVerのなかみ」アカウントのフォロワー数はtry! Swiftの期間だけで約200人増加しました。多くの方々にブースに足を運んでいただいた証として、大変嬉しく思っています！

まだ「TVerのなかみ」アカウント（@TVer_Inside）をフォローされていない方は、ぜひチェックしてみてください。開発の舞台裏や、エンジニアの日常など、興味深い情報を発信しています。

印象に残ったセッション

Swift OpenAPIを使ったライブコーディング ― ゼロから構築するストリーミングChatGPTプロキシ

このセッションは、Swift OpenAPIの威力を体感できるとても有意義なものでした。 OpenAPIのyamlファイルからSwiftコードを自動生成し、プロキシサーバーを構築するデモがライブコーディング形式で行われました。

お題は、野球などのスポーツでの応援歌が「レッツゴー○○○」とワンパターンになりがちな問題を解決し、選手の特徴に合った個性的な応援歌を自動生成する「ChantGPT」というサービスです。

Xcode以外の選択肢

開発環境にXcodeではなくVS Codeを採用していた点が興味深かったです。 SwiftとOpenAPIの拡張機能を活用したこの選択は、OpenAPI関連の開発においては非常に効率的だと感じました。

Xcodeしか使ったことがない身としては、業務でも活かせそうだなと、とても参考になりました。

Swift OpenAPIの素晴らしさ

発表者はまず、ChatGPTのAPIを直接呼び出すクライアントの作成から始めました。OpenAIが公開しているOpenAPIのyamlファイルからエンティティを自動生成し、API通信に必要な各種実装を行っていきます。

特に印象的だったのは、API定義に準拠した型安全なコードが自動生成される点です。 パラメータ設定のミスやレスポンスのパースエラーといった典型的なバグを未然に防げるため、開発工数の削減と品質向上に直結すると感じました。

TVerでもバックエンドでOpenAPIを採用し始めているため、この利点は非常に共感できました！

プロキシサーバーの威力

実際にChatGPTに特定チームの応援歌を作成してもらうデモでは、興味深い問題が発生しました。特定選手の応援歌を生成しようとした際、ChatGPTの情報が古く、選手が過去に所属していたチームの応援歌が生成されてしまったのです。

この問題に対し、最新のチーム情報をテキストファイルとしてChatGPTに学習させる解決策が示されました。 このようなロジック修正をより柔軟に行うため、OpenAPIのyamlファイルでChantGPT(プロキシサーバー)のAPI定義を作成し、そこからプロキシサーバー側、クライアント側のエンティティの自動生成・通信処理の実装が行われました。このアーキテクチャにより、

  • クライアントがChatGPTに直接依存しなくなる
  • 認証情報の管理が一元化される
  • 事前学習などの複雑な処理をサーバー側に隠蔽でき、関心の分離が実現できる

などのメリットがあると感じました。プロキシサーバーの必要性が実際の問題解決を通して自然と理解できる流れは非常に説得力がありました。 私自身はiOSエンジニアとしてフロントエンド開発を主としていますが、今回のセッションを通じてバックエンド側の解像度も高まり、業務にも活かしていけると感じました。

Appleプラットフォームにおけるセキュリティリサーチとバウンティハンティング入門

このセッションでは、Appleプラットフォームにおける脆弱性の発見方法や、Apple Security Bountyプログラムについて説明されました。 普段の開発の視点から少し離れた内容で、新たな発見が多かったです。

開発者にもできるセキュリティリサーチ

セキュリティリサーチとは、ソフトウェア、OS、ハードウェアにおける悪用される可能性のある脆弱性を発見する活動です。 このような活動を行う人々は「Ethical Hacker（ホワイトハッカー）」と呼ばれています。

興味深かったのは、普段私たちがソフトウェア開発で行っていることとの違いです。 開発者は「どうやったらうまく機能させることができるか」を重視していますが、セキュリティリサーチでは「どうやったら壊すことができるか」という考え方にシフトするだけなのです。

つまり、開発者ならば誰でもセキュリティリサーチャーになれる可能性があるという点が印象的でした。

脆弱性発見のアプローチ

セッションでは、脆弱性を発見するための具体的なアプローチとして、リバースエンジニアリングの手法が紹介されました。 Appleのフレームワークをデコンパイルし、内部処理を解析するというものです。

最新のデコンパイル用ソフトウェアを使えば、かなり理解できるレベルの疑似ソースコードが得られるとのことでした。 これにより、開発者でもAppleの内部実装を理解し、脆弱性を発見できる可能性があることを知りました。 時間のあるときに実際に試してみたいと思います。

Apple Security Bountyの仕組みと実例

Apple Security Bountyは、Apple製品の脆弱性をAppleに報告することで報奨金が支払われるプログラムです。 報奨金は脆弱性の種類や影響範囲によって異なり、5,000ドルから最大200万ドル（約3億円！）にもなるそうです。

特に興味深かったのは、発表者が実際に経験した報告事例です。Xcodeの内部処理でUserDefaultsのキーとしてユーザーのApple IDのメールアドレスが暗号化されずに保存されており、他のアプリからも閲覧可能な状態だったとのことでした。

発表者はこの脆弱性を利用してメールアドレスを取得できるサンプルアプリを作成し、詳細なレポートとともにAppleに報告しました。 結果として7,500ドル（約100万円）の報奨金を受け取ったそうです。

事例を聞くと比較的シンプルな内容であり、日常の開発の中でも発見できる可能性があると感じました。機会があれば自分も貢献してみたいと思います。

開発者としての新たな視点

このセッションから得た最大の学びは、私たち開発者が普段の業務の中で異なる視点を持つことの重要性です。 普段何気なく使っているApple標準のアプリやAPIも人間が作ったものであり、必ずしも完璧ではありません。

「このAPIは悪用できないだろうか？」「この実装に脆弱性はないだろうか？」という視点を持ちながら開発することで、自分たちのアプリのセキュリティ向上にもつながりますし、もし実際にApple製品の脆弱性を発見できれば、報酬を得ながらAppleエコシステム全体のセキュリティ向上に貢献できるという、まさに一石二鳥の可能性があります。

TVerの開発においても、このような「壊す視点」を時には取り入れることで、よりセキュアな実装ができるのではないかと感じました。 セキュリティはユーザー体験の重要な一部であり、万が一の情報漏洩などを防ぐためにも、常に意識しなければならないテーマだと再認識できました。

最後に

try! Swift Tokyoを通して交流してくださった皆様、本当にありがとうございました！ こうしてエンジニア間での交流が気軽にできる場があるのは、とてもありがたいなと改めて感じました。

また、TVerでは現在、一緒に働く仲間を募集しています！ 5/21(水)12:00~13:00に、iOSエンジニアの小森がFindy Job LTに登壇してTVerでのiOSアプリ開発の状況についてお話する予定です。ご興味のある方はぜひご参加ください！

findy-code.io

カジュアル面談も受け付けています。少しでもTVerのことが気になった方は、お気軽にご連絡ください！

herp.careers

TVerバックエンドAPIのリアーキテクチャ

Go

TVerバックエンドチームの id:takanamito , 小林 ( @k0bya4 ) です。

この記事では、TVerにおけるAPIリアーキテクチャについて紹介します。

ここでいうリアーキテクチャはAPIサーバーのソフトウェア的なアーキテクチャを変更する作業のことを指します。一部インフラにも変更点はありますが、今回の記事ではソフトウェアのリアーキテクチャにフォーカスして書いていきます。

今回の記事では、なぜリアーキテクチャをするのか、どのような課題を解決しようとしているのかを整理して解説します。

続きを読む

TVerサービスの継続的安定への取り組み

AWS NewRelic SRE

はじめに

TVerのSREチームでインフラ周りやサービス監視オブザーバビリティーを担当しています西尾です。 この度はサービスとしての認知が広まり、配信プラットフォームとしての社会的な重要性も高まってきたTVerサービスについて運用面からの取り組みを紹介していきたいと思います。 現在Tverに関しては、多くのユーザーから視聴していただいていますが、サービス提供に関するステークホルダーとしてはこの視聴されていますユーザー以外にも、配信を行うコンテンツを制作提供している各放送局の方々も含まれ、サービスとしてはBtoC/BtoBの両方の性質をもっています。 そのため、サービスの安定稼動についてはこれからもっと多くのユーザーに必要とされ、また信頼できる動画配信プラトフォーム業者として各放送局の方々から選ばれるように高いレベルで求められています。 安定稼働の取り組みとしては各チームで様々な施策を行なっていますが、SREチームとしてどのような事を行い、どのような姿を目指しているかを書いていきたいと思います。

動画配信サービスの構成

TVerのサービスに関しては、このサービスを提供するにあたって様々なコンポーネントで構成されています。 ここでは個々の領域に踏み込むと説明が長くなってしまうので割愛し、一般的に使われているサービス名を利用しながら紹介したいと思います。 まずTVerのサービスに関しては大部分がAWS上で稼働しています、一部のコンポーネントに関してはGCP上でも動いていますが、これはサービス（サービスを構成する個々のコンポーネント）やデータ特性などにより各種パブリッククラウドの事業者のサービスを使い分けているのでこのような構成となっています。 動画配信の部分を除けば、一般的なAPI構成で使われているAWSサービスを利用して構築されていますので、その部分はイメージがつきやすいと思います。 パブリッククラウドのサービス以外の部分ですと、CDNではJOCDNを、動画配信のメディアに関してはPLAY社のSTREAKSなどを利用しています。

TVerインフラ構成

CMSに関しては、TVerで配信を行なっているコンテンツを登録するために専用の画面を作ってそこで配信素材を管理しています。

運用面

SREチームが関わる非機能要件部分の運用業務としては、CI/CD周りやインフラのスケーリングなどが存在します。 CI/CD周りに関してはGitHub Actionsでコードが含まれるイメージをbuildして、それにタグ付けを行なってからECRにイメージをpushしています。 そしてそのイメージがpushされたのをトリガーとして、ECS上のサービスが更新されるようになっています。 デプロイの更新に関しては、通常はローリングアップデートを行なっていますが、重要な更新を含むリリースの場合はカナリアリリースを行うようにしています。 カナリアリリースに関しては、カナリアリリース用のECSサービスが別途稼働していますので、そのターゲットグループに対して流すトラフィックのウェイトをALB側で設定しています。 カナリアリリース後問題なければ、本番稼働していますECSサービスに全てのトラフィックを流してリリースが完了となります。 ECSサービスでカナリアリリースする場合、いくつかの方法がありますが、当初はブルーグリーン・デプロイメントも利用することができるデプロイ方式のAWS CodeDeployを検討しました。 ただこれに関してはサービスの再作成が必要になり導入の際にダウンタイムを無くす場合の準備と検証に時間がとれなかったので見送りになりました。

カナリアリリース

しかし将来的にはリリース時のサービス影響を極力無くすために、今後ブルーグリーン・デプロイメントの採用はどこかの時点でやっていきたいと思っています。

インフラ周りのスケーリングに関しては、過去の記事で取り上げていますがOmniscientという独自のシステムを利用して行なっています。 このシステムではECSサービスのタスク数やリソース、RDSのレプリカ数などをGUI上のコンソールで指定することがで、その指定した内容で最終的にはCloudFormationを通して実際の変更が行われています。 事前に具体的なスケーリング内容を設定してテンプレートを準備しておく事が出来るので、スケーリングすべき日時にそのテンプレートを適用するだけでインフラのスケーリング作業を完了する事ができます。 実際のスケーリングをどのタイミングで行うかですが、例えば多くのユーザーに注目されるコンテンツ配信については事前にどれくらいユーザーが流入するか過去の経験や別チームから提供される情報で対象を特定する事が可能ですので、そのコンテンツの配信可能となる時間に合わせて行われています。

イメージ - XX月XX日 21:00
サッカー日本対XXX ユーザー想定同接数　XX万人　→ 　x10倍テンプレート利用

監視面

サービスを安定稼働させるには欠かせないのが監視、最近では予防的な措置を含めて観測するオブザーバビリティーとしてシステムの安定稼働に必要な要素として再定義されています。 TVerサービスとしては、原則はNew Relicにデータを送りそこでアラート設定も含めてメトリクス、ログの監視を行なっています。 New Relicにデータを送る方法ですが、現在稼働するサービスが複数のAWSアカウントやサービスに跨っていますので下記の通り複数経路が存在します。

APM

・コード上にAPMエージェントを組み込み、New Relicに直接送信

インフラ面

  • メトリクス

・ コンテナのサイドカーとしてinfra agent組み込んでNew Relicに送信

・ EC2についてはinfra agentを直接配置してNew Relicに送信

  • ログ

・ コンテナのサイドカーとしてFireLensを組み込み、New Relicに直接送信 (＊FireLensでS3、CloudWatch Logs、New Relicにカスタムルーティングを行なっている)

・ EC2に関してはfluentを利用してCloudWatch Logsにエラーログのみ転送し、トリガーとしてlambdaを設定しNew Relicに送信

・ ALBのログなどAWS固有のサービスログに関しては、S3に保存し、その後Athenaを利用して集計しlambda経由でNew Relicに送信

Log Forwarder 構成

監視アラートに関しては、設定できるポイントはいくつかありますが一元的にアラート管理を行いたいのでアラート設定を行う必要のあるメトリクスやログはNew Relicに流してそこで設定するようにしています。 New Relicに関してはAPM機能を利用するために、バックエンド、フロントエンド、ネイティブアプリにエージェントのインストールを行なっていますが、Androidアプリに関してはFirebaseやGoogle Play Consoleで補完しているものもあります。

通知アラート

アラートの閾値、通知設計は的確にサービスの問題を検知し対応するためにサービスの安定提供に重要な要素になります。 当初はあまり通知先や閾値設計ができてなかったので、どこに何のアラートが飛んでるかわからず、またこのアラートがどの程度のサービスインパクトがあるか把握しにくい部分がありました。 そのため、現在はサービスインパクト別にセベリティで分けた通知先を準備し、アラートの閾値は現在まで蓄積されたメトリクスを利用し障害時の状況から逆算的に設定できるように取り組んでいます。 まだこれに関しては、進行中の作業になりますが設定が終わる頃には以前よりは問題把握のスピードアップができエスカレショーンフローもスムーズになると信じています。

SLA/SLO

TVerでは特に現在のところSLA/SLOを公表していませんが、必要性を理解していますのでまずは内部的な指標としてその準備を現在進めています。 New Relicにデータを一元的に集めることで、エンドポイント監視、ログ監視、Syntheticモニター機能を利用して全体的なサービス、個々の機能の広く見渡せるよう定義していく予定です。 現在までにこの作業で実施している取り組みに関しては、下記のようなものがあります。

  • New Relic Synthetics scripted browserを利用して実際のユーザー体験を考慮した(CUJ)監視計測
  • スパイク時、障害時のメトリクスデーターの蓄積を行い問題発生時に注視すべき対象を特定
  • 遅延などデグラデーションも認識できるようにポイント、コンポーネントごとの指標の定義
  • WEB、アプリ、コネクテッドTVなど複数のデバイスで視聴されるので、デバイス固有の問題を特定できる指標の定義

SLA/SLOダッシュボード(New Relic)

これらはのデータはすぐに揃えることが難しくなかなかSLA/SLOの着手ができなかったので時間を要しましたが、各サービスの開発担当者と協力しながらある程度形になるものは出来ようとしてます。

目指すべき姿

残念ながら今年に入ってもTVerサービスでは一時的な接続障害を発生させてしまっています。 起因となる理由は複数ありますが、本来SREとしてカバーしていれば防げたところもありました。 特に挙げられるものとしては、TVer独特の事象としまして地上波放送からの流入により一時的に急激な流入でインフラのスケールが追いつかずにトラフィックを捌けない事があります。 前もってわかるような同接数であれば、事前にスケールする事が可能ですが、スポーツなどのリアルタイム配信に関しては試合展開によっては地上波放送時間内に収まらずにTVerに誘導される事があるかと思いますがこれがあたります。 ECS構成は管理しやすく運用も比較的に楽ではありますが、ユーザー数の増加やサービスの重要性を考えるとこのスケールが間に合わない問題に対して抜本的なインフラ構成のリファクタリングを考える時期にきていると思っています。 合わせて開発側のCI/CD周りの利便性やリリース方式の検討もできれば、今までボトルネックになっている問題に対しても解決策を提示できるのではないかと思います。

まとめ

サービスを安定稼働するためにSREとして関わることが出来る業務として複数あります。

  • 各サービス開発者に対して、適切な指標の提供
  • サービスの問題を素早く検知しエスカレーションが出来る体制の整備
  • 運用管理しやすいインフラ構成の提供
  • SLA/SLOを整備することにより、サービス関係者に現在のシステム状態の周知 　 　

これらの事はどれも重要ですので全て進めていきたいですが、時間も人も有限なので現状は優先順位をつけて取り組んでいる状況です。 そのためTVerサービスを支えていただける方(SRE業務)を幅広く求めています。 サービスとしては非常に社会的に求められるサービスであり、大規模なトラフィックを捌ける業務となりますのでやりがいはあるかと思います。

TVerはtry! Swift Tokyo 2025に協賛します！

スポンサー カンファレンス 参加レポート iOS

こんにちは、TVerでエンジニアリングマネージャーをしている高橋 (@ukitaka) です。 TVerはtry! Swift Tokyo 2025にゴールドスポンサーとして協賛させていただくことになりました！

TVerのiOSチームの近況

以前iOSDC Japan 2024で発表させていただいたタイミングではまだまだ立ち上がり途中だったチームも、当時から人数がなんと3倍 (※1人 → 3人) になり順調に大きくなってきています。

また昨年末からtry! Swiftオーガナイザーの1人である松舘さんにも技術アドバイザーとしてご参画いただいています。

techblog.tver.co.jp

TVerとしてはもう少しiOSエンジニアを採用していく予定なので、去年も大盛況だったtry! Swiftにスポンサーをさせていただくことに決めました！

まずは去年の様子を弊社iOSエンジニアの小森から発表させていただきます。

try! Swift Tokyo 2024の参加レポート

こんにちは、TVerでiOSエンジニアをしている小森(@mathtanguu)です。 今更ですが、try! Swift Tokyo 2024の参加レポートになります。

5年ぶりの開催ということでオープニングから盛り上がってました！

ブースに関して

様々なコンテンツが用意されており、各社参加者が有意義に過ごせるように工夫されていました。

  • LINEヤフーさんのソースコードレビュー

  • RIZAPさんのアンケート

  • RevenueCatさんのくじ引き

ぬいぐるみも当てましたw

セッションに関して

セッションスライド等は有志の方々がまとめてくれています。

qiita.com

特に印象的だったセッションは、Swiftの型推論を学ぼう | Let’s Learn About Type Inference in Swiftです。 Swiftの型推論に関するメカニズムを解説したセッションでした。

speakerdeck.com

正直、私はこのメカニズムを深く意識した開発はしていないので内容を理解するのに非常に苦労しました。(まだ理解しきれていない) Swift言語仕様に関しての理解力をあげていきたいと考えるきっかけになりました。 (内容薄くてすみません、本当に言語仕様って難しい)

最後に

最高に有意義な3日間でした。アフターパーティーではHACKING WITH SWIFTのPaulさんに声をかけて写真を取っていただきました！

try! Swiftへの参加は初めてだったのですが、世界中から集まった登壇者や参加者の熱量に圧倒され、TVerとしてもtry! Swiftに何らかの形で貢献できないかと考えるようになりました。

そして try! Swift Tokyo 2025 協賛へ...

try! Swift Tokyo 2024の盛り上がりを踏まえ、Swiftの開発者コミュニティへ貢献したいという想いと、そこにいる人たちに少しでもTVerでのiOS開発に興味を持ってもらえればという想いから、今年はTVerもゴールドスポンサーとして協賛させていただくことにしました。

当日はスポンサーブースも出しているので、ぜひ遊びに来てください！

herp.careers

松館大輝 (@d-date)さんに iOSの技術アドバイザーとして就任いただきました

iOS

こんにちは、TVerでエンジニアリングマネージャーをしている 高橋 (@ukitaka) です！ 昨年末から松館大輝 (@d-date) さんにTVerのiOSアプリの技術アドバイザーに就任いただきましたので、この記事でお知らせさせていただきます。

松館 大輝（まつだて だいき）

東京を拠点に活動する iOS Developer。世界中から Swift の開発者が集まる try! Swift Tokyo のメインオーガナイザーを務める。またスタートアップ数社、内閣官房 IT 総合戦略室（デジタル庁準備室）を経て、現在ではデジタル庁エンジニアユニット長を務める傍ら、さまざまな企業でアプリ開発の支援や技術顧問・アドバイザリーを行う。

※著書「iOSアプリ設計パターン入門」（PEAKS）

今回の取り組みの背景

iOSDCやこのTech Blogでも何度かお伝えさせていただいている通りTVerのiOSアプリは現在リアーキテクチャに取り組んでいます。

speakerdeck.com

もちろんリアーキテクチャを行わず枯れた技術を使い続けるという選択自体はできなくはないですが、以下のような観点を踏まえて、TVerではリアーキテクチャに取り組むことに決めました。

  • 採用市場での競争力低下のリスク

  • 新しい技術や体験への適応に時間がかかりすぎることによる、サービスとしての競争力の低下リスク

ただし、アーキテクチャの変更はそれ自体が技術的に難易度の高いタスクであり高度なソフトウェアエンジニアリングスキルを必要とします。さらに、iOS開発を取り巻く環境は数年前に比べて大きく変化しており、SwiftUIやSwiftConcurrencyの登場によりiOSエンジニアに求められる標準的なスキルは上がっていっているように感じています。

ベースとして「自分たちでやりきるぞ！」という気合いも持ちつつも、技術的に詰まってしまった時にサクッとトップレベルのエンジニアに相談できる環境があること自体がスピーディーに開発を進める上でも重要だと考え、TVerが採用していく予定のTCAやSwift Package Managerでのマルチモジュール構成などに業界トップレベルの深い知見を持っている @d-dateさんに技術アドバイザーとして参画いただくことに決めました。

実際の取り組み

数回のミーティングを通してまずは現状のコードベースと、幾つかのフィードバックをいただいています。

松館大輝 (@d-date)さん からのひとこと

ご縁ありまして、技術アドバイザーに就任いたしました。私自身お世話になっているサービスですし、TVerのiOSエンジニアのみなさんのお力になれるように一緒に頑張りたいと思っています。

さいごに

トップレベルのエンジニアのサポートを受けながら開発できるというのはある意味最高の福利厚生だと考えています。 TVerではまだまだiOSエンジニアを募集していますので、ご興味持っていただけた方はぜひご応募よろしくお願いします！

herp.careers