1. コンテナ時代に
インフラエンジニアは何をするの
か
グリー株式会社 開発本部 駒﨑 拓斗

2. 2
●グリー入社前
○ 組み込みソフト企業
○ 携帯電話向けプラットフォームの開発
●2012年より グリーインフラ部門
○ 開発環境の構築、運用
○ デプロイツール・フロー改善
○ 商用サービス部門向き合いのインフラ構築・運用・相談
○ 最近の主なフィールドは AWS や GCP
2
自己紹介
駒﨑 拓斗

3. 3
3
とつぜんですが
クイズです

4. 1. init オプション付きで起動する
1. pid=host オプション付きで起動する
1. user=1000:1000 オプション付きで起動する
1. sig-proxy=true オプション付きで起動する
4
次のコマンドは Ctrl+C で停止できません
run のオプションで停止可能にできます。効果があるものを全て選んでください
Q1. Docker クイズ
$ docker run --rm busybox sleep 10000
$ docker run --rm --init busybox sleep 10000
$ docker run --rm --pid=host busybox sleep 10000
$ docker run --rm --user=1000:1000 busybox sleep 10000
$ docker run --rm --sig-proxy=true busybox sleep 10000

5. 5
5
ⓘ Start presenting to display the poll results on this slide.
Ctrl+c で停止可能なのはどれ？ (複数選択)

6. 1. init オプション付きで起動する
1. pid=host オプション付きで起動する
1. user=1000:1000 オプション付きで起動する
1. sig-proxy=true オプション付きで起動する
6
次のコマンドは Ctrl+C で停止できません
run のオプションで停止可能にできます。効果があるものを全て選んでください
Q1. 簡易解説
$ docker run --rm busybox sleep 10000
$ docker run --rm --init busybox sleep 10000
$ docker run --rm --pid=host busybox sleep 10000
$ docker run --rm --user=1000:1000 busybox sleep 10000
$ docker run --rm --sig-proxy=true busybox sleep 10000
PID1 のプロセスは明示的にハンドルしない限
り
INT や TERM シグナルで停止しない
軽量 init プロセスを PID1 とし、
コマンドをその子として実行するオプション
→ init 経由でシグナルが伝わり停止する
ホストと PID namespace を共有するオプション
→ PID1 でなくなりシグナルが伝わり停止する
uid:gid を指定するオプション
→ 特に本件では関係ない シグナルの伝搬を指定するオプション
→ デフォルトで true 、本件では指定しても意味がな
い
逆に false にすると Ctrl+C で
KILL が送信され停止する

7. 1. Service type: ExternalName を作成し
Pod から Service 名で参照
$ curl https://greetech/
2. そのままの名前で参照
$ curl https://greetech.example.com/
3. そのままの名前 (末尾 . 付き)で参照
$ curl https://greetech.example.com./
7
Kubernetes の ある Pod から
外部サービス https://greetech.example.com にアクセスします
最も少ない DNS トラフィックが期待できるのは次のうちどれでしょう
※ 一般的な初期設定の Kubernetes クラスタにおいて Pod - クラスタ内 DNS サーバ間
Q2. Kubernetes クイズ
apiVersion: v1
kind: Service
metadata:
name: greetech
spec:
type: ExternalName
externalName: greetech.example.com.
※同一 namespace

8. 8
8
ⓘ Start presenting to display the poll results on this slide.
DNS トラフィックが少ないのは？

9. 1. Service type: ExternalName を作成し
Pod から Service 名で参照
$ curl https://greetech/
2. そのままの名前で参照
$ curl https://greetech.example.com/
3. そのままの名前 (末尾 . 付き)で参照
$ curl https://greetech.example.com./
9
Kubernetes の ある Pod から
外部サービス https://greetech.example.com にアクセスします
最も少ない DNS トラフィックが期待できるのは次のうちどれでしょう
※ 一般的な初期設定の Kubernetes クラスタにおいて Pod - クラスタ内 DNS サーバ間
Q2. 簡易解説
apiVersion: v1
kind: Service
metadata:
name: greetech
spec:
type: ExternalName
externalName: greetech.example.com.
※同一 namespace
# 標準的な resolv.conf (EKS)
nameserver 10.100.0.10
search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
options ndots:5
search リスト、ndots: 5 が特徴
→ 名前に含まれるドットが5より少なければ search リストを順番にためすよ、の意
ドット<5 なので search リストの先頭
greetech.default.svc.cluster.local. に問い合わせ、
返された CNAME greetech.example.com. に問い合わせ
ドット<5 なので search リストの先頭から
greetech.example.com.default.svc.cluster.local. ,
greetech.example.com.svc.cluster.local. ,
greetech.example.com.cluster.local. ,
greetech.example.com.ec2.internal. ,
と問い合わせた後、
greetech.example.com. に問い合わせ
FQDN なので greetech.example.com. に問い合わせ

