サイトアイコン 協栄情報ブログ

【AWS】EC2インスタンスタイプ変更ハンズオンと注意点について

ejima


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

協栄情報えじまです

今回は、インスタンスタイプについて触れていきたいと思います

たくさんあって覚えるのが大変ですよね

もし性能があわなくなり変更することになった場合のため

注意点や変更の方法をハンズオンをしながら勉強していきたいと思います

今回の目的と概要

インスタンスタイプとは

インスタンスは、設定次第で様々なOSや、CPU、メモリなどを自身が必要としているものへとカスタマイズすることができます

そのうちの、CPUやメモリについての設定ができるモデルのことをインスタンスタイプといいます

インスタンスタイプの命名規則

インスタンスタイプは、要件に応じて様々なタイプを選択できます

無料枠として良く検証用にも使われるインスタンスタイプを例として挙げ
それぞれ軽く触れます

例） t2.micro

ファミリータイプ

特性に応じて様々なタイプがあります
例えば、CPUの性能を上げるCタイプや、メモリサイズを増やすRタイプなどがあります
詳しくは公式サイトをご覧ください

世代

数字が大きい方が新しい世代になります

基本的には特別な理由がない限り、最新世代を利用することをお勧めします

性能が高く、価格も安いことが理由です

インスタンスのサイズ

cpuやメモリ等のキャパシティを決められたセットから選択します

先ほどの公式サイトのリンクからこちらもご覧になっていただけます

CPUとvCPU,スレッドについて

補足ですが、後ほどハンズオンの中で確認する部分として、CPUのコア数,vCPU数,スレッド数などが出てきますのでそれぞれどんな意味なのか少し触れます

AWSではインスタンスタイプを選択する際に、vCPUを選ぶ基準にすることができます

例：）インスタンスタイプがm5.largeの場合

デフォルトCPUコア数：1
デフォルトvCPU数: 2
1コアあたりのスレッド数: 2

CPUのコア数　×　1コアあたりのスレッド数　＝　vCPU数（＝スレッド数）

つまり、脳みそは本来1つ(CPUのコア数）なのですが、
脳みそが2つタスクをこなせる(1コアあたりのスレッド数)ので、
コンピュータから見ると、2つの脳みそ(vCPU数)があるように見えます

また、公式ドキュメントにインスタンスタイプごとの表がございますので、選ぶ際に有用です

どういった状況で変更をするのか

CPUやメモリの性能が足りない時、兆候が表れたときに変更をお勧めします

例えば、CloudWatchでのメトリクス監視で、CPU使用率が90パーセントを超えている場合などですね

変更の際の注意点

現在業務で使用しているインスタンスの変更をする場合は特に注意しなければいけない点がいくつかあります

  1. インスタンスタイプの互換性
    インスタンスタイプの変更は、現在のインスタンスタイプと互換性がある場合のみにできます

インスタンスタイプの互換性については公式サイトのドキュメントをご覧ください

  1. インスタンスを停止する必要がある
    後ほど手順の中で記載しますが、インスタンスタイプを変更するには、一度インスタンスを停止する必要があります

もし、稼働しているサーバーの停止が必要な場合は、停止する前に必ずクライアントに確認をしてから作業をするようにしましょう

インスタンスを停止することで、以下の2点も、より注意すべきポイントになります

  1. IPアドレスが変わる
    インスタンスを停止→再起動とすることでパブリックIPアドレスが変更されます
    ElasticIPアドレスを使用することで固定のIPアドレスを指定できます

  2. ストレージが消える場合がある
    インスタンスのストレージにインスタンスストアを選択している場合、インスタンスを停止、または終了するとデータは消去されます
    理由として、インスタンスストアは、EC2インスタンスが起動している間のみテータを保持するものだからです

停止する前にバックアップを取るなど対策をしておきましょう

変更ハンズオン

今回はEC2を2台パブリックサブネットに作成します
AMIには、LinuxとWindowsをそれぞれ選択してください

状況としては、本番環境でCPUの処理が追い付かなくなったことにします

前提条件

項目 値
パブリックサブネット 1つ以上
項目 値
AMI Amazon Linux２
インスタンスタイプ t2.micro
IAM Role(Policy) AmazonSSMManagedInstanceCore
ユーザーデータ SSM Agentインストール(以下記載) 
#!/bin/bash

sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
項目 値
AMI Microsoft Windows Server2022 Base
インスタンスタイプ t2.micro
キーペア 任意のものを使用
セキュリティグループ RDP接続用インバウンドルール(3389番ポート)

手順

1. cpu数とメモリサイズの確認

今回は、インスタンスタイプに【t2.micro】を選択しておりますので、以下の設定になっております（コストを加味してのため無料枠を利用させていただいています）

タイプ vCPU数 コア数 1コアあたりのスレッド数 メモリ数
t2.micro 1 1 1 1.00(Gib)

それぞれのインスタンスで確認してみましょう

作成したインスタンスを選択

「接続」をクリック

タブの「セッションマネージャー」から接続

  1. cpu 
    lscpu

    コマンドを打つと以下のように出力されます

sh-4.2$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               63
Model name:          Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
Stepping:            2
CPU MHz:             2400.082
BogoMIPS:            4800.01
Hypervisor vendor:   Xen
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            30720K
NUMA node0 CPU(s):   0
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt

今回注目していただきたいのは3か所になります

A. vCPU数

CPU(s):              1

B. 1コアあたりのスレッド数

Thread(s) per core:  1

C. 1ソケットあたりのコア数（※基本的にソケットは1なので、ソケット数は計算式には入りません）

Core(s) per socket:  1
  1. メモリ 
    free -m
    sh-4.2$ free -m
          total        used        free      shared  buff/cache   available
Mem:            970          91         310           0         568         732
Swap:             0           0           0

Totalメモリ数が970MBということで、ほぼ1Gibになっていますね

freeコマンドは、オプションによって表示単位を変えられますが、今回はわかりやすいように、MB単位で調べられるオプションにしております

「プライベートキーファイルのアップロード」を選択して、ローカルのファイルから作成したキーペアを選択

その後「パスワードを複合化」をクリックでパスワードが生成されます。

先ほどダウンロードした、「リモートデスクトップファイルを開きます
「接続」をクリックするとパスワードの入力画面が表示されます

無事接続できると以下の画像のような画面になります

この画面で、「Ctrl」＋「Shift」＋「Esc」を入力していただくと、タスクマネージャーが開くので、PerformanceタブからCPUとメモリを確認できます

また、検索タブから「SystemInformation」と検索することでも確認できます

作成したEC2を選択し、「詳細」タブの下の方に「ホストとプレイスメントグループ」という場所があり、そこの「vCPUの数」で確認ができます

2. EC2のバックアップをとる

実際の業務上で変更する際は、インスタンスを停止することで弊害が起きたり、インスタンスタイプを変更した結果思わぬ障害が起きたりする場合があります

ですので、インスタンスタイプを変更する場合は必ずバックアップを取るようにしましょう

バックアップを取る方法は様々ありますが、今回は新しいAMIを作成する方法でバックアップを取りたいと思います

新しいAMIの作成

マネジメントコンソールから作成したEC2を選択して「停止」します
（本来停止しなくても作成はできます。しかし、データの破損などの恐れがあるため念のため停止をした方がいいかと思います。)

