オンプレミスからクラウドへの移行で、設計ミスに不安を感じる担当者もいるのではないでしょうか。

クラウド環境の構築は、単純にサーバーの置き場所を変える作業ではありません。メリットを最大限に引き出すためには、オンプレミスとは異なる考え方と進め方の理解が必要です。

そこで本記事では、これからクラウド設計を始める担当者に向けて「クラウド設計の具体的な進め方」を7ステップで解説します。オンプレミスとの違いも解説するので、ぜひ参考にしてみてください。

クラウド設計の基礎と重要性

クラウド設計は、移行後の安定稼働・コスト管理・セキュリティに直結する重要なフェーズです。サービスの安定稼働や障害の発生リスク、さらには費用対効果も設計の質に大きく左右されます。

クラウドはオンプレミスと比較して責任範囲の考え方が異なるため、設計段階で運用ルールや責任の範囲をあいまいにすると想定外のトラブルにつながる可能性も少なくありません。そこで、まずはクラウド設計が重要視される理由や押さえるべき基本的な観点を解説します。

クラウド設計が重要視される理由

クラウド環境における設計ミスは、運用コストの増加やセキュリティ事故につながる可能性があります。構築したクラウド基盤の設計を修正するには、システムの停止を伴う大規模な改修が必要になるケースも少なくありません。

また、クラウドならではのメリットを最大限に生かすためには、オンプレミスとは異なる構成や機能の理解も必要です。たとえば、システムの負荷に応じてサーバー台数を自動的に増減させる「オートスケーリング」機能は便利ですが、初期設定を誤ると不要な運用コストの増加につながる可能性もあります。

サービスの停止リスクや運用コストを最小限に抑えるためには、自社の要件に適したクラウド設計が重要です。

クラウド設計で押さえるべき基本的な観点

クラウド設計は、以下のような前提となる要件の明確化から始めます。

• 事業要件
• システム要件
• セキュリティ要件

オーバースペックによるコストの増加や性能不足による業務・サービスへの影響など、要件定義があいまいな状態では設計ミスによるリスクも想定されます。また、後述する責任共有モデルや可用性など、クラウドの特性を設計に反映させることも重要です。

設計の段階から運用フェーズを見据え、監視やバックアップを「誰が、いつ、どのように対応するか」も事前に決めておきましょう。

クラウド設計におけるオンプレミスとの違い

クラウドでは物理的な機器を自社で所有しないため、設計の手順や考え方がオンプレミスとは異なります。とくに以下の観点は、クラウド特有の設計方針に大きく影響する要素です。

• 可用性・冗長性
• 責任共有モデル
• スケーラビリティ（拡張性）
• コスト

ここからはオンプレミスとの比較をもとに、クラウド設計の基本を解説します。

可用性・冗長性の考え方

可用性と冗長性における最大の違いは、物理的な故障への対策を「誰が実施するか」という観点です。

物理的なハードウェアを扱うオンプレミスの場合は、故障が発生してもシステム全体が止まらないように対策します。たとえば、サーバー機器やネットワーク回線の障害時に備えて、以下のような冗長化を自社で設計します。

• サーバーのアクティブ・スタンバイ構成
• HDDのRAID構成
• ネットワーク回線の二重化

一方でクラウド設計では、物理的なハードウェアはクラウド事業者が管理するため、利用者側で物理冗長化する必要はありません。

ただし、クラウドでもシステムが停止する可能性はあるため、複数のアベイラビリティゾーン（AZ）に分散させるなど、クラウド特有の冗長化設計が重要です。

責任共有モデルの考え方

▲出典：責任共有モデル – Amazon Web Services（AWS）

クラウド利用におけるセキュリティと管理の範囲は「責任共有モデル」に基づきます。オンプレミスの場合は、物理的なハードウェアからソフトウェアまで、一貫して利用者（自社）の責任範囲で管理するのが基本です。

一方でクラウドの場合は、責任範囲が事業者と利用者で明確に分かれています。基盤となるハードウェア仮想化基盤の管理はクラウド事業者の責任ですが、アプリケーションやデータ、アクセス権限（IAM）などは利用者側の責任です。

利用者側が責任をもって運用・管理する主な領域は以下のとおりです。

• アプリやデータの管理
• パフォーマンスの監視
• IAM設定や暗号化などのセキュリティ対策

クラウド上の設定ミスによる不具合や情報漏洩などは、利用者側の責任となるため注意しましょう。

