RDS Blue/Green Deployment を使って Aurora MySQL 5.7 → 8.0 に移行を試した

タダです.

Aurora MySQL 5.7 のサポート期限が今年の10月末に迫っているため,データベースエンジンのバージョンアップを進めています.そんな中で RDS Blue/Green Deployment を使って開発環境のバージョンアップを行ったのですが,その時に感じた良さをまとめてみます.

RDS Blue/Green Deployment の概要

RDS Blue/Green Deployment は最小限のダウンタイムでデータベース環境の更新や移行を実現するための機能です.Blue/Green で2つの完全に独立したデータベース環境を用意して Blue が移行元の環境で Green が移行先の環境なのですが,Blue → Green にはデータがレプリケーションされているためタイミング合わせて切り替えを行います.

docs.aws.amazon.com

RDS Blue/Green Deployment の良さ

データベースエンジンバージョンアップがボタン1つでできてしまう手軽さ

データベースエンジンバージョンアップは以前だとむちゃくちゃ大変なイメージが有りましたが,RDS Blue/Green Deployment はそのイメージを払拭してくれました.というのもボタン1つで今回の Aurora MySQL 8の環境ができあがり,環境切り替えまでのデータレプリケーションも張り続けてくれ,切り替えもボタン一発で切り替えられました.事前準備や検証は一定ありましたが,実際の移行はむちゃくちゃ簡単でした.

関連記事

aws.amazon.com

docs.aws.amazon.com

環境移行後の Aurroa エンドポイントは引き継がれる

次の良さは Aurora のエンドポイントは Blue 環境から Green 環境に引き継がれます.当然といえば当然なのかもしれませんが,エンドポイントが引き継がれるおかげでアプリケーションの環境変数や DNS で登録してるレコードに影響を与えません.これは運用上ありがたい機能でした.

Terraform の後追いを行う必要がほぼない

Aurora エンドポイントが引き継がれる点と関連しますが,Terraform で Aurora を管理してると移行後にどれくらい差分が出るのかが気になっていました.実際,データベースエンジンのバージョン以外はほぼ移行後の差分はでませんでした.差分として出たのは1つ目が Aurora AutoScaling の設定がなくなっていたことです.Green 環境にはその設定が引き継がれてないため,新規追加のリソースとして差分がでました.もう1つは DB クラスターパラメーターグループとパラメーターグループでした.これは family のパラメータを変数でデータベースエンジンのバージョンを渡していたからだったんですが,5.7と8のパラメーターグループを別々で作って family の値を固定値にすれば差分はでないため,Terraform の影響もほぼなくてありがたかったです.

関連記事

registry.terraform.io

registry.terraform.io

まとめ

RDS Blue/Green Deployment を Aurora MySQL のバージョンアップを行った時に感じた良さをまとめました.

Aurora のデッドロック情報を抽出して CloudWatch Logs に出力する

タダです.

Aurora のデッドロックの発生時に SHOW ENGINE INNODB STATUS を実行し, LATEST DETECTED DEADLOCK の詳細情報を抽出して開発メンバーに連携する作業が時折発生してどうにかならんかな〜と思っていた際に自分の改善案を持っていって所属のチームで相談してみたところ, innodb_print_all_deadlocks というパラメーターを教えてもらいました.この記事ではこのオプションの概要と設定方法を記してきます.

innodb_print_all_deadlocks の概要

innodb_print_all_deadlocks は SHOW ENGINE INNODB STATUS からデッドロックの情報についてのみ出力するパラメーターです.まさに自分が今回やろうとしてた改善に適うパラメーターでした.

このパラメータを有効にすると (1 に設定)、InnoDB ユーザートランザクションに関連するデッドロックが MySQL エラーログに記録されます。それ以外の場合、この情報は SHOW ENGINE INNODB STATUS コマンドを使用して最後のデッドロックについてのみ利用できます

引用記事

aws.amazon.com

関連ドキュメント

docs.aws.amazon.com

Aurora MySQL で innodb_print_all_deadlocks を有効化する

Aurora では innodb_print_all_deadlocks はクラスターパラメーターグループにあり,再起動は不要で指定できます.加えて,エラーログでデッドロックの詳細情報が出力されるので CluoudWatch Logs の出力有効化を行います.これで準備万端です.

Aurora MySQL 設定パラメータ - Amazon Aurora

デッドロック発生時のログの中身

デッドロックを試しに発生した時の CloudWatch Logs の通知内容を確認してみます.デッドロックが発生すると transactions deadlock detected, dumping detailed information のメッセージの次のログにまさに LATEST DETECTED DEADLOCK の詳細情報が出力されていました(本記事では内容部分は割愛しています).この結果を通知してあげれば,データベースにログインするオペレーションも無くなり,開発メンバーもすぐに内容確認できて良い運用のカタチを目指せそうです.

