dockerとamazon ecsで devopsを進化させる · solutions architect, amazon web services japan...
TRANSCRIPT
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Ryosuke IwanagaSolutions Architect, Amazon Web Services Japan
June 2016
DockerとAmazon ECSでDevOpsを進化させる
今⽇の持ち帰り
• DevOpsとDocker
• Dev and Ops
• Amazon ECS
DevOpsとは?
DevOps = このライフサイクル⾼速化の効率
開発者 顧客
releasetestbuild
plan monitor
デリバリーパイプライン
フィードバックループ
ソフトウェア開発のライフサイクル
モノリシックな開発ライフサイクル
開発者
releasetestbuild
デリバリーパイプラインアプリ
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 UIOrder UI
User UI UIShipping UI
Order ServiceOrder
ServiceService
ServiceService
ServiceUser
Service
Shipping Service
マイクロサービスアーキテクチャ - スケール
マイクロサービスな開発ライフサイクル
開発者 デリバリーパイプラインサービス
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
サービス
• マイクロサービスだけの話ではない• 部⾨、新規事業、社内向け/社外向け、等
• 「サービス」は多くなってしまいがち• スタートアップからエンタープライズまで同じ
• サービスが多くなれば、それだけパイプライン/devopsも多くなる
• 他のシステムとの統合テスト
• 負荷テスト• UIテスト• 侵⼊テスト
リリースプロセスの、4つの主要なフェーズ
Source Build Test Production
• .javaファイル等のソースコードをチェックイン
• 新しいコードを相互レビュー
• コンパイル• 単体テスト• スタイルチェック• メトリクス• コンテナイメージ
作成
• 本番環境へのデプロイ
DevOpsの実態
Build Test ProductionSource
Application Artifact
コードだけ書いていればいい、、？
DevOpsの実態
Build Test ProductionSource
Application Artifact
Provision
Config
開発環境の構成のメンテナンスが必要
開発、テスト、本番で環境に差異がある。。。
テストの需要がバラバラで管理が⼤変。。。。
オートスケールやノード障害対応。。。
なるほど、全てが必要なんですね。。。
複数のDevOpsでの実態
DevOpsの難しさ
• 扱うべきことが多すぎる• ユニコーンな⼈/チーム
• 多くの異なるパイプラインが存在• サービス、⾔語、フレームワーク、バージョン、等
コンテナはサービスにとって⾃然なもの
• モデルがシンプル
• どんなアプリでも、どんな⾔語でも
• イメージがバージョン
• 同じ成果物をテストしてデプロイする
• ステートレスなサーバの⽅が、変更リスクが下がる
FROM ubuntu:14.04MAINTAINER John Doe <[email protected]>RUN apt-get update && apt-get install -y curl wget default-jre gitRUN adduser --home /home/sinatra --disabled-password --gecos '' sinatraRUN adduser sinatra sudoRUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoersUSER sinatraRUN curl -sSL https://get.rvm.io | bash -s stableRUN /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 pushdocker pull出荷
docker run実⾏
Dockerを取り⼊れたDevOps
Build Test ProductionSource
Application Image
Provision
Config
コードだけ書いていればいい！
Dockerを取り⼊れたDevOps
Build Test ProductionSource
Dockerを取り⼊れたDevOps
• Dockerを使うことで、パイプラインが同⼀になる• どんな⾔語でも、どんなアプリケーションでも
• 管理すべきものが減って、開発に注⼒できる• アプリケーションとDockerfileに集中
• でも、もっとやれることがないか？
Dev and Ops
Build Test ProductionSource
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
launchContainer Instance
Volume Definitions
Container Definitions
スケジューラ
スケジューラとは？
• 必要な状態を決める
• 現在の状態と⽐較する
• アクションを実⾏する
Cluster, Scheduler, Task Scheduler
ManagerCluster
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 / Scheduler
API
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 stateScheduler A Scheduler B
Cluster
Amazon ECS: スケジューラ• 各スケジューラはクラスタ上にタスクを配置する• 各スケジューラはクラスタの現在の状態を更新する
Run a taskRun 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-OwenCofounder 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
まとめ
まとめ
• コンテナはDevOpsにとって⾃然なもの
• Dev and Ops; 組織にフィットしますか？
• Amazon ECSは、とても簡単で柔軟• DevOpsにも• Dev and Opsにも
ありがとうございました