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

2015.10.25

この記事は公開されてから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移行を検討するにあたって参考となるセッションかと思います。

それではー。