Go to Qiita Advent Calendar Top
LoginSignup
86
89

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@im_yoneda(米田)in株式会社Works Human Intelligence

【AWS】アーキテクチャ図をラクして書きたい！

Posted at

やりたいこと

AWSの各サービスについては名前とどんなことができるかが一致している程度です。ただ、どのサービス同士が連携しているのか、どう連携させるのがベストプラクティスなのか、理解できていません。散らかっています。
それぞれのサービスを頭の中で結びつけたいのでアーキテクチャ図をAIに作ってもらってラクして覚えちゃおう！と思い立ちました。

簡単な結論

頭に想像している図を視覚化するには良いが、初心者が勉強のためにまっさらから描くのは難しいかもしれないです。

作戦

  1. AWSのMCPを導入する
  2. サービスのつながりをMCPを使ってまとめてもらう
  3. MCPの出力をもとに、copilotにアーキテクチャ図を作成してもらう

とりあえずやってみる

1.MCPの導入

AWS Knowledge MCP ServerをVSCodeに導入します。

メリット

  • Github CopilotがAWSのサービスについて教えてくれる
  • 公式ドキュメントを参照しているためハルシネーションが少ない
  • Agentと組み合わせることで、mdファイルでまとめてくれる

2.サービスのつながりをMCPを使ってまとめてもらう

MCPを起動し、Github Copilotに以下のプロンプトを与えます。

  • Agentモード
  • モデル：Claude Sonnet 4
#aws___read_documentation awsの各サービスのつながりについてまとめて

#aws___read_documentationはMCPのコマンドで、AWSのドキュメントを参照してmdファイルにまとめてくれます。

出力されたmdファイル

AWSサービス連携ガイド

概要

このドキュメントでは、AWSの各サービス間の連携パターンと接続方法について包括的にまとめています。現代のクラウドアーキテクチャでは、複数のAWSサービスを組み合わせることで、スケーラブルで信頼性の高いシステムを構築できます。

アーキテクチャパターンの基本原則

Well-Architected Framework

  • 運用性 (Operational Excellence)
  • セキュリティ (Security)
  • 信頼性 (Reliability)
  • パフォーマンス効率 (Performance Efficiency)
  • コスト最適化 (Cost Optimization)
  • 持続可能性 (Sustainability)

マイクロサービスアーキテクチャ

  • 機能ごとに分離されたサービス
  • 技術レイヤーではなくドメインによる垂直分割
  • 疎結合なコンポーネント設計

サービス層別の連携パターン

1. アプリケーション統合層

主要サービス

  • Amazon SQS - メッセージキュー
  • Amazon SNS - パブリッシュ/サブスクライブ
  • Amazon EventBridge - イベントバス
  • AWS Step Functions - ワークフロー管理

連携パターン

SQS + SNS パターン

  • 用途: ファンアウト通知とバッファリング
  • パターン: SNS → 複数のSQSキュー → 各コンシューマー
  • 利点: メッセージの持続化と複数コンシューマーへの配信

EventBridge + Lambda パターン

  • 用途: イベント駆動アーキテクチャ
  • パターン: イベント発生 → EventBridge ルール → Lambda関数
  • 利点: 複雑なイベントフィルタリングとルーティング

Step Functions ワークフロー

  • 用途: 複数サービスの協調
  • パターン: Lambda + SQS + SNS + その他AWSサービス
  • 利点: 可視化されたワークフローと エラーハンドリング

サービス比較

特徴 SQS SNS EventBridge
通信モデル Pull型 Push型 イベント駆動
永続化 あり なし なし
配信保証 最低1回 最低1回 最低1回
メッセージ順序 FIFO対応 FIFO対応 順序保証なし
フィルタリング 基本的 サブスクリプション 高度なパターンマッチング

複合パターン例

EventBridge → SQS (バッファ) → Lambda (処理)
SNS → 複数 SQS → 並列処理
EventBridge Pipes → Kinesis (分析) + Lambda (処理)

2. コンピューティング層

主要サービス

  • Amazon EC2 - 仮想サーバー
  • AWS Lambda - サーバーレス関数
  • Amazon ECS - コンテナサービス
  • Amazon EKS - Kubernetesサービス
  • AWS Fargate - サーバーレスコンテナ

連携パターン

EC2 + Lambda パターン

  • EventBridge経由: EC2ライフサイクルイベント → Lambda関数
  • 用途: インスタンス状態変更の自動処理
  • 例: インスタンス起動時のタグ付け、停止時のバックアップ

