Amazon Web Services ブログ

Category: Database

Apache Cassandra データベースから Amazon DynamoDB への移行を容易にする

お客様から、さまざまなデータベースエンジン間でのデータの移行 (異種間移行とも呼ばれています) は困難で時間がかかるという話を伺います。サムスンのような一部のお客様は、Apache Cassandra データベースを Amazon DynamoDB に移行する方法を自ら探らなければなりませんでした (「Moving a Galaxy into the Cloud: Best Practices from Samsung on Migrating to Amazon DynamoDB」をご覧ください)。NoSQL データベース間のこれらの移行は、データの規模と変更の速度のため、より困難になりえます。詳細については、この「Applied Live Migration to DynamoDB from Cassandra」テックトークをご覧ください。 AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) により、AWS のお客様はデータベースを AWS クラウドに移行しやすくなりました。AWS DMS と AWS SCT を使用して、任意のサポート対象のソース (MongoDB など) から任意のサポート対象のターゲット […]

Read More

過去18ヶ月間で見逃した可能性のあるAmazon DynamoDBのハイライト

Amazon DynamoDB は、信頼性の高いパフォーマンスをあらゆる規模で提供できる非リレーショナルデータベースです。これは完全管理型マルチリージョンのマルチマスターデータベースで、レイテンシは一桁台のミリ秒単位の安定性です。また、ビルトインのセキュリティ、バックアップとリストア、およびメモリ内キャッシュを提供します。 このブログの投稿は、過去18ヶ月のDynamoDBハイライトを要約したものです。この記事を読んで、データベースの規模、パフォーマンス、そして可用性を改善させながら、所有者の総コスト(TCO)を削減してクラウド変革を促進する方法を学んでください。 1. DynamoDBなどのAWS独自のデータベースは、アプリケーションに理想的なツールを提供します ワークロードをクラウドに移行する際に、アプリケーション用に画一的なリレーショナルデータベースを実行するための、フリーサイズのすべてのアプローチが不要です。独自のデータベースを使用して、適切な仕事(アプリケーション)に適したツール(データベース)を選択し、非リレーショナルデータベースの基礎となるDynamoDBを選択できるようにします。 ワーナー・ヴォゲルス:AWS独自のデータベース(ブログ記事) AWS独自のデータベース戦略:適切な仕事に適したツール(ビデオ) AWS独自のデータベース戦略の適用 (ビデオ) 2. DynamoDBは過去18ヶ月間に多くの新機能を追加しました DynamoDBは、心配の無い暗号化、バックアップとリストア、Amazon DynamoDB Accelerator、Time To Live、そしてグローバルテーブルなどの機能を着実に開始しています。次のビデオを見るか、付属のプレゼンテーションのスライドを読んで、AmazonのDynamoDBの歴史と、皆さんが操作にではなくコードに集中することができるよう、私たちがどのように革新を続けて行くかを学んでください。 Amazon DynamoDBの新機能(ビデオ) Amazon DynamoDB の新機能 (デッキ) 3. DynamoDBは、99.999%のサービス水準合意(SLA)をご提供します。 AWSは稼働時間を考慮してDynamoDBを設計しました。2018年6月から、DynamoDBには99.999%の稼働率のSLAがあります。DynamoDB SLAの詳細をお読みください。 DynamoDBサービス水準合意(ウェブページ) 4. 適応能力により容量の計画がさらに簡単になります 不均一なアクセスパターンやワークロードに対して、DynamoDB適応能力により、アプリケーションは一貫したパフォーマンスで読み書きを継続できます。 Amazon DynamoDBの適応能力が不均一なデータアクセスパターンに対応する仕組み(または、なぜDynamoDBについて知っている情報が古くなっているのか)(ブログ記事) DynamoDB適応能力:入り組んだワークロードのためのスムーズなパフォーマンス(ビデオ) 5. ポイントインタイムリカバリーとオンデマンドバックアップを使用して、データベースのバックアップとリストアを自動化 DynamoDBは、今年初めに連続バックアップとポイントインタイムリカバリー(PITR)を開始しました。これらの機能を使用すると、過去35日間のデータベースを1秒あたりで自動的にバックアップおよびリストアすることができます。PITRを有効にするためのメンテナンスやコードは必要ありません。 Amazon DynamoDB連続バックアップとポイントインタイムリカバリー(ブログ記事) DynamoDBのオンデマンドバックアップとリストア(ドキュメンテーション) 6.グローバルテーブル:DynamoDBは、唯一のマルチリージョン、マルチマスターデータベースサービスです グローバルテーブルでは、DynamoDBは唯一のマルチリージョン、マルチマスターデータベースサービスです。グローバルテーブルを使用して、最も厳しいビジネスの継続性要件を満たすマルチレージンソリューションを実行できます。また、グローバルテーブルを使用して、世界中のどこからでもエンドユーザーに向けた低レイテンシのデータアクセスが可能になります。 Amazon DynamoDBアップデート – グローバルテーブルとオンデマンドバックアップ(ブログ記事) 7.顧客は、Cassandraなどの他のデータベースからDynamoDBに移行しています SamsungやGumGumなどの企業は、CassandraからDynamoDBに移行し、結果としてTCOを最大70%削減しました。おそらく、DynamoDBへの移行の最大のメリットは、データベースを稼動させ続けることではなく、ビジネス革新に集中できるようになることです。 Apache CassandraデータベースをAmazon DynamoDBに簡単に移行する(ブログ記事) SamsungはCassandraからDynamoDBへ1 PBを移行(ビデオ) Hosted CassandraからAmazon DynamoDBへの移行:年間60%のコスト削減へと飛躍(ブログ記事) 概要 この記事では、過去18ヶ月間の主要なDynamoDBのハイライトの一部が再度要約されています。DynamoDBの機能の詳細については、Amazon DynamoDBの機能をご参照ください。DynamoDBの使用を開始するには、DynamoDB入門をご参照ください。 著者について […]

