Zenn
🛠️

Github Pagesのデプロイ速度向上〜Yattecastの改修〜

2024/01/11に公開
podcast
Cloudflare
GitHub Pages
yattecast
R2
tech

はじめに

私はaozora.fmというPodcastを配信しています。
これはYattecastというテンプレートを改造したPodcast配信ページです。
YattecastはGithub Pagesを利用しており、2021年8月末まではGithub PagesのデプロイにGithub Actionsは使われておらずデプロイ時間もさほどかかっていませんでした。

しかし、2023年11月末にGithub Pagesを更新したところ、デプロイにGithub Actionsが使われるようになっていました。
Github Pagesの設定でBuild and deploymentをDeploy from a branchにしていてもGithub Actionsが動きます。
Github PagesのGithub Actionsは毎回リポジトリ内の全てのファイルをアーカイブしアップロードします。
これがテキストや画像数枚だけのサイトなら問題ありません。
しかし、Podcast配信サイトとなると1エピソードにつき数十MBのMP3ファイルが含まれるため、エピソード数が多くなればなるほどそこそこのサイズのMP3ファイルがアーカイブ、アップロードされるようになり、デプロイに時間がかかるようになります。
aozora.fmでは86エピソード、合計3.77GBのMP3ファイルが存在し、デプロイに30分前後かかるようになってしまいました。

今回はこのデプロイ時間が長いという問題を解消した顛末を紹介します。
ほとんどいないと思いますが、YattecastでPodcastを配信している方、これから配信しようとしている方に向けて参考になれば幸いです。

サマリ

  • 問題
    • Github Pagesのデプロイに時間がかかる(30分前後)
    • Github Pagesのアーティファクトサイズの上限である1GBを超えてしまう
      • 警告は出るがデプロイはできる
      • しかし、いつデプロイできなくなるかは分からない
  • 解決策
    • サイズが大きいファイル(今回はMP3ファイル)を別サーバーへ移動
  • 結果
    • 30分前後かかっていたデプロイ時間が、50秒程度に短縮
    • 約3.7GBあったアーティファクトサイズが、約3MBに減少
  • 費用
    • ドメイン料に年間約600円

経緯

デプロイに時間がかかると分かってから3回、合計4回デプロイした時点でこれは対処しないとストレスフルだと判断しました。
なにせ、Podcast公開後に誤字脱字を1文字直すだけでも毎回全てのファイルをアーカイブしアップロードするため、公開まで30分待つ必要があります。
またGithub PagesにMP3ファイルを配置しているとデプロイが終わらなければ正常に再生できるかどうか分からず、約30分待ってちゃんと配信できたかどうか確認するはめになっていました。

対策案の検討

Github Actionsの設定見直し

そこでまずGithub Pagesにデプロイする際のGithub Actionsの設定を変更し、差分デプロイが可能がどうか調べてみました。
しかし、調べてみても差分だけデプロイ・アップロードする方法は見つかりませんでした。
差分を検知する方法、差分だけテストする方法などはありましたが、デプロイ対象を差分だけにする方法は見つかりませんでした。
もし、この記事をご覧の方でGithub Actionsの差分デプロイ方法をご存じの方がいればコメントなどでご教授いただけると幸いです。

知人に相談しGoogle Driveを使ってみる

次に知り合いが集まるITエンジニアコミュニティに相談し、解決策がないか相談してみました。
何も案がない相談では投げやりすぎるので以下の案で相談しています。

  1. CloudFlareでドメインを購入してWebサイトなりWebストレージなりを使う
  2. Google Driveを使う
  3. Podcastの配信サイトを変更する
  4. 諦めてデプロイ時間を受け入れる
  5. その他、なにか良い案があれば教えていただきたい

この時点で個人的には無料だしGoogle Driveかなぁと思っていました。

相談に乗ってくれたITエンジニアは二人で、両人ともGoogle Driveがよいと言ってくれたのでGoogle Driveを試してみました。
Google DriveにアップロードしたMP3ファイルを共有して得られたリンクをPodcastに埋め込むと、MP3として認識されず、Google Drive専用のViewページが表示されてしまいました。
これでは音源のダウンロードができても配信ページで再生できないため、NGです。

というわけで、Google Drive案はボツになりました。

さらに助言を募るとさくらのVPSが良いとのこと

Google Driveはダメだったとの報告を兼ねて、さらに助言を募ったところ、さくらのVPSをオススメされました。
そのときに確認すると最低構成にすれば月額319円[1]で運用できそうでした。

この時点で無料で解決するのはほぼ諦めており、どのサービスが一番安いか?に関心が移っていました。
比較すると以下のようになります。

  • CloudFlareで1番安いドメインを購入すると年額約600円
  • さくらのVPSで一番安い構成だと年額約3600円

CloudFlareは無料枠があり、超過すると課金されてしまう可能性があり、ストレージサイズの上限が10GBなのがボトルネックになります。
ですが、約5年間配信してきて3.7GBであり、仮に10GBを超過ても1GB2円とかなのでドメイン量に比べればわずかな値段なので問題にはならないと判断しました。
その他、バケットへの操作も月に100万、1,000万リクエストが無料の上限ですが、場末のPodcastではそこまでいくことはなさそうです。

というわけで最も安いCloudFlareで運用することにしました。

CloudFlare R2の導入

導入に関してはググれば出てくるのと、日本語にできるのでここでは詳細に紹介しません。

唯一ハマった点としては支払い方法として選択可能なPayPalが選択できず、クレジットカードじゃないと登録できなかったことです。
PayPalを選択してOKを押しても画面を更新すると無かったことになっており、特にエラーメッセージもなかったので調べ様もなく、解決できませんでした。

あとはドメインの購入(.winが安くてオススメです)、R2のバケット作成、ドメインの適用、MP3ファイルのアップロードをするだけで準備完了です。

Yattecastの改修

デフォルトではMP3のファイルパスはGithub Pagesにデプロイされたaudioフォルダ配下を参照しています。
これはyattecast/_layouts/article.htmlのaudioタグの中で以下のように指定されています。

src="{{ page.audio_file_path | prepend:site.github.url }}"

ここで prepend:site.github.url はGithubPagesのURLを示しているので、CloudFlareに載せ替える際はこれを削除します。
すると以下のようになります。

src="{{ page.audio_file_path }}"

この page.audio_file_path はyattecast/_posts配下にあるマークダウンファイル(例:2016-11-10-1.md)内のaudio_file_pathという項目にあたります。
ここにCloudFlareに配置したMP3ファイルのURLを指定すればCloudFlareからMP3ファイルを配信できます。

あとはaudioフォルダ内のMP3を削除してcommit、pushし、デプロイが成功すれば完了です。

さいごに

というわけでGithub Pagesのデプロイ速度改善にCloudFlare R2を導入した顛末を記事にしてみました。
相談に乗っていただいた方に報告するために、Yattecastで同じ悩みがある方のお役に立てばと思い書いてみました。

費用としてドメイン代金が年額600円かかるようになってしまったので、aozora.fmでは支援者を、PIXIV FANBOXかOFUSEで募集してます!

ゲストも募集中です!
X(旧:Twitter)でDMか、メンション頂ければOKです!
ハッシュタグ#aozorafmでご意見ご感想もお待ちしております!

脚注

  1. 確認当時の金額、この記事を書いている時点では590円になっていました ↩︎

Discussion