Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

OracleDBからPostgreSQLへの移行

  Knievel Co は、アマゾン ウェブ サービスのデータベースエンジニアです。 このブログ記事では、Oracle データベースを PostgreSQL に移行する方法の概要について説明します。データベース移行の2つの主要部分は、スキーマの変換とデータの複製です。)AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、これら 2 つの部分に取り組む方法について説明します。 SCT と DMSについて説明する前に、予備的な手順を実行する必要があります。これらは、すべての移行に役立つことが判明しています。移行を容易にする方法の 1 つは、移行の前に、通常更新フェーズと呼ばれるものを行うことです。このフェーズでは、Oracle データベース内のオブジェクトのインベントリを作成し、いくつかの決定を下します。 最初に、不要になったオブジェクトを削除します。オブジェクトの移行にかかる時間は誰も気にかけませんが、無駄にしないでください。また、不要になった履歴データを削除することもできます。一時的なテーブルや過去のメンテナンス時のテーブルのバックアップコピーなど、不要なデータを複製するために時間を無駄にすることはありません。次に、LOB、CLOB、LONG などに保存されているフラットファイルおよび長い文字列を Amazon S3 または Amazon Dynamo DB に移動します。このプロセスではクライアントソフトウェアの変更が必要となりますが、データベースが簡素化されサイズが削減されることで、システム全体がより効率的になります。最後に、PL/SQL パッケージとプロシージャを移動します。特にビジネスロジックを含むものをクライアントソフトウェアに戻してみます。これらのオブジェクトは、SCT が変換できない場合は手動で変更する必要があります。 次の手順は、異なるデータベースエンジン (この場合は Oracle から PostgreSQL へ) に移行するための手順です。別のプラットフォームに移動していない場合は、データベースを移動するためのより適切なネイティブツールやその他のテクニックがあります。 ターゲットデータベースでスキーマを作成します。 ターゲットデータベースの外部キーとセカンダリインデックスを削除し、トリガーを無効にします。 データを複製するためのDMSタスクを設定します (全ロードと変更データキャプチャ (CDC))。 全ロードフェーズが完了したらタスクを停止し、外部キーとセカンダリインデックスを再作成します。 DMS タスクを有効にします。 […]

Read More

