Category: Database*


AWS Migration Hub – エンタープライズアプリケーションの移行の計画と追跡

1週間に約1回、私はシアトルのエグゼクティブブリーフィングセンターで現在の有力なAWSのお客様に話します。一般的に私はイノベーションプロセスに重点を置いていますが、アプリケーションの移行を含む他のトピックについても議論することがあります。企業がアプリケーションポートフォリオを移行する場合、企業は構造化された整然としたやり方でそれを実行したいと考えています。これらのポートフォリオは、通常、何百もの複雑なWindowsおよびLinuxアプリケーション、合理的なデータベースなどで構成されています。お客様は、進め方についてはまだ不確実であることがわかります。これらの顧客と一緒に働く時間を費やした後、彼らの課題は一般的に次の3つの主要カテゴリに分類されることがわかりました。

ディスカバリー – お客様は、各アプリケーションを動かす全ての部分について、深くて完全な理解を得たいと考えています。

サーバー&データベース移行 – オンプレミスのワークロードとデータベースのテーブルをクラウドに転送する必要があります。

追跡/管理 – 大規模なアプリケーションポートフォリオと複数の移行が並行して行われるため、アプリケーション中心の方法で進捗状況を追跡および管理する必要があります。

ここ数年、私たちは最初の2つの課題に取り組む一連のツールを立ち上げました。 AWS Application Discovery Serviceはシステム情報の検出と収集のプロセスを自動化し、AWS Server Migration Serviceはクラウドへのワークロード移行を処理し、AWS Database Migration Serviceは最小のダウンタイムでリレーショナルデータベース、NoSQLデータベース、データウェアハウスを移行します。 RacemiCloudEndureなどのパートナーは、独自の移行ツールも提供しています。

新しいAWS Migration Hub

今日、これらAWSサービスとパートナー移行ツールをAWS Migration Hubに統合しています。ハブは、前述のツールへのアクセスを提供し、移行プロセスをガイドし、Migration Acceleration Program(MAP)で説明されている方法論および原理に従って、各移行の状況を追跡します。

ここにメイン画面があります。移行プロセス(ディスカバリー、移行、および追跡)の概要を示します。

Start discovery」をクリックすると、移行プロセスのフローが表示されます。

ディスカバリー手順をスキップしてすぐに移行を開始することもできます。

AWS移行サービス(Server Migration ServiceまたはDatabase Migration Service)のデータ、パートナーツール、またはAWS Application Discovery Serviceによって収集されたデータを使用し、サーバーリストが作成されます。

自分用の最初のアプリケーションを作成するには、「Group as application」を選択することができます。

移行するアプリケーションを特定したら、そのアプリケーションをHubの「Applications」セクションで追跡できます。

移行ツールは承認されている場合、アプリケーションの移行ステータスページに表示するために、ステータスの更新と結果を自動的にMigration Hubに送信します。ここでは、Racemi DynaCenterCloudEndure Migrationが担当する部分の移行を実施したことがわかります。

Migration Hub Dashboardをチェックすると、移行のステータスを追跡できます。

Migration Hubは、AWSと移行パートナーの移行ツールと連携して動作します。詳しくは、Integrated Partner Toolのリストをご覧ください。

 

今すぐ利用可能

AWS Migration Hubは、必要となる移行ツールが利用可能な様々なAWSリージョンの移行を管理できます。Hub自体は米国西部(オレゴン州)地域で運営されています。Hubは無料です。移行の過程で消費するAWSサービスに対してのみお支払いいただきます。

クラウドへの移行を開始する準備ができていて、何らかの支援が必要な場合は、Migration Accelerationパートナーのサービスを利用してください。これらパートナーは、大規模な移行を繰り返し実践・提供することを通じて移行コンピテンシーを獲得しています。

Jeff;

(翻訳は諸岡が担当しました。原文はこちら)

Amazon Redshiftクエリーモニタリングルールでクエリーワークロードを管理する

データウェアハウスのワークロードは多様性で知られています。これは、季節性や、往々にして高コストになりがちな探索的クエリー、SQL開発者のスキルレベルのばらつきなどによるものです。

Amazon Redshiftワークロード管理機能(WLM)を用いて優先度やリソース使用量を柔軟に管理することで、極めて多様なワークロード環境でも高い性能を得ることが可能となります。WLMによって、短時間で完了するクエリーが長時間実行されるクエリーのせいでキューに滞留するような状況を避けることができます。にも拘わらず、あるクエリーが不釣り合いな量のリソースを独占し、システム内のその他のクエリーを圧迫することが依然として起こり得ます。こうしたクエリーは、一般にrogue queryやrunaway queryと呼ばれます(訳者註:rogueはならず者、面倒を起こすといった意味、runawayは暴走の意で、ここでは一方的にリソースを占有し他のクエリーに影響を及ぼすクエリーを指します)

WLMは、メモリー使用量を制限し、タイムアウトを用いてクエリーを別のキューに移動させる機能を持ちますが、ずっと粒度の細かいコントロールができることが望ましいことは論を俟ちません。クエリーモニタリングルールを用いて、リソース使用量のルールを作成し、クエリーのリソース使用量を監視し、それらがルールを犯した時のアクションを決めることが可能になりました。

ワークロード管理における同時並列性とクエリーモニタリングルール

Amazon Redshift環境では、単一クラスターに対し最大500まで同時接続することができます。性能指標であるスループットは一般に一時間あたりのクエリー数として表現されますが、MySQLのような行指向データベースであれば、同時接続数を増やすことによってスケールします。Amazon Redshift環境では、ワークロード管理(WLM)によって、同時接続数とは異なる方法でスループットを最大化します。WLMは二つの部分があります。キューと同時並列性です。キューはユーザーグループまたはクエリーグループのレベルでのメモリー割り当てを可能にします。同時並列性(またはメモリースロット)は、この割り当てをさらにどのように分割し、個々のクエリーにメモリーを割り当てるかを制御します。

例えば、同時並列性10の1つのキューがある(メモリー割り当て100%)と仮定しましょう。これは、個々のクエリーは最大10%のメモリーの割り当てを受けることを意味します。もしクエリーの大半が20%メモリーを必要とした場合、これらのクエリーはディスクにスワップアウトし、スループットの劣化をもたらします。しかし、もし同時並列性を5に下げた場合、個々のクエリーは20%のメモリー割り当てを受けることができるため、トータルのスループットは高くなり、SQLクライアントへのレスポンスも全体的に高速になります。高い同時並列性がよりよいパフォーマンスに繋がると考えてしまうことは、行指向のデータベースを列指向に切り替える時に陥りがちな典型的な落とし穴の一つです。

同時並列性について理解したところで、クエリーモニタリングルールについて掘り下げていきましょう。リソース使用量に基づくルールと、それに違反した場合に取るアクションを定義します。当該クエリーによるCPU使用量、クエリー実行時間、スキャンされた行数、返された行数、ネステッドループ(Nested loop)結合など、12の異なるリソース使用量メトリクスを利用できます。

それぞれのルールは最大3つの条件(述語)と、一つのアクションを持ちます。

述語は、メトリック、比較演算子(=、<または>)、値で構成されます。あるルール内の全ての述語がマッチすると、そのルールのアクションがトリガーされます。ルールアクションには、ログ(記録)、ホップ(次のキューへの移動)、アボート(終了)があります。

これにより、はた迷惑なクエリーを、より深刻な問題が出来する前に捕捉することが可能になります。ルールはアクションをトリガーしてキューを解放し、スループットと応答性を改善します。

例えば、短時間実行クエリー専用のキューのために、60秒を超えて実行し続けるクエリーをアボートするルールを作ることができます。設計のよくないクエリーを追跡するために、ネステッドループを含むクエリーを記録する別のルールを作ることもできます。Amazon Redshiftコンソールには、簡単に始められるよういくつかのテンプレートが事前定義されています。

