talked by builderscon tokyo 2019 https://builderscon.io/tokyo/2019/session/18e6c5d7-9bb9-435f-b76d-86ba579b84df

1. なぜ
ディスクレスハイパーバイザに
⾄ったのか [公開版]
株式会社サイバーエージェント
技術本部 プライベートクラウドグループ
Nakanishi Kento @whywaita
builderscon tokyo @ 東京電機⼤学 2019/08/30
!1

2. 諸注意
!2
スライドは後ほどインターネット上で公開します
📸 は控えめにお願いします
Let’s laugh! 😊
盛り上がった賞狙っていきたい、是⾮笑ってください

3. Nakanishi Kento / whywaita
• 株式会社サイバーエージェント 技術本部
プライベートクラウドグループ 開発チーム
• 2019年新卒⼊社 (⼊社して5ヶ⽉経ちました)
• 仕事: OpenStack / Kubernetes ベースの
プライベートクラウドのお守り, 新機能の開発
最近は採⽤回りもやってるので興味ある⽅はお声がけを！
• 趣味: ⾃宅サーバ / ⾃宅インフラ, アニソン
最近趣味で我が家とAS がBGPで繋がりました
!3

4. 会社に記事を書いてもらいました
!4
ref: https://developers.cyberagent.co.jp/blog/archives/ /

5. 記事に対する(知り合いの)反応
!5

6. 記事に対する(知り合いの)反応
!6

7. 記事に対する(知り合いの)反応
!7

8. 記事に対する(知り合いの)反応
!8

9. 記事に対する(知り合いの)反応
!9

10. 記事に対する(知り合いの)反応
!10

11. 記事に対する(知り合いの)反応
新卒です💥😇💥
アイコンはすいません
!11
発表時はまだ
試⽤期間中です！

12. .はじめに
.プライベートクラウドはつらい？
.今までのプライベートクラウド
.ディスクレスハイパーバイザ
.ディスクレスハイパーバイザへの道
.おわりに
!12

13. はじめに
!13

14. 参加者アンケート
•皆さんどのあたりで 仕事 / 研究 / 勉強 してますか？
•データセンター事業者？
•プライベートクラウド部署？
•SRE？インフラエンジニア？
•アプリケーション開発エンジニア？
!14
※アンケート内容は悪⽤しません！※
上から
: : :
ぐらいでした

15. クラウドといえば？
!15

16. クラウドといえば？
!16

17. クラウドといえば？
!17
パブリッククラウドの皆さん

18. プライベートクラウドとは
•パブリッククラウドの逆
•社内の⼈間向けのクラウド基盤
•社外の⽅は利⽤不可
•OSSだとOpenStack, CloudStack
プロプライエタリだとVMWare製品が
⼈気という話を聞いております
!18

19. CAにおけるプライベートクラウド
•社内にプライベートクラウドを⾏っている部署が2つある
•メディア事業部
• メディア事業 （Amebaなど）向け（⼦会社含）の
プライベートクラウド
• 登壇者 (@whywaita) はこちら
•アドテクスタジオ
• 広告事業プロダクト向けのプライベートクラウド
• @amsy さんや @makocchi さんはこちら
!19

20. メディア事業部におけるプライベートクラウド
•2004年ごろからデータセンターの運⽤を開始
•過去はOpenStack Diablo( 年リリース)
や⾃作クラウド(Clover) を本番運⽤
•現在は TKY /TKY /TKY ( . 〜) 運⽤中
•最も新しいTKY はOpenStack Queens
• No Version Upな⽅針
•TKY Compute Node: 台前後
!20

21. プライベートクラウドは
〇〇〇？
!21

22. 皆さんがプライベートクラウドと聞いて思うこと
!22

23. 皆さんがプライベートクラウドと聞いて思うこと
「ああ、あのつらいやつね」
!23

24. 皆さんがプライベートクラウドと聞いて思うこと
「ああ、あのつらいやつね」
「あっ……お疲れ様です」
!24

25. 皆さんがプライベートクラウドと聞いて思うこと
「ああ、あのつらいやつね」
「あっ……お疲れ様です」
「夜寝られてますか？」
!25

26. 皆さんがプライベートクラウドと聞いて思うこと
皆さん根拠もなくつらいと
思っていませんか？
!26

27. 皆さんがプライベートクラウドと聞いて思うこと
真実は……
!27

28. 皆さんがプライベートクラウドと聞いて思うこと
✨つらい！！✨
!28

