Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[社内勉強会]ELBとALBと数万スパイク負荷テスト

15,697 views

Published on

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

Published in: Technology
  • Be the first to comment

[社内勉強会]ELBとALBと数万スパイク負荷テスト

  1. 1. ELBとALBと数万スパイク負荷 テスト/インフラチューニング
  2. 2. もてき たかひろ • 株式会社CyberZ • ビッグデータエンジニア • 以前はオープンソースのリアルタイムkernelと か開発 リアルタイムkernelコンテキストスイッチングの実装 モノリシック/マイクロ/ハイブリッドkernelアーキの設計/実装 • 得意な技術:エンジニアのための超自炊 https://www.facebook.com/takahiro.moteki.31
  3. 3. 話す事
  4. 4. ビッグデータエンジニアですが、ビッ グデータの話はしません
  5. 5. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  6. 6. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  7. 7. 経緯:オンプレアーキテクチャ(ざっくり) ………. スイッチ スイッチ Web/AP apache/tomat LB DB/KVS/Big-data mysql,aerospike, hadoop
  8. 8. 経緯:ある時… • 過去数万RPSクラスのスパイクアクセス発 生(オンプレ) • スパイクアクセスは不正アクセスと正常 アクセスを含んだもの
  9. 9. 経緯:ミッション • オンプレからAWSに移行させる • 数万RPSクラスのスパイク発生してもHTTPエラー 発生させないようなアーキテクチャ/構成にし、試 験を行う • バックエンド(DB/KVS/BigData)は今回対象外
  10. 10. AWSの場合どうなるのか?
  11. 11. 方針は大きく2つ
  12. 12. AWSの場合どうなるのか? 防御する 受けきる プロテクトのシグネチャ どうしよう、、、 システム運用が事業会社 なので現実的選択かもし れない VPC / ELB側でudp flood,syn flood等は防御してる、 他にもWAFとかもあるが、、、
  13. 13. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  14. 14. アーキテクチャパターン
  15. 15. 案1:ELB/EC2静的台数確保
  16. 16. 案2:pre-warming
  17. 17. 案3:route53-EC2(直刺し)
  18. 18. 案4:route53のトレンドを使う
  19. 19. 案5:ELB使わない。 HAproxy,nginx,Big-ip on EC2
  20. 20. 案6:auto scaling(ECS)活用
  21. 21. 案7:ストリームストレージkinesisフロン ト(もしくはapache kafkaとか)
  22. 22. 補足 • 負荷試験対象アプリ 特徴 – Cloudfrontのようなものは使えない(もちろんELBのoriginにも 刺せない) – セッションが短く、keep alivedのような維持はできない – HTTPのエラーは可能な限りなくす – レイテンシもある程度担保(数十msec以内)
  23. 23. 案1 +pre-warming 他プロジェクト等で本番稼動実績ある アーキテクチャを検証対象へ 一旦試験対象 静的確保だと素の オンプレと同じ、、、
  24. 24. ELBについて • AWS上のロードバランシングサービス(マネージドサービス) • EC2等を負荷分散 • L4のLB • 特徴 – スケーラブル(AutoScaling型のLB) – 高可用性(複数AZ対応/EC2の正常性判断によるリクエスト 振り分け) – 運用管理が楽(マネージドサービスなので) – 通常のLBと比べると機能性は少ない
  25. 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. 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. 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. 28. ELBのまとめ(キャパシティ面) • スパイクに弱い – 内部NodeでAutoScaleするが、数+秒~数分くらいかかる • 内部NodeのAutoScaleした動きがわかりにくい(モニタしに くい) • 内部NodeのAutoScaleに追加課金なし • 内部NodeのAutoScaleはあるが、AutoHealingは微妙 – Cross zone balancing有効化ならば、最小node数を2台へ保つ – ただし、ELB内部ノードに障害発生しAWSサポートへ入れ替え をしてもらった事あり 内部Nodeの動きは本来は意識しなくて良いもの。ただし、 ELBでスパイクと戦う時はそうもいかない
  29. 29. pre-warmingについて • 自前pre-warming – 自前で段階的に負荷かかてscaleさせておき、タ イミングで切り替える • 申請pre-warming – 静的にELBの内部Nodeのキャパシティを担保し ておく(増やしておく)機能 – Business以上のサポート加入&AWSサポートへ 申請することで可能 – 追加課金なし
  30. 30. 申請pre-warmingの仕様 • フロー – 申請フォーマット入力してAWSサポート -> AWS側作業(約1~数時間) -> 確認 • 1度申請での上限期間は3ヶ月 • pre-warming最大キャパシティ – コネクション数 – インスタンスタイプ/台数でpre-warming キャパシティ上限がある
  31. 31. 負荷ツール選定… の前にちょっと負荷ツールについて説明
  32. 32. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  33. 33. 負荷環境/ツールについて(カテゴライズ) • マネージドサービス/ソリューションサービスを使う • アプライアンスを使う • ハコは自前で静的に用意して負荷ツールを構築して使う オンプレ時代 まず、ハコがないんじゃ、 基盤が同じなんじゃ(NW影響受ける)
  34. 34. • マネージドサービス/ソリューションサービスを使う • アプライアンスを使う • ハコは自前で静的に用意して負荷ツールを構築して使う • ハコはクラウドベンダ上で動的生成を行い負荷ツールを構築して使う • クラウドベンダ上のマネージドサービスを使う クラウドになった時代 選択が増えた 負荷環境/ツールについて(カテゴライズ)
  35. 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. 36. プロビジョニング自動系について (他は説明不要、省略)
  37. 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. 38. Lambda登場 Lambdaを使用して分散負荷テス トするOSSツールが出てきた
  39. 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. 40. 他こうゆうのも(試してない) • Distributed Load Testing Using Kubernetes – https://cloud.google.com/solutions/distributed -load-testing-using-kubernetes
  41. 41. 負荷ツールについて(選択 細いやつ) • 実行エンジン/プロビジョニング • スパイクアクセス • 分散モード • long running • RPSスケジューリング • シナリオワーク • サマリレポート(分散モード) • クライアントの選択 • GUI • モバイルモード • webの情報量 • 実績 • 近くに詳しい人がいるか? • その他(認証やcookieテスト) • 金額/ライセンス
  42. 42. 今回のスパイク負荷テストのため 負荷ツールの選定
  43. 43. 話すこと • ELBと数万RPSスパイク負荷テスト – ~経緯~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  44. 44. 要件確認 スパイク負荷テスト(トラフィック許容テスト) baseのトラフィック 約1500RPS スパイクのトラフィック 約5万RPS ~ 6万RPS • 見たいところ – ELBのキャパシティ -> 1シナリオ – EC2側(OS+ミドル)とネットワークのキャパシティ -> 1シナリオ – HTTPの性能 – アプリケーションレイヤ • ただしアプリケーションはデプロイ
  45. 45. どうやってトラフィックを生成さ せるのか?
  46. 46. baseで1500RPSは問題ないが、数秒で一気に5万RPSかけ る、負荷かける側どうやるんだこれ? クラウドだし、数秒で台数確保すれば負荷かけられ るか? 懸念ポイント 数秒 -> ここで数十秒かかって負荷かけると、ELBが勝手 にスケールし始める。可能ならばリクエスト変動期間なし。 -> 本来のトラフィック再現テストになっていない
  47. 47. どうやるか…?
  48. 48. 負荷ツール選定 スパイク負荷テスト(トラフィック許容テスト) baseトラフィック 約1500RPS スパイクトラフィック 約5万RPS ~ 6万RPS baseトラフィック ->機能(RPSスケジューリング/long running/シナリオワーク) スパイクトラフィック -> 自動プロビジョニング
  49. 49. 負荷ツール選定 スパイク負荷テスト(トラフィック許容テスト) baseトラフィック 約1500RPS スパイクトラフィック 5万RPS ~ 6万RPS baseトラフィック -> jmeterクラスタ + シェーピングスループッ トタイマ スパイクトラフィック -> lambdaで定期的に発生(goad/dino) 2層でかける
  50. 50. 環境(全体構成)
  51. 51. Jmeterクラスタ(baseトラフィック生成、RPSスケジューリング) 複数リージョンからlambda 分散実行,結果はSQSへ
  52. 52. やっとくとおすすめな事(足回り) • 一通りcactiとかモニタリングツールにメト リクスを記録させよう – 後で、あ、あのリソース状況見忘れた。他の人が 確認したいとかとか。 – CloudWatchだと通常2週間で消えます。 • ログをうまく漁れるようにしておこう – 1台1台web/ap入ってログ収集だとけっこう面倒 • 開始と終了時刻を記録しておこう – 細かくやっていて、リソースメトリクスがわから なくなったとか。
  53. 53. 話すこと • ELBと数万RPSスパイク負荷テスト – ~背景~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  54. 54. 試験シナリオ • 見たいところ – ELBのキャパシティ -> 1シナリオ – EC2側(OS+ミドル)とネットワークのキャパシティ -> 1 シナリオ – HTTP性能 – アプリケーションレイヤ • ただしアプリケーションはデプロイ • 静的コンテンツ/動的コンテンツ • リソース的なクリティカルパス • 時間的なクリティカルパス
  55. 55. 実施
  56. 56. 結果 EC2 38台 • HTTPのエラーなし
  57. 57. 苦労したところ
  58. 58. その1:分散してぬ、、少しラグがある • lambdaが分散しない(goad) – 5000RPSと5万RPSで、アクセス元(webサーバ側からみた)の 数は同じ – Lambdaバックエンドのライフサイクルコンテナ内で順繰りに 実行されてる – goadで多重度を増やしてもバックエンドのコンテナは増えない – バックエンドコンテナで異なるIPを持つわけではない(ホスト上 でもつ) Goadの実装依存。Dinoを使用する もしくは自前実装で処理を変える • 5万RPSを発生させるまでにラグがある – ラグ5秒~10秒かかる -> ELBのスケールが怪しくなってきそ う。。
  59. 59. その2:負荷試験ツールの結果に騙される (ごくまれに) 負荷かけれる側を解析する。EMRに頼った(ESとかでも良 いと思う)
  60. 60. その3:秒間モニタリングの苦労 • スパイクのテストをやってるので基本秒間モ ニタ – Zabbix(2.4)側が対応していない(データ取れて もグラフ側が見えん) • 結局linux上でscript組んでやった – 統計とるlinux標準コマンドは、ほぼ使えない(例 netstatとかでestablish connectionカウントと か)。1秒で終わらないから – procファイルシステムを使え
  61. 61. その4:syn cookie発動 • Syn cookieは本来はOSのDDoSのプロテ クション機能 – 正常スパイクテスト(DDoSはかけてない)だ が発動しコネクションリセット • ただ、この機構がないとTCPレイヤでdrop – 原因はKernel側のsyn queueオーバーフロー
  62. 62. その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キャッシュ -> クライアント側の 設定で回避
  63. 63. 話すこと • ELBと数万RPSスパイク負荷テスト – ~背景~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  64. 64. インフラチューニング(細いところは基本なし) • kernel側のsyn queueやTCPチューニングし てTCPコネクションを保持/最適化する • 保持したsyn queueを早くさばけるようにミ ドルウェア側の各種ワーカースレッド/共有 メモリ等チューニングして、処理性能を上げ る – MaxRequestWorkers等のエラーを同時に解決 • OS資源(CPU/メモリ)が足らなくなったら、 EC2自体をスケールアップする
  65. 65. 他のやったこと • OS 3大資源(CPU/IO/memory)はOSチューニ ング クラウドでやっても微妙 – 他のところに力を使おう – 割り切ってスケールアップ、アップ • AWSはサービスレベル(EC2/RDS/S3…)で 10G対応だがレイテンシは改善しにくい(PGと かは除く) – MultiAZ対応しつつ、ネットワークレイテンシ改善 • enhanced network(SR-IOV)対応 • RPS/RFS/XFS拡張
  66. 66. 結果 EC2 38台 -> 19台 • HTTPのエラーなし • 通常のHTTPレイテンシ数MSEC -> 数+MSECまでDOWN
  67. 67. 話すこと • ELBと数万RPSスパイク負荷テスト – ~背景~ – ~アーキテクチャ(負荷かけられる側)について~ – ~負荷ツールについて~ – ~負荷環境(負荷かける側)について~ – ~スパイク負荷テスト実施~ • インフラチューニング • ALB少し
  68. 68. ALB • 8/12リリース • 機能 – L7バランシング – HTTP/2サポート – WebSocketサポート – 他パフォーマンス/パフォーマンス向上
  69. 69. ALBパフォーマンス(キャパシティ) • ELB同様 AutoScaling型のLB • Pre-warmingあり – 自前Pre-warming – 申請Pre-warming
  70. 70. おわり ALBは、ほとんど試験できてないです …(タイトルすみません)
  71. 71. 今後 • ALB検証進める • 実トラフィックで少しずつ重みをつけて分散 しつつ状態を見る • 負荷基盤改良 – EMR集計基盤統合化 – 全自動jmeterリソース分配とか統合化 – コンテナ対応のマネージドサービス(GKEあたり) 触ってみたいな

×