オンプレミスからのクラウド移行で気をつけること（物理サーバーからのクラウド移行）【2024年最新版】

「クラウド移行を進めたいが、どうしたら良いかわからない」
「エンジニアがクラウド移行を成し遂げるだけの技術力があるのかわからない」
「クラウド移行を依頼する方法を吟味する時間がない」

オンプレミスからのクラウド移行は情報が専門的かつ限定的であり、自社に最適な開発会社を探すのは非常に困難です。また、クラウド移行に失敗した時の会社のダメージは計り知れないため、きちんとした会社選びを行う必要があります。

そこで、インフラ/クラウドエンジニアとして働いているプロへの取材情報をまとめ、オンプレミスからのクラウド移行における考え方のポイントを解説します。

最後まで読めば、オンプレミスからのクラウド移行の失敗がグッと減りますので、ぜひ参考にしてください。

※オンプレミスからのクラウド移行に不安がある方は、システム幹事にお問い合わせください。予算や目的などをヒアリングした上で、最適な開発会社を提案します。

【無料】システム幹事にクラウド移行の外注先選定を相談する

オンプレミスとは何か（物理サーバーとは何か）

まずは、オンプレミス（物理サーバー）について具体的なイメージを掴んでもらうために、オンプレミスの概要について簡単に説明します。

オンプレミスとは、システムに必要なサーバーやネットワーク機器などを、自社で保有する形態のことです。プレミス（premises）とは英語で建物や施設を意味する単語。そのためオンプレミス（on premises）で建物内や施設内という意味になります。

研究施設などのスーパーコンピュータ（スパコン）などがイメージしやすいかもしれません。例えば東京工業大学は、大学内にTSUBAMEと呼ばれるスパコンを設置しています。

画像引用：東京工業大学

オンプレミスは従来から長く採用されている方式で、データセンター（DC）などの自社施設内にネットワークを引き、そこにサーバーを配置して、その上でシステムやアプリケーションなどを運用していました。

しかし2000年代後半~2010年代にかけて、クラウドコンピューティングが台頭し、クラウド上でシステムを構築・運用する企業も増えてきました。

オンプレミスとクラウドの違い

それでは、オンプレミスとクラウドはどう違うのでしょうか。

クラウドコンピューティングとは、利用者がサーバーなどのITインフラを持つことなく、必要な時に必要なだけITインフラを利用することができるサービスのことです。インターネット経由で、サーバやデータベースなどのITインフラを利用することができます。

クラウドの考え方と近い例として、カーシェアが挙げられます。従来は、自動車は自分で購入・保有するのが当たり前でした。（≒オンプレミス：自社で物理サーバを保有）

しかし近年は、自身で自動車を保有せず、使いたい時に使いたいだけ使うシェアサービスが台頭してきています。（≒クラウド：自社で物理サーバを保有せず、使った分だけ料金を払う）

有名なクラウドとしては、業界No1のAWS（Amazon Web Service）や2位のMicrosoft Azure、Googleが提供するGCP（Google Cloud）があります。また国内のクラウドとしては、富士通のニフクラなどが挙げられます。

オンプレミスが抱える課題

日本のオンプレミスの実情として、物理サーバーやその上のOSやソフトウェア、アプリケーションの老朽化が進んでいるということが大きな問題になっています。
これによって、以下のような課題が顕在化してきています。

管理コストの増大

オンプレミスの老朽化によって、管理コストも増大しています。例えばオンプレミスの物理サーバーの保守運用は、原則物理サーバーが存在する自社のデータセンターに出向いて実施する必要があります。

管理するための人員を常に確保しておく必要があり、老朽化によって障害の頻度も一般的には増えていきます。また、物理サーバーを設置するデーターセンターの確保や、それに伴う電源や空調なども固定費としてかかってきます。

平成29年の一般社団法人日本情報システム・ユーザー協会「デジタル化の進展に対する意識調査」では、レガシーシステムの維持運用費が高くて改修コストを捻出しづらい、と全体の1/3以上の企業が回答しています。

保守運用を行うエンジニア不足

エンジニア不足は多く世で叫ばれていますが、老朽化が進んでいるレガシーなシステムの保守運用ができるエンジニアはより不足しています。理由としては、定年退職するエンジニアが増えてきたことや、イケているイメージがなく、将来的にはさらに廃れた技術になることが目に見えているため、新しく始めるエンジニアがほとんどいないことが挙げられます。

また、仕様や手順をまとめているドキュメントがない場合も多く、高度に属人化している現場も少なくありません。平成29年の一般社団法人日本情報システム・ユーザー協会「デジタル化の進展に対する意識調査」では、有識者がいないと回答した企業が全体の1/3以上存在しています。また、経済産業省の調査では、そもそものIT人材が2020年時点で30万人不足しており、2030年には最大79万人の不足が発生するという統計も出されています。

