🛠️

オンプレ→クラウド移行で絶対に外せない“設計”のポイントまとめ

に公開
アーキテクチャ
設計
クラウド
移行
オンプレ
idea

はじめに

オンプレで長く運用してきたシステムをクラウドへ移行する――
一見シンプルな作業に見えて、実際に着手すると
「どこから考えればいいのか」途端に輪郭がぼやけてきます。

そこで本記事では、クラウド移行で“最低限ここは押さえておきたい”という観点を
見積・設計・テスト/移行・運用の4フェーズに分けて整理しました。
今回はその中でも 「設計」フェーズについて解説します。

現場でつまずきがちなポイントにも触れながら、
できるだけ多くの環境で応用できる内容を目指しています。

これからクラウド移行を検討する方、
すでにプロジェクトに関わっている方の参考になれば幸いです。

筆者について

入社から10年ほど、オンプレシステムの開発・保守・運用に携わってきました。
あるタイミングでクラウドを扱う部門へ異動となり、
オンプレ歴の長いエンジニアがクラウドへ踏み出す際に感じたギャップや気付きをもとに、
本記事を執筆しています。

クラウド移行で“最初に”考えるべき設計のポイント

構成検討

クラウド化における構成見直しポイント

オンプレからクラウドにマイグレーションする場合、
オンプレの構成そのままでクラウド側も設計してしまうのが簡単で抜け漏れがないです。

ただし同時に、クラウド特有の機能を活かせない“移行コストだけ高い構成”にもなりがちです。
まるっきりそのままだとクラウドのメリットを受けづらいので、
以下観点で見直しができるとベターかなと思っています。

クラウド構成検討における見直しポイント

  • サーバ台数の削減が可能か
  • NW 分割（サブネット）を用途別に再設計できないか
  • クラウドのストレージサービス(ライフサイクル管理等)を効率的に利用できないか
  • マネージドサービスで機能の置き換えができないか(名前解決やロードバランサー等)
  • バッチ化/ジョブ化している処理をクラウドの仕組みに統一できないか(ログ管理等)

特にサーバ台数削減やストレージの効率化は、
長い目で見た場合のクラウド利用料に大きく影響が出てきますので積極的に検討すべき内容です。

また、地味に見えるかもですがバッチ化/ジョブ化されている処理がオンプレのままだと
後々管理が煩雑になり大変です。
AWS なら Lambda や EventBridge に統一しておくと、
あとからの運用・障害対応が段違いで楽です。

キャパシティ設計

リソース検討

クラウドのメリットの一つとして、
マシンスペックやディスク容量を簡単に増強できることが挙げられます。
そのため、「リソースが足りなければ後から足せばよい」と考えがちです。

ただし、クラウドは
リソース量 = 利用料金
なので、オンプレのバッファをもったサイジングをそのままやるとコストが跳ね上がります。

クラウド化のキャパシティ設計は、将来的なデータ増加量はもちろん、

  • CPU
  • メモリ
  • システム領域のディスクサイズ
    等も改めて見直してあげるとコストメリットが出てきます。

オンプレでは後から増強が難しいためバッファを多く見ますが、
クラウドでは 最小構成（ミニマムスタート）→ 必要に応じて増強 の考え方が適しています。
私の経験上、最小構成としてもリソースが足りなくなるといったことはほぼほぼないです。

データ量検討

業務データについてはオンプレ同様、
将来的にどのくらいデータが増えていくかの見積りは必要です。

ただし、クラウドの場合単純にディスクサイズを増量するのではなく、
AWSでいうS3のようなストレージサービスを利用できる点も意識すべきです。
ストレージサービスであれば基本的に上限はないので、
ディスク容量を節約することができるかもしれません。
(もちろんデータの性質やレスポンス速度にもよりますが...)

上記のように、キャパシティ設計も少しオンプレとは考え方を変えて、
より最適な設計をできると余計なコストがかからず、
クラウドのメリットを存分に受けられるようになります。

性能設計

性能設計の進め方

