Recommended
More Related Content
What's hot
What's hot (20)
Similar to If aws is destroyed, can you continue work
Similar to If aws is destroyed, can you continue work (20)
Recently uploaded
Recently uploaded (9)
If aws is destroyed, can you continue work
- 2. 疑問 ？結局、どのサービスでコンテナを運用すればいいの 自前 or サービス（EKS、ECS、GKE、AKS） • 自前の学習コスト、資産化を許容する、運用人材とその学習コ スト、管理コストに耐えれるか？ • 基本は、サービス活用を推奨する ？コンテナ運用ってどんな感じ
- 3. コンテナ運用マップ Azure Kubernetes Service Google Kubernetes Engine Docker Kubernetes OS Elastic Kubernetes ServiceElastic Container Service Amazon 独自 Elastic Compute Cloud On-Premis Amazon Microsof Google Azure Virtual Machines Google Compute Engine Soft Hard
- 4. 今、AWSを使っているか？ 使っているなら、EKS。 使っていないなら、GKE ※規定でオンプレミス制限がある場合や優秀な運用担当者を持った企業は、自前も検討可能。 ただし、Kubernetes の学習コストは高く、サービス活用が妥当。 基本的に、コンテナ運用は、GKE 一強の状態。 しかし、現在、AWS サービスを活用しているユーザならば、サービス 連携や管理のメリットからEKS の選択は妥当である。
- 5. 参照：https://kubedex.com/google-gke-vs-microsoft-aks-vs-amazon-eks/ サービスの評価 サービス On-Premis Amazon Elascit Container Service(:ECS) Amazon Elastic Container Service for Kubernetes(:EKS) Google Kubernetes Engine(:GKE) Azure Kubernetes Service(:AKS) Regions Supported Limited Almost Worldwide Almost Worldwide Worldwide Almost Worldwide Cluster Create Time 3 minutes 20 minutes 20 minutes 3 minutes 20 minutes Auto Repair Yes No No β No Cross region LB No No No Yes No Bare metal nodes Yes No Yes No No Container as a Service integration No No No No Virtual Kubelet with ACI 基本的にGKE が優れている。しかしながら、AWS の使い勝手は評価が 高く、既存でAWS を利用しているユーザは、EKS が良い。
- 6. 参考～Amazon コンテナ ロードマップ～ Amazon には珍しく、開発ロードマップをユーザに開示している。特 に、コンテナ管理単位 ”Pod” のセキュリティグループを検討するなど、 既存のAWS ユーザにはたまらない機能を検討していることが分か る。 Amazon は、K8s において、Googleが有利な位置におり、Amazon の有利なEC2 ライクな機能で差別化し、CaaS 市場の王者を狙う構え だ。 参考： https://github.com/aws/containers-roadmap/projects/1 Comは、ユーザとして、基盤を使う力を蓄える必要がある。
- 7. ECS の運用とは
- 9. • ECS 上に展開したコンテナへアクセスしている • OS より下の運用をサービス化している 構成 Amazon ECS Tetris Container OS : alpine Mid : nginx Con : html Ser : Fargate ユーザ準備 サービス
- 10. 展開/運用の仕方 1. コンテナイメージの作成 2. ECS へ展開
- 13. コンテナ運用の形 サービス ：Elastic Container Service ( : ECS) 基本は、ECS で十分。 マルチ基盤運用の場合、ECS では対応できず、EKS 等のサービス が必要である。 （Kubernetes の管理、コンテナ間のネットワーク接続、、、）
- 15. まとめ • 結局、マルチ基盤を運用する企業 • Web はクラウド。基幹サービスはオンプレミス。分析/予測はGPU 。 • アプリケーション管理は、コンテナが主流になりつつある • 例：nginx イメージ数(Docker HUB : 50,427, AWS Marketplace : 155) • コンテナ管理(Docker)だけでは、以下の環境に不向き • 止められないサービスの動作（セルフヒーリング機能なし） • 一般サーバ, GPUサーバ, クラウドなどマルチ基盤（基盤単位の管理） = マルチクラウドチームは習得必須科目 • アプリ展開のコンテナは、Kubernetes 活用で、 マルチ基盤へ止められないサービスを展開できる
- 17. AWS のサービスが停止した場合、業務は継続できるか？ AWS コンテナオーケストレーションのオーケストレーション基盤 (Rancher) Azure コンテナ 管理基盤 コンテナ 管理基盤 コンテナ オーケストレーション基盤 コンテナ オーケストレーション基盤 コンテナ コンテナ AWS 壊滅でも業務を継続 オンプレミス コンテナ 管理基盤 (Docker) コンテナ オーケストレーション基盤 (Kubernetes) コンテナ
- 18. 現状、必要な基盤とネック マルチ K8s 環境のオーケストレータに需要 クラウド基盤 HCI 基盤 コンテナ 管理基盤 コンテナ App Library Library コンテナオーケストレーションのオーケストレーション オンプレミス 基盤 (GPU) コンテナ 管理基盤 コンテナ 管理基盤 コンテナ App Library Library コンテナ オーケストレーション基盤 コンテナ オーケストレーション基盤 コンテナ オーケストレーション基盤 コンテナ コンテナ
- 20. •コンテナオーケストレーションのオーケストレーションの運用 今日のお話 クラウド基盤 HCI 基盤 コンテナ 管理基盤 コンテナ App Library Library コンテナオーケストレーションのオーケストレーション オンプレミス 基盤 (GPU) コンテナ 管理基盤 コンテナ 管理基盤 コンテナ App Library Library コンテナ オーケストレーション基盤 コンテナ オーケストレーション基盤 コンテナ オーケストレーション基盤 コンテナ コンテナ
- 21. モックアップの構成 Amazon Rancher Role Master Docker Rancher Docker Kubernetes モックイメージは、ユーザ数 50 規模で、AWS とAzure で個別に開発が進んでいる 会社。 サービス基盤 の統合か分割か、検討の結果、分離して運用することとした。 サービス継続性を高め、ベンダロックを回避する方針で、複数のクラウド上にアプリケーションを展開する。 Control Plane / Node 1 Docker Amazon Azure Control Plane / Node 2 Amazon Linx Ubuntu
- 22. ハードルとは？ AWS とAzure のサービス理解。 VPCやSG、IAMでつまずく。 次に、Rancher。これは日本語の情 報が少なく、手間取った。 App の改修も手間だが、分かれ ば、大実現可能なレベル。 AWS Rancher Containr App Azure 難易度バベルと内訳 AWS Kubernetes Containr App Azure 2017年 2019年
- 23. なぜ、Rancher ? ECS や Azure Kubernetes でも同じ環境は構築できます。 ただし、構築ナレッジは、各社の基盤に偏ります。 （上を受け入れれるなら、ECS 等で作れば良い） 私は、どの環境でも作れ、運用できることを目指して、Rancher を選 択しました。 （ECS じゃないと作れません。って言いたくない）
- 24. ご静聴ありがとうございます