近年、多くの企業で基幹システムをクラウドに移行する動きが見られます。総務省が実施した「通信利用動向調査」によると、2019年にはクラウドを一部でも利用している企業の割合が6割以上となっており、多くの企業でクラウド移行が進んでいることが分かります。
その背景には、経済産業省によるDXの推進に加え、2020年以降は新型コロナウイルス感染症拡大に伴うリモートワーク・在宅勤務の需要の高まりがあると考えられます。
今はオンプレミス環境でシステム運用をしていても、今後基幹システムをクラウドに移行しようと検討している方も多いのではないでしょうか。そこで今回の記事では、基幹システムのクラウド移行のメリットを紹介しつつ、オンプレミス環境からAWSに移行する手順や移行時の注意点について解説していきます。
目次
AWSに移行するメリット
まず、基幹システムをAWSに移行するとどのようなメリットがあるのか、という点を解説していきます。
システムの運用保守にかかる負担・費用を削減できる
1つ目のメリットとして挙げられるのが、システムの運用保守やサーバールームなどにかかる費用・運用管理の負担を削減できるという点です。クラウドで運用する場合、ハードウェアの管理、ハードウェアに障害が発生した際の復旧対応は、クラウド事業者が実施します。オンプレミス環境での運用より運用管理の負担が大幅に削減できることも、クラウドの大きな魅力の一つです。
また、自社でハードウェアをリプレイスする必要もなくなるため、EOS対策※にもなりコスト面でもメリットがあります。
- ※ EOS対策:企業が製品に対するサポートを終了することを「End Of Support(EOS)」と呼びます。サポートが終了した製品に対しては、新機能の追加や不具合の修正といったサポートが提供されません。したがって、EOSを迎えた製品を使用し続けることはセキュリティリスクなどを抱えることになり、推奨されません。
ただし、クラウド上に環境を構築したからといって、全ての管理をクラウド事業者に任せられるわけではありません。AWSでは、クラウド内のソフトウェア・データ・ネットワークの安全性などについては、利用者が責任を負うことになります。それでもオンプレミス環境での運用と比べれば、運用管理にかかる負担が大幅に削減されるのは事実です。
状況に応じて柔軟にサーバースペックを変更できる
柔軟にサーバースペックを変更できるのも、クラウドならではのメリットです。オンプレミス環境の場合、簡単にスペックを変更できません。しかしクラウドでのシステム運用であれば、社員数が増加してより高いスペックが必要になった場合でも、柔軟にサーバースペックを上げられます。反対に、想定よりも利用が少ない場合は、サーバースペックを落とす対応も可能です。過剰なスペックはコスト増加を招き負担になりますが、状況に応じてサーバースペックを柔軟に変更できるため、コストの最適化にもつながります。
BCP対策がしやすい
続いて挙げられるのが、BCP対策がしやすいというメリットです。このメリットについて解説する前に、AWSのリージョンという概念について簡単に説明します。
AWSは、世界を複数の「リージョン(地域)」に分け、各リージョン内に複数の「アベイラビリティーゾーン(以降、AZ)」と呼ばれるデータセンター群を設置しています。例えば、日本には東京リージョンと大阪リージョンが存在し、それぞれのリージョンには複数のAZが存在します。リージョン間のネットワークは分離されているため、どこかのリージョンで障害が発生した場合でも、他のリージョンに影響は及びません。
それぞれのリージョンは独立しています。そのため、リージョン間でのデータの複製・システム連携は簡単ではありません。一方でAZ間は、ネットワークで相互接続されているため、簡単にデータの複製・システムの連携を行うことができます。
この仕組みを活用し、複数のAZをまたいでシステムを構築する(マルチAZ)ことで、自然災害が発生した際にデータが損失するリスクを最小限に抑えることができます。このように、構成次第でDR(災害復旧)対策ができるうえ、災害時の在宅ワークやリモートワークにも柔軟に対応でき、結果的にBCP対策にもつながります。
移行の大まかな流れ
続いて、具体的な移行の流れについて解説していきます。
移行計画
まず、既存の基幹システムをいつまで利用し、いつから新たな基幹システムに切り替えるのか(いつまで並行稼働するのか)という大まかな移行のスケジュール立てるところから始まります。また、いつまでに環境を構築し、どの環境でテストを実施して、いつから本番環境のデータを入れるのか、といった計画も立てておく必要があります。オンプレミスからクラウドに移行するにあたっては、さまざまな作業が必要になるため、この段階で必要な作業を洗い出し、余裕を持ったスケジュールを立てることが重要です。
要件定義
続いて、要件定義のフェーズに入ります。要件定義フェーズでは、現状の基幹システムで対応している業務を洗い出したうえで、新しい基幹システムでどの範囲をカバーするのかなどを定めていきます。
設計
要件定義に基づいて、基幹システムの機能をAWS上で実現するには、どのサービスを利用して、どのように設定をすればよいのかを検討・決定するのが設計フェーズです。また、外部システムとの連携についても考える必要があります。どのシステムと連携しているのかを一覧化し、それぞれの連携方法について検討を進めます。
構築
続く構築フェーズでは、AWS上に新システムの環境を構築していきます。環境を構築する際の各種パラメータなどの設定は、設計フェーズで定めた内容に従います。環境構築の完了後、無事にシステムを立ち上げられたら次のフェーズに移ります。
移行・設定
環境の構築が完了したら、既存システムのデータを新システムに移行します。設定は、基本的に要件定義に基づいて行います。コピーやデータ取り込みなどの機能を用いつつ、コピーできないものは手動で設定します。
テスト
移行が完了したら、意図した通りに動作するのかを検証する必要があります。また、実際の業務に基づいたテストも行い、新システムで業務が問題なく実施できるかの最終確認もこのフェーズで行います。
稼働・保守
テストが無事に完了したら、いよいよ稼働開始となります。システム移行の場合は、既存のシステムを停止し、新システムに切り替える必要があります。稼働後問題がなければ、保守フェーズに移行します。
移行にあたって注意すべきこと
ここまで、移行のメリットや大まかな移行の進め方について解説してきました。最後に、移行時に注意すべき点を紹介していきます。
事前にランニングコストの見積もりを
AWSでは従量課金制の料金体系を採用しているため、特に常時稼働しているタイプのシステムの場合は、ランニングコストが増加しやすい傾向にあります。そのため、コスト削減という目的でクラウドに移行しても、想定していたほどの効果を得られないケースもあります。システムの構成やユーザーの利用状況などをもとに事前にしっかりと検証を行い、どれほどのコストがかかるのかを明確にしておきましょう。
専門的な知識が必要
基幹システムをAWSに移行するのであれば、インフラ周りの知識はもちろんのこと、AWSに関する知識も必要不可欠です。どのような構成を組めば、クラウド移行によって得られる効果を最大化できるのか(ベストプラクティス)を、検討するための知識が求められます。環境構築を進めるにあたっては、AWS上で操作をしていくことになるため、AWSの各種サービスの操作方法も理解していなければなりません。
かなりの社内リソースが必要
また、基幹システムの移行は必然と規模が大きくなるため、リソースの不足も懸念されます。移行の計画を立てるにあたっては、さまざまな部署との調整も必要になるでしょう。移行のミスで、給与計算ミスや支払通知書のミスなどが起きてしまうと、大きな問題になりかねません。こういった理由から、システム移行をする際は、テストでも細部まで時間をかけて丁寧に行う必要があります。プロジェクト開始時点で必要な人員を算出し、余裕を持ったスケジュールで取り組むようにしましょう。リソースに余裕がない場合は、外部に委託するのも一つの手段です。
まとめ
基幹システムは日常的に使われるため、移行がうまくいけば大幅な業務の効率化につながる可能性があります。ただし、オンプレミスからクラウドへの移行は容易ではなく、入念な計画と専門知識が欠かせません。クラウドに移行したいと考えているものの、専門的な知識を持つ人材が社内にいないという場合や、そもそも社内のリソースが足りないという場合は、専門家に相談してみてはいかがでしょうか。
なお、TOKAIコミュニケーションズでは、オンプレミスからAWSへの移行をサポートする「AWSマイグレーションサービス 」を提供しています。ご興味のある方はお気軽にお問い合せ ください。
関連サービス
おすすめ記事
-
2020.06.23
Amazon Connectで在宅勤務でも対応できる問合せ窓口を立ち上げてみた
-
2020.08.17
Datadogで実現するモニタリングとオペレーションのオートメーション化
-
2020.04.27
Amazon FSx for Windows ファイルサーバーへの移行と活用方法
-
2020.06.11
Amazon WorkSpacesとは?その特長をまとめてみた
-
2020.06.23
AWSのDevOpsサービスと当社マネージドサービスを活用したDevOpsの実装①~概念編~