詳解: Amazon ECSのタスクネットワーク

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはコンテナにElastic Network InterfaceをアタッチできるようにするAmazon ECSのTask Networkingを発表しました。 この記事では、ECSが管理するインスタンス(コンテナインスタンスと呼ばれます)上でContainer Networking Interfaceプラグインを使って、この新しいコンテナネイティブなawsvpcネットワークモードがどのように実装されているかを詳しくご紹介したいと思います。 こちらはAmazon ECSでタスクネットワークが動作するかにdeep diveしたものです。もし自身のコンテナ化したアプリケーションでどうやってタスクネットワークを使い始めれば良いかについて学びたい時には、Amazon ECSコンテナにCloud Native Networkingが登場をご覧下さい。Cloud Native Computing Foundation (CNCF)がContainer Networking Interface (CNI)プロジェクトをホストしており、Linuxコンテナでネットワークインターフェースを設定するためのプラグインを書くための仕様やライブラリが含まれています。AWSのクラウドネイティブコンピューティングについての詳細は、Adrian CockcroftのCloud Native Computingについての投稿をご覧下さい。 コンテナインスタンスのセットアップ コンテナインスタンス上でのタスクネットワーク有効化の詳細をご説明する前に、ECSの典型的なインスタンスがどのようになっているかを見てみましょう。 上の図は典型的なコンテナインスタンスを示しています。ECS agentは自身もコンテナとして実行されているのですが、以下のような責任を負っています: EC2インスタンスをECSのバックエンドに登録 コンテナインスタンスに対してECSバックエンドが発生させたタスク状態の変化を、正しく適応 Dockerデーモンと会話しながら、コンテナの作成、開始、停止、監視 コンテナの状態とタスクの状態の遷移をECSバックエンドにリレー ECS agentはその管理下のコンテナのスーパーバイザーの様に動作するので、Dockerデーモン(Dockerのデフォルトネットワークモードで設定されたコンテナ用)、又はCNIプラグイン達(ネットワークモードがawsvpcで設定されたタスク内のコンテナ)のための、ネットワーク設定をする難しさをオフロードしてくれます。 いずれの場合にも、コンテナのネットワークスタックは、ネットワークのnamespaceを通じて設定されます。ip-netns(8)のマニュアルによると「ネットワークnamespaceは論理的なネットワークスタックのコピーで、自身のルーティング、ファイアウォールルール、ネットワークデバイスを持っています。」 とあります。ネットワークnamespaceの構成によって、ホスト上で動いているプロセスやコンテナ間でのネットワークスタックの隔離を可能としてくれます。 ネットワークnamespaceとCNIプラグイン CNIプラグインとは、CNI仕様を満たしコンテナのネットワーク接続性の設定を行う実行ファイル群です。CNIプロジェクトではプラグインの仕様を定義し、プラグインが利用するライブラリを提供することで、一貫していて信頼でき、かつ簡素なプラグイン用のインタフェースを提供してくれます。 コンテナやネットワークnamespaceを指定してプラグインを呼び出す時に、ADDコマンドでコンテナにネットワークインターフェースを追加したり、DELコマンドでそれを落としたりします。例えばリファレンスのBridgeプラグインは、ホストネットワークnamespaceの中にいるブリッジに対してホスト上の全てのコンテナを追加します。 このプラグインのモデルはECS agentの「コンテナのライフサイクルへの最小限の介入」というモデルと相性が良く、agentはコンテナのネットワーク設定の詳細について考慮する必要がなくなります。また拡張性の高いモデルなので、将来必要になった時には、agentが異なるプラグイン群を利用できるようにスイッチさせることもできます。最後に、これらプラグインは必要な時に呼び出されるだけなので、その死活監視をECS agentがする必要はありません。 ECS agentからCNIプラグインを呼び出す ECSがElastic Network Interfaceをインスタンスにアタッチし、agentに対しそのElastic Network Interfaceをタスク内のコンテナに対してプロビジョンするようにメッセージを送った時には、(任意のネットワークデバイスを使う) そのElastic […]

Read More