画像引用：経済産業省

OSやソフトウェアなどのサポート切れ

OSのサポートは5年や10年、ソフトウェアのサポートは3年や5年程度のものがよく見られます。これらのサポートが切れることにより、脆弱性が発覚しても修正プログラムが提供されなくなり、年々セキュリティ的に脆いシステムになっていきます。これにより、データの流出などのリスクが高くなります。

例えばWindows7は、2020年1月にサービスを終了し、引き続き使い続けることはウイルスの被害を受けやすくなるため、Micorosoftは推奨していません。Windows 10では、月に少なくとも数個の更新プログラムが提供されており、その都度機能追加に加えセキュリティパッチも適用されています。このように、セキュリティのリスクは日に日に増しているので、OSを使用するユーザーもきちんとセキュリティパッチをあてていくことが重要です。

新しい技術への対応が困難

レガシーシステムは、現在では非効率なシステムに対して長年改修を重ねた結果、複雑化/ブラックボックス化が進んでいます。このようなシステムは維持するのが精一杯で、新しい機能の追加であったり各機能からデータを抽出してビジネスに活用するといったことは非常に困難です。

一方で現場としては依然としてレガシーシステムを使っている場合も多く、安易に止めることもできず、八方塞がりとなっています。これらの課題は、経済産業省によって提唱された2025年の壁問題でも詳細が述べられています。

オンプレミスの2025年の壁

2025年の壁とは、2018年に経済産業省から出された「DXレポート　～IT システム「2025 年の崖」の克服と DX の本格的な展開～」内で提唱された概念です。2025年までに日本企業がDXを推進しなければ、2025以降の5年間で10兆円以上の経済損失が生じるという予測を打ち出し、経済界に警鐘を鳴らしました。

このレポートの中では、例えば約8割の企業が老朽化したレガシーシステムを抱えており、約7割の企業がレガシーシステムがDXの障壁になっていると回答しています。理由としては、以下のような理由が挙げられます。

• ドキュメントが整備されておらず、まだ有識者の引退もあり、現場の把握ができない
• レガシーシステムと新しいシステムのデータ連携が困難
• 機能改修を重ねた結果、システムが肥大化・ブラックボックス化している
• 技術的な制約や性能の限界がある
• メーカーやソフトウェアのサポートが切れており、触れたくない

このようなレガシーシステムはオンプレミス（物理サーバー）上で動いており、各社課題意識を持ちつつも、業務で使用されているなどの理由で刷新に踏み切れない企業も多く存在します。

画像引用：経済産業省

また、これらの問題の背景として以下のような日本特有の商習慣も指摘されています。

部署ごとの最適化が図られており、全体最適になっていない

経済産業省の「DXレポート　～IT システム「2025 年の崖」の克服と DX の本格的な展開～」によると、特に大企業においては各事業部ごとに独立してシステムの構築やデータの収集などを推進してきたため、全体のシステムが煩雑化しています。

そのため、部署を跨いだデータ連携・活用が限定的になり、AIやIoTなどを導入したとしても恩恵を全社的に受けることが難しいといった実情があります。また、データの利活用を想定したシステム設計になっておらず、一般社団法人日本情報システム・ユーザー協会の調査によると、対象企業の半数近くがレガシーシステムとのデータ連携が困難でレガシーシステムが足枷になっていると回答しています。

ベンダー文化であり、ITの知見がユーザー企業に蓄積しない

日本においては、ユーザー企業よりもベンダー企業にエンジニアが多く在籍しています。ベンダー企業がユーザー企業のシステムを受託し開発する構造であるため、ユーザー企業にIT資産が貯まらず、内製化の妨げになっています。また、ユーザーとベンダーの関係性についても、不満の声が漏れ出しています。経済産業省のDXレポート2.1では、「ITシステムの開発や管理をベンダー任せにすることで、IT対応能力が育たない」「ベンダーロックインにより経営のアジリティが低下する」などのユーザの声が紹介されています。

また、クラウドの運用については、およそ2/3の企業が運用保守の一部もしくは全部を外注しているという調査結果がMM総研のリサーチで出ています。技術知見や技術者不足により、クラウドなどの新技術の活用もベンダー企業などに頼らなければいけないという実情があります。そう言った実情の中で、IaaS/PaaSベンダーからの情報提供の不足を嘆く企業も14%以上あります。

画像引用：株式会社MM総研