スケーラビリティ（拡張性）の考え方

オンプレミスとクラウドでは、スケーラビリティ（※）のアプローチも異なります。

※利用者数やデータ量の増減にあわせて、システムや機器を拡張・縮小できる柔軟性

オンプレミスの場合は、運用時の最大負荷を想定した機器の選定が必要です。 スペック不足の対処にはCPUやメモリを増強する「スケールアップ」が主流であり、クラウドに比べて構成変更に伴う工数や追加費用が多くかかります。

クラウドの場合は、運用時の負荷にあわせてリソースを増減させる「スケールアウト」が可能です。また、オートスケーリングを活用すれば、負荷に応じてサーバー台数を動的に増減できます。クラウドの設計では、負荷に応じて自動的に調整できる仕組みの導入も検討してみましょう。

コストの考え方

オンプレミスとクラウドでは、コストの考え方や会計上の扱いも大きく異なります。

オンプレミスの主なコストは、ハードウェアやソフトウェアライセンスの初期投資（CAPEX：資本的支出）です。会社の資産として扱われる機器は、一般的に数年かけて減価償却を行います。先行投資となるため、利用頻度が低くても費用は戻りません。

一方でクラウドの主なコストは、サービスの利用期間に応じて支払う従量課金（OPEX：運用コスト）です。利用状況やリソースに応じてコストが変動するため、毎月の利用料として都度計上します。

クラウドを活用すれば物理サーバーの購入費を削減できますが、移行作業費やライセンス費用など、導入時に発生するコストには注意が必要です。

クラウド設計の進め方

ここからは、クラウド設計の進め方を「7ステップ」で解説します。複雑に見える設計フェーズも、段階ごとにタスクを分解すれば対応すべき手順の整理が可能です。

クラウドの構築作業で「機能が足りない」「予算があわない」といった問題に直面すると、軌道修正に多大な工数がかかります。各フェーズで決定すべき内容を理解しながら、手戻りのないスムーズな移行計画を立てましょう。

1. 要件定義

要件定義では、構築するシステムに「何を、どのレベルで求めるのか」を明確にします。とくに、以下4つの観点で要件を決めると効果的です。

• 可用性
• 性能・拡張性
• セキュリティ
• 運用方針

可用性

可用性とは、システムが停止せずに動き続ける能力を指します。24時間365日の稼働が必要なのか、あるいは平日の業務時間中だけでよいのかといった観点です。

また、可用性の具体的な数値目標として稼働率を設定します。たとえば、運用時間100時間のうち、正常に稼働した時間が99.5時間であれば稼働率は「99.5％」です。

性能・拡張性

平常時・ピーク時のトラフィックやリソース負荷などをもとに、性能・拡張性を定義します。将来的なユーザー増加やデータ量の増大も視野に入れながら、どの程度の負荷まで耐えられる設計にするかを決めます。

平常時・ピーク時の見積もりがあいまいな状態では、アクセス集中時にサーバーがダウンする可能性も少なくありません。また、従量課金制が主流となるクラウドでは、オーバースペックなリソースが不要なコストにつながるため注意しましょう。

セキュリティ

以下の観点で、セキュリティにかかわる要件を定義します。

• 遵守すべき業界規制やセキュリティポリシー
• データの暗号化要件やアクセス制御のルール

とくに顧客の個人情報を扱うシステムであれば、より強固なセキュリティ対策が欠かせません。

運用方針

以下の観点で、運用時の方針（ルールや手順など）を定義します。

• 監視すべき項目
• バックアップの頻度
• データの保管期間

それぞれの要件を数値やルールとして言語化し、関係者間で合意形成を図りましょう。

2. クラウドプラットフォームの選定

要件定義で明確になった内容をもとに、クラウドサービスから自社に適したプラットフォームを選定します。一般的には、以下のプラットフォームが主流です。

• AWS：もっとも高いシェアを誇り、豊富なサービスとナレッジの多さが強み
• Azure：Microsoft社の製品と連携しやすい強みがある
• Google Cloud：ビッグデータの分析やAI・機械学習に強みがある

プラットフォームの選定では、自社の要件を「もっとも効率よく実現できるサービスはどれか」の視点が重要です。選定に悩んでしまう場合は、シェアが高く、トラブルシューティングに役立つ情報も豊富なAWSを検討してみましょう。

関連記事：AWSを扱うクラウドエンジニアの探し方｜採用判断のポイントも解説

