Category: Amazon RDS*


Amazon Kinesis を用いた Databaseの継続的な変更

Emmanuel Espina は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。

このブログ記事では、Amazon Kinesis を使用して変更をストリーミングすることによって、中央リレーショナルデータベース を他のシステムと統合する方法について説明します。

次の図は、分散システムにおける一般的なアーキテクチャ設計を示しています。これには、「」と呼ばれる中央ストレージと、この中央ストレージを消費するいくつかの派生「衛星」システムが含まれます。

この設計アーキテクチャを使用して、リレーショナルデータベースを中央データストアとして使用し、このシステムのトランザクション機能を利用してデータの整合性を維持することができます。このコンテキストにおける派生システムは、この変化の事実の単一ソースを観察し、それらの変更を変換し、フィルタリングし、最終的にはその内部インデックスを更新する全文検索システムとすることができます。もう 1 つの例は、OLAP クエリに適した列形式ストレージです。一般に、中央リレーショナルシステムの個々の行を変更する際にアクションを取る必要のあるシステムは、派生データストアに適した候補となります。

これらの種類のアーキテクチャの単純な実装では、変更された行を検索するために派生システムが定期的にクエリを発行し、本質的に SELECT ベースのクエリで中央データベースをポーリングします。

このアーキテクチャのより優れた実装となるのが、非同期の更新ストリームを使用するアーキテクチャです。データベースには通常、行のすべての変更が格納されるトランザクションログがあるため、この変更のストリームが外部オブザーバシステムに公開されている場合、これらのシステムにこれらのストリームを添付して行の変更を処理およびフィルタリングできます。ここでは、中央データベースとして MySQL、メッセージバスとして Amazon Kinesis を使用して、このスキーマの基本的な実装をご紹介します。

通常、MYSQL バイナリログは、マスター上のすべての変更を読み取ってローカルに適用する読取りレプリカに公開されます。この記事では、変更をローカルデータベースに適用するのではなく、Amazon Kinesis ストリームに変更を公開する、一般化されたリードレプリカを作成します。

このメソッドの重要な点の 1 つは、コンシューマーが SQL クエリを受け取らないことです。SQL クエリは公開される可能性もありますが、一般的なオブザーバーは、SQL 互換のデータレプリカを維持しない限り、SQL にはあまり関心がありません。代わりに、変更されたエンティティ (行) を 1 つずつ受け取ります。このアプローチの利点は、コンシューマーが SQL を理解する必要はなく、事実の単一ソースは誰が変更を消費するのかを知る必要はないということにあります。これは、さまざまなチームが、必要なデータ形式で調整することなく作業できることを意味します。さらに都合がいいことに、Amazon Kinesis クライアントはが特定の時点から読む機能を備えているため、各コンシューマーは独自のペースでメッセージを処理します。これが、メッセージバスがシステムを統合するための結合されていない方法の 1 つとなる理由です。

この記事で使用されている例では、行フェッチャーは中央データベースに接続する通常の Python プロセスであり、リードレプリカをシミュレートします。

データベースは、Amazon RDS または MySQL の任意のインストールのいずれかになります。RDS の場合、フェッチャープロセスは RDS インスタンスホストにカスタムソフトウェアをインストールすることができないため、別のホスト (たとえば EC2) にインストールする必要があります。外部インストールの場合、フェッチャープロセスはデータベースと同じホストにインストールできます。

マスター MySQL インスタンスの準備

MySQL マスター (真実の単一のソース) は、それが通常のレプリケーションのマスターであるかのように設定する必要があります。個々の変更された行を受け取るには、Binlog を有効にして ROW 形式で作業する必要があります。(そうしないと、SQL クエリだけになってしまいます。)詳細については、MySQL サイトの「バイナリログ」を参照してください。

バイナリログを有効にするには、my.cnf 設定ファイルに次の 2 行を追加します。

log_bin=<path to binlog>
binlog_format=ROW