29. プライベートクラウドつらい物語
•ベンダーから「このconfigで動きます！」
って⾔われたやつが動かない…
•⾼頻度に設定を変更したときになぜか
全てが破壊される…
•/proc/meminfo の計算が合わない…
!29

30. プライベートクラウドつらい物語
!30
MemTotal 256440.12
MemFree 113801.20
MemUsed 142638.92
Active 19244.98
Inactive 5381.35
⼤体Active+Inactive≒Usedのはず… 🤔

31. 皆さんがプライベートクラウドと聞いて思うこと
✨つらい！！✨
!31

32. 皆さんがプライベートクラウドと聞いて思うこと
でも、ちょっと待って🤚
!32

33. 皆さんがプライベートクラウドと聞いて思うこと
結局どこがつらいのか？
!33

34. プライベートクラウドつらいところ
!34
VM OS
アプリケーション
パブリッククラウド プライベートクラウド

35. プライベートクラウドつらいところ
!35
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク

36. プライベートクラウドつらいところ
!36
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
ユーザが意識する
必要のない部分

37. プライベートクラウドつらいところ
これが
Infrastructure as a Service
や！覚えとけ！🤔
!37

38. 余談 - 会社で⼀番好きな絵⽂字
!38

39. 余談 - 会社で⼀番好きな絵⽂字
!39

40. 余談 - 会社で⼀番好きな絵⽂字
🤔
!40
※元ネタはCookPadさんらしいです
https://twitter.com/hiragram/status/

41. 余談 - 会社で⼀番好きな絵⽂字
⾊々あるようだ🤔
!41

42. 余談 - ⾊々ある絵⽂字
!42

43. 余談 - ⾊々ある絵⽂字
!43

44. 余談 - ⾊々ある絵⽂字
!44

45. 余談 - ⾊々ある絵⽂字
🤔
!45

46. 余談 - ⾊々ある絵⽂字
!46
⼀応両⽅あります

47. 閑話休題
!47

48. プライベートクラウドつらいところ
!48
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
つらそうポイント👉

49. その中で
今回お話しするのは
!49

50. プライベートクラウドつらいところ
!50
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
このへん！👉

51. 今までの
プライベートクラウド
!51

52. プライベートクラウドつらいところ
!52
で、結局つらいのは…

53. プライベートクラウドつらいところ
常⽇頃から「物理」を
意識しなければならない
!53
で、結局つらいのは…

54. プライベートクラウドつらいところ
ただ少しでも管理を軽減するため、
我々はディスクレスハイパーバイザに
⼿を出した……
!54

55. プライベートクラウドつらいところ
そう、「⼿を出してしまった」
のである…
!55

56. 突然ですが問題です
!56

57. Q. 物理サーバで
⼀番壊れやすいところは？
!57

58. シンキング🤔タイム
!58

59. 答え
!59

60. 答え
「動く」部分
!60
会場からは「HDD」が出ました。
半分正解！

61. 物理サーバの動く部分
•ストレージ (HDD)
•中の円盤が回転しつづけて動いている
•筐体に付いている冷却⽤ファン
•物理シャーシ内の空気を循環させて
サーバ内のパーツを冷却するために
•NIC (Network Interface Card)
•最近は⾼機能ICが載って冷却⽤ファンが乗るように
•※弊社だとファンレスNICしか使ってませんが……
!61

62. 物理サーバの壊れやすい部分
!62
•ストレージ (HDD)
•中の円盤が回転しつづけて動いている
•筐体に付いている冷却⽤ファン
•物理シャーシ内の空気を循環させて
サーバ内のパーツを冷却するために
•NIC (Network Interface Card)
•最近は⾼機能ICが載って冷却⽤ファンが乗るように
•※弊社だとファンレスNICしか使ってませんが……

63. サーバが壊れるのは⼤変！😫
•予備在庫を払い出さなきゃ……
•どこのIPアドレスが使えるんだっけ？
•ホスト⽤のOSイメージが⼊っている在庫はどれ？
•VM Managerに在庫を認識させなきゃ……
•ちゃんと在庫として⼊ってるのかな？
•あ、保守依頼出すの忘れてた……😇 ※⼀例です
!63

