Kubernetesの自前運用は難しい？　はてなの撤退事例：「専任エンジニアが2人以上欲しい」

はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。なぜ、Kubernetesの運用を諦めて撤退を選んだのか。はてなのMackerelチームでSREを務める今井隼人氏が語った。

　コンテナ型仮想化技術を活用したアプリケーションの管理（オーケストレーション）ツール「Kubernetes」が注目を集めている。その背景の一端にあるのが、アプリケーションをコンテナ化し、マネージドKubernetesサービスで実行することによるメリットの享受と、運用負荷の軽減だ。

参考記事：「Kubernetes」とは何か――コンテナ型仮想化の本番利用に向けた課題

参考記事：「Kubernetesで運用する」その前に　Kubernetesを本番環境で利用する際のポイント

　そんな中、「Kubernetesクラスタを自前で構築して運用していたが、撤退を選択した」という話が、2019年8月に開かれた「Kubernetes Meetup Tokyo #22」で公開された。なぜ、Kubernetesの運用を諦めて撤退を選択したのか。言い換えれば、なぜ、導入後に撤退できたのかを、はてなのMackerelチームでSREを務める今井隼人氏が語った。

Kubernetes導入の背景

　はてなでは、サーバ運用／サーバ監視サービス「Mackerel」を「Amazon Elastic Compute Cloud」（以後、EC2）のVM（仮想マシン）で提供している。コンテナ向けの監視機能などを提供する中で、顧客に対してはシステム運用におけるコンテナ監視のプラクティスを提供したり、社内では複雑なサーバ環境のプロビジョニング（準備）／管理からの脱却を目指したりするため、KubernetesクラスタをEC2に自前で構築、運用することにした。

はてな サービス・システム開発本部 Mackerelチーム SRE 今井隼人氏

　「EC2での自前構築を選んだのは、構築当時、Amazon Elastic Container Service for Kubernetes（Amazon EKS）の東京リージョンがなかったためだ。Amazon Virtual Private Cloud（Amazon VPC）を用いて、Google Kubernetes Engine（GKE）で構築することも検討したが、AWS以外で構築したときに起きると想定されたネットワークのオーバーヘッドが気になった。そのため、EC2でKubernetesクラスタを自前構築することにした」

　構築に当たっては、EC2のVM環境からKubernetesクラスタに一気通貫で切り替えるのは難しいと判断。サービスに対するインパクトが小さく済むよう、Mackerelサイトのメトリクスを収集するクローラー機能に絞り、構築、運用を始めることにした。

　運用後に問題が起きたとしてもサービスを継続できるようにするため、KubernetesのNodePort機能を用いて、EC2のVM環境に構築されたクローラーと、Kubernetesで構築されたクローラーにトラフィックを分散する並行稼働環境を構築した。

MackerelのアーキテクチャとKubernetesの導入範囲（左、右）

　今井氏は、Kubernetesクラスタで運用するために行ったことを説明した。

　「まず、アプリケーションのDockerイメージを準備してアプリケーションをコンテナ化。開発チームに影響を与えないように既存のCI（継続的インテグレーション）／CD（継続的デリバリー）の仕組みを維持しつつ、新たにSkaffoldとkustomizeを導入してCI／CDを実現した。Kubernetesクラスタ構築には構築手順が分かりやすいKubesprayを採用し、インスタンスの作成はTerraformで補う形を採用した」

追従困難なエコシステム、アップデートの失敗、運用メンバーの異動／退職……