コンテナ勉強会20170617 GMOデジロック株式会社

1. GMOデジロック株式会社
2017年6月17日 ＠大阪
左川善章
LXD 採用から運用までの
顛末記

2. 目次
1. 自己紹介
2. LXD 採用まで編
3. LXD 構築から運用まで編
4. LXD 運用編
5. 総括

3. 自己紹介
名前：左川善章
職業：GMOデジロック株式会社
技術部（サーバー保守・運用担当）
性格：真面目、誠実（笑）
特徴：ボケもツッコミも下手な関西人

4. ドメインサービス 紹介
低価格、自由度・柔軟性を重視したサービス
契約数 140万件以上
ユーザー数21万人

5. ホスティングサービス 紹介
低価格、自由度・柔軟性を重視したサービス
↑コンテナ採用 ↑リニューアル予定
続々コンテナ採用予定！

6. ～ LXD 採用まで編～

7. 色々お話させて頂きますが、
LXD採用で、
XREA、
ハイパフォーマンスで
安定稼動しております！！
コンテナ関係者の皆様に感謝！

8. XREA 仮想化前史～完全仮想化へ
1. その昔、創業当初からのものを含む、古い物理サーバー
を使っていた。ハード、ソフトとも老朽化しすぎ。。。
2. 2011年、マイグレーションに際して、KVM 完全仮想化を
採用して刷新。
3. 400 台弱のサーバーが、２ラックに収まった。

9. 完全仮想化の利点と問題点～運用してみて
1. セキュリティリスクや負荷のコントロールがVM内で完結
1. HDDディスクイメージの容量不足・増設でストレージの無駄が顕在化
2. CPU、メモリ、ディスク等でパフォーマンス不足、無駄の多さが目立つ……。
3. そして準仮想化へ。
メリット
デメリット

10. よし、時代はコンテナだ！
このままでは、お客様の満足度が下がる！

11. なぜコンテナか？
1. 年月が経ち、サーバー毎にアクティブ数がまちまちである
2. 最小限のコストで最大限のパフォーマンス
3. 保守・運用が楽、安定している
4. 弊社の規模・要件にマッチしている

12. なぜLXDか？
・Docker
⇒ Dockerでレンタルサーバーでやってやろう！と試行錯誤するも、ユーザーの権限独立
とネットワーク周りの問題が解決できず、本要件には不向きと判断
・KVM ⇒ 前述の通り、オーバーヘッドが多くてリソースが無駄
・OpenVZ ⇒ コンテナより遅かった
・Vmware ⇒ 考えたこともない
・LXD
⇒コンテナだし、リソースが有効に使えて、ヒャッハーだ！
（開発・構築担当者 原文ママ）

13. LXD採用からサービス開始まで①
• コンテナの採用決定から本番まで半年しかなかった
• 2016年夏 構築・運営ノウハウ、全てゼロからのスタート！

14. LXD採用からサービス開始まで②
• 2017年2月 運用スタート！
• 2017年5月 全台リニューアル完了！
• 2017年6月 安定稼働！ コンテナの障害なし！
まだまだ日々試行錯誤中・・・

15. LXDの運用対象
• アカウント数：30万ぐらい
• データ量：50TBぐらい
• ファイル数：8億ぐらい
• 帯域：1Gbpsぐらい

16. LXDの運用環境
• D社サーバー
• オールフラッシュ RAID10
• １ラックに収まるぐらいの台数＾＾；

17. LXDの運用環境
• ホストOS:Ubuntu 16.04 LTS
CentOS7なども検証。やっぱり、 Ubuntu。
• ゲストOS:CentOS7
共有サーバー要件で最適
保守・運用上、実績があり、使い慣れたもの（時間の節約）

18. LXDの運用環境
• 最新版LXD 2.0.9
• ZFS + ブロックデバイス
• ホスト、ゲストのファイルシステム：ext4

19. なぜZFSか？
• 公式がおすすめしているｗ
• ベンチマークが最速（個人的見解）
• 成熟している（運用実績はないが…）

20. ベンチマーク
ホスト
Seq-Read: bw=5535.2MB/s, iops=5535
Seq-Write: bw=3002.1MB/s, iops=3002
Rand-Read-512K: bw=5224.6MB/s, iops=10448,
Rand-Write-512K: bw=2994.2MB/s, iops=5988
Rand-Read-4K: bw=890889KB/s, iops=222722
Rand-Write-4K: bw=249720KB/s, iops=62430
Rand-Read-4K-QD32: bw=911013KB/s, iops=227753
Rand-Write-4K-QD32: bw=255501KB/s, iops=63875
• fioでの計測
• 5～15%のオーバヘッドは
あるものの、概ね良好！
コンテナ
Seq-Read: bw=4718.1MB/s, iops=4718
Seq-Write: bw=2790.2MB/s, iops=2790
Rand-Read-512K: bw=4376.7MB/s, iops=8752
Rand-Write-512K: bw=2730.7MB/s, iops=5461
Rand-Read-4K: bw=882640KB/s, iops=220659
Rand-Write-4K: bw=229749KB/s, iops=57437
Rand-Read-4K-QD32: bw=874542KB/s, iops=218635
Rand-Write-4K-QD32: bw=248301KB/s, iops=62075

