Amazon Web Services ブログ

Category: MySQL compatible*

AWS SCT と AWS DMS を使ってMySQLから Amazon Aurora に移行する方法

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。 データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。 一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。 多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。 このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。 同種間移行の方法 AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora […]

Read More

Amazon Aurora: MySQL 5.7互換をリリース

Amazon AuroraのMySQL 5.7互換版が皆様にご利用頂けるようになりました。JSONサポート、空間インデックス、generated columnsなどをご利用頂け、MySQL 5.7より最大5倍高速です。 Amazon Auroraの空間インデックスの作成は、MySQL 5.7よりも20倍以上の書き込みパフォーマンスと10倍以上の読み込みパフォーマンスとなっています。この機能がどのように実装されているかについては、AWSデータベースブログをご覧ください。またAmazon Auroraのドキュメントもご参照下さい。 Aurora with MySQL compatibilityがご利用頂ける13リージョン(US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Montreal), Europe (Ireland), Europe (Frankfurt), Europe (London), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), and Asia Pacific (Mumbai))全てでご利用頂けます。 ハイエンドな商用データベースのパフォーマンスと可用性を、オープンソースデータベースのシンプルさとコスト効率と組み合わせたAmazon Aurora (MySQLとPostgreSQL互換のリレーショナルデータベース)の詳細については、Amazon Auroraの製品ページをご覧ください。 CLIを用いた際のエンジンバージョンの指定方法や、スナップショットを利用したアップグレードなどAurora MySQL5.7互換に関する詳細な情報はドキュメントやフォーラムアナウンスをご覧ください。 […]

Read More

Amazon Aurora under the hood: Z-order curvesを用いたgeospatial indexの作成

