EXERCISE 90分

ストーリー

高
高橋アーキテクト
設計する力だけでなく、他人の設計を評価する力も必要だ
高
高橋アーキテクト
ここでは、与えられたアーキテクチャに対してレビューを実施する。リスクを特定し、改善提案を行う。これがアーキテクトの日常だ

ミッション一覧

#ミッション難易度推定時間
1ECサイトのアーキテクチャをレビューせよ基本20分
2ユーティリティツリーを作成せよ応用20分
3技術戦略を策定せよ応用25分
4ADRを3件作成せよ発展25分

Mission 1: ECサイトのアーキテクチャレビュー

レビュー対象のアーキテクチャ

graph LR
    SPA["SPA"] --> API["モノリシックAPI<br/>Node.js"]
    API --> PG[("PostgreSQL<br/>単一インスタンス")]
    API --> Redis[("Redis<br/>単一インスタンス")]
    API --> S3["S3<br/>画像ストレージ"]
  • デプロイ: EC2 x 2台 (ALB背後)
  • 1日の注文数: 1万件
  • DAU: 10万人
  • 今後12ヶ月で10倍に成長予定

レビュー項目

  1. このアーキテクチャのリスクを5つ以上特定せよ
  2. 各リスクの重要度（高/中/低）を判定せよ
  3. 各リスクの緩和策を提案せよ
  4. 10倍成長に耐えるための改善ロードマップを作成せよ
回答例

特定されたリスク:

  1. [高] PostgreSQL単一インスタンスがSPOF

    • 緩和策: リードレプリカ追加、自動フェイルオーバー（Aurora移行）

  2. [高] Redis単一インスタンスがSPOF

    • 緩和策: Redis Sentinel or ElastiCache Cluster化

  3. [高] モノリスがスケーラビリティのボトルネック

    • 緩和策: まずステートレス化。成長に応じてドメイン境界でサービス分割

  4. [中] EC2 2台では10倍の負荷に耐えられない

    • 緩和策: Auto Scalingグループ導入、最低4台に増強

  5. [中] DBの書き込みスケーラビリティ

    • 緩和策: 読み書き分離 + 注文テーブルのパーティショニング

  6. [低] 画像配信のレイテンシ

    • 緩和策: CloudFront CDN導入

改善ロードマップ:

  • Q1: SPOF解消（DB/Redis冗長化、Auto Scaling）
  • Q2: パフォーマンス最適化（CDN、キャッシュ戦略、読み書き分離）
  • Q3: モノリスの段階的分割準備（ドメイン境界整理、API仕様策定）
  • Q4: 最初のサービス分割（検索 or 在庫管理）

Mission 2: ユーティリティツリー作成

対象システム

オンラインチケット販売プラットフォーム（ライブイベントのチケットを販売）

要件

  • 発売開始時にアクセスが集中（通常の100倍）
  • 二重販売の防止が必須
  • クレジットカード決済に対応
  • モバイルアプリとWebの両方に対応

タスク

  1. 品質属性を4つ以上特定せよ（パフォーマンス、可用性、セキュリティ等）
  2. 各品質属性に対して具体的なシナリオを2つ以上記述せよ
  3. 各シナリオにビジネス優先度と技術難易度を付けよ（H/M/L）
  4. 上位3つのシナリオに対するアーキテクチャ上の対策を提案せよ
回答例

ユーティリティツリー:

品質属性シナリオビジネス技術
パフォーマンス発売開始時（通常100倍）でもp99 < 3秒HH
パフォーマンス通常時のページ表示がp99 < 1秒ML
可用性発売中にDBが障害でも購入フローを継続HH
可用性99.99%の年間稼働率を達成HM
セキュリティクレジットカード情報のPCI DSS準拠HM
セキュリティBot対策（転売目的の自動購入を防止）HH
一貫性同一座席の二重販売を完全に防止HM
変更容易性新しい決済手段を2週間以内に追加可能ML

