SRE不在のチームに入って2ヶ月でやったこと - 負荷試験ツールからはじめるSREプラクティスの導入

TechFeed Experts Night#17 〜 事例で学ぶSRE 〜 ツール、プラクティスから組織づくりまで
https://techfeed.io/events/techfeed-experts-night-17

Transcript

1. SRE不在のチームに入って2ヶ月でやったこと 負荷試験ツールからはじめるSREプラクティスの導入 2023.04.26 TechFeed Experts Night#17 @fujiwara
2. @fujiwara 面白法人カヤック SREチーム github.com/kayac/ecspresso Amazon ECS デプロイツール github.com/fujiwara/lambroll AWS Lambda デプロイツール
3. (専任)SRE不在のチームとサービス - SMOUT 2018年リリース
4. SREとしてチームに加わった背景 きっかけはEoL ElastiCache Redis 3 - 2023年7月31日 RDS for PostgreSQL 10 - 2023年7月18日 強制アップデートを伴うEoLがあるが手が回らない…他にも サーバーコストを削減したい CIに強すぎる権限がついているので絞りたい サービスの安定性を高めたい、監視を整備したい 1億行のテーブルから9000万行消してALTERしたい (とりあえず期間限定で) SREの手助けが欲しい
5. (専任)SRE不在だが、よくメンテされている Rails 5.1 → 6.1 Dependabotによる定期的なアップデート ElasticBeanstalk → ECS 手作業でのインフラ管理 → Terraform デプロイ → CircleCI やる気も能力もある。DevOpsできている (自分は期間限定なので) 今後も使える考え方や手法を導入するのがよさそう 単に「作業を代わりにやりました」で終わらないように
6. 最初にやったこと - Grafana k6 による負荷テストシナリオ Grafana k6 is an open-source load testing tool that makes performance testing easy and productive for engineering teams. k6 is free, developer-centric, and extensible. OSSの負荷試験ツール JavaScriptでシナリオを記述できる import http from 'k6/http' import { check, sleep } from 'k6' export default function () { const data = { username: 'username', password: 'password' } let res = http.post('https://myapi.com/login/', data) check(res, { 'success login': (r) => r.status === 200 }) sleep(0.3) }
7. なぜ負荷試験ツールを最初に用意したか PRコメント引用 ElastiCacheのバージョンアップ時のRailsアプリケーション挙動チェックのため、継続 的にアクセスがある状態でFailoverを発生させたい。ついでなので、簡単な負荷テスト に使える仕組みを整備しました。 以下のような用途にも使えるので便利です。 ミドルウェアのバージョンアップ(Failover)時の挙動を確認する アプリケーションのパフォーマンス改善時の性能向上を確認する モニタリング整備時に必要な値が取れているかを確認する いろいろ使えて便利だが、知見がないと取っつきづらい 簡単なサンプルを最初に書いて、誰でもいじれるようにしておく
8. 用意したシナリオ 1. トップページにアクセス 2. トップページから呼ばれるAPI(認証なし)を複数並列で叩く 3. ログインフォームにアクセス 4. ユーザー名とパスワードをPOSTしてログインする 5. ログインセッションが必要なAPI(要認証)を叩く コンポーネント(CDN, LB, WebApp, MySQL, Redis)を一通り通過する ストレージからの読み込み、書き込み処理が両方ある これを回しながら作業すると、各コンポーネントのエラーの発生と回復が検知できる
9. 「不安だからメンテ入れましょう」からの脱却 どれぐらいエラーが起きるか分からない どれぐらい復旧に時間が掛かるか分からない 「怖いので」サービス停止メンテナンスを入れてやりたい 知らない ＝ 怖い だけなので、試せばよい (検証環境で)負荷を掛けた状態でバージョンアップ(Failover)する 実際にどれぐらいのエラーが発生して、回復するか観察する 普段発生しているエラー数、頻度と比較してメンテナンスの必要性を考える → 「エラーバジェット」「SLO」の考え方に繋がる
10. 結果的には k6で負荷を掛けながらノーメンテでいろいろできた ElastiCache Redis のバージョンアップ RDS Blue/Green Deployments の昇格 切り替え時の接続エラーを踏む役目をk6が肩代わりしてくれる(再接続される) ため、実際の利用者が目にしたエラーは数件程度 今後も使える手法を導入できた
11. 他にもやったことはいろいろ(略) Cache専用Memcached廃止 → Redisに統合 1億行のテーブルから9000万行削除してALTER 出たばかりの RDS Blue/Gren Deployments を使ってノーメンテで MySQL DBのインデックス最適化 インデックスショットガン状態で書き込み負荷が高かった sys.schema_unused_indexes を見て不要なインデックス削除 最適な複合インデックス作成 インスタンスサイズ半分のRI購入でコスト大幅削減 Redash 5(EC2) → 10(ECS) CircleCI OIDC化 Mackerel導入
12. まとめ チームに「エラーバジェット」「SLO」の考え方を導入するため 負荷試験ツールをまず入れてみた SREは「エンジニアリング」の手法 専任のSREエンジニアだけがやるものではない ソフトウェアで扱える手法から導入していくとよいのでは