Kubernetes はじめました
こんばんわ、新規事業開発部にいる佐藤慧太(ジョン)です。
今回、新規事業開発部でGCPのKubernetes環境 Google Kubernetes Engine (以下GKE) を利用しはじめました。 僕自身GCPを触り始めたのが2年ほど前になり、App Engine(以下GAE)、CloudFunction、CloudRun、Compute Engine(以下GCE)と触ってきて、なぜGKEをはじめたのかについて書きたいと思います。
GKEを使う理由
個人的な考えではありますが以下があります。
- サービスの規模が大きい
- 内部DNSを使ったサービス間の内部通信をしたい
- サービスのオーケストレーションをマネージしたい
新規事業開発部のサーバ開発としては1名で運用していきます。そのため、以前はGAEをメインに使ってアプリケーションを開発してきました。
しかし、新しい事業ではより多いアクセス数を見込んでいます。 その条件で、GAEのserviceを分割したサービスメッシュを作ることよりも、Kubernetesによるサービスメッシュを作ったほうが、後に良いのではないかと考えました。
実際にGAEでのサービスメッシュ(GAE→GAE)のような形で計測してみたところ、GKEでの内部通信よりも遅くなってしまいました。おそらく外部のネットワークを通ってしまうためだと思います。 そのため、GAEでのマイクロサービスでは、こちらのGCPドキュメントの通り、縦割りでのモジュール作成が良いのかと考えます。
また、GAEではソースコードをアップロードしてやることでCloudBuildが実行可能な形にしていきます。そのため、自分たちでJava+Dockerで開発をしていくとなると、GAEを使うことで得られる「手軽さ」という、メリットというのがそもそも享受しにくいという環境があります。
やらない理由
ではなぜ、GKEをはじめから考えていなかったのかというと、Kubernetes自体は知っていましたが、コレを運用するというのはかなりのハードルを感じていたというのがあります。
理由としては、私自身に、インフラ知識が圧倒的に足りていないため、運用コストがかさんでしまうと思っていたためです。
しかし、新規事業開発部で新規アプリケーションを作成していく上で、DockerでbundleしたGCEでのアプリケーション開発やバッチを使ったアプリケーションの開発があり、徐々に力がついてきました。
フルマネージドはいいぞ
そして、インフラの知識について少しずつ付いてきたところで、調査としてGKEを始めたところ、思った以上に簡単にPodの作成や、公開などの操作ができました。そして、Cloud Buildを使うことでのデプロイの自動化もボタンを押していくだけで構築できました。
つまり、GKEというGCPのフルマネージド機能を利用することで一人でも、利用可能なレベルで構築できることがわかってきました。
そのため、社内での開発知見を貯めるという意味でも、GKEを通して、Kubernetesを利用していくメリットは高いと感じました。
とはいえ、聞き慣れない単語が多いのは確かです。私としては以下の書籍をもとに勉強を進めています。
今後の記事では、上記のGKE上の作業について、具体的に書いていきたいと思います。
最後に
GKEを触ってみると思った以上に、簡単にアプリケーションの管理ができることがわかりました。
最近では、更にGKEの運用を簡素にした autopilot がでております。こちらはNodeの管理自体をGCPに任せることでより簡単にサービスの構築ができるようになっております。
こちらをもとに進めて徐々に、複雑化していく要件に応えるために、standard なGKEを利用していくという手段もあるかと思います。
