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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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)
   }
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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導入
    

    View Slide

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

    View Slide