Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

2019年度 IaaS ワークショップ @ NTTコム

42 601 vues

Publié le

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

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

2019年度 IaaS ワークショップ @ NTTコム

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

×