Amazon Auroraのような高性能データベースシステムを設計する場合、一般的に最も幅広いワークロードを大きく改善出来るように取り組みたいと考えるかと思います。しかし時には、ゲームチェンジャーになりえる機会がある場合、特別な用途向けに改善を行うこともあります。 geospatial indexとはなにか、なぜ考慮する必要があるのか? 地理空間分析では、XY(Z)座標に沿った近さ、隣接性、重なりを識別することができます。 そのような分析を実行する必要があるアプリケーションには様々な例があります。タクシーアプリでは、利用可能な最寄りのタクシーを見つけることができます。不動産アプリは、サンフランシスコのPacific Heights地区で販売されている物件を探すことができます。 空間分析は、他にも多くの用途でも役立ちます: マーケティング – 店舗から2マイル以内のすべての見込み顧客をターゲットにプロモーションを行います 資産管理 – 顧客の位置と密度に基づいて影響を最小限に抑えるために修理ユニットを配置します リスク分析 – 顧客の居住地や職場の近くで車の盗難が発生した場合のリスクを見積もります 詐欺検出 – 前回のトランザクションからの距離に基づいて詐欺と考えられる取引の可能性を推定します ロジスティクス計画 – 運行の範囲を最小限にするように、トラブルのチケットを現場の技術者に割り当てます これらのアプリケーションは、高性能な空間データのインデックスから利益を得ることができます。残念なことに、Bツリーのような伝統的なインデックスは、Linlandのために作られたものであり、FlatlandやSpacelandではそうではありません。そのため、高性能な空間インデックスが必要です。 Rツリーとは? 最も一般的に使用される空間インデックスはRツリーです(詳細はこちらの論文を参照してください)。 MySQLとOracleはどちらもR-treeを使用しています。基本的な考え方は、バランスサーチツリーないにバウンダリーレクタングルを保存することです。リーフはデータポイントであり、各内部ノードは、その下のノードのミニマムバウンダリーレクタングルです。したがって、次の例では、長方形Aはリーフノードです。このノードは、矩形NおよびTによって順番に境界が作成されます。 Rツリーの主な問題は、安定していないことです(つまり、決定論的です)。挿入順序が異なると、異なるツリーが生成され、パフォーマンスの特性が大きく異なります。私たちのテストでは、ランダムな挿入順序では、最適な順序で構築されたツリーよりも1桁も性能が劣化したツリーが生成されました。これは、データの挿入順序が予測できず、変更可能なOLTP環境では明らかに問題になります。このような状況では、Rツリーは時間とともに性能が劣化します。1つの回避策は、データを定期的にインデックスを再構築することです。しかし、インデックスの再構築は負荷がかかります。加えて通常この作業は、手作業が必要であり、数時間かかることがあります。また、その期間中の他のトランザクションは遅くなる可能性があります。 そのため、Rツリーは人気がありますが、常に良好なパフォーマンスは得られません。 他にいい方法はあるのか? 私たちはそう考えています!トランザクションと同時実行に最適なデータ構造があります。それはBツリーです。 あらゆる場面で使用され、高いパフォーマンスを発揮するのはデータベースにとって基本です。 しかし、ちょっと待ってください。私はB-treeが多次元データに対してうまく機能しないと言いました。それは本当です。2次元を1次元にマップするトリックがあります。 私たちは、space-filling z-order curves(空間充填zオーダー曲線)を使用して行います。これは、ポイントのz値は、その座標値のバイナリ表現をインターリーブすることによって計算されます。zオーダー曲線は、これらの点をz値の順に横切る線です。たとえば、次の図は、0≤x≤7、0≤y≤7の整数座標の場合のz値を示しています(10進数と2進数の両方を示しています)。 zオーダー曲線上のBツリーの単純な実装では不十分です。なぜこれが当てはまるのかを知るために、以下の例を見てみましょう。緑色の四角形内のすべての点をBツリーで検索すると、クエリー領域外に30個の余分なz値(黄色い三角形の警告標識が付いている物)がスキャンされます。 元のクエリをより少ない偽陽性z値をカバーする小さなクエリに分割することで、この問題を改善します。(これを行うために幾つかの方法を使用していますが、それはこの記事でお伝えする範囲を超えています) それは私たちがポイントするために必要なものすべてを提示します。ポリゴンはどのように空間充填曲線で動作するのでしょうか?ポリゴンが単一点のように見えるまでズームアウトしたとします。どの程度ズームアウトしなければならないかは、ポリゴンの”レベル”によります。各空間オブジェクトは、オブジェクトのレベルとzアドレスの組み合わせとしてBツリーに格納されます。zアドレスがポイントのように見えるまでズームアウトしたので、zアドレスをポイントのように扱うことができます。他のシステムでは、このレベルを手動で指定する必要があります。明らかに、予測不可能で変更可能なデータを扱うOLTPシステムでは動作しません。このレベルはユーザーの設定なしで自動的に設定します。 Auroraのgeospatial indexesは、MySQL 5.7よりもselect-only(1秒当たりの読み込み回数)ワークロードで10倍以上、write-only(1秒当たりの書き込み回数)で20倍以上優れています。具体的には、サイズが1 GB未満のデータセットでSysbenchを使用して、AuroraとAmazon RDS for MySQL 5.7をdb.r3.8xlargeインスタンスを用いて計測しました。select-onlyのテストでは、2,000クライアントとST_EQUALSクエリを使用しました。write-onlyテストでは、4,000のクライアントを使用しました。 ご質問がある場合は、aurora-pm@amazon.comまでご連絡ください。 About the Author Sirish Chandrasekaran is a product […]

Read More

