Amazon Web Services ブログ

Category: Database

Amazon ElastiCache を使用して、ハイブリッド型アーキテクチャのレイテンシーを削減する

クラウドに移行する際、組織が直面する課題の 1 つに挙げられるのは、限られたライセンスを持つ古いレガシーインフラストラクチャを、幅広い機能と従量課金制を提供できる環境に移行する、あるいはそのような環境に統合するための最善の方法があります。AWS には、分析や計画に役立つ多くのオプションが用意されています。それらに共通する 1 つのアプローチは、既存のデータセンターと AWS の間にハイブリッド環境を確立することです。 ハイブリッド環境では、データベース、アプライアンス機器、内部システムなどのオンプレミスリソースに関連するレイテンシーを軽減することが課題の 1 つです。これに対処できるソリューションは、数多くあります。このブログ記事ではそのうちの 1 つ、キャッシングを使用してレイテンシーを短縮し、パフォーマンスを向上させ、同時に耐障害性を向上させる方法について説明します。 シナリオ : 顧客が主に使用しているアプリケーションで、高いレイテンシーがある 今回検討するシナリオでは、顧客が使用する主なアプリケーションで高いレイテンシーを経験しており、日々の操作に影響していました。このアプリケーションとは、データベースによって駆動する検索機能を備えたオンラインのメディカルライブラリーです。次の図は、元のアーキテクチャを示しています。確認の結果、検索エンジンからのクエリの数が多いことが原因の、過負荷データベースの問題であることが分かりました。さらに、クエリの結果が非常に大きいため、顧客の低速なネットワークリンクが飽和状態になり、応答時間に影響を与えたのでした。 この問題を解決するソリューションの 1 つは、この記事では説明していませんが、データベースを Amazon RDS に移行し、読み取り専用インスタンスを有効にすることです。しかし、顧客のデータベースのライセンス条件により、AWS への移行ができませんでした。データベースを移行する際の別の課題は、アプリケーションとデータベースの統合です。システムが稼働中であったため、アプリケーション全体をライセンス制限のない別のデータベースエンジンに書き換えることはできませんでした。 提案するソリューション : Amazon ElastiCache によるインメモリキャッシュ この問題にはバックエンドデータベースのレイテンシーが関係するため、Amazon ElastiCache でのインメモリキャッシュを使用して、ネットワークのレイテンシーを軽減し、データベースの負荷を軽減します。このソリューションでは、データ取得レイテンシーを劇的に短縮できます。また、Amazon ElastiCache は 1 秒あたり 2000 万を超える非常に高い要求速度を実現できるため、要求量も大幅に増加します。次の図は、提案するアーキテクチャを示しています。VPC 内のキャッシュをウェブサーバーおよびアプリケーションサーバーと共に使用すると、アプリケーションは AWS からローカルデータセンターに常に移動する必要がなくなります。この変更により、サーバー間の物理的な距離は関係なくなります。 このソリューションの別の利点は、ワークロードの追加的可用性と規模です。このアーキテクチャーを使用すると、ソースデータベースに障害が発生しても、アプリケーションに対してクエリを継続して実行できます。これは、結果がキャッシュに格納され、キャッシュから検索されるためです。 この新しいアーキテクチャだと、顧客エクスペリエンスが大幅に改善するはずです。 ElastiCache の背景 Amazon ElastiCache は、Redis および Memcached と互換性のある、完全管理型で低レイテンシーのインメモリデータストアです。ElastiCache は Redis と Memcached の管理に関連する管理タスクがほとんどなくなるため、ビジネスとデータに集中することが可能となります。このサービスは、低速ディスクを使ったデータベースに完全に依存する代わりに、高速でかつ管理されたインメモリデータストアから情報を取得できるようにすることで、ウェブアプリケーションのパフォーマンスを向上させます。ElastiCache では、障害の発生したノードを自動的に検出し置き換えるため、セルフ管理型のインフラストラクチャに伴うオーバーヘッドが減少します。したがって、ElastiCache […]

Read More

Amazon CloudWatch Logs ストリーミングと Kibana を使用した Amazon Elasticsearch Service スローログの分析

