Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナをたくさん詰め込んだシステムとランタイムの変化
Search
Hiroaki Mizuguchi
December 16, 2024
Programming
1
300
コンテナをたくさん詰め込んだシステムとランタイムの変化
10年近くコンテナを利用したシステムを運用してコンテナランタムの使い方がどのように変化してきたのか取り上げます
Hiroaki Mizuguchi
December 16, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
Foundation Modelsを実装日本語学習アプリを作ってみた!
hypebeans
0
110
育てるアーキテクチャ:戦い抜くPythonマイクロサービスの設計と進化戦略
fujidomoe
1
170
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
200
Django Ninja による API 開発効率化とリプレースの実践
kashewnuts
0
1.3k
オープンソースソフトウェアへの解像度🔬
utam0k
13
2.6k
Cursorハンズオン実践!
eltociear
2
1k
Introducing ReActionView: A new ActionView-Compatible ERB Engine @ Kaigi on Rails 2025, Tokyo, Japan
marcoroth
3
1k
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
400
Cloudflare AgentsとAI SDKでAIエージェントを作ってみた
briete
0
140
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
220
株式会社 Sun terras カンパニーデック
sunterras
0
280
Six and a half ridiculous things to do with Quarkus
hollycummins
0
170
Featured
See All Featured
Thoughts on Productivity
jonyablonski
70
4.9k
Code Review Best Practice
trishagee
72
19k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
32
2.3k
How to Ace a Technical Interview
jacobian
280
24k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
jQuery: Nuts, Bolts and Bling
dougneiner
65
7.9k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Scaling GitHub
holman
463
140k
The World Runs on Bad Software
bkeepers
PRO
72
11k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Making Projects Easy
brettharned
119
6.4k
Transcript
コンテナをたくさん 詰め込んだシステム とランタイムの変化 HIROAKI MIZUGUCHI INTERNET INITIATIVE JAPAN INC. CONTAINER
RUNTIME MEETUP #6 2024-12-16
自己紹介 名前: 水口 弘明 X: @m_akihiro, Github: akihiro
所属: Internet Initiative Japan Inc. 仕事: ネットワーク監視システムの開発運用、サーバOS周りのコンサルティング
IIJプライベートバックボーンサービス IIJのサービスや他社クラウドを相互接続 できる閉域網を提供 テナントごとに独立した閉域網を多数管理 2013年10月サービス開始
なぜ多数のコンテナを動かすのか? テナント毎にアドレス空間は独立し、テナント間ではアドレスが重複するから Tenant A Tenant B Tenant C Probe
For A Probe For B Probe For C 192.168.0.10 192.168.0.10 192.168.0.10 backend 169.254.0.0/16, fe80::/10 Link-Local Address
2014年 device mapperの導入 Containerのlayered filesystemとしてdevice mapper実装を導入 コンテナの収容に対してdevice mapperがボトルネック
o ブロックデバイスレイヤーで実装 o コンテナ毎にファイルキャッシュが独立 64GBのホストに250テナント/500コンテナを収容 o NetNSを保持するpause+CNI機能を持つ内製したgolang製のコンテナ o 監視サービス用の内製したpython3のコンテナ o 50GBほどのメモリ消費で安定していた Devicemapper Filesystem (file cache) Application
2018年 overlayfsの導入 Runtimeのlayered filesystemとしてoverlayfs実装を採用 同一コンテナイメージならファイルキャッシュが共有される コンテナ内部プログラムの書き換え
NetNS保持コンテナとしてk8sのpauseに置き換え、CNI相当をホスト側へ 監視プログラムをGo言語製に置き換え 96GBのホストに500テナント/1000コンテナを収容 メモリ消費は15GB程度で安定 Filesystem (file cahce) OverlayFS Application
Container Runtimeのfootprint 2014年docker、2018年docker+containerdを採用 コンテナの数に比例してContainer Runtimeのfootprintが問題視 500テナント/1000コンテナのOSのThread数
GoのRuntimeはCPU数程度のスレッドを作る。不足するともっと沢山作る containerd: 1k threads containerd-shim: total 10k threads pauseコンテナ: 500 threads アプリ本体のコンテナ(tini相当+本体): total 20k threads
2024年 daemonlessのpodman daemonlessのpodman+quadletを採用 管理用の常駐プロセス不要 containerd-shim相当のconmonはsingle thread動作
podmanは直接netnsを指定可能 → pauseコンテナ不要 アプリケーションコンテナの設計見直し Zombie reaperをGo製の内製ツールからtini(single thread動作)に変更 1ホスト当たり1000テナント/1000コンテナを収容
非k8s環境でのコンテナ管理 Podman Quadletとsystemdの組み合わせが良い(個人の感想です) Quadletはpodmanのsystemd-generatorとして実装 systemd.service likeな設定ファイルでコンテナ管理できる
Podman quadletとansibleの組み合わせが良い(個人の感想です) Ansibleとpodmanは共にredhatが開発している Podman用のansible roleもメンテナンスされている 沢山のコンテナの設定をjinjaテンプレートで管理できる NRIのような高度なリソース管理機能が要らないならおすすめ