導入部
こんにちは！テックリードの皆さん、そしてこれからシステム設計を担うエンジニアの皆さん。
「老朽化したオンプレミス環境のレガシーシステムを、最新のクラウドへ移行してほしい」——現場でこんなオーダーを受けたことはありませんか？
本連載では、とあるレガシーな受発注システム（VB6 / ClassicASP）を、最新の.NET環境とGoogle Cloud（GCP）へマイグレーションした架空のプロジェクト「SampleProject」を題材に、「理想のクラウドネイティブ」と「現実の泥臭い制約」の間で、アーキテクトがどう最適解を導き出したのかを紐解いていきます。
今回は第0回として、今後の技術選定ドラマを楽しむための「インフラとWebシステムの基礎知識」をおさらいします。
【対象となる前提環境】
- 移行前：Windows Server, IIS, SQL Server, 物理サーバー（オンプレミス）
- 移行後：.NET 8 (C#), Google Cloud (GCP)
- 対象読者：C#エンジニア、クラウド移行の技術選定に興味がある方
1. Webシステムの「3層構造」とOSの壁
【起結】⏱ 10秒まとめ：本章の結論
Webシステムは「フロント・バック・DB」の3層構造でできています。クラウド移行において、既存システムが「Windows」に依存しているか「Linux」で動くかが、最初の巨大な分岐点になります。
【承】🌩 課題：こんなこと困るよね。難しいよね。
「とりあえずGCP（クラウド）に持っていけば、サーバー管理から解放されて安くなるんでしょ？」
経営層からよく言われるこの言葉、現場のエンジニアとしては頭が痛いですよね。
特に歴史の長いエンタープライズシステムでは、WebサーバーにMicrosoft純正のIIS（Internet Information Services）が使われていることがほとんどです。IISや、そこで動く帳票ツール（Windowsの特定フォントに依存するものなど）は、Windows環境にベッタリと依存しています。これを「安くて軽量なLinuxサーバー（ApacheやNginx）」にそのまま載せ替えることは魔法でも使わない限り不可能です。
【転】💡 解決策：採用理由と他の選択肢
既存のWindows依存システムをクラウド化する際、アーキテクトは以下の選択を迫られます。
-
選択肢A：完全Linux対応への書き換え（見送り）
- IISをNginx等に変え、帳票ツールもLinux対応のものに買い替え、フォントもすべて代替品を探す。
- 見送り理由： クラウドの恩恵は最大化できるが、ソースコードの全面書き換えと互換性テストが発生し、移行コストとバグ発生リスクが天文学的に跳ね上がるため。
-
採用案：Windows Serverのままクラウドへ移行
- 採用理由： IISや既存のWindows向けライブラリ（C#の資産）をそのまま動かすことを最優先とし、まずは「インフラだけをクラウドに乗せ替える（リフト＆シフト）」ことで、プロジェクトの頓挫リスクを最小限に抑えるため。
【結】💻 具体例：Microsoftの「三種の神器」構成
クラウド上でも、あえて既存のオンプレミスと同じ「鉄板構成」を構築します。
[ インターネット ]
↓
【 プレゼンテーション層 (Webサーバー) 】
・OS: Windows Server
・ミドルウェア: IIS (Internet Information Services)
↓
【 アプリケーション層 (バックエンド) 】
・フレームワーク: ASP.NET Core (.NET 8)
↓
【 データアクセス層 (データベース) 】
・DB: SQL Server
【補足】🔰 初心者向け解説：3層構造とは？
レストランに例えると分かりやすいです。
- フロント（Webサーバー）： お客さんの注文を聞く「ウェイター」（IISなど）。
- バックエンド（アプリ）： 注文に従って料理を作る「シェフ」（C#などのプログラム）。
- データベース（DB）： 食材を安全に保管しておく「巨大な冷蔵庫」（SQL Serverなど）。
もし「ウェイター（IIS）」を突然「外国語しか話せない人（Linux）」に変えたら、厨房は大パニックになりますよね。
2. インフラの進化論：オンプレ、VM、そしてコンテナ
【起結】⏱ 10秒まとめ：本章の結論
インフラは「物理（オンプレ） → 仮想（VM） → コンテナ」と進化してきました。しかし「コンテナ＝Linux」という暗黙のルールがあり、Windowsシステムをコンテナ化するのは茨の道です。
【承】🌩 課題：こんなこと困るよね。難しいよね。
「最新のクラウドを使うなら、やっぱりコンテナ（Docker）化して、サーバーレスで動かしたいよね！」
技術記事を読んだ若手エンジニアからよく提案される構成です。確かにコンテナは起動が爆速で、スケールも容易です。
しかし、ここに大きな落とし穴があります。世の中のクラウドマネージドサービス（手放しでコンテナを動かしてくれる便利サービス）の99%は「Linuxコンテナ」しか受け付けてくれません。 Windowsコンテナ自体は技術的に存在しますが、運用難易度が高く、サーバーレス環境では実質的にサポート外になることが多いのです。
【転】💡 解決策：採用理由と他の選択肢
Windowsベースのレガシーシステムをどうクラウドに配置するか、ADR（アーキテクチャ・ディシジョン・レコード）の観点ではこうなります。
-
選択肢A：無理やりWindowsコンテナ化する（見送り）
- 見送り理由： クラウドの便利機能（サーバーレス等）が使えず、結局自力でKubernetes等の重い基盤を運用する羽目になるため。
-
採用案：素直に仮想マシン（VM / Compute Engine）を使う
- 採用理由： コンテナの夢は一旦捨て、クラウド上に「Windows OSが丸ごと入った仮想の箱（VM）」を構築する。OSのアップデートパッチ当てなどの運用手間は残るが、既存資産が100%確実に動くという圧倒的な安心感を取る。
【結】💻 具体例：インフラの形態と特徴の比較
| 形態 | 実体 | 管理の手間 | Windows対応 |
|---|---|---|---|
| オンプレミス | 物理的なサーバー機 | ハードウェアの故障対応まで必要 (激重) | ◎ 自由自在 |
| VM (仮想マシン) | クラウド上の仮想的なPC | OSのパッチ当てや再起動が必要 (中) | ◎ 普通に動く |
| コンテナ | OSを共有するアプリの箱 | インフラ管理はクラウドにお任せ (楽) | △ 茨の道 |
【補足】🔰 初心者向け解説：仮想マシン（VM）とコンテナの違いとは？
- 仮想マシン（VM）： 「一軒家を建てる」イメージ。土地（インフラ）の上に、基礎から家（OS）を丸ごと建てます。何でもできますが、建てるのも維持するのも重たいです。
- コンテナ： 「お弁当箱」のイメージ。おかず（アプリ）と調味料（動かすために必要な設定）だけを詰めたパッケージ。OSという重たい箱はクラウド側が用意したものをみんなで相乗りして使うため、軽くてどこへでも持ち運べます。
3. Google Cloud（GCP）の登場人物たち
【起結】⏱ 10秒まとめ：本章の結論
GCPには用途に応じた強力なサービスが揃っています。技術選定とは「どれが一番凄いか」を決めるのではなく、「今の自分たちの制約（資産）に合うのはどれか」をマッチングする作業です。
【承】🌩 課題：こんなこと困るよね。難しいよね。
クラウドのカタログを見ると、魅力的なサービスが並んでいます。
「管理不要で勝手に増減する『Cloud Run』を使いたい！」
「Google最強のデータベース『AlloyDB』を使えば、性能が100倍になるらしい！」
しかし、第1章・第2章で確認した通り、私たちの「SampleProject」は 『Windows Server』『IIS』『SQL Server』 という強力な制約（縛りプレイ）を抱えています。キラキラした最新サービスを使いたい衝動と、現実のシステム要件が激しく衝突します。
【転】💡 解決策：採用理由と他の選択肢
GCPへ移行するにあたり、どのサービスを組み合わせるべきか。
-
選択肢A：Cloud Run ＋ AlloyDB（見送り）
- 見送り理由： Cloud RunはLinuxコンテナ専用。AlloyDBはPostgreSQL互換。これを採用するには、システムを根本から別言語・別設計で作り直す必要があり、移行プロジェクトとしては破綻する。
-
採用案：Compute Engine ＋ Cloud SQL for SQL Server
- 採用理由： 既存のインフラ構成を、GCPのサービスでそのまま「エミュレート（再現）」できる手堅い組み合わせ。VM上でWindowsとIISを動かし、データベースは管理の手間を省けるマネージド版のSQL Serverを採用する。
【結】💻 具体例：今回活躍するGCPのスタメンたち
今回のプロジェクトで採用された（および比較検討された）GCPの主要サービスのマッピングです。
-
Compute Engine (CE)
- 役割: 仮想マシン（VM）。今回はここにWindows Serverを入れてWebサーバーとする。
-
Cloud SQL (for SQL Server)
- 役割: クラウドが自動でバックアップなどを取ってくれる、手放し運用可能なSQL Server。
-
Cloud Run (今回は見送り)
- 役割: コンテナをサーバーレスで動かす大人気サービス。（※Linuxコンテナ必須のため無念の不採用）
-
AlloyDB (今回は見送り)
- 役割: PostgreSQLと互換性を持つ、GCPが誇る超高速DB。（※SQL Serverからの移行難易度が高すぎたため不採用）
【補足】🔰 初心者向け解説：マネージドサービスとは？
「マネージド（Managed）」とは、「面倒なことはクラウド業者が代わりにやってあげるよ」という意味です。
例えば、自分でVMにデータベースをインストールすると、夜中にバックアップを取ったり、故障時に再起動したりする作業を自力でやる必要があります。しかし「Cloud SQL」のようなマネージドサービスを使えば、ボタンをポチッと押すだけで、Googleの凄腕エンジニアたちが裏で一生懸命お世話をしてくれる状態になります。
単語一覧 (Glossary)
- レガシーシステム: 作られてから長い年月が経ち、技術が古くなったり、中身が複雑になりすぎて手を加えにくくなったシステムのこと。「負の遺産」と呼ばれることも。
- リフト＆シフト (Lift and Shift): システムをクラウドへ移行する際の手法の一つ。まずは既存の環境をそのまま（Lift）クラウドのVM等へお引越しさせ、あとから徐々にクラウドに適した形へ改修（Shift）していく手堅いアプローチ。
- ADR (Architecture Decision Record): 「なぜその技術や設計を選んだのか（あるいは選ばなかったのか）」という意思決定の背景や理由を、後から来た人が読んでも分かるように記録しておくドキュメントのこと。
次回、第1回ではいよいよ「SampleProject」が始動します。
「オンプレミスのレガシーシステムを、どうやって安全にクラウドへ持っていくか？」
アーキテクトである上司が下した「ある決断」と、それに隠されたビジネス的戦略の真髄に迫ります。お楽しみに！
