AWSへWebサーバー移行を検討する際の16のポイント

今までレンタルサーバーや専用サーバー、オンプレ環境を使っていたが、そろそろAWSへ移行を検討しなければいけなくなってきた。このような状況の方は多くいるのではないでしょうか。

しかし、現在AWSには40以上のサービスがあり、今もなお各サービスは進化し続けています。これからAWSのことを調べてみようにもAWSのホームページから把握するには、どこを見たらいいか分かりづらい。。。実際のAWSへの移行作業は自分自身で行わないとしても、外部に委託するためにもある程度は把握しておきたい。

もし、そう感じておられたならAWSへの移行のポイントをしっかり抑えておけば、それほど難しいものではありません。

ここでは実際にお客様へ移行の提案をする際に確認や検討しているポイントをご紹介します。

1. まずは移行の背景を確認しよう

そもそもどうしてAWSへの移行を検討しようと思ったのでしょうか。何か問題があるから、問題はないけれどクラウドで圧倒的なシェアのAWSにしておくのが安心だから、競合もAWSにしているから・・・など、具体的なものからふわっとしたものまでさまざまなケースがあります。

AWSへの移行を検討した事例の背景をいくつかピックアップします。

コスト削減

サーバー導入後、5年間の負荷増加を見据えて性能の良い物理サーバーを購入しているケースを想定してみてください。当初はそれほど性能が必要ないにも関わらず、高価なサーバーを利用していることになります。AWSでは後からサーバーの増減が可能なため、必要なスペックのマシンをその時に必要な分だけ用意することができ、コスト削減につながります。

ハードウェア管理の手間をなくしたい

オンプレで運用しているケースではハードウェア障害は自分たちで対応をしなければいけません。故障が発生してから代替部品を準備して、サーバーの電源を落として修理をする。これを至急データセンターへ向かって行わなければいけません。 AWSでは膨大なサーバーが裏で待機しているので、ユーザーはハードウェアの修理を気にする必要はありません。

性能やディスク容量が不足してきた

専用サーバーやレンタルサーバーを扱っていて一番困ることが、性能不足やディスク容量不足です。基本的に専用サーバーやレンタルサーバーは性能アップを行うことができません。負荷が高くなってきて重くなってきたことを感じたら急いで移行をする、このようなケースは多数あります。 AWSではサーバーを移行することなくスペックアップが可能です。最初は低スペックからはじめて、徐々にスペックアップを行えます。

管理体制の見直し

会社の規模が大きいと、情報システム部門が全てのサーバーを管理していることが多くあります。しかし、基幹システムは情シスが管理するが、コーポレートサイトなどは役割が異なり、管理コストも余分にかかるのでアウトソースするケースが増えてきています。

障害からの復旧を迅速にしたい

物理サーバーを扱うレンタルサーバーや専用サーバー、オンプレでは物理的な障害が発生した場合、すぐに復旧できません。実際の復旧作業は、バックアップデータが存在していることが前提で、サーバーをセットアップしなおし、再度データを投入する必要があります。すぐに対応できる体制があったとしても数時間レベルはかかってしまいます。

AWSではサーバーのイメージを保存しておくことで、別のハードウェア上でサーバーをかんたんに復元することができます。

いくつかAWSへ移行を検討するケースをピックアップしました。あてはまるものはあったでしょうか。

続いて、AWSへの移行を検討する際のチェック項目を挙げていきます。

2. 既存のシステムを把握しよう

移行を検討しているサーバーではどのようなシステムが動作しているでしょうか？ WebサイトやECサイト、業務システム、バッチ処理などどのようなシステムかを把握しておきましょう。また、誰が使うものでどの程度の利用頻度のものかもチェックしておきます。

3. 既存のサーバーを把握しよう

今利用しているサーバーはどのような分類のものでしょうか。

共用レンタルサーバー
専用サーバー
クラウド
自社内においてある物理サーバー
自社データセンターに設置した物理サーバー
自社データセンターに設置したVMware環境

サービスを利用している場合は、ベンダー名やプランも把握しておきます。

4. インフラの構成を把握する

移行対象のサーバーおよび関連サーバーやサービスはどのような構成で動いているでしょうか？複数台の構成であれば構成図があると思いますので確認してみましょう。

サーバーの台数
ファイアウォールの有無
セキュリティサービスの有無
構成図

5. アプリケーションを把握する

既存のシステムの把握と似ていますが、ここではアプリケーションとして利用している具体的なソフトウェアを確認します。例としていくつか挙げておきます。

ホームページ用CMS「WordPress」「MovableType」
ECサイト構築用パッケージ「EC-cube」
独自開発システム

6. ミドルウェアの確認

現在のサーバーで動作しているミドルウェアを確認します。移行後の環境では同一のバージョンを利用できないこともあるため、マイナーバージョンまで確認しておくことが重要です。

Apache
MySQL
PHP
postfix など

そして、現在AWSで利用可能なOSとその上で動作するミドルウェアのバージョンの差異を確認しておきます。大幅にバージョンが異なっている場合は、システムの改修が必要となる可能性があります。

ここまでは既存のサーバーについて確認をしてきました。

ここからはAWSのどのサービスを利用すべきかを検討していきます。

7. 仮想サーバー EC2の利用を検討

