DE{CODE}: エッジがエッジ ケースではない理由

エッジにいるときは、速度、セキュリティ、およびサーバーの状態を後付けすることはできません。 このセッションでは、Cloudflare VP of Product Sergi Isasi と WP Engine プロダクト マネージャー Pavan Tirupati が、構築または維持する各 Web サイトの成功にエッジ ファーストの考え方が不可欠である理由について説明します。

セッションスライド

全文トランスクリプト

PAVAN TIRUPATI : 皆さん、こんにちは。 年齢が実際にはエッジケースではないことについて、このセッションにご参加いただきありがとうございます。 The Outreach チームの WP Engine のプロダクト マネージャーである Pavan Tirupati です。エッジのセキュリティ、パフォーマンス、信頼性を主に担当しており、WP Engine の顧客を成長させ、力を与えています。

本日、Cloudflare から製品管理担当副社長の Sergi が加わりました。 セルジさん、自己紹介をお願いします。

SERGI ISASI : わかりました。 私を迎えてくれてありがとう、パヴァン。 そして、セッションに参加してくださった皆様、ありがとうございました。 Pavan が言ったように、私は Cloudflare でアプリケーション パフォーマンスの製品担当副社長を務めており、エッジのパフォーマンスと信頼性に重​​点を置いています。 私たちは、すべてのお客様のために物事を迅速かつ信頼できるものにしたいと考えています。 私がカバーする製品は、Cloudflare がエッジでトラフィックを受信して​​処理する方法、つまりレイヤー 4 と 7 の両方です。これには、キャッシュ、プロキシ、FL スペクトル、DNS システム、証明書管理システムなどの Cloudflare の基本的なテクノロジーが含まれます。 IP アドレス管理システム、そして新しいエッジ アプリケーション、つまりロード バランシング、最新の Waiting Room 製品、そして今後の Web3 製品です。

私は Cloudflare に約 4 年半在籍しています。 繰り返しになりますが、今日ここにいられて幸せです。

PAVAN TIRUPATI: 素晴らしい。 そして今日は、エッジとは何か、それがどのように役立つのか、そしてタイトルが示すようにエッジがもはやエッジ ケースではない理由について深く掘り下げる素晴らしいセッションを皆さんに提供します。 私たちが皆さんに提供する議題は、エッジとは何か、そしてそのメリットは何かをより深く掘り下げることです。 そして、これらの時代を考えると、セキュリティにもっと集中することが重要です.

そして、いくつかの例について話し、いくつかのセキュリティ上の脅威について話します. また、ここにいる視聴者や世界中のデジタル プレゼンスを持つすべての人にとって、エッジがどのように役立つかについても説明します。 また、これらのセキュリティの脅威や問題を経験している可能性のある人々にとって有益な具体例もいくつか見ていきます。

刺激的で機知に富み、洞察に満ちたものになるでしょう。 それでは、ここでいくつかのコンテキストを設定することから始めましょう。 エッジとは何かのベースラインを設定したいと思います。 また、企業がビルダー文化への移行を経験していると言っても、誰にとっても驚くことではないと思います。ビルダー文化は、デジタル エクスペリエンスを直接作成および制御する開発者の能力に基づいて構築されます。

サイトとアプリケーションがモノリシック ビルドからよりマイクロサービス アーキテクチャに移行するにつれて、さまざまなソースからコンテンツを配信する機能がますます重要になります。 そして、エッジがエンド ユーザーに実際に最も近いインターネットの一部であることを認識し、理解しているため、ラスト マイルと呼ばれることもあります。 しかし、セルジさん、詳細に入る前に、何がエッジで、なぜそれが重要なのかについて聴衆にレベル設定したいと思います.

SERGI ISASI: わかりました。 そのため、クラウド コンピューティングについては、「クラウドは他人のコンピュータに過ぎない」ということわざがあります。 私はこの言葉がとても好きです。 これは、デスクトップやラップトップにあるものと同じであることを意味しますが、他の誰かがそれを管理しているだけです. エッジもまったく同じで、ユーザーに近いだけです。

