© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Ryosuke Iwanaga
Solutions Architect, Amazon Web Services Japan June 2016
DockerとAmazon ECSで
DevOpsを進化させる
今⽇の持ち帰り
•
DevOpsとDocker•
Dev and Ops•
Amazon ECSDevOpsとは?
DevOps
= このライフサイクル⾼速化の効率開発者 顧客
release test
build
plan monitor
デリバリーパイプライン
フィードバックループ
ソフトウェア開発のライフサイクル
モノリシックな開発ライフサイクル
開発者
release test
build
デリバリーパイプライン アプリ
2001
Amazonでの開発の変遷: 2001-2009
2009
モノリシックなアプリ チーム+
マイクロサービス ツーピッツァチーム+
Order UI User UI Shipping UI
Order Service
User Service
Shipping Service
Data Access
モノリシックアーキテクチャ
モノリシックアーキテクチャ - スケール
Order UI User UI Shipping UI
Order Service
User Service
Shipping Service
マイクロサービスアーキテクチャ
Order UI User UI UI
Order
Service Service Shipping
Service Order UI
Order UI User UI Shipping UI
UI
Order Service Order
Service
Service Service
Service Service
User Service
Shipping Service
マイクロサービスアーキテクチャ - スケール
マイクロサービスな開発ライフサイクル
開発者 サービス デリバリーパイプライン
release test
build
release test
build
release test
build
release test
build
release test
build
release test
build
サービス
•
マイクロサービスだけの話ではない•
部⾨、新規事業、社内向け/社外向け、等•
「サービス」は多くなってしまいがち•
スタートアップからエンタープライズまで同じ•
サービスが多くなれば、それだけパイプライン/devops も多くなる•
他のシステムと の統合テスト•
負荷テスト•
UIテスト•
侵⼊テストリリースプロセスの、4つの主要なフェーズ
Source Build Test Production
•
.javaファイル等 のソースコード をチェックイン•
新しいコードを 相互レビュー•
コンパイル•
単体テスト•
スタイルチェック•
メトリクス•
コンテナイメージ 作成•
本番環境へのデ プロイDevOpsの実態
Build Test Production
Source
Application Artifact
コードだけ書いて いればいい、、?
DevOpsの実態
Build Test Production
Source
Application Artifact
Provision Config
開発環境の構成の メンテナンスが必要
開発、テスト、本番で 環境に差異がある。。。
テストの需要がバラバラ
で管理が⼤変。。。。 オートスケールや ノード障害対応。。。
なるほど、
全てが必要なんですね。。。
複数のDevOpsでの実態
DevOpsの難しさ
•
扱うべきことが多すぎる•
ユニコーンな⼈/チーム•
多くの異なるパイプラインが存在•
サービス、⾔語、フレームワーク、バージョン、等コンテナはサービスにとって⾃然なもの
•
モデルがシンプル•
どんなアプリでも、どんな⾔語でも•
イメージがバージョン•
同じ成果物をテストしてデプロイする•
ステートレスなサーバの⽅が、変更リスクが下がるFROM ubuntu:14.04
MAINTAINER John Doe <[email protected]>
RUN apt-get update && apt-get install -y curl wget default-jre git
RUN adduser --home /home/sinatra --disabled-password --gecos '' sinatra RUN adduser sinatra sudo
RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers USER sinatra
RUN curl -sSL https://get.rvm.io | bash -s stable
RUN /bin/bash -l -c "source /home/sinatra/.rvm/scripts/rvm"
RUN /bin/bash -l -c "rvm install 2.1.2"
RUN /bin/bash -l -c "gem install sinatra"
RUN /bin/bash -l -c "gem install thin"
パッケージ
docker push docker pull
出荷
docker run
実⾏
Dockerを取り⼊れたDevOps
Build Test Production
Source
Application Image
Provision Config
コードだけ書いて いればいい!
Dockerを取り⼊れたDevOps
Build Test Production
Source
Dockerを取り⼊れたDevOps
•
Dockerを使うことで、パイプラインが同⼀になる•
どんな⾔語でも、どんなアプリケーションでも•
管理すべきものが減って、開発に注⼒できる•
アプリケーションとDockerfileに集中•
でも、もっとやれることがないか?Dev and Ops
Build Test Production
Source
Dev Ops
Dev
•
アプリと実⾏環境の開発に、専念 する•
不可変/廃棄可能なコンテナ•
継続的なデリバリーパイプラインDev and Ops
Ops
•
リソースとサービスの境界を 管理する•
クラスタ管理•
スケジューラ•
ログ、監視•
インフラを、如何なるアプリ ケーションからも分離させるDev and Ops
•
DevOpsの、アジリティ•
CI/CD、複数パイプライン•
伝統的な組織構造の、効率•
Devのスペシャリスト / Opsのスペシャリスト•
リソースの利⽤率をもっと⾼める•
重要な点: インフラは如何なるアプリにも依存しない•
だから、コンテナコンテナに適応したDevには…
The Twelve-Factor App
Twelve-Factorの主義
I.
コードベースバージョン管理される1つのコードベースと複数デプロイ
II.
依存関係依存関係を明⽰的に宣⾔し分離する
III.設定
設定を環境変数に格納する
IV.
バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う
V.
ビルド、リリース、実⾏ビルド、リリース、実⾏の3つのステージを厳密に分離する
VI.
プロセスアプリを1つ⼜は複数のステートレスなプロセスとして実⾏
VII.ポートバインディング
ポートバインディングを通してサービスを公開する
VIII.並⾏性
プロセスモデルによってスケールアウトする
IX.
廃棄容易性⾼速な起動とグレースフル停⽌で堅牢性を最⼤化する
X.
開発/本番⼀致開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ
XI.
ログログをイベントストリームとして扱う
XII.管理プロセス
管理タスクを1回限りのプロセスとして実⾏する
http://12factor.net/
コンテナに適応したOpsには…
Amazon EC2 Container Service
コンテナ管理を、あらゆるスケールで
何も準備する必要がない 完全な状態
制御と監視 スケール
柔軟なコンテナの配置
ロングランニングなアプリ バッチジョブ
複数のスケジューラ
AWSの基盤との連携
Elastic Load Balancing
Amazon Elastic Block Store Amazon Virtual Private Cloud Amazon CloudWatch
AWS Identity and Access Management
AWS CloudTrail
コンテナ管理
コンテナ管理とは?
•
利⽤可能なリソースを管理•
リソースの変化を追跡•
リソースへのリクエストを受け付ける•
正確性と⼀貫性を保証するCPU メモリ ポート
ディスク容量 ディスクIOPS ネットワーク帯域
リソース
{
"name": "simple-demo",
"image": "my-demo",
"cpu": 10,
"memory": 500,
"portMappings": [ {
"containerPort": 80,
"hostPort": 80 }
],
"entryPoint": [
"/usr/sbin/apache2",
"-D",
"FOREGROUND"
],
"essential": true },
“Task Definitions”
Tasks
Shared Data Volume Containers
launch
Container Instance
Volume Definitions
Container Definitions
スケジューラ
スケジューラとは?
•
必要な状態を決める•
現在の状態と⽐較する•
アクションを実⾏するCluster, Scheduler, Task
Scheduler
Manager Cluster
Task Definition Task
Agent
ECS Agent
Docker
Task
Container Instance
Container
ECS Agent Task
Container
https://github.com/aws/amazon-ecs-agent
Docker Task
Container Instance
Amazon ECS
Container
ECS Agent
ELB
Internet
ELB
User / SchedulerAPI Cluster Management Engine
Task
Container
Docker Task
Container Instance
Container
ECS Agent Task
Container
Docker Task
Container Instance
Container
ECS Agent Task
Container
AZ 1 AZ 2
Key/Value Store
Agent Communication Service
楽観的な状態共有モデル
Amazon ECS: スケジューラ
•
各スケジューラは定期的に現在のクラスタの状態を取得するCopy of cluster state Scheduler A Scheduler B
Cluster
Amazon ECS: スケジューラ
•
各スケジューラはクラスタ上にタスクを配置する•
各スケジューラはクラスタの現在の状態を更新するRun a task
Run a task
Amazon ECS: スケジューラ
•
もしリソースが既に確保されていたら、リクエストは拒絶されるRun a task on the same resource
=> Transactional
Amazon ECS: スケジューラ
•
楽観的な状態共有のスケジュール機構•
全てのスケジューラが、現在のクラスタの状態をいつでも⾒られるAmazon ECS Serviceスケジューラ
Serviceとは?
•
ロングランニングなアプリケーションをモデル化•
希望する状態を維持してくれる•
Serviceの更新で、デプロイ•
Elastic Load Balancingの後ろで動かすことも可能コンテナのスケジュール: ロングランニングアプリ
最⼩限の空間を使ってデプロイ:
minimumHealthyPercent
= 50%, maximumPercent = 100%Old version New version
コンテナのスケジュール: ロングランニングアプリ
サービスのキャパシティを落とさずに⾼速にデプロイ:
minimumHealthyPercent
= 100%, maximumPercent = 200%Old version New version
ケーススタディ: Segment
Segment
顧客のデータを1つのハブに収集し、後から分析、マーケティング、その他の⽬的で利
⽤する
"Amazon ECSに切替えたこ とで、プロビジョンや可⽤
性を⼼配する必要なく、稼 働中のサービスをとてもシ
ンプルにできました。"
Calvin French-Owen
Cofounder and Chief Technology Officer
以前
•
インスタンスが基本•
⼿作業でのセットアップ•
設定間違い / 同期できない 以後•
管理が容易に / ステートレス•
CI/CDパイプラインが⾃動化•
開発に専念できるようになったhttps://aws.amazon.com/solutions/case-studies/segment/
最適化されたインフラとしての
Amazon ECS
コンテナのログをawslogs経由で収集
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon S3
Amazon Kinesis
AWS Lambda
Amazon Elasticsearch Service
Amazon ECS
保存ストリーム 処理
検索
コンテナのログをawslogs経由で収集
•
サポートしているDockerのLogging Driver•
json-file, syslog, journald, gelf, fluentd, awslogs,•
AwslogsはAmazon CloudWatch Logsにログを送信•
Log groupはサービスを指定•
Log streamは各コンテナ•
Amazon CloudWatch Logs => 他のサービスへ•
検索, フィルタ, Amazon S3へ出⼒, Amazon Kinesis, AWS Lambda, Amazon Elasticsearch Serviceへ送るAmazon ES上のKibanaでログを検索
タスクのAuto Scaling
タスクのAuto Scaling
•
サービススケジューラがAuto Scalingと連携•
CloudWatch Alarm => Policy => 希望数を変更•
役に⽴つCloudWatchのメトリクス:•
サービス毎のCPU/Memory利⽤率• 各タスクが確保したリソースをどれくらい消費しているか?
•
クラスタ毎のCPU/Memory利⽤率• クラスタ全体のリソースの内、実際どれくらいが使われているか?
•
クラスタ毎のCPU/Memory確保• クラスタ全体のリソースがどの程度確保されているか?
Amazon CloudWatch Dashboardsで監視
Spotフリートをコンテナインスタンスとして使う
Amazon ECS Amazon EC2 Spot Fleet
+ ¢
c3.xlarge
c3.xlarge
c3.xlarge r3.8xlarge
r3.8xlarge r3.8xlarge
c3.8xlarge
c3.8xlarge c3.8xlarge
c3.4xlarge
c3.4xlarge c3.4xlarge
r3.2xlarge
r3.2xlarge
r3.2xlarge
まとめ
まとめ