最先端の CDN とは何か、なぜその採用が必要なのか

多くの開発者や企業が、今日のユーザーと開発者が求めるダイナミックなエクスペリエンスの実現に必要なリアルタイムの可視性やビルトインセキュリティ、プログラマブルなコントロールを提供できない従来のブラックボックス型 CDN と格闘しています。

最先端の CDN は革新的なデジタルエクスペリエンスを生み出すのに必要なツールを開発者に提供し、このようなエクスペリエンスは顧客生涯価値やコンバージョン率、顧客ロイヤルティの向上や平均注文価格の上昇を促します。安全で競争力のあるサイトやアプリケーションの開発と維持に必要なツールを開発者に与えることがビジネスを成功へと導く鍵となります。

Fastly のエキスパートによるこのウェビナーの主な内容は以下のとおりです。

従来型 CDN の進化と老朽化する土台の上に築かれた CDN 業界の現状。

Gannett や Stripe など、ユーザーの期待に応えるためにそれぞれの課題を抱えた Fastly のお客様が実際に構築したアプリケーションの例を交えながら最先端の CDN がもたらすメリットを紹介。

最先端 CDN プロバイダーの選び方と従来型 CDN との比較において確認すべき固有の差別化要因 (例 : 投資利益を得る方法)。

このウェビナーをご覧いただくことで、ご利用の従来型 CDN を見直し、今日のユーザーや開発者向けに設計された CDN への移行を検討する必要があることがお分かりいただけます。

[Leigh Clancy] 皆さんこんにちは。ウェビナーにご参加いただきありがとうございます。本日は「最先端の CDN とは何か、なぜその採用が必要なのか」をテーマにしています。

このウェビナーでは、CDN の進化と現状に加え、実際のアプリケーションを例に最先端 CDN のメリットや最先端 CDN プロバイダーの選び方、確認すべきポイントについてご紹介します。ご質問がございましたらチャットの欄に投稿してください。できるだけ最後の Q&A セッションでお答えしたいと思います。それでは今回のスピーカーを務める Lee Chen をご紹介します。Lee Chen は Fastly の Corporate Development and Strategic Partnerships 部門の Vice President として、Fastly のメディア関連プロダクトのエグゼクティブスポンサーを務めています。Fastly にてプロダクト、マーケティング、パートナーシップの分野でさまざまなチームを統括してきた Chen は、メディアおよびエンターテインメント業界で20年におよぶ実績を持ち、インターネット経由でのライブ放送を開拓してきました。Fastly 入社前は、eスポーツ向けテクノロジー関連のスタートアップ企業を複数立ち上げました。それでは Lee、どうぞ。

[Lee Chen] ありがとうございます。皆さんこんにちは。本日はご参加ありがとうございます。早速スライドをアップしますね。皆さん、見えますか？ 本日はお集まりいただき、本当にありがとうございます。今回、最先端の CDN とは何か、なぜその採用が必要なのかというテーマについて深く掘り下げてお話する機会をいただき、何だかワクワクしています。Leigh のご紹介どおり、9年ほど前に Fastly に入社する前、私は幸いにもこの世界のインフラサイドだけではなく、消費者サイドと直接向き合う仕事にも従事し、キャリア面で恵まれていました。まずは通信会社で初期のブロードバンドアクセスを担当し、キャリアを開始しました。その後、創成期の eスポーツ分野でライブ放送に取り組み、リアルタイムのインタラクティビティを実現し、何百万人ものユーザーに対応するために eスポーツプラットフォームをスケールアップさせるうえで、さまざまな課題に挑戦しました。そして Fastly 入社後も引き続き非常に多様なユースケースでインターネットスケールの問題の解決に取り組み、素晴らしい経験を重ねてきました。そこで今回、これまで私が学んできたことの一部を皆さんと共有し、なぜそれが開発における現在のコンテキストにおいて重要かを説明できる機会が持てたことを、とても嬉しく思います。 

