# 2021年/啓蟄(前) 1000コンテナ起動実験，eBPFの統計情報，CNDO2021 Created: March 8, 2021 8:17 AM Research: transtracer Tags: #cloudnative, #docker, #ebpf, #io_uring Week: March 8, 2021 → March 14, 2021 > 啓蟄（けいちつ）とは、土中で冬ごもりをしていた生き物たちが目覚める頃のこと。生き物たちは久しぶりに感じるさわやかな風と、麗らかな春の光の中で生き生きとしています。 [*https://www.543life.com/season/keichitsu*](https://www.543life.com/season/keichitsu) # Research ## Transtracerの研究 ようやく実験結果が揃ったので，論文を仕上げることができる． ### 1000コンテナ起動実験 Dockerコンテナを1000個いっせいに削除しようとすると，systemd-resolved，init，systemd，dockerd，containerd，libnetwork-setkeyなどの各プロセスが悲鳴を上げている． ![[ScreenShot_2021-03-08_at_21.16.59.png]] ![[ScreenShot_2021-03-08_at_21.16.59.png]] Dockerコンテナ数百個に対して，1個あたりTCP 20conns/sで負荷かけてると，ksoftirqdがCPU 40%/coreぐらいになるのか．コンテナなしで，20,000conns/sならksoftirqdは目立たない．docker-proxyでTCPパケットがスタックを往復する回数が増えてるからかな． コンテナ起動時のネットワークモードの指定をhost networkにすると，systemd-resolved，init，systemdなどのコンテナに直接関係ないプロセスのCPU利用率は落ち着いた． コンテナのプロセスのメモリ消費次第だけど，16GBメモリもあれば，1000コンテナぐらいは起動できることがわかった． コンテナ起動のためのコードはこのへん [https://github.com/yuuki/shawk-experiments/blob/main/tools/spawnctnr/main.go](https://github.com/yuuki/shawk-experiments/blob/main/tools/spawnctnr/main.go) ### eBPFの統計情報 評価実験でeBPFプログラムの実行時間を計測する必要がでてきた．計測方法は[昨年のeBPF summitのDatadogの人のLT](https://ebpf.io/summit-2020-slides/eBPF_Summit_2020-Lightning-Bryce_Kahle-How_and_When_You_Should_Measure_CPU_Overhead_of_eBPF_Programs.pdf)が詳しい．実際に計測できるようにしたコードは [https://github.com/yuuki/go-conntracer-bpf/pull/9](https://github.com/yuuki/go-conntracer-bpf/pull/9) ． kernel.bpf_stats_enabled sysctl - Linux 5.1 - run_time_ns run_cnt - ~20ns overhead per run 有効にする方法 - sysctl -w kernel.bpf_stats_enabled=1 - echo 1 > /proc/sys/kernel/bpf_stats_enabled 結果表示 - `bpftool prog show` - `cat /proc/<pid>/fdinfo/<bpf_prog_fd> `bpf(BPF_ENABLED_STATS, &attr, sizeof(attr))` - Linux 5.8 bpftool prog profile - Linux 5.7 - hardware Perf countershard - clock cycleとinstructions ### BPF Performance Tools輪読会 6.2 TraditionalToolsの6.2.2 Hardware Statisticsまで．perf listの続きから．Load Averageの算出方法は，指数移動平均となっている． [Load Average はどうやって算出されているのか | TECHSCORE BLOG](https://www.techscore.com/blog/2017/12/08/how_is_load_average_calculated/) [KPTI/KAISER Meltdown Initial Performance Regressions](http://www.brendangregg.com/blog/2018-02-09/kpti-kaiser-meltdown-performance.html) Gregg先生のPMC監視ツール． [brendangregg/pmc-cloud-tools](https://github.com/brendangregg/pmc-cloud-tools) ## AISREの研究 ### Zebrium - AIOpsのSaaS [ML-driven RCA for logs and Metrics (Root Cause Analysis) | Zebrium](https://www.zebrium.com/) - データソースはメトリックとログ - 根本原因分析ができる > Zebrium produces concise root cause reports with relevant log lines and correlated metrics anomalies. Now you can turn these into plain language summaries, thanks to the OpenAI GPT-3 language model. GPT-3の言語モデルを使って，根本原因レポートを作成しているらしい [Autonomous Monitoring with Chaos Engineering on Kubernetes | Zebrium](https://www.zebrium.com/blog/using-autonomous-monitoring-with-litmus-chaos-engine-on-kubernetes) Chaos Engineering（Litmus Chaos）のツールを使って，Private Betaで利用者にサービス機能を体験させているというようなことが書かれているブログ記事があった． のユーザーでもある． ## containerd + XDPでwithout proxy Dockerコンテナに外のホストから接続するとdocker-proxyが挟まっておそい．containerd + XDPでin-kernelでproxyさせるとはやくなりそう．XDPで遊びたいのでネタを作っておく．kube-proxyをCiliumに置換する話と同じ気もする． ## Instapaperを復活 Read it LaterのためのInstapaperを10年ぶりぐらいに復活させた． [[2021年 雨水(前) [[Transtracerの研究、RSSリーダーの再開]] Transtracer%E3%81%AE%E7%A0%94%E7%A9%B6%E3%80%81RSS%E3%83%AA%E3%83%BC%E3%82%BF%E3%82%99%E3%83%BC%E3%81%AE%E5%86%8D%E9%96%8B]] でRSSリーダーを運用しはじめて，あとでよむ場所としてNotionのwebclipを使っていたのだけど，Notionのwebclipには読み物以外に，コード書いててハマったときのstackoverflowのページとか雑多なものもいれていたので，あとでよみたいものが埋もれがちだった． そこで，RSSリーダー(Feedbin)からNotionにいれるのをやめて，Instapaperにいれることで，Instapaperには読み物が集まるようにしておく．Instapaperで読んでおもしろかったものは，この日誌のClipsに記録しておく． ## 社内技術研究部 io_uring チュートリアルを作ってもらっていたので，セットアップすべくカーネル5.11を用意． [https://sypalo.com/how-to-upgrade-ubuntu](https://sypalo.com/how-to-upgrade-ubuntu) をみながら， [https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.4/](https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.4/) からdebファイルを落としてくる． # Clips ## CNDO2021 全体的にKubernrtesを使い始めるフェーズは完全に通り過ぎていて，Kubernetesが前提になってる話がほとんどになってきた． ### How We Migrated K8S Cluster Without Downtime [How We Migrated K8S Without Downtime](https://speakerdeck.com/kimh/how-we-migrated-k8s-without-downtime) - CircleCIのk8sの話． - マイクロサービス 70．SREがk8sの構築と運用 - EC2 100インスタンスでk8s - ビッグバン移行か，段階的移行か．後者を採用． - 各サービスがスパゲッティ化の懸念．クラスタ間でプロキシを挟む． ⇒ Traefik - SREが移行するより，各サービスオーナーに移行をやってもらう． - Traefik nginx + haproxy 動的な設定のリロード Ingress Controllerとして動作 gRPCにも対応 - Host Based Routingで移行 virtual hostみたいなやつ？ - k8sマニフェストのラッパーツール - HPAでスケール TraefikのCPUがボトルネック Locustで負荷テスト - 振り返り - ELBの個数を節約できた - 移行状況をk8sマニフェストで管理できる - ほとんどのサービスオーナーは移行してくれなかった 😇 - 移行作業はSREが実施 ### SLO策定とアラート設定までの長い道のり [SLO策定とアラート設定までの長い道のり](https://speakerdeck.com/ueokande/sloce-ding-toaratoshe-ding-madefalsechang-idao-falseri) - サイボウズさんのSLO策定の話 - SLOv1 では各機能APIに対するSLOを設定 - 5分ウィンドウ ウィンドウ内のエラー件数N件以上，エラーレートがM%以上 - 応答時間Xパーセンタイルがγ秒以上 - アラートルールは↑のまま - アラートが過敏すぎた - アラート基準が曖昧になった．試行錯誤をやってるうちに根拠がわからなかった． - not simple - SRW本でSLOとアラートの見直し v2 - ダッシュボードによるSLO達成率の可視化 - バーンレートの導入 - ダッシュボードの2週に1回開催 研究ネタ ⇒ パイプラインのSLO策定フレームワーク ### AI事業本部におけるGPU活用の取り組みとKubernetes [](https://speakerdeck.com/masayaaoyama/cndo2021-ca-ml-gpuaas-aiplatform) - MIG Multi-instance GPU - DGX A100 - 8GPUを56インスタンス - 学習と推論を同じインスタンスで - MIG for k8s - 事前に分割する方式は公式ドライバで実装済み - CUDAでは1つのアプリ1つのGPU - 動的分割 未実装 空き領域のフラグメント化 - GPU as a Service - Prometheus DCGM Exporter でGPUのメモリ使用率を収集 - CSI driver - NetAppのTrident - read write many，read write onceへの対応 - Web UIコンソールのメタデータはCustom Resourceを使う．k8sのAPIに対して read write ### OpenAPIを使ったAPI監視とschemaを利用したエコシステムについて [API Monitoring with OpenAPI and Ecosystem using Schema](https://speakerdeck.com/line_developers/api-monitoring-with-openapi-and-ecosystem-using-schema) - LINE Verdaの話 - サービスをまたいだ障害対応が難しくなってきた ⇒ API監視 - verda-common-proxy: k8sチーム - Open API schemeで定義されたメトリックを出力 サイドカープロキシ - 3-4ヶ月で導入 - counter gaugeで保存 pod外から定期的にスクライビング - スキーマコンテナイメージ nginx + 設定？ - アプリとスキーマの別個管理？ - サーバプロセス側からスキーマ取得が可能 - FastAPI - リクエスト数，レイテンシ，サイズ - Grafanaで可視化 - verda-common-proxy OpenStack KeyStone - ヘッダにロールなどいれる - AuthNに加えてAuthZも - [https://engineering.linecorp.com/ja/blog/verda-common-proxy/](https://engineering.linecorp.com/ja/blog/verda-common-proxy/) - Prometheus (inCluster) ⇒ TSDB VictoriaMetrics ⇒ Grafana, VMAlert - オペレーション事例 - VM ネットワーキングを管理するAPI リクエスト数増大により性能低下 - 非同期リクエストはAPI監視ではわからない - VM作成などの非同期ジョブ - OpenStack リクエストIDで追跡 - ssh接続の結果を記録 ### NFVにおけるクラウドネイティブ技術適用の挑戦 [NFVにおけるクラウドネイティブ技術適用の挑戦](https://speakerdeck.com/sinohara/nfvniokerukurautoneiteihuji-shu-shi-yong-falsetiao-zhan) ### Istioを活用したObservability基盤の構築と運用 [Istioを活用したObservability基盤の構築と運用 / Constructing and operating the observability platform using Istio](https://speakerdeck.com/ido_kara_deru/constructing-and-operating-the-observability-platform-using-istio) [https://github.com/prometheus-operator/kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) 便利そう ### containerd をソースコードレベルで理解する - Pod作成時のCRIリクエスト - RunPodSandbox: pauseコンテナ作成 - containerd → runC - CreateContainer - containerdに登録するだけ - StartContainer - runCまでいって起動 ### モノリスからマイクロサービスへ - Datadogの話 - k8sのメタデータをDD上で全部もってる podのログもみれる - Notebook機能 メモとかできる ### 継続的な性能担保、DevPerfOpsという考え方 - 特定ブランチへのリリース時に性能試験が自動で走る - 本番リリース時に自動評価，自動切り戻し - Progress Delivery CDの次のステップ - リリース中の評価，自動切り戻しが追加 - カナリーリリース中にSLAなどの評価 ⇒ トラフィックを増加させていく - Flagger → weaveworks servicemesh前提 - Argo Rollouts - Spinnaker (Kayenta) - PipeCD [kashinoki38/sockshop-kashinoki38](https://github.com/kashinoki38/sockshop-kashinoki38) ![[ScreenShot_2021-03-12_at_14.10.05.png|600]] ![[ScreenShot_2021-03-12_at_14.10.05.png|600]] ### Calicoのデプロイをミスって本番クラスタを壊しそうになった話 [【CNDO2021】Calicoのデプロイをミスって本番クラスタを壊しそうになった話](https://www.slideshare.net/katsuyakawabe/cndo2021calico) ## Autopilot GKE AutopilotとEurosys'20のAutopilotの論文 [Rzadca 20] は別物って聞いたのだけど，一応確認している．論文のAutopilotは，利用者がリソースの設定をせずに，MLベースで水平方向と垂直方向の自動スケーリングする手法．GKEのAutopilotは，今はまだ利用者がpodのリソースの設定が必要みたいなので，たしかにこれは別物だ． [Rzadca 20] Autopilot: workload autoscaling at Google, European Conference on Computer System (EuroSys) 2020. [https://dl.acm.org/doi/pdf/10.1145/3342195.3387524](https://dl.acm.org/doi/pdf/10.1145/3342195.3387524) [GCPUG Tokyo GKE Day March 2021 (2021/03/08 19:00〜)](https://gcpug-tokyo.connpass.com/event/205839/) GCPUGのテーマがGKE Autopilotだったので一部を眺めていた． ## 日本でインターネットはどのように作られたのか？ [日本でインターネットはどのように創られたのか? WIDEプロジェクト20年の挑戦の記録](https://www.amazon.co.jp/dp/4844326775) 社内でインターネットの歴史を振り返るイベントがあって，そこで紹介されていたで，軽く眺めている．村井先生のインタビューのところで，インターネットはそもそも研究領域ではなかったから，研究として成立させるところで，努力を積み重ねられたことが伺えた． また，WIDEには「右手に運用、左手に研究」という標語があるらしい． > ただ作り出しただけでは，人に使われる技術には絶対になりません．本当に大事なことはそこから先の，普通の人に使われて，きちんと使い続けられるという継続と信頼の部分です．それは技術の深さとしてはほんの2%かもしれないが，その2%がすごく遠い． ## 完走した研究 [https://twitter.com/caesar_wanya/status/1369431482255745026?s=20](https://twitter.com/caesar_wanya/status/1369431482255745026?s=20) これまで書いてきた論文では，間に合わせの実験で終わっていたことが多かった．これでいいんだろうかと疑問に思って，今は納得いくまで実験してブラッシュアップすることにしつつあったので，励みになる． ![[Grafana Tempo]] ## libbpf: BPF static linking [https://lore.kernel.org/bpf/[email protected]/t/](https://lore.kernel.org/bpf/[email protected]/t/) BPFオブジェクトファイルのスタティックリンクが可能となった．externの解決はまだこれから． これまでは，単一のソースコードファイル内にすべてのコードとデータ（変数とマップ）を持たないといけなかったが，うまくカプセル化できるようになった． ## Observability Considarations in Chaos [Observability Considerations in Chaos: The Metrics Story](https://dev.to/ksatchit/observability-considerations-in-chaos-the-metrics-story-6cb) Litmus ChaosのExporterの改善の記事。Chaosで異常を注入したときのObservabilityについて述べている。Chaos Interleaved dashboardsはChaosの実験期間を示したダッシュボード。[https://dev.to/ksatchit/monitoring-litmus-chaos-experiments-198a](https://dev.to/ksatchit/monitoring-litmus-chaos-experiments-198a) の最後の画像のように，実験期間だけ色が変わる． 仮説の自動検証にも触れられている．[promProbe](https://docs.litmuschaos.io/docs/litmus-probe/#promprobe) で実験中のアプリメトリクスの期待値を定義できるとのこと．