[レポート]AWS Container Anywhare!! #devio2021

DevelopersIO 2021 Decade

#AWS

#イベント

カトアキ

2021.10.11

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

はじめに

「最近コンテナのアップデート、なんか凄いのいっぱいあったよね、何って・・ええと？」

とあやふやで困っていた矢先に、「DevelopersIO 2021 Decade」Day2において、「AWS Container Anywhere!」と題してアマゾンウェブサービスジャパン株式会社シニアエバンジェリスト亀田治伸氏にご登壇いただきましたので、そこにいち聴講者として参加してきました。

内容をレポートします。

ちなみに、このセッションでは「データプレーンってなんだっけ？」みたいな人もついていけました。そこもフォローしてくれていたので。

登壇者

アマゾンウェブサービスジャパン株式会社シニアエバンジェリスト亀田治伸氏

セッション概要

2021年9月に相次いでリリースされたAmazon ECS Anywhere と Amazon EKS Anywhere。このセッションでは、それらの技術特性や使い分けなどについてご紹介します。

お話いただいた内容

クラウドにおけるコンピュートサービスの変化

どんどん抽象化が進んでいる
各コンピュートサービスの抽象度の違いについて
- Amazon ECS, Amazon EKSのデフォルトはAmazon EC2の上にコンテナを配置するもの
- AWS Fargateはコンテナだけを実行するもの
- AWS Lambdaはプログラムをだけを実行するもの（マイクロVM上で）
AWSでコンテナを扱うサービスがAmazon ECS, Amazon EKS
- AWS純正がECS
- KubernetesネイティブがEKS

AWSはコンテナのサービスに力を入れている

Amazon ECS, Amazon EKS以外にも色々ある
- Amazon ECRについて
  - Amazon ECRとは、Open Container Initiative準拠のコンテナイメージを管理するリポジトリ
- ネットワーキング系（AWS Cloud Map, AWS App Mesh）で出来ること
  - コンテナ専用のルーティング
  - 死活監視
  - スケーリングした際にDNSに新しいノードを自動で登録してくれる
  - 等
- などなど・・

ということで、コンテナ関連の様々なアップデートについてお話くださいました。

AWS App Runnerとはどんなものか

まずはAWS App runnerについて。

CLIやAWS App Runnerのマネジメントコンソール経由で、ミニマムな設定でコンテナを起動できるようにしたともの
- 例えば先週出たアップデートでいうと、Amazon ECRのパブリックリポジトリに入っているコンテナからそのまんまAWS App Runner上でコンテナだけポーンと立ち上げる、といったことも出来るようになっている
コンテナを抽象化し、利用者の敷居を下げるようなサービス
- コンテナ利用者の敷居って何？
  - まず、AmazonECSというのは、Amazon EC2及びロードバランサ、VPCとかを使えるようになった人が次のステップとして使うことを前提としている感じ
  - 初心者の方はAmazon ECS, Amazon EKSを使おうとすると、設定項目が多すぎて面食らう
    - Amazon EC2を設定するより設定項目が多くなり、ほぼほぼそれらが必須の設定となるため。なぜなら。。。
      - オートスケーリングの設定が必要だったり
      - ロードバランサの設定が必要だったり
      - ネットワークの設定も必要だったり
      - Auto Scalingグループの設定も必要だったり・・・
    - なぜなら、EC2とかに比べて、アプリケーションの粒度を小さく、それによってスケーラビリティを確保しようというものであるため、それの実現には設定が必要になってしまう・・
- そうじゃなくて、もっと単純にコンテナだけを起動させればいいじゃないか、というのがAWS App Runner

AWS Copilotとはどんなものか

