狠狠撸

ELBとALBと数万スパイク負荷
テスト/インフラチューニング

もてきたかひろ
? 株式会社CyberZ
? ビッグデータエンジニア
? 以前はオープンソースのリアルタイムkernelと
か開発
リアルタイムkernelコンテキストスイッチングの実装
モノリシック/マイクロ/ハイブリッドkernelアーキの設計/実装
? 得意な技術:エンジニアのための超自炊
https://www.facebook.com/takahiro.moteki.31

ビッグデータエンジニアですが、ビッ
グデータの話はしません

話すこと
? ELBと数万RPSスパイク負荷テスト
– ~経緯~
– ~アーキテクチャ(負荷かけられる側)について~
– ~負荷ツールについて~
– ~負荷環境(負荷かける側)について~
– ~スパイク負荷テスト実施~
? インフラチューニング
? ALB少し

経緯:オンプレアーキテクチャ(ざっくり)
……….
スイッチ
スイッチ
Web/AP
apache/tomat
LB
DB/KVS/Big-data
mysql,aerospike,
hadoop

経緯:ある時…
? 過去数万RPSクラスのスパイクアクセス発
生(オンプレ)
? スパイクアクセスは不正アクセスと正常
アクセスを含んだもの

経緯:ミッション
? オンプレからAWSに移行させる
? 数万RPSクラスのスパイク発生してもHTTPエラー
発生させないようなアーキテクチャ/構成にし、試
験を行う
? バックエンド(顿叠/碍痴厂/叠颈驳顿补迟补)は今回対象外

础奥厂の场合どうなるのか?

础奥厂の场合どうなるのか?
防御する
受けきる
プロテクトのシグネチャ
どうしよう、、、
システム運用が事業会社
なので現実的選択かもし
れない
VPC / ELB側でudp flood,syn flood等は防御してる、
他にもWAFとかもあるが、、、

アーキテクチャパターン

案1:贰尝叠/贰颁2静的台数确保

案2:辫谤别-飞补谤尘颈苍驳

案3:谤辞耻迟别53-贰颁2(直刺し)

案4:谤辞耻迟别53のトレンドを使う

案5:ELB使わない。
HAproxy,nginx,Big-ip on EC2

案7:ストリームストレージkinesisフロン
ト(もしくはapache kafkaとか)

補足
? 負荷試験対象アプリ特徴
– Cloudfrontのようなものは使えない(もちろんELBのoriginにも
刺せない)
– セッションが短く、keep alivedのような維持はできない
– HTTPのエラーは可能な限りなくす
– レイテンシもある程度担保(数十msec以内)

案1 +pre-warming
他プロジェクト等で本番稼動実績ある
アーキテクチャを検証対象へ
一旦試験対象
静的確保だと素の
オンプレと同じ、、、

ELBについて
? AWS上のロードバランシングサービス(マネージドサービス)
? EC2等を負荷分散
? L4のLB
? 特徴
– スケーラブル(AutoScaling型のLB)
– 高可用性(複数AZ対応/EC2の正常性判断によるリクエスト
振り分け)
– 運用管理が楽(マネージドサービスなので)
– 通常のLBと比べると機能性は少ない

ELBのAutoScalingの動き(通常)
? cross-zone-balancing有効化で2台の内部nodeをもつ
? 2拠点からhealth checkリクエスト
? 内部nodeはpublic-IP/private-IPが付与、ENIを保持(ENIは
ユーザ側に見え、実際IPはENI上に保持)
? Per-LB/Per-AZレベルでCloudWatchメトリクス観覧可能
Availability Zone 1a
Cross zone
balancing有効化
ENI(Public IP)
ENI(Private IP)
ENI(Public IP)
ENI(Private IP)
内部
Availability Zone 1a Availability Zone 1a
web01 web02
web01 web02
Per-AZ Per-AZ
Per-LB

ELBのAutoScalingの動き(scale時)~1
Cross zone
balancing有効化
ENI(Public IP)
ENI(Private IP)
ENI(Public IP)
ENI(Private IP)
内部
web01 web02
web01 web02
Per-AZ Per-AZ
Per-LB
ENI(Public IP)
ENI(Private IP)
….
auto
….
auto
ENI(Public IP)
ENI(Private IP)
? 内部Node1台 = 1ENI = 1publicIP = 1privateIP(dual ENIはない…とのこと)
? Healthcheckリクエスト増えるぞ, 確保してるsubnet内のprivate IPが消費
? CloudWatchメトリクスのPer-AZは値は丸められる

