SRE NEXT 2022 2022-05-14 14:45〜15:15 https://sre-next.dev/2022/schedule#jp15
1年間のポストモーテム運用とそこから生まれたツール sre-advisor2022.05.14 SRE NEXT 2022面白法人カヤック 藤原俊一郎 @fujiwara
View Slide
@fujiwaraSREチーム 自社サービスを主に担当ISUCON 11優勝 / ISUCON 12出題github.com/kayac/ecspressoAmazon ECS デプロイツールgithub.com/fujiwara/lambrollAWS Lambda デプロイツール
Game & Community
AgendaSREチームでポストモーテムを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:DAvU99Dc4CAmazon 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 githubGitHub Actionsで実行 → gh issue createでissueにできるAdvisorが完走しました。: 0 Critical, 1 Warning, 2 Suppressed, 30 Good1箇所の推奨アクションがあります。動作ログ ```properties[Warning] ELBロードバランサー『web』のデフォルトアクションに"forward"タイプが使用されています。`` `##推奨アクション- [ ] [Warning] ELBロードバランサー『web』のデフォルトアクションには"forward"タイプを使用しないでください。
定期的に指摘潰し祭りGitHub Actions workflow ポチsre-advisor が issue 作成推奨アクションを分担して解消無視したいものは設定ファイルで人が見慣れた警告を無視する習慣を付けないように運用
社内ツールの配布方法sre-advisor は現在 internal repoprivate/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 → 事前検出 →インシデントから得られた知見をコード化して平和を目指しましょう
LICENSETwemoji by Copyright 2021 Twitter, Inc and other contributors is licensed under CC-BY 4.0
fujiwara3
nazonohito51
tkmnzm
kazukihayase
tomuro
hacomono
motsuhiro131
tammyeverts
sadonosake
nishiharatsubasa
ikezoemakoto
yanzm
claudioed
tmm1
chrislema
eileencodes
jlugia
marcduiker
sferik
keithpitt
holman
phodgson
lynnandtonic
aleyda