Amazon Web Services ブログ

Category: Database

AWS クラウドへの移行時にデータベースコストを削減して可用性を向上させる

ログとクリックストリームのデータを保存するためにデータベーステーブルを使用するアプリケーションがあるとしましょう。データは、開発タスクと管理タスクを容易にするためにリレーショナルデータベースに保存されているかもしれません。アプリケーションを起動すると、初めのうちはこのデータベースも管理可能ですが、データベースは毎週何百ギガバイトにも成長します。データストレージと取得だけでも、リレーショナルデータベースインスタンスの IOPS と CPU の 20 パーセントが消費されています。さらに、アプリケーションはトランザクションデータに加えて、データベーステーブルに XML ドキュメント、JSON ドキュメント、およびバイナリドキュメントも保存しています。履歴データも毎月増加し続けています。従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増える一方で、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。 データストアのタイプ リレーショナルデータベース管理システム (RDBMS) は、ほとんどのトランザクション処理システムの中核を成しています。RDBMS にすべてのデータを保存することによって、以下が起こる可能性があります。 パフォーマンス問題の原因になる。大規模なテーブルには、データのクエリにより長い時間が必要です。特定のテーブル一連における大量の読み取り/書き込みトラフィックは、データベースでの他のクエリの速度を低下させます。 総所有コスト (TCO) を増大させる。より多くの読み取り/書き込みトラフィックに対応するには、より多くのコンピューティングキャパシティーとストレージ容量を追加することによってデータベースを垂直にスケールする必要があります。これは季節的なトラフィックの増加に対処するためのものかもしれまんせんが、アプリケーショントラフィックへの対応に高額な先行投資を行わなければなりません。また、データベースサーバーをスケールダウンすることはできません。これも TCO を増加させます。 AWS に移行すると、アプリケーションはリレーショナルデータベースのストレージだけを使用するのではなく、そのデータを専用のデータストアに保存することができます。アプリケーションが使用するデータストアは、そのアクセスパターンに応じて異なります。これは、データがどのような規模で増加することを見込んでいるか、およびデータにどれだけ迅速にアクセスする必要があるかにも依存します。以下の表は、これらのデータストアのタイプと用途、および各タイプの例を示すものです。 データストア 用途 例 NoSQL 広告配信、ゲーミングデータ、IoT センサーデータ、およびユーザープロファイルなどの非構造化データ Amazon DynamoDB、MongoDB、Apache Cassandra ビッグデータ Twitter フィード、クリックストリームデータ、およびログなどのペタバイト規模のデータの保存と分析 Amazon EMR、Hadoop、Apache Spark、Apache Hive、Apache HBase キャッシング ゲームのスコアボードなどのアプリケーションサーバーとデータベースの間にあるキャッシュレイヤー Amazon ElastiCache オブジェクトストレージ ログファイル、画像、Twitter フィード、およびバックアップなどの、無制限の量のデータと無制限のオブジェクトの保存 Amazon Simple Storage Service (Amazon S3) […]

Read More

Amazon DynamoDB のベストプラクティスに従うという 2019 年の計を立てる

  AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。 パーティションキーを効率的に設計して使用する DynamoDB テーブルにある各アイテムを固有に識別するプライマリーキーは、シンプルなキー (パーティションキーのみ) または複合キー (ソートキーと組み合わされたパーティションキー) にすることができます。アプリケーションは、テーブルとそのセカンダリインデックスの論理パーティションキー全体で統一されたアクティビティのために設計してください。これは NoSQL のベストプラクティスですが、バーストキャパシティー、アダプティブキャパシティー、および書き込みシャーディングといった追加のメリットが得られます。 ソートキーを使用してデータを編成する DynamoDB テーブルでは、テーブル内の各アイテムを固有に識別するプライマリーキーを、パーティションキーだけではなく、ソートキーも使って構成することができます。適切に設計されたソートキーは、関連する情報を一か所に集め、それを効率的にクエリすることができます。複合ソートキーは、データで階層 (1 対多) リレーションシップを定義することを可能にし、任意の階層レベルでクエリすることができます。 セカンダリインデックスを効率的に使用する 多くの場合、セカンダリインデックスはアプリケーションが必要とするクエリパターンをサポートするために必須です。その一方、非効率的なセカンダリインデックスの使用は不必要にコストを増加させ、パフォーマンスを低下させます。 大型のアイテムと属性を保存する方法を理解する DynamoDB では現在、テーブルに保存する各アイテムのサイズが制限されています。お使いのアプリケーションに、サイズ制限の許容範囲を超えるデータをアイテムに保存する、またはそのアイテムをソートキーの効率的な使用によって分類される複数のアイテムに分割する必要がある場合、ひとつ、または複数の大型の属性を圧縮してみる、またはそれらを Amazon S3 内のオブジェクトとして保存して、Amazon S3 オブジェクト識別子を DynamoDB アイテムに保存することができます。 期間ごとに 1 アプリケーションあたり 1 つのテーブルを使って時系列データに対応する DynamoDB における一般的な設計原則では、使用するテーブルの数を最小限にとどめることが推奨されています。ほとんどのアプリケーションには、単一のテーブルしか必要ありません。しかし、時系列データについては、期間ごとに 1 アプリケーションあたり 1 つのテーブルを使うことができます。 多対多リレーションシップを管理する 隣接リストは、DynamoDB における多対多リレーションシップのモデル化に有用な設計パターンです。より一般的には、DynamoDB でグラフデータ (ノードとエッジ) を表現する方法を提供します。 […]