すべての接続 (たとえば、init_connect または JDBC などのデータベース API を使用) のグローバルまたはセッションレベルで、トランザクション分離レベルをコミット済み読み取りに設定することによって、行ベースのロギングを取得できます。

RDS (MySql 5.6+) を使用している場合は、簡単です。定期的なバックアップを有効にして (バックアップが有効になっていなければバイナリログは無効になります)、パラメータグループ変数 binlog_format を ROW に更新することによって、必要な設定を作成できます。(これは、パラメータグループの RDS ダッシュボードから行うことができます。)

アクセス権限の追加

RDS で作成されたデフォルトのユーザーを使用している場合は、既にこれらのアクセス許可がある可能性があります。そうでない場合は、REPLICATION SLAVE 権限を持つユーザーを作成する必要があります。詳細については、「レプリケーション用のユーザーの作成」を参照してください。

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

Amazon Kinesis ストリームの作成

Amazon Kinesis ストリームと boto3 クライアントの認証情報が必要です。クライアントの認証情報の詳細については、「Boto 3 ドキュメント」を参照してください。

Amazon Kinesis コンソールを開き、[ストリームの作成] を選択します。

使用するストリームの名前とシャード数を入力します。この例では、1 つのシャードがあります。

数分後、ストリームで行の変更を受け入れる準備が整います。

CLI ユーザーに権限を割り当てる

AWS Identity and Access Management (IAM) を使用して、このストリームにアクセスする CLI ユーザに権限を与えることができます。

この例では、そのユーザーは KinesisRDSIntegration です。ユーザーを作成したり、既存のユーザーを使用することはできますが、Amazon Kinesis ストリームへの書き込み権限を追加する必要があります。

ストリームに固有のポリシーを作成できます。この例では、Amazon Kinesis に完全にアクセスできるスタンダードポリシーを使用しています。

マスターに接続して変更を公開する

Python パブリッシャーが必要とするライブラリをインストールするには、次のコマンドを実行します。

pip install mysql-replication boto3

詳細な手順については、次を参照してください。

https://github.com/noplay/python-mysql-replication

https://boto3.readthedocs.io/en/latest/guide/quickstart.html

ここに、マジックを実行する Python スクリプトがあります。<HOST>、<PORT>、<USER>、<PASSWORD>、および <STREAM_NAME> の各変数を設定値に置き換えることを忘れないでください。

Python

 

import json

import boto3



from pymysqlreplication import BinLogStreamReader

from pymysqlreplication.row_event import (

  DeleteRowsEvent,

  UpdateRowsEvent,

  WriteRowsEvent,

)



def main():

  kinesis = boto3.client("kinesis")



  stream = BinLogStreamReader(

    connection_settings= {

      "host": "<HOST>",

      "port": <PORT>,

      "user": "<USER>",

      "passwd": "<PASSWORD>"},

    server_id=100,

    blocking=True,

    resume_stream=True,

    only_events=[DeleteRowsEvent, WriteRowsEvent, UpdateRowsEvent])



  for binlogevent in stream:

    for row in binlogevent.rows:

      event = {"schema": binlogevent.schema,

      "table": binlogevent.table,

      "type": type(binlogevent).__name__,

      "row": row

      }



      kinesis.put_record(StreamName="<STREAM_NAME>", Data=json.dumps(event), PartitionKey="default")

      print json.dumps(event)



if __name__ == "__main__":

   main()

このスクリプトは、変更された各行を JSON 形式でシリアル化された Amazon Kinesis レコードとして公開します。

メッセージを使用する

これで、変更されたレコードを使用する準備が整いました。あらゆるコンシューマーコードが動作します。この記事のコードを使用すると、次の形式でメッセージが表示されます。

{"table": "Users", "row": {"values": {"Name": "Foo User", "idUsers": 123}}, "type": "WriteRowsEvent", "schema": "kinesistest"}
{"table": "Users", "row": {"values": {"Name": "Bar user", "idUsers": 124}}, "type": "WriteRowsEvent", "schema": "kinesistest"}
{"table": "Users", "row": {"before_values": {"Name": "Foo User", "idUsers": 123}, "after_values": {"Name": "Bar User", "idUsers": 123}}, "type": "UpdateRowsEvent", "schema": "kinesistest"}

