Amazon Web Services ブログ

新しい – AWS Direct Connect Gateway – リージョン間の VPC アクセス

今回のブログの準備をしている時に、2012 年に公開した懐かしいブログ記事を読み返してみました。これは AWS Direct Connect のリリースについて紹介したものです。エンタープライズをご利用されているお客様達から、プライバシーの強化やデータ転送の帯域幅の追加、より予測可能性に優れたデータ転送パフォーマンスを実現するため、AWS リージョンに専用接続を確立できるようにしたいというリクエストを受け、Direct Connect を提供するに至りました。当初は AWS リージョン 1 か所と 1 つのコロケーションから始まりましたが、現在ではすべてのパブリック AWS リージョンでその利用が可能となり、世界中に散在する多数のコロケーションからアクセスできるようになりました (合計 60 か所のロケーション)。当社のお客様には Direct Connect を全面的にご活用いただいており、その後も Link AggregationAmazon EFS サポートCloudWatch モニタリングHIPAA の適格性といった機能を追加しました。過去 5 週間だけでも、Direct Connect ロケーションをヒューストン (テキサス)、バンクーバー (カナダ)、マンチェスター (英国)、キャンベラ (オーストラリア)、パース (オーストラリア) に追加しました。

そして現在は、Direct Connect Gateway を追加することで Direct Connect をよりシンプルに、そしてさらにパワフルにするよう努めています。また、すべてのリージョンにおいて Direct Connect をご利用のお客様が、当社のグローバル IP ルートを受信するパブリック仮想インターフェイスを作成したり、当社サービスのパブリックエンドポイントへのアクセスの有効化、Direct Connect の価格モデルの更新などを行えるようにしています。

では詳しく見てみましょう。

新しい Direct Connect Gateway
この新しい Direct Connect Gateway を使用すると、複数の AWS リージョンに渡り Virtual Private Cloud (VPC) で接続性を確立できます。そのため、VPC にそれぞれ複数の BGP セッションを確立する必要がないので、管理作業を減らしネットワークデバイスへの負担も軽減することができます。

また、この機能はどの Direct Connect ロケーションからでも関与する VPC への接続を可能にするため、クロスリージョンベースで AWS サービスを使用する場合のコストをさらに削減することもできます。

Direct Connect Gateway を使用して実現できる簡略化の例を示した以下の図をご覧ください (「ロック」アイコンは仮想プライベートゲートウェイを意味します)。まず、このように開始します。

最後に次のようになります。

特定の Direct Connect Gateway を参照する VPC には、重複しない IP アドレス範囲が必要です。現在、VPC はすべて同じ AWS アカウントになければなりませんが、今後これをもっと柔軟にする予定です。

各ゲートウェイはパブリック AWS リージョンすべてに渡り存在するグローバルオブジェクトです。ゲートウェイを介したリージョン間の通信はすべて AWS ネットワークのバックボーンに渡って行われます。

Direct Connect Gateway の作成
Direct Connect Gateway を作成するには Direct Connect Console を使用するか、 CreateDirectConnectGateway 関数を呼び出してください。私はコンソールを使用します。

開始するには、Direct Connect Console を開き [Direct Connect Gateways] をクリックします。

まだゲートウェイがないので、リストは空の状態になっています。これを変更するには [Create Direct Connect Gateway] をクリックします。

ゲートウェイの名前を入力し、ネットワークにプライベート ASN を入力したら [Create] をクリックします。ASN (自律システム番号) は RFC 6996 でプライベートとして定義されている範囲の 1 つにする必要があります。

しばらくすると、新しいゲートウェイが別の AWS リージョンで表示されます。

VIF を作成するのに使用する Direct Connect Connection がオハイオにあります。

次に Gateway と Connection を参照するプライベート VIF を作成します。

数秒で使用できるようになります。

重複しない CIDR とそれぞれに仮想プライベートゲートウェイがアタッチされている VPC のペアがすでにあります。こちらが VPC です (これはデモなので便宜上、同じリージョンでお見せします)。

仮想プライベートゲートウェイは次のようになります。

