Tweet
Tweet

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 の活用 ○ 攻めのインフラの今後