まとめ

このブログ記事では、擬似リードレプリカと Amazon Kinesis を使用して、変更ストリームをデータベースのレコードに公開する方法を説明しました。多くのデータ指向の企業が、これに類似したアーキテクチャを使用しています。この記事で提供されている例は、実際の本番環境には対応していませんが、この統合スタイルを試して、エンタープライズアーキテクチャの拡張機能を改善するために使用できます。最も複雑な部分は、おそらく Amazon Kinesis の背後で既に解決されているものでしょう。接着剤の役割を果たすものを提供する必要があります。

その他のリソース

すべてのソフトウェアエンジニアがリアルタイムデータの統合抽象化について知っておくべきこと

Databus に搭載されているすべてのもの: LinkedIn のスケーラブルで一貫性のある変更データキャプチャプラットフォーム

 

Amazon Neptune – フルマネージドのグラフデータベースサービス

現代の生活を可能にするために必要な全てのデータ構造やアルゴリズムの中でも、グラフは日々世界を変えています。ビジネスからは、複雑な関係性を持つリッチなデータが生まれ続け、また取り込まれ続けています。しかし開発者は未だにトラディショナルなデータベースの中でグラフのような複雑な関係性を扱うことを強要されています。必然的に、そのような関係性-リレーションシップが追加されるにつれ、パフォーマンスは劣化し、いらいらするくらい高コストで複雑なクエリとなっていきます。我々はそのようなモダンで複雑性が日々高まるようなデータセットやリレーションシップ、パターンを簡単に扱えるようにしたいと考えました。

Hello, Amazon Neptune

2017年11月29日、我々は限定プレビュー版のAmazon Neptuneを発表します。Amazon Neptuneにより、高度に接続されたデータセット間のリレーションシップから簡単に洞察を得ることができます。Neptuneのコア部分は、数十億ものリレーションシップが格納可能で、グラフに対してミリ秒レベルの遅延となるよう最適化された、専用の、高性能なグラフデータベースエンジンです。フルマネージドなデータベースとして提供されることで、Neptuneはお客様をメンテナンスやパッチ適用、バックアップ/リストアなどの退屈なオペレーションから解放し、アプリケーションに集中できるようにします。高速なフェイルオーバー、Point-in-Timeリカバリ、そしてマルチAZでの実装など高可用性のための各種機能も備えるサービスです。最大15個のリードレプリカによりクエリのスループットを秒間10万件レベルまでスケールさせることも可能です。Amazon NeptuneはAmazon VPC内で動作し、データを暗号化して保管でき、保管時や転送時にデータの整合性について完全に制御することができます。

(more…)

Scaling Your Amazon RDS Instance Vertically and Horizontally

Marie Yap はアマゾン ウェブ サービスのソリューションアーキテクトです。

Amazon RDSは、マネージド型サービスとして、リレーショナルデータベースのスケーリングを処理し、データベースがアプリケーションやアプリケーションの増加する要求に対応できるようにします。

このブログ記事では、RDS インスタンスを縦横に拡大縮小する方法について説明します。ほぼ同じ数の読み取りと書き込みを使用するアプリケーションの増加する要求に対応するために、垂直方向に拡大縮小することができます。また、読み取りが重いアプリケーションの場合は、水平方向に拡大縮小することもできます。

垂直スケーリング
データベースの高い負荷を処理するために、ボタンを押すだけでマスターデータベースを垂直方向にスケールアップできます。現在、RDS MySQL、PostgreSQL、MariaDB、Oracle、または Microsoft SQL Server インスタンスのサイズを変更する際に、18 種類以上のインスタンスサイズを選択できます。Amazon Aurora では、5 つのメモリ最適化インスタンスサイズを選択できます。インスタンスタイプを幅広く選択することで、データベースサーバーに最適なリソースとコストを選択できます。

