architecture-design

アーキテクチャ設計スキル

Well-Architected Framework と Cloud Adoption Framework のベストプラクティスに従って、包括的な Azure アーキテクチャを設計し、HLD ドキュメントを作成します。

使用するタイミング

• 要件に基づいて新しい Azure ソリューションを設計する
• ハイレベル設計（HLD）ドキュメントを作成する
• Azure サービスとアーキテクチャパターンを選定する
• クラウド移行やモダナイゼーションを計画する
• アーキテクチャ決定記録を作成する

設計プロセス

1. 要件を収集する

次の項目について、明確化のための質問をします。

• ワークロードの種類：Web アプリ、API、データ処理、IoT、AI/ML
• 規模：ユーザー数、データ量、地理的な分布
• パフォーマンス：応答時間、スループット、レイテンシー SLA
• 可用性：稼働時間の要件（例：99.9%、99.99%）
• セキュリティ：データ分類、コンプライアンス（HIPAA、GDPR、PCI-DSS）
• 予算：月額または年額のコスト制約
• タイムライン：デプロイ期限、段階的な導入の必要性

2. Azure サービスを選定する

サービス選定の優先順位： PaaS > Containers > IaaS

詳しいガイダンスについては、references.md を参照してください。

• コンピューティングの選択肢（App Service、Functions、AKS、Container Apps、VMs）
• データストレージ（Azure SQL、Cosmos DB、PostgreSQL、Blob Storage）
• メッセージング（Service Bus、Event Hubs、Event Grid、Storage Queues）
• ネットワーク（Front Door、Application Gateway、Load Balancer）

主な判断基準：

• サービスの機能を要件に適合させる
• チームの専門知識と運用負荷を考慮する
• コストと機能のトレードオフを評価する
• 運用負荷を軽減するため、マネージドサービスを優先する

3. アーキテクチャを設計する

要件に基づいてパターンを適用します。

N 層（従来型）：

• 適用する場合：標準的な Web アプリ、実績のあるパターン、チームに馴染みがある場合
• 構成：フロントエンド → ロードバランサー → アプリケーション層 → データベース
• サービス：App Service、Azure SQL、Application Gateway、Redis Cache

マイクロサービス：

• 適用する場合：疎結合のサービス、独立したスケーリング、複数言語のニーズ
• 構成：API ゲートウェイ → サービス → メッセージバス → データベース
• サービス：API Management、AKS/Container Apps、Service Bus、Cosmos DB

イベント駆動型：

• 適用する場合：非同期処理、リアクティブシステム、疎結合コンポーネント
• 構成：イベントソース → Event Hub/Grid → Functions/Logic Apps → ストレージ
• サービス：Event Hubs、Azure Functions、Cosmos DB、Service Bus

サーバーレス：

• 適用する場合：断続的なワークロード、イベント処理、コスト重視のシナリオ
• 構成：HTTP/タイマー/キュートリガー → Functions → ストレージ/データベース
• サービス：Azure Functions、Logic Apps、Cosmos DB、Blob Storage

4. Well-Architected Framework を適用する

5 つの柱すべてに対応します（詳しいチェックリストは waf-assessment skill を参照してください）。

信頼性：

• 本番環境では可用性ゾーンを使用する
• ミッションクリティカルなシステム（99.99% 以上）ではマルチリージョンを使用する
• ヘルスチェックと自動修復を実施する
• RPO/RTO を定義したバックアップ戦略を策定する

セキュリティ：

• マネージド ID を使用する（コードに資格情報を含めない）
• PaaS サービスにはプライベートエンドポイントを使用する
• TLS 1.2 以上を使用し、HTTPS のみを許可する
• ネットワークセキュリティグループで最小権限を適用する
• シークレットには Azure Key Vault を使用する
• Azure AD 認証と RBAC を使用する

コスト最適化：

• リソースのサイズを適正化する（小さく始め、必要に応じて拡張する）
• 自動スケーリングポリシーを設定する
• 予測可能なワークロードには予約インスタンスを使用する
• ストレージ階層（Hot/Cool/Archive）を活用する
• コストを監視し、アラートを設定する