3. アーキテクチャ設計

アーキテクチャ設計は、要件定義の内容をもとに「クラウドサービスでどのように実現するか」を具体化するフェーズです。一般的なWebシステムであれば、Web・AP・DBの3層をベースに構成を検討します。

たとえば、以下のようにクラウドの可用性・拡張性・セキュリティなどを満たす全体構成を設計しましょう。

• サーバーの分配配置で単一障害点を排除する
• スケールアウトの仕組み化を検討する（オートスケーリングの導入）
• システムの配置や連携を可視化した構成図を作成する

4. ネットワーク設計

オンプレミスと同様に、クラウド上に独立した仮想ネットワークを構築するための設計も必要です。以下のように、セキュリティと拡張性を考慮した観点で設計します。

• プライベートネットワークのIPアドレス範囲を設定する（VPCやVNetなど）
  ※他ネットワークと重複しないように注意が必要
• プライベートネットワークの分割範囲を設定する
  ・ インターネットからアクセス可能なパブリックサブネット
  ・ 直接アクセスさせないプライベートサブネット
• ネットワーク通信のルーティングを設定する
  ・ インターネットの通信経路
  ・ システム間（プライベートサブネット）の通信経路

ネットワーク設計を誤ると「サーバーにつながらない」「情報が意図せず外部公開された」といったトラブルにつながります。通信の流れを整理しながら、誰がどこにアクセスすべきかを的確にコントロールしましょう。

5. セキュリティ設計

クラウドの責任共有モデルに基づき、利用者側が責任をもつ範囲のセキュリティ対策を設計します。以下は、とくに注視しておきたい観点です。

セキュリティ設計の観点としては、外部からの攻撃を防ぐだけでなく、内部担当者の操作ミスや不正利用への対策も必要です。

6. コストの見積もり

設計内容に基づき、クラウドの利用料金を見積もります。利用料金の見積もりには、クラウドの各プラットフォームが提供する公式の料金計算ツールを活用するのが便利です。

• AWS：AWS 料金見積りツール
• Azure：料金計算ツール
• Google Cloud：Google Cloud 料金計算ツール

クラウドの料金体系は、従量課金制が一般的です。リソースや利用状況に応じて変動するため、以下の対策でコストの削減を期待できます。

• オーバースペックなサーバーを選定しない
• 夜間や休日などに不要なリソースを稼働させない

また、常時稼働する環境であれば、長期利用が対象となる割引オプションを活用するのも効果的です。たとえば、Amazon EC2であれば「Savings Plans」や「リザーブドインスタンス」などもチェックしてみましょう。

7. 各種設計書の作成

各フェーズで設計した内容をドキュメント化します。設計のドキュメント化は、チーム内のメンバーで認識の齟齬を防ぐためにも重要な取り組みです。

以下は、作成しておきたい設計書やドキュメントの一例です。

• 基本設計書
• 詳細設計書
• 運用設計書
• 全体構成図
• パラメーターシート

作成したドキュメントは、システムの変更にあわせて継続的に更新します。最新の状態を維持するための運用ルールもあわせて検討しておきましょう。

クラウド設計前に検討したい運用改善のポイント

クラウドの価値を最大限に活用するためには、移行や構築だけでなく運用フェーズを見据えた設計も欠かせません。

クラウドの強みは、状況に応じて構成を変更できる柔軟性です。しかし、設計段階で運用ルールを決めておかないと、非効率な作業が増え、運用負荷が高くなる可能性もあります。

そこで、クラウドならではの運用改善につながる以下の観点を解説します。

• 運用の効率化（IaCの導入）
• 信頼性と可用性の確保（SREの導入）

作業の負担を減らす仕組みやシステムの信頼性を高めるための考え方を取り入れておきましょう。

運用の効率化（IaCの導入）

IaC（Infrastructure as Code）は、インフラの構成をコードとして管理する手法です。IaCによるインフラ構成のコード化には、以下のようなメリットがあります。

• 手作業によるミスの削減
• 変更履歴の可視化
• 迅速な環境構築・同一環境の再構築および展開

TerraformやAWS CloudFormationなどのサービスを活用することで、手作業で対応していた作業を効率化できます。たとえば、テスト環境で動作確認した構成を、そのまま本番環境に適用するといった作業もスムーズです。

