[社内勉強会]ELBとALBと数万スパイク負荷テスト
Download as PPTX, PDF33 likes29,959 views
社内勉強会資料 ~ELBとALBと数万スパイク負荷テスト~
![[社内勉強会]ELBとALBと数万スパイク負荷テスト](https://image.slidesharecdn.com/elbalb-160822022623/85/ELB-ALB-56-320.jpg)
[社内勉強会]ELBとALBと数万スパイク負荷テスト
- 2. もてき たかひろ • 株式会社CyberZ • ビッグデータエンジニア • 以前はオープンソースのリアルタイムkernelと か開発 リアルタイムkernelコンテキストスイッチングの実装 モノリシック/マイクロ/ハイブリッドkernelアーキの設計/実装 • 得意な技術:エンジニアのための超自炊 https://www.facebook.com/takahiro.moteki.31
- 3. 話す事
- 5. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
- 6. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
- 7. 経緯:オンプレアーキテクチャ(ざっくり) ………. スイッチ スイッチ Web/AP apache/tomat LB DB/KVS/Big-data mysql,aerospike, hadoop
- 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
- 22. 補足 • 負荷試験対象アプリ 特徴 – Cloudfrontのようなものは使えない(もちろんELBのoriginにも 刺せない) – セッションが短く、keep alivedのような維持はできない – HTTPのエラーは可能な限りなくす – レイテンシもある程度担保(数十msec以内)
- 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 キャパシティ上限がある
- 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… 星の数ほどある負荷かけれるツール…
- 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
- 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テスト) • 金額/ライセンス
- 43. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
- 44. 要件確認 スパイク負荷テスト(トラフィック許容テスト) baseのトラフィック 約1500RPS スパイクのトラフィック 約5万RPS ~ 6万RPS • 見たいところ – ELBのキャパシティ -> 1シナリオ – EC2側(OS+ミドル)とネットワークのキャパシティ -> 1シナリオ – HTTPの性能 – アプリケーションレイヤ • ただしアプリケーションはデプロイ
- 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. 環境(全体構成)
- 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のスケールが怪しくなってきそ う。。
- 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
- 72. 今後 • ALB検証進める • 実トラフィックで少しずつ重みをつけて分散 しつつ状態を見る • 負荷基盤改良 – EMR集計基盤統合化 – 全自動jmeterリソース分配とか統合化 – コンテナ対応のマネージドサービス(GKEあたり) 触ってみたいな