Amazon Web Services ブログ

98、99、100 か所の CloudFront 接続ポイントを提供

9 年前のことになりますが「Amazon CloudFront でコンテンツを分散させるには (Distribute Your Content with Amazon CloudFront)」というブログを書いたことがあります。2008 年のリリース以来、14 の接続ポイントで始まった CloudFront は急速な拡大を遂げてきました。そして本日、100番目の接続ポイントを東京で 5 番目の、そして日本で 6 番目の接続ポイントとして提供を始めました。89 か所のエッジロケーションと 11 か所のリージョン別エッジキャッシュを備えた CloudFront は、世界中の何百万ものユーザーが生成するトラフィックをサポートするようになりました。 23 か国、50 都市、今後もさらに増加 100 か所の接続ポイントは世界中の 23 か国 50 都市で展開されています。過去 12 か月間に渡りネットワークサイズを 58% 拡大、次の 9 都市を含む 37 か所の接続ポイントを追加しました。 ベルリン (ドイツ) ミネアポリス (米国ミネソタ) プラハ (チェコ共和国) ボストン (米国マサチューセッツ) ミュンヘン (ドイツ) ウィーン (オーストリア) クアラルンプール (マレーシア) フィラデルフィア […]

Read More

AWS HIPAA 利用資格の更新 (2017 年 10 月) – 16 の追加サービス

