cloud-solution-architect

クラウドソリューションアーキテクト

概要

Azure Architecture Center のベストプラクティスに従って、適切に設計された本番環境向けのクラウドシステムを設計します。このスキルでは、以下を提供します。

• Azure アプリケーション向けの 10 の設計原則
• 選定ガイダンスを含む 6 つのアーキテクチャスタイル
• WAF の柱に対応付けられた 44 のクラウド設計パターン
• コンピューティング、ストレージ、データ、メッセージングの テクノロジー選定フレームワーク
• 避けるべき パフォーマンスのアンチパターン
• 体系的な設計検証のための アーキテクチャレビューワークフロー

---

Azure アプリケーションの 10 の設計原則

#	原則	主な戦術
1	自己修復を前提に設計する	バックオフを伴う再試行、サーキットブレーカー、バルクヘッド分離、ヘルスエンドポイントの監視、グレースフルデグラデーション
2	あらゆるものに冗長性を持たせる	単一障害点の排除、可用性ゾーンの利用、マルチリージョンへのデプロイ、データのレプリケーション
3	連携を最小限にする	サービスの疎結合化、非同期メッセージングの利用、結果整合性の採用、ドメインイベントの利用
4	スケールアウトを前提に設計する	水平スケーリング、自動スケーリングルール、ステートレスサービス、セッションの固定化の回避、ワークロードの分割
5	制限を基準にパーティション分割する	データのパーティション分割（シャード／ハッシュ／範囲）、コンピューティングとネットワークの制限の遵守、静的コンテンツへの CDN の利用
6	運用を前提に設計する	構造化ログ、分散トレース、メトリクスとダッシュボード、ランブックの自動化、Infrastructure as Code
7	マネージドサービスを利用する	IaaS より PaaS を優先し、運用負荷を軽減し、組み込みの HA／DR／スケーリングを活用する
8	ID サービスを利用する	Microsoft Entra ID、マネージド ID、RBAC、認証情報の保存回避、ゼロトラストの原則
9	進化に対応できるよう設計する	疎結合、バージョン管理された API、後方互換性、統合のための非同期メッセージング、機能フラグ
10	ビジネスニーズに合わせて構築する	SLA／SLO の定義、RTO／RPO 目標の設定、ドメイン駆動設計、コストモデリング、複合 SLA

---

アーキテクチャスタイル

スタイル	説明	使用する場面	主なサービス
N 層	水平方向のレイヤー（プレゼンテーション、ビジネス、データ）	従来型のエンタープライズアプリ、リフトアンドシフト	App Service、SQL Database、VNets
Web-Queue-Worker	Web フロントエンド → メッセージキュー → バックエンドワーカー	長時間実行タスクを含む中程度の複雑さのアプリ	App Service、Service Bus、Functions
マイクロサービス	小規模で自律的なサービス、境界づけられたコンテキスト、独立したデプロイ	複雑なドメイン、独立したチームのスケーリング	AKS、Container Apps、API Management
イベント駆動型	パブリッシュ／サブスクライブモデル、イベントの生成元／コンシューマー	リアルタイム処理、IoT、リアクティブシステム	Event Hubs、Event Grid、Functions
ビッグデータ	バッチおよびストリーム処理のパイプライン	分析、ML パイプライン、大規模データ	Synapse、Data Factory、Databricks
ビッグコンピューティング	HPC、並列処理	シミュレーション、モデリング、レンダリング、ゲノミクス	Batch、CycleCloud、HPC VM

選定基準

• ドメインの複雑さ → マイクロサービス（高）、N 層（低～中）
• チームの自律性 → マイクロサービス（独立したチーム）、N 層（単一チーム）
• データ量 → ビッグデータ（TB 以上）、その他（GB）
• レイテンシ要件 → イベント駆動型（リアルタイム）、Web-Queue-Worker（許容可能）

---

クラウド設計パターン

主な関心事ごとに整理した 44 のパターンです。WAF の柱との対応：R=信頼性、S=セキュリティ、CO=コスト最適化、OE=運用上の優秀性、PE=パフォーマンス効率。

メッセージングと通信

パターン	概要	柱
非同期リクエスト／応答	ポーリングまたはコールバックを使用してリクエストと応答を分離します	R, PE
クレームチェック	大きなメッセージを分割し、ペイロードを別途保存して参照を渡します	R, PE
コレオグラフィ	中央のオーケストレーターを介さず、サービスがイベントで連携します	R, OE
競合コンシューマー	複数のコンシューマーが共有キューからメッセージを並行して処理します	R, PE
メッセージングブリッジ	互換性のないメッセージングシステムを接続します	R, OE
パイプとフィルター	複雑な処理を再利用可能なフィルターステージに分解します	R, OE
優先度キュー	優先度の高い作業が先に処理されるよう、リクエストに優先順位を付けます	R, PE
パブリッシャー／サブスクライバー	トピックやサブスクリプションを介して送信側と受信側を分離します	R, PE
キューベースの負荷平準化	キューでリクエストをバッファリングし、断続的な負荷を平準化します	R, PE
順序付きコンボイ	関連するメッセージを順番に処理しながら、グループ間の並列処理を可能にします	R, PE

