未来の自分が幸せになることを願ってAWSの各作業をここに記します。
RDS
RDSの自動起動対策
RDSは7日間の停止後に自動で起動してしまう仕様が存在する。
稼働していないシステムで使用しているRDSは止めておきたいという要望が上がってきた。
7日間ごとに停止を手動で行うのは面倒くさすぎるし、ヒューマンエラーが発生する可能性がある。
そんな時に EventManeger にてRDSの自動停止を達成する事ができた。
やったこととしては、以下の通り。
- RDSの自動停止/起動 のスクリプトをLambda で定義
- Lambdaスクリプトを EventManeger にて7日周期で実行するように定義
- 起動 → 停止 の順番で実行するようにしないと、RDS本体の再起動とLambdaスクリプトの停止処理が同時刻に実行されてしまい、自動停止が出来ないよ
Aurora
クラスターとインスタンスという概念がある。
Blue/Greenデプロイ
ダウンタイムを限りなく減らすデプロイ手法のこと。（2系統の環境を作成し、ユーザーが使用しているシステムに影響を少なくする）
当手法では、エンドポイントの切り替えを行う必要がないため、プログラマー目線だとかなり作業が楽。（インフラ担当の作業範囲で収まるため）
実際に経験したユースケースは以下の通り。
- RDS for MySQL の5系から8系へのアップグレード
- インスタンスサイズの変更
上記対応を行った際のダウンタイムは2 ~ 3分程度で切り替えが行われた。これはかなり凄いことだと思う。
以前までの対応だと、以下の対応があると思われるが、当手法ではコンパネから手軽に実施することができる。
- 本番環境とは別にMySQLサーバーを構築し、各種テストを実施後に現環境と旧環境の切り替え
切り替え後はエンドポイントの切り替えを行う必要がある。 - システムメンテナンス期間を設け、現環境の変更を行う。
Blue/Greenデプロイは素晴らしい。。。
インスタンスタイプのサポート期日は守ろう
とあるタスクにて、RDSの インスタンスタイプのアップグレード & MySQLのバージョンアップ の作業があった。
その際の作業方法として、ダウンタイムを可能な限り削減するべくBlue/Greenデプロイを想定していたが、T2系インスタンスのサポートが終了していたため、Blue/Greenの作成が出来なかった。
本来であれば Blue/Green を作成後にGreen環境でインスタンスタイプのアップグレードとMySQLのバージョンアップを考えていたが、こうも上手くいかないとは思わなかった。
代替手段として、RDSのスナップショットからサポートされているインスタンスタイプで新規インスタンスを起動し、アプリケーションのエンドポイントを切り替える方法を考えたが、エンジニアが関与していないシステム（Redash等が上がっていたが、複数のサービスが連携していると報告が上がってきた）があるため、この手法は取れなかった。
そのため、エンドユーザーにダウンタイムを許容してもらう形で現行環境のRDSをインプレースで対応することになった。
エンジニアのプライドとして許せなかったが、前任の構築者が既にいなかったことやI/Oの遅さからユーザーからのクレームがあり早急に対応する必要があったので仕方がない結果となった。
（このタスクは他チームのインフラを面倒みることになっていたので余計に情報が絡み合ってめんどくさかった）
最終的には深夜作業で対応することになり、なんとか目的を達成することが出来た。
今後の教訓としては、インスタンスタイプのサポート期限は守ろう。
パラメータグループはデフォルトを使うな
時間がないからと言って、AWSが用意しているパラメータグループを使うな。
以下の問題が起きる
- Slow Query の出力がない
- クエリの実行時間の制限がない
問題の発生に気付けないのは大きな問題だ。
EC2
Amazon Linux2023 は remiリポジトリが使えないぞ
Amazonlinux2023 はAWSさんが独自で管理しているOSらしいので、remi リポジトリがサポートされていない。
epel も使えない。
Q: AL2023 は AL2 のような Amazon-Linux-Extras を搭載していますか?
A: いいえ。AL2023 には extras はありません。言語ランタイムなどの高レベルのソフトウェアパッケージの場合、四半期ごとのリリースを使用して、リポジトリで提供されるデフォルトパッケージに加えて、個別の名前空間化されたパッケージとしてメジャー/マイナー更新をパッケージに追加します。 例えば、Amazon Linux 2023 のデフォルトの Python バージョンは 3.8 である可能性がありますが、Python 3.9 (python39) が利用可能になると、別の名前空間化されたパッケージとして追加されます。これらの追加パッケージは、アップストリームリリース頻度とサポートモデルに厳密に従います。また、それらのサポートポリシーは、コンプライアンスとセキュリティのユースケースのために、パッケージマネージャーによってアクセスされることがあります。デフォルトパッケージは、AL2023 の存続期間を通じてサポート対象であり続けます。
サポート切れの PHP7.4 を使いたいという要件を達成するため、PHPの公式サイトからソースをビルドする事を考えたが、 php-fpm の導入及び関連する拡張機能の有効化の方法が分からなかったため、当手法は断念。
代わりに Rocky Linux を選択し、remi リポジトリからPHP7.4のインストールを行った。
（そもそもサポートの切れている言語Version 使うなよというお話でした
OSのメンテナンスは定期的に
10年近く稼働している一度もOSの再起動を行ったことのない EC2 のメンテナンス作業を行うタスクがあった。
（何で誰も手つけて来なかったの？馬鹿じゃないの？
構築した人は既におらず、インスタンスの中身がどうなっているかわからない状況だったため、作業前に以下の対応を行った。
- EBS バックアップ取得
- AMI バックアップ取得
- インスタンスの中で使用しているプログラムについての調査
- 各種言語のバージョン(拡張機能
- cron
- シェル
- VPCの構成
とりあえず結果からいうとデータの損失等が発生せず作業を終了することができた。
（やったこととしては、インスタンスサイズのアップグレード と ストレージのアップグレード。
若者に伝えたいのが定期的にメンテナンスを行うことと運用がしやすいように設計書なり構成図なりを残すこと。
（まじで何でも良いので、データとして残すことをオススメします。分かる人が見たら多少ズレのある設計書でもなんとなく予想がつくため。
