SaaS型ECプラットフォームにおける高負荷対策

SaaS型ECプラットフォーム
における高負荷対策
株式会社インターファクトリー CTO
水野謙

View Slide

自己紹介
 略歴
 2006年日本IBM 東京基礎研究所入社
 マルチコア環境におけるJavaの高速化
 設計書（Word, Excel）の品質検証ツールの作成、適用
 2013年インターファクトリー入社
 2016年 CTO就任
 興味
 パフォーマンスチューニング

View Slide

今日話すこと
 下記のような特徴をもつサービスでの
高負荷時の課題と解決策
EC：瞬間的な高負荷がある（セール、SNS拡散）
共用環境：同一サーバーで複数の店舗が稼働
拡張性：店舗により負荷傾向が異なる
Java, Tomcat, Linux, PostgreSQL

View Slide

先に結論
 各サーバーの、各リソースについて、
店舗ごとの閾値を設ける
 閾値を超えたときに、より「マシな」
エラーの出し方をする

View Slide

サービスの特徴：拡張性と最新性の両立
ASP ebisumart パッケージ
拡張性 △ 〇
・標準のJavaクラスを拡張して
カスタマイズを記述
・API経由でカスタマイズ
〇
最新性〇〇
カスタマイズしていても
標準機能は自動でアップデート
×

View Slide

共用環境最大の課題：他店舗影響
 ある店舗でアクセスが集中したことにより
他の店舗も遅くなってしまう
 ある店舗のカスタマイズロジックの
パフォーマンスバグにより、
他の店舗も遅くなってしまう
パフォーマンスバグがあるのは悪いこと
それにより他店舗影響が出るのは最悪なこと

View Slide

アプリケーションサーバーの
リソース制御

View Slide

解決策1：スレッド数制限
 ある店舗のリクエストを処理している
スレッド数が閾値を超えたら、
それ以上は受け付けない
処理が滞留したら確実に
制御が発動する
SLA（秒間PV）未満でも
発動する可能性がある

View Slide

解決策2：秒間PV制限
 ある店舗にSLA以上のアクセスが発生したら
それ以上は受け付けない
店舗管理者への説明が
しやすい
SLA（秒間PV）未満でも
サーバーが高負荷になる
ことはある
⇒「最悪なこと」を防げない

View Slide

ここまでの対策で十分？
以下のようなサービスならたぶん十分
⚫ SNS
⚫ Web検索
以下のようなサービスでは不十分
⚫ EC
⚫ 東京オリンピックの
ボランティア申し込み

View Slide

View Slide

以下のようなサービスならたぶん十分
⚫ SNS
⚫ Web検索
以下のようなサービスでは不十分
⚫ EC
⚫ 東京オリンピックの
ボランティア申し込み
リクエスト単位で
ほぼ目的達成
複数のリクエスト
を経て目的達成

View Slide

ECシステムの難しさ
 セッションレスなプロトコル
ユーザーの離脱を正確に判定できない
SLAは秒間PVで定義
 セッションフルなアプリケーション
複数の通信を経て目的達成
完了直前のエラーはユーザー体験として最悪

View Slide

ユーザー体験として「マシな」
アクセス制御
 新規ユーザーは混雑時に一定の確率でエラー
 回遊中ユーザーはエラーにはなりにくい
 「回遊中ユーザー」の定義は？
 一回でもアクセスしたら
 カートに商品を投入したら
 注文情報入力画面を表示したら
 離脱の判定方法は？
 一定期間アクセスがなかったら
 ブラウザのタブを閉じたら

View Slide

具体的な制御の方法
 新規ユーザーだった場合
 回遊中ユーザー数が閾値以上ならエラー
 そうでなければ、回遊中ユーザー一覧として登録
 回遊中ユーザーだった場合
 最終アクセス日時から一定時間以上たっていたら新規ユーザーとして処理
 そうでなければ、最終アクセス日時を更新
制限発動時のユーザー体験が
比較的良い
PVやサーバー負荷が低くても
制限が発動する場合がある
適切な閾値の設定が難しい

View Slide

