Amazon Web Services ブログ

Category: Database

Amazon DynamoDB Accelerator コンソールのウォークスルー – パート 2

Amazon DynamoDB は、応答時間が 1 桁のミリ秒単位で測定されるスケーラビリティとパフォーマンスを提供します。マイクロ秒単位の応答時間が必要なユースケースでは、DynamoDB Accelerator (DAX) がその実現に役立ちます。DAX は DynamoDB と互換性がある API マネージドキャッシュで、リアルタイムのゲーム、入札、気象分析、取引など、要求の厳しいアプリケーションに高速のインメモリパフォーマンスを提供します。DAX を使用すると、読み取り容量単位を効率的にプロビジョニングすることでコストを削減し、最終的に一貫した読み取りワークロードの応答時間がマイクロ秒に短縮されるため、スループットが向上します。 このブログ記事では、ウェブベースの DynamoDB コンソールを使用して、数回クリックするだけで DAX を有効にすることに焦点を当てています。このウォークスルーの過程で、クラスター、ノード、サブネットグループ、パラメータグループ、イベントなどの DAX 主要コンポーネントについて理解を深めることができます。 DynamoDB コンソール DynamoDB Accelerator セクションの詳細ウォークスルー DynamoDB の設定については、このブログ記事のパート 1 を参照してください。このウォークスルーは、DynamoDB コンソールに 1 回以上アクセスしたことを前提としています。コンソールの DynamoDB DAX セクションで利用可能なすべての機能と、そこからアクセスする方法についてステップバイステップのウォークスルーに沿って説明します。 DynamoDB DAX コンソールに初めてアクセスした後は、常にコンソールの [ダッシュボード] ページから始めます。ダッシュボードには、Amazon CloudWatch アラームによってトリガーされた最近のアラート、DAX サービスヘルス、DynamoDB Accelerator に関するその他の情報に関する DAX コンポーネントの詳細が表示されます。 上のスクリーンショットで番号付けされているように、ダッシュボードのセクションは以下のとおりです。 # セクション 説明 1 クラスターの作成 ダッシュボードから直接、DAX […]

Read More

Amazon RDS PostgreSQL レプリケーションのベストプラクティス

Amazon RDS for PostgreSQL では、読み込み負荷を取り除き、災害復旧 (DR) リソースを作成するために、ソース PostgreSQL インスタンスのレプリカを簡単に設定することができます。リードレプリカは、ソースと同じリージョン、または異なるリージョン内に設定できます。 RDS PostgreSQL リードレプリカインスタンスを使用すると、読み込みワークロードをレプリカインスタンスにオフロードすると同時に、書き込みアクティビティのためにソースインスタンスのコンピューティングリソースも確保します。ただし、レプリケーション遅延を避けるには、リードレプリカを正しく設定し、適切なパラメータ値を設定する必要があります。 概要 この記事では、リードレプリカを正しく設定するためのベストプラクティスをいくつかご紹介します。リージョン内、クロスリージョン、および論理レプリケーションなどのさまざまな RDS PostgreSQL レプリケーションオプションの長所と短所を取り上げ、適切なパラメータ値と、監視するメトリクスを推奨します。以下のステップでは、レプリケーション遅延を最小限に抑えながら、DR 戦略、読み込みワークロード、および健全なソースインスタンスを最適化する方法を説明します。 一般的な推奨事項 全体的なベストプラクティスとして、リードレプリカで実行するリードクエリが、ソースインスタンスとしてデータの最新バージョンを使用することを確認してください。データバージョンは、Amazon CloudWatch メトリクスでレプリケーション遅延を調べることによって確認できます。レプリケーション遅延を最小限に抑えることによって、古いデータに基づいたクエリ出力と、インスタンスの健全性に対するリスクの両方を避けることができます。 リージョン内のレプリケーション RDS PostgreSQL は、ソースインスタンスと同じ AWS リージョン内でリードレプリカを作成するために Postgres ネイティブストリーミングレプリケーションを使用します。ソースインスタンスでのデータの変更は、ストリーミングレプリケーションを使ってリードレプリカにストリームされます。このプロセスが何らかの理由で遅れると、レプリケーション遅延が発生します。以下の図は、RDS PostgreSQL が同じリージョン内のソースとレプリカの間でレプリケーションを実行する方法を示しています。 この後のセクションでは、同じリージョン内でホストされている RDS PostgreSQL インスタンスを最適にレプリケートするために Postgres インスタンスを調整する方法について説明します。 適切な wal_keep_segments の値 Postgres では、wal_keep_segments パラメータで pg_wal ディレクトリに保存される WAL ログファイルセグメントの最大数を指定します。Postgres は、このパラメータを超える WAL セグメントを Amazon S3 バケットにアーカイブします。 リードレプリカが […]

