【re:Invent 2025】EC2最適化に関するテクニックを学ぶワークショップに参加しました

はじめに

本ブログは、私が現地参加したre:Invent 2025のワークショップ、「Optimizing EC2: Hands-On Strategies for Cost-Effective Performance (CMP337)」のレポートとなります。

ワークショップの概要

Discover practical techniques to extract optimal performance from Amazon EC2 instances in this technical workshop. Learn systematic approaches to workload analysis, focusing on key performance indicators and resource utilization patterns. Through guided exercises, explore how different application architectures influence instance behavior, and master the art of measuring price-performance ratios. Gain hands-on experience with performance testing tools, learn to interpret benchmarking results, and develop strategies for identifying performance bottlenecks. Leave with actionable methods to select and optimize EC2 instances for your specific workload requirements.

このテクニカルワークショップでは、Amazon EC2インスタンスから最適なパフォーマンスを引き出すための実践的なテクニックを学びます。
主要なパフォーマンス指標とリソース使用率パターンに焦点を当てた、ワークロード分析への体系的なアプローチを習得します。
ガイド付きの演習を通じて、さまざまなアプリケーションアーキテクチャがインスタンスの動作にどのように影響するかを探り、価格対性能比を測定する技術を習得します。
パフォーマンステストツールの実践的な経験を積み、ベンチマーク結果の解釈方法を学び、パフォーマンスのボトルネックを特定するための戦略を開発します。
特定のワークロード要件に合わせてEC2インスタンスを選択し最適化するための実用的な方法を持ち帰ることができます。

ワークショップの流れ

本ワークショップではAWSマネジメントコンソールは使用せず、全てVSCodeインスタンスのコードエディター上で行いました。

環境構成

ユーザーはCloudFrontを介してコードエディターにアクセスし、コードエディターからその先にあるGoアプリケーションに対して各種操作を行います。

下記が実際の操作画面です。
ターミナルを2つ用意し、右側でパフォーマンスを確認しつつ、左側でコマンドを入力していきます。

【ラボ１】パフォーマンスのベースライン設定と限界点分析

最初のラボで各アプリケーションの現状のパフォーマンスを測定し、変更が望ましい効果をもたらしているかを知るための「アンカー（基準点）」とします。

テストでは、「wrk」コマンドを使用します。
※wrkコマンドは、スレッド数、コネクション数、実行時間等を指定してWebサーバに対して負荷をかけるコマンドです。

• ステップ① 段階的なステップ実行
  • 控えめな負荷で容量を下回って開始します。
  • 負荷を倍々にしていき、パフォーマンスは低下し始めるポイントを特定します。
  • 容量を超えてテストし、飽和状態を観察します。
• ステップ② 飽和テスト
  • 限界容量の約二倍の負荷をかけ、意図的に制限を超えます。
  • 要求されたレートや、実際に達成されたRPS（1秒あたりに処理できるリクエストの数）を観察します。
  • 実際に観測されたスループットの約90％でテストします。
  • レートが良好で、最大持続可能容量を確立していることを確認します。
• ステップ③ テスト結果の分析
  • テストの結果を用意されたシェルスクリプトで抽出します
    • パフォーマンスが低下するポイントや、良好な時点のポイント等
  • 用意されたJupyter Notebookで結果を可視化・分析します
    • パフォーマンス曲線や最大スループット
• ステップ④ 価格性能比のベースラインを計算
  • Jupyter Notebookで、パフォーマンスデータを使用し、リクエストあたりのコストを計算します。

【ラボ２】インスタンスタイプの比較と選択

新しいインスタンスでのパフォーマンスを測定し、推奨と評価の意思決定フレームワークを使用します 。
インスタンスを属性（コア数、RAMなど）に基づいて選択する方法を学びます 。

• ステップ① インスタンスタイプ間の価格性能比を比較
  • Jupyter Notebookで、自動でデータの視覚化を行います。
• ステップ② 最適なインスタンスタイプを特定
  • 視覚化データを元に、インスタンスの価格とパフォーマンスを分析し、アプリケーションのワークロード特性に合わせて最適なインスタンスタイプを特定します。

EC2最適化のポイントまとめ

ワークショップを通して学んだ、EC2最適化の取り組みにおけるポイントを整理します。

重要な原則とポイント

• 推測ではなく測定する
  • パフォーマンスに関する意思決定は感覚に頼らず、実際のワークロードでテストを実施し、データに基づいて判断を下すべきです。
    CPU使用率だけでなく、コストとスループットを組み合わせた複合的な指標に注目します。
• 最適化の順序が重要
  • 最適化は通常、インフラストラクチャやハードウェアの選択から始め、その後にコードの最適化を行うという手順で、フェーズを分けて着実に実施します。
• 異なるワークロードには異なるインスタンスが必要
  • メモリやネットワークなど、ワークロード特性に基づいたインスタンスタイプを選択することが、最高のパフォーマンスを引き出すための鍵です。
• 限界点の真の能力を明らかにする
  • 定常的な負荷テストだけでなく、インスタンスが処理できる最大のリクエスト数（限界点） を把握し、余裕を持ったキャパシティを計画することが重要です。

避けるべき落とし穴

• CPU使用率のみに頼る
  • CPUだけでなく、メモリ、ネットワーク、ディスクI/Oなどのリソースもボトルネックになり得るため、単一のメトリクス（CPU使用率）のみで判断しないこと。
• 無駄な過剰最適化
  • パフォーマンスに影響のない部分まで最適化に時間を費やし、費用対効果の低い努力をすること。
• 「コスト効率」よりも「最適」を選ぶ
  • 最高のパフォーマンスを追求するあまり、不要な高価なインスタンスを選んでしまうこと。
• 時間の経過とともに再評価しない
  • 技術やAWSのサービスが常に進化しているため、パフォーマンスを定期的に再評価・再ベンチマークしないこと。

さいごに

本ワークショップでは、EC2インスタンスの最適化に関する実践的なアプローチを学びました。

「推測ではなく測定する」という原則のもと、実際のワークロードでのパフォーマンステストを通じて、最適なインスタンスタイプの選択方法を体験することができました。
今回学んだ知識を自社の環境に持ち帰り、今後に活かしていきたいと思います。