信頼性とレジリエンス

パターン	概要	柱
バルクヘッド	ワークロードごとにリソースを分離し、連鎖的な障害を防ぎます	R
サーキットブレーカー	障害が発生しているサービスへの呼び出しを停止し、リソースを保護するために即座に失敗させます	R
補償トランザクション	後続のステップが失敗した場合、以前にコミットしたステップを取り消します	R
ヘルスエンドポイント監視	ロードバランサーやオーケストレーター向けにヘルスチェックを公開します	R, OE
リーダー選出	リーダーを選出して分散インスタンスを調整します	R
再試行	指数バックオフを用いた再試行により、一時的な障害に対処します	R
サーガ	補償トランザクションを用いて、マイクロサービス間のデータ整合性を管理します	R
スケジューラー・エージェント・スーパーバイザー	再試行と障害処理を用いて、分散アクションを調整します	R

データ管理

パターン	概要	柱
キャッシュアサイド	データストアから必要に応じてキャッシュにデータを読み込みます	PE
CQRS	独立したスケーリングのため、読み取りモデルと書き込みモデルを分離します	PE, R
イベントソーシング	ドメインイベントの追記専用シーケンスとして状態を保存します	R, OE
インデックステーブル	データストア内で頻繁にクエリされるフィールドにインデックスを作成します	PE
マテリアライズドビュー	効率的なクエリのために、データに対するビューを事前計算します	PE
シャーディング	スケールとパフォーマンスを高めるため、データを複数のパーティションに分散します	PE, R
静的コンテンツホスティング	クラウドストレージ／CDNから静的コンテンツを直接配信します	PE, CO
バレットキー	ストレージリソースへの限定的な直接アクセスをクライアントに許可します	S, PE

設計と構造

パターン	概要	柱
アンバサダー	横断的関心事をヘルパーのサイドカープロキシに委譲します	OE
腐敗防止層	新しいシステムとレガシーシステムのモデル間を変換します	OE, R
フロントエンドごとのバックエンド	フロントエンドの種類（モバイル、ウェブなど）ごとに個別のバックエンドを作成します	OE, PE
コンピューティングリソースの統合	複数のワークロードをより少数のコンピューティングインスタンスに統合します	CO
外部構成ストア	デプロイパッケージから構成を外部化します	OE
サイドカー	メインサービスと並行してヘルパーコンポーネントをデプロイします	OE
ストラングラーフィグ	レガシーシステムの一部を置き換えながら段階的に移行します	OE, R

セキュリティとアクセス

パターン	概要	柱
フェデレーション ID	外部の ID プロバイダーに認証を委任します	S
ゲートキーパー	リクエストを検証する専用ブローカーを使用してサービスを保護します	S
隔離	外部アセットを使用可能にする前に隔離して検証します	S
レート制限	コンシューマーによるリソース消費速度を制御します	R, S
スロットリング	負荷がかかっている状況で SLA を維持できるよう、リソース消費を制御します	R, PE

デプロイとスケーリング

パターン	概要	柱
デプロイスタンプ	アプリケーションコンポーネントの独立したコピーを複数デプロイします	R, PE
エッジワークロードの構成	多様なエッジデバイス間でワークロードを異なる設定にします	OE
ゲートウェイ集約	複数のバックエンド呼び出しを単一のクライアント要求に集約します	PE
ゲートウェイオフロード	共通機能（SSL、認証）をゲートウェイにオフロードします	OE, S
ゲートウェイルーティング	単一のエンドポイントを使用して、複数のバックエンドに要求をルーティングします	OE
ジオード	アクティブ／アクティブでサービスを提供するため、複数のリージョンにバックエンドをデプロイします	R, PE

詳細な実装ガイダンスについては、デザインパターンのリファレンスを参照してください。

---

テクノロジーの選択

意思決定のフレームワーク

各テクノロジー領域について、要件 → 制約 → トレードオフ → 選択の順に評価します。