まず、最先端の CDN の進化について触れたいと思います。背景として、今回のテーマに非常に大きく関係しているためです。いくつかの興味深い実例を挙げながら最先端の CDN がもたらすメリットの一部について詳しくご紹介し、特有のユースケースに合った最先端の CDN を選ぶ方法についてお話ししたいと思います。そして、Fastly が素晴らしい選択肢のひとつである理由についても軽く触れますが、このセッションを通じて、大勢のユーザーに対応するためだけではなく、パフォーマンスやリーチ、セキュリティ、そして恐らく最も重要なコントロール性の向上に向けてアプリケーションを見直し、スケールする方法について何らかのインサイトを提供することができれば幸いです。また、今回のウェビナーは非常に幅広い対象者を想定しているうえ、何時間かけても話せるような大きなテーマを扱いますが、それは誰も望んでいないと思いますので、できるだけ簡潔な内容にしたいと思います。Leigh がご説明したように、ご質問がありましたら Q & A セッションに向けてチャットの欄にご質問をあげてください。必ず回答するようにします。

それでは早速始めましょう。

CDN が登場する前、企業はどうしていたのでしょうか。CDN がまだ存在しなかったインターネットの初期、特にアプリケーションやサイトのユーザーが分散するにつれ、またはこれらの人気が急速に高まるにつれ、多くの課題が発生しましたが、これらの課題は今日も存在します。最初にアプリケーションやサイトを構築する際、ほとんどの場合、世界中にコンテンツを安全かつ迅速に配信するのに役立つグローバルに分散されたエッジネットワークを使用しません。その結果、レイテンシの影響で読み込み時間が遅くなったり、地理的なシャーディングによってサイトに不具合が生じたりし、ユーザーエクスペリエンスが損なわれたりといった問題に遭遇します。こうした問題を解決するには、

自分たちでサイトまたはアプリケーションの複数のインスタンスを世界各地に立ち上げる方法がありますが、データセットをめぐって一貫性の問題が生じます。

CDN はこのような課題を解決するために誕生しました。初期の CDN は、ある意味、同じように機能していました。つまり、同じデータの複数のコピーを世界各地のキャッシュまたは POP (配信拠点) と呼ばれる場所に保存していたのです。サイトやアプリケーションのいわゆる静的コンテンツのコピーを保持するキャッシュを構築することで、若干優れたパフォーマンスが得られました。画像や動画、テキストといったコンテンツは実際、あまり頻繁に更新されないので、一貫性の問題はある程度緩和されました。しかし頻繁に変化する、特にログインステータスや主要ニュースサイトのホームページ、個人の Twitter フィードなど、ユーザーごとにパーソナライズされる動的コンテンツに関しては、それほど効果はありません。また初期のインターネットでは、ネットワークトポロジーも今とはだいぶ異なりました。初期の CDN が効果を発揮するには、配信拠点をネットワークのラストマイルに設置する必要がありました。

