Slackは、パフォーマンスに焦点を当てているエンジニアだけでなく、すべてのエンジニアにとって負荷テストが注力すべき関心事になるよう取り組んできた。そして、パフォーマンスに対するリアクティブなアプローチから、より統合された取り組みに移行していると、SlackのエンジニアShreya Ramesh氏とMelissa Khuat氏は述べている。
負荷テストは、パフォーマンスの低下がリリースに入り込んでいないかを確認するための重要なプラクティスである。残念ながら、負荷テストは、特に複雑なテスト環境をセットアップする必要があるため、非常に時間がかかる。そのため、エンジニアのやる気がそがれる可能性があるとRamesh氏とKhuat氏は述べている。
この問題に取り組むために、Slackは非常に抜本的なスタンスを取った。アドホックな負荷テストに依存せずに、そのテストを開発プロセスの標準機能にした。これにより、負荷テストを継続的に実行することで、パフォーマンスの問題を早期に段階的に特定することができるようになった。
クライアントを常に起動して実行することで、エンジニアがクライアントを起動してカスタム環境をセットアップするために必要な労力を除くことができます。ビルドを本番環境にデプロイすると、アクティブユーザー数が多い大規模な[テスト]組織に対してすぐにテストを実行して、パフォーマンスの低下が発生していないことを確認できます。
負荷テストを継続的に実行することは、技術的な課題があるだけでない。テストにより適切なプラットフォームの動作が損なわれることを避け、効率的な運用を保証し、組織全体がそれを理解するように注意する必要がある。したがって、このアプローチが効果的に機能するためには、Slackチームは、安全性、回復力、コミュニケーションという3つの重要な側面に取り組む必要があった。
安全性を向上させるために、Slackのエンジニアは2つのメカニズムを提供した。APIの成功率が5分間95％を下回ったときにトリガーされる自動シャットダウンサービスと、エンジニアが手動でトリガーできる緊急停止サービスである。
回復力は、テストサービスがその状態をデータベースに保存することで実現される。これにより、たとえば、新しいリリースが展開された場合や、サービス自体がセキュリティパッチを受信する必要がある場合に、自動再起動ができるようになった。回復力のもう1つの重要な側面は、テストに必要なすべてのステップ（例えば、トークンの生成）の自動化である。これは、エンジニアリングの介入を減らすためのものである。
最後に、コミュニケーションは、組織がテストツールへの信頼を維持するためのキーポイントであった。これには、関係者へのサプライズを最小限に抑えるための段階的な立ち上げプロセスが含まれている。同じように、発生する可能性のあるインシデントに対応し、チームが高可用性を維持できるように、慎重なローテーション戦略が必要であった。
Ramesh氏とKhuat氏によると、継続的な負荷テストにより多くのメリットが得られた。例えば、大口顧客が期待するパフォーマンスをよりよく理解すること、問題の再現を試みるために、本番環境のインシデントに迅速に対応できること、本番環境に移行する前にパフォーマンスの低下を検出することである。
継続的な負荷テストをパイプラインに統合するために実行されるSlack戦略には、ここで説明できるものよりもはるかに多くのものがある。そのため、全ての詳細を見たい場合には、元の記事を見逃さないようにしてください。