Kubernetesの自前運用は難しい？はてなの撤退事例 | 米シリコンバレーCloud DevOpsアーキテクト(AWS DevOps Pro & CKAD & CKA)が解説

#AWS #devops #エンジニア #クラウド #docker #kubernetes #terraform #eks #datadog #jenkins

https://atmarkit.itmedia.co.jp/ait/articles/1911/08/news009.html#_ga=2.188258350.709048750.1646114793-940530861.1646114793

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

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

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

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

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

役立ったと思ったら、アルゴリズムのためライクとコメントで引き続き応援してもらえると、私の心が少しホッコリします：）

日本１のCloud DevOpsスクール(受講生１.5万人超) ➡️ https://www.cscareerkaizen.com/