実体験に基づくAWSへのシステム移行時のあれこれ・雑感

本格的な夏の始まりと共に、プール開き当日に6時間水遊びを楽しんだ結果、毎年恒例の日焼けによる肌の強烈なヒリヒリ感に苦しんでいる、MMM代表の国本です。

昨年よりAmazon Web Services(AWS)へのシステム移行(AWSマイグレーション)に関して、お問い合わせ・ご相談頂く機会が増加傾向にあります。

「100超のシステムを移行」三菱東京UFJがAWS活用策明かす で、MUFJがAWSへの移行を決断された事が大きく取り上げられたこともあり、このような大きな動きに追従する形で業種・システム種別を問わず、AWSへの移行をご検討されている企業が増えたというのが背景にあると見ています。

我々MMMは、AWSへの移行をソリューションとして提供し、これまで多くのシステムをAWSへ移行しており、これまでの実体験をベースにAWSへのシステム移行時に検討すべき事項や、よくご相談・ご質問いただく内容について、雑感として書いてみようと思います。

1．AWS移行でよくご相談いただくシステムの種別

AWSは多くのマネージドサービスが存在し、非常に裾野が広い(and 深い)クラウドサービスであり、ビジネス業種・形態を問わず移行可能ですが、よくご相談いただくシステムは下記のとおりです。

Webサービス・モバイルアプリ(のバックエンド)

コンシューマー/ビジネスユースのWebサービスやEコマース(ECサイト)、またモバイルアプリケーション向けのバックエンドサービス(API)など、Webやモバイルアプリそのものでビジネスを提供しているサービス。

多くは現状、オンプレミス(自社保有設備)やハウジング、またはレンタルサーバー上で稼働しているというケースです。

企業のいわゆる「情報系」

ファイルサーバーやグループウェア、スケジュール管理、ActiveDirectory(AD)など、社内外とのコミュニケーション機能がメインで、企業のビジネス活動を間接的に支援するような情報系と呼ばれるシステム群。

多くは現状、オンプレミス(自社保有設備)やハウジング、レンタルサーバーなどで稼働しています。

企業の「基幹・業務系」

ERPや生産/販売管理/受発注システムなど、ビジネス活動のベースとなり、非常に高い可用性や冗長性が求められ、OracleやSAP、JP1など商用ソフトウェアプロダクトが多数投入されているシステム。

多くは現状、オンプレミス(自社保有設備)やハウジングで稼働しています。

2．AWS移行検討に至る経緯・背景

AWS移行を検討されている企業毎に様々な経緯や背景は存在するものの、概ね下記3つに集約できます。

運用コストを削減したい

オンプレミス(自社)で運用しているサーバーやストレージ機器は、通常一定期間(3年や5年)の保守サービスと共に購入され、契約保守の期限切れに併せて、保守会社から機器のリプレースを打診されるため、そのタイミングでコストを抑えるためにAWSへの移行を検討される。というケースが多くあります。

このように最初は『コスト削減』というキーワードでAWS移行のご検討を開始されるというケースが現状では一番多いように実感しています。

顧客先・上層部からの移行要請

次に多いケースとして『サービス提供先の顧客からインフラをAWSへ移行したいという要請が来た』『上司からAWSクラウドへの移行検討を指示された』などの「外的要因での移行検討」もかなり存在します。

大規模なシステムから小規模サービスまで、AWSへのシステム移行事例は昨今、枚挙にいとまがなく、そのような事例をWebや雑誌で見て「是非とも我が社も！」と考えられるようなケースです。

ビジネススピードに追従できる俊敏性・柔軟性を得たい

AWSへのシステム移行の本質的な価値は、デジタルビジネスに必須となる「俊敏性(アジリティ)」「柔軟性(フレキシビリティ)」「拡張性(スケーラビリティ)」を得られるという点だとMMMでは捉えています。

ビジネススピードに追従できるような俊敏性、柔軟性や拡張性を得たいという理由で、AWSを選択されるという企業は、現時点ではそこまで多くはないように感じていますが、最終的にはこのようなクラウドの本質的な価値を得たいという理由に至ると考えます。

3．AWS移行検討時によくいただくご質問

