Contents
前提
小～中規模のLAMP環境（EC2でAmazon Linux、 Apache、RDSでMySQL、PHP）を任された事を想定。また、ELB配下に複数のWebサーバがあり、CPU使用率が閾値を超えた時にスケールアウトする。
負荷試験の目標として、性能の確認に加えて各パラメータのチューニングなども行う。
最初にやること
分からなければ本を読む。特に「Amazon Web Services負荷試験入門―クラウドの性能の引き出し方がわかる」を読むことを強くオススメします。入門と銘打っているだけあって初心者の強い味方になると思います。
可能であればリーダ、マネージャクラスの人にも読んでもらいましょう。最低でも「Chapter1 間違いだらけの負荷試験とWebシステムの失敗事例」に目を通してもらうと、負荷試験をやるにあたって真剣に話を聞いてもらえるようになるはず。
基本的には「非機能要件に書いてあるパフォーマンス指標を満たせるかどうか確認する」ということが負荷試験の目的になるはずですが、パフォーマンス指標の表現が曖昧（負荷試験の実施結果とリンクしない）になっていることもあります。この場合、要件定義の見直しや再確認が必要です。意味のある負荷試験にするために、リーダ、マネージャと意識合わせはしておきましょう。
Apacheのチューニング
最初にApacheのチューニングからやります。設定値にも色々ありますが、マストは以下の２つだと思います。
- MPM
- MaxClients(MaxRequestWorkers)
MPM
いくつか種類があるMPMですが、どれを使うか決めます。システムによって変わるのでお好みで。（オートスケーリング環境下であれば攻める必要もないので、個人的にはpreforkでいいんじゃないかと思います。）
MaxClients(MaxRequestWorkers)
定番の最初から一気に最大数の子プロセスを立ち上げる設定は入れておきます。
肝心のMaxClientsですが、チューニングの方法については諸説あります。
一番新しい、かつAWSの公式ドキュメントということで以下を参照するとpsの%MEMから算出するように書いています。
Amazon EC2 での Apache メモリのチューニング
しかしpsの%MEMはRSSから算出したメモリ使用率のはずです。共有メモリ分がそれぞれの子プロセスに上乗せされているので、この値を用いるとMaxClientsはかなり少なくなります。
なので（一気に立ち上げる設定も入れたことですし）実際に子プロセスを立ち上げてチューニングします。また、立ち上げるだけでなく軽くabで負荷をかけます。（一度リクエストを受け取るとメモリ使用量が少し増えたりするので…）
しばらく簡易的に負荷をかけてみて、メモリの使用量をモニタリングします。メモリリークしている場合は論外なのでプログラムの修正などをします。どうにもならない場合はMaxRequestsPerChildを適当に設定する。
Apacheの子プロセス自体のメモリ使用量+PHPでのメモリ使用量を想定し、少し余裕を見てMaxClientsを決めます。
EC2のチューニング
カーネルパラメータ
カーネルパラメータには定番の設定項目があります。以下にキーワードを挙げます。ググって関連する項目もまとめて/etc/sysctl.confに設定して下さい。
- net.core.somaxconn
- net.core.netdev_max_backlog
- net.ipv4.tcp_fin_timeout
- net.ipv4.tcp_tw_reuse
- net.ipv4.tcp_max_syn_backlog
- ……
この辺を設定しておかないと、具体的な症状として以下が現れます。
- Webサーバに継続して負荷をかけた際、かけ始めの瞬間はCPU使用率が上がるが、その後下がる（CPU使用率が高い状態で張り付かない）
- Webサーバのロードアベレージが低い
- ELBがHTTPステータス 504を返す
swap領域
負荷試験とは直接は関係ありませんが、AWS公式のLinux AMIだとswap領域が作成されないので必ず作成します。実メモリ枯渇によるOOM Killerを避けるためです。積極的に使用したいわけではないので、性能に影響のありそうなSwappinessは極力下げます。ボトルネックはCPU使用率になるのでメモリフルになることはないはずですが念の為。
負荷試験の実施
任意のツールで非機能要件に合致したシナリオ／スレッドで負荷をかけます。必要であればELBの暖気申請を。
最終的に以下を確認します。
- 第一段階として、ボトルネックがWebサーバのCPU使用率になっていること（リクエスト数の増加に伴いWebサーバのCPU使用率が上昇しスケールアウトすること）
- 第二段階として、ボトルネックがRDSのCPU使用率になっていること（オートスケーリンググループ内の最大インスタンス数が、RDSが死なない程度の個数になっていること）
- 端末で正常に動作確認ができること（タイムアウトなど、操作に支障がないか）
- 非機能要件を満たしていること
まとめ
負荷試験の具体的な一例を書いてみました。チューニングについてはそれぞれバラバラに言及されていることが多いので、そもそもシステム全体としてパラメータのチューニングをどこから始めたらいいのか分からないという場合に参考になれば幸いです。
負荷試験における具体的な負荷のかけ方など「Amazon Web Services負荷試験入門―クラウドの性能の引き出し方がわかる」で言及されていることについては敢えて書いていないので、とにかく読んでみて下さい。今回書いたような実践のケーススタディも豊富にあり、視野を広げてくれると思います。またAWSかどうかに関わらず、負荷試験をやるにあたっての知見が盛り沢山なので多くの人にきっと役に立つはずです。