MODULE 02 / COMPUTE & ARCHITECTURE
コンピューティングと、 変化に強いシステム
サーバーを用意するだけでは、システムは完成しません。
処理能力を選び、需要に合わせて増減し、障害の影響を小さくする。EC2を出発点に、その設計をつなげて学びます。
このModuleで学ぶこと
01EC2の仕組みと性能・料金の選び方
02Console / CLI / SDKとAPIの関係
03監視・自動増減・負荷分散の役割分担
04SQS / SNSでサービスを疎結合にする
EC2は、 処理を動かす土台
Amazon EC2（Elastic Compute Cloud）は、必要なときにサーバーの処理能力を利用できるサービスです。起動した1台のサーバーをインスタンスと呼びます。LinuxやWindowsを選び、Webアプリケーション、データベース、バッチ処理などを実行できます。
物理サーバーの購入・設置を待たずに起動でき、必要がなくなれば停止・終了できます。OSやアプリケーションの設定、ネットワークのアクセス制御は利用者が行います。
物理サーバー · AWSが管理
仮想化
物理的なCPUやメモリを、独立した複数のコンピューターとして扱えるようにする技術。各インスタンスは自分のOSやアプリを実行します。
マルチテナント
複数の利用者が物理基盤を共有する形。共有していても、ほかの利用者のOSやデータを自由に見られるわけではありません。
性能とコストを、 用途から選ぶ
最初に考えるのは「何のリソースが必要か」です。CPUが必要な処理と、大量のデータをメモリに載せる処理では、適したサーバーが違います。用途に合う系統を選び、その中でサイズを決めると整理できます。
m5ファミリー · 系統＋世代largeサイズ · リソース量例：m5.large全体がインスタンスタイプです。「汎用」などは用途別のカテゴリで、m5などが具体的なファミリー。命名にはプロセッサなどを示す追加文字が付く場合もあります。上の例は最新世代の推奨ではありません。
| カテゴリ | 重視するリソース | 適した処理の例 |
|---|---|---|
| 汎用 | CPU・メモリ・ネットワークのバランス | Webサーバー、開発環境 |
| コンピューティング最適化 | CPUの処理性能 | 計算量の多いバッチ、科学計算 |
| メモリ最適化 | 大容量メモリ | インメモリDB、大規模データ処理 |
| 高速コンピューティング | GPUなどのアクセラレーター | 機械学習、グラフィックス処理 |
| ストレージ最適化 | ローカルストレージのI/O性能 | 大量の読み書き、データ分析 |
同じファミリーでも、サイズによってCPU・メモリなどの量が変わります。大きなサイズは必要な能力を増やせますが、料金も増えるため、実際の負荷を測りながら見直すことが大切です。ストレージの構成はタイプによって異なり、EBS（EC2で使う永続ストレージ）の容量は別に設定できます。
料金は「使い方」と「契約」で選ぶ
以下は料金・購入方法の代表例です。専有ホストは、割引方式というより物理サーバーを専有する配置方法であり、独立した選択軸です。
| 選択肢 | 考え方 | 向いている状況 / 注意点 |
|---|---|---|
| オンデマンド | 長期の利用コミットなしで使う | 試作、短期利用、需要が読めない処理。課金単位はOSなどで異なる |
| Savings Plans | 1年・3年の一定利用額（$/時）を約束し、対象利用を割引 | 安定した利用。Compute Savings PlansはEC2に加えLambda・Fargateにも適用。EC2 Instance Savings Plansは対象が限定される |
| Reserved Instances | 1年・3年の契約で、条件に合うインスタンス利用を割引 | 予測可能な継続利用。条件や支払い方法で割引が変わる。すべてがキャパシティ予約を伴うわけではない |
| Spot Instances | 余剰キャパシティを割安で利用 | 再実行できるバッチなど。中断を前提に設計する |
| Dedicated Hosts （専有ホスト） |
物理サーバーを専有し、配置を制御 | ソフトウェアのライセンス要件や規制要件に対応 |
入口が違っても、 APIにつながる
APIは、ソフトウェア同士がやり取りするためのインターフェースです。AWSでは、リソースの作成・参照・変更などの操作をAPIで受け付けます。Console・CLI・SDKは、そのAPIを呼ぶための代表的な入口です。
| 入口 | 使う場面 | 具体例 |
|---|---|---|
| Console | 初めての設定、状態の確認 | EC2の一覧画面を開く |
| CLI | 繰り返す運用、シェルスクリプト | aws ec2 describe-instances |
| SDK | アプリやプログラムにAWS操作を組み込む | PythonのBoto3でEC2一覧を取得 |
CLIはローカルのターミナルや、CLIがあらかじめ用意されたAWS CloudShellから利用できます。繰り返し作業をスクリプトにすると、手入力による設定のばらつきを減らせます。自動化しても、操作内容の確認は必要です。
公式資料：EC2の概要とアクセス方法 ↗需要に合わせて、 増やす・減らす
スケーラビリティ（拡張性）は、負荷が増えても処理能力を拡張できる性質。伸縮性は、変動する需要に合わせてリソースを増減できる性質です。ピークに合わせて常に大量のサーバーを稼働させる代わりに、必要な量へ調整します。
Scale Up · 垂直スケーリング
1台の処理能力を増やすCPU・メモリが足りない1台を、より大きなインスタンスタイプに変更。逆方向はScale Downです。
Scale Out · 水平スケーリング
並列に処理する台数を増やす複数のサーバーで処理を分担。台数を減らすScale Inと合わせ、EC2 Auto Scalingで自動化できます。
監視と制御を、ループにする
CloudWatchが状態を観測し、EC2 Auto Scalingが設定したポリシーに従って台数を調整します。Auto Scalingグループでは、最小台数・希望する容量・最大台数を設定します。ターゲット追跡では、例えば平均CPU使用率の目標値を設定し、それを維持するように調整します。
分散して、 止まりにくくする
複数台に増やすだけでは、1か所の障害にまとめて巻き込まれるかもしれません。高可用性（障害時もサービスを継続しやすい性質）を目指すなら、リージョン内の複数のAvailability Zone（AZ）に分散します。AZは、1つ以上の独立したデータセンターから構成される配置単位です。
リクエストを各サーバーへ振り分ける役割はElastic Load Balancing（ELB）が担います。図ではWeb用途のApplication Load Balancer（ALB）を例にしています。
ELB：どこへ送るか
複数のターゲットへトラフィックを分散します。ヘルスチェックで状態を確認し、通常は正常なターゲットへ送ります。基盤のパッチ適用などはAWSが管理します。
Auto Scaling：何台動かすか
ポリシーに基づいて台数を増減し、不健全なインスタンスを置き換えます。ELBとの連携を設定すると、追加したインスタンスをターゲットへ登録できます。
内部の通信にも、共通の入口を置ける
フロントエンドがバックエンド各台のアドレスを管理する代わりに、内部ELBのDNS名へリクエストを送ります。台数変更の影響を減らせます。ただし、同期通信では相手の応答を待つため、時間的な依存は残ります。
メッセージで、 実行する時刻を分ける
注文を受け付けるWebアプリが、その場で配送処理の完了まで待つ設計だと、配送側の遅延や障害が受付側にも伝わります。キューに処理依頼を保存すれば、受付と配送が同時に動いていなくても連携できます。
このように、相手の状態や内部実装への依存を減らす設計が疎結合です。直接通信すること自体が常に密結合というわけではなく、何にどの程度依存しているかが重要です。
| 比較する点 | Amazon SQS | Amazon SNS |
|---|---|---|
| 中心となる役割 | 処理待ちの仕事をバッファリング | イベントを購読先へ配信 |
| 受信側との関係 | 受信側がポーリングして取得 | サービスが購読先へ配信 |
| 複数の受信者 | ワーカーが仕事を分担。重複受信に備える | 各購読先へ配信（フィルター設定で対象を絞れる） |
| 用途 | 配送、画像変換、非同期バッチ | 注文イベントの配信、メール・SMS・プッシュ通知 |
| 組み合わせ | SNS → 複数のSQS → 各処理。イベントの配信と、処理待ちの保存を両立 | |
SQS：受信しただけでは、処理完了ではない
メッセージの中身をペイロードと呼びます。例えば、注文IDと配送先を含むデータです。ワーカーが受信すると、そのメッセージは可視性タイムアウトの間、ほかのワーカーから見えなくなります。処理に成功したワーカーが削除しなければ、再び受信できるようになります。
公式資料：Standardキューの配信特性 ↗SNS：受信先の数を、発行側から切り離す
SNSのPublish/Subscribe（発行・購読）では、トピックへ発行する側は、配送・分析などの購読先を個別に呼び出す必要がありません。新しい購読先を追加しても、発行側の処理を大きく変えずに連携先を増やせます。
役割の違いを、 言葉にしてみる
- EC2：処理を実行する。ファミリーとサイズで特性・容量を選ぶ。
- Console / CLI / SDK：AWS APIへ操作を届ける入口。
- CloudWatch：状態を観測する。Auto Scaling：台数を制御する。
- ELB：リクエストを分散する。複数AZ：配置場所の障害に備える。
- SQS：仕事をためて処理時刻を分ける。SNS：イベントを複数先へ配信する。
Q1. EC2を増やしたのに、リクエストが1台へ集中する。何を考える？
台数を増やすAuto Scalingとは別に、リクエストを分散する仕組みが必要です。ELB、ターゲット登録、ヘルスチェックや振り分け設定を確認します。
Q2. 高性能なEC2を1台にすれば、高可用性になる？
1台の性能を上げても、その1台や配置場所が止まれば処理は止まります。複数AZに分散し、ほかの台へ処理を引き継げる構成と容量を考えます。
Q3. 配送処理が止まっても、注文の受付を続けたい。何を挟む？
SQSに処理依頼を保存し、配送ワーカーが後から受信します。受付側はSQSへの送信に成功する必要があり、保持期間内に処理を再開できることも必要です。受付成功と配送完了は別の状態として扱います。
Q4. 注文のイベントを、配送と分析の両方で処理したい。
SNSのトピックへ発行し、配送用と分析用のSQSをそれぞれ購読させます。各処理が独立したキューを持つため、別々のペースで処理できます。
確認に使った公式資料
本文は提供されたModule 2のトランスクリプトを再構成し、誤解しやすい箇所を補足しています。以下は補足を確認したAWS公式資料です（確認日：2026年10月4日）。サービスの仕様や料金は更新されるため、実際の利用前に最新版を確認してください。