Neonのレイクベースアーキテクチャの内部：ステートレスコンピュートとセル分離がいかにしてAWS障害を乗り越えるか

これは、AWSのプロビジョニング障害時に極めて重要な意味を持つ。Neonは、故障したコンピュートを置き換えるために、プレッシャーのかかった状況下でAWSのEC2 APIを呼び出す必要がないのである。Neonは、事前にウォームアップ済みのインスタンスプールから代替を引き抜き、それを既存のストレージ状態に紐付けるだけで済む。クラウドプロバイダ側の制御プレーン障害は、データ可用性の緊急事態ではなく、単なる「運用上の不便」程度の話になる。

セルベースの分離：1つのリージョンが1つの障害ドメインではない

Neonのリージョン展開は一枚岩ではない。各リージョンは1つ以上の「セル」で構成されており、各セルがKubernetesのコントロールプレーン、コンピュートプール、ストレージリソースを一式抱えた、いわば独立したミニリージョンのように振る舞う。この区画化こそが、ある1つのセルで発生した障害（クラウドの障害、ソフトウェアのバグ、リソース枯渇など原因は問わない）が、同じリージョン内の他のセルに伝播しないことを保証する仕組みである。

2026年5月のAWS us-east-1での障害時、AWS側では新規インスタンスのプロビジョニングとIPアドレス割り当てに特化した障害が発生していた。もしこれが単一セルのアーキテクチャだったら、リージョン全体の障害に直結していただろう。しかしNeonのセルベース設計においては、事前にプロビジョンされたコンピュートのバッファを使い切ったセルだけが影響を受けるにとどまった。十分なバッファを持つ他のセルは、何事もなく稼働を続けたのである。

この結果は、意図的な設計判断の賜物だ。各セルのリソース制限がリージョン全体のボトルネックにならないよう、セルは適切にサイジングされている。セルベース分離へ移行する前、Neonは1リージョンに1つのKubernetesクラスタで運用していたが、その負荷テストで得た教訓がこの判断を後押しした。EKSのetcdメモリ上限（8GB）、ネットワーク構成の制約（us-east-1で約12,000の同時接続データベースが限界）、Kubernetes APIのレート制限などの壁に直面し、1万を超える同時データベース数でサービスが劣化することが判明したのだ。セルベースアーキテクチャは、負荷を独立した複数のセルに分散することで、こうした単一クラスタの天井を完全に取り払う。

クラウド依存の低減：事前プロビジョニングと自前の仮想化

Neonとクラウド基盤との関係は、意識的に「距離」を置いたものだ。データベースの起動が必要になるたびにオンデマンドでEC2 APIを呼び出すのではなく、Neonは大規模な（しばしばベアメタルの）インスタンスプールをあらかじめ割り当て、プロビジョニング障害を吸収するためのバッファを常に確保している。これは一部の優先テナント向けの小さなウォームプールではない。システムがコンピュートをスケジューリングする構造的なコンポーネントそのものなのである。

さらに、この事前プロビジョンされたインスタンス群の上で、Neonは独自の垂直オートスケーリング仮想化レイヤーを動作させ、1台の物理ホスト上に複数のPostgresインスタンスを高密度に配置する。これにより、クラウドプロバイダへの依存を二重に回避している。VMのプロビジョニングAPI（インスタンスは既に稼働済みのため）と、ブロックストレージのアタッチメントパス（Neonのコンピュートノードはクラウドブロックボリュームを使用しないため）の両方をバイパスするのだ。

データの耐久性も同じパターンに従う。データベースの全コンテンツは、クラウドのブロックデバイスではなく、Amazon S3やAzure Blob Storageのようなオブジェクトストアをバックエンドとした、Neon独自のゾーンレジリエントストレージサービス上に常駐する。オブジェクトストレージのAPIは、VMプロビジョニングAPIとは異なる故障モードを持ち、実際のリージョン制御プレーン障害下では、はるかに高い耐障害性を示すことが実証されている。PageserverやSafekeeperのノードに障害が発生しても、耐久データが失われることはない。別のノードが、WALとオブジェクトストレージから必要なページを再構築できるからだ。

ゾーン冗長ストレージは「土台」であり、特別なアドオンではない

多くのマネージドデータベースサービスでは、マルチAZ（アベイラビリティゾーン）ストレージレプリケーションは有償の追加機能だ。しかしNeonでは、料金ティアに関わらず、すべてのデータベースが複数のAZにまたがるNVMe SSDキャッシュと分散オブジェクトストレージによってバックアップされている。ストレージ層自体が本質的に複製されているため、物理的なゾーン間レプリケーションを別途考慮する必要はない。

WALレプリケーションの設計は、具体的な耐久性保証を提供している。書き込みはSafekeeperへ同期的に複製され、クォーラム要件が課せられる（例えば、ある公開構成では6台のSafekeeperに複製し、4台からの書き込み応答を必須とする「4/6ライトクォーラム」を採用している）。これは、1つのAZ全体と、さらに1つのレプリカが同時に壊滅してもデータロスが生じないことを意味する。これは理論上の話ではなく、トランザクションをクライアントに承認する前に、書き込み経路上で実際に満たされなければならない特性である。

特にコンピュートの可用性においては、共有ストレージモデルが従来のプライマリ-レプリカ型アーキテクチャにはない利点をもたらす。すべてのコンピュートインスタンスが同一の永続ストレージ履歴を共有しているため、代替のコンピュートは物理レプリケーションを通じて追いつく必要がない。既存の履歴にアタッチし、ワークロードやキャッシュされたワーキングセットのサイズに応じて、数秒から数分以内にクエリの処理を開始する。

