Amazon Web Services ブログ

Category: Database

発表: Amazon ElastiCache で Redis バックアップおよび復元を実現、クラスターのサイズ変更も可能に

インメモリキャッシュは、アプリケーション設計時またはソリューション構築時の大規模なパフォーマンス強化やコスト削減と同等に扱われます。ここで、サービスが 1 つのみの場合は、スケーリングする機能を強化しながら、継続的にクラウド内のインメモリキャッシュをより簡単にデプロイおよび活用できるようにします。冗談はさておき、この優れた機能を実現するクラウドサービスとは、もちろん Amazon ElastiCache です。Amazon ElastiCache は、パフォーマンスの高いインメモリデータストアまたはキャッシュをクラウドで実現する AWS マネージドサービスです。I/O 集約型または計算量の多いデータの低レイテンシー、安全性、アクセスを実現するための分散環境を作成、スケール、管理する簡単な方法を提供します。また、ElastiCache では、Amazon CloudWatch を通じて、キャッシュシステムのノードの主要なパフォーマンスメトリクスの可視性を強化すると同時に、障害が発生したノードを検出して置換することで、インメモリデータ構造サーバやキャッシュのインフラストラクチャを管理するオーバーヘッドを抑えることができます。この優れたサービスで、Redis バックアップおよび復元とクラスターのサイズ変更を実現しました。 Amazon ElastiCache に精通している方であれば、ElastiCache で次の 2 つのインメモリキー値エンジンがサポートされていることをご存じでしょう。 Memcached: パフォーマンスの高いオープンソースの分散メモリオブジェクトキャッシュシステム。データベースの負荷を軽減して動的なウェブアプリケーションを高速化することを当初の目的として 2003 年に開発されました。 Redis: オープンソースのインメモリデータ構造ストア。Redis クラスターを使用して、組み込みレプリケーション、アトミックオペレーションサポート、さまざまなレベルのオンディスクの永続性、高可用性を実現しながら、キャッシュ、メッセージング、データベースのブローカーとして開発され、2009 年に発表されました。 2016 年 10 月、Redis 3.2.4 使用の Redis クラスターがサポートされるようになり、ElastiCache Redis のユーザーは Redis クラスターを活用できるだけでなく、次のことが行えるようになりました。 クラスターレベルのバックアップの作成 バックアップ内のクラスターのシャード単位でのスナップショットの生成 最大 15 シャードの間で 3.5TiB のデータのワークロードのスケール ElastiCache や関連する機能を活用した Redis の使用については、「Amazon ElastiCache for Redis」の製品ページを参照してください。Redis […]

Read More

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日到来前にアップグレード対象バージョン以上のマイナーバージョンもしくは、メジャーバージョンにアップグレードして頂くことで回避可能です。そのため、テスト環境などでテストを行っていただき、自動適用が開始される前に手動でアップグレードすることをお勧め致します。   原文はこちらをご覧ください。  

Read More

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

本日Amazon Auroraの新機能を2つリリース致しました。 暗号化済みデータベースのクロスリージョンサポート 暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。また、リージョンをまたいだデータベースの移行も容易に行なえます。 また、暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。また、遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。 詳細は、クロスリージョンレプリケーションとクロスリージョンスナップショットコピーのドキュメントをご覧ください。   AWSアカウント間で暗号化済みスナップショット共有をサポート AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。 詳細なドキュメントはこちらをご覧ください。 Amazon Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。また、こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。 翻訳は星野が担当しました。原文は、Amazon Aurora Announces Encryption Support for Globally Distributed Database Deployments, Amazon Aurora Supports Cross-Account Encrypted Snapshot Sharing            

Read More

AWS Database Migration Service – 現在も増え続けているこれまでの移行数 20,000 件

