サーバーの性能を、後から変える

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

同じ1台のインスタンスのまま、インスタンスタイプだけを切り替えます。ディスクの中身（OS の設定やデータ）は変わらず、CPU・メモリなどのスペックだけが変わる、という点を確認します。

※ インスタンスタイプの組み合わせは一例です。無料利用枠の対象外になる場合があるため、組み合わせは自分で確認のうえ選んでください。

以下の流れで、「今のスペックを確認する」→「停止して変更する」→「起動して変わったことを確認する」を順に行ってください。

「変更前の状態を確認してから変更する」という順番で進めることで、何がどう変わったのかを実感しやすくなります。

1. マネジメントコンソールにサインインし、リージョンを合わせる

   ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。

2. 確認用の EC2 インスタンスを1台起動する

   EC2 コンソールで「インスタンスを起動」を押し、名前に resize-type-demo、AMI に Amazon Linux 2023、インスタンスタイプに無料利用枠の対象（例：t3.micro）を選びます。キーペアを新規作成し、.pem ファイルをダウンロードしておきます。

   セキュリティグループは SSH のみ許可でよい

   インバウンドルールで SSH（ポート22）を自分の IP からのみ許可しておきます。それ以外のポートは今回開けなくて構いません。

3. Windows の OpenSSH で接続し、いまのスペックを確認する

   PowerShell から接続し、変更前の vCPU 数とメモリ容量を確認します（<インスタンスのパブリックIP> は実際の値に置き換えてください）。

   PowerShell

   # 鍵ファイルの権限を自分のみ読み取り可に絞る
   icacls .\resize-type-demo-key.pem /inheritance:r
   icacls .\resize-type-demo-key.pem /grant:r "$($env:USERNAME):(R)"
   
   # SSH接続
   ssh -i .\resize-type-demo-key.pem ec2-user@<インスタンスのパブリックIP>

   EC2 インスタンス内

   # vCPU数を確認
   nproc
   
   # メモリ容量を確認
   free -h

   表示された値をメモしておく

   nproc の結果（例：2）と、free -h の Mem 行の total 列（例：~950Mi）を、あとで比較するためにメモしておきましょう。

4. インスタンスを停止する

   EC2 コンソールで resize-type-demo を選び、「インスタンスの状態」→「インスタンスを停止」を選びます。状態が「停止済み（Stopped）」になるまで待ちます。

   「再起動」ではなく「停止」が必要

   OS の「再起動（Reboot）」では、インスタンスタイプの変更メニューは選べません。インスタンスタイプの変更には、AWS の視点で完全に「停止済み」の状態になっている必要があります。

5. インスタンスタイプを変更する

   停止済みになったら、resize-type-demo を選んだ状態で「アクション」→「インスタンスの設定」→「インスタンスタイプを変更」を開きます。一覧から新しいインスタンスタイプ（例：t3.small）を選び、「適用」を押します。

   選べるのは互換性のあるインスタンスタイプだけ

   一覧には、現在の AMI のアーキテクチャ（x86_64 など）と互換性のあるインスタンスタイプだけが表示されます。見当たらないインスタンスタイプがある場合、アーキテクチャが異なる可能性があります。

6. インスタンスを起動する

   resize-type-demo を選び、「インスタンスの状態」→「インスタンスを開始」を選びます。状態が「実行中（Running）」に戻るまで待ちます。

   パブリック IP が変わる場合がある

   Elastic IP を関連付けていない場合、起動し直すとパブリック IP アドレスが変わります。次の手順で SSH 接続する際は、最新のパブリック IP アドレスをコンソールで確認してから接続してください。

7. 再接続し、スペックが変わったことを確認する

   もう一度 SSH 接続し、nproc と free -h を実行します。手順3でメモした値と比較し、新しいインスタンスタイプのスペックに変わっていることを確認します。

   EC2 インスタンス内

   nproc
   free -h

   これがゴール

   コンソール上の「インスタンスタイプ」表示と、サーバー内の nproc / free -h の値の両方が新しい値になっていれば、このハンズオンの目的は達成です。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面・コマンドのどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。

• EC2 コンソールのインスタンス詳細で、「インスタンスタイプ」が変更後の値（例：t3.small）になっている。
• インスタンスの状態が「実行中（Running）」に戻っている。
• SSH 接続後、nproc の出力が変更後の vCPU 数と一致している。
• free -h の total 列が、変更前にメモした値と比べて変わっている。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. インスタンスタイプの変更には、なぜ「停止」が必要なのでしょうか。稼働中のまま切り替えられない理由を考えてみましょう。
   ヒント

   インスタンスタイプを変えると、裏側で動いている物理的なハードウェアの割り当てそのものが変わることがあります。動いているプログラムを実行したまま、土台のハードウェアだけをすり替えることはできない、という観点から考えてみましょう。
2. インスタンスタイプを変更しても、ディスク（EBS）の中身はそのまま残りました。これはなぜでしょうか。
   ヒント

   EBS は、インスタンス（計算リソース）とは別の、ネットワークでつながった独立したストレージです。計算リソース側を載せ替えても、つなぎ直すだけで同じディスクをそのまま使える、という関係性がヒントです。
3. サーバーの負荷が高くなったとき、「1台のインスタンスタイプを大きくしていく」という方法には、コストや上限の面でどんな限界があるでしょうか。複数台に分散する方法と比べて考えてみましょう。
   ヒント

   1台を大きくする方法（垂直スケーリング）は、選べるインスタンスタイプの上限に達すると、それ以上は大きくできません。また、コストもおおむね線形に増えていきます。複数台に処理を分散する方法（水平スケーリング）と比べて、それぞれの向き・不向きを考えてみましょう。

作成したインスタンスを終了し、リソースを整理しましょう。

1. インスタンスを終了する：EC2 コンソールの「インスタンス」で resize-type-demo を選び、「インスタンスの状態」→「インスタンスを終了（Terminate）」を選びます。