sysloadや監視などの話（仮）

sysloadや監視などの話です。

Transcript

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