Amazon Web Services ブログ

Category: Database

Amazon RDS で機密データを保護するためのベストプラクティスの適用

このシリーズの最初の投稿では、AWS のデータストアに適用できる一般的なセキュリティの概念とそれに対応する AWS のセキュリティコントロールについて説明しました。これらを使用して、データに関わるセキュリティ体制をより強固にすることができます。この 2 回目の投稿では、こうした概念を Amazon RDS データベースで実装する方法を説明します。 実装例の多くはすべての RDS データベースエンジンに共通していますが、一部は個々のエンジンの種類によって異なる場合があります。このような場合は、MySQL との互換性を持つ Amazon Aurora の実装例を含めますが、他のデータベースエンジンの情報を入手する場所についても説明します。 それでは、最初の投稿で説明した順序でセキュリティの概念の実装を見ていきましょう。 データの分類とセキュリティゾーンモデリング データの分類とセキュリティゾーンモデリングに関するおさらいとして、以下をご覧ください。ここで提供されているより詳細な説明、およびデータの分類とセキュリティゾーンモデリングの背景にある概念については、このシリーズの最初の投稿を参照してください。 データの分類 この投稿で後述するセキュリティコントロールのどれを適用するかを決定するには、データの分類を理解してください。たとえば、どちらもこの投稿の後半で説明しますが、データのトークン化やセキュリティのマイクロセグメンテーションなど、特殊なセキュリティコントロールは必要ないかもしれません。これらが不要であるケースとしては、データベースにクレジットカード番号や社会保障番号などの機密性の高いデータがない場合があります。 セキュリティゾーンモデリング セキュリティゾーンを設計したら、ネットワークアクセスコントロールリスト (ACL) を使用して実装します。サブネット全体をネットワークフロー制御バリアとして使用できるようにすることをお勧めします。この投稿の後半の「セキュリティグループとネットワーク ACL」セクションで、ネットワーク ACL を使用してセキュリティゾーンを実装する方法を示します。 セキュリティゾーンモデリングを実装するときは、ネットワーク設計を慎重に検討します。CIDR 範囲のサイズによって、各サブネットが表現できる IP アドレスの数が決まります。サブネット内の増加 (より多い IP アドレス) とサブネット数の増加をサポートできるように、CIDR 範囲を設計します。Amazon VPC とオンプレミスのデータセンター間、または VPC 間に矛盾のない IP アドレススペースを確保するための要件とバランスを取ります。詳細については、AWS Answers サイトの AWS 単一 VPC の設計を参照してください。 徹底的な防御 RDS 内での徹底的な防御のためのセキュリティコントロールの詳しい説明に入る前に、この投稿の後半で説明するセキュリティ設定について説明している RDS 起動ウィザードのセクションを見てみましょう。 セキュリティ設定を取得するには、AWS […]

Read More

Amazon DynamoDB: アドテックのユースケースと設計パターン

広告技術 (アドテック) 企業は、Amazon DynamoDB を使用して、ユーザープロファイル、ユーザーイベント、クリック数、訪問済みリンクなどのさまざまな種類のマーケティングデータを保存します。用途としては、リアルタイム入札 (RTB)、広告ターゲティング、アトリビューションなどがあります。このブログ記事では、DynamoDBを使用するアドテック企業の最も一般的なユースケースと設計パターンを特定します。 こうしたユースケースでは、高いリクエスト率 (1 秒あたり数百万件のリクエスト)、低くて予測可能なレイテンシー、および信頼性が必要です。大規模な読み取りボリュームがある場合、またはミリ秒未満の読み取りレイテンシーが必要な場合、企業は DynamoDB Accelerator (DAX) によるキャッシングを利用します。ますます多くのアドテック企業が、複数の地域で RTB や広告ターゲティングプラットフォームをデプロイしており、これには AWS リージョン間でのデータレプリケーションが必要になります。 完全マネージド型サービスである DynamoDB を使用すると、アドテック企業はデータベースの運用にリソースを投資することなく、こうした要件をすべて満たすことができます。また、こうした企業は、DynamoDB への移行によってデータベースの支出が削減されるため、DynamoDB の費用対効果も高いことに気付きます。たとえば、GumGum が自社のデジタル広告プラットフォームを DynamoDB に移行したとき、古いデータベースに比べてコストが 65〜70% 削減されたと推定しています。 この記事で使用される用語 この記事では、以下のデータモデリングと設計パターンの用語を使用します。 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。 DAX によるキャッシング: DynamoDB の前で読み取りキャッシュとして DAX を使用すると、読み取りのレイテンシーを短縮できるだけでなく、頻繁にアクセスされるアイテムに対する高い読み取り負荷を費用効果の高い方法で処理することができます。 アドテックのユースケースと設計パターン ユースケース データモデリングまたは設計パターン RTB および広告ターゲティングでのユーザープロファイルの保存 1:1 モデリング、1:M モデリング […]

Read More