IT人材白書2017では、日本では7割以上のIT人材がベンダーなどのIT企業に勤めている一方、アメリカやドイツなどでは30〜40%の人材しかIT関連の企業に勤めておらず、残りはユーザー企業の専任ITエンジニアとして働いていることが示されています。このように海外では日本ほど終身雇用が根強くないため、会社として積極的にIT知見を貯めていることが推察できます。

ただ近年、日本企業もITの内製化に舵を切りつつあり、IPAのIT人材白書2020によると、従業員1000人以上の国内企業のおよそ6割以上が内製化を進めていると回答しています。

画像引用：IPA IT人材白書2017

画像引用：IPA IT人材白書2020

終身雇用によるドキュメント意識の希薄化

経済産業省の「DXレポート　～IT システム「2025 年の崖」の克服と DX の本格的な展開～」によると、日本の多くの企業は終身雇用が前提のため、ITシステムに関するノウハウや手順をドキュメント化するメリットや意識は弱く、おざなりになっていました。これまでは有識者が社内に存在するため問題は顕在化していませんでした。しかし近年、定年退職などで有識者が年々現場を去っており、それらの有識者に属人化していたITシステムの保守運用などの業務の実施が困難になっています。経済産業省の情報システム開発課題アンケート結果によると、レガシーシステムのリスク・課題として、66%の企業が保守運用が属人的になっており、継承が難しいと回答しています。

【無料】クラウド移行の外注先選定を相談する

クラウド移行とは何か

続いては、クラウド移行について説明していきます。クラウド移行とは、オンプレミスで動くシステムを、AWSやAzureなどのクラウドへ移行することです。

クラウド事業者が提供するITインフラは、家に例えると骨組みのようなもの。ITインフラの上で動くシステムは、謂わばキッチンやお風呂、寝室などの家の設備です。

システム移行を家の改築に例えると、家の設備はそのまま使えるように維持しつつ、家の骨組みだけ木造から鉄筋コンクリートに変えることです。

システム移行が非常に難しいのがお分かりいただけたでしょうか？少し骨組みのサイズを間違えただけでお風呂が設置できないといったトラブルがあっても、以前の骨組みには簡単には戻せません。非常にリスクの高い作業のため、石橋を何度も叩いた上で実施する必要があります。

クラウド(AWS、Azure、GCP)の解説

まずは、主要なクラウドであるAWS、Azure、GCPについて簡単に説明します。

AWS（Amazon Web Service）

AWSは、業界トップのクラウドベンダーです。2006年からサービスを提供しており、2022年2四半期のクラウドインフラ業界におけるシェアは31%で、継続して業界No1を維持しています。

AWSの特徴としては、業界リーダーとしてバランスよく様々な領域のサービスを展開していることが挙げられます。

開発会社を選定するという視点でも、AWSへの移行経験のある開発会社は、他クラウドへの移行と比較しても多く存在します。開発会社の候補が多いことも、メリットの1つではないでしょうか。

関連記事：Amazon Web Service（AWS）とは？主な機能と活用事例・メリット・注意点

Microsoft Azure

Azureは、業界No2のクラウドベンダーです。2010年からサービスを開始しており、2022年2四半期のクラウドインフラ業界におけるシェアは24%と、首位のAWSとの差をじわじわ縮めています。

Azureの最大の強みとして、Microsoft OfficeやAcitive DirectoryなどのMicrosoftサービスとの親和性が高いことが挙げられます。これらのサービスと簡単に連携できるため、システム導入やシステム移行がスムーズに実施でき、コストを削減できます。

開発会社選定の視点だと、Azureへの移行経験のある開発会社も多く存在します。特に近年、Azureへの移行もよく耳にするようになりました。

関連記事：Microsoft Azureとは？主な機能と活用事例・メリット・注意点について解説

GCP（Google Cloud）

GCPは、Googleが提供するクラウドサービスです。2008年からサービスを開始しており、2022年2四半期のクラウドインフラ業界におけるシェアは8%でした。GCPの特長としては、Googleとして培っているデータ分析などの特定の領域に非常に強いことです。

例えばBigQueryは、他クラウドと比較して低コストと高パフォーマンスでビッグデータを分析できます。オンプレミスからGCPへの移行は、AWSやAzureほどは多くないため、開発会社を見つける難易度がAWSやAzureと比較して高いという懸念もあります。

【無料】クラウド移行の外注先選定を相談する

クラウド移行のメリット

オンプレミスからクラウドへ移行するメリットとして、以下4点が挙げられます。

費用が抑えられる

オンプレミスの場合、サーバの調達に何百万単位の初期コストがかかります。一方でクラウドの場合は自社でのサーバ購入が不要のため、初期コストはほぼ0円、月々のランニングコストも数百円〜数万円で開発を始めることができます。