OSSベースのCLIのツールである
- 以前もAWSの普通のCLIを使ってもコンテナの設定はできていたが、コンテナ専用にさらにもう少し抽象化して便利に出来るようにしたもの
- 宣言的なマニフェストファイルを作っておいて、それをもとにコンテナの実行環境を作ろうというもの
- （前のセクションの通り）コンテナの設定は、いろいろな設定項目が多岐にわたるので、結構大変である。そこで・・・
  - 中身をApplicationレイヤー, Environmentレイヤー, Serviceレイヤーの3つに抽象化
  - スタック毎に個別の設定
  - それらの設定をmanifestファイルとして一つにまとめておけるようにする
Amazon EKSではなく、Amazon ECS専用である。
（著者追記）マニフェストファイルの例をこちらから引用します

# Service 名はロググループや ECS サービスなどのリソースの命名に利用されます。
name: frontend
type: Load Balanced Web Service

# Serviceのトラフィックを分散します。
http:
  path: '/'
  healthcheck:
    path: '/_healthcheck'
    healthy_threshold: 3
    unhealthy_threshold: 2
    interval: 15s
    timeout: 10s
    grace_period: 45s
  deregistration_delay: 5s
  stickiness: false
  allowed_source_ips: ["10.24.34.0/23"]

# コンテナと Service の構成
image:
  build:
    dockerfile: ./frontend/Dockerfile
    context: ./frontend
  port: 80

cpu: 256
memory: 512
count:
  range: 1-10
  cpu_percentage: 70
  memory_percentage: 80
  requests: 10000
  response_time: 2s
exec: true

variables:
  LOG_LEVEL: info
secrets:
  GITHUB_TOKEN: GITHUB_TOKEN

# 上記すべての値は Environment ごとにオーバーライド可能です。
environments:
  test:
    count:
      range:
        min: 1
        max: 10
        spot_from: 2
  staging:
    count:
      spot: 2
  production:
    count: 2

今年の前半にとても重要なアップデートがあった
- マニフェストファイルのexec:trueの部分である
  - コレ何？っていうのが次のセクションの「Amazon ECS Exec」についてを知ると分かる

Amazon ECS Execについて

2021/03にAmazon ECS Execという機能がリリースされた（著者追記)：ドキュメントはこちら
- コンテナの中に、メンテナンス用に入れる口をセキュアに作ってくれる機能
  - 開発者がSSHで入りたい場合、コンテナに入るのではなくて、SSMの基盤にHTTPSでアクセスして、そこからSSHライクなIFを通して、間接的にコンテナに入った状態になる
  - 中のエージェントがSSMに対して常時ポーリングをかけ続けている
    - つまり、実際にアクセスさせているのではなくて、エージェントがポーリングをしているだけ（なので、コンテンツ側でポートを開けてはいない）
- いやちょっとまって、必要？
  - コンテナはイミュータブルにするべき・・・ですよね？
    - コンテナはOSよりも起動が圧倒的に高速
      - ブートシーケンスを通ることはない
      - 起動するまで数分間時間がかかる(AWSのAuto Scaling駆使したとしても)
      - コンテナの方がより高速にスケーリングする
    - コンテナのほうがより高速にスケーリングする、という考え方を延伸していくと・・・「いちいち使い捨てであるコンテナに、ログインして、パッチを適用して…というOS的な使い方をするのはやめるべき」
    - なので、今動いているコンテナの中身が古くなったのであれば、それを捨てて、新しいコンテナイメージ作り直して、新しいコンテナイメージから今のコンテナを新しいものに置き換えましょうね、ってのが基本
  - とはいえ、テスト目的で中に入りたい場合もある
    - ただし、SSHの口を空けておくのは嫌だ。商用環境に切り替える際に、それを消し忘れることも十分考えられるというときに便利！
- AWS Copilotとの関係
  - Amazon ECS ExecはAWS Copilot経由である必要はない
    - 普通にAWSのCLIとかSDKとかでも使える
  - Amazon EC2でも既に同じような仕組みが存在するものを、今回Amazon ECSにも対応したよ、というアップデートである

Bottlerocket AMIについて