ECS + Lambda パターン

  • CloudWatch Events: タスク状態変更 → Lambda
  • 用途: コンテナデプロイメントの自動化
  • 例: タスク失敗時のアラート、ログ処理

EKS + Fargate パターン

  • 用途: Kubernetesクラスターのサーバーレス実行
  • 利点: インフラ管理不要、オートスケーリング
  • 制約: 特定のワークロード制限

コンピューティングサービス選択指針

用途 推奨サービス 理由
イベント処理 Lambda 自動スケーリング、従量課金
長時間実行 EC2/ECS 継続的な処理に適している
マイクロサービス ECS/EKS コンテナオーケストレーション
バッチ処理 Lambda/Batch 短期間/長期間で使い分け

3. データベース層

主要サービス

  • Amazon RDS - リレーショナルデータベース
  • Amazon DynamoDB - NoSQLデータベース
  • Amazon DocumentDB - MongoDB互換
  • Amazon Redshift - データウェアハウス

選択基準（Lambda使用時）

DynamoDB vs RDS

要素 DynamoDB RDS
接続方式 HTTP API コネクションプール
コールドスタート 影響なし 接続時間が必要
スケーリング 自動 手動/計画的
クエリ複雑度 シンプル 複雑なSQL対応
一貫性 結果的/強整合性 ACID準拠
課金 使用量ベース インスタンス時間

推奨パターン

  • サーバーレス: DynamoDB + Lambda
  • 複雑なクエリ: RDS + RDS Proxy + Lambda
  • 分析ワークロード: Redshift + Spectrum
  • ドキュメント型: DocumentDB + EC2/ECS

データベース連携パターン

Lambda → DynamoDB (低レイテンシアクセス)
EC2 → RDS (コネクションプール管理)
EMR → Redshift (大規模データ分析)

4. ストレージ層

主要サービス

  • Amazon S3 - オブジェクトストレージ
  • Amazon EBS - ブロックストレージ
  • Amazon EFS - ファイルシステム

連携パターン

S3 統合パターン

Lambda → S3 (ファイル処理)
CloudFront → S3 (静的配信)
EMR → S3 (データレイク)
Athena → S3 (クエリ実行)

ストレージ選択指針

  • S3: 静的コンテンツ、バックアップ、データレイク
  • EBS: EC2インスタンス用永続化
  • EFS: 複数インスタンス間でのファイル共有

5. ネットワーク層

主要サービス

  • Amazon VPC - 仮想プライベートクラウド
  • Application Load Balancer - アプリケーションロードバランサー
  • Amazon API Gateway - APIゲートウェイ
  • Amazon CloudFront - CDN

典型的なアーキテクチャ

Internet → CloudFront → ALB → ECS/EKS
Internet → API Gateway → Lambda → DynamoDB

実践的な設計パターン

1. サーバーレスマイクロサービス

API Gateway → Lambda → DynamoDB
CloudWatch → SNS → Lambda (監視)
S3 → Lambda (ファイル処理)

2. コンテナベースマイクロサービス

ALB → ECS/EKS → RDS
EventBridge → ECS Task (バッチ処理)
CloudWatch → SNS (アラート)

3. データパイプライン

S3 → Lambda → DynamoDB
Kinesis → Lambda → Elasticsearch
S3 → Athena → QuickSight

4. ハイブリッドアーキテクチャ

API Gateway → Lambda (軽量処理)
ALB → ECS (重い処理)
EventBridge → 両方のサービス

ベストプラクティス

1. 疎結合設計

  • サービス間の直接呼び出しを避ける
  • メッセージングサービス（SQS、SNS）を活用
  • イベント駆動アーキテクチャの採用

2. 適切なサービス選択

  • 用途に応じたコンピューティングサービスの選択
  • データアクセスパターンに基づくデータベース選択
  • トラフィックパターンを考慮したキャッシュ戦略

3. 運用性の考慮

  • CloudWatchでの監視設定
  • X-Rayでの分散トレーシング
  • CloudTrailでの監査ログ

4. セキュリティ

  • IAMロールベースのアクセス制御
  • VPC内でのネットワーク分離
  • サービス間通信の暗号化

一般的な統合パターン

同期 vs 非同期

  • 同期: API Gateway → Lambda、ALB → ECS
  • 非同期: SQS → Lambda、SNS → 複数サービス

フォールトトレラント設計

  • リトライ機構: SQSの可視性タイムアウト
  • サーキットブレーカー: Lambda関数の同時実行制限
  • デッドレターキュー: 失敗メッセージの隔離

