AWS上のシステムを維持管理して得たハマりポイント

#はじめに

• 現在、とあるAWSのシステムのインフラの維持管理を担当しているが、AWSやパブリッククラウドならではのところでハマったポイントについてとりとめもなくご紹介したい。

• WEBではAWSの新機能の紹介や構成検討の情報は結構載っているものの、このあたりの地味な情報はなかなか見た事がなかったので記載しようと思った次第。

• 特にオンプレからAWSへの移行を検討されている方に参考なれば幸いです。

• 記載内容に誤りがありましたら、ご指摘頂けれると大変ありがたいです！

#ハマりポイント1. Auroraはバージョンダウンできない！

• Auroraはバージョンダウンの機能が(今のところ)無い。

• バージョンアップ作業における業務閉塞中のコンチプランとして、事前に取得したスナップショットからAuroraクラスタの再作成等が考えられるが、業務閉塞解除後だとスナップショット取得以降の全ての更新を手動で追い付く必要があるため、実質不可能。

• そのため、私の担当しているシステムでは業務閉塞解除後に問題が発生した場合は、対策前進の方針としている。

• 業務閉塞解除後もコンチ発動できる様にするためには、DMSで同期させておく、等の個別の検討が必要。

#ハマりポイント2. Aurora(PostgreSQL)のバージョンを指定できない！

• Aurora (PostgreSQL)のパッチバージョン(2.5.1の1の部分)はDBエンジンのバージョンアップ時に明示的に指定できず、常にバージョンアップ時点の最新のものが適用される。

• そのためバージョンアップ対応の際、開発環境でのノンデグテスト実施時とその後の本番環境でのリリース時で異なるパッチバージョンとなる可能性がある。

• 私が担当しているシステムではノンデグテストを実施していないパッチバージョンでのリリースを避けるため以下の対応方針とした。

1. リリース直前に開発環境Auroraでバージョンアップを実施し、万が一パッチバージョンがテスト時より新しいものになったらリリース中止。新しいパッチバージョンで再度ノンデグテスト実施。

2. バージョンアップリリース後の確認でパッチバージョンが新しいものとなっていたらコンチ発動で旧戻し。

• どこまで神経質になるのかという話ではあるが、、、テストしていないものはリリースできないという原則に従った方針。
  Aurora(MySQL)だとパッチレベルまでユーザが指定できるらしい。Aurora(PostgreSQL)でも指定できる様にしてほしい！