Read More

Amazon Aurora Multi-Master を使用して高度に使用可能な MySQL アプリケーションによりビルド

アップタイム要件が高いトランザクション性のアプリケーションをお持ちですか? これらの要件を満たすために、クラウドにリレーショナルデータベースが必要ですか? 新しく開始された Amazon Aurora Multi-Master は、ノードの障害に柔軟性のあるリレーショナルデータベースを必要とするアプリケーションのために設計され、読み取りと書き込みの両方に利用可能です。 Amazon Aurora は、ハイエンドな商用データベースの速さや可用性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。MySQL 互換エディションの Aurora は、同じハードウェアで動作する標準 MySQL の最大 5 倍のスループットを実現します。これにより、既存の MySQL アプリケーションおよびツールを変更することなく実行できます。Amazon Aurora は 1 個のライターと最高 15 個の読み取りレプリカを 1 つ以上のアベイラビリティ―ゾーンとリージョンでサポートします。 Amazon Aurora Multi-Master は Aurora の MySQL 互換エディションに使用可能です。クラスターの各ノードはライターノードで、厳しいアップタイム要件をもつトランザクション性アプリケーションを実行するための追加パワーを与えます。 この記事では、MySQL 互換エディションのデータベース用の Aurora Multi-Master を最大限利用するために知っておくべきことを見直します。 アーキテクチャ Aurora Multi-Master は、データベースノードのクラスター全体で高可用性と ACID トランザクションを実現し、読み取り / 書き込み後の整合性を設定できるように設計されています。そのコアで、Aurora クラスターは計算 (データベース) ノードと共有ストレージボリュームのセットから構成されています。ストレージボリュームは、ユーザーデータの高可用性と耐久性のために、3 つのアベイラビリティーゾーンに配置された 6 つのストレージノードで構成されています。クラスターの各データノードは、ステートメントの読み取りと書き込みを実行できるライターノードです。 下図は […]

Read More

Amazon ElastiCache for Redis でクラスターモードを使用する

 私が AWS を気に入っている理由の 1 つは、幅広い技術的ユースケースに取り組むために使用できる多数のビルディングブロックがあることです。Amazon ElastiCache for Redis は、そうしたビルディングブロックの 1 つです。データベースキャッシュの高速化のニーズを最もよく考慮していますが、ElastiCache は非常に柔軟で高速 (マイクロ秒) です。これまでに、ElastiCache を使用して地理空間クエリを実行し、リアルタイムダッシュボードを構築する方法について説明しました。 この記事では、既存のワークロードにほとんど変更を加えることなく、信頼性と可用性を強化するためにクラスターモードを有効にした ElastiCache for Redis を活用する方法について説明します。後で説明するように、クラスターモードには、Redis クラスターの水平方向の拡大および縮小という主な利点があり、クラスターのパフォーマンスへの影響はほとんどありません。これまでに過剰または過少にプロビジョニングされている Redis クラスターに遭遇したことがあるか、その内部の仕組みをもっとよく理解したいなら、この記事をお読みください。 詳細を説明する前に、ElastiCache for Redis クラスターを起動する際の構成オプションについて簡単に説明します。次の図に示すように、(1) シングルノード、(2) クラスターモード無効、(3) クラスターモード有効の 3 つのクラスター構成のいずれかを使用することができます。モードに関係なく、特定のクラスター内のすべてのノードは、(基礎となる EC2 インスタンスに関して) 同じノードタイプおよび構成になるように設計されています。 3 つのモードは、主に信頼性、可用性、およびスケーリングの動作が異なります。本稼働のワークロードの場合は、データの保護を強化するためにレプリケーションを含む構成を使用することを検討してください。プライマリノードを除いて、何らかの理由でノードに障害が発生した場合でも、他のノードにレプリケートされているためデータは失われません。プライマリノードに障害が発生した場合は、レプリケーションのレイテンシーが原因で一部のデータが失われる可能性はあります。次の表は、ElastiCache for Redis の構成間の主な違いをまとめたものです。 シングルノード クラスターモード無効 クラスターモード有効 レプリケーション可能? いいえ はい (ノードあたり最大 5 つのレプリカ) はい (ノードあたり最大 5 つのレプリカ) データパーティション分割可能? […]