一部のお客様から Amazon Elasticsearch Service (Amazon ES) スローログの効率的な分析についてガイダンスを求められました。こうしたお客様の声の一例を下にご紹介します。 「当社では、Amazon Elasticsearch Service 環境で動作の遅いクエリを特定し、分析してトラブルを解決したいと考えています。これはクエリを送信するアプリケーションの修正が目的です。Elasticsearch スローログが Amazon ES で提供されるようになったという記事を読みました。ブログ投稿でスローログを表示する方法の説明を読みましたが、ログが当社のパフォーマンスダッシュボード (これも Amazon ES で動作しています) に流れるようにしたいのです。設定方法を教えてください!」 スロークエリの原因を知りたいですか? 最もパフォーマンスが低いクエリを特定したいですか? インデックス設定をデバッグしますか? このブログ投稿でその方法がわかります。 ソリューションの概要 Amazon ES での Elasticsearch スローログの可用性でもお知らせしましたが、Amazon ES クラスターの設定で Amazon CloudWatch Logs にスローログを送ることができるようになりました。これでスローログメッセージを確認して、ご利用の Amazon ES クラスターのパフォーマンスをより詳しく理解し、動作が低下している検索またはインデックス作成操作を特定できます。 CloudWatch Logs は、ログメッセージを処理や追加の分析のために他のサービスに提供するサブスクリプションをサポートしています。サポートされているサブスクリプションの 1 つが Amazon ES です。Amazon ES クラスターにログを送信するようにサブスクリプションを設定すると、サブスクリプションにより AWS Lambda を使用する関数が自動的に作成されます。CloudWatch がすべてのメッセージを Lambda 関数に送信し、この関数により、メッセージはターゲットの […]

Read More

AWS アカウントの運営上のベストプラクティスの監査を自動化する方法

マイクロサービスアーキテクチャでは、他の組織が運営上のベストプラクティスに従っていることを確認するために、セントラルオペレーショナルエクセレンスチームを必要とする場合が多くあります。 例えば、Amazon S3 バケット内のオブジェクトのライフサイクルポリシー、バージョニング、およびアクセスポリシーが適切に設定されたかどうかを知りたい場合があります。適切な構成においては、所望の保存および削除ポリシーを確実に得ることができ、Amazon S3 オブジェクトの偶発的な共有を回避します。 これと同様に、チームがテーブル内で Amazon DynamoDB auto scaling を有効にしているかについて知りたい場合もあります。これにより、トラフィックの増加をシームレスに処理できるようにスループット容量 (読み出しと書き込みの容量単位) が増加し、ワークロードが減少するとスループット能力が低下します。この scaling は、適切な量のプロビジョニングした容量分を支払うことを意味します。最後に、効率的かつ自動化された応答のために、Amazon CloudWatch アラームを DynamoDB テーブル (または他の AWS リソース) への設定完了を確認することをお勧めします。 AWS は Amazon CloudWatch 、AWS CloudTrail 、AWS Config 、および AWS Trusted Advisor などのサービスを提供し、運営監査を可能にします。このブログ記事では、さまざまな AWS services により提供される AWS Lambda と API を使用して、運営上のベストプラクティスの監査を自動化する方法について説明します。 ソリューションの概要 この記事では、 Lambda 関数の AWS Identity and Access Management (IAM) […]

Read More

AWS re:Invent 2017 Roundup:オンデマンド視聴のためのすべてのAmazon DynamoDB関連のセッション