64. サーバが壊れるのは⼤変！😫
•届いたサーバ、在庫として使えるようにしなきゃ
•空いてるポートを探して、接続確認して……
•管理⽤LAN接続ヨシ！ファイバー接続ヨシ！
•BIOSの設定ヨシ！IPMI設定ヨシ！
•⼤体1台セットアップするのに15分ほど要していた
•もちろんその後にOSインストール / 設定確認
•もちろんヨシ！は2名体制
•数百台をセットアップするのにかかる時間は…😱
!64

65. サーバが壊れるのは⼤変！😫
とはいえサーバが壊れることは不可避
→なら、壊れることを許容しよう！
!65

66. ディスクレス
ハイパーバイザ
!66

67. 森羅万象における常
破壊の後には再⽣がある
!67

68. プライベートクラウドにおける常
!68

69. プライベートクラウドにおける常
物理サーバが壊れた後
再⽣をさせる
!69
森羅万象では「ある」ですが、
こちらは「させる」です

70. そもそもなぜ再⽣が⼤変になっているのか
•既にある状態（ステート）と相違ないように
再⽣を⾏う必要がある
•ネットワークバックボーンが持つステート
•ユーザが利⽤しているVMのステート
•ハイパーバイザの持つステート
•出来る限りステートは管理したくない!!!
!70

71. そもそもなぜ再⽣が⼤変になっているのか
•既にある状態（ステート）と相違ないように
再⽣を⾏う必要がある
•ネットワークバックボーンが持つステート
•ユーザが利⽤しているVMのステート
•ハイパーバイザの持つステート
•出来る限りステートは管理したくない!!!
!71

72. ステートを管理しないためには？
•ステートを持つ部分をなくせばいいんだ！
•コンピュートノードにおけるステートを
保存したり管理している部分は？
→ 補助記憶装置 = HDD / SSD / NVMe
•ヨッシャ、全部外すぞ!!!!!!
!72

73. というわけで
!73

74. というわけで
ディスク、はずしました
😊
!74

75. ディスクを外した結果
•コンピュートノードはAll OnMemoryに
•何か問題が発⽣した場合とりあえず
sudo reboot で 🙆
•コントロールプレーンはKubernetesによって管理
•何か問題が発⽣した場合とりあえず
kubectl delete pod -n openstack {all pod}
で 🙆
!75

76. ディスクを外した結果
•物理キッティング時はケーブル刺して電源ポチで
OK!
•正常に在庫追加されると⾃動でシャットダウン
•全部刺して起動させた後、
しばらくしてもシャットダウンしていない
個体だけ確認すれば⼤丈夫に！😊
•物理管理コスト、チェック⼈員のタスク軽減！
!76

77. 在庫登録失敗時
失敗すればSlack通知 & ブートしたまま
!77

78. ディスクを外した結果
めっちゃ管理が楽!!!
!78

79. 要素技術: Kubernetes
•Googleが作ったコンテナ管理基盤
•チーム内での扱いとしては
「Platform for Platform」とよく⾔ってます
•弊チームが管理する全ての物理サーバは
⼤きいクラスタ (global-k s)の Kubernetes
ノードとして管理している
•global-k s で提供サービスを管理したりしている
!79

80. 要素技術: OpenStack
•NASAとRackspaceが作り始めたIaaSソフトウェア
•VMを起動出来たりVolumeを管理できたり etc
•様々な*aaSをOSSで実装されている
•DBaaS, LBaaS, DNSaaS
•様々なコンポーネントがある
•みんな⼤好き MicroServices 😊 😊 😊
•RabbitMQ / Memcached もバリバリ使ってるぞ！
!80

81. 要素技術: OpenStack
•コントロールプレーンやコンピュートノードに
それぞれ必要なプロセスを動作させる必要性
•コントロールプレーン: nova (VM),
cinder (storage), designate (DNS),
horizon(WebUI), keystone(Auth), etc
•コンピュートノード: nova-compute, neutron-
proxy, neutron-openvswitch-agent etc
!81

82. 再⽣可能なハイパーバイザ
•OpenStackコンポーネント群をKubernetesのPodとして
起動させ、Kubernetesによる管理
•Helmを使って⾃家製チャート (openstack-charts) を
フルスクラッチで実装
•在庫からコントロールプレーン / コンピュートノードとして
追加されると、Kubenretesが検知しDaemonSet /
Deployment などで必要なプロセスをコンテナとして起動
•kubeletの追加など、クラスタに組み込む作業はansible
!82

83. 再⽣可能なハイパーバイザ
!83

84. 再⽣可能なハイパーバイザ
!84