Read More

AWS GlueとAmazon Athenaを使用して、Amazon DynamoDBのデータ抽出と分析を簡素化

100,000人以上のAWSユーザーが、モバイル、Web、ゲーム、アドテック、IoT、その他多くのアプリケーション向けにAmazon DynamoDBを選択しました。たとえば、DuolingoはDynamoDBを使用して、1秒あたり24,000回の読み取り容量単位と3,300回の書き込み容量単位となるテーブルに、310億アイテムを格納しています。 DynamoDBは、あらゆる規模のアプリケーションやマイクロサービスに幅広く対応できます。また、DynamoDBの多くの顧客は、DynamoDBテーブルに格納されているデータに対して、分析とアドホッククエリを実行します。このプロセスには一般的に、Amazon S3などの大規模なデータ分析とクエリのために、DynamoDBテーブルのデータをデータストアにコピーまたはアーカイブすることが含まれます。AWS Glueと新しいDynamoDBのクロール、そして抽出機能を使用することで、分析のためにAmazon S3へデータを移動する作業を簡素化できます。 この記事には、AWS Glueを使用してDynamoDBテーブルをクロールし、Amazon S3にデータを抽出し、Amazon AthenaでSQLクエリを使用して分析を実行するという方法が載っています。これらのサービスは、AWS上で完全に管理され、スケーラブルで、サーバーレスなサービスを使用することにより、DynamoDBからのデータの移動と解析の作業を簡素化しています。また、実践的なチュートリアルと独自のAWSアカウントで、ワークフローをテストできるAWS CloudFormationテンプレートもご提供しています。 ソリューションの概要 この記事のソリューションは、次の図に示すように、AWS Glue、Amazon S3、Athenaを使用して、DynamoDBからのデータのクロール、抽出、および解析を実行しているということです。 AWS Glueは完全に管理されており、分析のために使うデータ準備時間のプロセスを自動化するpay-as-you-goや抽出、変換、そしてロード(ETL)サービスをご提供しています。AWS Glueは、AWS Glue Data CatalogおよびAWS Glueクローラを介してデータを自動的に検出し、プロファイルを作成します。ソースデータをターゲットスキーマに変換するためのETLコードを推奨して生成します。次に、完全に管理されたETLジョブを、スケールアウトされたApache Spark環境で実行し、データをその宛先にロードします。AWS Glueを使用すると、複雑なデータフローを設定、調整、監視することもできます。 また、AWS Glue ETLジョブを作成して、DynamoDBテーブルからAmazon S3やAmazon Redshiftなどのダウンストリーム分析用のサービスに、データを読み込んだり、変換、ロードすることもできます。 上の図に示すように、ソリューション例のアーキテクチャーの仕組みは次のとおりです。 AWS CloudFormationは、AWSアカウントにDynamoDBテーブルを作成し、ニューヨーク市タクシーアンドリムジン委員会(TLC)の運行記録データの一部を入力します。AWS Glueのクローラは、DynamoDBからスキーマを検出し、AWS Glue Data Catalogにメタデータを設定します。 AWS Glueジョブは、Apache Parquetファイル形式のDynamoDBテーブルからデータを抽出し、S3に格納します。Parquetは、Hadoopエコシステムのプロジェクトで使用できる円柱状のストレージファイル形式であり、Athenaでクエリを効率化します。 AWS Glue ETLジョブは、AWS Glue Data Catalogによって提供される、定義済みのスキーマに結果を格納します。 Athenaは、Amazon S3で新しく抽出されたデータの外部スキーマストアとしてAWS Glue Data Catalogを使用します。SQLを使用してAmazon S3を直接クエリするために、Athenaを利用することで、データ分析を実行できます。 大規模なDynamoDBテーブルのベストな演習 AWS Glue ETLジョブは、同時実行データ処理ユニット(DPUs)のコンセプトを使用して、ジョブ実行の計算能力を描きます。単一のDPUには、4つの仮想中央処理装置(vCPUs)と16 […]

