Amazon Web Services ブログ

Category: Database

AWS Database Migration Service を使用して Amazon Aurora から Amazon S3 にデータをレプリケート

このブログ記事でご紹介するのは、AWS CloudFormation テンプレートを使って Amazon Aurora のようなリレーショナルデータベースから Amazon Simple Storage Service (Amazon S3) にデータをレプリケートできるよう、設定を自動化する方法です。CloudFormation テンプレートのサンプルを使って説明していくので、ニーズに合わせて応用してください。 AWS Database Migration Service (AWS DMS) を使えば、データをあるデータソースから別のデータソースに移行できます。たとえば、Oracle から Aurora、NoSQL から SQL、オンプレミスからクラウドへの移行などがあります。顧客が DMS を利用するのは 1 回限りのデータ移行の場合だけではありません。ETL プロセスの一部として継続的な異種データレプリケーションを行う場合にもよく利用します。それこそがこのブログ記事のテーマです。 ソリューションの概要 アーキテクチャを図で示します。 この CloudFormation テンプレートのサンプルは、この例に必須のすべてのリソースを記述しプロビジョニングします。コードは GitHub で探すことができ、テンプレートをスタックとしてデプロイするには [Launch Stack] ボタンをクリックします。注意: us-east-1 リージョンでは、このテンプレートは RDS DB クラスタースナップショットを使用します。スタックを別のリージョンにデプロイしたい場合は、希望するリージョンにスナップショットをコピーして、CloudFormation テンプレート内の SnapshotIdentifier の値を置き換えます。 このプロセスの開始からスタックが作成されるまでには、約 50 分ほどかかります。このテンプレートは下記の処理を行います。 AWS DMS Sample Database […]

Read More

Amazon RDS for MySQLの delayed replicationで障害から復旧を行う

Amazon RDS for MySQLでdelayed replicationをサポートしました。これにより、レプリカデータベースがソースデータベースより遅延する期間を設定できます。標準のMySQLレプリケーション設定では、ソースとレプリカの間の遅延が最小限に抑えられています。今回のアップデートで意図的な遅延を導入するオプションを選べるようになりました。 遅延は、人為的なエラーから復旧させる必要がある場合に非常に役立ちます。たとえば、誤ってプライマリデータベースからテーブルを削除した場合、レプリカで同じクエリを実行する必要はありません。テーブルが削除される直前でレプリケーションを停止し、レプリカをスタンドアロンインスタンスに昇格させることができます。このブログ記事では、delayed replicationを使用して、このようなシナリオから復旧させる方法をご紹介します。 次の図は、遅延が3600秒(1時間)に設定されたレプリカを人為的エラーから回復する方法を示しています。まず、レプリケーションを停止します。次に、ログの問題の箇所を見つけ、問題のクエリが実行される直前までトランザクションを実行し。最後に、レプリカをマスターに昇格させます。   前提条件 delayed replicationをチェックする前に、Amazon RDS for MySQLソースデータベースインスタンスでMySQL 5.6.40または5.7.22以降が必要です。また、インスタンスに接続するためのMySQLクライアントと、データベースにアクセスできる適切なセキュリティグループが必要です。 バイナリログを十分な時間保持していることを確認してください。バイナリログの詳細については、 MySQL Binary Logsを参照してください。次のコマンド例は、保持期限を24時間に設定する方法を示しています。 call mysql.rds_set_configuration(‘binlog retention hours’, 24);   シナリオの設定 既存のAmazon RDS for MySQLデータベースを既存のリードレプリカで使用するか、新しいデータベースを作成します。このブログ記事では、既存のRDS MySQLデータベースを利用し、新しい読み取りレプリカを作成します。 データベースの作成 MySQLインスタンス用のAmazon RDSをまだお持ちでない場合は、作成をしてください。クライアントマシンからのアクセスを許可するセキュリティグループを使用してデータベースを構成してください。作業したいMySQLデータベースがすでにある場合は、この手順をスキップしてください。 AWSマネージメントコンソール、AWS CLI、AWS SDK、またはAWS CloudFormationテンプレートを使用して、MySQLデータベース用のRDSを作成します。MySQLインスタンスの作成を支援する必要がある場合は、Create and Connect to a MySQL Database with Amazon RDSの手順に従ってください。次のスクリーンショットは、すでに設定されて使用可能な1つのデータベースインスタンスを示しています。 データベースに接続する マスターデータベース・インスタンスが作成されて使用可能になったら、そのデータベースインスタンスに接続します。Amazon EC2 Linuxマシンを使用している場合は、次のコマンドに示すように、いくつかの環境変数を設定して余分なタイピングを省くことができます。 export REGION=”us-west-2″ export […]