シナリオ

クエリーモニタリングルールを使って、単純なロギングからクエリーのアボートまで、幅広いクエリーレベルアクションを行うことができます。また、全てのアクションはSTL_WLM_RULE_ACTIONテーブルに記録されます。

それでは、以下の三つのシナリオを用いて、クエリーモニタリングルールをどのように使うかを見ていきましょう。

シナリオ1:アドホッククエリーに潜む非効率なクエリーを制御するには?

二つの大きなテーブルを結合するようなクエリーは、何十億、あるいはそれ以上の行を返す可能性があります。十億行を超える行を返すクエリーをアボートさせるルールを設定することで、アドホッククエリーの安全性を担保することができます。このルールは、論理的には以下のようになります。

IF return_row_count > 1B rows then ABORT

以下のスクリーンショットの設定では、十億行を超える行を返すBI_USERグループ内のクエリーはすべてアボートします。

シナリオ 2: 非効率で、CPUインテンシブなクエリーを制御するには?

CPUスパイクをもたらすクエリーが、必ずしも問題というわけではありません。しかし、高いCPU使用量と長いクエリー実行時間を併せ持ったクエリーは、実行中の他のクエリーのレイテンシーを悪化させます。例えば、高いCPU使用率を示し続ける非効率なクエリーが長時間実行されている場合、それは誤ったネステッドループ結合のせいかも知れません。

こうしたケースでは、10分間にわたって80%以上のCPU使用率を示しているクエリーをアボートさせるルールを作成することで、クラスターのスループットと応答性を上げることができます。このルールは、論理的には以下のようになります。

IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下のスクリーンショットの設定では、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。

80%以上のCPU使用率を5分以上続けるクエリーを記録し、10分以上続いた場合はアボートするよう、ルールを拡張することもできます。このルールは、論理的には以下のようになります。

IF cpu_usage > 80% AND query_exec_time > 5m then LOG and IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下のスクリーンショットの設定では、5分間にわたってCPU使用率が80%を超えているクエリーは記録され、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。

シナリオ 3:

進捗していないクエリーを監視し、記録するには?

例えば、ミックスワークロード環境では、ETLジョブがS3から大量のデータを抽出し、Amazon Redshiftにロードしているケースがあります。データ抽出中、キューでスタックして、全く進捗していないように見えるCOPYコマンドが見つかるかも知れません。このようなクエリーはデータ抽出を遅延させ、ビジネス上のSLAに悪影響を与える可能性もあります。

クエリーを追跡し記録するルールを作ることで、こうしたクエリーを捕捉することができます。低いCPU使用率のまま長時間実行されているクエリーを見つけ出すルール、例えば1%のCPU使用率で10分間動作しているようなクエリーを記録するルールを作成します。このルールは、論理的には以下のようになります。

IF cpu_usage < 1% AND query_exec_time > 10m then LOG

以下のスクリーンショットの設定では、10分間にわたってCPU使用率が1%未満であるクエリーが記録されます。

まとめ

Amazon Redshiftは強力かつフルマネージドなデータウェアハウスであり、高いパフォーマンスと低いコストの双方をクラウド上でご提供します。しかしながら、クラスターリソースを独り占めするクエリー(rogue queries)はユーザーエクスペリエンスに悪影響を及ぼします。

このポストでは、クエリーモニタリングルールがこの種のクエリーにどのように対処可能かを見てきました。これらの内容は、ミックスワークロード環境でのクラスター性能とスループットを最大化し、円滑なビジネス遂行を実現する上で役立つはずです。

ご質問やご提案がありましたら、以下にコメントを残していただけますと幸いです。

(翻訳はAWS Japanプロフェッショナルサービス仲谷が担当しました。原文はこちら

DynamoDB Accelerator (DAX) が正式にサービス開始しました

今年の初め頃 Amazon DynamoDB AcceleratorDAX)について紹介をしました。DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段(論理的に)に置かれます。DAXはキャッシュされたデータに対するリクエストをマイクロ秒単位で返すため、読み込みワークロードに最適です。DAXはアプリケーションコード内ではDynamoDB APIと互換性を保つ様にサポートしており、シームレスで使いやすいようにデザインしています。管理することはDAXクラスタを作成して既存の読み取りと書き込みのターゲットとして使用するだけです。パッチ適用、クラスタメンテナンス、キャッシュデータの複製、または障害管理について心配する必要はありません。

本日から利用可能
今日DAXが正式に利用可能になったことをお知らせします。DAXが利用可能なAWSリージョンを追加拡張し、プレビューの期間にパフォーマンスと可用性をチューニングしました。

5つのリージョンで利用可能 – 現在 DAXはUS East (Northern Virginia)、EU (Ireland)、US West (Oregon)、Asia Pacific (Tokyo)、US West (Northern California) の5つの地域で利用可能です。

In Production – プレビュー期間内にDAXを本番で使用しているユーザーもおり、DAXをアプリケーションに追加するのが楽で今ではアプリケーションの速度が10倍速くなってたという声を頂いています。

Getting Started with DAX
以前の記事(翻訳版はこちら)で紹介したように、DAXを使用して既存のDynamoDBアプリケーションを高速化するのは簡単です。必要なリージョンにDAXクラスタを作成し、 DAX SDK for Javaを利用するようにアプリケーションを更新します(コード内の呼び出し方は同じですが、ライブラリの置き換えを行う事です)。SDKを構成してクラスタにエンドポイントを使用するようにします。リードスルー/ライトスルーキャッシュとして、DAXはすべてのDynamoDB読み取り/書き込みAPIをシームレスに処理します。

私たちは他の言語のSDKのサポートも取り組んでおり、利用可能になった時点で追加情報を共有します。

価格について

US East (Northern Virginia) と US West (Oregon) の各地域で、時間あたり$ 0.269から始まる料金
でクラスター内の各ノード(詳細については、 DynamoDBの価格を参照)を1時間単位でお支払いいただきます。DAXでは、クラスタ内の各ノードが高可用性のための読み取りターゲットおよびフェールオーバーターゲットとして機能します。DAX SDKはクラスタを認識しており、クラスタ内のすべてのノードに対してラウンドロビンで要求を発行し、クラスタのキャッシュリソースを最大限に活用できるようにします。

DAXは読み取りトラフィックの急激な急上昇を容易に処理できるため、テーブルのプロビジョニングされたスループットの量を減らすことができ、結果としてマイクロ秒で結果を返しながら全体のコストを削減できます。

最後にAmazon.comのCTOであるWerner Vogelsが書いたブログを紹介させて頂きます。

Amazon DynamoDB Accelerator (DAX): Speed Up DynamoDB Response Times from Milliseconds to Microseconds without Application Rewrite.

Tinder、Careem、そしてCanon INC. の事例についてもご紹介していますので、ぜひご覧ください。

Jeff;

