「Prisma Accelerate」をIPv6に移行、誰にも気づかれずに完了

序章

まずは、「Prisma Accelerate」の仕組みに関する簡単な入門から始めましょう。「Prisma Accelerate」の詳細な解説はまだできていませんでしたので、ここでは主要なアーキテクチャのポイントをまとめます。

「Prisma Accelerate」は、CloudflareとAWSのインフラストラクチャにまたがるハイブリッドクラウドアーキテクチャ上に構築されています。「Prisma Accelerate」のキャッシュ、認証、リクエストルーティングは、Cloudflare Workersを使用してエッジで行われます。これにより、世界中にデプロイされたアプリに対して一貫して高速なキャッシュヒットが実現されます。エッジは、単一リージョンに存在するデータベースへの接続プールを維持したり、ラウンドトリップを最適化したりするのには適していません。そのため、「Prisma Accelerate」は、データベースに最も近いAWSリージョンで、プロジェクトごとにEC2インスタンスを運用しています。セキュリティ、パフォーマンス、ワークロードの分離など、多くの理由から、プロジェクトを専用のEC2インスタンスに完全に分離することを選択しました。

これらのEC2インスタンスは、以前はIPv4ネットワークを利用しており、外部との通信のためにパブリックIPv4アドレスが割り当てられていました。このセットアップはシンプルで、「Prisma Accelerate」がサポートする16リージョンにそれぞれVPCがあり、それぞれにサブネットがありました。EC2インスタンスがどのようにオーケストレーションされるかはさらに興味深い点ですが、それは別の投稿で取り上げます。

重要なポイントは、「Prisma Accelerate」が、使用パターンに応じてプロビジョニングおよびデコミッションされる数千のEC2インスタンス上で動作しているということです。インスタンスあたり月額3.60ドルの追加料金は、ユーザーに費用対効果の高いソリューションを提供する能力に影響を与えたでしょう。パブリックIPv4アドレスをなくす必要がありました。

IPv6全面移行

IPv6のみへの移行を検討している方は、IPv4とIPv6が異なる非互換のプロトコルであることを知っておく必要があります。IPv4アドレスのみを持つマシンは、IPv6のみのマシンと通信できず、その逆も同様です。ワークロードが通信している外部サービスを評価し、それらのサービスがIPv6アドレスをアドバタイズしているかどうかを確認することが重要です。

最初は、「Prisma Accelerate」はIPv6への迅速な切り替えに適しているように思われました。すべての受信トラフィックは、まずCloudflare Workerベースのエッジネットワークを経由しますが、これはユーザー向けにIPv4とIPv6の両方のアドレスをアドバタイズしています（Cloudflareに感謝！）。CloudflareからAWSへの通信は、IPv4とIPv6の両方をサポートする内部ネットワーク内で行われます。

課題は、ユーザーのデータベースへの接続でした。多くの一般的なデータベースプロバイダーがIPv6アドレスをアドバタイズしていないことが判明しました。「Prisma Accelerate」ユーザーの半数以上がIPv4のみのデータベースに依存していました。これは残念なことに、「Prisma Accelerate」のEC2ワークロードをIPv6のみにすることが選択肢ではないことを意味しました。それでも、AWSが課したIPv4アドレスの新たなコストをなくす必要がありました。

DNS64とNAT64の登場

私は90年代の子供です。CRTの前でN64 🕹️ をプレイするのにかなりの時間を費やしました。残念ながら、それはDNS64/NAT64への備えにはなりませんでした。

IPv4とIPv6は非互換ですが、IPv6からIPv4への発信トラフィックを変換することは可能です。特別なIPv6範囲である 64:ff9b::/96 は、DNS64と呼ばれるプロトコルのために指定されています。DNS64は、IPv4アドレスをIPv6アドレスにエンコードします。IPv6のみのサーバーがDNS64ネームサーバーに対してDNSクエリを実行すると、IPv4の A レコードを IPv6 の AAAA レコードに変換します。その後、IPv6のみのサーバーは、DNS64 IPv6アドレスにリクエストを送信します。

DNS64だけでは、IPv4アドレスのエンコードとデコードのみを行います。別のホスト、通常はゲートウェイが、DNS64 IPv6アドレスでリクエストを受信し、宛先のIPv4にプロキシする必要があります。このプロセスはNAT64と呼ばれます。ネットワークルーティング構成は、64:ff9b::/96 範囲を NAT64 ゲートウェイにルーティングするように構成されているため、すべてのIPv6のみのホストは DNS64/NAT64 プロセスを認識しません。NAT64を導入すると、NAT64ゲートウェイのみが外部のIPv4のみのサーバーと通信するためにパブリックIPv4アドレスを必要とします。

ここで早期に気づかなかったケースが1つありました。明示的なIPv4アドレスはDNS解決を経由しないため、DNS64によってエンコードされません。「Prisma Accelerate」には、接続文字列で直接IPv4アドレスを使用しているユーザーが少数います。初期ロールアウトは、これらのユーザーの一部に影響を与えました。これを軽減するために、Cloudflare Workersのオーケストレーションワークフローにコードを追加し、IPv4を検出してDNS64で変換してからEC2インスタンスに渡すようにしました。DNS64変換は、実装に数行のコードしか必要ないシンプルな関数です。

IPv6ファースト

