2019 IaaS Workshop in training for new employee at NTT Com

Slide 1

Slide 1 text

IaaSワークショップ @NTT Communications @iwashi86 2019.4.15

Slide 2

Slide 2 text

Day3-5(3⽇間)の流れ・IaaS/CaaS/FaaSを⽤いて同じ仕様のWebアプリを作成・今回の研修の本質はアプリではない・本質は・どうクラウドを使いこなすか？・サービス(お客様価値)をどう作り上げるか？・クラウドはそのための強⼒な武器

Slide 3

Slide 3 text

今⽇(IaaS)の流れ・講義: 1-1.5h 程度・クラウド、IaaSについて・注: 知識量が多く駆け⾜なので、気になるところは別途確認のこと

Slide 4

Slide 4 text

今⽇(IaaS)の流れ・講義: 1-1.5h 程度・クラウド、IaaSについて・注: 知識量が多く駆け⾜なので、気になるところは別途確認のこと・実習: 残り時間全て・IaaSクラウドデザインパターンの実装・簡易カオスエンジニアリングに耐える

Slide 5

Slide 5 text

講義の流れ

Slide 6

Slide 6 text

・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ

Slide 7

Slide 7 text

ɾΫϥ΢υશൠͷ஌ࣝ ・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ

Slide 8

Slide 8 text

そもそもクラウドとはなにか？ NISTによるクラウドコンピューティングの定義 https://www.ipa.go.jp/files/000025366.pdf （最近だとちょっと古い感じの内容 + 少しお硬いので…）

Slide 9

Slide 9 text

・対照的なのはオンプレ・⾃社でサーバを抱えること・クラウド ⇒ 抱えない・オンデマンドで必要なときにリソース確保・コスト・オンプレ：将来を予測して投資・クラウド：必要なだけ払う（⼤量に使った場合はむしろ⾼いことも）そもそもクラウドとはなにか？

Slide 10

Slide 10 text

クラウドを提供するサービス達・GCP / Google ・AWS / Amazon Web Services ・Azure / Microsoft ・ECL 2.0 / NTT Com

Slide 11

Slide 11 text

クラウドの分類① ・IaaS / Infrastructure as a Service ・もっともベーシック・他を⽀える基礎として抑えておくのが重要・IaaSが向いている機能もある・VM、ネットワーク、ストレージを貸出・PaaS / Platform as a Service ・アプリ＋ミドルウェア以外をマネージ・HerokuやGoogle App Engineが有名

Slide 12

Slide 12 text

クラウドの分類② ・CaaS / Container as a Service / 詳しくは明⽇・コンテナの実⾏基盤を提供・主流は Kubernetes をマネージ・GKE / EKS / AKS と各社出している・FaaS / Function as a Service / 詳しくは明後⽇・関数の実⾏環境を提供・AWS Lambda、Google Cloud Functions など・SaaS / Software as a Service、GitHubとか

Slide 13

Slide 13 text

レイヤで分類⽐較してみる

Slide 14

Slide 14 text

オンプレは全部やる、データセンタすら作るデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレ⾃社は事実、データセンタを多く構築している

Slide 15

Slide 15 text

ホスティングはデータセンタ内のサーバを拝借データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティング

Slide 16

Slide 16 text

IaaSはOS以上をユーザがやるデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS

Slide 17

Slide 17 text

CaaSはコンテナ以上をユーザが対応データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS

Slide 18

Slide 18 text

PaaSはアプリだけ⾃分で作るデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS

Slide 19

Slide 19 text

FaaSは関数だけ⾃分で作るデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ FaaS

Slide 20

Slide 20 text

SaaSは使いたい機能だけデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ FaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ SaaS

Slide 21

Slide 21 text

それぞれに向き不向きがあるデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ FaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ SaaS ⼤ ← ⾃由度 → ⼩⼤ ← ⼯数→ ⼩

Slide 22

Slide 22 text

参考: 使い分けはCNCFのホワイトペーパーがオススメ https://github.com/cncf/wg-serverless

Slide 23

Slide 23 text

・クラウド全般の知識 ɾ*BB4ʹ͍ͭͯ ・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ

Slide 24

Slide 24 text

IaaSの得意領域・既存のシステム移⾏・特定のOS/Kernelに縛りがある・GPUが必要・HTTP/S以外のプロトコル

Slide 25

Slide 25 text

IaaSでは・GUIをポチポチ or APIを叩くと VMが上がる + NW とストレージが付属

Slide 26

Slide 26 text

