Amazon Web Services ブログ

Category: Database

分散型可用性グループを使用して、ハイブリッドMicrosoft SQL Serverソリューションを設計する方法

モノリシックでミッションクリティカルなMicrosoft SQL ServerデータベースをオンプレミスからAWS(Amazon EC2ベースのSQL Server)に移行することは、しばしば困難な作業です。主な課題は次の通りです: 継続的なダウンタイム – ビジネスに悪影響を及ぼす可能性のあるカットオーバー中の継続的なダウンタイムウィンドウが発生する課題 データ同期の課題 – オンプレミスに配置されたデータベースとAWS上のデータベースを同期した状態に維持するための課題 柔軟性の欠如 – 移行のための段階的なアプローチを計画・実行する為の柔軟性を確保する課題 この記事では、重要なSQL ServerデータベースをAWSにリフト&シフト(またはリフト&トランスフォーム)するためのハイブリッドソリューションの構築方法について詳しく説明します。このソリューションでは、SQL Server 2016で導入された新しい機能である分散型可用性グループを使用します。この記事では、分散型可用性グループを使用して移行を制御し、柔軟性を高める段階的アプローチについても説明します。 分散型可用性グループの概要 分散型可用性グループは、2つの個別の可用性グループにまたがる特別なタイプの可用性グループ(AG)です。分散型可用性グループは複数の可用性グループの1つ(または複数のAGの中の1つ)と考えることができます。基礎となる可用性グループは、2つの異なるWindows Server Failover Cluster(WSFC)で構成されます。 分散型可用性グループアーキテクチャは、既存のオンプレミスWindows Server Failover Cluster(WSFC)をAWSに拡張するよりも効率的です。データは、オンプレミスのプライマリからAWS上の1つのレプリカ(フォワーダ)にのみ転送されます。フォワーダは、AWS上の他のリードレプリカにデータを送信する役割を担います。このアーキテクチャにより、オンプレミスとAWSの間のトラフィックフローが削減されます。 アーキテクチャ概要 次の図は、ソリューションの全体的なアーキテクチャを示しています。 図に示されているように、最初のWSFCクラスタ(WSFC1)はオンプレミスでホストされています。オンプレミス可用性グループ(AG1)はこのWSFCクラスタに配置されます。 2番目のWSFCクラスタ(WSFC2)はAWSでホストされます。 AWS可用性グループ(AG2)はこのWSFCクラスタに配置されます。 このユースケースでは、オンプレミスのSQL Serverインスタンスとデータベースは、従来の物理サーバーまたは仮想マシン(VM)によってホストされています。 AWSのSQL ServerインスタンスはAmazon EC2でホストされ、SQL ServerデータベースはAmazon EBSボリュームで構成されます。 AWS Direct Connectによって、オンプレミスからAWSへの専用ネットワーク接続を確立しています。 前述のアーキテクチャ図に示すように、オンプレミス可用性グループ(AG1)には2つのレプリカ(ノード)があります。これらの間のデータ転送は、自動フェイルオーバーを使用して同期します。オンプレミスレプリカの1つに障害が発生すると、AGは2番目のレプリカにフェールオーバーすることで、アプリケーションとユーザーはDBを使用できます。各可用性グループは、1つのプライマリレプリカと最大8つのセカンダリレプリカをサポートしています。高可用性の要件と拡張性のニーズに基づいて追加のレプリカを同期または非同期にする必要があるかどうかを判断します。 AWS可用性グループ(AG2)にも2つのレプリカがあり、それらの間のデータ転送は自動フェールオーバーで同期しています。 EC2インスタンスまたは1つのアベイラビリティゾーンに障害が発生すると、AGは別のアベイラビリティゾーンにある2番目のEC2インスタンスにフェールオーバーします。 このソリューションの一環として、分散型可用性グループを構成します。このグループには、オンプレミス可用性グループ(AG1)とAWS可用性グループ(AG2)の両方が含まれます。分散型可用性グループは、前述の図において赤い点線で示すように、データベースを非同期で同期させます。 フォワーダ(前述の図で緑文字で表されている)は、AWS内の他のリードレプリカにデータを送信する役割を担います。このデータ転送により、オンプレミスとAWS間のトラフィックフローが減少します。オンプレミスからAWSへのデータ転送はプライマリレプリカから一度だけ実施され、フォワーダは残りの伝播を処理します。 どの時点でも、書き込みに使用できるデータベースは1つだけです。残りのセカンダリレプリカデータベースは読み取り用に使用できます。前述のサンプルアーキテクチャ図では、社内のプライマリデータベースを読み取り/書き込み可能にし、AWSセカンダリデータベースを読み取りに使用できます。 AWSでリードレプリカを追加できることが重要なメリットです。この能力があれば、AWSへの移行に際して、読取り専用アプリをAWSに最初に移行することができます。また、データベースは、AWS上のアプリケーションとそのユーザーにも近くなります。 読み込みのワークロードをスケールアウトする場合は、AWSにさらに多くのリードレプリカを追加できますし、複数のアベイラビリティゾーンに配置することも可能です。このアプローチは、以下のアーキテクチャ図で表されます。この図では3つの異なるアベイラビリティゾーンに、それぞれリードレプリカを配置しています。 段階的な移行方法 分散型可用性アーキテクチャを使用することで、段階的な移行が可能となり、移行における柔軟性を高めることができます。 フェーズ1 この段階では、ほとんどの読取り専用アプリケーションをAWSに移行して、AWS上の読取り専用セカンダリデータベースにアクセスします。読み取り/書き込みを行うアプリケーションは、引き続きオンプレミスのプライマリ・データベースにアクセスします。 クラウド移行のこのフェーズでは、ストレステスト、機能テスト、およびデータベース作業負荷の回帰テストが重要な要素です。読取りワークロードをサポートするためにEC2インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。 […]

