jaws-ug Kyoto 20181026 Container-as-a-Service with Spotinst

Slide 1

Slide 1 text

JAWS-UG Kyoto 2018/10/26 ABEJA, Inc. Shogo Muranushi 15分で始める Container as a Service with スポットインスタンス

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 略歴トピック • インフラエンジニア • AWSを採⽤しハマる • AWSをたくさん使う • 資格を5冠取得 • AWSでDeepLearning  プラットフォーム作る • インフラ => SRE Tech Lead • マイクロサービスで遊ぶ • プロダクトオーナーになる

Slide 5

Slide 5 text

5 アジェンダ 1. Dockerとは 2. Dockerオーケストレーションツール云々 3. Container as a Serviceって 4. スポットインスタンス？Spotinstについて 5. 15分での作り⽅

Slide 6

Slide 6 text

6 まずは質問 •Docker使ったことある⼈？ •KubernetesやECSのようなサービス・ツール使ったことある⼈？ •スポットインスタンス使ったことある⼈？

Slide 7

Slide 7 text

7 今⽇のゴール

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 •Dockerとは •Dockerの歴史 •なぜDockerを使うのか •Dockerを本番運⽤する上で何が課題になるのか

Slide 10

Slide 10 text

• 2013年リリース • コンテナ型仮想環境を提供 • コンテナにアプリケーションを内包させる • LinuxコンテナやWindowsコンテナあり • 様々なインフラやOSで動作 10 とは

Slide 11

Slide 11 text

11 の歴史 • 2013年 • dotCloudがOSSで公開 • 2014年 • Googleは毎週20億のコンテナを起動していた • 1.0リリース • 2015年 • マイクロソフト、Google、Red Hat、VMware、Amazon Web Servicesらと共同でコンテナの標準化団体「Open Container Initiative」の発⾜ • （2011年） • Heroku エンジニアが The Twelve-Factor App を提唱出展元:https://www.sdxcentral.com/cloud/containers/deﬁnitions/containers-vs-vms/

Slide 12

Slide 12 text

12 The Twelve-Factor App (2011) Webアプリケーションを使いやすい形でスケーラブルにするための⽅法論 • I. コードベース • バージョン管理されている1つのコードベースと複数のデプロイ • II. 依存関係 • 依存関係を明⽰的に宣⾔し分離する • III. 設定 • 設定を環境変数に格納する • IV. バックエンドサービス • バックエンドサービスをアタッチされたリソースとして扱う • V. ビルド、リリース、実⾏ • ビルド、リリース、実⾏の3つのステージを厳密に分離する • VI. プロセス • アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する

Slide 13

Slide 13 text

13 • VII. ポートバインディング • ポートバインディングを通してサービスを公開する • VIII. 並⾏性 • プロセスモデルによってスケールアウトする • IX. 廃棄容易性 • ⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する • X. 開発/本番⼀致 • 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ • XI. ログ • ログをイベントストリームとして扱う • XII. 管理プロセス • 管理タスクを1回限りのプロセスとして実⾏する The Twelve-Factor App (2011) Webアプリケーションを使いやすい形でスケーラブルにするための⽅法論

Slide 14

Slide 14 text

14 なぜDockerを使うのか • リソース集約効率が上がる • 必要な⾔語やライブラリを閉じ込めるため、  ⼀つのサーバで複数の⾔語やバージョンを稼働させられる • 複数環境載せてもセキュリティ上分離可能（厳密には・・） • 環境の再現性が⾼い • アプリの実⾏環境構築が容易で、構築⾃体や問題発⽣の再現性が⾼い • ポータビリティ性が⾼い • どの環境でも動かすことが可能で、移⾏や複数環境構築が容易 • ローカルと本番の環境を限りなく合わせることも可能で、開発・テストが容易

Slide 15

Slide 15 text

15 Dockerを本番運⽤する上で何が課題になるのか • 複数コンテナの管理 • 本番利⽤するときは1コンテナではなくWeb、App、DBなど複数コンテナ • 可⽤性 • 正しく稼働していること、⾃動でリカバリすること • オートスケール • 負荷に応じて⾃動でスケールすること • モニタリング、セキュリティ、etc • それらを管理するツールが必要になってきた

Slide 16

Slide 16 text

16 オーケストレーションツール

Slide 17

Slide 17 text

17 以下の課題を解決 • 複数コンテナの管理 • 本番利⽤するときは1コンテナじゃなく複数コンテナ • Web、App、DBなど種類も複数 • 可⽤性 • 正しく稼働していること、⾃動でリカバリすること • オートスケール • 負荷に応じて⾃動でスケールすること • モニタリング、etc • それらを管理するツールが必要になってきた