「Prisma Accelerate」は、IPv6ファーストと呼ぶアプローチでNAT64を活用しています。「Prisma Accelerate」がサポートするすべてのリージョンで、NAT64が有効になっているAWS NATゲートウェイを運用しています。EC2インスタンスは、IPv6のみのVPCサブネットに配置され、特定のIPアドレス範囲からパブリック IPv6アドレスが自動的にプロビジョニングされ、IPv4アドレスはプロビジョニングされません。EC2インスタンスがユーザーのデータベースに接続しようとすると、データベースもIPv6アドレスをアドバタイズしている場合は、パブリックIPv6アドレス経由の直接接続が優先されます。それ以外の場合は、代わりにDNS64アドレスが解決され、リクエストは接続されたNATゲートウェイを経由してIPv4経由でデータベースにルーティングされます。CloudflareからAWSへのリクエストを含むすべての内部トラフィックは、常にIPv6です。

残念ながら、これによりIPv4アドレスのコストは削減されますが、NATゲートウェイ経由で追加のデータ転送料が発生します。Prismaは、エコシステムが新しいIPv6の状況に適応する間、このコストを吸収することを決定しました。この決定は、移行をユーザーにとって可能な限りシームレスにするためです（これで、この投稿のタイトルをなぜ選んだのかお分かりいただけたでしょうか？ 😉）。この決定は、Data DXマニフェストで掲げている開発者体験に焦点を当てた原則のいくつかとも一致しています。

AWSでNATゲートウェイを使用すると、追加コストが発生します。多くのワークロードでは、NATゲートウェイよりも専用のIPv4アドレスを利用する方が費用対効果が高くなります。一方、「Prisma Accelerate」のようなケースでは、NATゲートウェイの方が費用対効果の高いソリューションです。最適なソリューションを特定するために、独自に分析を行うことをお勧めします。

予期せぬ事態

NAT64は外部ネットワークの課題を解決しましたが、それは内部で予期せずIPv4に依存していた箇所を露呈したに過ぎませんでした。

「Prisma Accelerate」は、CloudflareからAWSへの通信のためにポートにバインドするプロセスをEC2インスタンス上で実行します。これらのバインディングは、IPv6ではなくIPv4でリッスンしていました。幸いなことに、これはEC2インスタンスを動的に構成するCloudflare Workersベースのオーケストレーションコードで簡単に変更できました。

「Prisma Accelerate」は、Dockerを使用してEC2インスタンス上のこれらのプロセスをオーケストレーションします。当初、コンテナネットワークの問題が発生しましたが、ローカルのDockerネットワークでIPv6を有効にすることで迅速に解決されました。

最終的に、すべてが動作するようになりましたが、ネットワーク呼び出しが非常に遅いように見えました。調査（はい、digを使用しました）の結果、この遅延は、DNS解決が最初にIPv4アドレスをクエリしようとし、次に正しいIPv6アドレスを使用しようとすることで発生していることがわかりました。これは、EC2ベースAMIがIPv4ネットワーク上に作成され、その構成で復元されたことが原因でした。DNS解決にいくつかの調整を加えたところ、速度は良好になりました。

ロールアウト

「Prisma Accelerate」は非常に分散されているため、この変更は段階的にデプロイされ、ユーザーへの目に見える影響はありませんでした。私たちはこれを非常に誇りに思っています。 🏆

まず、新しいインフラストラクチャをすべてのリージョンにデプロイすることから始めました。インフラストラクチャはPulumiで管理し、構成がデプロイで再現可能であり、チームがレビューできるようにしています。すべてのリージョンで、既存のインフラストラクチャと並行して、まったく新しいVPC、サブネット、NATゲートウェイ...すべてをデプロイすることで、インフラストラクチャのリスクを軽減しました。

新しいインフラストラクチャは、それを利用するEC2インスタンスをデプロイするようにオーケストレーションコードを修正するまで未使用でした。新しい構成をリージョンごとに条件付きで切り替えることで、段階的に有効にし、結果を綿密に監視することができました。内部テストリージョンから開始し、使用率の低いリージョンから使用率の高いリージョンへと、リージョンごとに新しい構成を有効にしました。

リージョンで新しい構成を有効にしても、劇的な影響はありませんでした。実行中のEC2インスタンスは、「Prisma Accelerate」によってすぐに置き換えられるわけではありません。むしろ、インスタンスがオーケストレーションワークフローによって自然にリサイクルされるにつれて、古いIPv4のみのインスタンスは、ピカピカの新しいIPv6ファーストのものに置き換えられました。「Prisma Accelerate」のこの特性は、アクティブなユーザーへのリスクと影響を最小限に抑えたため、ロールアウトに不可欠でした。

初期ロールアウトは、数千人のユーザーにわたって非常にスムーズでした。はい、いくつかの孤立した問題はありました（マーフィーの法則！）。私たちは計画にそのような事態を組み込み、問題のあるユーザーがいる孤立したリージョンを以前のバージョンに戻し、修正をデプロイして、リージョンを再びIPv6に戻すことができました。時間が経つにつれて、すべてのユーザーインスタンスが置き換えられ、古いインフラストラクチャを廃止することができました。

結び

「Prisma Accelerate」のIPv6ファーストアーキテクチャは、IPv4のみのデータベースに対する優れたサポートを継続しながら、ウェブの未来に向けて最適化されています。データベースエコシステム全体でのIPv6の普及状況を改善するために、パートナーと積極的に協力しています。私たちのチームは、「Prisma Accelerate」、そして今後登場するさらにエキサイティングな製品で、イノベーションの最前線に立てることに興奮しています。

今日の深掘りでは、内部ネットワークでのIPv4からIPv6への切り替えについて詳しく説明しました。次回の投稿では、「Prisma Accelerate」のアーキテクチャについて詳しく解説します。KubernetesからCloudflare + EC2に移行することで、どのようにコストを削減し、稼働時間を増やしたかを探ります。お楽しみに。アラートを受け取るにはサインアップしてください。