10:00カテゴリ:AWS,CDN,技術こんにちは、MSP事業部エンジニアリンググループの佐藤です。Webサービスを運営していく中で、パフォーマンス改善等々でCDN(コンテンツ・デリバリー・ネットワーク)の導入を検討することは多々あるかと思います。CDN事業者が提供する分散されたエッジサーバーを介してコンテンツ配信をすることで、Webサーバーやアプリケーションの負荷を軽減したり、DDoS攻撃対策などのセキュリティ面での効果が期待できたりします。効果的に利用するためにはCDNのキャッシュをうまくコントロールする必要があり導入に二の足を踏んでいる人もいるのではないでしょうか。私は前職で大規模なWebサイトの運営・運用に携わっていました。その中で、Webディレクターなど技術に精通していない運用者たちとも多く話す機会がありました。更新したはずなのにコンテンツになかなか反映されなかったりしてコンテンツ運用をむずかしくしてしまうという側面がCDNにはあります。これが彼らはこわく感じてしまうようです。CloudFrontを題材に、次のようなゴールを目指してお伝えしていきます。CloudFrontを導入するにあたってWebディレクター向けに説明した内容を元にしています。経由してデータを配信することで、自動化されたネットワークマッピングとインテリジェントなルーティングにより、レイテンシーを低減します。攻撃を防御することができます。オリジンからのデータ転送にかかる費用をゼロにすることで、コストを削減。エッジで実行するコードを、サーバーレスコンピューティング機能を使ってカスタマイズし、コスト、パフォーマンス、セキュリティのバランスをとることができます。以上をざっくりと要約すると、以下のようになります。レイテンシーが低減し、パフォーマンスが向上する450以上のPoPを経由することで可用性が向上するセキュリティが向上するAWSの他のサービスに組み合わせることでコスト削減効果が見込めるサーバーレスコンピューティングが活用できるなお、こちらの情報は当記事執筆時点(2023年3月31日)での情報となります。PoPの数は年々増加しています。私が把握している限りでは2020年3月の時点では216だったので、3年で倍以上に増えていることになります。2019年3月14日に公開されている最新のサービスレベルアグリーメント(SLA)は月間稼働率99.9%以上ということです。詳細については公式のドキュメントを参照ください。キャッシュとはキャッシュとは一度読み込んだ内容・情報を一時的に保存しておき、再利用できるようにする仕組みおよびそのデータのことを指します。英語では「Cache」と書き、現金を意味する「Cash」とはつづりが違います。CloudFrontに限らず、CDNを利用したWeb配信におけるキャッシュには大きく以下の3つが登場します。ブラウザキャッシュブラウザがすでに取得済みのデータを一時的にデバイス上に保存したもの。次に同じページにアクセスした際、参照することで表示を早くしたり通信量を削減させたりします。ブラウザの強制リロードで削除ができるキャッシュはこちらになります。アクセスさせるたびに内容が変更になるような動的なコンテンツに対してはキャッシュをさせないようにするなど対策をするべきです。エッジキャッシュCDNのエッジサーバーがすでに取得済みのデータを一時的にエッジサーバー上に保存したもの。オリジンとなるWebサーバーに代わってブラウザにレスポンスすることで、Webサーバーや関連するシステムの負荷を下げたり、地理的にブラウザにより近い場所からすばやくデータを届けることで表示を早くします。アクセスさせるたびに内容が変更になるような動的なコンテンツに対してはキャッシュをさせないようにするなど対策をするべきです。更新が反映されることに時間差が許容できるのであればキャッシュさせることで上記の利点を享受できます。逆にこのエッジキャッシュをうまくコントロールできていないと「サイトを更新した、ブラウザも強制リロードした、なのに表示に反映されない」の原因になります。サーバーキャッシュオリジンとなるWebサーバーが過去に作成したデータを一時的にサーバー上に保存したもの。Webアプリケーションの実行頻度を減らすことでWebサーバーや関連するシステムの負荷を下げたり、アプリケーションの実行をスキップすることですばやくデータを届け表示を早くしたりします。一般的にはデフォルトでは一切キャッシュしないので明示的に設定をすることになります。キャッシュさせる場合の注意点はエッジキャッシュと同様になります。CloudFrontのエッジキャッシュについて説明していきます。エッジキャッシュには大きく以下の3つの状態が存在します。キャッシュが存在しない有効なキャッシュが存在する無効なキャッシュが存在するこのうち無効なキャッシュとは有効期限(TTL)が切れたキャッシュのことを指します。CloudFrontの振る舞い※以下は簡素化して記載しているため詳細な振る舞いを知りたい場合は公式ドキュメントを参照してください。キャッシュが存在しない場合クライアントからリクエストがあるとエッジサーバーは以下の振る舞いをします。CloudFrontに設定された条件に従ってオリジンサーバーにリクエストを転送しデータを取得する取得したデータをクライアントにレスポンスする取得したデータを設定された条件に従ってエッジサーバーが保持(キャッシュ)する有効なキャッシュが存在する場合クライアントからリクエストがあるとエッジサーバーは以下の振る舞いをします。リクエストを受け付けたエッジサーバーは近くのエッジサーバー(リージョナルエッジサーバー)にキャッシュの有無を確認する自分自身にキャッシュがある場合はそのままレスポンスするキャッシュを持っているエッジサーバーにリクエストを転送しデータを取得する取得したデータをクライアントにレスポンスする取得したデータを設定された条件に従ってエッジサーバーが保持(キャッシュ)するこの状態が多くなることを「キャッシュヒット率が高い」といいます。CDNの運用をする場合、なるべくキャッシュヒット率が高い状態を目指すことが費用対効果を最大化するうえで大きな指標のひとつとなります。無効なキャッシュが存在する場合クライアントからリクエストがあるとエッジサーバーは以下の振る舞いをします。OK)取得したデータをクライアントにレスポンスする取得したデータを設定された条件に従ってエッジサーバーが保持(キャッシュ)するエッジキャッシュの確認方法ここまででエッジキャッシュの状態についてはおおむね理解できたのではないでしょうか。CloudFrontのエッジキャッシュから取得したものであるかどうかは以下のレスポンスヘッダを確認することで判断できます。ブラウザの開発者ツールなどで確認できますが、ここではその詳細には触れないので必要であれば別途調べてみてください。CloudFrontのキャッシュ条件の設定について紹介します。キャッシュの持ち方をコントロールすることで、キャッシュ効率を高くしつつ、運用しやすいWebサイトを構築できます。CloudFrontのキャッシュ条件はパスパターンをキーとします。CloudFrontディストリビューションにつき最大で250パターンまで設定できます。パスにはワイルドカードを使用でき、大文字/小文字は区別されます。正規表現は使えません。パスパターンの最大長は255文字となります。各パターンに対して以下のような要素を対象にキャッシュの管理を区別できます。有効期限が満了していないエッジキャッシュも個別に削除可能です。コーポレートサイトのロゴ画像など、ほとんど更新しないファイルは一般的にはTTLを長く設定してキャッシュヒット率を最大化します。このようなときに「ロゴデザインが変わったので差し替えたい!」といったケースなどで利用します。指定できるのはパスパターンのみで、キャッシュの条件のキーと同様にワイルドカードが指定できます。クエリ文字列を転送する設定の場合、パスパターンにはクエリ文字列も含める必要があります。先程の例だと、/item/と/item/?id=1と/item/?id=100はそれぞれ別のパスパターンとなります。ワイルドカードを利用して/item/*を指定することでまとめて削除できます。削除のパフォーマンス(速度など)に対するSLAはないので、必ずしもすぐに消えるわけではないようです。削除リクエストは指定したパスパターンごとに課金が発生するため、うまくキャッシュを管理してなるべく個別の削除は行わない設計をすることが大事です。最後にCDNのキャッシュは、実装するインフラエンジニアやバックエンドエンジニアだけでなく、マークアップエンジニアやWebディレクターも一緒に設計し、一緒に運用することで効果が最大化できます。株式会社ハートビーツの技術情報やイベント情報などをお届けする公式ブログです。こちら「みんな仲良く」「プライドを持って」「変化を楽しむ」という企業理念に共感していただけるエンジニアを募集しています。