以下は、RDS インスタンスをスケールアップする際の考慮事項です。

  • スケールを変更する前に、商用エンジン (SQL Server、Oracle) の正しいライセンスを取得していることを確認してください (特に、ライセンス持ち込み (BYOL) が必要な場合)。重要なことは、商用エンジンの場合はライセンスによって制限されていることです。ライセンスは、通常 CPU ソケットまたはコアに関連付けられています。
  • 変更をいつ適用するかを決めます。変更をすぐに適用するか、インスタンスで指定されたメンテナンス期間中に変更を適用するかを選択できます。
  • ストレージとインスタンスのタイプは切り離されています。データベースインスタンスを上下にスケールしたときは、ストレージサイズは同じままで、変更の影響を受けません。DB インスタンスを個別に変更して、割り当てられたストレージスペースを増やすか、ストレージタイプを変更して (一般目的 SSD からプロビジョニング IOPS SSD などに) パフォーマンスを向上させることができます。
  • スタンバイデータベースが最初にアップグレードされた後で、新しくサイズの変更されたデータベースでフェイルオーバーが発生するため、Multi-AZ 環境でスケールアップする場合のダウンタイムは最小限に抑えられます。シングル AZ インスタンスは、スケール操作中は使用できません。

インスタンスのタイプを変更するには、RDS コンソールの [インスタンスの操作] メニューから [変更] を選択します。

次に、新しい DB インスタンスクラスを選択します。

最後に、変更をすぐに適用するかどうかを決定します。変更をすぐに適用するには、[変更] ページの一番下にある [すぐに適用] チェックボックスを選択します。変更をすぐに適用しないと、定義した優先メンテナンスウィンドウ中に変更がスケジュールされます。

水平スケーリング
マスターデータベースを垂直方向に拡張するだけでなく、読み取りレプリカを使用してデータベースを水平方向に拡大することによって、読み取りが重いデータベースのパフォーマンスを向上させることもできます。RDS MySQL、PostgreSQL、MariaDB には最大 5 つのリードレプリカがあり、Amazon Aurora には最大 15 のリードレプリカがあります。

リードレプリカを使用すると、マスターデータベースと同期する読み取り専用コピーを作成できます。より良いパフォーマンスを得るために、リードレプリカをユーザーにより近い別の AWS Region に配置することもできます。また、リードレプリカをマスターに昇格させることで、リードレプリカを使用してデータベースの可用性を高め、災害時の迅速なリカバリーを行うことができます。ただし、リードレプリカは、Multi-AZ が提供する高可用性と自動フェイルオーバー機能の代替となるものではありません。

現在、RDS リードレプリカは、クエリまたは接続の透過的なロードバランシングをサポートしています。各レプリカには固有のドメインネームサービス (DNS) エンドポイントがあり、アプリケーションはレプリカエンドポイントに接続してロードバランシングを実装できます。では、アプリケーションで RDS リードレプリカを認識させる方法のオプションを見てみましょう。

アプリケーションがネイティブの MySQL ドライバを使用している場合は、アプリケーションに大きな変更を加えることなく、読み取り/書き込み分割と読み取り専用のエンドポイントロードバランシングを実行できる MySQL Connector があります。たとえば、PHP アプリケーションをお持ちの場合は、MySQL ネイティブドライバの PHP Mysqlnd レプリケーションとロードバランシングプラグインを使用できます。

MySQL Connector を使用することに加えて、アプリケーションとデータベースサーバの間にロードバランサを追加することができます。アプリケーションに単一のデータベースエンドポイントが表示されるように、この追加を行います。このアプローチでは、アプリケーションのデータベース接続文字列を絶えず更新することなく、ロードバランサの背後にあるリードレプリカを透過的に追加または削除できるより動的な環境が可能になります。また、スクリプトを使用してカスタムヘルスチェックを実行することもできます。

