現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～

連載第3回：「DBなんて線を繋ぎ変えるだけでしょ？」が招く大惨事！AlloyDBの誘惑とSQL Serverの密結合

Posted at 2026-08-12

導入部

こんにちは！テックリードの皆さん。
「インフラをクラウド化するなら、データベースもライセンス不要なものに変えようぜ！」と言われて、簡単に引き受けて後悔した経験はありませんか？

連載第3回となる今回は、架空のプロジェクト「SampleProject」において、Google Cloud（GCP）が誇る最強データベース「AlloyDB」がなぜ見送られ、「Cloud SQL for SQL Server」が維持されたのかに迫ります。

「Entity Frameworkを使っているんだから、DB変更なんて設定ファイルを書き換えるだけでしょ？」
そんな私の甘い見通しを打ち砕いた、フレームワークとデータベースの深すぎる関係（密結合）と、上司のアーキテクチャ設計の真髄をお届けします。

【対象となる前提環境】

アプリ：ASP.NET Core (.NET 8), Entity Framework Core
移行前DB：SQL Server
移行先候補：Cloud SQL for SQL Server または AlloyDB for PostgreSQL
対象読者：C#エンジニア、ORMを使えばDB移行は簡単だと考えている方

1. 3層構造の幻想と「三種の神器」の力

【起結】⏱ 10秒まとめ：本章の結論

「WebサーバーとDBを繋ぐ線を切り替えるだけ」でデータベースを移行できるというのは幻想です。特にMicrosoft製品（IIS ＋ ASP.NET ＋ SQL Server）は、エコシステム全体で強力に連携しており、これを崩すと自力で構築しなければならない仕組みが山のように発生します。

【承】🌩 課題：こんなこと困るよね。難しいよね。

GCPへの移行が決まった当初、私はデータベースの選定で興奮していました。
「GCPにはAlloyDB（PostgreSQL互換）という超高性能でコスパ最強のデータベースがある！これを使えば、SQL Serverの高額なライセンス費用ともおさらばできるぞ！」

フロント、バックエンド、データベースという綺麗な3層構造で作られているなら、バックエンド（C#）とDBを繋ぐ線を、SQL ServerからAlloyDBに繋ぎ変えるだけで済むはずです。しかも、データベース操作には「Entity Framework Core（EF Core）」という優秀な翻訳機を使っています。「プロバイダを切り替えるだけでPostgreSQLと会話できるんだから、楽勝でしょ！」と本気で思っていました。

【転】💡 解決策：採用理由と他の選択肢

しかし、アーキテクトである上司の決断は「Cloud SQL for SQL Serverの維持」でした。

選択肢A：AlloyDB（PostgreSQL）への移行（見送り）
- 見送り理由： ライセンス費用は削減できるが、C#のエコシステムがSQL Serverに依存している箇所が多すぎる。DBをPostgreSQLに変えることで、セッション管理やログ出力などの「周辺システム」まで全面的な作り直しとテストが発生し、「レガシーコードの脱却」という本プロジェクトの目的から大きく逸脱するため。
採用案：Cloud SQL for SQL Serverの採用
- 採用理由： 既存の「Microsoftの三種の神器」による恩恵を100%維持する。クラウドでも商用ライセンス費用は発生し続けるが、レガシー移行において「DB層に起因するバグ」を発生させないという安全性を最優先したため。

【結】💻 具体例：Microsoftの「三種の神器」構成図

Microsoft技術をベースにしたエンタープライズ開発では、以下のような構成が鉄板です。これらは息をするように自然に連携できるため、あえてここを崩すことは「自ら茨の道へ進む」ことを意味します。

【インターネット】
      │
      ▼
┌───────────────────────────┐
│ Webサーバー (IIS)         │ ◀ Windows Server専用。Windows認証等と強固に連携。
└─────────┬─────────────────┘
          │
┌─────────▼─────────────────┐
│ フレームワーク (ASP.NET)  │ ◀ C#によるビジネスロジックの頭脳。
└─────────┬─────────────────┘
          │ (EF Coreや専用パッケージによる通信)
┌─────────▼─────────────────┐
│ データベース (SQL Server) │ ◀ データの保存だけでなく、セッションやログの保存先としても活躍。
└───────────────────────────┘

【補足】🔰 初心者向け解説：ORMとセッションって何？

ORM（データ翻訳機）： プログラム（C#）の世界の言葉を、データベース（SQL）の言葉に自動で翻訳してくれる便利なツールです。これがあるおかげで、エンジニアはSQLを直接書かなくてもDBを操作できます。

セッション（ログイン状態の記憶）： 「この人はログイン済みのAさんだ」という一時的な記憶のこと。Webサーバーが複数台ある場合、この記憶をDBなどに保存してみんなで共有する必要があります。

2. ドミノ倒しで崩れる周辺インフラと設定ファイル