なぜそれが重要なのですか？ Cloudflare では、可能な限りユーザーに近いものにしたいと考えています。 そして、それは本当にあなたが言ったその声明に帰着します。それはラストマイルです. したがって、ソフトウェアをどれだけ速く作成しても、どれだけ効率的に作成しても、何かに応答するだけでも、ソフトウェアがサブミリ秒で実行できる場合でも、光の速度に縛られています. また、ソフトウェアがユーザーのデバイス上にないか、ユーザーのできるだけ近くにない場合、ユーザーはわずかな遅延を経験することになります。 そして、その遅延は問題ない場合もあれば、エンド ユーザーにとって非常に不快な場合もあります。 したがって、ポイントは、エッジのエンド ユーザーに近いもの、またはコアに近いものを最適化することです。

Cloudflare が行っていることは、すべてをエッジに置くことです。 あなたが私にこのチャットを依頼した理由の 1 つは、私たちが間違いなく世界最大のエッジ ネットワークの 1 つを運営しており、それを非常に誇りに思っているからだと思います。 Cloudflare は 10 年以上前からあり、このネットワークをずっと構築してきました。 世界中の 95% のインターネット ユーザーに 50 ミリ秒以内に到達するという目標を掲げて、100 か国の 250 都市に展開するまでに成長しました。実際にこの目標を達成しました。 そして、これもまた、ラスト マイルです。50 ミリ秒以内に到達できれば、これらのエンド ユーザーの 1 人 1 人に対して、はるかに高速に対応できます。

もう 1 つは、他のネットワークに接続することです。 たとえば、世界中の10,000の他のネットワーク、たとえば多くのローカルISPに接続し、独自のバックボーンも運用しています。そのため、コアまたはオリジンに行く必要がある場合に備えて、そのトラフィックのバックホールを作成します。さらに速く。 1 秒あたり 100 テラビット強の容量で 2021 年を終えました。 これは、お客様のトラフィックの増加と、お客様および自社のネットワークに対する攻撃の増加の両方に対する水平方向のスケーリングに関して重要です。

過去 30 年から 40 年にわたってコンピューティングに関して興味深いことの 1 つは、エッジからコア、クライアントへと移行することです。これは、その時点でどこが理にかなっており、すべてのコンピューティング能力がどこにあったかによって異なります。 したがって、公共のインターネットが登場する前までさかのぼると、メインフレームがありました。 コアには多くの計算能力があり、エッジには非常に小さな計算能力があり、それを行き来するための帯域幅は非常にわずかでした。 つまり、メインフレームにコマンドを送信すると、それらのコマンドの結果がテキストで返されます。

そこからエンドポイントの多くの進歩に移行したため、多くのファット クライアント (Windows、Microsoft Word、エンドポイントで多くの計算を行ったすべてのこと) を取得し、それを通常はそのコンテンツを共有するコア。

エッジとコアが強化されるにつれて、クラウド アプリが見られるようになりました。 そのため、デバイスで変更を行うのではなく、Web ブラウザーで変更を行い、共有のために他のデバイスを介して伝達されました。 これは、モバイル デバイス、特に計算量は少ないが帯域幅がはるかに多い初期のモバイル デバイスが登場したときに非常に重要になりました。

では、なぜこれが重要なのでしょうか? 本当にすべては、スピードに対するユーザーの期待です。 そのため、ユーザーは常に優れたユーザー エクスペリエンスを求めています。 特に今日では、優れたユーザー エクスペリエンスとは、一種のインスタント インタラクションです。 リンクをクリックし、ボタンを押すと何かが起こりますが、それがどこで起こったかはあまり気にしません。 どこで起こったのかさえわからないかもしれませんが、早くしたいです。