Read More

Amazon DynamoDBの適応能力が不均一なデータアクセスパターンに対応する仕組み(または、なぜDynamoDBについて知っている情報が古くなっているのか)

Amazon DynamoDBは、あらゆる規模の高性能な非リレーショナルデータベースです。これは、組み込み式のセキュリティ、バックアップ、およびデータ保護を使用して、スループットニーズに適応する、十分に管理されたサービスです。10万人以上の開発者が、モバイル、Web、ゲーム、アドテック、IoT、および低レイテンシのデータアクセスを必要とするその他のアプリケーション向けのDynamoDBを選択しました。 しかし、以前は余分なスループットを提供することでアシストしていた不十分な容量、これに関連するエラーにより要求が失敗することを心配しているという声を、依然として顧客から聞きました。これらの顧客は通常、DynamoDBは、他のキーよりもいくつかのキーをより多く読み書きするクエリパターンなど、プライマリキー(ハッシュキーまたはパーティションキーとしても知られている)全体でトラフィックが均一でないワークロードに精通している、という印象を受けます。 この記事では、DynamoDBの容量とサービス提供の仕組みがもはや懸念事項ではないことについて説明しています。これを行うには最初に、DynamoDBがどのようにしてパーティションとサーバー間でデータを分割させるのかという基礎部分を説明します。次に、あなたが過去に経験したことがあるかもしれない不均一なワークロードの問題を修正する、適応能力と呼ばれる機能を強調したいと思います。最後に、適応能力を実証するために、独自のAWSアカウントで実行できるサンプルアプリケーションを紹介します。 スケーリングに対するDynamoDBのアプローチ 注意:すでにDynamoDBパーティショニングを理解していて、適応能力についてのみ知りたい場合は、次のセクションに進んでください。 DynamoDBがデータをどのように管理するのかを理解することから始めましょう。他の非リレーショナルデータベースと同様に、DynamoDBは、複数のサーバー間で1つまたは複数のパーティションに、テーブルを水平分割します。しかし、独自のNoSQLデータベースのホスティングからDynamoDBを使用することとの違いは何ですか? Amazon EC2が、サーバーハードウェアを仮想化して、規模、効率、低コストのメリットを兼ね備えたマルチテナントエクスペリエンスを作成するのと同じように、DynamoDBもデータベースハードウェアと同様に機能します。 DynamoDBは、次の例の図で示すように、物理サーバー間でテーブルのパーティションを透過的に分割します。テーブル1は、異なるサーバー上にある2つのパーティション(T1.p1とT1.p2)に分割されています。 DynamoDBを使い始めるには、テーブルを作成して読み書きを開始するだけです。データベースノードまたはクラスタのための適切なハードウェア(CPU、RAM、そしてストレージなど)の選択について、心配する必要はありません。DynamoDBはバックグラウンドでハードウェアリソースを処理します。DynamoDB Auto scalingでは、アプリケーションの要求レートに対応する適切な読み取りおよび書き込みスループットが自動的に設定されます。ワークロードが進化するにつれて、DynamoDBは、読み取りスループット、書き込みスループット、およびストレージの変化に応じて、パーティションを自動的に再共有し、動的に再配分します。 この場合、ストレージの拡張がトリガーとなるDynamoDBの再構築の仕組みの例を見てみましょう。パーティションA、B、Cに分割された1つのDynamoDBテーブルがあると仮定します。これらのパーティションは、次の図に示すように、3つに分かれた物理サーバー(サーバー1、サーバー2、およびサーバー3)に格納されます。 注意:DynamoDBは、実際には9つのソリッドステートドライブ(3つではありません)にこのテーブルのデータを格納します。これは、AWS Regionの3つの機能にデータの複製が自動生成され、サーバ障害やアベイラビリティーゾーンの中断時にフォールトトレランスをご提供するためです。しかし、この例では、単純化のために複製を割愛しています。 この場合、アプリケーションは、次の図に示すように、パーティションAへの書き込みのほとんどを行っています。つまり、パーティションAのストレージはほぼ満杯となります。 DynamoDBは、入力を必要とせずに、自動的にパーティションAを2つに分割します。パーティション1はサーバー1に、パーティション2はサーバー4に配置されます。この変更はアプリケーションにとって透過的で、DynamoDBは自動的に新しいパーティションにリクエストを送信します。 パーティションの仕組みを説明したので、DynamoDBの適応能力について詳しく説明します。 適応能力の仕組みはどのようなものか もし以前にDynamoDBを使用していた場合は、最適なパフォーマンスのために均等に分散されたトラフィックを配信するように、アプリケーションを構築することをDynamoDBがお薦めしているということを、おそらく知っているでしょう。つまり、リクエストは主要なキー全体に均等に分散する必要があります。これは、適応能力の前に、DynamoDBが読み書きのスループットをパーティション間で均等に割り当てるためのものです。例えば、4つのパーティションに分散された、1秒あたり400回の書き込み(つまり、400回の書き込み容量単位、または「WCUs」)が可能なテーブルがある場合、各パーティションには100 WCUが割り当てられます。1つのパーティションに1秒あたり100回を超える書き込み(ホットパーティション)を受信する不均一なワークロードがあった場合、これらのリクエストによってProvisionedThroughputExceededExceptionエラーを返信された可能性があります。 実際には、完全一律にアクセスすることは困難です。不均一なデータアクセスパターンに対処するために、DynamoDBの適応能力により、(もちろん、全体のテーブルレベルのスループットを超えていない限り)リクエストが失敗することなくホットパーティションへの読み書きを継続できます。適応能力は、より多くのトラフィックを受け取るパーティションのスループット能力を自動的に増加させることによって機能します。適応能力に関するさらに詳しい分析については、このAWS re:Invent 2017ブレークアウトセッションビデオ(63分)をご参照ください。 次の図は、適応能力の例を示しています。この一例のテーブルには、4つのパーティション間で均等に共有される400個のWCUが提供され、各パーティションで1秒あたり最大100個の書き込みを維持できます。ただし、パーティション1〜3は1秒あたり50回の書き込みしか受信しませんが、パーティション4では1秒あたり150回の書き込みを受信するため、アプリケーションは不均一なトラフィックを発生させます。DynamoDBの適応能力は、自動的にパーティション4に「ブースト」を適用し、100 WCU以上の割り当てを消費することができます。したがって、アプリケーションは不均一なトラフィックにもかかわらず、正常かつ無期限に動作し続けます。 適応能力は、デフォルトですべてのDynamoDBテーブルで使用できるため、明確に有効または無効にする必要はありません。これはDynamoDBによって完全に管理されるため、新しいAmazon CloudWatch測定基準を監視する必要はありません。DynamoDBがテーブル上の適応能力をアクティブにすると、ワークロードが不均衡のままであっても、テーブルは無期限にトラフィックの不均一を処理し続けます。 カナダの人口調査への適用 – 適応能力の実践 非一様なワークロードを引き起こす典型的なアプリケーションに、適応能力がどのように対応し、そしてどのようにホットパーティションによって引き起こされるProvisionedThroughputExceededExceptionエラーを排除するか調べてみよう。このセクションでは、ダウンロードして実行できるサンプルアプリケーションの結果について説明します。 シナリオ – カナダの人口調査 10の州と3つの地域にまたがるカナダの人口に対して、オンラインの国税調査アプリケーションを構築していると仮定しましょう。DynamoDBを使用し、次の画像に表されるスキーマを有するテーブルにアプリケーションのユーザー応答を保管します(Provinceはパーティションキーであり、ResponseIdはソートキーです)。 今、カナダについての知識を特に持っていないと仮定しましょう。具体的に、次の画像に現れるカナダの人口分布に関した雑学的なことは少ししか分かりませんでした。 残念ながら、人口が各地方において、均等に分布していないため、私たちのパーティションキーとソートキーは、スキーマの選択肢を貧弱にしています。つまり、私たちのDynamoDBのアクセスパターンでは、人口がより多く集まる地域は、より頻繁に書き込まれるため、トラフィックの分布が不均一になります。次のカナダの人口に関する円グラフでは、カナダ人の60%以上がオンタリオ州とケベック州という2つの州にしか住んでいないことを示しています。 人口調査アプリケーションのサンプルの概要 アプリケーションのサンプルは、カナダ人口調査のウェブアプリケーションを再現します。まず、このアプリケーションで、Province、ResponseIdをそれぞれ主要なキー、ソートキーとして、3,000 WCUと3,000回の読み取り容量ユニット(RCU)を持つDynamoDBテーブルを作成します。作成された4つのパーティションに多くのスループット能力の結果を提供します。その後、25 WCUを持つ4つのパーティションごとで書き込まれたスループットを100 WCUに減らします。次に、アプリケーションはカナダの実績人口分布に従って、エンドユーザーからの1秒あたり70件の人口調査に関する回答を再現します。各人口調査の回答ごとに、アプリケーションのサンプルによって作成されたDynamoDBテーブルに新しい項目を書き込みます。このアプリケーションは、10秒あたり一行のデータを作成し、各州ごとに成功した書き込み数を反映します。 アプリケーションのサンプルを自分で実行するには、このGitHubリポジトリにアクセスしてください。アプリケーションを実行する前に、次のことにご注意ください。 アプリケーションを実行するには、DynamoDBにアクセスするためのAWSアカウントと権限が必要です。 模擬実験を実行する時間と、毎月の無料リソースをすでに使い果たしているかどうかという状態によって、DynamoDBのわずかな費用(約10ドル)が発生する可能性があります。このアプリケーションには約4時間にあたり3,000 WCUと3,000 RCUが必要です。 模擬実験が完了した後でクリーンアップをするには、アプリケーションで使用されるDynamoDBテーブルを削減したり削除する必要があります。 アプリケーションのサンプルの実行とその結果の解釈 実際の人口分布に比例して、1秒あたり70回の書き込みをランダムに実行すると、各州がどのように運賃を支払うかを見てみましょう。次のグラフは、出力のプロットを示しています。青色のONライン(オンタリオ州)とオレンジ色のQCライン(ケベック州)の成功率は低下し、その後正常に戻ることに注意してください。 オンタリオ州とケベック州の文字列の値がランダムなチャンスで同じパーティションにマップされていたため、オンタリオ州とケベック州の書き込みは約13分後に終了しました。その結果、スループットの25%が提供されているに過ぎず、1つのパーティションがテーブルのトラフィックの60%以上を占めていました。デフォルトの5分のバースト容量が役立ちました(そのため、歪みはすぐには発生しませんでした)が、トラフィックの不均衡が持続するために最終的に疲弊してしまいました。適応能力の前に、これらのProvisionedThroughputExceededExceptionエラーに対する唯一の対応策は、提供されたスループットを向上させるか、より均一なデータアクセスのためにアプリケーションを再設計することでした。 しかし、次の図に示すように、約30分後に正常な書き込みが回復したことになります。これは、適応能力が回復したときということです。DynamoDBは介入を必要とせずに、不十分なパーティションレベルのスループットによってトリガーとなったリクエストの失敗を検出しました。次に、DynamoDBは不均衡をもっとうまく処理するためにテーブルを調整しました。通常、テーブルがリクエストの失敗に遭遇してから、適応能力が正常なパフォーマンスに復帰するまでに5〜30分かかります。 何が起こっているかをズームアウトしたビューについては、次のCloudWatchグラフをご参照ください。正常な書き込みリクエスト(青色の線)と抑制された書き込みリクエスト(オレンジ色の線)を表します。同じパターンが実行されることに注意してください。ワークロードが正常に実行され、パーティションレベルのアクティビティが不十分であるために調整が行われ、適応能力によって正常なパフォーマンスが回復します。 […]

