Edited at

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


まえがき

JAWS-UG コンテナ支部 #15 にブログ枠で参加したので、レポートを書きます。


懐かしのツイートと振り返るAWSコンテナサービスアップデート - 2019年上半期編 -


資料

https://speakerdeck.com/toricls/how-memorable-those-aws-container-services-updates-and-tweets-are



発表者

Yasuhiro Tori Hara @toricls from AWS Japan


感想

このところAWSのニュースはあらかたチェックしていたので、いい再確認になりました。

個人的にはスライドに出てきたニュースの中では


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運用物語 ~ 本当にコンテナで幸せになりますか? ~


資料

https://speakerdeck.com/soudai/fargate-story


発表者

曽根壮大 @soudai1025 from オミカレ


内容要約


  • 経緯


    • EC2をやめてコンテナ化したい


      • 構成管理が辛い


        • クリーンなEC2とAnsibleで構築すると起動が遅くなる

        • かといってゴールデンAMI方式だと、AMI作り直しが頻発して辛い

        • Ansibleは良いツールだが、スピード感を保ちながら冪等を守るのは難しい

        • 構成管理をシンプルにするためにDockerが使いたい



      • 開発環境が辛い


        • シンプルな構成のサーバならVMで十分

        • 開発環境の肥大化・多ロール化に伴いサービスに必要なVMが増えてきた


          • 起動が遅い

          • 構成差分の発生





      • デプロイが辛い


        • 8年前の自作デプロイツール


          • 出戻りしたら不思議なコードが追加されていた

          • 誰もメンテできず属人化









  • Fargate導入での知見


    • 辛かった点


      • AWS/コンテナ/Docker/コンテナオーケストレーションどれも詳しくなかった


        • Fargate用のVPC切ったせいでネットワーク設計から苦労

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


          • ピーク時オートスケーリングでコンテナの起動が間に合わずコンテナがどんどん減っていく



        • デバッグで、何のどこをみてもわからず苦戦


          • 死んだコンテナが消えていてデバッグできない





      • 費用が高い、特にCPU

      • ロギングが不自由


        • 結果サイドカーが増えていく





    • 良かった点


      • 課題点


        • 構成管理改善

        • 開発環境改善

        • デプロイ改善



      • それ以外の利点


        • セキュリティ観点


          • ホストEC2のセキュリティの面倒を見なくて良い

          • コンテナを直に外に晒していないので守りやすい

          • ミドルウェアのアップグレードもしやすい



        • デプロイの切り戻し


          • アプリケーションに手を入れず過去のイメージを再デプロイするだけでよい







    • 取り組みによる学び


      • 一足飛びに導入したせいで混乱が発生した


        • 開発環境からなど段階的にやってもよかった



      • 困っている問題を解決する技術を採用しよう


        • EC2で困ってなければEC2でいいじゃん、PaaS,SaaSなども検討しましたか?

        • コンテナ化でテスト楽になるけどそもそもテスト書いてますか?








感想


  • インフラの技術的負債って後回しになりがち、ちゃんと返すタイミングを見極めて返し切ったのがすごいと思いました

  • タップルとオミカレの事例並ぶの面白かった

  • オミカレ全体の構成もしりたかった、構成図ググってもパッと出てこず……

  • これからECSに切り替えていくのも簡単にできそうですね


How Fast can your Fargate Scale?


資料


発表者

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で書くのかなりつらそう……





イベント全体の感想


  • コンテナサービス系の事例紹介、大きなイベントだと詳しく喋ってくれなかったりするので、深く聞けて楽しかったです。また行きたい。

  • Chimeで遠方からも参加できるようになってとってもいいですね。