変わったもう一つのことは、私たちが自分自身を見つける環境です. そのため、主にこれらのデバイスがより強力になったため、攻撃が大幅に増加しています。 そして、セキュリティとプライバシーがユーザーだけでなく政府にとっても最優先事項になるため、多くの規制が変更されています。 これが、Cloudflare が POP を追加し続ける理由です。 より多くのユーザー、より多くのトラフィック、より多くの攻撃を目にし、エッジに配置してそれらのエンド ユーザーにとって強力なものにすることができるより多くのユース ケースを目にします。

PAVAN TIRUPATI: 素晴らしい。 ポップについて少し掘り下げてもいいですか？ ポップとは？ そして、時間の経過とともに POP に何が変化したのでしょうか? Cloudflare の POP 実装を具体的に掘り下げると、何がユニークなのですか?

SERGI ISASI: 戻ってきてくれてありがとう。 私は POP とよく言いますが、それが何を意味するのかを明確にする必要があります。 これは、インターネットの Point of Presence です。 そして、Cloudflare のケースや他のほとんどのケースで、誰かが POP について話しているのを聞くとき、それが意味するのは、ソフトウェアを実行する、どこかに置かれているサーバーのスタックです。

時間の経過とともに何が変化したかについては、何が変化したか、何が変化していないかについて話す方が実際には簡単です。 そして、それについて少し説明します。 つまり、私たちは第 11 世代のサーバーを使用しています。 私たちはブログでこれらの反復のそれぞれについて書いています。 そのため、エッジでより高速なコンピューターを入手し続けています。これは素晴らしいことです。 それはコストの削減、より多くの機能を意味し、一般的にエンド ユーザーにとってより良いものを意味します。

時間の経過とともに変化した興味深い点の 1 つは、実際には 3 つの異なる CPU アーキテクチャ、または実際には 2 つの異なる CPU アーキテクチャ、3 つのメーカーに実装したことです。 そのため、Intel と AMD の両方を実行しており、エッジでも ARM も実行しています。

時間の経過とともに変化したもう 1 つの点は、場所を追加し続けていることです。 10年以上前に立ち上げたときに何人いたかはわかりません。 それはダースの範囲でした。 しかし、Cloudflare の初期のファンであり、創業者のことを知っていた CTO の面白い話があります。 彼は言った、これはいつ来るのですか？ そして、私は参加します。

私たちの拠点は、需要に基づいて最初に成長しました。 リージョン内で大量のトラフィックが発生していることがわかります。一般に、リージョン内にハードウェアを配置してそこでトラフィックを処理する方が、実際には安価です。 それで、最初はそれをやり始めました。

私たちが大きくなると、地元のパートナーや ISP が、彼らとそのエンド ユーザーにとってより効率的なものにするために、その地域でハードウェアを構築するように私たちに依頼し始めるのを目にするようになりました。 つまり、Cloudflare の世界における興味深い種類の海の変化でした。

私たちの当初の目標は、エンド ユーザーから 100 ミリ秒以内になることでした。 そして、もっとうまくやれることに気づきました。 これで、50 ミリ秒の目標ができました。 そして、年が経つにつれてそれがさらに小さくなったとしても、私は驚かないでしょう.

変わっていないのは、私たちが非常に早い段階で、すべての場所のすべてのエッジ サーバーで同じソフトウェアを実行するという、私たちに固有の非常に運命的な選択をしたことです。 これは、ほとんどのエンジニアリング チームにとってより簡単な選択でした。 私たちは各デバイスで何が実行されているかを把握しており、そこでトラブルシューティングを行い、より効率的に実行することができます。 このため、一部のエンジニアリング チームはより多くの仕事を抱えています。

長期的にも短期的にも、スケーリングがはるかに簡単になります。 短期的には、負荷とその時点でその場所で何が起こっているかに応じて、必要に応じてリソースを別のサービスに移動できます。 すべてのマシンで水平方向にスケーリングできます。

長期的には、スタック全体を実行する必要があることがわかっているため、新しいマシンをどこに配置する必要があるかを事前に決定できます。 エンジニアリング チーム、特に製品エンジニアリング チームにとってのもう 1 つの大きな利点は、サービス全体で一貫したパフォーマンスが得られることです。 一部の場所が特定のタイプのユーザーに近いため、より高速で異なるエクスペリエンスが得られることについては心配していません. サーバー間および世界中で一貫性が保たれます。

