Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
1年間のポストモーテム運用とそこから生まれたツール sre-advisor / SRE NEX...
Search
FUJIWARA Shunichiro
May 14, 2022
Technology
6
13k
1年間のポストモーテム運用とそこから生まれたツール sre-advisor / SRE NEXT 2022
SRE NEXT 2022
2022-05-14 14:45〜15:15
https://sre-next.dev/2022/schedule#jp15
FUJIWARA Shunichiro
May 14, 2022
Tweet
Share
More Decks by FUJIWARA Shunichiro
See All by FUJIWARA Shunichiro
alecthomas/kong はいいぞ / kamakura.go#7
fujiwara3
1
300
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
9
1.1k
「最高のチューニング」をしないために / hack@delta 24.10
fujiwara3
21
4k
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
10
4.5k
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
2
1.5k
awslim - Goで実装された高速なAWS CLIの代替品を作った/layerx.go#1
fujiwara3
6
760
AWS CLIの起動が重くてつらいので aws-sdk-client-go を書いた / kamakura.go#6
fujiwara3
7
10k
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
31
7.1k
fujiwara-ware OSSをひたすら紹介する/ya8-2024
fujiwara3
8
810
Other Decks in Technology
See All in Technology
20241220_S3 tablesの使い方を検証してみた
handy
3
320
ブラックフライデーで購入したPixel9で、Gemini Nanoを動かしてみた
marchin1989
1
520
サーバレスアプリ開発者向けアップデートをキャッチアップしてきた #AWSreInvent #regrowth_fuk
drumnistnakano
0
190
小学3年生夏休みの自由研究「夏休みに Copilot で遊んでみた」
taichinakamura
0
150
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
120
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
31k
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
38k
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
[Ruby] Develop a Morse Code Learning Gem & Beep from Strings
oguressive
1
150
10分で学ぶKubernetesコンテナセキュリティ/10min-k8s-container-sec
mochizuki875
3
330
生成AIをより賢く エンジニアのための RAG入門 - Oracle AI Jam Session #20
kutsushitaneko
4
220
Oracle Cloud Infrastructure:2024年12月度サービス・アップデート
oracle4engineer
PRO
0
170
Featured
See All Featured
Docker and Python
trallard
42
3.1k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
For a Future-Friendly Web
brad_frost
175
9.4k
Site-Speed That Sticks
csswizardry
2
190
Statistics for Hackers
jakevdp
796
220k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Making Projects Easy
brettharned
116
5.9k
The Cost Of JavaScript in 2023
addyosmani
45
7k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
170
How to Ace a Technical Interview
jacobian
276
23k
Transcript
1年間のポストモーテム運用と そこから生まれたツール sre-advisor 2022.05.14 SRE NEXT 2022 面白法人カヤック 藤原俊一郎 @fujiwara
@fujiwara SREチーム 自社サービスを主に担当 ISUCON 11優勝 / ISUCON 12出題 github.com/kayac/ecspresso Amazon
ECS デプロイツール github.com/fujiwara/lambroll AWS Lambda デプロイツール
Game & Community
Agenda SREチームでポストモーテムを1年半運用してみた ポストモーテムの運用から sre-advisor というツールが生まれた
ポストモーテムとは? postmortem=事後検証 システムにインシデント発生したことによる影響、緩和や解決のた めに取られた行動、インシデントの原因、再発防止策などをまとめた文書
なぜポストモーテムを統一運 用しようと思ったのか カヤックのSREチームはいわゆる 「Embedded SRE」 自分が関わっていないインシデントは把 握しづらい SRE以外のエンジニアではなおさら
ポストモーテムで知見を共有したい インシデント発生時に実際に手を動かす人がどうしても固定化されてしまう 経験が多かったりチーム歴が長いエンジニアが速攻で対応を済ませがち → あらたに経験を積む機会が減ってしまう インシデントから得られた知見を共有したい 2020年10月から各チーム横断で統一運用に取り組むことに
取り決めた運用フロー あらかじめテンプレートをGoogle ドキュメントで用意 チーム内でレビューして作成 月に1回、Slackチャンネルで 「先月のポストモーテム」 興味を引く一言コメント付き
通称「月刊ポストモーテム」
「非難をしない」こと ポストモーテムで批判を行わないことは、SRE の文化における信条です。ポストモーテ ムが本当に非難を伴わないようにするためには、悪い行動や不適切な行動をもって特定 の個人やチームを糾弾することなく、インシデントに影響を及ぼした原因を特定するこ とに集中しなければなりません。非難なくポストモーテムを書くための前提となるの は、インシデントに関わりを持ったすべての人々が善意の下で、知り得た情報をもって 正しい行動をとったものと考えることです。個人やチームの「間違った」行いに対する 指弾と不名誉の文化が広がってしまえば、人々は処罰を恐れて問題を公表しようとしな くなります。
O'Reilly SRE サイトアビリティエンジニアリング 15章 これは特に取り決めも心配もしなかった 元々社内の文化として、特定の個人を非難するような風潮はない
ポストモーテムを書くかどうかの判断基準 プロダクトの利用者に大きな影響を与えたインシデントについては必ず書く 「大きな」の定義は当初は漠然 SLI/SLOを運用しているチームではエラーバジェットの消費量を基準に メンテナンス時などに想定外の事象が発生した場合は、積極的に書く 他のチームへ想定外だった事例を共有する
たまには1本もない月もあります
ポストモーテムを運用してみてよかったこと 1. 原因追及や根本原因の解消が放置されにくくなった 2. 社内の他のプロダクトで起きている事例を知る機会に 3. プロダクトが消滅しても、その事例が保持される
1. 原因追及や根本原因の解消が放置されにくくなった インシデントはいつ発生するか分からない 業務時間外の夜間や休日に発生 → その場での対応でおしまいになりがち ポストモーテムを書く → 発生原因やタイムラインを詳しく調査する必要がある 根本原因の解消や再発防止のために時間を使えるようになった
2. 社内の他のプロダクトで起きている事例を知る機会に (業態的に)社内には多数のプロダクトがある 他のプロダクトで起きているインシデントを知る機会になった 自分が関わっていない場所のインシデント → 共通する技術要素を使っていれば参考にでできるように
3. プロダクトが消滅しても、その事例が保持される 社内に多数のプロダクトがある ⇔ 常に多数のプロダクトが誕生、終了 プロダクト内に閉じたドキュメントでは見返されなくなってしまう 統一的なとりまとめで終わってしまったプロダクトの事例も永続化できるように
発生要因を振り返って気が付いたこと クラウドインフラやミドルウェアなどの設定(不備)が発生要因の場合がけっこうある 通常時には問題ないが、高負荷や長期間の運用で… これらをどうやって炙り出すか?
【例】とあるポストモーテムより 根本原因 ***の情報取得の権限確認の部分がN+1クエリ状態になっていた。その結果、***管理サ ービスの前にいるAppMesh Envoyで接続数が増大してファイルディスクリプタが枯渇 し、***管理サービスのECSタスクが終了するという状態が起きた。 N+1クエリ状態になっていた。 ECS Taskの各コンテナにulimitを設定していなかったため、ファイルディスクリプ タが枯渇しやすい状態だった。
「ulimit がデフォルト(nofiles 1024)だと高負荷時に足りないことがある」 対策「ECSタスク定義を確認する」……だれがどうやって?
「チェックシート」はトイル 「リリース前にこのチェックシートを確認して提出してください!」 継続的に運用するとインフラリソースやミドルウェアは増えていく そのたびにチェックシートを埋めるのは…… トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰 り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量 がサービスの成長に比例するといった傾向を持つもの O'Reilly SRE サイトアビリティエンジニアリング
5章 SREならエンジニアリングで解決しよう!
sre-advisor 社内ツールを作った AWS SDK for Go v2を使用 アカウントに存在している各種リソースの設定を取得、問題がある内容を検出 結果を text
/ markdown で出力する CLI ツール
sre-advisorが検出する項目(例) Amazon ECS のタスク定義で、コンテナにulimitが定義されていない デフォルトのnofiles 1024では足りないことがある ALB のデフォルトアクションで forward を指定
IPアドレスなどによる直接アクセスが意図せず貫通する デフォルトアクションでは静的に404を返却 forwardはHostヘッダ条件などのルールで行うのを推奨 AWS Lambda の呼び出しで alias や revision を指定していない デプロイ中に$LATESTを呼び出すとエラーが発生する可能性(2021年〜) Amazon RDS でデフォルトのパラメータグループを使っている デフォルトパラメータグループは編集できない 変更する際に再起動が必要になる
検出結果(例) [Critical] ECS のタスク定義『example:1 』内のコンテナ nginx にはulimits の設定が足りていません。 [Warning] ELB
ロードバランサー『web 』のデフォルトアクションに"forward" タイプが使用されています。 [Warning] Lambda 関数『foo 』の$LATEST は『arn:aws:events:ap-northeast-1:123456789012:rule/bar 』 からのlambda:InvokeFunction の許可が与えられてます。 [Warning] DB インスタンス『db1 』のDB パラメータグループが『default.aurora-mysql5.7 』です。
どう直せばいいのか推奨も表示する [Critical] ECS のタスク定義『example:1 』内のコンテナ nginx にulimits の設定を追加してください。 nofile,nproc に関して以下のように設定してください。
"ulimits": [ { "name": "nofile", "softLimit": 10000, "hardLimit": 10000 }, { "name": "nproc", "softLimit": 10000, "hardLimit": 10000 } ], ECS Fargate タスクでのデフォルトのnofile のソフト制限は1024 です。 設定していない場合、Too many open files のようなファイルディスクリプタの上限に達して ECS タスクが突然終了するような現象が起きる可能性があります。
AWS Trusted Advisor の警告も一緒に取得 AWSコンソールを見に行くのが面倒なのでついでにAPIで取得して表示 [Warning] Trusted Advisor[cost_optimizing 関連付けられていない Elastic
IP Address] CheckID:Z4AUBRNSmz [Critical] Trusted Advisor[fault_tolerance Amazon EBS スナップショット] CheckID:H7IgTzjTYb
Trusted Advisorの推奨はAPIで返ってくるものを表示 DescribeTrustedAdvisorChecks APIが親切にHTMLで文字列を返してくれる 適当にtext化 ───────────── 推奨アクション1────────────── [Warning] Trusted Advisor[cost_optimizing
利用頻度の低い Amazon EBS ボリューム] をOK にしてください。CheckID:DAvU99Dc4C Amazon Elastic Block Store (Amazon EBS) ボリュームの設定をチェックして、 ボリュームが十分に使用されていない可能性を警告します。課金はボリューム作成時に開始します。 ボリュームがしばらくの間アタッチされないままになっているか書き込みアクティビティが非常に少ない ( ブートボリュームを除く) 場合、そのボリュームはおそらく使用されていません。 ...( 略)
指摘されても無視したいことはある [Warning] Trusted Advisor[fault_tolerance Amazon RDS Multi-AZ] がOK ではありません。 CheckID:f2iK5R6Dep
「開発用のRDSしかないのでMulti-AZにはしていないんですよ」 設定ファイルでIDを指定すると指摘されなくなる rules: trusted_advisor: suppression_rules: - check_id: f2iK5R6Dep
結果を GitHub Flavored Markdown で出力できる $ advisor run --reporter github
GitHub Actionsで実行 → gh issue create でissueにできる Advisor が完走しました。: 0 Critical, 1 Warning, 2 Suppressed, 30 Good 1 箇所の推奨アクションがあります。 <details> <summary> 動作ログ </summary> ```properties [Warning] ELB ロードバランサー『web 』のデフォルトアクションに"forward" タイプが使用されています。 `` ` </details> ## 推奨アクション - [ ] [Warning] ELB ロードバランサー『web 』のデフォルトアクションには"forward" タイプを使用しないでください。
定期的に指摘潰し祭り GitHub Actions workflow ポチ sre-advisor が issue 作成 推奨アクションを分担して解消
無視したいものは設定ファイルで 人が見慣れた警告を無視する習慣を付け ないように運用
社内ツールの配布方法 sre-advisor は現在 internal repo private/internal repo の GitHub Release
を取得するのはちょっと面倒 (このためにpersonal access tokenを用意するのは…) GitHub Actionsでビルド → Amazon S3へ配置する Organization の AWSアカウントで認証済みなら取得できるようにしてみた
S3 Bucket Policy の設定でできます Condition で "aws:PrincipalOrgID" に AWS Organization
ID を指定する → その Organization のアカウントからのみアクセスを許可できる { "Version": "2012-10-17", "Statement": [{ "Sid": "DelegateS3Access", "Effect": "Allow", "Principal": "*", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": ["arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*"], "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-999999999" // ← ここがポイント } } }] }
まとめ カヤックではSREチーム主導でポストモーテムを1年半運用してみました ポストモーテムを書くことには利点がたくさんあります ポストモーテムで得られた運用上の知見を共有するため sre-advisor というツールを作りました インシデント → ポストモーテム →
sre-advisor → 事前検出 → インシデントから得られた知見をコード化して平和を目指しましょう
LICENSE Twemoji by Copyright 2021 Twitter, Inc and other contributors
is licensed under CC-BY 4.0