代替案：二段階の秒間PV制限（未採用）
 1秒間に一定のリクエスト数までは無条件に
受け付ける
 それを超えた場合、回遊中ユーザーからの
アクセスのみ受け付ける
閾値を決めやすい高負荷時も一定の新規ユーザー
を受け付ける
⇒回遊中ユーザーにエラーを
表示する可能性が増える

View Slide

まとめ：
アプリケーションサーバーのリソース制御
 スレッド数制限
⇒サーバーを守るため
 秒間PV制限
⇒SLAに関する説明のしやすさのため
 回遊ユーザー数制限
⇒ユーザー体験をよくするため

View Slide

DBサーバーのリソース制御

View Slide

解決策1：接続数制限
 店舗ごとにコネクションプールを用意し、
接続数上限を設定
技術的に簡単負荷が低くても制限が発動
する

View Slide

ケースA：他店舗の負荷状況の違い
 1店舗のみの負荷の場合
店舗A： 1/10コネクション利用
店舗B：10/10コネクション利用
 複数店舗同時の負荷の場合
店舗A：10/10コネクション利用
店舗B：10/10コネクション利用
低負荷なのに
制限発動
高負荷で
制限発動

View Slide

解決策2：二段階の接続数制限
 一定数までは無条件に確保
 それを超えた場合、全店舗の接続数合計が
閾値以下ならコネクション追加
 プール上限に達したら拒絶
 参考：店舗共通のプールにしない理由
 他店舗影響防止
 DBサーバーのメモリ使用量削減

View Slide

ケースB：コネクションを保持して
も使っていない
 クエリを投げた後、アプリサーバーで処理
商品一覧画面：商品ごとの金額計算
購入処理：トランザクション保持中に多数の処理
 単にコネクションを解放していない
フレームワークにてメソッド末尾で解放
複数処理で単一コネクションを使いまわし
こまめに開放すると、今度はコネクション取得の
オーバーヘッドがかかる

View Slide

解決策3：アクティブ接続数制御
 「クエリを投げて結果待ち」の状態の接続数
をカウント
 一定数を超えたらそれ以上クエリを投げない
他のクエリが終わるまで待つ
待っている数が処理が多ければエラー

View Slide

例：受注処理
1. 入力値のチェック
2. 決済連携
3. 在庫更新＆受注登録
4. メール送信

View Slide

⇒障害を防ぐための制限で障害発生
例：受注処理
1. 入力値のチェック
2. 決済連携
3. 在庫更新＆受注登録
4. メール送信
制限発動でエラー
決済連携済みなので
手動リカバリーが必要

View Slide

解決策4：リクエスト開始時のチェック
 接続数・アクティブ接続数を、リクエスト処
理開始時にもチェック
 その時点で閾値を超えていたら、処理を開始
せずにエラー画面を表示

View Slide

まとめ：
DBサーバーのリソース制御
 2段階の接続数制限
⇒複数店舗間の負荷制御
 アクティブ接続数制限
⇒「実際にDB負荷となる接続」の数の制御
 リクエスト開始時のチェック
⇒致命的なタイミングでのエラーを防ぐ

View Slide

今日話したこと
 下記のような特徴をもつサービスでの
高負荷時の課題と解決策
EC：瞬間的な高負荷がある（セール、SNS拡散）
共用環境：同一サーバーで複数の店舗が稼働
拡張性：店舗により負荷傾向が異なる
Java, Tomcat, Linux, PostgreSQL

View Slide

結論
 各サーバーの、各リソースについて、
店舗ごとの閾値を設ける
 アプリケーションサーバー、 DBサーバー
 PV数、スレッド数、ユーザー数、etc.
 閾値を超えたときに、より「マシな」
エラーの出し方をする
 回遊中ユーザーは優先
 エラーはなるべく処理の最初に

View Slide

SaaS型ECプラットフォームにおける高負荷対策

SaaS型ECプラットフォームにおける高負荷対策

株式会社インターファクトリー

More Decks by 株式会社インターファクトリー

Other Decks in Technology

Featured

Transcript