そして、私たちが行った大きな変更の 1 つ (現時点でおそらく 3 年前のもの) は、お客様が Workers 製品を介してエッジでコードを実行できるようになったことです。 そして、その顧客が製品を展開することを選択したときの利点は、実際に世界の地域を選択できることです。 私たちは彼らに、「私は米国西部で走りたい」などと言うよう強制しません。 同社のソフトウェアはすべての場所に展開され、可能な限り眼球の近くで実行されます。

PAVAN TIRUPATI: すばらしい。 では、コアと比較してエッジはどうなのでしょうか?

SERGI ISASI: わかりました。 したがって、それはアーキテクチャに依存します。 また、一部のアーキテクチャでは、エッジがコアであり、コアがエッジです。 場所が 1 つしかない場合は、すべてを一度に行うことになります。

ただし、一般的には、エッジはコンピューティングの速度と効率が向上し、コアは秘密と構成を保持し、コアからエッジにデータをプッシュする場所です.

PAVAN TIRUPATI: Cloudflare にはコアがありますか? もしそうなら、それはどのように実装されていますか？

SERGI ISASI: 初日からそうですね。 そして、私たちはそれについてあまり話しません。 ちょっと面白いです。 しかし考えてみれば、私たちは 2009 年に設立されたので、すべてをエッジで実行することは 2009 年には信じられないほど非現実的でした。

では、コアで何を実行しますか? 構成管理 - そのため、ソフトウェアをプッシュする必要があります。 どこかからやらなければならないので、Cloudflare ソフトウェア、すべての新しいバージョン、コードをコアからエッジまで毎日プッシュしています。 そして、引き続きコア データ センターと通信する顧客構成も実行します。 そしてそこから端まで行く。 実際、これは WP Engine と当社の DNS ソフトウェアからの興味深い話です。

そのため、Cloudflare は当初、オープンソースの DNS ソフトウェアである PowerDNS を実行していました。 そして、社内で RR DNS と呼んでいる独自の DNS ソフトウェアを 2013 年に構築し始めました。非常に効率的なソフトウェアです。 何十万ものレコードのようなゾーンがいくつかありましたが、すべてがそれらの要件に沿って比較的順調に進んでいました。 その後、WP がやって来て、私たちのゾーンにはおそらく 100 万件以上のレコードがあると彼らは言いました。 また、更新速度、つまり変更を加えてそれをエッジにプッシュする機能は非常に重要でした。これは、顧客がオンボーディングされ、その経験を積む必要があることを意味していたためです。 そして、これは私たちにとって実際のエッジケースでした. そこで私たちはそれを見て、コンテンツのサイズと更新の速度と頻度の両方を処理するために、コアを管理し、そのトラフィックをエッジに送信する方法を明らかに変更する必要があると言いました.

そのため、2016 年に DNS エンジニアの 1 人である Tom Arnfeld は、WP Engine と一緒に座って、あなたが何を望んでいるのか、なぜそれを望んでいるのか、2017 年にはどのようになるのか、そして 2017 年にはどのようになるのかを実際に理解できるかどうか尋ねました。 2022 年、5 年が経ちました。 2017 年に私たちが行ったことは、CEO の要求に応じて、魔法のようにエッジからデータを移動できるように、DNS ソフトウェアのデータ構造全体を実際に書き直すことでした。 実際、これはお客様のニーズに応えたいと考えていたものの 1 つでしたが、コアからエッジにデータを移動する方法を再考する必要がありました。

私たちが今でも中心的に行っているもう 1 つのことは、分析です。 したがって、テレメトリはエッジからコアに到達します。 当社のお客様は、分析を表示するときにダッシュボードまたは API に移動しますが、これらはすべてコアから提供されています。