ELBのAutoScalingの動き(scale時)~2
? 内部nodeでの追加課金はなし
? ELBの内部nodeが増減する
– いつnode増えるか? -> 一例)リクエスト増(surge queue length)
– いつnode減るか? -> 一例)リクエスト減(surge queue length)
– 増減時にコネクションの断はない(EC2から見た場合)
– (何個)増減したかの確認方法
? digコマンド等で名前を引いてIPを数える
? ENIが増えてることを確認する
? アクセスログ
? VPC flow logs
– いつ増減したか
? CloudtraiでENIの生成/破棄の日付を確認する
? アクセスログでの拠点増加を確認する
? VPC flow logs
? 2拠点ELBの内部nodeの入れ替え
– いつ入れ替わるか? -> 一例)リクエスト増(surge queue length)
– 入れ替わり時のコネクション断はないが、TTLキャッシュ消失
– 入れ替わったかの確認方法
? digコマンドで名前を引いてIPの変化を見る
? ENIからのpublicIP/privateIPを確認する
? アクセスログ
? VPC flow logs
いろいろなところで
”だいたい”わかります

ELBのまとめ(キャパシティ面)
? スパイクに弱い
– 内部NodeでAutoScaleするが、数+秒~数分くらいかかる
? 内部NodeのAutoScaleした動きがわかりにくい(モニタしに
くい)
? 内部NodeのAutoScaleに追加課金なし
? 内部NodeのAutoScaleはあるが、AutoHealingは微妙
– Cross zone balancing有効化ならば、最小node数を2台へ保つ
– ただし、ELB内部ノードに障害発生しAWSサポートへ入れ替え
をしてもらった事あり
内部Nodeの動きは本来は意識しなくて良いもの。ただし、
ELBでスパイクと戦う時はそうもいかない

pre-warmingについて
? 自前pre-warming
– 自前で段階的に負荷かかてscaleさせておき、タ
イミングで切り替える
? 申請pre-warming
– 静的にELBの内部Nodeのキャパシティを担保し
ておく(増やしておく)機能
– Business以上のサポート加入&AWSサポートへ
申請することで可能
– 追加課金なし

申請pre-warmingの仕様
? フロー
– 申請フォーマット入力してAWSサポート ->
AWS側作業(約1~数時間) -> 確認
? 1度申請での上限期間は3ヶ月
? pre-warming最大キャパシティ
– コネクション数
– インスタンスタイプ/台数でpre-warming
キャパシティ上限がある

負荷ツール選定…
の前にちょっと負荷ツールについて説明

負荷環境/ツールについて(カテゴライズ)
? マネージドサービス/ソリューションサービスを使う
? アプライアンスを使う
? ハコは自前で静的に用意して負荷ツールを構築して使う
オンプレ時代
まず、ハコがないんじゃ、
基盤が同じなんじゃ(NW影響受ける)

? マネージドサービス/ソリューションサービスを使う
? アプライアンスを使う
? ハコは自前で静的に用意して負荷ツールを構築して使う
? ハコはクラウドベンダ上で動的生成を行い負荷ツールを構築して使う
? クラウドベンダ上のマネージドサービスを使う
クラウドになった時代
選択が増えた
負荷環境/ツールについて(カテゴライズ)

負荷ツールについて(特徴)
? 金額/ライセンス
? プロビジョニング
? 機能/シナリオワーク
と(クライアント数)
手動系:
Jmeter,tsung,Locust,vegeta,
ab,wrk,httperf…
自動系:
Beeswithmachineguns, ec2-fleet
Lambda,Goad,dino,clojider
GKE(loading service)…
可能:
Jmeter,tsung,Locust,vegeta…
不可能:
ab,wrk,httperf…
マネージド?サービス:
Load Impact, LoadRunner, loader.io…
星の数ほどある負荷かけれるツール…

プロビジョニング自動系について
(他は説明不要、省略)

プロビジョニング自動系~1
? Beeswithmachineguns
– EC2をプロビジョニングして分散テスト
– https://github.com/newsapps/beeswithmachinegu
ns
– Github fork 365,star 3318
? ec2-fleet
– EC2をプロビジョニングして分散テスト
– https://github.com/ashtuchkin/ec2-fleet

