さくらインターネット研究所の坪内（@yuuk1t）です。

昨年末に、個人ブログで公開したLinux eBPFトレーシング技術を体系化して整理した記事を、研究成果の一環として紹介します。

Linux eBPFトレーシング技術の概論とツール実装 - ゆううきブログ

eBPF（extended Berkley Packet Filter）という用語を著者が初めてみかけたのは、2015年ごろだった。最初は、eBPFをその字面のとおり、パケットキャプチャやパケットフィルタリングを担うだけの、Linuxの新しいサブシステムであろうと認識していた。しかし、実際にはそうではなかった。 システム性能の分析のための方法論をまとめた書籍Systems Performance 1 の著者で有名なBrendan Greggが、Linuxのネットワークサブシステムとは特に関係ない文脈で、古典的なシステム性能計測ツールでは計測できないことを計測するツールを作っていた。その計測ツー…

https://blog.yuuk.io/entry/2021/ebpf-tracing

Linuxカーネルの拡張技術であるeBPF（extended Berkley Packet Filter）の普及により、ユーザー定義のコードにより、カーネル内部の関数呼び出しなどのイベントを追跡し計測しやすくなりました。この記事では、eBPFとはなにか、トレーシングにおけるeBPFの位置付け、eBPFトレーシングの技術要素（アーキテクチャ、イベントソース、BCC、bpftrace、CO-RE）、1992年の起源から2021年に至るまでの歴史、eBPFトレーシングツールをプログラミングする方法をまとめました。

この記事を書くきっかけは、論文誌Journal of Information Processing（JIP）に採録された我々の次の論文（執筆時点で未出版）のアイデアを実装するために、Linuxカーネルの機能を拡張する必要に迫られたことでした。

Yuuki Tsubouchi, Masayoshi Furukawa, Ryosuke Matsumoto, Low Overhead TCP/UDP Socket-based Tracing for Discovering Network Services Dependencies, Journal of Information Processing, Vol. 30, 2022.

昨今では、カーネルの拡張のためにeBPFを用いることがデファクトとなってきていますが、自分自身ではeBPFを用いたコードを書いたことはありませんでした。したがって、eBPFをイチから学ぶ必要がありましたが、自分の目的に対して、どのような道筋で学べばよいのか自明ではありませんでした。そのため、複数の書籍、ブログポスト、コードの切れ端などを寄せ集めて、目的を徐々に達成していくことになりました。そこで、今後同じような苦労に遭遇するかもしれない人々に向けて、その苦労を避けるために、今回道筋を記事にまとめました。

情報科学では一般に、新規性のある問題発見とその解決法を提案・評価することが代表的な研究成果として認知されています。その過程で、提案の主たる貢献にはあたらないが、成果を実装するために使用した要素技術（eBPFなど）に精通することがあります。新規性のある領域では、使用する要素技術は、確立はしていても比較的新しいか、もしくは古典的ではあっても対象とする領域でまだ馴染みが薄いケースもあります。そのため、新技術を提案するだけでなく、既存の要素技術を第三者が学びやすくなるように体系的に整理することも、社会への貢献として重要なことであると考えます。そもそも、学術研究における 「学術」とは「学ぶ術（すべ）」を構築することを指す言葉でもあると認識しています。

以前にソフトウェアエンジニア職に就いていたときは、開発・運用の現場では、断片的な知識やテクニックが民間伝承のように語られていました。このような断片的で学びにくい状態から脱するために、現場の未整理の知識を体系化して、次のようにまとめてきました。

2015年Webサーバアーキテクチャ序論 - ゆううきブログ

2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています…

https://blog.yuuk.io/entry/2015-webserver-architecture

Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。

https://blog.yuuk.io/entry/architecture-of-database-connection

Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ

本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CP…

https://blog.yuuk.io/entry/linux-networkstack-tuning-rfs

RedisサーバのCPU負荷対策パターン - ゆううきブログ

Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリ…

https://blog.yuuk.io/entry/redis-cpu-load

サーバーレスアーキテクチャ再考 - ゆううきブログ

2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを…

https://blog.yuuk.io/entry/2019/rethinking-serverless-architecture

今では開発・運用の現場からは離れることになり、プロダクション環境の生々しい経験をすることはなくなりました。しかし、その一方で、研究と開発・運用の狭間にもまだまだ未整理の事柄は大量に存在するため、そのような事柄の体系化を続けていきたいと考えています。