Kubernetes上に負荷試験基盤を構築した話 - Sansan Tech Blog
こんにちは、研究開発部Architectグループ ML Platformチームの藤岡です。今回はKubernetes上に負荷試験基盤を構築したので、その取り組みについて紹介しようと思います。 目次 目次 背景 負荷試験基盤の要件 負荷試験ツールの選定 負荷試験基盤のシステム概要 シナリオファイルの管理方法 Kubernetes operator pattern の利用 GitHub Actionsの共通化 Slack通知用のAPIを用意 負荷試験の導入 負荷試験シナリオの詳細 負荷試験の実行 負荷試験の結果 おわりに 背景 研究開発部ではマイクロサービスで開発することが多く、各事業部向けにさまざまなシステムをAPI形式で提供しています。 APIを作成した際には負荷試験を行っており、リリース前にAPIのパフォーマンスを確認しています。 しかし現状では、各々のローカル環境で負荷試験を実施してい
負荷制限を使用して過負荷を回避する
私は、数年間 Amazon のサービスフレームワークチームで働いた経験があります。私たちのチームは、Amazon Route 53 や Elastic Load Balancing などの AWS のサービスの所有者がより迅速にサービスを構築するのに役立つツールを作成し、サービスクライアントはそれらのサービスをより簡単に呼び出せるようになりました。他の Amazon チームは、測定、認証、モニタリング、クライアントライブラリ生成、ドキュメント生成などの機能をサービス所有者に提供しました。各サービスチームがそれらの機能をサービスに手動で統合する代わりに、サービスフレームワークチームは 1 回統合を行い、設定を通じて各サービスに機能を公開しました。 私たちが直面した課題の 1 つは、特にパフォーマンスまたは可用性に関連する機能に対して、適切なデフォルトを提供する方法を決めることでした。たとえば
クラウドネイティブ環境におけるJavaチューニングの進め方 〜 20,000rpsをさばく超PayPay祭の事例
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ショッピング統括本部の川口です。 本記事では、2022年2月から3月にかけて開催された超PayPay祭の事例をもとに、クラウドネイティブ環境におけるJavaチューニングの進め方について解説します。 本記事の内容は2022年6月19日に開催された、JJUG 2022 Springで発表した内容をベースにしています。 Yahoo!ショッピングにおける超PayPay祭は高負荷 超PayPay祭は全国のPayPay加盟店とオンラインショップでお得に買い物をお楽しみいただける大規模キャンペーンです。Yahoo!ショッピングにおいても、PayPayポイントがもらえるキャンペーンなどさまざまなお得な施策が実施されます。超PayPay
負荷試験＃サーバーアーキテクチャ事例 | 外道父の匠
図を書いて気分転換したくなったので、アーキテクチャについて軽く触れます。 細かくは省いて、負荷試験の大雑把なサーバー構成にはどのような選択肢があるのか、の事例を出していきます。 登場人物 超ざっくり分けると３つに分類されます。 基本AWS内での利用を想定していますが、User と Server は別にどこの環境でも大丈夫なようにしています。Client は ECS Fargate で使い捨て。 私の場合、実際にどのような構成で試験できるようにしたのか、を紹介していきますが、これだけ見ると至って普通な内容かもしれません。 １：１ ダイレクト型 まずは最もシンプルな構成で、主に動作テスト用です。 これだと普通にLocustを動かすのと変わらない構成です。実行命令と負荷リクエストを出すサーバーが同じで、任意の１ホストへリクエストを送信します。 Server は Host を指定するだけなので、経
負荷試験＃性能基準単位 | 外道父の匠
１つのリクエスト処理が完了するまでは大雑把に書くと User → Request → Web → App ↔ DB/KVS User ← Response ← Web ← と一連の流れがあり、当たり前ですけど、AppサーバーのCPUが稼働するのはAppの部分の処理だけになります。なので、1 : 1 で負荷をかけても、ネットワーク等のレイテンシによりAppをフル稼働させることが微妙にできなかったりします。 となると、1vCPU = 100% としての計測値を確実に採取したいならば、vCPU数より多いClient数が必要になります。そして、Client数に対してWorker数が足りないと、接続待機またはエラーが発生するので、Worker数もまたvCPU数より多い方が確実になります。 概ね1vCPU=100%での計測値を採取できれば良い、という考えでもある程度はイケるかもですが、ただ漠然と行う負
負荷試験＃実行条件と傾向観察 | 外道父の匠
負荷試験シリーズ、今回は実行時の条件と結果の読み取りについて考えていきます。 どのようなな調整で負荷試験を進めていけば、より効率的に正確な成果を得られるのか。これはただのパワーゲームではありません。 誤った考え方 アプリケーションが多様ゆえに、負荷試験にも完全な正解はないかもしれませんが、限りなく正着といえる手法はあります。 負荷試験を始めましょう、となった時にヤラカシがちなのが、いきなり本番想定のサーバー量で試験を始めることです。このサービスの想定DAUがいくらで、ピークタイムのRPSがいくらになりそうだから、サーバーはこのくらいだろう。と用意してそれに負荷をかけ、大丈夫だの足りないだのやりだすことの、なんと意味の薄いことか。 もしそれがオンプレミスならありえます。なぜなら、サービスが完成するだいぶ前には物理サーバーの準備ができている必要があり、そこから増減を考える意味がないからです。今
AWSの負荷テストソリューションを試してみた | DevelopersIO
シナリオを用いた負荷テストツールとしてJMeterやGatlingなどがございますが、AWSでも負荷テストのソリューションが用意されております。 こちらのソリューションは、Fargateで1秒あたり選択した数のトランザクションを生成する数千規模の接続ユーザーを簡単にシミュレートできます。 本エントリでは、AWSの負荷テストソリューションを使った負荷テストを紹介します。 構成要素 公式の構成図を拝借しています。 フロントエンドでは、バックエンドの負荷テストエンジンを実行するAPIと、テストシナリオの作成やモニタリングに使用するウェブコンソールが提供されています。 なお、使用するテストシナリオにはJMeterのシナリオを指定できるため、既にJMeterを使っている場合は簡単に大規模な負荷テストを行うこともできます。 バックエンドでは、負荷を生成するためのDockerイメージを作成します。イメー
負荷試験＃基本リンク集 | 外道父の匠
前の記事は実は前フリで、最近、負荷試験について深く潜り込んだので、自分なりに考えたことを細かく分けて書いていこうと思います。負荷試験シリーズのはじまり:-) 後半はほとんど自分で考えて色々実装しましたが、序盤は先人の知恵をかき集めてイィトコ取りしたので、メモっておいたリンク集を置いておきます。 はじめに 負荷試験ってツールを選んで大量リクエストを発生させるんでしょ。ってイメージがあるかもですが、より効率的により正確にって仕上げていくと、独自に実装したい仕組みが結構でてきます。 アプリケーションは当然モノによって仕組みや構成は異なるし、プロトコルが異なる場合もあります。千差万別は言いすぎかもだけど試験には色んな選択や工夫があり、これが正解っていう単純なものではないのは間違いないです。 とはいえ、シンプルな実行と結果でも、複雑な取り組みをしたとしても、求められる成果に対して十分で正しい結果を示
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Load test types | Grafana k6 documentation
AWS での分散負荷テスト | AWS ソリューション | AWS ソリューションライブラリ
負荷試験コトハジメ