10. 10
10
お付き合いありがとうございました

11. 11
11
本題
コンテナ時代のインフラ

12. ●アプリケーション担当者/チーム (アプリチーム)
○ あるサービスのビジネスロジックを担当する
○ カスタマーに対し サービスを開発、運用する
○ 典型的には、サーバアプリケーション開発者チーム
●インフラストラクチャ担当者/チーム (インフラチーム)
○ アプリチームに対し基盤を提供、開発、運用する
○ 複数のサービスを受け持ち、共通課題を横串で担当する
■ 横串で受け持つことで、コスト・リソースの最適化を狙う
●理想的にはワンチームでプロダクトが作れたらよい、が
○ 複数事業をさばくため
12
アプリチームとインフラチーム
背景: 本日の "インフラエンジニア" について

13. ●サービスを提供するインフラは絶えず変化
●ベアメタルから VM、コンテナへ
●2020 現在グリーでは
○ オンプレミス・パブリッククラウド併用中
○ さらにパブリッククラウドへ移行中
13
グリーグループのインフラの歩み
背景: Web サービスインフラの移り変わり
ベアメタル
オンプレ VM
パブリッククラウド VM
サーバレス
コンテナ

14. ●ベアメタル時代
○ サーバ調達、インベントリ管理、OS 設定、プロビジョニング、...
○ 監視・アラートシステム 内製
●VM 時代 初期
○ プロビジョニングツールの導入
○ Infrastructure as Code による自動化
○ 構造はそのまま クラウドへの "リフト" が行われた
●VM 時代 後期
○ パブリッククラウドの活用
■ プログラマブル / 宣言的な構築 により自動化がさらに進む
■ クラウドに合わせた設計の浸透
■ スケーリング操作など一部運用がアプリチーム側へ
14
インフラのデリバリー・運用の変化
これまでの変化 (ホストベース時代)

15. ●実用的なコンテナ基盤の普及
○ アプリチームからもコンテナが身近なものに
■ docker-compose
■ Cloud Run
■ AWS copilot (ecs-cli)
■ Kubernetes
●マネージド Kubernetes の大きなインパクト
15
コンテナ時代へ

16. 16
消えるインフラ業務、残る生まれるインフラ業務
マネージド Kubernetes の出現
ランタイム / Lib 更新したい
VM イメージ作り直してもらえます
か
サーバにつなげる
最小限の E2E 環境がほしい
構築とデプロイお願いします
デプロイツールの改修を
…
Dockerfile をちょいと
FROM php:7.4-apache 、と
クラスタぽちぽち、
Deployment に Service に
Ingress 書いて、apply 、と

17. ●たしかに 一部の既存業務は ほぼなくなった
○ VM イメージ管理
○ デプロイツール
○ オートスケーリング設定
●引き続きやってくモノ・新しく生まれるモノ
○ サイト信頼性エンジニアリング (SRE) 関連
■ 可観測性の面でより重要度が高まる
○ データストアやネットワーク、CDN などの専門知識
○ 本番運用に耐えるための Kubernetes 自体の知識
○ これまでも VM やパブリッククラウドの登場による変化はあったが
Kubernetes による変化はそれよりかなり大きい
17
消えるインフラ業務、残る生まれるインフラ業務
マネージド Kubernetes の出現

18. ●(少なくとも今のとこは) まだまだ
●例. 冒頭のクイズの領域
○ Q1. Docker クイズ (The PID1 Problem)
■ Dockerfile の書き方を気をつける問題、nodejs で遭遇しがち
○ Q2. Kubernetes クイズ (dnsPolicy ClusterFirst の設定)
■ 名前解決のお作法に気をつける問題
○ しかし全くビジネスロジックには関係無い
■ アプリチームが頑張るところだろうか？
■ 組織として横串で共有すべきノウハウの類
●"アプリチームに基盤を提供する" 仕事の本質は同じ
○ が、どこまでが基盤なの？
18
Kubernetes でインフラの業務範囲はどんどん縮小する？
これから仕事減りそう？

19. 19
ホストベースのころ
19
PHP : アプリチーム
CI : アプリチーム
Deploy : インフラチーム
apache : インフラチーム
VM : インフラチーム
LB : インフラチーム
︙
チーム担当範囲の境界はどこだ
これから
Dockerfile : アプリチーム...?
ちょっとインフラ?
CI/CD : アプリ?インフラ?
K8s : インフラチーム...?
とアプリチーム...?
︙
従来型分担とのアンマッチ