85. 再⽣可能なハイパーバイザ
!85
•OpenStackをHelm管理するメリット
•「何かあったら helm delete --purge」
•サクッとOpenStackを作り直せる
• 実際devは何度も⽴て直している
•もちろんデメリットもゼロではない
•設定を⼯夫しないとlivenessProbeに🔪

86. 再⽣可能なハイパーバイザ
ここまでやると
オンメモリ化が⾒えてくる
!86

87. ディスクレスハイパーバイザ
•コンピュートノードは完全なディスクレス
•ユーザのVM⽤ディスクはiSCSI経由で接続
•OSはiPXE経由で起動
•在庫からコンピュートノードとして認識
されていると⾃動起動
•⾃家製ベアメタル管理アプリが全てを管理
(Bearman)
!87

88. Bearmanによる在庫管理
• TKY ⽤に開発されたDjango製アプリケーション
• ⽬的: 運⽤者の作業軽減
• 物理サーバ(Baremetal) における様々を管理
• UUID / hostname
• Flavor
• 起動するOSが切り替わる
• ex: ComputeNode, Software LB
• VLAN / IPMI各種情報 / OS付属 IP address
!88

89. Bearmanによる在庫管理 - 登録編
. iPXEによるブート (CentOS)
. autorun.service が起動
. BIOS / NICのファームウェアバージョンチェック
and アップ (Golang)
. lldpd によって近傍スイッチ情報をチェック
. dmidecode コマンドでHW情報をチェック
. Bearmanに登録 / IPMI設定
. CentOS シャットダウン！
!89

90. Bearmanによる在庫管理 - 登録編
!90
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
初回ブート 1段階⽬OS
firmware-updator
lldpd
vlan-manager
iPXEによって
CentOSのブート
dmidecode

91. Bearmanによる在庫管理 - 登録編
!91
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
autorun.service
により
各種デーモン起動
lldpd
vlan-manager
dmidecode

92. Bearmanによる在庫管理 - 登録編
!92
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
NICやBIOSの
ファームウェア
バージョンアップ
lldpd
vlan-manager
dmidecode

93. Bearmanによる在庫管理 - 登録編
!93
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
近傍スイッチと
やりとり
ポート/状態 sync
lldpd
ToR Switch
vlan-manager
dmidecode

94. Bearmanによる在庫管理 - 登録編
!94
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
NETCONFで情報
取得 / 更新
lldpdと差異確認
lldpd
ToR Switch
vlan-manager
dmidecode

95. Bearmanによる在庫管理 - 登録編
!95
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
HW情報を取得
Bearmanに登録
lldpd
Bearman
By gRPC
vlan-manager
dmidecode

96. Bearmanによる在庫管理 - 登録編
!96
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
Bearmanから
IPMI設定を返答
lldpd
Bearman
By gRPC
vlan-manager
dmidecode

97. Bearmanによる在庫管理 - 登録編
!97
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
Bearmanからの
設定をIPMIに
焼き込み
lldpd
Bearman
vlan-manager
dmidecode

98. Bearmanによる在庫管理 - 登録編
!98
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
在庫登録正常なら
OSシャットダウン
lldpd
Bearman
vlan-manager
dmidecode

99. Bearmanによる在庫管理 - 起動編
!99
. iPXEによるブート (CentOS)
. Firmware / LLDP までは⼀緒
. /proc/cmdline をチェック
. Linux-kernel / initrd をBearmanに聞い
てwget !
. kexec でUbuntuに OSチェンジ！
. ComputeNodeとして起動成功！

100. Bearmanによる在庫管理 - 起動編
!100
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=
append=
初回ブート 1段階⽬OS 2段階⽬OS

101. Bearmanによる在庫管理 - 起動編
!101
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=
append=
初回ブート 1段階⽬OS 2段階⽬OS
autorun.service
までは
在庫登録と⼀緒

102. Bearmanによる在庫管理 - 起動編
!102
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=
append=
初回ブート 1段階⽬OS 2段階⽬OS
Bearmanから
Nodeごとの
Flavorを取得
Bearman

103. Bearmanによる在庫管理 - 起動編
!103
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=
append=
初回ブート 1段階⽬OS 2段階⽬OS
Flavorから
必要なURL群を
取得
Bearman

104. Bearmanによる在庫管理 - 起動編
!104
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=
append=
初回ブート 1段階⽬OS 2段階⽬OS
kexecによって
OSをswitch!