(翻訳はSA成田が行いました。原文はこちら

新機能 – Auto Scaling for Amazon DynamoDBについて

Amazon DynamoDBには幅広い業界やユースケースを含む10万人以上の多くのお客様がいます。 お客様は世界中の16の地域で、DynamoDBの一貫性のあるパフォーマンスを利用する事が出来ます。 最近の傾向は、DynamoDBを使用してサーバレスアプリケーションと組み合わせるお客様です。 この使い方は非常にマッチします:DynamoDBでは、サーバーのプロビジョニング、OSとデータベースのソフトウェアパッチ適用、または高可用性を確保するためのAZゾーン間のレプリケーションの設定などを考える必要はありません。テーブルを作成してデータを追加するだけでDynamoDBが処理するようにします。

DynamoDBにはプロビジョニングキャパシティーユニットモデルが用意されており、アプリケーションで必要とされる読み書き容量を設定できます。 これによりサーバの考え方から解放され、簡単なAPIコールまたはAWS Management Consoleのボタンをクリックしてテーブルのプロビジョニングを変更できるようになりましたが、多くのお客様はDynamoDBの容量をさらに簡単に管理できるように望んでいました。

本日、DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量管理を自動化できるようになりました。 維持をしたい使用率を指定し、読み書き容量の上限と下限を指定するだけです。 DynamoDBは、Amazon CloudWatchアラームを使用して消費量を監視し、必要に応じてプロビジョニングされた容量を調整します。 Auto Scalingは、すべての新しいテーブルとインデックスに対してデフォルトでオンに出来ます(但しIAM権限の事前準備が必要です)。また、既存のテーブルやインデックスに対しても設定できます。

あなたが常にマネジメントコンソールに張り付いていなくても、DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。 これによりDynamoDBデータの管理が容易になり、アプリケーションの可用性を最大化しDynamoDBのコストを削減するのに役立ちます。

どのような機能か早速御覧ください。

Using Auto Scaling

新しいテーブルを作成するときに、DynamoDB Consoleにデフォルトパラメータセットが提示されるようになりました。 あなたはそのまま利用する事も、「Use default settings」のチェックを外して独自のパラメータを入力することもできます

独自にパラメータを設定する方法は以下の通りです。

Target utilizationは、消費容量とプロビジョニングされた容量の比率で表されます。 上記のパラメータは、読み取りまたは書き込み要求が増えた時でも消費される容量の2倍になるように十分な空き容量を確保します(DynamoDBの読み書き操作とプロビジョニングされた容量の関係の詳細については容量単位の計算を参照してください)。 プロビジョニングされた容量の変更は、バックグラウンドで行われます。

Auto Scaling in Action

この重要な新機能が実際に動作するのを見るために、「Getting Started Guide」の指示に従いました。 私は、新しくEC2インスタンス起動し、AWS SDK for Pythonを設定(sudo pip install boto3)を実行し利用するための設定(aws configure)を行いました。 次に、PythonとDynamoDBのコードを使用していくつかのデータを含むテーブルを作成し、読み込みと書き込みの各容量を5ずつ手動で設定しました。

CloudWatchメトリクスで綺麗な直線を得るために私は急いで休憩を取ったので、AutoScalingの効果を示すことができました。 負荷を適用する前のメトリクスは次のとおりです。

私はステップ3のコードを変更して、1920年から2007年の範囲でランダムにクエリを発行し、1〜2分後に読み取りメトリクスを確認しました。

消費された容量はプロビジョニングされた容量よりも多く、その結果多くの読み込みリクエストに対してスロットルが発生します。 AutoScalingが実行される!

私はコンソールに戻ってテーブルのCapacityタブをクリックした。 Read capacityをクリックし、デフォルト値を受け入れ、Saveをクリックしました

DynamoDBは新しいIAMロール(DynamoDBAutoscaleRole)とCloudWatchアラームのペアを作成して、読み取り容量のAuto Scalingを設定しました。

DynamoDB Auto Scalingはアラームのしきい値を管理し、スケーリングプロセスの一部としてアラームのしきい値を上下に調整します。 最初のアラームがトリガーされ追加の読み取り容量がプロビジョニングされている間にテーブルの状態が[Updating]に変更されました。

この変更は、数分で読み取りメトリクスに表示されました。

私は変更されたクエリスクリプトをいくつか実行し、追加の容量がプロビジョニングされているのを見てみました。

私はすべてのスクリプトを停止しスケールダウンアラームが発生するのを待ちました。:

翌朝Scaling activitiesを確認し、アラームが夜の間に何度かトリガされたことを確認しました:

これはメトリクスにも表示されていました。

これまでは、あなたが期待した使用量についてプロビジョンキャパシティユニットを十分に設定し、余裕を持たせる設定(青い線と赤い線の間のスペース)を行うことで、このような状況に備えることができました。若しくはプロビジョンキャパシティユニットを少なくしすぎ、監視するのを忘れてトラフィックが増えた時に容量が使い果たされる可能性がありました。 Auto Scalingを使用すると、リクエストが増加し必要な場合は自動的に増やし、もう不要な時は自動的に下げる事が可能です。

Things to Know

DynamoDB Auto Scalingは、ある程度予測可能である程度定期的に変化する要求レートに対応するように設計されています。予期せぬバーストした読み取りアクティビティに対応する必要がある場合は、Auto ScalingをDAXと組み合わせて使用​​する必要があります(詳細は、Amazon DynamoDB Accelerator(DAX) – Read heavyなワークロード向けインメモリ型キャッシュクラスタを参照してください)。また、AWS SDKを利用したアプリケーションは、スロットリングされた読み込み要求と書き込み要求を検出し、適切な遅延の後に再試行します。

(補足:Auto Scaling実行され実際に使える容量が増えるまでにはどうしても時間が掛かります。その為瞬間的なリクエスト増加に対応するのは難しいケースがあります。その為、瞬間的なリクエスト増加に対応するにはDAXなどのソリューションと組み合わせる事や、瞬間的にスロットリングが発生してもリトライで処理を継続させる事により影響を最小限にする処理が必要です。)

 

私はDynamoDBAutoscaleRoleを先に述べました。このロールは、テーブルとインデックスのスケールを上下させるために必要な権限をAuto Scalingに提供します。このロールと権限の詳細については、「Grant User Permissions for DynamoDB Auto Scaling」を参照してください。

Auto ScalingにはAuto Scalingポリシーを有効または無効にする機能を含むCLIとAPIの完全なサポートがあります。トラフィックに予測可能な時間的なスパイクがある場合(ゲームなどであれば決まった時間に発生するイベントなど)は、プログラムによって自動スケーリングポリシーを無効にし、一定期間高いスループットをプロビジョニングしてから、後でAuto Scalingを再度有効にすることができます。

DynamoDBの制限ページに記載されているように、プロビジョニングされた容量は、必要に応じて必要なだけ増やすことができます(アカウントごとに設定されている上限内にて)。各テーブルまたはグローバルセカンダリインデックスごとに1日に最大9回まで容量を減らすことができます。(その為、あまり頻繁に容量を下げる設定にしてしまうとこの回数を使い切ってしまいその後下げる事が一時的に出来なくなる可能性があります。)

実際に実行された容量は通常のDynamoDBの価格が掛かります。さらに節約するためにDynamoDBのリザーブドキャパシティユニットを購入することもできます。

今すぐ利用可能
この機能は現在すべての地域で利用可能で、今すぐ使用することができます!

Jeff;

(この記事はSA 成田が翻訳しました。原文はこちら

 

 

 

オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

  • AWS SCT をダウンロード
  • AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
  • 米国西部(オレゴン)リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部(オレゴン)リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

Launch Stack

スタックを起動して名前を付けるには、次のようにします。

  1. AWSアカウントにまだログインしていない場合はログイン。
  2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
  3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
    Specify Details
  4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
    I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
    Eventsタブ
  6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
    Outputsタブ

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

  1. AWS Schema Conversion Tool を開始。
  2. Fileから New Project を選択。New Project ダイアログが表示される。
    New Project dialog
    次のプロジェクト情報を追加。

    Project Name プロジェクト名を入力。コンピュータにローカル保存される
    Location ローカルプロジェクトファイルの保存先を入力
    Data Warehouse (OLAP)
    Source DB Engine Oracle DW
    Target DB Engine Amazon Redshift
  3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
  4. Oracle Database に接続するため、Connect to Oracle DW を選択。

    Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。

    以下の値をフォームに入力。

    Server name <移行元EC2エンドポイントのDNS名>
    Server port 1521
    Oracle SID XE
    User name dms_sample
    Password dms_sample
    Use SSL チェックしない
  5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
  6. 移行元データベースに接続するため、OKを選択。
  7. DMS_SAMPLEデータベースを選び、Nextを選択。
  8. Database Migration Assessment Report を読み、Nextを選択。

  9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。

    Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。

    以下の値をフォームに入力。

    Server name 移行先RedshiftエンドポイントのDNS名
    Server port 5439
    Database dev
    User name admin
    Password CloudFormationで選ばれたパスワード
    Use SSL チェックしない
  10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
  11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

  1. Viewを選び、Main View を選択。
  2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Convert schema を選択。
  3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
  4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

  1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
  2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
  3. 「レプリケーションインスタンスの作成」ページが表示される。

    このページで以下の値を入力し、「次へ」を選択。

    名前 8から16文字のASCII文字によるレプリケーションインスタンスの名前(/、”、@を除く)
    説明 レプリケーションインスタンスの説明を入力
    インスタンスクラス dms.t2.medium
    VPC 使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
    Multi-AZ いいえ
    パブリックアクセス可能 チェック
  4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

  1. ソースエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン oracle
    サーバー名 <移行元EC2エンドポイントのDNS名>
    ポート 1521
    SSLモード none
    ユーザー名 dms_sample
    パスワード dms_sample
  2. ターゲットエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン redshift
    サーバー名 <RedshiftエンドポイントのDNS名>
    ポート 5439
    SSLモード none
    ユーザー名 admin
    パスワード CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

タスク名 タスク名を入力
ソースエンドポイント 使用する移行元エンドポイントを選択
ターゲットエンドポイント 使用する移行先エンドポイントを選択
レプリケーションインスタンス 使用するレプリケーションインスタンスを選択
移行タイプ Migrate existing data
作成時にタスクを開始 チェックする

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

Oracle Database を Amazon Aurora に移行する方法

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。

データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。

AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。

すばらしい! では、どこから始まれば良いのでしょう?

AWS SCT での移行手順

通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool とは からご覧ください。

この投稿ではSCTのイストールや構成については触れませんが、注意点は移行元と移行先のデータベースにSCTを接続するために、OracleとMySQLのドライバーをインストールする必要があることです。移行元のOracleに接続した後、スキーマのいずれかを右クリックしてアセスメントレポートを作成できます。アセスメントレポートはこのスキーマがどれくらいOracleからAuroraに自動変換されるのかと、自動変換後に残された作業量がどれくらいなのかの概要を教えてくれます。以下がレポートの例です。

Database Objects with Conversion Actions for Amazon Aurora

アセスメントレポートに加えて、SCTは各オブジェクトがどれくらい正確に変換されるかも教えてくれます。もしあるオブジェクトが変換できない場合、SCTはその理由と、状況を改善するためのヒントを教えてくれます。

Database Objects with Conversion Actions for Amazon Aurora

スキーマの100%がOracleからAuroraに変換されない場合、いくつかの方法で状況を改善できます。

  • 移行元のOracleのデータベース上のオブジェクトを変更して、SCTでAuroraに変換できるようにする
  • スキーマをひとまず変換し、SCTによって生成されたスクリプトを変更してからAuroraデータベースに適用する
  • 変換できないオブジェクトを無視し、移行先でそれらを置き換えるか無視する。たとえば、Oracleのsys.dbms_randomパッケージを呼び出すファンクションがあるとします。このパッケージはAuroraには存在しません。この問題を解決するには以下のことができます。
    • ランダム値の生成をアプリケーションコードに移し、それをパラメーターとしてファンクションに渡します。この変更は、変換前の移行元データベースまたは変換後の移行先データベースで行うことができます。
    • SCTで生成されたコードを、MySQLに存在するRAND()ファンクションを使うように変更し、新しいコードをAuroraデータベースに適用します。

その他の例として、一意の識別子を生成するためにOracleのシーケンスを使っているとします。Auroraはシーケンスをサポートしていないので、修正するために以下を実行してください。

  • 自動的に一意の識別子を生成するAuroraのauto-increment機能を使う。この方法で行く場合は、Auroraデータベースにスキーマを作成した後で、移行先のテーブルを変更するためのスクリプトを作成することをお勧めします。
  • 一意の識別を生成する何か別の方法(ファンクションや類似のもの)を作成し、シーケンスを参照している部分を新しいファンクションで置き換える。これは変換前に移行元のOracle上で実施することも、移行先のAuroraで実施することもできます。
  • 両方の手法を使う必要があるかもしれません。

一般的に、移行の一環としてSCTを使うための良い取り組み方には以下を含みます。

  • SCTアセスメントレポートを作成し、移行のギャップを埋める計画を立てる。もし移行候補となる複数のシステムがある場合は、どのシステムから最初に取り組むべきかの決定に役立ちます。
  • Action Items を確認し、変換に失敗した各項目の適切な処理を決定する。
  • 新しいAuroraデータベースに対してアプリケーションをテストしながら、AWS Database Migration Service と連携して新しいスキーマにデータをロードし、この処理を繰り返す

AWS DMS での移行手順

AWS DMS は移行元のOracleデータベースから移行先の新しいAuroraデータベースにデータをロードするときに使えます。DMSの素晴らしい点は、データを丸ごとロードすることに加えて、実行中のトランザクションをキャプチャして適用することです。カットオーバーの準備が整うまで、Oracleの移行元データベースとAuroraの移行先データベースを同期させつづけます。このアプローチによって、移行を完了させるために必要な停止時間を大幅に短縮することができます。DMSマイグレーションには、移行元エンドポイントであるOracle、移行先エンドポイントであるAurora、レプリケーションサーバー、タスクを含みます。

OracleからAuroraに移行するとき、既存データを移行し、進行中の更新をレプリケーションするタスクを構成したいでしょう。これにより、データ全体の移行中に実行されたトランザクションをキャプチャするようにDMSに指示します。データ全体がロードされると、DMSはキャプチャされたトランザクションの適用を開始し、OracleとAuroraのデーベースの同期を開始します。Auroraをカットオーバーする準備ができたら、アプリケーションを停止し、残ったトランザクションをDMSに適用させ、新しいAuroraデータベースに接続するアプリケーションを開始するだけです。

DMSを使用してOracleからAuroraに移行する場合、考慮すべき点がいくつかあります。

サプリメンタルロギング。 DMSが移行元のOracleから更新をキャプチャするにはサプリメンタルロギングを有効にする必要があります。詳細な手順については、DMSのマニュアルを参照してください。

DMSの3つのフェーズ。 データを移行し、進行中の更新をキャプチャするとき、DMSは3つのフェーズを経ています。

  • バルクロード: バルクロードフェーズで、DMSはn個のテーブルを一度にまとめてロードします。デフォルトでは n = 8 です。この値はDMSマネジメントコンソールまたは AWS CLI を利用して変更できます。
  • キャッシュされたトランザクションの適用: バルクロードフェーズにDMSは移行元データベースへの更新をキャプチャします。あるテーブルのバルクロードが完了すると、DMSはバルクロードの一部であるかのようにキャッシュされた更新をできるだけ速くそのテーブルに適用します。
  • トランザクションとしての適用: すべてのテーブルのバルクロードが完了すると、DMSはキャプチャされた更新を単一のテーブルの更新ではなく、トランザクションとして適用し始めます。

セカンダリインデックス。 状況によっては、性能上の理由からDMSのバルクロードフェーズにセカンダリインデックスを削除したくなるかもしれません。バルクフェーズ中にセカンダリインデックスの一部またはすべてを削除することを選ぶ場合は、移行を一時停止して、トランザクションとしての適用フェーズでそれらを追加しなおす必要があります。すべてのテーブルのフルロードが完了した後であれば、移行を安全に一時停止することができます。

外部キー、トリガーなど。 バルクロードはテーブル単位で行われるため、バルクロードやキャッシュされたトランザクションの適用フェーズでは移行先のAurora内の外部キーに違反する可能性があります。initstmt=SET FOREIGN_KEY_CHECKS=0 をAuroraエンドポイントの追加接続属性として加えることで、外部キー検査を無効にすることができます。一般的に、データのバルクロードを中断したり悪影響を与える可能性のあるものにどう対処するかの戦略を策定する必要があります。たとえば、問題を回避するために、移行のカットオーバーフェーズになるまでトリガーの実装を延期することができます。

データ型。 新しいデータベースエンジンに移行するときには、どのようなデータ型がサポートされているかと、移行元のデータ型を移行先の新しいデータ型にどう変更するかを理解することが重要です。これについては、移行元のOracleのデータ型移行先のAuroraのデータ型をマニュアルで確認すべきです。

性能。 移行の全体的な性能は、移行元のOracle内のデータ量、種類、分散に依存しています。 AWS Database Migration Service Best Practices ホワイトペーパーに移行性能を最適化するためのいくつかの推奨事項が載っています。

手順をおさらいすると、

  1. SCTアセスメントレポートを使用して課題の概要を知ることができます。Auroraへの移行候補が複数ある場合は、どれから最初に取り組むべきかの決定に役立ちます。
  2. 処理の前後に必要となるかもしれない移行手順を洗い出すために、DMSを使用して移行先スキーマの作成とロードを実践します。
  3. 移行先のシステムでアプリケーションをテストして、新しい環境で期待通りに動作することを確認します。負荷やネットワーク環境を含む本番環境と同等の構成でテストしてみてください。
  4. スキーマの生成、データのロード、後処理の手順の適用、移行元と移行先システムの同期、カットオーバーに必要な手順などの実際の移行を実践します。
  5. SCTもDMSをシステム全体を一度に移行することを求めません。システムを短期間で効率的に移行するため、また必要であれば再構築するために、これらのツールを使用することができます。

実際の移行を開始する前に、SCTとDMSの両方のドキュメントを通して読むことをお勧めします。また、Step-by-Step ウォークスルーAWS Database Migration Service Best Practices ホワイトペーパー を読むこともお勧めします。

ツールの使い方を知るためにサンプルデータベースを使用したいのであれば、AWS GitHub リポジトリ で見つけることができます。

この投稿は特定の状況に必要な可能性のあるすべての手順や考慮事項を解説するものではありませんが、SCTとDMSを使用してプロプライエタリなOracleデータベースの足かせをどう緩められるかについての良いアイデアを提供しました。それでは幸せな移行を!


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は How to Migrate Your Oracle Database to Amazon Aurora です。

【AWS Database Blog】AWS Database Migration Service におけるイベント通知

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。


先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email や テキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。

お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。

レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。

さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS コンソール、AWS DMS API を使って、そのカテゴリをサブスクライブできます。サブスクライブすることにより、そのカテゴリに関するイベントが起きた際に、通知されます。例えば、特定のレプリケーションインスタンスについての “creation(作成)”カテゴリをサブスクライブした場合、レプリケーションインスタンスが作成されているなどのような、レプリケーションインスタンスに影響を与える creation に関連したイベントが起きた際はいつでも通知がなされます。

下記の一覧は、現時点で DMS レプリケーションインスタンスについてサブスクライブできるカテゴリを示しています。

  • Configuration change(設定変更)—レプリケーションインスタンスの設定が変更されています
  • Creation(作成)—レプリケーションインスタンスが作成されています
  • Deletion(削除)—レプリケーションインスタンスが削除されています
  • Maintenance(メンテナンス)—レプリケーションインスタンスのオフラインメンテナンスが実行中です
  • Low storage—レプリケーションインスタンスの空きストレージが少なくなっています
  • Failover(フェイルオーバー)—Multi-AZ インスタンスのフェイルオーバーに関連するイベント。フェイルオーバーの有効化、開始、完了など。
  • Failure(失敗)—レプリケーションインスタンスで、ストレージ障害やネットワーク障害が発生しました

下記の一覧は、現時点で DMS レプリケーションタスクについてサブスクライブできるカテゴリを示しています。

  • State change— レプリケーションタスクが開始もしくは停止されました
  • Creation(作成)—レプリケーションタスクが作成されました
    Deletion(削除)—レプリケーションタスクが削除されました
  • Failure(失敗)—レプリケーションタスクが失敗しました

AWS DMS によるイベントとイベントカテゴリの一覧は、ドキュメントのイベントと通知の使用を参照してください。

AWS DMS イベントをサブスクライブするには、以下の通り行います。

  1. Amazon SNS トピックを作成します。このトピックには、どんなタイプの通知を受け取りたいか、受け取るアドレスや電話番号を設定します。
  2. AWS マネジメントコンソール、AWS CLI, もしくは AWS DMS API を通じて、AWS DMS イベント通知のサブスクライブを行います。
  3. AWS DMS のイベント通知を受け取るための承認メールもしくは SMS メッセージを受け取り、E メール、SMS メッセージ内のリンクをクリックして、サブスクライブの確認を行います。

サブスクライブしたことを確認すると、AWS DMS コンソールの Event Subscriptions セクションにて、お客様のサブスクリプションのステータスが更新されます。

そして、イベント通知の受信が開始されます。

コンソールを使ったテーブルマッピングについての詳細は、DMS ドキュメントを参照ください。

AWS Database Migration Service 全般に関する詳細は、こちらのウェブサイトを参照ください。

Amazon Redshiftのワークロード管理(WLM)を使ってミックスワークロードを実行する

ミックスワークロードの環境下では、ビジネス上の要求を満たすために、バッチとインタラクティブのワークロード双方が同時に実行されます。ミックスワークロードを管理し構成するには、アクセスパターンやシステムリソースの使われ方、およびパフォーマンス要件についての詳細な理解が必要です。

ミックスワークロードでは、一般に、一部のプロセスが他より高い優先順位を必要とします。あるケースでは、これはあるジョブが特定のSLA内で完了しなくてはならないことを意味します。別のケースでは、あまりクリティカルではないレポーティングワークロードが一度に多くのクラスターリソースを消費しすぎないようにするだけでよいこともあります。

ワークロード管理(WLM)を利用しない場合、各クエリーは同じ優先順位で処理されます。これによって、あるメンバー、チーム、あるいはワークロードが、他のビジネス上重要なジョブに比べてさほど重要ではない処理のために、大量のクラスターリソースを消費するといった事態が起こり得ます。

このブログポストでは、一般的なWLMパターンに関するガイドラインを提供するとともに、WLMに関連する様々なクエリーとビューを使用して本番ワークロードの構成を最適化する方法について記載します。

ワークロードの概念

WLMを使用して、複数のビジネスワークロードを分離すると共に、システム上で実行される様々なタイプの同時実行クエリ−の優先順位を設定することができます。

  • インタラクティブ:実行する人間の入力を受け付けるソフトウェア。インタラクティブなソフトウェアには、BIツールやレポーティングアプリケーションなどのポピュラーなプログラムが含まれます。
    • 短時間のみ実行される、読み取り専用のユーザークエリー。低レイテンシーで実行する要件を含むTableauダッシュボードクエリーなどが該当します。
    • 長時間実行される、読み取り専用のユーザークエリー。過去10年間の営業データの集計する複雑な構造化レポートなどが該当します。
  • バッチ:手動介入を伴わない、サーバープログラム内の一連のジョブの実行(非インタラクティブ)。単一の入力ではなく、複数の入力の集合(”バッチ的な”入力とも言えます)に基づく一連のプログラムの実行は、カスタムジョブと呼ばれます。
    • 一括で実行されるINSERT、UPDATE、およびDELETEトランザクションもバッチクエリーに含まれます。ETLやELTプログラムはこの一例です。

Amazon Redshift ワークロード管理(WLM)

Amazon Redshift はスケーラビリティ、セキュリティおよび高パフォーマンスを提供する、ペタバイトスケール・カラムナー・超並列型の、完全に管理されたデータウェアハウスです。Amazon Redshiftは業界標準のJDBC/ODBCドライバーインターフェイスを提供します。これにより、お客様は彼らの既存のBIツールを用いて接続することができ、また既存の分析クエリーを再利用することが可能です。

Amazon Redshiftは様々な種類の分析的データモデルに適合します。例えば、スタースキーマ、スノーフレークスキーマや、 シンプルな非正規化テーブルなどが利用できます。

ワークロードを管理する

Amazon Redshiftワークロード管理は、特定環境下における、様々なサイズと複雑性を持つワークロードの管理を可能にします。WLMの構成はパラメーターグループに含まれ、いくつのクエリーキューが処理に利用可能か、およびそれぞれのキューがどのようにそれらのキューにルーティングされるかを決定します。カスタムパラメーターグループを作成してグループ内の設定を編集し、それをクラスターに関連付けて下さい。以下のような設定が構成可能です。

  • それぞれのキュー内でいくつのクエリーが同時に実行可能か
  • キュー間でのメモリ配分
  • クエリーがどのようにキューにルーティングされるか。誰がクエリーを実行しているか、クエリーレベルは、などの基準
  • あるキューにおけるクエリータイムアウト設定

ユーザーがクエリーを実行する際、WLMはそのクエリーを最初にマッチしたキューに割り当てた上で、WLMの構成に基づいてルールを実行します。WLMクエリキュー、同時実行、ユーザーグループ、クエリーグループ、タイムアウト設定、およびキューホッピング機能等の詳細については、クエリーキューの定義を参照して下さい。動的に変更可能な構成プロパティの詳細については、WLM の動的設定プロパティと静的設定プロパティを参照して下さい。

例えば、以下のスクリーンショットのWLM構成では、ETL、BI、およびそれ以外のユーザーをサポートするための三つのキューが構成されています。ETLジョブは長時間実行用のキューに割り当てられ、BIクエリーは短時間実行用のキューに割り当てられます。その他のユーザーのクエリーはデフォルトキューで実行されます。

 

WLM-Picture 1

WLM最適化クラスター構成のガイドライン

1. 複数のビジネスワークロードを分離し、クエリーを互いに独立して実行する。

ダッシュボードクエリーとETLといった異なるビジネスプロセスをサポートするため、互いに独立したキューを作成します。例えば、ワンタイムクエリーのための独立したキューを作成することは、それらのクエリーがより重要なETLジョブを阻害しないようにするための有益なソリューションと言えます。

また、より短時間で実行されるクエリーは一般的にメモリー使用量が少ないため、それらのワンタイムユーザーやクエリーグループ用のキューには、より低いWLM使用メモリー比率(訳者註:マネジメントコンソール上の”メモリ(%)”の設定値)を設定することができます。

2. 同時実行数やメモリー割り当てをアクセスパターンに合わせてローテーションする。(適合するユースケースの場合)

トラディショナルなデータ管理では、ETLジョブはソースシステムから特定のバッチウィンドウ内でデータを取得、整形した後、ターゲットのデータウェアハウスにロードします。このアプローチでは、業務時間中は、BI_USERグループにより多くの同時実行数とメモリを割り当て、ETL_USERには非常に限られたリソースのみを割り当てます。業務時間後は、重くリソースインテンシブなジョブが迅速に完了するよう、ETL_USERへの割り当てを動的に変更またはスイッチすることを、クラスターの再起動なしに行うことが可能です。

注:下記のAWS CLIコマンドサンプルはデモ目的のために、複数の行で表示されています。実際のコマンドは改行を挟まず一行で実行する必要があります。また、下記のJSON構成にはエスケープクォートが必要です。

Redshift_Workload_2

WLM設定を動的に変更する方法として、AWSはスケジュールされたLambda関数あるいはスケジュールされたデータパイプライン(ShellCmd)をお勧めします。

3. ミックスワークロード(ETLとBIワークロード)を継続的にサポートないし最適化するために、キューホッピングを使用する

WLMキューホッピングは、読み取り専用クエリー(BI_USERのクエリー)が、キャンセルされる代わりにあるキューから別のキューに移動することを可能にします。例えば、以下のスクリーンショットにあるように、二つのキュー(一つはタイムアウトが60秒に設定されたインタラクティブクエリー用のもの、もう一つはタイムアウトなしで設定されたバッチクエリー用のもの)を作成し、同じユーザーグループ(BI_USER)をそれぞれのキューに設定します。WLMは、インタラクティブキューで実行され、タイムアウトしたBI_USERのクエリー(のみ)を、バッチキューに自動的に再ルーティングし再実行します。WLM-Picture 2

この例では、ETLワークロードはBIワークロードクエリーを阻害しません。長時間実行されている読み取り専用クエリーは、自動的にバッチとして分類され、より短時間で完了するクエリーをブロックしないようになります。

4. リソースインテンシブなETLやバッチクエリー用に、スロットカウントを一時的に増やす。

Amazon Redshiftはメモリー不足エラーを回避するために中間結果をディスクに書きますが、ディスクI/Oはパフォーマンスを劣化させる要因となります。次のクエリーは、ディスク上で実行されているアクティブクエリーを表示します。

SELECT query, label, is_diskbased FROM svv_query_state WHERE is_diskbased = 't';

クエリーの結果は以下の通りです。

query | label        | is_diskbased
-------+--------------+--------------
1025   | hash tbl=142 |      t

一般的に、ハッシュ、集計、ソートの操作は、システムが十分なメモリーをクエリー処理に割り当てなかった場合、ディスクにデータを書く可能性が高くなります。この問題を回避するには、その処理が使用するクエリースロットの数を一時的に増やすことで、より多くのメモリーを割り当てます。例えば、同時実行レベルが4であるキューは、4つのスロットを持っています。この時、スロットカウントを4に設定すると、単一のクエリーがそのキューの持つ全ての利用可能メモリーを使うことができるようになります。なお、複数のスロットを単一クエリーに割り当てると、同時実行数が消費され、他のクエリーが実行できなくなり得る点に注意して下さい。

以下の例では、クエリーを実行する前にスロットカウントを4にセットし、クエリー完了後、1に戻しています。

 

SQL
set wlm_query_slot_count to 4;
select
	p_brand,
	p_type,
	p_size,
	count(distinct ps_suppkey) as supplier_cnt
from
	partsupp,
	part
where
	p_partkey = ps_partkey
	and p_brand <> 'Brand#21'
	and p_type not like 'LARGE POLISHED%'
	and p_size in (26, 40, 28, 23, 17, 41, 2, 20)
	and ps_suppkey not in (
		select
			s_suppk
                                  from
			supplier
		where
			s_comment like '%Customer%Complaints%'
	)
group by
	p_brand,
	p_type,
	p_size
order by
	supplier_cnt desc,
	p_brand,
	p_type,
	p_size;

set wlm_query_slot_count to 1; -- after query completion, resetting slot count back to 1

注: 上記のTPC データセットクエリーは例示のみを目的としています。

WLMクエリーの例

以下のサンプルクエリーは、お客様がご自身のワークロードに関してお持ちの、以下のような疑問への回答となるかも知れません。

  • 現在のクエリーキュー構成は?クエリースロット数や、それぞれのキューのタイムアウト設定はどうなっているか?
  • いくつのクエリーが実行され、キューに到達し、また現在クエリーキュー上で実行されているか?
  • 我々のワークロードは、各クエリーキュー上で毎時どの程度滞留しているか?負荷に応じて、構成を変更する必要があるか?
  • 我々の既存のWLM構成はどのように動作しているか?どのクエリーキューがビジネス上の要求に対して最適化される必要があるか?

WLMは、内部で定義されたWLM”サービスクラス”に応じて、クエリーキューを構成します。”キュー”と”サービスクラス”の用語は、システムテーブル内でほぼ同義に使われます。

Amazon Redshiftは、WLM構成で定義されたキューと共に、これらのサービスクラスに応じたいくつかの内部キューを作成します。それぞれのサービスクラスは一意のIDを持ちます。サービスクラス1 – 4はシステム用途に予約されています。スーパーユーザーキューはサービスクラス5を使用します。ユーザー定義のキューはサービスクラス6以上を使用します。

クエリー:既存のWLM構成

既存のWLM構成を確認するためには、以下のクエリーを実行します。4つのキューが構成され、それぞれのキューはある数字に割り当てられています。クエリーでは、キュー番号はサービスクラスにマップされ(ETL_USER用の1番目のキューはサービスクラス6にマップされている)、evictableフラグ(*)はfalseに設定されています(クエリータイムアウトが設定されていない)。

*訳者註:evictは“立ち退き”の意で、ここではキューホッピングを意味しています。

SQL
select service_class, num_query_tasks, evictable, eviction_threshold, name
from stv_wlm_service_class_config
where service_class > 5;
Redshift_Workload_4

上記のクエリーは現在のWLM構成についての情報を提供します。このクエリーはLambdaを使用して自動化し、WLMに変更が発生した都度、運用チームに通知を送ることが可能です。

クエリー: キュー状態

キューの状態、各キューに対するメモリー割り当て、および各キューに対して実行されたクエリーをモニタリングするには、以下のクエリーを実行します。このクエリーは、カスタムキューとスーパーユーザーキューについての情報を提供します。

SQL
select config.service_class, config.name
, trim (class.condition) as description
, config.num_query_tasks as slots
, config.max_execution_time as max_time
, state.num_queued_queries queued
, state.num_executing_queries executing
, state.num_executed_queries executed
from
STV_WLM_CLASSIFICATION_CONFIG class,
STV_WLM_SERVICE_CLASS_CONFIG config,
STV_WLM_SERVICE_CLASS_STATE state
where
class.action_service_class = config.service_class
and class.action_service_class = state.service_class
and config.service_class > 5
order by config.service_class;

Redshift_Workload_5

上記の結果からは、サービスクラス9は使用されていないことが伺えます。このことは、デフォルトキューに割り当てるリソース(同時実行数とメモリー)を最小限に押さえることができることを意味します。サービスクラス6(etl_group用)はより多くのクエリーを実行しているため、より多くのメモリーや同時実行数を割り当てることを検討してもよいかも知れません。

クエリー: 前回のクラスター再起動後の状況

前回のクラスター再起動後から現在までに完了または実行中のクエリーの数をサービスクラスごとに確認するには、以下のクエリーを実行します。

SQL
select service_class, num_executing_queries,  num_executed_queries
from stv_wlm_service_class_state
where service_class >5
order by service_class;

Redshift_Workload_6
サービスクラス9は使用されていません。サービスクラス6(etl_group用)は他のサービスクラスより多くのクエリーを実行しています。クエリー処理を高速化するために、このグループ用のメモリーや同時実行数を変更することを検討した方がよいでしょう。

クエリー: 各WLMキューの時間ごとのワークロード

各WLMクエリーキューの時間ごとのワークロードを確認するには、以下のクエリーを実行します。このクエリーを使用して、WLMキューの最適化を行うことが可能です。少なすぎるスロットや多すぎるスロットを含んだキューは、WLMでのキューイングや、未使用のクラスターメモリーに繋がります。このクエリー(wlm_apex_hourly.sql)は、amazon-redshift-utils GitHubレポジトリーからコピーできます。

SQL
WITH
        -- Replace STL_SCAN in generate_dt_series with another table which has > 604800 rows if STL_SCAN does not
        generate_dt_series AS (select sysdate - (n * interval '1 second') as dt from (select row_number() over () as n from stl_scan limit 604800)),
        apex AS (SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
                FROM
                (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
                FROM stl_wlm_query wq
                JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 4)
                JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
                WHERE wq.userid > 1 AND wq.service_class > 4) iq
        GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
        maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                        from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class, apex.num_query_tasks as max_wlm_concurrency, maxes.d as day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;

本ポストの主旨に基づき、結果はサービスクラスごとにブレイクダウンされています。

Redshift_Workload_7

上記の結果からは、サービスクラス6が24時間を通じて、コンスタントに最大8までのスロットを消費していることが伺えます。この数字を見る限り、このサービスクラスへの変更は現時点では特に必要ありません。

Redshift_Workload_8

サービスクラス7は、上記の結果に基づき最適化することが可能です。

二つの点が観察できます。

  • 朝6時から午後3時まで、あるいは午後6時から翌朝6時まで:消費されている最大スロットは3です。これらのアクセスパターンに基づいて、同時実行数とメモリー割り当てをローテーションする余地があります。リソースのローテーションについて詳しくは、本ポストのガイドラインセクションの項を参照して下さい。
  • 午後3時から午後6時まで:この期間にピークの発生が観察されます。この時間帯については、現在の設定のままで構いません。

まとめ

Amazon Redshiftは強力かつ完全に管理されたデータウェアハウスであり、高いパフォーマンスと低いコストの双方をクラウド上でご提供します。WLM機能を用いることで、クラスター上で動作する異なるユーザーとプロセスが、それぞれのパフォーマンスとスループットを最大化するための適切な量のリソースを得られることを担保することができます。

ご質問やご提案がありましたら、以下にコメントを残していただけますと幸いです。

著者について

Suresh_90Suresh AkenaはAWS Professional ServiceのシニアBig Data/ITトランスフォーメーションアーキテクト。SureshはAWSプラットフォームへのマイグレーション、ビッグデータ、分析プロジェクトを含む巨大データストラテジーのリーダーシップをエンタープライズカスタマーに提供し、AWSを使ったデータドリブンアプリケーションの最適化や市場に出るまでにかかる時間の改善を支援しています。余暇には8才と3才の娘達と遊び、映画を楽しんでいます。

(翻訳はプロフェッショナルサービス仲谷が担当しました。原文はこちら


関連記事:Amazon Redshiftのパフォーマンスチューニングテクニック Top 10

Sign up Today – Amazon Aurora with PostgreSQL Compatibility のプレビュー

昨年、Amazon Aurora に PostgreSQL 互換のエンジンをリリースするとアナウンスしました。その際、プライベートプレビューのサインアップを紹介し、申し込んでいただくようご案内しました。

そのリクエストの反応は非常に大きいものでした!お客様は既に Amazon Aurora が高い可用性、堅牢性を提供することを理解し、ご自身の PostgreSQL 9.6 アプリケーションを AWS クラウドで動かすのを楽しみにされていました。

Opening up the Preview
本日、興味をお持ちのすべてのお客様に Amazon Aurora with PostgreSQL Compatibility の プレビューを開放し、こちらからサインアップ可能となります。プレビューは、米国東部(バージニア北部)リージョンで実施され、従来の環境で運用されていたPostgreSQL に比べて、2-3倍の性能を提供します。このプレビューでは、高速で低レイテンシなリードレプリカをすばやく簡単に作成することも可能です。

Amazon RDS Performance Insights もPreview にてご利用可能です
本プレビューには、Amazon RDS Performance Insights も含まれます。このツールを利用することで、各クエリの詳細を含む細かいレベルでデータベース性能を確認することができます。Performance Insight ダッシュボードを通して、データベースの負荷を可視化し、SQL, waits, users, hostsという観点でフィルタリングできます:

Jeff;

原文: Sign up Today – Preview of Amazon Aurora with PostgreSQL Compatibility(翻訳: SA江川)

 

 

Amazon DynamoDB Accelerator(DAX) – Read heavyなワークロード向けインメモリ型キャッシュクラスタ

既にAmazon DynamoDBの事はご存知の方が多いと思います。ご存じのように、必要なだけのテーブルスペース、読み込み容量、書き込み容量に対応できるように拡張されたフルマネージドのNoSQLデータベースです。応答時間は1桁のミリ秒単位で測定され、多くのお客様がadtechIoTゲームメディアオンライン学習、旅行、電子商取引、金融など、さまざまな種類のアプリケーションにDynamoDBを使用しています。一部のお客様では一つのDynamoDBテーブルに100TB以上のデータを格納し、1秒当たり何百万もの読み取りまたは書き込み要求を行います。 Amazonの小売サイトはDynamoDBに依存しており、Black Friday、Cyber​​ Monday、Prime Dayなどの短時間で高強度のイベントに関連するトラフィックの急増に耐えます。

DynamoDBは、あらゆるアプリケーションやワークロードに対して、高速で一貫性のあるパフォーマンスのメリットを提供することができますが、常に改善の余地があります。いくつかのワークロード(ゲームやadtechが代表的な例ですが、他にもたくさんあります)のビジネス価値は、低レイテンシかつ高性能な読み取り処理を行えるデータベースによってもたらされます。できるだけ早くDynamoDBからデータを取得する機能により、クリックスルー率が最も高いゲームや広告の反応が速くなります。

 

Amazon DynamoDB Accelerator

このような重い読み込み処理を必要とする方の為に我々はパブリックプレビューでAmazon DynamoDB Acceleatorをローンチしました。DAXとも呼びます。

DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段(論理的に)に置かれます。Write – throughモードで動作し、DynamoDBとAPI互換を持っています。キャッシュからレスポンスが返る時はマイクロセカンドのレスポンスを実現し、eventually – consistentなread heavyなワークロードに特に向きます。DAXはシームレスかつ簡単に使えます。シンプルにDAXクラスターを作成する事が出来、アプリケーション側に読み書きのエンドポイントのターゲットとしてDAXを指定するだけです。DAXにパッチを当てるオペレーションをしたり、クラスタのマネジメントやレプリケーション、障害について心配することはありません。

DAXクラスタは1~10ノードで構成されます。読み込み処理の量に応じてノードを追加する事が可能です。クラスタでキャッシュ出来るサイズ(working setとも呼ばれる)はベースとなるノードの大きさ(dax.r3.large から dax.r3.8xlargeまで選択出来ます)を選択してクラスタを作成します。クラスタはVPC内に作成されAvailabillty Zones毎に分割してノードを配置出来ます。

利用するにはDAX for Java SDKを必要とします。このSDKは作成したクラスタとlow – level TCPでのやりとりを行う事で低レイテンシかつ高スループットを実現するためにチューニングしてあります。(我々は今後他の言語向けSDKについても速やかに対応する方針です。)

DAX クラスタの作成

それではDAXクラスタをDynamoDB Consoleから作ってみましょう(APIやCLIでの操作も可能です)。マネジメントコンソールのCreate clusterをクリックして始めます。

まず名前と詳細を入力し次にノードタイプを選択します。そして初期のクラスタサイズを設定します。DAXに与えるIAM roleとpollicyとして私のDynamoDBテーブルにアクセス出来る権限を設定します。(必要な権限が設定されている既存の物を指定する事も可能です。)

例としてコンソールではポリシーとして一つのテーブルにアクセス出来る権限を許可します。アクセスするテーブルを追加したくなったらIAMのコンソール上からポリシーを編集する事で可能です。
次にDAXで使われるノードを配置するサブネットグループを作成します。グループ名とどのサブネットを使うか選択します。

デフォルト設定で起動する事を確認したらLaunch clusterをクリックします。

クラスタは数分で起動します。


次に私のアプリケーションをDAX SDKを使うようにしエンドポイントとして私のDAXクラスタのエンドポイントを指定します。(今回ではdax1.seut3.clustercfg.use1.cache.amazonaws.com:8111です)
アプリケーションを起動し実行、Metricsタブを選択するとキャッシュパフォーマンスに関係するメトリクスを見ることが出来ます。
Amazon CloudWatchメトリクスに含まれキャッシュヒットやキャッシュミス、リクエストカウント、エラーカウントなどが見れます。

Alarmsを選択する事でこのメトリクスを利用したCloud Watch Alarmを作る事が出来ます。

例えばキャッシュミスが異常な数になった物を検知する事が出来ます。

Nodesタグを選択する事でクラス内のノードリストを見ることが出来ます。新しいノードを追加したり削除する事が可能です。

DAXがどのように動いているか、DAXのサンプルアプリケーションをインストールして二回実行してみます。初めにDynamoDBにダイレクトアクセスし、キャッシュが無い状態で操作を行います。ベースラインパフォーマンスとしては以下の通りです。

出力内容の途中に処理グループ毎の結果を見ることが可能です。クエリが2.9~11.3ミリ秒で動作しています。二番目にDAXを使ってパフォーマンスにどのような影響があるかを表示します。


まず一回目はキャッシュが無いのでキャッシュミスをしている状態の結果が表示されています。次のサブシーケンスではキャッシュが働き非常に早く処理が行われている事が確認できます。

Thngs to Know

DAXを使ってアプリケーションが書き込みを行う場合に以下の点について注意下さい。

Java API – 先程お伝えしたように、我々がpublic previewとして公開した時にサポートしているのはJava SDKとなります。計画として他の言語のサポートもあります。DAXはDynamoDBとAPIインターフェイスで互換性を持っている為、コード上で独自のキャッシュロジックであったり大きな変更を必要としません。(すなわちロードするライブラリを変更する事でDynamoDBに対するread / write処理は同じコードで動きreadは自動的にキャッシュから取得出来ます。)

Consistency – eventually consistent readsを使用することでin-memory キャッシュからレスポンスを返す事でDAXで最高のパフォーマンスを引き出す事が出来ます。(DAXは強い一貫性の読み込みではDynamoDBに対して常にreadを実行します。すなわちキャシュを使わないという事です。)

Write-Throughs – DAXはwrite-through キャッシュです。ただし、読み込んだ内容と書き込む内容との間に弱い相関関係がある場合は、書き込みを直接DynamoDBに行う事が出来ます。これにより、DAXはあなたの読み込み処理に対してより大きく助けを出来ると思います(書き込みを直接DynamoDBに行う事でキャッシュ生存期間が終わるまでそのキャッシュを利用する事が出来る為、DynamoDBに対する読み込みを軽減出来るという形です。)

Deprovisionig – DAXをあなたの環境で使用する時、基になるテーブルに対する読み込みキャパシティユニットのプロビジョニングを軽減することでコストが大幅に削減する事が出来ます。(多くの場合は劇的に削減出来ます)また、DAXは読み込み処理の急激な伸びに対応する事が出来ます。

Available Now

DAXは本日からpublic previewとしてUS East(北ヴァージニアリージョン)、US West(オレゴンリージョン)、そしてEU(アイルランドリージョン)にて利用申込後に可能です。public previewでは費用は掛かりません。より詳細を知りたい場合はDAX Developer Guideを是非お読み下さい。

Jeff; (翻訳はSA 成田が担当しました。)

翻訳元blog