見出し画像

2020-07-29 夏のAWSコンテナ祭り with Amazon ECS #ECSMatsuri

2020/07/29 に開催された 夏のAWSコンテナ祭り with Amazon ECS のイベントレポートです。

●イベント概要
みなさん、コンテナサービスをお使いですか?
多くの人がコンテナを使うようになった今だからこそ、「ここでつまってしまった」「ここがわからない」など課題や疑問が顕在化してきていることでしょう。当セミナーでは、AWSコンテナサービス、特にAmazon ECSをお使いのお客様の活用事例と、AWSソリューション アーキテクトによるECS活用のための徹底解説を展開します。


■Capacity Provider をもっと身近に

松田 和樹さん [アマゾン ウェブ サービス ジャパン]

スクリーンショット 2020-07-29 10.50.22

●ECS Capacity Providers
・Capacity
  タスクを配置する先のリソース
  EC2やFargate
・Provide
  コンテナの実行費必要な量を調達
・配置先を決定するための新しい方法
  タスクの配置先の柔軟なコントロール
  60%はオンデマンド、残りはスポットインスタンスなど

スクリーンショット 2020-07-29 10.57.40

●これまでのECSクラスターのスケーリング 1
・ECS Cluster
  ECS Tasks
  EC2 AutoScaling Group
  ※serviceは端折ってます
→ 新しいコンテナが実行されるとVMのCPU、メモリを消費
→ CloudWatch metrics
  CPU, Memory, Network In/Out
  デフォルトだとメモリは取れないのでカスタムメトリクスで
→ CloudWatch Alarm
→ EC2 AutoScaling
  EC2のインスタンスを増やす
・EC2のリソースを見てリアクティブにスケール
  コンテナの整合性は自身でコントロールが必要

スクリーンショット 2020-07-29 10.59.21

●これまでのECSクラスターのスケーリング 2
・ECS Cluster
  ECS Tasks
  EC2 AutoScaling Group
→ CloudWatch metrics
  Cluster CPU reservation, CPU utilization
  クラスタ全体のmetricsが取れる
→ CloudWatch Alarm
→ EC2 AutoScaling
  EC2のインスタンスを増やす
・新規に追加する台数や予約率で調整
  コンテナのメトリクスを見ているが、クラスタ全体
  複数ワークロードが共存すると難しい

●Capacity Providers登場前の課題
・コンテナのスケール前にEC2をスケールさせる必要がある
・コンテナをスケールできる余剰を残しておく必要がある
  空いていないと増加が見えない
  コスト最適化で不利
  最小値を0にすることができない
→ AWS Fargateで考える必要をなくせる
  GPUインスタンスが必要な場合などは自力
・複数のAutoScaling Groupの制御が複雑
  片方縮退している間に
  もう一方のAutoScalingが走ってしまったり
  ルールを考えるのが大変
・スケーリングの設定がECSから独立
  人によっては複雑に感じる
  細かく設定できるので良い面も
・コンテナをバリバリ使っていきたいのに
  コンテナとEC2のスケーリング両方考えないといけない

スクリーンショット 2020-07-29 11.07.20

●Capacity ProvidersによるECSクラスターのスケーリング
・ECS Cluster
  ECS Tasks
  Capacity Provider
    EC2 AutoScaling Group
    図は便宜上包含させているが、紐付ける形
→ コンテナを起動したい
→ CloudWatch metrics
  Capacity Provider Reservation
  追加になる
  Task実行がスケジュールされると変化
→ CloudWatch Alarm
→ AutoScaling
・コンテナワークロードの状態を反映したメトリクスでスケーリング
・Capacity Providerが自動的に設定
  CloudWatch metrics
    Capacity Provider Reservation
  CloudWatch Alarm
  AutoScaling

スクリーンショット 2020-07-29 11.09.11

●複数のCapacity Providerを使うこともできる
・ECS Cluster
  ECS Tasks: 10
  Capacity Provider A: weight 3
    EC2 AutoScaling Group
      オンデマンド 60%
  Capacity Provider B: weight 2
    EC2 AutoScaling Group
      スポットインスタンス 40%
・Taskのリバランスをやってくれる

●ECS Capacity Providersで登場するリソースや機能
・Capacity Provider
・Capacity Provider Strategy
・Capacity Provider Reservation
・Managed Scaling

●Capacity Provider
・ECSとコンテナ実行基盤の間をつなぐ
  AutoScalingGroup, Fargate
  Capacity Provider経由で管理
・1つCapacity Providerとして定義
  AutoScalingGroup, Fargateというグループ
  複数と紐付けることはできない

スクリーンショット 2020-07-29 11.16.26

