• 検索結果がありません。

_DockerとAmazon_ECSでDevOpsを進化させる_public

N/A
N/A
Protected

Academic year: 2022

シェア "_DockerとAmazon_ECSでDevOpsを進化させる_public"

Copied!
67
0
0

読み込み中.... (全文を見る)

全文

(1)

© 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を進化させる

(2)

今⽇の持ち帰り

DevOpsとDocker

Dev and Ops

Amazon ECS

(3)

DevOpsとは?

DevOps

= このライフサイクル⾼速化の効率

開発者 顧客

release test

build

plan monitor

デリバリーパイプライン

フィードバックループ

ソフトウェア開発のライフサイクル

(4)

モノリシックな開発ライフサイクル

開発者

release test

build

デリバリーパイプライン アプリ

(5)

2001

Amazonでの開発の変遷: 2001-2009

2009

モノリシックなアプリ チーム

マイクロサービス ツーピッツァチーム+

(6)

Order UI User UI Shipping UI

Order Service

User Service

Shipping Service

Data Access

モノリシックアーキテクチャ

(7)

モノリシックアーキテクチャ - スケール

(8)

Order UI User UI Shipping UI

Order Service

User Service

Shipping Service

マイクロサービスアーキテクチャ

(9)

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

マイクロサービスアーキテクチャ - スケール

(10)

マイクロサービスな開発ライフサイクル

開発者 サービス デリバリーパイプライン

release test

build

release test

build

release test

build

release test

build

release test

build

release test

build

(11)

サービス

マイクロサービスだけの話ではない

部⾨、新規事業、社内向け/社外向け、等

「サービス」は多くなってしまいがち

スタートアップからエンタープライズまで同じ

サービスが多くなれば、それだけパイプライン/devops も多くなる

(12)

他のシステムと の統合テスト

負荷テスト

UIテスト

侵⼊テスト

リリースプロセスの、4つの主要なフェーズ

Source Build Test Production

.javaファイル等 のソースコード をチェックイン

新しいコードを 相互レビュー

コンパイル

単体テスト

スタイルチェック

メトリクス

コンテナイメージ 作成

本番環境へのデ プロイ

(13)

DevOpsの実態

Build Test Production

Source

Application Artifact

コードだけ書いて いればいい、、?

(14)

DevOpsの実態

Build Test Production

Source

Application Artifact

Provision Config

開発環境の構成の メンテナンスが必要

開発、テスト、本番で 環境に差異がある。。。

テストの需要がバラバラ

で管理が⼤変。。。。 オートスケールや ノード障害対応。。。

なるほど、

全てが必要なんですね。。。

(15)

複数のDevOpsでの実態

(16)

DevOpsの難しさ

扱うべきことが多すぎる

ユニコーンな⼈/チーム

多くの異なるパイプラインが存在

サービス、⾔語、フレームワーク、バージョン、等

(17)
(18)

コンテナはサービスにとって⾃然なもの

モデルがシンプル

どんなアプリでも、どんな⾔語でも

イメージがバージョン

同じ成果物をテストしてデプロイする

ステートレスなサーバの⽅が、変更リスクが下がる

(19)

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"

パッケージ

(20)

docker push docker pull

出荷

(21)

docker run

実⾏

(22)

Dockerを取り⼊れたDevOps

Build Test Production

Source

Application Image

Provision Config

コードだけ書いて いればいい!

(23)

Dockerを取り⼊れたDevOps

Build Test Production

Source

(24)

Dockerを取り⼊れたDevOps

Dockerを使うことで、パイプラインが同⼀になる

どんな⾔語でも、どんなアプリケーションでも

管理すべきものが減って、開発に注⼒できる

アプリケーションとDockerfileに集中

でも、もっとやれることがないか?

(25)

Dev and Ops

Build Test Production

Source

Dev Ops

(26)

Dev

アプリと実⾏環境の開発に、専念 する

不可変/廃棄可能なコンテナ

継続的なデリバリーパイプライン

Dev and Ops

Ops

リソースとサービスの境界を 管理する

クラスタ管理

スケジューラ

ログ、監視

インフラを、如何なるアプリ ケーションからも分離させる

(27)

Dev and Ops

DevOpsの、アジリティ

CI/CD、複数パイプライン

伝統的な組織構造の、効率

Devのスペシャリスト / Opsのスペシャリスト

リソースの利⽤率をもっと⾼める

重要な点: インフラは如何なるアプリにも依存しない

だから、コンテナ

(28)

コンテナに適応したDevには…

(29)

The Twelve-Factor App

(30)

Twelve-Factorの主義

I.

コードベース

バージョン管理される1つのコードベースと複数デプロイ

II.

依存関係

依存関係を明⽰的に宣⾔し分離する

III.設定

設定を環境変数に格納する

IV.

バックエンドサービス

バックエンドサービスをアタッチされたリソースとして扱う

V.

ビルド、リリース、実⾏

ビルド、リリース、実⾏の3つのステージを厳密に分離する

VI.

プロセス

アプリを1つ⼜は複数のステートレスなプロセスとして実⾏

VII.ポートバインディング

ポートバインディングを通してサービスを公開する

VIII.並⾏性

プロセスモデルによってスケールアウトする

IX.

廃棄容易性

⾼速な起動とグレースフル停⽌で堅牢性を最⼤化する

X.

開発/本番⼀致

開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ

XI.

ログ

ログをイベントストリームとして扱う

XII.管理プロセス

管理タスクを1回限りのプロセスとして実⾏する

http://12factor.net/

(31)

コンテナに適応したOpsには…

(32)

Amazon EC2 Container Service

(33)

コンテナ管理を、あらゆるスケールで

何も準備する必要がない 完全な状態

