5.2クラウドサービスモデルと移行

クラウド活用を設計するシステムアーキテクトは、「どこまでを自社で管理し、どこからをクラウド事業者に委ねるか」という責任分界を明確にした上でサービスモデルを選び、既存システムをどう移行するかという移行戦略を、運用負荷・カスタマイズ要件・移行にかけられる時間とコストのトレードオフから判断する必要があります。この節ではその2つの判断軸を学びます。

5.2.1IaaS/PaaS/SaaSの責任分界

• IaaS（Infrastructure as a Service）＝仮想サーバ・ストレージ・ネットワークといったインフラ層をサービスとして提供し、その上のOS・ミドルウェア・アプリケーションは利用者が管理する形態。事業者はハードウェアと仮想化基盤までの責任を負い、利用者はOSのパッチ適用・ミドルウェアの構成・アプリケーションの実装と運用まで自ら担う。既存のオンプレミス構成に近い形でOSレベルの自由な制御が必要な場合に適する。
• PaaS（Platform as a Service）＝OS・ミドルウェア・実行環境まで事業者が管理し、利用者はアプリケーションのコードとデータに集中できる形態。OSパッチ適用やミドルウェアの構成管理を利用者が行わずに済むため運用負荷を大きく抑えられるが、事業者が定めるランタイムやフレームワークの制約内でしか構成できず、独自のOSレベル制御やミドルウェアの細かなカスタマイズはできない。
• SaaS（Software as a Service）＝完成されたアプリケーション機能そのものを事業者が提供し、利用者は設定とデータ入力のみを担う形態（例：クラウド型グループウェア）。運用負荷は最小だが、業務要件に合わせた独自のロジック実装余地はほぼない。責任分界は「事業者がインフラからアプリケーションまで、利用者はデータと利用者アカウントの管理まで」という整理が基本。

5.2.2パブリック/プライベート/ハイブリッドクラウド

• パブリッククラウド＝クラウド事業者が不特定多数の利用者に共通基盤を提供する形態。初期投資が不要でスケーラビリティに優れるが、他テナントと基盤を共有するため業界固有の厳格な規制やデータ隔離要件によっては採用しにくい場合がある。プライベートクラウド＝特定の組織専用に基盤を構築・運用する形態で、規制対応やカスタマイズの自由度は高いが、自社/専有分の設備投資と運用負荷が発生する。ハイブリッドクラウド＝両者を組み合わせ、規制上オンプレミスに残す必要があるデータ・処理はプライベート側に、スケーラビリティが必要な処理はパブリック側に配置するなど、要件ごとに使い分ける構成。

5.2.3クラウド移行戦略：リフト&シフトとリアーキテクト

• リフト&シフト＝既存システムの構成・アーキテクチャをほぼそのままクラウドの仮想サーバ（IaaS）上に移す移行方式。アプリケーションの作り直しが不要なため移行の期間とコストを抑えられるが、オンプレミス時代の構成をそのまま踏襲するため、クラウドのスケーラビリティやマネージドサービスの恩恵を十分には得られない。移行の期限が短い、または改修予算が限られる場合に選ばれる。
• リアーキテクト＝クラウドのマネージドサービス（PaaS・サーバレス・マネージドDB等）やスケーラブルな構成を前提に、アプリケーションの構造を作り直す移行方式。オートスケールやマネージドサービスの運用負荷削減といったクラウドネイティブな恩恵を最大限に得られるが、アプリケーションの改修に相応の期間・コスト・技術検証が必要になる。長期運用を見据え、スケーラビリティや運用効率を重視する場合に選ばれる。
• 移行方式の選定は「移行にかけられる期限・予算」対「移行後に得たいクラウドネイティブな恩恵の大きさ」のトレードオフで判断する。段階的に、まずリフト&シフトで移行を完了させ、その後優先度の高いコンポーネントから順にリアーキテクトしていくという二段階の移行戦略も実務では広く採られる。

あるシステムアーキテクトが、オンプレミスで稼働する自社の基幹業務システムをクラウドへ移行するプロジェクトを担当しているとします。経営層からは「半年以内に移行を完了させたい」という期限が示された一方、このシステムには独自開発した特殊なミドルウェア連携が組み込まれており、事業者が提供するPaaSのランタイム制約の中には収まらないと判明しました。この時点で、PaaSやSaaSは独自ミドルウェアを自由に構成できないため不採用と判断し、OSから上を利用者が管理できるIaaSを土台に選定しました。次に移行方式を検討したところ、半年という短い期限とアプリケーションを作り直す予算が確保できていないことから、まずは既存の構成をほぼそのままIaaS上の仮想サーバへ移すリフト&シフトで期限内の移行を完了させることにしました。ただし、リフト&シフトだけではオンプレミス時代のスケーラビリティの低さがクラウド移行後も残ってしまうため、移行完了後のフェーズ2として、アクセス集中が課題になっている一部のコンポーネント（例えば注文照会機能）だけをマネージドサービス前提の構成にリアーキテクトし、段階的にクラウドネイティブな恩恵を取り込んでいく計画を経営層に提示しました。また、このシステムが扱う顧客の機密データの一部には業界規制によりオンプレミス相当の隔離環境での保持が義務付けられていたため、当該データ処理だけはプライベートクラウド側に残し、それ以外の処理はパブリッククラウド側に配置するハイブリッド構成とすることも合わせて決定しました。このように、責任分界（独自ミドルウェアが使えるか）・移行の期限とコスト・規制上のデータ隔離要件という複数の制約を突き合わせ、単一の「正解」ではなく段階的な移行計画を設計することが、クラウド移行におけるアーキテクトの核心的な判断です。

5.2.4この節のまとめ

• IaaSはOSから上を利用者管理・PaaSはOS/ミドルウェアまで事業者管理・SaaSはアプリ機能ごと提供、と責任分界の境界が異なる
• 規制上オンプレミス相当の隔離が必要なデータはプライベートクラウド側、スケーラビリティが必要な処理はパブリッククラウド側というハイブリッド構成も実務で用いられる
• リフト&シフトは低コスト/低改修で移行完了を優先、リアーキテクトはクラウドネイティブな恩恵を最大化＝要件・期限・予算で使い分ける