学生がKubernetesで本番運用始めた

こんにちは、戸ヶ里 健晟 といいます！大学院生をしながら株式会社OPTIMIND でインフラエンジニアをしています。

ついに、Kubernetesを本番環境で運用始めました！
まず構築したインフラの構造を（既に運用している人や現在構築中の人向けに）、次に本番運用にいたるまでの波乱万丈のストーリーを（導入検討中の人向けに）紹介します。

パイプライン

今回のインフラ構造を実現するにあたり作成したデプロイまでのパイプラインを紹介します。

1. 開発者がアプリコードをGithubにPushする
2. PushをトリガーにしてCloudBuildが実行される
3. CloudBuildによって
　1) GCR（Container Registry）にコンテナイメージがPushされる
　2) Github（インフラコード）のバージョンやイメージが変更される
4. ArgoCDによってGithubの内容でGKEにデプロイされる

フローチャート

技術スタック

今回のインフラ構造を実現するにあたり使用している主要なツールを紹介します。

Github：言わずと知れたコード管理ツール。エンジニアなら必須と言ってもいいのでは。弊社では、それぞれアプリケーションコードとインフラコードはリポジトリを分けて管理している。

Docker：こちらも言わずと知れたコンテナツール。これからはコンテナの時代でしょう！（ただし、全てがコンテナに移行したり、マイクロサービス化するとは思っていません。）

Google Kubernetes Engine：Googleが提供しているKubernetesマネージドサービス。マスターノードの管理をしてくれるのですごく楽。Istio on GKEも導入してトラフィックの切り替えなどに使っています。

Terraform：インフラストラクチャ定義ツール。弊社ではGKEのリソース（性能）をコード化して管理している。Iac（Infrastructure as code）のためには不可欠。環境のコピーや、マシンリソース変更にもすごく便利。

CloudBuild：GCPのサービスの一つ。Githubのアクションをトリガーにビルドを実行してくれる。コンテナイメージをGCR（Google Cntainer Registry）に簡単にプッシュできる点も良い。

ArgoCD：Githubのインフラコードを読み取ってGKEにデプロイしてくれるツール。HelmやKustomizeにも対応している。弊社ではインフラコードはKustomizeを使っている。

Datadog：死活監視、ログの回収はもちろん、Pod（マシン）のリソース分析やWorker Nodeの管理もできる。自分で欲しい情報をカスタマイズして監視できるのが良い。まだまだ導入したばかりで使いこなせてないがめちゃくちゃ便利。Slack連携ももちろん可能。

Auth0：Authentication（認証）ツール。弊社では各チームのアプリケーションがインターネットを介したAPIで繋がっている。なので、認証をつけることでセキュリティを強化している。

弊社では開発・検証・本番の３つの環境を用意しています（実際はもう少し複雑でそこに至るまでの紆余曲折も別記事に書きます）

開発環境：アプリ開発者がインフラのことを何も考えずに自由に使える環境（これとは別にインフラ部門が自由に使える環境もある）　　　　　　　　検証環境：他チームと繋いだり、本番前のテストをするための環境　　　　本番環境：お客さんに使っていただく環境

環境・役割

参考にした資料

Kubernetes完全ガイド　青山真也著

日本のKubernetes界、第一人者の一人である青山さん（私感）（@amsy810）が書かれた本です。仕事ができるだけじゃなくかっこよくて憧れです。いつか一緒に仕事できるようにこれからも頑張ろうと思います。

Kubernetes 公式
Kubernetesの公式ドキュメントです。分かりやすいし最新の情報が載っているのでおすすめです。

Google Cloud Platform
今回はGCPのサービスをたくさん使ったのでたくさん読みました。こちらも分かりやすくておすすめです。また、スタートアップ向けに支援プログラムもあるのでスタートアップの方は是非。

ここからは本番運用にいたるまでの波乱万丈や七転八倒を紹介します。

ストーリー

ここからは本番運用にいたるまでの波乱万丈や七転八倒を紹介します。

登場人物
とがり　：私、大学院生、インターン生
guo君 　：ソフトウェアエンジニア、共同創業者
ヤマさん：ベテランエンジニア

1. 導入
とがり　：「入社しました！よろしくお願いします！」
ーーーーーーーーーーーーーーーーーーーー
guo君 　：「大変だ、人手が足りない」
とがり　：「手伝います、何をしますか？」
guo君 　：「このコンテナをKubernetesで管理したい」
とがり　：「... What is Kubernetes ?」