そのため、スモールスタートで事業を始めることができ、その時々に合わせてスピード感を持った事業推進が可能です。

オンプレミスからクラウドへ移行することで、ランニングコストを削減することができる場合も多いです。例えば管理コストについて、オンプレミスの物理サーバーの保守運用は、原則物理サーバーが存在する自社のデータセンターに出向いて実施する必要があり、ハードウェアのメンテナンスも必要でした。クラウドへ移行することによって、Webコンソールなどからメンテナンスが出来、ハードウェアの管理は不要となります。

また、物理サーバーを設置するデーターセンターの確保や、それに伴う電源や空調などの固定費も不要となります。

一般社団法人 日本情報システムユーザー協会の「企業IT動向調査報告書 2017」によると、企業のIT関連費用のうち平均80%以上が既存システムの保守運用に宛てられているいるという調査結果があります。これにより、新技術を用いた新しいシステムの開発などに十分な予算が割り当てられず、DX化が進んでいないという実情もあります。

またクラウドは、従量課金（クラウドリソースを使った分だけ払う）なので、バッチ処理などの定期的な実行のみにサーバを使っていた場合は、より大きなコスト削減になります。

所要時間が少ない

オンプレミスの場合、サーバの選定・調達や実際に使用可能になるまでのセッティング完了までに数ヶ月を要する場合があります。

クラウドの場合は、最短その日から使用することができ、サーバやデータベースの使用をすぐに始めることができるため、スピーディーな事業推進が可能となります。

拡張性が高い

オンプレミスの場合は、物理サーバーのスペックを上げるスケールアップや、物理サーバの数を増やすスケールアウトには、大きなコストとリードタイムを要します。一方クラウドの場合は、数クリックでスケールアップが可能であり、マネージドなサービスを使うことで簡単にスケールアウトが実現できます。

また、利用が少ない時はサーバの数を減らしコストを抑えるスケールインができることもクラウドのメリットです。このように、クラウドは嵐のように変わる市場の状況に合わせて小回りを利かせやすく、コストメリットが出しやすいため、活用が進んでいます。

オンプレミスからクラウドへ移行することで、将来的に新しい技術や機能の追加がしやすくなります。例えばクラウド上の全てのサーバーからログを取得しダッシュボードに可視化するといった機能は、AWSやAzureなどの1クラウドのマネージドサービスを使うことで簡単に実現できます。

また、オンプレミスのサーバー上で動いていたコードを、クラウドのサーバレスサービスを使って動かすといったことも検討できます。クラウドのサーバレスやコンテナサービスを活用し、それぞれの要素が疎結合のマイクロサービスアーキテクチャに寄せていくことで、影響範囲が少なくなるために機能の追加や改修がしやすくなります。

このような、機能に沿って小さな単位でアプリケーションを管理していくマイクロサービスの考え方が、近年広まってきています。

パフォーマンスの向上

クラウド事業者が提供する自動スケーリングの仕組みを使えば、ユーザーや業務の急激な増減にも柔軟に対応でき、トラフィック急増時にもパフォーマンスを担保できます。加えて、その時々の最新のハイスペック機種のハードウェアを使用できるのも魅力。

また、アメリカやヨーロッパなどの特定の地域にサービス展開している場合、クラウド事業者が提供しているリージョン/ロケーション（データセンターの集まり）を指定することで、その地域のレイテンシー（応答速度）を向上させることができます。

CDN（Contents Delivery Network）などの一部のサービスは、クラウド事業者によってはグローバル共通で提供しています。これらを活用することで、世界中どこからのアクセスであっても高速なレスポンスを返すことができます。

【無料】クラウド移行の外注先選定を相談する

オンプレミスからのクラウド移行のステップ（手順）

オンプレミスからのクラウド以降は、大きく3ステップに分けられます。

①要件定義・設計

まずは、計画フェーズです。最初にやることとして、ヒアリングなどを行い既存環境を棚卸しして文書化していきます。現場が分からないことにはクラウドへの移行もできません。この現状の可視化がきちんとできるかどうかで、クラウド移行の成否が決まるといっても過言ではありません。

続いて、移行対象の決定やスケジュールを作成していきます。クラウド移行は思わぬトラブルも多く想定されるため、余裕を持ったスケジュール策定が望ましいです。

移行対象が決まったら、クラウドの設計をしていきます。どのようなサービスをどのような設定で、どう組み合わせるかを、既存環境の資源や構成を元に決めていきます。

②クラウド構築・テスト

