🐙渋谷の1000円ランチと、K8s vs ECS という選択
今日は渋谷でランチ。魚金へ。30周年らしい。なんと渋谷ランチで1000円。驚安。カツオとシラス丼、メンチカツ付き。30周年というと1996年創業ということになる。
私は今年で29周年。ということは来年で30周年。何を驚安しようか。安売りはしたくない。そもそも売れるものも少ない。時間くらいだろうか。思いつかない。商売って難しい。親に感謝。親がいないが。ガッハッハ。
商売のプラットフォームをどう選ぶか、という話はエンジニアリングにも通じる。
魚金は渋谷のビルを借りて商売している。自分でビルを建てたわけじゃない。そのぶん内装や仕入れや接客に集中できる。一方、ビルのオーナーに家賃を払い続ける必要があるし、ビルが取り壊されたら移転しなければならない。それでも30年続いた。プラットフォームの選択は、それくらい根本的な意思決定だ。
コンテナのオーケストレーションも同じ話で、ECSを選ぶかKubernetesを選ぶかは、「どのビルを借りるか・自分で建てるか」に近い感覚がある。
ECSとKubernetesを一言で言うと
ECS（Fargate）はホテルに泊まるようなものだ。チェックインして荷物を置けば終わり。空調が壊れても、清掃が必要になっても、自分でやることは何もない。その代わり、内装を好き勝手には変えられない。
EKS（マネージドK8s）は管理会社付きマンション。共用廊下やエレベーターは管理会社が面倒を見てくれる。でも部屋の中は自分で管理する。電球が切れたら自分で替える。
K8sの自前運用は、土地を買って家を建てること。設計の自由度は最大。でも配管から固定資産税まで全部自分だ。
魚金で言えば、ECS Fargateは完全フランチャイズの居抜き物件に近い。K8s自前運用は、土地から仕込む本格開業だ。どちらが正解というわけではなく、チームの規模と覚悟次第で決まる。
何が実際に違うのか
一番の違いはControl Plane（頭脳部分）を誰が管理するかだ。
ECSのControl PlaneはAWSが完全に管理していて、費用もかからない。ユーザーは「何台のコンテナを・どのイメージで・どのネットワークで動かすか」を宣言するだけで、実際にスケジューリングするのはAWSだ。
K8s（EKS）だと、Control Planeはマネージドといえど1クラスターあたり月7,000円ほどかかる。そのうえNodeの管理、マニフェストの管理、CertificateのローテーションといったK8s固有の運用が発生する。
デプロイの単位も考え方が違う。ECSは「Task」という単位でコンテナをまとめ、「Service」で何台動かすか・どう更新するかを管理する。K8sは「Pod」「Deployment」「Service」「Ingress」と概念が分かれており、それぞれを組み合わせて使う。最初は煩雑に感じるが、これが後でNetworkPolicyやService Meshといった高度な制御を可能にする。
ネットワークも構造が違う。 ECSのFargateは各TaskがそのままVPCのIPアドレスを持つ。Security GroupをTask単位で設定でき、VPC Flow Logsでもそのまま追跡できる。直感的だ。K8sは独自のネットワーク空間を持ち、NodeのIPとPodのIPが別の空間になる。理解するまでは「なんで通信できないんだ」となりやすい。
どっちを選べばいいのか
自分がよく使う判断軸はこうだ。
ECS Fargateを選ぶとき： チームがK8sの経験をあまり持っていない。サービス数が10以下。AWSのエコシステム（ALB・RDS・IAM・CloudWatch）と深く統合したい。とにかく運用コストを下げたい。このどれかに当てはまるなら、ECS Fargateが正直なところ強い。
K8sを選ぶとき： 複雑なデプロイ戦略（カナリアリリース・Blue/Green）が必要。サービスが50を超えてきてNetworkPolicyやService Meshが活きてくる規模感になってきた。マルチクラウドやオンプレとの混在がある。チームにK8sの経験者がいる。こういうときはK8sの豊富なエコシステムが力を発揮する。
よく「K8sにすれば移植性が高い」と言われるが、それは半分正しい。StorageClass・Ingress Controller・LoadBalancerの実装はクラウドごとに異なるので、完全な移植には追加コストがかかる。「移植性のためにK8sを選んだが、結局EKS固有の機能を使いまくっている」という現場をいくつか見てきた。
コンテナ運用の共通の落とし穴
どちらを選んでも同じ罠に落ちることがある。
リソース制限を設定しない。 CPUとメモリの上限を設定しないと、あるコンテナが暴走して隣のサービスを道連れにする。K8sならrequests/limits、ECSならcpu/memoryを必ず設定する。
ヘルスチェックを甘く設定する。 起動が遅いアプリケーションが「不健全」と誤判定され、無限再起動のループに入ることがある。起動猶予時間（K8sならinitialDelaySeconds、ECSならstartPeriod）を実態に合わせて設定しておく。
環境変数にシークレットを直書きする。 Dockerfileや設定ファイルにDBのパスワードを書いてしまう。K8sのSecretリソースやAWS Secrets Managerを使う習慣をつけたい。
ログをファイルに書き出す。 コンテナが停止するとファイルも消える。標準出力・標準エラーに書いて、ログドライバーやFluentdで収集する構成にする。
魚金は1000円でカツオとシラス丼とメンチカツを出せる。あの価格で30年続けるには、仕入れ・オペレーション・立地という選択の積み重ねがあるはずだ。エンジニアリングも同じで、K8sかECSかという選択は、その後の運用コスト・柔軟性・チームの認知負荷に長く影響する。ランチのあと、そんなことを考えながら渋谷を後にした。
来年の30周年、何か考えよう。まだ思いつかないが。