Slide 18

Slide 18 text

18 オーケストレーションツールの歴史 • 2014 • GoogleがKubernetes、DockerがDocker swarm、AWSがECSを発表 • Mesos 0.21、Rancher 0.4リリース • 2015 • Docker swarm、Kubernetes 1.0リリース • CNCF（Cloud Native Computing Foundation）設⽴ • 2016 • Apache Mesos1.0 + Dockerサポート • Rancher1.0リリース

Slide 19

Slide 19 text

19 オーケストレーションツールの歴史 • 2017 • Fortune 100企業のKubernetesの採⽤率は54％を突破と報道（Redmonk） • DockerがKubernetesの統合を発表 • Azure、AWSもKubernetesマネージドサービス提供 • 2018 • Rancher2.0リリース + Kubernetesを標準に

Slide 20

Slide 20 text

20 なぜKubernetesがデファクトスタンダードになったのか • 定期的なメジャーアップデート • 3ヶ⽉ごとにアップデートを繰り返し、エンタープライズからのフィードバックも反映。本番稼働に耐えうるソフトウェアとして信頼を得た。 • によるエコシステムの拡⼤ • Kubernetesの成⻑と共にCNCFに各⼤⼿企業が参加 • Alibaba、AWS、Google、IBM、Microsoft、Oracle、Redhat、VMware、etc • 様々な良質なOSSがCNCFのエコシステムに • Prometheus、Fluentd、GRPC、containerd、cni、envoy、helm、etc • その他の要素含め、これらにより企業と開発者が集まるサイクルができて、圧倒的な速度で成⻑を遂げた

Slide 21

Slide 21 text

21 と、⾔われていますが個⼈的には • 設計がイマドキ • ベストプラクティスに添えば、良い設計になる • エコシステムのOSSもセンスが良い • Istio(Envoy)、Kubeflow、Knative、etc • マイクロサービスの課題を解決しやすい • UNIXの哲学、The Twelve-Factor App、コンテナデザインパターンを採⽤ • マイクロコンテナになる • マイクロサービス化していく • マイクロサービスの管理⾟い • Istio登場 <<=== イマココ

Slide 22

Slide 22 text

22 Kubernetesは完璧か？使いこなすには？ • Kubernetesは銀の弾丸ではない • マイクロサービスに耐えうる組織設計と⽂化形成と相性が良い（メルカリさん） • 組織設計 = コンウェイの法則 • ⽂化形成 = 価値提供の速度向上・⽣産性向上を徹底する⽂化 • ただし、マイクロサービスには課題がある • 分散システムのトレーシング、多数のシステム管理、⼀貫性、テスト、、、 • 完璧ではないけど、徐々に良い⽅向に向かっています • コンウェイの法則 • 組織の設計するシステムは、その組織のコミュニケーション構造をそのまま反映した設計になる

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

26 Container as a Service

Slide 27

Slide 27 text

27 話を戻して Container as a Service の定義 •IaaS = Infrastructure as a Service •PaaS = Platform as a Service •Container as a Service =   Container基盤を「サービス」として利⽤する

Slide 28

Slide 28 text

28 Container as a Serviceイメージ Container Definition Container Definition 28 Black box Infra

Slide 29

Slide 29 text

29 AWS Fargate = Container as a Service? • Yes • しかしEC2のオンデマンド、スポットインスタンスより⾼い • 参考価格 ( Tokyo region ) • Fargate = 2CPU / 8GB = $150/month • オンデマンド(m4.large) = $95/month • スポットインスタンス(m4.large) = $25/month • 細かい計算やPros/Consはブログを参照ください

Slide 30

Slide 30 text

30 Fargateは⾼いので ECSにスポットインスタンスを組み合わせた

Slide 31

Slide 31 text

31 しかしECSには罠があった • ECSとEC2 (AutoScale)の溝 • ECSのリソース不⾜（ECSイベント）を検知してスケールしてくれない • EC2 AutoScaleはCloudWatchメトリクスベースのスケーリング • 余剰リソースが空いてても集約してくれない • コンテナサイズでリソースを確保してくれない • ECSはCPU/MEMの空き容量ベースの確保 • インスタンスのTerminate時に⾃動でコンテナをDrainしてくれない • ⾃分でコンテナをDrainしてからインスタンスをTerminateする必要がある • ホストのBlue / Green Deploymentは⾃分で構築する必要がある（Teraform?CloudFormation?）