2021/6にリリースされた
is 何？
- OSSベースのコンテナ起動用OS（著者追記：Githubのサイトへのリンクはこちら）
  - コンテナを起動させるOSに不必要なものを「初めから搭載しない」というコンセプトのOS
    - 例えば、上でコンテナが動く前提のLinuxOSには無駄が多い
      - Pythonのインタプリタ、シェル、SSHのエージェント…
      - けど、標準のLinuxをいれるとそういったものが入りがち
    - OSの中に余計なものは入れないので、/etcとかは「ブート毎に再生性される一時ファイル置き場」に置き換えられる
    - 特権管理を持ったOSに対する変更作業にも対応
      - SELinux上に乗っている特定のコンテナからしかOSの操作を出来ないようにしている
  - OSSベースで提供しているので、誰でもマシンイメージをDLしてオンプレ環境でも使うことができる
ってことは・・・これがAnyware系のアップデートにつながってくる

Anyware系とBottlerocket AMIの関係

Bottlerocker AMIができたので、誰でも、AWSで作ったコンテナを配布できるようになるよね、ということでECS Anyware, EKS Anywareができてきた

ちょっとまって、データプレーンとコントロールプレーンって何？

次のセクションの前にちょっと前提の説明。平たく言うと・・・
- コントロールプレーンは、コンテナをいいかんじで「ばらまく」やつ
- データプレーンはコンテナを「ばらまかれる」やつ
  - AWS内部でいうと、Amazon EC2、Amazon Fargateという選択肢がある

Amazon ECS Anywareって何？

is 何
- クラウド上のフルマネージドなコントロールプレーン
- 平たく言うと、「オンプレミスにもコンテナをいい感じでばらまく」ことができるもの
どういう仕組みで動いてるの？
- オンプレの場合
  - AWS側とオンプレ側があるとする
  - オンプレ側のOSにSSMエージェントをインストールする
  - SSMエージェントがAWS側と通信し、アクティベートの処理を行う
    - エージェントが入ったオンプレ側のサーバをAWSの管理配下にするということ
    - 実は、この状態で、コンテナに限らずいろいろな操作をAWS側から行うことが出来るようになっている。例えば、windowsのイベントビューアをwindowsにログインすること無く見れるとか
  - AWS IAMからインスタンスロールを受け取って、Amazon ECSエージェントをインストールする
  - エージェントを通じてオンプレ側がAWSに必要な通信を行う
    - Amazon ECSエージェントがAWS Systems Managerのエージェントから必要な認証情報を引き取って、インスタンスをAWS側(Amazon ECS)に登録する
    - オンプレミスのサーバがデータプレーンとして認識される
  - dockerをコンテナランタイムとして、dockerエンジン経由でコンテナをばらまく
  - オンプレ側のエージェントがAmazon CloudWatchと連携
    - 統合的にAWS側ですべて管理することができる
- オンプレ以外も混ざる場合
  - ユースケースは例えば、テスト環境はオンプレ、商用環境はクラウド、またはその逆
  - なので、データプレーンとしてAmazon EC2・AWS Fargateの場合が選べるようになっている
スケーラビリティが高い
- IP-Rearchableであればどこでもデプロイできるようになっている
  - とはいえ、AWS Systems Manager・Amazon ECSのエージェントはそこまで古すぎるOSには対応していないので、対応できない環境もある（例えば、Redhatの4とか5とかだとさすがに難しいですよね）
オンプレにデプロイする際の制限となること
- Amazon ECSはいろいろなネットワークモードを持っているが、awsvpcネットワークモードは未サポート
  - なぜなら、一つのサーバに対してコンテナを複数配置した場合に次の問題がある
    - 同じポートにバインド出来るの？同じIPアドレスに持っちゃうんですか？という問題にぶつかる
- Amazon EBSボリュームは利用不可
  - これは自明だが、AWS環境ではないので。
- インスタンスのオートスケーリングは未対応
  - 自明だが、AWS環境ではないので、サーバを増えたり減ったりということが起こせない
