AWSのインスタンスタイプのEOL対応方法

みなさんが経験したことあるだと思いますがAWSがどんどんリソースを新しくにしてますが、古いリソースがいずれなくなってます、それのせいで前から稼働してるリソースを上げるしかないです。

今年の12月1日はいくつのインスタンスタイプがなくなります


:::note warn
前世代のノード T1、M1、M2、M3、R3 は、2022 年 12 月 1 日にサポート終了 (EOL) になります。2022 年 12 月 1 日より前に、新しい世代のノード タイプにアップグレードすることをお勧めします。
:::

その世代はRDSだけではなくて、Elaticacheも影響されてます。なくなるなので自分で新しい世代を変更しなきゃ行けない。

## 普通のやり方

一番やりしやすいは普通にDBを変更する！AWSは次の世代のオススエしてまして、


| Previous Generation Node type | Recommended Node Type |
|:-----------|------------:|
| cache.m1.small       | cache.t3.small        |
| cache.m1.medium     | cache.t3.medium      |
| cache.m1.large       | cache.m5.large        |
| cache.m1.xlarge         | cache.m5.xlarge          |
| cache.m2.xlarge       | cache.m5.xlarge       |
| cache.m2.2xlarge    | cache.m5.2xlarge     |
| cache.m2.4xlarge       | cache.m6g.4xlarge        |
| cache.m3.medium     | cache.t3.medium      |
| cache.m3.large       | cache.m5.large        |
| cache.m3.xlarge         | cache.m5.xlarge          |
| cache.m3.2xlarge       | cache.m5.2xlarge       |
| cache.r3.large    | cache.r5.large |
| cache.r3.xlarge   | cache.r5.xlarge |
| cache.r3.2xlarge  | cache.r5.2xlarge |
| cache.r3.4xlarge  | cache.r5.4xlarge |
| cache.r3.8xlarge  | cache.r6g.8xlarge |
| cache.t1.micro  | cache.t3.micro | 
| cache.t2.micro  | cache.t3.micro | 
| cache.t2.small  | cache.t3.small | 
| cache.t2.medium | cache.t3.medium | 

自分の場合は`r3`のデータベースだったので`r5`で変更するべき。

![Screen Shot 2022-11-21 at 20.26.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/5c4c29ae-6b39-02c0-f02b-321093603c99.png)
それでインスタンスタイプを選択してで変更出来るます！
![Screen Shot 2022-11-21 at 20.28.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/c891f411-4843-5d00-029a-2212798e944c.png)
![Screen Shot 2022-11-21 at 20.28.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/20f87d09-118e-de18-7d6b-5d2f7abafb3d.png)

もちろんダウンタイムが発生します、変更中はアクセス出来ません！データベースの大きさ次第で時間がかかってます。

ですが、検証したい！インスタンス変更はそんなに変わらないはず、DBのバージョンだと結構変わりますがインスタンスは本当にハードウェアなのでそんなに変わらない。

検証するために新しい`r3`を作って、`r5`に変更すれば良いですね！これが悲しいところです、古い世代のインスタンスを作成出来ません。。じゃ、`r5`の変更して、問題あったら`r3` に戻せばようですね！これも悲しい、`r5`になったら`r3`に戻れない。泣。

## 安全のやり方

話に戻ると、VPCからのアクセス制限、Security Groupを確認して、インスタンスの中にDB入ってます。

![Untitled Diagram.drawio (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/8244b02d-1b31-9767-92c2-6fbb4a72933e.png)

安全にするために両方古い世代と新しい世代を同時に作ります。

![Untitled Diagram.drawio (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/a67bc0f3-48f7-bc7f-8e3e-b346062a767e.png)


ですが、同じタイミングだとデータの依存が厳しい、バックアップから作るだとしても作り中のr5が同じデータじゃない。もっとやらなきゃ！問題は古い世代をアクセスがあれば意味がないです。

### 3ステップ

#### 順番とタイミング

 - 古い世代をアクセス止める。
 - バックアップを作成する。
 - バックアップから新しい世代を作成する。
 - 新しい世代のアクセスポイントをコードに修正とリリースする。

#### Security Groupの追加

VPCを外せないと変更出来ませんので残るはSecurity Groupは変更出来ます！
今あるセキュリティー設定を外して、新しいSGをインスタンスを付けて、アクセス出来ないようにすれば、無事にバックアップ出来ます。
![Screen Shot 2022-11-21 at 20.50.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/84d2da3f-26a7-f66c-2c87-c5d96515b680.png)

こんなようなSGあれば、アクセス出来ません！TCPを0だけ設定すれば問題ないです！

#### アクセス順番

設定を確認できるようになったら、次はタイミングの問題です！

順番として：
![Untitled Diagram.drawio (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/878226/1af6d2dc-d7c0-7288-cd04-9df315d23c0c.png)
- 古い世代の今あるSGを外して、no-accessのSGを付けます。
- アクセスが出来なくになった、バックアップを作成する。
- バックアップ終われば、そのバックアップからインスタンスを作成する。
- 新しい世代のエンドポイントARNをコード修正して、サーバーへのリリースする。

画面操作だと重くになるのでSGの変更を`aws cli`でやります！

```bash:redis cluster
aws elasticache modify-replication-group --replication-group-id <redis cluster名前> --security-group-ids sg-XXX （no-accessのSG id）
```
```bash:memcache cluster
aws elasticache modify-cache-cluster --cache-cluster-id <memcache cluster名前> --security-group-ids sg-XXX （no-accessのSG id）
```
```bash:RDS cluster
aws rds modify-db-cluster --db-cluster-identifier <RDSのDB名前> --vpc-security-group-ids sg-XXX （no-accessのSG id）
```

どのサービス次第コマンド変わります。Security groupはどのサービスでも問題ない、VPCだけを気をつけるべき。

:::note warn
びっくりしたところ、elasticacheの２件ありました、redisとmemcacheですが、やり方が違います、redisはreplication-groupを変更ですが、memcacheはmodify-cache-clusterを使う。
:::


## 結論

使ってるシステム次第でやり方が変わるので自分で決めるしかないです。この記事を書いた時はまだお試しでやってましたですが、やっと本番をやったらちょっと気をつけるべきものもありました！

:::note alert
no-accessのSGを付けたら新規のコネクションを貼れないですが、まだコネクション付けてるサーバーなどはこのコネクションはまだ稼働中です！自分で切るしかないです
:::

### コネクションを外す方法
#### mysql/aurora :

```
mysql -h <エンドポイント> -p -u <ユーザー> mysql -s -e "SELECT GROUP_CONCAT(ID) FROM information_schema.PROCESSLIST WHERE USER = '<ユーザー>';"
GROUP_CONCAT(ID)
1765260,1765256,1669793,1445918,1720350,1720349,1669739,1720368,685452,685365
``` 
これはコネクションのプロセスリストです。リストあったらプロセスをkillするべきです。
```
mysqladmin kill 1765260,1765256,1669793,1445918,1720350,1720349,1669739,1720368,685452,685365 -h <エンドポイント> -p -u <ユーザー>
```
#### redis

RedisはまだRDSと違って、一時的な再起動など出来ません。Multi-AZこクラスタあったら出来ます。

一旦マインのノードをfailoverして、failoverが無事に終わったらこの２番目のノードを再起動すれば、マインのノードに戻るし、コネクションもなくなります。


:::note alert
大注意！
マインのノードを再起動すれば、データが消えます！確かにコネクションなくなるけどデータもなくなります。
:::


fin.