Amazon Aurora Under the Hood: クオーラムメンバーシップ

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 この記事は、Amazon Auroraがどのようにクオーラムを使用するのかをお話する4回シリーズの最後です。最初の記事では、障害が発生した場合に必要なクォーラムのメリットとメンバの最小数について説明しました。2回目の記事では、読み書きを行う際に利用するネットワーク帯域の増加を避けるために、ロギング、キャッシュの状態、および非破壊的な書き込みを使用する方法について説明しました。3回目の記事では、より高度なクォーラムモデルを使用して複製コストを削減する方法について説明しました。クォーラムに関するこの最後の記事では、クォーラムメンバーシップの変更を管理する際にAmazon Auroraが問題を回避する方法について説明します。 クオーラムメンバーシップの変更を管理するテクニック マシンは故障します。クオーラムメンバの1つが破損すると、ノードを交換することによってクオーラムを修復する必要があります。これは複雑な決定になります。 クォーラムの他のメンバーは、障害のあるメンバに一時的なレイテンシーの増加が発生したか、再起動のための短期間の可用性低下が発生したか、または永久にダウンしたかどうかを判断できません。 ネットワークパーティションにより、複数のメンバーグループが同時にお互いに隔離を実行出来ます。 ノードごとに大量の永続状態を管理している場合、クォーラムを修復するための状態の再複製には長い時間がかかります。 そのような場合、障害のあるメンバーが復帰できる場合に備えて修復を開始することについて慎重に行う必要があります。 多くのノードで状態をセグメント化することで、修復時間を最適化することができます。 しかし、これは失敗の可能性を高めます。 Auroraでは、データベースボリュームを10GBのチャンクに分割し、3つのアベイラビリティゾーン(AZ)に分散した6つのコピーを使用します。 現在の最大データベースサイズが64TBなので、プロテクショングループは6,400個、セグメント数は38,400個です。 このスケールでは破損は一般的に発生する可能性があります。 メンバーシップの変更を管理する一般的な方法は、一定期間リースを使用し、各リースでメンバーシップを確保するためにPaxosなどのコンセンサスプロトコルを使用することです。 しかし、Paxosは処理負荷のかかるプロトコルであり、最適化されたバージョンでは多数の障害が発生します。 障害を管理するためにクオーラムセットを利用する Auroraはメンバーシップの変更を管理するために、ロギング、ロールバック、コミットなどのクォーラムセットとデータベース技術を使用します。 A、B、C、D、E、Fの6つのセグメントを持つプロテクショングループを考えてみましょう。この場合、書き込みクォーラムはこの6組のうち4つのメンバーであり、読み取りクォーラムは3つのメンバーです。 前回の記事でご紹介したように、Auroraのクオーラムはこれよりも複雑ですが、今は単純に考えてみることにします。 Auroraの読み書きはそれぞれ、メンバーシップエポックを使用します。これは、メンバーシップの変更ごとに単調に増加する値です。 現在のメンバーシップエポックよりも古いエポックにある読み取りと書き込みは拒否されます。そのような場合、クオーラムメンバーシップの状態をリフレッシュする必要があります。 これは、概念的には、REDOログ内のlog sequence numbers(LSN)の概念に似ています。 エポックナンバーおよび関連する変更記録は、メンバーシップに順序付けられたシーケンスを提供します。 メンバーシップエポックを変更するには、データ書き込みと同様に書き込みクォーラムを満たす必要があります。 現在のメンバーシップの読み込みには、データの読み込みと同様のリードクオーラムが必要です。 ABCDEFのプロテクショングループの話を続けましょう。セグメントFが破損した可能性があるとし、新しいセグメントGを導入する必要があると考えてください。一時的な障害に遭遇する可能性があり、迅速に復帰する可能性があります。またはリクエストを処理しているかもしれませんが、なんらかの理由で検出出来ない可能性があります。また、Fが復活したかどうかを確認するのを待ちたくはありません。クオーラムが損なわれて2回目の障害が発生する可能性が増加だけです。 これを解決するためにクォーラムセットを使用します。 私たちはABCDEFからABCDEGに直接メンバーシップの変更をすることはありません。代わりに、メンバーシップのエポックを増やし、クォーラムセットをABCDEFとABCDEGに移動します。書き込みはABCDEFの6つのコピーのうち4つから正常に行われなければならず、またABCDEGの6つのコピーのうち4つからackが返る必要があります。 ABCDEのどの4つのメンバーは両方とも書き込みクォーラムを満たしています。 読み取り/修復クォーラムは同じように動作し、ABCDEFからの3つのackとABCDEGから3つのackが必要です。ABCDEからの3つのいずれかが両方を満たします。 データがノードG上に完全に移動され、Fを取り除くと決定した場合、メンバーシップエポックの変更を行い、クォーラムセットをABCDEGに変更します。エポックの使用は、コミットLSNがREDO処理のために行うのと同様に、これをアトミックに行います。このエポックの変更は、現在の書き込みクォーラムが満たされている必要があり、他のアップデートと同様に、ABCDEFの6つのうち4つと、ABCDEGの6つのうちの4つからのackが必要です。Gが利用可能になり前に再びノードFが利用可能になると、変更を元に戻しメンバーシップエポックの変更をABCDEFに戻します。完全に健全なクオーラムに戻るまで、いかなる状態やセグメントも破棄しません。 このクォーラムへの読み書きは、メンバーシップの変更中に、変更前または変更後と同じように行われることに注意してください。 クォーラムメンバーシップへの変更は、読み取りまたは書き込みをブロックしません。失効したメンバーシップ情報を持つ呼び出し元は、状態をリフレッシュして正しいクォーラムセットに要求を再発行します。また、クオーラムメンバーシップの変更は、読み取り操作と書き込み操作の両方に対して非ブロッキングです。 もちろん、Fの代わりにGへデータを移動しクオーラムを修復している間にABCDEGのいずれかが破損する可能性もあります。多くのメンバーシップ変更プロトコルはメンバーシップの変更中に障害を柔軟に処理しません。クォーラムセットとエポックでは、簡単です。Eも破損してHに置き換えられる場合を考えてみましょう。ABCDEFとABCDEGとABCDFHとABCDGHのクオーラムに移動するだけです。単一障害と同様に、ABCDへの書き込みはこれらのすべてを満たします。メンバーシップの変更は、読み取りと書き込みの失敗と同じ範囲になります。 まとめ クォーラムセットをメンバーシップの変更に使用することにより、Auroraは小さなセグメントを使用することができます。これにより、Mean Time To Repair(MTTR)および複数の障害に対する可能性を削減することで、耐久性が向上します。また、お客様のコストを削減します。Auroraのボリュームは必要に応じて自動的に増加し、小さなセグメントでは少しずつ増加します。クォーラムセットを使用することで、メンバーシップの変更が行われている間も読み取りと書き込みが継続できるようになります。 メンバーシップの決定を元に戻すことができれば、積極的にクオーラムを変更することができます。障害のあったメンバーが返ってくると、いつでも変更を元に戻すことができます。いくつかの他のシステムでは、リースが期限切れとなり、クオーラムメンバシップを再確立する必要があるため、定期的な停止が発生します。Auroraは、リースが期限切れになるまでメンバーシップの変更操作を延期するという耐久性の犠牲を払わず、クオーラムメンバシップが確立されている間に読み込み、書き込み、またはコミットを遅らせるというパフォーマンス上のペナルティも発生しません。 Auroraは、さまざまな分野で進歩を遂げています。データベースと分散システムを統合するアプローチは、これらの多くの中核を成しています。クォーラムをどのように使用するかについてのこの連載をご覧いただき、ご自身のアプリケーションやシステムを設計する方法について考えるときに役立てて頂けると思います。今回使用した手法は広く適用可能ですが、スタックの多くの要素にに対して適用する必要があります。 もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。 翻訳は星野が担当しました (原文はこちら)

