この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事では、AWS re:Invent 2019で実施されたビルダーズセッション「ANT412 "Modernize your data warehouse with Amazon Redshift"」の内容をレポートします。
セッション情報
概要
日本語訳：
オンプレミスのデータウェアハウスをクラウドに移行するのは複雑だと思われがちですが、必ずしもそうである必要はありません。このビルダーセッションでは、要件を正しく収集するために必要な手順について説明します。また、AWS Database Migration Service(AWS DMS)、AWS Snowball、AWS Snowmobileなど、Amazon Redshiftへのデータ移行を支援するAWSサービスも紹介します。その後、参加者のニーズに基づいて、対象とするユースケースを検討します。ノートパソコンを持参してください。
原文：
Migrating an on-premises data warehouse to the cloud is often perceived as complex, but it doesn't have to be. In this builders session, we go over the steps you should take to correctly collect your requirements. We also cover AWS services that can assist you in migrating your data to Amazon Redshift, such as AWS Database Migration Service (AWS DMS), AWS Snowball, and AWS Snowmobile. We then dive into targeted use cases based on the needs of the participants in the room. Please bring your laptop.
進行役
- Hunter Grider(Database Engineer, AWS)
セッションレポート
「ビルダーズセッション」とは？
ビルダーズセッションとは、一言で表すと、60分間の小規模なグループセッションです。
AWSのエキスパートが座るテーブルに6人程の参加者が座ります。まず、AWSのエキスパートが、参加者に対し議題に関する簡単な説明またはデモンストレーションを行います。説明が終わったら、ラップトップを使って実験やビルドを行う、という形で進めます。
詳細は下記AWS re:Inventのページに記載されています。
Builders sessions are back at re:Invent this year by popular demand. These are 60-minute small group sessions with up to six customers and one AWS expert, who is there to help, answer questions, and provide guidance. It’s just you, your laptop, and the AWS expert.
Each builders session begins with a short explanation or demonstration of what you are going to build. There won’t be any formal presentation. Once the demonstration is complete, you will use your laptop to experiment and build with the AWS expert.
Breakout Content | AWS re:Invent
会場に入ると、グループセッション用のテーブルが目に入ります。AWSエキスパートが使用する表示用画面や模造紙がそれぞれのテーブルごとに準備されています。
参加者は、予約時に予めテーブル番号を示されるので、そのテーブル番号毎のレーンで待ちます。
セッション前半：DWHの近代化、移行の進め方
セッションは全体で1時間でしたが、前半の約20分がHunter氏によるDWHの近代化、移行の進め方の説明でした。
教訓を学ぶ
正確な要件の範囲を把握する
- 未知の要件があると仮定する
- 欲求(ウォンツ)とニーズを分離する
- どのようなタイプのアプリケーションを移行しようとしているのか理解する
計画を立てる
- マイルストーンを事前に理解して計画する
- スコープの忍び込み(後でそっと要件が追加される)を防ぐ
- 欲求(ウォンツ)とニーズを分離する
- 利用可能なツールを把握する
- POC(概念実証)を実施する
適切なサービスを選択する
- 自分自身が"正しい質問"をしているか確認する
- 本来セットで威力を発揮するサービスの部分的な導入を回避する
- 早期に(サービスの専門家に)支援を求める
関連AWSサービスの紹介
移行サービス
- AWS Snowファミリー(Snowball, Snowmobile)
- (移行したいデータ量に応じて)複数の選択肢がある
- 最大ではエクサバイト(ペタバイトの1000倍)サイズまでスケールできる
- AWS Database Migration Service(DMS)
- ソースおよびターゲットに多数のデータベースやサービスが選択できる
- 継続的なデータ変換(CDC)が使用できる
- AWS Schema Conversion Tool(SCT)
- スキーマ変換を自動で行える
- ワークロード認定フレームワーク(WQF)が使用できる
- WQFについては、こちらをご参照ください
セッション後半：オープンディスカッション
セッション後半40分は、オープンディスカッションと称し、テーブルに着いたみんなで今抱えている課題を共有し、解決法を一緒に考える、という形式で進みました。
英語力あまりないので、下記はとりあえず私が理解できた&同席者からのヒアリングによるものです。実際にはもっと多くのトピックで議論されました。
Snowファミリーを使うベストプラクティス
- Snowmファミリーはオンプレにある大量データの一括移行に向いている
- 移行後、(並行稼動のために)継続的なデータの同期が必要な場合は、DMSを併用する
SQL ServerからRedshiftへの移行があるか
- SQL Server一台でOLTP(日常の業務処理)とOLAP(データ分析)を一緒に担当している場合がある
- SQL ServerからOLAPの部分をRedshiftに移行させて業務上の役割、負荷を分担させる
- SQL ServerとRedshiftのデータ同期はバッチが基本
- 間を空けたくなければ更新データをチャンク(小さな塊)にまとめ、頻度の高いバッチ処理としてRedshiftに転送させる
DMSで移行できないものがあるという話
- OracleやSQL Serverにはインデックスがあるが、これがRedshift移行時に無視される
- 元々Redshiftにはインデックスが無いので仕方ない
- 他には、データベースユーザの情報もDMSで移行されなかった
- 結局ユーザは手作業で移行先に再作成した
機械データの扱い
- 機械が吐き出すデータは、データ取得ミスによる空白や不正値などのノイズが含まれる
- データをそのままRedshiftに入れるのは危険
- 一度(EMRなど)外部の仕組みでクレンジングする必要がある
クラスタサイズの話
- 移行時に開発環境と本番環境を異なるインスタンスサイズにすることは有り得る
- 注意点は、機能は同じものが利用できるが、負荷に対する能力が異なるということ
- CPU使用率が高くても(70〜80%程度)であれば、別にクラスタサイズを上げる必要はないと考える
- むしろリソースがよく使われていて価格対費用の効率が良いと考える
まとめ
今回始めてビルダーズセッションに参加しましたが、国外のエンジニア達の視点、経験を得られる良い機会でした。
このような双方向コミュニケーションを行うセッションは、会場に来てこそ体験できるものなので、AWS re:Inventに参加するならば少なくとも一度は体験しておくことをお薦めします。
3
