COLUMN誰でもわかる！お役立ちコラム

AWS活用支援コラム

AWS移行の成功のポイント

ITシステムをAWS（Amazon Web Services）に移行する企業は近年増えてきています。一方で、ITシステムのAWSなどへのクラウド移行は、時に失敗することもあります。クラウド移行プロジェクトを成功させるためには、どのようなことに気を付ければいいのでしょうか。具体的に記載していきます。

AWS採用の目的を明確化する

まずは、AWS採用の目的を明確にしておきましょう。AWSは様々な機能があり、多種多様のITシステムの移行先として適していますが、なんとなく、AWSをに移行したい、といった温度感でAWSへの移行プロジェクトを立ち上げてしまうと、社内調整で上長への説明がしにくいだけでなく、移行プロジェクトがとん挫することにもつながりかねません。

移行プロジェクトには検証や移行作業の推進において、多少なりとも時間とコストを要します。プロジェクトがとん挫することで、このようなコストが無駄になってしまっては元も子もありません。
では、どのように目的を明確化していけばいいのでしょうか。

一般論として、AWSはITシステム開発におけるQCD（Quality、Cost、Delivery）を大幅に改善することができます。まずはQCDにフォーカスした、社内のITシステム開発・運用における課題を整理するところから始めてみるといいでしょう。課題を明確にしておくことで、AWS移行に向けた目的や達成すべき成果を明確に定めることができます。次に、定めた目的を経営者や経営層にもきちんと説明し、共有しましょう。また、ITシステムを利用するエンドユーザーやその責任者とのへの連絡や説明も必要です。

古いシステムでも安心して移行できるスタイルズのAWS導入・移行サービスはこちら→

あるべき「アーキテクチャ」の設計

オンプレミスからクラウドへの移行には、主に以下の４つの方式があります。

  • リフト、リホスト
  • リプラットフォーム
  • 再購入
  • リファクタリング

このうち、リフト、リホストはシステムの構成やアプリケーションをそのままにしながら、クラウド上へ移行する方式で、もっとも簡単な移行方式となります。しかしながら、この方法ではOSのパッチ適用やログ監視といった運用はそのまま残り、クラウドの価値を100%は享受できません。

クラウドのメリットを生かすためには、リプラットフォームやリファクタリングといった、いわゆる『クラウドネイティブ』のアーキテクチャを採用してくと、十分にクラウドのメリットを享受することができます。十分なノウハウがないうちはリフト・リホストでも問題ありませんが、最終的なゴールはリプラットフォームやリファクタリングを設定してください。

事前にチェックすべきAWSの制約事項

AWSへの移行に向けて、事前に確認しておくべき制約事項を記載します。

製品の制約

オンプレミス環境で利用している製品によっては、AWS上で利用できなかったり、ライセンス体系が変更になったり、ということがあります。例えば、AWSでは共有ディスク構成がとれないので、共有ディスクを利用するクラスタリングソフト等をそのまま利用することができません。このように、利用しているソフトウェアやライセンス体系を事前にチェックして、同様の機能のAWS における実現方法を検討しておくことは非常に重要です。

機能・性能の制約

移行対象のシステムにおいて、AWS側で具備していない機能・性能が要件となっていないかを確認しましょう。例えば。EV-SSL証明書という、最上級に厳格なSSL証明書はAWSにおいては利用できません。また、既存の固定IPを再利用する、といったこともAWSでは実現できません。このような要素は、システム移行プロジェクトに大きな影響を与えかねないため、ベンダーやAWSの個別相談会なども利用して十分に確認するといいでしょう。

ユーザーに関する制約

ITシステムを利用するエンドユーザーによっては、AWSなどのクラウドにデータを置きたくない、といった要望があるユーザーも存在します。例えば金融系のデータは直接管理できるデータセンターにおいておきたい、といったセキュリティポリシーを持つ金融機関も存在します。ユーザーの要望によりAWSを採用できない、といった場合もあるので、事前に確認しておくといいでしょう。

どんなシステムならコストメリットが出せるのか？

AWSへの移行において、構築コストは一様にかかってしまいますが、構築後の運用コストは大きな差が出ることがあります、運用コストを下げるには、マネージドサービスを使ったりサーバレスサービスを活用したり、といったケースが考えられます。マネージドサービスやサーバレスサービスは、SaaSのように大部分の運用をAWSが行うため、運用コストを大幅に下げることができます。

単なるサーバ移行で『Amazon EC2』に置いたシステムのうち、サーバレスサービスのAWS LambdaやAWS Fargate、データベースサービスのAmazon Aurora、DynamoDBなどに移行できないか考えるといいでしょう。このように、極力サーバーを利用しない、サーバレスなアーキテクチャはコストメリットが出やすい手法のひとつです。

古いシステムでも安心して移行できるスタイルズのAWS導入・移行サービスはこちら→

AWS移行で陥りがちなよくある誤解

AWS移行において、ありがちな誤解や失敗について記載していきます。

S3はディスクではない。マウントは非推奨。

S3はOSにマウントするディスクではありません。OSにマウントするディスクは『ブロックストレージ』といい、入出力（I/O）に優れています。S3は『オブジェクトストレージ』といい、データの保存や耐久性に優れていますが、高速なI/Oが必要なケースには向いていません。OSにS3をマウントすると思わぬ性能劣化を招くため、マウントするディスクはEBSを利用するようにしましょう。

IPアドレスを静的に管理しようとすると

AWSではIPアドレスは動的に変更します。例えば、ロードバランサーのサービスであるELBはIPアドレスが予告なく変化します。よって、オンプレミス側のファイアウォールなどでELBのIPアドレスを登録しておく、といったことを行うと、IPアドレスが変更したときにファイアウォールの設定も変更しなくてはいけないため、運用コストが上がってしまいます。IPアドレスは静的に管理しようとせず、変更するものだという意識をもって管理をするといいでしょう。

ディスクサイズを多めに見積もる

オンプレミスでは、データベースやサーバのディスク拡張が困難であるため、ディスクサイズを多めに見積もる、といった経験があるかもしれません。AWSはディスクサイズが自動で拡張したり、GUIとコマンドを打つことで簡単にディスク拡張が可能です。したがって、ディスクサイズを多めに見積もるとコストメリットが得られないため注意が必要です。

継続的改善に向けてポイントとなるのは自動化の取り組み

AWSでは、運用を自動化する様々なサービスが用意されており、しかも無料で利用できる場合が多いです。例えば、OSのパッチ適用はSystems Managerというサービスを利用することで自動的に行うことが可能です。また、アプリケーションのデプロイなどもCodePipelineというサービスを使うことで自動的に行うことができます。従来まで手作業で行っていた運用・保守作業を、これらのサービスを利用することで運用フェーズにおけるコストを大幅に削減することができます。AWSへのシステム移行後は、手作業を以下に自動化するか、がコストを削減するためのカギとなります。

まとめ

ITシステムをAWSに移行する前に、どのような目的があるのか、担当者だけでなく経営層やステークホルダーと共有を行い、目的と実施ステップを明確化したうえでAWS移行に進めるといいでしょう。また、AWSに移行して終わりにせず、サーバレス化や、作業の自動化といったAWSのサービスをフル活用する（クラウドネイティブ）ことで、さらにコストを下げ、改善のスピードを高速化することができます。

継続的な活動がAWS移行プロジェクトの成功のカギとなります。改善点が見つからない場合でも、経験豊富なベンダー等にコンサルティングを受けることで改善点が見つかる場合があるので、是非相談してみてください。