インターネットの規模と普及が拡大し、年を追うごとに日々のインターネット使用が飛躍的に拡大するなか、CDN の元のアーキテクチャが抱えていた問題もかさみ続け、CDN は対応に苦戦していました。インターネットのラストマイルに何十万ものキャッシュサーバーが置かれるということは、世界中で同じコンテンツの何十万ものコピーが存在することを意味します。そして、世界中に設置されたこれらのキャッシュサーバーのいずれかで、あるコンテンツ、例えば更新されたバージョンのホームページにアクセスされると、アプリケーションスタックはそのコンテンツをオリジンから取得する必要があります。従って、アプリケーションまたはコンテンツの人気が高いと、何百万人ものユーザーからのリクエストが、最新のコンテンツを取得するためにオリジンに殺到します。また、従来型アーキテクチャを採用している組織は、ご覧のように中間層キャッシュと呼ばれるものを実装し、その結果、数万のサーバーのみがラストマイルキャッシュのオリジンとして機能しますが、これらは依然として新しいコンテンツや更新されたコンテンツを取得するのにオリジンサーバーにアクセスする必要があります。さらに、リアルタイムコンテンツのニーズが高まっています。DevOps や継続的統合とデプロイの採用が普及しつつありますが、これらは開発フローの改善に加えて、イテレーションの高速化も目的としており、古いエッジアーキテクチャでは、このような要因が突きつける問題を解決するのがますます困難になっています。Web ページの古いコンテンツや失効済みコンテンツを保存するのは望ましくありません。どんどん古くなり、正確さに欠けるバージョンのコンテンツや API、もしくはそのようなエッジアプリケーションの使用は、さらに深刻な問題を招きます。ラストマイルのキャッシュや中間層キャッシュを使用しても、Thundering Herd が発生してオリジンにリクエストが殺到することがよくあるのです。そもそも、私たちが CDN エッジを導入したのは、縦横のスケール問題を解決するためでした。加えて、ボットや悪質なアクターなどが脆弱性を悪用したり、スクレイピングやさらに悪質な攻撃をしかけたりするなど、これらのアプリケーション等をめぐる状況は悪化しています。そこで、この図にはエッジで起きていることに関するオブザーバビリティや可視性が実際に欠けていることにご注目ください。ご存知のとおり従来型のアーキテクチャでは、24時間から48時間後にダンプファイルが提供されますが、これはリアルタイムで問題を診断したり、トラブルシューティングしたりするうえでまったく役に立ちません。

もうひとつこの図に欠けているのは、エッジで使用されているコンテンツを無効化する方法です。誤りのあるトップ記事や在庫数など、ビジネスやブランドにとって重要なコンテンツが誤りを含んだままインターネット上で使用されている場合、開発者は誤りを修正できるようにする必要があります。そこで Fastly の出番です。Fastly のような最先端の CDN では何が違うのでしょうか。まず、私たちは最後の1マイルではなく、インターネット上でトラフィックが集中する交差点に大容量の POP をデプロイしています。これは、世界中の異質なネットワーク同士が相互接続し、インターネットがひとつにつながる場所を意味します。これにより、CPU やディスク、ネットワークが集約され、キャッシュやコンピューティングの効率向上につながり、皆さんや皆さんの Web サイト、アプリケーションにより優れたコントロールと可用性をもたらします。Fastly の POP はインターネットの主要交差点に配置されているので、私たちのネットワークのレイテンシとパフォーマンスは従来の CDN と同じぐらい優れています。Citrix で公開されているサードパーティの統計データでこれをご確認いただけます。どなたかがそのリンクをチャット欄にドロップして全員で共有できると良いのですが。このような独立したサードパーティによる測定によって、私たち自身による測定数値ではなく、第三者が測定したレイテンシのメトリクスを確認できます。動的オブジェクトの配信を確認するのは、特定のエッジネットワークのレイテンシパフォーマンスを把握するうえで最も有効な方法のひとつです。Fastly の大容量 POP の高いコンピューティング密度により、設定スクリプトでの複雑なアプリケーションロジックの実行も、Compute での完全なアプリケーションの実行もすべてエッジで行い、アプリケーションやWebサイトにアクセスするユーザーのリクエストを処理できます。また、リクエストを共有するシールド機能により、何万もの中間層リクエストがオリジンに送信されることがなくなり、重複に対するシールドを有効にしている場合、1-2件のリクエストのみをオリジンで処理するだけで済む可能性があります。これにより Thundering Herd の発生を回避できます。セキュリティについては、リクエストをアプリケーションに送信する Web アプリケーション API をファイアウォールで保護できます。このファイアウォールは正当なユーザーと悪意のあるアクターを実際に識別できるので、ブロックモードで使用できます。API 経由でエッジプラットフォーム全体をコントロールできるので、開発ワークフローから直接プログラムでエッジプラットフォームにアクセスし、変更や更新を数秒で (数分や数時間かかることなく) グローバルに反映させることができます。また Instant Purge 機能によって平均150ミリ秒以下でコンテンツのキャッシュや無効化が可能です。このふたつを組み合わせることで、世界中のコンテンツのコピーのみでなく、コンテンツがレンダリングされる方法を定義するアプリケーションロジックもほぼリアルタイムでコントロールできます。さらに、前に触れた可視化機能も提供します。アプリケーションで実際に起きていることをほぼリアルタイムで可視化できるので、問題への対応やトラブルシューティング、分析が可能になり、業績やユーザーエクスペリエンスの向上を実現できます。単に基本的な内容のログがストリーミングされるのではなく、実際にログのほぼすべての側面をカスタマイズできます。特定の AB テストのトラフィックの中からユーザー ID を取得したい場合、Fastly のログにそれを含むことができます。特定の地理的地域に関するレイテンシのテレメトリが必要な場合、Fastly のログにそれを含むことができます。コンプライアンスのために監査証跡が必要な場合、Fastly のログにそれを含むことができます。しかも、すべて簡単にカスタマイズできるのです。これらすべての機能を合わせることで、最先端の開発環境に適した非常にパワフルなツールキットを得ることができます。つまり最先端の開発環境には最先端の CDN が必要なのです。