Read More

RDS SQL Serverには、ワクワクする新しい2つのバックアップ機能とリストア機能があります

Amazon Relational Database Service(Amazon RDS)は、AWSクラウドでリレーショナルデータベースを実行するための主要なメカニズムです。Amazon RDS for SQL Serverは、SQL Server 2008 R2からSQL Server 2017へのSQL Serverバージョンの実行をサポートします。 RDS for SQL Serverチームは、SQL Serverのネイティブバックアップとリストアに関する2つの重要な改善点を最近リリースしました。Amazon RDSユーザーガイドに記載されているこれらのバックアップは、S3バケット内の単一の.bakファイルとして、SQL Serverデータベースの完全データベースバックアップとなっています。S3バケットを表示するためにRDS SQL Serverのアクセス許可を受けた後、RDS SQL ServerデータベースをS3バケットにバックアップできます。また、S3バケットからRDS SQL Serverにバックアップをリストアすることもできます。 ただ1つのデータベースバックアップ 標準的なスキーマまたはテーブルデータを使用してユーザーデータベースを作成する一般的な方法は、必要なスキーマとデータを作り、SQL Serverバックアップを作成することです。次に、バックアップをリストアし、繰り返し名前を変更します。これは、単一のシステム上で複数の顧客をホスティングするなどの用途に最適です。RDS for SQL Serverは、これらを同じデータベースの複写として検出し、この方法で作成したデータベースをリストアできないようにしていました。最近のネイティブバックアップおよびリストアシステムの改良により、RDSは、これらのバックアップをRDS for SQL Serverシステムにリストアできなくなりました。 同期的なネイティブリストア 最近の別の改善点として、Amazon RDS for SQL Serverの高可用性マルチAZ(HA)配置が挙げられます。RDS for SQL Serverのインストール時に、高可用性オプションを選択すると、RDSは2番目のアベイラビリティーゾーンにデータベースミラーコピーを作成します。これは、RDS for SQL Serverでサポートされている最大30のデータベースに対して実行できます。以前は、HA構成でRDS for SQL Serverへのネイティブリストアを使用した場合、プライマリーSQL Serverインスタンスでデータベースをリストアしていました。その後、ミラーリングセッションを停止して再確立します。これにより、同じシステム上の他のすべてのデータベースのミラーリングセッションも停止され、そのサーバー上のすべてのユーザーデータベースの再ミラーリングが直ちに開始されます。 新たな改良により、フルバックアップをプライマリおよびミラーパートナーサーバーの双方に同時にリストアし、2つのデータベースを迅速に同期させます。さらに、SQL Serverの同じインスタンス上の他のデータベースを停止して再ミラーリングすることもなくなりました。結果として、セカンダリサーバーがプライマリミラーサーバーと完全に同期していない場合のウィンドウが大幅に縮小されます。システムの全体的な可用性が改善します。これは、FULLリカバリーモデルのデータベースでのみ有効で、これはSQL […]