Direct Connect Console に戻り Direct Connect Gateways にアクセスします。Gateway を選択し [Associate Virtual Private Gateway] を [Actions] メニューから選びます。

両方の仮想プライベートゲートウェイを選択し [Associate] をクリックします。

いつものように、もし自分の VPC が特定の AWS リージョンである場合も同じ手順を使用できます。このブログでは 2 回ではなく 1 回で操作をお見せした方が簡単でした。

数分ほどで仮想ゲートウェイの関連付けが完了します (associating の状態で開始)。

この状態が [associated] になると、VPC がある AWS リージョンにかかわらず、AWS Direct Connect 接続でオンプレミスネットワークと VPC 間でトラフィックが移動するようになります。

サービスエンドポイントのパブリック仮想インターフェイス
これで、あらゆる AWS リージョンで実行している AWS サービスの AWS パブリックサービスエンドポイントへのアクセスを可能にするパブリック仮想インターフェイスを作成できるようになりました。こうしたインターフェイスは Amazon のグローバル IP ルートを受信 (BGP 経由) します。[Public] オプションを選択し Direct Connect Console でインターフェイスを作成できます。

価格モデルの更新
AWS リージョンや AWS Direct Connect ロケーションの数が日々増えていくことを考慮し、データ転送料金が Direct Connect とソース AWS リージョンのロケーションをベースにするようになりました。新しい料金設定は AWS Direct Connect ロケーションをベースにしたこれまでのモデルに比べ、よりシンプルになりました。

提供開始
この機能はすでに利用可能となっており、今すぐ使用を開始できます。Direct Connect Gateways は追加費用なしに作成し使用することができます。いつものようにポート時間とデータ転送に基づいた Direct Connect 料金を支払うことになります。

Jeff;

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 か所の接続ポイントを追加しました。

  • ベルリン (ドイツ)
  • ミネアポリス (米国ミネソタ)
  • プラハ (チェコ共和国)
  • ボストン (米国マサチューセッツ)
  • ミュンヘン (ドイツ)
  • ウィーン (オーストリア)
  • クアラルンプール (マレーシア)
  • フィラデルフィア (米国ペンシルバニア)
  • チューリッヒ (スイス)

2018 年第 1 四半期にエッジロケーションを追加予定のアラブ首長国連邦を始め、今後その他の都市も追加してきます。

顧客に向けたイノベーション
先述のように、当社のネットワークはエッジロケーションとリージョン別エッジキャッシュで構成されています。2016 年の re:Invent で発表したリージョン別エッジキャッシュは、エッジロケーションとユーザーのオリジンサーバーの間に位置し、エッジロケーション以上のメモリを備えています。オリジンサーバーのロードを減らしながら、視聴者に向けて配信を迅速に提供できるように、コンテンツを身近に保存することを可能にしています。

ロケーションが大切なことには変わりませんが、それは単なる開始点です。先日はセキュリティポリシー機能をリリースするなど、当社は引き続きセキュリティを重視しています。また、CloudFront は HIPAA 対応サービスであることもお知らせしました。Lambda@Edge のリリースにより、これまで以上にコンテンツ提供やコンテンツ生成のオプションを提供し、ユーザーに近い状態で AWS Lambda 関数を実行できるようにしています。

また、キャッシュの無効化や設定変更の処理の高速化にも力を注いでいます。リクエストからミリ秒以内に無効化を受け入れるようになり、通常 60 秒以内にそのリクエストが世界中で処理できるようになりました。これにより、顧客がタイムリーに最新のコンテンツにアクセスすることを可能にしています。

サインアップ情報、チュートリアル、オンラインセミナー、オンデマンド動画、営業時間などに関する情報については「Amazon CloudFront の使用を開始 (Getting Started with Amazon CloudFront)」ページをご覧ください。

Jeff;

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

「医療顧客の事例 (Health Customer Stories)」 ページでは、AWS で実行するヘルスケアやライフサイエンスのアプリケーションを構築し実行している数多くのお客様の中から数件をご紹介しています。Verge HealthCare CloudOrion 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 – Encryption at Rest for Amazon Aurora)」をご覧ください。

