Edited at

JAWS-UG コンテナ支部 #15 イベントレポート


はじめに



ブログ枠で参加したので、Qiitaで概要をまとめていきたいと思います!!


タイムテーブル

時間
内容
登壇者

18:30
受付開始
-

19:00 - 19:05
会場、UG 案内など

19:05 - 19:25
AWS コンテナサービスアップデート
トリ / Amazon Web Services Japan

19:25 - 19:55
Amazon ECSの開発環境を動的に管理するツールを作ってみました
プログラミングヤクザ / サイバーエージェント

19:55 - 20:00
休憩
---

20:00 - 20:30
Fargate運用物語 ~ 本当にコンテナで幸せになりますか? ~
曽根 壮大 / オミカレ

20:30 - 21:00
How Fast can your Fargate Scale?
Pahud Hsieh / Amazon Web Services

21:00
終了・撤収


セッション


1. AWS コンテナサービスアップデート by トリ Twitter: @toricls

2019年の AWS コンテナ関連サービスアップデートをササササッと振り返り



これ、最近パブリックプレビューしてめちゃくちゃありがたい、、(ECS)

https://qiita.com/fukubaka0825/items/a6f5f528771fb63a3192










2. Amazon ECSの開発環境を動的に管理するツールを作ってみました by プログラミングヤクザ Twitter: @prog893


  • (プログラミングヤクザって勝手につけられたらしい。。)

  • PRごとに専用のECS環境を動的に作成、削除できるツールを紹介 EDENというツール


    • REST風APIとCLIツールの二つ





  • タップル誕生にEDENを導入


    • 作成は3秒 削除は2秒  LoadBalancerを作ってないから

    • 自動デプロイでlead timeが短縮できる

    • Terraformのdev00以外のdevが消せる



  • 今後のロードマップやOSS化について、サイバーエージェントのインフラ周りのツールのOSS化プロジェクトについて紹介






3. Fargate運用物語 ~ 本当にコンテナで幸せになりますか? ~ by 曽根 壮大(そね たけとも) Twitter: @soudai1025


Fargateにしてみた


  • 大前提はEC2で困っていること 困ってないならコンテナ、ECS、Fargate必要ない

  • オミカレというサービスをやっていて、Fargateで動いている https://party-calendar.net/

  • EC2よりもFargateを使いたい


    • 根拠なき使用は悪 つらみを積み重ねるだけ



  • よくあるEC2で辛かったこと


    • AMIやAnsibleの管理

    • 手元の環境



  • Ansibleで冪等性担保


    • どんどんオートスケール時の起動が遅くなる

    • AMIのゴールデンディスクも併用する

    • そうするとRoleの管理が非常に煩雑になる。。。。



  • そもそも冪等性は幻想

  • 複雑になったAnsibleのメンテは大変


    • 最初にちゃんと設計していることは稀

    • スタートアップだと特にそう思う

    • 頻繁に環境に手を入れるならコンテナの方が向いている

    • バチっと決まっているならAnsibleはとても便利



  • VagrantとAnsibleでシンプルなLAMPを維持するのは楽だった
    - ただ肥大していくと、乱立するVM。。。

  • だんだん開発環境と本番環境が乖離してくる。。

  • デプロイツールは昔はエースエンジニアがオレオレで作っていた


    • deployをシンプルにしよう

    • dockerfileメンテ、コンテナはシンプルにCDできる!!!最高




Fargateで辛かったこと


  • 最初の環境構築 知見がなくて失敗。。


    • 既存とVPCを容易に分けてしまった

    • 作りながら学ぶ状態

    • パフォーマンスの計測が甘かった

    • ネットワークのdebugが大変



  • トラブルシューティング


    • デバッグしようとするといない。。



  • ログ

  • モニタリング


    • 永続的に個別でとりたい、、チューニングむずい




Fargateにしてよかったこと


  • 開発環境と本番環境の乖離が起きない

  • デプロイがシンプルになる

  • 本番にあるコンテナは全て同じ

  • ロールバックが簡単


    • ECRの履歴で戻せる



  • コンテナの外に閉じているしホストもないので、EC2より守りやすい

  • Stagingや開発環境の複製が簡単

  • パートナーにも環境を提供しやすい

  • CI/CDの環境構築がより簡単になる


コンテナの勘所


  • コンテナの勘所を抑えないと運用は難しい
     - ログとかモニタリングが非常に難しい

  • それ、レンタルサーバでできるよってことよくある

  • テスト書く前にコンテナ化するな

  • 自分たちの解決したい問題のスコープを大事にする

  • コンテナ技術を使うなら仕組みかが重要(状態を持たないからこそ、仕組みかできる)


まとめ


  • 適材適所で自分のユースケースにあった部分をコンテナ化する

  • 技術で課題解決する

  • 運用のことは考えよう



4. How Fast can your Fargate Scale? by Pahud Hsieh Twitter: @pahudnet

AWS Fargate でスパイキーなトラフィックに対して10秒以内にオートスケーリングをトリガーする話


  • Fargateが好きなのはServerless Containerだから

  • しかし、どれくらい早くFargateはScaleしてくれる??

  • 普通のスケールであれば1~3分くらいはかかる Monitor Detenctionだけで


    • iamgeが小さければ小さいほど リージョンがかみ合っていれば それ以降は時間がかからない

    • このMonitor Detectionの時間を短縮する

    • CloudWatchを使わない



  • Step functionがループでイテレーションを回して、監視しているっぽい


  • CDKで2、3行で各リソースが用意される


  • publicに今回のサンプルのソースなどを挙げる予定なので、チェックを!