[クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す!〜]

既存システムをAWSに載せ替える【第6回】

2017年5月22日(月)清野 剛史(クラスメソッドAWS事業部ソリューションアーキテクト)

前回までで、AWS(Amazon Web Services)上でWebサイトやECサイトなどを効果的に構築するためのポイントは、つかめたかと思う。ただクラウドに関する弊社への問い合わせでは「新しいシステムをAWSで構築したい」というものと並び「現行システムをAWSに載せ替えたい」というものが非常に多い。今回はオンプレミスに構築・運用しているシステムをAWSに移行する際のポイントについて考える。

 サーバー資産を自社で管理することを「オンプレミス」と呼ぶ。文字通りサーバーそのものを1から10までシステム管理者が“お世話”する形である。経営側からのITに対する期待値や、成長に伴うシステム拡大に対応していくには、物理的・精神的な負担が非常に大きい。これまでも物理資産を外部のデータセンターに置き管理を委託することで、温度管理など物理的な“お世話”からは解放されてきたが、昨今はクラウドに移行しインフラ管理の負担を減らすことで本来のシステム構築にリソースを集中したいという企業が急増している。

現行システムはできるだけ止めたくはない

 ただ、そうした企業には共通の悩みがある。「現在、稼働しているシステムを具体的に、どのようにクラウドに移行するのか」である。システム管理者にすれば「何年も運用し安定して動いているシステムに手を付けたくない」というのは共通する思いだろう。結果、「システムをできるだけ止めずにクラウドに移すには」「今の、この仕組みはクラウドでは、どのサービスに置き換わるのか」「データ移行はどうするのか」などの課題が、すぐに浮かんでくる。

 セキュリティの課題もある。今ではクラウドに対する誤解も解け「とにかくセキュリティが心配」という声は少なくなってきたが、「万一設定を間違えてセキュリティ的に穴が空いてしまったら」「最重要なデータは手元で管理しないと監査的に困る」など、システム移行を実際に決断するまでには様々なハードルがある。

 一方で、マネージメントサイドからすれば「どうせクラウドで管理するのであれば、コストやリソースなどクラウドのメリットを十分に享受できるよう“クラウド仕様”にしたい」という期待がある。とはいえ現行システムをアーキテクチャーから変更するには、中身について事前に、かつ慎重に洗い出さなければならない。「なんとなく動いている」システムについても、前任者からの引継漏れはないかを含め、その仕様の理由を改めて把握する必要がある。

 オンプレミスからクラウドへの移行には、(1)単純移行=クラウド上にサーバーを立て、中身をまるごと移す、(2)置き換え=クラウド上で提供されているサービスに置き換える、(3)作り変え=クラウド上のSaaS(Software as a Service)として動くようにプログラムを作り変える、などのレベルがある。

 当然、外部APIとの連携や管理上、どうしても移行できないシステムもある。クラウドに移行するといっても「すべての資産をネットワークの向こう側に置かなければならない」というものではない。移行できないものはオンプレミスに残し、クラウドとネットワークで結ぶことでクラウドとオンプレそれぞれのメリットを利用する「ハイブリッド」という形もある。

 大事なことは、移行の「目的」を明確にし、それについて、どこまでリソースを割けるのかを検討したうえで、既存システムに、どこまで手を加えるのかの判断だ。実際には、フェーズを分けながら移行し、その後にアーキテクチャーを徐々に作り変えるというパターンも少なくない。現行システムの移行においては、通常業務と並行して準備を含めこなさなければならないからだ。以下では、クラウドへの移行に伴うポイントを順を追って説明する。

小規模サイトでも移行時にはロードバランサーを使う

 最初の移行対象になるのは、外部公開サイトやポータルサイトなどである。最も単純な移行方法としては、現在動いているサーバーをそのままイメージ化し、AWS上に「EC2」を立ち上げて、そのイメージを展開することだ。OSレベルから、そのままコピーしているだけなので、ほとんどの場合、プログラム上にIPアドレスが固定で設定されていないかさえチェックすれば動作する。

図1:「ロードバランサーの使用」と「スケーリング」がサイト移行のポイント図1:「ロードバランサーの使用」と「スケーリング」がサイト移行のポイント
拡大画像表示

 サイト移行でのポイントは「ロードバランサーの使用」と「スケーリング」だ。これら2つの対策が打たれているだけで、だいぶ「クラウドらしさ」がでてくる(図1)。

 まずロードバランサーについては、AWSでは、たとえサーバーが1台だとしても手前にロードバランサーを置くのが良い。オンプレミスの小規模なシステムではロードバランサーなどは使わず、そのままサーバーを公開している場合が多いのではないだろうか。だがAWSの「ELB」「ALB」というロードバランサーのサービスを手前に置いておくことでサーバー側の自由度が格段に高まる。

 例えばシステムをアップデートしたい場合、動いているEC2をコピーして手元でステージングとしてプログラムをアップデートし、テストによる確認が取れればELB/ALBにつなげて古いEC2を取り外す。これで、サービスを停止することなくシステムをアップデートできる。このようにサーバー資産を手軽に調達できるところがクラウドのメリットだ。ロードバランサーを使うことで、そのメリットを充分に活用したい。

 現行システムをSSL化していない場合は、クラウドへの移行の機会にSSL化を検討してみよう。サーバーに直接証明書をインストールしてSSL化するにはミドルウェアの設定を含め準備・計画が必要になる。だがこれも、ELB/ALBがあることで簡単になる。ELB/ALBへの証明書のインストールにはウィザードが用意されているからだ。管理者は、それに従って秘密鍵や証明書、中間証明書をコピー&ペーストするだけで、サーバーには一切手をつけずにサイト全体をSSL化できる。

 さらにELB/ALBへのSSL用証明書であれば、AWSの「ACM」という無料のSSL証明書サービスを使える。追加コストなしにSSL化が完成するのだから使わない手はないだろう。

バックナンバー
クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す!〜一覧へ
関連記事

Special

-PR-

既存システムをAWSに載せ替える【第6回】前回までで、AWS(Amazon Web Services)上でWebサイトやECサイトなどを効果的に構築するためのポイントは、つかめたかと思う。ただクラウドに関する弊社への問い合わせでは「新しいシステムをAWSで構築したい」というものと並び「現行システムをAWSに載せ替えたい」というものが非常に多い。今回はオンプレミスに構築・運用しているシステムをAWSに移行する際のポイントについて考える。

PAGE TOP