※AMIの作成時にインスタンスを【再起動しない】へのチェックについて
チェックをしていない状態だと、AMI作成の際に再起動をします。
AWSからの自動再起動で都合が悪ければ手動で停止して行うなりしてください（今回はあえて手動で停止しております）
チェックをつけて停止せずに行うこともできますが、その場合は、実行されているプロセスに一貫性が失われ、ファイルシステムの整合性が保証されないので、ご注意ください

警告
[No reboot] (再起動しない) を選択した場合、作成されたイメージの、ファイルシステムの整合性は保証されません。
引用URL (https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#awsdocs-note-title:~:text=%5BNo%20reboot%5D%20(%E5%86%8D%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%AA%E3%81%84)%20%E3%82%92%E9%81%B8%E6%8A%9E%E3%81%97%E3%81%9F%E5%A0%B4%E5%90%88%E3%80%81%E4%BD%9C%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AE%E3%80%81%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E6%95%B4%E5%90%88%E6%80%A7%E3%81%AF%E4%BF%9D%E8%A8%BC%E3%81%95%E3%82%8C%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82)
公式ドキュメント

「アクション」→「イメージとテンプレート」→「イメージを作成」

イメージ名と説明は任意のものを入力

他はデフォルトのままで大丈夫です

確認まで完了したら「イメージを作成」

EC2のマネジメントコンソール左のペインからAMIを選択

作成したイメージがちゃんとあることを確認してください

3. インスタンスタイプの変更

【アクション】タブから、「インスタンスの設定」「インスタンスタイプの変更」をクリックしてください

今回は【t2.large】に変更してみます
ここは任意ですので、試してみたいタイプがありましたら選択してみてください

料金はそれぞれ全く違いますのでご注意を

選択できたら「適用」をクリックして、再度インスタンスを起動しましょう

4. 変更できたか確認

最初に確認した手順で、もう一度確認してみましょう
今回選択したのは、【t2.large】でした

タイプ vCPU数 コア数 1コアあたりのスレッド数 メモリ数
t2.large 2 2 1 8.00(Gib)

各項目が変更されて入れば成功です

※コアあたりのスレッド数が2つある【t3.xlarge】でやってみました（Linuxのみ）

タイプ vCPU数 コア数 1コアあたりのスレッド数 メモリ数
t3.xlarge 4 2 2 16(Gib)

スケールアウトとスケールアップについて

最後に、スケールアップとスケールアウトについての違いを少し

スケールアウト

システムの容量を増やすために、複数のリソース（例：サーバー、インスタンス、コンテナ）を追加することです（水平方向）
AWSサービスの中でいうと、Auto Scalingがこれに当たります

人に例えると、1人より2人の方が作業効率が捗るように、インスタンスの数を増やすことによって、CPUの処理の分散や、メモリを増やしたりということが可能です

反対にリソースを減らすことを
【スケールイン】といいます

また、スケールアウトは、既存のインスタンスを停止することがないのがスケールアップとの大きな違いです

スケールアップ

システムの性能を向上させるために、既存のリソースの容量や能力を増やすことです（垂直方向）

単純に単体の性能を上げるとこが目的です
人に例えると、AWSの資格を1個持っている人を、極端に言うと12冠の人に成長させるようなイメージです

反対に性能を下げることを
【スケールダウン】といいます

コストについて

一般的に、スケールアウトはスケールアップよりもコストが高いとされています

スケールアップが、"既存"のリソースの変更をすることに対して、
スケールアウトは、"新たに"リソースを作るものになりますのでそれなりのコストがかかります

インスタンスタイプはどっち？

インスタンスタイプはスケールアップに当たります

許されるコストや、求められるものにより変わりますが、

状況に応じて最適な選択を行うことが大切になります

まとめ

AWSにおいて、拡張性やコストの最適化などの原則の良さをまさに体現しているものになると思います

もしオンプレですと一度購入したサーバーの性能があってないなどがあったら大変ですが、そういったリスクを減らしてくれます

クラウドの良さはこういったところですよね

これを機にインスタンスタイプについての見識を広めて行きたいと思います

ここまで読んでくださりありがとうございました

モバイルバージョンを終了