2024-03-14 02:09:32 xxxInnoDB: transactions deadlock detected, dumping detailed information.
2024-03-14 02:09:32 xxx-03-14 02:09:32 xxx
*** (1) TRANSACTION:
~各種情報~
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
~各種情報~
*** (2) TRANSACTION:
~各種情報~
*** (2) HOLDS THE LOCK(S):
~各種情報~
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
~各種情報~
*** WE ROLL BACK TRANSACTION (2)
=====================================

まとめ

Aurora のデッドロックの詳細情報を CloudWatch Logs に出力するパラメーターと設定方法をまとめました.

AWS CLI を使用して SQS のメッセージ滞留数の統計情報を取得

タダです.

AWS CLI の SQS に滞留してるメッセージを特定期間中の統計情報を取りたいと思って調査したので備忘録でまとめます.

SQS の滞留数取得

1時間ごとの SQS 滞留メッセージの最大値を取得したいとします.滞留しているメッセージ数は ApproximateNumberOfMessagesVisible なので,AWS CLI で実行するコマンドとして次のように実行しました.--statistics で SampleCount,Average,Sum,Minimum,Maximum のいずれかを指定する必要があり,今回は最大値を取りたいため Maximum を指定します.--start-time と --end-time で期間を YYYY-MM-DDTHH:MM:SSZ 形式で指定し,--period でメトリクスの取得期間を指定します.$((60 * 60)) で指定しているのは1時間の範囲で指定した場合で,この値は任意の値を乗算できます.

aws cloudwatch get-metric-statistics \
    --namespace AWS/SQS \
    --metric-name ApproximateNumberOfMessagesVisible  \
    --dimensions Name=QueueName,Value=[SQS名] \
    --statistics Maximum \
    --start-time 2024-01-01T00:00:00Z \
    --end-time 2024-02-01T00:00:00Z \
    --period $((60 * 60)) \
    --query "sort_by(Datapoints,&Timestamp)[][Timestamp,Maximum]" \
    --output text

まとめ

CloudWatch の統計情報から SQS のメッセージ滞留数を取得することをAWS CLI で取得したのが初めてだったのでまとめました.

『TechBrew in 東京 〜CI/CDパイプライン改善 最適化の取り組み〜』に参加して各社のCI/CDパイプラインの取組みを学んだ

タダです.

遅くなったのですが,「TechBrew in 東京 〜CI/CDパイプライン改善 最適化の取り組み〜」に参加してきたので,参加の感想をまとめていきます.

findy.connpass.com

イベント概要と参加目的

昨今、開発生産性を向上させるために、スピードと品質の両立のためにもテストやデプロイといった部分を自動化が進んでいます。資源の統一化、一元的な管理等の対応は急務であり、CI/CDの考え方や取り組みについて、様々な組織で工夫が凝らされています。

CI/CD はとても関わる技術領域で,他社の事例を聞いてみたくて参加しました.

発表のサマリーと感想

各発表ごとにサマリと感想をまとめていきます.

開発生産性と開発者体験の向上に向けたCI/CD改善の取り組み

@deliku0306さんによる CI/CD 改善の取組に関する発表でした.

サマリ

• CI は Github Actionsで CD が CodePipeline と CodeBuildの構成を取っている
• CI実行改善の止めにやったこと: キャッシュの利用/job 並列実行/Large Runnerの利用/reviewdog で Linter解析結果をコメント/CI 実行結果を Slack 通知
  • 今後の改善として CodeRabbit の AIコードレビュー導入を行う予定

発表資料

speakerdeck.com

AWSで構築するCDパイプラインとその改善

@shonansurvivorsさんによる AWS での CD パイプライン構成をどうやってとっているか,またその改善に関する発表でした.

サマリ

• CD は本番環境の強い権限を持ちがちなのを権限管理ができる CodePipeline に寄せた
  • CI は GitHub Actions
• CodePipeline/CodeBuild で行う処理の例: Flyway の実行/ecspresso の実行/Serverless Framework のデプロイ
• CD の品質を高めるために CD のコスパをよくして,速度と安定性を加味したパイプラインにする
  • 加えてIAMの権限を最小限にする
• 開発者から CodeBuild の一部を動かしたいっていう要求に応えるために環境変数で動かせるようにしたり柔軟な制御を入れている

発表資料

speakerdeck.com

CIは5分以内！素早い開発サイクルを支えるCI

@hamchance0215さんによる CI の時間の短縮事例でした.

