メインサービスのDBを1年でAurora1から段階的にAurora3へアップグレードした話

メインサービスのDBを1年でAurora1から段階的にAurora3へアップグレードした話  JAWS-UG SRE支部 #8 春のAurora祭り🌸  マクアケSREチーム　稲村一真 

自己紹介  氏名　　　　 : 稲村一真  会社名　　　 : 株式会社マクアケ  所属チーム : SRE 
ロール　　　 : チームリード  Xアカウント : kzm0211  MySQL経験 : =インフラエンジニア歴  　　　　　　但しDBAのような経験は　　　　　　無し 

代表者  中山　亮太郎  設立  2013年5月1日  上場市場  東京証券取引所グロース市場  従業員数  約190名  所在地 
東京都渋谷区渋谷2-16-1  Daiwa渋谷宮益坂ビル 10F  他、関西/名古屋/北陸/中四国/九州/韓国      株式会社マクアケ  アタラシイものや体験の応援購入サービス  想いをもつ事業者と生活者を結びつける新しいプラットフォーム 

デプロイフローメインDB Aurora1 タイムライン  2022.10  入社  2022.11  Aurora2  検証開始  2023.02 
Aurora2  切り替え  メンテナンス  2023.08  Aurora3  検証開始  2023.12  Aurora3  切り替え  メンテナンス  主にやったこと  １．MySQL, AWS公式ドキュメント , 各社ブログの調査   ２．CI, 開発, 本番環境などインフラ作成   ３．開発チームスケジュール調整   ４．QAチーム依頼（動作チェック） →修正依頼  ５．社内調整（メンテナンス日やリリース調整等）   ６．メンテナンス作業実施（当日のメンテナンスは 4人で実施）

デプロイフローメインDB Aurora1 主にやったこと  １．MySQL, AWS公式ドキュメント, 各社ブログの調査  ２．CI, 開発, 本番環境などインフラ作成 
３．開発チームスケジュール調整  ４．QAチーム依頼（動作チェック）→修正依頼  ５．社内調整（メンテナンス日やリリース調整等）  ６．メンテナー（メンテナンスは4人） 

デプロイフローメインDB Aurora1 検討した切り替え手法  手法  メリット  デメリット  MySQLのbinlog切り替え  MySQLの運用に慣れていれば最もサービスダウン時間を軽減可能
  binlog運用に慣れていなければ運用リスクがある  切り戻しフローを検討する必要がある   インプレースアップグレード   上記同様、シンプル   切り戻しフローを検討する必要がある   枯れていない, 失敗事例がある   Blue Green  上記同様（詳細調査は未実施）   枯れていない, 事例が少ない  xxx dump  シンプル  データ量によっては厳しい   スナップショットから新規作成   （Terraform)  シンプル、旧環境を残しておける   サービスダウン時間が長くなる   Aurora2, Aurora3の検証時に都度AWS SAの方に相談  採用 

デプロイフローメインDB Aurora1 TerraformによるIaC化で作業のシンプル化  １．スナップショット作成  ２．クラスター作成（スナップショットから）  ３．インスタンス作成（Writer）  ４．インスタンス作成（Reader）  ５．カスタムエンドポイント作成  •
検証が容易になった→メンテナンス時間の計画が立てやすくなった  • 旧環境のクラスターが残せる→切り戻しのしやすさを優先  IaCされていなかったDB→早々にIaC化を実施 

デプロイフローメインDB Aurora1 Route53によるクラスターエンドポイント切り替え  プライベートホストゾーン  TTLを低く設定  • Route53でレコード変更→エンドポイント切り替えに複数デプロイが不要  • TTL低く→フェイルオーバーの遅延時間は
許容範囲  • クラスターエンドポイントに含まれるランダム識別子は、アカウントとリージョンで固定なので事前に準備可能  App  DB 

切り替え前  モノリス結合データベース  メインDB  Aurora1  5年物  App A  App B  App
C  App D  モノリシック  フレーワムワーク   メンテナンスのときの   デプロイ大変かも...  クラスターエンドポイント URL 

Route53でエンドポイント変更  メインDB  Aurora2  New!!  メインDB  Aurora1  5年物  App A  App
B  App C  App D  Route53で作成したエンドポイント URL  不要  Route53のレコード  切り替えのみでOK 

デプロイフローメインDB Aurora1 パラメータグループの比較と統合  • 手動で何を変えたか、影響があるかどうかを調査   • インスタンスパラメータグループが存在していたが、本当に必要かを判断してクラスターパラメータグループに統合 
◦ クラスターパラメータグループ →インスタンスパラメータグループ（ default）  比較画面のサンプル

デプロイフローメインDB Aurora1 PerformanceInsights  Sample • 7日間なら無料なので要有効果  • 半信半疑で有効化したが現状は大量アクセスなどがあった際
にトップクエリなどをチェック→ スロークエリチェック  • 但し、有効化にはインスタンス再起動が必要なので注意 

デプロイフローメインDB Aurora1 SSMオートメーションによる自動起動の停止  停止  7日後  起動  停止  切り戻しに備えてしばらくはクラスターを停止して様子見  EventBridge 
SSM Automation 

デプロイフローメインDB Aurora1 Aurora3, ReaderのTempTableの仕様  引用: https://aws.amazon.com/jp/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/ MySQL8.0.28  Aurora3.04 Reader 

デプロイフローメインDB Aurora1 • まとめ  • これからアップグレード検討している方へ  ◦ MySQL, AWS公式ドキュメント、各社事例ブログチェックは必
須  ◦ アップグレードには複数の選択肢があるので、自社の状況にあわせて最適な方法を選択すると吉  • やってよかった  ◦ AWS SAへ相談→解像度UP  ◦ IaCによる作業→手順のシンプル化  ◦ Route53による切り替え→デプロイ時間の短縮化  ◦ 事前メンテナンスリハーサル→手順書ブラッシュアップ 

デプロイフローメインDB Aurora1 ご清聴ありがとうございました😊 

メインサービスのDBを1年でAurora1から段階的にAurora3へアップグレードした話

メインサービスのDBを1年でAurora1から段階的にAurora3へアップグレードした話

inamuu

More Decks by inamuu

Featured

Transcript