Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

@fujiwara 面白法人カヤック SREチーム github.com/kayac/ecspresso Amazon ECS デプロイツール github.com/fujiwara/lambroll AWS Lambda デプロイツール

Slide 3

Slide 3 text

(専任)SRE不在のチームとサービス - SMOUT 2018年リリース

Slide 4

Slide 4 text

SREとしてチームに加わった背景 きっかけはEoL ElastiCache Redis 3 - 2023年7月31日 RDS for PostgreSQL 10 - 2023年7月18日 強制アップデートを伴うEoLがあるが手が回らない…他にも サーバーコストを削減したい CIに強すぎる権限がついているので絞りたい サービスの安定性を高めたい、監視を整備したい 1億行のテーブルから9000万行消してALTERしたい (とりあえず期間限定で) SREの手助けが欲しい

Slide 5

Slide 5 text

(専任)SRE不在だが、よくメンテされている Rails 5.1 → 6.1 Dependabotによる定期的なアップデート ElasticBeanstalk → ECS 手作業でのインフラ管理 → Terraform デプロイ → CircleCI やる気も能力もある。DevOpsできている (自分は期間限定なので) 今後も使える考え方や手法を導入するのがよさそう 単に「作業を代わりにやりました」で終わらないように

Slide 6

Slide 6 text

最初にやったこと - 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) }

Slide 7

Slide 7 text

なぜ負荷試験ツールを最初に用意したか PRコメント引用 ElastiCacheのバージョンアップ時のRailsアプリケーション挙動チェックのため、継続 的にアクセスがある状態でFailoverを発生させたい。ついでなので、簡単な負荷テスト に使える仕組みを整備しました。 以下のような用途にも使えるので便利です。 ミドルウェアのバージョンアップ(Failover)時の挙動を確認する アプリケーションのパフォーマンス改善時の性能向上を確認する モニタリング整備時に必要な値が取れているかを確認する いろいろ使えて便利だが、知見がないと取っつきづらい 簡単なサンプルを最初に書いて、誰でもいじれるようにしておく

Slide 8

Slide 8 text

用意したシナリオ 1. トップページにアクセス 2. トップページから呼ばれるAPI(認証なし)を複数並列で叩く 3. ログインフォームにアクセス 4. ユーザー名とパスワードをPOSTしてログインする 5. ログインセッションが必要なAPI(要認証)を叩く コンポーネント(CDN, LB, WebApp, MySQL, Redis)を一通り通過する ストレージからの読み込み、書き込み処理が両方ある これを回しながら作業すると、各コンポーネントのエラーの発生と回復が検知できる

Slide 9

Slide 9 text

「不安だからメンテ入れましょう」からの脱却 どれぐらいエラーが起きるか分からない どれぐらい復旧に時間が掛かるか分からない 「怖いので」サービス停止メンテナンスを入れてやりたい 知らない = 怖い だけなので、試せばよい (検証環境で)負荷を掛けた状態でバージョンアップ(Failover)する 実際にどれぐらいのエラーが発生して、回復するか観察する 普段発生しているエラー数、頻度と比較してメンテナンスの必要性を考える → 「エラーバジェット」「SLO」の考え方に繋がる

Slide 10

Slide 10 text

結果的には k6で負荷を掛けながらノーメンテでいろいろできた ElastiCache Redis のバージョンアップ RDS Blue/Green Deployments の昇格 切り替え時の接続エラーを踏む役目をk6が肩代わりしてくれる(再接続される) ため、実際の利用者が目にしたエラーは数件程度 今後も使える手法を導入できた

Slide 11

Slide 11 text

他にもやったことはいろいろ(略) 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導入

Slide 12

Slide 12 text

まとめ チームに「エラーバジェット」「SLO」の考え方を導入するため 負荷試験ツールをまず入れてみた SREは「エンジニアリング」の手法 専任のSREエンジニアだけがやるものではない ソフトウェアで扱える手法から導入していくとよいのでは