運用の優秀性：

• Infrastructure as Code（Bicep または Terraform）を使用する
• CI/CD パイプラインを構築する
• Application Insights と Log Analytics を使用する
• 重要なシナリオに対するアラートを設定する
• デプロイとロールバックを自動化する

パフォーマンス効率：

• 静的コンテンツには CDN を使用する
• キャッシュ戦略を策定する（Redis、CDN）
• 非同期処理を使用する
• 適切なコンピューティング SKU を選択する
• 自動スケーリングルールを設定する

5. 命名規則を作成する

Cloud Adoption Framework に従います。

{resource-type}-{workload}-{environment}-{region}-{instance}

Examples:
- rg-ecommerce-prod-eastus-001
- app-ecommerce-prod-eastus-001
- sql-ecommerce-prod-eastus-001
- kv-ecommerce-prod-eastus
- func-orderproc-prod-eastus-001

標準タグ：

Environment: Production | Staging | Development | Test
Owner: [email protected]
CostCenter: IT-12345
Project: ProjectName
BusinessUnit: Sales | Marketing | Engineering
Criticality: Critical | High | Medium | Low
DataClassification: Public | Internal | Confidential | Restricted

6. コストを見積もる

最新の小売価格を取得するには、azure-pricing スキルを呼び出してください。記憶に基づいてコストを見積もらないでください。

azure-pricing スキルは次の処理を行います。

• 課金対象のリソース SKU とリージョンごとに azure-mcp/pricing（pricing_get）を呼び出します
• 3 列の表を返します：従量課金制 | 1 年予約 | 3 年予約
• 有力な予約インスタンス／節約プランの候補を特定します

価格を照会する前に、手順 3 ですべてのサービス SKU を確認してください。このツールには、具体的な SKU またはサービス名が必要です。

コストの出力は次のカテゴリ別に整理してください。

• コンピューティング（App Service、Functions、VM、AKS ノード）
• データ（SQL、Cosmos DB、Storage）
• ネットワーク（Front Door、App Gateway、Firewall、Bandwidth）
• 監視（Application Insights、Log Analytics）

高レベル設計の出力形式

次のセクションを含む包括的な HLD ドキュメントを作成してください。

1. エグゼクティブサマリー

• ソリューションの概要（2～3 段落）
• 主なメリットとビジネス価値
• 概算コスト
• スケジュールとデプロイ方法

2. 要件の概要

• 機能要件（箇条書き）
• 非機能要件（パフォーマンス、可用性、セキュリティ）
• 制約と前提条件

3. アーキテクチャの概要

• アーキテクチャ図の説明（コンポーネントと接続）
• 使用する設計パターン（N 層、マイクロサービス、イベント駆動型、サーバーレス）
• アーキテクチャのアプローチを採用する理由

4. コンポーネント設計

各コンポーネントについて、次の内容を記載してください。

• サービス名：選定した Azure サービス
• SKU／Tier：具体的な価格プラン（例：App Service P2v3、Azure SQL S2）
• 目的：アーキテクチャにおける役割
• 構成：主な設定（リージョン、ゾーン、インスタンス、容量）
• 命名：CAF の規則に準拠（rg-app-prod-eastus-001）

5. ネットワーク設計

• 仮想ネットワークの構成（アドレス空間）
• サブネットとネットワークセキュリティグループ
• プライベートエンドポイントとサービスエンドポイント
• イングレス／エグレスのパターン（ロードバランサー、ゲートウェイ）
• DNS の構成

6. セキュリティ設計

• 認証と認可（Azure AD、Managed Identity）
• シークレット管理（Key Vault）
• 暗号化（保存時および転送中）
• ネットワークセキュリティ（NSG、ファイアウォール、WAF）
• コンプライアンス要件

7. データ設計

• データベースのスキーマ方針
• コンポーネント間のデータフロー
• バックアップと復旧の戦略（RPO／RTO）
• データ保持ポリシー
• 災害復旧のアプローチ

8. 監視と運用

• Application Insights の構成
• Log Analytics ワークスペース
• 監視する主なメトリック
• アラートの定義としきい値
• ダッシュボードの推奨事項

9. デプロイ戦略

• Infrastructure as Code のアプローチ（Bicep または Terraform）
• CI/CD パイプラインの設計
• 環境戦略（dev、staging、prod）
• デプロイの順序と依存関係
• ロールバック手順

10. コストの内訳

• サービス SKU と対象リージョンごとの最新の小売価格を取得するため、azure-pricing スキルを呼び出してください
• サービスごとの月額コストと年間予測
• 比較表：従量課金制 | 1 年予約 | 3 年予約
• コスト最適化の推奨事項（適正サイズ化、スポット／プリエンプティブルノード、ストレージ層）
• 月間の節約額の見積もりを含む、有力な予約インスタンス／節約プランの候補

11. Well-Architected 評価

• WAF の各柱に照らした簡潔な評価
• 設計の主な強み
• 今後改善できる領域

12. リスクと緩和策

• 特定された技術的リスク
• 緩和策
• 依存関係と前提条件

13. 次のステップ

• 直ちに実施する対応（フェーズ 1）
• 短期的な改善（フェーズ 2）
• 長期ロードマップ（フェーズ 3）

HLD の記述例

# High-Level Design: E-Commerce Web Platform

## 1. Executive Summary

This HLD describes a scalable e-commerce platform on Azure supporting up to 100K concurrent users
with 99.95% availability. The solution uses proven PaaS services with multi-region capabilities,
comprehensive security controls, and cost-optimized infrastructure.

**Key Benefits:**
- Global reach with Azure Front Door CDN
- Auto-scaling for traffic spikes (Black Friday, holidays)
- PCI-DSS compliant payment processing
- **Estimated cost**: see Section 10 — priced live via the `azure-pricing` skill per SKU and target region

**Timeline:** 8-week implementation with phased rollout

## 3. Architecture Overview

**Pattern:** N-Tier with asynchronous order processing

**Components:**

Azure Front Door（グローバル CDN + WAF） └─ Application Gateway（リージョン WAF + LB） ├─ App Service（Web フロントエンド - 3 インスタンス、P2v3） ├─ App Service（API バックエンド - 3 インスタンス、P2v3） ├─ Azure Functions（注文処理、Premium） ├─ Azure SQL Database（S2 DTU、50GB） ├─ Redis Cache（Basic C1、1GB） └─ Blob Storage（ホット層、商品画像）

**Rationale:** N-tier provides proven scalability, PaaS reduces operational overhead,
Functions handle asynchronous order processing, Azure SQL provides ACID guarantees.

## 4. Component Design

**Frontend Web App**
- Service: Azure App Service (Linux)
- SKU: P2v3 (2 vCores, 8GB RAM)
- Instances: 3 (Availability Zones 1, 2, 3)
- Auto-scale: 3-10 instances based on CPU > 70%
- Naming: app-ecommerce-web-prod-eastus-001
- Purpose: Serves customer-facing website

[Continue with all components...]

優れた HLD のヒント

具体的に記述する： 正確なサービス名と SKU を使用します（「データベース」ではなく「Azure SQL Database S2 DTU」）。 トレードオフを示す： サービス Y ではなくサービス X を選択した理由を説明します。 図を含める： コンポーネント間の関係を明確にして、アーキテクチャを視覚的に説明します。 最新の料金を使用する： コストに関する各セクションで azure-pricing スキルを呼び出します。料金を記憶に頼って推測してはいけません。必ず対象の region と currency を指定します（英国のワークロードでは GBP など）。 コストを考慮する： 常にコストの見積もりと最適化の機会を提示します。 セキュリティを最優先する： 認証、認可、暗号化、ネットワークセキュリティに対応します。 WAF との整合性： 設計上の判断で、具体的な WAF の原則を参照します。 命名規則： CAF の規約を一貫して使用します。 実装可能な内容にする： IaC の生成に十分な詳細を提示します。

避けること： 曖昧な表現、コストの記載漏れ、セキュリティの無視、WAF の省略、コンポーネントの不足、根拠の欠如