図に示すように、トランスポートまたはレイヤ 4 ロードバランサを MySQL Connector とともに使用できます。現在、Elastic Load Balancing (ELB) ロードバランサは、RDS インスタンスへのトラフィックのルーティングをサポートしていません。したがって、多くの人が使用するオープンソースのソフトウェアベースのロードバランサである HAProxy などのオプションを検討することもできます。このソリューションでは、1 つのポートで読み込みクエリを受信し、もう 1 つのポートで書き込みクエリを受信するように HAProxy を構成できます。

もう 1 つの選択肢は、レイヤ 7 の SQL 対応ロードバランサを使用することです。複雑なルールを使用してデータベースにクエリを転送することができます。このタイプのロードバランサは、マルチステートメントで読み書きスプリットを適切に実行する方法を理解する、MySQL Connector よりも洗練された機能を備えています。このソリューションは、分散データベース環境でスケーリングの問題を処理するため、アプリケーション層のスケーリングを処理する必要がないため、アプリケーション自体にはほとんど変更が加えられません。これを実現するには、MaxScale、ProxySQL、MySQL Proxy などのオープンソースソリューションと商用ソリューションがあります。そのうちのいくつかは AWS Marketplace にあります。

まとめ
要約すると、アプリケーションの増加するニーズに対応するために、RDS 構成を拡張または縮小することができます。RDS はデータベースのスケーリングに大いに役立つため、お客様はアプリケーションやアプリケーションにより集中できるようになります。

 

Amazon Aurora: Fast DDLの詳細

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。

Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。

 

Fast DDLとは?なぜ考慮するのか

アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。

多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。

私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。

 

なぜ既存の方法では問題が起こるのか?

MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。

MySQLは以下のような処理を行っています:

  1. データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します
  2. 変更後のスキーマで新しい空のテーブルを作成します
  3. 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます
  4. 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します
  5. オリジナルテーブルをdropし、テーブルをリネームします

これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。

 

もっと良い方法はないのでしょうか?

これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。

完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。

Auroraでは、DDLをユーザが実行すると

  1. データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます

同期的に行う操作はこれだけで完了です。

そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。

DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。

もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。

パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。

TableComparison

明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。

このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。

質問やフィードバックはありますか?aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。

注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。

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

Amazon Auroraアップデート: クロスリージョン・クロスアカウントサポートの拡張、T2.Small DBインスタンス、リージョンの追加

Amazon Auroraの最近のアップデートを振り返ってみたいと思います。Amazon AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。Amazon Auroraの紹介は、【AWS発表】Amazon Auroraをご利用頂けるようになりました!や【AWS発表】Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください。

最近Auroraへ追加された機能は以下のとおりです

  • クロスリージョンスナップショットコピー
  • 暗号化されたデータベースのクロスリージョンレプリケーション
  • 暗号化されたスナップショットのアカウント間の共有
  • US West (Northern California)リージョンのサポート
  • T2.smallインスタンスサポート

 

クロスリージョンスナップショットコピー

Amazon Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。スナップショットを選択し、Snapshot ActionsからCopy Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。

au_copy_snap

この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。

 

暗号化されたデータベースのクロスリージョンレプリケーション

Amazon Aurora DBを作成する際に暗号化オプションを設定出可能です。

au_enable_encr

数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。クロスリージョンリードレプリカを作成するには、既存のDBインスタンスを選択し、メニューからCreate Cross Region Read Replicaを選択するだけです。

au_ccrrr_menu

その後、Network & Securityからリージョンを選択し、Createをクリックします。

au_pick_dest_reg

レプリケーション先のリージョンには必ず2つ以上のアベイラビリティゾーンを含んだDB Subnet Groupが必要です。

このパワフルな新機能について詳細は、ドキュメントをご覧ください。

 

暗号化されたスナップショットのアカウント間の共有

Amazon Aurora DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。

au_take_snapshot

DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。

AWS間で暗号化されたスナップショットを共有出来るようになりました。この機能を使うためには、DBインスタンスはdefault RDS keyではないマスターキーで暗号化されている必要があります。まず、スナップショットを選択し、Snapshot ActionsメニューからShare Snapshotを選択します。