Read More

AWSデータベース対応プログラムの紹介

新しいAWS Database Ready Programを導入し、ソフトウェアベンダーが彼らのソフトウェアを現代化し、Amazon Auroraをサポートできるようにします。 顧客は、商用データベースのライセンス費用を掛けずに、Amazon Auroraの性能、可用性、およびオープンソースの簡潔性を活用するクラウドネイティブアプリケーションを求めています。 AWS Database Readyは、元々AWSデータベースサービスで実行されるアプリケーションを使用してクラウド移行を加速することを可能にするものです。

Read More

Performance Insights を使用して Amazon Aurora の MySQL のワークロードを分析する

Amazon Relational Database Service (Amazon RDS) Performance Insights を使用すれば、パフォーマンスの問題の原因だけでなく、Amazon RDS データベース上のワークロードの性質を即座に把握できます。このブログ記事では、Amazon Aurora MySQL-Compatible Edition の Performance Insights ダッシュボードを手短に見て、パフォーマンスの問題を分析する方法を学びます。前回のブログ記事「Performance Insights で Amazon RDS データベースのワークロードを分析する」では、Performance Insights へのアクセスに関する基本的な事項と、Amazon Aurora PostgreSQL-Compatible Edition でそれを使用することについて取り上げました。 以下では、Performance Insights が、Aurora MySQL データベースで実行されている負荷が示されています。この例では、負荷グラフは待機でスライスされます。待機から、どのような作業が負荷の原因となっているか、そしてCPU、I/O 読み取り、ロック、安定したストレージへの書き込み、または他のデータベースリソースからの競合によってどれくらいの負荷がかかているかがわかります。Aurora MySQL は、MySQL の Performance Schema を使用してデータベースの待機を計測します。つまり、Performance Insights を最大限に活用したい Aurora MySQL ユーザーは、MySQL Performance Schema を有効にする必要があります。RDS パラメータグループで Performance Schema を有効または無効にしたことがない場合は、Performance Insights を有効にすると、自動的に […]