時間が経つにつれて、顧客の規模と攻撃の高度化により、テレメトリの方法を再考するようになりました。 たとえば、以前はすべての DDoS 検出ソフトウェアをコアで実行していました。 したがって、テレメトリはエッジから入ってきて、DDoS のように見えるとコアは言い、データをエッジに送り返して緩和します。 一部の DDoS 攻撃ではこれで十分ですが、その他の攻撃では実際にその決定をエッジで行う必要があります。 そのため、昨年半ばに実際にエッジで実行され、コアとは独立して決定を下し、レポートを返すいくつかの新しいシステムでコアを実行する元の Gatebot システムを強化し、攻撃に継続的に適応するようにしました。水面。

コアについて最後にお話しすることは、現在、ほとんどの機械学習をコアで行っているということです。 特にセキュリティ製品については、機械学習に大きく依存しています。 しかし、DDoS システムでも同様のパターンが見られる可能性が高いため、エッジでさらに多くのことを行いたいと考えています。 そこで、NVIDIA と提携して、エッジでもより多くの ML を実行し始めました。

PAVAN TIRUPATI: Sergi、あなたは DDoS とセキュリティについて言及しました。 特にセキュリティは非常に重要であるため、少し掘り下げたいと思います。 あなたが目にしているトレンドや物事にはどのようなものがありますか?

SERGI ISASI: 確かに、私たちの記録は少し破られていますが、DDoS 攻撃は記録破りです。 私たちはその記録を毎年破っています。 その理由は、ボットネットが実際に規模を拡大し、より強力なデバイスを活用しているためです。 したがって、現在の携帯電話またはコンピューターが前年と比べてどれだけ高速化されているかを考えると、大規模な攻撃を開始するための容量がますます増えていることは理にかなっています。少し前の「毎秒 2 テラバイト」の攻撃 - これは私たちが聞いた中で 2 番目に大きい攻撃です - そして、大量のリクエストや高価なリクエストを必要とせずに処理できる、よりスマートな攻撃です。

ここで実際に話しているのは、攻撃による高度化です。 そして、私が最も興味深いと思う統計は、私たちが

実際に話題になっているのは、エッジのトラフィックの 8% が​​軽減されているということです。 なんらかのルールやそのようなことを行う前に、8% が完全に削減されます。つまり、エッジでセキュリティを行うことを考えているお客様は、多くのトランザクションとアプリケーションへのやり取りをすぐに取り除くことができます。それはある種の攻撃であるため、彼らはまったく望んでいない、または必要としない.

PAVAN TIRUPATI: ええ、WP Engine では、ネットワーク製品の 1 つである Advanced Network をすべてのお客様のデフォルトにして、この追加のセキュリティ層を活用できるようにしようとしています。 また、関連するセキュリティ製品である GES でかつてないほどの成長が見られます。これは、追加のセキュリティ レベルとレイヤーを求めている顧客により適しています。 また、GES には Web アプリケーション ファイアウォールと Argo Smart Routing が付属しています。

しかし、ここで強調したいことの 1 つは、現在 WP Engine の顧客の 65% がこれらのネットワークのいずれにも属していないことです。 Argo Smart Routing と WAF は、彼らにとって間違いなくメリットとなるものです。 スマート ルーティングと WAF が Cloudflare の観点からどのように機能するかについて少し詳しく説明していただけませんか。

SERGI ISASI: わかりました。 Argoはとても興味深い製品です。 これは Cloudflare に非常にユニークで、慣れていない場合は少し気が遠くなるようなものです。 つまり、Argo は私が話していたエッジ テレメトリを利用して、実際にインターネット全体のより良いルートを探します。 社内では、インターネットの Waze のようなものだということわざがあります。 これは私の好みの例えではありませんが、合理的な例えです。

ルートが非効率的で、一貫性がない場合があるためです。 したがって、今日では、原点に直接行く方が速いかもしれませんし、そうでない場合もあります。 インターネットの輻輳を回避するために、Cloudflare のエッジから別のエッジに実際に移動する方が理にかなっている場合があります。