Read More

Amazon Alexa および AWS Systems Manager でのカスタムスキルを使ったデータベースの管理

 Amazon のお客様は何年も、消耗品を注文、音楽を聴く、ミーティングをサポート、ホームデバイスを管理、そして天気や最新ニュースを知るために Amazon Alexa の音声コマンドを使ってこられましたが、AWS のリソース管理となるとどうでしょうか。 AWS のマネージドサービスと完全マネージドサービスは、すでに管理タスクを減らし、アプリケーション上のリソースに焦点を当てることを可能にしていますが、今では音声対話で管理工数をさらに削減できるようになっています。 IT 管理者によるインフラストラクチャの管理と制御 開発者によるメトリクスのチェックと事前定義されたタスクのセキュアな実行 マネージャーによる IT リソースステータスとメトリクスの監視 さらに、これらのタスクはキーボードに触れることなく実行できます。 この記事では、Alexa の音声コマンドを使用して Amazon RDS インスタンス、または Amazon Aurora インスタンスを管理するためにインフラストラクチャを設定する方法について説明します。Alexa に、データベースインスタンスのメトリクス、設定、およびステータスを E メールするだけでなく、再起動やフェイルオーバーも実行してもらいましょう。 前提条件 AWS リソースの適切な音声管理には、以下を含めた AWS のサービスの組み合わせへのアクセスが関与します。 Alexa AWS Lambda Amazon EC2 AWS Systems Manager Amazon CloudWatch Amazon RDS Amazon Aurora Amazon SNS Amazon のクラウドベース音声サービスである Alexa は、毎日使うテクノロジーと直観的にやり取りすることを可能にします。このサービスを最大限に活用していただくため、Amazon は Alexa で音声エクスペリエンスを構築するためのツールと […]

Read More

AWS DMS 3.1.3 での Parquet データ形式のサポートの発表

本日、AWS DMS は、Apache Parquet データ形式で、AWS がサポートするソースから Amazon S3 へのデータの移行のサポートを発表しました。これは、DMS 3.1.3 の多数ある新機能の 1 つです。お客様の多くは、データレイクを構築するために DMS で「ターゲットとしての S3」サポートを利用しています。そして、このデータを Amazon EMR、Amazon Athena、Amazon Redshift Spectrum などの他の AWS のサービスと共に使用しています。そうした中、さまざまな形式で S3 への移行をサポートする方法が求められ、この機能が利用可能になりました。 この記事では、選択した S3 バケットおよびフォルダに、Parquet 形式のデータを移行するように DMS タスクを設定する方法を説明します。 概要 Apache Parquet は、効率的な圧縮およびエンコードスキームをサポートするように構築されています。複数のプロジェクトで、データに適切な圧縮およびエンコードスキームを適用することによるパフォーマンスへの影響が実証されています。Parquet は列ごとのレベルで圧縮スキームを指定することを可能にし、今後発明、実装されるより多くのエンコーディングを追加できることが将来的に保証されています。AWS DMS 3.1.3 では、Parquet 形式で S3 への移行をサポートできます。 ウォークスルー まず、適切な設定で S3 ターゲットエンドポイントを作成します。Parquet 形式のデータを移行するために必要な追加の接続属性を使用してこれを行うには、AWS CLI を使用する方法、DMS コンソールを使用する方法の 2 つの方法があります。 AWS CLI […]