Amazon DocumentDB の新しい集約パイプライン機能を使いパワフルな集約型クエリを記述する

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメントデータベースサービスです。お客様は、現在ご使用のものと同じ MongoDB 向けアプリケーションコードや、ドライバー、およびツールを、そのまま Amazon DocumentDB 上で実行や管理をしたり、処理負荷の調整などに使えます。これにより、基本インフラストラクチャの管理に煩わされることなく、向上したパフォーマンス、スケーラビリティ、および可用性を活用することが可能です。 2 月のブログで解説した機能を基に、 今回、Amazon DocumentDB に新たな集約パイプライン処理に関するサポートが追加されました。この新機能には以下のものが含まれます。 7 個の集約文字列演算子 ($indexOfCP、$indexOfBytes、$strLenCP、$strLenBytes、$toLower、$toUpper、$split) 9 個の日付時間演算子 ($dayOfYear、$dayOfMonth、$dayOfWeek、$year、$month、$hour、$minute、$second、$millisecond) $sample 集約パイプラインステージ このブログでは、一般的なユースケースとして上記演算子の使用法を示しながら、そこに新しく加わった機能をご紹介していくことにします。 Amazon DocumentDB の使用開始 Amazon DocumentDB の初心者の方は、次のいずれかから使用を開始することができます。 Amazon DocumentDB の開始方法 Amazon DocumentDB Quick Start Using AWS CloudFormation Getting Started with Amazon DocumentDB (YouTube 動画)  新機能 Amazon DocumentDB クラスターを作成して接続したら、次の例をよく理解して拡張することができます。 1.集約文字列演算子 ドキュメント内に格納された文字列は、多様な利用法に応じ、必要とされる部分ごとに分けて取り出す操作が可能です。この文字列では、追加の処理や比較、あるいはデータのクリーンアップなどが行えます。アプリケーションコードで文字列処理を記述しなくても、集約文字列演算子を用いてデータ処理をデータベース内に落とし込むことができます。現状で、Amazon […]

Read More

改元はどのように RDS で実行されている MySQL 互換エンジンに影響を与えるか

RDSもしあなたのソフトウェアやシステムが日本のお客様をサポートしており、さらにそのソフトウェアやシステムが元号を表示する必要がある場合、新しい元号を表示するように改修の必要があるかもしれません。新しい元号は、現在の天皇陛下が退位される 2019 年 5 月 1 日から有効になります。 このブログ記事では、かかる元号の変更(改元)にかかわる背景について説明し、その後、どのように改元の影響を調べるかを、私が RDS で実行される MySQL 互換のデータベースエンジンについて調査した際の方法を元に、詳しく解説します。またその調査の結果、RDS で実行される MySQL 互換のデータベースエンジンは改元の影響を受けない、という結果を得たことを報告します。 改元について 元号は、日本で、主に政府のシステムや公的な文書などを中心に、未だ広く使われています。そのようなシステムをサポートするために、いくつかのソフトウェアでは元号をサポートするための機能が実装されています。例えば、Windows では元号をレジストリに格納していたり、Oracle データベースは元号を表示するためのカレンダー・ファイルを持っていたり、glibc ライブラリの strftime()関数は元号を表示するための機能があり、日本語のロケール・ファイルには元号の情報が含まれていたりします。 来る 2019 年 4 月 30 日に、現在の天皇陛下が退位され、それにともない 2019 年 5 月 1 日から元号が変更されます(改元)。そのため、元号をサポートするソフトウェアは、新しい元号を表示できるように更新する必要があります。 新しい元号は2019 年 4 月 1 日に発表される予定となっており、ソフトウェアのアップデートを準備する時間は 1 ヶ月未満の短い期間しかありません。 条件の理解 基本的に、Linux ビルトインのソフトウェアのうち、元号の表示に対応しているものは glibc() ライブラリの strftime() 関数のみです。 strftime()は日付や時刻の表示フォーマットを変更するための関数で、元号を使用して日付を変更する機能を持ちます。日本語 (ja_JP) ロケールを使用しているシステムでフォーマット指定子 (format specification) として […]

Read More

レイテンシーを考慮した Amazon DynamoDB アプリケーションのための AWS Java SDK HTTP リクエスト設定の調整

Amazon DynamoDB は、大規模に実行されるアプリケーションとサービスに低レイテンシーと高スループットのパフォーマンスを提供するために設計された NoSQL クラウドデータベースサービスです。ユースケースの例には以下が含まれます。 大規模多人数参加型オンラインゲーム (MMOG) バーチャルリアリティとオーグメントリアリティ e コマースでのチェックアウトと注文処理 リアルタイムの株価情報と売買 そのようなシステムをグローバルで運営していると、時折レイテンシースパイクが発生することがあります。これらのスパイクは、一時的なネットワーク中断による再試行、サービス側およびネットワーク側の問題、または過剰な負荷がかかった応答が遅いクライアントが原因で発生する場合があります。 根本的な原因にかかわらず、DynamoDB サービスとやり取りするアプリケーションは、レイテンシースパイクを回避するために役立つ再試行戦略に従うよう調整しておく必要があります。使用している AWS SDK に応じて、基盤となる HTTP クライアントの動作は、HTTP を経由する低レベルのクライアント対サーバー通信がアプリケーションのレイテンシー要件に従うことができるように、デフォルト設定を設定し直すことが可能です。このブログ記事では、レイテンシーを考慮した DynamoDB クライアントのための、HTTP リクエストのタイムアウトと再試行動作の微調整に利用できる AWS Java SDK 設定オプションについて説明します。また、適切な設定のメリットを実証するために、2 つの仮定上のアプリケーションシナリオについても説明します。 DynamoDB クライアントのための AWS Java SDK HTTP 設定 AWS Java SDK は、HTTP クライアントの動作と再試行戦略に対する完全な制御を提供します。標準 HTTP 設定の情報については、「クライアント側の設定」を参照してください。一方で、レイテンシーを考慮した DynamoDB アプリケーションクライアントを構築するために必要なより詳しい設定は、ClientConfiguration (JavaDocs) コード実装にあります。 このブログ記事では、非同期 DynamoDB クライアント を Java でゼロから構築し、AWS SDK からの ClientConfiguration […]

Read More

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