AWSで利用するサーバーといえばEC2（Amazon Elastic Compute Cloud）を通常は指します。一見、検討の余地がないようですが、もし既存のシステムがホームページで、しかもWordPressを利用しない静的コンテンツのみであればS3(Amazon Simple Storage Service)の採用も候補になります。

サービス	説明
EC2	LinuxやWindowsが動作する仮想サーバー。プログラムを動作させることができる。
S3	ストレージサービス。プログラムは動作しないが、HTMLや画像ファイルを置いてWebに公開することができる。

S3はアクセス集中があってもほぼサーバーダウンが発生せず、障害にも強いサービスです。プログラムが動作していないWebサイトであれば検討してみる価値は十分あります。

8. データベース RDSの利用を検討

移行対象のシステムがデータベースを利用している場合は、RDS（Amazon Relational Database Service）を検討しましょう。RDSは利用者がOSの管理をする必要がないデータベースサービスです。セットアップ済みのデータベースアカウントが提供され、OSには一切触れることができない、というのが分かりやすいでしょうか。

もともとDBが独立している場合はRDSへ移行することで管理コストを抑えることができます。DBサーバーが独立していなかった場合も、より堅牢にしたい場合はDBだけRDSに移行してしまうことも検討しておきます。

9. DBサーバー冗長化の検討

AWSではデータベースの冗長化構成（マルチAZ構成）を設定のみで実現できます。冗長化構成にしておけば、万が一、一台のDBに障害が発生したとしても自動的にフェイルオーバーし、システムの稼働を継続することができます。

10. DNS Route53の検討

移行対象がWebサイトの場合、DNSが必ず必要になります。下記のいずれかのパターンにあてはまるので、現状を確認しておきます。

お名前.comなどドメイン取得サービスに付属しているDNSを利用している
Route53などのDNS専用サービスを利用している
DNSサーバーを自前で準備している
WebサーバーにBINDなどのDNSを同居させている

DNSの管理コストを抑えたい場合は、Route53のようなDNSサーバーサービスを検討しましょう。Route53はSLA100%の超安定DNSです。費用も約100円/月・ホストゾーンという体系で安価な価格設定です。

11. ロードバランサ ELBによる冗長化の検討

移行対象がWebサーバーの場合、負荷対策や障害対策でWebサーバーを複数台に分けることを検討します。もし、冗長化を行いたい場合は、ELB(Elastic Load Balancing)というサービスを利用することで簡単な設定でロードバランサを利用することができます。

AWS Elastic Load Balancing公式ページ

12. 国外データセンター併用の検討

AWSでは世界中にデータセンターがあり、ユーザーは用途に合わせて自由にデータセンターの場所(リージョン)を選ぶことができます。日本国内の利用者が対象のサーバーであれば、東京リージョンを選択します。以下のようなケースでは国外データセンターを併用することも検討すると良いでしょう。

海外の利用者も多く、東京にサーバーを用意するだけではネットワーク遅延が大きい
災害対策のため、東京リージョンだけでなく海外のデータセンターも利用したい(ディザスタリカバリ)

13. ディスク種別、容量の検討

サーバーのディスク種別として、HDDやSSDが選択できます。速度を追求したい場合の選択肢もありますので、用途に応じて選択します。また、どの程度のディスク容量を必要とするかを検討します。ディスクは後から追加可能ですので、無駄に増やしてスタートする必要はありません。

14. データ転送量の検討

AWSではデータ転送は従量課金です。現在のシステムがどの程度のデータ転送を行っているかを確認しておきましょう。レンタルサーバーなどでは転送量が確認できないことも多いのですが、その場合はアクセス数から算出してみます。

参考までに、Webサイトのアクセス数からデータ転送量を試算してみます。実際には、ユーザー環境によりキャッシュが効いたりしますので、上限値と考えて算出すると良いでしょう。

トップページのデータ量    ： 2MB
トップページ月間アクセス数 ： 1万PV
第2階層の平均データ量   ： 1MB
第2階層月間アクセス数   ： 25万PV

月間転送量 (2MB*1万PV+1MB*25万PV)/1024 = 264GB

15. バックアップの検討

AWSではサーバーのイメージを丸ごとS3へ保管しておくことができます。サーバー本体とは別の場所に保管ができるので、万が一の障害や誤操作でも影響を受けません。通常は1日1回3世代程度を保管し続ければ良いでしょう。

その他、独自のバックアップがあれば従来と同様にバックアップを取得し、S3へ転送するなどすれば安心です。どの程度の容量が必要かを確認しておきましょう。

16. 料金の確認

今までの15項目が確認できいれば、AWSへの移行可否およびどのような構成にしたいかが見えてきていると思います。最後にどの程度の費用がかかるかを試算しておきましょう。

費用については下記に詳細をまとめています。

Web担当者向け、AWSでWeb構築する際の見積もり5パターン

まとめ

今回はAWSへ移行したいというニーズがある前提で、チェックポイントをまとめてみました。各項目の詳細調査はエンジニアでないと難しいと思いますが、やり取りをする上でポイントを把握しておくとコミュニケーションがスムーズに進みます。

通常、安定稼働しているシステムを、わざわざコストをかけて移行することはありません。何かトラブルや今後を見据えて課題があるからAWSへの移行を検討しようとしているはずです。AWSを使えば様々な構成が組むことができますし、リッチな構成も組めます。しかし、本来の移行の目的を忘れてしまっては本末転倒です。

最小限のコストで多くのメリットを得られる移行プロジェクトを進めていきましょう。