QCon Londonにおいて、Neon社（@neon.tech)のストレージ・エンジニアリング・リードであるJohn Spray氏は、Neon Serverless Postgresをケーススタディとして、ステートフル・クラウド・サービスの設計において見過ごされがちな複雑さについて議論した。彼のセッションは、カンファレンス初日のCloud-Native Engineeringトラックの一部だった。
John Spray氏は講演の中で、最新のITインフラにおけるデータ管理とストレージに関する重要な検討事項について述べた。同氏は、データのローカライゼーションとレプリケーション、データ保存の最適な戦略、データの完全性と可用性を維持するために必要なコピーの数を決定することに関する疑問を取り上げた。
/filters:no_upscale()/news/2024/04/stateful-cloud-services-qcon/en/resources/1IMG_0748-1712602963530.jpg)
John Spray氏はまた、キャッシュドライブが空の新しいノードの初期化中にサービスの可用性を確保するという課題に取り組み、ローカルのディスクストレージに依存するサービスを効率的にスケーリングする戦略について議論した。彼の分析はさらに、この領域におけるKubernetesの影響力の評価や、複数のアベイラビリティ・ゾーンやリージョンにまたがるデータの耐久性を実現することの財務的影響にまで及び、コスト、パフォーマンス、信頼性のバランスに焦点を当てた講演となった。
InfoQは、QCon Londonでの講演前にJohn Spray氏にインタビューした。
InfoQ: データの耐久性とサービスの可用性を確保するために、特にNeon Serverless Postgresのようなデータベースの場合、同期と非同期のデータレプリケーション方法を選択する際のトレードオフについて教えてほしい。
John Spray氏: 実用上は通常、同期レプリケーションが好まれます。これはプライマリからセカンダリに切り替わる際に、非同期システムが抱える「タイムトラベル」の問題を避けることができるため、ユーザーにとって理解しやすいということもあります。例えば、Neonの内部では、Safekeeperのノード間で完全な同期レプリケーションを使用しています。レイテンシは1ミリ秒以内であり、結果としてユーザが期待する動作が得られます（つまり、ノードの1つが失われたとしても、ユーザの視点からは何も変わりません）。
非同期レプリケーションでは、プライマリがセカンダリの応答性に関係なく処理を進めることができる。これは高レイテンシのリンク上で有用であることは言うまでもないですが、読み取り集中型の分析ワークロードなど、セカンダリが高負荷にさらされる場合にも重要です。プライマリがセカンダリのワークロードに関係なく高いパフォーマンスを維持できるようにすることは、堅牢なアーキテクチャを構築するための重要な手段です。
Neonのリード・レプリカ・エンドポイントは、さらに1つの分離レベルを追加する。リードレプリカはNeonの分散ストレージバックエンドから直接読み込むことができるため、プライマリは更新をレプリカに送信する必要がなく、プライマリのPostgresインスタンスに余分な負荷をかけることなく、いくつでもレプリカを実行することができます。
InfoQ: さらに、ローカルディスクストレージを利用する場合とブロックストレージやオブジェクトストレージを利用する場合では、リカバリ戦略はどのように異なるのでしょうか。
John Spray氏: どのようなリカバリを指しているのか明確ではないですが、ここではインフラ障害からのリカバリについて議論していると仮定します。
Neonでは、ユーザーの書き込み（WAL）を「Safekeeper」サービスに3倍速でAZ横断レプリケーションし、その後、オブジェクト・ストレージ（こちらもAZ横断レプリケーション）に書き込み、このデータを「Pageserver」サービス経由で読み込むという組み合わせで、データの耐久性を提供しています。
これは、障害から復旧するためのローカルディスクとオブジェクトストレージの対比を示す有用な例となる。
Safekeeper ノードが故障した場合、データの3倍のレプリケーションを復元し、完全に健全な状態に戻すために、新しい（代替）ノードがピアからローカルストレージを再充填する必要がある。ユーザデータは失われないものの、完全に複製された状態に戻すために、できるだけ早く新しいコピーを作成しなくてはならない。
ページサーバーノードの障害は、基本となるデータのレプリケーションには影響しません（S3にある）が、稼働しているオブジェクトのセットを再ダウンロードしなければならないため、可用性には影響します。 私たちは、余分なディスクスペースを使用する代償として、他のページサーバ上にウォームスタンバイ・キャッシュを保持することで、これを軽減しています。
ローカルディスクにレプリカを使用することは、プライマリストレージにオブジェクトストレージを使用するよりもコストがかかりますが、ユーザーの書き込みに対してより低いレイテンシーを提供するために、そのコストを受け入れています。 例えば、あまりアクティブでないデータベースに対して、ローカル・ディスク・キャッシュにオブジェクトの余分なウォーム・コピーを保持しないようにすることができます。 これにより、すべてのローカル・ディスク・コピーを常に3つ以上保持しなければならない設計と比較して、テナントごとに使用するハードウェア・リソースの量をよりきめ細かく最適化することができます（最新の書き込みのローカル・ディスク・コピーを3つ保持するだけです）。
EBSのようなレプリケート/ネットワーク・ブロック・デバイスを使えば、設計を簡素化できる場合もある。EBSボリュームは単一のAZ内でのみ複製される（ユーザーは通常、AZの障害に対するデータベースの耐久性を期待している）。
InfoQ: ステートフルなサービスを複数のアベイラビリティゾーンやリージョンに展開することは、高可用性を実現する上で非常に重要だが、多くの場合、コストに大きな影響を与える。ステートフルサービスのマルチリージョン展開を設計する際に、企業がコストとパフォーマンスのバランスをどのようにとることができるか、見解をうかがいたい。
John Spray氏: マルチAZのデプロイは、クラウドユーザーにとって「請求書ショック」の原因となることが多い。2つ以上のAZのストレージインスタンス間で高レートの書き込みをレプリケートすると、基本となるストレージインスタンスに匹敵するコストがかかる可能性がある。
したがって、AZをまたがるレプリケーションのトラフィックは、必要不可欠なもの、つまりレイテンシ要件が厳しい書き込みに限定すべきである。クロスAZレプリケーションを後のデータ管理／保管に使用することは避ける。データをできるだけ早くオブジェクト・ストレージに取り込み、異なるAZからイグレス・コストをかけずにアクセスできるようにする。
どうすればこれを軽減できるのか？
クラウドベンダーのストレージサービスは、独自のエグレス料金の対象外であり、ローカルディスク間のレプリケーションよりもレイテンシが高いが、例えばS3では自前で構築するよりも低価格でクロスAZレプリケーションを提供していることがある。
圧縮を上手に使えば、大きな効果が期待できる。ホットデータは圧縮性が高いことが多い。これは典型的なOLTPワークロードやストリーミングワークロードに当てはまる。最近のCPUは、余分なレイテンシをあまり発生させることなく、LZ4のような軽量圧縮を適用することができ、CPUサイクルはエグレス料金よりも安いです。
同様の問題はマルチリージョン展開にも当てはまるが、緩和の余地は少ない。光ファイバーケーブルでの長距離データ移動には本質的なコストがかかる。 耐久性のためにリージョンをまたいだレプリケーションが規制上必要な業界にとっては、これは単にビジネスを行うためのコストになる。 また、遠隔地に拠点を持つことのビジネス上のメリットが、データを地域間でレプリケートするコストを正当化するのに十分かどうかを慎重に検討する必要がある。
InfoQ: サービスのパフォーマンスとデータの耐久性を維持または強化しながらコストを最小化するのに役立つ特定のパターンやKubernetesの機能はありますか？
John Spray氏: これについては講演で詳しく説明する。簡単に言うと、kubernetesのStatefulSetを使うときには落とし穴があるので注意しなければならないし、マネージドkubernetesサービスのノード交換がサービスのメンテナンスにどのような影響を与えるかを考慮しなければない。Kubernetesは今でも仕事に適したツールであることがありますが、kubernetesを使うには、ステートフルなサービスの場合、典型的なステートレスなユースケースよりも慎重に考える必要がある。
ビデオ・オンリー・パスで録画されたQCon Londonの講演にアクセスする。