☁️
Misskeyで使うCDNにCloudflare以外の選択肢はあるのか

2025/12/10に公開
これはMisskey Advent Calendar 2025 10日目の記事です。
みなさんこんにちは、Misskeyサーバー Polestarの鯖缶をしているSoliです。

今回は、Misskeyで使うCDN、とりわけCloudflare以外の選択肢はないのかという点と、一つの選択肢としてAWS CloudFrontを採用した例について紹介します。

 はじめにまず、Cloudflareで十分です！読んでいただきありがとうございました！
…となりたいところです。実際、9割のサーバーではCloudflareで問題ないでしょうし、現状PolestarでもCloudflareに”戻し”ました。

Misskeyにとって必要なCDNとしての役割を十分に果たしています。
しかし、なぜCloudflare以外の選択肢を考えるに至ったのか、それはCloudflareの品質低下という事象が発生していたためです。

 Cloudflareの品質低下2025年8月の半ば、21時過ぎになるとMisskeyが非常に重くなるという事象が自分含め、多くのユーザーから報告されました。

この重さはフロントエンド・バックエンドの両方に影響し、もはや使うことができないレベルでした。

最初はMisskey本体やDB, サービスホストの問題を疑いましたが、ログやメトリクスを確認しても全く重くなっていないことがわかりました。
となると、次に疑うのはCDN、Cloudflareです。

Cloudflareのステータスページを確認しても特に障害は発生していませんでしたが、Cloudflareを経由しない直アクセスでは問題が発生していないことから、Cloudflare側の問題である可能性が高いと判断しました。
また、以下にUptime Kumaによって収集していたレスポンスタイムを示します。

Spotify NowPlayingというのは自宅K8s上で動かしているWebアプリケーション、MisskeyはXserver上で動かしています。

バックのホスト関係なく、同じような時間にレスポンスタイムが跳ね上がっていることがわかります。


Misskeyのレスポンスタイム


Spotify NowPlayingのレスポンスタイム
この時点でCloudflareが原因であると確信しました。

 Cloudflare以外のCDNを検討ゴールデンタイムにMisskeyが使えなくなるほどに重くなるのは致命的です。もう我々にとってMisskeyなしの生活は考えられません。
CDNを使わない選択肢もありますが、Misskeyのパフォーマンス・セキュリティリスクを考えるとCDNは必須です。
そこで、Cloudflare以外のCDNを検討することにしました。

CDNというとそれなりに選択肢がありますが、Misskeyで使うに当たっては一つ重要な要件があります。
WebSocketをサポートしていること
これです。WebSocketのないMisskeyはMisskeyにあらず、なぜなら自動更新が使えないからです。

この要件があるため、(個人が使える範囲での)CDNの選択肢はかなり限られてしまいます。

ここでいう個人が使える範囲とは、主に価格体系の面です。
そして、そのようなCDNがどれだけあるかというと、以下の3つになります。
Cloudflare
AWS CloudFront
Gcore
なお、Gcoreについては試験的に使おうとしましたが、証明書周りの設定がうまくいかず断念しました。

結果として、AWS Cloudfrontのみが選択肢として残りました。

 MisskeyでCloudFrontを使うそれでは、MisskeyでCloudfrontを使うためのセットアップを行いましょう。

まずはCloudfrontのディストリビューションを作成します。


ディストリビューションの作成
次に、オリジンの設定を行います。

ここではAWS関係のないVPSと仮定して進めますので、Otherを選択します。


オリジンのコンフィグ
また、キャッシュの設定を推奨のものからいくつか変更します。

Cache settingsのCustom origin settingsを選択します。
HTTPメソッドでPUT, POST, PATCH, DELETEを有効に
キャッシュポリシーをUseOriginCacheControlHeaders-QueryStringsに変更
オリジンリクエストポリシーをAllViewerに変更
アバターやカスタム絵文字がクエリ文字列で個々のリソースを識別しているため、クエリ文字列をキャッシュキーに含める必要があります。

また、AllViewerにすることで、ヘッダーがすべてオリジンに転送されるようになります。


オリジンのカスタムコンフィグ
最後にWAFの設定を尋ねられます。EDoS攻撃対策には必要不可欠ですが、ここでは無効とします。

本番運用する際には有効にしてください。レートレミットやBOTブロックなどが行えます。
これで進むと、ディストリビューションが作成されますが、最後に一つだけ設定を追加します。

ビヘイビアタブから新規作成を選択し、APIエンドポイント(/api/*)に対してキャッシュを無効化します。
パスパターンを /api/* に設定し、キャッシュポリシーを「CachingDisabled」に設定します。


APIエンドポイントに対するキャッシュを無効化
最後に、一般タブに表示されているディストリビューションドメイン名を、お使いのDNSでMisskeyのドメインのCNAMEレコードとして設定します。

これでCloudfrontの設定は完了です。

 Cloudfrontを使った感想Cloudfrontを使った結果、レスポンスタイムがかなり速くなりました。

Cloudflareで問題が発生していないタイミングよりも速く、体感でも非常に快適です。


Cloudfrontに切り替えてからレスポンスタイムが高速かつ安定している
AWSを使うに当たって一番気になる点はコストだと思います。月の半分以上を使っていた9月のコストと使用料のグラフは以下の通りです。

Cloudfrontは月に1TBの転送量、10,000,000リクエストまでは無料なため、CDN自体の課金は発生しませんでした。

念のためWAFを有効にしていたため、WAFの使用料に対する課金が発生していた状態です。


AWS Cloudfrontのコスト
転送量とリクエストは日当たり大体300MB、40,000リクエスト程度だったので、かなり余裕があります。

小規模なMisskeyサーバーであれば、Cloudfrontは無料で使える可能性が高いです。


AWS Cloudfrontで配信されたコンテンツのサイズ


AWS Cloudfrontに対するリクエスト数
レスポンスが速く、安定していることは非常に快適でした。

これと引き換えに、突発的なリクエストの増加でを杞憂して高額請求を毎日案じていました。鯖缶の精神衛生には良くなかったです。
なお、11月18日にAWS Cloudfrontの定額プランがリリースされました。精神衛生上良い使い方が出来るようになりますね。
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-flat-rate-pricing-plans/

 Cloudflareに戻すCloudfrontを利用しつつ他のCDNを模索していましたが、最終的にはCloudflareに戻しました。

Cloudflareを介したサービスの外形監視も続けていたのですが、9月下旬になってレスポンスタイムが安定するようになっていたためです。
Cloudfrontは非常に快適でしたが、Cloudflareが
無料であること
機能の豊富さ(しかも無料)
その上で設定のしやすいUI
情報量の多さ
などを考慮すると、やはりCloudflareが最適解であると判断しました。
Cloudflareが無料で何もかも使わせてくれるのは非常にありがたいことです。従量課金に怯えることもありません。

 おわりに今回はMisskeyでCloudflare以外のCDNを検討した話と、AWS Cloudfrontを使った例について紹介しました。

Cloudflareは非常に優れたCDNですが、万が一の事態に備えて他の選択肢を知っておくことは重要であると考え、このような記事を書きました。(この記事11月頭にはもう書き終わっていたのですが、まさか本当に万が一の事態が起きるとは思わないじゃないですか)
Cloudflareが安定して動作し続けてほしいと思いつつ、他の手頃なCDNがWebSocketをサポートしてくれると選択肢も増えるので嬉しいなと思います。
今回は以上です。ありがとうございました。