2019 IaaS Workshop in training for new employee at NTT Com

2019年のNTTコミュニケーションズグループの新卒研修資料の一部です。

1. IaaSワークショップ @NTT Communications @iwashi86 2019.4.15
2. Day3-5(3⽇間)の流れ ・IaaS/CaaS/FaaSを⽤いて 同じ仕様のWebアプリを作成 ・今回の研修の本質はアプリではない ・本質は ・どうクラウドを使いこなすか？ ・サービス(お客様価値)をどう作り上げるか？ ・クラウドはそのための強⼒な武器
3. 今⽇(IaaS)の流れ ・講義: 1-1.5h 程度 ・クラウド、IaaSについて ・注: 知識量が多く駆け⾜なので、 気になるところは別途確認のこと
4. 今⽇(IaaS)の流れ ・講義: 1-1.5h 程度 ・クラウド、IaaSについて ・注: 知識量が多く駆け⾜なので、 気になるところは別途確認のこと ・実習: 残り時間全て ・IaaSクラウドデザインパターンの実装 ・簡易カオスエンジニアリングに耐える
5. 講義の流れ
6. ・クラウド全般の知識 ・IaaSについて ・Instagramライクなアプリの設計で学ぶ ・カオスエンジニアリング 講義の流れ
7. ɾΫϥ΢υશൠͷ஌ࣝ ・IaaSについて ・Instagramライクなアプリの設計で学ぶ ・カオスエンジニアリング 講義の流れ
8. そもそもクラウドとはなにか？ NISTによるクラウドコンピューティングの定義 https://www.ipa.go.jp/files/000025366.pdf （最近だとちょっと古い感じの内容 + 少しお硬いので…）
9. ・対照的なのはオンプレ ・⾃社でサーバを抱えること ・クラウド ⇒ 抱えない ・オンデマンドで必要なときにリソース確保 ・コスト ・オンプレ：将来を予測して投資 ・クラウド：必要なだけ払う（⼤量に使った場合はむしろ⾼いことも） そもそもクラウドとはなにか？
10. クラウドを提供するサービス達 ・GCP / Google ・AWS / Amazon Web Services ・Azure / Microsoft ・ECL 2.0 / NTT Com
11. クラウドの分類① ・IaaS / Infrastructure as a Service ・もっともベーシック ・他を⽀える基礎として抑えておくのが重要 ・IaaSが向いている機能もある ・VM、ネットワーク、ストレージを貸出 ・PaaS / Platform as a Service ・アプリ＋ミドルウェア以外をマネージ ・HerokuやGoogle App Engineが有名
12. クラウドの分類② ・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とか
13. レイヤで 分類⽐較してみる
14. オンプレは全部やる、データセンタすら作る データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ ⾃社は事実、データセンタを多く構築している
15. ホスティングはデータセンタ内のサーバを拝借 データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング
16. IaaSはOS以上をユーザがやる データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ IaaS
17. CaaSはコンテナ以上をユーザが対応 データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ IaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ CaaS
18. PaaSはアプリだけ⾃分で作る データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ IaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ CaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ PaaS
19. FaaSは関数だけ⾃分で作る データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ IaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ CaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ PaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ FaaS
20. SaaSは使いたい機能だけ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ IaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ CaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ PaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ FaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ SaaS
21. それぞれに向き不向きがある データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ オンプレ データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ ホスティング データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ IaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ CaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ PaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ FaaS データセンタ 物理サーバ 仮想化 OS コンテナ 実⾏環境 アプリ 関数 データ ネットワーク ストレージ SaaS ⼤ ← ⾃由度 → ⼩ ⼤ ← ⼯数→ ⼩
22. 参考: 使い分けはCNCFのホワイトペーパーがオススメ https://github.com/cncf/wg-serverless
23. ・クラウド全般の知識 ɾ*BB4ʹ͍ͭͯ ・Instagramライクなアプリの設計で学ぶ ・カオスエンジニアリング 講義の流れ
24. IaaSの得意領域 ・既存のシステム移⾏ ・特定のOS/Kernelに縛りがある ・GPUが必要 ・HTTP/S以外のプロトコル
25. IaaSでは ・GUIをポチポチ or APIを叩くと VMが上がる + NW と ストレージが付属
26. IaaSでは ・GUIをポチポチ or APIを叩くと VMが上がる + NW と ストレージが付属 ・NWもまるごと設計できるので ⾃由度は⾮常に⾼い その半⾯、イマイチな設計もしやすい (クラウドの⼒を使いこなせない)
27. ではどうするか？ ・もともと有名なやつ （と類似の概念で…）
28. クラウドデザインパターン(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年ぐらいに流⾏していた （今も現役で動いているものは多いはず）
29. ・クラウド全般の知識 ・IaaSについて ɾ*OTUBHSBNϥΠΫͳΞϓϦͷઃܭͰֶͿ ・カオスエンジニアリング 講義の流れ
30. InstagramみたいなWebアプリを想像 ・まず、HTML/JavaScript/CSSを取得 ・ユーザ登録・ログイン認証 ・画像やコメントの投稿・修正・閲覧 ・当然、それらは保存される必要がある ・ユーザのAppへPush通知 これを作りたい、さてどうしよう？
31. もし研究室でやるなら VM App + DB ・サーバ(VM)を1台たてる ・Webサーバ(nginx) ・Rails/Djangoとかでロジック ・MySQLやPostgreSQLにデータを保存 ・落ちたら苦情ドリブンで復旧 ・全部とぶとヤバいので たまにRDBのバックアップをとる
32. お仕事でやる場合の 重要概念
33. SPOFを避ける ・SPOF / Single Point Of Failure ・⽇本語だと「単⼀障害点」 ・その単⼀箇所が働かないと システム全体が障害となるような箇所 補⾜) 全てSPOFを避けるのではなく、費⽤対効果でSPOFを許容するケースもある
34. SPOFを避ける ・SPOF / Single Point Of Failure ・⽇本語だと「単⼀障害点」 ・その単⼀箇所が働かないと システム全体が障害となるような箇所 ・解決⽅法の例 ・冗⻑化 ・落ちても⾃動復旧させる 補⾜) 全てSPOFを避けるのではなく、費⽤対効果でSPOFを許容するケースもある
35. IaaS x Webアプリ x CDP
36. 最初の構成 VM App + RDB
37. 圧倒的に重要なDBを冗⻑化 App RDB (Primary) RDB (Secondary) Primaryが落ちたら SecondaryをPrimaryに昇格し 接続先を切り替え
38. 圧倒的に重要なDBを冗⻑化 App RDB (Primary) RDB (Secondary) 参考： ・⾊々なDBの冗⻑化 ・ACT/ACT、マルチマスタ ・Primary/Secondary、ACT/SBY -> 障害時はFailOver Master/Slave(Slaveという⾔葉がいまいちなので最近使わない) ・使うDBの種類、プロダクトによって異なる
39. Appも冗⻑化していく App RDB (Primary) RDB (Secondary) App
40. 参考: スケールアウト/スケールイン App RDB (Primary) RDB (Secondary) App App ・ ・ ・ ス ケ ル ア ウ ト ス ケ ル イ ン
41. どうやってAppにリクエストを振り分ける？ App RDB (Primary) RDB (Secondary) App
42. 代表的案な2⽅式
43. 代表的案な2⽅式
44. 結果的にこうなる App RDB (Primary) RDB (Secondary) App LB LB DNS ラウンド ロビン ・IaaSを使った場合の超基本形
45. さらにマネージドサービスを使うと… App App DNS ラウンド ロビン※ クラウド 提供LB クラウド 提供DB ※ クラウドによってラウンドロビンするかは異なる GCPの場合は、単⼀IPアドレスでIPエニーキャストで対応
46. 参考: Cloud Load Balancing(GCP Managed LB)
47. 参考: Cloud SQL(GCP Managed RDB)
48. ・クラウド全般の知識 ・IaaSについて ・Instagramライクなアプリの設計で学ぶ ɾ৑௕Խʹ͍ͭͯ ・カオスエンジニアリング 講義の流れ
49. 冗⻑化したときの ハマりどころ
50. 50 App(Rails) App(Rails) ①ログイン ログインを考える
51. 51 App(Rails) App(Rails) ①ログイン ②セッション キャッシュ ログインを考える
52. 52 App(Rails) App(Rails) ①ログイン ③GET ログインを考える ②セッション キャッシュ
53. 53 App(Rails) App(Rails) ①ログイン ③GET ④キャッシュが無くて アクセスがコケる ログインを考える ②セッション キャッシュ
54. 54 ①スティッキーセッション ・ロードバランサなどを利⽤して セッションを払い出したアプリサーバと 同⼀のアプリサーバに常に接続させる 代表的な対応策 x 2
55. 55 ①スティッキーセッション ・ロードバランサなどを利⽤して セッションを払い出したアプリサーバと 同⼀のアプリサーバに常に接続させる ②セッションの状態を外に追い出す ・KVSなどを利⽤してセッションを追い出す ・クラウドを活かすならコッチ ・スケールイン/アウトに対応しやすいから 代表的な対応策 x 2
56. 56 App(Rails) App(Rails) ①ログイン ②セッション ③GET ④セッションを取りに⾏く KVSとか ②セッションを書き出す セッションを外に出した例
57. 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
58. 58 ・スティッキーセッション ・ロードバランサなどを利⽤して セッションを払い出したアプリサーバと 同⼀のアプリサーバに常に接続させる ・セッションの状態を外に追い出す ・KVSなどを利⽤してセッションを追い出す ・クラウドを活かすならコッチ 重要な概念
59. 59 ・スティッキーセッション ・ロードバランサなどを利⽤して セッションを払い出したアプリサーバと 同⼀のアプリサーバに常に接続させる ・セッションの状態を外に追い出す ・KVSなどを利⽤してセッションを追い出す ・クラウドを活かすならコッチ スケールアウトさせるときの肝 ＝いかに状態/ステートを 外にだすか？閉じ込めていくか？ (この概念はコンテナ時代でも重要) 重要な概念
60. 60 ①APP ②RDB ③KVS ④Other ユーザが写真を投稿したらどこに保存？
61. 61 ①APP ②RDB ③KVS ④Other ①APP 状態を追い出す、 閉じ込められてない例 ①はNG、リクエスト先によっては存在しない
62. 62 ①APP ④Other ④が多い、よく使うのはオブジェクトストレージ ⾃社クラウドであるCloudnの オブジェクトストレージへ貯め込む例
63. 冗⻑化のめんどくささ
64. 冗⻑化対象は⾊々とある ・RDB (MySQL/Postgres/Oracle/…) ・KVS (Redis/…) ・LB ・全部やるのは⾮常に⼤変 ・ちゃんとFailoverするの？コネクションは？ ・直接、お客様価値につながらない部分 ・Instagramだったら、ここは本質ではない ・そもそも、その価値(仮説)が刺さるか謎
65. そこで各クラウドプロバイダはマネージドを⽤意 ・RDB ・AWS RDS ・GCP CloudSQL ・KVS ・AWS ElastiCache ・GCP / Cloud DataStore ・LB ・AWS ALB/NLB/CLB ・GCP LB (その他、SQLで扱えるDBは⾊々あるが割愛) ・⾃動で対応 ・セキュリティ パッチアップデート ・冗⻑化 ・バックアップ
66. そこで各クラウドプロバイダはマネージドを⽤意 ・RDB ・AWS RDS ・GCP CloudSQL ・KVS ・AWS ElastiCache ・GCP / Cloud DataStore ・LB ・AWS ALB/NLB/CLB ・GCP LB (その他、SQLで扱えるDBは⾊々あるが割愛) ・⾃動で対応 ・セキュリティ パッチアップデート ・冗⻑化 ・バックアップ 重要なのは サービス・プロダクトの 本来の価値にリソースを集中すること (サボれる部分はサボる)
67. どこまで冗⻑化するか？
68. 冗⻑化の単位 ・HDD/SSD単位(RAID) ・サーバ単位 ・ラック単位 ・データセンタ単位、Availability Zone単位 ・リージョン単位 ・クラウド単位 結局、サービス・プロダクト特性にあわせて検討
69. スケールアウト/イン or スケールアップ/ダウン
70. 再掲: スケールアウト/スケールイン App RDB (Primary) RDB (Secondary) App App ・ ・ ・ ス ケ ル ア ウ ト ス ケ ル イ ン
71. スケールアップとダウン ・スケールアップ ・CPUの数を増やす、メモリを増やす ・スケールダウン ・CPUの数を減らす、メモリを減らす なお… 現代は、スケールアウトを上⼿く使うのが主流 (スケールアップ/ダウンも使わないわけじゃない、使い分け)
72. 12 Factor Apps https://12factor.net/ja/
73. I. バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係を明⽰的に宣⾔し分離する III. 設定を環境変数に格納する IV.バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実⾏の3つのステージを厳密に分離する VI.アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する VII.ポートバインディングを通してサービスを公開する VIII.プロセスモデルによってスケールアウトする IX.⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する X. 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ XI.ログをイベントストリームとして扱う XII.管理タスクを1回限りのプロセスとして実⾏する 参考: 12 Factor Apps の各項⽬
74. I. バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係を明⽰的に宣⾔し分離する III. 設定を環境変数に格納する IV.バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実⾏の3つのステージを厳密に分離する VI.アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する VII.ポートバインディングを通してサービスを公開する VIII.プロセスモデルによってスケールアウトする IX.⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する X. 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ XI.ログをイベントストリームとして扱う XII.管理タスクを1回限りのプロセスとして実⾏する 参考: 12 Factor Apps の各項⽬ 微妙にイメージが湧きにくいので、たとえばAWSなら
75. https://www.slideshare.net/AmazonWebServicesJapan/the-twelvefactor-appaws
76. https://codezine.jp/article/detail/10402
77. 少し戻って…
78. 再掲: InstagramみたいなWebアプリを想像 ・まず、HTML/JavaScript/CSSを取得 ・ユーザ登録・ログイン認証 ・画像やコメントの投稿・修正・閲覧 ・当然、それらは保存される必要がある ・ユーザのAppへPush通知
79. 再掲: InstagramみたいなWebアプリを想像 ・まず、HTML/JavaScript/CSSを取得 ・ユーザ登録・ログイン認証 ・画像やコメントの投稿・修正・閲覧 ・当然、それらは保存される必要がある ・ユーザのAppへPush通知 ⇒ ⼀度に⼤量配信すると処理溢れで 捌けなくなることも…
80. Queueを挟んで分散する Queue App App 送りたいタスクを ⽣成(Produce) 配信App 配信App Queueからタスクを 取得して配信 (Consume)
81. ・クラウド全般の知識 ・IaaSについて ・Instagramライクなアプリの設計で学ぶ ɾΧΦεΤϯδχΞϦϯά 講義の流れ
82. https://www.oreilly.com/ideas/chaos-engineering
83. カオスエンジニアリングとは “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.” ・分散システムにおいて ・本番環境のように荒れる環境にも耐える能⼒を持っている ・という確信を得るための実験/検証の規律
84. どのようなことをするか？ ・(⼀番有名なものだと） 商⽤のVMをランダムで落とす ・リージョンやデータセンタ単位で障害を起こす ・あるトラフィックに対して⼀定期間 レイテンシを増加させる ・ある関数がランダムに例外を投げるようにする ・システム間の時刻をずらす ・デバイスドライバでI/Oエラーを起こす ・クラスタのCPUを最⼤限まで使い切る
85. なぜこんなことを？ ・お客様価値を落とすシステムの弱みを学び それを改善することで、 システムの信頼性を⾼められるから （実際に障害を起こさないと 分からないことは⼭程ある…）
86. カオスエンジニアリング適⽤の前提条件 ・シンプルな質問に答えられるか？ 「あなたのシステムは、サービスの障害や ネットワークレイテンシの急激な上昇といった 現実世界の出来事から回復できるか？」 もし、no なら先にやることがある。 ・⾃分のシステムの状態を監視できているか？ + Steady State(正常な状態) を定義できているか？
87. 再掲：実習では少しだけ味⾒してみる (カオスエンジニアリングの⼀部だけ体験してみる) ・(⼀番有名なものだと） 商⽤のVMをランダムで落とす ← 採⽤ ・リージョンやデータセンタ単位で障害を起こす ・あるトラフィックに対して⼀定期間 レイテンシを増加させる ・ある関数がランダムに例外を投げるようにする ・システム間の時刻をずらす ・デバイスドライバでI/Oエラーを起こす ・クラスタのCPUを最⼤限まで使い切る
88. 現実世界では もっと考えることがある
89. たとえば… ・運⽤って何やるんだっけ？ ・冗⻑化してても落ちたら？ ・依存しているAPIが不安定に… ・使ってるライブラリの脆弱性が⾒つかった？ ・あれ、そもそも監視って何やるんだっけ？ ⇒ トピックはいくらでもあるので 書籍、オンライン資料、実務で⾝につける
90. （参考） 個⼈的にいくつか良い クラウド向けの 勉強リソース/書籍
91. https://www.oreilly.co.jp/books/9784873118642/ ⼊⾨ 監視
92. https://www.slideshare.net/AmazonWebServicesJapan AWS Black Beltシリーズ
93. https://cloudplatformonline.com/onair-japan.html Google Cloud OnAir
94. まとめ
95. 本⽇お話したこと ・クラウドとは？IaaSとは？ ・Instagram的なアプリを作る⽅法 ・CDPを使う ・マネージドを使う ・カオスエンジニアリング おしまい！（質問があれば！）