動画配信用のプラットフォームを格安で作る（インフラ編）
記事概要
先日、AniSwipeというショートアニメ専用プラットフォームをApp Storeに公開しました。
AniSwipeは縦スワイプで次々にショートアニメを楽しめるアプリです。個人からプロまで多彩な作品を手軽に視聴・応援できるプラットフォームを目指しています。本アプリの開発にあたって、「AIネイティブで作ること」「インフラコストを極限まで抑えること」に徹底的にこだわりました。このチャレンジの結果として、一定の成果を得られたと考えます。以下はそのサマリとなります（※どちらも超概算です。ご容赦ください）
- AIネイティブに実装することで開発コストは従来の10〜20%未満に抑えられる
- マルチクラウド戦略で動画配信プラットフォームのインフラコストは1〜25%未満に抑えられる
本記事では、どのようにAniSwipeのインフラコスト抑制を図ったかに焦点を当てて執筆します。AIネイティブの実装については後日執筆します。
もし、AniSwipeというサービスに興味を持たれた方、もしくはシステム開発やコンサルのお仕事を依頼したいという方はinfo@aniswipe.comまでご連絡いただければと思います。
開発経緯
普段は内資系コンサルファームで働いています。AniSwipeの開発はプライベートな時間を使って、2025年1月から開発をスタートしました。
AniSwipeの発案者は同僚のkiryoです。ショートアニメ専用のプラットフォームを作って、日本から世界にコンテンツを発信していきたいというアイディアに共感し、アプリ開発をスタートさせました。なお、kiryoはBiz側の人間なので、デザインを除いて一人で実装する必要がありました。
しかし、ユーザー投稿型の動画配信プラットフォームを個人開発で作るには開発工数・インフラ費用の観点で現実味がありませんでした。そこで、上述の技術的チャレンジを行い、2025年6月にアプリ公開にこぎ着けました。
インフラの想い
今でこそ私はフルスタック・フルライフサイクルのエンジニアですが、インフラエンジニアとしてのキャリアが長く、AWS資格は全て保有するAWSフリークだと自認しています。隙あらばLambdaやDynamoDBを中心としたサーバレスアーキテクチャを捩じ込むタイプのエンジニアでした。
しかし、AWSだけでAniSwipeを実装した場合のインフラコストは、個人開発でやっていくには許容できない費用見積となりました。また、将来的に国内のクリエイターに収益還元していくためには、貴重な原資を高額なAWS利用料に費やすべきではないと考え、エンジニア使命として徹底的にコスト削減にこだわりました。
インフラ構成と費用(vs AWSの一般的な構成)
AniSwipeのインフラ構成は以下の特徴を持っています。
- サーバーはCloudflare Workersでエッジ処理し、ユーザー体験を向上
- データベースは分散DBであるAurora DSQL (2025年5月GA)を採用し、将来の海外展開を視野
- 検索エンジンはCloudflare Vectroize(ベクトルDB) + Workers AI(LLM)を採用し、高速なセマンティック検索を提供
- 動画配信はegress転送料金が無料のCloudflare R2を利用
これらの技術選定は、コスト観点でも本サービスの生命線を担っています。いずれも従量課金制のマネージドサービスであり、利用していない間はほぼ課金が発生しないため、非常にコスト効率の高いアーキテクチャとなっています。
o3で超概算したところ、一般的なAWSの構成と比較して大規模想定の場合で25％未満のコストに抑えられました。更にCloudflare Enterprise契約に満たない小規模想定であれば、1％未満までコストを抑えられます。これはCloudflare R2のegress料金無料によるものです。
小規模想定の場合（MAU 5 万 / DAU 1 万）
| 機能 | AWS 構成 & サービス | 月額 (USD) | Cloudflare 構成 & サービス | 月額 (USD) |
|---|---|---|---|---|
| 動画配信 | CloudFront + S3 Standard | 16,894 | R2 + Cloudflare CDN (Free/Pro) | 21 |
| サーバー/API | Lambda + API Gateway (HTTP) | 127 | Workers (Paid Bundle) | 37 |
| データベース | Aurora Serverless v2 + RDS Proxy | 250 | Aurora DSQL + Hyperdrive | 47 |
| 検索エンジン | Amazon OpenSearch Service | 91 | Vectorize + Workers AI | 3 |
| エンコード | MediaConvert (Basic Tier, 3 renditions) | 56 | MediaConvert (同上) | 56 |
| 合計 | 17,418 | 164 |
大規模想定の場合（MAU 250 万 / DAU 50 万）
Cloudflare は Enterprise：帯域 $0.01/GB + 固定 $10 k 仮定
| 機能 | AWS 構成 & サービス | 月額 (USD) | Cloudflare 構成 & サービス | 月額 (USD) |
|---|---|---|---|---|
| 動画配信 | CloudFront + S3 Standard | 1,116,210 | R2 + Cloudflare CDN (Ent.) | 282,025 |
| サーバー/API | Lambda + API Gateway (HTTP) | 8,895 | Workers (Paid Bundle) | 2,701 |
| データベース | Aurora Serverless v2 + RDS Proxy | 2,852 | Aurora DSQL + Hyperdrive | 2,383 |
| 検索エンジン | Amazon OpenSearch Service | 816 | Vectorize + Workers AI | 209 |
| エンコード | MediaConvert (Basic Tier) | 3,750 | MediaConvert (同上) | 3,750 |
| 合計 | 1,132,523 | 291,068 |
インフラの創意工夫
以下、趣味と偏見で構成されています。ご容赦ください。
エッジ処理の導入とUX向上
開発当初は慣れ親しんだLambda + API Gatewayを利用していました。しかし、Lambdaのコールドスタートによりレスポンスが1秒を超えるため、アプリをぬるぬる動かすにはサーバレス構成では厳しさを感じていました。
そこで、ゼロコールドスタート可能なCloudflare Workersにサーバーを移行することにしました。結果として、データベースを使用しない場合（Hyperdirveのキャッシュ時含む）は50ms程度、使用する場合は500ms程度で安定してリクエストを返すようになりました。この差分は、CloudflareとAWS間の通信に起因しているものと考えます。
検索エンジンの選定
検索エンジンには当初、ElasticSearch (OpenSearch)を考えました。しかし、時間あたりでコストが発生するため、3環境分（本番・検証・開発）を用意するとなると高額なコストが発生します。
そのため、全文検索ではなく、ベクトルDBによるセマンティック検索を検討するようになりました。しかし、ベクトルDB選定に関する情報はまだ少なく、様々なサービス（Pinecone、Weaviate Cloud、Qdrant Cloud）を調査しましたが、コスト観点で完全な従量課金を実現するサービスは見つけられませんでした。Pinecone Severlessに期待しましたが、スケール時に利用料が高額となることが分かったので見送っています。
盲点だったのが、CloudflareがベクトルDBを提供していたことでした。エッジ環境でベクトルDBが動くと考えていなかったのですが、Cloudflare Vectorizeは完全な従量課金が可能で、レスポンスも早く理想的なベクトルDBでした。
またリコメンドエンジンとしても重要な役割を持っています。ユーザーベクトルから類似ユーザーを取得し、視聴履歴を元にリコメンドを作成します。
Vectorizeは開発体験も優れており、WorkersにVectorizeとWorkers AIをバインドすることで、簡単にセマンティック検索を実装することができました。Workersにバインドできるエコシステムは、LambdaからWorkersに乗り換えて良かったことの一つです。
IaCのツール棲み分け
マルチクラウドの管理は全てTerrafromで実施しています。唯一、Firebase AuthenticationはTerraformではGoogle認証などの設定が行えず、コンソールから実施しています。
Cloudflareを実装する以前は、Terraformに加えてCDKによるLambdaのデプロイを行っていました。ソースを自動でバンドルして、アプリをデプロイする体験はTerraformでは難しかったためです。結果として、TerraformとCDKが共存する不自然なリポジトリとなりました。
しかし、Cloudflare Workersに移行後は、アプリのデプロイは専用ツールであるwranglerに集約されました。wranglerはデプロイが高速でログ取得も簡単なため、非常に開発体験が良いです。その結果として、IaCツール群は以下のように整理されました。
- インフラ管理: Terraform
- アプリデプロイ: Wrangler
- DBスキーマ管理: Drizzle Kit (Drizzle ORM)
唯一Drizzle Kitに関しては、まだAurora DSQLに対応していないのが難点です。現状はSQLの自動生成だけ実施し、手動で適用しています。また、手動で適用する場合もAurora DSQL特有の制約に対応する必要があります。Drizzle KitがAurora DSQLに対応したら、私の中でIaCツール群は上記でFIXします。楽しみです。
終わりに
AWSのマネージドサービスは質量ともに圧倒的で、今後も主たるクラウプロバイダーの地位を継続すると思います。特にOffice365やAIをフックにエンタープライズでシェアを伸ばしているAzureには負けて欲しくないと心の底から思っています。
一方で、AWSを基盤に新たなクラウドサービスを提供するベンダーも増えており、様々なクラウドサービスを組み合せるマルチクラウド戦略の有効性とTerraformによるIaC管理の重要性は増していくと思います。
下記のブログでは、エッジに強みを持つCloudflareが中央集権的なデータセンターを持つAWSをレガシープロバイダーと定義しています。AWSをレガシー扱いする勇気もそうですが、記事内容自体も面白かったので共有します。
これらは単なる哲学の違いで、私自身AWSのことをレガシーとは全く思いません。しかし、AniSwipeの開発の過程で、これまでのAWSありきの技術選定ではなく、クラウドプロバイダーの特性を理解した技術選定の必要性を学ぶことができました。
Discussion