●Capacity Provider Strategy
・どのCapacity Providerにタスクを配置するか
・Task実行やService作成時に指定
・baseとweightで、複数のCapacity Providerにまたがって配置
  このTaskはCapacityProviderBで実行したい
  こっちのTaskはCapacityProviderA:B = 2:1とか
・Default Capacity Provider Strategy
  Capacity Provider Strategyを指定しないとこれ
  試験環境ならこれでスポットインスタンスなど
・weight
  タスクの総数に対する指定
  最終的にこのバランスに落ち着く
・base
  先にこの最小数が配置される
・Capacity Provider Strategy with Fargate
  基本は同じ
  Fargate Spotは別のCapacityProviderを使う
  AutoScaling GroupのCapacityProviderと混在はできない

●Capacity Provider Reservation
・リソースの割合を表すメトリクス
・キャパシティの予約率

スクリーンショット 2020-07-29 11.19.48

●Managed Scaling
・CloudWatch Alarmとスケーリングポリシーを設定してくれる
・Capacity Provider経由でしか設定できない
  手動では削除も、変更もできないようになっている

●Capacity Providerの実体
・CloudWatchに専用のメトリクスをつくる
・Strategyに基づいてタスク実行状況をメトリクスに反映
  EC2でもECS Clusterでもない
  EC2が存在していないと、値がブランク
  0→1のスケーリングはできなかった
・ManagedScaling
  Alarmとスケーリングポリシーを設定してくれる
  手動操作できない

●まとめ
・タスク配置時にStrategyが考慮してメトリクス制御
・基本のしくみはCloudWatch, EC2 AutoScalingのもの
・CapacityProvider側で、ManagedScalingの設定をするだけ


■コンテナセキュリティ on Amazon ECS を改めて考える

金森 政雄さん [アマゾン ウェブ サービス ジャパン]

スクリーンショット 2020-07-29 13.00.32

ECSのセキュリティを、NIST SP800-190を参考に整理

●なぜコンテナセキュリティを考えるのか
・AWSのセキュリティの考え方

スクリーンショット 2020-07-29 13.04.20

  責任共有モデル
  データセンターやハードウェアやコンピュート層
  そこにアクセスする権限の管理など
・ガードレールの必要性
  オンプレミスの場合
  統制がかかることでブレーキになっていることも
  セキュリティサービスやAPIでの自動化
  アジリティを下げずにセキュリティを担保
  高速道路のたとえ
  一般道と仕切られていることで安心してスピードを出せる
・AWSモダンアプリケーション開発のベストプラクティス
  セキュリティとコンプライアンス
  イノベーションの速度を犠牲にすることなく
  セキュリティ脅威に対応
  標準を自動化し、継続的に評価

スクリーンショット 2020-07-29 13.07.27

●セキュリティ対策のサイクル
・リスクアセスメント
  どんなリスクがあるのかわからないと始まらない
・方針決定
・対策実施
・評価

●NIST SP800-190
・National Institute of Standards and Technology
・SP800シリーズ
  Special Publications
  政府機関向け
  民間企業でも有益
・NIST SP800-190
  2017年9月
  コンテナテクノロジーに関するセキュリティの問題と対応

●NIST SP800-190の構成
・1,2章
  コンテナアプリケーションの技術的特徴の解説
・3,4章
  コンテナテクノロジの5つのコンポーネント
  リスクの解説、対策
・6,7章
  攻撃シナリオの例
  ライフサイクルに沿った考慮事項
・8章
  結論

スクリーンショット 2020-07-29 13.10.54

・executive summary
  コンテナのイミュータブルで宣言的な性質で
  手作業を最小限に
  自動化されたアプリ中心のセキュリティを実現できる

スクリーンショット 2020-07-29 13.12.00

●コンテナのコアコンポーネントとMajor Risks
・コンテナのコアコンポーネント
  Image
  Registory
  Orchestrator
  Container
  HostOS
・ライフサイクルが、各コンポーネントと関わってくる

スクリーンショット 2020-07-29 13.13.03

●Image Risks
・イメージの脆弱性
  イメージ = 性的なアーカイブファイル
    後で脆弱性が見つかる
    動いているコンテナにパッチを当てることはできない
    イメージの更新が必要
  リスク
    脆弱性を持つイメージから脆弱性を持つコンテナが生成される
  対策
    パイプラインベースのビルドアプローチ
    イミュータブル性を活かす仕組み
・埋め込まれたマルウェア
  イメージには悪意のあるファイルが含まれることがある
    意図的、不注意どちらも
  リスク
    マルウェアも他の機能と同等のケイパビリティを持つ
    攻撃ができてしまう
  対策
    継続的にイメージをモニタリング

