Retell AI アーキテクチャバリアント

概要

Retell AI インテグレーション向けの3つの検証済みアーキテクチャブループリント。

前提条件

• チームサイズと日次アクティブユーザー数要件の理解
• デプロイメントインフラストラクチャの知識
• 明確なSLA要件
• 成長予測が利用可能

バリアント A: モノリス（シンプル）

最適な用途: MVP、小規模チーム、日次アクティブユーザー数 < 10K

my-app/
├── src/
│   ├── retellai/
│   │   ├── client.ts          # Singleton client
│   │   ├── types.ts           # Types
│   │   └── middleware.ts      # Express middleware
│   ├── routes/
│   │   └── api/
│   │       └── retellai.ts    # API routes
│   └── index.ts
├── tests/
│   └── retellai.test.ts
└── package.json

主な特性

• 単一デプロイメントユニット
• リクエストパスでの同期的な Retell AI呼び出し
• インメモリキャッシング
• シンプルなエラー処理

コードパターン

// ルートハンドラーへの直接統合
app.post('/api/create', async (req, res) => {
  try {
    const result = await retellaiClient.create(req.body);
    res.json(result);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

---

バリアント B: サービスレイヤー（中規模）

最適な用途: 成長するスタートアップ、日次アクティブユーザー数 10K～100K、複数の統合

my-app/
├── src/
│   ├── services/
│   │   ├── retellai/
│   │   │   ├── client.ts      # Client wrapper
│   │   │   ├── service.ts     # Business logic
│   │   │   ├── repository.ts  # Data access
│   │   │   └── types.ts
│   │   └── index.ts           # Service exports
│   ├── controllers/
│   │   └── retellai.ts
│   ├── routes/
│   ├── middleware/
│   ├── queue/
│   │   └── retellai-processor.ts  # Async processing
│   └── index.ts
├── config/
│   └── retellai/
└── package.json

主な特性

• 関心の分離
• バックグラウンドジョブ処理
• Redisキャッシング
• サーキットブレーカーパターン
• 構造化されたエラー処理

コードパターン

// サービスレイヤーの抽象化
class RetellAIService {
  constructor(
    private client: RetellAIClient,
    private cache: CacheService,
    private queue: QueueService
  ) {}

  async createResource(data: CreateInput): Promise<Resource> {
    // API呼び出し前のビジネスロジック
    const validated = this.validate(data);

    // キャッシュの確認
    const cached = await this.cache.get(cacheKey);
    if (cached) return cached;

    // リトライ付きのAPI呼び出し
    const result = await this.withRetry(() =>
      this.client.create(validated)
    );

    // 結果をキャッシュ
    await this.cache.set(cacheKey, result, 300);

    // 非同期フォローアップ
    await this.queue.enqueue('retellai.post-create', result);

    return result;
  }
}

---

バリアント C: マイクロサービス（複雑）

最適な用途: エンタープライズ、日次アクティブユーザー数 100K+、厳密なSLA

retellai-service/              # 専用マイクロサービス
├── src/
│   ├── api/
│   │   ├── grpc/
│   │   │   └── retellai.proto
│   │   └── rest/
│   │       └── routes.ts
│   ├── domain/
│   │   ├── entities/
│   │   ├── events/
│   │   └── services/
│   ├── infrastructure/
│   │   ├── retellai/
│   │   │   ├── client.ts
│   │   │   ├── mapper.ts
│   │   │   └── circuit-breaker.ts
│   │   ├── cache/
│   │   ├── queue/
│   │   └── database/
│   └── index.ts
├── config/
├── k8s/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── hpa.yaml
└── package.json

other-services/
├── order-service/       # retellai-service を呼び出し
├── payment-service/
└── notification-service/

主な特性

• 専用 Retell AI マイクロサービス
• 内部通信用の gRPC
• イベント駆動アーキテクチャ
• サービスごとのデータベース
• Kubernetes自動スケーリング
• 分散トレーシング
• サービスごとのサーキットブレーカー

コードパターン

// イベント駆動とドメイン分離
class RetellAIAggregate {
  private events: DomainEvent[] = [];

  process(command: RetellAICommand): void {
    // ドメインロジック
    const result = this.execute(command);

    // ドメインイベントを発行
    this.events.push(new RetellAIProcessedEvent(result));
  }

  getUncommittedEvents(): DomainEvent[] {
    return [...this.events];
  }
}

// イベントハンドラー
@EventHandler(RetellAIProcessedEvent)
class RetellAIEventHandler {
  async handle(event: RetellAIProcessedEvent): Promise<void> {
    // サガオーケストレーション
    await this.sagaOrchestrator.continue(event);
  }
}

---

判断マトリックス

要因	モノリス	サービスレイヤー	マイクロサービス
チームサイズ	1～5	5～20	20+
DAU	< 10K	10K～100K	100K+
デプロイメント頻度	週単位	日単位	継続的
障害の分離	なし	部分的	完全
運用の複雑さ	低	中	高
市場投入までの時間	最速	中程度	最遅

マイグレーションパス

モノリス → サービスレイヤー:
1. Retell AIコードを service/ に抽出
2. キャッシングレイヤーを追加
3. バックグラウンド処理を追加

サービスレイヤー → マイクロサービス:
1. 専用の retellai-service リポジトリを作成
2. gRPC契約を定義
3. イベントバスを追加
4. Kubernetes にデプロイ
5. トラフィックを段階的に移行

手順

ステップ 1: 要件を評価

判断マトリックスを使用して適切なバリアントを特定します。

ステップ 2: アーキテクチャを選択

ニーズに基づいてモノリス、サービスレイヤー、またはマイクロサービスを選択します。

ステップ 3: 構造を実装

選択したブループリントに従ってプロジェクトレイアウトをセットアップします。

ステップ 4: マイグレーションパスを計画

今後のスケーリング向けのアップグレードパスを文書化します。

出力

• 選択されたアーキテクチャバリアント
• 実装されたプロジェクト構造
• 文書化されたマイグレーションパス
• 適用された適切なパターン

エラーハンドリング

問題	原因	解決策
過度な設計	誤ったバリアント選択	より シンプルから開始
パフォーマンス問題	誤ったレイヤー	キャッシング/非同期処理を追加
チーム間の摩擦	複雑なアーキテクチャ	シンプルにするか、トレーニング実施
デプロイメント複雑性	マイクロサービスのオーバーヘッド	サービスレイヤーを検討

例

クイックバリアント確認

# チームサイズとDAUをカウントしてバリアントを選択
echo "Team: $(git log --format='%ae' | sort -u | wc -l) developers"
echo "DAU: Check analytics dashboard"

リソース

• Monolith First
• Microservices Guide
• Retell AI Architecture Guide

次のステップ

一般的なアンチパターンについては、retellai-known-pitfalls を参照してください。