スケーリング戦略

  • オートスケーリング: EC2、ECS、Lambda
  • プロビジョニング: DynamoDB、RDS
  • キャッシュ: ElastiCache、CloudFront

まとめ

AWSサービスの連携は、要件に応じて適切なパターンを選択することが重要です。以下の原則を念頭に置いて設計しましょう：

  1. 目的に応じたサービス選択
  2. 疎結合なアーキテクチャ設計
  3. 適切な統合パターンの採用
  4. 運用性とセキュリティの確保
  5. コスト効率の最適化

このガイドを参考に、要件に最適なAWSサービス連携を実現してください。

3.copilotにアーキテクチャ図を作成してもらう

VSCodeに以下の拡張機能を追加し、エディター上でdraw.ioを使えるようにします。

Github Copilotに以下のプロンプトを与えます。

{作成されたmdファイル} に記載されているawsのサービスのつながりを #sample.dio で図示してください

最終的にこのような図ができました。

aws_servicese.png

サービスのつながりはわかりますが、もっといい感じにできそうです。

もうちょっといい感じにしてみる

今回は設計パターンを絞って、リアルタイムで動画を配信したい場合についてまとめてもらいます。

プロンプト

#aws___read_documentation リアルタイムで動画を配信したい場合、どのように構築すればよいですか
出力されたmdファイル

AWSでリアルタイム動画配信を構築する方法

概要

AWSを使ってリアルタイム動画配信システムを構築する方法について、主要なアプローチとサービスを紹介します。

主要なソリューション

1. Amazon IVS Real-Time Streaming（推奨）

特徴

  • 超低遅延: 300ms未満の遅延でリアルタイム配信が可能
  • 高同時接続数: 25,000人以上の視聴者をサポート
  • 最大12人のホスト: 同時に複数のホストが参加可能
  • モバイル最適化: Android/iOSアプリに最適化されたSDK
  • WebRTC対応: Webブラウザでの配信と視聴に対応

アーキテクチャ

配信者 → IVS Broadcast SDK → Amazon IVS Stage → IVS Web/Mobile SDK → 視聴者

主要コンポーネント

  1. Stage（ステージ）: 配信の基盤となるリソース
  2. Participant Token: 参加者の認証・権限管理
  3. Broadcast SDK: 配信用SDK（Web、iOS、Android）
  4. Player SDK: 視聴用SDK

セットアップ手順

1. IAM権限の設定
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ivs:CreateStage",
                "ivs:CreateParticipantToken",
                "ivs:GetStage",
                "ivs:ListStages"
            ],
            "Resource": "*"
        }
    ]
}
2. Stageの作成
aws ivs-realtime create-stage --name "MyLiveStage"
3. Participant Tokenの生成
aws ivs-realtime create-participant-token \
    --stage-arn "arn:aws:ivs:region:account:stage/stageId" \
    --user-id "user123" \
    --capabilities PUBLISH,SUBSCRIBE
4. Web SDKの実装例
<!DOCTYPE html>
<html>
<head>
    <title>IVS Real-Time Streaming</title>
</head>
<body>
    <video id="localVideo" autoplay muted></video>
    <video id="remoteVideo" autoplay></video>
    
    <script src="https://web-broadcast.live-video.net/1.28.0/amazon-ivs-web-broadcast.js"></script>
    <script>
        const { Stage, SubscribeType } = IVSBroadcastClient;
        
        // デバイス権限の取得
        async function requestPermissions() {
            try {
                const stream = await navigator.mediaDevices.getUserMedia({ 
                    video: { width: 1280, height: 720 }, 
                    audio: true 
                });
                return stream;
            } catch (error) {
                console.error('権限取得エラー:', error);
            }
        }
        
        // Stage接続
        async function joinStage() {
            const participantToken = 'YOUR_PARTICIPANT_TOKEN';
            
            const stage = new Stage(participantToken, {
                stageStreamsToPublish: () => [
                    new LocalStageStream(stream.getVideoTracks()[0]),
                    new LocalStageStream(stream.getAudioTracks()[0])
                ]
            });
            
            stage.on('connectionStateChanged', (state) => {
                console.log('接続状態:', state);
            });
            
            stage.on('streamsAdded', (participant, streams) => {
                streams.forEach(stream => {
                    if (stream.streamType === 'video') {
                        document.getElementById('remoteVideo').srcObject = stream.mediaStream;
                    }
                });
            });
            
            await stage.join();
        }
    </script>
