AWS Fargate ECS/EKS祭りに参加した際のメモ

AWS Fargate ECS/EKS祭り

  • 8/3(金)
  • AmaozonWebServices目黒セントラルスクエア

AWS Fargate & Amazon ECS/EKS最新情報

ECS

  • AWS 西谷さん(@Keisuke69)
  • コントロールプレーン=コンテナの管理をする場所(ECS/EKS)どこでコンテナを動かす?生死は?デプロイ時にどこに配置する?など
  • データプレーン=実際にコンテナが稼働する場所(Fargate/EC2)
  • ECSの話
    • ローンチされてから数年
    • 数百万インスタンス/数億コンテナが毎週起動
    • プロダクションでコンテナ運用を支援するために開発されている
    • CloudWatchLogと簡単に連携
    • CloudWatch Iventと連携
  • Fargateのローンチ
  • 7月からTokyoリージョンサポート
  • AutoScallingをユーザー側で考えなくても良い(ECSと同じ)
  • スケジューラ、LBなどはECSと同じで利用可能
  • 課金はCPUとメモリが秒単位
  • FarageteはVPCネットワーク利用のみ
  • ALB/ELBをサポートしている
  • パーミッションタイプ(Cluster/Application/HouseKeeper)
  • CloudWatchでモニタリング
  • Farfateで難しいもの
    • Windows Containers
    • GPU Support
    • docker exec デバッグ
    • SpotやRIベースの価格モデルの適用→必要ならEC2モード
  • Lambdaのほうがよい場合
    • イベント・ドリブン
    • ミリ秒単位のコンピュート
    • ランタイム管理したくない
    • 分散バッチコンピューティング
  • コンテナのAutoScaling
  • ECS Trackingとの連携がおすすめ
  • SLA99.99%(ECSと同じ)

EKS

  • k8sをプロダクションを運用している人→ちらほら
  • k8sは可用性のためにAZをまたいで3つ作成が必要 on AWS
  • k8sは人気があるが自前構築が大変…
  • AmazonEKSはずっとプレビューだったが、6月末で一般公開になった(AWS、Kubernetesを簡単に実行できる「Amazon EKS」を正式リリース)
  • Confirmability
  • CNI plugin
  • ENI Secondary IP
  • LB: CoreOSALB
  • エンドポイント認証はIAMできる
  • FlutendでCloudWatch Logsと連携が簡単
  • WorkerのメトリックスはCloudWatchで取れる
  • AmazonECS + AmazoneEKS + Faragte 連携予定

コンテナ化したアプリケーションをAWSを動かすためのベストプラクティス

  • 福井さん(@afukui)
  • カナリアデプロイ/ブルー・グリーンデプロイ がやりやすいのがコンテナのメリット
  • マイクロサービス化している方? – ちらほら
  • コンテナを利用した開発に必要な技術要素
    • アプリのステートレス化
    • レジストリ
  • コンテナの中にいれるのはステートレスなアプリに
  • ステートが必要なものはコンテナの外に
    • RDBMS -> RDS
    • オブジェクト -> S3
  • Twelve-Factor App(The Twelve-Factor App)
  • レジストリの自前運用は大変なのでマネージドを使うのがおすすめ
  • CI/CDパイプラン
    • 自動化するメリットは誰がデプロイしても同じ結果になる
    • デプロイ職人(!)のような属人性をうまない
  • CodeBuildでイメージをECRへデプロイ
  • コンテナをデプロイするのはCodePipeline
  • ECRでライフサイクルポリシーでイメージの自動クリーンアップ
  • スケジューラでBlue/Greenデプロイサポート
  • IAM RoleはTaskごとに設定可能
  • Service Discovery by Route53 が提供された
  • Target Trackingと連携してAutoScaling可能(CPUやメモリの使用率でスケールできる)
  • CI/CDパイプライン
    • 誰がやっても同じようにデプロイできること
    • イメージがどうやて作られどこで使われているか把握
    • アプリごとに統一された手法を利用する
  • Amazonで年間5000万回のデプロイメント
  • AWS CodePipelineでつなげることができる
  • CodePipeline
    • GUI
    • ソフトウェアのリリースプロセスをモデル化
    • Github連携可能
    • マニュアル承認のサポート
    • Dockerで動いている
    • ビルドした分数で課金なので動いていなければ課金されない
    • ローカルのCodeBuild環境が提供
    • VPCエンドポイントをリリースしている
  • CodeCommit
    • Gitソース管理
    • git互換
    • バックエンドS3
  • Farageteはインスタンス管理を不要として、理想的なオートスケール実現可能でアプリケーション開発に集中できる

kintone on EKS

kintone on EKS ― EKS で実現するインフラ自動構築パイプライン

  • 野島さん(@nojima)
  • サイボウズ
  • EKSで構築している
  • NginxをLBとして使っている
  • 「理想状態への収束」
  • 「手順」をそのまま自動化すると脆くなる
  • 常に自動構築を動かす
  • 継続的インテグレーション
    • git push をするたびにCIで変更を開発環境に適用する
    • 一日一回CIでVPCを削除してゼロから再構築する
  • k8sのマニフェストに動的に情報を埋め込む(AmazonElasticsearchはあとからホスト名がわかるため、CloudFormationに変数を埋め込んでいる)
  • type=LoadBalancerのserviceを作る
    • やりすぎな場合もある
  • Route53にpodのIPアドレスを登録する
  • EKSの利点
    • エコシステムが多い
    • オンプレで使える(自社DCがある)
  • ECSの利点
    • AWSとのインテグレーションが強い

AWS FargateでElixirのコンテンツ配信システムを運用してみた

  • エムスリー 園田さん
  • AWS FargateでElixirのコンテンツ配信システムを動かしてみた (実装編) – エムスリーテックブログ
  • Fargate化してみて
    • アプリケーションデプロイが高速化(20分→10分)
    • プラットフォーム変更にかかる時間が高速化(1時間→2分)
    • デプロイパイプラインが管理しやすくなった
  • Fargate化前はErlangがインストールされていたCustomPlatformをつかっていた
  • CustomPLatformのビルド時間が長い..(Erlangだけで40分)
  • Fluentdもタスクとして動かしてログを収集
  • Gitlabを使っていたのでIAMの権限が強かったのでS3にPushするようにした
  • ecs-cliで直接ECSにデプロイは強い権限を与えることになるのでボツにした
  • 課題
    • 監視の仕組み
    • buildspec.ymlがアプリケーションリポジトリにしか置けない

EKS,Fargate,コンテナの運用監視はいままでとなにが違うのか?よくある課題とその対策

  • Datadog 服部さん @toolyee
  • Datadogは監視対象サーバーが100万台
  • データの収集は安価に可能だが、いざ必要なときに持たざる場合は高くつく
  • データは取れるだけ取っておく!
  • EKS/Fargateだから監視が特別になるわけではない
  • コンテナ環境ではデータを取るプロセスに特徴がある
  • 8 surprising facts about real Docker adoption
  • Dockerが稼働するホストはDataDogの20%
  • 50%のユーザーがオーケストレーターを利用
  • オーケストレーターがコンテナのライフタイムを平均で半日にまで縮小
  • k8sのイメージランキング
  • Nginx,Redis,Postgress or Fluentd
  • モニタリングすべき対象が増えていく
  • スケールを前提としたモニタリング基盤が必要
  • タグやラベルによるクエリベースのモニタリング