Amazon ECSコンテナにCloud Native Networkingが登場

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはAmazon ECSのTask Networkingを発表しました。これによって、Elastic Network Interfaceを使ったAmazon EC2のネットワーク機能をタスクに持ち込むことができるようになります。 Elastic Network InterfaceはVPC内のインスタンスにアタッチすることができる仮想的なネットワークインタフェースです。EC2の仮想マシンを起動する時には、インスタンスにネットワークの機能を提供するために自動的に1つのElastic Network Interfaceがプロビジョンされます。 タスクは実行されるコンテナの論理的なグループです。これまでは、Amazon ECSで実行されるタスクはそれが動くEC2ホストのElastic Network Interfaceを共有していました。これからは、新しいawsvpcというネットワークモードを使うことで、Elastic Network Interfaceが直接タスクにアタッチされます。 これによってネットワークの設定を簡略化することができ、VPCが持っているネットワークの全機能、隔離性、そしてセキュリティの制御を各コンテナにEC2インスタンスと同様のレベルで利用することができます。 この記事では、awsvpcモードがどのように動作し、ECSのタスクでどのようにElastic Network Interfaceを使い始めることができるかをご紹介します。 背景: EC2のElastic Network Interface VPC内にEC2インスタンスを起動する時には、各インスタンスが互いに通信できるようにするために、追加のオーバーレイネットワークを設定する必要はありません。標準で、VPCのルーティングテーブルがインスタンスや他のエンドポイント間での通信をシームレスに実現してくれます。これは、Elastic Network Interfaceと呼ばれるVPC内の仮想的なネットワーク・インタフェースによって可能となっています。全ての起動されるEC2インスタンスは自動的に1つのElastic Network Interface(プライマリネットワークインタフェース)がアサインされます。サブネット、セキュリティグループといった全てのネットワークパラメータは、このプライマリネットワークインタフェースの属性として扱われます。 さらに、各Elastic Network Interfaceは作成時にVPCによってIPv4アドレス(プライマリIPv4アドレス)が割当られます。このプライマリアドレスはユニークでVPC内でルーティング可能なものです。これによって、VPCは実際はフラットなネットワークとなり、ネットワークトポロジを簡潔なものとしてくれます。 Elastic Network InterfaceはVPC上で多様なエンドポイントとの接続を実現するための基本的なビルディングブロックとみなすことができ、そのうえでより高レベルな抽象レイヤを構築することができます。これによってElastic Network Interfacdeは以下の機能を利用することが可能となっています: VPCネイティブなIPv4アドレスとルーティング (VPC上でのインスタンス間や他のエンドポイントとの間) ネットワークトラフィックの隔離 ACLとファイアウォールルール(セキュリティグループ)を使ったネットワークポリシーの強制 (サブネットのCIDRを通じた)IPv4アドレスレンジの強制 なぜawsvpcを使うのか? 以前はECSはDockerが提供する標準のネットワークの挙動が提供するネットワーク機能に依存した形でコンテナ向けのネットワークスタックを構成していました。デフォルトのBridgeネットワークモードでは、インスタンス上のコンテナ達はdocker0ブリッジを使って互いにつながっています。インスタンス外のエンドポイントと通信する時には、コンテナはこのブリッジを利用し、それが実行されているインスタンスのプライマリネットワークインタフェースを使います。コンテナは、ファイアウォールルール(セキュリティグループ)やIPアドレスは、そのプライマリElastic Network Interfaceのネットワーク属性を共有しまた依存しています。 これは、Dockerによって割当られたIPアドレス(ローカルスコープのアドレスプールから割当られます)を使ってもこれらのコンテナに到達できないことと、細かいNetwork ACLやファイアウォールルールを強制できないことを意味します。代わりに、VPCからはインスタンスのプライマリElastic Network […]

Read More

Amazon ElastiCache for Redis を使ったChatアプリの開発

Sam Dengler は、アマゾン ウェブ サービスのソリューションアーキテクトです。 このブログ記事では、チャットアプリケーションに関連する概念とアーキテクチャのパターンについて説明します。また、チャットクライアントとサーバーの実装の詳細、サンプルのチャットアプリケーションを AWS アカウントに展開する方法についても説明します。 背景情報 チャットアプリケーションを構築するには、クライアントがチャットルームの他の参加者に再配信されるメッセージを送信できる通信チャネルが必要となります。この通信は、一般に publish-subscribe パターン (PubSub) を使用して実装されます。このパターンでは、メッセージが中央トピックチャネルに送信されます。関係者は、このチャンネルをサブスクライブして更新の通知を受けることができます。このパターンでは、発行者の知識なしに受信者のグループを拡大または縮小できるように、発行者と受信者を切り離しています。 PubSubは、クライアントが WebSockets を使用して通信するバックエンドサーバーに実装されます。WebSockets は、クライアントとサーバー間で双方向にストリーミングされるデータのチャネルを提供する永続的な TCP 接続です。単一サーバアーキテクチャでは、1 つの PubSub アプリケーションが発行者と受信者の状態を管理し、WebSocket を介してクライアントにメッセージを再配布することもできます。次の図は、単一サーバー PubSub アーキテクチャ上の 2 つのクライアント間でメッセージが WebSocket を通過するパスを示しています。 単一サーバーアーキテクチャは、通信フローを説明するのに役立ちます。しかし、ほとんどのソリューションビルダーはマルチサーバーアーキテクチャで設計したいと考えています。マルチサーバーアーキテクチャは、信頼性を高め、伸縮性を高め、クライアントの数が増えるにつれてアプリケーションを水平的に拡大するのに役立ちます。 マルチサーバーアーキテクチャでは、クライアントはサーバープールにトラフィックを転送するロードバランサーに対して WebSocket 接続を行います。これらのサーバーは、WebSocket 接続とそれを経由してストリーミングされるデータを管理します。WebSocket 接続が PubSub アプリケーションサーバーとの間で確立されると、その接続は永続化され、データは両方向のアプリケーションにストリームされます。ロードバランサーは、WebSocket 接続のリクエストを健全なサーバーに配信します。つまり、2 つのクライアントが異なるアプリケーションサーバーに WebSocket 接続を確立できます。   複数のアプリケーションがクライアントの WebSocket 接続を管理するため、アプリケーションはメッセージを再配布するためにそれらの間で通信する必要があります。この通信が必要なのは、メッセージが WebSocket を介して 1 つのアプリケーションサーバーにストリームアップされ、別のアプリケーションサーバーに接続されたクライアントにストリームダウンされる必要があるためです。クライアント接続を管理しているアプリケーションから PubSub ソリューションを外部に出すことで、アプリケーション間の共有通信の要件を満たすことができます。   次の図は、マルチサーバー PubSub […]

