Oracle/SQL Serverの AWS への移行～その選択肢と注意事項～

（株）インサイトテクノロジー宮地 敬史

Agenda

1. AWSのデータベース移行先～EC2 or RDS？～2. データベースの乗換え3. 弊社サービスの紹介

AWSのデータベース移行先～EC2 or RDS？～

Database on EC2

物理サーバがAWS EC2インスタンスになるだけ。

⇒ EC2上にRDBインストール、データベース作成を行う

- 監視・通知・監査の仕組み- 運用（バックアップ/リストア、メンテナンス等）- 環境構築用/運用スクリプト

今使っている運用回りの仕組みを(ほぼ)そのまま使用できる

セルフマネージが可能

- データベースのバージョン・エディション- 適用するパッチ、適用タイミング- サーバリソースのDBへの割り当て

DB on instance

Amazon EC2

Amazon RDS

マネージド型リレーショナルデータベースOSやRDBをインストールすることなくすぐに利用できる

管理が簡単AWSマネジメントコンソール、AWS RDS CLI、AWS RDS APIを使用

拡張性ダウンタイムなしでリソース追加可能*ストレージサイズ/IOPSの場合のみ(CPU/Memoryは再起動が必要)

可用性Multi-AZでの可用性担保

特徴

AmazonRDS

初期化パラメータがある程度最適化されている

パッチ適用も簡単に実施可能

Oracle DB instance

バックアップ自動バックアップ/DBスナップショット

Amazon RDS

固定パブリックIPアドレスを使用できない

再起動/Failover時に何らかの対処が必要になる場合あり

SSH(SCP)接続ができない既存の仕組みでSSHやSCPで直接接続している場合は要注意

注意点

パッチ適用必須パッチはAmazonの指定期間内に適用する必要がある

データベースへの接続にはエンドポイント名を使用する

Oracle Database

Oracle on EC2 AWS RDS for Oracle

バージョン/エディション

11.2.0.1 – 12.1.0.2Personal Edition使用可

11.2.0.4 – 12.1.0.2Personal Edition使用不可

DBパラメータ設定 全て設定可能 一部設定不可

管理系コマンド - 一部コマンドが異なる(次頁参照)

Oracle*NET 詳細設定可能(listener.ora,sqlnet.ora)

詳細設定不可

Oracle RAC 構成可能 構成不可

DataGuard 最大保護モード最大可用性モード最大パフォーマンスモード

構成不可 ただし、Multi-AZで最大保護モード同等＋自動Failoverの動作

その他機能 全て使用可能 一部使用不可(次頁参照)

EC2 vs RDS

Oracle Database

RDSだと変わる管理系コマンド

システム管理 制限セッションの有効化と無効化

共有プールのフラッシュ

バッファキャッシュのフラッシュ

セッションの切断

セッションの強制終了

グローバル名の変更

非マスターユーザーへの権限の付与

DBMS_SCHEDULER ジョブの変更

ログ管理 オンラインログファイルを切り替える

オンライン再実行ログの追加、削除、サイズ変更

強制ログ作成の設定

アーカイブされた再実行ログの保持

サプリメンタルロギング作成の設定

Oracle Database

データベース管理 表領域とデータファイルの作成およびサイズ変更

デフォルト表領域/一時票領域の設定

データベースのチェックポイント機能

その他 分散復旧の設定（バージョン 11.2.0.3.v1 以降の場合）

SYS オブジェクトへの SELECT または EXECUTE 権限の付与

データベースタイムゾーンの設定

自動ワークロードリポジトリ（AWR）の使用

VPC の DB インスタンスで使用するデータベースリンクの調整

主要なデータストレージ領域での新しいディレクトリの作成

オンライン再実行ログの追加、削除、サイズ変更

DB インスタンスディレクトリのファイルの一覧表示と読取り

RDSだと変わる管理系コマンド

Oracle Database

RDSでは使用できない機能使用できない機能

Oracle 11g Real Application Clusters (RAC)

Real Application Testing

Data Guard/Active Data Guard

Oracle Enterprise Manager Grid Control

Automatic Storage Management

Database Vault

Streams

Java のサポート

Locator

Oracle Label Security

Spatial

Oracle XML DB Protocol Server

Oracle Database

RDSでは使用できない機能使用できない機能

Oracle 12c Real Application Clusters(RAC)

Automatic Storage Management

DataGuard/Active DataGuard

Database Vault

Javaサポート

Locator

マルチテナントデータベース

DBMS_SCHEDULER ジョブの変更

今後の機能拡張で対応されることがある為、対応機能については、都度確認してください。

まとめ

以下が譲れない場合は、Oracle on EC2を選択、許容できる場合は、AWS RDS for Oracleも検討しましょう。

必要になるCPU/メモリ/Diskが足りない Oracle RACの使用 Oracle Active DataGuardの使用 RDSでは使えない機能(OracleJVM等)の使用 データベースバージョン、パッチレベルを細かく管理したい パッチ適用時のサービス断（多くて数カ月に1回） どうしてもサーバから管理したい 既存の監視・運用の仕組みを変えたくない

