地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【AWS】Amazon Web Service 負荷試験入門の読書メモ

概要

Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかる Software Design plus | 仲川 樽八, 森下 健 | 工学 | Kindleストア | Amazon

この本を読み始めたので気になったところとかをメモしていく

目次

負荷試験PDCAサイクル

負荷試験におけるPDCAはざっくり以下の流れ。一回で終わらせるのではなく回していくのが大事

  • Plan 負荷試験計画の立案
  • Do 負荷試験の準備及び実施
  • Check 計画時に立てた目標値と前提条件をクリアしたか
  • Action 負荷試験レポートの作成、システムの改善

試験なので合否を出してレポートまとめて終了みたいな場合が多くなりそうだが小さなPDCAを継続的に改善していくのが大事。

1章 間違いだらけの負荷試験とWebシステムの失敗事例

間違いだらけの負荷試験負荷試験は試験内容的にも後回しにされがちで最後の最後にさっとやって終わらせるケースが多い。負荷試験で問題が起きるとボトルネック次第では手戻りが大きくなるのできちんとスケジュールを組み込んでおく必要がある。

あとは基礎知識がない状態で負荷試験に挑むとレポートが実は誤りだらけであまり意味のないレポートが出来上がってしまい運用時に困るケースがある。間違った試験に気づかないまま試験完了とならないようにきちんとレビューなりで試験項目やレポートを確認する必要がある。

2章 Webシステムの設計手法

システムの設計手法

オンプレ時代/クラウド時代のwebアーキテクチャの説明とそれぞれの特性の違いなど

可用性に影響する起因

  • ネットワーク
  • 電源
  • ハードウェア

などなど可用性はソフトウェアだけで語れる部分と語れない部分が存在する。可用性の計算はシステムが直列になっている場合はそれぞれの積になる

単一障害点

システムは冗長化することで単一障害点をなくすことができる。別系統であるのが重要とされているが別系統ってみるレイヤ次第でどこまで変える必要があるのかなど考慮点は多いと感じた。(AWSでいうMulti-AZなど)

冗長度は以下の式で求めることができる

1 - (単一機器の利用不能率)^冗長度

冗長度を上げることで可用性が向上する

クラウド時代のシステム構築

ここでのクラウドとはオンプレ時代と違って自社でハードウェアリソースを調達せずにクラウド事業者の所有するリソースを時間単位で借りて利用できるシステム。

(馬鹿でかい会社だとプライベートクラウドのような概念も存在して自社でハードウェアを調達するがアプリケーションエンジニア視点では意識しないのでこの書籍でのクラウドにはプライベートクラウドも該当すると思って読んでいる)

この章はあとは代表的なクラウドデザインパターンの紹介と特性の説明となっていた。以下のサイトも詳しいので補完的に読むのに良さそう。

aws.clouddesignpattern.org

堅牢性とは

可用性と似た言葉に堅牢性という言葉がある。可用性とは違った概念を指していてデータ欠損が発生しない数値を示す。

3章 負荷試験の基本知識

負荷試験の基本知識

クラウド時代の負荷試験の目的

この章がとても刺さった。

クラウド時代の負荷試験はいわゆるオンプレ時代のようなハードウェアの選定や性能改善に必要な数値の割り出しの他にスケール性の評価が重要だということ。スケーラビリティはオンプレではあまり意識することなかったがクラウドはスケールが簡単に行えるので例えば単体サーバでの性能は重要ではあるが重要度はそこまで高くなくてサーバをスケールアウトやアップすることでサービス提供能力が高まることの方が大事。

スループット とレイテンシ

  • スループット -> 単位時間に処理を行う量のこと
  • レイテンシ -> 処理時間

それぞれ明確に意味は異なるがどちらかを改善するともう一方も改善したりと関連性はあったりする。またそれぞれ依存するサブシステムが存在する場合はそこの数値のうち最小値がボトルネックとなり得るので意識する必要がある

悪い負荷試験

  • 試験対象システムに負荷が集中していない
    • 試験対象外の場所に負荷が集中している状態
  • ボトルネックを特定できていない
    • 負荷試験の目的としてどこをスケールさせれば性能が出るかなどを知るためにやったりもするのでこの観点は大事

4 負荷試験のツール

負荷試験を行うためのツールである攻撃やプロファイリング/モニタリーングツールに関しての選定基準など。選定基準には攻撃力についてなんかもためになった

  • 攻撃ツール -> システムに負荷を与えるツール
  • モニタリングツール -> システムのリソース状況を観測し可視化するツール
  • プロファイリングツール -> ミドルウェアやアプリの内部の動作を可視化するツール

(プロファイリングは使ったことないけどflaskとかspringにあるような高機能なものはいつか使ってみたい)

攻撃ツール

モニタリングツール

プロファイリングツール

5 負荷試験の計画

計画の立て方や目標値の設定方法など

6 負荷試験の準備

事前に必要な準備について

7 負荷試験の実施1―試験実施とボトルネックの特定

8 負荷試験の実施2―原因分析とシステムの改善作業

9 負荷試験レポートの作成

10 負荷試験実践のケーススタディ

11 巻末資料

その他

負荷テストの目的