AWS EC2のインスタンスタイプをわずかな停止時間で変更（スケールアップ）した時の記録
コンテンツ
インスタンスタイプ
このブログはAWS（Amazon Web Services）のEC2（Elastic Compute Cloud）でOSはUbuntu 18.04 にWordPressをインストールして書いている。
インスタンスタイプは最初の１年間無料だったので選んだ t2.micro（vCPU：1、メモリ：1 GiB）をずっと使っており５万PV／月辺りまでは特に問題が無かった。
しかしここ数日でメモリ不足（oom-killer）で応答無しになった事が２回程発生しており、とりあえずの対応としてメモリ不足発生時にOSを自動で再起動する設定で仮対応をしていた。
しかしフリーメモリーが１００～２００MByteしか無い状態をこれからも継続する事はあまりよろしく無いのでインスタンスタイプをt2-microからt2-small（vCPU：２、メモリ：２ GiB）に変更することにした。
またページの平均表示速度が始めの頃と比べて段々と遅くなって来てしまっていた事もインスタンスタイプの変更の理由のひとつである。
またt2-microで3年のリザーブドインスタンス（前払いをして割引を受けたインスタンス）を購入していたのでインスタンスタイプを変更すると同時にリザーブドインスタンスと購入し直した。
変更手順を備忘録として残しておくので誰かの参考になれば幸いだ。
変更手順
変更手順は以下の通り。
- 空きメモリを確認（事前チェック）
- AMI（Amazon Machine Image）へイメージコピー（バックアップ）
- インスタンスの停止
- インスタンスタイプの変更
- インスタンスの開始
- 空きメモリの確認（事後チェック）
- AMIの削除
- リザーブドインスタンスの購入（任意）
- 不要になったリザーブドインスタンス
空きメモリを確認（事前チェック）
インスタンス変更前に現在の空きメモリを以下のコマンドで確認した。
free -m
空きメモリは193M Byte！しかない。
１００Mを切っていた時もあったので多少（？）の余裕があるとはいえ空きメモリが厳しい状態であることには変わりがない。
AMIへイメージコピー
万が一に備えてバックアップの意味でAMIを作成しておく。
AWSにログイン後、サービスからEC2、該当のインスタンスを選択する。
”アクション”ー＞”イメージ”ー＞”イメージの作成”をクリックする。
尚、この処理はインスタンスの稼働中でも行えるが、更新や参照が少ない時間帯に実施した方がリスクは少ないと思う。
- イメージ名：wordpress20200628
- イメージの説明：WordPress Server AMI 20200628
この記事が何処かで誰かの役に立つことを願っている。
尚、当記事中の商品へのリンクはAmazonアソシエイトへのリンクが含まれています。Amazonのアソシエイトとして、当メディアは適格販売により収入を得ていますのでご了承ください。
を入力して「イメージの作成」ボタンをクリックする。
「イメージの作成リクエストを受け取りました」のメッセージが表示されてAMIの作成が非同期で実行される。
AWSのメニューから”イメージ”ー＞”AMI”で作成中のAMIが表示される。
しばらく待つとステータスがpendingからavailableに変わる。
万が一、インスタンスタイプの変更に失敗してインスタンスが失われたらこのAMIからインスタンスを起動させる。
尚、AMIはインスタンスの変更が無事に終了した後は削除して構わない。
インスタンスの停止
インスタンスタイプの変更前にインスタンスを停止する。
尚、ELB（Elastic Load Balancing）を用いてインスタンスを停止ぜずにインスタンスタイプを変更する方法もあるがこのインスタンスはそれほどクリティカルなインスタンスで無いので停止してインスタンスタイプを変更することにする。
”インスタンスの作成”ー＞”停止”でインスタンスを停止する。
下記の「インスタンスを停止するとエフェメラルストレージ上のデータは失われる」との警告メッセージが表示されるので「停止する」ボタンをクリックする。
エフェメラルストレージとはEBSより高速だが揮発性のディスクなのでサーバを停止すると消えてしまうストレージ。
しばらく待ってインスタンスのステータスがstoppedになるのを確認する。
インスタンスタイプの変更
インスタンスが停止したのを確認したらインスタンスタイプを変更する。
”アクション”ー＞”インスタンスの設定”ー＞”インスタンスタイプの変更”をクリックする。
ドロップダウンリストからt2.smallを選択して「適用」ボタンをクリックする。
インスタンスの開始
インスタンスタイプがt2.smallに変更されているので、”アクション”ー＞”インスタンスの状態”ー＞”開始”でインスタンスを開始する（画面ショット撮り忘れ）
確認メッセージが表示されるので「開始する」ボタンをクリックする。
何の問題なくあっさりインスタンスが立ち上がってrunning状態になった。
１～２分で停止、インスタンスタイプの変更、開始が終了している。
空きメモリの確認（事後チェック）
free -mで空きメモリを確認すると空きメモリが１．３GByteと大幅に増加した！
AMIの削除
一通り動作確認を行って問題が無い事が確認できたのと、そのまま放置すると課金されてしまうのでAMIを削除する。
AWSのメニューから”イメージ”ー＞”AMI”で該当のAMIを選択した後、”アクション”ー＞”登録解除”でAMIの登録を解除する。
尚、この際必要に応じて（複数のAMIのイメージを保持している時など）AMI IDを控えておく。
確認メッセージが表示されるので「次へ」ボタンをクリックするとAMIの登録が解除される（データが削除された訳では無い）
AWSのメニューから”ELASTIC BLOCK STORE”ー＞”スナップショット”を選択した後、該当のスナップショットを検索する。（この際、先程控えておいたAMI-IDで検索しても良い）
スナップショットを選択後、”アクション”ー＞”削除”を選択する。
確認メッセージが表示されるので「はい、削除する」ボタンをクリックする。
以上でバックアップ用に取得したAMIの削除は完了。
リザーブドインスタンスの購入
今まで使っていたt2.miroは３年のリザーブドインスタンス（※）を使用していた。
※３年分前払いをして割引を受けたインスタンス。
今回インスタンスタイプを変更したのでt2.small用のリザーブドインスタンス（３年）を新たに購入している。
リザーブドインスタンスと購入手順の詳細は以前の記事を参照。
リザーブドインスタンスのインスタンスタイプは変更する事ができるのだが、大きいものから小さいインスタンスタイプに分割する場合や小さい複数のインスタンスタイプを統合（期間が同じである必要がある）するケースに対応しており、今回の様に１つのリザーブドインスタンスを大きく変更するケースには対応していない。
つまり変更では無く新規に新しいサイズのリザーブドインスタンスを購入する必要がある。
残り日数を日割りして差額でリザーブドインスタンスを買い替え出来れば良いのだが出来ないものは仕方がない。
不要になったリザーブドインスタンス
t2.microのリザーブドインスタンスは２年２ヶ月程使用している状態なので約１０ヶ月（４１週）残ってしまっていた。
本来であればちょうど使い切るタイミングでインスタンスタイプを変更するのが最適なのだがメモリ不足が頻発してしまっているので仕方がない。
５７％OFFで購入したので元はとっているのだが不要なリザーブドインスタンスをマーケットプレイスで売買できるとの事なので試してみる事した（後述するが結局売買できず）
AWSのメニューから”リザーブドインスタンス”を選択して、不要なt2.microをチェックして”出品”タブをクリックする。
銀行口座の設定が必要とあるので”ここをクリックしてください”リンクをクリックする。
Business Nameを入力して「Continue」ボタンをクリックする。
”it must be a U.S. bank account.”（アメリカの銀行口座が必要）とのメッセージが表示されてしまった。
アメリカの銀行口座は持っていないので断念するしか無い。
残り日数も少ないので買い手も居ないだろうとは思っていたのだが、出品自体は試してみたかったのでちょっと残念。
日本の銀行やpaypalに対応して貰えるとありがたい。
終わりに
以上でEC2のインスタンスタイプの変更に関する記事は終了する。
この記事が何処かで誰かの役に立つことを願っている。
尚、当記事中の商品へのリンクはAmazonアソシエイトへのリンクが含まれています。Amazonのアソシエイトとして、当メディアは適格販売により収入を得ていますのでご了承ください。
最近のコメント