続いて、実際に手を動かすフェーズに移っていきます。移行先のクラウドの環境を構築します。例えばAWSへ移行する場合の例としては、DNSサービスであるRoute 53でIPアドレスとドメインの紐付けを行い、ロードバランサーのALB+WAFからの通信を、EC2やECSなどのサーバ/コンテナで処理し、RDSなどのデータベースに格納するような構成が挙げられます。

構築した環境で、OSやミドルウェア・ソフトウェア、またアプリケーションの動作確認を行います。特にクラウド移行では思わぬトラブルが起こるため、あらゆる状況を想定したテストが求められます。

それと並行し移行作業を手順化し、ドキュメントにまとめていきます。作業を属人化せず、誰でもできる状態にしておくことが大切です。最後に、リハーサルを行います。これは移行本番を想定し、内容に留まらずメンバーや時間制限も本番と同じにするべきです。システムの規模によっては、リハーサルを複数回実施する場合もあります。

③移行

最後に、システムをオンプレミスからクラウドへ移行します。データベースの移行では、データベースのテーブルやスキーマ、データ自体をクラウドへ移行していきます。

また、物理サーバー上で動くアプリケーションについても、クラウドのIaaSのサーバーなどに移行します。アプリケーションやデータベースなどの移行が終わったら、原則全ての機能について挙動を確認・テストしていきます。

移行作業では、必ずチェックリストを作り、1つ1つの作業に対して確認を行います。また、2人以上のペアで作業は実施し、監督者が常に監督していることが望ましいです。一通りの機能や挙動を確認し、全て問題なければ移行は完了です。

【無料】クラウド移行の外注先選定を相談する

オンプレミスからのクラウド移行で大切な知見と実績

次に、オンプレミスからクラウドへ移行する際に必要な知見・スキルや実績について紹介します。

クラウド移行と他の開発の違い

例えばクラウドを用いたスクラッチ開発では、0から新しいシステムを構築します。スクラッチ開発では、動かない資源を微修正し、試行錯誤して動くようにブラッシュアップしていくといったことが基本的に可能です。

一方で、クラウド移行では、クラウド上に載せ替えた後に細かいチューニングをして、試行錯誤していくことは基本的にはできません。

クラウド移行は、オンプレミスで動いている機能をそのままクラウドへ移植し、同じように動作させる必要があります。既存のシステムは複雑に絡み合っているため、移行時にクラウド上で動くようにチューニング・ブラッシュアップするということは非常に困難です。そのため、事前のテストによって、確実にクラウド上で動作することを1つ1つ担保していくことがより重要になります。

クラウド移行で求められる知見・スキル

クラウド移行においては、前提として以下に関する知見・スキルが求められます。

• ネットワーク
• OS/ミドルウェア
• アプリケーション

「クラウド上に移行したシステムと社内ネットワークをどう安全に接続するか」「クラウド上に移行したアプリケーションのネットワークセキュリティをどう担保するか」
これらをきちんと考慮し設計するためには、ルーティングなどのネットワークの知見・スキルが不可欠です。

また、クラウド移行においてはOSやミドルウェアの知識も非常に重要です。「ミドルウェアやソフトウェアを動作させるために、どのバージョンのどのOSを採用するか」「該当のバージョンのOSで、移行するシステムは正常に動作するのか」

システムをクラウド上で動作させるために、採用するミドルウェアやOSの種類・バージョンの選定が非常に重要になってきます。OSやミドルウェアのバージョンによってはシステムが動作しない場合もあるため、OSやミドルウェアの知見・スキルを網羅的に押さえていることが必要です。

当然ですが、アプリケーションの知見・スキルも求められます。「移行するシステムがどのようなロジックで動作するのか」「必要なアプリケーション要件は何か」クラウドでもオンプレミスでも、必要な要件に対してバックエンドとフロントエンドを適切に構築する知識・スキルは普遍的に必要です。

これらの土台となる知見・スキルを前提として、クラウド移行に特有の以下の観点も求められます。

各クラウドサービスの仕様・特徴

システムの移行先としてクラウドの適切なサービスを選定するためには、クラウドの各サービスの仕様・特徴を深く理解する必要があります。テストフェーズになって、OSとの互換性で使いたいソフトウェアが使用できない、サービスの制約でプログラムが動作しないなどの致命的な手戻りを防ぐためにも、各々のサービスの特徴や制約をきちんと理解することが求められます。

また、実際のクラウド移行においては、サーバやデータベース、ロードバランサーなどの複数のクラウドサービスを組み合わせて使用します。
そのため、サービス同士の相性や組み合わせ方、組み合わせた際の制約や懸念点なども考慮した上で移行先のアーキテクチャを策定する必要があります。アーキテクチャを描くためには、各クラウドサービスの仕様や制約と、ネットワークやOSなどのITインフラの識の両方に対する深い理解が求められます。