Argo の大きなポイントは、ユーザーからエッジまで、およびエッジからオリジンまでの両方のラスト マイル効率が低下することです。これは、現在、すべてのコンテンツをエッジから提供しているわけではないためです。 これは、基本的にボタンを押すだけで大幅に増加し、アプリケーションのコードを変更する必要はありません。

PAVAN TIRUPATI: それは実際には非常に洞察に満ちています。 ありがとう、セルジ。 顧客ベースにどのような変化が見られましたか? 攻撃の増加と攻撃の実際の表面の実際の影響は何ですか?

SERGI ISASI: 2020 年から 2021 年にかけての大きな変化は、ランサムウェア攻撃と別の種類のランサムウェアの台頭が見られるようになったことだと思います。あなたが私たちに支払わない場合、あなたとあなたを降ろします。

2020年には、それらのかなりの数を見ました。 2021 年には増加しましたが、パターンに変化が見られました。 そして、パターンの変化は、一般的にターゲットを見つけることではなく、同じ業界でターゲットを見つけることでした. 興味深いのは、多くのボイスオーバー IP および電話会議会社が標的にされたことです。 ちょっと理にかなっていますよね？ 誰もがリモートで作業することが多くなったため、これらのサービスは非常に重要でした。 また、ユーザーとプロバイダーの両方がオンラインにとどまることが重要であり、攻撃者がそこに非常に明確なターゲットを設定できるようにしました。

今でも変わらないことの 1 つは、インテリジェンスの共有が重要であるということです。 すべての顧客が標的にされるのを目の当たりにしている間、同じパターンが侵入し、同じ攻撃パターンがそれらのアプリケーションに送られるのを目の当たりにしていました。

PAVAN TIRUPATI: ええ、予測可能性やパターンは実際にはデータを理解する上で優れているので、それはわかります。 しかし、この電話会議に参加している開発者は、一般的な保護についてどのように、どこで考えるべきでしょうか? ここで共有できる、過去に見た最悪のシナリオは何ですか?

SERGI ISASI: わかりました。 したがって、最悪のシナリオは集中攻撃です。 そのため、誰かが本当にあなたをオフラインにしたい場合、そのような動機のある攻撃者を処理することは非常に困難です. したがって、何らかの形で物議を醸すアプリケーションや、ある種の敵を持つ可能性のあるアプリケーションを実行している場合は、考慮する必要があります。 そして、それは最近多くのことです。

ここでの攻撃は、Adidas が 1 秒あたり 1,720 万件のリクエストを行った例です。 したがって、これはスループットではなく、実際の正当な HTTP 要求です。 これらは、増幅またはスプーフィングされていません。 したがって、この攻撃者は、これらの接続を確立し、正当に見せかけることができる十分な数のデバイスにアクセスできました。 非常に分散された攻撃。 一部の地域では集中していましたが、大多数の場所で見られました。

そして、最悪のシナリオは、緩和に費用がかかることです。 これはレイヤ 7 で行われたため、接続を受け入れる必要がありました。 攻撃をかわして正当なトラフィックと識別する前に、SSL を終了する必要がありました。 つまり、これをオンプレミスの WAF などで実行しようとすると、トラフィックを見つけるだけで非常にコストがかかり、トラフィックを軽減することはできません。

PAVAN TIRUPATI: すばらしい。 ありがとう、セルジ。 セキュリティに固執すると、戦争中、ロシアやウクライナで現在目撃されているように、サイバー攻撃が急増すると予想されます. 実際、CIA と FBI は、これらの攻撃の破壊的な性質と、これらの時期に重要な資産とデータがどれほど脆弱であるかについて、共同勧告を発行しました。 彼らは、規模に関係なく、すべての組織が強化されたセキュリティ体制を採用することを推奨しています。 WP では、攻撃でもこの傾向が見られます。

このようなイベントへの準備についてどう思いますか? また、そのような状況にどのように備えることができるでしょうか。 ロシアとウクライナの戦争以外に頭に浮かぶ大きなイベントのいくつかは、昨年目撃した Log4shell イベントで、世界中の多くのアプリケーションに影響を与えました。

