(レポート) ISM304: OracleからAmazonRDS MySQLまたはAmazon Auroraへの移行:Gullup社の事例

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。オペ部の半瀬です。

はじめに

今回もAWS re:Invent 2015 のセッションレポートです。
コチラでレベルごとのセッション一覧をひっぱれます。)

今回はOracleからAmazonRDSデータベースへの移行例、またその際にMySQLと Auroraについての特徴と利点などを比較下セッションです。

タイトルと目次

タイトル:(ISM304) Oracle to Amazon RDS MySQL & Aurora: How Gallup Made the Move
(弊社訳:OracleからAmazonRDS MySQLまたはAmazon Auroraへの移行:Gullup社の事例)
目次:
 ・Gullup社の紹介
 ・当初の課題
 ・なぜAWSだったか?
 ・データベース以外の事情についての考察
 ・RDS MySQLの利点と課題
 ・移行後のアーキテクチャ
 ・DevOps
 ・Amazon RDSとAmazon Aurora
 ・まとめ

Gullup社の紹介

(※ 以下、スライドの要約)

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-3-1024

(割愛します。詳細はこちら

当初の課題

本セッションにおける問題。オンプレで抱えるよくある問題たち

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-4-1024

本セッションにおいては具体的に下記のようなもの。
 ・スケーラブルな調査分析プラットフォームを準備したい
 ・コストは最適化されている必要がある
 ・分析のための豊富なキャパシティ
 ・高可用性(24x7 HA)
 ・レプリケーション
 ・複数リージョンでのデータ分離・隔離
 ・簡便な管理方法

なぜAWSだったか?

AWSの採用理由について。おおきく5つの理由から

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-5-1024 ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-6-1024

1. コスト最適化
 ※ 従来のモデルでは。。
  ・ソフトウェアライセンスコストが前払いで発生
  ・ハードウェア投資の発生
  ・ハードウェアとデータベースの二重管理の負担

2. 複数リージョンのサポート
 ・Patriot Act(米国愛国者法): 取り扱う情報(世論統計など)の性質から準拠する必要がある(?)。すみません、背景は勉強不足です。とにかく複数リージョンでデータを抱える必要性の一つということですね。
 ・国境を超えたデータ転送

3. 高可用性
 ・レプリケーション

4. スケーラビリティ
 ・ピークロード、スパイクに対応可能となるAutoScaling
 ・分析処理による負荷
  ・バッチの実処理時間によるもの
   ・継続的な負荷とはならない

5. 豊富なマネージドシステム体系
 ・RDS, EMR, Redshift, S3, KMS ... etc.

データベース以外の事情についての考察

クラウド移行にあたって、データの処理操作以外で考察すべき要件。大きく、「プロセス」と「テクニカル」要素について

プロセス

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-7-1024

1. オンプレミス
 ・固定されたプロセスの存在
 ・10年にわたって最適化されてきたものがある
 ・伴って受け継がれてきた運用管理の負荷

2. クラウド
 ・新しいプロセスへの切り替え
 ・新しいツールセットへの切り替え
 ・文化を変える(データを自社設備におくものではない、という考え方)
 ・データ隔離

3. データマイグレーション
 ・VPC とpublic
 ・帯域(自社ネットワークからVPNを経由したVPCへのアクセス
 ・セキュアなデータ移行を実現する必要がある
 ・暗号化
  ・データベース
  ・ETL(Extract , Transform , Load)

テクニカル

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-9-1024 ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-10-1024

1. リソースの変化=スキルセットのギャップが発生
 ・MySQLのプロシージャや関数の経験が必要となる
 ・AWSのスキルセット
  ・サービスレイヤのマインドセット(http,web,...etc)
 ・Oracleのスキルは軽便なものでよくなる(?)
  ・結果として、多くの欠乏と特化が発生(?)

2. データマイグレーション
 ・データ同期の要件
  ・オンプレミスとクラウドの比較
  ・自動化 - 構築費と購入費
 ・Amazon RDS reporting repository
 ・Data lake
  ・S3のデータ貯蔵性(統合性とグローバル)
  ・アドホックなカスタムデータ作成や分析処理
  ・クロスドメインでのデータ分析を容易にする
 ・AWSに関する留意点
  ・SQS: 「いわゆるqueueではない」こと
  ・S3: 結果整合性(Eventual Consistency)
  ・各種AWSサービスにレイテンシとパフォーマンスがあること

RDS MySQLの利点と課題

Oracleから載せ替えをする上でのRDS MySQLについての考察

RDS MySQLを使用することで得られる恩恵

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-11-1024

・リレーショナルDB(Oracle代替としての)
・コスト効率がよく、管理が簡単
・スケーラブル
 ・リサイズがシームレスに可能
・読み込み用DBインスタンス
 ・スケーラビリティ
  ※ 大多数が読み込みとなる(レポートのため)
 ・一時的な要求となる
・レプリケーションとHA
 ※ マルチregion, KMS , ... etc
・セキュリティと暗号化

データ移行時の課題

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-13-1024 ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-14-1024

1. データベース
 ・プロシージャ内のカーソルパラメータ
 ・動的SQL: 即時性がもとめられる
 ・デバッグとログ保管
 ・動的SQLに伴うカーソル宣言
 ・Global temporary table
 ・FROM条件内のサブクエリ
 これらの機能移行

2. データインテグレーション
 ・HTTPエンドポイント(SNS)
 ・メール通知能力
 ・S3への統合
 ・SQSへの統合(enqueue/dequeue)

移行後のアーキテクチャ

構成について。

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-15-1024

移行後の構成

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-16-1024 ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-17-1024

1. RDS MySQL
 ・現データのレポート
 ・広範囲で使用されるストアドルーティンやプロシージャ

2. RDS++
 ・DBプロシージャとのAWS側での統合
 ・XMLベースの定義
 ・Javaアプリケーション

3. レポート用の構成
 ・Tomcat/Java
  ・VPC / EC2 / ELB / AutoScaling

4. データ用の構成
 ・Tomcat/Java
  ・ETL / SWS(AWS?) / S3 / SQS / AWS java SDK / RDS++Host

5. 分散コンテクストのマネジメント
 ・ElastiCache

6. データ収集
 ・SQS / S3
 ・ETL / S3 : 既存オンプレミス環境で処理された統計データ

7. オンプレ環境の構成
・Tomcat/Java
  ・ETL / S3 / CLI (VPN経由でVPCにアクセス)
  ・共有ディレクトリにOracleからエクスポート

MySQL移行時に必要となったワークアラウンド

(※スライド割愛します。19から22枚目まで)
・変数のスコープ
 ・ストアドプロシージャ間で共有するセッション変数
・動的SQLのカーソル
 ・一時テーブルを作成する
 ・一時テーブルに移した動的SQLを実行

移行後のMySQL

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-23-1024

・400以上のプロシージャ(初期フェーズ)
・200以上のテーブルとビュー(初期フェーズ)
・オンプレミスからの統計データをサポート
・レポート機能をサポート
・Amazon RDS++
 ・SQS / S3 / SNS / SES をMySQLからサポート
 ・一部のプロシージャを統合

DevOps

・GitHub
 ・オンプレ環境で使用(VPN経由)
・Jenkins
 ・Javaのデプロイ
・DBコード(プロシージャ)デプロイ
・Ec2とChef
 ・AutoScalingに対応
 ・Stress Environment(?) (プロダクション環境のクローン)  ・デプロイの自動化
  ・マルチリージョンに対応
・S3を中継したデプロイステップ
ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-25-1024
 1. オンプレ:Jenkins - チェックアウト
 2. jenkins - warファイルをビルドし、適切なバケットにデプロイ
 3. jenkins - QA-EC2(図を参照)にてスクリプトを実行し、ファイルsync
 4. PROD-EC2 にデプロイを実行(スクリプト)
 5. AutoScaling - AutoScalingで追加されるインスタンスは以下の手順を踏む
  ・インスタンス作成
   ・インストールとデプロイ
    ・warファイルをS3からsync
     ・完了後、ELBに追加

Amazon RDSとAmazon Aurora

Auroraの採用にあたって

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-26-1024

・早期採用
・読み込みインスタンス増大と遅延時間の短縮
・レプリケーションとHA
・将来的なAWSコンポーネントとの統合性
・将来的なDevOpsツールの拡充。特にデータベースのデプロイにおいて
・暗号化  ★ ロールアウトのためには、この機能拡充を待っている

まとめ

本セッションのまとめ

ism304-oracle-to-amazon-rds-mysql-aurora-how-gallup-made-the-move-27-1024

1. AWSは将来にわたって私たちにフィットしている
 ・コスト効率性に対して
 ・スケーラビリティ対して
 ・挑戦的で全体的なビジネスニーズの発生に対して

2. RDS MySQLとAurora
 ・コスト効率の良いOracle代替となる。クラウド上において。特にアプリケーション面、パフォーマンス面でのスケール性によって
 ・Auroraに関しては、将来的なAWSコンポーネントとの統合性も期待できる

さいごに

OracleからAWS RDSへの移行例を紹介するセッションでした。
移行によって何を実現したいか、それをどのようにして構成に落とし込んだか、さらには移行にあたっての留意点や課題となった点について、スライドにわかりやすくまとめられていて、勉強になりました。
オンプレ環境からのAWS移行を検討するにあたって参考となるセッションかと思います。

それではー。