Read More

Amazon RDS Performance Insights のカウンターメトリクスを Amazon CloudWatch にインポートする

Amazon RDS Performance Insights では、Amazon RDS データベースインスタンスをモニターでき、データベースのパフォーマンスの分析やトラブルシューティングが可能です。Performance Insights のデータは AWS Management Console で表示させることができます。また別の手段として、Performance Insights の公開された API を使い、ご自分が必要なデータを照会することもできます。この API を使って、データ取得や、既存のモニタリングダッシュボードへの Performance Insights データの追加、あるいは、ご自身のモニタリングツールの構築などが行えます。今回のブログでは、Cloudwatch へデータを送信するために、この API を使用します。 概要 Performance Insights では、システムパフォーマンスのモニタリングに使うため、オペレーティングシステムやデータベースカウンターについての、多様なメトリクスを収集します。各 Amazon RDS データベースエンジンには、Aurora メトリクスなど、一連のカウンターメトリクスが個別に備わっています。データベースパフォーマンスのトラブルシュートは、データベースの動作時刻を指定することで開始できますが、カウンターメトリクスも、データモニタリングのために、二次的ソースとして便利に利用できます。またこれらを、既存のシステムダッシュボードに統合すると便利です。 この記事は、データベースカウンターメトリクスに関心をお持ちの方すべてに向けたものです。まず、2 つある Performance Insights API の 1 つである GetResourceMetrics を取り上げます。これにより、Performance Insights からデータを取り出す AWS Lambda 関数を作成する方法と、別のモニタリングシステムにそれを統合する方法をご紹介します。この記事では、Boto3、Python3、AWS CLI、Performance Insights API を使用していきます。作業開始の前に、Performance Insights が有効化された Amazon […]

Read More

Amazon RDS および Amazon Aurora のデータベースエンジンに適切な暗号化オプションを選ぶ

 AWS クラウドのデータベースやデータストアの暗号化をデフォルトで選択するお客様の数は、ますます増えています。この流れは、さまざまな規制の枠組みにおいて機密データ (個人特定可能な情報 [PII、Personally Identifiable Information] など) の意味が発展していくのにともなって、勢いを増すばかりです。最新のデータベース暗号化の中から、パフォーマンスや各製品での迅速な反復を維持したまま最適なものを選ぶ方法について教えてほしい、というお客様からの要望も AWS に寄せられています。 そこで今回の記事では、Amazon RDS MySQL、MariaDB、Amazon Aurora MySQL の各データベースエンジンで使用できる、暗号化の方法をご紹介します。この記事は、ワークロードやビジネスのニーズに最も適した暗号化の方法を見つける一助となることを目指しています。なお簡略化のため、上記のエンジンをここでは “RDS MySQL 関連” のエンジン、または “MySQL 関連” のエンジンと呼びます。 概要 RDS で利用できる暗号化の方法は、次の 3 つのカテゴリーに分けることができます。 保存時のデータの暗号化。これには、プラットフォーム全般の機能およびデータベースエンジンそれ自体の機能が含まれます。 送信中のデータの暗号化。これは、データベースとクライアント間のネットワークを移動するデータを確実に保護する方法です。 レプリケーション中に送信されるデータの暗号化。ひとつ前のカテゴリーと大きな違いはありませんが、こちらはデータベースサーバー間のデータレプリケーションのトラフィックに用いられる方法です。 次に、それぞれのカテゴリーを詳しく見ていき、ニーズに合わせて最も効果的に実装する方法をご紹介します。 保存時のデータの暗号化 RDS MySQL 関連のデータベースエンジンを使用している AWS の多くのお客様は、RDS リソースの暗号化に依存しています。RDS により暗号化されたリソースを使うと、データは保存時に、データベース (DB、Database) インスタンスの基盤となるストレージ、その自動バックアップ、リードレプリカ、スナップショットを含めて暗号化されます。この機能は、データの暗号化にオープン標準の AES-256 暗号化アルゴリズムを使用しています。このアルゴリズムはデータベースエンジンに対して透過的です。 Amazon EBS では、RDS MySQL と MariaDB 向けに、基盤となるストレージとスナップショット機能が提供されます。Aurora では、専用の、分散されたログ構造のストレージサービスが使用されています。暗号化された Aurora DB […]