Slide 32

Slide 32 text

Slide 33

Slide 33 text

33 それらを解決してくれるのが

Slide 34

Slide 34 text

34 ( ElastiGroup )

Slide 35

Slide 35 text

35 ( ElastiGroup ECS Integration ) • ECSのリソース不⾜（ECSイベント）を検知して⾃動でスケール • 余剰リソースがギリギリでも⼤丈夫 • 余剰リソースが空いたら⾃動で集約 • 集約効率がギリギリまで上がる • 必要なコンテナサイズ x 個数でリソースを確保 • 必要なコンテナサイズとCPU/MEMを考慮した空き容量計算が不要に • インスタンスのTerminate時に⾃動でコンテナをDrainする • 気をつける必要がなく安全にインスタンスを停⽌できる • ホストのBlue / Green Deploymentを強制してくれる • 安全に⼊れ替えができる

Slide 36

Slide 36 text

36 完成図 Container Definition Container Definition 36

Slide 37

Slide 37 text

37 15分で作る⼿順

Slide 38

Slide 38 text

38 前提 1. AWSアカウントがある（10分） 2. Spotinstアカウントがある（10分） 1. AWSアカウントを連携している（5分） 2. （14⽇間無料、クレカ不要）

Slide 39

Slide 39 text

39 先⽇、AWS公式のQuick Startが公開された。けど https://aws.amazon.com/jp/about-aws/whats-new/2018/10/deploy-spotinst-elastigroup-for- amazon-ecs-on-aws-with-new-quick-start/

Slide 40

Slide 40 text

40 作り⽅ 1. ECS Cluster作る、EC2をJoinさせる、ECS Serviceを作る（7分） 2. SpotinstでImportする（2分） 1. SecurityGroupやIAM、Userdataなど全て引き継がれる 3. EC2がデプロイされるのを待つ（3分） 4. 古いEC2(AutoScalingGroup)を0台にする（1分）

Slide 41

Slide 41 text

41 1. ECS Cluster作る、EC2をJoinさせる、ECS Serviceを作る（7分）

Slide 42

Slide 42 text

42 1. ECS Cluster作る、EC2をJoinさせる、ECS Serviceを作る（7分）

Slide 43

Slide 43 text

43 1. ECS Cluster作る、EC2をJoinさせる、ECS Serviceを作る（7分）

Slide 44

Slide 44 text

44 2. SpotinstでImportする（2分） C

Slide 45

Slide 45 text

45 2. SpotinstでImportする（2分）

Slide 46

Slide 46 text

46 2. SpotinstでImportする（2分）

Slide 47

Slide 47 text

47 3. EC2がデプロイされるのを待つ（3分）

Slide 48

Slide 48 text

48 4. 古いEC2(AutoScalingGroup)を0台にする（1分）

Slide 49

Slide 49 text

49 再掲 ( ElastiGroup ECS Integration ) • ECSのリソース不⾜（ECSイベント）を検知して⾃動でスケール • 余剰リソースがギリギリでも⼤丈夫 • 余剰リソースが空いたら⾃動で集約 • 集約効率がギリギリまで上がる • 必要なコンテナサイズ x 個数でリソースを確保 • 必要なコンテナサイズとCPU/MEMを考慮した空き容量計算が不要に • インスタンスのTerminate時に⾃動でコンテナをDrainする • 気をつける必要がなく安全にインスタンスを停⽌できる • ホストのBlue / Green Deploymentを強制してくれる • 安全に⼊れ替えができる

Slide 50

Slide 50 text

Slide 51

Slide 51 text

51 ECSのリソース不⾜（ECSイベント）を検知して⾃動でスケール Container Definition Container Definition 51 Black box Infra

Slide 52

Slide 52 text

52 余剰リソースが空いたら⾃動で集約 Container Definition Container Definition 52 Black box Infra

Slide 53

Slide 53 text

53 必要なコンテナサイズ x 個数でリソースを確保 Container Definition Container Definition 53 Black box Infra

Slide 54

Slide 54 text

54 インスタンスのTerminate時に⾃動でコンテナをDrainする Container Definition Container Definition 54 Black box Infra

Slide 55

Slide 55 text

55 Container as a Service With スポットインスタンスの完成

Slide 56

Slide 56 text

56 まとめ 1. Dockerとは 2. Dockerオーケストレーションツール云々 3. Container as a Serviceって 4. スポットインスタンス？Spotinstについて 5. 15分での作り⽅

Slide 57

Slide 57 text

57 ご静聴ありがとうございました