」を呼んで学んだことまとめひろTechメモ技術ブログです。Services負荷試験入門」)を呼んでみることにしました。以下では、「良い負荷試験とは?」について、「AWS負荷試験入門」本を引用しつつ、自分の言葉で追加解説してみようと思います。「AWS負荷試験入門」によると、良い負荷試験の条件は以下の2つであると紹介されています。複数のサブシステムにて構成された試験の場合、それぞれのサブシステムに個別で負荷をかけて挙動を調査する必要があります。負荷試験の最中に特定のハードウェアリソースが過負荷に陥るのは決して悪いことではなく、非常に良い負荷試験が実施できていることを意味します。クラウドの性能の引き出し方がわかる」から引用システムの構成は、時として「自前で作った部分」と「外部サービスを呼んでる部分」に別れることがあります。仮に、あるフェーズでの負荷試験の目的が「『自前で作った部分』の性能を測り、改善していくこと」だったとしましょう。この場合、負荷試験を実施した結果、「外部サービスを呼んでる部分」が過負荷となってしまうと、良い性能試験にはなりません。本当は自前で作った部分で「不要なクエリをDBに飛ばしている」だったり、「DBに必要なインデックスが足りてない」とか、そういったことを検証するためのデータが出てきて欲しいのですが、「外部サービスが遅い」だけが結果になってしまうと、改善のしようがありません。これがアンチパターンであり「試験対象とするシステムに負荷が集中してない」状態です。観測したい対象や目的はフェーズによって変わっていくため、「外部サービス処理も含めた性能」も見たい場合があります。その場合は外部サービスをモックせずに試験することになります。常に現在実施中の試験におけるボトルネックはどこになっているのかを意識する必要があります。その特定をしやすい手順で実施することで、非常に効率的に試験を行えます。クラウドの性能の引き出し方がわかる」から引用ボトルネックとは「そのシステムの処理の中で一番スループットが低い場所」です。その場所がシステム全体の処理性能を決めています。逆にいうと「そこさえ改善すればシステム全体の処理性能を上げられる場所」なので、ボトルネックの推定・特定は大事な作業ですね。負荷試験は卓球のラリーコラムとして紹介されていた程度なのですが、「イメージ掴みやすいな」と思ったので紹介です。Services負荷試験入門」では、負荷試験は卓球のラリーであると紹介されていました。クラウドの性能の引き出し方がわかる」コラムを参考に作成このイメージを持てば、負荷試験における注意すべき以下3点についてイメージがしやすいとのことです。攻撃サーバ側を「ラリーのサーバ」、負荷試験対象システム側を「レシーバ」と言い換えて、卓球になぞらえるとこんな感じになるでしょうか。「球が卓球台を通過する時間」はシステムの文脈だと「ネットワークを通過する時間」に置き換えられます。山根は以前現場で「攻撃サーバは試験対象システムからネットワーク的に近い場所に置こう」という指摘をもらったことがありますが、その理由がこの例えでかなり腑に落ちました。確かにネットワーク的に近い場所に置いておかないと、観測したい指標が確認できませんね。まとめ簡単ではありますが、「AWS負荷試験入門」を呼んで学びになったなと思う箇所をまとめてみました。負荷試験はシステム全体を見ないといけない、総合力が試されるタスクだと思うので、引き続き研鑽を重ねていこうと思います。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。【性能】ISUCON9予選のLocal環境構築(DB部分:Docker-Compose)性能周りの知見向上のため、ISUCON過去問を触ってみたい!と思い至りました。「単体テストの考え方/使い方」を読んで、「良い単体テストとは、どういう状態か?」についてポイントをまとめた記事です。「リファクタリングをしたい」となったときに、リーダーとして「これってGoサイン出していいんか...??」と迷った時の思考についてメモります。Q&Aベースで思考を深めていく形をとります。経験5年目のWebエンジニアです。SIerからの転職経験1回あり。技術とリーダー経験の両取り目指して邁進中。ひろTechメモ技術ブログです。