Read More

Amazon Dynamo DB グローバルテーブル 東京リージョン対応のお知らせ

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   Amazon DynamoDBのグローバルテーブル機能が東京リージョンに対応しましたのでお知らせいたします。 DynamoDBはどのような規模でも信頼性が高いパフォーマンスを維持できる、完全マネージド型の非リレーショナルデータベースです。グローバルテーブルの機能により、マルチリージョン、マルチマスターのデータベースを構築することが可能となり、そのレイテンシーを 10 ミリ秒未満に維持できるようになります。選択した AWS リージョンにテーブルの更新内容を自動的にレプリケーションすることができ、また、グローバルテーブルを使用して、DynamoDB テーブルデータを他の AWS リージョンにレプリケーションすることで可用性を高めることもできます。   作成済のDynamoDBテーブルを選択すると、「グローバルテーブル」のタブが出てきます。設定作業はテーブル作成後に行うこととなりますが、テーブルが空である必要があるのでご注意ください。 ここから、機能を有効にすることができます。機能を使うためにはDynamoDB Streamsの機能をオンにする必要があります。DynamoDB Streamsは、テーブルに対して発生した変更をキャプチャし、例えばAWS Lambdaを実行させるなどに機能をつかさどります。グローバルテーブルはこの機能を用います。 そして対象リージョンを指定すると、レプリカテーブルが指定したリージョンに作成されます。 DynamoDBは今年の5月に継続的バックアップとPITR(ポイントインタイムリカバリ)に対応しより使いやすくなっています。今回のグローバルテーブル対応で、より高度な耐障害性とリージョンワイドのアプリケーションへのより高速な対応性能を備えることなりました。 – プロダクトマーケティング エバンジェリスト 亀田

Read More

【開催報告】Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –

こんにちは。AWS ソリューションアーキテクトの八木達也 ( @ygtxxxx ) です。 7月23日に、「Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –」を開催いたしました。 AWSジャパン主催でデジタル広告業界の方向けのイベントを開催するのは2年ぶりでしたが、定員60人のところ55名の方にお集まりいただき、盛況となりました。             このイベントは「Digital Advertising、AdTech 領域における Machine Learningの実践知」を「互いに学び合う」ことができる場を作ることを目標としていたため、AWSメンバーによるプレゼンテーションだけではなく、お客様プレゼンテーションを中心としたAGENDAを構成しました。機会学習という領域における、テクノロジー視点でのお取組み、組織育成視点でのお取組み、それぞれの視点で最先端な活動をなさる方々よりご登壇を頂きました。 まずは主催者の唐木/八木よりオープニングセッションを行いました。 唐木より全体の説明を行い、八木より「Machine Learning for Digital Advertising」というタイトルでプレゼンテーションを行いました。 Machine Learning for Digital Advertising from Amazon Web Services Japan 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update from Amazon […]

Read More

1億2500万人のゲーマーをオンラインでスムーズにプレーするにはどうすればいいでしょうか?Epic GamesがFortniteについて語ってくれました。

FortniteのクリエイターであるEpic Gamesは、2018年7月17日にニューヨークのJavits Centerで開催されたAWSサミットでAWSサービスへオールインを明らかにしました。 ゲーム上に1億2500万人のプレイヤーを想像してください。1億2500万人、それはニューヨークの人口の15倍になります。マルチプレイヤーゲームをプレイしているすべての人が、夢を実現するでしょう。 プレイヤー全員が素晴らしい時間を過ごすことを保証しなければなりません。どのようにしてこの大変多くの人々のすべてのデータを取り扱うのでしょう? Epic GamesのFortnite クリエイターが今年、自分自身でそれを見つました。Fortomiteのこの驚異的な成長により、Epic Gamesが毎月2ペタバイトのデータを扱わなければいけないことを意味します。2,000テラバイトのハードドライブが積み上がっていることを想像してください。どのようにゲームデベロッパーがその規模の情報量を処理するでしょうか?

Read More

Database Migration Service を使用して、リレーショナルデータベースから Amazon Kinesis に CDC データをロードする