IaaSでは・GUIをポチポチ or APIを叩くと VMが上がる + NW とストレージが付属・NWもまるごと設計できるので⾃由度は⾮常に⾼いその半⾯、イマイチな設計もしやすい (クラウドの⼒を使いこなせない)

Slide 27

Slide 27 text

ではどうするか？・もともと有名なやつ（と類似の概念で…）

Slide 28

Slide 28 text

クラウドデザインパターン(CDP)へ補⾜: AWS版だけど、他クラウドでもほぼそのまま応⽤できる http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 だいたい2013-2015年ぐらいに流⾏していた（今も現役で動いているものは多いはず）

Slide 29

Slide 29 text

・クラウド全般の知識・IaaSについて ɾ*OTUBHSBNϥΠΫͳΞϓϦͷઃܭͰֶͿ ・カオスエンジニアリング講義の流れ

Slide 30

Slide 30 text

InstagramみたいなWebアプリを想像・まず、HTML/JavaScript/CSSを取得・ユーザ登録・ログイン認証・画像やコメントの投稿・修正・閲覧・当然、それらは保存される必要がある・ユーザのAppへPush通知これを作りたい、さてどうしよう？

Slide 31

Slide 31 text

もし研究室でやるなら VM App + DB ・サーバ(VM)を1台たてる・Webサーバ(nginx) ・Rails/Djangoとかでロジック・MySQLやPostgreSQLにデータを保存・落ちたら苦情ドリブンで復旧・全部とぶとヤバいのでたまにRDBのバックアップをとる

Slide 32

Slide 32 text

お仕事でやる場合の重要概念

Slide 33

Slide 33 text

SPOFを避ける・SPOF / Single Point Of Failure ・⽇本語だと「単⼀障害点」・その単⼀箇所が働かないとシステム全体が障害となるような箇所補⾜) 全てSPOFを避けるのではなく、費⽤対効果でSPOFを許容するケースもある

Slide 34

Slide 34 text

SPOFを避ける・SPOF / Single Point Of Failure ・⽇本語だと「単⼀障害点」・その単⼀箇所が働かないとシステム全体が障害となるような箇所・解決⽅法の例・冗⻑化・落ちても⾃動復旧させる補⾜) 全てSPOFを避けるのではなく、費⽤対効果でSPOFを許容するケースもある

Slide 35

Slide 35 text

IaaS x Webアプリ x CDP

Slide 36

Slide 36 text

最初の構成 VM App + RDB

Slide 37

Slide 37 text

圧倒的に重要なDBを冗⻑化 App RDB (Primary) RDB (Secondary) Primaryが落ちたら SecondaryをPrimaryに昇格し接続先を切り替え

Slide 38

Slide 38 text

圧倒的に重要なDBを冗⻑化 App RDB (Primary) RDB (Secondary) 参考：・⾊々なDBの冗⻑化・ACT/ACT、マルチマスタ・Primary/Secondary、ACT/SBY -> 障害時はFailOver Master/Slave(Slaveという⾔葉がいまいちなので最近使わない) ・使うDBの種類、プロダクトによって異なる

Slide 39

Slide 39 text

Appも冗⻑化していく App RDB (Primary) RDB (Secondary) App

Slide 40

Slide 40 text

参考: スケールアウト/スケールイン App RDB (Primary) RDB (Secondary) App App ・・・スケルアウトスケルイン

Slide 41

Slide 41 text

どうやってAppにリクエストを振り分ける？ App RDB (Primary) RDB (Secondary) App

Slide 42

Slide 42 text

代表的案な2⽅式

Slide 43

Slide 43 text

代表的案な2⽅式

Slide 44

Slide 44 text

結果的にこうなる App RDB (Primary) RDB (Secondary) App LB LB DNS ラウンドロビン・IaaSを使った場合の超基本形

Slide 45

Slide 45 text

さらにマネージドサービスを使うと… App App DNS ラウンドロビン※ クラウド提供LB クラウド提供DB ※ クラウドによってラウンドロビンするかは異なる GCPの場合は、単⼀IPアドレスでIPエニーキャストで対応

Slide 46

Slide 46 text

参考: Cloud Load Balancing(GCP Managed LB)

Slide 47

Slide 47 text

参考: Cloud SQL(GCP Managed RDB)

Slide 48

Slide 48 text

・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ ɾ৑௕Խʹ͍ͭͯ ・カオスエンジニアリング講義の流れ

Slide 49

Slide 49 text

冗⻑化したときのハマりどころ

Slide 50

Slide 50 text

50 App(Rails) App(Rails) ①ログインログインを考える

