タグ

負荷対策に関するshunmatsuのブックマーク (10)

  • Amazon DynamoDB に負荷をかけ、検証する方法をご紹介 | AWS - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

    皆さんこんにちは、Game Solutions Architect の邵 (@axot) です。 以前 AWS ブログの Amazon DynamoDB スケーリングのベストプラクティス という記事で DynamoDB 運用する際のポイントを紹介しました。 記事では、DynamoDB に負荷をかける方法をご紹介します。さらに、それを応用してスパイクおよび不均等なアクセスパターンについてのテストおよび解説もご紹介します。最後まで是非ご覧ください ! まず、今回のテストのための DynamoDB テーブルを作成します。 ベンチマークではなく、負荷の掛け方や性質を確認が目的なので、ReadCapacityUnits(RCU)、WriteCapacityUnits(WCU) とも最小限に 1 に設定しています。 また、ソートキー については日のテストで利用しないため、プライマリキーのみを作成し

    Amazon DynamoDB に負荷をかけ、検証する方法をご紹介 | AWS - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
  • 負荷制限を使用して過負荷を回避する

    私は、数年間 Amazon のサービスフレームワークチームで働いた経験があります。私たちのチームは、Amazon Route 53 や Elastic Load Balancing などの AWS のサービスの所有者がより迅速にサービスを構築するのに役立つツールを作成し、サービスクライアントはそれらのサービスをより簡単に呼び出せるようになりました。他の Amazon チームは、測定、認証、モニタリング、クライアントライブラリ生成、ドキュメント生成などの機能をサービス所有者に提供しました。各サービスチームがそれらの機能をサービスに手動で統合する代わりに、サービスフレームワークチームは 1 回統合を行い、設定を通じて各サービスに機能を公開しました。 私たちが直面した課題の 1 つは、特にパフォーマンスまたは可用性に関連する機能に対して、適切なデフォルトを提供する方法を決めることでした。たとえば

    負荷制限を使用して過負荷を回避する
  • k8s 上の負荷試験基盤でロードテストを効率化するために新機能を追加した話 - DMM inside

    Dagger Go SDK vs Shell in GitHub Actions ~ モノレポのCIの実装をGoで実装するまでの道のり ~

    k8s 上の負荷試験基盤でロードテストを効率化するために新機能を追加した話 - DMM inside
  • Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Enjoy Architecting

    概要 ここ最近、Kubernetesクラスタを番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 記事ではこれらの観点のチェックリスト的に使えるものとしてまとめてみます。 確認観点 攻撃ツール 1: ボトルネックになりえないこと Podレベル 2: 想定レイテンシでレスポ

    Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Enjoy Architecting
  • Locust を用いた Amazon EKS 上で動作するワークロードの負荷テスト | Amazon Web Services

    Amazon Web Services ブログ Locust を用いた Amazon EKS 上で動作するワークロードの負荷テスト 序章 多くの AWS 利用者は、自身のワークロードを実行するために Amazon Elastic Kubernetes Service ( Amazon EKS ) を利用しています。そのため、EKS クラスターをテストするプロセスを用意して、ワークロードを公開する前に弱点を特定し、クラスターを最適化することが不可欠です。負荷テストは、実世界のトラフィックを模倣する人工的な負荷を発生させることによって、ワークロードの性能や信頼性に焦点を当てます。特に、EKS の高い弾力性を期待する場合には有効です。 Locust は、リアルタイムダッシュボード 及び プログラマブルなテストシナリオを備えたオープンソースの負荷試験ツールです。 このブログでは、2 つの Amaz

    Locust を用いた Amazon EKS 上で動作するワークロードの負荷テスト | Amazon Web Services
  • 大規模な負荷テストを実行可能。「Distributed Load Testing on AWS」 を試してみる - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

    皆さん、こんにちは!テクニカルソリューションアーキテクトの山澤良介です。 皆さんは「AWS ソリューション」というページをご存知でしょうか? AWS ソリューションでは、世界中のユーザーが直面する一般的な問題の解決策を提供しております。既に 60 を超える多数のソリューションが公開されており、お客様は AWS ソリューションを使用することで実装にかかる時間と労力を節約することができます。 このように非常に便利なものではあるのですが、AWS ソリューションの存在を知っていた方であっても、「どんなソリューションがあるのかわからない」「ソリューションの概要や使い方がわからない」などの理由で実際に活用したことがある方は少ないのではないでしょうか ? そのような背景から、今回の記事では、皆さんに活用頂けそうな AWS ソリューションを 1 つ、使い方などを含めて紹介していこうと思います ! 今回紹介

    大規模な負荷テストを実行可能。「Distributed Load Testing on AWS」 を試してみる - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
  • 負荷試験#サーバーアーキテクチャ事例 | 外道父の匠

    図を書いて気分転換したくなったので、アーキテクチャについて軽く触れます。 細かくは省いて、負荷試験の大雑把なサーバー構成にはどのような選択肢があるのか、の事例を出していきます。 登場人物 超ざっくり分けると3つに分類されます。 基AWS内での利用を想定していますが、User と Server は別にどこの環境でも大丈夫なようにしています。Client は ECS Fargate で使い捨て。 私の場合、実際にどのような構成で試験できるようにしたのか、を紹介していきますが、これだけ見ると至って普通な内容かもしれません。 1:1 ダイレクト型 まずは最もシンプルな構成で、主に動作テスト用です。 これだと普通にLocustを動かすのと変わらない構成です。実行命令と負荷リクエストを出すサーバーが同じで、任意の1ホストへリクエストを送信します。 Server は Host を指定するだけなので、経

    負荷試験#サーバーアーキテクチャ事例 | 外道父の匠
  • 負荷試験#性能基準単位 | 外道父の匠

    1つのリクエスト処理が完了するまでは大雑把に書くと 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がいくらになりそうだから、サーバーはこのくらいだろう。と用意してそれに負荷をかけ、大丈夫だの足りないだのやりだすことの、なんと意味の薄いことか。 もしそれがオンプレミスならありえます。なぜなら、サービスが完成するだいぶ前には物理サーバーの準備ができている必要があり、そこから増減を考える意味がないからです。今

    負荷試験#実行条件と傾向観察 | 外道父の匠
  • 負荷試験#基本リンク集 | 外道父の匠

    前の記事は実は前フリで、最近、負荷試験について深く潜り込んだので、自分なりに考えたことを細かく分けて書いていこうと思います。負荷試験シリーズのはじまり:-) 後半はほとんど自分で考えて色々実装しましたが、序盤は先人の知恵をかき集めてイィトコ取りしたので、メモっておいたリンク集を置いておきます。 はじめに 負荷試験ってツールを選んで大量リクエストを発生させるんでしょ。ってイメージがあるかもですが、より効率的により正確にって仕上げていくと、独自に実装したい仕組みが結構でてきます。 アプリケーションは当然モノによって仕組みや構成は異なるし、プロトコルが異なる場合もあります。千差万別は言いすぎかもだけど試験には色んな選択や工夫があり、これが正解っていう単純なものではないのは間違いないです。 とはいえ、シンプルな実行と結果でも、複雑な取り組みをしたとしても、求められる成果に対して十分で正しい結果を示

    負荷試験#基本リンク集 | 外道父の匠
    shunmatsu
    shunmatsu 2021/08/14
    []パフォーマンス]
  • 1