【レポート】クラウドへシステムをマイグレーションするときの整理指針 #AWSSummit

こんにちは、青柳＠福岡オフィスです。

AWS Summit Osaka 2019 のセッションレポートをお送りします。

セッション情報

• セッションタイトル
• クラウドへシステムをマイグレーションするときの整理指針

• スピーカー (敬称略)
• アマゾン ウェブ サービス ジャパン株式会社 Product Marketing エバンジェリスト　亀田 治伸 氏

• セッション概要

システムをクラウドへ移行させる際、何を考えておく必要があるのでしょうか。このセッションでは、クラウド移行の方針決定の際にあらかじめ知っておいていただきたいこと、整理が必要なこと、についてお伝えします。

レポート

Microsoft製品のクラウド移行

• オンプレミスからクラウドへの移行動向
  • 世界のクラウド市場は2025年までに1.25兆ドルに到達
  • その中で、多くのお客様がMicrosoftのサーバー製品を利用

Windowsアプリケーションの移行にまつわるよくある課題・検討事項

• 古いバージョンのサーバー製品、データベース製品は移行可能か？
  • AWSでの稼働実績： Windows Server 2003 R2、Windows Server 2008、SQL Server 2008、、、など
• 多岐にわたるMS製品が問題なく稼働するか？
  • ファイルサーバー、認証基盤(AD/ADFS)、.NETアプリケーション、ISVソフトウェア製品、SQL Server、Exchange Server、SharePoint Server、など
• 既存ライセンスが有効活用できるか
  • ライセンスモビリティ、BYOLなど、追加投資を最小限に抑える方法

責任共有モデル

• クラウドコンピューティングは従来の「物を持つIT」とは違う
  • クラウドベンダー(AWS)とユーザーがそれぞれ責任を受け持つ
• AWSの責任範囲
  • 施設、物理サーバー、物理ネットワーク、物理層セキュリティ、SSL暗号化、物理ボリューム暗号化
  • 各種認証を取得 (SOX、PCI-DSSなど)
• お客様の責任範囲
  • 仮想ネットワークのセキュリティ： ルーティング、セキュリティグループ
  • 仮想ボリュームの暗号化
  • OSのセキュリティ： 更新プログラム管理、Windowsファイアウォール
  • ミドルウェアのセキュリティ： IISセキュリティ

移行にあたって決めなくてはいけないこと

• 1: What？ 対象システムは？
• 2: Why？ 移行理由は
• 3: How？ 移行戦略は？
• 4: Where？ 移行先は？
• 5: When？ 期限は？
• 6: Who？ 担当者は？

1: What？ 対象システムは？

• 移行の費用効果と移行難易度は正比例する
• いきなりミッションクリティカルなシステムを移行するのはおすすめしない
  • ステークホルダーが少ないシステム、停止時のビジネス損失が少ないシステムから移行
• 自分たちで行う場合： どれだけ自社内でできるのかの見極め
  • 最初は外注で行い、慣れたら自社で行うようにする等の検討

2: Why？ 移行理由は

• インフラレイヤー抽象化の効果
  • 従来型オンプレミスによるITインフラ： 優先度の高い業務30％、付帯的なIT管理業務70％
  • クラウド活用によるITインフラ： 優先度の高い業務70％、クラウドの管理業務30％
  • エンジニアが優先度の高い業務に時間を割くことができるようになる
• クラウド移行による「コスト削減」
  • 単純なコスト削減という考え方では、達成が難しい
  • 経営側のコスト削減の思惑によって、現場のエンジニアのモチベーションが下がる場合もある

3: How？ 移行戦略は？

6つの移行戦略

• Re-Host (ホスト変更)
  • サーバーやアプリをそのままEC2に持ってくる
• Re-Platform (プラットフォーム変更)
  • Re-Hostに加え、移設のタイミングでプラットフォームの更新・バージョンアップを行う
• Re-Purchase (買い替え)
  • クラウドに対応したライセンスやアプリケーションに買い替える
    (例： Oracleからライセンス込みのRDS for Oracleに買い替える)
  • 移行対象規模が大きければ大きいほど、ライセンス持ち込みの方が安くなる
  • そうでない場合は、AWSのライセンスを使う方が良い
• Refactor (書き換え)
  • クラウド環境で最適に動作するようにアプリを書き換える
    (例： 商用DBからAurora等のOSSベースDBに変更)
• Retire (廃止)
  • 平行運用していた古いシステムをDB/アプリごとこのタイミングで廃止する
    (例： 部門毎に持っていたデータをクラウドに統合し、不要となったDBサーバーを廃止)
• Retain (保持)
  • オンプレミス環境を引き続き使用する
    (例1： 古いバージョンのOSやライブラリに依存していてアップグレードできないパッケージアプリがある)
    (例2： セキュリティ面や可用性の条件、あるいは「上層部の説得」などが障壁となりクラウドに移行できない)