AWS Database Migration Service について初めてブログ (AWS Database Migration Service) を投稿したのは 1 年ほど前のことです。その時点で AWS ユーザー 1,000 人がすでに AWS への移行の一部として同サービスを使用していました。簡単に説明すると、 とスキーマ変換ツール (SCT) は、AWS のお客様が高価な独自のデータベースやデータウェアハウスから、リレーショナルデータをよりコスト効率の良い 、、MySQL、MariaDB、PostgreSQL といったクラウドベースのデータベースやデータウェアハウスに、ダウンタイムを最低限に抑えた状態で移行できるようにサポートします。ユーザーの皆様からは、その柔軟性とコスト効率に優れた点において良い評価を頂いています。たとえば に移行すると、商用データベースに掛かる 10 分の 1 のコストで MySQL と PostgreSQL との互換性を持つデータベースにアクセスすることができます。Expedia、Thomas Publishing、Pega、Veoci といった企業による使用事例は AWS Database Migration Services Customer Testimonials でご覧いただけます。 独自の移行数 20,000 件 AWS のお客様は、これまでに を使用して 20,000 件もの独自のデータベースを AWS に移行しており、現在もその数は上昇する一方です (2016 年 9 […]

Read More

Amazon RDS – 2016 を振り返る

昨年は 294 件のブログを公開しましたが、取り上げることができなかった紹介に値するリリースはいくつもありました。そこで今回は に焦点を当て、このファミリーが 2016 年に進歩を遂げたすべてのポイントに関する総集編をお届けします。去年、同チームは 4 つの主なエリアに注目しました。 高可用性 拡張モニタリング セキュリティの簡略化 データベースエンジンの更新 では、これらのエリアを見ていきましょう。 高可用性 リレーショナルデータベースは様々なタイプのアプリケーションにおいて、その中心にあります。高可用性の高いアプリケーションをお客様が構築できるようにするため、RDS は 2010 年初期からマルチ AZ サポートを提供しています (詳細は Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability をご覧ください)。データベースインスタンスの作成時にマルチ AZ 配置を選択すれば、複数のインスタンス設定、レプリケーションのアレンジ、ネットワーク、インスタンス、ネットワーク問題などの検出に使うスクリプトを書いたり、フェイルオーバーの決断や新しいセカンダリインスタンスをオンラインにするために、何週間にもわたりセットアップにかける時間を省くことができます。また、RDS はクロスリージョンリードレプリカを作成しやすくします。高可用性を実現しやすくするため、AWS が 2016 年に行ったその他の機能強化については次のブログをご覧ください。 RDS SLA が Amazon RDS for MariaDB を対象に Amazon RDS がアジアパシフィック (ソウル) AWS リージョンで SQL Server 用のマルチ […]

Read More

新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech( リファレンスアーキテクチャ )、Gaming( リファレンスアーキテクチャ )、IoT( リファレンスアーキテクチャ )、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。 多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud(EC2)インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。 新しいTime to Live(TTL)管理 について この普及した重要なユースケースを合理化するため、新しくTTL(Time to Live)機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。 属性が指定され、TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。 DynamoDBストリームを使用することで(詳細は、「 DynamoDBアップデート – トリガ(Streams + Lambda)+クロスリージョンレプリケーションアプリケーション」を参照)。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。 テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。 指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。 上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。 また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス(CLI)からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。 TTL の利用事例(TUNE様)  AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。 HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。 今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。 知っておくべきこと あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。 […]

Read More

シャーディングされたシステムを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は各シャードへのアプリケーショントラフィックを表しています。 MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。 残りのデータを移行する この時点で、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インスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。 この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。   複雑なシャードの扱い方 これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか? それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。 この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。 何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。 諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 […]

Read More

新機能 – Time to Live (TTL) を使用した DynamoDB 項目の管理

AWS のお客様は を十分に活用しています。お客様は、その速度と柔軟性を気に入り、一貫性がある数ミリ秒台のレイテンシーを活かした広告技術 (リファレンスアーキテクチャ)、ゲーム(リファレンスアーキテクチャ)、IoT (リファレンスアーキテクチャ)、およびその他のアプリケーションを構築しています。また、DynamoDB はマネージ型のサーバーレスデータベースとして、数テラバイトというサイズのテーブルに対する 1 秒あたり数百万件ものリクエストを処理するようにスケールできる点も好評です。多くの DynamoDB ユーザーは、有効期限があるデータや、時間とともにアクセス頻度が低くなるデータを保存している場合があります。最近のログイン、トライアルのサブスクリプション、またはアプリケーションのメトリクスを追跡する場合もあります。保存期間が規制または契約で制限されるデータを保存している場合もあります。このような場合、これまでは独自の時間ベースのデータ管理を導入していました。大規模なケースでは、DynamoDB 項目のスキャン、データ属性のチェック、不要になった項目の削除リクエストの発行などを行うためだけに、数個の インスタンスを実行することもありました。これに伴って、アプリケーションのコストと複雑さが増大しました。 新しい Time to Live (TTL) による管理 この一般的で重要なユースケースを効率化するため、当社は本日から、新しい Time to Live (TTL) 機能の提供を開始します。この機能をテーブルごとに有効にし、項目の有効期限を含む項目属性を指定できます。項目属性を指定して TTL 管理を有効にすると (1 回の API コールで両方のオペレーションを実行できます)、DynamoDB が、有効期限が切れた項目を見つけて削除します。この処理は自動的にバックグラウンドで実行され、テーブルに対する読み取りまたは書き込みトラフィックに影響を与えることはありません。DynamoDB ストリーム(詳細については、「Sneak Preview – DynamoDB Streams」を参照) を使用して、実際の削除を処理またはアーカイブできます。削除は、ストリームの他の更新レコードのように、ローリング期間の 24 時間ベースで使用できます。有効期限が切れた項目については、AWS Lambda および DynamoDB トリガーを使用してコールドストレージへの移動、ログへの記録、または他のテーブルの更新を行うことができます。テーブルに対して TTL を有効にし、必要な属性を指定する方法を次に示します。 属性は DynamoDB の数値データ型とする必要があり、UNIX エポック時間形式に従って秒数として解釈されます。上記のスクリーンショットからおわかりのように、DynamoDB ストリームを有効にして、TTL を有効にしたときに削除される項目のプレビューを表示することもできます。また、コードから UpdateTimeToLive 関数を呼び出すか、 update-time-to-live コマンドを […]

Read More

コストアロケーションタグがAmazon DynamoDBに対応しました

Amazon DynamoDBのテーブルにタグを設定可能になりました。タグは多くのAWSサービスでサポートしている、シンプルでユーザがカスタマイズ可能なキー・バリューのペアです。DynamoDBのタグ対応は DynamoDBの利用料金の可視化に有効です。テーブル毎にタグを設定でき、タグ毎に料金を参照出来ます。 様々な環境(development/staging/production)で複数のDynamoDBテーブルを持っているシナリオを例に上げてご説明します。DynamoDBテーブルにタグを設定出来ます。例として、keyにEnvironment、valueにDevelopment, Staging, Productionとそれぞれ設定します。 DynamoDBコンソールでどのように設定するか見ていきましょう。設定を行う前にListTagsOfResourceとTagResourceのAPI操作を行う適切な権限を持っているか確認をして下さい。 AWS Management Consoleにサインインをし、https://console.aws.amazon.com/dynamodb/からDynamoDBコンソールを開きます Tablesを選択し、設定を行ないたいテーブルを選択します Settingsタブで、Tagsをナビゲーションメニューから選択します Add Tagsセクションで、KeyにEnvironment、ValueにDevelopmentを入力し、Apply Changesをクリックします 標準の動作では、新しく追加されたキーはbillingでは無効化されています。以下の手順でBilling Consoleよりアクティベートを行えます: AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます ナビゲーションメニューからCost Allocation Tagsを選択します User-Defined Cost Allocation Tagsセクションから、タグキー内の Environmentタグ横のチェックボックスを選択し、Activateをクリックします アクティベート済みのコストアロケーションタグがある場合、AWS Cost Explorerからタグ付けされたAWSリソースのコストを簡単にブレークダウンして閲覧出来ます: AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます ナビゲーションメニューからCost Explorerを選択し、Launch Cost Explorerを選択します 左上のメニューからMonthly costs by serviceを選択し、右のメニュー内の Time rangeから閲覧したいタイムレンジを指定します Filteringセクション内のFilter byからTagを選択します タグキーのオートコンプリートフィールドから Environmentを選択、Developmentをタグバリューのオートコンプリートセクションから選択し、Applyをクリックします 指定したタグ(Environment=Development)でコストがフィルタリングされます。コストはタグをAWSリソースに指定した時点から表示されます DynamoDB Management Console, AWS CLIやAWS […]

Read More

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を選択するだけです: そして、データベースインスタンスの情報やオプションを入力し、Create Read Replicaをクリックします: コンソール上でマイグレーションの進捗状況を閲覧出来ます: マイグレーション完了後、Aurora Read Replicaでレプリカラグが0になるのを待ちます(SHOW SLAVE STATUSコマンドをレプリカで実行し、“Seconds behind master”を監視します)。その後、ソースのMySQL DBインスタンスへの新しいトランザクションを停止し、Aurora Read ReplicaをDBクラスタに昇格させます: 新しいクラスタが利用可能になるまで待機します(通常は1分程度): 最後に、アプリケーションの設定をクラスタのread/writeエンドポイントを利用するように設定し完了です! — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More