Read More

12 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナル サービスの宮本です。AWS Black Belt オンラインセミナー12月の配信についてご案内させて頂きます。サービスカットは、10/24 に Generally Available を迎えた Amazon Aurora with PostgreSQL Compatibility をはじめ、今月も様々なテーマを取り扱います。また、ソリューションカットは、「AWSサービスを利用したアプリケーション開発を始めよう」と題して、AWSにおけるアプリケーション開発に活用できる様々なサービスについてご紹介や、AWSにおけるIPv6のサポート状況についてご紹介します。                         12月の開催予定 サービスカット 12/6(水) 18:00-19:00 Amazon Elasticsearch Service 12/14(木) 18:00-19:00 Amazon ElastiCache ※ 通常の開催曜日と異なりますのでご注意ください。 12/20(水) 18:00-19:00 Aurora PostgreSQL ソリューションカット 12/1(金) 12:00-13:00 AWS re:Invent 2017 Report  ※ 通常の開催曜日と異なりますのでご注意ください。 12/5(火) 12:00-13:00 […]

Read More

今すぐご利用可能 – Amazon EC2 コンピューティング最適化インスタンス C5

新しくコンピューティングに最適化されたC5インスタンスが、3つのAWSリージョン、6つのインスタンスサイズでリリースされ、今日から利用可能であることを発表することに興奮しています! これらのインスタンスは、バッチ処理、分散解析処理、高性能コンピューティング(HPC)、広告配信、スケーラブルなマルチプレーヤゲーミング、ビデオエンコーディングなどのコンピューティング重視のアプリケーション用に設計されています。 新しいインスタンスは、C4インスタンスに対して25%の価格/パフォーマンスの向上をもたらし、一部のワークロードでは50%を上回ります。 また、vCPUあたりの追加メモリ(新しいAVX-512命令を使用できるコードにおいて)は、2倍のベクターおよび浮動小数点演算のパフォーマンスを備えています。 AWSによって設計、構築された専用ハードウェアにさまざまな種類の作業をオフロードすることに長期的に視点を置き、最高のネットワーク、ストレージ、およびコンピューティングパフォーマンスを顧客に提供するために、私たちは長年にわたりノンストップで取り組んできました。 C5インスタンスタイプには、最新世代のハードウェアオフロードが組み込まれており、ハードウェアに手を加えて新しいハイパーバイザーを追加することで、さらに大きな前進を遂げています。新しいハイパーバイザーを使用すると、ホストハードウェアが提供するすべての処理能力にアクセスすることができます。同時に、パフォーマンスをより一貫して強化し、さらにセキュリティを強化します。 私たちはAWS re:Inventで、それに関する多くの技術的な詳細を共有します。 新しいインスタンス C5インスタンスは6つのサイズが利用可能です: Instance Name vCPUs RAM EBS Bandwidth Network Bandwidth c5.large 2 4 GiB Up to 2.25 Gbps Up to 10 Gbps c5.xlarge 4 8 GiB Up to 2.25 Gbps Up to 10 Gbps c5.2xlarge 8 16 GiB Up to 2.25 Gbps Up to 10 Gbps c5.4xlarge […]

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