Amazon Web Services ブログ

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

Amazon Elasticsearch Service を使用して GuardDuty でセキュリティをリアルタイムで監視する

Amazon GuardDuty を使用して AWS アカウントとワークロードを保護すると、大量のデータをすばやく検索して可視化できるようになります。企業によっては、何千ものアカウントからアクティビティを分析しているところもあるでしょう。分析後、是正措置がとれるようにセキュリティチームに警告する必要があります。重要なのは、タイミングです。 GuardDuty に、Amazon Elasticsearch Service とデータの可視化を組み合わせることで、データを実用的な洞察に変換することができます。この記事では、Amazon ES を使用して GuardDuty の調査結果を分析する方法を示します。また、Amazon ES のオープンソースのデータ可視化プラグインである Kibana を使用して、データを検索、探索、可視化する方法を紹介します。 このようなリソースの作成を開始するための概要と手順は、次のとおりです。 ソリューションの概要と前提条件 設定方法の高水準フローは、以下に示すように次のステップから構成されています。 Amazon Cloudwatch Events と AWS Lambda を使用して GuardDuty の調査結果を収集します。それを Amazon S3 に送信します。 S3 バケットに配信されたログを Amazon ES に送信します。 Amazon ES で調査結果を分析、検索、集約します。 Kibana ダッシュボードを使用して結果を可視化します。 ここで手順を開始する前に、このAWS ブログ記事で概説しているように、マスターアカウントで GuardDuty を有効にします。マスターアカウントには、GuardDuty のすべての調査結果が集計されます。マスターアカウントは通常、セキュリティチームによって管理され、すべてのメンバーアカウントの結果が表示されます。 ステップ 1: AWS Lambda を使用して GuardDuty ログを収集し、Amazon […]

Read More

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

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

Read More

OracleデータベースでのAmazon EBS調整可能な容量の使用(パート1):紹介