SQLServer

SQLServer on EC2 AWS RDS for SQLServer

バージョン/エディション

SQLServer2008以降は全て(SQLServer2005も可能)

SQLServer2008R2 SP1/SP3SQLServer2012 RTM/SP2/SP3SQLServer2014 SP1 ※SEのみ

Always on 構成可能 構成不可

Log Shipping 構成可能 構成不可

ストレージ容量拡張 サポート サポートされない

EC2 vs RDS

まとめ

以下が譲れない場合は、SQLServer on EC2を選択、許容できる場合は、AWS RDS for SQLServerも検討しましょう。

Always onの使用 Log Shippingの使用 RDSでは使えない機能の使用 SQLServer2014以降で、EEの機能を使用したい データベースバージョン、パッチレベルを細かく管理したい パッチ適用時のサービス断（多くて数カ月に1回） どうしてもサーバから管理したい 既存の監視・運用の仕組みを変えたくない

まとめ

AWS RDSのいいところ

自動パッチ適用(OS/RDB) ⇒ 必須パッチ以外はスルーも可 バックアップ・リストアが簡単に行える

⇒ 自動バックアップ＋DBsnapshot DR(DisasterRecovery)構成が簡単に行える リソース追加が簡単にオンラインで行える

データベースの種類の変更？

なぜ変更する？

要件に見合った機能・性能

新しいDBにチャレンジしてみたい

コスト・・・（運用コスト/ライセンスコスト）

OLTP？ BI/DWH？

スケールアウトする？

データベース変更時の注意事項

データ型

テーブルの命名規則

・テーブル名の長さの上限はデータベースごとに異なる・指定できる文字種が異なる・デフォルトで大文字/小文字が異なる

取り扱える値の範囲が異なる為、正しくマッピングしてあげる必要がある。

Oracle : NUMBER、MySQL/PostgreSQL : INTEGER/NUMERIC

取り扱える値の精度が異なる ⇒ 処理の結果が変わってしまうことも・・・

Oracle : date、MySQL : date/datetime、PostgreSQL : date

Oracle : timestamp、MySQL : timestamp、PostgreSQL : timestamp

データベース変更時の注意事項

対応オブジェクト

一部のデータベースでは存在しないオブジェクトタイプがある

Oracle / PostgreSQLにはシーケンスはあるが、MySQLにはない

Oracleにはシノニムはあるが、MySQL/PostgreSQLにはない

SQL文の書き方

外部ジョイン ⇒ Oracleのみ、(+)でも書ける

特定範囲の行の抽出 ⇒ Oracleにはlimit句はない

できるだけ、ANSI標準SQLを使いましょう

組み込み関数

そもそも存在しない関数、同じ名前だが引数が異なる関数もある

データベース変更時の注意事項

プロシージャ

基本構文自体が異なる為、改修が必要となる。

運用・保守

データベースバックアップ

定期的に行うメンテナンス処理（統計情報取得、vacuum等）

データベース変更時の注意事項

オブジェクト関連の移行

データの移行

AWS DMS

これらを使うことで、データベース移行のコストを”比較的”削減できます。

AWS Schema Conversion Tool

まとめ

どのデータベースに乗り換えるとしても、「期間と予算があれば」乗換自体は可能。

向いている処理

Amazon Aurora データサイズが大きいシステム大量の並列処理（OLTP/バッチ）

Amazon RedShift 巨大なデータセットOLAP, BI（集計・分析）複雑なSQLだが同時実行数が少ない

PostgreSQL OLTP処理

MySQL OLTP処理※スケールアウトに限界を感じたら、Auroraへ

やろうとしている処理に向いていないデータベースは選択しない。

AWS 移行コンサルティングサービス

AWSへのデータベース移行コンサルティングサービスを開始

インサイトテクノロジーでは、停止することが困難なデータベースの移行に対してレプリケーションテクノロジーを適用したミニマムダウンタイム移行を実現させてきました。実績のあるデータベース移行の知見と経験を基に急成長を続けるAWSへのデータベース移行のコンサルティングサービスを開始致します。

■ コンサルティングサービス内容

AWS RDS及び AWS EC2上に構築したデータベースへの移行アセスメント

ミニマムダウンタイムデータ移行コンサルティング

AWS移行トライアルプログラム

サービス適用対応者AWSへのデータベース移行を検討されている企業様

対象社数先着５社

移行対象データベースOracle / SQLServer

コンサルティングサービス内容 AWSへのデータベース移行アセスメント データベース移行時の問題点や問題の難易度、移行にかかる時間、コストを見

積もり、レポートとして提示致します。 AWSの利用費用を一部負担します。

2ヶ月間、最大$1,000をインサイトテクノロジーが提供致します。(利用期限:2016年12月末)

お申し込みはこちら: http://www.insight-tec.com/service/db-consulting.html

記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。

Copyright 2016 Insight Technology, Inc. All Rights Reserved.