20. ●ソフトの構造と組織の構造に相関がある、として
●従来のチーム分け
○ VM時代以前(ホストベース) の構造に最適化されたもの
●インフラの新しいレイヤが積まれ構造が変化
○ 一段上のプラットフォームができた
○ 抽象化・ソフトの構造が変化した
○ 従来の組織でアンマッチを感じるのは自然
20
ソフトウェアの変化、変化前の組織とのアンマッチ
なぜアンマッチが発生するか

21. ●現状は双方からコミット
●コミュニケーションを大事に
●サービスの時期によって柔軟に
○ 弊社ケース
■ 初期はインフラチーム率高め
■ 安定運用 & K8s 習熟度向上してくるとアプリチーム率高め
■ 境界のあいまいさは許容
21
インフラチーム / アプリチームの壁を越えてコミュニケーション
現時点の状況
Dockerfile
インフラチーム アプリチーム
K8s manifest
K8s Cluster Config
Dockerfile
インフラチーム アプリチーム
K8s manifest
K8s Cluster Config
Dockerfile
インフラチーム アプリチーム
K8s manifest
K8s Cluster Config
CI/CD CI/CDCI/CD
むしろ、従来の構造のチームにキッチリ
合わせようとしてしまうと
Kubernetes 的/クラウドネイティブ的
なソフトを活かせなくなる可能性も

22. ●グリーでは現状 ホストベース環境が主流
○ コンテナ/Kubernetes に向けて即組織刷新とかはない
●いま 2020 年、両方やらなくちゃいけない
●Kubernetes との向き合い方には気をつける
○ コンテナ管理ツール ではなく プラットフォームとして
○ 今までのやり方を延長するより、段を登ってみる
○ さらにプラットフォームのためのプラットフォームでもある
○ プラットフォームの意図を汲む
22
従来のホストベース環境も両方見ていく
現時点の状況

23. ● Dokcer も Kubernetes も関係無しに
実現するとしたら？
○ 環境ごとに VPC を分ける
VPC ごとの DNS サーバを使って
レコードを切り替える
○ AWS Route53 など
23
例.
23
DNS 管理者の帽子
「自前 DNS サーバでコントロールしよう」
アプリから外部サービス API を参照する。
Production / QA / Develop の
環境ごとに参照先を切りかえたい…
どうやって実現しようか

24. ● Dokcer コンテナ的なお作法で
実現するとしたら？
○ コンテナ内で環境変数を参照させ
実行環境で環境変数に参照先ドメインを流し込む
○ コンテナ内に全パターンの config を埋めておき、
環境変数で config パスを切り替える
24
例.
24
Docker の帽子
「APP_PORT_TCP_ADDR 環境変数を
参照させよう」
DNS 管理者の帽子
「自前 DNS サーバでコントロールしよう」
アプリから外部サービス API を参照する。
Production / QA / Develop の
環境ごとに参照先を切りかえたい…
どうやって実現しようか

25. ● Kubernetes のお作法で
実現するとしたら？
○ コンテナ内の名前は固定してよい
Service リソースで流し込む
○ または Docker のとこで挙げたパターンもよい
25
例.
25
Kubernetes の帽子
「Service リソース名を参照させよう」
「もしくは環境変数でもよい」
Docker の帽子
「APP_PORT_TCP_ADDR 環境変数を
参照させよう」
DNS 管理者の帽子
「自前 DNS サーバでコントロールしよう」
アプリから外部サービス API を参照する。
Production / QA / Develop の
環境ごとに参照先を切りかえたい…
どうやって実現しようか

26. ●帽子のかぶりわけ
○ 範囲を明確に認識出来ている状態
●まずは一番上の帽子をかぶる
○ だめなら下の帽子をかぶりなおす
○ どの帽子をかぶっているかを忘れない
●柔軟なプラットフォームほど
帽子を見失いがち
●作る側に回るときにも必要
26
このプラットフォームはどう使われることを想定しているのか
プラットフォームの意図を汲む
Kubernetes の帽子
「Service リソース名を参照させよう」
「もしくは環境変数でもよい」
Docker の帽子
「APP_PORT_TCP_ADDR 環境変数を
参照させよう」
外部サービスの参照先を
環境ごとに切りかえたい
…
DNS 管理者の帽子
「自前 DNS サーバでコントロールしよう」