サマリ

• CI は10分が限界値で5分を切るようにしている
  • 早くするための方法：GitHub Actions でテスト静的解析とセキュリティチェック
• バックエンドで行った改善
  • テストを直列でやると20~30分かかる
    • 並列実行する仕組みを作ってテストを8分割していることで5分以内にしている
• フロントエンドで行った改善
  • Typecheck に時間をかかっている
  • Nxをつかって CI を高速化:モジュールの依存関係を管理できるようになっていて,依存関係を解釈して関連するところだけ CI を実行する
    • 変更した箇所と依存した部分だけ CI が実行されてキャッシュも使われるため高速化ができてる

発表資料

speakerdeck.com

CI/CDボトルネックの把握とその先へ

@Kesin11さんによる CI/CD のボトルネック把握のための計測と解消に関する発表でした.

サマリ

• CI/CD の最適化としてやっていること
• 推測するな、計測せよ
  • ボトルネックを先に把握する
  • 意外なところに時間かかっているかもしれないから計測しよう
• クリティカルパスから最適化
  • 全体としてどこがクリティカルパスを把握して如何に早くするか
  • どう分析するのか
    • GitHub Actions には遅いワークフローの分析ができないぞ...
      • actions-timeline(workflow の可視化ができる)
      • 可視化は Mermaid でやる
    • 設定は楽にできる
• actions-timeline のその左記
  • 可視化の先:ボトルネックの改善は知識と経験が必要
    • 毎回サポートするのはスケールしない
    • ので、基本的なアドバイスを代行してくれるツールが欲しい
    • actionlint では足りない...
• キャッシュは時間が足りないので割愛
  • 懇親会で聞きたかった...

発表資料

www.docswell.com

デプロイ再考2024

@sugitak06 さんによるデプロイの原則から自社での取り組みに関する発表でした.

サマリ

• プロダクトごとに技術スタックが違って複雑 なので改めてデプロイとは何なのかを考えてみる
• デプロイとはソフトウェアを実行可能な状態に持っていくこと
• 原則：ビルドとデプロイの2フェーズ
  • ビルドにアプリケーションごとの差異はないし,事前にビルドやっていけば高速化できる
• 究極のデプロイ高速化のやり方
  • Blue/Green Deploy と Feature Flag Deploy
• estie 社の選択
  • 事前ビルドを行っている
    • ビルドは dev でだけ行って、他の環境は tagging する
  • ディスクイメージは全環境共用
• CI/CD ツールはフロー整理のために使いたい
  • アプリケーションごとの固有のロジックは入れない
  • 実際の処理はスクリプトなどを用意して読み込ませる
  • ビルドのロジックは Makefile とシェルスクリプトを外だし
    • 社内共通actionsを使って活用している

発表資料

speakerdeck.com

懇親会

懇親会参加したかったんですが,イベントに向かう最中に体調が悪くなっている気がしてそのまま帰りました...残念...

まとめ

CI/CD のテーマの勉強会で各社の取り組みを聴くことで新たな気づきを得ることができました.企画・運営のみなさん&発表されたみなさん ありがとうございました！

AWS Backup Restore testing のジョブ失敗を Slack に通知する

タダです.

AWS Backup Restore testing のジョブが失敗したら通知して監視できるようにしたいと思い,AWS Chatbot を通じて Slack 通知する検証を行いました.その設定をこの記事に記載します.

AWS Backup Restore testing のジョブの失敗通知設定方法

過去記事に記載した方法と同じなため割愛します.

sadayoshi-tada.hatenablog.com

EventBridge でジョブのステートをチェックする

EventBridge で AWS Backup Restore testing のジョブステータス遷移を見ることができ,その中に FAILED があったため,このイベントを SNS トピックを通知してみることにしました.

docs.aws.amazon.com

EventBridge ルールのイベントパターンは以下のように定義しました.加えて SNS トピックのアクセスポリシーは events.amazonaws.com から SNS 通知を許可しました.

イベントパターン

{
  "detail": {
    "status": ["FAILED"]
  },
  "detail-type": ["Restore Job State Change"],
  "source": ["aws.backup"]
}

SNS アクセスポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:ap-northeast-1:[アカウント番号]:[トピック名]"
    }
  ]
}

AWS Backup Restore testing のジョブの失敗通知結果

AWS Backup Restore testing ジョブで IAM 権限を意図的に不足した状態でテストを行ったところ,次のように Slack 通知されました.失敗した理由が Message に記載があり確認できます.

Slack 通知メッセージイメージ

まとめ

AWS Backup Restore testing のジョブ失敗を Slack 通知してみたので備忘録にまとめました.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com