多くの大企業は、タイムリーな情報を得るために、データ処理をバッチ処理からリアルタイム処理に移行しています。そうすることの課題は、リアルタイムのデータ処理アーキテクチャが着信データストリームに追いつけなければならないということです。これには、強固な耐障害性と伸縮性が必要です。 このブログ記事では、リアルタイムのデータ処理アーキテクチャと、Amazon RDS for SQL Server データベースへの変更をキャプチャして Amazon Kinesis Data Streams に送信する方法について解説します。Amazon S3 および AWS Lambda をデータの初期ロードに使用する方法と、AWS Database Migration Service を進行中のレプリケーションに使用する方法を示します。 AWS では、Amazon Kinesis Data Streams、AWS Database Migration Services (DMS)、AWS Lambda などのデータ処理を適正に行うためのサービスを数多く提供しています。DMS は、既存のデータを移行し、進行中の変更データをソースシステムからターゲットシステムにレプリケートするのに役立ちます。 前提条件および仮定 このソリューションを自分で使用するには、AWS のサービスへのアクセスを提供する AWS アカウントが必要です。 サービスは us-east-1 リージョンで作成する必要があり、ネットワーキングの考慮事項を簡素化するために us-east-1 リージョンの同じ VPC で設定する必要があります。 Lambda 関数のコンパイル済み Java コードは、この Amazon Repository にある ZIP ファイルに含まれています。S3 バケットを作成し、ZIP […]

Read More

Autodesk が Amazon Aurora を使用してデータベースのスケーラビリティを向上させ、レプリケーションラグを削減した方法

Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアのリーダーです。Autodesk は物を作る人のためのソフトウェアを作成しています。高性能の車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万人もの Autodesk ユーザーがソフトウェアで行っていることを体験したことがあると思われます。 Autodesk は Amazon RDS で稼働するマネージド MySQL データベースと Amazon EC2 でホストされるセルフマネージド MySQL データベースの両方からAmazon Auroraに移行しました。このブログ記事は、その経験をまとめ、次の点について取り上げます。 Autodesk の Amazon Aurora への移行決定に影響を与えた要因 移行上の特定の利点 移行と最適化に関して学んだベストプラクティスと教訓 まず、クラウドで生まれた Autodesk Access Control Management (ACM) アプリケーションの移行パスを確認します。始めに Amazon RDS for MySQL を選択し、スケーラビリティ、可用性、およびパフォーマンスを向上させるために Aurora に移行しました。ACM が移行を問題なく完了させたことで、Autodesk の他のいくつかのアプリケーションが Aurora に移行する意欲が高まりました。EC2 でホストされているセルフマネージド MySQL データベースを Amazon Aurora に移行する主要な例として、BIM 360 Field Classic について説明します。 […]

Read More

統合ワークロードに向けた MySQL と互換性がある Amazon Aurora を計画・最適化する方法

MySQL と互換性がある Amazon Aurora はデータベースワークロード統合を検討中のお客様から好評をいただいています。Aurora MySQL は、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Aurora MySQL は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 今回のブログ記事では、大規模な統合データベースワークロードのために行う Amazon Aurora の最適化に役立つガイダンスをいくつかお伝えします。また、「統合の費用はどれくらいかかりますか?」や「データセットはどのくらいの大きさにできますか?」など、よくある質問にお答えします。 上記の質問はシンプルですが、必ずしも回答がシンプルになるわけではありません。回答は、お使いのデータセットやワークロードのパターンによって大きく異なります。 データベース統合の定義 統合のユースケースに関しては、以下の要素に的を絞り、それからコンテキストに応じた Aurora MySQL の操作方法について詳細を説明します。 テーブルのサイズ。統合により、一般的にテーブルは大きくなります。アドテック、IoT、消費者向けアプリケーション分野の場合、通常は大きな同種アプリケーションのデータベースをそれぞれにデータのサブセットが含まれる大量のシャードに分割します。Aurora ではシャーディングを完全になくすことはできないかもしれませんが、より少数のシャードに統合して操作上のオーバーヘッドを減らすことができます。 テーブルの数。テーブル数の増加も、統合の結果見られることです。この結果は、各テナントが通常、独自のデータベースまたはテーブルセットを有する場合にテナントの分離が必要な SaaS アプリケーションで一般的なものです。このタイプの複数のテナントは数が少なくより大きな Aurora クラスターにまとめられ、テナントあたりの操作コストを削減します。 データベースの使用率。さらに多数の同時接続を行うなど、統合データベースワークロードの使用率が多くのメトリクスで増加します。 実際には、同じプロジェクト内の複数の要素で使用率が増加することになります。以下のガイドラインは、各要素でワークロードを最適化するのに役立つはずです。 「大きい」とは具体的にどのくらいのサイズですか? Amazon Aurora には最大容量に制限があります。私たちの最も重要な成果は、Aurora クラスターで 64 TB という最大の保存容量です。最大容量により、Aurora クラスターに物理的に保存できるデータ量の上限が決められます。また、個々のテーブルの大きさについて上限が決められます。 加えて、MySQL と互換性があるデータベースエンジンとして、Aurora MySQL は MySQL と InnoDB ストレージエンジンから多くの特徴を受け継いでいます。これらの特徴には効果的な統合に影響を与えるものがあります。 大きなテーブルサイズを最適化する方法 Amazon Aurora […]

