AWSコンテナサービス入門 NDS第60回 JAWS-UG長岡第3回
View Slide
自己紹介 ● @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には特性の異なる複数のコンテナ運用自動化サービスがある
(そもそも) コンテナ運用に至るまでの道のり
サービス目的と成長、運用を考慮した 無理のないコンテナ運用を。
hayajo
k1low
carta_engineering
you
mizunohiroaki
xibuka
asazutaiga
tsubakimoto_s
ikuyamada
tgalopin
nenonaninu
hanhan1978
konboi
jmmastey
keavy
destraynor
shpigford
rasmusluckow
kastner
chriscoyier
danielanewman
brettharned
mraible
thekraken
productmarketing