Amazon Web Services ブログ

Category: Database

Amazon Aurora MySQL 互換エディションでグローバルトランザクション ID (GTID) によるレプリケーションがサポートされるようになりました

Amazon Aurora MySQL 互換エディションは、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Amazon Aurora with MySQL compatibility は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 本ブログ記事では、オンプレミスまたは Amazon EC2 上でホストされている MySQL DB を、新たにリリースされた GTID べースのレプリケーション機能を使用する Aurora MySQL に移行するのに役立つガイダンスについて解説します。 GTID ベースのレプリケーションとは? グローバルトランザクション ID (GTID) とは、MySQL、または MySQL 互換エンジンを実行するデータベースサーバー上でコミットされた各トランザクションに作成され、関連付けられる固有の識別子です。この ID は元のサーバーと、さらにトランザクションの両方を個別に識別します。 フェイルオーバーやダウンタイム後、データベース管理者にとって最大の課題は、ひとつの変更もスキップされることなく、また、一切の競合が生成されることない方法でレプリケーションを復元することです。ワークロードが動的に、スケーラブルに、また複雑になるに従って、これらの再構成タスクもますます頻度が増えていきます。その結果として、バイナリログファイルの位置を特定するのに必要な管理的オーバーヘッドが増大し、それによって、復旧時間が長引きます。

Read More

AWS Database Migration Service (DMS) レプリケーションインスタンスをスケールする方法