上位3シナリオの対策:

  1. ピーク時パフォーマンス: 仮想待合室 + Auto Scaling + CDN
  2. 発売中のDB障害: Multi-AZ配置 + 在庫キャッシュ + 自動フェイルオーバー
  3. Bot対策: CAPTCHA + デバイスフィンガープリント + レート制限

Mission 3: 技術戦略の策定

シナリオ

あなたは50人のエンジニア組織のアーキテクトです。以下の現状があります。

  • 主要言語: PHP (Laravel)、一部Python
  • DB: MySQL 5.7（EOL間近）
  • デプロイ: 手動（FTP + SSH）
  • テスト: ほぼなし（カバレッジ5%）
  • モニタリング: サーバーのCPU/メモリのみ

タスク

  1. 技術原則を3つ策定せよ
  2. 技術レーダー（Adopt/Trial/Assess/Hold）を作成せよ
  3. 1年間の技術ロードマップを四半期ごとに作成せよ
  4. 技術的負債の優先順位付けを行え
回答例

技術原則:

  1. 「自動化ファースト」: 手作業は全て自動化の対象。CI/CDを最優先で導入
  2. 「段階的モダナイゼーション」: ビッグバンリプレイスではなく、段階的に改善
  3. 「計測駆動」: 監視・メトリクスなしに判断しない

技術レーダー:

  • Adopt: Docker, GitHub Actions, Laravel 11, MySQL 8, Datadog
  • Trial: TypeScript (新規マイクロサービス向け), Terraform
  • Assess: Next.js (フロントエンド刷新), Kubernetes
  • Hold: PHP 7.x (8.xに移行), FTPデプロイ, 手動テスト

ロードマップ:

  • Q1: CI/CD導入 (GitHub Actions), MySQL 8移行, 監視導入 (Datadog)
  • Q2: テスト基盤構築（カバレッジ30%目標）, Docker化, Laravel 11移行
  • Q3: IaC導入 (Terraform), ステージング環境整備, テストカバレッジ50%
  • Q4: 初のマイクロサービス分離検討, フロントエンド刷新PoC

Mission 4: ADRを3件作成せよ

タスク

Mission 3のシナリオに対して、以下の3件のADRを作成せよ。

  1. データベースの移行先の選定
  2. CI/CDツールの選定
  3. モニタリングツールの選定

各ADRには Context, Decision, Consequences, Alternatives を含めること。

回答例

ADR-001: データベースの移行先

  • Context: MySQL 5.7がEOLを迎える。新バージョンへの移行が必須
  • Decision: MySQL 8.0に移行する（PostgreSQLへの変更は行わない）
  • Consequences: 既存のクエリとORMの互換性を維持。新機能（CTEなど）が利用可能に
  • Alternatives: PostgreSQL（学習コスト高）、Aurora MySQL（コスト増だがマネージド）

ADR-002: CI/CDツール

  • Context: 手動FTPデプロイを自動化したい。GitHubを使用中
  • Decision: GitHub Actionsを採用
  • Consequences: GitHubとの統合がシームレス。月2000分の無料枠あり。YAML定義
  • Alternatives: Jenkins（管理コスト高）、CircleCI（外部サービス依存増）

ADR-003: モニタリングツール

  • Context: CPU/メモリのみの監視では障害検知が遅い。APM、ログ集約、アラートが必要
  • Decision: Datadogを採用（APM + ログ + インフラ監視を統合）
  • Consequences: 月額コスト増（$23/host）。だが障害検知時間の短縮と運用効率化で相殺
  • Alternatives: Grafana + Prometheus（OSS、運用コスト高）、New Relic（同等だが高価格）

達成チェックリスト

  • Mission 1: アーキテクチャレビューでリスクを5つ以上特定した
  • Mission 2: ユーティリティツリーを作成した
  • Mission 3: 技術戦略（原則、レーダー、ロードマップ）を策定した
  • Mission 4: ADRを3件作成した
  • 全てのミッションで根拠を明記した

次のステップへ

次はStep 5のチェックポイントです。アーキテクチャレビューとキャリアの知識を確認しましょう。

推定所要時間: 90分