Next Door

隣のプロダクトチームがEKSで苦しんでいる。

Kubernetesのバージョンアップが来るたびに、彼らの顔が曇る。EKSのKubernetesサポートウィンドウはおよそ14ヶ月。バージョンが切れる前にクラスタをアップグレードしなければならない。ノードグループの入れ替え、非推奨APIの洗い出し、Helmチャートの互換性確認、Istioのバージョン追従。本番のワークロードを止めずにこれをやる。リリースとは関係のない、純粋なインフラ維持のためだけの作業だ。

EKSとECSの分岐点は、責務をどこに置くかだ。Kubernetesを選ぶということは、オーケストレーションのレイヤーを自分たちで管理すると宣言することだ。ベンダーロックインを避け、マルチクラウドの可能性を残し、エコシステムの柔軟性を手に入れる。その代償がバージョン追従であり、サービスメッシュの運用であり、シークレット管理の設計だ。

ECSはその逆だ。AWSのエコシステムに乗ると決めてしまえば、サービスメッシュもシークレット管理もAWSが面倒を見る。クラスタのバージョン管理という概念そのものがない。

横着で怠惰なわたしはECSを選んだ。自由と天秤にかけたが、怠惰には勝てなかった。

ただし、高い。オンプレも見てきた目には、本当に高い。請求書がわたし宛なら、さっさと逃げ出しただろう。だが日本の採用市場において、優秀なインフラエンジニアはベンガルトラより希少だ。採用コストと、採用がガチャであるという現実を勘案すれば、AWSのコストのほうがまだ未来が見通せる。

結局、何を管理し何を委ねるかの線引きだ。Kubernetesの自由が必要な規模とフェーズなのか、AWSに寄せて運用コストを下げるべきフェーズなのか。正解は組織の数だけある。

隣のチームからECSについて聞かれることがある。だが移行は想像以上の困難を伴う。不幸な事故とわたしの仕事を増やさないために、聞かれたことだけ答えている。

隣のチームを見ていると、自由の代償について考える。うちはうちで、AWSという檻の中で快適に暮らしている。組織という檻の中にすでにいる場合は、なおさらだ。