Read More

Amazon Aurora Under the Hood: クオーラムセットを使ったコスト削減

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 このポストはAmazon Auroraが利用しているクオーラムの仕組みについての4回の連載の3本目です。このポストを皆様がご自身で分散システムをデザインする際に活用頂けると幸いです。今回は、クオーラムシステムでどのようにコストを管理するかについてご説明します。 私たちが取り組んでいる基本的な問題は、Auroraが6つのアベイラビリティゾーン(AZ)に分散した6つのクォーラムを使用し、6つのコピーのうち4つを使用して書き込みを行い、読み取り/修復のために6つのコピーのうち3つを使用することです。 このシリーズの最初の記事では、なぜ6つが最小限必要なコピー数であるのかをご説明しました。 2番目の記事では、書き込みと読み取りの両方でクォーラムのパフォーマンスの低下を避ける方法について説明しました。 しかしそれはまだ多くのデータのコピーであり、コストが多くかかります。 Amazon Auroraのストレージが低価格なのは、何か特別なことをしているのではと考えさせるきっかけになるかもしれません。 私たちが何をしているか理解するためには、クオーラムの基本的な定義に戻る必要があります。 一般的に、クオーラムについて書き込み用のセットが大部分の要素を表し、読み書きで必要なセットが重複していいると表現します。 これは正しいのですが、単純化された説明です。 基本的な要件は、読み取りと書き込みのセットがすべてのクオーラムメンバーシップセットのサブセットであることです。正当な書き込みサブセットの場合、少なくとも1つのメンバーも正当な読み取りサブセット内に含まれ、各書き込みサブセットは以前の書き込みサブセットと重複します。 同じように思えますが、そうではありません。 違いは、クオーラムメンバーが互いに同じであるという要件はないということです。 異なるレイテンシ、コスト、または耐久性の特性を持つクォーラムサブセットをうまく組み合わせてクォーラムセットを構築できます。 ブール論理のルールを使用して、完全なクオーラムのクオーラムメンバシップ要件を満たすために、各サブセットにわたってより高度な読み書きルールを作成することができます。 それでは、コストを削減するためにAuroraではこれらをどのように行っているのかを見てみましょう。 Mixing full and tail segments of data Auroraでは、データベースボリュームは10GBのデータセグメントで構成されています。 これらのセグメントはプロテクショングループとして複製され、6つのコピーが3つのAZに分散しています。 しかし、6つのコピーはすべて同じではありません。 コピーの半分はフルセグメントで、ボリュームの10GB部分のデータページとログレコードの両方を含んでいます。 残りの半分は、ログレコードのみを含むテールセグメントです。 各AZには、1つのフルセグメントと1つのテールセグメントが含まれています。 ほとんどのデータベースには、REDOログストレージよりもはるかに多くのデータブロックストレージがあります。 フルセグメントとテールセグメントを組み合わせて使用すると、Auroraの物理ストレージに必要な要件がデータベースの6倍から、3倍より少し多い程度になります。 “AZ+1″の障害に耐えるように設計されたシステムでは、これは最小限のレプリケーションファクターです。 フルセグメントとテールセグメントの組み合わせを使用すると、読取りセットと書込みセットをどのように構築する必要があるかが変わります。 ブール論理のルールを使用して、サブセット間の重複を保証し、メンバーの複雑な分布に対しても正確にそれを行うことができます。 Auroraでは、書き込みクオーラムは6つのセグメントのうち任意の4つ、または3つのフルセグメントのうち3つです。 読み込みクォーラムは、6つのセグメントのうち任意の3つと3つのフルセグメントから1つです。 このことから、クォーラム内のすべてのセグメントに重複があり、フルセグメント上に重複があることがわかります。 これにより、以前に行った6つのセグメントのうち4つにログレコードを書き込むことができます。 これらのうち少なくとも1つはフルセグメントであり、データページを生成します。 前回の記事で説明した最適化を使用して、フルセグメントからデータを読み込み、クオーラムの読み取りを回避しすることで必要なデータを持っているものから読み込むことが出来ます。 破損したセグメントを再構築し、問題のあるクォーラムを修復する方法として読み込みクォーラムを使用します。 また、データベースのマスターノードを再起動する必要がある場合は、ローカルの状態を再構築するためにも使用します。 テールセグメントの1つが破損した場合は簡単です。 単純なクオーラムモデルと同じように他の3つのコピーのいずれかから修復します。 フルセグメントの1つが破損した場合、もう少し複雑です。 破損したものは、書き込みの一部として書き込んだもののコピーであった可能性があります。 しかしその場合、最新の書き込みを見ていなくても、別の完全なセグメントがあります。 また、フルセグメントを最新なものに再構築できる十分なREDOログレコードのコピーがあります。 また、クォーラムのセグメント間をゴシップを利用して、不足している書き込みをすばやく埋めることができます。ここれにより、書き込みパスにパフォーマンスの負担をかけることなく、フルセグメントを再構築する必要がなくなります。 異なるメンバーのクォーラムセットによるコストの管理 異なるメンバーのクォーラムセットを使用すると、コストを抑えることができます。 […]