AWSのサービスが多すぎて、何を使ったらよいかわからない

AWSが提供するクラウドサービスが数多く、移行時に具体的にどのサービスを採用し、システムを構成したら良いのか難しい。といった声をよく聞きます。

我々MMMでは、現行システムを単純にEC2などの仮想サーバーにそのまま置き換えるだけではなく、移行対象となるシステムについて入念にアセスメントを実施し、AWSクラウドのメリットを十二分に享受できる形でクラウド志向のアーキテクチャをご提案しています。

AWSで商用ソフトウェアライセンスの見積りがわからない

AWSへ移行した場合に、現在導入している商用ソフトウェアのライセンス形態に変更があるのか？という点ですが、我々MMMでは、ソフトウェアプロダクトの開発元ベンダーもしくは公式な販売代理店と連携し、AWS上での稼働における公式なサポート状況、及び推奨される構成を調査した上で、ライセンス含めたお見積を提示しています。

AWSへのデータ移行をどう進めたらよいか

現システムのダウンタイムを抑えて移行を進めたいが、具体的にどのような手順を踏めばよいのか？という点について、我々MMMでは、AWSが提供しているDatabase Migration Service(DMS)などを活用したデータ移行を初め、ダウンタイムを最小化できる移行を設計し、移行の具体的な手順をご提示した上で、リハーサルを実施しています。

AWSの月額利用料の見積りができない

従量課金とはいえ社内稟議で必要になるので、大体の月額利用料金は把握したいが、見積りはどのように行えばよいのか？という質問もよく受けますが。

我々MMMでは、移行対象システムを事前にアセスメントした上で、見込みベースのネットワークトラフィック含めて、必要なAWSリソースを「月額利用想定額」という形で提示しています。

AWSに移行後の監視をどうすればよいか

システムの運用監視はどのように構成したら良いのか？また費用はどの程度発生するのか？という点も多く質問を受けますが、我々MMMではAWSへの移行前に運用監視のご要件をヒアリングし、DatadogというSaaS型のモニタリングサービスを用いて、監視サーバーを別途準備せず、24時間365日の監視サービスを提供しております。

また、オンプレミスでご利用されている監視サービスをそのまま踏襲したいという場合も、オンプレミスとAWSとのネットワーク設計含めてサポートしています。

4．AWSへの移行におけるポイント

システムの全面移行は新規構築と比較し、考慮すべき点が多数あり、比較的難易度が高いプロジェクトとなりますが、加えてAWSへの移行の場合、クラウドならではの検討すべきポイントを忘れてはなりません。

AWSの旨味を活かすクラウドアーキテクチャを検討する

以前、 オンプレミス(自社運用)環境をクラウドへ移行するときにありがちな失敗パターン でも書きましたが、オンプレミスの設計方式をそのままAWSに持ち込み、適用することが運用上好ましくないケースも存在し、場合によってはインフラのみならずアプリケーションレイヤーまで含めて最適化したほうが良いという場合もあります。

よって、事前に移行対象のシステム構成をアセスメントし、AWSへ移行した後にクラウドの良さを享受できるアーキテクチャを入念に設計することが重要となります。

AWSの特徴をうまく活かしてコストを圧縮する

こちらも、 オンプレミス(自社運用)環境をクラウドへ移行するときにありがちな失敗パターン で以前書きましたが、オンプレミスのように数年先を見越した形で極度にオーバースペックなサイジングを行うと、コストが跳ね上がってしまいます。

よって、AWSクラウドの弾性を上手く活かし、サービス稼働に必要な最小限のスペックでの構成配備や、従量課金を活かして開発・検証環境を営業時間のみ稼働させる仕組みを作りなど、AWSの月額利用料を最適化してコストを圧縮することがポイントです。

移行元システムとAWS間のデータ同期の仕組み作り

AWSへの移行時に対象システムを長期間サービス全停止できるレアなケースを除き、ビジネスの機会損失を抑えるために、移行時にはシステムのダウンタイムは最小化することが求められる場合がほとんどだと思います。