2ヶ月前にAWS re:Invent 2017を開催したにもかかわらず、私たちは引き続き、会議から素晴らしいAmazon DynamoDBセッションの内容をまとめて共有したかったのです。次のテーブルには、DynamoDBに関連するセッションのタイトルと、セッション録画へのリンク、セッションの説明、および各セッションの最適な説明が記載されています。 AWS re:Invent 2017のセッションタイトルとビデオへのリンク セッション内容 ベスト Amazon.com – 100のOracle DBをJust Oneに置き換える:Amazon DynamoDB(ARC406) 300を超えるAmazonエンジニアリングチームが使用するミッションクリティカルなシステムで、Herdは毎日40億以上のワークフローを実行します。2013年からは、Herdのワークフロートラフィックは、毎年倍増していました。そして、その数十の水平方向にパーティション化されたOracleデータベースをスケーリングすることは、悪夢のようなものでした。Herdのスケーリングニーズをサポートし、より良い顧客体験を提供するために、Herdチームはストレージシステムを再構築し、OracleからAmazon DynamoDBへのプライマリーデータストレージを移動する必要がありました。このエキスパートレベルのセッションでは、DynamoDBへの移行について議論し、直面した最大の課題とその克服の方法を学び、学んだ教訓を共有します。 Amazon.comがどのように100のOracleデータベースをDynamoDBに移行したかを知りたい方。 キャッシング可能な場合:高度なキャッシングストラテジー(ATC303)によりコストを最適化しながらレイテンシを最小化する Amazon CloudFrontからElastiCache、Amazon DynamoDB Accelerator(DAX)まで、このセッションは、アドテックワークロードにどうやってキャッシュ方法を適用させるかを学習するワンストップショップです。どのデータをキャッシュすべきで、それはなぜですか? キャッシュするときの一般的な副作用と落とし穴は何ですか? 実際にDAXをどのように使用するべきですか? 常にデータが最新のキャッシュ状態を保つにはどうすればよいですか? このセッションでは、これらのトピックについて深く議論し、チームインターネットから学んだ教訓を共有します。 アドテックのワークロードにどうやってキャッシュ方法を適用させるか詳細を知りたい方。 DynamoDB – 新機能(DAT304) 今回のAmazon DynamoDBの一般セッションでは、新しく発表された機能について説明し、最新の技術革新についてのエンドツーエンドの視点を提供します。また、顧客の成功事例やユースケースを共有し、グローバルテーブルとオンデマンドバックアップのライブデモを共有します。 DynamoDBや新機能について知りたい方。 クラウドへのギャラクシーの移行:サムスンのAmazon DynamoDB(DAT320)への移行に関するベストプラクティス このセッションでは、従来のリレーショナルデータベースマネジメントシステムやその他のNoSQLデータベースなど、データベースをAmazon DynamoDBに移行するためのベストプラクティスを紹介します。重要なDynamoDBの概念、評価基準、DynamoDBでのデータモデリング、DynamoDBへのデータ移行、データ移行時の重要な考慮事項について説明します。CassandraクラスターをSamsung CloudワークロードのためにDynamoDBに移行した、Samsung Electronicsの事例を紹介します。 SamsungがDynamoDBにどのように移行したかを知りたい方。 ExpediaがDynamoDBに飛ぶ:Travel Analytics(DAT324)のためのライトニング – ファストストリーム処理 豊富で高性能なストリーミングデータシステムを構築するためには、複雑なビジネスロジックを実装するために参照データセットへのオンデマンドアクセスが必要です。このセッションでは、Expediaが直面したアーキテクチャー上の課題と、Amazon DynamoDB Accelerator(DAX)とAmazon DynamoDBがアーキテクチャー全体にどのように適合し、Expediaの設計要件を満たしているかについて説明します。以下について学びます:1)データをストリーミングするためのExpediaの全体的なアーキテクチャーパターン、2)ExpediaがDynamoDB、DAX、Apache Spark、Apache Kafkaを使用して問題に対処する方法、そして3)DAXが提供する価値と、Expediaがパフォーマンスとスループットを向上させ、コストを削減する方法—新しいコードを書く必要はまったくありません。 ExpediaがDynamoDBとDAXを使用して、参照データセットに高速かつオンデマンドでアクセスする方法を知りたい方。 Amazon DynamoDB(DAT325)のSnapchat Stories […]

Read More

MySQL5.7互換のAmazon AuroraでJSONを利用する

