2016.05.19 2022.10.29

オンプレミス(自社運用)環境をクラウドへ移行するときにありがちな失敗パターン

kuni

若い時(20代)は全く興味なかったのに、子供が生まれてから急にキャンプやバーベキューなどアウトドアの魅力にどっぷりハマっている代表の国本です。

モバイルアプリのバックエンドやフロント系のWebサービス以外にも、これまでオンプレミス(自社運用)で運用していた業務系のエンタープライズなシステムをAWSなどのクラウドに移行したいというご相談をお受けすることが最近非常に多いです。

このようにオンプレミスからクラウドへの移行を検討されている場合、新規にゼロベースでシステムを設計・開発する場合と異なり、既存の商用プロダクトや業務系のシステムをクラウド上で稼働させるような御希望が多く、必然的に商用プロダクトの移行サポートや現在開発に携わっている開発会社を交えてのプロジェクトとなりますが。

これまでオンプレミス前提でシステム基盤を長らく設計・構築されているシステムインテグレータや開発会社の場合、オンプレミス前提の設計方式をそのままクラウドでも適用しようとし、結果クラウド環境での最適化に失敗される例がかなり多く見受けられます。

そこで今回はオンプレミスで開発・運用してきたチームが、クラウドへ移行するときにありがちな失敗パターンをいくつかあげてみようと思います。

Contents

バッファを持たせたジャブジャブなスペックサイジング
マネージドサービスを活用せず何でもかんでも独自実装
ステートフル前提で物理ノード的な扱いを行う
クラウドへの移行をスムーズに、より素早く実現するために

バッファを持たせたジャブジャブなスペックサイジング

オンプレミスでは物理サーバはもとより、仮にvSphereなどの統合的な仮想環境が存在していたとしてもシステム開発に携わる開発者が、アプリケーションを稼働させるサーバ環境のスペックを柔軟に変更させてもらえるような権限を持っている事は少ないかと思います。

よってオンプレミスでは、初期のサーバ構築の段階で、いきなり想定されるピークを見越したオーバなサイジングが行われる傾向があり、AWSなどのクラウド導入時にもそのようなサイジングを行っている会社がありますが、これはクラウドの大きなメリットである弾性とスケーラビリティを活かしておらず、コストを増加させている要因となります。

AWSをはじめとするクラウドでは稼働させるサーバのスペック変更を柔軟かつ迅速に行えるため、初期はミニマム構成でスタートし、負荷状況を可視化・確認しながら必要に応じてスペックを変更するという方法がお財布に優しくクラウドのメリットを享受できる運用です。

マネージドサービスを活用せず何でもかんでも独自実装

AWSを始めとするクラウドでは、オブジェクトストレージやリレーショナルデータベース(RDB)、キューイングの仕組みなど、システム構築で非常によく使われるコンポーネントやサービスの運用・管理を、クラウド事業側で担ってくれるマネージドサービスが多数存在します。

これらマネージドサービスを上手に活用することで、ビジネスのコア部分の開発に注力し、迅速にシステムを立ち上げることが可能ですが、オンプレミス前提の会社の場合、マネージドサービスを利用すれば作る必要が無い部分まで独自に実装し、開発コストはもとより、その後の運用コストを跳ね上げている設計を見ることがあります。

もちろん、マネージドサービスでは実現が難しいケースもあるとは思いますが、クラウドへの移行後の運用を見据え、マネージドサービスにて代替できる箇所は無いかという点をきっちり検討することが重要です。