【起結】⏱ 10秒まとめ：本章の結論

インターフェース（ILoggerなど）を使ってプログラムコードの変更を防げたとしても、DBを変更すれば「インフラの設定」と「周辺の連携システム」は確実に壊れます。DB移行とは、システム全体の大手術なのです。

【承】🌩 課題：こんなこと困るよね。難しいよね。

「いやいや、プログラム内でちゃんとインターフェース（抽象化）を使って設計しているから、DBが変わってもC#のコード自体は書き直さなくていいはずだ！」
そう反論したくなるエンジニアの気持ち、とてもよく分かります。

確かに、ログ出力に ILogger を使っていれば、DBがSQL ServerからPostgreSQLに変わっても、プログラムの _logger.LogInformation() というコードは一行も直さなくて済みます。これは見事な設計です。

しかし、問題は「設定」と「インフラ」にあります。
例えば、ログをデータベースに書き込むためのライブラリ「Serilog」を使っている場合、設定ファイル（appsettings.json）には「SQL Serverの、このテーブルの、この型（nvarchar等）のカラムに書き込む」というSQL Server特有の泥臭い設定がビッシリ書かれています。

【転】💡 解決策：採用理由と他の選択肢

DBを変更するということは、この泥臭いインフラ設定をすべて再構築することを意味します。

上司は、システムを見渡して以下のような「ドミノ倒し」のリスクを計算していました。

ログ出力設定の崩壊： Serilogの設定をPostgreSQL用（Npgsql）に書き換え、DB側に新しいテーブルを構築し直す手間。
データ分析基盤への波及： 吐き出されたログをBigQueryに転送して集計するパイプラインがある場合、DBのテーブル構造や型が変わることで、その転送システムまでエラーを起こすリスク。
セッション管理インフラの追加： SQL Serverの標準機能（分散キャッシュ）で賄っていたセッション管理が使えなくなるため、新たに「Redis」などのインメモリDBサーバーを構築・運用するコスト。

「AlloyDBのライセンス費ゼロ」というメリットを得るために、これらのドミノをすべて立て直すのは、限られたリスク予算の無駄遣いであると判断したのです。

【結】💻 具体例：変更が困難な「泥臭い設定」のイメージ

プログラムのコードは無傷でも、設定ファイル（appsettings.json）はDB依存の塊です。以下のように、SQL Server特有のデータ型（nvarchar）や独自の列定義が指定されている場合、DB移行は単なる「プロバイダの切り替え」では済みません。

// SerilogのSQL Server向け設定のイメージ（appsettings.json）
"WriteTo": [
  {
    "Name": "MSSqlServer",
    "Args": {
      "connectionString": "AdminContext",
      "tableName": "Logs",
      // ↓ ここにSQL Server特有の泥臭い設定がビッシリ詰まっている
      "columnOptionsSection": {
        "additionalColumns": [
          { "ColumnName": "UserId", "DataType": "nvarchar", "DataLength": 450 },
          { "ColumnName": "RequestPath", "DataType": "nvarchar", "DataLength": 2048 }
        ]
      }
    }
  }
]

【補足】🔰 初心者向け解説：インターフェースの限界って？
「インターフェース」とは、電化製品の「コンセントの穴」のようなものです。
テレビ（プログラム）のプラグの形を統一しておけば、壁の裏の配線（DB）が変わっても、テレビ側は改造せずに使い続けられます。
しかし、壁の裏の配線を「100V（SQL Server）」から「200V（PostgreSQL）」に変えた場合、テレビは無事でも、途中の変圧器（設定ファイル）やブレーカー（周辺インフラ）は全部取り替えないと火事になりますよね。インターフェースは万能ではないのです。

単語一覧 (Glossary)

AlloyDB: Google Cloudが提供する、PostgreSQLと完全互換でありながら、Googleのインフラ技術で超高速化された大人気の最強データベース。
Entity Framework (EF Core): C#でよく使われるORM（データ翻訳機）。SQL文を直接書かなくても、C#のオブジェクトを操作するだけでデータベースとやり取りできる便利な技術。
Redis: データをハードディスクではなく「メモリ」に保存する、超高速なデータベース。一時的なデータ（ログインのセッション情報など）を爆速で読み書きするのによく使われる。

いかがでしたか？
「最新のデータベースを使いたい」というエンジニアのロマンに対し、「システム全体に波及する見えないコスト」を冷徹に計算するアーキテクトの眼力。
上司の「あえてSQL Serverを残す」という決断は、レガシー移行という絶対に失敗できないプロジェクトにおいて、リスク予算を適切に配分するための最高の一手だったのです。

次回、第4回では「ネットワークとセキュリティ」について語ります。クラウドに移行したむき出しのサーバーをどう守るのか。「Cloud Armor」という強力な盾と、内部ネットワークの美しい構成について紐解きます。お楽しみに！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up