Amazon CloudWatch ログ)」 – ログを使用してシステムやアプリケーションをモニタリングしたり、トラブルシューティングを行うことができます。既存のシステム、アプリケーション、カスタムログファイルをほぼリアルタイムでモニタリングするので、特定のフレーズ、値、パターンなどを監視できます。ログデータは永続的そして低コストで必要な限り保存されます。詳しくは「Amazon CloudWatch で OS とアプリケーションログファイルの保存とモニタリング (Store and Monitor OS & Application Log Files with Amazon CloudWatch)」と「CloudWatch ログとダッシュボードの改良 (Improvements to CloudWatch Logs and Dashboards)」をご覧ください。

Amazon Connect – このセルフサービスによるクラウドベースのサポートセンターは、低コストでより良いカスタマーサービスを提供できるようにしています。ビジュアルデザイナーを使用すれば、問い合わせフローやエージェント管理、パフォーマンスのトラッキングを特別なスキルなしにセットアップすることができます。詳しくは「Amazon Connect – クラウドを使用したサポートセンター (Amazon Connect – Customer Contact Center in the Cloud)」と「Amazon Connect と Amazon Lex の統合 (New – Amazon Connect and Amazon Lex Integration)」をご覧ください。

Amazon ElastiCache for Redis – このサービスはアプリケーションのパフォーマンス改善に使用するため、インメモリ型データストアやキャッシュをデプロイ、操作、スケールできるようにします。ElastiCache for Redis クラスターは、それぞれ Amazon CloudWatch にキーパフォーマンスメトリクスを発行するようになっています。詳しくは「Amazon ElastiCache とクラウドでキャッシング (Caching in the Cloud with Amazon ElastiCache)」と「Amazon ElastiCache – Dash of Redis を使用 (Amazon ElastiCache – Now With a Dash of Redis)」をご覧ください。

Amazon Kinesis Streams – このサービスでは、ウェブサイトのクリックストリーム、金融取引、ソーシャルメディアフィード、ロケーション追跡イベントなどのストリーミングデータを処理したり分析するアプリケーションを構築できるようにします。詳しくは「Amazon Kinesis – ビッグデータをリアルタイムで処理 (Amazon Kinesis – Real-Time Processing of Streaming Big Data)」と「Amazon Kinesis Streams のサーバー側で行う暗号化 (New: Server-Side Encryption for Amazon Kinesis Streams)」をご覧ください。

Amazon RDS for MariaDB – このサービスは スケーラブルでマネージド型 MariaDB インスタンスを数分でセットアップできるようにし、高パフォーマンス、高可用性そして保管時および転送中のデータを暗号化しやすくする簡略化したセキュリティモデルを提供しています。詳細については「Amazon RDS の更新 – MariaDB が利用可能に (Amazon RDS Update – MariaDB is Now Available)」をご覧ください。

Amazon RDS SQL Server – このサービスはスケーラブルでマネージド型 Microsoft SQL Server インスタンスを数分でセットアップできるようにします。また、高パフォーマンス、高可用性そして簡略化したセキュリティモデルも提供しています。詳細については「AWS Elastic Beanstalk の Amazon RDS for SQL Server と .NET サポート (Amazon RDS for SQL Server and .NET support for AWS Elastic Beanstalk)」および「Amazon RDS for Microsoft SQL Server – 透過的なデータ暗号化 (TDE) (Amazon RDS for Microsoft SQL Server – Transparent Data Encryption (TDE))」をご覧ください。

Amazon Route 53 – これは可用性の高いドメイン名サーバーです。www.example.com といった名前を IP アドレスに変換します。詳しくは「Amazon Route 53 の活用 (Moving Ahead with Amazon Route 53)」をご覧ください。

AWS Batch – このサービスは大規模なバッチのコンピューティングジョブを AWS で実行できるようにします。特別なバッチソフトウェアのインストールや維持、または独自のサーバークラスターを構築する必要はありません。詳細は「AWS Batch – AWS でバッチのコンピューティングジョブを実行 (AWS Batch – Run Batch Computing Jobs on AWS)」をご覧ください。