設計時には、コードの保管場所や変更履歴の管理方法など、IaCのツール選定や運用ルールの策定を検討しておきましょう。初期の学習コストはかかりますが、長期的な運用コストの削減につながる重要な取り組みです。

信頼性と可用性の確保（SREの導入）

クラウドの運用で必要な取り組みは、システムの停止を防ぐ対策だけではありません。サービスの利用者にとって快適な状態を維持しながら、継続的に運用を改善するための視点も求められます。

システムの信頼性を継続的に改善していくためのアプローチとして、Googleが提唱している「SRE」の導入を検討するのも効果的です。SREを導入することで、システムの信頼性を具体的な数値で評価できます。

また、開発チームと運用チームの連携強化も導入目的の一つです。SREで用いられる具体的な数値（指標）は、開発スピードと運用の安定化のバランスをとるための合理的な判断基準になります。

関連記事：SREがAWS環境で重要視される理由｜導入メリットや基本知識も解説

クラウド設計を依頼するならフリーランスの活用が効果的

設計スキルのあるクラウドエンジニアは、採用市場での需要が高い存在です。しかし、需要の増加により、正社員採用の難易度も高まっています。

こうした状況において、有効な選択肢のひとつがフリーランスの活用です。ここからは、クラウドエンジニアの正社員採用が難しい背景と、フリーランスを活用する具体的なメリットについて解説します。

採用市場でクラウドエンジニアの需要が高まっている

オンプレミス環境からクラウド環境への移行が推進されており、クラウドエンジニアの需要が高まっています。総務省『令和6年版 情報通信白書』でも、パブリッククラウドサービス市場規模が今後も成長していくと示されており、クラウド基盤の整備を急ぐ企業が増えている状況です。

クラウドの構築・運用経験があるクラウドエンジニアは、正社員の採用市場では希少な存在です。採用難易度が高いため、応募が集まらなかったり求めるスキルをもつ人材が見つからなかったりするケースも少なくありません。

また、企業が提示する条件と求職者が求める待遇のミスマッチにより、待遇面で折り合いがつかずに他社との競争に苦戦するケースも想定されます。このような背景があるため、正社員だけにこだわらず、外部委託を含めて柔軟なリソース確保を検討するのが効果的です。

関連記事：クラウドエンジニアの年収相場と採用方法、優秀な人材確保のコツも解説

フリーランスなら専門性に特化した人材と柔軟に契約できる

フリーランスの活用には、以下のようなメリットがあります。

• アサインまでのスピードが早い
• 専門性の高いスキルをもつ人材を確保しやすい
• 契約の柔軟性が高い

上記のようなメリットを重視する場合は、専門のエージェントサービスを活用するのも効果的です。たとえば、クロスネットワークであれば、最短2〜3営業日で人材のアサインをサポートできます。株式会社マイナビの調査によると、正社員（転職者）の募集から採用までにかかる期間は1週間〜2か月が目安です。

また、フリーランスのエンジニアには、複数の企業やプロジェクトに参画した経験のある人材が豊富です。IaCやSREのように、専門性のある技術領域の経験を積んでいる人材も少なくありません。

関連記事：フリーランスのクラウドエンジニアを採用するメリットと方法を徹底解説

クラウド設計を依頼するならクロスネットワークがおすすめ

クラウド設計に失敗しないためのポイントは、サーバーをクラウドに移行するだけではなく、運用まで見据えた観点を反映することです。オートスケーリングによる拡張性の確保やIaC・SREといった運用手法の導入など、設計段階で検討しておきたい項目は多岐にわたります。

しかし、クラウド設計を初めて担当するときには、理解すべき観点の多さに戸惑ってしまうのも事実です。そこで、もし、社内に十分な知見がない場合は、クラウド設計の経験が豊富なエンジニアに外部委託を検討してみましょう。

フリーランス専門のエージェントサービス「クロスネットワーク」では、クラウド設計の経験も豊富なインフラエンジニアを迅速にマッチングいたします。プロジェクト単位でも柔軟に対応しており、初めての業務委託を検討する企業でも安心です。

クロスネットワークに相談いただければ、最短3営業日でのアサインも可能です。また、週2〜3日の依頼にも対応しているので、解決したい課題やご要望に応じて柔軟な外注をサポートいたします。

サービス資料は【こちら】から無料ダウンロードが可能です。柔軟な契約条件でインフラエンジニアを確保するなら、ぜひ気軽に【お問い合わせ】ください。平均1営業日以内にご提案します。