Lambda登場
Lambdaを使用して分散負荷テス
トするOSSツールが出てきた

プロビジョニング自動系~2
? Goad
– Go製ツール。Lambda + SQSでの分散テスト
– 複数リージョン同時実行対応、Lambdaを分散して実行し、SQSに結果を詰める
– https://github.com/goadapp/goad
– https://goad.io/
– Github fork 52, star 829
? Dino
– Nodejsを使ったツール。Lambda + SNS + SQSで分散テスト
– 基本複数リージョンは同時実行不可、Lambdaを分散して実行し、SQSに結果を詰める。
SNSを挟んでいるのでさらにLambda等をフック可能。
– https://github.com/hassy/artillery-dino
– http://veldstra.org/2016/02/18/project-dino-load-testing-on-lambda-with-
artillery.html
? Clojider
– Cloujure製ツール。Lambda + S3で分散テスト
– https://github.com/mhjort/clojider
– Github fork 1,start 32
? 自前Lambda
– 自前でfunction定義してやるパターン

他こうゆうのも(試してない)
? Distributed Load Testing Using Kubernetes
– https://cloud.google.com/solutions/distributed
-load-testing-using-kubernetes

負荷ツールについて(選択細いやつ)
? 実行エンジン/プロビジョニング
? スパイクアクセス
? 分散モード
? long running
? RPSスケジューリング
? シナリオワーク
? サマリレポート(分散モード)
? クライアントの選択
? GUI
? モバイルモード
? webの情報量
? 実績
? 近くに詳しい人がいるか?
? その他(認証やcookieテスト)
? 金額/ライセンス

今回のスパイク負荷テストのため
負荷ツールの選定

要件確認
スパイク負荷テスト(トラフィック許容テスト)
baseのトラフィック約1500RPS
スパイクのトラフィック約5万RPS ~ 6万RPS
? 見たいところ
– ELBのキャパシティ -> 1シナリオ
– EC2側(OS+ミドル)とネットワークのキャパシティ ->
1シナリオ
– HTTPの性能
– アプリケーションレイヤ
? ただしアプリケーションはデプロイ

どうやってトラフィックを生成さ
せるのか?

baseで1500RPSは問題ないが、数秒で一気に5万RPSかけ
る、負荷かける側どうやるんだこれ？
クラウドだし、数秒で台数確保すれば負荷かけられ
るか？
懸念ポイント
数秒 -> ここで数十秒かかって負荷かけると、ELBが勝手
にスケールし始める。可能ならばリクエスト変動期間なし。
-> 本来のトラフィック再现テストになっていない

負荷ツール選定
baseトラフィック約1500RPS
スパイクトラフィック約5万RPS ~ 6万RPS
baseトラフィック ->機能(RPSスケジューリング/long
running/シナリオワーク)
スパイクトラフィック -> 自動プロビジョニング

負荷ツール選定
baseトラフィック約1500RPS
スパイクトラフィック 5万RPS ~ 6万RPS
baseトラフィック -> jmeterクラスタ + シェーピングスループッ
トタイマ
スパイクトラフィック -> lambdaで定期的に発生(goad/dino)
2層でかける

Jmeterクラスタ(baseトラフィック生成、RPSスケジューリング)
複数リージョンからlambda
分散実行,結果はSQSへ

やっとくとおすすめな事(足回り)
? 一通りcactiとかモニタリングツールにメト
リクスを記録させよう
– 後で、あ、あのリソース状況見忘れた。他の人が
確認したいとかとか。
– CloudWatchだと通常2週間で消えます。
? ログをうまく漁れるようにしておこう
– 1台1台web/ap入ってログ収集だとけっこう面倒
? 開始と終了時刻を記録しておこう
– 細かくやっていて、リソースメトリクスがわから
なくなったとか。

話すこと
? ELBと数万RPSスパイク負荷テスト
– ~背景~
– ~アーキテクチャ(負荷かけられる側)について~
– ~負荷ツールについて~
– ~負荷環境(負荷かける側)について~
– ~スパイク負荷テスト実施~
? インフラチューニング
? ALB少し

試験シナリオ
? 見たいところ
– ELBのキャパシティ -> 1シナリオ
– EC2側(OS+ミドル)とネットワークのキャパシティ -> 1
シナリオ
– HTTP性能
– アプリケーションレイヤ
? ただしアプリケーションはデプロイ
? 静的コンテンツ/動的コンテンツ
? リソース的なクリティカルパス
? 時間的なクリティカルパス

