Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
なぜ

ディスクレスハイパーバイザに
⾄ったのか [公開版]
株式会社サイバーエージェント

技術本部 プライベートクラウドグループ

Nakanishi Kento @whywaita
builderscon tokyo @ 東京電機⼤学 2...
諸注意
!2
スライドは後ほどインターネット上で公開します
📸 は控えめにお願いします

Let’s laugh! 😊
盛り上がった賞狙っていきたい、是⾮笑ってください
Nakanishi Kento / whywaita
• 株式会社サイバーエージェント 技術本部

プライベートクラウドグループ 開発チーム
• 2019年新卒⼊社 (⼊社して5ヶ⽉経ちました)
• 仕事: OpenStack / Kubern...
会社に記事を書いてもらいました
!4
ref: https://developers.cyberagent.co.jp/blog/archives/ /
記事に対する(知り合いの)反応
!5
記事に対する(知り合いの)反応
!6
記事に対する(知り合いの)反応
!7
記事に対する(知り合いの)反応
!8
記事に対する(知り合いの)反応
!9
記事に対する(知り合いの)反応
!10
記事に対する(知り合いの)反応
新卒です💥😇💥

アイコンはすいません
!11
発表時はまだ

試⽤期間中です!
.はじめに
.プライベートクラウドはつらい?
.今までのプライベートクラウド
.ディスクレスハイパーバイザ
.ディスクレスハイパーバイザへの道
.おわりに
!12
はじめに
!13
参加者アンケート
•皆さんどのあたりで 仕事 / 研究 / 勉強 してますか?
•データセンター事業者?
•プライベートクラウド部署?
•SRE?インフラエンジニア?
•アプリケーション開発エンジニア?
!14
※アンケート内容は悪⽤しません!...
クラウドといえば?
!15
クラウドといえば?
!16
クラウドといえば?
!17
パブリッククラウドの皆さん
プライベートクラウドとは
•パブリッククラウドの逆
•社内の⼈間向けのクラウド基盤
•社外の⽅は利⽤不可
•OSSだとOpenStack, CloudStack

プロプライエタリだとVMWare製品が

⼈気という話を聞いております
!18
CAにおけるプライベートクラウド
•社内にプライベートクラウドを⾏っている部署が2つある
•メディア事業部
• メディア事業 (Amebaなど)向け(⼦会社含)の

プライベートクラウド
• 登壇者 (@whywaita) はこちら
•アドテク...
メディア事業部におけるプライベートクラウド
•2004年ごろからデータセンターの運⽤を開始
•過去はOpenStack Diablo( 年リリース)
や⾃作クラウド(Clover) を本番運⽤
•現在は TKY /TKY /TKY ( . 〜)...
プライベートクラウドは
〇〇〇?
!21
皆さんがプライベートクラウドと聞いて思うこと
!22
皆さんがプライベートクラウドと聞いて思うこと
「ああ、あのつらいやつね」


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

思っていませんか?
!26
皆さんがプライベートクラウドと聞いて思うこと
真実は……
!27
皆さんがプライベートクラウドと聞いて思うこと
✨つらい!!✨
!28
プライベートクラウドつらい物語
•ベンダーから「このconfigで動きます!」

って⾔われたやつが動かない…
•⾼頻度に設定を変更したときになぜか

全てが破壊される…
•/proc/meminfo の計算が合わない…
!29
プライベートクラウドつらい物語
!30
MemTotal 256440.12
MemFree 113801.20
MemUsed 142638.92
Active 19244.98
Inactive 5381.35
⼤体Active+Inact...
皆さんがプライベートクラウドと聞いて思うこと
✨つらい!!✨
!31
皆さんがプライベートクラウドと聞いて思うこと
でも、ちょっと待って🤚
!32
皆さんがプライベートクラウドと聞いて思うこと
結局どこがつらいのか?
!33
プライベートクラウドつらいところ
!34
VM OS
アプリケーション
パブリッククラウド プライベートクラウド
プライベートクラウドつらいところ
!35
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
プライベートクラウドつらいところ
!36
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
ユーザが...
プライベートクラウドつらいところ
これが

Infrastructure as a Service

や!覚えとけ!🤔
!37
余談 - 会社で⼀番好きな絵⽂字
!38
余談 - 会社で⼀番好きな絵⽂字
!39
余談 - 会社で⼀番好きな絵⽂字
🤔
!40
※元ネタはCookPadさんらしいです

https://twitter.com/hiragram/status/
余談 - 会社で⼀番好きな絵⽂字
⾊々あるようだ🤔
!41
余談 - ⾊々ある絵⽂字
!42
余談 - ⾊々ある絵⽂字
!43
余談 - ⾊々ある絵⽂字
!44
余談 - ⾊々ある絵⽂字
🤔
!45
余談 - ⾊々ある絵⽂字
!46
⼀応両⽅あります
閑話休題
!47
プライベートクラウドつらいところ
!48
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
つらそう...
その中で

今回お話しするのは
!49
プライベートクラウドつらいところ
!50
VM OS
アプリケーション
パブリッククラウド
物理サーバ
ネットワーク
物理ラック / 電源
VM Manager
VM OS
アプリケーション
プライベートクラウド
⋮
仮想ネットワーク
このへん...
今までの
プライベートクラウド
!51
プライベートクラウドつらいところ
!52
で、結局つらいのは…
プライベートクラウドつらいところ
常⽇頃から「物理」を

意識しなければならない
!53
で、結局つらいのは…
プライベートクラウドつらいところ
ただ少しでも管理を軽減するため、

我々はディスクレスハイパーバイザに
⼿を出した……
!54
プライベートクラウドつらいところ
そう、「⼿を出してしまった」
のである…
!55
突然ですが問題です
!56
Q. 物理サーバで

