Builderscon Tokyo 2019
参加した理由
YAPC:Asiaに行って以来行けてなかったので、東京に来たら行こうと思っていた
面白かったセッション
CyberAgentで運用しているOpenStackで構築されるプライベートクラウドについて
CAさんは、新たなデータセンターを作る度に、新しいOpenStackクラスタを構築してプライベートクラウドとして提供しているらしい
CAさんで面白いのは、社内ではパブリッククラウドとプライベートクラウドの両方を開発者は使用することが出来て、使い勝手が良い方や、安い方が使われる
プライベートクラウドとパブリッククラウドで競争しているのが良い
このセッションでは新しく作られたOpenStackクラスタであるTKY02というプライベートクラウドについての紹介をしている
このOpenStackクラスタはk8sを用いてコンポーネントが管理されている
OpenStackの1つ1つのコンポーネントはマイクロサービスとして構築されているので、k8sでホストするのに向いてるらしい
現在、ハイパーバイザーは150台程度稼働しているらしい
CAはこのプライベートクラウドの構築にディスクレスハイパーバイザーを用いている
ディスクレスハイパーバイザーを用いることで故障率の低下などを目的としている
ディスクレスハイパーバイザーなので、起動する時にPXEブートでOSを起動する
そして、起動したら、kexecを用いてコンポーネントが動作するカーネルに切り替えて、自信はk8sに登録して、稼働する
これにより、使われてないハイパーバイザーの電源を落として管理することが出来る
また、ディスクレスなので、ラックの集積度などを上げれる
仮想マシンのストレージにストレージアプライアンスを買って、iSCSIで接続している
また、同様にストレージレスで動いているシステムとしてディスクレスで動作しているロードバランサ用のnginxクラスタもあるらしい
Intelの拡張命令でAESチップなどが入っているので、専用のLBアプライアンスなどと最近は普通のサーバでも同等のサーバが出るらしい
ディスクレスなので、サーバをリブートすれば、設定を綺麗さっぱりなかった事が出来るらしい
kimitoboku.icon OpenStackの構成として面白い、ディスクへのアクセス性能が必要な場合には、専用のフレーバーも提供して居るらしい
スーパーカミオカンデで運用している事について
物理の話はちょっとちゃんと覚えてないので割愛
"宇宙からの来る敵" (データをとるさいに邪魔になるやつ)というワードがかっこよかった
チェレンコフ光をゴジラ以外で久々に聞いた
毎秒50MB程度のデータが流れてくるので、それを処理してデータとして処理すべき物を判断して保存する必要がある
しかも、データには結構なノイズが載ってるので除外しないといけない
このために、専用のボードを作って、データの受信から後ろのサーバに送信までやってる
Linuxも動くボードだったらしいが、Linuxは遅かったので、データ送信のためにSiTCPというFPGAでTCP/IPを喋ってデータを送ったりしてるらしい
最近超新星爆発しそうな天体があって、それが来ると、 8 event / dayで今動いているシステムに10M event / secくらいで突撃してくるらしいので、システムを頑張らないといけない
光が到達するよりも先に観測出来るから、観測したら、世界中の天体望遠鏡をそっちに向けられるようになるから、もう、SLA100%で頑張る
kimitoboku.icon ASIC作ったり、FPGAでがりがりしたり、性能要求が凄かったり、別世界の話っぽくて良い買った
kimitoboku.icon CERNのROOTはCERN以外でも使われてるらしいことが分かった。
OpenLDAPの作者のsymasさんの話が聞けただけで貴重
クヌースの最適化するなを受け止めすぎてる
最適化で大事なのは3%程度だったというのが大事な所
まず正しく動くのが大事
しかし、OpenLADPでは99%の部分が最適化が必要だった
パフォーマンスのゴールを決めるのが大事
コードのプロファイリングをしなければ、遅いかどうかも分からない
Linuxだとperfが良いよ
Valgrind callgrindがコードの関係を見れるけど、めちゃくちゃ遅いよ
なので、最初はperfを使うべきである
perfは早くて使いやすいが、完全ではないので、複数のツールを使うことが大事
'Don't Repeat Yourself' <- 同じコードを書くな
実行時でもにたようなもんで、同じデータを何回も計算しない
OpenLADPのオペレーションでは文字列処理を繰り返してる
文字列の長さを得るなどは、よく使うが何度も計算する必要ない
strcat()も遅い
毎回最初の部分から遠い所に行かなければならない。
結合をするたびにどんどん遅くなっていく
モダンなC言語ではstecpyがある
処理時間で文字列処理の次に長いのがmalloc
mallocライブラリをまずは置き換えるということを考える
それでは10%程度の改善に止まる
それ以上はメモリの使われ方を正しく考える必要がある
結果をmallocして返すのではなく、既に確保されている物を、参照渡しなどすれば、mallocしなくてすむ
OpenLADPではLDAPのリクエストをソケットで処理する
リクエストの度にmallocするのではなく、プールを確保しておいて、それらを処理する
これらのアロケーションを減らすことで、mallocの処理時間をTop 100からも外すことが出来た
メモリリークを確認するツールとかも用意した
github.com/hyc/mleak
Threadの生成にもコストがかかる
Thread Poolを使う
これによりさらに15%の改善が図れた
Debugの関数がコードの中にばらばらに存在することで、実はコストがかかっていた
DEBUGマクロを作成して、コンパイル時に動作しないようにした
これでも、5%改善した
LADPのSearch Requestでは14もパラメータがあった
これはコールスタックに積み上げるため、呼び出し時間が遅くなる
関数で10もパラメータがある場合は何かおかしいことがあるだろうと言われている
データストラークチャを定義する時に、オーダーに注意する必要がある
不必要なパディングを減らす必要がある
アライメント整合性がとれるようにパディングする
mutexがスタックされている時にはプロセスが止まっている
このmutexで止まっている間の時間はプロファイルに出てこない
mutraceでmutexのブロック時間を見る
ボトルネックを解消すると別のボトルネックが出てくるので、対処した記録を付けるのが大事
まとめ
コードは最初から可能な限り正しくする
コードの高速化は反復的な努力
時には0からスタートする勇気も必要
本当に自分が必要としているだけの効率を求めるだけ
"Don't Repleat Yourself"
kimitoboku.icon 最適化の前にまず計測!というのはやっぱり正しい
kimitoboku.icon最適化するなというのを過剰に信じずに、最適化が必要な事はあるし、目標が必要
Builderscon楽しかった
懇親会の後に川に向かうやつは、KMCとの謎の文化融合を果たしてる感があった