MySQL 5.7でのJSONサポートについて重要な点は? MySQL 5.6では、数値、日付と時刻、文字列(文字とバイト)の型、および空間データ型をサポートしています。これらの型は広くサポートされていますが、これらの基本データ型は、アプリケーションを進化を作成する際の柔軟性を制限します。 MySQL 5.6を使用している場合は、アプリケーションに機能を追加する計画する際に2つの選択肢があります。最初のオプションは、アプリケーションで現在必要なすべてのフィールドを含む完全なスキーマを設定することです。その後アプリケーションで新しいフィールドが必要な場合は、スキーマを更新してその列を追加する必要があります。このアプローチにはいくつかの利点があります。新しいフィールドにインデックスを作成することができます。また、Amazon Auroraのfast DDLのような機能により、列を追加する際の影響を最小限に抑えることができます。ただし、データベース・スキーマの変更を実行し、その変更に対応するためにSQL文を更新する必要があります。 2番目のオプションは、文字列を使用して柔軟なフィールドセットをエンコードし、アプリケーションレイヤーで文字列を解析することです。柔軟性はありますが、この方法ではデータを解析するのに無駄なコストがかかります。 この様な場面ではJSONが適しており、必要とされる柔軟性を提供することで優れた方法を提供します。 JSONは、データを解析するためのコードを書く必要がないという利点も提供します。ORMまたは言語ランタイムで処理が可能です。JSONサポートはMySQL 5.7.8で導入されました。 これらの利点に加えて、JSONをネイティブ・タイプとしてMySQLで使用することで、データベースはJSONカラムに保存されているJSONドキュメントを自動的に検証できます。無効なドキュメントではエラーが発生します。ネイティブタイプのJSONでは、データベース中でJSON形式を最適化することもできます。JSONカラムに格納されたJSONドキュメントは、ドキュメント要素への高速な読み取りアクセスを可能にする内部形式に変換されます。サーバーが後でこのバイナリ形式で格納されたJSON値を読み取る必要がある場合、その値をテキスト表現から解析する必要はありません。バイナリ形式は、サーバーがサブオブジェクトまたはネストされた値をキーまたは配列のインデックスで直接参照できるように構成されています。これは、ドキュメント内の前後の値をすべて読み取らずに行います。 Amazon AuroraはMySQL 5.7との互換性をサポートしています。つまり、MySQL 5.7互換のAuroraを利用してJSONデータ型を使用したアプリケーションを開発できるようになりました。 この記事の残りの部分では、JSONデータ型とMySQL互換のAuroraを使用する電化製品のECサイトのサンプルアプリケーションをご紹介します。 スキーマの作成 電化製品は、ラップトップ、携帯電話、プリンター、テレビ、DVDなど多様なもを取り扱います。また、製品の属性もどうように多くなります。このため、さまざまな機能や属性を検索できるように、製品属性を正規化された形式で保存するのは難しいくなります。たとえば、製品比較のためにこれを行えるようにします。 まず、店舗用のデータベースを作成します。 CREATE DATABASE online_store; USE online_store 簡単にするため、データベースにはブランド、カテゴリ、製品という3つのテーブルのみ作成します。brandsとcategoriesテーブルにはJSONフィールドがありませんので、先に進むために説明は省かせて頂きます。 CREATE TABLE brands ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL ); CREATE TABLE categories ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY […]

Read More

DataSunrise Database Security を使用した Amazon Aurora データベースアクティビティのモニタリング

DataSunrise 社エンジニアリングリーダー、Radik Chumaren DataSunrise は、多種多様なデータベースのためのアクティビティモニタリング、データマスキング (動的および静的マスキング)、データベースファイアウォール、および機密データ検出を含む、幅広いセキュリティソリューションを提供するデータベースセキュリティソフトウェア企業です。DataSunrise の目標は、外部および内部の脅威と脆弱性からデータベースを保護することです。お客様はよく、DataSunrise Database Security が Amazon Aurora、Amazon Redshift、Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB、Amazon RDS for Oracle Database、および Amazon RDS for Microsoft SQL Server を含む AWS で実行される異なる種類のデータベースエンジンを保護するときに、統合された制御とシングルユーザーエクスペリエンスを提供することから DataSunrise Database Security を選択しておられます。 DataSunrise は、アクティブなデータとデータベースのセキュリティに加えて、監査などの受動的なセキュリティの両方を提供します。アクティブなセキュリティは、機密データへの不正アクセスの防止、疑わしい SQL クエリのブロック、SQL インジェクション攻撃の防止、またはリアルタイムでのデータの動的なマスキングと難読化などの事前定義されたセキュリティポリシーに基づいています。DataSunrise は、高可用性、フェイルオーバー、および自動スケーリングを備えています。 この記事では、監査としても知られる受動的なセキュリティに焦点を当てます。今回は、DataSunrise が Aurora で何を監視するか、どのように機能するか、およびその使用開始方法について説明します。今後の記事では、アクティブなセキュリティ、データマスキング、および機密情報の検出を含む、セキュリティにおけるその他の側面を取り上げます。 DataSunrise 監査の対象 DataSunrise は、SQL クエリ、データフロー、バインディングなどの監査を可能にします。収集される情報には、SQL クエリの詳細と、それらの実行による結果が含まれます。SELECT […]