最先端の CDN とはどのような CDN なのでしょうか ? 前のスライドでさまざまな機能についてお話ししました。最先端の CDN は最低限これらの機能をすべて備えているべきですが、ここで特に強調したい重要なポイントは、最先端の CDN を開発プロセスの一部として統合できる必要があるということです。後付けされたり、開発プロセスの妨げとなったりすることがあってはなりません。実際に企業や開発者個人の目標達成をサポートするツールキットとして機能すべきであり、問題が発生してから緊急で導入するのはお勧めしません。最終的に、最先端の CDN によって開発チームはイテレーションとイノベーションを加速できるはずです。Google のページランキングのアルゴリズムではページの読み込み時間が測定され、これはレイテンシによって左右されます。キャッシュからいつでもコンテンツを配信できる状態にある最先端の CDN は高速かつパフォーマンスが高いので、自動的に検索ランキングも向上します。また、Google などの検索エンジンと緊密にネットワークがつながっている必要があります。前述のようにページランキングまたはレイテンシのメトリクスを使用して簡単にパフォーマンスを評価できます。エッジでコンテンツをカスタマイズし、エッジで AB テストを実行するユースケースも可能であるべきです。ユーザー入力に合わせて動的にコンテンツをレンダリングでき、なおかつユーザーエクスペリエンスの向上や収入の最適化に向けて調整を行うのに必要な可視性が提供されなければなりません。さらに、セキュリティがエッジでネイティブ統合されている必要があります。基本的なキャッシュ設定以上の機能を備え、アプリケーションロジックを含め、まさに本当の意味でアプリケーション全体をエッジで実行できなければなりません。必要な機能は他にもまだありますが、

ここで実例をいくつか見てみましょう。

Gannett は米国最大のニュースパブリッシャーであり、信頼できるローカルコミュニティの構築で知られています。USA Today のパブリッシャーと言えば一番お分かりいただけるかもしれません。パブリッシング業界では、最新のトップ記事やニュースを常に新鮮な状態に保つため、Fastly では Instant Purge と呼ばれる、キャッシュを無効化する機能が非常に重要です。150ミリ秒の速さでパージできる可能性を想像してみてください。簡単に言えば、Gannett は同社のオリジンサーバーの延長にある、ほぼリアルタイムで機能するグローバル分散ネットワークとして Fastly を使用しています。Gannett のホームページは動的に配信され、キャッシュできないとみなされるかもしれません。高度にカスタマイズされており、トップ記事をはじめ多くのコンテンツが絶えず更新されます。動的に配信されるということは、クラウドにあるオリジンサーバーから直接配信されることを意味します。Gannett は常に最新のニュースをアップしてトップ記事を更新する必要があるほか、ニュース速報の更新やコメントの投稿、「いいね」ボタンのクリックなどのイベントも実は動的な配信を必要とします。このようなイベントを特定し、API を通じてパージリクエストをトリガーするようプログラムすることができます。Instant Purge を利用することで、Gannett はこれを実現しました。これにより、アプリケーションロジックをエッジに移行させると同時に、インフラストラクチャへの負担を大幅にオフロードできたのです。その結果、設定をグローバルにプッシュするのにかかる時間が、以前のセットアップと比較して98.86%短縮されました。さらに、オリジンへのトラフィックを Fastly にオフロードすることで、データ送信コストを35%削減できました。

