【レポート】AWS Summit Tokyo 2017:AWS のコンテナ管理入門(Amazon EC2 Conatainer Service) #AWSSummit

aws-summit-tokyo-2017-longlogo 2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『AWS のコンテナ管理入門(Amazon EC2 Conatainer Service)』に関する内容をレポートしたいと思います。

セッション概要

当セッションの登壇者及び概要は以下の通り。

スピーカー:
 川村 誠氏 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト

セッション概要:
 このセッションでは、AWS が提供する Amazon EC2 Container Service (ECS) の概要について解説します。
 ECS は Docker コンテナをサポートする非常にスケーラブルで高性能なコンテナ管理サービスです。
 ECS を利用すると、Amazon EC2 インスタンスで構成されるクラスタの管理、クラスタ上でのアプリケーション実行/管理が簡単に実現可能となります。

 

セッションレポート

  • AWSでコンテナ管理を始めるための入門レベルの解説を致します

なぜコンテナなのか

  • コンテナは真新しい技術ではない
  • コンテナはリソース隔離が元々の由来

現場の課題

  • 開発に専念したい
  • 運用管理を効率化
  • コストの削減
  • 速いデプロイ/スケール

コンテナとは

  • OS,アプリ, ミドル => イメージ
  • 一つのホストに複数のコンテナをデプロイ
  • コンテナの操作は自動化できる

VMとの比較

  • コンテナはオーバーヘッドが小さい
  • コンテナイメージもコンパクト

コンテナの利点

  • 可搬性(イメージそのものが一つのバージョンを構成。いつどこで動かしても同じになる)
    • イメージは不変
    • 開発したコンテナをそのまま本番にも使える
  • 柔軟性
    • 削除、再生が容易
  • 速度
    • OSは既に起動している
  • 効率
    • オーバーヘッドが少ない
    • 粒度を細かくホストマシンの利用率を上げられる
  • TCOの削減が期待できる

ベストプラクティス

  • アプリをコンテナに適応させる
  • シンプルに保つ
  • タスクに集中する
    • いつでもどこでも動かせるようにタスクを実行できるか

アンチパターン

  • VMベースの処理やワークフロー
    • コンテナをVMの用に考える
  • 複雑さを上げてしまう
    • 俊敏性を損なう
  • ホスト単位でなにかを実行させる

課題/クラスタ管理

  • 1台のサーバ上でクラスタを管理するのは容易だが複数台のクラスタ上で管理するのは困難
    • 複数のAZにまたがると余計大変
    • どこのサーバーにリソースがあるのか
    • 新しいソフトをどうやってデプロイするのか
    • それらをどうやって自動化するのか
  • お客様はアプリの開発に専念したい
    • 車輪の再発明はしたくない
    • ビジネスの差別化には繋がらない
  • ここから生まれたのがECS

Amazon EC2 Container Serviceの概要

ECSの利点

  • 簡単に、どんなスケールのクラスタも管理出来る
  • 柔軟なコンテナの配置
  • 他のAWSサービスとの連携がデザインされている
  • 拡張性が高い

アーキテクチャ

Clusters

  • Taskが実行されるコンテナインスタンス群で構成されるリソースプール
  • Docker daemonとECS agentが動いている必要がある
    • Amazon ECS-optimized AMIを使うとラク

ECS Agent

  • コンテナインスタンスとMangerの連携を司る

Manager

  • 利用可能なClusterのリソースとTaskの状態を管理
  • リソースの変化を追跡
  • リソースへのリクエストを受け付ける

Task Definitions

  • Taskで使用するコンテナ、周辺設定の定義をする設計図のようなもの
  • Container DefinitionsとVolume Definitionsに分かれる

Tasks

  • コンテナ実行の1単位
  • 関連するコンテナでグループ化される
  • 1つのTask Definitionから複数のTaskが生成される

Scheduler

  • Run Task
    • バッチジョブのようなワークロードに使われる
    • コンテナインスタンスは自動的に選択される
  • Servoce
    • Web/APIのように長期かどうするワークロードに使われる
    • Taskを必要数維持するスケジューラ
    • 複数のTaskが実行される。負荷の分散としてELBとの連携も可能

構築の流れ

  • リポジトリの設定
  • dockerイメージの構築、プッシュ
  • Task Definitionの作成
  • Serviceの設定
  • Clusterの設定
  • 確認・実行

削除

  • 構築に使われているCloudFormationを削除するとすべて消える

EC2 Container Registry

  • フルマネージドで使えるDockerレジストリサービス
  • DockerHubのようなもの。AWS内部にあるのでイメージのロードが速い

ECSを利用するAWSサービス

  • AWS Elastic Beanstalk
  • AWS Batch
    • 裏側ではECSが動いているがユーザは全く意識することなく使える

事例

  • mapbox
    • 簡単にオリジナルの地図を作ることが出来る
    • 導入前はサービスごとにEC2のインスタンスを決める形で使われていた
    • 地図サービスはC4, 検索サービスはR3, DirectionにはM4
    • 地図サービスはCPUを使うが検索サービスはメモリを使う。混ぜるとコストが削減できる
    • インスタンスを多様化して使うことでコストを削減
    • Spot Fleetを使うことで更なるコストを削減
    • 25%のインスタンス削減
  • Nextdoor
    • ご近所様通しのSNSコミュニティを提供
    • 無停止でサービスをデプロイする事をEC2のブルーグリーンで実現していた
    • デプロイにかかる時間が課題
    • ECSを使うことで課題を解決
    • 元々EC2のFleetで組んでいたアーキテクチャをほとんど変えることなく変更できた
    • ビルドとデプロイにかかる時間を10倍に改善できた
  • Expedia
    • 世界最大級の旅行会社
    • Primerと呼ばれる内部のデプロイツールにECSを使用
    • ECS Optimized AMIをベースにCloudFormationで構築

まとめ

  • Amazon EC2 Container Service
    • AWSネイティブで非常に簡単
    • スタートアップからエンタープライズまで多くの実績

 

まとめ

ECSの入門編として非常にわかりやすい内容でした。Dockerを使える方には選択肢の一つとして検討してみてはいかがでしょうか。