インバスケットとは
インバスケットとは短時間で多くの実践的な問題を解くことで、判断力向上の訓練や昇進の際の評価試験で使われている。
今回はパフォーマンス・チューニングの問題を2問出すので2分以内に自分なりの論理的な答えを出していただきたい。
事例１
旅行ツアーを予約できるWebサイトである一定以上のユーザが閲覧しているとサイトの表示が非常に重くなるという報告があった。
社内で確認したところ、10人程度が同時にサイトを使用すると、トップページを除く、商品の一覧画面・詳細画面・以降の予約の処理全般が遅い。ただし、時々表示が早くなることがあったが、そのあとすぐ遅くなってしまう。
１人だけで使うと特に問題なく、１ページ当たり５秒程度で画面が表示される。
アプリケーションサーバやデータベースの負荷はいずれも低い。
事例２
to C向けの小売り事業を行っている会社で、夜間にその日の売り上げに対する加工を行うバッチ処理を行っている。バッチ処理はマイクロサービスを提供する複数のサーバグループで行う。
各サーバのグループはロードバランサの配下に集約され、ロードバランサ経由でアクセスされる。
１週間前からバッチ処理の実行時間が30%遅くなってしまった。確認すると年齢別売り上げの集計を行うサーバグループで処理時間が増えているようである。処理するデータ量や内容自体は以前から変わっていない。バッチ処理の変更もない。
調査のため、数度ロードバランサに対してリクエストを投げたが正常な時間でレスポンスが返ってきた。
解答例は
↓
↓
↓↓
↓↓↓
↓↓↓↓
↓↓↓
↓↓
↓
↓
↓
↓↓
↓↓↓
↓↓↓↓
↓↓↓
↓↓
↓
↓
↓↓
↓↓↓
↓↓↓↓
↓↓↓
↓↓
↓
↓↓
↓↓↓
↓↓↓↓
↓↓↓
↓↓
↓
↓
↓
↓
↓
解答例１
インフラの負荷が低く、少数のアクセスなのに処理が重い場合、リソースの競合が考えられる。
例えばデッドロックしていたり、データベースでテーブル全体をロックしているなどである。
対策としては以下が考えられる。
- リード系の処理はリソースのロックを行わない
- 必要最小限の単位でロックを行う
- 各処理においてリソースの確保は決まった順番で行う
解答例２
データ量が変わってないのに急に一部の処理が遅くなったのであれば、いずれかのサーバがスタックしている可能性がある。例えばログや一時ファイルでディスクがいっぱいになったとか、部分的にハードウェア故障したとかである。
一部のサーバのみがスタックしている場合、ロードバランサから数度リクエストを送るだけでは問題のあるサーバに処理が割り振られずに検知できない可能性がある。
各サーバに直接アクセスしてステータスを確認するのが良い。
Discussion