開発者にも浸透し始めたKubernetes、成り立ちに見る難しさの原因
普段アプリケーションを開発しているエンジニアにとってコンテナは少し遠いインフラの世界の話題に感じられるのではないだろうか。しかし現実は、アプリケーション開発者にとってコンテナは身近に迫ってきている。Java開発者を対象にした調査（2022 Java Developer Productivity Report）では、使用しているプラットフォームは上位からDocker（41％）、Kubernetes（26％）、VMware（16％）。上位2つがコンテナで、半数以上を占めている。
さらにVMwareの調査（State of Spring 2021）によると、Kubernetes上でコンテナ化したSpringアプリケーションを稼働している組織は前年の44％から57％へと上昇した。インフラエンジニアだけではなくアプリケーション開発者にとっても、もはやKubernetesは無視できない存在になりつつある。
とはいえアプリケーション開発者にとってコンテナは敬遠したいところではないだろうか。基盤がコンテナで運用されることでスケーラブルになったり、環境を素早く柔軟に構築できたりするのはいいが、コンテナ、特にKubernetesに関与せざるをえないとなると腰が引ける。「インフラエンジニアに任せて、アプリケーション開発に専念したい」のが本音ではないだろうか。アプリケーション開発者の内心にKubernetesへの壁や苦手意識らしきものが潜んでいるかのようだ。
その謎をVMware デベロッパーアドボケイト 柳原伸弥氏がするりと解く。なお柳原氏はもともとアプリケーション開発者でJavaやSpringに詳しい。トラディショナルな開発とクラウドネイティブ開発の両方を経験し、アプリケーションのモダナイゼーションの専門家でもある。
まずはコンテナとKubernetesを分けて考えること。柳原氏は「例えばSpringにはフレームワークにコンテナを作り込む機能があります。開発者はコンテナを意識しなくて良いため、コンテナ自体はそう難しくないと感じるのでは」と話す。
「一方でKubernetesに難しさの根源があります」と柳原氏。もともとKubernetesはGoogleの基盤に源流がある。周知の通り、Googleは24時間365日止まることなく、世界中にGmailやGoogle マップなどのサービスを提供している。もはや社会インフラだ。そのサービスを支えるインフラストラクチャとしてGoogleが開発したものがBorgと呼ばれるクラスタマネージャーである。
このBorgを誰でも使えるようにオープンソース化したのがCloud Foundry BOSHとKubernetes。どちらも源流はGoogleのBorgであり、巨大サービス基盤を想定しているため「Google（の基盤）を自分たちで作ろうとするようなものだから、難しくて当然なのです」と柳原氏は断言する。
Kubernetesを通じてダイナミックなインフラを作りあげていくところに醍醐味はあるものの、Googleに匹敵する巨大インフラを必要とする企業はそう多くはない。大規模サービスに関わるインフラエンジニアやSREエンジニアなら話は別だが、アプリケーション開発者がKubernetesを敬遠してしまいがちなのも無理もないというわけだ。