21. ～ LXD 構築から運用まで編～

22. ホストシステム構築時のトラブル
• オープンファイル数の上限 fs.inotify.max_user_instances
• PID、スレッド数の上限 kernel.threads-max kernel.pid_max
• 共有メモリー系の上限 vm.max_map_count kernel.msg*

23. オープンファイル数の上限編
コンテナばんばん作成するぜー！（開発・構築担当者談）
Error: Too many open files
Job for network.service canceled.
あれ？
⇒コンテナの作成台数が20台を越えた辺りからネットワーク周りが不安定になる
⇒ファイル数、プロセス周りの制限が掛かって上手くいかないのか？
こんな事やりました↓

24. オープンファイル数の上限編
echo 1000000 > /proc/sys/fs/file-max
vi /etc/sysctl.conf
fs.file-max=1000000
vi /etc/security/limits.conf
* soft nofile 1000000
* hard nofile 1000000
ulimit -n 1000000
あれ？直んない
↓
なんで
↓
なんで
↓
なんで
↓
こっちかい
↓

25. オープンファイル数の上限編
echo "fs.inotify.max_user_instances =
819200" | tee -a /etc/sysctl.conf && sudo
sysctl –p
そっちかい！

26. その他上限解除編
fs.aio-max-nr
fs.inotify.max_user_instances
kernel.msgmax
kernel.msgmnb
kernel.msgmni
kernel.pid_max
kernel.sem
kernel.shmall
kernel.shmmax
kernel.shmmni
kernel.threads-max
net.core.rmem_max
net.core.somaxconn
net.core.wmem_max
net.ipv4.ip_conntrack_max
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_max_orphans
net.ipv4.tcp_rmem
net.ipv4.tcp_sack
net.ipv4.tcp_syncookies
net.ipv4.tcp_timestamps
net.ipv4.tcp_window_scaling
net.ipv4.tcp_wmem
net.nf_conntrack_max
vm.dirty_background_ratio
vm.dirty_expire_centisecs
vm.dirty_ratio
vm.dirty_writeback_centisecs
vm.max_map_count

27. ～ LXD 運用編～

28. 運用時の苦労①
ゲゲッ ユーザークォータできないん
ですけど…
⇒色々調査したものの解決策が見つからず
⇒運用でカバー！

29. 運用時の苦労②
マイグレ前半は特にLXDに関連する大きなトラブルは無し！！
だが後半、マイグレ作業中に、Apacheのアラートがバンバンなり始める！
「なんだなんだ！？」
容赦なくアラートはバンバン増えていく、薄れゆく意識（夜間作業）、
増大する恐怖・・・
「ここまで来て、まさかの、切り戻しか・・」
作業時間午前4時…
原因判明
↓

30. 運用時の苦労②
原因は
Apache RLimitNPROC
＋
Potential DoS attacks
https://linuxcontainers.org/lxc/security/
⇒要は、各コンテナでプロセス起動数制限をかける際、制限対象のUIDが共通
であるプロセス数を、全コンテナで見てしまっていた

31. 運用時の苦労③
ホストのロードアベレージが急激に上昇、
ホストからは問題のあるユーザーは特定できない・・
⇒ZFSがボトルネック
チューニングを実施
zfs_arc_meta_adjust_restarts
zfs_arc_meta_prune
収まったものの、まだまだ未知の問題がでる可能性があり
日々試行錯誤、格闘しています。

32. 運用時の苦労④
コンテナ自体のリソース制御は、この辺をチュー
ニングしています。
（自動化テスト中…）
limits.cpu:
limits.memory:
limits.memory.enforce:

33. 運用時の苦労⑤
ホスト側からコンテナ内のユーザーを制御するた
め、コンテナ内のUIDを取得し、制御する仕組み
をテスト中…

34. ～ 総括～

35. LXDはヒャッハーなのか？

36. LXDに変えてどうだったか
・2ラック⇒1ラックにできた
・運用でカバーしている部分もあるが、保守・運用負荷は減った
・集約率を上げたにも関わらず、以前よりも快適にご利用頂いている
・CPU/ストレージ/メモリー領域を有効に使える
⇒高速なCPUやSSD、大容量のメモリーを採用でき、安価でご利用頂ける
⇒結果として、競争力のあるサービスになった！
⇒おかげさまで、ユーザー数は増加中！

37. 結局のところ……

38. ヒャッハーだ！

39. お客様の満足度が上がりました！
LXD最高！！
OSS/コンテナ開発関係者の
皆様に感謝！
ご清聴ありがとうございました。