au_share_snap_menu

そして、共有先のAWS Account IDを入力し(それぞれのアカウント毎にAddをクリックします)、Saveを選択します。

au_share_snap

この他にも、スナップショットの暗号化で使用したキーも共有する必要があります。この機能の詳細はドキュメントをご覧ください。

 

US West (Northern California)リージョンのサポート

Amazon Aurora DBをUS West (Northern California) リージョンでご利用頂けるようになりました。Auroraをご利用頂けるリージョンのリストは以下の通りです。

  • US East (Northern Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • US West (Northern California)
  • Canada (Central)
  • EU (Ireland)
  • EU (London)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Sydney)
  • Asia Pacific (Seoul)
  • Asia Pacific (Mumbai)

それぞれのリージョンでの価格については、こちらをご覧ください。

 

T2.smallインスタンスサポート

t2.small DBインスタンスをご利用頂けるようになりました。

au_launch

これらの経済的なインスタンスは、開発環境とテスト環境、および負荷の少ないプロダクションワークロードに最適です。また、Amazon Auroraの経験を積むこともできます。これらのインスタンス(昨年11月にリリースしたt2.mediumを含む6つのインスタンスと同様)は、Auroraが利用できるすべてのAWSリージョンで利用可能です。

t2.small DBインスタンスのオンデマンド価格はUS East (Northern Virginia)リージョンでは、1時間あたり$0.041からご利用いただけ、3年のAll Upfrontリザーブドインスタンスをご利用頂くと、1時間あたり$0.018となります。さらに詳細な価格についてはAmazon Auroraの料金ページをご覧ください。

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

Amazon RDS for MySQL バージョン: 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 リタイアメントのお知らせ

Amazon RDS for MySQLにおいて、MySQLのマイナーバージョン 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 のサポートを2017年7月19日に終了致します。これらのバージョンはAmazon RDSで2014年10月から2015年6月にかけてサポートされました。そして、新機能やセキュリティ・安定性向上を含んだバージョンに更新されてきました。

現在これらのバージョンをご利用の場合、現在サポートされているMySQLの最新のマイナーバージョン(2017/3/8現在: 5.6.34)にアップグレードを行うことを推奨致します。メジャーバージョンアップグレードと異なり、マイナーバージョンアップグレードはそれ以前データベースエンジンのマイナーバージョンと後方互換性を持っています。

2017年4月5日Auto Minor Version UpgradeがYesに設定されているDBインスタンスに対して、自動アップグレードを設定致します。アップグレードはこの日以降の通常のメンテナンスウインドウ内で順次実施されます。

2017年7月5日以降に起動しているMySQL 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23バージョンのRDS DBインスタンスは、Auto Minor Version Upgradeの設定に関わらず自動的に最新のマイナーバージョンに、各インスタンスに設定されているにメンテナンスウインドウ内でアップグレードが行われます。

2017年7月19日以降に起動している該当バージョンのRDS MySQLインスタンスは、メンテナンスウインドウに関わらず即座にアップグレードが実施されます。

RDSでのMySQLのマイナーバージョンアップグレードについては、こちらをご覧ください。

不明点などがありましたら、AWS サポートチームへコミュニティフォーラムかサポートセンター経由でご連絡下さい。

今回のアップグレードは、2017年4月5日到来前にアップグレード対象バージョン以上のマイナーバージョンもしくは、メジャーバージョンにアップグレードして頂くことで回避可能です。そのため、テスト環境などでテストを行っていただき、自動適用が開始される前に手動でアップグレードすることをお勧め致します。

 

原文はこちらをご覧ください。

 

Amazon Aurora: 暗号化されたスナップショット・データベースに対する新機能

本日Amazon Auroraの新機能を2つリリース致しました。

暗号化済みデータベースのクロスリージョンサポート

暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。また、リージョンをまたいだデータベースの移行も容易に行なえます。

また、暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。また、遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。

詳細は、クロスリージョンレプリケーションクロスリージョンスナップショットコピーのドキュメントをご覧ください。

 

