まえがき
JAWS-UG コンテナ支部 #15 にブログ枠で参加したので、レポートを書きます。
懐かしのツイートと振り返るAWSコンテナサービスアップデート - 2019年上半期編 -
資料
本日の資料をアップしました! #jawsug_ct
— ポジティブな Tori (@toricls) 2019年8月29日
/ "懐かしのツイートと振り返るAWSコンテナサービスアップデート - 2019年上半期編 - Speaker" Deck https://t.co/RakN4D30N1
発表者
Yasuhiro Tori Hara @toricls from AWS Japan
感想
このところAWSのニュースはあらかたチェックしていたので、いい再確認になりました。
個人的にはスライドに出てきたニュースの中では
-
AWSコンテナサービス ロードマップ
- AWSコンテナ系サービスに関しての要望をissueで挙げられたり、対応予定を確認したりできる。
-
Amazon ECS サービスで複数のロードバランサーターゲットグループのサポートを開始
- このアップデートが出来る前は違うLBに紐付けるためだけに同じ内容のサービス作ったりしてましたが、このアップデートによって不要になりました。超便利。
-
Amazon ECR でイミュータブルなイメージタグのサポートを開始
- これチェックしてなかったけど地味に便利ですね。多くの場合タグは一意になるもの(ブランチとかコミットハッシュとか日時とか)を自動で生成して付与するようなデプロイ設計になると思いますが、一度タグつけた内容があとから改変されることがなくなるのは安心ですね。
Amazon ECSの開発環境を動的に管理するツールを作ってみました by prog893
資料
https://www.slideshare.net/TamerlanTorgayev/jawsug-15-amazon-ecs/TamerlanTorgayev/jawsug-15-amazon-ecs発表者
Tamirlan Torgayev @prog893 from CyberAgent
内容の要約
- 課題:開発中にECS上での確認作業を行う際、開発者が多いほど開発環境を構築せねばならず、その際リソースの費用や利用タイミングの調整に面倒が発生していた
- 解決のため、CIの一環としてECS Taskを起動できるツールEDENを開発した
- 雑にまとめると、指定した正環境のECS Taskをコピーして同じ構成のECSサービスを起動するツール
- もともとOSS化する予定だったが、この発表あったのでサクッとOSS化した
感想
- ECSの開発環境として、開発者が多くなるにつれてAWSでの挙動を確認するための開発環境が増えていき、「DevXX環境がほしいです」「DevXX環境はこのPRの確認のために使わせてください」のような前時代的なやりとりが発生してしまうのは大変あるあるでした。
- そして下記の点はとても良いと思いました👍
- ソリューションを考えて実装して、実際開発現場で利用されてるところ
- 実装への割り切り(ALBは新規作成しない、ECS以外のリソースへの破壊的変更はスコープ外とする)
- Mobile/Webアプリ両方で隠しコマンドで接続先を切り替えられるような協力体制を作ったところ
- OSS化への速度
Fargate運用物語 ~ 本当にコンテナで幸せになりますか? ~
資料
発表者
曽根壮大 @soudai1025 from オミカレ
内容要約
- 経緯
- EC2をやめてコンテナ化したい
- 構成管理が辛い
- クリーンなEC2とAnsibleで構築すると起動が遅くなる
- かといってゴールデンAMI方式だと、AMI作り直しが頻発して辛い
- Ansibleは良いツールだが、スピード感を保ちながら冪等を守るのは難しい
- 構成管理をシンプルにするためにDockerが使いたい
- 開発環境が辛い
- シンプルな構成のサーバならVMで十分
- 開発環境の肥大化・多ロール化に伴いサービスに必要なVMが増えてきた
- 起動が遅い
- 構成差分の発生
- デプロイが辛い
- 8年前の自作デプロイツール
- 出戻りしたら不思議なコードが追加されていた
- 誰もメンテできず属人化
- 8年前の自作デプロイツール
- 構成管理が辛い
- EC2をやめてコンテナ化したい
- Fargate導入での知見
- 辛かった点
- AWS/コンテナ/Docker/コンテナオーケストレーションどれも詳しくなかった
- Fargate用のVPC切ったせいでネットワーク設計から苦労
- パフォーマンス計測が甘かった
- ピーク時オートスケーリングでコンテナの起動が間に合わずコンテナがどんどん減っていく
- デバッグで、何のどこをみてもわからず苦戦
- 死んだコンテナが消えていてデバッグできない
- 費用が高い、特にCPU
- ロギングが不自由
- 結果サイドカーが増えていく
- AWS/コンテナ/Docker/コンテナオーケストレーションどれも詳しくなかった
- 良かった点
- 課題点
- 構成管理改善
- 開発環境改善
- デプロイ改善
- それ以外の利点
- セキュリティ観点
- ホストEC2のセキュリティの面倒を見なくて良い
- コンテナを直に外に晒していないので守りやすい
- ミドルウェアのアップグレードもしやすい
- デプロイの切り戻し
- アプリケーションに手を入れず過去のイメージを再デプロイするだけでよい
- セキュリティ観点
- 課題点
- 取り組みによる学び
- 一足飛びに導入したせいで混乱が発生した
- 開発環境からなど段階的にやってもよかった
- 困っている問題を解決する技術を採用しよう
- EC2で困ってなければEC2でいいじゃん、PaaS,SaaSなども検討しましたか?
- コンテナ化でテスト楽になるけどそもそもテスト書いてますか?
- 一足飛びに導入したせいで混乱が発生した
- 辛かった点
感想
インフラの成長はビジネスの成長と両輪なのでまずはビジネスの成長です。そのために必要なことはこの先5年分くらいはやったと思ってます(例えばDBリファクタリングとかもそう
— そーだい@初代ALF (@soudai1025) 2019年8月29日
- インフラの技術的負債って後回しになりがち、ちゃんと返すタイミングを見極めて返し切ったのがすごいと思いました
- タップルとオミカレの事例並ぶの面白かった
- オミカレ全体の構成もしりたかった、構成図ググってもパッと出てこず……
- これからECSに切り替えていくのも簡単にできそうですね
How Fast can your Fargate Scale?
資料
オラオラスケールアウトするマンの図 #jawsug_ct pic.twitter.com/rSf2SX9FAw
— ポジティブな Tori (@toricls) 2019年8月29日
本人のサンプルコードここにあった https://t.co/2dXFkkwFZO #jawsug_ct https://t.co/wrYbcaPmCl
— Ryo Nakamaru (@pottava) 2019年8月29日
発表者
Pahud Hsieh from AWS Taiwan
内容要約
- FargateのAutoScaleを10秒程度で行うには?
- FargateにビルトインされているAutoScaleだとCloudWatchがトリガーするまでに1〜3分かかってしまう
- nginxのstub_status出力をLambda StepFunctionsでポーリングしておき、アクセスが増えたらFargateのサービスのタスク数を増加させるAPIを叩くような仕組みを実現
- 実際に10秒程度でAutoScalingした
感想
- 身も蓋もないんですが、AWSのAutoScalingの仕組みがもっと良くなれば自作しなくていいのではないかと思うんですよね。
- この実装が今の最適解であることや、改善される可能性が低そうなのもわかります。
- StepFunctions
- 見たことなかったけどVisual workflowとかも見られてめっちゃいいですね
- CDK面白そう
-
new Cluster
するだけでFargate用のCluster作れるの偉い - アプリエンジニアがインフラ面倒をみるパターンは良さそうだと1思いました。
- やったことないですが、Step FunctionをTerraformで書くのかなりつらそう……
-
たったこれだけで Fargate タスクが起動して ALB まで用意されるの楽ですよね #jawsug_ct pic.twitter.com/rTz4JL7gaH
— ポジティブな Tori (@toricls) 2019年8月29日
イベント全体の感想
- コンテナサービス系の事例紹介、大きなイベントだと詳しく喋ってくれなかったりするので、深く聞けて楽しかったです。また行きたい。
- Chimeで遠方からも参加できるようになってとってもいいですね。