sysloadや監視などの話（仮）

Copyright © GREE, Inc. All Rights Reserved.
sysloadや監視などの話（仮）
Takanori Sejima

自己紹介
● わりとMySQLのひと
● 3.23.58 から使ってる
● むかしは Resource Monitoring も力入れてやってた
● ganglia & rrdcached の（たぶん）ヘビーユーザ
● 2010年くらいから使い始めた
● gmond は素のまま使ってる
● gmetad は欲しい機能がなかったので patch 書いた
● webfrontend はほぼ書き直した
● あとはひたすら python module 書いた
● ganglia じゃなくても良かったんだけど、とにかく rrdcached を使いたかった
● というわけで、自分は Monitoring を大事にする
● 一時期は Flare という OSS の bugfix などもやってた
● むかしあげたslideなど
● https://www.slideshare.net/takanorisejima
2

● 今日はその Resource Monitoring の話などしようと思います。
● ざっくりいうと、長いことやってれば学ぶことも多くあるし、長いことやってる
ことで問題もある、そんな話です。
● 今回はほとんどMySQLの話はありません。
● 自分でゴリゴリ monitoring 関係のコード書いてたのは、2014年くらい
までかなぁと思います、それ以降もちょくちょく metric 追加してますが。
● ここ数年、細かいところは、優秀な若手たちが頑張ってくれてます。
本日のお話
3

● かつて sysload という metric を作ったのですが、それに纏わる話など
します。
● gree/sysload
● ６年くらい前に自作した metric がそこそこ有用だと思うので、OSSで公開します
本日のお話の補足資料
4

● 2010年以前の弊社の resource monitoring
● gangliaをどう改造したのか？
● 次なる課題
● そこでsysload
● 当時、monitoring system 自作したのはなぜか
● 仮に、今ならばSaaSで置き換えられるのか
● 2010年ごろから長く使い続けて、見えてくるもの
● 継続的な monitoring は、エンジニアにとって学びの機会
● 新たな課題
Agenda
5

はじめに
6

● ganglia 以前は cacti を拡張した仕組みが動いてました。
● 大規模インフラの監視システム
● たいへんよくできてたんですけど、いくつか課題があったので。
● 2010年に入社したわたしが、新しい monitoring system を作ることに
なりました。
2010年以前の弊社の resource monitoring
7

● （監視対象のサーバが多すぎるせいか）metricがときどき途切れることが
ありました。
● cacti は polling して metric 収集するので、監視対象多すぎてpoller 回りきってな
かった可能性。
● cactiは内部的にMySQL使っているのだが、その部分がスケールしない
作りになってました（と当時感じました）。
● サービスが過負荷になったとき、障害発生箇所の切り分けをするために
は、metricの精度が足りてませんでした。
● 弊社では cacti で NFS を使っていたんですが、（少なくとも当時のLinux
では） NFSの安定性がイマイチだと感じることがありました。
cacti時代の課題
8

● （cacti のころは4桁後半のサーバを monitoringしてたけど）、それの軽
く数倍は管理してほしい。
● それらのサーバを、負荷の高い順にリアルタイムでソートしてほしい。
● （障害対応など他の業務の合間に）開発は一人でやってほしい。
● プロダクション環境への導入も、一人でやってほしい。
新しい monitoring system の要件
9

OK
わかった
10

開発期間は
無視させて
もらったけど 11

それ以外は
（だいたい）
できた 12

どうやった
のか？
13

まずは
dogfooding
14

● まずは自分でひたすら既存の cacti を使いながら、サービスの障害対応
した。
● cacti のアクセスログを調べて、社内のヘビーユーザを洗い出して、個別
にヒアリングし、ヘビーユーザの要件を、新規に洗い出してみた。
● かなり難しい要件なので、OSSをベースにして自分で開発するしかない
な、という感覚があった。
● 使えそうなOSSを調査していった。
最初にやったこと
15

● 割と早い段階で rrdcached の存在に気づいた。
● rrdcached はRRDtoolに付属している daemon。
● 2010年当時では、比較的新しい存在だった。
● 「rrdcached使えば、 cacti でもっと頑張れるのでは？」と思ったけど、
cacti で使っている RRDtool の template 機能を、 rrdcached はサ
ポートしていなかった。
● rrdcached に対応しているものとして、当時、 ganglia と collectd が
あった。
● そこで、入門監視でも取り上げられている collectd も、候補として考え
た。
当時、 ganglia と collectd が候補だった
16