Read More

Database Migration Playbook が公開されました!

Database Migration Playbooks(Amazon Web Services と NAYA Tech の共同プロジェクト)とは、異種間データベース移行計画を成功させるためのベストプラクティスに焦点を当てた一連のガイドです。このプレイブックは、AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Servies (AWS DMS) を含む、既存の自動化および半自動化されたAmazonデータベース移行ソリューションおよびツールを補完するものです。

「Oracle to Amazon Aurora Migration」プレイブックの初版では、Oracle 11g と12cのデータベース機能とスキーマオブジェクトを Amazon Aurora with PostgreSQL compatibility に移行するためのベストプラクティスに重点を置いています。移行するためには、PostgreSQLデータベースエンジン自体に組み込まれている機能と、様々なAWSサービスやソリューションの両方を使用しています。

Read More

Oracle データベースから Amazon Aurora PostgreSQL データベースへの移行の概要

この記事では、Oracle データベースから Amazon Aurora PostgreSQL データベースへの移行プロセスのデモを行うために、リソースをデプロイする AWS CloudFormation スタックを構築します。これは異種間移行であるため、How to Migrate Your Oracle Database to PostgreSQL で詳しく説明されているものと同様の 2 フェーズのアプローチに従います。 この記事は、AWS Schema Conversion Tool (AWS SCT) と AWS Data Migration Service (AWS DMS) の中核的な概念をより良く理解するために役立つ移行スタックの構築に焦点を当てます。また、データベースパラメータグループを使用して、移行のためにターゲットの Amazon Aurora PostgreSQL データベースでトリガーを無効化する方法についても説明します。 今回は、AWS DMS で Oracle データベース (HRDATA) が事前にインストールされた Amazon EC2 インスタンス、Amazon Aurora PostgreSQL クラスター、およびレプリケーションインスタンスをデプロイするために AWS CloudFormation を使用します。移行プロセスに役立てるため、Amazon Virtual Private […]

Read More

AWS Database Migration Service のログ管理

AWS DMS を完全に管理できるように、レプリケーションインスタンスの移行ログを管理する機能をAWSは導入しました。この機能を使用することで、特定のレプリケーションインスタンスの各タスク用のログがどれくらいストレージを消費しているかを確認することもできます。さらに、この機能を利用すると、あなたが都合の良いときにログファイルをパージできます。

Read More

[AWS Black Belt Online Seminar] データウェアハウスのAWSへの移行 資料及びQA公開

こんにちは、ソリューションアーキテクトの有岡です。 先日(2018/3/19)開催致しました AWS Black Belt Online Seminar「データウェアハウスのAWSへの移行」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

Read More

新機能 – Amazon DynamoDBに継続的バックアップとPoint-In-Time-Recovery(PITR)機能が追加されました