Stripe も私のお気に入りの事例のひとつです。年間数十億ドル規模の商取引を扱う同社は、フラッシュセールや繁忙期にまったく予測不可能なトラフィックスパイクを経験することがあります。Stripe のビジネスはセキュアであることはもちろん、高いパフォーマンスを必要とします。決済プロセスで遅延が生じると、同社の顧客の売り上げ損失につながり、Stripe の収入に直接影響する可能性があるためです。Stripe にとってトラフィックスパイクは日常茶飯事なので、スパイクに対応しながらエンドユーザーの決済手続きを処理し続けられる必要があります。  そのため、スケールしてスパイクを処理できるエッジプラットフォームを採用し、大量のリクエストがオリジンサーバーに殺到しないようにすることが非常に重要でした。これは、以前のプロバイダーから直に学んだレッスンでした。さらに「2秒ルール」というものがあり、ページの読み込みで遅延が2秒を超えるとユーザーがショッピングカートを放棄し、別のサイトでプロダクトを見つけようとする傾向があることが報告されています。つまり Stripe のパフォーマンスが遅いと、顧客は取引を失うことになるのです。従って Stripe は顧客の売り上げ損失を防ぐため、継続的にパフォーマンスを向上させる必要があります。そこで Fastly を自社のエッジアプリケーションプラットフォームに統合したところ、驚いたことに決済時間が80%も短縮し、カスタマーエクスペリエンスを劇的に改善することができました。

それではどのようにして最先端の CDN を選ぶべきでしょうか？ 購入する前に確認すべきポイントについて、こちらをご覧ください。左の欄は開発者のニーズに関するものです。前にも述べましたが、最先端の CDN は開発プロセスの一部として機能する必要があります。後から検討したり、後付けするものではありません。最初から CDN を活用することで開発チームや企業はさまざまなメリットが得られますが、開発チームにとって特に重要なのは、イテレーションとイノベーションを加速できることです。開発者が最初から CDN のメリットを上手に活かせることが理想的です。これにより、ビジネス課題の解決とユーザーエクスペリエンスの強化に専念できます。コントロール、可視性、標準へのコンプライアンスとサポート、そしてビルトインセキュリティを実現するプログラマビリティ、これらの重要な機能をすべて備えている CDN が必要です。中央の欄は、抱えているビジネスのニーズ、目標、目的を満たすために必要なものです。総保有コストは常に重要なポイントです。クラウドからのデータ転送によるコストへの影響や、EC2 での実行またはキャッシュアーキテクチャのサポートに必要なサーバーの数を確認することも、CDN を選ぶ際に重要です。最後に、購入前に試してください。昔と違い、今は購入前に試すことが可能です。サポートの質も評価する必要があります。最先端の CDN のような真のエッジプラットフォームは、ビジネスやスタックへの統合が可能です。個人的に私は取引相手として誇りに思えるパートナーやベンダー、お客様をできるだけ選ぶようにしています。