● ganglia 3.1.7 から、 python で拡張 module を書けるようになった。
● 当時、 collectd はCでしか plugin 書けなかった気がする。
● ganglia は、Grid単位でツリー構造を構成し、サーバを管理できる設計に
なっていたので、うまく設計すれば、かなり大規模な構成を組めそうだと感
じた。
● ganglia は node の情報を取得するためのAPIなどあったので、うまく設
計すれば、APIサーバとして社内に機能を提供し、いろいろ拡張できそうだ
と思った。
なぜ ganglia を選んだか・その１
17

● Facebook による大規模な導入事例があったので、ある程度の規模でな
ら運用できそうだという期待があった。
● Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側-
Publickey
● Velocity 2010: Tom Cook, "A Day in the Life of Facebook Operations" -
YouTube
● ただ、 Facebook は「負荷の高い順にソートして表示する」というようなと
ころを魔改造しているようには見えなかったので、そのあたりは創意工夫
が必要だろうな、とは思っていた。
● あと、 Facebook は RRD の保存の disk write が重いから tmpfs に
RRD置いてたそうなんで、そこは HDD に書けるようにしたいなと思った。
なぜ ganglia を選んだか・その２
18

そして
魔改造
19

gangliaを
どう改造
したのか？
20

時間がないので
ざっくり行きます
21

● ganglia の cluster を、IPアドレスのレンジで適切にshardingする
● それらの cluster を透過的に扱えるよう、 webfrontend を作って、その
frontend にそれぞれの cluster へ proxy させる。
● webfrontend が cluster を透過的に扱うためのマッピング情報は、
batch job で定期的に生成する。
● RRDに15sec単位で情報を保存するために、 rrdcached を使いつつ適
切にチューニングする。
簡単にまとめると
22

● ざっくり書くと、次のような感じで。
● サーバのIPアドレスの /24 とかの単位で分割して、 ganglia の cluster たくさん作
る。
● ganglia は gmond という agent から UDP でパケット投げるんだけど、 IPアドレスのレン
ジ的に近いなら、UDPのパケットも落ちにくいだろうという期待もあった。
● それぞれの cluster に対して賢く proxy する webfrontend を自作する。
● webfrontend がどの cluster に proxy すればいいか、そのためのマッピング情報を
batch job で生成し、KVSに保存する。
● マッピング情報には、ついでに Load Average とかも保存しておいて、 Load Average の
順にサーバのリストを取得できるようにする。
● batch でリストを生成すると、完全にリアルタイムとはならないけど、だいたいリアルタイムで
負荷の高い順にソートできる。
● 故障したサーバがあれば、 batch 実行時にマッピング情報の更新対象から外せばいい
● webfrontend から、サーバの情報を管理するDBや、マッピング情報を管理するKVSに
アクセスして、特定のサーバの情報を表示できるようにする。
frontend部分はフルスクラッチで書いた
23

● 監視対象4桁後半、1nodeあたり数百metricで、RRDを15秒単位で更新
すると、実に大量の random write が発生するんですが。
● まぁ disk I/O は得意分野だから頑張ればいいだけなので、頑張って
チューニングしました。
● 最近はSATAのSSD使ってますけど、数年前まではHDDでなんとかして
ました。
● rrdcached は優秀でした。
RRDの更新については
24

● 数百 metric * 数千 node で大量のデータがあったとしても、そのすべて
を同時に見ることはない。
● 新機能をリリースしていたり、過負荷になっていたり、障害が発生していたりするような、
特定のサーバ以外では、metric を参照されるのは限定的である。
● ほとんどのサーバの metric は普段参照されていないので、そういった更新はバッファリ
ングしておけば良い。
● 本当に必要なものだけ、例えば、monitoring system のユーザが参照したいものだ
け sync するとか、あるいはバックアップ時にいったんflush したいとか、そういったとき
以外は、ゆっくり書き込めばよい。
● そういったバッファリングのための仕組みとして、 RRDtoolの場合は、
rrdcached を使うことができる。
Resource Monitoring の最適化のヒント
25

