この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
セッション内でNetflix社によるカーネルチューニングの具体例が紹介されていたの
で共有します。
セッションのタイトルはAMIの最適化ですが、ここで紹介された内容はLinuxであれば環境を問わず適用できると思います。
Linux カーネルチューニングをやる意義
実際のチューニング内容の紹介の前に、なぜNetflix社が手間がかかるにもかかわらず カーネルチューニングをやってるのかの解説がありました。
カーネルチューニングの利点
- インスタンスのキーリソースを効率的に使える(キーリソースとはそのインスタンス上で動くアプリケーションが特に必要とするりソースです)
- 効率化は大きなコスト削減につながる
- チューニングの過程で適切なインスタンスタイプを特定できる
- 例えばprefやsystemtapなどのLinuxツールにより、カーネルやアプリケーションをより深く理解できるようになる
カーネルチューニングによるトレードオフ
- カーネルの各サブシステムは相互に依存しているので、ある特定の部分の改善が他 の部分に悪影響を与えることがある
- アプリケーションのリファクタリングやチューニングに比べて効果が低い(効果はアプリケーションが80%、カーネルが20%)
- 全てに効果的なチューニングは存在しない。あるアプリケーションに効果的なチューニングは他のアプリケーションには悪影響を及ぼす
Netflix社の場合、多様なアプリケーションがそれぞれ非常に大きな規模(数万台規模)で稼働しているので、チューニングにより大きなコスト削減が実現できているとのことでした。
Amazon Linuxはデフォルトでそれぞれのインスタンスサイズに適したチューニングが施されているので、それほどの規模でない場合はそのままでもいいかもしれませ ん。
チューニング対象
リソース測定ツール
個人的に、以下の３枚の資料が一番の収穫でした。
htop、いいですよね。viの癖で「k」で下に移動しようとするとkillになるのが怖いですが。
他にも良いツールがあったら教えてください。
タスクスケジューラのチューニング
バッチ処理など少数のプロセスにCPUを効率的に使わせたいシステム用です。
プロセスに割り当てられる時間を長くすることで、コンテクストスイッチングによるオーバヘッドを減らし、CPUキャッシュが効果的に使われるようにしています。
ページキャッシュのチューニング
CassandraやSambaなど書き込みスループットが求められるアプリケーション用です。
ページキャッシュ内のデータをこまめにディスクに書き出すことで、一度に大量の書き込みが発生することを避けています。
ブロックレイヤーのチューニング
おそらくインスタンスタイプHI1かHS1を使っており、SSD用にキューの深さを256にしていますが、他のインスタンスタイプならもっと小さい値の方がいいかもしれません。
メモリのチューニング
OOM Killerが怖いので、実メモリ以上のメモリをプロセスに割り当てないようにしています。
ネットワークスタックのチューニング
tcp_fin_timeout以外、知りませんでした。どのくらい効果があるか計測してみたいと思います。
今後のチューニング予定
楽しそうですね。
感想
別のセッションで、EC2インスタンスに対する負荷試験のやり方の説明があったのですが、インスタンスタイプごとに10台のインスタンスを立ち上げて、統計値を取っているとのことでした。同じインスタンスタイプでもインスタンス間で性能にばらつきがあるからです。
もしNetflix社も似たようなやり方で試験をし、チューニングしているのであれば、すごい手間と時間をかけていることと思います。
そうして得られた結果をたとえ一部であってもこうして公開するのはすごいなと感じました。
もちろん、上のチューニングの値はNetflex社が自社のアプリケーションが特定のインスタンスで最適に動くように指定しているものなので、自分の環境にそのまま適応するのは危険ですが、チューニングのポイントは参考になるのではないでしょうか。
0