SERGI ISASI: ええ、つまり、私たちは応答しなければなりません。 それが私たちのいる世界です。物事が起こり、本当に恐ろしいことが起こり、私たちはそれに対応しなければなりません。 ウクライナに関する限り、大量の情報を共有することはできませんが、共有できることの 1 つは、ウクライナのトラフィックは全体的なユーザーの観点から比較的安定している一方で、ファイアウォールの緩和策が大幅に改善されていることです.

そのため、先ほどお話しした典型的な 8% から、リクエスト全体の 30% にまで減少しました。 つまり、通常のユーザー トラフィックにさらに多くの攻撃トラフィックが混入していることになります。 繰り返しになりますが、前の例と同様に、これらは高価な軽減策であり、レイヤー 4 に基づく通常の攻撃からそれらを識別するのは難しいため、レイヤー 7 で実行する必要があります。

Log4shell について話しますが、これはおそらく私が長い間覚えている中で最大のイベントでした。 したがって、これは業界にかなりの打撃を与えました。 Cloudflareの両方で、内部ディスカッションを読んでいる多くの人を覚えています。

そして、それは脆弱性であり、攻撃者が任意の文字を挿入することを可能にする非常に一般的なソフトウェアであり、それらの文字が存在すると、ソフトウェアが移動し、攻撃者が挿入した URL に対して git 要求を発行します。 だから、みんな慌てていた。 依存関係がわからない場合があります。 これは一種のレッスン 1 であり、依存関係を把握し、実行しているソフトウェアと、そのソフトウェアが実行しているソフトウェアを把握することです。

しかし、重要なことは、ここに非常に巧妙なエクスプロイトがたくさんあったことです。 そのため、お客様 (およびお客様のお客様) のためにこれを軽減していたとき、コンテンツの存在とそのコンテンツをエンコードするさまざまな方法があったため、ファイアウォール ルールのさまざまなバリエーションを展開し続ける必要がありました。

私が Log4j で最も興味深いと思ったことの 1 つは、ログ パイプラインで見られたことです。 そのため、アプリケーションが十分にファイアウォールで保護されているため、外部からの接続を受信できないと考えていたとしても、これらの文字を含むログ イベントを取得すると、その要求を送信します。 そのため、単純なファイアウォールでは十分ではありませんでした。

エッジはここで重要であり、脆弱かどうかに関係なく、コントロールをすばやく簡単に開始できるため、非常に役立ちます。 コントロールを配置することのマイナス面はありません。これが、無料の顧客にもロールアウトしたもう 1 つの理由です。 そのため、単一のコントロール ポイントは実際にそのシナリオで非常に役立ちます。

PAVAN TIRUPATI: また、このシナリオで顧客がトラフィックをスケーリングするために利用できるツールや手法にはどのようなものがありますか?

SERGI ISASI: もちろん、どのようなシナリオでも、Cloudflare にワーカーがいます。 これにより、エッジでコードを実行できるようになり、水平方向のスケーリングを心配することなく、必要なものを構築できます。

また、2021 年の初めに、Waiting Room という製品を導入しました。 待合室は、おそらくあなたがよく知っているものです。 何かを買いに行くと、その品物が足りているかどうかを判断するために列に並びました。 アプリケーションにも使用できます。 サイトに接続して、良い体験をすることができますか? それとも待つべきですか？

これは実際に私たちが作った非常に興味深い製品です。 エッジ上で Cloudflare ワーカーを使用して構築しました。 そして、それは困難でした。 おそらく、コアで構築するのがより簡単な製品です。 それは Cloudflare の DNA ではありません。 私たちはエッジ上で構築できますが、実際にはスケーリングを検討していました。 何かをコアでスケーリングしようとすると、はるかに困難になります。

待合室を作っていたときの大きな問題は、状態の共有です。 そのため、世界中のユーザーが 1 つの待合室で体験できるようにしたいと考えました。 そして、私たちは200以上の場所について話していました. それは簡単ではありません。

