Slide 1
Slide 1 text
1
ペパボが求める
「守って攻める」
インフラとは？
高橋 拓也 @ 技術部技術基盤チーム
2021/02/25
Pepabo Tech Conference #14
Slide 2
Slide 2 text
2
2
アジェンダ
● 自己紹介
● 守りのインフラ
○ 守りのインフラはどうなっていくのか？
● 攻めのインフラ
○ 攻めのインフラはどうなっていくのか？
Slide 3
Slide 3 text
3
自己紹介
3
Slide 4
Slide 4 text
4
4
高橋 拓也 (takutaka)
自己紹介
● インフラエンジニア
● 所属: 技術部 技術基盤チーム
● 自宅サーバを飼っています
● https://github.com/takutakahashi
● https://www.takutakahashi.dev
● https://twitter.com/takutaka1220
写真
Slide 5
Slide 5 text
5
5
高橋 拓也 (takutaka)
自己紹介
● 所属: 技術部 技術基盤チーム
○ 事業部のお手伝いをしたり、
○ 全社的なインフラ基盤を開発したりするチーム
● 自宅サーバを飼っています
● https://github.com/takutakahashi
● https://www.takutakahashi.dev
● https://twitter.com/takutaka1220
写真
WS 兼 k8s node
k8s node
k8s master
k8s master
Backup HDD
今は使ってない HDD
Slide 6
Slide 6 text
6
守って攻めるインフラ
6
何じゃそりゃ？
Slide 7
Slide 7 text
7
7
高い可用性と高コストパフォーマンスを維持しながら
運営サービスがチャレンジングな挑戦を
継続的かつ爆速で実行し続けられるインフラの仕組み
Slide 8
Slide 8 text
8
8
高い可用性と高コストパフォーマンスを維持しながら
運営サービスがチャレンジングな挑戦を
継続的かつ爆速で実行し続けられるインフラの仕組み
「守る」インフラ
「攻める」インフラ
Slide 9
Slide 9 text
9
守るインフラ
9
サービスを守るぞ！
Slide 10
Slide 10 text
10
10
解決したい課題
Slide 11
Slide 11 text
11
11
運営サービスの
可用性をさらに上げたい
Slide 12
Slide 12 text
12
12
ペパボのサービスインフラ
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
Slide 13
Slide 13 text
13
13
ペパボのサービスインフラ
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
事業部エンジニアで運用
プラットフォームチームで運用
Slide 14
Slide 14 text
14
14
ペパボのサービスインフラ
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
テストコードの実装
開発環境による動作検証
監視
検証環境構築
継続的アップデート
脆弱性対応
リソース監視とアラート
スケール調整
ステージ分離
Slide 15
Slide 15 text
15
15
プラットフォームの障害発生
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
Slide 16
Slide 16 text
16
16
プラットフォームの障害発生
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
Slide 17
Slide 17 text
17
17
プラットフォームの障害発生
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
トラブルシューティング
復旧作業
トラブルシューティング
復旧作業
Slide 18
Slide 18 text
18
18
プラットフォームの障害発生
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
祈る
祈る
Slide 19
Slide 19 text
19
19
可用性を上げたい
プラットフォーム起因による大規模障害時にも
「プラットフォームの復旧を祈るしかない」という状態を無くし、
最悪の状況下でもサービス提供を継続できる状態を作りたい
Slide 20
Slide 20 text
20
守るインフラ
20
サービスを守るぞ！
Slide 21
Slide 21 text
21
21
守るインフラ？
ユーザーからのアクセスに対し
期待される水準で正常に返答できる環境を提供することに
商業的に合理的な最大限の努力をするインフラ
Slide 22
Slide 22 text
22
- availability
- 正常なレスポンスをちゃんと返す
- reliability
- 想定される遅延以内でレスポンスを返す
- security
- データを安全に保管、管理できる
正常に応答する
守るインフラ
22
Slide 23
Slide 23 text
23
- サービス品質向上幅と消費コストは正比例しない
- 一定水準以上はコストパフォーマンスが悪化する
- 全てのコストは総量が決まっている
- コストを削減すれば、他の部分に利用できるコストが増える
- 品質向上は一定ラインで頭打ちする
- 極端な例: 日本にDCがある以上日本が沈没したら終わる
商業的に合理的な最大限の努力
守るインフラ
23
コスト:
- お金
- コンピュート
- 人的リソース
Slide 24
Slide 24 text
24
やるべきことは２つ
- コスト対品質向上効率を最大化する
- ボトルネックを排除し、品質の上限を上げ続ける
商業的に合理的な最大限の努力
守るインフラ
24
コスト対品質効率最
大化 品質上限突破
Slide 25
Slide 25 text
25
25
守るインフラを
実現するために
Slide 26
Slide 26 text
26
26
守るインフラを実現するために
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex: OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
Slide 27
Slide 27 text
27
27
守るインフラを実現するために
いんたーねっと
DC, ネットワーク機器などの物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
プラットフォームを分割
する
Slide 28
Slide 28 text
28
28
リージョンの作成
守るインフラを実現するために
- メリットはいくつかあり、実現可能性も高い
- 障害単位の分割がある程度可能
- プラットフォームの構成はコードで管理されている
- ユーザーが使い慣れている
- プロビジョニングの資産が使い回せる
Slide 29
Slide 29 text
29
29
リージョンの作成
守るインフラを実現するために
- 果たして最適か？
- 保守コストは確実に上がる
- IP の取り回しやクラスタライフサイクルの考慮など
- 利用コストも確実に上がる
- プロビジョニング手順はどうやっても変わる
- 恩恵は可用性向上のみ
- 付加機能を与えたり、BCP としての役割は果たせない
- 障害リスクが劇的に減るわけではない
- 同じシステムを利用するし
- 運用者が増えてスケールするわけでもないし
Slide 30
Slide 30 text
30
30
リージョンの作成
守るインフラを実現するために
- 果たして最適か？
- 保守コストは確実に上がる
- IP の取り回しやクラスタライフサイクルの考慮など
- 利用コストも確実に上がる
- プロビジョニング手順はどうやっても変わる
- 恩恵は可用性向上のみ
- 付加機能を与えたり、BCP としての役割は果たせない
- 障害リスクが劇的に減るわけではない
- 同じシステムを利用するし
- 運用者が増えてスケールするわけでもないし
もっとイケてるやり方が
あるんじゃないか？
Slide 31
Slide 31 text
31
31
守るインフラを実現するために
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
パブリッククラウド
コンピュートリソース (ex: VM)
アプリケーションコード
パブリッククラウドを
併用する
Slide 32
Slide 32 text
32
32
ハイブリッドクラウド
守るインフラを実現するために
- 障害点が完全に分割される
- 地理的にも異なるサイトに存在する
- 利用したい機能が多くある
- Managed Services
- 利用者や運用担当が多い分障害に強い
- 巨人の肩に乗れる
Slide 33
Slide 33 text
33
33
ハイブリッドクラウド
守るインフラを実現するために
- AWS とプライベートクラウドを専用線で繋いだ
- 任意のテナントと VPC が L3 で接続可能になった！
Slide 34
Slide 34 text
34
34
守るインフラを実現するために
プライベートクラウドは
AWS の豊富な機能と可用性をてにいれた！
Slide 35
Slide 35 text
35
35
立ちはだかる大きな課題
Slide 36
Slide 36 text
36
36
AWS をすぐに活用できない
立ちはだかる大きな課題
- 既存の仕組みをなかなか HA にできない
- AWS にもうひとつサイトを作るのはとても大変
- 人的リソースが全然割けない
- イニシャルの学習コストが高め
新規プロジェクトでは
AWS フル活用したものも多いよ
Slide 37
Slide 37 text
37
37
金銭的コストが大きい
立ちはだかる大きな課題
- EC2 は(プライベートクラウドと比較して)ちょっと高い
- 念の為多めにリソース確保といったことをしづらい
- プライベートクラウドがコスト面で圧倒的有利
- うまいこと使い分けたい
- うまいこと？
Slide 38
Slide 38 text
38
38
エンジニアリングで解決する
Slide 39
Slide 39 text
39
39
守るインフラを実現するために
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
パブリッククラウド
コンピュートリソース (ex: VM)
アプリケーションコード
パブリッククラウドを
併用する
Slide 40
Slide 40 text
40
40
守るインフラを実現するために
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
パブリッククラウド
パブリッククラウドを
一部分だけ利用する
マネージドサービス
Slide 41
Slide 41 text
41
41
パブリッククラウドを一部分だけ活用する
守るインフラを実現するために
- 構成をがらっと変えなくても適用できる範囲はある
- 大幅に可用性を向上できなかったとしても、プライベートクラウドのリス
クを少しでも分散できたら利用する価値はある
プライベートクラウドを拡張する
モジュールとして AWS を利用できる実装を行った
Slide 42
Slide 42 text
42
42
事例: LB on AWS DX
Slide 43
Slide 43 text
43
43
背景
LB on AWS DX (Direct Connect)
- プライベートクラウドでロードバランサを提供している
- OpenStack Octavia
- haproxy + keepalived の HA 構成を LBaaS として提供するもの
- L4 ロードバランサとしての利用がほとんど
Slide 44
Slide 44 text
44
44
背景
LB on AWS DX (Direct Connect)
- 概ね問題ないが、稀に負荷に耐えられず死ぬ
- ノイジーネイバーでパケロスしたり
- ネットワークサービス (Neutron) との連携をミスったり
- LB のダウン中はサービスが停止する
- 復旧まで時間がかかるケースが多い
- かなり難易度の高い障害が多い
- 新規 LB 構築で復旧を試みることが多く、時間がかかる
Slide 45
Slide 45 text
45
45
背景
LB on AWS DX (Direct Connect)
- LB 自体も可用性向上の為継続的にアップデートされる
- LB のバージョンアップが大変だったりする
- LB Image の更新
- 機能開放
- 脆弱性対応
Slide 46
Slide 46 text
46
46
背景
LB on AWS DX (Direct Connect)
- LB 自体も可用性向上の為継続的にアップデートされる
- LB のバージョンアップが大変だったりする
- LB Image の更新
- 機能開放
- 脆弱性対応
Octavia とは別の仕組みを利用して
リスク分散を図りたい
→ Elastic Load Balancer (ELB)
Slide 47
Slide 47 text
47
47
Elastic Load Balancer (ELB)
LB on AWS DX (Direct Connect)
- 詳しくは割愛
- レイヤごとに異なる特徴を持った LB を提供している
- Network Load Balancer (NLB)
- L4 Load Balancer
- EIP 固定、暖機運転不要、設定項目少ない
- Application Load Balancer (ALB)
- L7 Load Balancer
- EIP 不定、暖機運転が必要、柔軟に設定が可能
Slide 48
Slide 48 text
48
48
Elastic Load Balancer (ELB)
LB on AWS DX (Direct Connect)
- 詳しくは割愛
- レイヤごとに異なる特徴を持った LB を提供している
- Network Load Balancer (NLB)
- L4 Load Balancer
- EIP 固定、暖機運転不要、設定項目少ない
- Application Load Balancer (ALB)
- L7 Load Balancer
- EIP 不定、暖機運転が必要、柔軟に設定が可能
L4LB の代替として NLB を利用した
Slide 49
Slide 49 text
49
49
カラーミーショップでの
導入事例
Slide 50
Slide 50 text
50
50
5秒でわかるカラーミーショップ
カラーミーショップでの導入事例
- EC を運営するための各種機能を提供するサービス
- ショップサイトは殆どがプライベートクラウドで運用されている
Slide 51
Slide 51 text
51
プライベートクラウド
51
カラーミーショップでの導入事例
L4LB
Octavia
SSL終端プロキシ
ショップページ
決済システム
ショップページ
ショップページ
ショップページ
決済システム
決済システム
決済システム
ユーザー
Slide 52
Slide 52 text
52
プライベートクラウド
52
カラーミーショップでの導入事例
L4LB
Octavia
SSL終端プロキシ
ショップページ
決済システム
ショップページ
ショップページ
ショップページ
決済システム
決済システム
決済システム
ユーザー
LBが利用不能になると
サービス全体が停止
Slide 53
Slide 53 text
53
プライベートクラウド
53
カラーミーショップでの導入事例
L4LB
Octavia
SSL終端プロキシ
ショップページ
決済システム
ショップページ
ショップページ
ショップページ
決済システム
決済システム
決済システム
ユーザー
AWS
L4LB
NLB
Slide 54
Slide 54 text
54
プライベートクラウド
54
カラーミーショップでの導入事例
L4LB
Octavia
SSL終端プロキシ
ショップページ
決済システム
ショップページ
ショップページ
ショップページ
決済システム
決済システム
決済システム
ユーザー
AWS
L4LB
NLB
LBが利用不能でも
NLB でサービス継続
Slide 55
Slide 55 text
55
プライベートクラウド
55
カラーミーショップでの導入事例
L4LB
Octavia
SSL終端プロキシ
ショップページ
決済システム
ショップページ
ショップページ
ショップページ
決済システム
決済システム
決済システム
ユーザー
AWS
L4LB
NLB
NLBやDXが利用不能でも
Octavia でサービス継続
Slide 56
Slide 56 text
56
プライベートクラウド
56
カラーミーショップでの導入事例
L4LB
Octavia
SSL終端プロキシ
ショップページ
決済システム
ショップページ
ショップページ
ショップページ
決済システム
決済システム
決済システム
ユーザー
AWS
L4LB
NLB
Route53 によるヘルスチェックと
重み付け DNS ラウンドロビン
Route53 によるヘルスチェックと
重み付け DNS ラウンドロビンで
定常時は10%だけ NLB に誘導する
Slide 57
Slide 57 text
57
57
本番環境への導入を実施した
カラーミショップでの導入事例
- 二通りの経路にて導入を実施した
- ショップ閲覧機能への入り口
- ショップオーナー用管理画面への入り口
Slide 58
Slide 58 text
58
58
NLB の構築と運用
Slide 59
Slide 59 text
59
59
構築と運用コストを限りなくゼロにしたい
NLB の構築と運用
- 構築、運用コストの増大が容易に想像できた
- 構築時に terraform 書くのが大変
- たくさん NLB 作るのも大変
- メンバの追加、削除を忘れる
Slide 60
Slide 60 text
60
60
構築と運用コストを限りなくゼロにしたい
NLB の構築と運用
- 構築、運用コストの増大が容易に想像できた
- 構築時に terraform 書くのが大変
- たくさん NLB 作るのも大変
- メンバの追加、削除を忘れる
Kubernetes Custom Controlelr を利用して
構築運用自動化 API を実装した
Slide 61
Slide 61 text
61
61
Kubernetes Custom Controller
NLB の構築と運用
- Kubernetes に任意の動作を拡張できる機能
- 新しいリソースを追加できる
- リソースの変更をトリガしオペレーションを追加できる
Slide 62
Slide 62 text
62
62
Kubernetes Custom Controller
NLB の構築と運用
Slide 63
Slide 63 text
63
63
Kubernetes Custom Controller
NLB の構築と運用
Octavia LB の UUID
vpc, subnet などの情報
プラットフォームを
操作する秘匿情報
Slide 64
Slide 64 text
64
64
NLB 構築フロー
Slide 65
Slide 65 text
65
プライベートクラウド
65
LB 新規構築フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
Slide 66
Slide 66 text
66
プライベートクラウド
66
LB 新規構築フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
Octavia LB の uuid を
パラメータに
NLB の構築をトリガ
Slide 67
Slide 67 text
67
プライベートクラウド
67
LB 新規構築フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
Octavia API に
与えられた uuid の LB の構
成情報を問い合わせる
Slide 68
Slide 68 text
68
プライベートクラウド
68
LB 新規構築フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
LB の listener, member,
healthcheck などの情報を
教える
Slide 69
Slide 69 text
69
プライベートクラウド
69
LB 新規構築フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
NLB の定義情報を作成し
構築する
L4LB
NLB
Slide 70
Slide 70 text
70
70
NLB ターゲット変更フロー
Slide 71
Slide 71 text
71
プライベートクラウド
71
LB 運用フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
L4LB
NLB
Octavia に
メンバが追加された
Slide 72
Slide 72 text
72
プライベートクラウド
72
LB 運用フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
L4LB
NLB
一定間隔で API に
構成情報を問い合わせる
Slide 73
Slide 73 text
73
プライベートクラウド
73
LB 運用フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
L4LB
NLB
返却された
構成情報に差分が生じる
Slide 74
Slide 74 text
74
プライベートクラウド
74
LB 運用フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
L4LB
NLB
差分を元に
NLB にターゲットを追加す
る
Slide 75
Slide 75 text
75
プライベートクラウド
75
LB 運用フロー
L4LB
Octavia
SSL終端プロキシ
運用者
AWS
NLB 構築システム
Octavia
API
L4LB
NLB
サービス運用者は
AWS を一切触らずに
運用が完結する！
Slide 76
Slide 76 text
76
76
自動化システムの導入により
NLB の構築と運用
- NLB 構築の際に必要な作業が大幅に少なくなった
- 元となる Octavia LB と AWS クレデンシャルだけ
- NLB 運用がゼロになった
- メンバの増減はシステムが勝手に全部やってくれる
- 切り替えは DNS による自動フェイルオーバー
Slide 77
Slide 77 text
77
77
自動化システムの導入により
NLB の構築と運用
- NLB 構築の際に必要な作業が大幅に少なくなった
- 元となる Octavia LB と AWS クレデンシャルだけ
- NLB 運用がゼロになった
- メンバの増減はシステムが勝手に全部やってくれる
- 切り替えは DNS による自動フェイルオーバー
限りなく少ない手順で
AWS を活用した可用性向上が可能となった
Slide 78
Slide 78 text
78
「守るインフラ」は
どうなっていくのか？
78
Slide 79
Slide 79 text
79
79
Nyah はハイブリッドクラウドプラットフォームになります
「守るインフラ」はどうなっていくのか？
- 今まではプライベートクラウドとしての Nyah だった
- パブリッククラウドを透過的に利用できるプラットフォームになります
１つのプラットフォームを操作するように
マルチクラウドを操作できる
Slide 80
Slide 80 text
80
80
Nyah はハイブリッドクラウドプラットフォームになります
「守るインフラ」インフラはどうなっていくのか？
- Nyah のユーザーに例えば以下の体験を提供します
- LB を作成したら自然と NLB がついてくる
- DNSラウンドロビンによる冗長構成がついてくる
- NKE クラスタを作ると EKS がついてくる
- プラットフォーム障害をユーザー対応無しで回避する
- コスト効率を最適化したオートスケールができる
Slide 81
Slide 81 text
81
81
「守るインフラ」まとめ
Slide 82
Slide 82 text
82
82
「守るインフラ」まとめ
- 手詰まりの状態を作らないようにプラットフォームを進化させる
- AWS とのハイブリッドクラウドにより実現を目指す
- 長年運用されているシステムでも恩恵を受けられるようにする
- LB を第一弾として適用を実践、事例を紹介した
- 今後はさらにオンプレとパブリッククラウドの境界をなくしていく
Slide 83
Slide 83 text
83
「攻めるインフラ」
83
Slide 84
Slide 84 text
84
84
解決したい課題
Slide 85
Slide 85 text
85
85
可用性を維持したまま
開発サイクルを爆速にしたい
つまりどういうことかというと
Slide 86
Slide 86 text
86
86
「多分動くと思うから
リリースしようぜ」
画像略
Slide 87
Slide 87 text
87
87
多分動くと思うからリリースしようぜ
開発サイクルを爆速にしたい
- ステージングでうまくいっても本番でうまくいく保証にはならない
- データ量に比例して処理が重くなるとか
- 地理的影響が大きかったとか
- 埋もれてた本番の設定差分が影響したとか
- 「とりあえず本番に出してみよう」をできる限り可能にする
- 可用性を犠牲にしない
Slide 88
Slide 88 text
88
88
多分動くと思うからリリースしようぜ
開発サイクルを爆速にしたい
- どうすればいい？
- ローリングリリース
- 本番環境の家畜化
Slide 89
Slide 89 text
89
89
ローリングリリース
開発サイクルを爆速にしたい
- 本番に少しずつリリースする
- リリース時のユーザーへの影響を最小限にする
10%
30% 50%
100%
Slide 90
Slide 90 text
90
90
本番環境の家畜化
開発サイクルを爆速にしたい
- 本番として動作できる環境一式を容易に構築できるようにする
- 動作検証を本番環境で行い、ウォームアップ後リリースする
- 障害発生時は他の本番環境にロールバックできるようにする
- 複数の本番環境を同時にサービスインできる構成を取る
100%
100%
100%
本番環境
api
frontend
LBなど
ウォームアップ
リリース済み
本番
スケールアウトや
アクセス開放など
赤色は
サービスイン済み
100%
100%
100%
本番環境
api
frontend
LBなど
Slide 91
Slide 91 text
91
- 本番環境が１つの場合
- 原因特定、revert, deploy を短時間で実施する必要がある
- 原因が特定できるまで長引くとその分ダウンタイムが長引く
91
アプリケーション更新による障害発生時の対応
開発サイクルを爆速にしたい
ダメな
本番環境
原因を特定し
revert & deploy
よい
本番環境
赤色は
サービスイン済み
Slide 92
Slide 92 text
92
92
アプリケーション更新による障害発生時の対応
開発サイクルを爆速にしたい
100%
100%
100%
ダメな
本番環境
リリース済み
本番
残された本番環境を
ウォームアップし
切り替え
100%
100%
100%
ダメな
本番環境
- 本番環境が複数ある場合
- とりあえず動作実績のあるバージョンに切り替え
- ダウンタイムは O(1) となる
赤色は
サービスイン済み
Slide 93
Slide 93 text
93
93
本番環境の家畜化の利点
開発サイクルを爆速にしたい
- ロールバックが速い
- 手法次第では数秒でロールバック可能
- サービス成長に寄与できる
- 縮小本番環境に一部リクエスト流してABテストしたり
- 需要の増加に対し本番環境の追加で対応したり
- ローリングリリースも家畜化で実現できる
- 家畜10セットを１つずつリリースすれば10%段階リリース
Slide 94
Slide 94 text
94
94
本番環境の家畜化の欠点
開発サイクルを爆速にしたい
- どう考えても管理が複雑になる
Slide 95
Slide 95 text
95
95
どう考えても管理が複雑になる
開発サイクルを爆速にしたい
- ひとつの本番環境を運用するのでも結構大変
- 本番環境を本当に環境差分なく大量に運用できる…？
Slide 96
Slide 96 text
96
96
どう考えても管理が複雑になる
開発サイクルを爆速にしたい
- ひとつの本番環境を運用するのでも結構大変
- 本番環境を本当に環境差分なく大量に運用できる…？
人手を必要とせずに大量の本番環境を
うまく管理する仕組みが絶対に必要
Slide 97
Slide 97 text
97
97
オーケストレーションプラットフォームが必要
大量の環境をうまく管理する
- 定義に則ってリソースをオーケストレーションするシステムが必要
- マルチクラウドできると最高
- 「守るインフラ」を実現する
- オーケストレーションシステムは管理の手間が少ないとよい
Slide 98
Slide 98 text
98
98
オーケストレーションプラットフォームが必要
大量の環境をうまく管理する
- 定義に則ってリソースをオーケストレーションするシステムが必要
- マルチクラウドできると最高
- 「守るインフラ」を実現する
- オーケストレーションシステムは管理の手間が少ないとよい
Managed Service が充実していて
社内外実績も豊富な
Kubernetes が最適
Slide 99
Slide 99 text
99
99
Kubernetes を活用した
本番環境の家畜化
Slide 100
Slide 100 text
100
100
再掲
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
アプリケーションコード
パブリッククラウド
コンピュートリソース (ex: VM)
アプリケーションコード
Slide 101
Slide 101 text
101
101
再掲
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
パブリッククラウド
コンピュートリソース (ex: VM)
Kubernetes Services
prod prod prod prod
Kubernetes の層が挟まる
Slide 102
Slide 102 text
102
102
再掲
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
パブリッククラウド
コンピュートリソース (ex: VM)
Kubernetes Services
prod prod prod prod
VM は管理対象ではなくなり
クラウド間の差分もなくなる
(ように実装する)
Slide 103
Slide 103 text
103
103
再掲
いんたーねっと
DC, ネットワーク機器などの
物理層
クラウドプロパイダ (ex:
OpenStack)
HV, SDN, SDS
コンピュートリソース (ex: VM)
パブリッククラウド
コンピュートリソース (ex: VM)
Kubernetes Services
prod prod prod prod
この部分を
具体的に解説します
Slide 104
Slide 104 text
104
104
家畜化の具体的な活用方法
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
クラウドを跨いだ複数クラスタで
透過的に同一環境が動作する
Slide 105
Slide 105 text
105
105
家畜化の具体的な活用方法
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
ユーザー属性を考慮した
Prod 間冗長を行う
Slide 106
Slide 106 text
106
106
クラスタ障害発生時
Slide 107
Slide 107 text
107
107
家畜化の具体的な活用方法 障害発生時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
とあるクラスタが動作不能になる
Slide 108
Slide 108 text
108
108
家畜化の具体的な活用方法 障害発生時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
このユーザーが
サービス利用不可能になる
Slide 109
Slide 109 text
109
109
家畜化の具体的な活用方法 障害発生時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
これらのユーザーのアクセスは
守られる
Slide 110
Slide 110 text
110
110
家畜化の具体的な活用方法 障害発生時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
何らかの方法で
利用する Prod を変更して復旧
Slide 111
Slide 111 text
111
111
アプリケーション更新
Slide 112
Slide 112 text
112
112
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
指定した法則に乗っ取り
更新する Prod を選択する
Slide 113
Slide 113 text
113
113
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
更新順の例:
1. テスト利用 Prod
2. 搭載ユーザーが少ない Prod
3. 冗長済みユーザー
4. 冗長なしユーザー
Slide 114
Slide 114 text
114
114
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
更新順決定:
1. C-2
2. C-1
3. A-2, B-1
4. A-1, B-2
Slide 115
Slide 115 text
115
115
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
更新順決定:
1. C-2
2. C-1
3. A-2, B-1
4. A-1, B-2
テスト用 Prod で更新実施後
動作確認を行う
Slide 116
Slide 116 text
116
116
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
更新順決定:
1. C-2
2. C-1
3. A-2, B-1
4. A-1, B-2
ユーザー影響の少ない Prod を
更新する
Slide 117
Slide 117 text
117
117
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
更新順決定:
1. C-2
2. C-1
3. A-2, B-1
4. A-1, B-2
アラートがでなければ次へ
Slide 118
Slide 118 text
118
118
家畜化の具体的な活用方法 アプリケーション更新
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
2ドメイン冗長
冗長なし
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
更新順決定:
1. C-2
2. C-1
3. A-2, B-1
4. A-1, B-2
更新完了
Slide 119
Slide 119 text
119
119
クラスタアップグレード
Slide 120
Slide 120 text
120
120
家畜化の具体的な活用方法 クラスタアップグレード時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
Cluster A をアップグレードする
Slide 121
Slide 121 text
121
121
家畜化の具体的な活用方法 クラスタアップグレード時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
空きのある Prod へ
リクエストを割り振る
Slide 122
Slide 122 text
122
122
家畜化の具体的な活用方法 クラスタアップグレード時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
クラスタをアップグレードする
Slide 123
Slide 123 text
123
123
家畜化の具体的な活用方法 クラスタアップグレード時
k8s Cluster A k8s Cluster B
Prod
A-1
Prod
A-2
Prod
B-1
Prod
B-2
k8s Cluster A
(On-Prem)
k8s Cluster B
(EKS)
k8s Cluster B
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
別のクラスタから
リクエストを再配置する
Slide 124
Slide 124 text
124
124
どうやって実現する？
Slide 125
Slide 125 text
125
125
どうやって実現する？
本番環境の家畜化
- Prod のライフサイクル管理
- 構築、更新、リソース監視、退役
- クラスタのライフサイクル管理
- 構築、更新、リソース監視、退役
- ユーザーのリクエストハンドリング
- Prod スケジューリング
- 向き先変更
Slide 126
Slide 126 text
126
126
どうやって実現する？
本番環境の家畜化
- Prod のライフサイクル管理
- 構築、更新、リソース監視、退役
- クラスタのライフサイクル管理
- 構築、更新、リソース監視、退役
- ユーザーのリクエストハンドリング
- Prod スケジューリング
- 向き先変更
ライフサイクルの管理には
Custom Controller が最適
Custom Controller を利用して
実装開始
Slide 127
Slide 127 text
127
127
現在の進捗
Slide 128
Slide 128 text
128
128
本番環境の家畜化
k8s Cluster A
(On-Prem)
Prod
A-1
Prod
A-2
k8s Cluster B
(EKS)
Prod
B-1
Prod
B-2
Prod
C-1
Prod
C-2
k8s Cluster C
(On-Prem)
Prod の管理だけ実装できた
Slide 129
Slide 129 text
129
129
実装の進捗
本番環境の家畜化
- Prod を Custom Controller で管理することができるようになった
- kubectl create -f prod.yaml で作成できる
- アプリケーション更新は自動化できた
- git tag やブランチ更新を監視しイメージを切り替える
- 未実装のものが色々ある
- ロールバック
- リソース監視
- ウォームアップ
Slide 130
Slide 130 text
130
130
実装の進捗
本番環境の家畜化
- Kubernetes クラスタの管理は考え中
- 可能ならリソースで管理したい
- ClusterAPI を使うか、独自実装するか
- NKE の出来が良いので独自実装しても簡単そう
Slide 131
Slide 131 text
131
131
クラスタ自体の家畜化構想もある
本番環境の家畜化
- Workload Cluster と Control Plane Cluster に分ける
- Control Plane Cluster が Workload Cluster を設定管理する
- Workload Cluster はイミュータブルに管理する
- クラスタアップグレードしないで捨てる
Slide 132
Slide 132 text
132
132
実装の進捗
本番環境の家畜化
- ユーザーハンドリングは考え中
- あまりピンとくるアイディアがない
- DNS ラウンドロビンをするか、L7 Proxy を設置するか
- スケジューリングをどうするか
- クラスタ間のグローバルデータストアが必要？
- 監視とフェイルオーバーをどうするか
Slide 133
Slide 133 text
133
「攻めるインフラ」まとめ
133
Slide 134
Slide 134 text
134
134
「攻めるインフラ」まとめ
- 本番環境の家畜化で攻めていきます
- ユーザー影響を最小化した開発サイクルを実現します
- 人間のオペレーションをできる限り排除する実装をしています
- 現在実装途中です
- 「攻めるインフラ」が「守るインフラ」の実現にも繋がっています
Slide 135
Slide 135 text
135
「守って攻める」インフラ
まとめ
135
Slide 136
Slide 136 text
136
136
「守って攻める」インフラまとめ
- より可用性を高められるために試行錯誤を繰り返しています
- 現在はハイブリッドクラウド活用による解決を模索しています
- 同時に、事業の成長を加速できるインフラを目指しています
- こちらは Kubernetes + Custom Controller で解決します
Slide 137
Slide 137 text
137
137
「守って攻める」インフラまとめ
- より可用性を高められるために試行錯誤を繰り返しています
- 現在はハイブリッドクラウド活用による解決を模索しています
- 同時に、事業の成長を加速できるインフラを目指しています
- こちらは Kubernetes + Custom Controller で解決します
一緒にインフラを守って攻める仲間を募集中です！
Slide 138
Slide 138 text
138
138
おしまい
● 守りのインフラ
○ AWS とプライベートクラウドの活用
○ NLB on DX の導入事例
○ 守りのインフラの今後
● 攻めのインフラ
○ 本番環境の家畜化
○ Kubernetes と Custom Controller の活用
○ 攻めのインフラの今後