Read More

EMR – Sqoop を使用して RDBMS またはオンプレミスデータを EMR Hive、S3、および Amazon Redshift に移行する

 このブログ記事では、AWS のお客様が Apache Sqoop ツールの使用によって利益を得る方法について説明します。このツールは、データをリレーショナルデータベース管理システム (RDBMS) から AWS の EMR Hadoop Distributed File System (HDFS) にインポートし、データを Hadoop で変換して、それをデータウェアハウス (例: Hive または Amazon Redshift) にエクスポートするために設計されています。 Sqoop ツールのデモを行うために、この記事では以下の 3 つのシナリオにおいて、Amazon RDS for MySQL をソースとして使用し、データをインポートします。 シナリオ 1 — AWS EMR (HDFS -> Hive および HDFS) シナリオ 2 — Amazon S3 (EMFRS)、次に EMR-Hive シナリオ 3 — S3 (EMFRS)、次に […]

Read More

Amazon Aurora を使用してエンドユーザーの待ち時間を 3 倍に改善する方法

  AWS で誕生 2011年の創業以来、我々の旅に加わっている InfoScout は AWS で誕生しました。友人や家族からアップロードされたレシートを収集する 1 つの Amazon EC2 インスタンス とともにすべてが始まりました。それから7年後、モバイルアプリケーション、データパイプライン、マシンラーニングモデル”→”機械学習モデル、SaaS 分析プラットフォームをサポートするため、現在では 150 以上の AWS インスタンスを管理しています。この記事では、増加するインフラストラクチャとデータベース移行での課題を詳細に分析しています。 我々のビジネスはシンプルです。日常の消費者がショッピングレシートの写真を撮影してクラウドにアップロードが可能なモバイルアプリケーションのポートフォリオを持っています。我々はこのデータを分析し、ブランド、小売業者、代理店、消費者パッケージ商品 (CPG) 企業の買い物客に深い識見を提供します。大規模なデータ収集に対するこの消費者中心のアプローチは、ブランドが最終的に非常に多くの問いの背後にある「なぜ」に答えることを可能にします。「なぜ、私のカテゴリーで売上高が 5% 減少したのでしょうか ? 」「このカテゴリーのどのような消費者シフトが私のブランドに売上に貢献しているのでしょうか ? 」「消費者のどのセグメントがオンラインに移行しているのでしょうか ? 」 米国では 500 回の購入で 1 回のキャプチャを行い、1 日に 300,000 枚のレシート画像をストリームします。 AWS でインフラストラクチャとアプリケーション全体を強化するために、Amazon EC2 、Amazon RDS 、Amazon S3 、Amazon VPC 、および Route 53 を大量に使用しています。2011 年にはカリフォルニア北部の single VPC 1 […]