「医療顧客の事例 (Health Customer Stories)」 ページでは、AWS で実行するヘルスケアやライフサイエンスのアプリケーションを構築し実行している数多くのお客様の中から数件をご紹介しています。Verge Health や Care Cloud、Orion Health といったお客様は、HIPAA や HITECH の規制に準拠する取り組みの一環として、保護されるべき医療情報 (PHI) や個人識別情報 (PII) において AWS に信頼を寄せています。 その他 16 のサービス 前回の「HIPAA 利用資格の更新 (HIPAA Eligibility Update)」と題したブログでは、HIPAA 利用資格サービスのリストに 8 つのサービスを追加したことについてお知らせしました。そして本日、それに加え 16 のサービスをリストに追加し、ご利用可能なサービスの合計数はこれで 46 件になりました。次に、今回追加したサービスの簡単な概要と過去のブログ記事へのリンクをご紹介します。 PostgreSQL と互換性を持つ Amazon Aurora – Amazon Aurora に追加したこのサービスは、AWS Key Management Service (KMS) で作成し管理するキーを使用してリレーショナルデータベースを暗号化できるようにします。Amazon Aurora データベースで暗号化を有効にすると、基盤となるストレージが暗号化されます。また、自動バックアップやリードレプリカ、スナップショットにおいても同様です。詳しくは「Amazon Aurora の保管時の暗号化 (Read New […]

Read More

Amazon CloudWatch で GPU 使用率をモニタリング

GPU には何千ものコアがあるため、ディープラーニングには大量のマトリックス乗算と GPU (グラフィックス処理ユニット) により並列化できるベクトルオペレーションが必要です。アマゾン ウェブ サービスでは P2 または P3 インスタンスにサインアップすることが可能です。このようなインスタンスは、大規模なディープニューラルネットワークのデプロイの加速化を強調する MXNet のようなディープラーニングフレームワークの実行に優れています。 データサイエンティストや開発者はネットワークを微調整する場合、適切なバッチサイズを使用できるように GPU 使用率を最適化したいと考えています。今回のブログでは、Amazon CloudWatch メトリクスを使用して GPU とメモリ使用量をモニタリングする方法をご説明します。Amazon マシンイメージ (AMI) では、インスタンスが Amazon Deep Learning AMI を使用することを勧めています。 GPU を有効にしたインスタンスのモニタリングや管理をサポートするために使用されている現在の一般的な方法は、コマンドラインユーティリティの NVIDIA システム管理インターフェイスを利用することです (nvidia-smi)。nvidia-smi の使用により、ユーザーは GPU 使用率、メモリ消費量、ファンの使用量、電力消費量、そして NVIDIA GPU デバイスの温度などの情報をクエリすることができます。 nvidia-smi は NVIDIA 管理ライブラリをベースにしているので (NVML)、C ベースの API ライブラリを使用し、カスタムメトリクスとして Amazon CloudWatch に送信するのと同じデータポイントをキャプチャできます。このライブラリに関する詳細については「リファレンスマニュアル (reference manual)」をご覧ください。このブログではライブラリに Python ラッパーの pyvnml を使用します。 […]

Read More

AWS がエモリー大学とのコラボレーションを通じ、Apache MXNet を活用したクラウドベースの NLP 研究プラットフォームを開発

自然言語処理 (NLP) は、コンピュータプログラムに人間の言語 (自然言語) を理解させるという、人工知能の研究分野のひとつです。NLP についてあまりご存じない方でも、日々の生活の中でこれを使っている可能性は高いでしょう。携帯電話の仮想キーボードで文字入力を行う際、入力内容の分析結果に基づき、次に打ち込むべきであると予測される単語がリスト表示されます。これは言語モデリングと呼ばれ、入力された単語にどの単語が続くかの確率をその内容に基づいて測定する技術であり、NLP の中核的タスクのひとつです。NLP はすでに多くのアプリケーションに採用されており、世の中を大きく変えつつあります。 エモリー大学の NLP 研究グループである Evolution of Language and Information Technology (ELIT) チームは、研究者たちに最先端の NLP と機械学習テクノロジーをもたらす取り組みを行っています。ELIT プロジェクトは、AWS クラウドの豊富なリソースを活用し、ビッグデータ解析に向けたスケーラブルなエンドツーエンドの NLP パイプラインを提供することに主眼を置いています。他の多くの NLP フレームワークとは異なり、ELIT はウェブ API をサポートすることで、プラットフォームに依存しない体制を実現しています。そのお陰で、研究者たちはいつでもどこでも大規模なコンピューティングを利用できます。また、ELIT プロジェクトは、GitHub にも参加しています。これは、エモリー大学の NLP 研究グループが AWS の MXNet チームとの緊密なコラボレーションの下で立ち上げたサービスです。今回のブログ投稿では、ELIT のプラットフォームをご紹介するとともに、そこで活用されているウェブ API や、NLP の可視化についてもご説明します。 ELIT の研究用プラットフォーム 近年、NLP においてディープラーニングが盛んに活用され始めた結果、機械学習に基づく NLP モデルには多大な計算処理能力が要求されるようになり、研究者たちは強力なマシンなしには NLP の最新技術をフル活用できなくなっています。AWS のようなクラウドコンピューティングプラットフォームは、研究者たちがこれらのモデルを実行できるよう、無制限のコンピューティングリソースを提供します。しかしこれは、クラウドにさほど通じていない方々にとっては面倒でもあるでしょう。そこで ELIT プロジェクトが目指すのは、NLP のためのウェブサービスを提供し、インターネット接続さえあれば誰でもリクエストを行えるようにすることです。つまり、ローカルインストールは不要ですし、クラウドコンピューティングに関する予備知識も必要ありません。では、感情分析などの一般的な NLP […]

Read More

Amazon Rekognition とグラフデータベースを使って映画スターのソーシャルネットワークを理解する

Amazon Rekognition は、イメージの分析をアプリケーションに簡単に追加できるようにする AWS サービスです。ディープラーニングを活用したこのコンピュータビジョン向け API に追加された最新機能が、有名人の認識です。この使いやすい機能は、各分野の有名人や著名人を多数検出、認識します。このツールにより、ユーザーは自身の関心に基づいて有名人のデジタルイメージライブラリのインデックスを作成し、検索することができます。 当社のお客様が個人に関するデータの保存に用いる一般的な方法の 1 つが、グラフデータベースです。過去のブログ投稿で詳しく説明したとおり、Facebook や LinkedIn、Twitter といった企業は巨大な関係性ネットワークの管理能力を通じ、社会が相互に関わり合う方法を革新してきました。このブログ投稿の目的は、Rekognition の有名人の認識および顔認識機能をグラフデータベースに保存された関係情報に組み合わせるのがいかに簡単かをご紹介することです。 これらのテクノロジーを組み合わせることで、お客様は 1 枚の写真を通じて、その写真に含まれる人物が他の関心対象である人物とどのように関連しているかを把握できます。さらに、2 枚の写真を送信し、それぞれの写真に含まれる人々の間にどのような相互関係があるかを素早く見極めることも可能です。この関係マッピングを活かしたコミカルな例が、有名な Six Degrees of Kevin Bacon (ケヴィン・ベーコンとの六次の隔たり) ゲームです。しかし、このようなアプリケーションのビジネス価値は実に大きなものです。法執行機関は 2 枚の写真を基に Rekognition を活用して各人物の身元を特定し、グラフデータベースを参照して関心対象である 2 名の人物が知り合いかどうかを突き止めることができます。同様に、ホスピタリティ企業は Rekognition とグラフデータベースを使って敷地内にいる有名人を素早く特定し、その人物の知り合いである他の有名人のうち、近隣に宿泊している人物を把握できます。 このブログ投稿では、グラフデータベース (ここでは Neo4j Community Edition を使用) を採用した Rekognition と、D3.js ライブラリを使用した Jupyter Notebook の併用方法のデモンストレーションをご紹介します。 設定 このテクノロジーの組み合わせの使用を開始するには、まず AWS ラボの Github リポジトリからプロジェクトのコピーを取得します。  プロジェクト構成には 2 つの主なエリアが含まれます。 <project […]

Read More

見逃していませんか? 最近公開された AWS サービスの概要

目を疑うほどの数のリリースやクラウドの最新技術が開発されています。今回のブログでは、この夏から秋の終わりまでにリリースされた優れたサービスや機能の近況報告の概要を紹介します。 今回ご紹介するサービスと機能: RDS MySQL と Amazon Aurora で行うデータベースユーザー認証の AWS IAM Amazon SES 評価ダッシュボード Amazon SES オープンおよびクリックのトラッキングメトリクス ソリューションビルダーチームによるサーバーレスイメージハンドラ ソリューションビルダーチームによる AWS Ops Automator では、詳しい内容を見てみましょう。 RDS MySQL と Amazon Aurora で行うデータベースユーザー認証の AWS IAM AWS IAM を使用して、Amazon RDS データベースインスタンスやクラスターへのアクセスを管理したいと思ったことはありませんか?なんと、それを実現できるようになりました。Amazon RDS はユーザーが IAM を使用して MySQL や Amazon Aurora DB の Amazon RDS へのデータベースアクセスを管理できるようにする機能をリリースしました。 このサービス機能の良い所は、使用開始が実に簡単なことです。IAM を使用してデータベースユーザー認証を有効にするには、DB インスタンスまたはクラスターの作成、変更、復元を行う際に [Enable IAM DB Authentication] […]

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