可用性目標と、データが示す真実

公開されているNeonのレイクベースアーキテクチャの可用性SLI（サービスレベル指標）は、約99.93%から99.96%の範囲にある。これは、コンピュート障害をアイドル状態のホットスタンバイにフェイルオーバーするのではなく、ステートレスノードの交換によって回復し、ストレージ耐久性を同期ディスクミラーリングではなくオブジェクトストアベースのレプリケーションで達成する設計を反映した数字だ。

Neon自身のインシデント履歴は、これらの目標を校正する有益な材料を提供してくれる。2025年5月のus-east-1でのインシデントでは、2度にわたる合計5.5時間にわたり、データベースの新規作成や一時停止状態からの起動が不能になった。しかし、稼働中のデータベースには影響はなかった。根本原因は、KubernetesサブネットでのIPアドレス枯渇であり、制御プレーンの過負荷とAWS CNI（Container Network Interface）プラグインの設定ミスによって引き起こされた。この問題は、後にセルベースアーキテクチャが防ぐべく設計されたスケーラビリティの限界を露呈させるものだった。

これに先立つ2024年8月には、us-east-1でEC2インスタンスの故障を発端とするPageserverの障害が発生し、約0.4%の顧客プロジェクトに最大2時間の影響が出た。PageserverはS3をバックエンドとするローカルディスクキャッシュとして機能するため、その喪失はデータの永久損失ではなく、一時的な可用性の低下を意味した。

これらのインシデントは、ステートレスコンピュートと共有ストレージが障害の重大度を劇的に軽減する一方で、完全に「無敵」にはなれないことを浮き彫りにしている。コンピュート障害によるデータロスなし、再アタッチによる自動復旧、セルで区切られた爆風半径といったアーキテクチャの耐障害性は、現実の障害条件下で確かに威力を発揮する。しかし、ソフトウェアの欠陥、リソースの枯渇、あるいはIPアドレス割り当てのように、まだ完全に依存を断ち切れていないクラウドプロバイダの要素に対して、システムが無傷でいられるわけではないのだ。

レジリエンステスト：Neonはどう設計を検証するのか

Neonのエンジニアリングブログによれば、このシステムはクラウドプロバイダのプロビジョニング障害やAZ全体の遮断シミュレーションといった、現実世界の障害シナリオに対して定期的にテストされている。これらのテストは、爆風半径を限定する役割を持つ、事前プロビジョニングされたインスタンスバッファとセル分離の境界を鍛え上げる。Neonが説明するカオスエンジニアリングの形式は、業界で確立されたプラクティスを踏襲している。システムが障害下でどう振る舞うべきかという「定常状態の仮説」を定義し、AZ全体の切断やコンピュートバッファの枯渇といった制御された障害を注入し、その仮説が維持されるか観測し、維持されなければアーキテクチャを改良する、という流れだ。

Neonは詳細なカオスエンジニアリングの方法論や、アーキテクチャ概要以上の具体的な実験結果を公表してはいない。しかし、入手可能な情報から、そのテストがアーキテクチャの際立ったレジリエンス特性を直接標的にしていることは明らかだ。Neonが説明する「プロビジョニング障害とAZ障害のシミュレーション」は、まさにステートレスコンピュートとセル分離が、従来のマネージドデータベースアーキテクチャに対して最大の優位性を発揮すべきシナリオである。2026年5月のAWS障害は、これらと全く同じメカニズムに対する、計画外の大規模な実地検証だったと言える。そして、爆風半径が封じ込められたという結果は、事前プロビジョニングとセル分離が生み出すよう設計された効果に、完全に合致するものだった。

サーバーレスPostgresを検討する開発チームへの示唆

Neonのアーキテクチャは、明確な「レジリエンスのトレードオフ」を提示している。それは、「コンピュートは儚い（Ephemeral）ものである」と割り切り、何が何でも稼働させ続けるのではなく、高速に交換する。その代わりに、ストレージの耐久性と障害ドメインの分離に多大な投資を行う、という考え方だ。

数秒未満のクエリ中断が許容でき、最重要関心事がデータの安全性であるようなワークロードにとって、このモデルはホットスタンバイを維持するコストと複雑さを根本から排除する。一方で、一切の中断なく継続的なクエリ可用性を要求するワークロードには、より高コストなマルチコンピュート構成も用意されているが、そのコストは当然高くなる。

このアーキテクチャはまた、「クラウド依存」の現実を正直に見つめさせる。いかなるデータベースサービスも、その基盤となるクラウドプロバイダから真に独立することはできない。しかし、その「結合度」には雲泥の差がある。Neonが下した、事前のキャパシティプロビジョニング、自前の仮想化レイヤー、ブロックボリュームではなくオブジェクトストレージへのデータ保存、といった一連の選択は、データベース層が機能するために「利用可能でなければならないクラウドプロバイダAPI」の種類を大幅に狭めている。

この「依存するAPIの表面積」の狭さこそが、2026年5月のAWS障害時に真価を発揮した。十分な事前プロビジョニングバッファを持つセルは、より密に結合したアーキテクチャならリージョン全体に及んだはずの障害をものともせず、稼働し続けたのだ。

サーバーレスインフラ上にシステムを構築する開発チームにとって、Neonのアプローチは一つの証明である。爆風半径の封じ込めは、後付けの対策ではない。障害が起こるはるか以前に、ストレージとコンピュートの境界線、そして障害ドメインの構造に対して下された、根本的なアーキテクチャ判断の「産物」なのだ。