DockerとAmazon ECSで DevOpsを 進 化 させる Ryosuke Iwanaga Solutions Architect, Amazon Web Services Japan June 2016 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
今 の 持 ち 帰 り DevOpsとDocker Dev and Ops Amazon ECS
DevOpsとは? ソフトウェア 開 発 のライフサイクル デリバリーパイプライン build test release 開 発 者 plan monitor 顧 客 フィードバックループ DevOps = このライフサイクル 速 化 の 効 率
モノリシックな 開 発 ライフサイクル build test release 開 発 者 アプリ デリバリーパイプライン
Amazonでの 開 発 の 変 遷 : 2001-2009 2001 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 UI User UI Shipping UI Order UI UI Order Service Order Service Order Service Service Service Service Service Service User Service Shipping Service Shipping Service
マイクロサービスな 開 発 ライフサイクル build test release build test release build test release build test release build test release 開 発 者 サービス build test release デリバリーパイプライン
サービス マイクロサービスだけの 話 ではない 部 新 規 事 業 社 内 向 け/ 社 外 向 け 等 サービス は 多 くなってしまいがち スタートアップからエンタープライズまで 同 じ サービスが 多 くなれば それだけパイプライン/devops も 多 くなる
リリースプロセスの 4つの 主 要 なフェーズ Source Build Test Production.javaファイル 等 のソースコード をチェックイン 新 しいコードを 相 互 レビュー コンパイル 単 体 テスト スタイルチェック メトリクス コンテナイメージ 作 成 他 のシステムと の 統 合 テスト 負 荷 テスト UIテスト 侵 テスト 本 番 環 境 へのデ プロイ
DevOpsの 実 態 Source Build Test Production Application Artifact コードだけ 書 いて いればいい?
DevOpsの 実 態 開 発 環 境 の 構 成 の メンテナンスが 必 要 Source 開 発 テスト 本 番 で 環 境 に 差 異 がある Build Test Production Provision Config Application Artifact なるほど 全 てが 必 要 なんですね テストの 需 要 がバラバラ で 管 理 が 変 オートスケールや ノード 障 害 対 応
複 数 のDevOpsでの 実 態
DevOpsの 難 しさ 扱 うべきことが 多 すぎる ユニコーンな /チーム 多 くの 異 なるパイプラインが 存 在 サービス 語 フレームワーク バージョン 等
コンテナはサービスにとって 然 なもの モデルがシンプル どんなアプリでも どんな 語 でも イメージがバージョン 同 じ 成 果 物 をテストしてデプロイする ステートレスなサーバの が 変 更 リスクが 下 がる
パッケージ FROM ubuntu:14.04 MAINTAINER John Doe <jdoe@example.com> 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 Source Build Test Production Provision Config Application Image コードだけ 書 いて いればいい!
Dockerを 取 り れたDevOps Source Build Test Production
Dockerを 取 り れたDevOps Dockerを 使 うことで パイプラインが 同 になる どんな 語 でも どんなアプリケーションでも 管 理 すべきものが 減 って 開 発 に 注 できる アプリケーションとDockerfileに 集 中 でも もっとやれることがないか?
Dev and Ops Source Build Test Production Dev Ops
Dev and Ops Dev アプリと 実 環 境 の 開 発 に 専 念 する 不 可 変 / 廃 棄 可 能 なコンテナ 継 続 的 なデリバリーパイプライン 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 ネットワーク 帯 域
Task Definitions { }, "name": "simple-demo", "image": "my-demo", "cpu": 10, "memory": 500, "portmappings": [ { "containerport": 80, "hostport": 80 } ], "entrypoint": [ "/usr/sbin/apache2", "-D", "FOREGROUND" ], "essential": true
Tasks Shared Data Volume Containers Volume Definitions Container Definitions launch Container Instance
スケジューラ
スケジューラとは? 必 要 な 状 態 を 決 める 現 在 の 状 態 と 較 する アクションを 実 する
Cluster, Scheduler, Task Scheduler Task Agent Task Definition Cluster Manager
Container Instance ECS Docker Task Task Agent Container Container ECS Agent https://github.com/aws/amazon-ecs-agent
Internet User / Scheduler ELB ELB AZ 1 AZ 2 Container Instance Container Instance Container Instance Docker Docker Docker Task Container Task Container Task Container Task Container Task Container Task Container ECS Agent ECS Agent ECS Agent Amazon ECS Agent Communication Service Cluster Management Engine Key/Value Store API
楽 観 的 な 状 態 共 有 モデル
Amazon ECS: スケジューラ 各 スケジューラは 定 期 的 に 現 在 のクラスタの 状 態 を 取 得 する Scheduler A Scheduler B Copy of cluster state 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の 後 ろで 動 かすことも 可 能
コンテナのスケジュール: ロングランニングアプリ 最 限 の 空 間 を 使 ってデプロイ: Old version New version minimumhealthypercent = 50%, maximumpercent = 100%
コンテナのスケジュール: ロングランニングアプリ サービスのキャパシティを 落 とさずに 速 にデプロイ: 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 ECS 保 存 Amazon CloudWatch Logs Amazon S3 ストリーム Amazon CloudWatch Logs Amazon Kinesis 処 理 Amazon CloudWatch Logs AWS Lambda 検 索 Amazon CloudWatch Logs Amazon Elasticsearch Service
コンテナのログを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.4xlarge c3.xlarge r3.8xlarge c3.8xlarge r3.2xlarge r3.2xlarge r3.8xlarge c3.xlarge c3.4xlarge c3.8xlarge c3.4xlarge c3.8xlarge r3.2xlarge r3.8xlarge c3.xlarge
まとめ
まとめ コンテナはDevOpsにとって 然 なもの Dev and Ops; 組 織 にフィットしますか? Amazon ECSは とても 簡 単 で 柔 軟 DevOpsにも Dev and Opsにも
ありがとうございました