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
- モニタリングすべき対象が増えていく
- スケールを前提としたモニタリング基盤が必要
- タグやラベルによるクエリベースのモニタリング