#えむけーろぐ

間違った事を書いていたらやさしく教えてください

Podcastの音声配信部分を自前のものから別の配信サービスへ移行した #yuru28

Podcastの音声配信を、Rails + S3 / CloudFrontで構築していた自作のものからART19に乗り換えた。

移行前のシステムについて、まとまった文章を書いたことがなかったなぁと思ったのでメモがてら書きつつ、今後どうART19と並行運用していくのか、みたいな話を書いていこうと思う。

旭山動物園(北海道旭川市)にいたあひる ※記事とは関係なし

はじめに

学生時代の友人と趣味でやっているゆるふわPodcastは、Webサイトから音声配信、管理画面や分析ダッシュボードまですべて自前で開発・運用していた。

yuru28.com

当初はWebサイトをJekyll + GitHub Pagesで構築・配信し、音声配信はSoundCloudにおまかせという感じだったのだが、「仕事でRails使うし自分でメンテして好き勝手にできるRailsアプリを持っておきたい」というモチベーションでWebサイトや音声配信システムを自分で開発・運用していた。

最初のcommitは2020年4月

自作の配信システム + Podcast CMS

自作の配信システムの概要はこうだ。下図で示したのは音声配信の仕組みのみだが、WebサイトやPodcast CMS(Vue製のSPA)向けのAPIも同じRails Appに同居している。

Podcast 音声配信システムのシーケンス図

音声配信を自作したモチベーションは、冒頭に書いた通り技術勉強が大きな割合を占めている。それに加えて、音声配信を自身のコントロール下におきたいというのがあった。

音声配信を自作すると、コンテンツの設定・配信まで一連の作業をすべて手中に収めることができる。「音声を別のプラットフォームにアップロードし公開予約をしたあと、Webサイト側は別でページの公開設定をして……」といった作業、「現状の再生数やリスナー数を知るために、Apple Podcast ConnectとSpotify for Podcasters、Google Podcasts Manager、その他諸々……の数値を足し合わせて集計する」といった作業から開放される。

音声ファイルの公開予約とエピソードのWebページの編集・公開予約は同じ画面で簡単に設定できるし、プラットフォーム横断で再生数を取得し、自分の好きな単位(時間・日・月や曜日ごとなど)で集計するなんてことも簡単なクエリを書けばすぐに算出できる。

自作したPodcast CMS
Podcastの分析の様子(Redash利用)

この配信システム + Podcast CMSは、自分が開発者であると同時に、自分が最大のユーザーである。自分の作業を改善したいとなったとき、新しい技術を試したいとき、誰に依頼するでもなく自分でいろいろできるのはとても楽しい。

過去に、この配信システムについて発表したときの資料がこちら。
※ 当時はAmazon Lightsailのオブジェクトストレージを利用していたが、AWS S3の方が安いしラクということに気がついて乗り換えている。

speakerdeck.com

下記にいくつかシステム開発の記録の記事を貼っておいて、移行前の配信システムの話は終わりにしようと思う。

blog.m6a.jp

blog.m6a.jp

blog.m6a.jp

移行の動機

ここまでで書いた自作の配信システムだが、実は2023年6月から、音声配信部分を別システムのART19に移行している。ART19は、Podcast配信と収益化のSaaSで、2021年にはAmazonに買収されている。

www.itmedia.co.jp

移行の理由は、Podcastのプロデュース等を行っているスタートアップPitPaさんのエンジニアPodcastネットワークに加入させてもらったからだ。

prtimes.jp

2023年7月以降、ゆるふわPodcastのエピソードを聞くと音声広告が挿入されていると思う。時期によって適切なコンテンツを動的に挿入しているのだが、これはART19のシステムを利用して提供しているため、自作していたシステムも乗り換える必要があったのだ。

並行稼働期の概要

というわけで、音声配信部分のみRails Appで提供するのをやめて、ART19に移行する必要が出てきた。とはいえ、Webサイトはちゃんと活かしたい(自分のドメインで配信したい)ので、そっちは引き続きCMSで管理しRails Appから配信する必要がある。つまり、自作のシステムとART19の並行稼働が必要になるわけだ。

音声配信の部分は、自分で配信していたRSSフィードへのアクセスをすべてART19にリダイレクトすることで解決した。下記のようなイメージだ。

Rails App / ART19並行稼働時のシーケンス図

一方で、「音声を別のプラットフォームにアップロードし公開予約をしたあと、Webサイト側は別でページの公開設定をして……」という作業が増えてしまった。幸い、ART19は開発者向けのWeb APIを提供しているため、利用させてもらうことにした。

用意されているのは参照系のみだったので、ART19 -> Rails Appという片方向のみの同期を行い、RailsのDBにはあってART19には無い項目(出演者情報など)を手動で入力するというオペレーションの改善を行っている。

ART19 -> Rails App同期のSlack通知を起点にRails App上で追加の操作を行う

RailsのDBにはあってART19に無い属性(スピーカー)は手動で管理画面から埋めている……

今後

Podcastとしてコアの部分である音声配信を外部のプラットフォームに任せてしまっているので、正直サーバーサイドを廃していわゆるJamstack的なWebサイトにしてしまっても良いと思っている。

が、オペレーションの改善は続けつつ、ART19とRails Appの並行稼働は続けたい。

Podcastという趣味で使う道具を自分で作って改善していくということは続けたいし、それをRailsという大好きなフレームワークで出来るということに大きな意味があると思っている。まぁ、企業の営利目的の事業だとそんな話通じないだろうけど……趣味なので、いいでしょう。

とはいえ現状のようなART19上で設定してRails Appで追加設定するなんてオペレーションはさっさとやめてしまいたい。データはすべてART19からsyncするようにして二重オペレーションを無くしつつ、Podcast以外の付加価値の部分(例えばサポーター向けのWebサイト。現状文字起こし検索しかない。)を拡充していくとかが落とし所かなぁ。

おわりに

気がつけば今年の5月で4周年を達成していたり、先日はEP200を達成していたりと、よくもまあこんなに続いているもんだと思う。こんなにもPodcastが続いたのは、いつも一緒に収録してくれているメンバーや、出演してくれるゲスト様、そして聞いてくれているリスナーのみなさんのおかげだ。それと同時に、「自分の趣味で使う道具を自分でつくる」という、一種のDIY的な要素がめちゃくちゃ楽しかったというのがあると思っている。

今後も楽しくPodcastとものづくりを並行して続けていければなと思う。