継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

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

タダです.

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

innodb_print_all_deadlocks の概要

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

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

引用記事

aws.amazon.com

関連ドキュメント

docs.aws.amazon.com

Aurora MySQLinnodb_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 に寄せた
  • 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

『TechBrew in 東京 〜SRE大集合!信頼性を高める取り組み〜』に参加して各社の信頼性向上の取組みを学んだ

タダです.

TechBrew in 東京 〜SRE大集合!信頼性を高める取り組み〜」に参加してきたので,参加の感想をまとめていきます.

findy.connpass.com

イベント概要と参加目的

「自社では信頼性を高めるためにどのような取り組みを行っているのか?」をテーマのLTで各社の取り組みを共有し合える場

転職以降に他社の事例を聞いたり,話す機会がかなり減ったのを危惧して今回参加させていただきました.

発表のサマリーと感想

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

SREに活かすセルフ・アウェアネス

@syossan27さんによる SRE 文脈でのソフトスキルに関するお話でした.SRE に限らず組織で働くことは組織内で協調していく必要があると思いますし,Indeed 社では求人票に書かれているのは印象的でした.また,ポストモーテムで非難しないのは当然としてなぜなぜ分析をしてしまうと自己嫌悪に陥りやすいため What から入るのも印象的でした.

発表資料

SIEMってサイトの信頼性向上に寄与するの?

@yuta_k0911さんから SIEM を使ったセキュリティログ分析のお話でした.セキュリティログ分析はなかなか手を回すのは後手になりがちな印象がありますが,SIEM OpenSearch を使うことで分析しやすさがあるんだなという学びがありました.そして,分析するだけでなくプロアクティブなアクションにつなげていくことで信頼性向上に繋げる考え方は自分自身,足場を固める活動として日々やらねばと背筋が伸びました.

発表資料

チームと成長するSRE

@maruloopさんから開発者の成長とSREの成長に関するお話でした.自分が所属してきた組織で SRE のメンバーから導入したツールや仕組みなどは属人的になりがちな印象で,それらを如何に他の人に技術伝承していくかが長期的に大事だと思っています.考え方次第ですが,特定の人への負荷集中や人依存につながるのは個人的に良くないと思っていて同じ組織で可能な限り同一のオペレーションをできて全体としてのパフォーマンスが高い状態になったほうが良いかと思います.なので,発表の中での定期ハンズオンや SRE チームが各メンバーごとの多重ワークを許容し議論できる状態にあるのは素晴らしいと感じました.

発表資料

トイル撲滅から始める改善手法とその結果

@yjszk666さんの解決されたトイル撲滅のお話でした.トイル撲滅はむちゃくちゃ喫緊で自分も潰した話があったので共感の嵐でした.中でもトイルを誰もやりたくない仕事と定義してからそれを拾いに行ってから潰すムーブとトイルを潰す空気を作れているのが最高で,改めて自社のトイル撲滅をもっとやって向き合うべき課題の時間捻出に繋げたいと思いました.

関連記事

made.livesense.co.jp

発表資料

ジョインしたてのSREが信頼性向上に取り組む(監視設計編)

KK さんによる監視設計のお話でした.監視設計をビジネスフレームワーク(5W1H)に落とし込んでやっているのは初めて見た切り口ではありましたが,各設計項目ごとに必要な考慮事項が整理しやすくなるかもなと思いました.

イベントレポート zenn.dev

発表資料

ガチめなインフラエンジアから見たSRE

@barieroさんのキャリアで初めて SRE ロールになってからどんなことが求められているかを考察された発表でした.SRE がサービスの信頼性を高めるところを主眼に置いて関わるっていうのは同意で今後の信頼性向上の取組みも気なった発表でした.

発表資料

入社1ヶ月目でSREチームの方針とあり方を見直している話

@ohsawa0515さんによる出向された組織での SRE チーム方針とあり方を見直しているお話でした.技術組織はチームトポロジーに沿った組織体になっていて,SRE チームはプラットフォームの分類になっていたそうです.しかし,様々な課題から現場は各チームに Embeded SRE の形ではいっていき課題解決にあたられています.自分自身もやはり感じるのは課題に取り組みやすくするためにそのチームに所属して一緒に課題を解くことだと思っているため,その後の活動込みでどういう課題改善なされるのか楽しみになりました.

発表資料

Datadog実行基盤をEC2からECSへ移行してみた

@Y0u281さんによる Datadog の実行基盤の移行のお話でした.最初の課題提起から実行基盤を ECS に乗せる過程で得られるメリットとそれに伴う実績コストを評価した上で実行されてて Fact ベースな判断をされていて素晴らしいし,コスト削減にもつながっていて一石四鳥では?と思うほど取り組みでした.

発表資料

懇親会

お酒飲みつつ,各社のお話や雑談をさせてもらって楽しかったです.

全体の記念写真

個別で延長戦させてもらった時の写真

まとめ

久々のオフライン勉強会に参加して各社の取組みを聞くことができて勉強になりました.来週は CI/CD のテーマの勉強会があるので,これも参加してレポートを書きます.

findy.connpass.com