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や監視などの話（仮）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Takanori Sejima

More from Takanori Sejima (9)

Recently uploaded

Recently uploaded (8)

sysloadや監視などの話（仮）