AWSアカウント間で暗号化済みスナップショット共有をサポート

AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。

詳細なドキュメントはこちらをご覧ください。

Amazon Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。また、こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。

翻訳は星野が担当しました。原文は、Amazon Aurora Announces Encryption Support for Globally Distributed Database DeploymentsAmazon Aurora Supports Cross-Account Encrypted Snapshot Sharing

 

 

 

 

 

 

Amazon RDS – 2016 を振り返る

昨年は 294 件のブログを公開しましたが、取り上げることができなかった紹介に値するリリースはいくつもありました。そこで今回は Amazon Relational Database Service (RDS) に焦点を当て、このファミリーが 2016 年に進歩を遂げたすべてのポイントに関する総集編をお届けします。去年、同チームは 4 つの主なエリアに注目しました。

  • 高可用性
  • 拡張モニタリング
  • セキュリティの簡略化
  • データベースエンジンの更新

では、これらのエリアを見ていきましょう。

高可用性
リレーショナルデータベースは様々なタイプのアプリケーションにおいて、その中心にあります。高可用性の高いアプリケーションをお客様が構築できるようにするため、RDS は 2010 年初期からマルチ AZ サポートを提供しています (詳細は Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability をご覧ください)。データベースインスタンスの作成時にマルチ AZ 配置を選択すれば、複数のインスタンス設定、レプリケーションのアレンジ、ネットワーク、インスタンス、ネットワーク問題などの検出に使うスクリプトを書いたり、フェイルオーバーの決断や新しいセカンダリインスタンスをオンラインにするために、何週間にもわたりセットアップにかける時間を省くことができます。また、RDS はクロスリージョンリードレプリカを作成しやすくします。高可用性を実現しやすくするため、AWS が 2016 年に行ったその他の機能強化については次のブログをご覧ください。

 

拡張モニタリング
MySQL、MariaDB、Amazon Aurora のサポートなど、拡張モニタリングで行った最初の大きなステップは 2015 年末のことでした (New – Enhanced Monitoring for Amazon RDS)。そして引き続き 2016 年にも新たなニュースをお届けしました。

 

セキュリティの簡略化
保管中または利用中にかかわらず、お客様のデータを保護するための暗号化を可能な限りシンプルで使いやすくしたいと考えています。昨年に施した強化機能については次をご覧ください。

 

データベースエンジンの更新
オープンソースコミュニティと商用データベースのベンダーは非常に速いペースで新機能を追加したり新しいリリースを製作しています。AWS はその作業を密接に把握し重要なリリースに合わせて、できる限り早急に RDS を更新できるように努めています。2016 年のリリース内容については次をご覧ください。

 

次回の投稿
今年はすでに大きな発表がありました (詳細は AWS 2017 年の最新情報をご覧ください)。最近お知らせしたニュース (PostgreSQL との互換性を備えた Aurora バージョン) はもちろん、その他にも色々ご用意しています。お楽しみに! RDS、Amazon AuroraAmazon ElastiCache を最大限に活用する方法を詳しく説明している AWS データベースブログへの参加もご検討ください。

Jeff;

追伸 – このブログ投稿には、去年 AWS Database Migration Serviceスキーマ変換ツールに施したすべての強化機能は含まれていません。このトピックについては別件でブログを投稿する予定です。

シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。

難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。

しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。

シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。

シャーディングされたシステムをAuroraに集約するために – まずはじめに –

多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。

多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。

ShardMap

MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。

ShardMap1

残りのデータを移行する

この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって?

 

AWS Database Migration Service (AWS DMS)を是非ご活用下さい!AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。

ShardMap2

この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。

ShardMap3

 

複雑なシャードの扱い方

これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか?

それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。

AppTier

この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。

何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。

諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 この例では、Auroraインスタンスは次のようになります。

ShardMap4

MySQL以外のデータベースを利用している場合

