こんにちは、 estie SRE の sugitak です。デプロイが好きで、最近は SLO と向き合っています。気になる不動産ニュースはアンドパッドさんの三田移転です。
先日アンドパッドさんの会場をお借りし、ゆるSRE勉強会#9 にて発表をさせて頂いたので、その内容を紹介します。
こちらは概ね二部制の内容となりました。
第一部 SLO は「ベストプラクティス」
Service Level Agreement (SLA) や Service Level Objective (SLO) という言葉は、私たち SRE にとって親しみの深いものです。しかし、実際に運用をしようとすると決して簡単なものではありません。変わり続ける顧客要望・プロダクト・事業に向き合う必要があります。
SRE における SLO はベストプラクティスです（※）。「信頼性」に対して Google が向き合った結果、その中心に SLO を据えて社内外の関係者との合意に使うとしたものです。 SLO があると、信頼性に関する複雑な問題を一度に解決できます。
言い方を変えると、 SLO は多くの問題を一度に解決する責任を負わされています。
そんな SLO はいきなり登り切れるものではありません。 SRE として、 SLO は目指すべきゴールの一つですが、そのものは目的ではなく、本来の問題を一つひとつ順番に解決していくことこそが重要でしょう。
※ SLA や SLO それ自体は Google SRE 本以前からあるので、 SRE における SLO という書き方をしています
第二部 ブラウザテストで SLI を作っている話
第一部で SLO の位置づけを確認したところで、サービスの品質指標としての Service Level Indicator (SLI) を改善している話を紹介します。
私たちのプロダクトは、多くの不動産情報が一定の正確性のもと閲覧できるものです。お客様からのご期待にお応えするためには、データの量・質が常に重要となっています。
これまで私たちの健康指標は「サービスが正常に応答できるか」でした。しかし改めて Critical User Journey を考えてみると、私たちのプロダクトでは「お客様に適切にデータ検索体験を提供できているか」こそが重要ということに気づきました。
「検索体験」については API でもある程度確認はできるのですが、やはりブラウザテストを利用できるとさらに高い正確性でもってテストを実施できます。
QA チームによるブラウザテスト
折しも、 QA チームでは E2E テストを Playwright で構築していました。QA engineer at a Startup vol.3 macho編｜IT勉強会・イベントならTECH PLAY［テックプレイ］
QA チームでは、サービスが維持するべき特徴をレベル分けし、重要であるとチームで合意されたものについて、 E2E のリグレッションテストとして実装していました。
このテストは、以下の特徴を備えていました：
- 実際に動いており、テストが継続的に成功してきている
- そのテストが重要であることがすでにチームと合意済み
これはまさに Critical User Journey (CUJ) です。これまでの QA 活動に敬意を示しつつ、このテストの中でももっともコアなものを CUJ として利用させて頂くこととしました。
実行環境として ECS on EC2
実行環境としては、最初は Lambda を使おうとしました。ですが、主に Write-only の仕様を超えるのが難しく、またすでにある Playwright test を載せ替えるのも結構な複雑性があるため、相当難航していました。そんななか、 SRE 同僚のスタッフエンジニア氏が ECS on EC2 で動かせば良いのでは、と提案してくれました。その提案に乗って実装したところ、サクッと！従来の Playwright の環境を、定期実行可能なテストへと構築し直せたのでした。
ECS の中でも Fargate を採用しなかった理由としては、起動までの時間が2分かかってしまうことがありました。監視タスクは頻繁に起動するものなので、起動までの2分は許容できません。 ECS on EC2 ではホストにディスクイメージがキャッシュされることで起動が早まり、だいたい1分以内程度で起動できるようになっており、この点もとても都合が良いものでした。
ブラウザテストのマネージドサービスも検討しましたが、こちらは回数ベースの課金だったため、小さいテストを大量に行う監視向けではありませんでした。リグレッションテストのような大きいテストを数時間〜数日おきに実行するのであれば非常に有用そうです。これに限らずですが、マネージドサービスはサービス側が期待している利用方法をすることが重要ですね。
現在、半数程度のプロダクトにこの SLI テストが入りつつあり、より高いレベルで社内システムの品質・信頼性を保証していこうとしています。
最後に
QAもSREも品質・信頼性を高めていく立場。肩書きこそ違えど目指すものは同じです。この SLI に限らず、これからも協力してやっていきます。
estie では信頼性や品質を高めることに対して魂を燃やせる SRE を大大大募集しています。ぜひカジュアル面談へのご応募、お待ちしております！
