Amazon RDSとAuroraは、AWSクラウドで管理されるリレーショナル・データベース、特にPostgreSQLとMySQLエンジンのための一般的なソリューションです。Auroraは現在、”サーバーレス “の形で提供されている（実際、私たちのサーバーレス・リトマス試験でかなり良い結果を出していると思うが、メモリ/コンピュータ/ネットワークの比率が固定された単位でのスケーリングは理想的ではありあせん）が、基本は常に同じです。この記事では、いつレプリカを増やすのが理にかなっているのか、いつキャッシュするのがより理にかなっているのかを理解できるように、これらの基本をバラバラにしようと思います。

ここにもレプリカ、あそこにもレプリカ……あらゆる場所で一貫してレプリカを複製している？

RDS/Auroraのフードの下を見ると、ライターレプリカと（オプションで）複数のリーダーレプリカがあります。ライターレプリカは任意の時点でデータの権威あるビューを所有します。書き込みはすべてライター経由で行われ、書き込みの効果をすぐにリードで確認したい場合は、リードクエリもライターレプリカ経由で行わなければなりません。これを “read-after-write consistency “と呼ぶ。リーダレプリカは、レプリケーションが非同期であるため、read-after-write一貫性はありません。変更はライターレプリカからリーダーレプリカへ順番にレプリケートされ、トランザクション内で行われた複数行の変更はアトミックに（1つとして）適用されます。リーダレプリカから読み込むと、(互いに対して)意味のある行を含む結果が得られますが、それは最新のビューではないかもしれません。このような「最終的に一貫性のある」読み込みは、たいていの場合は問題ありません。 しかし、クライアントが読み込みのレスポンスを受け取るまでに、他のスレッドによってデータベース内のデータが変更されている可能性があります。さまざまな形式の一貫性についてもっと知りたいですか? Alex DeBrieによる非常に詳細な記事をご覧ください。

作家はやることがたくさんある。読者より多いかもしれない。

ライターのレプリカはすべての変更を処理するため、書き込みの多いワークロードでは、メトリクスにこのような結果が現れることが予想されます。また、ライターの作業が完了することはありません。Auroraでは、レプリケーション作業の多くはストレージレイヤー内で処理されます（データのコピー数は決まっており、6つです！）。RDSでは、この作業はすべてレプリカ自身が行わなければなりません。重要なのは、レプリカの数が増えれば増えるほど、レプリケーションを管理するための作業が増えるということです。では、なぜレプリカを増やすのか？また、いくつあれば十分なのでしょうか？

耐久性

もしあなたがプロダクション・データベースを使っているのであれば、耐久性というアイデアを気に入っている可能性があります。これには2つの考え方があります： 1つは、長期保存におけるデータ損失に対する回復力、もう1つは、新しい書き込みを冗長な永続ストレージに保存することで、1つのコンポーネントの障害（およびそれに続くライターレプリカのフェイルオーバー）によって、最新の変更が長期保存のために完全に複製される前に消えてしまうことがないようにすることです。

Auroraのストレージレイヤーは本質的に高い耐久性を持ちます。RDSの場合、#1については自分で考える必要があるが、3つのAZに合計3つのレプリカがある場合、それはおそらくあなたが得ることができる耐久性と同じくらいで、3つを超えると耐久性の向上は急速に減少します。また、S3にバックアップを取ることになります！

耐久性タイプ2については、マルチAZ構成を確実に実行する必要があります。少なくとも2つのレプリカ、できれば3つが望ましい数です。3つ以上になると、耐久性はあまり上がりません。

可用性は？

データベースも利用可能であってほしいですよね？理想的には、1つのレプリカ（またはAZ）が利用できない場合でも、耐久性のある書き込みをサポートし続けられるようにしたいものです。だから、マジック・レプリカの数は3つです。顧客に高可用性を提供したいのであれば、3つはおそらくアプリケーションを運用しているAZの数でもあります。AWSが最小3AZでリージョンを構築しているのは偶然でしょうか？そうではありません。3つのAZに3つのデータベースレプリカがあれば十分であり、それ以上のレプリカを追加することは、より多くの（最終的に一貫性のある）読み込みをサポートするための高価な方法に過ぎません。

キャッシュを使って一貫性のあるリードをスケールアウトするのはどうだろう？

いい質問ですね！私たちは、3つのデータベースレプリカを超えても、耐久性や可用性という点ではあまり得られず、最終的に一貫性のある読み取りを提供する能力を高めるだけだということを学びました。キャッシュは、AuroraやRDSのリーダーレプリカに送信するような、最終的に一貫性のある読み取りを提供するために構築されています。また、パフォーマンスを向上させ、負荷スパイクを吸収してデータベースを過負荷から保護する（レプリカの垂直スケーリングなどを管理する時間を増やす）のに優れています。データベースの読み取りをキャッシュすることは非常に一般的ですが、ユビキタスではありません。その理由は、キャッシングを追加することは複雑で、低スケールではコストがかかる可能性があったからです（従来のキャッシュクラスタには高い最低購入価格があり、低スループットのニーズには対応できません）。

でキャッシング・インフラの将来を保証するは、真にサーバーレスなキャッシュを提供することで、方程式を変えました。運用の負担を増やすことなく、どのような規模でもキャッシングを適用できるようになり、実際に使用した分だけ料金を支払うことになります。AuroraやRDSのようなデータベースを最初からスムーズかつコスト効率よくスケールアウトするのに役立ちます。開発者には、キャッシュ用の組み込みフレームワーク（PHP用のLaravelなど）を使用したり、データベースクエリを集中的にラップするミドルウェアを使用するなど、シンプルな統合の機会を探すことをお勧めします。

今すぐMomento Cacheを試して、AuroraとRDSにキャッシュの利点を追加することがいかに簡単かを学びませんか。AuroraやRDSクラスタのスケーリングパスを最適化することができます。

データベースのスケーリングに関して、Momentoに解決してもらいたい運用上の課題はありますか？ぜひ教えてください！ツイート @pj_naylor、LinkedIn、またはメール support@momentohq.com までご連絡ください。

ピート・ネイラー

著者

Runs a consulting business called High Bar Solutions. Previously worked as a Solution Architect for Momento and spent 6 years working with DynamoDB at AWS—plus “lots” of years accumulated in old-school environments which are better forgotten these days. Firmly believes that giving software developers the tools to innovate faster will move the world in a positive direction. Always seeking to embed within groups of smart people and act like a sponge. Likes disconnected breaks in the wilderness from time to time. Beware: may talk for hours about distributed systems, correctness and scale in a transactional database context.