- サービスはオートスケーリング可能
  - サービスとはコンテナの束のこと
- Amazon ECSのネットワークモードにはいくつか種類がある
  - bridgeモード
    - 上のコンテナ自体が仮想化されたIPアドレスと仮想化されたNICを持つ
    - 仮想化されたIPアドレスと仮想化されたNICを持つのであれば、当然同じポート番号を使うことができる
    - 外に出るときは、NAT経由でhostのNIC、MACアドレスをもって出ていく
    - 入ってくるものは、仮想化されたポートマッピングをもとに各コンテナに割り振られる。
  - Hostモード
    - より管理がしやすい、かわりに多様性を失ってしまうもの
    - ホストとNICを共有する。なので当然複数のコンテナは同じポートを使うことができない
  - noneモード
    - ネットワークを使用しないモード

(次のAmazon EKS Anywareの前に…)EKS Distroについて

is 何
- AWSが開発した、Kubernetesのアップストリーム版
  - Kubernetes標準に準拠している
    - AWS独自機能が含まれていない
      - eksctlなどが入っていない
  - 一般的なコミュニティ版であれば、過去3バージョンしかサポートされない（最大9ヶ月）
  - EKS Distroだと拡張サポート機能が提供されている。つまり、次のようになる
    - 過去4バージョンをサポート
    - 最大14ヶ月のサポート

Amazon EKS Anywareについて

ハイブリッド環境で一貫したKubernetes運用基盤を実現するもの
例えば、オンプレも含めるとこんな構成になる
黄色い部分までは標準のKubernetesの世界。Amazon EKS Distroが間に入って、AWS専用の拡張機能を提供している
Amazon EKS Anywareではコントロールプレーンは任意
- （Amazon ECS AnywareではコントロールプレーンはAWSだった）
- こんな構成になる
- まず、ド標準のKubernetesが一番下に載っている
- そこに、Amazon EKS Distroが乗ることで、長期のサポートを実現する
- その上はAWSで動かすかオンプレで動かすかで異なってくる
  - AWS
    - Amazon EKSが動く
    - AWSがシステム（下回り）を運用
    - AWSがサポートするAPIで管理する
  - オンプレミス
    - Amazon EKS Anywareが動く
    - （完全なるKubernetesなので）普段使っている&Amazon AWSがEKS Dirtoro用にサポートしているツール、Kubernetes標準の運用ツールが使える
EKS Anywareではクラスタの管理を簡易にするためのツールが中に入っている
- HA Clustors, Node OS, eksctlあたりはAWS独自機能がEKS Distroの上に乗っかるAmazon EKS Anywareの中に含まれている
  - 自分たちで勝手にk8sをフォークしてものを作ることができないから、こういう複雑な形になっている
  - AWSはOSSのk8sをリスペクトし、途中まで、可能な限りk8s準拠で作りつつも、必要な部分だけ一部AWS独自機能が入っている形。

コンテナの運用を簡便化するサービス2つについて

Amazon Managed Service for Grafanaについて
- Grafanaとは、OSSのダッシュボードツール
  - AWSでいうと、Amazon CloudWatch LogsとかAWS X-Rayとか
  - データセンターのサーバの運用管理などでも使われているもの
  - コンテナに特化してものではない
- Amazon Managed Service for Grafanaについてとはそれらと連携することを前提として作られたAWSのマネージドサービス
  - 自動でAWS X-RayとかAWS IoTとかAmazon ECSとかあとAmazon EC2、Amazon RDSのネットワークやストレージやCPUなどが可視化出来るようになる
Amazon Managed Service for Prometheus
- Prometheusのマネージドサービス
- ログをコレクタがかき集める
- 集めたログをワークスペースにinjestしていく
- GrafanaやAmazon Managed Service for Grafanaには、Prometheusから自動でデータを引っ張るライブラリがある
  - そのため、すぐダッシュボードでログデータを見ることができる（なお、これはGrafana専用のツールというわけではない）