JAWS-UG コンテナ支部 #15 参加レポート
コンテナについてお話するJAWS-UG コンテナ支部 #15に参加してきたのでそのまとめです。
懐かしのツイートと振り返るAWS コンテナサービスアップデート – 2019年上半期編 –
Twitter
6 Tweets
https://twitter.com/toricls
2018/11-12
- 11月
- EKSがohaioに、fargateがきたりした
- re: eventでいろいろ発表
- 12月
- ECRコンソールバージョンが上がったりした
- container public roadmapがひっそりリリース
- github上で、どういうふうにサービスを伸ばすかのリポジトリを作って、projectの機能を使ってロードマップとして乗ってます。
2019年上半期
- fargateの最大50%の値下げ
- 1/17 EKSで99.9%のSLA
- ECRで99.9%のSLA
- ECSでのEC2がsecrets managerをサポート
- パラメータストアに定義したものをコンテナにインジェクトしていたが、secrets managerも正式にサポートした
- ECS, ECR, Fargateがprivate linkをサポート
- エンドポイントを叩くが、インターネットに公開されていることが多い。
- vpcの中のECRのpullしたいときなどにprivate linkを使える
- しかし、fargateはサポートしていなかったので、今回それをサポートした
- ECSがGPU対応EC2インスタンスのサポートを強化
- ECSはCPU/memory/port番号を考えてコンテナを置くが、GPUも考えておくようにした
- EKSがムンバイ、ロンドン、パリのAWSリージョンで使えるように
- ECSがコンテナの依存関係の管理を強化
- コンテナは1個で起動して、productionで使ったりするが、タスクの中にコンテナが複数あったりする。ものによっては順番で起動したり、コンテナの起動を待ってから起動したり、停止をまってから停止したり、停止のタイムアウトの設定が必要になったりする。そういった依存関係などを設定できるようになった
- EKSがKubernates APIサーバーエンドポイントアクセスコントロールをリリース
- privateなendpointを設定できるようになった
- ALBで高度なリクエストルーティングをサポート
- HTTPヘッダ、メソッド、クエリ文字列、ソースIP CIDRが条件として使える！
- EKSがwindwos コンテナサポートのパブリックレビューを開始
- ※ちなみに会場内でwindowsコンテナを使ってる人はほぼ皆無
- ECSで新しいローカルのテストツールが利用可能に
- ecsで起動したらhttpsエンドポイントが付与されているが、ecsで起動しないと使われない
- クレデンシャルを発行したり、タスクのメタデータを使ったりするが、ローカルでテストできないので、それらを再現するコンテナを公開した
- AWS App Meshが一般提供を開始
- Deep Learning Containersがリリース
- Machine Learningはセットアップが大変だが、そのへんのセットアップをサポート
- Fargateおよび、ECSが外部デプロイメントコントローラをサポート
- デプロイするときはローリングとブルーグリーンデプロイが使えるが、外部デプロイメントコントロールは全てをコントロールできるAPIを公開した
- マキシマムの調整や、LBから外すなど、全てAPIから呼べるようになった
- ぷちカナリアリリースができる
- EKSで1.12
- EFSとFSx for LustreのCSI Driverを公開
- Fargateがシークレットとコンテナ依存関係をサポート
- 起動順番のパラメータも設定できるように。
- EKSがCloud Watchへのkubernetesコントロールプレーンログの配信を開始
- cube controlを叩くとaudit logがjsonで出てくるが、それを分析で使ったりする
- root権限など気をつけるときに使う
- ECSに対するAWS CloudFormationのサポート範囲更新
- EKSがパブリックレビューとしてA1インスタンスが使える
- Fargateがsplunkログドライバーに対応
- EKSがk8sがクラスター認証を簡素化
- IAMとk8sの認証認可をマッピングするプラグインがデフォルトで動いているが、EKSはセキュリティのために外せないようになっている
- 今回のアップデートでaws iam authentificatorが不要で使えるようになった
- EKS/k8s向けCloudWatch Container Insightsのプレビュー開始
- EKSバージョンライフサイクル更新
- k8s 1.10はdepricationになった
- ECSでwindows server2019コンテナのサポートが一般利用可能に
- windwosコンテナはでかい。1Gとかあったが、windows server2019からナノコンテナというものが動かせる（しかし.NET frameworkは使えない）
- ECSがawsvpcネットワークモードのタスクに対するElastic Network Interface制限の強化をサポート
- SGやvpc flowlogなどをとるためにコンテナがVPCのIPを持つのは大事
- vpcレベルのIPがもらえるが、今までEC2はつけられるENIの制限がかかっていて、今回のアップデートでもっとつけれるようになった
- CodeCommitで２つのマージ戦略とマージ競合の解決方法をサポート
- ECSのCloudFormationの更新
- AppMeshServiceDiscoveryがdeepになった
- EKSがk8sv1.13、private linkおよび、pod セキュリティーのサポート
- EKSの正式名称がamazon elastic kubernetes serviceに変更
- ECSが新しいリソースレベルのアクセス許可及びタグベースのアクセス制御をサポート
最近
- ECSとfargate向け、cloudwatch container insightsプレビュー開始
- CDKの一般公開を開始
- FluentBitプラグインをリリース
- ECSがローカルテスト向けの改善された機能の提供を開始
- ECSコンソールがAppMeshとのシンプルな統合に対応
- AppMeshの設定をECSのコンソールでいい感じにexpandしてくれるようになった。
- cliでは設定できません
- chatbot（ベータ）の紹介
- slackかamazon chimeにbotがグラフ付きでメッセージを投げれる
- ECRでイミュータブルなイメージタグのサポートを開始
– コンテナイメージからソースをとれるようにcommit hashtagをつけているが、簡単に変えられてしまう。
- そこで、信頼性をあげるために、この名前のコンテナは一意であることを言えるようになった
- ECSサービスで複数のLBターゲットグループのサポートを開始 – 今まではインターネット用と内部用で2このサービスをデプロイしないといけなくなった
- fargateとeksが香港リリース
- ECSがコンテナ単位でのスワップ領域パラメータのサポートを開始
一番伸びたツイート
そういえば、Amazon EKS の正式名称が改称されて、今日から "Amazon Elastic Kubernetes Service" になってます！
(え、元ですか？元は "Amazon Elastic Container Service for Kubernetes" でした)https://t.co/7lts6KkvR3
— ポジティブな Tori (@toricls) June 19, 2019
Amazon ECSの開発環境を動的に管理するツールを作ってみました
Twitter
https://twitter.com/prog893
- よく見る流れの話として、ECS導入して、簡単だし楽だからオンプレからAWSに移設するという話において、移設してECSでの本格開発が始まり、リアルなDBとか周辺サービスつなぎ込んでAWS上でどう動くかマージする前に確認したいという要件が出てくる
- しかし、開発環境は一つだけの状態。
- 理想としてはA/B testingやmicroserviceにするがいいが、現実としてはdevxx方式として、同じdev環境を複数用意するやり方になる
- しかし開発レーンが増えてしまう
- クラウドとアプリケーションの稼働プラットフォームが変わっただけでチームとメンバーの意識や開発スタイルが何も変わってないのが問題
- devxx方式のメリット
- 学習コストが低い
- ansible的なのを流してdns設定するだけ
- 導入コストも低い
- コードの修正もいらない
- 一つ一つの環境が完全分離されてる
- デメリット
- チャットベースで管理したり、割当表ができたりで原始的コミュニケーションが走る
- 環境増減は手動
- ALBは作成時間がかかり、いるだけでprovisioningで課金される
- お金がかかる
- シャットダウン忘れや、サーバ以外のリソース（LB）がかかったりする
- そこでdevxxを自動化してみた
- CFn/Terraform/CDKで作ると思うが、自動コミットとか自動applyは怖い
- 自前ツールとして、dev環境の増減するところをIaaCで管理しないスタイル
- 動的devxx
- devxx方式のメリットを活かしつつデメリットを解消
- ALB使いまわしてそれ以外はいい感じに自動化
- 1環境のライフサイクルを考えると、1つのPRで完結する場合が多いので、環境とPRは1:1の関係
- PRが作成されたら環境を作成、クローズorマージされたら削除する
- EDENというシステムを作りました！
EDEN
- create/deleteの2コマンドのみ
- 既存環境へのcreateはtask definitionの作成とdeployのみ
- REST風APIとCLIがある。（RESTfulではない）
- 参照となるECS Serviceを指定するとそれをパクってくれる
- 常にリポジトリのマスターを参照して、それをIaaCで管理想定
- 環境を作成するたびにDescribeを行う
- dev00を変更すればそれ以降に作成された動的環境が新しい設定で作成される
- 既存の環境を更新したければ一旦deleteする
- つくるもの
- ECS Task Definition
- ALB Target Group
- ECS Service
- ALB Listener Rule（共通ALBにHostHeaderルール追加のみ）
- Route 53 CNAME record
- configファイルの更新
- configファイル
- 開発アプリケーションにどんな環境があるかを知らせるためのjsonファイル
- 隠しメニューを出すとjsonから生成された環境一覧が出る
- 環境が切り替えられる
- prefix、ブランチ名、環境などでendpointが生成される
タップル誕生で導入してみた
- cliからいれてみた
- 環境作成3秒、削除2秒くらい
- 既存環境へのcreateはdeployするだけになるのでもっと早い
- eden REST APIをデプロイした
- CIでビルドとECRへのpushが終わった直後に条件分岐追加することで、commitで環境作ってmergeで環境削除するようにした
- 感想
- 自動デプロイでlead timeが短縮できる
- terraformのdev00以外のdevが消せる
- 利用が終わったdev環境にmaster流し直すとかしなくなってもよくなった
- feedback
- staleになって放置されてるPRの環境が自動的に削除されてほしい。
- どんな環境があるのかの一覧としてみたい
OSS化について
- baikonur projectというOSS化プロジェクトでterraformのモジュールなど公開しているが、そこで出しました！
- aws-eden-core
- APIとCLIの共通部分
- aws-eden-cli
開発ロードマップ
- 作成された環境のstateを持つようにする
- 32文字までしかブランチ名使えないので回避用branch名称登録するようにする
- stale environment auto-cleaner
- 放置されてそうなブランチのenvを消すやつ
- 1日以上デプロイがない開発環境を削除
- remote-ls
- 環境一覧出すやつ
- ここまでできたらほかサービスへの導入ができるので、導入サービス増やしていきます
まとめ
- ECS Serviceとか環境一式を秒で作成、削除できるツール作ったら反響がよく、管理コスト、リソースコストが削減できた
- OSS化出した
QA
- 環境のコピーの具体的な方法は？
- リファレンス環境を都度describeして、可変パラメータ部分を上書きしてAPIを叩く。ここではterraformとかは使わない
- DBが破壊的な変更が行われるときはどうするか？
- DBは共通なものを使ってる前提
- LBの仕組みかえるやDB変更などでは使えないことがある
- 最初に作るLBにedenからアタッチしてると思うが、標本のALBの構成をいじるときは不都合ないか？
- dev00についてるLBは使い回さない
- LBはeden専用になる。それはterraform管理なのでそれをいじって変更する
Fargate運用物語 ～ 本当にコンテナで幸せになりますか？
Twitter
12 Tweets
2 Users
4 Pockets
https://twitter.com/soudai1025
- 結論としては、EC2で運用できるならEC2。EC2で困っているならコンテナ
- コンテナを使うという中で、シンプルなサービス構成ならFargateが合う
EC2よりもfargateを使いたい
- なぜならば使いたいからだという理由はダメ。根拠がないとつらみを重ねるだけ
- どういうオーケストレーションサービスを使うのかという理由も大事
EC2で辛かったこと
- AMIやANsibleの管理
- オートスケールの起動がどんどん遅くなる
- オートスケール用のAMIを作ろうとして作ったが、細かい修正のたびにAMI作り直す必要が出てきた
- ロールが増えてくると、サーバの責務がansibleの責務を超えてしまいがち
- そもそも冪等性を担保するansibleを作るのが難しい。責務が増えると複雑度が増えていく
- 複雑になったansibleのメンテは大変
- 最初にちゃんと設計してることは稀
- Ansibleはとても便利だが、頻繁に環境に手を入れるならコンテナのほうが向いてる
- 固まった運用する（パッケージングして提供するなど）ほうならansibleやterraformは合う
- 何回もロールバックしたりするのであればコンテナが向いてる
- 手元の環境との乖離
- LAMPのときはEC2 & Vagrantでも良かった
- APIやデータストア層が増えてくると、どんどん複雑になっていく
- 1つのvagrantではでかすぎてのっけられなくなる。
- AnsibleとVMもロール単位で分けよう！
- コンポーネント毎にVMが乱立する
- そこでdockerを使おうとなったが、Ansibleとdockerの二重管理になり、本番と開発環境で乖離がでた
- deployの複雑さ
- はるか昔、deployツールは神から与えられた（エースエンジニアが作る）
- mackerelからwebサーバ一覧取得したりしてデプロイしてた
- 8年前のデプロイツール、メンテが属人化したので、deployをシンプルにしようとなった
- システム開発において、誰かがいないとデプロイできないというのは致命的。誰でもかんたんにデプロイできるというのが重要
- そういうことを考えたらgithubのmasterからコンテナを生成、circle ciがECRにpushして、ECSにデプロイする仕組みにした
- docker fileだけメンテすればいいようになったが、、、次章へ続く
Fargateで辛かったこと
- 最初の環境構築
- トラブルシューティング
- ログ
- モニタリング
- 知見が全くない状態でいきなり作ったのは失敗だった
- 実務経験がある人が重要
- 構築と運用が属人化する
- そうしないと運用のフェーズになったときに単一障害点になる
- 知見がなくて失敗したこと
- 既存とVPCを安易に分けてしまった。構築するときにvpcだけ変えて作れるようにしたかったが、ALBがターゲットグループを分けたときに接続できない。そうするとルートテーブル設定したり、ペアリング接続設定したりしないといけない。webサービスとapiは同じvpcにいる。aws内で通信するのでペアリング設定が難しくなる
- ECRからデプロイされるが、サービスディスカバリをデプロイするといいとなるが、消すのが難しい。cliで消すことが後ほどわかる。
- コンテナに限らずだが、パフォーマンスの計測が甘かった
- cdn挟むので計測が甘かった
- ネットワークのdebugが大変
- EMSが設定されてるか、ALBが他のALB通ってるか、SG正しいか、ESに届いてるかなど大変
- xray使えばいいと言われるが、構築中は大変
- ALBのhttpsヘッダの設定、リスナーの複数登録が対応してなくてオレオレプラグインができたりした
- ECSのオートスケールが間に合わない
- 増える速度より減る速度のほうが早い
- コンテナが落ちたとき、DNSなのか、ネットワークなのか調査が早い
- オートスケールは簡単だけど、増えるより落ちるほうが早くて困る
- fargateは高い。特にcpuを増やすと金額が跳ねる。メモリはミニマムの設定でいいが、CPUはチューニングしたい
- ログが気軽に保存できない。
- fargateのログがcloud watch logsに入るわけではない
- アプリのログやミドルウェアのアクセスログ、リトライログなどをなげたいが、そういうときはfluentdをいれたりしないといけない
- コンテナのdebugしたいけど、大切なときに君はもういない
- モニタリングしてチューニングしたいけど、永続的な情報を取るのは難しい – cloud watchの一本の線を見るしか無い。複数台があって平均値がとられてしまう
- 最初はEC2のECSで作ればよかった
Fargateで良かったこと
- 当初の目的を得られたのはでかい
- 運用が回りだせば順調
- 本番にあるコンテナは全て同じ。バージョンを固定することも常に最新にすることもコントロールしやすい
- 常に最新のパッケージを使ってるのでセキュアになるし、fargateはホストのことを考えなくても良い
- ロールバックがかんたん
- ECRの履歴を使って戻せる
- ビルドやコードの調整は不要
- コンテナは外に閉じてるし、ホスト無いので、EC2よりも守りやすい
- アプリケーションのセキュリティだけに注力すればいい
- stagingや開発環境の複製がかんたん
- パートナーにも艦娘湯を提供しやすい
- しかし、CloudFrontは時間かかる
- CI/CDの環境構築がよりかんたんになるのでサービスの品質向上に
- コンテナを利用するメリットは多いので、コンテナに合わせた運用を考えながらチョイスするのが大事
コンテナの勘所
- 段階的に学ぶことが大事
- いきなりコンテナからやり始めたりすると
- テストが楽になる！
- 弊社ちゃんとテストある？
- テスト書くほうが先。
- テストがないとメリットが弱い
- ネットワークとログの設計はコンテナのほうが難しい
- 油断するとサイドカーを増やしたくなる
- それならEC2でいい
- サイドカーが増えていくなら本当にやりたいことなのかを考えたほうがいい
- ブログを立てたいだけとかならレンタルサーバでできたりする
- BeansTalkもあったりするので選択肢を考える
- 自分たちの解決したい問題のスコープを大事にする
- EC2をやめたいという要素があるからfargateがある。
- コンテナ技術を使うなら仕組み化が重要
- 状態を持たないからこそ仕組み化しやすい
まとめ
- コンテナは使えばいいものではない
- 解決したい課題に合わせる
- 一部から使うことでもメリットはある
- 運用のことは考えよう
- 技術で課題を解決する
How Fast can your Fargate Scale?
- Fargateは全くサーバを管理しないで使えるサービスでみんな愛しているが、課題としてどうやってfargateをスケールするのか？という課題がある
- cloud watchではスケールの必要性に気づくのに1-3分かかる
- そこで、/nginx_statusを3秒ごとにGETするlambdaをStepFunctionで叩き、スケールアウトの必要に気づいたらlambdaがECS Control Planeを叩いてスケールさせる仕組みを考案
オラオラスケールアウトするマンの図 #jawsug_ct pic.twitter.com/rSf2SX9FAw
— ポジティブな Tori (@toricls) August 29, 2019
- StepFunctionでは、現在のスケール状態のステートを持っていて、コネクション数などに応じてスケールを管理する
- 今回の仕組みはcdkを使って全て構築しています
たったこれだけで Fargate タスクが起動して ALB まで用意されるの楽ですよね #jawsug_ct pic.twitter.com/rTz4JL7gaH
— ポジティブな Tori (@toricls) August 29, 2019
- aws sampleは来週公開します（本人のリポジトリはこちら）
- →公開されました
@mogmetの所管
コンテナ周りの情報をリアルな声を含めて沢山キャッチアップできるとてもいい勉強会でした。
特にECSのオートスケールについては、目から鱗な方法でした。
今までは遅いので時間に合わせて予め大きくしとくしか無いかなぁと思っていたのですが、この方法ならば突発的な負荷の上昇にも使えそうなので、早速導入したいと思える素晴らしいデモンストレーションでした。