</body>
</html>

利用シーン

  • ゲストスポット: 視聴者をホストとして招待
  • 対戦配信: リアルタイム対戦の同時配信
  • 音声ルーム: 音声中心の双方向配信
  • ライブオークション: リアルタイム入札システム

2. AWS Elemental MediaLive + MediaStore + CloudFront

サービス特徴

  • 従来型ライブ配信: HLSまたはDASHプロトコル
  • 遅延: 15-30秒程度
  • 大規模配信: 数十万〜数百万の同時視聴者対応
  • 高品質: 4K配信対応

システム構成

配信ソース → MediaLive → MediaStore/MediaPackage → CloudFront → 視聴者

構築手順

1. MediaLive Channelの作成
aws medialive create-channel \
    --name "LiveChannel" \
    --input-specification \
    '{"Codec":"AVC","Resolution":"HD","MaximumBitrate":"MAX_20_MBPS"}'
2. MediaStoreコンテナの作成
aws mediastore create-container --container-name live-streaming
3. CloudFront Distributionの設定
{
    "DistributionConfig": {
        "Origins": {
            "Items": [{
                "Id": "MediaStoreOrigin",
                "DomainName": "your-container.data.mediastore.region.amazonaws.com",
                "CustomOriginConfig": {
                    "HTTPPort": 443,
                    "OriginProtocolPolicy": "https-only"
                }
            }]
        },
        "DefaultCacheBehavior": {
            "TargetOriginId": "MediaStoreOrigin",
            "ViewerProtocolPolicy": "redirect-to-https"
        }
    }
}

3. Amazon Kinesis Video Streams with WebRTC

サービス特徴

  • P2P通信: 1対1の低遅延通信
  • WebRTC: ブラウザネイティブサポート
  • 用途: ビデオ通話、リモート監視

実装例

const kinesisVideoClient = new AWS.KinesisVideo();
const kinesisVideoSignalingChannelsClient = new AWS.KinesisVideoSignalingChannels();

// シグナリングチャネルの作成
const channelName = 'MySignalingChannel';
await kinesisVideoClient.createSignalingChannel({ ChannelName: channelName }).promise();

// WebRTC接続の確立
const configuration = {
    iceServers: [{ urls: 'stun:stun.kinesisvideo.region.amazonaws.com:443' }]
};

const peerConnection = new RTCPeerConnection(configuration);

料金体系

Amazon IVS Real-Time Streaming

  • Stage時間: $0.20/時間
  • 参加者時間: $0.015/参加者・時間
  • 配信データ転送: $0.045/GB

AWS Elemental MediaLive

  • チャンネル時間: $2.00-10.00/時間（解像度による）
  • データ転送: CloudFrontの料金に準拠

選択指針

要件 推奨サービス 理由
超低遅延（300ms未満） Amazon IVS Real-Time WebRTC対応
大規模視聴者（数万人以上） MediaLive + CloudFront CDN最適化
双方向配信 Amazon IVS Real-Time 複数ホスト対応
P2P通信 Kinesis Video Streams 1対1最適化
モバイルアプリ Amazon IVS Real-Time モバイル最適化SDK

ベストプラクティス

セキュリティ

  • Participant Tokenの適切な有効期限設定
  • IAMロールによる最小権限の原則
  • HTTPS/WSS必須

パフォーマンス

  • 720p解像度制限（リアルタイム配信）
  • 適応的ビットレート配信
  • エッジロケーション活用

監視・ログ

  • CloudWatch Metricsの活用
  • Real User Monitoring（RUM）
  • エラーハンドリングの実装

実装サンプル

完全な実装例は以下のAWSサンプルを参照：

まとめ

リアルタイム動画配信を実現するには、要件に応じて適切なAWSサービスを選択することが重要です。超低遅延が必要な場合はAmazon IVS Real-Time Streaming、大規模配信が必要な場合はMediaLive + CloudFrontの組み合わせを検討してください。

{作成されたmdファイル} を参考に、 #sample.dio でアーキテクチャ図を作成して

出力されたアーキテクチャ図

setup_for_ondemand.png

...なんか微妙な気がする

結論

  • アーキテクチャ図は作成できた
  • 初心者が勉強するためにはちょっと見づらいかも
  • 頭で想像している内容が正しいか確認してもらう際に使いやすい
  • 有識者が他の人へ説明する際に簡単にまとめるには良さそう
  • もっとプロンプトを的確にすれば未来は明るい
86
89
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
86
89

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?