AWS Database Migration Service (DMS) は、データベースを AWS に迅速かつセキュアに移行するために役立ちます。AWS DMS の移行プロセスには、レプリケーションインスタンス、ソースエンドポイントとターゲットエンドポイント、およびレプリケーションタスクの設定が含まれます。 レプリケーションインスタンスは、CPU、メモリ、ストレージ、I/O などのリソースを使用します。これらは、インスタンスのサイズやワークロードの種類によって制約を受ける可能性があります。 この記事では、必要に応じて AWS DMS レプリケーションインスタンスを自動的にスケールして、より高い負荷 (スケールアップ) を処理し、負荷が低いときにコストを削減 (スケールダウン) する方法を示します。 ユースケース AWS DMS レプリケーションインスタンスをセットアップする際には、以下を分析します。 データベース内のテーブル数 それらのテーブルのデータ量 同時レプリケーションタスク数 ソースデータベースへのトラフィック AWS DMS レプリケーションインスタンスを適切なサイズにするには、適切なリソース使用率 (CPU) を予測できなければなりません。 動的サイジングソリューションの概要 こちらがアーキテクチャのダイアグラムです。 AWS DMS のベストプラクティスホワイトペーパーでは、適切なサイズの AWS DMS レプリケーションインスタンスを設定するいくつかの戦略について概説しています。 この記事では、AWS DMS レプリケーションインスタンスのサイズ設定において大きな柔軟性を実現する方法を説明します。 Amazon CloudWatch を使用して、AWS DMS レプリケーションインスタンスの CPU 使用率を監視します。CloudWatch のアラームしきい値に達すると、Amazon Simple Notification Service (Amazon […]

Read More

Amazon Relational Database Service を使用したシャーディング

水平パーティション分割とも呼ばれるシャーディングは、リレーショナルデータベースの一般的なスケールアウトアプローチです。Amazon Relational Database Service (Amazon RDS) は、クラウドでシャーディングを使いやすくするための優れた機能を提供するマネージド型リレーショナルデータベースサービスです。この記事では、Amazon RDS を使用してデータストレージの高いスケーラビリティ、高可用性、およびフォールトトレランスを実現するために、シャードデータベースアーキテクチャを実装する方法について説明します。Amazon RDS をデータベースシャードとしてデプロイする際のスキーマ設計とモニタリングメトリクスに関する考慮事項について説明します。また、リシャーディングの課題についても概説し、Amazon RDS でのプッシュボタンによるスケールアップおよびスケールアウトソリューションを紹介します。 シャードデータベースアーキテクチャ シャーディングは、データをより小さなサブセットに分割し、それらを物理的に分離された多数のデータベースサーバーに分配する手法です。各サーバーはデータベースシャードと呼ばれます。すべてのデータベースシャードは通常、同レベルのパフォーマンスを生成するために、同じタイプのハードウェア、データベースエンジン、およびデータ構造を持っています。ただし、それらはお互いの知識を持っておらず、その点が、データベースクラスタリングやレプリケーションなどの他のスケールアウトアプローチとシャーディングを区別する重要な特性です。 シェアードナッシングモデルにより、スケーラビリティとフォールトトレランスの点で、シャードデータベースアーキテクチャは独自の強みを発揮します。データベースメンバー間のコミュニケーションや競合を管理する必要はありません。それに伴う複雑さとオーバーヘッドは存在しません。1 つのデータベースシャードにハードウェアの問題があるか、フェールオーバーを経ても、単一障害点やスローダウンは物理的に分離されているため、他のシャードは影響を受けません。アプリケーション層に存在するデータマッピングとルーティングロジックの一部から発生するレイテンシーが非常に少ないという条件で、シャーディングは必要なだけのデータベースサーバーを利用する可能性があります。 ただし、シェアードナッシングモデルでは、シャーディングという避けられない欠点も発生させます。そこでは、さまざまなデータベースシャードに分散しているデータが分離されています。複数のデータベースシャードからデータを読み取りまたは結合するためのクエリは、特別に設計する必要があります。通常、片方のシャードでのみ動作するピアよりも高いレイテンシーが発生します。すべてのデータの一貫したグローバルなイメージを提供できないことは、データ分析機能が通常データセット全体に対して実行されるオンライン分析処理 (OLAP) 環境で積極的な役割を果たすことにおいて、シャードデータベースアーキテクチャを制限します。 オンライントランザクション処理 (OLTP) 環境では、大量の書き込みまたはトランザクションが単一のデータベースの容量を超えることがあり、スケーラビリティが懸念される場合、シャーディングは常に追求する価値があります。Amazon RDS の登場により、データベースの設定と運用は大幅に自動化されました。これにより、シャードデータベースアーキテクチャを扱う作業がずっと簡単になります。Amazon RDS は、Amazon RDS for MySQL、MariaDB、PostgreSQL、Oracle、SQL Server、およびAmazon Aurora を含むデータベースエンジンのセットを提供します。これらのいずれかを、シャードデータベースアーキテクチャのデータベースシャードの構成要素として使用できます。 Amazon RDS を使用して構築されたシャードデータベースアーキテクチャの例を見てみましょう。AWS クラウドコンピューティング環境のコンテキストでは、データフローパス内での位置はいくつかの特徴があります (次の図に示します)。 Auto Scaling 機能を備えた Amazon EC2 インスタンスのグループでホストされているウェブアプリケーションを介してデータがシステムに入力されます。 データストレージは、さまざまなビジネス要件および所有権要件を満たすために OLTP 環境が OLAP 環境から分離されている層になっています。 OLTP 環境ではデータベースシャーディングを使用します。これは、高いスケーラビリティで書き込みスループットに対する増大する需要を満たすために Amazon RDS で構築されたデータベースのグループで構成されています。Multi-AZ 機能を使用してデプロイされたスタンドアロンデータベースを使用した高可用性を実現するために各データベースシャードを構築します。注意: […]

Read More

Redis 用の Amazon ElastiCache を使用したアプリケーションパフォーマンスの向上とコストの削減

シニアソフトウェア開発エンジニアの Shawn Wang 氏、ソフトウェア開発エンジニアの Maddy Olson 氏、およびソフトウェアエンジニアリング担当シニアマネージャーの Itay Maoz 氏による寄稿。 Redis 用の Amazon ElastiCache を使用すると、クラウド規模で非常に低いレイテンシーで最高のパフォーマンスと最小限の管理コストを実現できます。Redis の高性能、シンプルさ、そして多様なデータ構造サポートは、最も人気のある NoSQL キーバリューストアとなっています。キャッシング、リアルタイム分析、ゲームのリーダーボード、チャットやメッセージングのいずれの場合であっても、スピードが勝ります。Redis 用 Amazon ElastiCache で簡単に実現できます。 昨年、弊社は ElastiCache が AWS でさらに優れたパフォーマンス実現への道を歩み始めました。ElastiCache で M5 および R5 インスタンスのサポートを追加する一環として、AWS Nitro ベースシステムを使って、Redis 用のElastiCache を実行するためにインスタンスを最適化しました。Amazon ベース Linux イメージを最適化することで、M5 と R5 のネットワークパフォーマンスをチューニングしました。この結果は有望でした。R5 では、R4 と比較して、1 秒あたり最大 144% を超えるトランザクションを達成しました。平均 (p50) とテール (p99) のレイテンシーを最大 23% 削減しました。それ以来、多くの大規模な ElastiCache のお客様は、より良く、より速く、そしてより安価な […]

Read More

Amazon DynamoDB グローバルセカンダリインデックスを設計する方法

大学時代、私はリレーショナルデータベースのシステム要件をモデル化するために、エンティティ関係図を作成しました。このプロセスでは、ソフトウェアシステムのすべてのエンティティを検索し、それらのエンティティ間の関係を定義しました。次に、データベースがどのクエリをサポートする必要があるかを判断する前に、関係とエンティティをデータベーステーブルにモデル化しました。データベーススキーマを設計するこの方法は、スケーラビリティとより一貫したパフォーマンスを利用するために非リレーショナルデータベースを使い始めるまではうまく機能しました。 非リレーショナルデータベースでは、スキーマ設計のアプローチは逆になります。データベーススキーマを設計する前に、アプリケーションが必要とするクエリを特定するために「クエリ優先」アプローチを使用するのです。そのため、データはアプリケーションが使用する必要がある方法で明示的に保存され、クエリの効率が向上します。 また、クエリに柔軟性を追加したい場合は、Amazon DynamoDB でグローバルセカンダリインデックスを使用することができます。DynamoDB テーブルでグローバルセカンダリインデックスを使用すると、非キー属性を使用して他のディメンションでデータを柔軟に照会できます。 ただし、効率的なクエリパフォーマンスを維持するには、DynamoDB テーブルのスキーマを設計したのと同じ方法で、グローバルセカンダリインデックスのスキーマを慎重に設計する必要があります。このブログ記事では、グローバルセカンダリインデックスのスキーマを設計するためのアプローチを示し、設計プロセスにおける一般的な落とし穴を回避する方法を説明し、コストを削減するためのヒントを提供します。 グローバルセカンダリインデックスのスキーマ設計プロセス 次の図は、グローバルセカンダリインデックスのスキーマを設計する方法について、この記事で説明しているアプローチをまとめたものです。 クエリパターンを特定する アプリケーション固有のクエリパターン (テーブルがサポートするクエリの種類) が、グローバルセカンダリインデックスの設計を推進します。設計を推進する中心的な質問は、「グローバルセカンダリインデックスが回答する、どのような質問が必要であるか?」ということです。 回答が必要な質問が決まったら、質問をテーブルデータのクエリにマッピングします。「より大きい」、「より小さい」、「の間」、「で始まる」などの範囲クエリに基づくデータフィルターを使用します。 アクセスしなければならないがフィルタリングやソートを必要としない他のデータについても考慮する必要があります。たとえば、オンラインショッピングのウェブサイトに商品情報を表示するには、商品の ProductId でデータをフィルター処理します。ただし、クエリでアクセスする必要があるその他のデータには、製品の説明、価格、重量、製品の色などがあります。できるだけ多くのクエリを事前に特定します。スキーマ設計でクエリを考慮に入れると、グローバルセカンダリインデックスのコストとパフォーマンスを最適化するのに役立ちます。 それでは例を見て、アプリケーション固有のクエリがテーブルクエリにどのように変換されるのかを確認しましょう。たとえば、オンラインショッピングのウェブサイトが、顧客の注文をすべて OrderId をパーティションキーとして Orders テーブルに保存しているとします。また、このテーブルには、OrderDate、CustomerId、Status など、注文に関するその他のデータも保存されています。次の表は、アプリケーション固有の一般的な質問とそれに対応するテーブルクエリの一部を示しています。 アプリケーション固有の質問 テーブルクエリ 注文日順に並べ替えられた顧客のすべての注文を検索する Orders テーブルのすべての注文を CustomerId でフィルター処理してから、OrderDate で並べ替える 特定の日付範囲内の特定の顧客の注文を取得する Orders テーブルのすべての注文を CustomerId でフィルター処理してから、OrderDate での範囲照会でフィルター処理する 顧客の保留中の注文をすべて探す Orders テーブルのすべての注文を CustomerId でフィルター処理してから、Status を「Pending」としてフィルター処理する 5 日以上経過している顧客の保留中の注文をすべて探す Orders テーブルのすべての注文を CustomerId でフィルター処理してから、Status を「Pending」とし、OrderDate < CurrentDate-5 の範囲照会でフィルター処理する 顧客のすべての注文の OrderId、OrderDate、Status […]

Read More

Amazon DynamoDB コンソールについて知りたかったが、質問できなかったすべてのことについての詳しいウォークスルー

2012 年にリリースされて以来、Amazon DynamoDB は、あらゆる規模で高速かつ予測可能なパフォーマンスを提供できるように設計された、完全マネージド型でマルチリージョン、マルチマスター対応のデータベースサービスとなりました。DynamoDB は、ウェブベースのコンソール、AWS コマンドラインインターフェイス (CLI)、多数のプログラミング言語用の SDK のセットという、操作を実行するための 3 つのオプションを提供する NoSQL データベースです。 このブログ記事では、DynamoDB のコアコンポーネント (テーブル、項目、属性)、グローバルテーブル、読み取り/書き込みキャパシティーモード、リザーブドキャパシティーの購入、バックアップメカニズムについて理解を深めるために、DynamoDB コンソールについて詳しく説明します。 DynamoDB コンソールについての詳細なウォークスルー DynamoDB コンソールを開始するには、以下の手順を実行します。 DynamoDB ホームページへ移動し、[Get started with Amazon DynamoDB] を選択します。(まだ AWS アカウントを設定していない場合は、[Create an AWS Account] を選択すると、アカウントを設定するプロセスが案内されます。) AWS マネジメントコンソールにサインインして、DynamoDB コンソールを開きます。 DynamoDB コンソールを初めて使用する場合は、[ようこそ] ページが表示され、DynamoDB に関する情報とその使用方法が表示されます。[ようこそ] ページには、一般的な操作を実行するための次の 3 つのオプションがあります。 テーブルの作成 項目の追加および照会 テーブルの監視および管理 DynamoDB コンソールに初めてアクセスした後は、常にコンソールの [ダッシュボード] ページから始めます。ダッシュボードには、Amazon CloudWatch アラームによってトリガーされた最近のアラート、プロビジョニングされたテーブルの合計キャパシティー、サービスヘルス、DynamoDB に関するその他の情報の詳細が表示されます。 上のスクリーンショットで番号付けされているように、ダッシュボードのセクションは以下のとおりです。 […]

Read More

PostgreSQL ユーザーとロールの管理

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上の開発作業を経て、PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。アマゾン ウェブ サービス(AWS)は、管理された 2 つの PostgreSQL オプションを提供します:PostgreSQL および Amazon Aurora PostgreSQL 用の Amazon Relational Database Service(Amazon RDS)。この記事では、PostgreSQL でユーザーとロールを管理するためのベストプラクティスについて説明しています。 PostgreSQL を使用すると、きめ細かいアクセス権限を持つユーザーとロールを作成できます。新しいユーザーまたはロールには、各データベースオブジェクトに必要な権限を選択的に付与する必要があります。これはエンドユーザーに多くの力を与えますが、それと同時に、正しい許可を持つユーザーとロールを作成するプロセスを潜在的に複雑にしています。 PostgreSQL では、データベースユーザーに直接権限を付与することができます。ただし、グッドプラクティスとして、アプリケーションとアクセスの要件に基づいて、特定の権限のセットを持つ複数のロールを作成することをおすすめします。次に、各ユーザーに適切な役割を割り当てます。ロールは、データベースオブジェクトにアクセスするための最小権限モデルを強制するために使用するべきです。Amazon RDS および Aurora PostgreSQL インスタンスの作成中に作られたマスターユーザーは、他のユーザー、ロール、およびデータベースの作成などのデータベース管理タスクにのみ使用する必要があります。マスターユーザーはアプリケーションによって使用されるべきではありません。 PostgreSQL できめ細かいアクセスコントロールを設定するための推奨アプローチは次のとおりです: マスターユーザーを使用して、readonly や readwrite などのアプリケーションまたはユースケースごとにロールを作成します。 これらのロールがさまざまなデータベースオブジェクトにアクセスできるように権限を追加します。例えば、readonly ロールは SELECT クエリのみを実行できます。 機能にとって最低限必要な権限をロールに付与します。 app_user や reporting_user のように、アプリケーションごとまたは個別の機能ごとに新しいユーザーを作成します。 適切なロールをこれらのユーザーに割り当てて、ロールと同じ権限をすばやく付与します。例えば、readwrite ロールを app_user に付与し、readonly ロールを reporting_user に付与します。 […]

Read More

新しい Amazon DocumentDB の集計、配列、インデックス作成機能

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメント データベース サービスです。今日、使用したものと同じ MongoDB アプリケーションコード、ドライバー、およびツールを使用して、Amazon DocumentDB でワークロードを実行、管理、および拡張できます。これにより、基となるインフラストラクチャの管理を気にせず、パフォーマンス、スケーラビリティ、および可用性を向上させることができます。 今日、Amazon DocumentDB は、新しい集計パイプライン演算子とステージをサポートするようになりました。これにより、ドキュメントで強力な集計を作成することができます。新しい機能には、集計文字列演算子 ($concat, $substr, $substrBytes, $substrCP, $strcasecmp)、配列集計演算子 ($size)、集計グループ アキュムレータ演算子 ($push)、および集計ステージ ($redact と$indexStats) が含まれます。さらに、Amazon DocumentDB は、配列内の要素を更新する位置配列演算子 ($[] と $[<identifier>]) およびインデックスを選択する hint() をサポートするようになりました。 このブログ記事では、一般的なユースケースを示してこれらの新機能のいくつかを紹介します。これにより、Amazon DocumentDB で大規模のアプリケーションを構築および管理する機能を使い始めることができます。 Amazon DocumentDB の使用の開始 Amazon DocumentDB を使い始めるには、Amazon DocumentDB 入門ガイド、AWS CloudFormation のクイック スタートをご覧ください。準備ができたら、現在 MongoDB で使用しているものと同じアプリケーションコード、ドライバー、およびツールを使って、Amazon DocumentDB での開発を開始できます。 新機能 Amazon DocumentDB […]

Read More

Amazon DynamoDB Auto Scaling: 規模を問わないパフォーマンスとコストの最適化

 データベース容量の拡大は、面倒でリスクが伴う作業になり得ます。データベースとアプリケーションの微妙な動きを理解しているベテランの開発者とデータベース管理者でさえも、この作業には細心の注意を払います。共有 NoSQL クラスターの今の時代にもかかわらず、容量の増加は何時間、何日、または何週間もかかりかねません。このようなタスクを行った人なら誰でも、容量拡大中におけるパフォーマンスへの影響は予測不可能であったり、ダウンタイムを伴う場合があることを証言できます。逆に、容量を縮小する値打ちがあると判断することは、まれな状況でしかあり得ないでしょう。これにも独自の複雑な検討事項がつきものだからです。データベース容量の計画と作業がこれほど難しいのはなぜでしょうか? データベースをアンダープロビジョニングすると、アプリケーションに壊滅的な影響を及ぼす可能性があり、オーバープロビジョニングすると、数万、または数十万ドルが無駄になる可能性があります。誰もそのような経験はしたくありません。 Amazon DynamoDB は、開発者とデータベース管理者たちが 10 年以上前から信頼してきた完全マネージド型のデータベースです。DynamoDB は、あらゆる規模で低レイテンシーパフォーマンスを実現し、データベース容量管理を大幅にシンプル化します。最小限の取り組みで、多種多様な SDK および AWS のサービスと簡単に統合される、完全にプロビジョニングされたテーブルを得ることができます。テーブルをプロビジョニングした後は、その容量をすぐさま変更できます。アプリケーションが一晩で大人気を集めたことがわかったとしても、簡単に容量を増加できます。その一方で、アプリケーションロジックを最適化し、データベーススループットを大幅に低減する場合は、プロビジョニングされた容量を減らすことでコスト節約を即座に実現できます。DynamoDB のアダプティブキャパシティーは、裏手で容量の増加と削減をスムーズに処理します。 2017 年 6 月、DynamoDB は効率的な容量管理を容易にする Auto Scaling をリリースしました。それ以来、Auto Scaling は DynamoDB ユーザーが予測可能なトラフィックパターンを持つワークロードのコストを削減できるように援助し続けています。Auto Scaling がリリースされる前は、テーブルのピークロードと小さなバッファに対応するために容量を静的にプロビジョニングしていました。しかし、大抵の場合、テーブルをピーク容量以上に静的にプロビジョニングすることはコスト効率性が良くありません。このブログ記事では、Auto Scaling がトラフィックの変化に対応する方法、Auto Scaling に最適なワークロード、ワークロードの最適化方法とコストベネフィットの計算方法、そして毎秒 100 万件のリクエストで DynamoDB が実現できるパフォーマンスについて説明します。 背景: DynamoDB Auto Scaling の仕組み DynamoDB テーブルを作成すると、Auto Scaling がデフォルトの容量設定となりますが、それがアクティブになっていないテーブルで Auto Scaling を有効化することもできます。以下の図で説明されているように、DynamoDB Auto Scaling は背面で アプリケーションの Auto […]

Read More

Amazon Neptune のための Gremlin クエリヒントの紹介

Amazon Neptune は、高度に連結されたデータの保存とクエリのために最適化された、高速で信頼性に優れた完全マネージド型のグラフデータベースで、データにおける連結のナビゲートと活用に依存するオンラインアプリケーションに最適です。 Amazon Neptune は、SPARQL クエリ言語を使用してクエリできる W3C RDF グラフをサポートします。また、Gremlin グラフトラバース/クエリ言語を使用してクエリできる Apache TinkerPop プロパティグラフもサポートしています。 この記事では、Gremlin ユーザーが使用できるいくつかの新しい機能について検討していきます。今回は特に、クエリがどのように実行されるかをより良く制御できる新しいクエリヒント機能に注目します。 Gremlin クエリヒント Gremlin クエリヒントは、クエリがデータをトラバースする方法をより良く制御し、クエリ順序を最適化するかどうかを指定するために設計されています。このクエリヒントは、特にデータのシェイプを熟知している場合に便利です。 クエリヒントを適用するには、以下の withSideEffect Gremlin ステップを使用します。ここにある <hint-name> は適用されるヒントの名前に置き換え、<hint-setting> は適切な値に置き換えます。新しいヒントは、すべて Neptune# プレフィックスで始まります。 g.withSideEffect(‘Neptune#<hint-name>’,'<hint-setting>’) 現在利用可能なヒントとヒント設定を、以下の表に示します。各ヒントについては、この記事で後から詳しく見ていきます。 ヒント名 ヒント設定 アクション noReordering true Neptune はクエリの実行順序の最適化を試みません。これは、データがどのように編成されているかをユーザーが理解しており、Neptune が順序を変更して制約が適用されることがないようにしたい場合に最も有効です。 noReordering false Neptune は、最初に最も厳しい制約を適用するために、クエリの実行順序の最適化を試みます。これはデフォルトの noReordering 設定です。 repeatMode BFS 幅優先の方法でグラフをトラバースします。これは Gremlin の repeat ステップの使用時における Amazon Neptune のデフォルトバースモードで、多くのユースケースにとって望ましいモードです。ただし、多数の頂点を調べなければならない場合には、かなり多くのメモリを消費する場合があります。 […]

Read More