高パフォーマンスとコスト最適化のシナリオ
キャッシュ戦略、データレイクのクエリ最適化、リザーブドとSpotのトレードオフ、リードレプリカ構成に関するシナリオ問題に答えます。
「高パフォーマンスとコスト最適化のシナリオ」はCoddyKit上の無料AWS Solutions Architectレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。
シナリオ 1:キャッシュによるデータベース負荷の軽減
シナリオ:あるニュースサイトの RDS MySQL データベースでは、最大でも 1 時間に 1 回しか変更されない記事コンテンツへの読み取りトラフィックが 90% を占めています。データベースの CPU 使用率は平均 80%、コストは増加しており、クエリごとのレイテンシーは 200 ms です。解決策:lazy loading(cache-aside)パターンを使用して、RDS の前段にElastiCache Redis クラスターを追加します。アプリケーションはまずキャッシュを確認し、キャッシュヒット時には 1 ms 未満でキャッシュ済みの記事を返します。キャッシュミス時には RDS にクエリを実行し、結果を返してから 1 時間の TTL でキャッシュに書き込みます。期待される結果は、キャッシュヒット率 90%、RDS の CPU 使用率 20% 未満、キャッシュされた応答のレイテンシー 5 ms 未満です。
import boto3, json
elasticache = boto3.client('elasticache')
redis_client = None # assume redis-py client connected to ElastiCache endpoint
def get_article(article_id):
cache_key = 'article:' + str(article_id)
# Check cache first
cached = redis_client.get(cache_key)
if cached:
return json.loads(cached) # cache hit: <1ms
# Cache miss: query RDS
article = rds_query('SELECT * FROM articles WHERE id = %s', article_id)
# Write to cache with 1-hour TTL
redis_client.setex(cache_key, 3600, json.dumps(article))
return articleシナリオ 2:静的アセット配信のための CloudFront
シナリオ:us-east-1 の EC2 でホストされている Web アプリケーションについて、アジア太平洋地域のユーザーの読み込み時間が 2~4 秒かかっています。アプリケーションは大容量の静的アセット(画像、JS、CSS)を配信しています。解決策:ALB の前段にCloudFront ディストリビューションを配置します。/static/* パスに対して、TTL を長く(例:1 週間)設定したキャッシュビヘイビアを構成し、アジアのユーザーに近い CloudFront エッジロケーションで静的ファイルをキャッシュします。動的 API リクエストは TTL=0 でキャッシュをバイパスします。アジアのユーザーは us-east-1 との往復を待つ代わりに、シンガポールまたは東京のエッジロケーションから 100 ms 未満で静的アセットを読み込めます。
# CloudFront origin for ALB + separate behaviour for static assets
aws cloudfront create-distribution --distribution-config '{
'Origins': {
'Quantity': 1,
'Items': [{
'Id': 'alb-origin',
'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
'CustomOriginConfig': {"HTTPSPort": 443, "OriginProtocolPolicy": "https-only"}
}]
},
'CacheBehaviors': {
'Quantity': 1,
'Items': [{
'PathPattern': '/static/*',
'DefaultTTL': 604800,
'MaxTTL': 604800
}]
},
'DefaultCacheBehavior': {"DefaultTTL": 0}
}'シナリオ 3:Compute Optimizer による適正サイズ化
シナリオ:ある企業が 500 台の EC2 インスタンスを保有しており、その多くは 3 年前に大きなインスタンスタイプでプロビジョニングされています。AWS の請求額は高いものの、どのインスタンスが過剰にプロビジョニングされているのか把握できていません。解決策:AWS Compute Optimizer(無料、14 日間の CloudWatch メトリクスを使用)を有効にします。Compute Optimizer は各インスタンスの実際の CPU、メモリ、ネットワーク、ディスクの使用率を分析し、適正サイズ化の推奨事項を提供します。平均 CPU 使用率 8% で稼働する t3.xlarge には、t3.small へのダウンサイジングが推奨されます。500 台のインスタンス全体に推奨事項を適用すると、通常は EC2 コストを 20~40% 削減できます。
# Enable Compute Optimizer at account level
aws compute-optimizer update-enrollment-status \
--status Active
# Get EC2 instance recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--filters Name=Finding,Values=OVER_PROVISIONED \
--query 'instanceRecommendations[*].{Instance: instanceArn, Current: currentInstanceType, Recommended: recommendationOptions[0].instanceType}' \
--output tableシナリオ 4:バッチ処理のための Spot Instances
シナリオ:あるゲノミクス企業が、完了まで 8 時間かかり、中断されても再試行できる夜間バッチジョブを実行しています。これらのジョブにかかる EC2 On-Demand のコストは月額 10,000 ドルです。解決策:バッチ処理フリートにEC2 Spot Instancesを使用します。Spot Instances は、最大 90% 割引で利用できる未使用の EC2 キャパシティです。中断に耐えられるバッチジョブには、失敗した Spot ジョブを自動的に再キューイングし、混合フリート(Spot + 最小限の On-Demand フォールバック)を使用するAWS Batchを利用します。期待される削減効果はコンピューティングコストの 70~90% で、月額 10,000 ドルから 1,000~3,000 ドルになります。
# AWS Batch compute environment with Spot instances
aws batch create-compute-environment \
--compute-environment-name spot-genomics \
--type MANAGED \
--state ENABLED \
--compute-resources '{
"type": "SPOT",
"bidPercentage": 60,
"minvCpus": 0,
"maxvCpus": 256,
"instanceTypes": ["optimal"],
"subnets": ["subnet-1a", "subnet-1b"],
"securityGroupIds": ["sg-batch"],
"instanceRole": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
"spotIamFleetRole": "arn:aws:iam::123456789012:role/AmazonEC2SpotFleetRole"
}' \
--service-role arn:aws:iam::123456789012:role/AWSBatchServiceRoleシナリオ 5:変動するトラフィックに対する DynamoDB On-Demand
シナリオ:あるゲームのランキングシステムが、プロビジョンドスループットで DynamoDB を使用しています。ゲームのリリース時にはトラフィックが 50 倍に急増し、テーブルがリクエストをスロットリングします。一方、リリース以外の時間帯はスループットがほぼゼロで、プロビジョニングしたキャパシティが無駄になっています。解決策:DynamoDB をオンデマンドキャパシティモードに切り替えます。On-Demand は手動でキャパシティを計画しなくても、あらゆるスループットに即座に対応してスケールし、プロビジョニング済みユニットではなくリクエスト単位で課金されます。実行したリクエスト分だけ支払うため、リリース間のアイドルキャパシティコストは発生しません。On-Demand では、リクエスト単価がやや高くなる代わりに、スロットリングが発生せず、キャパシティ管理も不要になります。
# Switch existing DynamoDB table to On-Demand mode
aws dynamodb update-table \
--table-name Leaderboard \
--billing-mode PAY_PER_REQUEST
# Verify the change
aws dynamodb describe-table \
--table-name Leaderboard \
--query 'Table.BillingModeSummary.BillingMode'シナリオ6:予測できないアクセスに対するS3 Intelligent-Tiering
シナリオ:ある企業が、ユーザー生成画像を数百万枚、S3 Standardに保存しています。アクセスパターンは予測できず、毎日アクセスされる画像もあれば、数か月間アクセスされない画像もあります。ライフサイクルポリシーを手動で管理せずに、ストレージコストを削減したいと考えています。解決策:S3 Intelligent-Tieringを使用します。アクセスパターンに基づいて、オブジェクトを自動的に各ティア間で移動します。ティアには、頻繁なアクセス(Standard)、低頻度アクセス(30日以上アクセスなし)、Archive Instant Access(90日以上)、Archive Access(90日以上、オプトイン)があります。Intelligent-Tiering内では、取り出し料金はかかりません。モニタリング料金は、1,000オブジェクトあたり月額$0.0025で、大規模なデータセットでは無視できる程度です。
# Move objects to Intelligent-Tiering via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
--bucket user-images-bucket \
--lifecycle-configuration '{
"Rules": [{
"ID": "AutoTier",
"Status": "Enabled",
"Filter": {},
"Transitions": [{
"Days": 0,
"StorageClass": "INTELLIGENT_TIERING"
}]
}]
}'シナリオ7:AthenaとRedshiftのトレードオフ
シナリオ:あるスタートアップが、S3データレイクのテーブルをクエリしたいと考えています。週に約10回、アドホッククエリを実行します。あるベンダーが、dc2.largeクラスターを使用するAmazon Redshiftを提案しています。スタートアップ向けの解決策:まずはAmazon Athenaを使用します。インフラストラクチャのコストはゼロで、スキャンしたデータに対してのみ料金が発生します(約$5/TB)。適切にパーティション分割されたParquetデータに対する週10回のクエリであれば、月額$5未満になる可能性があります。Redshift dc2.largeは、継続的に稼働させると月額約$180かかります。Redshiftがコスト効率に優れるのは、クエリの同時実行数が多い場合(1日50回以上)や、サブ秒の応答時間が必要な場合に限られます。「アドホックで低頻度」というキーワードは、明確にAthenaを示しています。
# Athena cost estimate for 10 queries/week:
# Assume each query scans 5 GB of Parquet data
# 10 queries x 5 GB = 50 GB / week = 200 GB / month
# Athena cost: 200 GB x $0.005/GB = $1.00 / month
#
# Redshift dc2.large cost: $0.25/hr x 24hr x 30days = $180/month
#
# For 10 queries/week -> Athena saves $179/month
# Breakeven: when queries scan >36 TB/month or concurrency >50/day -> use Redshiftシナリオ8:EBSボリュームタイプの選択
シナリオ:あるリレーショナルデータベースサーバーに、64,000 IOPSと一貫した低レイテンシーが必要です。現在のgp3 EBSボリュームは、IOPSの上限に達しつつあります。解決策:io2 Block Expressにアップグレードします(I/O負荷の高いデータベース向けに設計されたEBSボリュームタイプです)。io2 Block Expressは、ボリュームあたり最大256,000 IOPSと、サブミリ秒のレイテンシーをサポートします。gp3より高額ですが($0.125/GB + プロビジョニング済みIOPSあたり月額$0.065)、64,000以上のIOPS要件を満たせる唯一のEBSオプションです。gp3の16,000 IOPS上限では不十分な、レイテンシーが重要なデータベースワークロードでは、io2が唯一の現実的なEBSの選択肢です。
# Create io2 Block Express volume with 64,000 IOPS
aws ec2 create-volume \
--volume-type io2 \
--size 500 \
--iops 64000 \
--availability-zone us-east-1a \
--encrypted
# EBS volume type IOPS limits summary:
# gp3: up to 16,000 IOPS (default 3,000, configurable)
# io1: up to 64,000 IOPS (on Nitro instances)
# io2 Block Express: up to 256,000 IOPS
# st1 (throughput HDD): no IOPS focus, max 500 MB/s throughput
# sc1 (cold HDD): lowest cost, 250 MB/s max, rarely accessed dataシナリオ9:安定したワークロードに対するリザーブドインスタンス
シナリオ:ある企業が、本番アプリケーション向けにr6i.4xlarge EC2インスタンスを20台、継続的に稼働させています。今後3年間、要件に変更はないと見込んでいます。これらのインスタンスに対する現在のオンデマンド料金は、年間$80,000です。解決策:最大の割引を得るため、3年契約のStandard Reserved Instances(またはCompute Savings Plans)を全額前払いで購入します。Standard Reserved Instancesでは、オンデマンド料金と比較して最大72%の割引を受けられます。インスタンスは予測可能なワークロードで24時間365日稼働しており、これはReserved Instancesに最適な典型的なケースです。予想されるコスト削減額は、$80,000 × 0.72 = 年間$22,400です。オンデマンド料金の年間$80,000と比較して、年間$57,600を節約できます。
# Reserved Instance purchase decision matrix:
# On-Demand: No commitment, highest price, any workload
# 1-yr RI (All Up): 40% discount, 1-yr commitment, specific instance type
# 3-yr RI (All Up): 60-72% discount, 3-yr commitment, best for stable workloads
# Compute Savings Plan: 66% max discount, flexible instance family/size/Region
# EC2 Spot: 90% discount, interruptible, batch/stateless only
#
# Rule: if usage > 70% of the time for >1 year -> buy RI or Savings Plan
# Rule: if usage < 50% -> stick with On-Demand
# Rule: if usage pattern is steady 3yr -> 3yr RI All Upfront maximises savingsシナリオ10:変動するトラフィックにおけるLambdaとEC2のコスト比較
シナリオ:ある企業が、月額$8のt3.micro EC2インスタンス上でREST APIを実行しています。このAPIは月間100万リクエストを受け付け、各リクエストの処理に100msかかります。チームは、Lambdaのほうが安くなるかどうかを検討しています。分析:Lambdaの料金は、1,000,000リクエスト × $0.0000002 = $0.20(リクエスト料金)+ 1,000,000 × 0.1秒 × 128MBメモリ × 料金レート = 約$1.67(コンピューティング料金)で、合計は月額約$1.87です。この低トラフィックのAPIでは、LambdaのほうがEC2より安価です。トラフィックが月間約4,000万リクエストを超えると、EC2のほうが安くなります。各ワークロードの損益分岐点を確認するには、Lambda Cost Calculatorを使用してください。
# Lambda vs EC2 cost rough break-even calculation:
# Lambda costs: $0.20 per 1M requests + $0.0000166667 per GB-second
# At 128 MB memory, 100ms duration:
# GB-seconds per request = 0.128 GB x 0.1s = 0.0128 GB-s
# Cost per request = $0.0000166667 x 0.0128 = $0.000000213 compute
# + $0.0000002 request fee = $0.000000413 total per request
#
# EC2 t3.micro: $0.0104/hr x 720 hrs = $7.49/month
# Break-even: $7.49 / $0.000000413 = ~18 million requests/month
# Below 18M requests/month -> Lambda cheaper
# Above 18M requests/month -> EC2 cheaper (if utilisation is high)シナリオ11:動的APIに対するGlobal Accelerator
シナリオ:ヨーロッパ、米国、アジアのユーザーにサービスを提供するグローバルAPIで、トラフィックが予測できないインターネット経路を通過するため、レイテンシーが安定しません。CloudFrontも検討されましたが、APIのレスポンスは動的で、キャッシュできません。解決策:AWS Global Acceleratorを使用します。これにより、グローバルに2つの静的なエニーキャストIPアドレスが提供されます。ユーザートラフィックは最寄りのAWSエッジロケーションからAWSグローバルバックボーンに入り、AWSのプライベートネットワークを経由して対象リージョンのオリジンへ移動します。そのため、混雑したパブリックインターネットの中間区間を回避できます。Global Acceleratorは動的APIの応答時間を20~60%改善し、リージョンのエンドポイントが異常になると即座にフェイルオーバーします。
# Create a Global Accelerator for an ALB
aws globalaccelerator create-accelerator \
--name my-api-accelerator \
--ip-address-type IPV4 \
--enabled
# Add a listener and endpoint group pointing to ALB
aws globalaccelerator create-listener \
--accelerator-arn arn:aws:globalaccelerator::123:accelerator/abc \
--protocol TCP \
--port-ranges '[{"FromPort": 443, "ToPort": 443}]'
# Endpoint group in us-east-1 with ALB
aws globalaccelerator create-endpoint-group \
--listener-arn arn:aws:globalaccelerator::123:listener/xyz \
--endpoint-group-region us-east-1 \
--endpoint-configurations '[{"EndpointId": "arn:aws:elasticloadbalancing:...", "Weight": 100}]'クイックチェック
このレッスンで学んだAWS Solutions Architect(SAA-C03)の概念を理解できているか確認しましょう。
レッスンの振り返り
このレッスンでは、ElastiCacheの遅延ロードによってRDSのCPU使用率を80%から20%に削減する方法、Spot InstancesとAWS Batchによってバッチジョブのコストを70~90%削減する方法、低頻度のアドホッククエリにはAthena、高い同時実行性が求められる分析にはRedshiftを使い分ける方法、そして取り出し料金なしで予測できないアクセスパターンに対応するS3 Intelligent-Tieringについて、シナリオを通して学びました。次は最後の総合演習です。時間制限付きの複数分野ミニ試験で、準備状況を確認します。
AI チューターと学ぶ AWS Solutions Architect — 無料
ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。
- コース
- 30
- レッスン
- 120
よくある質問
「高パフォーマンスとコスト最適化のシナリオ」レッスンは無料ですか?
はい。「高パフォーマンスとコスト最適化のシナリオ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。
「高パフォーマンスとコスト最適化のシナリオ」で何を学びますか?
キャッシュ戦略、データレイクのクエリ最適化、リザーブドとSpotのトレードオフ、リードレプリカ構成に関するシナリオ問題に答えます。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
AWS Solutions Architectを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「高パフォーマンスとコスト最適化のシナリオ」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このAWS Solutions Architectレッスンでコードを書いて実行できますか?
はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- セキュアアーキテクチャのシナリオ
- レジリエントで高可用性のアーキテクチャシナリオ
- 高パフォーマンスとコスト最適化のシナリオ
- 全分野横断の本格ミニ試験