こんにちは。インフラ/バックエンド担当の森井です。
皆さんは普段からCDNを活用していますか？ CDNという技術は有名ですが、きちんと勉強する機会はあまり多くないのではないでしょうか。 この記事では、フロントエンド/バックエンド/インフラ全ての領域で意識する必要があるシステム設計の重要技術、CDNについて解説します。
この記事は「Web エンジニアなら知っておきたい」というシリーズの2回目の投稿です。
前回の記事はこちら。 engineers.fenrir-inc.com
CDNとは？
CDNは、Contents Delivery Network（コンテンツ配信ネットワーク）の略称です。 CDNを利用することで、世界中に分散して配置されたサーバー群からキャッシュしたコンテンツを配信することが可能になります。
CDN導入前後のイメージを用意しました。 オレンジ色のサーバーがオリジンサーバー、青色のサーバーがCDNのサーバー群（エッジサーバー）です。 オリジンサーバーは大元のコンテンツを保持している配信元サーバーのことです。
このように、CDNを使用するとエッジサーバーを世界中に展開することができます。
CDNを使用すると、ユーザーのリクエストはまずCDNのエッジサーバーに到達します。
ここでリクエストされたコンテンツの有効なキャッシュがある場合は、キャッシュされたコンテンツをレスポンスします。
有効なキャッシュがない場合は、エッジサーバーがオリジンサーバーにリクエストしてコンテンツを取得し、ユーザーにレスポンスします。
有名なCDNサービスには以下のようなものがあります。
大別すると、クラウドベンダーが数あるサービスの一つとしてCDNを提供しているパターンと、CDNを専業で提供しているパターンに分かれます。
CDNを利用するメリット
CDNを利用するメリットは主に3つあります。
Webサイトの遅延軽減
普段Webサイトを閲覧しているときにはあまり意識することはありませんが、サーバーへの物理的な距離によって通信に必要な時間は変化します。つまり、あなたが現在東京にいる場合、東京でホストされているサーバーに接続する時間は比較的短いですが、ブラジルにあるサーバーに接続する時間は比較的長くなります。*1
地理的に近いエッジロケーションからキャッシュされたコンテンツを配信することで、Webサイトの遅延を軽減することが期待できます。
オリジンサーバーの負荷分散
CDNを使わずに全てのHTTPリクエストをオリジンサーバーからレスポンスすることは可能ですが、リクエスト数が増えるに従ってサーバーの負荷も増えていくことになるでしょう。
CDNのエッジサーバーからキャッシュされたレスポンスを返却することで、オリジンサーバーの負荷を軽減することができます。オリジンサーバーの負荷を軽減することでWebサイトの信頼性が向上するほか、ランニングコストを削減することにもつながります。
セキュリティの向上
CDNを使用している場合、ユーザーからの通信の相手はCDNのエッジサーバーになります。CDNを利用することで通信のセキュリティ対策をCDNサービスに委任することができます。
Webサイトの開発チームが常に最新のセキュリティ対策を適用するようチームを組成することは現実的ではありませんが、CDNサービスでは専業のセキュリティチームが最新手法を調査し対策してくれていることが多いでしょう。*2
また、DDoS対策としても有効です。コンテンツはエッジサーバーから配信されるため、DDoS攻撃を受けた際のオリジンサーバーの負荷軽減が期待できるほか、DDoS対策の機能を提供しているCDNサービスもあります。*3
CDN活用パターン
CDNの活用パターンは3つに大別できます。
静的コンテンツ配信
静的コンテンツ配信は、CDNの最もよく活用されるパターンでしょう。 動画や画像ファイル、HTML/CSS/JavaScriptなど様々な静的コンテンツを配信することができます。 この場合、オリジンサーバーはS3などのオブジェクトストレージが選ばれることが多いと思います。
動的コンテンツ配信
CDNは動的コンテンツ配信にも利用することができます。 配信する動的コンテンツは、APIサーバーのJSONなどが多いと思います。
エッジでのコード実行
近年はエッジロケーションでコードを実行することもできてしまいます。
などのサービスが有名どころでしょうか。
「コード実行して何するんだ？」という疑問が浮かんだでしょうか。Cloudflareのページに活用例のサンプルが掲載されているので、興味ある方は見てみてください。
また、Honoなどエッジで実行することを想定したフレームワークなども出てきています。 筆者も以前ブログで紹介したことがあります。
CDNを利用するときに気をつけるポイント
最後に、CDNを利用する際に気をつけた方が良いことをご紹介します。
アウトバウンド通信量が多い場合はコストに気をつけよう
CDNに限らずですが、インフラ系のサービスではデータ通信量が課金対象になっていることが多いです。*4 例えば、CloudFrontのアウトバウンド通信はGBあたり0.114 USD*5です。
動画などサイズの大きいコンテンツを大量に配信する場合は、必ず事前にランニングコストの見積もりをしましょう。
秘密情報をキャッシュしないように気をつけよう
これもCDNに限りらずですが、"キャッシュ"は強力な解決策になる一方で、意図していないデータをキャッシュしてしまう危険性も孕んでいます。 CDNのキャッシュによる大規模インシデントだと、メルカリ社の事例などがあります。
このような事態を避けるために、動的コンテンツ配信ではそもそもキャッシュ機能を使わない、キャッシュ可能なコンテンツとキャッシュしないコンテンツを明示的にパスを分ける、などの設計上の工夫もできるでしょう。細心の注意を払って設計し、入念に試験しましょう。
単一障害点になることを理解した上で使おう
単一障害（single point of failure、SPOFとも呼びます）とは、その箇所が動かないと、システム全体が障害となるような箇所を指します。 システム設計では単一障害点をできるだけ排除することが重要ですが、CDNは単一障害点になってしまいます。
絶対に落ちないシステムはありません。CDNもいつかどこかで落ちます。 有名CDNサービスが大規模障害が起きると、世界中の様々なサービスが利用できなくなり阿鼻叫喚の状態になります。2021年のFastlyの障害は記憶に新しいですね。
CDN障害時のシステム停止システムが利用できなくなることを認識した上で導入しましょう。
ちなみに、CDN障害時のシステム停止を許容できない場合は、マルチCDNという選択肢もあります。これは複数のCDNをDNSベースで切り替えるものです。 ただし、CDNサービス間の挙動の違いや切り替えの動作確認など入念に準備する必要があります。
おわりに
今回は、CDNについて解説しました。 次回の「Web エンジニアなら知っておきたい」もお楽しみに。
*1:リクエストを開始してからレスポンスを得るまでにかかる時間をRTT（ラウンドトリップタイム）と呼びます。このRTTをいかに短縮できるかがWebサイトパフォーマンスに大きな影響を及ぼします。
*2:Cloudflareのブログを訪れるとセキュリティチームの様子を伺うことができます。The Cloudflare Blog
*3:例えばAWSではAWS ShieldというDDoS保護サービスを提供しています。AWS Shield（マネージド型の DDoS 保護）| AWS
*4:Cloudflareはアウトバウンド通信料金がかからないようです。CloudflareのブログにはAWSを名指しで批判する記事が掲載されていたりします。 AWS’s Egregious Egress
*5:記事執筆時点。日本リージョン、最初の10TBまで。最新情報は公式ページを参照してください。料金 - Amazon CloudFront | AWS
