2021年啓蟄(後) SlackのObservability論文，トップ会議の論文の書き方など

# 2021年/啓蟄(後) SlackのObservability論文，トップ会議の論文の書き方など Created: March 16, 2021 10:43 AM Research: heterotsdb, transtracer Tags: SRE, heterotsdb, kernelvm, observability, paper, verdafm Week: March 15, 2021 → March 21, 2021 # Research ## ジャーナル論文の執筆今週は，シャローワークが多めで，執筆の進みが少し悪かった．初稿がだいたいできたので，セルフレビューしつつ，手直しをいれている．せっかくなので，やはり英文で書くことにした．後ろの国際会議の締め切りをあまり気にせずじっくりやっていこうという気持ちになってきた． ![[SlackのObservability論文]] ## BPF Performance Tools輪読会 6.2.2 HardwareStatisticsの続きから． perf listでPMCを一覧できる． perf statは-eでイベント指定，-aですべてのCPUコア，-Iでインターバル指定(ms) `perf stat -e mem_load_retired.l3_hit -e mem_load_retired.l3_miss -a -I 1000` （手元環境だと `perf stat -e mem_load_uops_retired.l3_hit -e mem_load_uops_retired.l3_miss -a -I 1000` ） PMCはたくさんあって[Intel 16] [AMD 10] などのベンダーガイドラインに書いてある． PMCとMSR（Model Specific Registers）を併用することで、CPUの内部コンポーネントの性能、CPUの現在のクロックレート、温度やエネルギー消費量、CPUのインターコネクトやメモリバスのスループットなどを把握できる． tlbstat [https://github.com/brendangregg/pmc-cloud-tools/blob/master/tlbstat](https://github.com/brendangregg/pmc-cloud-tools/blob/master/tlbstat) Meltdown回避のための[Linuxカーネルページテーブルアイソレーション（KPTI，ユーザー空間とカーネル空間のページテーブルを完全に分離）](https://en.wikipedia.org/wiki/Kernel_page-table_isolation)パッチの影響調査が目的．（以下のブログに詳細がある） [KPTI/KAISER Meltdown Initial Performance Regressions](http://www.brendangregg.com/blog/2018-02-09/kpti-kaiser-meltdown-performance.html) KPTIのオーバヘッドは5つの要素がある．KPTIは，ユーザ空間とカーネル空間で，別々のページテーブルを利用するため，システムコールで空間が切り変わったときに，TLBのフラッシュが入る． - システムコールレート - Netflixの多くのサービスはCPUあたり1万システムコール/秒未満であるため、このタイプのオーバーヘッドは無視できると予想される（<0.5％） - `perf stat -e raw_syscalls:sys_enter -a -I 1000` でシステムコール率を計測可能．ftrace/mcountでより低オーバヘッド - コンテキストスイッチ - sar -wb 1で計測 - ページフォールト率 - ワーキングセットサイズ - 10 Mバイトを超えると、TLBフラッシュのために追加のオーバーヘッドが発生．[Linux 4.14のPCID](https://kernelnewbies.org/Linux_4.14#Longer-lived_TLB_Entries_with_PCID)でオーバヘッドを低減可能． - キャッシュアクセスパターン tlbstatの中身はperf statでtlb関連のPMCを出力して整形しているだけ． `perf stat -e cycles -e cycles -e dtlb_load_misses.miss_causes_a_walk -e dtlb_store_misses.miss_causes_a_walk -e itlb_misses.miss_causes_a_walk -e dtlb_load_misses.walk_active -e dtlb_store_misses.walk_active -e itlb_misses.walk_active -e instructions` DTLB（全サイクルのうちData TLBがアクティブなサイクルの割合） 27%，ITLB（Instruction TLBの割合）22%の例は，KPTIのオーバヘッドがもっともひどいケース． CPUリソースの半分が仮想アドレスから物理アドレスへの変換処理を行うメモリ管理ユニットによって消費された． 6.2.3 HardwareSampling perlは-cで指定したカウント数ごとに1度イベントの状態をキャプチャできる． PMCのハードウェアサンプリングは、BPFプログラムのトリガーになる．例えば、BPFは、サンプリングされた全てのスタックトレースをPerfバッファ経由でユーザ空間にダンプする代わりに、カーネルコンテキスト内でそれらを周波数カウントし、効率を向上できる 6.2.4 TimedSampling perfはCPUの周波数ベースのサンプリングもサポートしている． FrameGraphは，上辺の最も長い幅の部分がボトルネック． [https://github.com/Netflix/flamescope](https://github.com/Netflix/flamescope) # Clips ## 情報処理学会論文誌ジャーナルへの出版 [https://twitter.com/yuuk1t/status/1372029854263115785](https://twitter.com/yuuk1t/status/1372029854263115785) はてな時代の2016年の秋ぐらいからの取り組みが僕の中で一つの形をもって区切りを迎えた．学術雑誌に掲載されるので，一応は学術的貢献を認められたということになる．論文として高い新規性があるわけではないし，すごいカンファレンス・ジャーナルに通ったとかでもないけど，これぐらいでも学術的貢献は認められるという例になったと思う．情報処理学会のジャーナルでは，既存研究との差分は，明確に示さないとはいけないものの，小さくて良いことになっている．下の"論文必勝法"のところに書いているような，1+1=2（ただし自明ではない）でも小さな改善を積み上げるでもたぶんよいはず． [https://yuuk.io/papers/2021/heterotsdb_ipsj_journal.pdf](https://yuuk.io/papers/2021/heterotsdb_ipsj_journal.pdf) ## 第8回ウェブシステムアーキテクチャ研究会 [第8回WebSystemArchitecture研究会（オンライン） (2021/06/04 10:00〜)](https://wsa.connpass.com/event/207143/) - 今回から座長枠，共同研究・開発者枠を追加してみた． - すでに発表者枠は8/10で好調．connpassかつオンラインにしてから発表者をがんばって集めなくて良くなった．第8回と直接関係ないけど，wsaのSlackワークスペースで雑談するためのwsa cafeとかやりたい気もする． cafeのコンテンツはとりあえず，このlogbookを振り返るとかかな． ## システム系の代表的国際会議 [https://twitter.com/mumumu_vm/status/1348876547361423363?s=21](https://twitter.com/mumumu_vm/status/1348876547361423363?s=21) ASPLOS, PLDI, POPL → プログラミング言語処理系 EuroSys, USENIX ATC → システム系全般 FAST, VLDB → ストレージ，データベース HPCA → HPC ISCA,MICRO → コンピュータアーキテクチャ系 NSDI → ネットワークシステム OSDI, SOSP → OS系 SIGCOMM → ネットワーク，インターネット SIGMETRICS → システム性能解析 SIGMOD → データベース，データ処理 USENIX Security, S&P, → セキュリティ ## SREのプラクティスの適用性 [https://twitter.com/yuuk1t/status/1372635491535757313](https://twitter.com/yuuk1t/status/1372635491535757313) SREのプラクティスの他分野への適用性についてはたまに考える．この説明だとまだ抽象度が高すぎるかもしれない．失敗の概念を盛り込む必要がある．SREの場合，説明変数が100%に近づくと，目的変数が減少する理由は，失敗を避けようとする力が働いているからだ．この文脈では，DMMのy_matsuwitterさんの記事が興味深い． [3-4 失敗予算ソフトウェアと経営｜Matsumoto Yuki｜note](https://note.com/y_matsuwitter/n/nfa3b6d7fdc52) ## SREとObservability [https://twitter.com/yuuk1t/status/1372673455380787202](https://twitter.com/yuuk1t/status/1372673455380787202) モニタリング，Observabilityを単なる備えとするより，守りから攻めに転ずることができる技術と捉えるのが好き．その観点では，例えば，ディザスタリカバリは災害に対する備えでしかなくて，災害時にこそ有用なシステム以外は，費用対効果を見出しづらいのではないか．災害に対する事業継続性を高めるなら，データセンターの心配をするより，社員の大半が東京に住んでいることのほうがリスクが大きい可能性もあるので，ボトルネックがどこにあるかを見極めないといけない． ## Verda FM Verda FMというPodcastを発見したので，聴いてみた． [https://www.verda.fm/episode/2](https://www.verda.fm/episode/2) Verdaには前から興味があったので，楽しく聴いていた． ## ArgoCD+Litmus Chaosの事例 [KubeCon＋CloudNativeCon NA 2020 IntuitとMayaDataによるカオスエンジニアリングのセッション](https://thinkit.co.jp/article/18178) - Kubernetesに特化したカオスエンジニアリングがあるべき - 障害パターンを実行するためのワークフローとして、手続き型言語などを使わずにArgoCDを使うという発想 - ChaosHubはユーザーやベンダーが再利用可能な障害パターンを格納するハブ - Bring your own Chaos: SDKを使って障害パターンを自作できる機能 - k8sそのものに故障注入できるわけではない - ソフトウェアやプラットフォームを壊すだけなら度胸さえあればだれでも簡単にできる。問題は、もしも元に戻らなかった時にそれを復旧することが難しいことだ。本番環境ならなおさらだし、そのためにはログやモニタリングツールが重要になる - [https://github.com/litmuschaos/litmus/tree/master/demo/kubecon-demo/2020-NA](https://github.com/litmuschaos/litmus/tree/master/demo/kubecon-demo/2020-NA) ## 論文必勝法 [情報処理学会第83回全国大会](https://www.gakkai-web.net/ipsj/83/event/html/event/B-9.html) 基調講演で，トップ会議では，やはり高い新規性（技術の深み）と完全性が要求されるという話があった．すぐ思いつくアイデア，1+1=2や小さな改善を数個積み上げるような研究では難しいとのこと．これまで自分がやってきたようなことはすべて後者なので，なにがどうなったらそんなアイデアを実践できるのかと疑問に思う．クラウドの分野では，トップ会議レベルのあっと驚くようなアイデアは，GoogleやAmazon以外では実現が難しいように思う．費用対効果を考えると，これまで読んできたトップ会議の論文の中で，そのまま実装して現場に適用しようと思えるものは，なかなかない．しっかりメンテされたOSSになるか，クラウドのマネージド・サービスとして提供されないと実際に使うまでにはなかなか行き着かない．国内のサービス事業者目線で，実課題をもとに研究しようとすると，むしろ1+1とか小さな改善をつみあげるほうがむしろ問題を適切なサイズで解決できることもある．トップ会議に通すことだけが研究ではないはずなので，自分が解決したい課題に注力していければいいかなと思う．新規性が小さいならその分，ちゃんと使えるソフトウェアとして形（OSSなど）にしていきたい．そう思いながらも，新規性の高いアイデアの素も頭の中にはなくはないので，一度くらいはいつか通したいという気持ちもある． ## distributedとdecentralized どちらも日本語では分散と訳されることがある．分散と言ったときに，どちらを指しているかを区別しないといけない．decentralizedは，非中央集権を意味する． [What is the difference between decentralized and distributed systems?](https://medium.com/distributed-economy/what-is-the-difference-between-decentralized-and-distributed-systems-f4190a5c6462) この記事によると，"A decentralized system is a subset of a distributed system." とされている． distributedは，処理が複数のノードにまたがって共有されるものの，”decision"はまだ中央化されている状態も含む．decentralizedはすべてのノードが自身の振る舞いを”decision”する状態． > **Decentralized** means that there is no single point where the decision is made. Every node makes a decision for it’s own behaviour and the resulting system behaviour is the aggregate response. > **Distributed** means that the processing is shared across multiple nodes, but the decisions may still be centralized and use complete system knowledge. ## Kernel/VM探検隊 [Kernel/VM探検隊online part2 (2021/03/20 13:30〜)](https://connpass.com/event/201059/) 自作QEMU，Intel MPK，WebAssemblyの話がおもしろかった． [Rustで作るフルスクラッチQEMU型エミュレータ](https://speakerdeck.com/msyksphinz/rustdezuo-ruhurusukuratutiqemuxing-emiyureta) QEMUをそもそもあまりよくわかってなかった．命令セットエミュレータの一種．複数のアーキテクチャ（x86とかARMとか）に対応する． - ゲストアーキテクチャとホストアーキテクチャの中間に中間言語をもつ． - エミュレーション方式には，インタプリタ型（逐次解釈）とバイナリ変換型（ホスト命令に変換）があって，QEMUは後者． [Intel MPKについて](https://docs.google.com/presentation/d/1JrejoTdEAlbyZuDTBPmPnQ77g0G-7yz7t6_Hp-r0LiU/edit#slide=id.p) Intel MKの話．そもそもmprotectすら知らなかった． [WebAssemblyのWeb以外のことぜんぶ話す](https://www.slideshare.net/TakayaSaeki/webassemblyweb-244794176) Web外WASM - Wasmer - Envoy - Krustlet k8s上でwsamコンテナ実現 - Kernel-wasm - Nabulet WASMの夢複合 - portable execute（JVM） - common language bytecode VM - NaCI/ eBPF secure/isolated sandbox - Lua embeddable runtime WASM特徴 - 安全，言語非依存，ポータブル，オープン - 安全 - ホストランタイムから隔離された単一メモリ空間 - システムコールとか呼べない - gotoとかない - オープン - オブジェクトファイルフォーマットの仕様も含む - ホストにImport/Exportする関数/変数の定義がある - Luaが活躍しているフィールド WASMがなにができるかは外のインターフェイスで決まる