【レポート】 JAWS-UGコンテナ支部 21 西谷圭介さんとトリさん徹底討論スペシャル #jawsug_ct
コンサル部のとばち(@toda_kk)です。
JAWS-UGコンテナ支部 #21 に参加しました。
今回はいつもと毛色が異なり、AWS Japanからスタートアップへ転身された元サーバーレスSAの西谷圭介さんと元コンテナSAのトリさんのお二人に プロレス 討論していただこうという企画になっていました。
セッションタイトルでは「スタートアップ向け」とはなっているものの、スタートアップ以外の企業様にとってもサーバーレスとコンテナの活用を考える上で参考になる討論となっておりましたので、簡単に内容をまとめてみました。
拾いきれていないところも多々あり、また大変面白いやりとりもありました。動画アーカイブが公開されるようなので、全編が気になる方はぜひご覧ください!
動画アーカイブ
セッション一覧
内容 | 登壇者 |
---|---|
AWS最近のコンテナアップデート振り返り | 林政利さん / AWS Japan |
徹底討論!「トリと西谷がすべて語る Lambda vs ECS vs EKS、スタートアップに本当に向いている技術選定とは?」 | 西谷圭介さん(パネラー)、トリさん(パネラー)、ハマコーさん(モデレーター) |
AWS最近のコンテナアップデート振り返り
概要
みなさん、最近のAWSコンテナアップデート追えていますか?本日の徹底討論前に、AWSの最新コンテナアップデートを振り返って、今日の討論のためのアップをしておきましょう! 今回はAWS コンテナスペシャリストの林さんがお届けします。
登壇者
- 林 政利さん
- AWS Japan コンテナスペシャリストSA
内容
アジェンダ
まず、AWSコンテナ関連のサービスについて、最近のアップデートの振り返りがありました。
直近のものだけでも膨大な量のアップデートがあるので、以下のサービスに限定して紹介されていました。
- Amazon ECS
- Amazon EKS / Kubernetes
- Amazon ECR
- AWS App Runner
Amazon ECS
- AWS Fargate でアプリケーションのより高速なスケーリングが可能に
- Fargateではアカウント共有のレートリミットがあり、スケーリングの際のボトルネックになっていたが、継続的な改善によって 20tasks/秒 まで短縮されている。
- 詳解: Amazon Elastic Container Service と AWS Fargate のタスク起動レートの向上 | Amazon Web Services ブログ
- Amazon ECS on FargateでAWS Graviton2が利用可能に
- Amazon ECS Anywhere(外部インスタンス)
- Windowsサポート
Amazon EKS / Kubernetes
- Karpenter GA
- AWSがオープンソースで開発しているKubernetesのクラスターオートスケーラー。
- 現在デファクトスタンダードとなっているKubernetes Cluster Autoscalerでは、事前にノードグループを定義する必要があり、クラスターが肥大化するにつれて管理上のボトルネックになりがちという課題がある。
- Karpenterはそうした課題を解決するための仕組み。
- PendingしているPodの使用を見て、動的にインスタンスを起動。
- EC2 Fleet APIを使用するので、事前にノードグループを定義する必要がない。
- ユースケースとしては、緩いマルチテナント環境や、機械学習ワークロードが挙げられる。
- Karpenter のご紹介 – オープンソースの高性能 Kubernetes Cluster Autoscaler | Amazon Web Services ブログ
- KubernetesクラスターでNodeの自動スケーリングをするKarpenterがGA#reinvent | DevelopersIO
- Amazon EKSのIPv6サポート
- IPv4だと発生しがちなIP枯渇のリスクがなくなる。
- Amazon EKS が IPv6 サポートを開始 | Amazon Web Services ブログ
- Amazon EKS on Fargate監視関連
- Amazon EKS on AWS Fargate が Fluent Bit Kubernetes Filter のサポートを開始
- Amazon CloudWatch Container InsightsがEKS on Fargateをサポート(AWS Distro for OpenTelemetryを使用)
- AWS Distro for OpenTelemetry を使用した CloudWatch Container Insights の EKS Fargate サポートのご紹介 | Amazon Web Services ブログ
- Kubernetes protection in Amazon GuardDuty
- Amazon EKS and Bottlerocket
Amazon ECR
- Amazon ECR Enhanced Scanning
- Amazon ECR Pull Through Cache Repository
AWS App Runner
- AWS App RunnerのVPCサポート
徹底討論!「トリと西谷がすべて語る Lambda vs ECS vs EKS、スタートアップに本当に向いている技術選定とは?」
概要
AWSでイマドキのWebアプリケーションを構築する際、代表的なプラットフォームの選択肢にあげられるのが、以下の3種なのは論をまたないでしょう。
Lambda(サーバーレス) ECS(コンテナ) EKS(コンテナ) これらのうち、スタートアップにおけるサービス提供という文脈では、一体何を選択するのが正解なんでしょうか?奇しくもAWS Japanからスタートアップへ転身された元サーバーレスとコンテナSAのお二人に思う存分に語ってもらいながら、それぞれの技術要素の特徴を深堀りする、そんな超絶貴重な時間にできればと思います。
当日はパネルディスカッション形式を予定してます。 Twitterからお二人への質問もたくさん拾う予定なので、ぜひ皆さん積極的に場外乱闘繰り広げましょう!
登壇者
- 西谷圭介さん(パネラー)
- Singular Perturbations CTO
- 元AWS Japan サーバーレススペシャリストSA、シニアスペシャリストSA
- トリさん(パネラー)
- カミナシ ソフトウェアエンジニア
- 元AWS Japan コンテナスペシャリストSA、元AWS Product Developer Advocate, Containers
- ハマコーさん(モデレーター)
- クラスメソッド MAD事業部
- DevelopersIOでの投稿記事
- コンテナ支部運営メンバーのみなさん(ワイガヤ)
内容
NGワード「適材適所」
セッション冒頭、早速モデレーターのハマコーさんからNGワードが発表されました。「適材適所」です。
適材適所禁止www これを禁じられたらAWSのSAはほとんど喋れることがなくなるぞ #jawsug_ct
— Keisuke Nishitani (@Keisuke69) April 22, 2022
そりゃあそうじゃ。
全体の流れ
スタートアップって実際どんなところ?
- 西谷さん
- 「スタートアップ」と一言で言っても、ステージやフェーズによってだいぶ違う。
- 今の会社は社員が1桁台(西谷さんが2人目)なので、企業としての体制をなしていない。一方で、スピード感がある。
- やろうと思っていること・ビジョンはあるものの、それ以外は何もないのがスタートアップ。
- トリさん
- カミナシはもう少し後のフェーズ(シリーズA)で、企業としての体制をなすための機能がそこそこできつつある。開発者、バックオフィス、カスタマーサクセスの人たちもいる。
- とはいえ、前職と比べると「マジなんもねえ」ってなる。
スタートアップにおける技術選定の考え方とは?
- 西谷さん
- 基本的には、業務委託のメンバーも含めたチームにとって、一番手っ取り早く形を作れるものを採用している。学習コストも考慮に入れる。
- トリさん
- 入社したときに既に動いているものがあった。過去1〜2年のシリーズAの前は、同じように早く作れる技術を採用していた。
- 今であればPMF(Product Market Fit)の後なので、数年後のビジネススケールを想定する必要がある。例えば、エンタープライズへの導入など。
- 西谷さん
- 今の時点でも、計算量とスケーラビリティを意識したアーキテクチャ選定やコードレビューを実施している。
- トリさん
- SAのバックグラウンドがあるから、とても意識している。
- PMF前の段階でオーバーエンジニアリングにならない程度にスケーラビリティを考慮できる人を採用できると、最高。
オーバーエンジニアリングにならないように気をつけていること
- 西谷さん
- 事業的なロードマップと照らし合わせてエンジニアリングコストを考慮する。
- トリさん
- めっちゃやりたくなるけど「今じゃねえ」みたいなものがたくさんある。
- 例えば、今やらなきゃいけないのは、セキュリティ。一方で、チーム間でツールや言語を統一したくなるが、過度な標準化は今じゃない。
Lambda vs ECS vs EKS
- 西谷さん
- 基本的には Lambda → コンテナ → EC2 という順番でマッチするか考える。
- ただ、最近はアプリケーションをコンテナに寄せようとしている。小さいコードはLambdaで動かしているが、APIを持つようなアプリケーションを考えたときに、API Gateway + Lambda は必ずしも生産性が高いとは思えない。
- コンテナを使うなら、わざわざLambdaは使わない。
- そもそもコンテナは嫌い。しかし、少なくともアプリケーションの開発を考えると、コンテナを使う方が効率が良い。
- トリさん
- 同じく、 Lambda → ECS on Fargate → EC2 という順番で考える。
- EKSやKubernetesは考えない。
- 「デートするならKubernetes、結婚するならECS」
- アーキテクチャで考えることが多い。常駐してプロセスを走らせる必要があれば、コンテナやECSを使うことが多い。
- Lambdaはイベント駆動アーキテクチャを作るためのコンポーネントだと思っている。
- App Runnerの機能が充実してきたので、Lambda or App Runnerで考えられるようになりつつある。
- 同じく、 Lambda → ECS on Fargate → EC2 という順番で考える。
KubernetesやEKSを選ばないのはなぜ?
- トリさん
- 運用したくないから。
- 西谷さん
- Kubernetesは、事業と関係ないところで考えなきゃいけないことが多すぎる。
モニタリングツールは?
- トリさん
- 入社したときにDatadogとSentryが入っていた。
- 西谷さん
- New RelicとSentryを入れている。
5年後、アプリケーションの開発はどうなってるか?
- 西谷さん
- あんまり変わってないのでは。5年前、10年前と比べて現在、そんなに大きく変わってるように思わない。
- トリさん
- 同じく、そんなに大きく変わるイメージがない。
- それよりも、モニタリングや可観測性のパラダイムは大きく変わるのではないかと思っている。サービスメッシュのためのサイドカーなどは、eBPFやWASMの発達で消え去ってほしい。
スタートアップにおける技術選定や、サーバーレスとコンテナの活用を考える上で参考になる討論でした
討論のセッションについては、本レポートで拾えている箇所はほんの一部であり、また簡単なまとめとなってしまっているため、気になる方はぜひ動画アーカイブをご視聴ください。
スタートアップに移られて事業と向き合いながらエンジニアリングを行なっているお二人の言葉には、いろいろと気付かされるものも多いと思います。
学びになる部分や共感する部分だけでなく、いやそれはどうだろうと意見の異なる部分もあるかと思いますので、技術選定などについて自身の考えを言語化するためのきっかけにもなると思っています。
以上、コンサル部のとばち(@toda_kk)でした。