アーキテクチャ図の一例

クラウドのセキュリティに関する知見・スキル

クラウドのセキュリティは、オンプレミスよりも注意を払う必要があります。オンプレミスはデフォルトでインターネットアクセスが出来ない場合がほとんどですが、クラウドはデフォルトでインターネットにアクセスできる設定のサービスもあります。そのため、適切なセキュリティ設定と監視の仕組みを整備する必要があります。

また、クラウド事業者自体の障害も起こりうる可能性があるため、サーバやデータベースなどの死活監視に加えてクラウドサービス自体の死活監視や、サーバのメモリやCPUなどのリソース監視など、幅広いセキュリティ設定を行うことのできる知見・スキルが必要です。

AWSやAzureなどのクラウド事業者が提供しているセキュリティサービスや、セキュリティに特化したSaaSなど多くのサービスがある中で、自社のシステムに必要な要件を洗い出し、適切なソリューション選定が出来るスキルが求められます。

クラウドのパフォーマンスに関する知見・スキル

システムをクラウド移行する際には、パフォーマンスも考慮する必要があります。例えば、クラウド事業者が提供しているサーバーのディスクは、I/O（入出力）の上限がオンプレミスより低い場合があります。高いディスクI/O（入出力）が求められるシステムを移行する場合は、特に注意する必要があります。

また、クラウドの実態は、クラウド事業者が持つデータセンターのサーバー群です。例えば日本の東京リージョンを選択した場合、物理サーバが動いているのは東京のデータセンターになります。そのため、九州の企業の社内システムを東京リージョンで構築した場合は、物理的な距離が理由でパフォーマンスが出ない場合なども考慮する必要があります。
パフォーマンスの問題は、後からのチューニングには限界があるため、移行時点で非機能要件をきちんと考慮してアーキテクチャを実装することが大切です。

移行元のプログラミング言語に関する知見・スキル

移行元のシステムで使用されている言語に対する深い理解も不可欠です。オンプレミスからクラウドへ移行するにあたり、OSやミドルウェアの種類やバージョンを揃えて同一環境に限りなく近づけますが、やはりオンプレミスとクラウドでの環境差異を許容しなければいけない場合もあります。

その場合に、差異がどのようにシステムに影響するのか。移行を想定したテスト時にシステムが動作しなかった場合、何が原因なのか、どうプログラムを修正すべきなのか。これらの問題の原因を特定するためには、言語がサーバの中でどのように動作するのか、ビルドやコンパイルはどのような原理で実行されるかなど、言語の深い挙動を理解し、問題を切り分ける必要があります。

クラウド移行で求められる実績・移行内容

クラウド移行をお願いする開発会社を見極めるにあたり、まずは以下の基本的な実績を確認してください。

• ネットワーク構築
• OS/ミドルウェア構築
• アプリケーション構築

オンプレミスからのクラウド移行には、インフラレイヤーからアプリケーションレイヤーに至るまでの幅広いIT知識・経験が必要です。その中でも、ネットワーク、OSやミドルウェア、アプリケーションの知識・経験は、クラウド移行だけに限らず、全ての開発の土台となるものです。

ネットワーク構築の実績としては、例えば社内ネットワークの構築や、社内ネットワークと他ネットワークの接続、またインターネット向けアプリケーションのネットワーク設計などが一例として挙げられます。

またOS/ミドルウェア構築の実績としては、LinuxやWindowsサーバの構築や、ミドルウェアの導入・セットアップ経験などです。

アプリケーションについては、お客様の求める要件に対して、適切なサービスや言語を組み合わせてシステムを開発し、きちんと完成まで至っていることが重要です。

これらを、設計などの上流から、開発やテストなどの下流まで一貫して経験していることが望ましいです。上流の経験しかない場合、実装力に不安が残りますし、仕様通りの開発やテストしか実施したことがない場合は、上流の構想力に不安が残ります。

これらの土台となる実績を踏まえて、以下のようなクラウド移行の実績を確認してください。

類似のクラウド移行の実績があるか

クラウド移行と一口で言っても、AWSなのかAzureなのかで大きく変わってきます。AWSでも、アーキテクチャ（設計図・サービスの組み合わせ）が異なれば、クラウド移行に必要な知識やクラウド移行時のポイントがかなり異なってきます。どのようなシステムを、どのクラウドのどのサービスへ移行したのかをきちんとヒアリングすると良いでしょう。

クラウドやその中でのサービスの選定基準も聞くべきポイントです。要件を満たすために、きちんと複数候補を比較して明確な基準を持ってソリューションを選んでいるのか。世の中には、ソリューションが有名だからなんとなく選んだ、というパターンも多く存在するので、自社のシステムに本当にマッチしたソリューション選定を行ってくれる開発会社を見つけることが大切です。