すごい
雑に言うと
26

InnoDB Adaptive Flushing
みたいな最適化をすれば
いいんだよ
27

● 自分で作ったものは、自分でヘビーに使ってみる
● 少なくとも、自分で許容できない response time にはしないようにする
● reseponse time が許容できる範囲であれば、なるべくシンプルな設計にした
● web アプリケーションなんで、どこかいじるたびに、chrome の developer tool で
[Network] パネルを見て、影響を調べてた
● ganglia や rrdcached 自体を monitoring する
● 何がボトルネックで、どれくらいスケールしそうなのか自分で調べる
● access.log からヘビーユーザの傾向をみる
● 例えば、朝出社してから帰宅するまで、何枚も画面開きっぱなしにしてるユーザがかなり
いた。そこで、グラフのreload間隔をN秒固定ではなく、多少ゆらぎをもたせるようにし
た。
作った後も、基本はやはり dogfooding
28

だいたい
要件満たすもの
作ったんだけど
29

ganglia
導入後の課題
30

課題・その一
（私以外の人には）
metricが多すぎる
31

● 昨年 blog で書きましたが、わたしは SHOW ENGINE INNODB
STATUS をパースするなどして MySQL だけで一台あたり三桁の
metricを取るようにしています。（わたし個人は）ほぼ全てのmetricが有
意義だと思ってるんですが、あまり評判がよろしくありませんでした。
● 昨年書いた MySQLのmetricに関する話と、実際にキャプチャした画面
● 個別の metric を取って drill down できるようにしておくのは重要なん
ですが、なんらかの summarize された composite graph が無いと、
組織的にスケールしないかな、という課題意識もありました。
metric多すぎる問題
32

課題・その二
　
（一時期）kernelがバグってて
Load Average の計算間違ってる
33

● わたしが入社した頃、サービスが過負荷になることがしばしばあったので、
「負荷が高くなってるサーバをとにかく抽出して、負荷高い順に表示する」と
いう monitoring system を提供することにより、サービスの安定性改善
に貢献しようと思ってたのですが。
● OS新しくしたら、負荷が高くなっても Load Average 上がらなくて、わた
しの作った monitoring system で高負荷なサーバを抽出できなくなっ
てしまったので。
● これは大いに困るな、と思いました。
Load Average 使えない問題
34

そこで
35

sysload
36

● 先日書いたblog
● ６年くらい前に自作した metric がそこそこ有用だと思うので、OSSで公開します
● 当時、 sysload で何をやりたかったかといいますと
● 様々なスペックのサーバが混在している中で、サーバの負荷を百分率で表現したい
● ただし、単純にCPU使用率だけでは表現できないので、 disk I/O などの負荷も加味したも
のが必要である
● capacity planning をわかりやすくしたい
● N+1の構成にするために、何台増設すればよいのかわかりやすくしたい
● APIサーバ提供したい
● New Relic みたいに summary report 投げたい
詳しくは blog を後ほど読んでいただくとして
37

● 仮にMySQLのslaveがn台あって、それぞれの sysload の平均値が x
とします。
● slaveが一台 host down しても、サービスを安定稼働させるために最低
限必要な台数は、少なくとも、次の式から求められるわけです
● x*n/(n-1) < 100
● 例えば、 slave の sysload の平均値が60として、 slave の台数が3だった場合、 slave
が一台 hostdown して slave の台数が2になったとき、 slave の sysload は
60*3/(3-1)=90 まで上昇すると予想されます
● まぁ実際には sysload < 100 ではなく、安全率かけて、一台 hostdown してもそんな
に負荷高まらないようにするんですが
● 単純に、 InnoDB で spin lock が競合し始めると、CPU使用率がリニアに上昇していくわ
けでもないので、低めに見積もっておかないとあっさり刺さるんで
● 式で表現できると、組織内で共通認識にしやすいわけです
（だいたいの問題を）百分率で表現できると
38