Read More

ProxySQL と Percona Monitoring and Management で、Amazon RDS for MySQL のデプロイを強化する

本日は、Percona 社の Michael Benshoof 氏によるゲストブログ投稿です。Benshoof 氏によると、「Percona 社は、3 千人以上の顧客をグローバルに持ち、バイアスのない最善の企業規模サポート、コンサルティング、管理サービスおよびトレーニングを提供し、リスクと運用コストを減らす対策を提供しています。さらにオンプレミスとオープンソース環境でのオープンソースデータベースのためのソフトウェアを使って、ロックインを排除し、機敏性を高め、ビジネスの成長を可能にしています。」 」 クラウドにアプリケーションをデプロイする予定で、データ層には Amazon RDS for MySQL を利用しようと考えている? それはいい選択ですね! それでは、アーキテクチャを最大限に活用するためのベストプラクティスをいくつか見てみましょう。 Amazon RDS for MySQL とは RDS for MySQL は、アマゾン ウェブ サービス (AWS) スタック内でサービスを行う管理データベース (DBaaS) です。RDS for MySQL では、次のような細かな操作作業の多くを処理します。 バックアップ ポイントインタイムリカバリ マイナーバージョンの自動アップグレード 新しいレプリカの追加 自動フェイルオーバー (Multi-AZ を実行している場合) このように、RDS for MySQL は、クラウド上で動作するデータ層にとって最適なオプションです。よく見られるフェールオーバーは標準の Multi-AZ デプロイで対応可能はもちろんのこと、RDSの回復力と使いやすさの向上も目指すことが可能です。これらの方法により、ワークロードの増加に合わせて、よりシームレスにデプロイおよびインフラストラクチャを拡張できます。 標準的なベストプラクティス 任意のアーキテクチャ (クラウドまたは物理データセンター内にある) を一から設計する場合、不具合への対応を準備しておくことは大変重要です。障害に対する準備が整ったインフラストラクチャの設定は、耐障害性のある環境を設計する上でかなめとなります。そのため、本番でのデプロイ (または高可用性が必要なデプロイ) の場合は、少なくとも以下を実行する必要があります。 プライマリインスタンスに、Multi-AZ を指定する […]

Read More