社内システムパフォーマンス勉強会資料 #0

1. システムパフォーマンス
勉強会
#0
産業第1事業部
鈴木真吾

2. 注意
• このスライドは勉強会後に SlideShare にアップロードする予
定です
• メーリングリストで告知予定

3. 今回の内容
今回は勉強会のキックオフ回
• 勉強会について
• 勉強会の対象・目的・目標
• システムパフォーマンスについて
• システムパフォーマンスとは
• パフォーマンス分野の作業
• パフォーマンスエンジニアリングの難しさ
• 詳解システム・パフォーマンスについて
• 勉強会で扱う範囲
• 勉強会の進め方

4. 勉強会について
今回はシステムパフォーマンスを題材にした勉強会です
• 対象
• パフォーマンスで困ったことがある人
• パフォーマンスを意識した設計・実装を行いたい人
• 低レイヤの基礎知識がほしい人
• 目的
• パフォーマンスを意識した設計・実装・アーキテクトの知識を得る
• 目標
• 詳解システム・パフォーマンスの基礎部分を一通り読む(予定)

5. パフォーマンスエンジニアリング
“Performance engineering encompasses the techniques applied during a systems
development life cycle to ensure the non-functional requirements for performance
(such as throughput, latency, or memory usage) will be met.”
(en.wikipedia.org から引用)
• パフォーマンスエンジニアリングとは開発のライフサイクルに
おいて性能に関する非機能要件を達成する技術・学問
• 特にシステム全体にかかわるときにシステムパフォーマンスエンジニ
アリング(systems performance engineering)という

6. システムパフォーマンスエンジニアリング
• 対象
• すべての物理コンポーネント、ソフトウェアスタックが対象
• パフォーマンスに影響するものは何でも！
• 誰が扱うか
• システム管理者、アプリケーションデベロッパなど
• 担当業務の一部として
• 場合によってはすべてのチームで協力する
• 企業によってはパフォーマンスエンジニアという職種がある

7. パフォーマンスエンジニアリングは難しい
• パフォーマンス問題は主観的になりがち
• システムは複雑
• 同時に複数のパフォーマンス問題

8. パフォーマンス問題は主観的になりがち
• パフォーマンスの問題は客観的な評価を下しずらい
• そもそも問題なのかどうか明確でない
• 問題だとしても修復されたかどうか明確でない
• 一人のユーザがパフォーマンスが「良い」と思っても、別のユーザは
「悪い」と思うことがある。
• モデルを作り目標を定義しよう
• 平均応答時間の目標
• 要求の一定割合が特定の範囲のレイテンシに収まる
• レイテンシ分析など⇒(本の２章「メソドロジ」で紹介)

9. システムは複雑
• 全体的なアプローチが必要になることが多い
• 切り離して分析するとパフォーマンスはよいのに結合すると問題が起
きる
• ボトルネックも複雑
• 予想外の形で連関しているかもしれない
• ひとつのボトルネックを修復しても、システム内のどこか別の場所に移動してい
るだけかも
• 本番環境の負荷の特性のために実験環境では再現しない問題
⇒本の6章から10章までシステムリソースごとの分析手法を紹介

10. 同時に複数のパフォーマンス問題
• 複雑なシステムでは複数のパフォーマンス問題が同時に
• 本当の仕事は問題を見つけることではなく、もっとも重大な意
味を持つ問題を見つけること
• ⇒問題の大きさを定量化する必要がある
• レイテンシなどの指標を使う

11. 詳解システム・パフォーマンス
• 著者 Brendan Gregg
• @brendangregg
• Sun Microsystems, Oracle etc
• 現在 Netflix でパフォーマンスアーキテクトとして活動中
• 2017/2 出版
• DTrace
• 動的トレーシングツール、書籍でも紹介
• 原著「Systems Performance: Enterprise and Cloud」
• 2013/10 出版
• 原著を買ってから一ヶ月後に日本語版が出るとアナウンスがあった
• 日本語版は amazon で★★★★☆
• 大体良著との評価
• 訳と構成について問題があり

12. 詳解システム・パフォーマンスの対象
• OS
• Linux , Solaris
• 想定読者
• OS・アプリのパフォーマンスについて理解が必要な人
• 学生

13. 本の目次
• 1 章 イントロダクション
• 2 章 メソドロジ
• 3 章 オペレーティングシステム
• 4 章 可観測性ツール
• 5 章 アプリケーション
• 6 章 CPU
• 7 章 メモリ
• 8 章 ファイルシステム
• 9 章 ディスク
• 10 章 ネットワーク
• 11 章 クラウドコンピューティング
• 12 章 ベンチマーキング
• 13 章 ケーススタディ

14. 各章の構成
• 5章から11章 (CPU,メモリ,etc) は次のような構成
• 基礎知識
• 章が対象とするものの基礎知識・用語
• 基本となるモデル
• パフォーマンスに関する主要な概念
• アーキテクチャ
• 対象のアーキテクチャ
• メソドロジ
• 対象の観察・実験方法
• (応用) 分析
• ツールの使用方法・結果の確認方法など
• (応用) チューニング
• チューニング可能なパラメータの紹介

15. 本でおすすめされているツール
以下のツール(特に systemtap)については勉強会の４章あたりの
際に詳しくやりたい
• DTrace
• 動的トレーシングツール
• 実行中のソフトウェアを止めずにあらゆる個所の経過時間を動的に計測
• Solaris 向けだが Linux 向けにも移植されている
• systemtap
• 動的トレーシングツール
• 機能は DTrace に似ている（設計方針が同じ)
• systemtap については使い方・データの読み方を紹介しておきたい

16. 勉強会で扱う範囲
• 1章「イントロダクション」から11章「クラウドコンピューティン
グ」まで
• 1章から4章までは全体の基礎となる部分なのでこの順序で
• 5章以降は面白そうな部分から
• CPU,メモリ,ネットワーク,クラウドコンピューティングはやっておきたい
• ファイルシステム,ディスクはそれほどでもない (個人の意見)
• 基礎部分に重点を置きたい
• 基礎知識、アーキテクチャ、メソドロジ
• Solaris 部分はあまり触れない方向で
• 社内で触れる環境は用意できそうにない
• クラウドだと富士通が SPARC/Solaris クラウドを提供していた
• が、安く使えそうな感じではないのでパス

17. 勉強会の進め方
• 2 週間ごとに 1 回
• 1 回あたり 45 分まで
• それ以上は疲れる
• しばらくは shingo-s がプレゼン
• 希望があればだれかやってもらえばいい
• どこでやるか？
• 参加者に依存する

18. まとめ
• パフォーマンスエンジニアリングは難しい
• 広範囲の知識が必要
• 詳解システムパフォーマンスは良著なので勉強会にかかわらず
読もう