昨年、私たちは調整可能なボリュームと呼ばれる新しいAmazon EBS 機能を開始しました。Amazon EBSの調整可能なボリュームを使用すると、ボリュームの使用中に、EBSボリュームのサイズを増やしたり、IOPSまたはボリュームのタイプを変更したりすることができます。この変更は操作に影響を与えなく、行うことができます。 この3つのブログ記事のシリーズでは、Oracleデータベースでの調整可能なボリュームを使用するメリットを検討します。また、調整可能なボリュームを使用してデータベースストレージを増やし、データベースの可用性または性能に影響を与えなく、準備されたIOPSを変更する方法についても説明します。 1番目の記事では、データベースストレージマネジメント用のロジカルボリュームマネージャー(LVM)のないオペレーティングシステムファイルシステムを使用して、Oracleデータベースで調整可能なボリュームを使用する方法について説明します。2番目の記事では、データベースストレージマネジメントにLVMを使用するOracleデータベースについて説明します。3番目の記事では、Oracle自動ストレージマネージャー(Oracle ASM)を使用するOracleデータベースについて説明します。 Amazon EBSの調整可能なボリュームの概要 調整可能なボリュームを使用すると、EBSボリュームの使用中に、EBSボリュームのサイズを増やしたり、準備されたIOPSを調整したり、EBSボリュームのタイプを変更したりすることができます。データベースはオンラインのままで、変更が有効になっている間に使用可能となっています。 AWS マネジメントコンソールから、簡単なAPI呼び出しを使用して、またはAWSコマンドラインインターフェース(AWS CLI)を使用して、ボリュームの変更を要求することができます。変更されるEBSボリュームは一連の状態を経過します。ボリュームの変更を要求すると、ボリュームは変更 状態になり、次に最適化状態になり、最後に完了状態になります。 EBSのボリュームのサイズの変更は、完了するまでに通常だと数秒がかかり、ボリュームが最適化状態になってから有効となります。パフォーマンス(IOPS)の変更には数分から数時間かかることがあり、構造の変更が行われたかどうかで決まります。EBSボリュームは最適化 状態になっていますが、ボリュームのパフォーマンスはソースとターゲットの構成仕様の間にあります。 Amazon EC2におけるOracleデータベースストレージレイアウト Amazon EC2でOracleデータベースを実行する場合は、EBSボリュームをデータベースストレージに使用します。一般的に、高性能のデータベースワークロード用のio1ボリュームと、それよりもあまり要求のないその他のワークロード用のgp2ボリュームを選択します。IO1ボリュームは、遅延の影響を受けやすい取引ワークロード用に設計されており、ボリュームにあたり最大32,000 IOPSまで提供します。GP2ボリュームは、価格と性能のバランスが優れており、ベースラインIOPSは3 IOPS/GB、ボリュームにあたり最大10,000 IOPSを提供します。 Oracleデータベースの物理ストレージには、ディスクに格納されているファイルのセット(データ、一時的なファイル、再実行ファイル、制御ファイルなど)が含まれています。これらのファイルの作成および管理には、オペレーティング・システムのファイル・システム、LVM、またはOracle ASMを使用することができます。 単純なデータベースストレージ操作 このセクションでは、単一のEBSボリュームとオペレーティングシステムファイルシステム(LVMなし)をデータベースストレージに使用する単純なOracleデータベース用のAmazon EC2におけるストレージレイアウトについて簡単に説明します。次に、準備されたストレージを増やしたり、準備されたIOPSを変更したりすることなどといったOracleデータベースのストレージの変更が調整可能なボリュームの導入前にどのように行われたかについて説明します。私たちは、この変更に関連する問題点を説明します。最後に、調整可能なボリュームを例に、これらの問題点のいくつかを解決する方法をお教えします。 単純なデータベースのストレージレイアウト 単純なデータベースについて、データベースストレージ用に単一のEBSボリュームのみを使用する場合があります。データベースファイルを格納するには、データベースファイルを分割してファイルシステムを作成します。このシナリオでは、LVMを使用しません。次の図は、この単純なデータベースストレージレイアウトを示しています。 調整可能ボリュームではないストレージ操作 データベースストレージ用の単一のEBSボリューム(LVMなし)を使用してストレージを増やしたり、またはシステム用に準備されたIOPSを変更したりすることができます。これを行うには、現在のEBSボリュームのスナップショットから目的のサイズとIOPSで新しいEBSボリュームを作成し、EBSボリュームをスワップします。この操作を行うには、次の手順を実行します。この操作には、データベースを停止する時間が必要です。 データベースを停止し、EBSボリュームのスナップショットを作成します。 スナップショットから求めたサイズとIOPSで新しいEBSボリュームを作成します。 古いEBSボリュームをEC2インスタンスから切り離し、新しいEBSボリュームをEC2インスタンスに接続します ファイルシステムのサイズを変更し(EBSのボリュームサイズが変更されている場合)、データベースを起動します。 調整可能なボリュームによる保管作業 EBSボリュームを変更するには、AWS CLIからの変更 – ボリュームコマンドまたはAWS マネジメントコンソールからの変更 – ボリュームオプションを使用します。その場合は、新しいボリュームサイズとIOPSを指定します。ボリュームサイズを変更せずに準備されたIOPSのみ変更する場合は、オペレーティングシステムレベルで変更する必要はありません。EBSボリュームのサイズを変更する場合は、ボリュームの変更後にファイルシステムのサイズを変更する必要があります。 EBSボリュームのサイズまたはIOPSを変更すると、データは自動的に複数のバックエンドデバイスに分散され、ホットスポットが発生しないようにしたり、準備されたIOPSを取得するようにします。 例:LVMを使用せずに単純なデータベースのストレージを増やす このセクションでは、停止時間が無くても、オペレーティングシステムファイルシステムをストレージマネジメントに使用するOracleデータベース用に準備されたストレージを増やす方法を示します。このデモでは、Amazon Linuxの上で動作するOracle 12cデータベースを使用します。30-GiB EBSボリュームがインスタンスに接続され、Oracleデータベースストレージ用のファイルシステムが作成されます。このデモでは、停止時間がなく、30 GiBから60 GiBに準備されたストレージを増やします。 サイズ変更がデータベースの停止時間なしに実行されたことを示すため、evtestprocというデータベースストアドプロシージャを作成しました。このプロシージャは、レコードを10秒間隔でevtesttabというテーブルに挿入します。このプロシージャは、サイズ変更操作の実行中に行われます。レコードが10秒間隔でevtesttabテーブルに挿入されていることを確認して、データベースの停止時間なしにサイズ変更が完了したことを確認できます。 ステップ1:現在の設定を確認する AWSマネジメントコンソールから、EBSボリュームのサイズを確認します。現在、次のスクリーンショットが示すように30 […]

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

AWS について学ぶ – 11 月の AWS オンラインテックトーク

 AWS オンラインテックトークは、様々な技術レベルで幅広いトピックをカバーするライブでのオンラインプレゼンテーションです。 今月は、AWS のサービスとソリューションについて学びましょう。ご質問があれば、オンラインで専門家がお答えします。 今月の特集! テックトークをチェック: Virtual Hands-On Workshop: Amazon Elasticsearch Service – Analyze Your CloudTrail Logs、AWS re:Invent: Know Before You Go、AWS Office Hours: Amazon GuardDuty Tips and Tricks いますぐ登録を! 注意 – すべてのセッションは無料で、太平洋時間です。 今月のテックトーク: AR/VR 2018 年 11 月 13 日 | 午前 11:00 ~ 12:00 (太平洋時間) – How to Create a Chatbot Using Amazon […]

Read More