領域	主な選択肢	選定基準
コンピューティング	App Service, Functions, Container Apps, AKS, VMs, Batch	ホスティングモデル、スケーリング、コスト、チームのスキル
ストレージ	Blob Storage, Data Lake, Files, Disks, Managed Lustre	アクセスパターン、スループット、コスト階層
データストア	SQL Database, Cosmos DB, PostgreSQL, Redis, Table Storage	一貫性モデル、クエリパターン、スケール
メッセージング	Service Bus, Event Hubs, Event Grid, Queue Storage	順序、スループット、パブ／サブとキューのどちらを使うか
ネットワーク	Front Door, Application Gateway, Load Balancer, Traffic Manager	グローバルとリージョンのどちらか、L4 と L7 のどちらか、WAF
AI サービス	Azure OpenAI, AI Search, AI Foundry, Document Intelligence	モデルのニーズ、データグラウンディング、オーケストレーション
コンテナー	Container Apps, AKS, Container Instances	運用上の制御とシンプルさのどちらを重視するか

詳細な意思決定ツリーについては、テクノロジー選択のリファレンスを参照してください。

---

ベストプラクティス

プラクティス	主なガイダンス
API 設計	REST の規約、リソース指向の URI、HATEOAS、URL パスまたはヘッダーによるバージョン管理
API の実装	非同期操作、ページネーション、冪等な PUT／DELETE、コンテンツネゴシエーション、ETag キャッシュ
自動スケーリング	メトリック（CPU、キューの深さ、カスタムメトリック）に基づくスケーリング、クールダウン期間、予測スケーリング、スケールイン保護
バックグラウンドジョブ	キューまたはスケジュールされたトリガーの使用、冪等な処理、ポイズンメッセージの処理、正常なシャットダウン
キャッシュ	キャッシュアサイドパターン、TTL ポリシー、キャッシュ無効化戦略、複数インスタンス向けの分散キャッシュ
CDN	静的アセットのオフロード、バージョン付き URL によるキャッシュバスティング、地理的な分散、HTTPS の強制
データのパーティション分割	水平（シャーディング）、垂直、機能別のパーティション分割。均等に分散するパーティションキーの選択
パーティション分割戦略	ハッシュベース、範囲ベース、ディレクトリベース。再分散の方法、パーティションをまたぐクエリの回避
ホスト名の保持	Cookie、リダイレクト、認証フローのために、プロキシ／ゲートウェイ経由でも元のホストヘッダーを保持
メッセージのエンコード	スキーマの進化（Avro／Protobuf）、後方／前方互換性、スキーマレジストリ
監視と診断	構造化ログ、分散トレース（W3C Trace Context）、メトリック、アラート、ダッシュボード
一時的な障害の処理	指数バックオフとジッターを伴う再試行、サーキットブレーカー、冪等性キー、タイムアウト予算

実装の詳細については、ベストプラクティスのリファレンスを参照してください。

---

パフォーマンスのアンチパターン

負荷がかかったときにパフォーマンスを低下させる、次のようなよくあるパターンは避けてください。

アンチパターン	問題	解決策
データベースの過負荷	処理をデータベースに過剰に委ねている	ロジックをアプリケーション層に移し、キャッシュを使用する
フロントエンドの過負荷	フロントエンドのリクエストスレッドでリソース負荷の高い処理を実行している	バックグラウンドワーカーやキューにオフロードする
頻繁な I/O	大きなリクエストを少数送る代わりに、小さな I/O リクエストを多数送っている	リクエストをバッチ処理し、一括 API を使用して、書き込みをバッファーする
不要なデータ取得	必要以上のデータを取得している	必要なフィールドだけを選択し、ページネーションを行い、サーバー側でフィルターする
不適切なインスタンス化	リクエストごとにコストの高いオブジェクトを再作成している	シングルトン、コネクションプーリング、HttpClientFactory を使用する
単一の永続化方式	すべてのデータ型に単一のデータストアを使用している	ポリグロット永続化を採用し、ワークロードごとに適切なストアを使用する
キャッシュなし	変更されていないデータを繰り返し取得している	キャッシュ・アサイドパターン、CDN、出力キャッシュ、Redis を使用する
ノイジーネイバー	1 つのテナントが共有リソースをすべて消費している	バルクヘッド分離、テナントごとのクォータ、スロットリングを適用する
リトライストーム	積極的なリトライによって、復旧中のサービスに過剰な負荷がかかっている	指数バックオフとジッター、サーキットブレーカー、リトライ予算を適用する
同期 I/O	I/O 操作中にスレッドがブロックされている	Async/await、ノンブロッキング I/O、リアクティブストリームを使用する

---

ミッションクリティカルな設計

99.99% 以上の SLO を目標とするワークロードでは、次の設計領域に対応してください。