• ※「Retain(保持)戦略」で留意すべきこと
  • 古い技術を学習するエンジニアは時間と共に減ってくるため、あまり塩漬けにしすぎると移行不能となる事態もある

• 6つの移行戦略を移行の複雑さとコスト効率で比較
  • Retain ＜ Retire ＜ Re-Host ＜ Re-Purchase ＜ Re-Platform ＜ Refactor
    (右に行くほど移行は複雑となるが、コスト効率は高まる)
  • まず最初に「Re-Host」を検討するのがオススメ
    いったんクラウドに持って行ってから、他の移行戦略を検討すればよい

4: Where？ 移行先は？

EC2

• EC2の特徴
  • Windows、Linuxなど、OS別のマシンイメージが用意されている
  • AWSが提供するベースOSイメージを基に、独自のイメージを作成することも可能
  • インスタンスを1つずつ作成することも、複数台をまとめて作成することも可能
  • 必要な時にインスタンスを作成し、不要になったら終了する
• EC2の代表的なOSとサポートバージョン
  • Windows： Windows Server 2003～2019がサポートされる
    • Windows ServerのOS単体イメージの他、SQL Serverバンドルイメージも選択可能
      (Amazon Linux2＋SQL Serverのバンドルイメージもあり)
  • Linux： Amazon Linux 2、Red Hat Enterprise Linux、CentOSなど
• EC2のインスタンスファミリー： 種類とユースケースにより選択
  • 汎用 (Mシリーズ、Tシリーズ)
  • コンピューティング最適化 (Cシリーズ)
  • メモリ最適化 (Rシリーズ、Xシリーズ、z1d)
  • ストレージ最適化 (Hシリーズ、Iシリーズ、Dシリーズ)
  • ベアメタル (i3.metal、m5.metal、r5.metalなど)
• 汎用インスタンスについて
  • Mシリーズは本番用途、Tシリーズは検証用途に向いている
• EC2のテナンシーについて
  • 共有、専用、Dedicated Hostがある
  • 専用とDedicated Hostの違い
    • Dedicated Host： CPUソケットや物理コアが管理可能 (ライセンスの制約に対応するために用意、BYOLを可能に)
• EC2への移行(＝Re-Host)の次に検討するのはマネージドサービス
  • マネージドサービスの利点： 運用負荷の軽減
  • マネージドサービスの欠点： OS層にアクセスできない

VPC

• VPCの特徴
  • お客様専用のプライベートアドレス空間を構築
  • 社内ネットワークとインターネットVPNや閉域網で接続も可能
• VPCに関するリソース
  • VPC： ネットワーク空間を作成
  • サブネット： パブリックorプライベートを選択
  • ルートテーブル： 経路を決定する
  • セキュリティグループ： 仮想ファイアウォール

RDS

• RDSの特徴
  • RDBの構築・運用を簡単にする
  • 簡単に高可用性・高性能を実現
    • Multi-AZ、リードレプリカ、スケールアップ、プロビジョンドIOPS
• DBの移行
  • EC2上でDBを稼働させる
  • RDSへ移行する： アプリの対応が必要となる場合もある
• SQL Serverアップグレードツール
  • EC2で稼働するSQL Server 2008を自動的に2016へアップグレードするツール

ストレージ

• ストレージ形式について
  • 従来： ブロックストレージ（EBS)、オブジェクトストレージ(S3)から選択
  • 共有ファイルストレージの登場： FSx for Windows File Server、Elastic File System (EFS)
  • 今まではオンプレの共有ストレージ(NFS)からEBSやS3への移行が必要だったが、今後は共有ストレージへそのまま移行できる

移行支援サービス

サーバー移行支援のサービス

• Server Migration Service (SMS)
  • VMwareからイメージを抽出してイメージ(AMI)化、AMIからEC2を作成する
  • 差分移行もサポート (サーバー本体はオンプレのまま、バックアップのみAWSへ移行など)
• CloudEndure Migration
  • オンプレサーバーのブロックストレージを抽出し、AWS上へ直接移行する

データベース移行支援のサービス

• Database Migration Service (DMS)
  • 同種、異種のDBの移行が可能
  • 移行中もアプリケーション稼働が可能 (最小限のダウンタイム)
  • スキーマの変換(Schema Conversion Tool)： 大部分を自動変換することができる、残りは手動で移行

感想

移行に際して検討課題が多いと考えられる「WindowsサーバーからAWSへの移行」「データベースの移行」を中心に、移行の選択肢やポイントが分かり易く解説されたセッションでした。

また、「6つの移行戦略」のそれぞれの違いについても、非常に興味を持ちました。場面に応じて選定ができるようにしたいと思います。