スクリーンショット 2020-07-29 13.17.48

・ECSでの対策方法
  CoreOS ClairでECRのイメージをスキャン
    image pushでスキャン
    手動、APIで実施
    カバレッジは確認が必要
  コンピテンシーパートナーのソリューション
    セキュリティ、モニタリング、コンテナ管理など

スクリーンショット 2020-07-29 13.19.24

●Registory Risks
・レジストリ内の古いイメージ
  レジストリには古いものが含まれていく
  リスク
    誤って脆弱性のあるバージョンがデプロイされてしまうことも
  対策
    安全ではないイメージやレジストリの削除
    イミュータブルな名前を使ってイメージにアクセス
    latestは最新を指すわけではないので注意

スクリーンショット 2020-07-29 13.21.36

・ECSでの対策方法
  ECRライフサイクルポリシー
    リポジトリ内のイメージのライフサイクル管理を指定
    タグ指定で、1つ以上残すなど

スクリーンショット 2020-07-29 13.22.53

  イミュータブルなイメージタグ
    イメージタグの上書きを禁止できる
    コミットハッシュなどの一意な値を使う事が多い
    イメージの置き換えに耐性がつく

スクリーンショット 2020-07-29 13.23.20

●Orchestrator Risks
・管理者権限への制限のないアクセス
  環境全体をコントロールしたいはず
    セキュリティレベルの違うアプリが混在されていることが多い
    通常、別チームで管理
  リスク
    最小権限の法則に沿っていない
    悪意、不注意で他のコンテナに影響を与えてしまう
  対策
    最小権限のアクセスモデル
    テストチームは本番にアクセス不可など
・認証なしのアクセス
  オーケストレータ独自の認証機構が、組織の認証機構と別
    管理されなかったり、プラクティスが弱くなる
  リスク
    オーケストレーターが持っている高い権限で攻撃
  対策
    管理アカウントの多要素認証
    組織の認証機構とシングルサインオン

スクリーンショット 2020-07-29 13.25.49

・ECSでの対策方法
  IAMでのセキュリティベストプラクティス

スクリーンショット 2020-07-29 13.26.10

●Container Risks
・ランタイムの脆弱性
  コンテナスケープを許すと危険
  リスク
    ランタイム自体を変更
  対策
    ランタイムの脆弱性を追って、対応

スクリーンショット 2020-07-29 13.28.34

・ECSでの対策
  Fargate
    Fargateを使っていれば大丈夫!だけではない
    ランタイムはパッチされるがテストが必要
  ECSタスクのリタイア
    基盤HWに回復不可能な障害や
    プラットフォームバージョンに脆弱性がある場合
    step
      アドレスに通知がくる
      当日になるとタスク停止
  Fargate タスクリサイクル
    ECSサービスのタスクでパッチが適用できない場合
    個々のタスクを停止してシミュレートするテストが必要

スクリーンショット 2020-07-29 13.29.23

●Host OS Risks
・ホストOSコンポーネントの脆弱性
  コンテナ向けOSも、他のソフトウェア同様に脆弱性を持つことがある
  リスク
    すべてのコンテナやアプリに影響
  対策
    脆弱性チェック、アップデート
    イミュータブルなホストOSの運用

スクリーンショット 2020-07-29 13.30.54

・ECSでの対策
  イミュータブルにホストOSを扱う
    SSHを避ける
    パッチ済みAMIから起動
    コンテナの置き換え
      ECSサービスとコンテナインスタンスのドレイン
  置き換えstepの例
    パッチ済みAMI作成
    EC2インスタンスをECSクラスタに登録
    古いコンテナインスタンスをDRAINING設定
    コンテナが置き換わったら、terminate

●まとめ
・コンテナの特性にあった対応が必要
  イミュータブル、宣言的など
・組織の運用文化やプロセスをコンテナに合わせる
  セキュリティ対応の自動化
  開発の責任範囲と権限拡張→DevOps
・コンテナのベストプラクティスに近い
  アジリティだけでなくセキュリティにも貢献する


■その昔ECSでベストプラクティスだったものがアンチパターンになったもの、またはその逆

Toriさん [アマゾン ウェブ サービス ジャパン]

スクリーンショット 2020-07-29 15.40.56

せっかくなので新しいプレゼンを試してみます
手抜きじゃありませんw

スクリーンショット 2020-07-29 15.42.19

●ECSの特徴
・多くのインテグレーションを追加インストールなしで使える
・Fagateで足回りの考慮なしで動かせる