オンプレ→クラウドに限らずですが、
プラットフォームを更改する場合性能要件を満たせるかということは
しっかりと見ておく必要があります。

とはいえ、作って確認する前に “机上で性能を見極める” のは本当に難しいですし、
私自身もこの性能設計でもめることが多いように思います。

私なりに整理した検討の流れは以下の通りです：

  1. 必要な性能指標をヒアリング
    　　(応答速度、スループットなど）

  2. システムの処理を分解する
    　　(ユーザー→クラウド、サーバ→ストレージ、DB→アプリなど）

  3. 各経路ごとにボトルネックを洗い出す

分解の単位としては、
「ユーザー→クラウドの経路」「サーバ→ストレージの経路」等
通信の経路で分けると何が性能に影響するのか整理できてよいです。
分解、整理ができたら製品やサービスのスペックやNW帯域を見ながら
性能要件を満たせるのか確認する流れです。

分解の例としては以下図を参照。

信頼性設計

SLA(サービスレベルアグリーメント)

信頼性設計は「壊れる前提でどう備えるか」を決める部分です。
システムも結局はモノなので、どこかで壊れるタイミングはやってきます。
オンプレの場合、あらゆる機器を冗長構成にしたり、サーバもクラスタ構成にしたりと
システムの重要度や緊急度によって自分たちで決めることができます。

ただクラウドサービスを利用する場合、
クラウド事業者の SLA（サービスレベルアグリーメント）が前提になります。
そのサービスレベルとシステムの重要度・停止許容時間（RTO）を見比べて
クラウド側の構成を決めていく必要があります。

残念ながらSLAが信頼性要件満たさない場合には、

  • 別リージョンに DR（災対）環境を構築
  • バックアップデータを別環境へ複製
  • サーバ・DB・ストレージの分散構成を強化

等別の環境も利用して信頼性を高めていく判断も必要です。

セキュリティ設計

公開前提にあわせたセキュリティ検討

クラウドのセキュリティ設計は、
オンプレの「閉じたネットワークで守る」感覚の延長ではうまくいきません。
構成要素が外に開いているぶん、
セキュリティサービスを1つ1つ吟味して利用を検討していく必要があります。

考慮すべき領域はざっくり以下です：

  • アイデンティティ管理（IAM）
  • データ保護
  • ネットワーク防御(ACLやIDS/IPS、WAF等)
  • 監査・脆弱性管理

こうしたクラウド・ネイティブの仕組みは豊富ですが、
全部乗せるとコストも運用負荷も跳ね上がります。
そのため、必要性・脅威・運用の現実 を踏まえて取捨選択していくことになります。

特にオンプレ側が「閉域だから最低限のACLでOK」という文化だった場合、
クラウド移行で初めて“敵に見つけられる”前提の設計が必要になります。

設計フェーズの要点をもう一度整理

最後に設計フェーズで最低限気を付けたほうが良いポイントについてチェックリスト化しました。
クラウド化を検討する際に参考になれば幸いです。

✅ 設計フェーズ チェックリスト

▼ 構成設計
　■ サーバ台数の削減余地
　■ NWサブネットの再設計
　■ マネージドサービスの置き換え可能場所
　■ ストレージ戦略（EBS / S3）の適正化
　■ バッチ処理・ジョブ管理方式の置き換え可能検討

▼ キャパシティ設計
　■ サーバリソース(CPU、メモリ、ディスク)の見直し
　■ データ増加量の将来予測
　■ ストレージサービス利用可否検討

▼ 性能設計
　■ 要求性能指標(応答速度・スループット)の明確化
　■ 処理経路ごとにボトルネック候補の洗い出し
　■ ネットワーク帯域のチェック

▼ 信頼性設計
　■ 利用サービスの SLA 確認
　■ システムの RTO/RPO と SLA の整合性確認
　■ DR構成の要否判断

▼ セキュリティ設計
　■ IAM/権限管理のルール整理
　■ データ暗号化（保存時・通信時）の有効化
　■ ACLの要件整理
　■ その他セキュリティサービスの取捨選択

Discussion