他の仮定として、データベースエンジンとしてMySQLデータベースを利用をしている前提がありました。もしそうでなければ? OracleまたはMicrosoft SQL Serverを使用する場合はどうなるでしょうか? 大丈夫です! AWS Schema Conversion Tool が役立ちます!

ドキュメントの最初で「AWS Schema Conversion Toolは、ソースデータベースのスキーマとカスタムコードの大部分をターゲットデータベースと互換性のあるフォーマットに自動的に変換することで、異種データベースの移行を容易にします」と述べています。シャーディングされたシステムでは、ストアドプロシージャとトリガを使用してデータベース内に組み込まれた多くのビジネスロジックは、通常すでにアプリケーション側に移動されています。 AWS Schema Conversion Toolで、ソースデータベースとしてサポートされているデータベースエンジンでシャーディングされたシステムを利用している場合、Auroraへの変換と統合が可能かどうかを調べる価値があります。 統合の恩恵を受けるだけでなく、オープンソースプラットフォームへの移行のメリットも得られます。

さらに踏み込んで

さらに詳細に興味がありますか? AWS Database Migration Service を使用して、シャーディングされたデータベースを1つ以上のAuroraインスタンスに統合する方法を説明する資料をまとめはじめました。 この例では、DMSチームが提供するMySQLサンプルデータベースのシャーディングバージョンを使用しています。 私たちはこのシャーディングされたバージョンをRDSスナップショットとして利用できるようにしました。 スナップショットは公開されているため、こちらの説明に従って試すことが可能です。それぞれ、説明中でmysql-sampledb-master-shard、mysql-sampledb-shard1、mysql-sampledb-shard2と呼ばれていたものです。

 

— Ed Murray (manager at Amazon Web Services) (翻訳は星野が担当しました。原文はこちら)

 

 

 

 

 

 

RDS MySQL DBインスタンスからAmazon Aurora Read Replicaを作成可能になりました

24時間365日稼働しているアプリケーションが利用しているデータベースエンジンを他のデータベースエンジンに移行するにはいくつかの方法を使う必要があると思います。データベースをオフラインにせずに移行する良い方法として、レプリケーションを利用する方法があります。

本日、Amazon RDS DB for MySQLインスタンスを Amazon AuroraにAurora Read Replicaを作成して移行する機能をリリースしました。マイグレーションは、まず既存のDBスナップショットを作成し、そこからAurora Read Replicaを作成します。レプリカのセットアップが完了後、ソースデータベースとのレプリケーションの設定を行い最新のデータをキャッチアップします。レプリケーションラグが0になればレプリケーションが完了した状態です。この状態になった後に、 Aurora Read Replicaを独立したAurora DB clusterとして利用可能で、アプリケーションの設定を変更しAurora DB clusterに接続します。

マイグレーションはテラバイトあたり数時間かかります。また、6TBまでのMySQL DBインスタンスに対応しています。InnoDBテーブルのレプリケーションはMyISAMテーブルのレプリケーションよりもやや高速で、圧縮されていないテーブルの利点も受けられます。

RDS DBインスタンスをマイグレーションするためには、 AWS Management ConsoleからRDSのコンソールを選択し、Instance Actionsを選択します。その後、Create Aurora Read Replicaを選択するだけです:

rds_migrate_aurora_pick_src

そして、データベースインスタンスの情報やオプションを入力し、Create Read Replicaをクリックします:

rds_migrate_setup_aurora

コンソール上でマイグレーションの進捗状況を閲覧出来ます:

rds_migrate_progress

マイグレーション完了後、Aurora Read Replicaでレプリカラグが0になるのを待ちます(SHOW SLAVE STATUSコマンドをレプリカで実行し、“Seconds behind master”を監視します)。その後、ソースのMySQL DBインスタンスへの新しいトランザクションを停止し、Aurora Read ReplicaをDBクラスタに昇格させます:

rds_aurora_pick_promote
新しいクラスタが利用可能になるまで待機します(通常は1分程度):

rds_aurora_new_cluster

最後に、アプリケーションの設定をクラスタのread/writeエンドポイントを利用するように設定し完了です!

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