「AWSへのDCマイグレーションストラテジー」講演メモ (AWS Summit Tokyo 2015) #AWSSummit

メモった。間違い等あるかもしれませんが、その場合はごめんなさい。

何を移行するのか

  • 一部システムがAWSに向かないため移行検討が進まない
    • All or Nothingではない
    • 大多数のエンタープライズはハイブリッド型
    • 移行対象は選定が必要
  • AWS技術制約確認
    • 物理機器(USBドングル、プリンター、テープ装置、物理ストレージ装置)
    • 共有ディスク
    • ネットワーク
    • 未対応OS(RHEL4以前、Windows2000以前、AIXなど
    • ミドルウェア・パッケージ
    • 性能(CPU36コア、メモリ244GBを上回るサーバ)
  • 業務要件確認
  • コスト・移行合理性確認

どのように移行するのか

  • セキュリティポリシー
  • オンプレミスシステムとの結合度
  • ランニングコスト、移行コストを算出し、ROIを試算
  • コスト比較だけではなくAWSを使うメリットを再確認
  • 移行後のアーキテクチャ
  • 移行計画の検討
    • RTO(目標復旧時間)、RPO(目標復旧地点)は?
    • 現行環境の構成は?
    • 現行環境は目標サービスレベルを達成しているか?
    • 目標サービスレベルは本当に必要か?
  • クラウド移行時のアーキテクチャパターン
    • Rehost, Refactor, Revise, Rebuild, Replace
  • 既存のマネージドサービスすべてで使われている機能を、AWSのマネージドサービスで実現できるとは限らない
    • RDS(データサイズがRDSの最大容量を超える、DBパラメータを細かくチューニングしたい)

移行後どのように運用するのか

  • 運用変更項目の洗い出し
  • 役割分担の整理
    • AWSの権限管理
  • ガバナンス方針
    • コスト管理
    • セキュリティチェック

ケース:社内標準ガイドライン作成

  • サービスレベル・インフラ・運用の標準を定義
  • 標準ガイドラインを作成
    • サービス時間、可用性、バックアップ、災害対策、拡張性
  • サービスレベル毎にインフラ構成を定義
    • 標準インフラ構成ごとにCloudFormationテンプレートを作成

AWSへの移行方式

  • サーバの移行
    • サーバ再構築+アプリ導入(既存のオンプレミスな環境での移行イメージと同様)
    • 仮想マシンのインポート(VM ImportでOSイメージを丸ごと移行可能)
  • データの移行
    • ファイル単位、ブロックデバイス単位、ミドルウェアの機能を利用

VM ImportによるOS変更点

  • OS起動、ネットワーク接続等、AWS上で稼働するための最低限の変更が加えられる
  • CentOS 6.6での例
    • ブートローダー関連(ttyS0追加)
    • ネットワーク関連(内部DNS参照、DHCPによる取得)
    • ファイルシステム群(UUID追加)

VM Importのこれまでの課題

  • 転送に時間がかかる
  • 失敗した場合、ファイル転送からやり直し
  • 複数ボリュームの仮想マシンが移行できない
  • 同時にImporできる数が少ない

新しいVM Import API

  • EC2インスタンスを作るのではなく、AMIを作るようなイメージ
  • イメージ転送と、IMport処理を分離
  • S3にあるイメージを起点としてAMI/EBSスナップショット作成を実行
  • OVA形式への対応

オンプレミスからAWSへ接続

  • 接続方法
    • Internet
    • Internet VPN
    • DX(Public)
    • DX(Private)

※ Direct Connectを使う場合、S3はVPC外にあるため、Public経由か、Privateであれば要Proxy

  • 移行時のダウンタイムをいかに短くするか
    • データ同期までの時間がシステムのダウンタイムに直結
    • 帯域を有効に使いきれる方式を取る

ファイルの移行方式

  • S3へ
    • 専用線接続を利用する
    • 大きいファイルはマルチパートアップロード
    • 並列で転送
  • EC2へ
    • ソリューションを活用(WAN高速化ソリューションを使う)

ブロックデバイスの移行

  • S3
    • VM Importを利用
    • AWS Storage Gateway
  • EC2
    • DRBD
    • DataKeeper

ミドルウェア機能を利用したデータ移行

  • バックアップ・リストア
    • 一般的に移行時間は長くなるが、十分なダウンタイムが取れる場合に利用
  • 各ミドルウェアのレプリケーション機能
    • Active Directoryなど
  • レプリケーション専用ソフトウェア
    • ライセンスが必要になるケースがある(Oracle GoldenGateなど)

データ移行時間を考慮したシステム切り替え方式の選択

  • 一括移行
  • 一括移行+差分同期
    • バックアップを使ってある断面でのシステム移行を行い、切り替え時に差分を同期
  • 並行稼働による段階的移行
    • データを同期しながら利用ユーザを徐々に移す

データ移行方式のポイント

  • 十分なネットワーク帯域を用意
  • 帯域を有効に使える移行方式を選択
  • ミドルウェアレベルでの機能が使えるか検討
  • ダウンタイムを考慮して方式を検討




まとめ


クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)