【開催報告】コンテナラウンドテーブル #2: コンテナ運用に関するディスカッションが行われました

AWS ソリューションアーキテクトの落水です。Amazon ECS や Amazon EKS をご利用中のお客様同士で情報交換をしていただくイベント「コンテナラウンドテーブル」の第二回が、2020 年 11 月 10 日にオンラインで開催されました。第一回の様子は、こちらの開催報告のブログをご確認ください。第二回では 5 社の企業様にご参加いただき、CI/CD パイプラインやコストの最適化など、いくつかのトピックを設定して情報交換およびディスカッションが行われました。

当日のタイムテーブル

14:00 – 14:35: 情報交換

AWS のコンテナサービスをどのように活用しているのか、各企業様からユースケースをご紹介いただきました。参加者の方からは『他社様の運用実績や課題を知ることができ、とても参考になった』などの声もいただいており、有意義な情報交換が行われました。

14:35 – 15:25: ラウンドテーブル

参加された各企業様には事前にアンケートを回答していただき、ご要望の多かったトピックについてラウンドテーブルを実施しました。ラウンドテーブルには、AWS からソリューションアーキテクトの加治・濱、プロダクトデベロッパーアドボケイトの Tori Hara も加わりディスカッションが行われました。ラウンドテーブルで行われたディスカッションについて、いくつかの内容をピックアップしてご紹介します。

 デプロイにおいて課題に感じている点は？

• CI/CD パイプラインを構築しているが、ロールバックなど一部のオペレーションが手動になっているため、できれば自動化したい
• ロールバックについて、アプリケーションの状態が追いやすかったり、管理がしやすい方法があれば知りたい
• 例えば Amazon ECS では、デプロイに AWS CodeDeploy を利用することで Canary デプロイなどのトラフィックコントロールが可能となるので、トラフィックの切り戻しを含めてパイプラインに組み込むとロールバックの制御がやりやすくなる
  • アプリケーションの状態は、ビジネスに近いメトリクスで健全かどうかを判断するのが望ましい

CI/CD パイプラインはどのように構築している？

• Amazon ECS は CI/CD が同一パイプラインだが、Amazon EKS は CI と CD でそれぞれのパイプラインを用意している
  • アプリケーション開発者と SRE でチームが分かれているのが背景
• パイプラインは Jenkins で動かしており、Jenkins のジョブでそれぞれのパイプラインを繋いでいる

開発環境はどのように用意している？

• 開発者ごとに Docker が稼働する環境を用意している
• ローカル環境のマシンで Docker Compose を利用している

開発環境と本番環境のイメージで、環境ごとの差異はどのように管理している？

• 環境変数で制御している
• 開発環境でのみ必要なライブラリをイメージに含める場合、どのようにイメージを管理すべきか
  • 環境ごとに Dockerfile のビルド先を変える方法は考えられる

コストの最適化を行うためのアプローチは？

• Fargate Spot の割合を増やしていきたいが、よりスムーズに終了するために終了通知を 2 分よりも前に送ってほしい
• ベースラインが予測しづらいワークロードだと Savings Plans の導入を難しく感じる
  • Savings Plans とスポットインスタンスの併用がおすすめ
  • 予測可能な部分に Savings Plans を、適用可能なワークロードにスポットインスタンスを利用する
• スポットインスタンスの利用に際して、アプリケーションが中断しやすいように改修する必要がある点を懸念している

などなど、多くのディスカッションが行われました。ご参加いただいた皆様、改めてありがとうございました。「コンテナラウンドテーブル」につきましては、ひとまず今年はこれにて終了となります。今後も、みなさまにわくわくしていただけるようなイベントを実施していきたいと思いますので、ご意見やご要望などにつきましてはぜひフィードバックしていただけますと幸いです。