社内勉強会資料 ~ELBとALBと数万スパイク負荷テスト~

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

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

3. 話す事

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

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

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

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

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

9. 経緯:ミッション
• オンプレからAWSに移行させる
• 数万RPSクラスのスパイク発生してもHTTPエラー
発生させないようなアーキテクチャ/構成にし、試
験を行う
• バックエンド(DB/KVS/BigData)は今回対象外

10. AWSの場合どうなるのか?

11. 方針は大きく2つ

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

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

14. アーキテクチャパターン

15. 案1:ELB/EC2静的台数確保

16. 案2:pre-warming

17. 案3:route53-EC2(直刺し)

18. 案4:route53のトレンドを使う

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

20. 案6:auto scaling(ECS)活用

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

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

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

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

25. 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)
Availability Zone 1a
ENI(Public IP)
ENI(Private IP)
内部
Availability Zone 1a Availability Zone 1a
web01 web02
web01 web02
Per-AZ Per-AZ
Per-LB

26. ELBのAutoScalingの動き(scale時)~1
Availability Zone 1a
Cross zone
balancing有効化
ENI(Public IP)
ENI(Private IP)
Availability Zone 1a
ENI(Public IP)
ENI(Private IP)
内部
Availability Zone 1a Availability Zone 1a
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は値は丸められる

27. 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
いろいろなところで
”だいたい”わかります

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

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

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

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

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

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

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

35. 負荷ツールについて(特徴)
• 金額/ライセンス
• プロビジョニング
• 機能/シナリオワーク
と(クライアント数)
手動系:
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…
星の数ほどある負荷かけれるツール…

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

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

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

39. プロビジョニング自動系~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
– Github fork 3,star 24
• Clojider
– Cloujure製ツール。Lambda + S3で分散テスト
– https://github.com/mhjort/clojider
– Github fork 1,start 32
• 自前Lambda
– 自前でfunction定義してやるパターン

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

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

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

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

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

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

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

47. どうやるか…?

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

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

50. 環境(全体構成)

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

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

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

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

55. 実施

57. 結果 EC2 38台
• HTTPのエラーなし

58. 苦労したところ

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

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

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

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

63. その5:アクセスの偏り
Availability Zone 1a
負荷ツール
ENI(Public IP)
ENI(Private IP)
Availability Zone 1a
ENI(Public IP)
EIP(Private IP)
内部
Availability Zone 1a Availability Zone 1a
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キャッシュ -> クライアント側の
設定で回避

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

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

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

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

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

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

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

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

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