⼀番壊れやすいところは?
!57
シンキング🤔タイム
!58
答え

!59
答え

「動く」部分
!60
会場からは「HDD」が出ました。

半分正解!
物理サーバの動く部分
•ストレージ (HDD)
•中の円盤が回転しつづけて動いている
•筐体に付いている冷却⽤ファン
•物理シャーシ内の空気を循環させて

サーバ内のパーツを冷却するために
•NIC (Network Interface Car...
物理サーバの壊れやすい部分
!62
•ストレージ (HDD)
•中の円盤が回転しつづけて動いている
•筐体に付いている冷却⽤ファン
•物理シャーシ内の空気を循環させて

サーバ内のパーツを冷却するために
•NIC (Network Interf...
サーバが壊れるのは⼤変!😫
•予備在庫を払い出さなきゃ……
•どこのIPアドレスが使えるんだっけ?
•ホスト⽤のOSイメージが⼊っている在庫はどれ?
•VM Managerに在庫を認識させなきゃ……
•ちゃんと在庫として⼊ってるのかな?
•あ、...
サーバが壊れるのは⼤変!😫
•届いたサーバ、在庫として使えるようにしなきゃ
•空いてるポートを探して、接続確認して……
•管理⽤LAN接続ヨシ!ファイバー接続ヨシ!
•BIOSの設定ヨシ!IPMI設定ヨシ!
•⼤体1台セットアップするのに15分...
サーバが壊れるのは⼤変!😫
とはいえサーバが壊れることは不可避

→なら、壊れることを許容しよう!
!65
ディスクレス

ハイパーバイザ
!66
森羅万象における常
破壊の後には再⽣がある
!67
プライベートクラウドにおける常
!68
プライベートクラウドにおける常
物理サーバが壊れた後

再⽣をさせる
!69
森羅万象では「ある」ですが、

こちらは「させる」です
そもそもなぜ再⽣が⼤変になっているのか
•既にある状態(ステート)と相違ないように
再⽣を⾏う必要がある
•ネットワークバックボーンが持つステート
•ユーザが利⽤しているVMのステート
•ハイパーバイザの持つステート
•出来る限りステートは管理...
そもそもなぜ再⽣が⼤変になっているのか
•既にある状態(ステート)と相違ないように
再⽣を⾏う必要がある
•ネットワークバックボーンが持つステート
•ユーザが利⽤しているVMのステート
•ハイパーバイザの持つステート
•出来る限りステートは管理...
ステートを管理しないためには?
•ステートを持つ部分をなくせばいいんだ!
•コンピュートノードにおけるステートを

保存したり管理している部分は?

→ 補助記憶装置 = HDD / SSD / NVMe
•ヨッシャ、全部外すぞ!!!!!!
!...
というわけで



!73
というわけで

ディスク、はずしました
😊
!74
ディスクを外した結果
•コンピュートノードはAll OnMemoryに
•何か問題が発⽣した場合とりあえず

sudo reboot で 🙆
•コントロールプレーンはKubernetesによって管理
•何か問題が発⽣した場合とりあえず

kub...
ディスクを外した結果
•物理キッティング時はケーブル刺して電源ポチで
OK!
•正常に在庫追加されると⾃動でシャットダウン
•全部刺して起動させた後、

しばらくしてもシャットダウンしていない

個体だけ確認すれば⼤丈夫に!😊
•物理管理コスト...
在庫登録失敗時
失敗すればSlack通知 & ブートしたまま
!77
ディスクを外した結果
めっちゃ管理が楽!!!
!78
要素技術: Kubernetes
•Googleが作ったコンテナ管理基盤
•チーム内での扱いとしては

「Platform for Platform」とよく⾔ってます
•弊チームが管理する全ての物理サーバは

⼤きいクラスタ (global-k...
要素技術: OpenStack
•NASAとRackspaceが作り始めたIaaSソフトウェア
•VMを起動出来たりVolumeを管理できたり etc
•様々な*aaSをOSSで実装されている
•DBaaS, LBaaS, DNSaaS
•様々...
要素技術: OpenStack
•コントロールプレーンやコンピュートノードに

それぞれ必要なプロセスを動作させる必要性
•コントロールプレーン: nova (VM),
cinder (storage), designate (DNS),

h...
再⽣可能なハイパーバイザ
•OpenStackコンポーネント群をKubernetesのPodとして
起動させ、Kubernetesによる管理
•Helmを使って⾃家製チャート (openstack-charts) を

フルスクラッチで実装
•...
再⽣可能なハイパーバイザ
!83
再⽣可能なハイパーバイザ
!84
再⽣可能なハイパーバイザ
!85
•OpenStackをHelm管理するメリット
•「何かあったら helm delete --purge」
•サクッとOpenStackを作り直せる
• 実際devは何度も⽴て直している
•もちろんデメリットも...
再⽣可能なハイパーバイザ
ここまでやると

オンメモリ化が⾒えてくる
!86
ディスクレスハイパーバイザ
•コンピュートノードは完全なディスクレス
•ユーザのVM⽤ディスクはiSCSI経由で接続
•OSはiPXE経由で起動
•在庫からコンピュートノードとして認識

されていると⾃動起動
•⾃家製ベアメタル管理アプリが全て...
Bearmanによる在庫管理
• TKY ⽤に開発されたDjango製アプリケーション
• ⽬的: 運⽤者の作業軽減
• 物理サーバ(Baremetal) における様々を管理
• UUID / hostname
• Flavor
• 起動するO...
Bearmanによる在庫管理 - 登録編
. iPXEによるブート (CentOS)
. autorun.service が起動
. BIOS / NICのファームウェアバージョンチェック
and アップ (Golang)
. lldpd によ...
Bearmanによる在庫管理 - 登録編
!90
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
初回ブート 1段階⽬OS
firmware-updator
lldpd
vlan-ma...
Bearmanによる在庫管理 - 登録編
!91
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
autorun.servi...
Bearmanによる在庫管理 - 登録編
!92
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
NICやBIOSの
ファー...
Bearmanによる在庫管理 - 登録編
!93
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
近傍スイッチと

やりとり...
Bearmanによる在庫管理 - 登録編
!94
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
NETCONFで情報
取得...
Bearmanによる在庫管理 - 登録編
!95
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
HW情報を取得

Bear...
Bearmanによる在庫管理 - 登録編
!96
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
Bearmanから
IPM...
Bearmanによる在庫管理 - 登録編
!97
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
Bearmanからの

設...
Bearmanによる在庫管理 - 登録編
!98
iPXE CentOS
kernel=
initramfs=
append=
autorun.service
firmware-updator
初回ブート 1段階⽬OS
在庫登録正常なら
OSシャ...
Bearmanによる在庫管理 - 起動編
!99
. iPXEによるブート (CentOS)
. Firmware / LLDP までは⼀緒
. /proc/cmdline をチェック
. Linux-kernel / initrd をBear...
Bearmanによる在庫管理 - 起動編
!100
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=...
Bearmanによる在庫管理 - 起動編
!101
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=...
Bearmanによる在庫管理 - 起動編
!102
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=...
Bearmanによる在庫管理 - 起動編
!103
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=...
Bearmanによる在庫管理 - 起動編
!104
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=...
Bearmanによる在庫管理 - 起動編
!105
iPXE CentOS Real OS (Ubuntu)
kernel=
initramfs=
append=
autorun.service
kexec
kernel=
initramfs=...
[再掲] 在庫登録失敗時
失敗すればSlack通知 & ブートしたまま
!106
[再掲] 在庫登録失敗時
IPアドレスが付いてるのでCentOSにSSHできる!!!
!107
👉
※grub rescueみたいなしょぼいシェルではない完全なbash
Bearmanによる在庫管理 - 起動編
!108
Real OS (Ubuntu)
2段階⽬OS
ComputeNode
Flavorなら
Ubuntuが起動
Bearmanによる在庫管理 - 起動編
!109
Real OS (Ubuntu)
2段階⽬OS
LXD / ansible

で作った

OSイメージ
LDAP
NIC driver
apt repo GPG Key
etc
Docker
...
Bearmanによる在庫管理 - 起動編
!110
Ansibleで
JoinNode.yml
Real OS (Ubuntu)
2段階⽬OS
LDAP
NIC driver
apt repo GPG Key
etc
Docker
kubelet
Bearmanによる在庫管理 - 起動編
!111
ノードとしてクラスタに

追加されると

各種Podが⾃動起動
Real OS (Ubuntu)
2段階⽬OS
LDAP
NIC driver
apt repo GPG Key
etc
Doc...
k s-master (物理)k s-master (物理)
Bearmanによる在庫管理 - 起動編
!112
k sのDaemonSetで

ComputeNodeに必要な

プロセスを起動させる
Real OS (Ubuntu)
2段階⽬...
k s-master (物理)k s-master (物理)
Bearmanによる在庫管理 - 起動編
!113
ComputeNode Podから
OpenStack群に

新規ノードとして追加要求
Real OS (Ubuntu)
2段階⽬...
Bearmanによる在庫管理 - VM起動編
!114
コントロールプレーンから
VMの作成要求がくる

※VM情報はmasterが持つ
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Pods
k s-master (...
k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!115
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレー...
k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!116
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレー...
k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!117
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレー...
k s-master (物理)
Bearmanによる在庫管理 - VM起動編
!118
Real OS (Ubuntu)
2段階⽬OS
ComputeNode Podsk s-master (物理)opst-master (コンテナ)
ストレー...
再⽣可能なハイパーバイザ
OpenStackノードの
オンメモリ化完了🙆

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

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

「もはやこれは物理のコンテナ化」
!121
「何かあったらsudo rebootだ!」
※rebootするとComputeNode上のVMはシャットダウンされるので、
...
その他TKY における仕様
•(プライベートクラウドを作る⼀番の理由ですが)

価格がかなり安い ※残念ながら具体的な価格は🙊
•CPU: Core Mem: GB の整数倍が基本

m .large ( C . GB) が再安価フレーバー
•...
ディスクレス

ハイパーバイザへの道
!123
ようやく本編
どうやって

この部分に⾄ったのか?
!124
話は過去にもどって……
/
!125
話は過去にもどって……
iOS における

ATS (App Transport Security)
の強制化
!126
App Transport Security
•iOS開発においてアプリケーションとサービス

(いわばアプリケーションバックエンド)の

セキュアな通信機構
•有効化しておけばよりセキュアな開発が可能
•バックエンドアプリケーションとの通信に...
App Transport Security
•iOS開発においてアプリケーションとサービス

(いわばアプリケーションバックエンド)の

セキュアな通信機構
•有効化しておけばよりセキュアな開発が可能
•バックエンドアプリケーションとの通信に...
プラットフォーム側としては
• Webアプリケーションプラットフォームとして、

ロードバランサーも提供を⾏っているため対応検討
• 「今HTTPな通信をover SSLにしてやればOK? 🤔」
• ハードウェアアプライアンスLBに対応してもら...
プラットフォーム側としては
ここで気づく

「Nginx並べればいいんじゃね?」


!130
プラットフォーム側としては
ここで気づく

「Nginx並べればいいんじゃね?」
→ ディスクレスNginxクラスタ:
sslproxy 爆誕
!131
sslproxy
•アプリケーションのSSL終端する君
•設定のマスターはGit管理しておき、コントローラか
らrsyncで設定を投げつけるお⼿軽プロビジョニング
•OS⾃体はPXEブート
•PXEブートのイメージをコントローラに持たせていた
...
sslproxy
!133
nginx-deploy.sh
sslproxyの着想元
!134
どっからこの発想

持ってきたんだ?🤔
⼊社当時の私の疑問
sslproxyの着想元
•TKY 版sslproxyはIntel Xeon v によっ
てIntel AVXが改良され、opensslが⾼速化
•NginxのSSLももちろん対象!
•「TKY では新しいの買いたくない…」
•オンボロサーバ有...
sslproxyの着想元 (後追い)
!136
sslproxyの着想元 (後追い)
!137
引⽤: https://www.buffalo.jp/product/detail/faq/wsr- dhpl-c.html
これ
sslproxyの着想元 (後追い)
•ルータのブートシーケンスから着想
•POSTを⾏いハードウェアチェック
•圧縮イメージからOSを探索し

RAM上に展開 / 起動
•NVRAMから設定を探索し読み取り
•RAM上に設定を展開しトラフィッ...
sslproxyの着想元
そして

「Nginx並べればいいんじゃね?」

に繋がる
!139
その後のオンメモリ運⽤
•sslproxy はtky 後期の制作物
•tky 向けComputeNode構成検証中、最初は
boot領域をiSCSI接続させる構成を検証していた
•なぜかうまく動かず
•「そういえばsslproxyはオンメモリで...
おわりに
!141
現在とこれから
•ご紹介したシステムはTKY として稼働中
•今後数年間は稼働し続ける予定
•コンテナ / オンメモリ化によって踏んだバグも沢⼭
•発表者は配属後最初の1ヶ⽉間 Nova(VM) の

コードを読みました(しんどいぞ!)
•完全...
まとめ
. 物理は壊れる、森羅万象における常である
• そのための運⽤コストが⾮常に⾼かった
. 物理障害の対策の1つとして、

ディスクレスなハイパーバイザを運⽤中
• Kubernetes + OpenStackにより実現
• 物理をコンテ...
Upcoming SlideShare
Loading in …5
×

なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builderscon

3,186 views

Published on

talked by builderscon tokyo 2019

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

Published in: Technology
  • Be the first to comment

なぜディスクレスハイパーバイザに至ったのか / Why did we select to the diskless hypervisor? #builderscon

  1. 1. なぜ
 ディスクレスハイパーバイザに ⾄ったのか [公開版] 株式会社サイバーエージェント
 技術本部 プライベートクラウドグループ
 Nakanishi Kento @whywaita builderscon tokyo @ 東京電機⼤学 2019/08/30 !1
  2. 2. 諸注意 !2 スライドは後ほどインターネット上で公開します 📸 は控えめにお願いします
 Let’s laugh! 😊 盛り上がった賞狙っていきたい、是⾮笑ってください
  3. 3. Nakanishi Kento / whywaita • 株式会社サイバーエージェント 技術本部
 プライベートクラウドグループ 開発チーム • 2019年新卒⼊社 (⼊社して5ヶ⽉経ちました) • 仕事: OpenStack / Kubernetes ベースの
 プライベートクラウドのお守り, 新機能の開発 最近は採⽤回りもやってるので興味ある⽅はお声がけを! • 趣味: ⾃宅サーバ / ⾃宅インフラ, アニソン 最近趣味で我が家とAS がBGPで繋がりました !3
  4. 4. 会社に記事を書いてもらいました !4 ref: https://developers.cyberagent.co.jp/blog/archives/ /
  5. 5. 記事に対する(知り合いの)反応 !5
  6. 6. 記事に対する(知り合いの)反応 !6
  7. 7. 記事に対する(知り合いの)反応 !7
  8. 8. 記事に対する(知り合いの)反応 !8
  9. 9. 記事に対する(知り合いの)反応 !9
  10. 10. 記事に対する(知り合いの)反応 !10
  11. 11. 記事に対する(知り合いの)反応 新卒です💥😇💥
 アイコンはすいません !11 発表時はまだ
 試⽤期間中です!
  12. 12. .はじめに .プライベートクラウドはつらい? .今までのプライベートクラウド .ディスクレスハイパーバイザ .ディスクレスハイパーバイザへの道 .おわりに !12
  13. 13. はじめに !13
  14. 14. 参加者アンケート •皆さんどのあたりで 仕事 / 研究 / 勉強 してますか? •データセンター事業者? •プライベートクラウド部署? •SRE?インフラエンジニア? •アプリケーション開発エンジニア? !14 ※アンケート内容は悪⽤しません!※ 上から
 : : : 
 ぐらいでした
  15. 15. クラウドといえば? !15
  16. 16. クラウドといえば? !16
  17. 17. クラウドといえば? !17 パブリッククラウドの皆さん
  18. 18. プライベートクラウドとは •パブリッククラウドの逆 •社内の⼈間向けのクラウド基盤 •社外の⽅は利⽤不可 •OSSだとOpenStack, CloudStack
 プロプライエタリだとVMWare製品が
 ⼈気という話を聞いております !18
  19. 19. CAにおけるプライベートクラウド •社内にプライベートクラウドを⾏っている部署が2つある •メディア事業部 • メディア事業 (Amebaなど)向け(⼦会社含)の
 プライベートクラウド • 登壇者 (@whywaita) はこちら •アドテクスタジオ • 広告事業プロダクト向けのプライベートクラウド • @amsy さんや @makocchi さんはこちら !19
  20. 20. メディア事業部におけるプライベートクラウド •2004年ごろからデータセンターの運⽤を開始 •過去はOpenStack Diablo( 年リリース) や⾃作クラウド(Clover) を本番運⽤ •現在は TKY /TKY /TKY ( . 〜) 運⽤中 •最も新しいTKY はOpenStack Queens • No Version Upな⽅針 •TKY Compute Node: 台前後 !20
  21. 21. プライベートクラウドは 〇〇〇? !21
  22. 22. 皆さんがプライベートクラウドと聞いて思うこと !22
  23. 23. 皆さんがプライベートクラウドと聞いて思うこと 「ああ、あのつらいやつね」 
 !23
  24. 24. 皆さんがプライベートクラウドと聞いて思うこと 「ああ、あのつらいやつね」 「あっ……お疲れ様です」 !24
  25. 25. 皆さんがプライベートクラウドと聞いて思うこと 「ああ、あのつらいやつね」 「あっ……お疲れ様です」 「夜寝られてますか?」 !25
  26. 26. 皆さんがプライベートクラウドと聞いて思うこと 皆さん根拠もなくつらいと
 思っていませんか? !26
  27. 27. 皆さんがプライベートクラウドと聞いて思うこと 真実は…… !27
  28. 28. 皆さんがプライベートクラウドと聞いて思うこと ✨つらい!!✨ !28
  29. 29. プライベートクラウドつらい物語 •ベンダーから「このconfigで動きます!」
 って⾔われたやつが動かない… •⾼頻度に設定を変更したときになぜか
 全てが破壊される… •/proc/meminfo の計算が合わない… !29
  30. 30. プライベートクラウドつらい物語 !30 MemTotal 256440.12 MemFree 113801.20 MemUsed 142638.92 Active 19244.98 Inactive 5381.35 ⼤体Active+Inactive≒Usedのはず… 🤔
  31. 31. 皆さんがプライベートクラウドと聞いて思うこと ✨つらい!!✨ !31
  32. 32. 皆さんがプライベートクラウドと聞いて思うこと でも、ちょっと待って🤚 !32
  33. 33. 皆さんがプライベートクラウドと聞いて思うこと 結局どこがつらいのか? !33
  34. 34. プライベートクラウドつらいところ !34 VM OS アプリケーション パブリッククラウド プライベートクラウド
  35. 35. プライベートクラウドつらいところ !35 VM OS アプリケーション パブリッククラウド 物理サーバ ネットワーク 物理ラック / 電源 VM Manager VM OS アプリケーション プライベートクラウド ⋮ 仮想ネットワーク
  36. 36. プライベートクラウドつらいところ !36 VM OS アプリケーション パブリッククラウド 物理サーバ ネットワーク 物理ラック / 電源 VM Manager VM OS アプリケーション プライベートクラウド ⋮ 仮想ネットワーク ユーザが意識する
 必要のない部分
  37. 37. プライベートクラウドつらいところ これが
 Infrastructure as a Service
 や!覚えとけ!🤔 !37
  38. 38. 余談 - 会社で⼀番好きな絵⽂字 !38
  39. 39. 余談 - 会社で⼀番好きな絵⽂字 !39
  40. 40. 余談 - 会社で⼀番好きな絵⽂字 🤔 !40 ※元ネタはCookPadさんらしいです
 https://twitter.com/hiragram/status/
  41. 41. 余談 - 会社で⼀番好きな絵⽂字 ⾊々あるようだ🤔 !41
  42. 42. 余談 - ⾊々ある絵⽂字 !42
  43. 43. 余談 - ⾊々ある絵⽂字 !43
  44. 44. 余談 - ⾊々ある絵⽂字 !44
  45. 45. 余談 - ⾊々ある絵⽂字 🤔 !45
  46. 46. 余談 - ⾊々ある絵⽂字 !46 ⼀応両⽅あります
  47. 47. 閑話休題 !47
  48. 48. プライベートクラウドつらいところ !48 VM OS アプリケーション パブリッククラウド 物理サーバ ネットワーク 物理ラック / 電源 VM Manager VM OS アプリケーション プライベートクラウド ⋮ 仮想ネットワーク つらそうポイント👉
  49. 49. その中で
 今回お話しするのは !49
  50. 50. プライベートクラウドつらいところ !50 VM OS アプリケーション パブリッククラウド 物理サーバ ネットワーク 物理ラック / 電源 VM Manager VM OS アプリケーション プライベートクラウド ⋮ 仮想ネットワーク このへん!👉
  51. 51. 今までの プライベートクラウド !51
  52. 52. プライベートクラウドつらいところ !52 で、結局つらいのは…
  53. 53. プライベートクラウドつらいところ 常⽇頃から「物理」を
 意識しなければならない !53 で、結局つらいのは…
  54. 54. プライベートクラウドつらいところ ただ少しでも管理を軽減するため、
 我々はディスクレスハイパーバイザに ⼿を出した…… !54
  55. 55. プライベートクラウドつらいところ そう、「⼿を出してしまった」 のである… !55
  56. 56. 突然ですが問題です !56
  57. 57. Q. 物理サーバで
 ⼀番壊れやすいところは? !57
  58. 58. シンキング🤔タイム !58
  59. 59. 答え
 !59
  60. 60. 答え
 「動く」部分 !60 会場からは「HDD」が出ました。
 半分正解!
  61. 61. 物理サーバの動く部分 •ストレージ (HDD) •中の円盤が回転しつづけて動いている •筐体に付いている冷却⽤ファン •物理シャーシ内の空気を循環させて
 サーバ内のパーツを冷却するために •NIC (Network Interface Card) •最近は⾼機能ICが載って冷却⽤ファンが乗るように •※弊社だとファンレスNICしか使ってませんが…… !61
  62. 62. 物理サーバの壊れやすい部分 !62 •ストレージ (HDD) •中の円盤が回転しつづけて動いている •筐体に付いている冷却⽤ファン •物理シャーシ内の空気を循環させて
 サーバ内のパーツを冷却するために •NIC (Network Interface Card) •最近は⾼機能ICが載って冷却⽤ファンが乗るように •※弊社だとファンレスNICしか使ってませんが……
  63. 63. サーバが壊れるのは⼤変!😫 •予備在庫を払い出さなきゃ…… •どこのIPアドレスが使えるんだっけ? •ホスト⽤のOSイメージが⼊っている在庫はどれ? •VM Managerに在庫を認識させなきゃ…… •ちゃんと在庫として⼊ってるのかな? •あ、保守依頼出すの忘れてた……😇 ※⼀例です !63
  64. 64. サーバが壊れるのは⼤変!😫 •届いたサーバ、在庫として使えるようにしなきゃ •空いてるポートを探して、接続確認して…… •管理⽤LAN接続ヨシ!ファイバー接続ヨシ! •BIOSの設定ヨシ!IPMI設定ヨシ! •⼤体1台セットアップするのに15分ほど要していた •もちろんその後にOSインストール / 設定確認 •もちろんヨシ!は2名体制 •数百台をセットアップするのにかかる時間は…😱 !64
  65. 65. サーバが壊れるのは⼤変!😫 とはいえサーバが壊れることは不可避
 →なら、壊れることを許容しよう! !65
  66. 66. ディスクレス
 ハイパーバイザ !66
  67. 67. 森羅万象における常 破壊の後には再⽣がある !67
  68. 68. プライベートクラウドにおける常 !68
  69. 69. プライベートクラウドにおける常 物理サーバが壊れた後
 再⽣をさせる !69 森羅万象では「ある」ですが、
 こちらは「させる」です
  70. 70. そもそもなぜ再⽣が⼤変になっているのか •既にある状態(ステート)と相違ないように 再⽣を⾏う必要がある •ネットワークバックボーンが持つステート •ユーザが利⽤しているVMのステート •ハイパーバイザの持つステート •出来る限りステートは管理したくない!!! !70
  71. 71. そもそもなぜ再⽣が⼤変になっているのか •既にある状態(ステート)と相違ないように 再⽣を⾏う必要がある •ネットワークバックボーンが持つステート •ユーザが利⽤しているVMのステート •ハイパーバイザの持つステート •出来る限りステートは管理したくない!!! !71
  72. 72. ステートを管理しないためには? •ステートを持つ部分をなくせばいいんだ! •コンピュートノードにおけるステートを
 保存したり管理している部分は?
 → 補助記憶装置 = HDD / SSD / NVMe •ヨッシャ、全部外すぞ!!!!!! !72
  73. 73. というわけで
 
 !73
  74. 74. というわけで
 ディスク、はずしました 😊 !74
  75. 75. ディスクを外した結果 •コンピュートノードはAll OnMemoryに •何か問題が発⽣した場合とりあえず
 sudo reboot で 🙆 •コントロールプレーンはKubernetesによって管理 •何か問題が発⽣した場合とりあえず
 kubectl delete pod -n openstack {all pod}
 で 🙆 !75
  76. 76. ディスクを外した結果 •物理キッティング時はケーブル刺して電源ポチで OK! •正常に在庫追加されると⾃動でシャットダウン •全部刺して起動させた後、
 しばらくしてもシャットダウンしていない
 個体だけ確認すれば⼤丈夫に!😊 •物理管理コスト、チェック⼈員のタスク軽減! !76
  77. 77. 在庫登録失敗時 失敗すればSlack通知 & ブートしたまま !77
  78. 78. ディスクを外した結果 めっちゃ管理が楽!!! !78
  79. 79. 要素技術: Kubernetes •Googleが作ったコンテナ管理基盤 •チーム内での扱いとしては
 「Platform for Platform」とよく⾔ってます •弊チームが管理する全ての物理サーバは
 ⼤きいクラスタ (global-k s)の Kubernetes  ノードとして管理している •global-k s で提供サービスを管理したりしている !79
  80. 80. 要素技術: OpenStack •NASAとRackspaceが作り始めたIaaSソフトウェア •VMを起動出来たりVolumeを管理できたり etc •様々な*aaSをOSSで実装されている •DBaaS, LBaaS, DNSaaS •様々なコンポーネントがある •みんな⼤好き MicroServices 😊 😊 😊 •RabbitMQ / Memcached もバリバリ使ってるぞ! !80
  81. 81. 要素技術: OpenStack •コントロールプレーンやコンピュートノードに
 それぞれ必要なプロセスを動作させる必要性 •コントロールプレーン: nova (VM), cinder (storage), designate (DNS),
 horizon(WebUI), keystone(Auth), etc •コンピュートノード: nova-compute, neutron- proxy, neutron-openvswitch-agent etc !81
  82. 82. 再⽣可能なハイパーバイザ •OpenStackコンポーネント群をKubernetesのPodとして 起動させ、Kubernetesによる管理 •Helmを使って⾃家製チャート (openstack-charts) を
 フルスクラッチで実装 •在庫からコントロールプレーン / コンピュートノードとして
 追加されると、Kubenretesが検知しDaemonSet / Deployment などで必要なプロセスをコンテナとして起動 •kubeletの追加など、クラスタに組み込む作業はansible !82
  83. 83. 再⽣可能なハイパーバイザ !83
  84. 84. 再⽣可能なハイパーバイザ !84
  85. 85. 再⽣可能なハイパーバイザ !85 •OpenStackをHelm管理するメリット •「何かあったら helm delete --purge」 •サクッとOpenStackを作り直せる • 実際devは何度も⽴て直している •もちろんデメリットもゼロではない •設定を⼯夫しないとlivenessProbeに🔪
  86. 86. 再⽣可能なハイパーバイザ ここまでやると
 オンメモリ化が⾒えてくる !86
  87. 87. ディスクレスハイパーバイザ •コンピュートノードは完全なディスクレス •ユーザのVM⽤ディスクはiSCSI経由で接続 •OSはiPXE経由で起動 •在庫からコンピュートノードとして認識
 されていると⾃動起動 •⾃家製ベアメタル管理アプリが全てを管理 (Bearman) !87
  88. 88. Bearmanによる在庫管理 • TKY ⽤に開発されたDjango製アプリケーション • ⽬的: 運⽤者の作業軽減 • 物理サーバ(Baremetal) における様々を管理 • UUID / hostname • Flavor • 起動するOSが切り替わる • ex: ComputeNode, Software LB • VLAN / IPMI各種情報 / OS付属 IP address !88
  89. 89. Bearmanによる在庫管理 - 登録編 . iPXEによるブート (CentOS) . autorun.service が起動 . BIOS / NICのファームウェアバージョンチェック and アップ (Golang) . lldpd によって近傍スイッチ情報をチェック . dmidecode コマンドでHW情報をチェック . Bearmanに登録 / IPMI設定 . CentOS シャットダウン! !89
  90. 90. Bearmanによる在庫管理 - 登録編 !90 iPXE CentOS kernel= initramfs= append= autorun.service 初回ブート 1段階⽬OS firmware-updator lldpd vlan-manager iPXEによって
 CentOSのブート dmidecode
  91. 91. Bearmanによる在庫管理 - 登録編 !91 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS autorun.service
 により
 各種デーモン起動 lldpd vlan-manager dmidecode
  92. 92. Bearmanによる在庫管理 - 登録編 !92 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS NICやBIOSの ファームウェア
 バージョンアップ lldpd vlan-manager dmidecode
  93. 93. Bearmanによる在庫管理 - 登録編 !93 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS 近傍スイッチと
 やりとり
 ポート/状態 sync lldpd ToR Switch vlan-manager dmidecode
  94. 94. Bearmanによる在庫管理 - 登録編 !94 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS NETCONFで情報 取得 / 更新 lldpdと差異確認 lldpd ToR Switch vlan-manager dmidecode
  95. 95. Bearmanによる在庫管理 - 登録編 !95 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS HW情報を取得
 Bearmanに登録 lldpd Bearman By gRPC vlan-manager dmidecode
  96. 96. Bearmanによる在庫管理 - 登録編 !96 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS Bearmanから IPMI設定を返答 lldpd Bearman By gRPC vlan-manager dmidecode
  97. 97. Bearmanによる在庫管理 - 登録編 !97 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS Bearmanからの
 設定をIPMIに
 焼き込み lldpd Bearman vlan-manager dmidecode
  98. 98. Bearmanによる在庫管理 - 登録編 !98 iPXE CentOS kernel= initramfs= append= autorun.service firmware-updator 初回ブート 1段階⽬OS 在庫登録正常なら OSシャットダウン lldpd Bearman vlan-manager dmidecode
  99. 99. Bearmanによる在庫管理 - 起動編 !99 . iPXEによるブート (CentOS) . Firmware / LLDP までは⼀緒 . /proc/cmdline をチェック . Linux-kernel / initrd をBearmanに聞い てwget ! . kexec でUbuntuに OSチェンジ! . ComputeNodeとして起動成功!
  100. 100. Bearmanによる在庫管理 - 起動編 !100 iPXE CentOS Real OS (Ubuntu) kernel= initramfs= append= autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS
  101. 101. Bearmanによる在庫管理 - 起動編 !101 iPXE CentOS Real OS (Ubuntu) kernel= initramfs= append= autorun.service kexec kernel= initramfs= append= 初回ブート 1段階⽬OS 2段階⽬OS autorun.service
 までは
 在庫登録と⼀緒
  102. 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. 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. 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. 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. 106. [再掲] 在庫登録失敗時 失敗すればSlack通知 & ブートしたまま !106
  107. 107. [再掲] 在庫登録失敗時 IPアドレスが付いてるのでCentOSにSSHできる!!! !107 👉 ※grub rescueみたいなしょぼいシェルではない完全なbash
  108. 108. Bearmanによる在庫管理 - 起動編 !108 Real OS (Ubuntu) 2段階⽬OS ComputeNode Flavorなら Ubuntuが起動
  109. 109. Bearmanによる在庫管理 - 起動編 !109 Real OS (Ubuntu) 2段階⽬OS LXD / ansible
 で作った
 OSイメージ LDAP NIC driver apt repo GPG Key etc Docker kubelet
  110. 110. Bearmanによる在庫管理 - 起動編 !110 Ansibleで JoinNode.yml Real OS (Ubuntu) 2段階⽬OS LDAP NIC driver apt repo GPG Key etc Docker kubelet
  111. 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. 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. 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. 114. Bearmanによる在庫管理 - VM起動編 !114 コントロールプレーンから VMの作成要求がくる
 ※VM情報はmasterが持つ Real OS (Ubuntu) 2段階⽬OS ComputeNode Pods k s-master (物理)k s-master (物理)opst-master (コンテナ)
  115. 115. k s-master (物理) Bearmanによる在庫管理 - VM起動編 !115 Real OS (Ubuntu) 2段階⽬OS ComputeNode Podsk s-master (物理)opst-master (コンテナ) ストレージ
 アプライアンス qemuプロセスを作成し
 ストレージをiSCSI経由で
 アタッチ qemuプロセス (VM)
  116. 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. 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. 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. 119. 再⽣可能なハイパーバイザ OpenStackノードの オンメモリ化完了🙆
 !119
  120. 120. 再⽣可能なハイパーバイザ OpenStackノードの オンメモリ化完了🙆
 「もはやこれは物理のコンテナ化」 !120
  121. 121. 再⽣可能なハイパーバイザ OpenStackノードの オンメモリ化完了🙆
 「もはやこれは物理のコンテナ化」 !121 「何かあったらsudo rebootだ!」 ※rebootするとComputeNode上のVMはシャットダウンされるので、  当然気軽にrebootは⾏っていません
  122. 122. その他TKY における仕様 •(プライベートクラウドを作る⼀番の理由ですが)
 価格がかなり安い ※残念ながら具体的な価格は🙊 •CPU: Core Mem: GB の整数倍が基本
 m .large ( C . GB) が再安価フレーバー •CPU NUMA制御⼊りスケジューリング •Over commit なし、ホストCPU占有 •ストレージはベンダーアプライアンス •超爆速 I/O Read Write可能 !122
  123. 123. ディスクレス
 ハイパーバイザへの道 !123
  124. 124. ようやく本編 どうやって
 この部分に⾄ったのか? !124
  125. 125. 話は過去にもどって…… / !125
  126. 126. 話は過去にもどって…… iOS における
 ATS (App Transport Security) の強制化 !126
  127. 127. App Transport Security •iOS開発においてアプリケーションとサービス
 (いわばアプリケーションバックエンド)の
 セキュアな通信機構 •有効化しておけばよりセキュアな開発が可能 •バックエンドアプリケーションとの通信に
 HTTP over SSL (https)が必須 •つまりバックエンド側はHTTPS Listenが必須に !127理解がざっくりですみません 🙇
  128. 128. App Transport Security •iOS開発においてアプリケーションとサービス
 (いわばアプリケーションバックエンド)の
 セキュアな通信機構 •有効化しておけばよりセキュアな開発が可能 •バックエンドアプリケーションとの通信に
 HTTP over SSL (https)が必須 •つまりバックエンド側はHTTPS Listenが必須に !128理解がざっくりですみません 🙇
  129. 129. プラットフォーム側としては • Webアプリケーションプラットフォームとして、
 ロードバランサーも提供を⾏っているため対応検討 • 「今HTTPな通信をover SSLにしてやればOK? 🤔」 • ハードウェアアプライアンスLBに対応してもらう? • アプライアンスはCipher Suiteが⾜りない… • 「新しく買うにしては⾼いしなあ…」 !129
  130. 130. プラットフォーム側としては ここで気づく
 「Nginx並べればいいんじゃね?」 
 !130
  131. 131. プラットフォーム側としては ここで気づく
 「Nginx並べればいいんじゃね?」 → ディスクレスNginxクラスタ: sslproxy 爆誕 !131
  132. 132. sslproxy •アプリケーションのSSL終端する君 •設定のマスターはGit管理しておき、コントローラか らrsyncで設定を投げつけるお⼿軽プロビジョニング •OS⾃体はPXEブート •PXEブートのイメージをコントローラに持たせていた •なにかあったらNginxが起動しているノードを rebootで🙆 !132 rebootで 🙆 
 少し前にも聞きましたね!
  133. 133. sslproxy !133 nginx-deploy.sh
  134. 134. sslproxyの着想元 !134 どっからこの発想
 持ってきたんだ?🤔 ⼊社当時の私の疑問
  135. 135. sslproxyの着想元 •TKY 版sslproxyはIntel Xeon v によっ てIntel AVXが改良され、opensslが⾼速化 •NginxのSSLももちろん対象! •「TKY では新しいの買いたくない…」 •オンボロサーバ有効活⽤のため、
 信頼性の低いディスクを抜くと良い?🤔 !135
  136. 136. sslproxyの着想元 (後追い) !136
  137. 137. sslproxyの着想元 (後追い) !137 引⽤: https://www.buffalo.jp/product/detail/faq/wsr- dhpl-c.html これ
  138. 138. sslproxyの着想元 (後追い) •ルータのブートシーケンスから着想 •POSTを⾏いハードウェアチェック •圧縮イメージからOSを探索し
 RAM上に展開 / 起動 •NVRAMから設定を探索し読み取り •RAM上に設定を展開しトラフィック転送を 開始 !138 ※バッファロー社製家庭⽤ルータがこのシーケンスで
 動いているという話ではなく、⼀般的な挙動の説明です
  139. 139. sslproxyの着想元 そして
 「Nginx並べればいいんじゃね?」
 に繋がる !139
  140. 140. その後のオンメモリ運⽤ •sslproxy はtky 後期の制作物 •tky 向けComputeNode構成検証中、最初は boot領域をiSCSI接続させる構成を検証していた •なぜかうまく動かず •「そういえばsslproxyはオンメモリでちゃんと
  動いてるな…… 🤔」 •できちゃった ⭐ !140
  141. 141. おわりに !141
  142. 142. 現在とこれから •ご紹介したシステムはTKY として稼働中 •今後数年間は稼働し続ける予定 •コンテナ / オンメモリ化によって踏んだバグも沢⼭ •発表者は配属後最初の1ヶ⽉間 Nova(VM) の
 コードを読みました(しんどいぞ!) •完全な安定稼働に向けてこれからも戦い続けます 😂 •次世代に関しては構想はあるもののまだまだこれから !142
  143. 143. まとめ . 物理は壊れる、森羅万象における常である • そのための運⽤コストが⾮常に⾼かった . 物理障害の対策の1つとして、
 ディスクレスなハイパーバイザを運⽤中 • Kubernetes + OpenStackにより実現 • 物理をコンテナ化するのは「気持ちいい」 . なぜディスクレスに辿り着き、選択したか • 常につらい運⽤から脱却しようとし続ける !143

×