Kazuki Ono

このプロジェクトは私がプロデューサー/ディレクターに提案し、実行しているプロジェクトです。 ## プロジェクト背景 2017 年の入社から BtoB 向けのサーバ監視サービスのインフラ運用を担当しています。サーバ管理には独自スクリプト、chef、 Ansible、CloudFormation、ElasticSearch(ログ基盤) を利用しており、インフラ運用の面で以下の問題がありました。 - コストがかかる複雑なインフラオペレーションが複数あり、オペレーションミスが発生しやすい運用体制になっている。 - インフラ運用のリポジトリが分散しており、チームのジョインとキャッチアップにかかるコストが大きくなっている。 - セルフヒーリング機能がなく、過負荷時や障害発生時にはオンコールでエンジニアが対応する運用になっている。 - microservices なアーキテクチャになっているが、サービス間のつながりが管理、監視できていない。 ## プロジェクト目的 コンテナオーケストレーションとしてデファクトスタンダードである Kubernetes を検証、利用して以下を目的に掲げています。 - インフラ基盤の再構築を行い、プロジェクト背景にあげた問題の解決を行う。 - BtoB 向けのサーバ監視サービスとして高い SLA を確保する。 - サーバ監視サービスが提供するプロダクトとして Kubernetes の監視、モニタリングをフィードバックする。 ## プロジェクト内容 社内には Kubernetes の運用事例が存在しなかったため、検証段階では複数のクラスタを構築するために AWS のマネージドサービスの EKS、 Kubernetes オペレーションツールの kops, kubespray, kube-aws を利用し、運用検証を行いました。検証段階では無停止アップデート、オ ペレーションの容易さを主軸に CNI、CloudNative ツールなどほかのリソースの連携の多様性に関して評価を行いました。検証段階では特定のマネージドサービス、クラスタオペレーションツールでは最新バージョンが利用できない、kube-apiserver が起動不能で素早く回復できな い状態になる、kube-proxy が生成する iptables の nat テーブルが期待している状態に収束しないことがありました。Kubernetes のソースコード、オペレーションツールのソースコードを読み動作を理解することで問題の原因となっているサーバ設定箇所を特定、解決を行い、Kub ernetes の運用に関わる検証を行いました。 Kubernetes の検証にあたって、最も時間を費やしたことはサーバプロビジョニング、クラスタプロビジョニング、 CI/CD の各コンポーネントが疎結合となり、相互に強く依存することがないよう、各種ミドルウェアを設計したことです。サーバプロビジョニングとクラスタプロビジ ョニングの観点では IaaS に強く依存することがないよう terraform, kubespray をそれぞれのツールとして選択し、CI/CD ではアプリケーションエンジニアが意識するオペレーションに影響がないよう、これまで利用していた Capistorano を置き換える形で skaffold を選択しま した。 プロジェクトの成果物として microservices として分離されているアプリケーションのコンテナ化のリリースを終えています。特にメンテナンス時間やダウンタイムを発生させることなく、移行したためサービスへの影響は発生しておらず、移行後にも問題なく安定して動作してい ます。 現在はメインのアプリケーション、リバースプロキシのログ基盤整備を予定しておりプロジェクトを進行しています。また、自信の持っている Kubernetes クラスタ管理のスキルの引き継ぎとして社内のクラスタ管理者育成を行っています。