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
210
コンテナをたくさん詰め込んだシステムとランタイムの変化
10年近くコンテナを利用したシステムを運用してコンテナランタムの使い方がどのように変化してきたのか取り上げます
Hiroaki Mizuguchi
December 16, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
1
200
ESLintプラグインを使用してCDKのセオリーを適用する
yamanashi_ren01
2
460
SwiftUIで単方向アーキテクチャを導入して得られた成果
takuyaosawa
0
170
ペアーズでの、Langfuseを中心とした評価ドリブンなリリースサイクルのご紹介
fukubaka0825
1
220
『改訂新版 良いコード/悪いコードで学ぶ設計入門』活用方法−爆速でスキルアップする!効果的な学習アプローチ / effective-learning-of-good-code
minodriven
29
4.9k
ASP.NET Core の OpenAPIサポート
h455h1
0
170
混沌とした例外処理とエラー監視に秩序をもたらす
morihirok
19
3.4k
CNCF Project の作者が考えている OSS の運営
utam0k
5
640
ISUCON14感想戦で85万点まで頑張ってみた
ponyo877
1
800
Open source software: how to live long and go far
gaelvaroquaux
0
460
月刊 競技プログラミングをお仕事に役立てるには
terryu16
2
1.3k
Spring gRPC について / About Spring gRPC
mackey0225
0
200
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
Designing for humans not robots
tammielis
250
25k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
KATA
mclloyd
29
14k
Practical Orchestrator
shlominoach
186
10k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Facilitating Awesome Meetings
lara
51
6.2k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
Into the Great Unknown - MozCon
thekraken
34
1.6k
The Pragmatic Product Professional
lauravandoore
32
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のような高度なリソース管理機能が要らないならおすすめ