AWS re:Invent2013参加レポート #29 Your Linux AMI: Optimization and Performance

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

IMG_0384

セッション内でNetflix社によるカーネルチューニングの具体例が紹介されていたの で共有します。
セッションのタイトルはAMIの最適化ですが、ここで紹介された内容はLinuxであれば環境を問わず適用できると思います。

Linux カーネルチューニングをやる意義

実際のチューニング内容の紹介の前に、なぜNetflix社が手間がかかるにもかかわらず カーネルチューニングをやってるのかの解説がありました。

カーネルチューニングの利点

  • インスタンスのキーリソースを効率的に使える(キーリソースとはそのインスタンス上で動くアプリケーションが特に必要とするりソースです)
  • 効率化は大きなコスト削減につながる
  • チューニングの過程で適切なインスタンスタイプを特定できる
  • 例えばprefやsystemtapなどのLinuxツールにより、カーネルやアプリケーションをより深く理解できるようになる

カーネルチューニングによるトレードオフ

  • カーネルの各サブシステムは相互に依存しているので、ある特定の部分の改善が他 の部分に悪影響を与えることがある
  • アプリケーションのリファクタリングやチューニングに比べて効果が低い(効果はアプリケーションが80%、カーネルが20%)
  • 全てに効果的なチューニングは存在しない。あるアプリケーションに効果的なチューニングは他のアプリケーションには悪影響を及ぼす

Netflix社の場合、多様なアプリケーションがそれぞれ非常に大きな規模(数万台規模)で稼働しているので、チューニングにより大きなコスト削減が実現できているとのことでした。

Amazon Linuxはデフォルトでそれぞれのインスタンスサイズに適したチューニングが施されているので、それほどの規模でない場合はそのままでもいいかもしれませ ん。

チューニング対象

IMG_0408

リソース測定ツール

個人的に、以下の3枚の資料が一番の収穫でした。
htop、いいですよね。viの癖で「k」で下に移動しようとするとkillになるのが怖いですが。
他にも良いツールがあったら教えてください。

IMG_0409

IMG_0414
IMG_0415

タスクスケジューラのチューニング

バッチ処理など少数のプロセスにCPUを効率的に使わせたいシステム用です。
プロセスに割り当てられる時間を長くすることで、コンテクストスイッチングによるオーバヘッドを減らし、CPUキャッシュが効果的に使われるようにしています。
IMG_0419

ページキャッシュのチューニング

CassandraやSambaなど書き込みスループットが求められるアプリケーション用です。
ページキャッシュ内のデータをこまめにディスクに書き出すことで、一度に大量の書き込みが発生することを避けています。
IMG_0422

ブロックレイヤーのチューニング

おそらくインスタンスタイプHI1かHS1を使っており、SSD用にキューの深さを256にしていますが、他のインスタンスタイプならもっと小さい値の方がいいかもしれません。
IMG_0424

メモリのチューニング

OOM Killerが怖いので、実メモリ以上のメモリをプロセスに割り当てないようにしています。
IMG_0425

ネットワークスタックのチューニング

tcp_fin_timeout以外、知りませんでした。どのくらい効果があるか計測してみたいと思います。
IMG_0427

今後のチューニング予定

IMG_0432
楽しそうですね。

感想

別のセッションで、EC2インスタンスに対する負荷試験のやり方の説明があったのですが、インスタンスタイプごとに10台のインスタンスを立ち上げて、統計値を取っているとのことでした。同じインスタンスタイプでもインスタンス間で性能にばらつきがあるからです。
もしNetflix社も似たようなやり方で試験をし、チューニングしているのであれば、すごい手間と時間をかけていることと思います。

そうして得られた結果をたとえ一部であってもこうして公開するのはすごいなと感じました。
もちろん、上のチューニングの値はNetflex社が自社のアプリケーションが特定のインスタンスで最適に動くように指定しているものなので、自分の環境にそのまま適応するのは危険ですが、チューニングのポイントは参考になるのではないでしょうか。