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年代の子供です。ブラウン管の前でN64 🕹️ をプレイするのにかなりの時間を費やしました。残念ながら、それはDNS64/NAT64の準備にはなりませんでした。

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

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

ここで、私たちが十分に早く気づかなかったケースが1つありました。明示的なIPv4アドレスはDNS解決を経由しないため、DNS64によってエンコードされません。Prisma Accelerateを使用しているユーザーの中には、接続文字列で直接IPv4アドレスを使用している方が少数います。初期の展開では、これらのユーザーの何人かに影響が出ました。これを軽減するため、Cloudflare Workersのオーケストレーションワークフローにコードを追加し、IPv4を検出し、EC2インスタンスに渡す前にDNS64で変換するようにしました。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の状況に適応する間、このコストを吸収することを決定しました。この決定は、ユーザーにとって移行ができる限りシームレスになるようにするためです（これで、この記事のタイトルを選んだ理由がわかりましたか？😉）。この決定は、当社のデータ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インスタンスをデプロイするようにオーケストレーションコードを修正するまで使用されませんでした。リージョンごとに新しい設定を条件付きで切り替え、段階的に有効化し、結果を綿密に監視できるようにしました。まず社内テストリージョンから始め、使用率の低いリージョンから高いリージョンへと順に新しい設定を有効にしていきました。

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

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

結び

Prisma AccelerateのIPv6ファーストアーキテクチャは、IPv4オンリーデータベースに対する優れたサポートを維持しつつ、Webの未来を最適化します。私たちはパートナーと積極的に協力し、データベースエコシステム全体でIPv6の採用を改善しています。当社のチームは、Prisma Accelerate、そして今後登場するさらにエキサイティングな製品でイノベーションの最前線にいることに興奮しています。

今日の詳細な解説は、内部ネットワークにおけるIPv4からIPv6への切り替えについてでした。次の投稿では、Prisma Accelerateのアーキテクチャについて詳しく掘り下げます。KubernetesからCloudflare + EC2への移行によって、コストを削減し、稼働時間をどのように向上させたかを探ります。お楽しみに、または登録して通知を受け取ることもできます。