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と数万スパイク負荷テスト

20,694 views

Published on

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

Published in: Technology
  • -- DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT -- ......................................................................................................................... ......................................................................................................................... Download FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... (Unlimited)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • accessibility Books Library allowing access to top content, including thousands of title from favorite author, plus the ability to read or download a huge selection of books for your pc or smartphone within minutes ,Download or read Ebooks here ... ......................................................................................................................... Download FULL PDF EBOOK here { https://urlzs.com/UABbn }
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • DOWNLOAD THI5 BOOKS 1NTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download Full EPUB Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... Download doc Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

[社内勉強会]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あたり) 触ってみたいな

×