● 弊社の ganglia では、過去24時間分は15秒単位でRRD保存してまし
た。
● 24時間以上前は cacti準拠で、最長797日分のデータを保存するようにしてました。
● RRDtool は rrdxport でXML形式（最近はJSONでも）で値を取り出せる
ので、 webfrontend の proxy 叩いたら、任意のサーバの任意の
metric で rrdxport 叩けるようにしました
● なので、 daily でそのAPI叩いて sysload 取得すると、過去24時間で最
も負荷の高かった時間帯がわかるわけです
APIサーバ作りたい
39

● 次のような感じで daily report や monthly report 作ってました
1. サーバ単位で、その日いちばん高かった sysload の値を、その時間
帯とセットでMySQLに保存
2. 1. で保存した値を用いて、サービス単位などで sysload の
summary report を dailyで集計し、 MySQLに保存
3. 2. で保存した値を用いて、サービスなどの単位で、「今月もっとも
sysloadが高かった日」をmonthlyで集計し、MySQLに保存
daily で API サーバ叩いてsysload取れるなら
40

● 何が嬉しいかというと、次のようなときに役に立つわけです
● 例：
● ゲームでプロモーションを開始したとき、次回のイベント時にどれくらいサーバの負荷が増加
しそうなのか、過去のイベント時のデータを使って試算できる。
● アプリケーションの不具合等で高負荷になってしまい、一時的にサーバの増設をした後、適
正台数に戻したくなったとき。過去の実績など見て、徐々に安全にサーバの台数を削減する
ことができる。
sysload でサーバの負荷を集計できると
41

● サーバやインスタンスの台数は、サービスのコストに直結するので、可能
な範囲で調整したいというのが、運営する側の気持ちだと思います。
● しかし、台数を削減しすぎて過負荷になり、障害に直結してしまった場合、
お客様は一方的に不利益を被ることになります。
● そうならないよう、「これ以上減らすことは危険である」といった共通認識
を、組織内で持てるようにするための指標値は、必ずあった方が良いので
す。
● 新しい世代のサーバやインスタンスに移設するとき、性能が向上している
と、ある程度は台数の削減が見込めます。ただ、そういったときに減らしす
ぎないよう、なんらかの指標値はあるべきなのです。
サーバの台数を無理に減らさないこと、超重要
42

さて
43

当時、
monitoring
system
自作したのは何故か44

● 入門監視では、監視は自作するより、監視のSaaSが推奨されてます。わ
たしも、現代において監視のSaaSは有力な選択肢だと思います。
● ただ、当時は数千台以上のサーバのmetricを15秒単位で保存できる手
段は、自分でなんとかするしかなかったので、自分で作りました。
スケーラビリティとmetricの精度
45

● ざっくりいうと、数年前まで、ハードウェアの性能と、ミドルウェアのCPUス
ケーラビリティが足りませんでした。よって、（監視対象となる）サーバを、増
やさざるを得ませんでした。
● （極めて個人的な見解ですが）数年前と現代を比べて最大のブレークス
ルーは、やはりNAND Flashだったかと思います。
● 2010年あたりの15krpmのSAS HDDは、容量がとても少なかったので、大量のデータ
を保存するためには、数を並べるしかありませんでした。また、SAS HDDは消費電力が
高かったので、数を並べるとそれだけで電力を食いました。
● SSDの普及によって、サーバ１台あたりで扱えるデータが増大し、MySQL
なども、たくさんのCore使えることが求められました。
● 現代はハードウェアもミドルウェアも集約度がたいへん向上したので、監視
対象となるサーバの台数を減らせるようになりました。
なぜ当時スケーラビリティが必要だったか
46

● サーバの台数が多い場合、例えば、「どのサーバがトリガーになって
（MySQLの） too many connections が発生したか」ということを調査
するのが、かなり難しくなります。
● そういったとき、複数のサーバの metric を高精度で保存し、並べて比較
できるようになると、 too many connections の発生していく様を、時系
列を追って調査することが容易になります。
● もし、「どれかのサーバがトリガーになって、連鎖反応を起こして複数の
サーバで障害が発生しているのだけど、調査するための情報が足りない」
と感じているならば、 metric の精度を上げるのは、良い対策だと思いま
す。
なぜmetricの精度が必要だったか
47

仮に、今ならば
SaaSで
置き換えられるの
か？ 48