Slide 51

Slide 51 text

51 App(Rails) App(Rails) ①ログイン ②セッションキャッシュログインを考える

Slide 52

Slide 52 text

52 App(Rails) App(Rails) ①ログイン ③GET ログインを考える ②セッションキャッシュ

Slide 53

Slide 53 text

53 App(Rails) App(Rails) ①ログイン ③GET ④キャッシュが無くてアクセスがコケるログインを考える ②セッションキャッシュ

Slide 54

Slide 54 text

54 ①スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる代表的な対応策 x 2

Slide 55

Slide 55 text

55 ①スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる ②セッションの状態を外に追い出す・KVSなどを利⽤してセッションを追い出す・クラウドを活かすならコッチ・スケールイン/アウトに対応しやすいから代表的な対応策 x 2

Slide 56

Slide 56 text

56 App(Rails) App(Rails) ①ログイン ②セッション ③GET ④セッションを取りに⾏く KVSとか ②セッションを書き出すセッションを外に出した例

Slide 57

Slide 57 text

57 CDP: State Sharingパターン http://aws.clouddesignpattern.org/index.php/CDP:State_Sharing%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

Slide 58

Slide 58 text

58 ・スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる・セッションの状態を外に追い出す・KVSなどを利⽤してセッションを追い出す・クラウドを活かすならコッチ重要な概念

Slide 59

Slide 59 text

59 ・スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる・セッションの状態を外に追い出す・KVSなどを利⽤してセッションを追い出す・クラウドを活かすならコッチスケールアウトさせるときの肝＝いかに状態/ステートを外にだすか？閉じ込めていくか？ (この概念はコンテナ時代でも重要) 重要な概念

Slide 60

Slide 60 text

60 ①APP ②RDB ③KVS ④Other ユーザが写真を投稿したらどこに保存？

Slide 61

Slide 61 text

61 ①APP ②RDB ③KVS ④Other ①APP 状態を追い出す、閉じ込められてない例 ①はNG、リクエスト先によっては存在しない

Slide 62

Slide 62 text

62 ①APP ④Other ④が多い、よく使うのはオブジェクトストレージ⾃社クラウドであるCloudnのオブジェクトストレージへ貯め込む例

Slide 63

Slide 63 text

冗⻑化のめんどくささ

Slide 64

Slide 64 text

冗⻑化対象は⾊々とある・RDB (MySQL/Postgres/Oracle/…) ・KVS (Redis/…) ・LB ・全部やるのは⾮常に⼤変・ちゃんとFailoverするの？コネクションは？・直接、お客様価値につながらない部分・Instagramだったら、ここは本質ではない・そもそも、その価値(仮説)が刺さるか謎

Slide 65

Slide 65 text

そこで各クラウドプロバイダはマネージドを⽤意・RDB ・AWS RDS ・GCP CloudSQL ・KVS ・AWS ElastiCache ・GCP / Cloud DataStore ・LB ・AWS ALB/NLB/CLB ・GCP LB (その他、SQLで扱えるDBは⾊々あるが割愛) ・⾃動で対応・セキュリティパッチアップデート・冗⻑化・バックアップ

Slide 66

Slide 66 text

Slide 67

Slide 67 text

どこまで冗⻑化するか？

Slide 68

Slide 68 text

冗⻑化の単位・HDD/SSD単位(RAID) ・サーバ単位・ラック単位・データセンタ単位、Availability Zone単位・リージョン単位・クラウド単位結局、サービス・プロダクト特性にあわせて検討

Slide 69

Slide 69 text

スケールアウト/イン or スケールアップ/ダウン

Slide 70

Slide 70 text

再掲: スケールアウト/スケールイン App RDB (Primary) RDB (Secondary) App App ・・・スケルアウトスケルイン

Slide 71

Slide 71 text

スケールアップとダウン・スケールアップ・CPUの数を増やす、メモリを増やす・スケールダウン・CPUの数を減らす、メモリを減らすなお… 現代は、スケールアウトを上⼿く使うのが主流 (スケールアップ/ダウンも使わないわけじゃない、使い分け)

Slide 72

Slide 72 text

12 Factor Apps https://12factor.net/ja/

Slide 73

Slide 73 text

I. バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係を明⽰的に宣⾔し分離する III. 設定を環境変数に格納する IV.バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実⾏の3つのステージを厳密に分離する VI.アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する VII.ポートバインディングを通してサービスを公開する VIII.プロセスモデルによってスケールアウトする IX.⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する X. 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ XI.ログをイベントストリームとして扱う XII.管理タスクを1回限りのプロセスとして実⾏する参考: 12 Factor Apps の各項⽬