Read More

AWS Database Migration Service を使用した Amazon RDS for SQL Server の継続的なレプリケーションの紹介

AWS Database Migration Service (AWS DMS) とAmazon RDS for SQL Server が新たに Amazon RDS for SQL Server からの継続的なレプリケーションをサポートするという新機能を発表できることを嬉しく思います。AWS DMSは、データベースをAWSに迅速かつより安全に移行できるサービスです。また、AWS内のデータ移行にも使用できます。Oracle、Microsoft SQL Server、PostgreSQLなど、広く普及している商用およびオープンソースデータベース間でデータを移行できます。このサービスはSQL ServerからSQL Serverのような同エンジン間の移行と、SQL ServerからAmazon Aurora MySQLまたはSQL ServerからAmazon RDS for MySQLなどの異なるデータベースプラットフォーム間の移行の両方が可能です。 この記事では、Microsoft SQL Server からの継続的なレプリケーションプロセスの概要を簡単に説明します。また、MS-CDC(SQL Serverでの変更データキャプチャ)とAWS DMSを使用して、Amazon RDS for SQL Serverからの継続的な変更をストリーミングするための新機能も紹介します。   背景 AWS DMSは異なるエンジン間の移行(SQL ServerからMySQLへの移行など)用に設計されています。ただし、同エンジン間(SQL ServerからSQL Serverなど)の移行もサポートしています。これまではソースインスタンスで実際に行われていた変更にアクセスする必要がありました。 主キーを持つテーブルの場合、AWS DMSはデフォルトで以下のように使用されるように設計されています。 1.SQL Serverから進行中の変更を移行するタスクを設定すると、AWS DMSは最初に次のコマンドを使用してトランザクションレプリケーション用のデータベースを有効にします。 use master exec sp_replicationdboption […]

Read More

AWS SCT と AWS DMS を使ってMySQLから Amazon Aurora に移行する方法

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。 データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。 一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。 多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。 このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。 同種間移行の方法 AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora […]

Read More

MongoDB クラスターから Amazon DynamoDB へのライブマイグレーションの実行

あるデータベースから別のデータベースへのデータ移行は、データの整合性、アプリケーションのダウンタイム、ターゲットとソースデータベース間の重要な設計の違いに関して、相当難易度が高くなる場合があります。AWS Data Migration Service (AWS DMS) は、MongoDB、Oracle、MySQL、Microsoft SQL Server などのデータベースの素早く、安全で、シームレスな AWS への移行を支援します。ソースデータベースは移行中もほとんど動作し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。 この記事では、シャーディングされた MongoDB クラスターのライブデータを Amazon DynamoDB のテーブルにシームレスに移行するためのアプローチを説明します。Amazon DynamoDB は、あらゆる規模で一貫性のある 1 桁ミリ秒台のレイテンシーが必要なアプリケーション向けの、完全マネージド型、高速、スケーラブル、柔軟なクラウドデータベースサービスです。この記事で説明されているアプローチは、ほぼダウンタイム無しで移行を実施し、AWS DMS を使用してソースデータを変換し、少数のアクセスパターンを提供します。 DynamoDB と MongoDB のコンポーネント間のマッピング 移行を実施する前に、Amazon DynamoDB と MongoDB のコンポーネントを簡単に比較してみましょう。DynamoDB と MongoDB の多くのコンセプトは類似しており、どちらも JSON のようなデータを柔軟でダイナミックなスキーマでアプリケーションに保存することができますが、いくつかの点で大きく異なります。 このセクションでは、DynamoDB のコアコンセプトをいくつか説明し、DynamoDB と MongoDB のコンポーネントを比較します。MongoDB のコンセプトの詳細については、MongoDB のマニュアルを参照してください。 主要なコンポーネント Amazon DynamoDB で用いる主要なコンポーネントは、テーブル、項目、および属性です。テーブルは項目の集合であり、各項目は属性の集合です。DynamoDB では、テーブルのアイテムを一意に識別するためプライマリキーを使用し、クエリの柔軟性を高めるためにセカンダリインデックスを使用しています。各テーブルはそれぞれに対応するインデックス、キャパシティー、スケーラビリティの設定がある分離されたユニットです。DynamoDB と MongoDB は、どちらもデータセットを項目の集合に分割することが可能です。 以下の表は DynamoDB […]