ですから、例を挙げましょう。 ここベイエリアでコンサートがあるとしましょう。 そのコンサートのほとんどのバイヤーはベイエリアにいる予定で、サンノゼのデータセンターに接続する可能性があります。 ただし、そうでないものもあります。 コンサートのために飛行機でやってくるか、その時に旅行している世界中のバイヤーのほんの一握りまたは数パーセントがいるでしょう。

では、どうやって公平にするのですか？ ベイエリアにユーザーのキューを配置することはできず、ユーザーのキューは他のすべての場所にあります。 そのため、エッジ全体で状態を共有するにはどうすればよいかを考える必要がありました。 そして、これがエッジの未来が向かうところだと思います。

そして、私たちは独自のDurable Objects製品を使用しています.スライドで見ることができます.すべての場所で状態を同期して共有しています. しかし、私たちが業界として、これらの問題をエッジでより多く解決しようとしているので、状態の共有がまだ難しいエッジでのソフトウェアの使用例がより多く見られるようになると思います。一貫性について、それが最終的なものか即時のものか？ それが私たちのソフトウェアの未来だと思います。

PAVAN TIRUPATI: すばらしい。 ありがとう、セルジ。 WP Engine では、お客様にパフォーマンスとセキュリティを確実に提供するために、このエッジ ファーストの考え方を持っています。 Sergi さん、電話会議でエッジで構築している開発者への最終的な考えやアドバイス、または重要な考慮事項や提案は何ですか?

SERGI ISASI: まず第一に、あなたは適切な場所に構築していると思います。 そして第二に、それは創造的であることだと思います。 1 年前に、エッジでそれらを実行できるかどうか尋ねられたら、「わかりません」と答えたであろうことはたくさんあります。 私はそうは思わない。 そして、あなたがここで見つけている革新のペースが速いだけでなく、あなたが考えている問題について考え、顧客側と製品側の両方で解決策を考え出している多くの創造的な開発者がいます.

もう1つの興味深いことは、一種のコミュニケーションと共有です。 問題を解決し、エッジでより多くのものを構築するための新しい創造的な方法を見つける動きが、特に開発者の Discord で多く見られます。 最後に、Cloudflare のプラグインとして、何かできないことがあれば、Cloudflare のプロダクト マネージャーを見つけてください。 私たちに電子メールを送ったり、Twitter で私たちを見つけたり、何を構築しようとしているのかをお知らせください。

PAVAN TIRUPATI: すごいですね。 そして、エッジはもはやエッジのケースではないと言っても過言ではありません。なぜなら、セキュリティとパフォーマンスに重点を置くのであれば、エッジはあるべき場所だからです。

セルジ、エッジについて素晴らしい言葉をありがとう。 このセッションがお役に立てば幸いです。 お時間を割いてご参加いただきありがとうございます。 どうぞよろしくお願いいたします。

プレゼンター: これで DE{CODE} 2022 の締めくくりです。インスピレーションを得て、WordPress の専門知識と新しいコミュニティとのつながりを深めていただければ幸いです。 金曜日にサイトで録画されたコンテンツを探して、見逃した可能性のあるものに追いついたり、ビデオをもう一度見たりしてください.

最後に、スポンサー パートナーである Amsive Digital、Box UK、Candyspace、Draw、Elementary Digital、Illustrate Digital、Kanopi Studios、Springbox、Studio Malt、StrategiQ、WebDev Studios、および 10Up に感謝の意を表したいと思います。 DECODE募金活動にご寄付いただき、誠にありがとうございます。 ご厚意に感謝いたします。

出席者ハブとセッションで私たちと交流してきたすべての人のために、上位 3 人の勝者を選び、DE{COD}E の最後に賞品を請求する方法をお知らせします。 直接または仮想的に、私たちの将来のイベントで再びお会いできることを楽しみにしています. 最新の WordPress 開発トレンドと、それらを実装して WordPress サイトをより迅速に構築する方法について、さらにお届けできることを楽しみにしています。 それは私からのすべてです。 ご参加いただき、誠にありがとうございました。