● かつて「gangliaで使ってるサーバの台数多すぎない？」と言われたことが
あったので、以前、若者が試算してくれたことがあったのですが。
● 一般的な監視のSaaSと比べてコストが1/4程度だったので、オンプレの監
視においては、未だに ganglia ベースのものが使われています。
● 「AWS向けの monitoring は ganglia ではない方が相性が良い」という
ことで、 AWS向けのものは、若者たちがGrafana+Prometheusベース
で新しいものを作ってくれましたが、監視対象のインスタンス上で metric
を収集するのには、未だ、 ganglia の agent が一部用いられてたりして
います。
コスト面で厳しい
49

2010年ごろから
長く使い続けて、
見えてくるもの
50

● 新しい世代のサーバやインスタンスを使おうとすると、具体的に言うと、新
しい世代のCPUを使おうとすると、新しい kernel に対応しているOSに移
行していく必要が発生します。
● （個人的な感想ですが）最近の kernel は、 TCP の再送を最適化するべ
く、TCP周りの修正がかなり入っています。
● そういった kernel patch は、大手クラウド事業者から提供されているものだったりする
ので、そういった大規模環境で実績がある最適化なのですが。
● わかりやすいところだと、 kernel 3.1 のときにRTOが１秒になったので、
この頃から /proc/net/netstat の TCPTimeouts の増え方がかなり変
わってると思います。
OSが新しくなると、 metric の意味が変わる
51

● 入門監視８章の訳注でも取り上げられた MemAvailable、 kernel 3.14
で merge されたみたいですが
● このあたりの解釈も踏まえると、メモリの監視って、 kernel を新しくすると
きに再考する必要も出てくるのかな、と感じたりします
● かつてわたしは、/proc/meminfo を参照して、次のような式でメモリの使
用量をグラフに書いてました
● メモリ使用量 = MemTotal - MemFree - Buffers - Cached
● 最近の kernel でこの式がベストかというと微妙ですが、いろいろ考えて、
現状このままで良いかなと思いました。
/proc/meminfo の MemAvailable など
52

● わたしがメモリの使用量を知りたい理由は、だいたい次の２つです
a. メモリリークが発生しているかどうか
b. malloc(2) が失敗する状態かどうか
● これら２つを知るためには、MemAvailable を厳格に解釈する必要はな
く、先ほどのメモリ使用量を求める式と、 /proc/meminfo の MemFree
があれば、だいたい要件を満たせるわけです。 page cache を破棄すれ
ばメモリ空けられるとしても、page cache 破棄するのはそれなりにコスト
が高いこともありますし。
● kernel が新しくなって、以前と metric の意味や定義が変わることはあり
ます。でも、その都度、本当に求められている情報について再考して、変化
を受け入れていけば良いわけです。
本当に知りたい情報を考える
53

● 話は変わって
● 一部のサービスをパブリッククラウドに移行したとき、アプリケーションサー
バでTCP timeout が一気に増えたことがあった
● しょうがないので、tcpdump とって kernel のソースコード読んだ
● おおむねわかった
● なので、kernel 3.13で引用しつつ解説
環境が変わると metric の意味が変わる
54

● Load Balancer が pre-open する（client から request 飛んでこなく
ても、事前に connection 張ろうとする）
● アプリケーションサーバ上で apache が TCP_DEFER_ACCEPT して
る。TCP_DEFER_ACCEPT で bare ack は破棄され、 apache は
SYN_RECV で待ち続ける
● （たいへんざっくりいうと）TCP_DEFER_ACCEPT してるサーバは、ACK
を受け取った後、 DATA が届くまで SYN/ACK を再送しない。
● しかし、SYN_RECVで待ち続けてる状態で、TIMEOUT を起こすと、
TCPTimeouts がインクリメントされる
TCP_DEFER_ACCEPT のときの振る舞い
55

● TCP Timeout が発生してパケット再送されるときは、TCPTimeoutsだ
けでなくRetransSegsも増える。
● しかし、RetransSegsが増えずにTCPTimeoutsだけ増えている場合は、
TCP_DEFER_ACCEPT が有効で、SYN/ACK再送せずに
tcp_syn_ack_timeout() だけ呼ばれたという可能性もある
● TCP_DEFER_ACCEPT が有効で bare ack が破棄されたときは
TCPDeferAcceptDrop がインクリメントされるので、 TCP_DEFER_ACCEPT が有効
かどうかは、TCPDeferAcceptDropを見ることで確認することもできる
TCPTimeoutsと併せてRetransSegsも
56

