これはなんですか
負荷試験と呼ばれるものと、継続的な改善に関するアプローチの仕方について簡単に述べたもの。
負荷とは
負荷とは２つの観点を持つ。
- アクセスに関するもの
時間あたりのアクセス数量。
俗にいうAPIアクセス(TPS)やアクティヴユーザ数、同時接続数、View数のこと。
ストアやストレージの読み取り速度がサービスの質に直結する場合はReadやWrite速度も勘案。
イメージは人通り。狭い道ではたくさんの人は通れない。 - ストアされているデータ量
契約ユーザ数○○、紐づくデータ数
ストレージであれば○○MiBやオブジェクトの数, DBでいえば各種テーブルの行数など、蓄積されていくもの。
イメージは溶けない雪、しんしんと降り積もる。でも適切に受け入れればちゃんと生活できる。
負荷試験について
サービスの成長曲線から予測するのが一番フィットした感じかなと思いますが、だいたい想定の十倍くらいを上限とするのがよいかなと思います。
上記２つの観点から想定をだします。
実施にあたって必要なのは下記
- 自動化された1.テストの作成
- ストアされるデータの構築。
ユーザ数はたとえば１０万人を見込んでいるなら１００万人で負荷試験を回す。
１００万ユーザと、それに付属するデータの整備である。
何日かAPIをループで回して作ってもいいし、DBに直接叩き込んでも良い。
その１００万人がどのようなアクセスをするのか、バックヤードの業務は回るのか。
この時、テストケースがきちんと動作するようなチューニングをアプリケーション、インフラストラクチャ、データストアに対して行う。
運用
クラウドの利点を最大限に活用すること。
最初から１００万人を想定したspecの設定はお金の浪費なのでやらない。
負荷に対するロードマップや見直しポイントをたてて負荷にあわせ適切な施策や、ボリュームを確保する。
継続的な改善
最初から徹底的にやろうとしない。
ローンチするときに負荷試験をやったあとは、その後やらないことがほとんどなので漏れ出る改善点は出てくる。
たとえば追加されたfeatureに対する徹底した負荷試験はあまりやっているところを見ないので、どこかで人間やシステムが我慢できなくなるポイントに行き当たる。
そういうところは最初にやった負荷試験の知見をもとに、少しの全体最適と全力の部分最適化の探究で乗り切るといいんじゃないでしょうか。
たまに負荷試験用の環境やデータを維持するリッチな開発現場もあるけれど、負荷試験環境の構築を自動化できてるほうが望ましいと思う。