Slide 74

Slide 74 text

Slide 75

Slide 75 text

https://www.slideshare.net/AmazonWebServicesJapan/the-twelvefactor-appaws

Slide 76

Slide 76 text

https://codezine.jp/article/detail/10402

Slide 77

Slide 77 text

少し戻って…

Slide 78

Slide 78 text

再掲: InstagramみたいなWebアプリを想像・まず、HTML/JavaScript/CSSを取得・ユーザ登録・ログイン認証・画像やコメントの投稿・修正・閲覧・当然、それらは保存される必要がある・ユーザのAppへPush通知

Slide 79

Slide 79 text

再掲: InstagramみたいなWebアプリを想像・まず、HTML/JavaScript/CSSを取得・ユーザ登録・ログイン認証・画像やコメントの投稿・修正・閲覧・当然、それらは保存される必要がある・ユーザのAppへPush通知 ⇒ ⼀度に⼤量配信すると処理溢れで捌けなくなることも…

Slide 80

Slide 80 text

Queueを挟んで分散する Queue App App 送りたいタスクを⽣成(Produce) 配信App 配信App Queueからタスクを取得して配信 (Consume)

Slide 81

Slide 81 text

・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ ɾΧΦεΤϯδχΞϦϯά 講義の流れ

Slide 82

Slide 82 text

https://www.oreilly.com/ideas/chaos-engineering

Slide 83

Slide 83 text

カオスエンジニアリングとは “Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the systemʼs capability to withstand turbulent conditions in production.” ・分散システムにおいて・本番環境のように荒れる環境にも耐える能⼒を持っている・という確信を得るための実験/検証の規律

Slide 84

Slide 84 text

どのようなことをするか？・(⼀番有名なものだと）商⽤のVMをランダムで落とす・リージョンやデータセンタ単位で障害を起こす・あるトラフィックに対して⼀定期間レイテンシを増加させる・ある関数がランダムに例外を投げるようにする・システム間の時刻をずらす・デバイスドライバでI/Oエラーを起こす・クラスタのCPUを最⼤限まで使い切る

Slide 85

Slide 85 text

なぜこんなことを？・お客様価値を落とすシステムの弱みを学びそれを改善することで、システムの信頼性を⾼められるから（実際に障害を起こさないと分からないことは⼭程ある…）

Slide 86

Slide 86 text

カオスエンジニアリング適⽤の前提条件・シンプルな質問に答えられるか？「あなたのシステムは、サービスの障害やネットワークレイテンシの急激な上昇といった現実世界の出来事から回復できるか？」もし、no なら先にやることがある。・⾃分のシステムの状態を監視できているか？ + Steady State(正常な状態) を定義できているか？

Slide 87

Slide 87 text

再掲：実習では少しだけ味⾒してみる (カオスエンジニアリングの⼀部だけ体験してみる) ・(⼀番有名なものだと）商⽤のVMをランダムで落とす ← 採⽤・リージョンやデータセンタ単位で障害を起こす・あるトラフィックに対して⼀定期間レイテンシを増加させる・ある関数がランダムに例外を投げるようにする・システム間の時刻をずらす・デバイスドライバでI/Oエラーを起こす・クラスタのCPUを最⼤限まで使い切る

Slide 88

Slide 88 text

現実世界ではもっと考えることがある

Slide 89

Slide 89 text

たとえば… ・運⽤って何やるんだっけ？・冗⻑化してても落ちたら？・依存しているAPIが不安定に… ・使ってるライブラリの脆弱性が⾒つかった？・あれ、そもそも監視って何やるんだっけ？ ⇒ トピックはいくらでもあるので書籍、オンライン資料、実務で⾝につける

Slide 90

Slide 90 text

（参考）個⼈的にいくつか良いクラウド向けの勉強リソース/書籍

Slide 91

Slide 91 text

https://www.oreilly.co.jp/books/9784873118642/ ⼊⾨監視

Slide 92

Slide 92 text

https://www.slideshare.net/AmazonWebServicesJapan AWS Black Beltシリーズ

Slide 93

Slide 93 text

https://cloudplatformonline.com/onair-japan.html Google Cloud OnAir

Slide 94

Slide 94 text

まとめ

Slide 95

Slide 95 text

本⽇お話したこと・クラウドとは？IaaSとは？・Instagram的なアプリを作る⽅法・CDPを使う・マネージドを使う・カオスエンジニアリングおしまい！（質問があれば！）