Read More

Amazon Redshiftを使用した高性能ETL処理のベストプラクティス Top 8

ETL(Extract、Transform、Load)プロセスを使用すると、ソース・システムからデータ・ウェアハウスにデータをロードできます。 これは、通常、バッチまたはほぼリアルタイムのインジェスト(挿入)プロセスとして実行され、データウェアハウスを最新の状態に保ち、エンドユーザーに最新の分析データを提供します。 Amazon Redshiftは、高速でペタバイト規模のデータウェアハウスであり、データ駆動型の意思決定を簡単に行うことができます。 Amazon Redshiftを使用すると、標準的なSQLを使用して、費用対効果の高い方法で大きなデータを洞察することができます。 StarおよびSnowflakeスキーマから、分析クエリを実行するための単純化された正規化されていないテーブルまで、あらゆるタイプのデータモデルを使用した分析が可能です。 堅牢なETLプラットフォームを操作し、Amazon Redshiftにデータをタイムリーに配信するには、Amazon Redshiftのアーキテクチャを考慮してETLプロセスを設計します。 従来のデータウェアハウスからAmazon Redshiftに移行する場合、リフト・アンド・シフト方式を採用することが魅力的ですが、結果としてパフォーマンスとスケールの問題が長期的に発生する可能性があります。 この記事では、ETLプロセスにおける最適かつ一貫した実行時間を確保するためのベスト・プラクティスを下記にご紹介します。 複数の均等なサイズのファイルからデータの COPY Workload Management (WLM) を用いたETL実行時間の改善 定期的なテーブルのメンテナンスの実施 単一のトランザクションで複数ステップの実行 データの一括読み込み UNLOADを利用した大きな結果セットの抽出 アドホックETL処理に Amazon Redshift Spectrumを使用 診断クエリを使用して日常的なETLヘルスの監視 1. 複数の均等なサイズのファイルからデータの COPY Amazon RedshiftはMPP(大規模並列処理)データベースで、すべての計算ノードがデータの取り込み作業を分割して並列化します。 各ノードはさらにスライスに細分され、各スライスは1つ以上の専用コアを有し、処理能力を等しく分割します。 ノードあたりのスライス数は、クラスタのノードタイプによって異なります。 たとえば、各DS2.XLARGE計算ノードには2つのスライスがありますが、各DS2.8XLARGE計算ノードには16のスライスがあります。 Amazon Redshiftにデータを読み込むときは、各スライスに同じ量の作業をさせることを目指すべきです。 1つの大きなファイルまたは不均一なサイズに分割されたファイルからデータをロードすると、一部のスライスは他のスライスよりも多くの仕事をする必要があります。 その結果、プロセスは最も遅い、または最も負荷の高いスライスと同じ速度で実行されます。 以下の例では、1つの大きなファイルが2ノードのクラスタにロードされ、ノード「Compute-0」のうちの1つだけがすべてのデータ処理を実行します。 データファイルを分割する際には、圧縮後のサイズがほぼ同じ(1 MB〜1 GB)であることを確認してください。 ファイル数は、クラスタ内のスライス数の倍数にする必要があります。 また、gzip、lzop、またはbzip2を使用してロードファイルを個別に圧縮し、大規模なデータセットを効率的にロードすることを強くお勧めします。 1つのテーブルに複数のファイルをロードする場合は、複数のCOPYコマンドではなく、テーブルに対して1つのCOPYコマンドを使用します。 Amazon Redshiftはデータの取り込みを自動的に並列化します。 1つのCOPYコマンドを使用してデータをテーブルにバルクロードすると、クラスタリソースの最適な使用と可能な限り高いスループットが可能となります。 2. Workload Management (WLM) を用いたETL実行時間の改善 […]

Read More