制御と監視 スケール

(34)

柔軟なコンテナの配置

ロングランニングなアプリ バッチジョブ

複数のスケジューラ

(35)

AWSの基盤との連携

Elastic Load Balancing

Amazon Elastic Block Store Amazon Virtual Private Cloud Amazon CloudWatch

AWS Identity and Access Management

AWS CloudTrail

(36)

コンテナ管理

(37)

コンテナ管理とは?

利⽤可能なリソースを管理

リソースの変化を追跡

リソースへのリクエストを受け付ける

正確性と⼀貫性を保証する

(38)

CPU メモリ ポート

ディスク容量 ディスクIOPS ネットワーク帯域

リソース

(39)

{

"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”

(40)

Tasks

Shared Data Volume Containers

launch

Container Instance

Volume Definitions

Container Definitions

(41)

スケジューラ

(42)

スケジューラとは?

必要な状態を決める

現在の状態と⽐較する

アクションを実⾏する

(43)

Cluster, Scheduler, Task

Scheduler

Manager Cluster

Task Definition Task

Agent

(44)

ECS Agent

Docker

Task

Container Instance

Container

ECS Agent Task

Container

https://github.com/aws/amazon-ecs-agent

(45)

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

(46)

楽観的な状態共有モデル

(47)

Amazon ECS: スケジューラ

各スケジューラは定期的に現在のクラスタの状態を取得する

Copy of cluster state Scheduler A Scheduler B

Cluster

(48)

Amazon ECS: スケジューラ

各スケジューラはクラスタ上にタスクを配置する

各スケジューラはクラスタの現在の状態を更新する

Run a task

Run a task

(49)

Amazon ECS: スケジューラ

もしリソースが既に確保されていたら、リクエストは拒絶される

Run a task on the same resource

=> Transactional

(50)

Amazon ECS: スケジューラ

楽観的な状態共有のスケジュール機構

全てのスケジューラが、現在のクラスタの状態をいつでも⾒られる

(51)

Amazon ECS Serviceスケジューラ

(52)

Serviceとは?

ロングランニングなアプリケーションをモデル化

希望する状態を維持してくれる

Serviceの更新で、デプロイ

Elastic Load Balancingの後ろで動かすことも可能

(53)

コンテナのスケジュール: ロングランニングアプリ

最⼩限の空間を使ってデプロイ:

minimumHealthyPercent

= 50%, maximumPercent = 100%

Old version New version

(54)

コンテナのスケジュール: ロングランニングアプリ

サービスのキャパシティを落とさずに⾼速にデプロイ:

minimumHealthyPercent

= 100%, maximumPercent = 200%

Old version New version

(55)

ケーススタディ: Segment

(56)

Segment

顧客のデータを1つのハブに収集し、後から分析、マーケティング、その他の⽬的で利

⽤する

"Amazon ECSに切替えたこ とで、プロビジョンや可⽤

性を⼼配する必要なく、稼 働中のサービスをとてもシ

ンプルにできました。"

Calvin French-Owen

Cofounder and Chief Technology Officer

以前

インスタンスが基本

⼿作業でのセットアップ

設定間違い / 同期できない 以後

管理が容易に / ステートレス

CI/CDパイプラインが⾃動化

開発に専念できるようになった

https://aws.amazon.com/solutions/case-studies/segment/

(57)

最適化されたインフラとしての

Amazon ECS

(58)

コンテナのログをawslogs経由で収集

Amazon CloudWatch Logs

Amazon CloudWatch Logs

Amazon CloudWatch Logs

Amazon CloudWatch Logs

Amazon S3

Amazon Kinesis

AWS Lambda

Amazon Elasticsearch Service

Amazon ECS

保存

ストリーム 処理

検索

(59)

コンテナのログを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へ送る

(60)

Amazon ES上のKibanaでログを検索

(61)

タスクのAuto Scaling

(62)

タスクのAuto Scaling

サービススケジューラがAuto Scalingと連携

CloudWatch Alarm => Policy => 希望数を変更

役に⽴つCloudWatchのメトリクス:

サービス毎のCPU/Memory利⽤率

• 各タスクが確保したリソースをどれくらい消費しているか?

クラスタ毎のCPU/Memory利⽤率

• クラスタ全体のリソースの内、実際どれくらいが使われているか?

クラスタ毎のCPU/Memory確保

• クラスタ全体のリソースがどの程度確保されているか?

(63)

Amazon CloudWatch Dashboardsで監視

(64)

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

(65)

まとめ

(66)

まとめ

コンテナはDevOpsにとって⾃然なもの

Dev and Ops; 組織にフィットしますか?

Amazon ECSは、とても簡単で柔軟

DevOpsにも

Dev and Opsにも

(67)

ありがとうございました

参照

関連したドキュメント

Since the optimizing problem has a two-level hierarchical structure, this risk management algorithm is composed of two types of swarms that search in different levels,

 活性型ビタミン D₃ 製剤は血中カルシウム値を上昇 させる.軽度の高カルシウム血症は腎血管を収縮さ

第 1 項において Amazon ギフト券への交換の申請があったときは、当社は、対象

サーバー費用は、Amazon Web Services, Inc.が提供しているAmazon Web Servicesのサーバー利用料とな

Besides, we offer some additional interesting properties on the ω-diffusion equations and the ω-elastic equations on graphs such as the minimum and max- imum property, the

サーバー API 複雑化 iOS&amp;Android 間で複雑な API

これはつまり十進法ではなく、一進法を用いて自然数を表記するということである。とは いえ数が大きくなると見にくくなるので、.. 0, 1,

補助 83 号線、補助 85 号線の整備を進めるとともに、沿道建築物の不燃化を促進