2021年春分(前) AccelTCP論文、ソフトウェア系Podcastいろいろ、喜連川先生最終講

# 2021年/春分(前) AccelTCP論文、ソフトウェア系Podcastいろいろ、喜連川先生最終講義 Created: March 22, 2021 2:11 PM Research: transtracer Tags: connperf, e34fm, fukaborifm, io_uring, misreadingchat, podcast, rebuildfm, tcp Week: March 22, 2021 → March 28, 2021 > 春分（しゅんぶん）とは昼と夜が同じ長さになる日であり、自然をたたえ、生物をいつくしむ日とされています。多くの出会いや別れがあり、新生活の始まりなど変化が多いのもこの時期です。[*https://www.543life.com/season/shunbun*](https://www.543life.com/season/shunbun) # Research ## ジャーナル論文の執筆論文を書きながら、いろいろ調べていると，やっていることがよく似ている論文と製品を発見したので，頭を悩ませていた．手法としての差分はたしかにあるので，それがちゃんと課題に紐づくことを言えればよい．そもそもその既存の手法の実装をしてまた実験しないといけない．それはいいとして，課題の部分は，う〜んって一日頭を悩ませて，昨年のNSDIの論文を眺めていたら，我々の手法にうまくハマるいい感じの課題が提示されていた論文（AcceplTCP）を発見したので，これとその言及部分の引用論文を引用すればいいかとなった． ## AccelTCP Moon, Young, Gyoun and Lee, Seung, Eon and Jamshed, Muhammad Asim and Park, KyoungSoo, AccelTCP: Accelerating Network Applications with Stateful TCP Offloading, NSDI'20 カーネルバイパスやゼロコピーのような多数の最適化をしたとしても，TCP操作のためのプロトコル適合性のオーバーヘッドは、短命の接続では CPU サイクル全体の 60%にもなり、L7 プロキシの性能を 3.2 倍から 6.3 倍にまで低下させる。そこで，Smart NICをTCPのアクセラレータとして利用し，接続のセットアップやティアダウンなどの複雑なTCP操作をNICにオフロードする．ホストスタック側では，アプリケーションとの間でデータを送受信や、輻輳やフロー制御などのコントロールプレーン操作を担う． 1,2章までしか読んでいないのだけど，AccelTCPの設計としては，NICにオフロードする話は昔からあったが，短命接続とL7プロキシのボトルネックを見極めて，TCPのどの処理をオフロードするとよいかがわかったことが貢献にみえる．そして，最近のSmartNICの登場によってそういった細やかな制御ができるようになったのかもしれない．それよりも，自分が注目したのが，2.1節の短命接続のオーバヘッドの話だ．今どきなら，インターネットでもDC内のネットワークでも，永続接続がほとんどじゃないかと思っていた．しかし，実地の調査ベースではないものの，いくつかの状況では，短命接続が支配的なケースもあるとのこと． - アプリケーションのデータが本質的に小さい場合や、散発的に転送される場合 [32, 69]，サーバーのリソースを圧迫する非アクティブな期間が発生する - PHPアプリケーションでは、リソースの不正使用のリスクを回避するために、永続接続はしばしば推奨されない[28] > In general, supporting persistent connections is cumbersome and error-prone because the application not only needs to keep track of connection states, but it also has to periodically check connection timeout and terminate idle connections. ## connperfの改善 ### v0.4.0 [https://github.com/yuuki/connperf/pull/6](https://github.com/yuuki/connperf/pull/6) connperfの永続接続モードでは，コネクションを確立してから，何もメッセージをやりとりしてなかったのだけど，—rate オプションで指定した頻度でメッセージのラウンドトリップをするようにした． ### v0.4.1 [https://github.com/yuuki/connperf/commit/caa68494f39629764b249c7d21ff6ae68bf0fded](https://github.com/yuuki/connperf/commit/caa68494f39629764b249c7d21ff6ae68bf0fded) rate値を増やすと，—durationで指定した時間が経過しても，終了しない現象に気づいた．プロセスの終了条件は2つあって，ひとつはすべての必要なタスクを終えたとき，もうひとつは，—durationで指定した時間が経過したとき．後者の条件で終了しなくなっていた．context.WithTimeoutでcontextをラップしたのちに，`ctx.Done()` で待ち受けていなかったため，errを受け取る用のchannelの受信処理でブロックし続けていた．という初歩的なミスをやっていた． ## 国際会議候補 - CLOUDNET [https://cloudnet2020.ieee-cloudnet.org/](https://cloudnet2020.ieee-cloudnet.org/) - クラウドネットワーク - APSEC [https://formal-analysis.com/apsec/2020/](https://formal-analysis.com/apsec/2020/) - ソフトウェア工学寄り - CORE Rank B ## Instapaperの運用 [[[[以前に書いたように，]] 1000%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E8%B5%B7%E5%8B%95%E5%AE%9F%E9%A8%93%EF%BC%8CeBPF%E3%81%AE%E7%B5%B1%E8%A8%88%E6%83%85%E5%A0%B1%EF%BC%8CCNDO2021]]RSSリーダーからInstapaperにあとで読むエントリを流してるんだけど，やっぱりInstapaperにエントリが溜まってしまう．この日誌にInstapaperで読んだ記事のメモを書いていってるのだけど，それがぜんぜん追いつかない．毎週棚卸しする時間とか決めないといけない気がする． # Clips ## Linuxサーバのリモート開発環境 [リモートの Linux サーバを開発環境にする](https://text.superbrothers.dev/210316-using-a-linux-server-as-a-development-environment/) eBPFとか最近やってる開発はほとんどLinux前提なので，僕もmini PC買って，Linuxサーバの開発環境作ろうかな... Ryzenがいいなと思ってググったら，やっぱりRyzenのmini PCもあるらしい． [https://www.itmedia.co.jp/pcuser/articles/2102/03/news054.html](https://www.itmedia.co.jp/pcuser/articles/2102/03/news054.html) iPadを開発マシンにするやつ教えてもらった． [https://arslan.io/2019/01/07/using-the-ipad-pro-as-my-development-machine/](https://arslan.io/2019/01/07/using-the-ipad-pro-as-my-development-machine/) ## e34.fm [1: Go 1.16 and Generics with tenntenn](https://e34.fm/1/) 先週のSlackのObservability論文は，e34.fmで知って読んでいた．newsは最新の話からなつかしいFlynnの話まで，SRE，インフラの話題が盛りだくさんだった．GoのGenericsはぜんぜんおってなかったので，どういうものかわかってよかった．tenntennさんって博士課程通われていたのか． [[SlackのObservability論文，トップ会議の論文の書き方など]] ## [fukabori.fm](https://fukabori.fm/) 2年前にいくつか聴いて，そのままみてなかったのだけど，最近また聴くようになった． [30. Cloud Native Data Center Networking w/ toby](https://fukabori.fm/episode/30) Cloud Native Data Center Networkingの話．古典的な3層アーキテクチャから．CLOSネットワークまで．CLOSネットワークが1953年の電話交換機の論文が元になっていたとは知らなかった． Clos, Charles (Mar 1953) A study of non-blocking switching networks [44. Spotify型およびゆめみにおける組織モデルの変遷 w/ raykataoka](https://fukabori.fm/episode/44) ゆめみの独自の組織モデルが想像以上に自律分散的でおもしろかった． ## Kubernetes Meetup Tokyo #39 [Kubernetes Meetup Tokyo #39 (2021/02/25 19:00〜)](https://t.co/fL8BYxZKcv?amp=1) ### Wasmで広がるEnvoyとIstioの世界 (30min) - Envoyは静的リンクが前提 C++で書かないといけない全台再起動要 - Envoyの内部APIはstableではない - Istioからの要望．Mixerがメトリックとったり，ポリシーチェック ⇒ MixierをEnvoyへ組み込みたい ### PipeCDでKubernetesのGitOpsについて - Contole Planeと各クラスタにインストールするpipedに分けられている ## BPF meets io_uring [BPF meets io_uring](https://lwn.net/Articles/847951/) - BPF_PROG_TYPE_IOURING - bpf()システムコールで作成し、新しいIORING_ATTACH_BPFコマンドを使用して、実行するリングに登録する - BPFプログラムがリングに新しいオペレーションを送信するために使用できるヘルパー関数 - BPFプログラムを非同期に実行して別の操作を行う価値はほとんどない - BPFが価値を高められるのは、リング上で以前に行われた操作の結果に基づいて決定を下すこと。現状では、これらの判断はユーザースペースで行う必要があり、関連するプロセスがスケジュールされて実行されるまでに遅延が生じる可能性がある。 ## dev random [dev random - Mar. 2021](https://www.youtube.com/watch?v=ysQbzdFPvTM) ryotaraiくんがはじめたゆるい感じのYoutube配信に出演していた． M1 Mac，パスワード管理，Podcastとか，RSSとか，この日誌のこととかについて話をしていた．やや真面目な飲み会ぽいのりで気楽に喋れてよかった．あまり人と話さなくなって，家にテレビもないし，Youtubeもそんなに観るほうではないから，音声を聴く習慣でもいれようかなと思っていれてる． Podcastアプリは，Overviewがよいときいたので，iPhoneにいれてみた．沈黙を認識して，動的に速度調整をしたり，リマスターをやってくれたりする機能があって便利．RebuildやMisreading chatを久々に聴こうと思った．英語のPodcastは気になるけど，僕の英語リスニングスキルだと厳しそう． ## [rebuild.fm](http://rebuild.fm) [Rebuild: 300: Note-Taking Nirvana (omo)](https://rebuild.fm/300/) 雑談ブログちょっとやってみたいかもしれない．はてなグループのような社内ブログツールは，USにはあまりない？らしい．はてなグループが存在する前提で長らく仕事していたことがあったので，あれがないと，文章を書いて共有するコストが高くなって，あんまり文章を書かなくなるんじゃないかという気がする．今の会社では，その手のツールを使うカルチャーがないので，事務的なものか個人メモのようなもの以外の文章をみること自体が稀になっている． [Rebuild: 299: H1 Perfectionist (yuka)](https://rebuild.fm/299/) Notionの話を聴いていた．やっぱり自由度があるから自分でカスタムできるのがよいという話と，会社だと他の人と管理方針があわなくて口論になりそうという話があった． ## misreading chat [#91: Serverless in the Wild](https://misreading.chat/2021/01/26/91-serverless-in-the-wild/) USENIX ATC'20のMicrosoft Researchの論文の話を聴いた．FaaSでずっと起動中の ## 喜連川先生最終講義「40年前に描いたデータ中心の世界が定年時に真っ盛りとなる皮肉」 [http://www.iis.u-tokyo.ac.jp/ja/news/3467/](http://www.iis.u-tokyo.ac.jp/ja/news/3467/) - コンピュータは計算と記憶要は処理（スパコン）と管理（データベース） - VLDB, SIGMOD, IEEE ICDEを毎年目指す - すべて紙査読も手書き感情がこもってる - 最初は論文競争 (Grace Hash Join) ⇒ アウトオブオーダー実行エンジン - DB2で使われるアルゴリズムに - 10年後に採用される - （当時は，DBMSというよりマシンとしての提案なんだな．ディスクコントローラーからつくっていた話） - 敵はVAE 20ノードの豪華マシン ⇒ 100ノードのPCクラスタ．ラックからつくってやってた． - PCクラスタの部屋が人気に．Gim Gray先生が訪れる - パイプラインマージソート: ディスクからデータひいてくるので，O(N)で十分 - ソート世界一 - 20年間やってみて．会社との共同研究．50-100倍の性能向上．従業員がはやくかえるようになった．ITの醍醐味． - LFS RAID．ディスクアレイは日本だとうちしかできない． - トランザクションの投棄実行 - KD Join，DBとプログラミング言語の統合， - 20年後，hash joinなどの研究者がDB分野からいなくなった． - 2000年ごろ，同じゲームを続けるか？採択される論文の書き方はわかる - Jim Gray先生が2回も日本に - トランザクションはあなたのオリジナルか？ - イタリアの研究者がいたようだ - 「それで？」論文のための研究じゃない． - Fourth Paradim 計算からデータの世界へ．支配方程式がない - 時代についていくのに必死だ - DB業界で最高の賞を受賞 - ストレージとサーバのレベニュー比がストレージへ - 超高速ストレージアクセス - クエリプラン先読み - キャッシュサイズは少量でよい ⇒ 10倍まで - 既存のDBMSコードをいじらないのが王道．横っちょでやる． - MS OSのコードはだせるけど，SQLサーバのコードはだせない - 1000倍を狙おう - RDBMSのベース自体をかえる - 非順序実行型 I/Oをすべて非同期に - 合田先生構造劣化自動修復 - 同一ハードウェアで20倍高速 - マルチコア時代のDB実験マシン ⇒ 1000倍 - MySQLとPostgresで実装 - Hadoop 128ノード - ディスクからフラッシュへ ⇒ レイテンシが小さくても，200,300倍 - 新しいアイデアかわからない． ⇒ 非同期回路とか昔からある．特許庁に調べてもらう - 日米で特許登録 - 日立のエンジニアがいきいき．これまでは既存の改良だった． - 楽しい時代だった．論文なんてどうでもいい通らないトップ会議の限界．ちょっと先しか査読者がわからない．マイナーなところにだしてエビデンスをつくる． - 2005年から情報爆発 - データ駆動型のアプリケーションへ地球環境，医療，メディア - 地球観測データ 50PB DIAS - ありとあらゆるリアルタイム観測データをいれる - 洪水予測システム - CPUシリアルで20時間かかる．リアルタイムに予測するために，GPUで20分． - テクノロジーのプラットフォームをどうやって使ってもらうか - マラリア流行予測@南アフリカ - Earth Health Verification Platform 苦節40年 - 論文はなかなかでない - 競争より，多数のオンリーワンの研究をやってきた - cockroachdb GRACE hash joinの実装 2018年 [https://github.com/cockroachdb/cockroach/issues/24582](https://github.com/cockroachdb/cockroach/issues/24582) - 論文生産性 - 基盤技術（OS，Architecture）は絶滅危惧種 - 学術の評価を見直す必要があるのでは - 大規模サイバーシンポジウム - たった2週間でやるのか？ - （NII 柏崎先生？の名前がでてきた） - Fail Fast, Cheap, - 論文にはならない様々な活動 - 残された人生1 大学教員の評価をかえる社会貢献も評価する - 2 データで価値をつくりだす - データ保有は最大のリスク ⇒ データ駆動型アプリケーションが作られくなるなんとかしたい - （Q&Aのなかで）人間と機械のインタラクション人間中心といいつつ，今の世の中になっている人間がmodestになる必要がある． - data citation - 教育のデータへの興味．学びのプロセスがObservableになる．