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 開発者 plan test release 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 Order UI Order UI Order Order Service Order Service Service User UI User UI Service Service Service Service Service User Service UI UI Shipping UI Shipping Shipping Service Service マイクロサービスな開発ライフサイクル 開発者 サービス build test release build test release build test release build test release build test release build test release デリバリーパイプライン サービス • マイクロサービスだけの話ではない • 部⾨、新規事業、社内向け/社外向け、等 • 「サービス」は多くなってしまいがち • スタートアップからエンタープライズまで同じ • サービスが多くなれば、それだけパイプライン/devops も多くなる リリースプロセスの、4つの主要なフェーズ Source • • .javaファイル等 のソースコード をチェックイン 新しいコードを 相互レビュー Build • • • • • コンパイル 単体テスト スタイルチェック メトリクス コンテナイメージ 作成 Test • • • • 他のシステムと の統合テスト 負荷テスト UIテスト 侵⼊テスト Production • 本番環境へのデ プロイ DevOpsの実態 Source Build Application コードだけ書いて いればいい、、？ Test Artifact Production DevOpsの実態 開発、テスト、本番で 環境に差異がある。。。 開発環境の構成の メンテナンスが必要 Source Build Test Production Provision Config Application なるほど、 全てが必要なんですね。。。 Artifact テストの需要がバラバラ で管理が⼤変。。。。 オートスケールや ノード障害対応。。。 複数の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 Source Build Test Provision Config Application コードだけ書いて いればいい！ Image Production Dockerを取り⼊れたDevOps Source Build Test Production Dockerを取り⼊れたDevOps • Dockerを使うことで、パイプラインが同⼀になる • どんな⾔語でも、どんなアプリケーションでも • 管理すべきものが減って、開発に注⼒できる • アプリケーションとDockerfileに集中 • でも、もっとやれることがないか？ Dev and Ops Source Dev Build Test Production Ops Dev and Ops Dev • アプリと実⾏環境の開発に、専念 する • 不可変/廃棄可能なコンテナ • 継続的なデリバリーパイプライン Ops • リソースとサービスの境界を 管理する • • • • クラスタ管理 スケジューラ ログ、監視 インフラを、如何なるアプリ ケーションからも分離させる Dev and Ops • DevOpsの、アジリティ • CI/CD、複数パイプライン • 伝統的な組織構造の、効率 • • Devのスペシャリスト / Opsのスペシャリスト リソースの利⽤率をもっと⾼める • 重要な点: インフラは如何なるアプリにも依存しない • だから、コンテナ コンテナに適応したDevには… The Twelve-Factor App Twelve-Factorの主義 I. コードベース VII.ポートバインディング II. 依存関係 VIII.並⾏性 III.設定 IX. 廃棄容易性 IV.バックエンドサービス X. 開発/本番⼀致 V. ビルド、リリース、実⾏ XI. ログ VI.プロセス XII.管理プロセス バージョン管理される1つのコードベースと複数デプロイ 依存関係を明⽰的に宣⾔し分離する ポートバインディングを通してサービスを公開する プロセスモデルによってスケールアウトする 設定を環境変数に格納する ⾼速な起動とグレースフル停⽌で堅牢性を最⼤化する バックエンドサービスをアタッチされたリソースとして扱う ビルド、リリース、実⾏の3つのステージを厳密に分離する アプリを1つ⼜は複数のステートレスなプロセスとして実⾏ 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ ログをイベントストリームとして扱う 管理タスクを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 Shar ed Data Volum e Container s Volume Definitions Container Definitions launch Container Instance スケジューラ スケジューラとは？ • 必要な状態を決める • 現在の状態と⽐較する • アクションを実⾏する Cluster, Scheduler, Task Scheduler Task Task Definition Agent Cluster Manager Container Instance ECS Agent Docker Task Task Container Container ECS Agent https://github.com/aws/amazon-ecs-agent User / Scheduler Internet ELB ELB AZ 2 AZ 1 Container Instance Container Instance Docker Task Container Docker Docker Task Task Container Task Container ECS Agent Task Container Task Container ECS Agent Agent Communication Service Amazon ECS Container Instance ECS Agent API Cluster Management Engine Key/Value Store Container 楽観的な状態共有モデル Amazon ECS: スケジューラ • 各スケジューラは定期的に現在のクラスタの状態を取得する Scheduler A Scheduler B Cluster Copy of cluster state 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 • • AwslogsはAmazon CloudWatch Logsにログを送信 • • • json-file, syslog, journald, gelf, fluentd, awslogs, 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 + 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 Amazon EC2 Spot Fleet ¢ まとめ まとめ • コンテナはDevOpsにとって⾃然なもの • Dev and Ops; 組織にフィットしますか？ • Amazon ECSは、とても簡単で柔軟 • • DevOpsにも Dev and Opsにも ありがとうございました
© Copyright 2024 ExpyDoc
