Skip to content

MS_CloudDesignPatterns

Jump to bottom
nishi_74322014 edited this page Aug 18, 2026 · 2 revisions

クラウド設計パターン

概要

補足（なぜ「クラウド用の」パターンが要るのか）: オンプレの設計と
決定的に違うのは、次の 2 点である。

前提 オンプレ クラウド
障害 例外的な事態 常に起きる（一時的障害が日常）
リソース 固定（買った分） 伸縮する（従量課金）

つまりクラウド設計パターンの多くは、

  • 一時的な失敗を前提に、勝手に回復する（リトライ、サーキット ブレーカー）
  • 負荷の波を吸収する（キュー、スロットル、スケール）

という 2 つの目的に集約される。
「落ちない前提」で作られたオンプレのコードをそのまま持ち込むと、
クラウドでは断続的な障害に悩まされることになる。

詳細

カテゴリ

可用性

アプリケーションの可用性が最大限になるように設計・実装。

  • 正常性エンドポイント監視
  • 調整（絞り弁、スロットル）
  • キュー ベースの負荷平準化

データ管理

データの整合性を維持するため、様々な場所にあるデータを同期する。

分類 パターン
配置 テーブルのインデックス作成 / マテリアライズド・ビュー / シャーディング
操作 イベント ソーシング / CQRS / 補正トランザクション
その他 バレット キー / キャッシュ アサイド / 静的コンテンツ ホスティング

設計と実装

  • コンポーネントの設計
  • デプロイの一貫性や統一性
  • 管理および開発を容易にする保全性
  • 再使用可能性

メッセージング

スケーラビリティを最大化する（非同期）メッセージング インフラストラクチャ。

課題も多数ある。

  • メッセージの順序
  • 有害メッセージ（poison message）の管理
  • 冪等性
分類 パターン
基本 要求チェック / 非同期要求 - 応答 / 競合コンシューマー / 調整
キュー キュー ベースの負荷平準化 / 優先順位キュー / パブリッシャー/サブスクライバー / シーケンシャルなコンボイ
タスクの協調動作 パイプとフィルター / Scheduler Agent Supervisor / コレオグラフィ

補足（冪等性が最重要）: メッセージングを使うと、
同じメッセージが 2 回届くことがある（at-least-once 配信）。
多くのマネージド キューは「厳密に 1 回」を保証しない。

このため、受信側は
同じメッセージを 2 回処理しても結果が変わらない（冪等）ように
作らなければならない。

手法 内容
メッセージ ID の記録 処理済み ID をストアに残し、重複を捨てる
UPSERT にする INSERT ではなく「あれば更新」
業務キーで判定 「注文番号 X は処理済み」で弾く

「送金を 2 回実行してしまった」という事故は、
ほぼこの考慮漏れから生じる。

管理と監視

アプリケーションの停止や再デプロイを行わずに、
変化するビジネス要件やカスタマイズに対応する。

分類 パターン
ゲートウェイ 集約 / オフロード / ルーティング
監視 正常性エンドポイント監視
システム間連系 破損対策レイヤー / ストラングラー
コンポーネント アンバサダー / サイドカー
構成 外部構成ストア

補足（ストラングラー パターンが移行の要）: レガシー システムの
段階的な置き換えで最もよく使われるパターンである。

[利用者] ──> [ファサード（振り分け）] ─┬─> 新システム（少しずつ増やす）
                                       └─> 旧システム（少しずつ減らす）
  1. 前段に振り分けのファサードを置く。
  2. 機能を 1 つずつ新システムに移し、振り分け先を切り替える。
  3. 旧システムの担当が無くなったら撤去する。

「一斉に切り替える（ビッグバン移行）」を避けられる点が最大の利点で、
ASP.NET Coreへの移行のような
大規模な移行でも有効に使える。
名前は「絞め殺しイチジク（strangler fig）」に由来する。

パフォーマンスと拡張性

  • 要求のピークに対応するスケールアウト
  • 要求が減少したときのスケールイン

回復性

一時的な障害からの自動回復。

補足（リトライだけでは足りない）: 一時的障害への対処は
リトライ + サーキット ブレーカーの組み合わせが基本である。

パターン 目的
Retry 一時的な失敗（瞬断・スロットリング）から回復する
Circuit Breaker 継続的な失敗のとき、呼ぶのを止める
Timeout 応答が返らない相手に引きずられない
Bulkhead 障害を局所化する（リソースを区画に分ける）
Fallback 失敗時の代替応答（キャッシュ値など）

リトライだけを実装すると、障害中の相手に負荷をかけ続け、
復旧を妨げる（リトライ ストーム）。
サーキット ブレーカーで「しばらく諦める」ことが必要になる。
.NET では Polly（現在は Microsoft.Extensions.Http.Resilience）で
これらをまとめて構成できる。

セキュリティ

主なパターン（抜粋）

パターン 一言でいうと
キャッシュ アサイド 読むとき：キャッシュに無ければ DB から読んで入れる
CQRS 読み取り用と書き込み用でモデルを分ける
イベント ソーシング 状態ではなくイベントの列を保存する
補正トランザクション 分散環境で取り消し処理を明示的に書く（Saga）
キュー ベースの負荷平準化 前段にキューを置いてピークを均す
競合コンシューマー 1 つのキューを複数のワーカーで取り合う（スケールアウト）
サイドカー 補助機能を別コンテナに切り出す（ログ、プロキシ）
ゲートキーパー 前段に検証専用のインスタンスを置く
バレット キー 限定的な権限のトークンを発行して直接アクセスさせる（SAS）

補足（バレット キーの実例）: 「バレット キー（valet key、
ホテルの係員に渡す鍵）」は名前が分かりにくいが、
Azure Storage の SAS（Shared Access Signature） がまさにこれである。

[クライアント] ──① SAS を要求──> [アプリ]
      └────② SAS で直接アップロード────> [Blob Storage]

大きなファイルをアプリ サーバー経由で中継すると、
帯域とメモリを無駄に消費する。
期限・権限を絞ったトークンを渡し、
ストレージへ直接アクセスさせることでこれを避ける。

参考

Microsoft Learn

Tags: 移行, アーキテクチャ, クラウド, Azure, 設計のポイント

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally