クラウドとプラットフォーム設計

目次

• 概要
• クラウド設計の視点
• Well-Architectedを設計レビューに使う
• プラットフォーム設計の主な要素
• ゴールデンパス
• Kubernetesとplatform engineering
• プラットフォームをプロダクトとして扱う
• コードとしてのインフラ
• デプロイ戦略
• マルチアカウントと環境分離
• コスト設計
• セキュリティの組み込み
• Well-Architectedで見る設計軸
• クラウドネイティブとクラウド対応
• プラットフォームAPI
• GitOpsとデプロイメント自動化
• プラットフォームを測る指標
• AWS Well-Architected Framework による設計
• Azure Architecture Center
• Google Cloud Architecture Framework
• IaC (Infrastructure as Code) のベストプラクティス
• 運用前チェックリスト
• まとめ
• 参考文献

概要

アプリケーションを動かす土台も設計対象である

アプリケーションの品質は、コードだけで決まるわけではありません。実行環境、ネットワーク、秘密情報、デプロイ手順、監視基盤、権限管理まで含めて、開発者が安全に変更を届けられる土台が必要です。

この章で重視すること

• IaaS、PaaS、Kubernetesの責務分担を理解する
• プラットフォームは「再利用できる運用」を作る場だと捉える
• セキュリティ、可観測性、デプロイ導線を最初から組み込む

クラウド設計の視点

重要なのは「どのサービスを使うか」よりも、「どこまでを自分たちが責任として持つか」です。マネージドサービスを増やすほど運用負荷は下がりやすいですが、設計自由度や移植性は変わります。

クラウド設計は、可用性、セキュリティ、性能、コスト、運用性、持続可能性のバランスです。AWS Well-ArchitectedやGoogle Cloud Architecture Frameworkのような枠組みは、特定サービスの選び方だけでなく、設計判断を定期的に見直すためのチェックリストとして使えます。

Well-Architectedを設計レビューに使う

Google CloudのWell-Architected Frameworkでは、クラウド構成をセキュリティ、信頼性、性能、コスト、運用、サステナビリティなどの柱で見ます。これは特定クラウドの機能一覧ではなく、非機能要件を漏らさないための設計レビューの型として使えます。

レビューで見る問い

品質の高いドキュメントは、量ではなく、明確さ、有用性、変更に合わせて保守されることが重要です。設計書は作って終わりではなく、運用中の判断を支える道具です。

信頼性は組織の責務

Reliability pillarでは、信頼性を開発、プロダクト、運用、プラットフォーム、SREを含む組織全体の責務として扱っています。クラウド構成だけでなく、ユーザー体験に基づく目標、観測、障害対応、学習のループまで含めて設計します。

責任共有モデル

クラウドでは、クラウド事業者が物理基盤や一部のマネージド機能を担当し、利用者が設定、データ、アクセス権、アプリケーションを担当します。どこまでが自分たちの責任かは、IaaS、PaaS、SaaSで変わります。

設定ミスはクラウド障害ではなく利用者側の設計問題として起きることが多いため、権限、ネットワーク、暗号化、監査ログを初期から標準化します。

責任共有モデルの詳細

AWS、Google Cloud、Azureなどのプロバイダー各社が定めた責任共有モデルでは、クラウド事業者が以下を担当します。

• ホスト OS、仮想化レイヤー、物理ネットワークの管理
• ハードウェア障害からの復旧
• 基盤レベルのセキュリティ監査

利用者側の責任は以下です。

• ゲスト OS、アプリケーションランタイム、アプリケーションコード
• ネットワーク構成、ファイアウォール設定
• ユーザー認証、権限管理（IAM）
• データの暗号化、バックアップ戦略

IaaSではこれらが最も多く、PaaSではクラウド事業者がミドルウェアを管理するため利用者の負担が減ります。Kubernetesでは、マネージド版（GKE、EKS、AKS）を使う場合、制御プレーンの管理はプロバイダー側になりますが、ワーカーノードやネットワークポリシーは利用者が責任を持ちます。

プラットフォーム設計の主な要素

• 実行基盤 VM、container、serverless
• デプロイ基盤 CI/CD、artifact、promotion
• 秘密情報管理 secret、KMS、rotation
• 権限管理 least privilege、service account
• 観測基盤 logs、metrics、traces
• 標準化 テンプレート、golden path

ゴールデンパス

platform engineeringでは、開発者に「何でも自由に選べる環境」を渡すより、推奨された標準経路を提供することが重要です。これをgolden pathと呼びます。

含めるものは次です。

• 新サービス作成テンプレート
• CI/CDの標準設定
• 監視とアラートの初期設定
• secretsの扱い
• logging / tracingの設定
• security scan
• deploy / rollback手順

開発チームが毎回同じ判断を繰り返さなくて済むようにするのが、良いプラットフォームの価値です。

良いgolden pathは、単なる社内テンプレート集ではありません。新規サービス作成、権限付与、デプロイ、監視、ロールバック、コスト可視化までが一本の導線になっていて、例外が必要なときだけ意識的に外れられる状態を目指します。

ゴールデンパスの実装パターン

実際のプラットフォームでgolden pathを実装するには、以下の要素が必要です。

テンプレート層

• Service template: 新サービスのスケルトン（Dockerfile、K8sマニフェスト、CI/CDパイプライン設定を含む）
• 環境テンプレート：本番・ステージング・開発環境の一貫性を確保

ポリシー層

• Admission controller: マニフェスト送信時の検証（ポリシー違反を事前防止）
• Network policy template: 標準的なネットワークセグメンテーション
• Resource quota: 環境ごとの利用上限

監視・ロギング層

• Sidecar injection: 全Podに対してlogging/tracing agentを自動挿入
• Alert rule template: サービス共通のアラート定義
• Dashboard template: Prometheus/Grafanaダッシュボード自動生成

例えば、GitLab CI/CDを使う場合、.gitlab-ci.ymlテンプレートで標準化し、開発者がinclude句で参照すれば、build→test→scan→deploy の全段階がgolden path通りに実行されます。

Kubernetesとplatform engineering

Kubernetesはコンテナの土台ですが、それ自体が開発者体験を保証するわけではありません。実際には、namespace設計、service account、ingress、secret、autoscaling、observabilityをどう標準化するかが重要です。

ここでplatform engineeringの発想が効きます。プラットフォームは、開発者が毎回ゼロから運用判断をしなくて済むように、共通の道筋を用意する役割を持ちます。

Kubernetesの標準設計パターン

Namespace設計

Kubernetesの標準的なnamespace戦略は、以下のような構造です。

kube-system          # システムコンポーネント（etcd、API server）
kube-public          # 公開リソース
kube-node-lease      # ノードハートビート（lease オブジェクト）
default              # デフォルトnamespace（本来は使わない）
ingress-nginx        # ingress controllerなどのアドオン
monitoring           # Prometheus、Grafana（オブザーバビリティ）
cert-manager         # TLS証明書自動更新
team-a               # チームA用namespace
team-b               # チームB用namespace

各namespaceはresource quota、networkpolicy、podsecuritypolicyで隔離し、RBAC（Role-Based Access Control）で権限を制限します。

Service Account設計

各マイクロサービスは専用のservice accountを持ち、最小権限（least privilege）で運用します。例えば、payment serviceがdatabaseへのアクセスだけが必要なら、API serverやetcdへのアクセス権は付与しません。

# Service Account定義例
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-service
  namespace: team-a
---
# Role: paymentサービスが必要な権限のみ
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payment-role
  namespace: team-a
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
---
# RoleBinding: Service AccountにRoleをバインド
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payment-rolebinding
  namespace: team-a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: payment-role
subjects:
- kind: ServiceAccount
  name: payment-service
  namespace: team-a

Health Check設計（Probes）

Kubernetesの3つのprobe typeは以下のように使い分けます。

例：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    # 起動時間が長い場合
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      failureThreshold: 30
      periodSeconds: 10
    # トラフィック受け入れ判定
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    # デッドロック検出
    livenessProbe:
      httpGet:
        path: /health/alive
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

リソース管理

Pod単位でCPU/メモリ上限を設定し、ノード障害時の自動退出（eviction）を制御します。

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

requestsは確保をリクエストし、limitsは上限です。limitsを超えるとOOMやthrottlingが発生します。

プラットフォームをプロダクトとして扱う

内部プラットフォームは、作って終わりの共通基盤ではなく、開発者を利用者に持つプロダクトです。CNCFのPlatform Engineering Maturity Modelでは、投資、採用、インターフェース、運用、計測といった観点で成熟度を見ます。

プラットフォームチームが見るべき指標は、単にクラスタ数やテンプレート数ではありません。

良いプラットフォームは、開発者に運用責任を押し付けるのではなく、よくある判断を安全な既定値へ畳み込みます。

コードとしてのインフラ

クラウドリソースは手作業で作ると差分が追いにくくなります。Infrastructure as Code(IaC) を使うと、構成をレビューし、履歴を残し、環境差分を比較しやすくなります。

IaCで見るべきポイントは次です。

• state管理
• module分割
• secretをstateに入れない
• drift detection
• plan / applyの承認
• 本番変更の監査証跡

IaCツールの選定と運用

Terraform

HashiCorp Terraformはプロバイダー非依存のIaCツールです。HCL（HashiCorp Configuration Language）で書かれたコード例：

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

# S3バケット定義
resource "aws_s3_bucket" "app_bucket" {
  bucket = "my-app-bucket-${var.environment}"
  tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

# バージョニング有効化
resource "aws_s3_bucket_versioning" "app_bucket_versioning" {
  bucket = aws_s3_bucket.app_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

# 暗号化設定
resource "aws_s3_bucket_server_side_encryption_configuration" "app_bucket_encryption" {
  bucket = aws_s3_bucket.app_bucket.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

State管理

Terraformのstateはシステムの現在状態を記録するため、secrets（データベースパスワードなど）が含まれることがあります。以下の対策が必須です。

• Remote state: S3 + DynamoDB backend（local stateは避ける）
• Encryption: state ファイルはKMS暗号化
• Access control: IAMで読み書き権限を制限
• State lock: DynamoDB lockで並行実行を防止

Drift Detection

# Drift検出（terraform plan は実際の状態と定義の差分を表示）
# CI/CDパイプラインで定期実行し、drift検出時は自動修復またはアラート
resource "aws_cloudwatch_event_rule" "drift_detection" {
  name                = "terraform-drift-detection"
  schedule_expression = "rate(24 hours)"
}

デプロイ戦略

クラウド設計では、どう動かすかだけでなく、どう安全に更新するかが重要です。

• rolling update
• blue-green deployment
• canary release
• feature flag
• progressive delivery

信頼性の高い運用では、リリースそのものを小さくし、観測しながら広げます。

Twelve-Factor Appの考え方では、設定をコードから分離し、build、release、runを分け、プロセスをstatelessに保つことが重視されます。これはクラウドネイティブの十分条件ではありませんが、移植性と運用しやすさを高める基礎になります。

デプロイ戦略の実装

Rolling Update（Kubernetes標準）

Kubernetesのデフォルトはrolling updateで、以下のように設定します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 新版Podの最大数
      maxUnavailable: 0    # 同時停止Pod数
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: myapp:2.0

この設定では、最大1つまで新版Podが並行実行され、古い版は段階的に置き換わります。

Blue-Green Deployment

# 旧版（青）
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    version: blue
  ports:
  - port: 80
    targetPort: 8080
---
# 新版（緑）をデプロイ
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      version: green
  template:
    metadata:
      labels:
        version: green
    spec:
      containers:
      - name: app
        image: myapp:2.0

新版が安定したら、service selectorを blue → green に切り替えます。

Canary Release

Argo Rollouts などを使い、トラフィックの一部を新版に流します。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10   # 10% のトラフィックを新版へ
      - pause:
          duration: 5m  # 5分間様子を見る
      - setWeight: 50   # 50% まで増加
      - pause:
          duration: 5m
      - setWeight: 100  # 全トラフィック to 新版

マルチアカウントと環境分離

本番、検証、開発を同じ境界に置くと、権限やデータの事故が起きやすくなります。クラウドでは、account、project、subscriptionなどの単位で環境を分けることがよくあります。

分ける観点は次です。

• 本番と非本番
• 個人検証と共有環境
• セキュリティ境界
• 請求境界
• 監査境界

AWS マルチアカウント戦略

組織構造の例

AWS Organization
├── Root (管理用アカウント)
│   ├── Billing アカウント（請求一元化）
│   └── Security アカウント（監査ログ集約）
├── Production OU
│   ├── Prod-Network アカウント
│   ├── Prod-App-A アカウント
│   └── Prod-App-B アカウント
├── Non-Production OU
│   ├── Staging アカウント
│   └── Development アカウント
└── Sandbox OU
    └── Experiment アカウント

権限委譲（AssumeRole）

各アカウント間でIAM roleを使い権限を委譲します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::PROD-ACCOUNT:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        }
      }
    }
  ]
}

コスト設計

クラウドでは、性能や可用性と同じようにコストも設計対象です。コスト最適化は節約だけではなく、どの資源がどの価値を生んでいるかを見える化することです。

• tag / labelを標準化する
• unused resourceを検出する
• autoscalingを設計する
• reserved / savings planを検討する
• egress costを見落とさない

コスト最適化の実装

タグ戦略

# Kubernetes: labels and annotations
apiVersion: v1
kind: Pod
metadata:
  labels:
    cost-center: engineering
    project: payment-api
    environment: production
    team: platform
    component: backend
  annotations:
    cost-allocation: "true"

Autoscaling 設定

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

セキュリティの組み込み

後からレビューするより、プラットフォーム側で安全な既定値を用意します。

• least privilege
• network segmentation
• encryption by default
• secret rotation
• workload identity
• image scanning
• policy as code

セキュリティ実装パターン

Pod Security Policy / Pod Security Standards

Kubernetes 1.25以降、PodSecurityPolicy（廃止予定）はPod Security Standardsに統一されました。

apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

この設定で、team-a namespace内のすべてのPodが「restricted」レベルのセキュリティ要件を満たす必要があります。

Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
# 特定の通信のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-payment-db
spec:
  podSelector:
    matchLabels:
      app: payment-service
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: payment-db
    ports:
    - protocol: TCP
      port: 5432

Workload Identity（GKE例）

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myapp-ksa
  namespace: default
  annotations:
    iam.gke.io/gcp-service-account: myapp@project-id.iam.gserviceaccount.com
---
# KSA←→GSA バインディングは gke-workload-identity-binding コマンドで実施
# gcloud iam service-accounts add-iam-policy-binding \
#   myapp@project-id.iam.gserviceaccount.com \
#   --role roles/iam.workloadIdentityUser \
#   --member "serviceAccount:project-id.svc.id.goog[default/myapp-ksa]"

Pod内では、service accountに自動マウントされた jwt トークンを使ってGoogle Cloudリソースにアクセスします。

Well-Architectedで見る設計軸

クラウド設計では、個別サービスの知識だけでなく、横断的な品質軸で見直すことが重要です。Google CloudやAWSのWell-Architected系の資料では、運用、セキュリティ、信頼性、性能、コストのような観点で設計をレビューします。

この軸はクラウドベンダーを選ぶためだけでなく、設計レビューの共通言語として使えます。

クラウドネイティブとクラウド対応

既存アプリをクラウド上のVMへ移しただけでもcloudで動いてはいます。しかしcloud nativeな設計では、障害、スケール、変更を前提にします。

CNCFの定義では、クラウドネイティブ技術はpublic cloud、private cloud、hybrid cloudのような動的環境で、scalableなアプリケーションを作り運用するためのものです。代表例はcontainer、service mesh、microservices、immutable infrastructure、declarative APIです。重要なのは、特定製品を導入することではなく、自動化、疎結合、復元性、観測可能性を設計原則として持つことです。

cloud nativeはKubernetesを使うこと自体ではありません。動的な環境で安全に変更し続ける設計のことです。

プラットフォームAPI

内部プラットフォームはUIだけでなく、APIとしても設計します。

• service template
• environment creation
• secret registration
• deploy request
• rollback
• observability dashboard
• cost report

開発者がチケットを投げて待つだけなら、プラットフォームはボトルネックになります。安全なself-service APIを用意すると、標準化と速度を両立しやすくなります。

Kubernetesの実装詳細

Control Plane コンポーネント

Kubernetesの制御プレーンは複数のコンポーネントで構成されます。

etcd は分散合意アルゴリズム Raft を使い、複数ノードでレプリケーションされます。本番クラスタではetcdの3ノード以上冗長化が標準です。

Node components

各ノードで動作するコンポーネント：

kube-proxy は3つのモード（userspace、iptables、ipvs）をサポートします。本番環境ではipvsモードが推奨（iptablesより性能が良い）。

Container Runtime Interface（CRI）

Kubernetes 1.24からDocker shutimはデフォルトサポート外になりました。代わりにcontainerdやCRI-Oを使います。

Kubelet → CRI (gRPC) → containerd/CRI-O → OCI Runtime (runc)

containerdは CRI プラグインとしてKubeletと通信し、OCI互換ランタイム（runc）を呼び出してコンテナを実行します。

GitOpsとデプロイメント自動化

Argo CD

Argo CDはKubernetes上で動作するGitOpsツールで、Git リポジトリを"source of truth"として、自動的に実装状態をGit定義に同期します。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/config-repo
    targetRevision: main
    path: apps/my-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # 削除されたリソース削除
      selfHeal: true    # ドリフト時に自動修復
    syncOptions:
    - CreateNamespace=true

Argo CDの利点：

• すべての変更がGit commitで追跡可能
• 権限制御がGitリポジトリレベルで統一（Kubernetesへの直接アクセス削減）
• rollback が Git revert 相当で簡単
• 監査ログが自然にGit historyに残る

プラットフォームを測る指標

プラットフォームは作って終わりではありません。利用者である開発チームが、安全に速く価値を届けられるかで測ります。

指標は開発者を監視するためではなく、摩擦を見つけるために使います。標準化が強すぎて例外が増えるなら、platform APIやtemplateの抽象度を見直します。

AWS Well-Architected Framework による設計

AWS が提供する5つの柱での評価:

1. 運用上の優越性（Operational Excellence）

自動化 → 可視化 → 学習

- インフラをコード化（IaC）
- 変更の自動化・追跡
- ベストプラクティスの定期的な改善
- メトリクスと予想値の定期的な見直し

実装例:

# CloudFormation (IaC)
Resources:
  OrderTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: orders
      AttributeDefinitions:
        - AttributeName: order_id
          AttributeType: S
      KeySchema:
        - AttributeName: order_id
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST
      PointInTimeRecoverySpecification:
        PointInTimeRecoveryEnabled: true
      Tags:
        - Key: Environment
          Value: prod

2. セキュリティ（Security）

Defense in Depth: 多層的な防御

Layer 1: IAM (Identity and Access Management)
         - 最小権限の原則
         - ロールベースアクセス制御
         
Layer 2: ネットワーク
         - VPC 隔離
         - Security Groups / NACLs
         - AWS WAF / DDoS 保護
         
Layer 3: データ保護
         - 転送中: TLS 1.3
         - 保存時: KMS 暗号化
         - キー管理: AWS Secrets Manager
         
Layer 4: 監査・ログ
         - CloudTrail (API ログ)
         - VPC Flow Logs (ネットワークログ)
         - CloudWatch (メトリクス)

3. 信頼性（Reliability）

目標: 99.99% の可用性（年間52分のダウンタイム）

- マルチAZ 配置（異なるデータセンタ）
- 自動フェイルオーバー
- Backup & Restore（RTO, RPO設定）

# RTO/RPO の計画例
"""
RTO (Recovery Time Objective): 復旧に許される時間
RPO (Recovery Point Objective): 許容できるデータロス

例：
- 本番DB: RTO=1時間, RPO=15分
  → 自動フェイルオーバー + 連続バックアップ
  
- ログ: RTO=24時間, RPO=1日
  → 日次バックアップで十分
"""

4. パフォーマンス効率（Performance Efficiency）

自動スケーリング戦略:

水平スケーリング (横スケ):
- 負荷増 → インスタンス追加
- 負荷減 → インスタンス削除
- EC2 ASG, Lambda 同時実行数

垂直スケーリング (縦スケ):
- インスタンスタイプ変更
- 短期的な急増対応
- 予測不能な需要

選択基準:
- Web/API: 水平（スケール容易）
- DB: 垂直 + Read Replicas（スケール限界）

5. コスト最適化（Cost Optimization）

ツール活用:

AWS Compute Optimizer
- CPU/メモリ利用率から最適インスタンスタイプ推奨
- 過度にプロビジョニングされたリソースを検出

AWS Cost Anomaly Detection
- 異常な費用増加を自動検知
- 原因分析サポート

Reserved Instances / Savings Plans
- オンデマンド比70% 割引
- コミットメント1〜3年

Cost Allocation Tags
- コスト部署別・プロジェクト別管理

例: 月額費用削減

Azure Architecture Center

Microsoft Azure の建築パターン:

Land Zone: 組織・セキュリティ・ガバナンスの単位

├─ Management Group (階層的管理)
│  └─ Subscription (課金・リソース制限)
│     └─ Resource Group (関連リソース集約)
│        ├─ Compute (VM, App Service, AKS)
│        ├─ Storage (Blob, Queue, Table)
│        ├─ Database (SQL, Cosmos DB)
│        └─ Network (VNet, Load Balancer)

実装例:

# Python SDK (Azure SDK for Python)
from azure.identity import DefaultAzureCredential
from azure.mgmt.resource import ResourceManagementClient
from azure.mgmt.compute import ComputeManagementClient

# 認証
credential = DefaultAzureCredential()
subscription_id = "your-subscription-id"

# リソース作成
resource_client = ResourceManagementClient(credential, subscription_id)
resource_client.resource_groups.create_or_update(
    "myResourceGroup",
    {"location": "East US"}
)

# VM作成
compute_client = ComputeManagementClient(credential, subscription_id)
# 詳細は省略...

Google Cloud Architecture Framework

Google Cloud の設計原則:

4つの基本: Business → Architecture → Governance → Operations

Business Alignment:
  - TCO 計算
  - ROI 予測
  
Architecture Principles:
  - スケーラビリティ
  - 可用性 99.95%
  - セキュリティ（Zero Trust）
  
Governance:
  - アクセス制御（IAM）
  - 監査・ログ
  - コンプライアンス
  
Operations:
  - 監視（Cloud Monitoring）
  - ロギング（Cloud Logging）
  - 自動修復

IaC (Infrastructure as Code) のベストプラクティス

Terraform による マルチクラウド対応

# variables.tf
variable "environment" {
  type        = string
  default     = "prod"
  description = "Environment name"
}

variable "instance_count" {
  type        = number
  default     = 3
  description = "Number of instances"
}

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "app_server" {
  count           = var.instance_count
  ami             = "ami-0c55b159cbfafe1f0"  # Amazon Linux 2
  instance_type   = "t2.micro"
  
  tags = {
    Name        = "app-server-${count.index}"
    Environment = var.environment
  }
  
  monitoring = true
  
  root_block_device {
    volume_type           = "gp3"
    volume_size           = 20
    delete_on_termination = true
    encrypted             = true
  }
}

# 出力
output "instance_ids" {
  value = aws_instance.app_server[*].id
}

Argo CD によるGitOps

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-app
  namespace: argocd

spec:
  project: default
  
  source:
    repoURL: https://github.com/company/app-config
    targetRevision: HEAD
    path: kustomize/prod
  
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  
  syncPolicy:
    automated:
      prune: true       # 削除されたマニフェストを削除
      selfHeal: true    # 手動変更を自動修復
    syncOptions:
      - CreateNamespace=true

運用前チェックリスト

• 新サービスは標準テンプレートから作れるか
• logs / metrics / tracesは最初から出るか
• deployとrollbackは誰でも同じ手順でできるか
• secretsはリポジトリやイメージに入らないか
• 本番変更の承認と証跡が残るか
• コストの所有者が分かるか

まとめ

クラウドとプラットフォーム設計は、アプリケーションの外側にある別テーマではなく、変更しやすいシステムを支える基盤です。開発者が安全に速く動けることを中心に置くと、設計の優先順位が見えやすくなります。

参考文献

公式・標準

• CNCF: Cloud Native Definition
• Kubernetes Concepts
• Kubernetes: Cluster Architecture
• Kubernetes: Liveness, Readiness, and Startup Probes
• Kubernetes: Resource Management for Pods and Containers
• Kubernetes: Assigning Pods to Nodes
• Kubernetes: Pod Topology Spread Constraints
• Kubernetes: Network Policies
• Kubernetes: Service
• Kubernetes: Persistent Volumes
• Kubernetes: Deployments
• Azure Architecture Center
• Google Cloud Architecture Framework
• AWS Well-Architected Framework

解説・補助

• Argo CD Documentation
• Terraform Documentation