Read More

Amazon Kinesis Data Streams および AWS Lambda を使用して、Amazon RDS for PostgreSQL の変更をストリーミングする

この記事では、Amazon Relational Database Service (Amazon RDS) for PostgreSQL 中央データベースを、Amazon Kinesis Data Streams にその変更をストリーミングすることで、他のシステムと統合する方法について説明します。以前の記事、「Amazon Kinesis を使用したデータベースの変更をストリーミングする」では、変更を Kinesis へストリーミングすることによって、MySQL データベース用の中央 RDS を他のシステムに統合する方法についてお話ししました。この記事では、さらに進んで、AWS Lambda 関数を使用して Amazon RDS for PostgreSQL の変更をキャプチャし、その変更を Kinesis Data Streams にストリーミングする方法を説明します。 次の図は、分散システムにおける一般的なアーキテクチャ設計を表しています。これには、信頼できる唯一の情報源と呼ばれる中央ストレージと、この中央ストレージを使用するいくつかの派生「サテライト」システムが含まれます。 この設計アーキテクチャーを用いて、データの整合性を維持するためにこのシステムのトランザクション機能を活用しながら、リレーショナルデータベースを中央データストアとして使用することができます。このコンテクストにおいての派生システムとは、全文検索システムであり、この信頼できる唯一の情報源の変更を観察し、それらの変更を変換かつフィルタリングし、最終的にその内部インデックスを更新するものです。もう 1 つの例は、OLAP クエリにより適したカラムナストレージです。一般に、中央リレーショナルシステムの個々の行が変更された時にアクションを実行する必要があるシステムはどれも、派生データストアにするのに適しているとい言えます。 この種のアーキテクチャの単純な実装では、変更された行を検索するために定期的にクエリを発行する派生システムがあります。これは基本的に SELECT ベースのクエリ (バッチ処理システムとも呼ばれます) で中央データベースをポーリングします。一方で、このアーキテクチャにより適した実装は、非同期の更新ストリームを使用するアーキテクチャです。 データベースには通常、行のすべての変更が格納されるトランザクションログがあります。ですので、この変更のストリームが外部のオブザーバシステムに公開されている場合、このシステムはこれらのストリームに接続し、行の変更を処理およびフィルタリングできる可能性があります。 この記事では、PostgreSQL を中央データベースとして、また Kinesis Data Stream をメッセージバスとして使用して、この基本的な実装を紹介します。 通常、PostgreSQL Write-Ahead Logging (WAL) ファイルは、マスター上のすべての変更を読み込んだ後、ローカルに適用するリードレプリカに公開されます。リードレプリカからデータを読み取る代わりに、wal2json 出力プラグインを用いた論理デコードを使用して、WAL の内容を直接デコードします。プラグインはこの GitHub […]

Read More

RDS for MySQL データベースを Amazon Aurora へ移行するためのベストプラクティス

MySQL は世界で最も普及しているオープンソースデータベースです。それにも関わらず、多くの利用者が一様にバックアップ、高可用性の確保にかかる膨大な手間に苦心していたり、また MySQL のスケーリングが複雑である、時間がかかる、あるいはその両方であると感じています。 お客様がそうした既存の MySQL 環境から Amazon RDS for MySQL へ移行する最大の理由の 1 つはそこにあります。Amazon RDS はポイントインタイムリカバリや高可用性などのオプションを複雑な設定など一切なしですぐに使用できる機能を提供します。RDS for MySQL はさらに、ソースあたり 5 つのリードレプリカに対応しています。このように、バイナリログ (binlog) レプリケーションを手動で設定したり、保守したりする必要なく、簡単にワークロードをスケールできます。 MySQL にハイエンドコマーシャルデータベースのパフォーマンスおよび可用性との互換性を期待するのであれば、MySQL データベースを Amazon Aurora に移行することでそれを実現できます。MySQL との互換性を持つ Amazon Aurora を使用することで、fast database clones および autoscaling replicas などの機能を活用できます。また、AWS Lambda および Amazon CloudWatch Logs といった他の AWS サービスとのネイティブ統合も可能になります。これらの機能に加えて、Amazon Aurora はまた、3 つのアベイラビリティーゾーンをまたぐデータのレプリケーションにより、優れた耐久性を実現します。また、最大で 15 個の Aurora レプリカにスケール可能で、すべてが通常では 20 […]

Read More