Read More

Amazon ElastiCache for Redis でリアルタイムゲームリーダーボードを構築する

ゲームリーダーボードを使用すると、プレイヤーは互いのパフォーマンスを比較できます。この重要なソーシャル機能により、プレイヤーの関わり合いが高められ、競争が促進されます。リーダーボードのデータは、同様のスキルレベルの競争相手とプレイヤーをマッチングさせるゲーム内のアルゴリズムに活かすこともできます。 この記事では、伝統的なリレーショナルデータベースを使用してゲームリーダーボードを構築および拡張することに関する課題を探ります。また、Redis などの最新のインメモリデータストアを活用して、非常に効率的でスケーラブルなソリューションを提供する方法についても検討します。 この提案されたソリューションは、リーダーボードストレージとクエリをリレーショナルデータベースからより汎用性の高い Amazon ElastiCache for Redis に向かうことを後押しします。ここで概説したアプローチは、ゲームリーダーボードだけでなく、一般にアプリケーション内でランキングを生成するあらゆる状況に適用されます。 背景 従来のリレーショナルデータベースを使用して基本的なリーダーボードを構築する手順はシンプルです。通常、以下の手順が含まれます。 テーブルを作成します。 スコアが変更されたときにスコアを挿入または更新します。 テーブルをクエリして、スコアの降順でランキングを取得します。 以下が基本的なリレーショナルデータベースのリーダーボードの実装です。 +———+———+——+—–+———+——-+ | Field | Type | Null | Key | Default | Extra | +———+———+——+—–+———+——-+ | user_id | int(11) | NO | MUL | NULL | | | score | int(11) | NO | MUL | NULL | | +———+———+——+—–+———+——-+ […]

Read More

Oracle パフォーマンスメトリクスに基づいた Amazon RDS インスタンスを大規模で適正なサイズにする

オンプレミスのミッションクリティカルなアプリケーションを商用データベースで稼働中のエンタープライズ企業で、コスト効率の高い、マネージド型データベースサービスをお探しのお客様がいらっしゃいます。リレーショナルデータベースのワークロードを移行するプラットフォームの 1 つ、Amazon RDS をおすすめします。RDS はサイズ変更が可能な容量を提供し、時間のかかる重い非個別型管理タスクに対応します。大規模なデータベースの移行では、適切なサイズのターゲット RDS DB インスタンスを多くのデータベースに作成できる、スケーラブルかつ効果的なソリューションが必要です。 この記事では、オンプレミスの Oracle パフォーマンスメトリクスに基づいた DB インスタンス を大規模で適切なサイズにするプロセスについて説明します。Python と SQL スクリプトを使用してオンプレミスデータベースから Oracle パフォーマンスメトリクスを収集する方法、および AWS Glue と Amazon Athena を使った DB インスタンスサイズのデータ分析と推奨事項を得る方法を解説します。このソリューションは、1 つのデータベースから多数のデータベースまでの DB インスタンスのサイズ調整に有効です。 概要 オンプレミスの Oracle ワークロードの検出を目的として、1 時間ごとの I/O、CPU、メモリ使用量の統計について Oracle 自動ワークロードリポジトリ (AWR) をクエリする SQL スクリプトが開発されました。Python スクリプトを検出するデータベースのリストを含む入力ファイルから読み込んで、各データベースをループ処理して SQL スクリプトを実行します。データベースごとに .csv 出力ファイルが生成されます。 目標は、少なくとも 1 か月のパフォーマンスメトリクスを収集し、DB インスタンスのサイズをより正確に推定することです。AWR の保存期間が 1 か月未満に設定されている場合、複数回スクリプトを実行できます。スクリプトはすべて […]

Read More