●ネットワーキング
・ECS serviceがALBを使えるようになった
・動的なポートマッピングができるようになった
・それまで
  classicロードバランサーしか使えなかった
  ポートマッピングが固定だった
・問題
  LB
  → EC2:8080
    container:80
  → もう1コンテナ立てたい
    8080は80はマウント済み
  → もう一台EC2を立てる必要があった
・動的ポートマッピング
  ALB
  → EC2:32050
    container:80
    :32051
    container:80
  コスト最適化はまだだった
  デプロイを容易にしていた
・新しいバージョンをデプロイしたい
  ローリングアップデートしかなかった
  もう一つEC2を立てておいてローリングアップデート

スクリーンショット 2020-07-29 15.48.03

・min, max HealthPercentが設定できるようになった
・awsvpcネットワーキングモード
  none コンテナをネットワークにつながない
  host EC2そのまま併用
  bridge VPCとは別のcidrブロックに参加
・問題
  Host/Bridgeモード
  EC2
    ENI
      Container web
        どこからでもOK
      Container api
        VPCだけからアクセス
  security groupはENIにしかつかない
  最小公倍数になっていた
・awsvpc
  概念を説明するためにちょっと崩した図
  EC2
    ENI
    Container
      ENI
    Container
      ENI
  実際にはEC2にENIがついている
  CPU, Memは余っているのに
  ENIのattach上限にひっかかる

・awsvpc Trunkingネットワーキングモード
  none, host, bridge, awsvpc, awsvpc trunking
  fargateはawsvpc
  EC2ではすべて
・タスクごとにENCを使える
  EC2インスタンスの上限を超えてENIを追加できる
  trunkingしているだけだから

●モニタリング
・CloudWatch Container Insights
  Map view
  Taskにドリルダウンして詳細が見れたり
・以前は task metadata endpoints
  sidecarとして外に送り出す処理をつくっていた
・問題
  ECS/Fargate
    Container Runtime
    ECS agent(Fargate agent)
      task metadata endpoint
    container app
    container sidecar
      CloudWatch custom metricに書き込む
      Datadogなども

●ロギング
・FireLens
  プロダクト名でもあり、プロジェクト名でもある
  プロダクト
    アプリコンテナのログを
    サイドカーのfluentd/fluentbitに流し込んてくれる
  プロジェクト名
    DockerHub / fluentbit for aws
・プロダクトのFireLens
  Fargate
    log driver
      awslogs: cloudwatch logsだけだった
      最近 splunkに対応
    aws firelens
・何をしてくれているのか
  ECSタスク
    Container: app
      stdout, stderr
    firelens
      つなぎこみ
      設定injection
        タスク定義やS3で設定
      pluginの同梱
    Container: fluentd/fluentbit
      →外部へ
  自前のimage管理が不要になった

スクリーンショット 2020-07-29 16.06.04

●セキュリティ
・ECSタスクレベルでIAMロールを使えるように
・問題
  EC2
    task1
      s3 get object
    task2
      dynamoDB table write
  以前は、EC2単位だったのでSGと同じ、最小公倍数だった
・それぞれにIAMロールをつけられるようになった
  秘密情報がちゃんと秘密に
  parameter storeのARN指定
  実行時に値を持ってきてinjectしてくれる

スクリーンショット 2020-07-29 16.08.56

・以前の秘密情報
  envにベタ書き
  entrypointのbash
    →secrets managerからget
    →s3からget

●オペレーション・実行管理
・step functions、話題になりましたね

●ストレージ
・やめろと言われているがNFSのユースケースはある
・問題
  EC2にEFSをマウント
  ホストのディレクトリをコンテナにマウント
  → EFSがマウントされている仮想マシンじゃないとダメ
・EFSがコンテナを追いかけるようになった

●スケーリング
・cluster auto scaling ありましたね

AWSのプロダクトは90-95%がお客様のリクエストをもとにつくっている
パブリックロードマップでポジティブリアクションが多いものが実現された


■感想

Capacity Providers便利そうですね!auto scalingの話が出たら使ってみようと思います。

EventBridgeでLambda実行をスケジュールできるんですね!触ってなかったので使ってみようと思います。

CloudWatch Container InsightsのMap viewからのドリルダウン便利そうですね!betaの時に調べただけだったので、触ってみようと思います。

不便なところからユーザーの声で徐々に便利になってきた経緯がよく分かりました。欲しい機能はロードマップでリアクションしていかなくては!

現場の目的での使い方しか把握していなかったので、多くの使ってみたいサービス・機能に出会うことができました。登壇者の皆さん、運営の皆さん、ありがとうございました!



この記事が参加している募集

いつも応援していただいている皆さん支えられています。