Amazon Web Services ブログ

Tag: データベース

AWS 料金値下げ – EC2 の SQL Server Standard Edition

AWS は 62 回目となる値下げを発表いたします。今回の対象は EC2 の Microsoft SQL Server Standard Edition です。多くのエンタープライズワークロード (特にオンプレミスまたは企業データセンター) は、Microsoft Windows で実行されています。そのグローバルな展開およびパートナーエコシステムによって支えられたサービスの幅広さにより、Windows アプリケーションの構築、デプロイ、スケール、管理には AWS が最適な場所であると考えています。 Adobe、Pitney Bowes、デブリー大学といったお客様は、すべて中核となる実稼働 Windows Server ワークロードを AWS に移行済みです。これらのお客様のアプリケーションは、SharePoint サイトからカスタム .NET アプリケーションや SAP まで広範囲に実行しており、頻繁に SQL Server を使用しています。AWS の Microsoft SQL Server は EC2 Windows インスタンスで実行され、お客様のアプリケーション開発および移行をサポートできます。リレーショナルデータベースをオンプレミスで実行している場合のように、すべての設定を管理でき、32 ビットおよび 64 ビットバージョンのサポートがあります。本日、R4、M4、I3、X1 インスタンスで実行される EC2 上の Microsoft SQL Server Standard Edition のオンデマンドおよびリザーブドインスタンスの料金を、インスタンスタイプ、サイズ、リージョンに応じて最大 52% […]

Read More

オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。 AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。 この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。 以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。 お客様のフィードバックに基づいたアップデートの後、AWS SCT と […]

Read More

Oracle Database を Amazon Aurora に移行する方法

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。 データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。 AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。 すばらしい! では、どこから始まれば良いのでしょう? AWS SCT での移行手順 通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool […]

Read More

Amazon ElastiCache for Redis の リードレプリカの自動フェイルオーバのテスト

“信頼するが、確認する” – ロナルド・レーガン米国大統領、1987 このコメントで、レーガン大統領は、核軍縮条約の哲学について、ロシアの諺を引用しました。DevOpsにも同じ考え方が当てはまります!   Amazon ElastiCache for Redisは、自動化されたフェイルオーバとリカバリを備え、高可用性を提供しています。ElastiCacheクラスタを作成したければ、 Redis Cluster モードを使用し、クラスタ内のシャード数を設定します。各シャードには、1つのプライマリノード(読み取りと書き込み用)と0〜5つのレプリカノード(読み取りとフェールオーバー保護用)があります。1つのクラスタは、レプリカがゼロ(1ノード)のシャードと同じくらい小さくても、5つのシャード(5つのレプリカ(合計90ノード))を持つことができます。   AWSでは障害が頻繁に発生することはありませんが、いずれのマシンでも障害は発生します。レプリカノードに障害が発生すると、障害が検出され、数分でノードが置き換えられます。   Redis Cluster では、プライマリノードに問題が起きた時に、Redis Cluster は障害を検知しレプリカノードを新しいシャードのプライマリとして昇格させます。このプロセスは大体30秒程で実施されます。問題の起きたノードは入れ替えられ、クラスタのレプリカノードとして復帰します。Redis ClusterとElstiCacheを、エンジンとして Redis 3.2.4 と Cluster モードを有効にすることによって使うことができます。   これを信じてください…しかし検証するべきです。   ElastiCacheのテストフェイルオーバのおかげで検証は簡単です。マネジメントコンソールかAWS CLIを使用し、ElasiCache クラスタのいずれかのノード障害をシミュレートする事ができます、そして、どのようなプロセスで貴方のアプリケーションが動くのかも見ることができます。マルチシャード、もしくはシングルシャードの環境でもテストは可能です。さらに古いRedis 2.8の環境でもテストは可能です。 コンソールまたはAWS CLIを使用して、ElastiCacheクラスタ内の任意のノードの障害をシミュレートし、自分のアプリケーションでフェールオーバープロセスがどのように機能するかを確認できます。マルチシャード環境とシングルシャード環境、さらに古いRedis 2.8ブランチ環境でもフェールオーバーをテストできます。コンソールでこれを行うには、クラスタとシャードを選択してノードビューを表示し、次にフェールオーバープライマリを選択します。マネジメントコンソールでテストを行う際には、クラスタとシャードを選択してNode Viewを確認し、次にFailover primaryを選択します。   使用には注意してください。どのようなクラスタでも同じように動きます。なぜならどのクラスタも開発環境、テスト、本番かをAWSが知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。   自動フェイルオーバのテストを試してみてください!   翻訳は桑野が担当しました。原文はこちら。

Read More