Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSコンテナサービス入門 / nds60-jaws-ug
Search
Hayato Imai
June 22, 2019
Technology
0
3k
AWSコンテナサービス入門 / nds60-jaws-ug
Hayato Imai
June 22, 2019
Tweet
Share
More Decks by Hayato Imai
See All by Hayato Imai
Kubernetes撤退、 その後のはてなの取り組み / kubernetes meetup tokyo number 52
hayajo
9
7.3k
Mackerelにおける Cloud Nativeへの取り組みと チームへ与えた変化 / CloudNative Days Tokyo 2020
hayajo
2
1.5k
MackerelにおけるKubernetes利用の取組みとこれから / Kubernetes Meetup Tokyo #22
hayajo
20
10k
Mackerelチームのコンテナ開発における戦略とこれから / 190722-cndt2019
hayajo
1
1.9k
コンテナのメトリクスと モニタリングパターン / 190320-sakura-event
hayajo
6
1.7k
Mackerelコンテナエージェントによる コンテナ監視について / Mackerel Meetup #13 Tokyo
hayajo
1
9.8k
Docker for Mac/Windows ではじめる Kubernetes / NDS55 Docker with Kubernetes
hayajo
16
15k
Terrafromで構築するマルチクラウドプラットフォームインフラストラクチャ / NDS53 Terraform
hayajo
0
430
Ncatをつかおう / Use Ncat
hayajo
1
3.7k
Other Decks in Technology
See All in Technology
因果AIへの招待
sshimizu2006
0
940
Ruby で作る大規模イベントネットワーク構築・運用支援システム TTDB
taketo1113
1
220
Overture Maps Foundationの3年を振り返る
moritoru
0
160
pmconf2025 - データを活用し「価値」へ繋げる
glorypulse
0
710
チーリンについて
hirotomotaguchi
5
1.5k
最近のLinux普段づかいWaylandデスクトップ元年
penguin2716
1
680
Microsoft Agent 365 を 30 分でなんとなく理解する
skmkzyk
1
1k
Kiro Autonomous AgentとKiro Powers の紹介 / kiro-autonomous-agent-and-powers
tomoki10
0
340
SSO方式とJumpアカウント方式の比較と設計方針
yuobayashi
7
530
寫了幾年 Code,然後呢?軟體工程師必須重新認識的 DevOps
cheng_wei_chen
1
1.2k
5分で知るMicrosoft Ignite
taiponrock
PRO
0
250
大企業でもできる!ボトムアップで拡大させるプラットフォームの作り方
findy_eventslides
1
640
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
225
10k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.2k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
The Language of Interfaces
destraynor
162
25k
GitHub's CSS Performance
jonrohan
1032
470k
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Transcript
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
None
なぜコンテナか • 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
サービス目的と成長、運用を考慮した 無理のないコンテナ運用を。