ここで、Fastly が誇る数字をいくつかご紹介したいと思います。Fastly のネットワークを約 200 Tbps までスケールアップさせながら、パージやグローバルデプロイにおいて高いパフォーマンスを維持しています。これは非常に大きな成果です。分散コンピューティングでこれを実現するのは容易ではありません。スケールアップさせながらも、すべてのパフォーマンス指標が向上し続けていることを私たちは非常に嬉しく思います。Fastly の Next-Gen WAF の場合、90%以上のお客様が完全にブロックモードで使用しています。これは、本物の正当なユーザーによるアクセスを拒否することなく、悪意のあるアクターやボットを実際にブロックできるという点において、お客様が Fastly を信頼していることを示しています。WAF をモニタリングモードで使用する場合、問題が発生してからそれに気付くことになります。完全なブロックモードで WAF を使用するということは、その WAF を支えているテクノロジーやセキュリティリサーチがワールドクラスであり、実際に悪者を捕まえ、本当に善良なユーザーが引き続きアプリケーションとやり取りし、購入に向けて決済手続きを行うことができると信頼できることを意味します。しかし恐らく最も重要かつ私たちが一番誇りに感じている数字は、私たちが心からお客様を大事にしていることを反映している数字です。私たちは誰もが人生のある地点で「客」の立場に立ったことがあり、客として自分がどのように扱われたいのかを本当に理解しています。そのため、「自分だったらこうして欲しい」と思うやり方でお客様に対応しています。お客様に関するこれらのメトリクスは、このような哲学に対する私たちの止むことのないコミットメントを反映しています。

それでは以上です。本日はご視聴いただきありがとうございました。では Leigh、よろしくお願いします。

[Leigh Clancy] ありがとうございました。始めにお伝えしたように、遠慮なくご質問を入力してください。今ここでご質問にお答えしたいと思いますが、それができない場合は、後でご連絡いたします。ですからどのような質問でも投稿してください。

[Lee Chen] 準備する間に画面の共有を止めますね。

[Leigh Clancy] 質問がひとつ上がったようです。他にもいくつかあるようですね。「開発者が完全にコントロールできる」というのはどういう意味ですか？もう少し詳しく教えてください。

[Lee Chen] とても良い質問ですね。ご存知のとおり、さまざまな形が存在します。コントロールを実現するには2つの要素が必要です。コントロールできるということは、設定を操作できる、すなわちキャッシュをコントロールするヘッダーやキャッシュに実際に存在するコンテンツを含め、最先端の CDN やエッジキャッシュテクノロジーでコントロールしたいさまざまなものを操作できることを意味します。従って設定にアクセスできる必要があり、ブラックボックスであってはなりません。Fastly では API またはコンソールを通じて設定にアクセスできます。実際には、コンソールが API をドッグフーディングしています。より重要なのは、変更を行った際にそれをグローバルに、トラフィックを運ぶすべてのノードに非常に高速に反映させられることです。グローバルデプロイ時間は13秒で、このように短時間で設定変更が世界中に反映され、ユーザーへの配信トラフィックにルールとして適用されます。コントロールに必要なもうひとつの要素は、何を変更するのか、なぜ変更するのかを判断できることです。ここで可視性の話に戻ります。実行しようとしている変更の影響をほぼリアルタイムで確認できない、変更がログや他の可視性ツールに反映されるまで何時間、または何日も待たなければならない場合、実際には役に立ちません。誤った設定変更を実行してしまった場合、サイトをダウンさせなかったとしても、例えばロゴを他のものに変えてしまった場合など、ブランドに影響しかねません。つまり、可視性とコントロールは共にリアルタイムであるべきであり、今日の開発者はリアルタイムが求められる環境で作業しています。そのため Fastly はリアルタイムの重要性を強く確信しています。

[Leigh Clancy] 次に、Web 標準やオープンソースソフトウェアに対する Fastly のサポートとは？