105. Bearmanによる在庫管理 - 起動編
!105
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=
append=
初回ブート 1段階⽬OS 2段階⽬OS
ComputeNode
Flavorなら
Ubuntuが起動

106. [再掲] 在庫登録失敗時
失敗すればSlack通知 & ブートしたまま
!106

107. [再掲] 在庫登録失敗時
IPアドレスが付いてるのでCentOSにSSHできる!!!
!107
👉
※grub rescueみたいなしょぼいシェルではない完全なbash

108. Bearmanによる在庫管理 - 起動編
!108
Real OS (Ubuntu)
2段階⽬OS
ComputeNode
Flavorなら
Ubuntuが起動

109. Bearmanによる在庫管理 - 起動編
!109
Real OS (Ubuntu)
2段階⽬OS
LXD / ansible
で作った
OSイメージ
LDAP
NIC driver
apt repo GPG Key
etc
Docker
kubelet

110. Bearmanによる在庫管理 - 起動編
!110
Ansibleで
JoinNode.yml
Real OS (Ubuntu)
2段階⽬OS
LDAP
NIC driver
apt repo GPG Key
etc
Docker
kubelet

111. Bearmanによる在庫管理 - 起動編
!111
ノードとしてクラスタに
追加されると
各種Podが⾃動起動
Real OS (Ubuntu)
2段階⽬OS
LDAP
NIC driver
apt repo GPG Key
etc
Docker
kubelet
k s-master (物理)k s-master (物理)k s-master (物理)

112. k s-master (物理)k s-master (物理)
Bearmanによる在庫管理 - 起動編
!112
k sのDaemonSetで
ComputeNodeに必要な
プロセスを起動させる
Real OS (Ubuntu)
2段階⽬OS
neutron-proxy
kubelet
k s-master (物理)
nova-compute
neutron-openvswitch-agent
Docker
It’s a MicroServices!!!!😂

113. k s-master (物理)k s-master (物理)
Bearmanによる在庫管理 - 起動編
!113
ComputeNode Podから
OpenStack群に
新規ノードとして追加要求
Real OS (Ubuntu)
2段階⽬OS
neutron-proxy
kubelet
k s-master (物理)
nova-compute
neutron-openvswitch-agent
Docker
k s-master (物理)k s-master (物理)opst-master (コンテナ)

114. Bearmanによる在庫管理 - VM起動編
!114
コントロールプレーンから
VMの作成要求がくる
※VM情報はmasterが持つ
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Pods
k s-master (物理)k s-master (物理)opst-master (コンテナ)

115. k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!115
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレージ
アプライアンス
qemuプロセスを作成し
ストレージをiSCSI経由で
アタッチ
qemuプロセス (VM)

116. k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!116
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレージ
アプライアンス
本環境におけるステート
. VMの構成情報(XML)
. VMのストレージ(OS)
qemuプロセス (VM)

117. k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!117
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレージ
アプライアンス
. VMの構成情報(XML)
qemuプロセス (VM)
. VMのストレージ(OS)

118. k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!118
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレージ
アプライアンス
. VMの構成情報(XML)
qemuプロセス (VM)
. VMのストレージ(OS)
ComputeNodeに
ステート無し！！

119. 再⽣可能なハイパーバイザ
OpenStackノードの
オンメモリ化完了🙆
!119

120. 再⽣可能なハイパーバイザ
OpenStackノードの
オンメモリ化完了🙆
「もはやこれは物理のコンテナ化」
!120

121. 再⽣可能なハイパーバイザ
OpenStackノードの
オンメモリ化完了🙆
「もはやこれは物理のコンテナ化」
!121
「何かあったらsudo rebootだ！」
※rebootするとComputeNode上のVMはシャットダウンされるので、
当然気軽にrebootは⾏っていません

122. その他TKY における仕様
•（プライベートクラウドを作る⼀番の理由ですが）
価格がかなり安い ※残念ながら具体的な価格は🙊
•CPU: Core Mem: GB の整数倍が基本
m .large ( C . GB) が再安価フレーバー
•CPU NUMA制御⼊りスケジューリング
•Over commit なし、ホストCPU占有
•ストレージはベンダーアプライアンス
•超爆速 I/O Read Write可能
!122

123. ディスクレス
ハイパーバイザへの道
!123

124. ようやく本編
どうやって
この部分に⾄ったのか？
!124

125. 話は過去にもどって……
/
!125

126. 話は過去にもどって……
iOS における
ATS (App Transport Security)
の強制化
!126

