AWSコンテナサービス入門 / nds60-jaws-ug

AWSコンテナサービス入門  NDS第60回 JAWS-UG長岡第3回     

自己紹介  • @hayajo (id:hayajo_77)  • 株式会社はてな  • Mackerelチーム SRE 

今日のゴール  • コンテナとは何かを理解する  • AWSのコンテナサービスの特性を理解する 

話すこと  • コンテナの基礎知識  • コンテナ運用の課題  • AWSコンテナサービスの紹介 

話さないこと  • アプリケーションのコンテナ化の手順  • コンテナ実行環境の構築、運用方法 

コンテナとは？ 

コンテナ  • OSリソースを隔離・制限したプロセス  • 仮想マシンのようなサンドボックスを実現 

コンテナが隔離・制限するもの  • PID、マウントテーブル、ネットワークなどを隔離  • CPU、メモリ、I/Oなどを制限  • 権限を細分化して制限  see also. 「コンテナ技術入門
- 仮想化との違いを知り、要素技術を触って学ぼう」   https://employment.en-japan.com/engineerhub/entry/2019/02/05/103000  

Docker  • 複数コンテナのライフサイクル管理  • Dockerイメージの管理  ◦ アプリケーションと依存関係をパッケージ化  ◦ コンテナのルートファイルシステムとして利用  ◦
環境の一貫性、再現性を実現 

プロセスコンテナ VM 仮想化メモリ OS ハードウェア Isolation 低高
フットプリント小大プロセス・コンテナ・VM 

なぜコンテナか  • Consistency  • Portability  • Isolation  • Efficiency 

コンテナの運用 

Dockerのスコープ  • シングルホストのコンテナ  ◦ ホストがダウンしたらそれまで  • 冗長性、可用性を高めるには  ◦ 複数ホストでのコンテナ運用が必要  ◦
Dockerのスコープ外 

コンテナの運用  • ライフサイクル管理  • デプロイ  • ヘルスチェック  • モニタリング  •
スケーリング  • スケジューリング  • ネットワーキング  • 構成管理  etc. 

運用の自動化が必要  • 信頼性の向上  • 運用負荷の軽減 

AWSのコンテナサービス 

コンテナ運用を自動化するAWSサービス  • AWS Elastic Beanstalk (EB)  • Amazon Elastic Container
Service (ECS)  • Amazon Elastic Kubernetes Service (EKS) 

AWS Elastic Beanstalk (EB) 

EB  • PaaS  ◦ インフラの手間を削減し、サービス開発に注力する  • ウェブサービスを提供するために必要なコンポーネントを一元管理  ◦ ネットワーク(VPC)、ロードバランサ(ELB)、VM(EC2)、データベース (RDS)、モニタリング(CloudWatch)
など 

Dockerもサポート  • Single Container (Docker)  ◦ 単一のコンテナをデプロイ  • Multi Container
(ECS)  ◦ 依存関係にある複数のコンテナをまとめてデプロイ  ◦ ECSのTaskとして実行   

スケーリング  • EC2単位でスケーリング  ◦ Amazon EC2 Auto Scaling  • コンテナ/Task単位ではスケールできない 
◦ EC2インスタンスとコンテナ/Taskは1対1の関係  ◦ VMなのでスケールの速度はそれなり 

EBを選択する理由  • インフラの構築、運用の手間を削減したい  • 頻繁にスケールする必要がない  • 独立したサービスとして完結できる  • コンテナを使い始めたばかり 

Amazon Elastic Container Service (ECS) 

ECS  • コンテナオーケストレーションサービス  • コンテナの宣言的管理  • 柔軟なスケジューリングとスケーリング  • Service →
Task → Container というトポロジをとる  ◦ スケールの最小単位はTask  ▪ 依存関係にある複数のコンテナをまとめた論理的単位 

コンテナオーケストレーション？  • コンテナの運用を自動化する 

コントロールプレーンとデータプレーン  • コントロールプレーン  ◦ コンテナを管理する場所  • データプレーン  ◦ コンテナが稼働する場所  コントロールプレーン
デプロイ、スケジューリング、スケーリング、コンテナの構成管理データプレーンコンテナの実行、状態のフィードバック

in ECS  • コントロールプレーン  ◦ ECS  • データプレーン  ◦ EC2起動タイプ 
◦ Fargate起動タイプ  コントロールプレーンデータプレーン

EC2起動タイプ  • データプレーンとしてEC2インスタンスによるクラスタを構築する  • EC2インスタンスはユーザーが構築・管理する必要がある  ◦ キャパシティ管理、セキュリティ対策が必要  ◦ ecs-agentのアップデート 

Fargate起動タイプ  • フルマネージドのデータプレーン  ◦ コンテナホストの管理不要  ◦ コンテナだけに注力できる  • コンテナに直接アタッチできないためデバッグが難しい  “また、FargateコンテナにSSHして、内部の情報を確認できるようにするなども予定している”
  https://www.atmarkit.co.jp/ait/articles/1906/19/news022.html  

ECSを選択する理由  • すでにAWSで稼動しているシステムのコンテナ化  • マイクロサービスも視野に入れている  • コスト最適化 

EC2起動タイプ  vs  Fargate起動タイプ 

EC2起動タイプを選択する理由  • 大規模ワークロードで実行コストを最適化したい  ◦ リザーブドインスタンスやスポットインスタンスを活用 

Fargate起動タイプを選択する理由  • 大規模ワークロードで運用コストを最適化したい  • 小規模ワークロードでときどき負荷が高くなる  • 負荷が小さい  • バッチ処理 

Amazon Elastic Kubernetes Service (EKS) 

EKS  • Kubernetesのマネージドサービス  • フルマネージドのコントロールプレーンを提供  • データプレーンはユーザーが構築・管理する  ◦ ECS/EC2起動タイプと同じような感じ  ◦
Fargate for EKSに期待  https://github.com/aws/containers-roadmap/issues/32  

コントロールプレーン EKS  データプレーン

Kubernetes?  • OSSのコンテナオーケストレーションツール  • 高い拡張性  ◦ インフラの拡張、APIの拡張  • 充実したエコシステム 

ref. Cloud Native Landscape https://github.com/cncf/landscape  

EKSのバージョンライフサイクル  ref. Amazon EKS バージョンライフライクルの更新   https://aws.amazon.com/jp/blogs/news/updates-to-amazon-eks-version-lifecycle/  

EKSを選択する理由  • オンプレでKubernetesを運用してい(る|た)が運用負担を減らしたい  • Kubernetesのエコシステムを利用したい  • 運用を積極的に自動化したい  • ベンダーロックインの回避  •
冗長性、可用性を更に高めたい 

各サービスの特性 

Simplicity  Convenience  Flexibility  EB  ECS  EKS 

まとめ 

まとめ  • コンテナはOSを仮想化してリソースを分割する  • コンテナの冗長性、可用性を高めるには運用の自動化が必要  • AWSには特性の異なる複数のコンテナ運用自動化サービスがある 

(そもそも)  コンテナ運用に至るまでの道のり 

ref. Cloud Native Landscape https://github.com/cncf/landscape  

サービス目的と成長、運用を考慮した  無理のないコンテナ運用を。 

AWSコンテナサービス入門 / nds60-jaws-ug

AWSコンテナサービス入門 / nds60-jaws-ug

More Decks by Hayato Imai

Other Decks in Technology

Featured

Transcript