設計領域	主な検討事項
アプリケーションプラットフォーム	マルチリージョンのアクティブ／アクティブ、可用性ゾーン、ゾーン冗長性を備えた Container Apps または AKS
アプリケーション設計	ステートレスサービス、冪等な操作、適切な縮退運転、バルクヘッド分離
ネットワーク	Azure Front Door（グローバル LB）、DDoS Protection、プライベートエンドポイント、冗長な接続
データプラットフォーム	マルチリージョンの Cosmos DB、ゾーン冗長 SQL、非同期レプリケーション、競合解決
デプロイとテスト	ブルーグリーンデプロイ、カナリアリリース、カオスエンジニアリング、自動ロールバック
ヘルスモデリング	複合ヘルススコア、依存関係のヘルス追跡、自動修復、SLI ダッシュボード
セキュリティ	ゼロトラスト、すべての箇所でのマネージド ID、キーのローテーション、WAF ポリシー、脅威モデリング
運用手順	自動化されたランブック、インシデント対応プレイブック、ゲームデー、事後分析

詳しいガイダンスについては、ミッションクリティカル リファレンスを参照してください。

---

Well-Architected Framework（WAF）の柱

すべてのアーキテクチャ上の決定は、5 つすべての柱に照らして評価してください。

柱	焦点	主な質問
信頼性	回復性、可用性、災害復旧	RTO/RPO は何ですか？障害にどう対処しますか？冗長性はありますか？
セキュリティ	脅威対策、ID、データ保護	ID は管理されていますか？データは暗号化されていますか？ネットワーク制御はありますか？
コスト最適化	コスト管理、効率性、適正規模化	コンピューティングは適正規模ですか？予約インスタンスはありますか？無駄はありませんか？
オペレーショナルエクセレンス	監視、デプロイ、自動化	デプロイは自動化されていますか？オブザーバビリティはありますか？ランブックはありますか？
パフォーマンス効率	スケーリング、負荷テスト、パフォーマンス目標	水平スケーリングできますか？パフォーマンスのベースラインはありますか？キャッシュを使用していますか？

WAF のトレードオフマトリックス

最適化の対象...	影響を受ける可能性があるもの...
信頼性（冗長性）	コスト（リソースの増加）
セキュリティ（分離）	パフォーマンス（レイテンシの増加）
コスト（統合）	信頼性（障害ドメインの共有）
パフォーマンス（キャッシュ）	コスト（キャッシュインフラストラクチャ）、信頼性（古いデータ）

---

アーキテクチャレビューのワークフロー

システムをレビューまたは設計するときは、次の構造化された手順に従ってください。

ステップ 1：要件を特定する

Functional: What must the system do?
Non-functional:
  - Availability target (e.g., 99.9%, 99.99%)
  - Latency requirements (p50, p95, p99)
  - Throughput (requests/sec, messages/sec)
  - Data residency and compliance
  - Recovery targets (RTO, RPO)
  - Cost constraints

ステップ 2: アーキテクチャスタイルの選択

上記の選択基準表を使用して、要件をアーキテクチャスタイルにマッチングさせます。

ステップ 3: テクノロジースタックの選択

テクノロジー選択の意思決定フレームワークを使用します。IaaS よりもマネージドサービス (PaaS) を優先します。

ステップ 4: 設計パターンの適用

特定された懸念事項に基づいて、44 のクラウド設計パターンから関連するパターンを選択します。

ステップ 5: 横断的関心事への対応

• ID とアクセス — Microsoft Entra ID、マネージド ID、RBAC
• 監視 — Application Insights、Azure Monitor、Log Analytics
• セキュリティ — ネットワークセグメンテーション、保存時/転送時の暗号化、Key Vault
• CI/CD — GitHub Actions、Azure DevOps Pipelines、Infrastructure as Code

ステップ 6: WAF の柱に基づく検証

各柱を体系的にレビューします。トレードオフを明示的に文書化します。

ステップ 7: 意思決定の文書化

アーキテクチャ決定レコード (ADR) を使用します:

# ADR-NNN: [Decision Title]

## Status: [Proposed | Accepted | Deprecated]

## Context
[What is the issue we're addressing?]

## Decision
[What did we decide and why?]

## Consequences
[What are the positive and negative impacts?]

---

参考資料

• 設計パターンリファレンス — パターンの詳細な実装
• テクノロジー選択リファレンス — Azure サービスの意思決定ツリー
• ベストプラクティスリファレンス — 実装ガイダンス
• ミッションクリティカルリファレンス — 高可用性設計

---

出典

Azure Architecture Center から派生したコンテンツ — Azure 上のクラウドソリューションアーキテクチャに関する Microsoft の公式ガイダンスです。設計原則、アーキテクチャスタイル、クラウド設計パターン、テクノロジー選択、ベストプラクティス、パフォーマンスのアンチパターン、ミッションクリティカル設計、Well-Architected Framework を網羅しています。