127. App Transport Security
•iOS開発においてアプリケーションとサービス
(いわばアプリケーションバックエンド)の
セキュアな通信機構
•有効化しておけばよりセキュアな開発が可能
•バックエンドアプリケーションとの通信に
HTTP over SSL (https)が必須
•つまりバックエンド側はHTTPS Listenが必須に
!127理解がざっくりですみません 🙇

128. App Transport Security
•iOS開発においてアプリケーションとサービス
(いわばアプリケーションバックエンド)の
セキュアな通信機構
•有効化しておけばよりセキュアな開発が可能
•バックエンドアプリケーションとの通信に
HTTP over SSL (https)が必須
•つまりバックエンド側はHTTPS Listenが必須に
!128理解がざっくりですみません 🙇

129. プラットフォーム側としては
• Webアプリケーションプラットフォームとして、
ロードバランサーも提供を⾏っているため対応検討
• 「今HTTPな通信をover SSLにしてやればOK？ 🤔」
• ハードウェアアプライアンスLBに対応してもらう？
• アプライアンスはCipher Suiteが⾜りない…
• 「新しく買うにしては⾼いしなあ…」
!129

130. プラットフォーム側としては
ここで気づく
「Nginx並べればいいんじゃね？」
!130

131. プラットフォーム側としては
ここで気づく
「Nginx並べればいいんじゃね？」
→ ディスクレスNginxクラスタ:
sslproxy 爆誕
!131

132. sslproxy
•アプリケーションのSSL終端する君
•設定のマスターはGit管理しておき、コントローラか
らrsyncで設定を投げつけるお⼿軽プロビジョニング
•OS⾃体はPXEブート
•PXEブートのイメージをコントローラに持たせていた
•なにかあったらNginxが起動しているノードを
rebootで🙆
!132
rebootで 🙆
少し前にも聞きましたね！

133. sslproxy
!133
nginx-deploy.sh

134. sslproxyの着想元
!134
どっからこの発想
持ってきたんだ？🤔
⼊社当時の私の疑問

135. sslproxyの着想元
•TKY 版sslproxyはIntel Xeon v によっ
てIntel AVXが改良され、opensslが⾼速化
•NginxのSSLももちろん対象！
•「TKY では新しいの買いたくない…」
•オンボロサーバ有効活⽤のため、
信頼性の低いディスクを抜くと良い？🤔
!135

136. sslproxyの着想元 (後追い)
!136

137. sslproxyの着想元 (後追い)
!137
引⽤: https://www.buffalo.jp/product/detail/faq/wsr- dhpl-c.html
これ

138. sslproxyの着想元 (後追い)
•ルータのブートシーケンスから着想
•POSTを⾏いハードウェアチェック
•圧縮イメージからOSを探索し
RAM上に展開 / 起動
•NVRAMから設定を探索し読み取り
•RAM上に設定を展開しトラフィック転送を
開始
!138
※バッファロー社製家庭⽤ルータがこのシーケンスで
動いているという話ではなく、⼀般的な挙動の説明です

139. sslproxyの着想元
そして
「Nginx並べればいいんじゃね？」
に繋がる
!139

140. その後のオンメモリ運⽤
•sslproxy はtky 後期の制作物
•tky 向けComputeNode構成検証中、最初は
boot領域をiSCSI接続させる構成を検証していた
•なぜかうまく動かず
•「そういえばsslproxyはオンメモリでちゃんと
動いてるな…… 🤔」
•できちゃった ⭐
!140

141. おわりに
!141

142. 現在とこれから
•ご紹介したシステムはTKY として稼働中
•今後数年間は稼働し続ける予定
•コンテナ / オンメモリ化によって踏んだバグも沢⼭
•発表者は配属後最初の1ヶ⽉間 Nova(VM) の
コードを読みました（しんどいぞ！）
•完全な安定稼働に向けてこれからも戦い続けます 😂
•次世代に関しては構想はあるもののまだまだこれから
!142

143. まとめ
. 物理は壊れる、森羅万象における常である
• そのための運⽤コストが⾮常に⾼かった
. 物理障害の対策の1つとして、
ディスクレスなハイパーバイザを運⽤中
• Kubernetes + OpenStackにより実現
• 物理をコンテナ化するのは「気持ちいい」
. なぜディスクレスに辿り着き、選択したか
• 常につらい運⽤から脱却しようとし続ける
!143