また、移行する対象のシステムについてもきちんと把握しておくべきです。使用しているOSやミドルウェア、言語やフレームワークによっても、注意すべきポイントは変わってきます。また、プログラム数やファイルのサイズなど、移行のボリュームも同程度かを聞いておくと良いでしょう。

クラウド移行では、必ず解決しなければいけない技術課題が生じます。移行時にどのような課題があり、それぞれに対してどう対処したかをヒアリングすることで、開発会社の技術力を確認できます。

クラウドセキュリティの実績

クラウドへシステムを移行した実績があっても、クラウド上でのセキュリティが不十分な場合も散見されます。クラウドでは、適切な設定をしないとセキュリティホールになってしまうサービスも存在します。どのような思想やルールで、どのようなセキュリティ設定を施したのかなどを、きちんとヒアリングしましょう。

クラウド事業者自体の障害も起こりうる可能性があるため、サーバやデータベースなどの死活監視に加えてクラウドサービス自体の死活監視も実装する必要があります。クラウドでどのような項目を監視しているのかを聞くことで、おおよそのセキュリティレベルが推測できます。

AWSやAzureなどのクラウド事業者が提供しているセキュリティサービスや、セキュリティに特化したSaaSなど多くのサービスがある中で、自社のシステムに必要な要件を洗い出し、適切なソリューション選定が出来るスキルが求められます。

・パフォーマンスチューニングの実績

クラウド移行では、クラウドのパフォーマンス制約を考慮せず使用サービスが選定されていることがあります。例えばディスクI/Oなどは、クラウドでは上限値がオンプレほど高くないため、パフォーマンス要件を確認する必要があります。

パフォーマンス観点でどのようなサービス選定・アーキテクチャ選定をしたのか、どのような設定を行ったのか、ヒアリングすることが大切です。
パフォーマンス問題は、後からのチューニングには限界があるため、移行時点でパフォーマンス要件を満たすようなアーキテクチャを実装することが大切です。

【無料】クラウド移行の外注先選定を相談する

オンプレミスからのクラウド移行で注意すること

続いては、オンプレミスからクラウドへの移行の際の注意点について紹介します。

OSの互換性があるクラウドかどうか

オンプレミスからのクラウド移行においては、OSやミドルウェアなどの互換性が非常に重要になってきます。例えばクラウドで使用できるOSは、クラウド事業者が提供しているものに限られます。したがって、同じOSの種類でも、オンプレミスで使用しているバージョンがクラウドで使用できないことがあります。OSのバージョンが異なると、その上で動くミドルウェアやソフトウェアが動作しない場合があります。また、動作してもサポート対象外になってしまうこともあります。

そのような環境差異を許容しなければいけない場合に、システムをきちんと動かすためにどのようなOS/バージョンを選定するのかは、知見・実績と愚直なテストの積み重ねの両方が必要です。

データベースマイグレーションはできるかどうか

データベースマイグレーション（データベースの移管・統合）ができるかどうかも、クラウド移行において非常に重要な観点です。こちらもOSと同様に、クラウドで使用できるデータベースエンジンは、クラウド事業者が提供しているものに限られます。したがって、同じデータベースエンジンでも、オンプレミスで使用しているバージョンがクラウドで使用できないことが多々あります。特にクラウドでは、直近の数バージョンのみ使用可能な場合もあるため、注意が必要です。

一方で、データベースのバージョンはマイナーバージョンの違いであれば、マイグレーションが可能で正常に動作する場合もあります。例えばエンジンのバージョンが14.3の場合、メジャーバージョンが14、マイナーバージョンが3の部分です。14.3と14.4など、マイナーバージョンの差であれば互換性がある場合もありますが、14.3と13.3などのメジャーバージョンが異なるとデータベースの仕様も大きく異なるため、移行時には注意が必要です。

データベースマイグレーションには、いくつかのDB移行ソリューションが検討できます。例えばAWS DMS（Database Migration Service）や、Azure Database Migration Serviceなどが挙げられます。しかし、クラウドからオンプレミスのデータベースにアクセスできるようにするなど必要要件が厳しい場合もあるため、使用可否などは十分に検証する必要があります。

パフォーマンス（非機能要件）は満たせるか

クラウド特有のパフォーマンスの課題も考慮した上で、非機能要件を満たすようなサービス選定・アーキテクチャ選定を行う必要があります。クラウド特有の課題としては、先述のディスクI/Oやリージョン選択による物理的な距離の遠さによるレイテンシーなどです。