AWS CloudHSM – クラウドスケールでのキーストレージや管理用のクラウドベースのハードウェアセキュリティモジュール (HSM) です。重要なワークロード用に設計された CloudHSM では、FIPS 140-2 のレベル 3 認証済み HSM を使用して独自のキーを管理することができます。詳細については「AWS CloudHSM – 安全なキーストレージと暗号化オペレーション (AWS CloudHSM – Secure Key Storage and Cryptographic Operations」および「AWS CloudHSM の更新 – 重要および規制対象ワークロード用のクラウドスケールにおけるコスト効率に優れたハードウェアキーの管理 (AWS CloudHSM Update – Cost Effective Hardware Key Management at Cloud Scale for Sensitive & Regulated Workloads)」をご覧ください。

AWS Key Management Service – このサービスはデータの暗号化に使用する暗号化キーの作成や管理を容易にします。キーを保護するために HSM を使用し、すべてのキー使用のログを提供するため、AWS CloudTrail と統合されています。詳しくは「新しい AWS Key Management Service (New AWS Key Management Service (KMS))」をご覧ください。

AWS Lambda – このサービスはサーバーを考慮したり管理する必要なくイベント駆動型アプリケーションまたはバックエンドコードを実行できるようにします。詳しくは「AWS Lambda – クラウドでコードを実行 (AWS Lambda – Run Code in the Cloud)」、「AWS Lambda – 2016 年を振り返って (AWS Lambda – A Look Back at 2016)」、「AWS Lambda – モバイル開発における新機能を備えた本稼働環境 (AWS Lambda – In Full Production with New Features for Mobile Devs)」をご覧ください。

Lambda@Edge – この AWS Lambda の新機能を使用して Node.js 関数を AWS ロケーションのグローバルネットワークに渡り実行することができます。豊富なコンテンツや個人化されたコンテンツを低レイテンシーでユーザーに提供する場合にサーバーをプロビジョニングしたり管理する必要がありません。詳しくは「Lambda@Edge を読む – Edge での HTTP リクエストの知的処理 (Read Lambda@Edge – Intelligent Processing of HTTP Requests at the Edge)」をご覧ください。

AWS Snowball Edge – これはオンボードのストレージとコンピューティング能力を搭載した 100 TB のデータ転送デバイスです。Snowball Edge は一時的なストレージ層として使い、AWS との間で大量のデータを移動するために使用することも、遠隔地やオフラインのロケーションにあるローカルワークロードを実行するために使用することもできます。詳細は「AWS Snowball Edge – より多くのストレージ、ローカルエンドポイント、Lambda 関数を提供 (AWS Snowball Edge – More Storage, Local Endpoints, Lambda Functions)」をご覧ください。

AWS Snowmobile – これはエクサバイト規模のデータ転送サービスです。セミトレーラートラックが牽引する長さ 14 m の丈夫な輸送コンテナで、Snowmobile 1 台あたり 100 PB まで転送できます。詳細は「AWS Snowmobile – エクサバイトのデータを数週間でクラウドに移行 (AWS Snowmobile – Move Exabytes of Data to the Cloud in Weeks)」をご覧ください (ついでに私の素晴らしい LEGO プロジェクトもお見逃しなく)。

AWS Storage Gateway – このハイブリッドストレージサービスはボリューム、ファイル、仮想テープ用のストレージを備え、シンプルかつシームレスな方法でオンプレミスアプリケーションが AWS クラウドストレージを使用できるようにします (Amazon Simple Storage Service (S3)Amazon GlacierAmazon Elastic File System)。詳しくは「AWS Storage Gateway – 既存のオンプレミスアプリケーションと AWS Cloud Storage を統合 (The AWS Storage Gateway – Integrate Your Existing On-Premises Applications with AWS Cloud Storage)」と「AWS Storage Gateway へのファイルインターフェイス (File Interface to AWS Storage Gateway)」をご覧ください。

以上です。HIPAA や HITECH に準拠するアプリケーション構築に便利なリソースについては過去のブログ記事をご覧ください。

Jeff;

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 を使用します。

Amazon CloudWatch は、システムやインフラストラクチャのセットアップ、管理、スケールを必要とせずに EC2 インスタンスでワークロードをモニタリングする場合に大変優れています。デフォルトにより、CloudWatch は CPUUtilization、DiskReadOps、DiskWriteOps、NetworkIn、NetworkOut といったメトリクスを提供するようになっています。(インスタンスのメトリクス一覧についてはこちらをご覧ください)

こうしたメトリクスの他にも API、SDK または CLI を使用し Amazon CloudWatch カスタムメトリクス を介して独自のデータポイントをプッシュすることもできます。Python Boto3 SDK を使用します。

(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 タスクにおける ELIT プラットフォームの活用例をご紹介しましょう。

感情分析

具体的なデモンストレーションをご覧いただく前に、感情分析に対する当チームのアプローチを簡単にご説明します。感情分析とは、各ドキュメントをネガティブニュートラルポジティブという 3 つの感情に分類することです。ELIT は、感情分析を行うための畳み込みニューラルネットワーク (CNN) モデルを 2 種類提供しており、これを活用することでソーシャルメディアおよび映画のレビューからのデータを分析できます。対象ドキュメント (ツイートまたは映画のレビュー) を指定すると、まずは各単語のベクトル表現がスタッキングされ、インプットとして行列が作成されます。このインプット行列が畳み込みおよびプーリング層に入力され、畳み込みの結果は、対象ドキュメントに含まれる各 n グラム (この例では n = [1、…、5]) の強度を表現するアテンションの行列と一致します。そして、このアテンションのアウトプットがソフトマックス層に入力され、対象データがネガティブニュートラルポジティブの各感情に分類される可能性について予測が行われます (ここで使用した CNN モデルの詳細については、Shin et al., 2017 をご覧ください)。

デモンストレーション

まず、ELIT のデモページ (http://demo.elit.cloud/) のスクリーンショットをご覧ください。

(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 root> – ここに、実際の Jupyter Notebook がすべての依存関係とともに保存されています。
  • <project root>/cft – インフラストラクチャを作成するための AWS CloudFormation テンプレートおよびサンプルプロパティ、サンプルコマンド。

ここに新たな/既存の ssh キーを追加する必要があります。AWS CloudFormation テンプレートが Neo4j Community Edition をインストールし、Rekognition を操作するための Python コード例を含む Jupyter Notebook を AWS ラボからダウンロードして、スピーディな利用開始に必要となるその他の Amazon EC2 設定を構成します。また、Cloud Formation テンプレートが Neo4j ブラウザまたは Jupyter Notebook のいずれかのクエリ対象となる一般的なムービーグラフデータベースを自動的にロードします。

(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] のチェックボックスをオンにします。RDS コンソール、AWS CLI および (または) Amazon RDS API を使用して IAM アクセスを有効にすることができます。

IAM 認証用のデータベース設定が完了すると、IAM セキュリティトークンサービスが生成した一時的なセキュリティ認証情報が提供され、クライアントアプリケーションがデータベースエンジンで認証します。データベースエンジンにパスワードを提供する代わりに、この認証情報を使用することができます。

IAM を使用してターゲットにした許可や認証を MySQL と Aurora に提供する場合の詳細情報については「Amazon RDS ユーザーガイド (Amazon RDS user guide)」をご覧ください。

Amazon SES 評価ダッシュボード

Amazon Simple Email Service のユーザーがメール送信でベストプラクティスガイドラインを利用するようにサポートするため、評価ダッシュボードをリリースしてメール送信の状態を包括的にまとめたレポートを提供するようになりました。送信したメールを積極的に管理するためのサポートを提供することで、ユーザーは送信メトリクス、コンプライアンスや実行のステータスを送信し、アカウント全体の状態の可視性を高めます。

評価ダッシュボードは次の情報を提供します。

  • Account status: アカウントの状態を示す説明です。
    • Healthy – 現在、アカウントに影響する問題はありません。
    • Probation – アカウントが停止猶予状態になっています。使用停止を避けるには停止猶予状態になっている理由を解決してください。
    • Pending end of probation decision – アカウントが停止猶予状態になっています。Amazon SES チームのメンバーはアクションを行う前にアカウントをレビューしてください。
    • Shutdown – アカウントが停止されました。Amazon SES を使用してメールを送信することはできません。
    • Probation – アカウントが停止猶予状態になっています。停止猶予状態になっている理由が解決されていません。
  • Bounce Rate: バウンスした送信済みメールの割合とバウンス率のステータスメッセージです。
  • Complaint Rate: 受信者がスパムとして報告した送信済みメールの割合と苦情率のステータスメッセージです。
  • Notifications: 別のアカウントの評価問題に関するメッセージです。

Amazon SES オープンおよびクリックのトラッキングメトリクス

Amazon SES に最近追加されたもう 1 つの優れた新機能はメールのオープンおよびクリックのトラッキングメトリクスです。メールのオープンおよびクリックのトラッキングメトリクス機能は、SES ユーザーが送信したメールがいつ開封されたか確認したり、メール内のリンクがいつクリックされたかをトラッキングすることを可能にします。この SES 機能を使うことで、メールキャンペーンのエンゲージメントや、その効率性を今まで以上にトラッキングできるようになります。

動作の仕組み

メール開封トラッキング機能を使用すると、SES はトラッキングの対象にするメールに透過的な小さなイメージを埋め込みます。そのメールが開封されると、メールアプリケーションクライアントは Amazon SES で、オープントラックイベントをトリガーするそのトラッキングを読み込みます。メールクリック (リンク) トラッキング では、メールや (または) メールテンプレートにあるリンクがカスタムリンクと置き換えられます。カスタムリンクがクリックされると、SES でクリックイベントが記録され、カスタムリンクはオリジナルメールのリンク先にメールユーザーをリダイレクトします。

新しい設定セットを作成したり、SES 内の既存の設定セットを変更することで、新しいオープントラッキングとクリックトラッキング機能を利用することができます。オープンおよびクリックメトリクスを取得するために Amazon SNSAmazon CloudWatch または Amazon Kinesis Firehose を AWS サービスとして選び、送信したいメールで新しい設定セットを選択すれば新機能を有効にできます。

AWS ソリューション: サーバーレスイメージハンドラと AWS Ops Automator

AWS ソリューションビルダーチームは、AWS でのアプリケーション構築や実行をサポートするため、アーキテクチャに関したよくある質問の回答を提供できるように努めています。ソリューションについては AWS Answers ページをご覧ください。秋の始めに AWS Answers で公開した新しい 2 つのソリューションはサーバーレスイメージハンドラAWS Ops Automator です。
サーバーレスイメージハンドラは、ユーザーが AWS Cloud で行うイメージ処理を動的に処理、操作、最適化することをサポートするソリューションを提供するために開発されました。このソリューションは、キャッシングに Amazon CloudFront を、そして AWS Lambda でイメージを動的に取得しイメージの変更を行い、Amazon S3 バケットでイメージを保存することを組み合わせています。さらに、サーバーレスイメージハンドラは、イメージ操作、処理、最適化を追加するオープンソースイメージ処理スイートの Thumbor を利用しています。

AWS Ops Automator ソリューションは、時間ベースまたはイベントベースのトリガーを使用して手動タスクを自動化しやすくします。たとえば、自動タスクのフレームワークを提供することでスナップショットスケジューリングを自動化します。また、タスクの追跡記録、ログ記録、リソースの選択、スケーリング、同時実行の処理、タスク完了の処理、API リクエストの再試行などもこれに含まれます。このソリューションには次の AWS サービスが含まれています。

  • AWS CloudFormation: タスク設定を生成するマイクロサービスやソリューションのコアフレームワークを起動するためのテンプレート
  • Amazon DynamoDB: イベントトリガー、リソースを定義するためのタスク設定データの保存とアクションとエラーの結果を保存するテーブル
  • Amazon CloudWatch Logs: 警告やエラーメッセージをトラックするログ記録を提供
  • Amazon SNS: ソリューションからのログ記録情報を受信するように登録済みのメールアドレスにメッセージを送信

さらに理解を深め、コーディングをお楽しみください。

Tara

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にご連絡下さい。

翻訳は星野が担当しました (原文はこちら)

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ログレコードのコピーがあります。 また、クォーラムのセグメント間をゴシップを利用して、不足している書き込みをすばやく埋めることができます。ここれにより、書き込みパスにパフォーマンスの負担をかけることなく、フルセグメントを再構築する必要がなくなります。

異なるメンバーのクォーラムセットによるコストの管理
異なるメンバーのクォーラムセットを使用すると、コストを抑えることができます。 利用可能な多くのオプションがあります。 低レイテンシのローカルディスクと耐久性/可用性のためのリモートディスクを組み合わせたクォーラムがあるかもしれません。 パフォーマンスとスループットのためにSSDを組み合わせたクォーラムと、低コストのレプリカで耐久性を向上させるHDDがあるかもしれません。 災害復旧を改善するためにAWSリージョン全体でデータを複製するクォーラムがあるかもしれません。適切な組み合わせを考えるために考慮することが沢山ありますが、その結果の利益は重要です。 Auroraの場合、先に説明したクォーラムセットモデルでは、低コストのストレージ価格を実現しながら、高い耐久性、可用性、パフォーマンスを提供します。

これまで、このシリーズでは、クォーラムのサイズを決める方法、読み取りと書き込みの増幅のペナルティを回避する方法、そしてこの記事でコストを制御する方法について説明しました。 次回の記事では、障害に直面した大規模分散システムでの管理コストの少ないクオーラムメンバーシップの管理方法について説明します。

もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。

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

翻訳は星野が担当しました (原文はこちら)

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 を見ることはできず、それにより何を読み込むべきか把握することはできません。

そのため、redo レコードがマスターからレプリカへ送られる際に、概念的にリードビューと同等のものが送られます。このビューにより、コミットLSNとLSNが堅牢であると示すセグメントの情報が更新されます。通常、コミットLSN を約 10ミリ秒ごとに更新することができます。それにより、レプリカをマスターノードとの差分を最小限に保ちます。

破壊的な書き込みの回避
このアプローチの鍵は、破壊的な書き込みの回避です。リードレプリカとマスター間の通信を調整しなければいけない理由の大部分は、読み取るデータが確実に表示されるようにすることです。以前のページイメージに戻すことができる限りは、リードビューにより、その調整負荷は大幅に減少されます。Aurora では、データページを別の場所に書き込みます。古いバージョンは、バックアップされ、すべてのリーダーがリードポイントをそのバージョン以上に更新した際に、ガベージ・コレクションされます。このアプローチにより、マスターノードより数ミリ秒遅れているレプリカノードでも一貫したビューを持つことができます。

トランザクションをロールバックすることがあったとしても、リレーショナルデータベースは、その根底において、常に更新される redo ログです。データベースを構成するデータページは、実のところ、アプリケーションの redo ログを一時的にキャッシュして具現化したものに過ぎません。多くのデータベースが破壊的にデータページを書き込むという事実は、実際、リレーショナルデータベースが最初に作成された際の高コストなディスクに基づく歴史的な好奇心です。

Aurora では、上記で説明したアプローチを用いるため、読み込みクォーラムを利用しません。その代わり、修復クォーラムを利用します。読み込みクォーラムにクエリする必要があるのは、書き込みマスターデータベースノードにおいてキャッシュの状態を失う時だけです。もし、マスターインスタンスを再起動、もしくはレプリカをマスターに昇格させなければいけない場合、ローカルの状態を再構築するため、少なくとも1度、読み込みクォーラムにクエリする必要があります。いずれにしても、どのようなトランザクションがコミットされているか把握するためにそうしなければならないことは明らかでしょう。これについては、いつか別のブログでお話しすることになるかもしれません。データベースのクラッシュが、読み取りに比べて発生頻度が少ないことを考えると、このトレードオフをとる価値があります。

まとめ
この投稿と前回の投稿で、可用性を提供するためにどのようにクォーラムを使用するか、どのように従来の読み込みクォーラムのオーバーヘッドを回避するかについて確認しました。次回の投稿では、クォーラムシステムをコストの観点でどのように利用しやすくするかについてお話します。もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。

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

翻訳は江川が担当しました(原文はこちら)