リレーショナル・データベースに格納されているデータはもちろん、日々システム上で更新される画像やテキストベースなどの静的ファイル群も含め、差分で日々データを移行先となるAWSに同期できるような仕組みづくりを設計し実装することが、移行時のダウンタイムを最小化するためには必須となります。

AWSの進化に追従できる運用・保守体制の整備

AWSはクラウドサービスの中でも特に進化が早く、顧客の声に答えるべく新しいサービスや機能改良が、かなりのハイペースで実施されていきます。

よってオンプレミスのような前提で、システムを一度開発・構築後、塩漬けで何年もひたすら放置するという形ではなく、日々クラウドの真価をキャッチアップし、自社のビジネスに貪欲に取り入れていける運用・保守体制を整備する覚悟が必要となります。

5．AWS移行のざっくりとしたステップ

MMMでは、AWSへのシステム移行について、下記のようなフローで進めています。

STEP1．AWS移行のビジネスゴールを定義

最初期のフェーズとしてAWSへ移行する具体的な目的と達成したいビジネスゴールを明確に定義します。

AWS移行検討に至る経緯・背景は企業によりそれぞれ異なり、運用コストの削減、ビジネスの俊敏性向上、セキュリティ・拡張性の強化、災害対策の実現など、AWS移行において実現したいゴールを明確に定義することで、最適と考えられるアプローチを行います。

特に 2．AWS移行検討に至る経緯・背景 外部要因による移行検討の場合、顧客や上層部の考えているゴールと、担当者レベルでのゴールに対する認識が乖離しているケースもあり、このビジネスゴールをプロジェクト関係者間で正確に把握・共有することがプロジェクトを成功へ導く前提条件だと考えています。

STEP2．移行対象システムのアセスメント

移行を検討しているシステムに対するアセスメントとして

• システムアーキテクチャ
• データ量(DBや静的ファイル含め)
• 利用ユーザ数
• システム開発及び運用フロー
• システムに関係する部署・ベンダー
• バックアップ・リストア状況
• 連携システム有無
• パフォーマンス要件
• 求められるサービスレベル(SLA)

を対象に、構成や現状の関係部署を含めた開発・運用フローを洗い出し、AWSへの移行時に改善・検討が必要と考えられるポイントを可視化・提案します。

STEP3．移行計画とAWS上のアーキテクチャ立案

STEP2の事前アセスメントの結果をベースに、具体的なAWSへのシステム移行計画と、AWSに適したクラウドアーキテクチャを提案いたします。

この際、インフラ見直しはもちろん、必要と考えられる場合はアプリケーションレイヤーや移行後の開発フローの仕組み作りまで含めた総合的な提案を行うことで、移行後のシステム運用コスト削減と、AWSクラウドならではの俊敏性を享受できるよう努めます。

また、移行までの対象システムデータ同期方式や、切替時に発生するダウンタイムなど、移行時に運用側でサポートが必要なアクションも認識合わせを行いながら、最終的な移行計画としてまとめていきます。

STEP4．AWS移行後の運用・保守要件の定義

移行計画が立案された段階で、AWSへの移行後のシステム運用・保守のついて定義していきます。

AWSへ移行後、どこまでを自社運用として、どこからを運用会社へ委託されるか、また、求められるサービス運用レベルに準じた監視や運用体制の整備をキッチリとこの段階で合意しておくことで、システム運用後も、AWSのサービス進化に追従し、ビジネスメリットを享受できる運用体制を確立することが狙いです。

STEP5．AWS移行の開始

具体的に立案されたAWSへの移行計画そして移行後の運用・保守に準じて、AWSへの移行作業を両社が協力し進めていきます。

雑感まとめ

AWSへのシステム移行は、実現したいビジネスゴールに向けて、クラウドならではのメリットと特徴を十分に把握・理解した上で、AWSへの移行後の運用まで踏まえた形で、慎重にプロジェクトを進める必要があります。

我々MMMは、AWSへのシステム移行をお考えのお客様に対して、単なるサーバー移行ではなく、その先にある ビジネス価値の最大化をフルサポートするAWS移行ソリューション を提供しておりますので、AWSへの移行をご検討されている方は、お気軽に MMMにご相談 下さいませ。

ではでは╭( ･ㅂ･)و ̑̑

kuni