摆社内勉强会闭贰尝叠と础尝叠と数万スハ?イク负荷テスト

結果 EC2 38台
? 贬罢罢笔のエラーなし

その1:分散してぬ、、少しラグがある
? lambdaが分散しない(goad)
– 5000RPSと5万RPSで、アクセス元(webサーバ側からみた)の
数は同じ
– Lambdaバックエンドのライフサイクルコンテナ内で順繰りに
実行されてる
– goadで多重度を増やしてもバックエンドのコンテナは増えない
– バックエンドコンテナで異なるIPを持つわけではない(ホスト上
でもつ)
Goadの実装依存。Dinoを使用する
もしくは自前実装で処理を変える
? 5万RPSを発生させるまでにラグがある
– ラグ5秒~10秒かかる -> ELBのスケールが怪しくなってきそ
う。。

その2:負荷試験ツールの結果に騙される
(ごくまれに)
負荷かけれる側を解析する。EMRに頼った(ESとかでも良
いと思う)

その3:秒間モニタリングの苦労
? スパイクのテストをやってるので基本秒間モ
ニタ
– Zabbix(2.4)側が対応していない(データ取れて
もグラフ側が見えん)
? 結局linux上でscript組んでやった
– 統計とるlinux標準コマンドは、ほぼ使えない(例
netstatとかでestablish connectionカウントと
か)。1秒で終わらないから
– procファイルシステムを使え

その4:syn cookie発動
? Syn cookieは本来はOSのDDoSのプロテ
クション機能
– 正常スパイクテスト(DDoSはかけてない)だ
が発動しコネクションリセット
? ただ、この機構がないとTCPレイヤでdrop
– 原因はKernel側のsyn queueオーバーフロー

その5:アクセスの偏り
負荷ツール
ENI(Public IP)
ENI(Private IP)
ENI(Public IP)
EIP(Private IP)
内部
web01 web02
web01 web02
Per-AZ Per-AZ
Per-LB
ENI(Public IP)
EIP(Private IP)
….
auto
….
auto
ENI(Public IP)
EIP(Private IP)
? TTLキャッシュ -> クライアント側の
設定で回避

インフラチューニング(細いところは基本なし)
? kernel側のsyn queueやTCPチューニングし
てTCPコネクションを保持/最適化する
? 保持したsyn queueを早くさばけるようにミ
ドルウェア側の各種ワーカースレッド/共有
メモリ等チューニングして、処理性能を上げ
る
– MaxRequestWorkers等のエラーを同時に解決
? OS資源(CPU/メモリ)が足らなくなったら、
EC2自体をスケールアップする

他のやったこと
? OS 3大資源(CPU/IO/memory)はOSチューニ
ングクラウドでやっても微妙
– 他のところに力を使おう
– 割り切ってスケールアップ、アップ
? AWSはサービスレベル(EC2/RDS/S3…)で
10G対応だがレイテンシは改善しにくい(PGと
かは除く)
– MultiAZ対応しつつ、ネットワークレイテンシ改善
? enhanced network(SR-IOV)対応
? RPS/RFS/XFS拡張

結果 EC2 38台 -> 19台
? 贬罢罢笔のエラーなし
? 通常のHTTPレイテンシ数MSEC -> 数+MSECまでDOWN

ALB
? 8/12リリース
? 機能
– L7バランシング
– HTTP/2サポート
– WebSocketサポート
– 他パフォーマンス/パフォーマンス向上

ALBパフォーマンス(キャパシティ)
? ELB同様 AutoScaling型のLB
? Pre-warmingあり
– 自前Pre-warming
– 申請Pre-warming

おわり
ALBは、ほとんど試験できてないです
…(タイトルすみません)

今後
? ALB検証進める
? 実トラフィックで少しずつ重みをつけて分散
しつつ状態を見る
? 負荷基盤改良
– EMR集計基盤統合化
– 全自動jmeterリソース分配とか統合化
– コンテナ対応のマネージドサービス(GKEあたり)
触ってみたいな

狠狠撸

摆社内勉强会闭贰尝叠と础尝叠と数万スハ?イク负荷テスト

More Related Content

摆社内勉强会闭贰尝叠と础尝叠と数万スハ?イク负荷テスト

Editor's Notes