# 2021年/立春(後) Transtracerの実験自動化 / 科学と技術 Created: February 17, 2021 4:38 PM Research: transtracer Tags: go Week: February 15, 2021 → February 21, 2021 この日誌の更新が滞ってしまった。日単位でページを切ると細切れになりすぎて、あとで見返しづらいと感じたので、毎日少しずつ書いていって、1週間単位で記録してみる。 # Transtracerの研究 ジャーナル化に向けて、年末から手法の改良を進めている。 [yuuki/go-conntracer-bpf](https://github.com/yuuki/go-conntracer-bpf) eBPFを利用して、TCP/UDP接続イベントをカーネル内で集約し、集約されたイベントをユーザランドで受信するためのライブラリとして実装しつつある。だいたい動くようになったので、あとは評価実験の準備を進めている。tools以下にconntopというCLIを用意していて、基本的にはconntopを叩いて、動作を確認している。 [Low-level advice for systems research](https://lalith.in/2020/09/27/Low-Level-Advice-For-Systems-Research/) 昨年のACM/IFIP Middleware'20のDoctorialセッションの講演をみてから、テストや実験インフラストラクチャの自動化をちゃんとやろうと思うようになった。`Automate your experiments like a maniac` と書かれていて、Gitのコミットごとに各環境のメタデータを収集しつつ、実験が自動で実行され、結果のレポートが保存される話があった。ここまでやるのかとさえ思うほど、実験が自動化されている。 実験用の負荷環境を作成するために、connperfと呼んでいる負荷生成ツールを作った。パラメータ、具体的にはconnections per secを思い通りにする。wrk + nginxでKeepalive offにすればrequests per secは理屈上connections per secと同じになるはずなのだが、うまくできなかった。 [yuuki/connperf](https://github.com/yuuki/connperf) さらに、トレースの負荷を実験するには、2つのVM間で、connperfを指定したパラメータで起動しつつ、トレースプログラムを走らせて、トレースプログラムのCPU負荷を計測しないといけない。パラメータはそれなりにあるのと、プログラムを変更したときや実験のミスが発覚したときに、また再実験しないといけないので、一回コマンドを打ったら、全ての操作を自動で実行できるようにしておきたい。 そこで、次のshawk-experimentsに自動化のためのコードをまとめている。 [yuuki/shawk-experiments](https://github.com/yuuki/shawk-experiments) マイクロベンチマークはどうしようかな。BPFのレイテンシは計測できそうだけど、CPU負荷がなぜ削減したかを直接計測するのはすこし難しいかも知れない。カーネル・ユーザ間のイベント転送部分だけのCPU負荷を計測するなんてできるのだろうか。そこのイベント転送数の変化とCPU負荷の変化が対応していることを示せばいいかな。 興がのってしまって、もともと考えていたジャーナル提出の予定を大幅に超過しているので、そろそろ論文の修正に入りたい。 # 思索コーナー ### 科学と技術、そしてエンジニアリング 博士課程に入る前あたりから、科学と技術は、何が違うのだろうかを考えている。中谷宇吉郎著「科学の方法」を読んだりして、すっきりした考えに帰着した。 **科学は「知」を生産し、技術（Technology）は「モノ」を生産する。「知」の中には、「モノ」の作り方の「知」もある。各生産物の利用者は、科学に対しては知を得られ、技術に対しては作り方の知を知らなくても、技術を利用できる。**工学分野は、「モノ」を生産することと、科学と技術が非常に近く、「モノ」の作り方の「知」を探求する。実際に作れることを示さないと、本当に作れるのかがわからないので、プロトタイプを開発するか、企業の実践の場で開発して、評価する。 Engineeringは、辞書上は工学を指すが、科学の一分野のことを指して、Engineeringと呼ばれることはあまりない。Engineeringは、技術（Technology）を生産に至るまでの直接のプロセスの全てをさして、Engineeringと呼ばれているのではないか。Engineeringの接尾辞が-ingであることは、プロセスを連想させる。 Engineeringを遂行する上で、「モノ」の作り方の「知」も必要である。また、人間が「モノ」を作ることから、人間が訓練によって獲得するTechniqueも必要になってくる。Techniqueも、Technology同様に、日本語で技術と訳されるので、TechnologyとTechniqueは混同されやすい。TechnologyはTechniqueを以て、生産されるが、TechnologyがTechniqueを置き換えることもある。 ちなみに、ルネッサンス期などの職人の時代では、Technologyというよりは、技芸（Art、Technique）であったのではないか。 科学と似たような用語に、学術や学問がある。自然科学や工学では、ほぼ同じ意味で使われている。その一方で、科学は、文学や社会学など一部の文化系学問分野を含まないことがある。 # 徒然コーナー ## 分散システムに対する誤謬 [Fallacies of Distributed Computing Explained](https://u.cs.biu.ac.il/~ariel/download/ds590/resources/misc/fallacies.pdf) という06年のホワイトペーパーがある．この出典をよく忘れてしまうので，覚えておく． 1. The network is reliable. 2. Latency is zero 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero 8. The network is homogeneous. ## 複雑適応系とネットワーク ネットワークを複雑適応系としてみなす話．4年前ぐらいに，分散システムを一般システム理論で捉える妄想をしていたことがあって，あまり日本語でそういう話はみかけないので興味深い． [ネットワーク・エンジニアリングから学ぶこと − システム理論の見地から - Qiita](https://qiita.com/mkohno/items/0c02ef8f76415208bd4e) [システム理論の続き - 宣言的ネットワーキング - Qiita](https://qiita.com/mkohno/items/ac83cf461632fbf4d862) ## Go 1.16 Go 1.16のリリース 🎉 [The Go Blog](https://blog.golang.org/go1.6) すぐ使いそうなのは、go:embedとsignal.NotifyContext。 ## Fireworq はてなのitchynyさんのツイートをみて、6〜7年前に設計したFireworqというジョブキューシステムを振り返っていた。はてなの合宿で4人がかりで作ったシステム。 [https://twitter.com/itchyny/status/1361320416652914690](https://twitter.com/itchyny/status/1361320416652914690) GitHub Starが2k超えになっていた。OSS化にはあまり僕は貢献していない。はてなのtaraoさんががんばっていた。ジョブキューはなんとなくひと目につきやすいイメージがある。 [fireworq/fireworq](https://github.com/fireworq/fireworq) [https://twitter.com/yuuk1t/status/1361330067700256769](https://twitter.com/yuuk1t/status/1361330067700256769) 今は、フルスクラッチされたはてなブックマークで利用されている。[https://speakerdeck.com/tarao/10nian-dedoubian-watuta-hatenabutukumakudefalseperlfalseshi-ifang?slide=16](https://speakerdeck.com/tarao/10nian-dedoubian-watuta-hatenabutukumakudefalseperlfalseshi-ifang?slide=16) サイボウズの人（自作OSで著名）がプロトタイプに採用したとのこと。 [https://twitter.com/uchan_nos/status/1053066484119793664](https://twitter.com/uchan_nos/status/1053066484119793664) Fireworqにインスパイアされて、ジョブキューを実装された方もいる。 [Goでジョブキューを実装した - オープンソースこねこね](https://kohkimakimoto.hatenablog.com/entry/2020/01/05/150907) はてなと同じようにPerl製ジョブキューを置換するためにFireworqを採用された方もいる。 [打倒qudo with fireworq - Qiita](https://qiita.com/stk0724/items/269328262d5a1f0eaa28) [fireworqのキュー設定、ルーティング設定の保存、適用CLIを書いた - DevDevデブ!!](https://stk132.hatenablog.com/entry/2021/02/06/114647) ### エッジ [https://twitter.com/two2mi/status/1362024607373385729](https://twitter.com/two2mi/status/1362024607373385729) ## Rust [https://twitter.com/yuuk1t/status/1360482285850533890](https://twitter.com/yuuk1t/status/1360482285850533890) ## TUI grep [https://twitter.com/yuuk1t/status/1361856682607800320](https://twitter.com/yuuk1t/status/1361856682607800320) エッジコンピューティングはまだ現実の基盤やアプリがあまりないこともあって、問題設定が難しく、2年前に検討を進めてから、一旦白紙にしている。 それでも、たまにこういう反応をいただくと、励みになる。 AWSのWavelengthを検証されているとのこと。