Amazon Web Services ブログ

Category: Amazon Aurora

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 RDS for PostgreSQL から Amazon Aurora PostgreSQL リードレプリカを作成可能になりました

Amazon Aurora PostgreSQL リードレプリカ(2018/1/23現在英語版ドキュメントのみとなっています)を Amazon RDS for PostgreSQL のインスタンスとして作成し、継続的に Amazon Aurora PostgreSQL へレプリケーション出来るようになりました。これにより、実稼働ワークロードを Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL に移行する際、アプリケーションとユーザーを Amazon Aurora PostgreSQL へ移す準備ができるまで、インスタンスタイプを同期させておくことで、ダウンタイムを最小化させることが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

暗号化されたスナップショットを Amazon Aurora PostgreSQL へ移行可能になりました

Amazon RDS for PostgreSQL の暗号化されたスナップショットから Amazon Aurora PostgreSQL へ移行できるようになりました。これにより、Amazon RDS から Amazon Aurora へ移行中の間も、データ暗号化を維持することが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

Microsoft Azure SQL Database から Amazon Aurora への移行

Oracle や Microsoft SQL Serverなどのライセンスが必要なエンジンから、AWS上で稼働するオープンソースエンジンへ移行する気運がますます高まっています。対象データの移行先として Amazon Aurora が選ばれています。この投稿では AWS Database Migration Service (AWS DMS) を用いた Microsoft Azure SQL database から Amazon Aurora MySQL クラスタへの移行方法を紹介します。 前提条件 この記事では、Azure SQLデータベースが既にインストールされていることを前提としています。移行には、このデータベースの接続情報(DNSエンドポイント、ユーザー名、パスワードなど)が必要です。また、移行作業に使用するユーザには、Azure SQLデータベースのデータにアクセスするための適切な権限が必要です。 記事の目的に合わせ、ターゲット(移行先データベース)として Amazon Aurora クラスタを作成します。 AWS DMSはソース(移行元データベース)およびターゲットとして、様々なデータベースエンジンをサポートしていますが、多くのお客様は独自のストレージエンジンを使用したAmazon Auroraを選択します。このエンジンは、3つのアベイラビリティゾーンに跨る耐久性、自動ポイントインタイムバックアップ、最大15台の低レイテンシ読み取りレプリカを実現します。 ターゲット用の Aurora クラスタを既に作成している場合は、新規に作成する必要はありません。新しい Aurora クラスタを作成する場合は、Amazon Aurora DB クラスタ作成の手順を参照してください。 AWS DMS インフラのセットアップ ここまででソースとターゲットの情報が確認できたので、AWS DMS インフラを設定していきましょう。 AWS DMSは非常に高い柔軟性をもつ為、多くのコンポーネントから構成されています。AWS CloudFormationを使用することで、これらのコンポーネントをまとめて単一の「スタック」にグループ化し、原子性を保った1つのユニットとして何度も再作成することができます。 AWS CloudFormation のコンソールを開いて設定を始めます。 […]

Read More

AWS DMS と Amazon Kinesis Data Firehose を利用した Aurora PostgreSQL データベースへのストリームデータのロード

AWS Database Migration Service (AWS DMS) を利用することで、様々なデータソースから商用データベースやオープンソースデータベースへとデータを移行できます。このサービスでは、Oracle Database から Oracle Database への移行といった同一のDBMS製品間での移行をサポートしています。また、Oracle Database から Amazon Aurora, Microsoft SQL Server から MySQL へといった異なるプラットフォーム間での移行もサポートしています。さらに、ストリーミングデータを Amazon S3 から Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server を含む様々な移行先へ配信することが可能です。 Amazon Kinesis Data Firehose は、AWS へストリーミングデータをロードする上で、最も簡単な方法です。ストリーミングデータのキャプチャ、変換を行い、Amazon Kinesis Data Analytics, Amazon S3, Amazon Redshift, Amazon Elasticsearch Service へロードできます。Firehose を利用することで、すでに利用しているビジネスインテリジェンスツールやダッシュボードを使い、ニアリアルタイム分析が可能となります。Firehose はお客様が送信するデータのスループットに合わせて自動的にスケールするフルマネージドサービスで、継続した運用管理を必要としません。Firehose は、ロード前にデータをまとめ、圧縮し、暗号化することで、ロード先のストレージで必要な容量を最小化したり、セキュリティを向上させたりすることができます。 AWS DMS […]

Read More

Amazon Auroraを使用したMagento Content Servicesの構築をAWS Quick Startで加速させる