27. ●アンラーニングで新しい帽子を手に入れる
○ 既存知識との境界を認識する、引きずらない
■ 既存知識の活用・応用はあとからでいい
●多くの場合、高次の帽子が "筋がいい" が
○ ときには帽子をかぶりわける
○ プラットフォームの機能が十分でないとき
○ あえて違う作法を選ぶとき
●帽子を混ぜない！どっちつかずは運用混乱を招く
○ どっちつかずの例.
■ ingress-controller で LB を作成したが、別の方法で設定追加
■ external-dns で作成したレコードと手動作成したレコード混在して参照させる
27
新しい帽子を手に入れる・帽子をかぶりわける
どっちつかずの帽子

28. ●コンテナ・クラウドネイティブ時代も変わらないもの
○ アプリチームがビジネスに集中できる基盤を提供する
○ 横串でノウハウ・サービスを展開する
●ホストベース時代とコンテナ時代の構造の違いを認識
○ どちらにもマッチするチームは難しい
○ (気持ちは) チームの柵を越えていく
●インフラの階層ごとに頭を切り替える
○ インフラ領域も確実に抽象化層が増えた
○ 帽子をかぶりわけるように
○ どの階層の話なのか？ をはっきり
28
移行期のインフラエンジニアとして
ホストベース時代からコンテナ時代へ

29. 29
29
ⓘ Start presenting to display the poll results on this slide.
よろしければ教えて下さい皆様の担当領域は？

30. 30

31. 31
Q1. Docker クイズ (The PID1 Problem) 資料
参考リンク
● "Docker/Kubernetes で PID 1 問題を回避する" https://text.superbrothers.dev/200328-how-to-avoid-pid-1-
problem-in-kubernetes/
● "PID1 は、カーネルから特別扱いされてるって本当ですか？" https://speakerdeck.com/superbrothers/pid1-ha-
kanerukara-te-bie-xi-isareterututeben-dang-desuka
● "Docker and Node.js Best Practices"
> Node.js was not designed to run as PID 1 which leads to unexpected behaviour …
https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md#handling-kernel-signals
● Google Cloud "PID 1、シグナル処理、ゾンビプロセスの適切な処理" https://cloud.google.com/solutions/best-
practices-for-building-containers?hl=ja#signal-handling
● docker アプリが適切な signal handling をしていない場合に、アプリの適切な終了処理ができなかったり、実行環境・ア
プリによっては fork したプロセスが回収されずゾンビ大量発生などの問題を招く
● 現実的には nodejs や LL の簡易サーバ、crond などで遭遇しがち
● 自分のアプリが適切に handling できているかについては、クイズのように docker run してみて Ctrl+C や docker stop
/ docker kill --signal="TERM" のようにしてみると簡単に確認できる
● 対応については、alpine ベースであれば apk で tini (軽量 init プロセス) を入れてしまうのが便利
$ docker run --rm busybox sleep 10000

32. 32
Q2. Kubernetes クイズ (dnsPolicy ClusterFirst の設定) 資
料
参考リンク
● "RESOLV.CONF(5)" https://linuxjm.osdn.jp/html/LDP_man-pages/man5/resolv.conf.5.html
● "Kubernetes Documentation >..> DNS for Services and Pods" https://kubernetes.io/docs/concepts/services-
networking/dns-pod-service/#srv-records
● GitHub "update docker's resolv.conf file with options ndots:5"
https://github.com/kubernetes/kubernetes/pull/10266
● GREE Engineer's blog "スマホゲームの API サーバにおける EKS の運用事例 > DNS の名前解決に失敗する"
https://labs.gree.jp/blog/2020/01/20271/#anker612
● "Amazon EKS での DNS 障害のトラブルシューティング" https://aws.amazon.com/jp/premiumsupport/knowledge-
center/eks-dns-failure/
● まずは resolv.conf(5) man の options ndots 項を参照のこと
● Kubernetes 固有の問題。ふつうの(?) Linux 環境であれば ndots: 5 が入っていることはそうそう無いので、
curl https://greetech.example.com/ で何も問題ない
● Kubernetes では、SRV レコードによるサービスディスカバリの利便性のためにこういう設定になっている (下記 github
の kubernetes/kubernetes リンクも参照)
● クイズで問題のある例として挙げた方法では、IPv6 が有効な場合 AAAA レコードにも問い合わせを行い、1つの名前解決
だけで 10 以上のクエリが発生する場合がある
# 標準的な resolv.conf (EKS)
nameserver 10.100.0.10
search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
options ndots:5
search リスト、ndots: 5 が特徴
→ 名前に含まれるドットが5より少なければ search リストを順番にためすよ、の意