[Lee Chen] Fastly のスタックにはこれらへのサポートが複数レベルで内蔵されており、QUICK と HTTP3 をはじめ、さまざまな Web 標準が Fastly のプラットフォームでサポートされています。また、ITF などの標準化団体にも積極的に参加し、標準の策定にも貢献しています。さらに、オープンソースをサポートする非常に強力なプログラムも展開しており、私たちはこれを誇りに思っています。このプログラムを通じてオープンソースプロジェクト、コード、リポジトリのデリバリーをサポートしており、npm やその他の複数の主要パッケージが Fastly を通じて配布されています。このご質問の具体的なコンテキストは分かりませんが、Fastly のプラットフォームでは Web 標準がサポートされているのでそれらをご利用いただけますし、そのほとんどが docs.fastly.com で説明されてます。経験から学んだことや独自の視点に基づいて意見を提供することで、これらの標準の策定に貢献しています。オープンソースプロジェクトに関しては、オープンソースプロジェクトの使用に興味がある開発者がそれらを実際に使用できるように無料のデリバリーサービスをオープンソースプロジェクトに提供しています。

[Leigh Clancy] ありがとうございます。最後の質問はライブイベントなどに関連するもので、Thundering Herd などに対応するためにスケールするうえで、Fastly がどのように役立ちますか？ これについては少し触れましたね。

[Lee Chen] そうですね。個人的にこの問題を経験してきました。うまく行ったこともあれば、まったくうまく行かなかったこともあります。ライブイベントと Thundering Herd について考える際、真っ先に頭に浮かぶのはスーパーボウルです。毎年、何百万人もの人がアメリカンフットボールの頂点を決めるチャンピオンシップを視聴しようと集まります。つまり通常の週末とはかなり異なるのです。従ってこの4時間の間に何百万人もの人がこのひとつの動画ストリームにアクセスしようと殺到し、非常に大規模なトラフィックスパイクの問題が発生するのです。規模は数千 Tbps に上りますが、実際トラフィックスパイクはどのようなイベントでも起こり得ります。例えばコンテンツがバズると Thundering Herd の問題が突然発生します。ニュース速報でも Thundering Herd 問題が発生することがあり、必ずしも巨大でグローバル規模とは限りません。ごく一部の地域に限られる場合もあります。例えば竜巻の警告や、急に地元住民の高い関心を集めるような地域的な出来事の発生などが考えられます。CDN は元来、このようなトラフィックの急増に対応できるようにするために設計されています。単に分散化の問題だけではなく、キャッシュのコピーを保存することによって生じる縦横のスケーリングの問題もあります。すべての CDN がこのような問題に対応できるはずですが、特に最先端の CDN はオリジンを過負荷の状態にすることなくトラフィックスパイクに対応する能力に優れています。ここで、最後のコンポーネント、「シールド」と呼ばれる機能について触れておきたいと思います。これは、エッジですべてのトラフィックに対応するというコンセプトに基づく機能です。Fastly によってエッジキャッシュまたはシールド POP を通じてコンテンツの新しいコピーを配信できるので、実際にオリジンに送信されるリクエストは1-2件で済みます。従来型の CDN ではこのようなメリットは得られません。これらの CDN は何千もの中間層キャッシュで構成されており、これらはオリジンと通信してコンテンツを取得し、それをエッジにプッシュする必要があります。その点、Fastly のアプローチは、特に大規模なトラフィックスパイクが発生した場合に大きなメリットがあります。

[Leigh Clancy] ありがとうございました。これが最後の質問だったようです。今回ご参加いただいた皆さまにもお礼を申し上げます。貴重なお時間をいただき、本当にありがとうございました。本日のウェビナーの録画へのリンクをメールにてお送りします。Fastly を実際に試してみたい方は、fastly.com/jp にアクセスし、「Fastly 無料トライアル」のボタンをクリックしてください。改めて本日はどうもありありがとうございました。どうか良い一日をお過ごしください。

[Lee Chen] 皆さん、ありがとうございました。ご参加、感謝します。それではどうぞお元気で。