Read More

タグベースのスケーリングプランを使って AWS Auto Scaling ポリシーを簡単に管理する方法

AWS Auto Scaling は、AWS リソースをそれらのトラフィックパターンに基づいて動的にスケールアップ/スケールダウンすることができます。しかし、典型的なアプリケーションスタックには多数のリソースがあり、これらのリソースすべてに対して個別の AWS Auto Scaling ポリシーを管理することは、組織的な課題となり得ます。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。 タグベースのスケーリングプランを使用するには、AWS リソースにタグを付けてからプランをセットアップする必要があります。私は、この例を開始する前にスケーリングプランで管理したい AWS リソースを検討しました (私の場合は Amazon EC2 Auto Scaling グループと Amazon DynamoDB テーブルです)。次に、対応する正しい値 (DEV、BETA、または PROD のいずれか) を持つ環境タグを使用してリソースにタグ付けしました。環境タグは、リソースのスケーリングポリシーをインフラストラクチャの場所別にグループ化して管理する、そしてターゲット使用率の割合を調整するために使用できます。リソースのタグ付けに役立つヒントと戦略については、AWS Tagging Strategies をご覧ください。 注意: AWS Auto Scaling は現在、AWS のリージョン表に記載されているリージョンでご利用いただけます。 インフラストラクチャ環境に基づいたスケーリングプランのセットアップ このセクションでは、すべての開発リソースのためにひとつのスケーリングプランをセットアップし、本番リソースのために 2 つ目のプランをセットアップします。これらのスケーリングプランによって、選択したタグに関連付けられている関連リソースのグループに、ターゲット使用率のパラメーターを簡単に設定することができるようになります。 開発リソースのためのプランの作成 作成を開始するには、AWS Auto Scaling コンソールに移動します。既存のスケーリングプランはないので、[今すぐ始める] を選択します。(既存のプランがある場合は、AWS Auto Scaling […]

Read More

[AWS Black Belt Online Seminar] Amazon DynamoDB Advanced Design Pattern 資料及び QA 公開

先日 (2018/12/25) 開催しました AWS Black Belt Online Seminar「Amazon DynamoDB Advanced Design Pattern」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. 「時系列データが必要なアプリケーション」のスライドで GSIKey Rand(0-N) というのがありましたが、これはどのような目的がありますか? A. こちらにあるような形で、書き込み後の検索効率向上の為のテクニックになります。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております! AWS Black Belt Online Seminar 1月分申込先 ≫ Redshift Recently Features Update 2019 年 […]

Read More

新しい Database Migration Playbook が公開されました—Microsoft SQL Server から Amazon Aurora MySQL への移行

Microsoft SQL Server to Amazon Aurora MySQL Compatibility Migration Playbook の初版を発表いたします。AWS Database Migration Service (AWS DMS) および AWS Schema Conversion Tool (AWS SCT) を使用すると、商用エンジンからオープンソースデータベースおよび Amazon が管理するデータベースへの移行に伴う労力を軽減できます。したがって、コストを削減し、ベンダーによるロックインを回避するのに役立ちます。このプレイブックは、既存の SQL Server データベースから Amazon Aurora with MySQL compatibility への移行を担当するデータベース管理者を支援するように設計されています。 このプレイブックは、AWS SCT の自動変換機能に焦点を当て、自動変換プロセスの制限事項に対する代替方法について説明します。SQL Server と Aurora MySQL の違い、非互換性、類似点を中心に説明し、幅広い種類のトピックを網羅しています。そうしたトピックとしては、T-SQL、構成、高可用性と災害対策 (HADR)、インデックス作成、管理、パフォーマンスチューニング、セキュリティ、物理ストレージなどが含まれます。このプレイブックには、ツールの機能の概要、移行の課題とその回避策、詳細な例が記載されています。 これは私たちが公開した 2 番目のプレイブックです。最初のプレイブック、Oracle to Amazon Aurora with PostgreSQL Compatibility Migration Playbook […]

Read More

2018 年に最もよく読まれた AWS データベースブログ

以下の 10 本の記事は、私たちが 2018 年に掲載した AWS データブログ記事で最もよく読まれたものです。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。 サーバレスアプリケーションから AWS データベースをクエリする AWS Schema Conversion Tool によるTrimble社のデータベース移行を成功させた秘訣とは AWS Glue を使って、分析処理のためにデータを抽出、変換、ロードする方法 (パート 2) Oracle から PostgreSQL への移行時における課題と、それらを解決する方法 AWS Database Migration Service を使用して Amazon RDS for SQL Server から継続的なレプリケーションを行う新機能の紹介 Amazon CloudWatch を使った Amazon Aurora MySQL、Amazon RDS for MySQL、および MariaDB のログの監視 Performance Insights を使って Amazon RDS データベースの作業負荷を分析する Amazon Kinesis Data […]

Read More

AWS データストア内の機密データを保護するためのベストプラクティス

クラウド内の機密データを保護するための効果的な戦略を立てるには、一般的なデータセキュリティパターンをよく理解し、これらのパターンを明確にマッピングしてクラウドセキュリティコントロールに活かすことが必要です。その後、これらのコントロールを Amazon Relational Database Service (Amazon RDS) や Amazon DynamoDB などのデータストアに固有の実装レベルの詳細に適用できます。 このブログ記事では、データを保護する一般的なデータセキュリティパターンとそれに対応する AWS セキュリティコントロールに焦点を当てます。この記事では Amazon RDS と DynamoDB について説明しますが、Amazon RDS と DynamoDB の実装については、今後投稿する 2 つの記事で詳細に説明する予定です。

Read More

Amazon DynamoDB グローバルテーブルを使用してマルチリージョンアーキテクチャを強化する方法

この記事では、Amazon DynamoDB を使用して、複数の AWS リージョンにデプロイされたグローバルバックエンドのデータベースを強化する方法について説明します。ここでは DynamoDB グローバルテーブルを使用します。これは完全マネージド、マルチリージョンかつマルチマスターのデータベースを提供するもので、世界中のどこにいても低レイテンシーのデータアクセスをユーザーに提供できます。

Read More

Amazon RDS Under the Hood: シングル AZ インスタンスのリカバリ

この投稿では、Amazon RDS シングル AZ RTO と RPO で何を期待できるかについて説明します。 ワークロードによっては RTO と RPO の要件が緩和されている可能性があり、これらのニーズを満たすにはシングル AZ 設定で十分な可能性があります。ただし、シングル AZ のみのソリューションに着手する前に、シングル AZ RDS インスタンスのリカバリの期待値と、どのようなシナリオがあるかを理解する必要があります。

Read More

DynamoDB グローバルセカンダリインデックスを使用してクエリのパフォーマンスを向上させ、コストを削減する方法

この記事では、グローバルセカンダリインデックスを使用してデータを照会し、アプリケーションのパフォーマンスを向上させ、毎月の DynamoDB 請求金額を削減する方法をいくつかご紹介します。最近、テーブルあたりのグローバルセカンダリインデックスの最大数が 5 から 20 に、制限が引き上げられました。そのため、今が DynamoDB の使用を最適化するためのグローバルセカンダリインデックスの使用方法を学ぶ恰好のタイミングです。

Read More