Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

sysloadや監視などの話(仮)

3,065 views

Published on

sysloadや監視などの話です。

Published in: Technology
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

sysloadや監視などの話(仮)

  1. 1. Copyright © GREE, Inc. All Rights Reserved. sysloadや監視などの話(仮) Takanori Sejima
  2. 2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● わりと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
  3. 3. Copyright © GREE, Inc. All Rights Reserved. ● 今日はその Resource Monitoring の話などしようと思います。 ● ざっくりいうと、長いことやってれば学ぶことも多くあるし、長いことやってる ことで問題もある、そんな話です。 ● 今回はほとんどMySQLの話はありません。 ● 自分でゴリゴリ monitoring 関係のコード書いてたのは、2014年くらい までかなぁと思います、それ以降もちょくちょく metric 追加してますが。 ● ここ数年、細かいところは、優秀な若手たちが頑張ってくれてます。 本日のお話 3
  4. 4. Copyright © GREE, Inc. All Rights Reserved. ● かつて sysload という metric を作ったのですが、それに纏わる話など します。 ● gree/sysload ● 6年くらい前に自作した metric がそこそこ有用だと思うので、OSSで公開します 本日のお話の補足資料 4
  5. 5. Copyright © GREE, Inc. All Rights Reserved. ● 2010年以前の弊社の resource monitoring ● gangliaをどう改造したのか? ● 次なる課題 ● そこでsysload ● 当時、monitoring system 自作したのはなぜか ● 仮に、今ならばSaaSで置き換えられるのか ● 2010年ごろから長く使い続けて、見えてくるもの ● 継続的な monitoring は、エンジニアにとって学びの機会 ● 新たな課題 Agenda 5
  6. 6. Copyright © GREE, Inc. All Rights Reserved. はじめに 6
  7. 7. Copyright © GREE, Inc. All Rights Reserved. ● ganglia 以前は cacti を拡張した仕組みが動いてました。 ● 大規模インフラの監視システム ● たいへんよくできてたんですけど、いくつか課題があったので。 ● 2010年に入社したわたしが、新しい monitoring system を作ることに なりました。 2010年以前の弊社の resource monitoring 7
  8. 8. Copyright © GREE, Inc. All Rights Reserved. ● (監視対象のサーバが多すぎるせいか)metricがときどき途切れることが ありました。 ● cacti は polling して metric 収集するので、監視対象多すぎてpoller 回りきってな かった可能性。 ● cactiは内部的にMySQL使っているのだが、その部分がスケールしない 作りになってました(と当時感じました)。 ● サービスが過負荷になったとき、障害発生箇所の切り分けをするために は、metricの精度が足りてませんでした。 ● 弊社では cacti で NFS を使っていたんですが、(少なくとも当時のLinux では) NFSの安定性がイマイチだと感じることがありました。 cacti時代の課題 8
  9. 9. Copyright © GREE, Inc. All Rights Reserved. ● (cacti のころは4桁後半のサーバを monitoringしてたけど)、それの軽 く数倍は管理してほしい。 ● それらのサーバを、負荷の高い順にリアルタイムでソートしてほしい。 ● (障害対応など他の業務の合間に)開発は一人でやってほしい。 ● プロダクション環境への導入も、一人でやってほしい。 新しい monitoring system の要件 9
  10. 10. Copyright © GREE, Inc. All Rights Reserved. OK わかった 10
  11. 11. Copyright © GREE, Inc. All Rights Reserved. 開発期間は 無視させて もらったけど 11
  12. 12. Copyright © GREE, Inc. All Rights Reserved. それ以外は (だいたい) できた 12
  13. 13. Copyright © GREE, Inc. All Rights Reserved. どうやった のか? 13
  14. 14. Copyright © GREE, Inc. All Rights Reserved. まずは dogfooding 14
  15. 15. Copyright © GREE, Inc. All Rights Reserved. ● まずは自分でひたすら既存の cacti を使いながら、サービスの障害対応 した。 ● cacti のアクセスログを調べて、社内のヘビーユーザを洗い出して、個別 にヒアリングし、ヘビーユーザの要件を、新規に洗い出してみた。 ● かなり難しい要件なので、OSSをベースにして自分で開発するしかない な、という感覚があった。 ● 使えそうなOSSを調査していった。 最初にやったこと 15
  16. 16. Copyright © GREE, Inc. All Rights Reserved. ● 割と早い段階で rrdcached の存在に気づいた。 ● rrdcached はRRDtoolに付属している daemon。 ● 2010年当時では、比較的新しい存在だった。 ● 「rrdcached使えば、 cacti でもっと頑張れるのでは?」と思ったけど、 cacti で使っている RRDtool の template 機能を、 rrdcached はサ ポートしていなかった。 ● rrdcached に対応しているものとして、当時、 ganglia と collectd が あった。 ● そこで、入門監視でも取り上げられている collectd も、候補として考え た。 当時、 ganglia と collectd が候補だった 16
  17. 17. Copyright © GREE, Inc. All Rights Reserved. ● ganglia 3.1.7 から、 python で拡張 module を書けるようになった。 ● 当時、 collectd はCでしか plugin 書けなかった気がする。 ● ganglia は、Grid単位でツリー構造を構成し、サーバを管理できる設計に なっていたので、うまく設計すれば、かなり大規模な構成を組めそうだと感 じた。 ● ganglia は node の情報を取得するためのAPIなどあったので、うまく設 計すれば、APIサーバとして社内に機能を提供し、いろいろ拡張できそうだ と思った。 なぜ ganglia を選んだか・その1 17
  18. 18. Copyright © GREE, Inc. All Rights Reserved. ● 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 を選んだか・その2 18
  19. 19. Copyright © GREE, Inc. All Rights Reserved. そして 魔改造 19
  20. 20. Copyright © GREE, Inc. All Rights Reserved. gangliaを どう改造 したのか? 20
  21. 21. Copyright © GREE, Inc. All Rights Reserved. 時間がないので ざっくり行きます 21
  22. 22. Copyright © GREE, Inc. All Rights Reserved. ● ganglia の cluster を、IPアドレスのレンジで適切にshardingする ● それらの cluster を透過的に扱えるよう、 webfrontend を作って、その frontend にそれぞれの cluster へ proxy させる。 ● webfrontend が cluster を透過的に扱うためのマッピング情報は、 batch job で定期的に生成する。 ● RRDに15sec単位で情報を保存するために、 rrdcached を使いつつ適 切にチューニングする。 簡単にまとめると 22
  23. 23. Copyright © GREE, Inc. All Rights Reserved. ● ざっくり書くと、次のような感じで。 ● サーバの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
  24. 24. Copyright © GREE, Inc. All Rights Reserved. ● 監視対象4桁後半、1nodeあたり数百metricで、RRDを15秒単位で更新 すると、実に大量の random write が発生するんですが。 ● まぁ disk I/O は得意分野だから頑張ればいいだけなので、頑張って チューニングしました。 ● 最近はSATAのSSD使ってますけど、数年前まではHDDでなんとかして ました。 ● rrdcached は優秀でした。 RRDの更新については 24
  25. 25. Copyright © GREE, Inc. All Rights Reserved. ● 数百 metric * 数千 node で大量のデータがあったとしても、そのすべて を同時に見ることはない。 ● 新機能をリリースしていたり、過負荷になっていたり、障害が発生していたりするような、 特定のサーバ以外では、metric を参照されるのは限定的である。 ● ほとんどのサーバの metric は普段参照されていないので、そういった更新はバッファリ ングしておけば良い。 ● 本当に必要なものだけ、例えば、monitoring system のユーザが参照したいものだ け sync するとか、あるいはバックアップ時にいったんflush したいとか、そういったとき 以外は、ゆっくり書き込めばよい。 ● そういったバッファリングのための仕組みとして、 RRDtoolの場合は、 rrdcached を使うことができる。 Resource Monitoring の最適化のヒント 25
  26. 26. Copyright © GREE, Inc. All Rights Reserved. すごい 雑に言うと 26
  27. 27. Copyright © GREE, Inc. All Rights Reserved. InnoDB Adaptive Flushing みたいな最適化をすれば いいんだよ 27
  28. 28. Copyright © GREE, Inc. All Rights Reserved. ● 自分で作ったものは、自分でヘビーに使ってみる ● 少なくとも、自分で許容できない response time にはしないようにする ● reseponse time が許容できる範囲であれば、なるべくシンプルな設計にした ● web アプリケーションなんで、どこかいじるたびに、chrome の developer tool で [Network] パネルを見て、影響を調べてた ● ganglia や rrdcached 自体を monitoring する ● 何がボトルネックで、どれくらいスケールしそうなのか自分で調べる ● access.log から ヘビーユーザの傾向をみる ● 例えば、朝出社してから帰宅するまで、何枚も画面開きっぱなしにしてるユーザがかなり いた。そこで、グラフのreload間隔をN秒固定ではなく、多少ゆらぎをもたせるようにし た。 作った後も、基本はやはり dogfooding 28
  29. 29. Copyright © GREE, Inc. All Rights Reserved. だいたい 要件満たすもの 作ったんだけど 29
  30. 30. Copyright © GREE, Inc. All Rights Reserved. ganglia 導入後の課題 30
  31. 31. Copyright © GREE, Inc. All Rights Reserved. 課題・その一 (私以外の人には) metricが多すぎる 31
  32. 32. Copyright © GREE, Inc. All Rights Reserved. ● 昨年 blog で書きましたが、わたしは SHOW ENGINE INNODB STATUS をパースするなどして MySQL だけで一台あたり三桁の metricを取るようにしています。(わたし個人は)ほぼ全てのmetricが有 意義だと思ってるんですが、あまり評判がよろしくありませんでした。 ● 昨年書いた MySQLのmetricに関する話 と、実際に キャプチャした画面 ● 個別の metric を取って drill down できるようにしておくのは重要なん ですが、なんらかの summarize された composite graph が無いと、 組織的にスケールしないかな、という課題意識もありました。 metric多すぎる問題 32
  33. 33. Copyright © GREE, Inc. All Rights Reserved. 課題・その二   (一時期)kernelがバグってて Load Average の計算間違ってる 33
  34. 34. Copyright © GREE, Inc. All Rights Reserved. ● わたしが入社した頃、サービスが過負荷になることがしばしばあったので、 「負荷が高くなってるサーバをとにかく抽出して、負荷高い順に表示する」と いう monitoring system を提供することにより、サービスの安定性改善 に貢献しようと思ってたのですが。 ● OS新しくしたら、負荷が高くなっても Load Average 上がらなくて、わた しの作った monitoring system で高負荷なサーバを抽出できなくなっ てしまったので。 ● これは大いに困るな、と思いました。 Load Average 使えない問題 34
  35. 35. Copyright © GREE, Inc. All Rights Reserved. そこで 35
  36. 36. Copyright © GREE, Inc. All Rights Reserved. sysload 36
  37. 37. Copyright © GREE, Inc. All Rights Reserved. ● 先日書いたblog ● 6年くらい前に自作した metric がそこそこ有用だと思うので、OSSで公開します ● 当時、 sysload で何をやりたかったかといいますと ● 様々なスペックのサーバが混在している中で、サーバの負荷を百分率で表現したい ● ただし、単純にCPU使用率だけでは表現できないので、 disk I/O などの負荷も加味したも のが必要である ● capacity planning をわかりやすくしたい ● N+1の構成にするために、何台増設すればよいのかわかりやすくしたい ● APIサーバ提供したい ● New Relic みたいに summary report 投げたい 詳しくは blog を後ほど読んでいただくとして 37
  38. 38. Copyright © GREE, Inc. All Rights Reserved. ● 仮に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
  39. 39. Copyright © GREE, Inc. All Rights Reserved. ● 弊社の ganglia では、 過去24時間分は15秒単位でRRD保存してまし た。 ● 24時間以上前は cacti準拠で、最長797日分のデータを保存するようにしてました。 ● RRDtool は rrdxport でXML形式(最近はJSONでも)で値を取り出せる ので、 webfrontend の proxy 叩いたら、任意のサーバの任意の metric で rrdxport 叩けるようにしました ● なので、 daily でそのAPI叩いて sysload 取得すると、過去24時間で最 も負荷の高かった時間帯がわかるわけです APIサーバ作りたい 39
  40. 40. Copyright © GREE, Inc. All Rights Reserved. ● 次のような感じで daily report や monthly report 作ってました 1. サーバ単位で、その日いちばん高かった sysload の値を、その時間 帯とセットでMySQLに保存 2. 1. で保存した値を用いて、サービス単位などで sysload の summary report を dailyで集計し、 MySQLに保存 3. 2. で保存した値を用いて、サービスなどの単位で、「今月もっとも sysloadが高かった日」をmonthlyで集計し、MySQLに保存 daily で API サーバ叩いてsysload取れるなら 40
  41. 41. Copyright © GREE, Inc. All Rights Reserved. ● 何が嬉しいかというと、次のようなときに役に立つわけです ● 例: ● ゲームでプロモーションを開始したとき、次回のイベント時にどれくらいサーバの負荷が増加 しそうなのか、過去のイベント時のデータを使って試算できる。 ● アプリケーションの不具合等で高負荷になってしまい、一時的にサーバの増設をした後、適 正台数に戻したくなったとき。過去の実績など見て、徐々に安全にサーバの台数を削減する ことができる。 sysload でサーバの負荷を集計できると 41
  42. 42. Copyright © GREE, Inc. All Rights Reserved. ● サーバやインスタンスの台数は、サービスのコストに直結するので、可能 な範囲で調整したいというのが、運営する側の気持ちだと思います。 ● しかし、台数を削減しすぎて過負荷になり、障害に直結してしまった場合、 お客様は一方的に不利益を被ることになります。 ● そうならないよう、「これ以上減らすことは危険である」といった共通認識 を、組織内で持てるようにするための指標値は、必ずあった方が良いので す。 ● 新しい世代のサーバやインスタンスに移設するとき、性能が向上している と、ある程度は台数の削減が見込めます。ただ、そういったときに減らしす ぎないよう、なんらかの指標値はあるべきなのです。 サーバの台数を無理に減らさないこと、超重要 42
  43. 43. Copyright © GREE, Inc. All Rights Reserved. さて 43
  44. 44. Copyright © GREE, Inc. All Rights Reserved. 当時、 monitoring system 自作したのは何故か44
  45. 45. Copyright © GREE, Inc. All Rights Reserved. ● 入門監視では、監視は自作するより、監視のSaaSが推奨されてます。わ たしも、現代において監視のSaaSは有力な選択肢だと思います。 ● ただ、当時は数千台以上のサーバのmetricを15秒単位で保存できる手 段は、自分でなんとかするしかなかったので、自分で作りました。 スケーラビリティとmetricの精度 45
  46. 46. Copyright © GREE, Inc. All Rights Reserved. ● ざっくりいうと、数年前まで、ハードウェアの性能と、ミドルウェアのCPUス ケーラビリティが足りませんでした。よって、(監視対象となる)サーバを、増 やさざるを得ませんでした。 ● (極めて個人的な見解ですが)数年前と現代を比べて最大のブレークス ルーは、やはりNAND Flashだったかと思います。 ● 2010年あたりの15krpmのSAS HDDは、容量がとても少なかったので、大量のデータ を保存するためには、数を並べるしかありませんでした。また、SAS HDDは消費電力が 高かったので、数を並べるとそれだけで電力を食いました。 ● SSDの普及によって、サーバ1台あたりで扱えるデータが増大し、MySQL なども、たくさんのCore使えることが求められました。 ● 現代はハードウェアもミドルウェアも集約度がたいへん向上したので、監視 対象となるサーバの台数を減らせるようになりました。 なぜ当時スケーラビリティが必要だったか 46
  47. 47. Copyright © GREE, Inc. All Rights Reserved. ● サーバの台数が多い場合、例えば、「どのサーバがトリガーになって (MySQLの) too many connections が発生したか」ということを調査 するのが、かなり難しくなります。 ● そういったとき、複数のサーバの metric を高精度で保存し、並べて比較 できるようになると、 too many connections の発生していく様を、時系 列を追って調査することが容易になります。 ● もし、「どれかのサーバがトリガーになって、連鎖反応を起こして複数の サーバで障害が発生しているのだけど、調査するための情報が足りない」 と感じているならば、 metric の精度を上げるのは、良い対策だと思いま す。 なぜmetricの精度が必要だったか 47
  48. 48. Copyright © GREE, Inc. All Rights Reserved. 仮に、今ならば SaaSで 置き換えられるの か? 48
  49. 49. Copyright © GREE, Inc. All Rights Reserved. ● かつて「gangliaで使ってるサーバの台数多すぎない?」と言われたことが あったので、以前、若者が試算してくれたことがあったのですが。 ● 一般的な監視のSaaSと比べてコストが1/4程度だったので、オンプレの監 視においては、未だに ganglia ベースのものが使われています。 ● 「AWS向けの monitoring は ganglia ではない方が相性が良い」という ことで、 AWS向けのものは、若者たちがGrafana+Prometheusベース で新しいものを作ってくれましたが、監視対象のインスタンス上で metric を収集するのには、未だ、 ganglia の agent が一部用いられてたりして います。 コスト面で厳しい 49
  50. 50. Copyright © GREE, Inc. All Rights Reserved. 2010年ごろから 長く使い続けて、 見えてくるもの 50
  51. 51. Copyright © GREE, Inc. All Rights Reserved. ● 新しい世代のサーバやインスタンスを使おうとすると、具体的に言うと、新 しい世代のCPUを使おうとすると、新しい kernel に対応しているOSに移 行していく必要が発生します。 ● (個人的な感想ですが)最近の kernel は、 TCP の再送を最適化するべ く、TCP周りの修正がかなり入っています。 ● そういった kernel patch は、大手クラウド事業者から提供されているものだったりする ので、そういった大規模環境で実績がある最適化なのですが。 ● わかりやすいところだと、 kernel 3.1 のときにRTOが1秒になったので、 この頃から /proc/net/netstat の TCPTimeouts の増え方がかなり変 わってると思います。 OSが新しくなると、 metric の意味が変わる 51
  52. 52. Copyright © GREE, Inc. All Rights Reserved. ● 入門監視8章の訳注でも取り上げられた MemAvailable、 kernel 3.14 で merge されたみたい ですが ● このあたりの解釈も踏まえると、メモリの監視って、 kernel を新しくすると きに再考する必要も出てくるのかな、と感じたりします ● かつてわたしは、/proc/meminfo を参照して、次のような式でメモリの使 用量をグラフに書いてました ● メモリ使用量 = MemTotal - MemFree - Buffers - Cached ● 最近の kernel でこの式がベストかというと微妙ですが、いろいろ考えて、 現状このままで良いかなと思いました。 /proc/meminfo の MemAvailable など 52
  53. 53. Copyright © GREE, Inc. All Rights Reserved. ● わたしがメモリの使用量を知りたい理由は、だいたい次の2つです a. メモリリークが発生しているかどうか b. malloc(2) が失敗する状態かどうか ● これら2つを知るためには、MemAvailable を厳格に解釈する必要はな く、先ほどのメモリ使用量を求める式と、 /proc/meminfo の MemFree があれば、だいたい要件を満たせるわけです。 page cache を破棄すれ ばメモリ空けられるとしても、page cache 破棄するのはそれなりにコスト が高いこともありますし。 ● kernel が新しくなって、以前と metric の意味や定義が変わることはあり ます。でも、その都度、本当に求められている情報について再考して、変化 を受け入れていけば良いわけです。 本当に知りたい情報を考える 53
  54. 54. Copyright © GREE, Inc. All Rights Reserved. ● 話は変わって ● 一部のサービスをパブリッククラウドに移行したとき、アプリケーションサー バでTCP timeout が一気に増えたことがあった ● しょうがないので、tcpdump とって kernel のソースコード読んだ ● おおむねわかった ● なので、kernel 3.13で引用しつつ解説 環境が変わると metric の意味が変わる 54
  55. 55. Copyright © GREE, Inc. All Rights Reserved. ● 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
  56. 56. Copyright © GREE, Inc. All Rights Reserved. ● 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
  57. 57. Copyright © GREE, Inc. All Rights Reserved. ● (だいぶ前ですが)kernel 2.6.37 で TCPTimeWaitOverflow が、 kernel 3.15 で TCPSynRetrans が追加されました。 ● もしいま取得していないのであれば、これらの metric は取得するようにし ても良いのではないかと思います。 ● 例えば、オンプレミス環境からパブリッククラウドに移行する際、最も気にな る要素の一つは、どれだけパケットの再送が発生するかとか、ネットワーク の品質かと思います。 TCPSynRetrans はそういったものを推し量る尺 度の一つとなり得ます。 ● 最近の kernel は TCP の再送周りの最適化がかなり進んでいるので、 RetransSegsだけでなく、TCPSynRetransなども併せて見たほうが、よ り効果的ではないかと思います。 環境が変わると、取得すべきmetricが増える 57
  58. 58. Copyright © GREE, Inc. All Rights Reserved. という具合に、 monitoring し続けて、 変化し続ける環境を見ていると、 多くの学びがあります。 58
  59. 59. Copyright © GREE, Inc. All Rights Reserved. 継続的な monitoringは 59
  60. 60. Copyright © GREE, Inc. All Rights Reserved. エンジニアに とって 学びの機会 60
  61. 61. Copyright © GREE, Inc. All Rights Reserved. ● 環境が変わったり、ミドルウェアのバージョンを上げたりすると、metric に 変化が現れることがある。 ● そういった機会を逃さずにちゃんと調べると、様々な学びがある ● そのためにはまず、自分たちの環境を細かく monitoring して、環境やミ ドルウェアのバージョンを変えたとき、どのような変化が生じるか、見逃さな いようにしたほうが良い。 ● もしなんらかのミドルウェアのスペシャリストであるならば、自分が得意なミ ドルウェアの metric は、注意深く取り続けたほうが、成長の機会は得ら れやすい。 環境、OS、ミドルウェアの変化を見逃さない 61
  62. 62. Copyright © GREE, Inc. All Rights Reserved. そうは 言っても 62
  63. 63. Copyright © GREE, Inc. All Rights Reserved. ganglia 使い始めて そろそろ十年 63
  64. 64. Copyright © GREE, Inc. All Rights Reserved. 長いこと 使いすぎ 64
  65. 65. Copyright © GREE, Inc. All Rights Reserved. 新たな課題 65
  66. 66. Copyright © GREE, Inc. All Rights Reserved. ● 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
  67. 67. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は主に 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
  68. 68. Copyright © GREE, Inc. All Rights Reserved. ● かつては大量のnodeを管理できないといけなかったけど。最近は、サー バ(ないしインスタンス)のスペックや、MySQLなどミドルウェアのCPUス ケーラビリティなど改善してきたので、monitoring system にそこまでの スケーラビリティは求められない。 ● python2.7のサポート期間がとても長かったので、gangliaではLLの EOLについてそれほど考えなくてよかったけど。次はそういったもののEOL を、どう乗り越えて行くのが良いか。 ● 少なくとも、次の環境に、python2系向けに書かれた sysload の python module をそのまま持っていくことはできない。ソースコードでは なく、培ったノウハウを、(その中でも意味のあるものを)、如何に取捨選択 して、次の環境に持っていくか。 数年後の未来に備えて、考えること 68
  69. 69. Copyright © GREE, Inc. All Rights Reserved. おわり

×