Amazon Web Services ブログ

Category: PostgreSQL compatible

Amazon Aurora under the hood: クオーラムと障害

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 Amazon Aurora ストレージは、ハイエンドなリレーショナルデータベースに求められる高いパフォーマンス、可用性、堅牢性要件を満たさなければならない分散システムです。これから 4回にわたって Amazon Aurora の設計に関する重要な要素を紹介します。この投稿はその第1回目です。 大規模なシステムにおいて必要な実世界の堅牢性、可用性、パフォーマンスのトレードオフを論じるパブリックドキュメントはあまり多くありません。このシリーズはトランザクショナルデータベースを設計する上での考慮点をベースにしていますが、ミュータブルな分散システムを設計する方に有用だと思います。 第1回目の投稿では、どのようにして Aurora ストレージでクォーラム採用するに至ったか、なぜ 3つのアベイラビリティゾーン(AZ)にわたる 6つのコピーを持つのかについてお話します。今回お話するいくつかは、SIGMOD paper にて論じたものです。 分散ストレージは素晴らしい考え方なのに、なぜうまく実現することが難しいのか まず分散ストレージがなぜよい考え方なのかをお話しましょう。データベースソフトウェアとストレージを1つの箱に配置することで素早くデータベースを構築することは簡単です。この場合、その箱が障害に遭うことが問題となります。障害後にバックアップからリカバリするのに時間がかかります。バックアップされていない直近のデータが失われることを許容できるシステムはほとんどないでしょう。 データベースインスタンスからストレージを分離することで、障害に備えるということに加えて、柔軟性を高めることができます。お客様は、データベースを停止します。スケールアップやスケールダウンを行います。リードレプリカを加えたり、除去します。ストレージとデータベースとを疎結合にすることで、こういった操作が簡単になります。というのも、根幹となるストレージを新しい場所に再作成するのではなく、単にデタッチし、再度アタッチするだけでよいためです。データは重力を持ちますが、コンピュートは異なります。 もちろん、ストレージをコンピュートから分離させることだけでは、それぞれ障害に遭う可能性のある機器を増やしてしまうことになります。それゆえ、同期もしくは非同期のレプリケーションが利用されるのです。もし、障害が複数の機器にまたがるようなものでなければ、レプリケーションが堅牢性を高めます。 しかし、レプリケーションにも考慮が必要な点があります。同期レプリケーションでは、堅牢な書き込みを行うために、すべてのコピーが行われたことを認識されなければいけません。このアプローチでは、最も遅いディスク、ノード、もしくはネットワークに律速されることになります。非同期レプリケーションでは、レイテンシーが改善されますが、もしデータがレプリケートされる前に障害が発生した場合、データロスが起こりえます。どちらの選択肢も魅力的とは言えません。障害によって、レプリカのメンバーシップの変更が必要となります。このアプローチも面倒です。除去されるレプリカを再作成するのも高コストなので、このようなことを行うのは非常に保守的になります。この保守的な振る舞いは、レプリカを隔離するまで数分のダウンタイムが発生することを意味します。 クォーラムモデル Aurora は代わりにクォーラムモデルを採用し、データコピーのサブセットに対して読み込み、書き込みを行います。V 個のコピーを抱えるクォーラムシステムは形式的に 2つのルールに従うことになります。1つ目は、読み込みクォーラム(Vr)、書き込みクォーラム(Vw)が、少なくとも1つのコピーを共通に持つ必要があります。 この方法では、もし 3つのコピーがある場合に、読み込みクォーラム、書き込みクォーラムが 2となり、それぞれがもう一方を確認することができます。このルールにより、データ項目が、2つのトランザクションによって同時に読み込み、あるいは書き込みされないことが保証されます。また、読み取りクォーラムには、最新バージョンのデータ項目を含むサイトが少なくとも1つ含まれていることが保証されます。 2つ目は、書き込みに使用されるクォーラムは、以前の書き込みクォーラムと重複があることを保証する必要があります。これは、Vw > V/2 という式を満たすことにより簡単に保証されます。このルールにより、同じデータ項目に対して、2つのトランザクションによる2つの書き込み操作が並列に発生しないことが保証されます。ここにいくつかのクォーラムモデルを示します。 V (コピーの数) Vw (書き込みクォーラム) Vr (読み込みクォーラム) 1 1 1 2 2 1 3 2 2 4 3 2 5 3 3 […]

Read More

今すぐご利用可能 – Amazon Aurora with PostgreSQL Compatibility

昨年後半、Amazon Aurora に PostgreSQL 互換のエンジンを追加する計画をお話しました。このアナウンスのすぐ後に、プライベートベータを開始し、今年の前半にはオープンプレビューを開始しました。このベータとプレビューの期間、非常に素晴らしい数多くのフィードバックをいただき、このサービスがお客様のニーズを満たし、期待値を超えることが確かなものになるように、できる限りのことをしました! 一般利用可能に 本日、Amazon Aurora with PostgreSQL Compatibility が一般利用可能となり、4つのリージョンで利用できるようになったことをお伝えします(その他のリージョンは今後対応していきます)。本サービスは、PostgreSQL 9.6.3 と互換性があり、そのストレージは、64 TB まで自動的にスケールし、そのバックエンドで 6つのレプリカを持ち、性能と可用性を高めています。 Amazon Aurora with MySQL Compatibility のように、このエディションはフルマネージドで、簡単にセットアップし、利用できます。性能の観点ではお客様自身で運用していた PostgreSQL と比較して、最大3倍のスループットを期待することができます(我々がどのようにこれを実現したかについては、Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases をご確認ください)。 新たにアップデートされた RDS Console から PostgreSQL と互換性のある Amazon Aurora インスタンスを起動することができます。まず、Amazon Aurora をエンジンとして選択し、PostgreSQL-Compatible をエディションとして選択し、[Next] をクリックします。 そして、インスタンスクラス、シングル(開発、テスト環境向き)/Multi-AZ(本番環境向き) デプロイメントの選択を行い、インスタンス名、管理者パスワードを設定し、[Next]をクリックします。 インスタンスクラスは、6つのモデルの中から選択可能です(2 から 64 のvCPUと 15.25 から 488 […]

Read More