Amazon DynamoDBチームはencryption at restに引き続き新しい機能を発表しました。AWS re:Invent 2017 では、グローバルテーブルの作成と DynamoDBテーブルのオンデマンドバックアップとリストアを発表しました。そして今日、継続的バックアップとしてPITR(ポイントインタイムリカバリ)を利用出来るようになりました。 AWS Management Consoleからワンクリックするか、簡単なAPIコール、またはAWSコマンドラインインターフェイス(CLI)を使用して継続的バックアップを有効にすることができます。DynamoDBはPITRが有効になってから35日以内であれば1秒単位でデータをバックアップし、1秒単位でリストアできます。誤った書き込みや削除を防ぐためにこの機能を構築しました。開発者がステージングではなくプロダクションに対してスクリプトを実行した場合や誤ったDeleteItemを実行した場合はPITRでカバー出来ます。その為予測できないようなシナリオにも利用出来ます。オンデマンドバックアップはアーカイブ目的のために必要なタイミングを指定できますが、PITRは偶発的なデータ消失に対する追加の保険として機能します。これがどのように機能するか見てみましょう。 継続的バックアップ マネジメントコンソールでこの機能を有効にするには、テーブルに移動して[ バックアップ ]タブを選択します。そこから、Enableをクリックするだけで有効になります。また、UpdateContinuousBackups API呼び出しを使用して継続的バックアップを有効にすることもできます。 継続的バックアップを有効にした後、最も遠い復元日と最新の復元日時を確認出来ます。 削除したい古いユーザーデータがたくさんある、というシナリオを例にとってみます。 私はlast_updateに格納されている日付に基づいてアクティブなユーザーだけに通知を送信したいと考えました。そしてサービスを使用していないユーザーを削除するために簡単なPythonスクリプトを書くことに決めました。 import boto3 table = boto3.resource(“dynamodb”).Table(“VerySuperImportantTable”) items = table.scan( FilterExpression=”last_update >= :date”, ExpressionAttributeValues={“:date”: “2014-01-01T00:00:00″}, ProjectionExpression=”ImportantId” )[‘Items’] print(“Deleting {} Items! Dangerous.”.format(len(items))) with table.batch_writer() as batch: for item in items: batch.delete_item(Key=item) すばらしい!これでサービスに2013年以来ログインしていない厄介な非アクティブユーザをすべて削除するはず・・・CTRL + C CTRL + C CTRL + […]

Read More

AWS CloudFormation を使用して Amazon DynamoDB テーブルとインデックスの Auto Scaling を設定する方法

AWS リソースをデプロイする上でのベストプラクティスは、Infrastructure as Code を扱う構成システムを使用することです。Infrastructure as Code は、開発者とオペレーションを連携させてアプリケーション配信を自動化する DevOps プラクティスの成功の鍵です。インフラストラクチャ全体を AWS CloudFormation テンプレートのコードとしてモデリングすることで、次のような利点があります。 クラウドソース用の信頼できる唯一の情報源を確立 開発環境とテスト環境のデプロイメントの自動化 災害対策の準備 バージョン管理などのコード管理ツールとの統合 Amazon DynamoDB などのサーバレスデータベースと組み合わせて AWS CloudFormation テンプレートを使用することで、アジャイルな DevOps プロセスを採用した開発チームの高速なオペレーションを大幅に簡素化できます。この記事では、実際の例と、AWS CloudFormation を使用して DynamoDB の Auto Scaling を設定する方法をご説明します。 注意: この記事では、ソリューションについて説明するためのスクリーンキャストを作成しました。どうぞお試しください。 DynamoDB の Auto Scaling DynamoDB は、あらゆる規模で一貫性のある 1 桁ミリ秒台のレイテンシーを必要とするアプリケーション向けの、完全マネージド型で、高速の、スケーラブルかつ柔軟なクラウドデータベースサービスです。2017 年、AWS は DynamoDB に Auto Scaling 機能を追加しました。Auto Scaling を使用すると、予測不能なパフォーマンスのニーズを持つアプリケーションの管理を簡素化することができます。Auto Scaling では、テーブルとグローバルセカンダリインデックスの読取りおよび書込み容量の上限と下限、およびターゲット使用率を構成できます。 AWS CloudFormation […]

Read More

OHDSI を使用して健康分析のために AWS でデータ科学環境を作成する

ヘルスケアデータにテクノロジを適用することには、多くのエキサイティングで重要な成果をもたらす可能性があります。ヘルスケアデータから生成された分析は、医療従事者が自分達が提供するケアを向上させるためにより良い意思決定を行えるようにすることで、個人と集団の健康を改善するようにエンパワメントできます。 観察的なヘルスデータ科学と情報 (OHDSI、「オデッセイ」と発音する) プログラムとコミュニティは、観察的健康データを保存し、分析するためのデータ標準とオープンソースソリューションを生成することを目標にしています。OHDSI ツールを使用して、集団全体の健康を可視化することができます。患者のコホートを構築し、さまざまな状態の発生率を分析し、特定の状態の患者に対する治療の効果を推定することができます。また、機械学習アルゴリズムを使用して健康成果の予測をモデル化することもできます。 ビッグデータツールの操作をするときにしばしば直面する課題の一つは、ツールを実行するときに必要なインフラストラクチャが必要になることです。もう一つの課題は、これらのツールを実装して使い始めるための学習曲線です。アマゾン ウェブ サービスを使用すると、エンタープライズクラスのインフラストラクチャーとテクノロジーを手ごろな費用で伸縮自在で自動化された方法で使用可能にすることにより、従来の IT の多くの課題に対応できるようになります。この記事では、AWS テクノロジーにいくつかの OHDSI プロダクト (Atlas、Achilles、WebAPI、およびOMOP Common Data Model) を組み合わせる方法を示します。そうすることにより、ヘルスデータ科学と情報環境を迅速に、少ない費用で実装できます。

