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

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

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

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

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

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

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

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

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

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

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

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

　サイト移行でのポイントは「ロードバランサーの使用」と「スケーリング」だ。これら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化が完成するのだから使わない手はないだろう。

サーバー内にデータは置かない

　スケーリングに対しては、偶数台のサーバーを各AvailabilityZone（AZ）に配置しておきたい。これにより、上に説明したようなサービスのアップデートのほかにも負荷対策や、何らかの不具合でサーバーが止まってしまった時のための可用性を確保する。このとき、気をつけるべきは「サーバー内にデータはないか」という点である。

　オンプレミスでサーバーを1台構成で運用している場合、ディスクの思わぬ所に設定ファイルやデータファイルなどが置かれているケースが多い。クラウドにけるサーバーは、「いざとなったら、どんどん捨てるもの」である。この意識を持って、データは「S3」や「EFS」に移動しパスを設定しておこう。現状の形をなるべく崩さないようにするのであれば、S3よりも業界標準のPOSIXに準拠しているEFSが良いだろう。

　データがサーバー内にないことを確認したら、AutoScalingにするか、手動でサーバーを設置するかを決める。AutoScalingはサーバーの故障時や負荷に合わせて自動でスケーリングしてくれるので運用的にはとても便利だ。ただし、これはクラウドならではの仕組みなので、慣れないうちは閾（しきい）値の設定などで戸惑うことも多い。それほどアクセス数に増減がないのであれば、手動でEC2を配置するほうが使い勝手が良い。現状のアクセス分析の結果から判断したい。

移行時のシステム停止が認められるかどうかで
データの移行方法は変わる

　次に考えるべきはデータベースなどに保管されているデータの移行である。小規模なシステムでは、1台のサーバー内にデータベースを置いてあることも多いが、データは企業にとっての生命線であるだけに、マネージドサービスの「RDS」の使用を強くお薦めする。データ移行のポイントは「サービスは無停止かどうか」だ。現状のオンプレサービスを止めて良いのか、止めずに移行するのかで、その方法は大きく変わる（図2）。

　「移行期間」としてサービスを止められるなら、最も単純な方法は現状のデータベースから、データとスキーマをEXPORTし、RDS上に立てた新しいDBにIMPORTすることである。RDBMS（リレーショナルデータベース管理システム）のそれぞれにEXPORT／IMPORTのコマンドがあるので、それを利用する。ただしデータベースのバージョンには注意が必要だ。オンプレミス側のDBMSのバージョンは意外と古いことがある。新しいバージョンのDBに移行する際にはデータ型やSQL構文などの動作チェックが不可欠である。

　一方、ギリギリまでサービスを止めない場合、その移行方法にはいくつかの方法がある。1つは、移行開始時のデータを「初期データ」と位置づけ、移行後に「初期データ」の最終データから移行から現在までに変更されたデータを「差分データ」として上書きする方法だ。データを蓄積していく形のシステムであれば問題は起きにくいが、UPDATE／DELETEなど既存データが頻繁に変更されるシステムの場合はREDOログの確認などに手間がかかることも多い。

　2つめは、RDS上のデータベースに対しレプリケーションを実行し、データが同期できたことを確認してからRDS側のデータベースをマスターに昇格させる方法である。この方法ならデータのずれは起こりにくい。ただしオンプレミスとRDSの両方をネットワークで結ばなければならないため、それらの設定に準備が必要になる。

　無停止のデータ移行で最も簡単なのは「DMS（Data Migration Service）」というAWSのデータ移行サービスを利用することだ。DMSはデータのレプリケーションとデータの同期を簡単に低コストで実行するサービスである。Oracle同士、MySQL同士など同一DBMS間のマイグレーションだけではなく、OracleからMySQLなど異なるDBMS間の移行にも対応している。クラウドへの移行を機にデータベースを変更してみたいという管理者はテストしてみてはどうだろう。

　特にオンプレミスでMySQLを使用している場合、規模によっては「Aurora」への移行を検討してみても良いかもしれない。AuroraはAWSに特化したデータベースサービスである。ベースはMySQLだが、最大5倍のスループットを持ち、データ容量が自動で拡張される。コストの最適化には有効だが、インスタンスサイズが「t2系（クレジットベースのインスタンス）」と「r3系（メモリーを重要視したインスタンス）」しかないので、要件に合うかどうかは良く考える必要がある。