みなさんが経験したことあるだと思いますがAWSがどんどんリソースを新しくにしてますが、古いリソースがいずれなくなってます、それのせいで前から稼働してるリソースを上げるしかないです。
今年の12月1日はいくつのインスタンスタイプがなくなります
前世代のノード 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で変更するべき。
それでインスタンスタイプを選択してで変更出来るます！
もちろんダウンタイムが発生します、変更中はアクセス出来ません！データベースの大きさ次第で時間がかかってます。
ですが、検証したい！インスタンス変更はそんなに変わらないはず、DBのバージョンだと結構変わりますがインスタンスは本当にハードウェアなのでそんなに変わらない。
検証するために新しいr3を作って、r5に変更すれば良いですね！これが悲しいところです、古い世代のインスタンスを作成出来ません。。じゃ、r5の変更して、問題あったらr3 に戻せばようですね！これも悲しい、r5になったらr3に戻れない。泣。
安全のやり方
話に戻ると、VPCからのアクセス制限、Security Groupを確認して、インスタンスの中にDB入ってます。
安全にするために両方古い世代と新しい世代を同時に作ります。
ですが、同じタイミングだとデータの依存が厳しい、バックアップから作るだとしても作り中のr5が同じデータじゃない。もっとやらなきゃ！問題は古い世代をアクセスがあれば意味がないです。
3ステップ
順番とタイミング
- 古い世代をアクセス止める。
- バックアップを作成する。
- バックアップから新しい世代を作成する。
- 新しい世代のアクセスポイントをコードに修正とリリースする。
Security Groupの追加
VPCを外せないと変更出来ませんので残るはSecurity Groupは変更出来ます！
今あるセキュリティー設定を外して、新しいSGをインスタンスを付けて、アクセス出来ないようにすれば、無事にバックアップ出来ます。
こんなようなSGあれば、アクセス出来ません！TCPを0だけ設定すれば問題ないです！
アクセス順番
設定を確認できるようになったら、次はタイミングの問題です！
順番として：
- 古い世代の今あるSGを外して、no-accessのSGを付けます。
- アクセスが出来なくになった、バックアップを作成する。
- バックアップ終われば、そのバックアップからインスタンスを作成する。
- 新しい世代のエンドポイントARNをコード修正して、サーバーへのリリースする。
画面操作だと重くになるのでSGの変更をaws cliでやります！
aws elasticache modify-replication-group --replication-group-id <redis cluster名前> --security-group-ids sg-XXX （no-accessのSG id）
aws elasticache modify-cache-cluster --cache-cluster-id <memcache cluster名前> --security-group-ids sg-XXX （no-accessのSG id）
aws rds modify-db-cluster --db-cluster-identifier <RDSのDB名前> --vpc-security-group-ids sg-XXX （no-accessのSG id）
どのサービス次第コマンド変わります。Security groupはどのサービスでも問題ない、VPCだけを気をつけるべき。
びっくりしたところ、elasticacheの２件ありました、redisとmemcacheですが、やり方が違います、redisはreplication-groupを変更ですが、memcacheはmodify-cache-clusterを使う。
結論
使ってるシステム次第でやり方が変わるので自分で決めるしかないです。この記事を書いた時はまだお試しでやってましたですが、やっと本番をやったらちょっと気をつけるべきものもありました！
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が無事に終わったらこの２番目のノードを再起動すれば、マインのノードに戻るし、コネクションもなくなります。
大注意！
マインのノードを再起動すれば、データが消えます！確かにコネクションなくなるけどデータもなくなります。
fin.