Read More

Amazon RDS リザーブドインスタンスのコストを節約するために AWS コスト管理製品を使用する

Amazon RDS を使用すると、クラウド内のリレーショナルデータベースを迅速かつ簡単に設定、操作、拡張できます。Amazon RDS Reserved Instances(RI)には、1年間または3年間のデータベースインスタンスを予約するオプションが用意されています。このオプションでは、オンデマンド価格と比較して大幅な割引(最大69%)があります。 この記事では、AWS Cost Management 製品を使用する際に、RI でコスト削減の機会を特定するのに役に立つ方法を学ぶことができます。同時に、ネイティブの AWS ツールを使用すると、新規および既存の Amazon RDS の管理に役立てることができます。 AWS Cost Explorer を使用すると、AWS のコストと使用状況を視覚化し、理解し、管理することができます。すでにご存知とは思いますが、Cost Explorer は、コスト分析と使用状況の分析を開始するのに最適です。しかし、Cost Explorer でも、Amazon RDS の使用状況履歴に基づいた、RI 購入推奨事項が提供されていることをご存知でしたか? Cost Explorer の左上隅にあるナビゲーションメニューを使用して、Recommendations エリアから RDS をすばやく選択し、カスタマイズされた RI 購入推奨事項にアクセスできます。 Amazon RDS の Cost Explorer の RI購入推奨事項を開始する 次のスクリーンショットでは、Cost Explorer コンソールを見ることができます。  支払人(マスター)のアカウントから、Cost Explorer が識別した RI 購入機会にアクセスできます。これを行うには、Cost Explorer の RDS RI […]

Read More

2018 年でこれまでに最もアクセスが多かった Amazon DynamoDB 開発者ガイドページのトップ 20

Amazon DynamoDB 開発者ガイドには、Amazon DynamoDB のコンセプトの概要と、各種機能を使用するための詳しい手順が説明されています。以下のリストには、2018 年の最初の 2 ヵ月間、このガイドの中でアクセスが最も多かったページ 20 件を記載しています。このリストには、各ページの内容を説明するために、概要とそれぞれのリンクが含まれています。このリストを使用して、AWS の他のお客様が何を読んでいるかをご覧ください。前から知りたいと思っていた DynamoDB トピックに対する興味が湧くかもしれません。 クエリの操作 Query オペレーションと、プライマリキー値に基づいてアイテムを検索するためにこのオペレーションを使用する方法について学びます。複合プライマリキー (パーティションキーまたはソートキー) がある任意のテーブルまたはセカンダリインデックスをクエリすることができます。 DynamoDB の使用開始 これらの言語別チュートリアルは、DynamoDB についてより詳しく学ぶために役立ちます。これらに含まれるサンプルコードを、ダウンロード可能なバージョンの DynamoDB、または DynamoDB ウェブサービスで実行してください。 DynamoDB ローカル (ダウンロード可能バージョン) のセットアップ ダウンロード可能なバージョンの DynamoDB を使用して、DynamoDB ウェブサービスにアクセスすることなくアプリケーションを記述してテストすることができます。本番用にアプリケーションをデプロイする準備が整ったら、コードを若干変更するだけで DynamoDB ウェブサービスを使用できるようになります。このダウンロード可能バージョンは、プロビジョニングされたスループット、データストレージ、およびデータ転送の料金の節約にも役立ちます。 テーブルのベストプラクティス DynamoDB でのテーブルを使った作業時には、これらのベストプラクティスに従うことが推奨されます。 DynamoDB での制限 これらは、DynamoDB における現在の制限 (または、場合によっては無制限) です。別途指定されている場合を除き、制限はそれぞれ AWS リージョン単位で適用されます。 DynamoDB コアコンポーネント DynamoDB では、テーブル、項目、および属性を使って作業します。これらのコアコンポーネントの詳細について学んでください。 DynamoDB での項目の操作 DynamoDB で、項目とは属性の集まりです。各属性には名前と値があります。DynamoDB は、項目の作成、読み取り、更新、および削除のために […]

Read More