Read More

Amazon Aurora Under the Hood: クオーラムの読み取りと状態の遷移

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 前回の投稿では、クォーラムモデルの利点をお話しました。レイテンシーの異常値や短期間のダウンタイム、ディスクとノードの長期的な喪失に直面して、このようなシステムがいかに耐久性があるかについて説明しました。この投稿は、1つの疑問を提起します – もし、クオーラムがとても素晴らしいのであれば、なぜ皆使わないのでしょうか? クォーラムシステムにおける読み取りの性能劣化 1つの問題は、クォーラムシステムでは読み取りが遅くなることです。クォーラムモデルでは、読み込みクォーラム、書き込みクォーラムともに、少なくとも1つのメンバーが必要です。 Amazon Aurora のような6つのメンバーを持つクォーラムシステムでは、書き込みクォーラムの 4 つメンバーを持ちながら、3つのデータのコピーを読み込む必要があります。これは不運です。データベースのページを読み取る場合、通常、バッファキャッシュにヒットしなかったことを意味し、次の処理に進む前に、I/O 処理を待って、SQL 文がブロックされます。3つのデータのコピーを読むには、およそ5回アクセスすることで、異常値を含むレイテンシーや一時的に発生する可用性の問題に対処するのが良いでしょう。そのようにすることは、ネットワークに大きな負荷をかけることになります。データベースページは、かなり大きく、読み取りによる増幅は容易に想像できます。クォーラムシステムの読み取りパフォーマンスは、従来のレプリケーションシステムと十分に比較されているとは言えません。従来のレプリケーションシステムでは、データがすべてのコピーに書き込まれますが、読み取りは、そのうちのどれか1つへアクセスします。 しかしながら、Aurora は、書き込み中、クォーラムによる増幅を避けています。Aurora では、6つのコピーに対して書き込みを行いますが、ログレコードしか書き込みません。データページの全領域を書き込むわけではありません。データページは、以前のバージョンのデータページと送られてくるログを元にストレージノードで組み立てられます。また、非同期に書き込むことができます。これらは読み取りには対応できません。 読み込みクォーラムのオーバーヘッドを避ける方法 読み込みクォーラムのオーバーヘッドは、クォーラムシステムにとって明らかに不利な点です。どのように避けることができるでしょうか?鍵となるポイントは、状態(state)を使うことです。 ノードをスケールさせるに伴い、一貫した状態を管理し、調整するのが難しいため、分散システムにおいて、状態という単語はしばしばよくないワードとして考えられ、不具合を引き起こします。もちろん、データベースシステムの全目的は状態を管理し、原子性、一貫性、独立性、永続性(ACID)を提供することです。Aurora は、これら二つの技術領域が交わる点に位置します。我々のイノベーションの大部分は、1つの領域のコンセプトを適用し、もう1つのドメインの進化を推し進めることから生まれています。 もっとも、通信なしに分散されたそれぞれの状態を一致させることは困難ですが、一致、調整、またはロックの必要性を避けるために利用できる一貫性のローカル領域があります。ここで紹介できる例としては、リードビューがあげられます。多くのデータベースシステムでも同様のコンセプトを持っていますが、ここでは MySQL にフォーカスします。 全てのリレーショナルデータベースと同様に、MySQL は ACID をサポートします。リードビューは論理的な時点を確立します。SQL 文は、その時点より前にコミットされた全ての変更を参照可能となり、まだコミットされていない変更は参照できないようにならなければいけません。MySQL では、直近のコミットのログシーケンス番号(LSN)を確立することで、これを実現しています。このアプローチにより、既にコミットされているすべての変更が参照可能となることが保証され、アクティブなトランザクションの一覧を利用することで、参照されてはならない変更の一覧を作成します。特定のリードビューに対するSQL 文がデーターページをチェックする際、その SQL 文がリードビューを確立した時点でアクティブだったトランザクションに対するいかなる変更も見えなくする必要があります。たとえ、これらの変更が現在コミットされたものであったとしてもこれは同様であり、リードポイントコミット LSN の後に開始された全てのトランザクションについても同様です。トランザクションがリードビューを確立した際に、一貫性のある時点に適切に戻すことができるのであれば、システムで実行されるいかなる変更からも、そのトランザクションから分離できます。 読み込みクォーラムにおいて、これをどう実現すれば良いでしょうか?全てです。データベースは、ストレージノードに対して継続的に書き込みを行います。ACK を受け取るたびに、データベースは各変更が堅牢なものであるとマークします。それ以前の全ての変更がそれぞれ堅牢であると登録されると、ボリュームポイントが堅牢であると更新されます。参照リクエストが来ると、そのリクエストは、データベースが参照しなければならない リードポイントコミット LSN を持ちます。 そのリクエストは、データベースによって、リードポイントコミットLSN を処理可能なことが分かっているストレージノードへと単に転送されます。 このアプローチでは、簿記のように状態管理を行うことによって、クォーラムの読み取りを回避します。その代わり、必要とするデータバージョンを把握しているノードから読み取りを行います。このアプローチにより、ネットワーク、ストレージノード、データベースノードで行われる通信を大幅に抑えられます。 レイテンシーを避ける方法 しかしながら、読み込みクォーラムを避けることによって、単一のストレージノードのレイテンシーに左右されることになります。これについては、ストレージノードに対する読み取りリクエストのレスポンスタイムをトラックすることにより対応してます。通常、読み取りリクエストは最もレイテンシーの低いノードに対して行われます。レイテンシーの情報を最新に保つため、時折、その他のノードに対してもクエリされます。 これは、1つのデータベースノードに対しては非常に分かりやすい作業です。なぜなら、全ての書き込みを認識し、全ての読み込みを調整することができるからです。リードレプリカのことを検討する場合、より複雑です。 Aurora では、リードレプリカは同じストレージボリュームを共有します。同時にマスターデータベースノードから、非同期にマスターの redo ログストリームを受け取り、キャッシュ上のデータページを更新します。このアプローチは、コストの観点で最も安いというだけではなく、データロストや同期レプリケーションによる書き込みレイテンシーなしに、レプリカのマスターノードへの昇格を可能にします。マスターノードへの ACK によりコミットされたとマークされた変更は、たとえレプリカにまだ伝播していなかったとしても、すべて堅牢です。これらのレプリカノードは、それぞれで読み込みを行い、書き込みとその ACK を見ることはできず、それにより何を読み込むべきか把握することはできません。 […]

Read More

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