ベンチャーあるあるの人手足りない問題です。Dockerは少し触ったことありましたが、Kubernetesは未経験でした。”誰もできなくてもやるしかない”ということで、その日から上記の公式ドキュメントや書籍を読んで作ってみて失敗してまたトライしての繰り返しの毎日でした。Pod... Deployment... Service... Ingress... なるほど、完全に理解した。Kubernetesは難しいですがそれよりも、（周辺サービスも含めた）より良いインフラ構造の設計に対する情報が少ないこと、コミュニティもそれほど活発ではなく（名古屋だから？）情報交換がしにくいことが大変でした。なので、今後は名古屋でコミュニティ活動を精力的に行っていこうと思いますので何卒よろしくお願いします。イベント告知などTwitterで行うと思います。(Twitter : @KenseiTogari)

話が変わりますが、何故Kubernetesの導入をしたのか話します。弊社では元々FaaS（AWS lambda）を使っていました。しかし、サービスの拡大とともにリソースや同時実行数の制約を受けるようになりました。また地図ファイルという莫大なサイズのファイルをマウントしてあげる必要が出てきました。そこでFaaSでは実現できなくなりました。その時にちょうどKubernetesがデファクトスタンダードになっており、周辺サービスの発展や人材採用において魅力的な会社と感じていただくというメリットを考慮して選択しました。

2. 環境差分問題
とがり　：「環境って何がありますか？」
guo君 　：「開発環境(≒ローカル環境)と本番環境があるよ」
とがり　：「開発からそのまま本番に移すのは怖いので
　　　　　　検証環境を導入しましょう」
とがり　：「作ってみたが開発環境→検証環境、
　　　　　　検証環境→本番環境に移行するの大変だ」
guo君 　：「全てコード化することが必要ですね」

Infrastructure as code やImmutable Infrastructureの重要性を実感しました。

※Infrastructure as code：Githubのコード＝インフラ構造
※Immutable Infrastructure：インフラ構造を変更しない
　　　　　　　　　　　　　変更したいときは再構築する

3. 新入社員
新しくヤマさんが入ってくれました
ーーーーーーーーーーーーーーーーーーーー
ヤマさん：「よろしくお願いします」
ーーーーーーーーーーーーーーーーーーーー
ヤマさんはベテランエンジニアで知識と経験がすごいにも関わらず、最近の技術も分かるという一番欲しかった人材でした。入社１ヶ月後には強力な戦力になっていて驚きです。
順調に開発は進み、完成が近づいてきました。

4. ログ監視問題
とがり　：「よし、できた！まずは社内のビズ部門に使ってもらおう」
ーーーーーーーーーーーーーーーーーーーー
ビズ部門：「全然レスポンス帰って来ねーぞ！」
とがり　：「はい！調査します」
とがり　：「このリクエスト処理したのどのPodだ...？
　　　　　　どこでエラーでその結果どうなってるんだ...？
　　　　　　メモリオーバーでPodがキルされててログ回収できない...」
とがり　：「あ”あ”あ”あ”、と”う”す”れ”は”い”い”ん”た”」
ヤマさん：「落ち着いてください、DataDogという監視ツールを
　　　　　　導入しましょう、導入したのがこちらです」
とがり　：「おお、これはすごい！便利だ」

ログの収集や監視については「kubernetes 監視」などで調べていただくとわかるようにKubernetes活用において難しい点・課題点の一つです。さらに弊社プロダクトでは地図からルートを探索するという仕様上、1リクエストを処理するのに必要リソースが数MBメモリから20GBメモリまで大幅に変動します。そのため各Podのリソース設定・管理には大変苦労しました。ここに関してはアプリケーションエンジニア（guo君）と議論をしてアプリ側にも変更を加えなんとか運用可能レベルに達することができました。

次回、感動のフィナーレ

5. 本番運用開始

ログ問題もとりあえず解決ました。

そして、ついに私が入社してから取り組んできたプロジェクトが先日リリースされました！！！！！！！

本番環境で少しずつ稼働しており、これから完全に移行して行きます。

今のところ大きな障害は発生しておりません。

しかし、いずれ障害は発生するものです。

障害の発生をワクワクしながら待ちたいと思います！

最後までご覧いただきありがとうございます！

今後の展望

・より美しいCI/CDパイプラインの構築
・Worker Nodeの管理から解放
・DevOps文化の浸透
・CKA/CKADの取得

最後に

是非、意見・コメントください！よろしくお願いいたします！