AWS Quick Startでは、2015年9月にオープンソースのコンテンツ管理システムであるMagentoを初めてリリースしました。最初のリリース以来、このQuick Startは常にお客様に最も人気のあるQuick Startのトップ10に入っています。 2017年10月、AWS Quick Start for Magentoのアップデートをリリースしました。Amazon Aurora MySQL-compatible editionのサポートが追加されました。また、Magentoのバージョンを2.1.2にアップデートしました。更新されたMagentoのQuick Startを利用することで、最新のMagentoバージョンでAuroraのパフォーマンスとスケーラビリティを使用して、コンテンツシステムの構築を迅速に行うことが出来ます。 数年前にAmazon Auroraの開発を開始した際に、私たちは次のような考え方を念頭に置いていました: ハイエンドの商用データベースのパフォーマンスと可用性を、オープンソースのシンプルさとコスト効率で実現 一般的なオープンソースデータベースであるMySQLとの完全な互換性を提供し、既存のアプリケーションを変更する必要がない アプリケーションの開発に専念できるように、データベースをマネージドデータベースとして提供することで管理コストを軽減 最新アプリケーションのスケーラビリティのニーズを満たすクラウドネイティブデータベースを提供 すでに何千もの顧客やパートナーが、Amazon AuroraMySQL-compatible editionを採用しています。お客様とISVパートナーは、様々なデータベースからAmazon Auroraに移行を行っています。オンプレミスデータベースからAmazon Auroraに移行されるお客様や、Amazon EC2上のMySQLまたは商用データベースからAmazon Auroraに移行を行うお客様もいらっしゃいます。 Magento on AWS with Amazon Aurora Magentoは、e-commerceウェブサイト用のオープンソースのコンテンツ管理システムです。セラーと開発者はオープンアーキテクチャ、柔軟性、拡張性(何百もの拡張機能)を評価しています。また、独自のニーズに合わせて、バックエンドのワークフローを調整できます。 Magento Community Edition(Magento CE)とMagento Enterprise Edition(Magento EE)は、我々のお客様に人気があります。多くのお客様は、Anchor Hosting、Elastera、Tenzing、Razorfish、OptarosなどのAWSパートナーを利用してMagentoをAWSでホストしています。他の企業はAWS MarketplaceからMagentoを起動しています。 Magentoを検索すると、2015年の20件から70件以上のリストが返されるようになりました。さらに、MagentoのAWS Quick Startを直接利用している企業もあります。 Amazon AuroraはMySQLと互換性があるため、MagentoのAWS Quick Startを更新するのは簡単です。新しいQuick Startでは、Magentoまたはその設定を変更する必要はありません。今使用しているコード、ツール、アプリケーションを、Amazon Auroraと既存のMySQLデータベースと併用することが可能です。 MagentoのAWS Quick Startを使用してデプロイした場合は、Amazon RDS […]

Read More

Amazon Aurora Multi-Master のプレビュー申し込み開始

Amazon Aurora Multi-Master は、複数のアベイラビリティゾーンにわたって複数のRead/Writeマスターインスタンスを作成することができます。これによって、リードレプリカで現在できることと同様に、アプリケーションは1つのクラスター内の複数のデータベースインスタンスを読み書きできるようになります。 Multi-MasterクラスターはAuroraの高可用性を向上させます。複数インスタンス内の1つが落ちたとしても、クラスター内のその他のインスタンスに即座に引き継がれます。インスタンス障害やAZ全体障害が起きたとしても、アプリケーションのダウンタイムほぼゼロで、読み書きの可用性が維持されます。 現在のSingle-MasterのAuroraは、1つのクラスター内に1台の書き込みインスタンスと最大15台の昇格可能なリードレプリカをサポートし、書き込みインスタンスはr4.16xlargeで秒間200,000書き込みを実行できます。Aurora Multi-Master であれば、より高い書き込みスループットを必要とするワークロードであっても、マスターインスタンスを追加することで書き込みを水平方向にスケールアウトさせることができます。 このプレビューはMySQL互換のAuroraで使用でき、サインアップフォームに記入することで参加できます。 Aamazon Aurora はオープンソースデータベースのシンプルさとコスト効率、およびハイエンド商用データベースのパフォーマンスと可用性を両立した、完全マネージドなリレーショナルデータベースです。 Aurora Multi-Master プレビュー: サインアップ (翻訳はSA柴田が担当しました。原文はこちら)

Read More

In The Works – Amazon Aurora Serverless

既にご存知の通り、Amazon AuroraはMySQL互換とPostgreSQL互換があり、マネージドサービスで自動的に64TBまでスケールアップするデータベースストレージ’を備えています。Auroraデータベースインスタンスを作成する際に必要なインスタンスサイズの選択や、リードスループットを向上させるためにリードレプリカを作成するかどうかのオプションを選択します。処理の需要やクエリ数の増減に応じて、インスタンスサイズやリードレプリカの数を必要に応じて変更可能です。このモデルはリクエスト数や負荷などのワークロードが予測し易い場合はうまくいきます。 しかし、場合によっては1日や1週間の間に数時間、もしくは数分間だけリクエストがスパイクするようなワークロードの割り込みがあったり予測が難しいケースがあります。セールや1回だけもしくは不定期イベント、オンラインゲームや日時・週次のレポーティング、dev/test、新規アプリケーションなどが当てはまります。適切なキャパシティに調整し続けるためには多くの作業が必要です、そのため安定している状態を基準として支払いを行うほうが懸命です。

Read More

Amazon DynamoDB からのデータストリームを AWS Lambda と Amazon Kinesis Firehose を活用して Amazon Aurora に格納する

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。 はじめに AWS ワークロードを実行するお客様は Amazon DynamoDB と Amazon Aurora の両方を使用していることがよくあります。Amazon DynamoDB は、どのような規模でも、一貫した、数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高い NoSQL データベースサービスです。データモデルの柔軟性が高く、パフォーマンスが信頼できるため、モバイル、ウェブ、ゲーム、広告、IoT、他の多くのアプリケーションに最適です。 Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、オープンソースデータベースのコスト効率性と簡素性を備えた、高性能の商用データベースの可用性とスピードをあわせもったエンジンです。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。 DynamoDB と Aurora を連携させるために、カスタムウェブ解析エンジンを構築して、毎秒数百万のウェブクリックが DynamoDB に登録されるようにしたとします。Amazon DynamoDB はこの規模で動作し、データを高速に取り込むことができます。また、このクリックストリームデータを Amazon Aurora などのリレーショナルデータベース管理システム (RDBMS) にレプリケートする必要があるとします。さらに、ストアドプロシージャまたは関数内で SQL の機能を使用して、このデータに対してスライスアンドダイスや、さまざまな方法でのプロジェクションを行ったり、他のトランザクション目的で使用したりするとします。 DynamoDB から Aurora に効率的にデータをレプリケートするには、信頼性の高いスケーラブルなデータレプリケーション (ETL) プロセスを構築する必要があります。この記事では、AWS Lambda と Amazon […]

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