radikoの録音アプリをGCPのAppEngine上でやっと動かせた話
ラジオを録音したいわけです。自宅PCは電源のオンオフがあるので、できればクラウドサービスを使いたい。
らじる☆らじるに関しては、まあまあうまくいったのですが、radikoが難関でした。
| サービス | らじる☆らじる | radiko |
|---|---|---|
| AWS Lambda | ○ | × |
| AWS EC2 | ○ | ○ |
| GCP Cloud Functions | ○ | × |
| GCP App Engine | ○ | ○(今回) |
| GCP Cloud Run | ○ | × |
| GCP Compute Engine | ○ | ○ |
もっとも、らじるでは15分番組を録るのでLambdaでもよいのですが、radikoではもっと長時間の番組を録る。そう考えたとき、Timeoutまでの時間がネックでした。下表はTimeoutの一覧です。
| サービス | タイムアウト（2022.5現在） |
|---|---|
| AWS Lambda | 15m |
| AWS EC2 | ∞ |
| GCP Cloud Functions | 9m |
| GCP App Engine | 24h（基本スケーリングの場合） |
| GCP Cloud Run | 1h |
| GCP Compute Engine | ∞ |
見て分かる通り、1時間超の番組を録音しようと思ったら、VM以外ではApp Engineしか選択肢がありません。
苦労した点
ローカル環境では問題なく動くスクリプトをApp Engineに載せた途端に動かず、クラウドでのデバッグにも慣れていないため、かなり長い間コーディングのミスを探していました（不毛）。
そんなことで原因が見つかるわけもなく、「radiko側から日本以外からのアクセスとみなされているんだろうな、多分」となかば諦めていたところ、同じ現象の人を発見。
jpdebug.com
東京（ap-northeast1）リージョンで作ったのに、そんなことがあるのかと思い、色々調べていくと、どうやら「GCPが東京リージョンであることと、そのIPがradiko側で東京と認識されることは別物」のようですね。Googleは世界中のIPアドレスを使えるが、各リージョンに対応するIPを振っているわけではない」とか「そのIPの割り振りがダイナミックなので、IPで判定するサイトが持っているデータベースと合わない」とか、私にはどれが完全に正解かはわかりませんでしたが、
GCPが東京リージョンであることと、そのIPがradiko側で東京と認識されることは別物
ということは間違いないなと理解できました。
解決法
サーバレスVPCアクセスを利用します。
- ハイブリッド接続 > Cloud Routerを作成（Cloud NATの作成時にまとめて作ることも可能）
- ネットワークサービス > Cloud NATを作成
app.yamlにサーバレスVPC設定を追記してデプロイ
# 前略 vpc_access_connector: name: "projects/<** project id **>/locations/<** region **>/connectors/asia-northeast1-connector<** connector name **>" egress_setting: all-traffic # 後略
参考
下記はApp EngineではなくCloud Functionの例ですが、やることはほぼ同じです。
www.isoroot.jp
現実的な課題
VPCアクセスコネクタを作るとき、推定料金が表示されます。
これ何かというと、VPCアクセスコネクタはスペックに応じてCompute Engineと同等のコストがかかるということです。しかも、その最小インスタンスは2以上、最大インスタンスは最小インスタンスより大きい数（つまり最低でも3）を設定しなければいけません。ここが、推定料金にもある通り、$15〜$23のようですから、なるべく低コスト・ノーコストで実装したい身としては重めのコスト負担になってきます。
結局、私個人としては、この”正しい”解決法は諦め、Compute Engineで実装しました。Compute Engineも使うときだけ動かせば、かなりの低コストで済むのです。もちろん、GCEのディスクの使用料は必要ですが、それでもVPCアクセスコネクタ（最低でも e2-micro×2台）ランニングコストに比べればかなり安上がりです。
感想
今回は、結構苦労して解決した割には、お金の都合でボツになってしまって残念でした。
