【レポート】【初級】AWS コンテナサービス入門 #AWSSummit

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Tokyo 2019 Day3 (2019/06/14) のセッション、「【初級】AWS コンテナサービス入門」をレポートします。

こちらは ライブストリーミング からのセッション参加レポートです。

セッション概要

AWS では、お客様のコンテナワークロードにおける幅広いユースケースをサポートするために多くのサービスを選択肢として提供しています。 本セッションでは、コンテナオーケストレーションサービスである Amazon ECS/Amazon EKS、フルマネージドなコンテナ実行環境 AWS Fargate、 コンテナイメージレジストリの Amazon ECR に代表される各サービスの特徴と、これらがなぜ必要なのかを説明しつつ、 ご自身のワークロード構築にフィットするサービスを選ぶための軸となる情報を紹介します。

スピーカー(敬称略)

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

原 康紘

セッションレポート

アジェンダは下記の通り。

コンテナとは

アプリケーションを構成するコンポーネントは 4つ。

  • ランタイム/エンジン
  • アプリケーションコード
  • 依存ライブラリ/パッケージ
  • 設定

ローカルラップトップ・ステージング・本番、 各環境でソフトウェアのバージョンが違って問題が起きることがある。 (例えば JVMのバージョンの違いで本番環境では動かなかった、など)

そういった問題を 「コンテナ」 で解決する。

  • ランタイム/エンジン・依存ライブラリ/パッケージ・アプリケーションコードをすべてコンテナに入れる
  • ※設定は環境の差異を吸収するためのものなので、コンテナには入れない(実行時に渡す)

現在のコンテナのデファクトスタンダードが Docker

  • 簡単なコマンドで実行できる
  • どの環境でも同じコンテナを動かせる

仮想マシンとコンテナは似ている と言われる。

  • 仮想マシン(EC2)は AMIを指定して起動 ⇔ コンテナもコンテナイメージを指定して起動
  • 仮想マシン(EC2) 変更の際は SSHを使用 ⇔ コンテナも 中に入って yum など実行可能

が、実際は違う

  • 仮想マシンは ハイパーバイザ上に GuestOS、そのGuestOS上でアプリケーションが起動
  • コンテナは Docker Engine 上にアプリケーションが複数起動

コンテナ起動はプロセス処理の時間のみ。 だから 仮想マシンと比べて起動が早い。

※それぞれのアプリケーションは別々のコンテナに入れることがベストプラクティス

Docker を利用した基本的ワークフロー

  • イメージ作成
    • Dockerfile を作成 → docker build → コンテナイメージ
    • もしくは コンテナ内で作業 → docker commit → コンテナイメージ
  • イメージ作成後
    • イメージレジストリに docker push でアップロード
    • 他の人もコンテナイメージを使えるようになる
  • コンテナ実行
    1. ssh でサーバに入る
    2. docker pull でイメージレジストリからコンテナイメージをダウンロード
    3. docker run でコンテナ実行

思っていたより手作業?

  • Docker の責務は同一サーバ上のコンテナライフサイクル管理
  • 複数サーバやコンテナを束ねた概念に対するオペレーションはスコープ外

→ 次のコンテナオーケストレーションの話へ

コンテナオーケストレーション

手動でのコンテナイメージダウンロード・実行は非効率で、ミスオペレーションを招く。

コンテナオーケストレーション … 代わりに docker pull/run を発行してくれるツール

Amazon Elastic Container Service (ECS)

  • オーケストレーションツール
  • ECSの APIをコールすることで、 Docker 内のオペレーションを代わりに実行
  • 各種AWSサービスとの高度な連携
  • 「タスク」「サーボス」というシンプルなリソース表現
  • 数億コンテナ/週、数百万 EC2 インスタンスを管理するスケーラビリティ
  • Linux/Windows サポート

Kubernetes

  • オープンソースのオーケストレーションツール
  • EC2上に Kubernetes を導入して運用する人が多い
  • 運用難易度が高いのでAWSで運用してほしい、という声が多かった

Amazon Elastic Container Service for Kubernetes (EKS)

  • 運用難易度の高い Kubernetes マスターをマネージドで提供
  • エコシステムのOSSやツールを利用可能
  • CNCF certified
  • 各種AWSサービスとの連携
  • オープンソースなので、問題が起きたときに自分でコード修正・パッチ適用ができる
  • 高い表現力

イメージレジストリ、コンテナ実行環境

イメージレジストリ … Docker Hub が有名。

Amazon Elastic Container Registry (ECR)

  • フルマネージドなプライベートコンテナイメージレジストリ
  • IAM連携可能
  • スケーラブルかつ高い可用性
  • Docker CLI からの利用が可能

EC2でコンテナを走らせた場合の運用業務

  • OSやエージェント類へのパッチ当て・更新
  • 実行中のコンテナ数に基づく、最適なリソース使用率を保つための EC2インスタンス数のスケーリング

AWS Fargate … 利用者はコンテナの管理のみ

  • AWSマネージド … EC2インスタンスの管理不要
  • コンテナネイティブ … 仮想マシンを意識しないシームレスなスケーリング
  • AWSサービスとの連携

その他のコンテナ関連サービス

AWS Cloud Map

  • クラウドリソースのためのサービスディスカバリ (誤解を生むかもしれない表現をすると名前解決)
    • 例えば AWS Lambda のリソースは IPの指定ではなく ARN、名前解決できない
    • クラウドネイティブなりソースも名前解決できるようにする
  • 開発生産性の向上
    • 全アプリケーションリソースをディスカバリ可能
  • AWSコンテナサービスとの連携 … AWS Fargate, Amazon ECS, Amazon EKS

AWS App Mesh

  • アプリケーションレベルのネットワーク
  • A3-03セッション「サービスメッシュは本当に必要なのか、何を解決するのか」で詳細を説明

Amazon CloudWatch Container Insights for Amazon EKS/Kubernetes

  • パブリックプレビュー
  • コンテナワークロードのためのモニタリングサービス

現実世界のコンテナワークロード

コンピューティングの多様な選択肢 … 適切なサービスの選択が重要

  • EC2 … コントロール範囲は広いが、運用コストが高い
  • Lambda … コントロール範囲は狭いが、運用コストが低い
  • コンテナは Lambda と EC2 の間

まとめ

▼AWSのコンテナ関連サービス

  • オーケストレーション: Amazon ECS, Amazon EKS
  • イメージレジストリ: Amazon ECR
  • ホスティング: Amazon EC2, AWS Fargate
  • アプリケーションレベル: AWS App Mesh, AWS Cloud Map

感想

コンテナの概要や、実行までのフローなど理解することができました。 また、関連するAWSサービスの特徴などの説明も丁寧でわかりやすかったです。

私自身「知ってはいるけど、触ったことがない」コンテナ初心者なので 今後実際に手を動かしてみて、今日のセッションで説明されていたメリットを実感しようと思います。