● （だいぶ前ですが）kernel 2.6.37 で TCPTimeWaitOverflow が、
kernel 3.15 で TCPSynRetrans が追加されました。
● もしいま取得していないのであれば、これらの metric は取得するようにし
ても良いのではないかと思います。
● 例えば、オンプレミス環境からパブリッククラウドに移行する際、最も気にな
る要素の一つは、どれだけパケットの再送が発生するかとか、ネットワーク
の品質かと思います。 TCPSynRetrans はそういったものを推し量る尺
度の一つとなり得ます。
● 最近の kernel は TCP の再送周りの最適化がかなり進んでいるので、
RetransSegsだけでなく、TCPSynRetransなども併せて見たほうが、よ
り効果的ではないかと思います。
環境が変わると、取得すべきmetricが増える
57

という具合に、
monitoring し続けて、
変化し続ける環境を見ていると、
多くの学びがあります。
58

継続的な
monitoringは
59

エンジニアに
とって
学びの機会 60

● 環境が変わったり、ミドルウェアのバージョンを上げたりすると、metric に
変化が現れることがある。
● そういった機会を逃さずにちゃんと調べると、様々な学びがある
● そのためにはまず、自分たちの環境を細かく monitoring して、環境やミ
ドルウェアのバージョンを変えたとき、どのような変化が生じるか、見逃さな
いようにしたほうが良い。
● もしなんらかのミドルウェアのスペシャリストであるならば、自分が得意なミ
ドルウェアの metric は、注意深く取り続けたほうが、成長の機会は得ら
れやすい。
環境、OS、ミドルウェアの変化を見逃さない
61

そうは
言っても
62

ganglia
使い始めて
そろそろ十年
63

長いこと
使いすぎ
64

新たな課題
65

● python2.7 はサポート期間がとても長い Lightweight Language だっ
た。十年近く使うことができた。
● ganglia の modpython.so は、python2.1以降を対象としていたの
で、一度つくった python module は数年間に渡って利用することができ
て、とても便利だった
● kernel やミドルウェアのバージョンが上がるたびに、ちまちま直してはいたけれど
● しかし、 ganglia は python3.x では build も通らない。仮にgangliaを
python3.xに対応させたとしても、 python module を python3対応さ
せる必要が出てくる。
python2.7 の EOL
66

● 弊社は主に Ubuntu 使ってるんですが、昨年リリースされた Ubuntu
18.04 LTS（Bionic Beaver）は、 python2.7 も python3も（3.6も
3.7も）サポートされることになりました。
● よって、Bionic Beaver の EOL、2023年4月までは、python2.7と
gangliaを使い続けることができるかなと思ってるんですが。
● それ以降は、ganglia 以外のものでmonitoring をやっていかないとい
けないかなぁと感じています。
● さしあたって、2020年4月に Ubuntu 20.04 LTS がリリースされる予定
で、20.04では python2.7 が含まれない予定なので、来年くらいから、
じっくり考えていきたいなと思ってます。
Ubuntu 18.04 は python2.7 からの橋渡し
67

● かつては大量のnodeを管理できないといけなかったけど。最近は、サー
バ（ないしインスタンス）のスペックや、MySQLなどミドルウェアのCPUス
ケーラビリティなど改善してきたので、monitoring system にそこまでの
スケーラビリティは求められない。
● python2.7のサポート期間がとても長かったので、gangliaではLLの
EOLについてそれほど考えなくてよかったけど。次はそういったもののEOL
を、どう乗り越えて行くのが良いか。
● 少なくとも、次の環境に、python2系向けに書かれた sysload の
python module をそのまま持っていくことはできない。ソースコードでは
なく、培ったノウハウを、（その中でも意味のあるものを）、如何に取捨選択
して、次の環境に持っていくか。
数年後の未来に備えて、考えること
68

おわり

sysloadや監視などの話（仮）

More Related Content

What's hot

Similar to sysloadや監視などの話（仮）

More from Takanori Sejima

sysloadや監視などの話（仮）