# 2021年 小満(後) 論文の英文公正、Chaosのツールを使った実験基盤、第8回WSA研など Created: June 6, 2021 11:58 AM Research: transtracer Week: May 24, 2021 → June 6, 2021 最近は、Obsidianでメモをとるようになったので、Notionでリアルタイム編集で継ぎ足していかずに、週末や月曜に記述をまとめるようになってきた。となるとNotionを使うメリットが薄れてきたので、logbookのホスト先は、はてなブログか、Headless CMS + Gatsby JS でもいいかという気になってきた。 # Research 12月末から続けていたジャーナル論文投稿のための実装・実験・執筆が一区切りついた。あとは査読が返却されるのを待つのみ。振り返ってみると、提案手法の実装や論文執筆している時間は、全体としてはわずかだった。実験環境の構築や実験の自動化、既存手法の実装、仮説通りの評価結果に持ち込むための試行錯誤などが作業時間の大半を占めていた。 今後は、次の国際会議の投稿締め切りが7月下旬にやってくるので、それに向かって準備を進めていく。 ## 論文の英文校正 英文校正のために、[ヒューマングローバルコミュニケーションズ（HGC）社（旧名 クディラ）の校正サービス](https://human-gc.jp/rewrite/)を利用した。 周囲の情報系の研究者の方はよくHGCを利用されているらしい。すこし割高だけど、添削までやってくれるので、修正の提案などもやってくれる。納期によって、校正費用がかわらないので、投稿ギリギリになって期日1~2日で校正にだして、費用を上げてしまう罪悪感を感じなくてよいかもしれない。営業日3日で納品となっているけど、交渉して1日とかでもできるらしい。 ## 異常データの自動生成と解析のための実験基盤 研究室で、次の研究のための、実験基盤の構想を話していた。Observabilityの分野では、データを収集して人がそのデータをみるというところまでは発展してきた。その次は、Observabilityに関するデータを機械学習などで解析することにより、より認知負荷の低い情報を人に見せるか、システムを自動制御する方向に向かわせたい。 そのために、手作業によらずに高い時間効率で、解析アルゴリズムの良し悪しを評価するために、実験環境で（異常）データを自動で生成して、その結果を管理するMLOpsのアプローチが必要となる。 異常データを生成するために、計画された異常注入（Failure Injection）が必要となる。そのために、Chaos Engineeringのツールを利用できる。 ![[2021%E5%B9%B4 %E5%B0%8F%E6%BA%80(%E5%BE%8C) %E8%AB%96%E6%96%87%E3%81%AE%E8%8B%B1%E6%96%87%E5%85%AC%E6%AD%A3%E3%80%81Chaos%E3%81%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E5%AE%9F%E9%A8%93%E5%9F%BA%E7%9B%A4%E3%80%81%E7%AC%AC8%E5%9B%9EWSA%E7%A0%94%E3%81%AA%E3%81%A8%E3%82%99/Untitled.png]]%20%E8%AB%96%E6%96%87%E3%81%AE%E8%8B%B1%E6%96%87%E5%85%AC%E6%AD%A3%E3%80%81Chaos%E3%81%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E5%AE%9F%E9%A8%93%E5%9F%BA%E7%9B%A4%E3%80%81%E7%AC%AC8%E5%9B%9EWSA%E7%A0%94%E3%81%AA%E3%81%A8%E3%82%99%209a55c47f61784a1b8d82d4ad18ce19f6/Untitled.png) ![[2021%E5%B9%B4 %E5%B0%8F%E6%BA%80(%E5%BE%8C) %E8%AB%96%E6%96%87%E3%81%AE%E8%8B%B1%E6%96%87%E5%85%AC%E6%AD%A3%E3%80%81Chaos%E3%81%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E5%AE%9F%E9%A8%93%E5%9F%BA%E7%9B%A4%E3%80%81%E7%AC%AC8%E5%9B%9EWSA%E7%A0%94%E3%81%AA%E3%81%A8%E3%82%99/Untitled 1.png]]%20%E8%AB%96%E6%96%87%E3%81%AE%E8%8B%B1%E6%96%87%E5%85%AC%E6%AD%A3%E3%80%81Chaos%E3%81%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E5%AE%9F%E9%A8%93%E5%9F%BA%E7%9B%A4%E3%80%81%E7%AC%AC8%E5%9B%9EWSA%E7%A0%94%E3%81%AA%E3%81%A8%E3%82%99%209a55c47f61784a1b8d82d4ad18ce19f6/Untitled%201.png) ## Chaos Engineeringツールの比較 [Chaos Engineering tools comparison](https://www.gremlin.com/community/tutorials/chaos-engineering-tools-comparison/) GremlinがChaos Engineeringツールの比較記事をだしてくれている。このなかでも、Chaos実験の内容を利用者がカスタマイズできるかつ、ある程度の実験計画ができたり、APIによりデータ解析部分と連携できそうなのが、Litmus ではないかと考えた。 Litmus 2.0（現在β）のリリースには [Litmus Portal](https://docs.litmuschaos.io/docs/portal/) が含まれていて、実験の管理がしやすくなっている。 今は、Litmus 2.0を[Sock Shop](https://github.com/ai4sre/microservices-demo)で動かす準備を進めている。 ## 第8回WebSystemArchitecture研 [第8回WebSystemArchitecture研究会（オンライン） (2021/06/04 11:00〜)](https://wsa.connpass.com/event/207143/) 2017年12月からはじめたWSA研も第8回目の開催となった。参加者のうち、研究者の方のほうが多かったのは珍しい。発表者は8人といつもより少し少なめで、平日開催とのこともあって、会社でミーティングが入ることもあって、こじんまりとした感じになったが、これはこれで参加者同士が密な感じがして、悪くないように感じた。 平日か休日に開催にするかは悩ましいところ。せっかく予定を確保していただいても、会社の用事だと会社を優先せざるをえなくて、議論に参加できないのはよくない気がするので、次回は休日開催にしてみようかな。 招待講演では、システム系トップ会議NSDI'21で発表された早川さんに、NSDIでの発表の概要部分と、採択までの試行錯誤について発表していただいた。何度かのリジェクトを経験しながら、実装と評価のクオリティを徹底させて、新規性以外の部分で、論文としての価値をだされたとのことで、エンジニア出身の研究者にとって、とても励まされるお話だった。 [ネットワークサービスの依存発見に向いた TCP/UDP通信の低負荷なトレース手法 / Low Overhead TCP-UDP Tracing in Kernel](https://speakerdeck.com/yuukit/low-overhead-tcp-udp-tracing-in-kernel) 研究室やら社内では何回か共有していたが、あまり対外的にだしていなかった、eBPFを使ったネットワークトレース手法について発表した。 # Clips ## Hatena-ex会 [インフォーマルな文章を書く楽しさ](https://messagepassing.github.io/015-poems/06-secondlife/) のエントリをきっかけにはてなをここ2,3年くらいにの退職者が集まって、はてな時代の思い出やをみんなで振り返ったり、今の会社の話をしていたりした。オンラインにもかかわらず、3時ぐらいまでしゃべってしまったので、翌日は午前休をとった。論文投稿を終えたところだったので、ちょうどよかった。事前にGoogle Docのページが用意されて、そこに近況やらトピックが書かれると、どんどんみんなで追加コメントを書いていくさまが、ああ、はてなっぽいなと懐かしく思った。 ## アカデミアの専門職 [Nature に筆頭で出して、英国でパーマネントの職も得たけど、やりがいがなくなったので辞めます - biochem_fanのブログ](https://biochem-fan.hatenablog.com/entry/2021/06/04/222044) 著者の方は、自分には新しいことを自分で見つけたいという願望がなく、自分にとって新しいことであれば、それが他人の仕事であっても、同じように興奮できる、と書かれている。そのため、解析の専門家としていろいろな実験家と共同研究すれば、自然と多くのデータ・多くの話題に触れることができ、新鮮で飽きることがない。そうした内発的動機を満たすために、Staff scientistという職種に就かれている。著者の方のこれまでの経験から、ソフトウェアのコモディティ化や専門家の役割の低下、研究で利用するコードのブラックボックス化、OSSの解析ソフトウェアのシェアの低下など、直接論文に記述されないような部分について警鐘を鳴らしている。 つまりは、アカデミアでソフトウェアエンジニアをやりたいが、そのような仕事の価値をあまり認めてもらえないということだと解釈した。自分の分野において、自分の周囲に限っては、ソフトウェアエンジニアが中心で、研究者があまりいないことから、立場を反対にすると、共感できる気がする。商用ソフトウェアの台頭についても、メガクラウドがシェアを独占しつつあるITインフラでも、似たような危機感がある。柏崎先生が昔話をされていた、GoogleやFacebookがそのうち知識を共有しなくなくなるのではという問題意識にも通ずる。[https://www.slideshare.net/reokashiwazaki/20150317-46105189](https://www.slideshare.net/reokashiwazaki/20150317-46105189)