これらの制約があるものの、クラウド事業者はCDNやエッジコンピューティングなど多くのパフォーマンス改善のためのサービスを提供していますので、必要に応じてそれらを適切に組み合わせ、パフォーマンス要件を満たすことが大切です。

パフォーマンスチューニングは、システム移行後の実施には限界があるので、移行時にきちんとパフォーマンスを考慮したアーキテクチャを実装することが求められます。

セキュリティレベルは満たせるか

クラウドのセキュリティは、クラウド特有の落とし穴があります。例えば、クラウドはデフォルトでインターネットにアクセスできる設定のサービスもあるため、適切な設定を施さないとセキュリティホールになってしまう場合もあります。クラウドサービスには多くの制約があることも理解し、設定出来る範囲の暗号化やロギング、検知の機構をきちんと実装し、求められるセキュリティレベルを満たしていくことが重要です。

また、クラウドはIDとパスワードがわかれば基本的にはどこからでもアクセスできてしまうので、例えばクラウド上のユーザの権限付与を最小限にしたり、ログインを特定のIPアドレスに制限したり、2段階認証を必須にするといったクラウド特有の対策も必要となります。

関連記事：クラウドサービスに情報漏洩リスクはある？トラブルの原因と対策を解説！

【無料】クラウド移行の外注先選定を相談する

オンプレミスからのクラウド移行の失敗パターン

このパートでは、オンプレミスからクラウドへ移行するにあたっての失敗パターンについて紹介します。ぜひ反面教師にして、開発会社選びに役立ててください。

OSの互換性がなかった

OSなどの互換性の問題でミドルウェアやソフトウェアが動かず、システムをクラウド上で動かすことができなかったという事例です。クラウド移行の前のテスト不足が原因です。

クラウドで使用できるOSやそのバージョンは、クラウド事業者が提供しているものに限られるため、使用可能なOSでソフトウェアやミドルウェアがきちんと動作することを、多角的な視点からテストする必要があります。

データベースマイグレーションできなかった

データベースエンジンやそのバージョンの違いによって、データベースのマイグレーションが出来なかったパターンです。クラウドで使用できるデータベースエンジンは、クラウド事業者が提供しているものに限られるため、少なくともマイナーバージョンの違いを許容しなければならない場合もあります。また、使用を想定していたDB移行ソリューションが、使用できなかったという場合もあります。DB移行ソリューションにはネットワークなどの要件や制約が多く存在するため、仕様が本当に可能なのか、オンプレミス側への一時的な接続は、社内のルール的に許容できるかなどを確認する必要があります。

パフォーマンス（非機能要件）を満たせなかった

システムの非機能要件で定めているパフォーマンスが、クラウドに移行したことで満たせなくなったパターンです。ディスクI/Oやリージョン選択によるレイテンシーなど、クラウド特有のパフォーマンスの制約があります。パフォーマンスを移行前のテストできちんと検証し、サーバのスペックの選定やエッジコンピューティングサービスの使用など、クラウドとITインフラの知識を総動員させてパフォーマンス要件を満たせることを確認した上で移行に臨みましょう。パフォーマンスは、システム移行後の後手の対応になることなく、移行時にきちんと対応することが大切です。

セキュリティレベルを満たせなかった

クラウドサービスは設定できる項目が決まっているため、例えばログや暗号化、ネットワーク要件が満たせない場合もあります。採用するクラウドやそれらのサービスで設定可能な項目をきちんと洗い出し、設計時点でセキュリティレベルを満たせるかをきちんと確認する必要があります。セキュリティレベルを担保するためには、クラウドの別サービスにシステムを移行するなどの大規模作業が発生する場合が多いため、移行の前の設計やテストできちんとセキュリティレベルを確認することが大切です。

【無料】クラウド移行の外注先選定を相談する

オンプレミスからのクラウド移行まとめ

オンプレミスやクラウド移行の概要と、クラウド移行に求められる知見や経験、クラウド移行の注意点や失敗パターンについて紹介しました。

• ネットワーク、OS/ミドルウェア、アプリケーションの知見・実績
• システムや構成、言語などの類似性の高いクラウド移行の知見・実績
• クラウドのセキュリティの知見・実績
• クラウドのパフォーマンスの知見・実績

このような観点で開発会社を見極めていきますが、テックスタックや技術力を見極めるためには、ある程度のクラウドの前提知識が必要となるケースも少なくありません。

クラウド移行の開発会社選びに困った場合は、システム幹事にご相談ください。予算や目的から最適な会社をご紹介します。相談料などは一切かかりません。

【無料】オンプレミスからのクラウド移行が得意な会社を紹介してもらう

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください