Cloudflare は現在120か国、320都市以上に500を超えるエッジデータセンターを保有しています。これらはIP Anycast という技術を用いて同じIPアドレスでその時点でのユーザーから一番近いエッジを判別しています。 また技術的に必然性のある場合を除き、全てのエッジの全てのサーバで全ての機能を動作させるというのが基本設計です。 このブログサイトでは今までCloudflareの様々な機能をテストし手順としてまとめてきており、非常に多くの機能が存在していることをお分かりいただけたかと思いますが、パブリッククラウドと異なりそれらの機能は可能な限り内部ルーティングなしで動作するように設計されており非常にモノリシックです。このため、ユーザーはどこにいても一番近いエッジと自動で通信が確立され同じ機能が提供されることになります。ゼロトラスト系のサービスを使う場合これはセキュリティと通信速度

この記事は、「HTB Development Team with Friends Advent Calendar 2023」の12月７日分の記事です。 副題は「副題：三浦さんとCloudflareとCache Eviction（と大栗さん）」です。 今年三浦さんとの付き合いといえば、Cloudflare Meet-upを1月に立ち上げてもらったことと、お仕事でも付き合いがあったことです。 肝煎りコンテンツの新作動画配信でCloudflareを採用してもらいました。 完全なる従量課金ではなく、１年間毎月新作公開をしても予算を超過しないという思い切った提案となりました。クラウドの従量課金は素晴らしい考え方であることは事実ですが、企業全体がまだデジタルに造詣が浅い場合、様々な試行錯誤とコストが連動するため、確定効果が見込めないものは承認がされないケースなどが考えられます。せっかくならデジタル領域

CloudflareはWaiting Room/待合室という機能を提供しています。これは、高負荷が予測されるウエブサイトに対して、その前段に待合室というものを作成し、順次アクセスしてきたユーザーを順番にオリジンウェブサイトにリダイレクトしてあげる機能です。これを用いることで設計を超える急激なユーザーのアクセスをHTTP500エラー等を出力することなく捌くことが可能となり、ユーザー全体の体験を向上させることが可能です。 勿論、多くのユーザーは待ち時間を経験することになります。本質的にはウェブサイトはクラウドのAuto Scalingや例えばAmazon Aurora等のクラウドネイティブデータベースを用いることで、同時処理可能数を引き上げることが本質的な解決となりますが、アプリケーションによってはセッション管理がAuto Scalingに対応していなかったり、そもそもクラウドで動作していない