ぼくたちのかんがえるさいきょうの Kubernetes 環境を作ろう

SRE チームリーダーの沼田です。この記事ではみんな大好き Kubernetes の話をしますが、技術的な内容というよりは、グロービスの SRE は如何に Kubernetes と付き合ってきたかというエモい感じの話にフォーカスします。

Kubernetes の難しさ

我々 SRE チームは2020年初頭から、 Amazon EKS を使った Kubernetes (k8s) 導入を推し進めています。

k8s は昨今、国内の SRE が取り扱う OSS としては極めて一般的なものになっていますが、一方ではたびたび「不要論」が話題になるツールでもあります。その理由は様々挙げられると思いますが、その1つに「急速に発展するエコシステムの複雑さ」があるかと思います。

k8s はあくまでリコンサイルループを通じて、コンテナを自律的に起動してくれるだけのプラットフォームに過ぎず、監視、CI/CD、秘密情報管理、ログ転送、バッチ処理等々、周辺的な処理についてはそれぞれツールを選択して導入する必要があります。これら k8s を取り巻くツールたちは CNCF Cloud Native Interactive Landscape に掲載されているような、ある種のエコシステムを成していますが、これを見るだけでも、非常に多種多様な OSS が存在することがわかります。これらの動向を常に追いながら、適切なものを選んで学んでいくプロセスは、必ずしも容易ではありません。

エコシステム以外の観点でも、意思決定や学習コストをかけなくてはならない箇所はいくつも存在します。EKS の場合は k8s manifests と Terraform の責任境界を決めなくてはなりませんし、 Namespace はどのような単位で使うのか、 manifest の label や annotation には何を書くのか、短時間のジョブは AWS Lambda を使うのか cronjob を使うのかなどなど、論点は数多くあります。「k8s を使う」とは、多くの場合、文字通り k8s だけを使う意味ではありません。より正確には「k8s の上で（あるいは k8s と共に）何を使うか？」という問いに答えていく過程のように感じています。

k8s 懐疑論から一転、導入へ

そういった「問い」にどう向き合ってきたのかと言えば、特別な何かがあるわけではなく、ひたすらに対話を重ねてきました。

始まりまで遡ると、実は私自身、当初 k8s の必要性には懐疑的でした。また他のメンバーからも、 EKS ではなく ECS で十分ではないかという意見が出ていました。チームでは従来、 Amazon EC2 の AMI を Codebuild 上で動かした Ansible + Packer で作成することによるインフラ管理を行っており、つまるところ AWS のエコシステムにべったりの状態でした。その状態からスムーズに移行可能なコンテナプラットフォームとしては、 EKS より ECS のほうが適切ではないか、という思いがあったのです。

2019年の暮れ、この問題に関しては実に1か月以上議論が続き、日常的に slack で話されることもありましたし、時間を取って対面の MTG で検討することもありました。また、小さなプロダクトで実際に ECS、EKS をそれぞれ試用もしました。そのような長いプロセスを経て、最終的にメンバー全員の合意によって k8s (EKS) が選ばれました。

……と、何やら高尚な議論があったかのように書いていますが（実際「無かった」とは言いませんが）、 k8s 導入を決めたその日の slack にはこんなことが書いてあったりします。

意外に軽いんですが、これが結構重要だったんじゃないかなと思っています。

対話の場を持ち続ける

k8s 導入決定後も、冒頭に書いたようなエコシステムと向き合うため、決めなくてはならないことは様々ありました。

そこで EKS 導入決定後の年明けから「もくもく会」と呼ばれる時間を週に1回、定期的に取るようになりました。実際には話し合いの時間で「黙々」していたことは一度もなかったと思います。なんでこの名前になったのかは正直わかりませんが、細かいところは置いておきましょう。

これは2020年1月頃の「もくもく会」のログです。当初は決めなくてはならないことが多岐に渡ったので、このように話すべき内容を一度書き出し、毎週1つずつテーマへ当たっていきました。一気に決めず、1週間に1つずつ決めていったのは、その間に十分な調査や検証・検討の時間を設けるためです。最初に書き出した内容がすべて決まるまで、たっぷり 1Q を費やしました。

その後もこの「もくもく会」の MTG 枠は生きており、実際の開発を進める中で出てきた新たな課題を話したり、わからない部分をモブプロしたりなど、自由に使える相談の時間としています。もちろん、普段から slack で相談などは都度飛び交いますし、リモートワークがデフォルトとなった最近では、突発的にモブプロや「作業中継」をすることもあります。しかし、 slack は常に全員が見ているとも限りません。この知見は全員に共有するべきだろう、この話題は全員で決めるべきだろうという内容については、なるべく「もくもく会」を活用する文化になっています。

ぼくたちのかんがえるさいきょう

先ほどの k8s 導入が決まったときの言葉に「楽しそうだから」「とりあえずやってみよう」というものがありました。これが結構重要だったんじゃないか、と書きましたが、それはその後のどの意思決定においても同じことです。

当然ながら「楽しそう」「とにかくやってみよう」だけを判断理由にすることはリスキーです。それぞれの意思決定においては、対象 OSS の設計思想を読み解いたり、実際に使ってみたり、他社の導入事例をブログで読んでみたり、多くのプロセスを重ねています。が、その上で大事にしたいのは楽しそうと思えるかどうか、言い換えれば、その意思決定を下したとして、モチベーションが湧くかどうかという点です。

具体例を挙げると、 EKS を使う上ではしばしば活用される公式 CLI である eksctl については、導入を見送っています。確かに魅力的なツールではあり、 Terraform で EKS cluster を建てるより簡単に扱うことができます。しかし、非常に多くのリソースを密結合に管理することになってしまう点や、宣言的かつ継続的なインフラ管理が難しい点 terraform-provider-eksctl の登場により、現在では少し状況が変化しています）がチームのポリシーに合致しなかったので、採用は見送りました。

どれだけ優れたツールであっても、それを実際に使うメンバーが乗り気じゃなければ宝の持ち腐れになってしまいます。世間的に最強と言われるようなものを使いたいのではなく、いわば「ぼくたちのかんがえるさいきょうの k8s 環境」を作りたいのです。選択肢の多さ、学習コストの高さは k8s の難しさでもあるかもしれませんが、一方で自分たちのニーズにマッチした環境を、対話を重ねながらどこまでも追求できるということでもあり、それはエンジニアとして大きな魅力であり、醍醐味だと思っています。

また「やってみよう」も非常に重要で、ある程度議論が煮詰まったなら、とりあえずやってみようか、という結論になり、その場で画面共有して「やってみる」こともよくあります。リソースの削除や、その履歴管理が容易な k8s においては、開発環境でまず試してみて、どうも上手くいかないようならすぐに revert すればいい、ぐらいに考えておくのがちょうどいいのかもしれません。

Cloud Native Journey の現状と今後

最後に、 k8s 導入の現状を軽く紹介します。

グロービス SRE チームでは以前、 Ansible + Packer によってインフラ管理を行っていました。この k8s 導入は、従来環境で顕在化した、以下のような問題を解消する目的で始まっています。

- AMI の作成後にインスタンスを入れ替えるため、デプロイに時間がかかる
- 同様にデプロイ失敗時のロールバックにも時間がかかるため、デプロイに心理的負荷がある
- プロダクトごとに分離したサーバーリソースにおいて、計算資源の余剰が多く発生している
- 当初想定よりプロダクトが増加、複雑化しており、 Ansible Playbook も複雑化している

最後の点に関しては「k8s 化」で必ずしも解決できるものではなく、式年遷宮アーキテクチャ の考え方に近いかもしれません。

現在までに新規プロダクトをいくつか k8s 上で実現した他、既存の小さなプロダクトで k8s 移行を完了しており、それらに関しては先の目的をクリアできた手応えを得ています。特にデプロイについては、 Ansible + Packer と比較して所要時間が3分の1になった例もあり、開発チームから期待の声をもらえることが増えてきました。今後は既存のより大きな既存プロダクトを k8s に移行するフェーズに入り、来夏あたりに全プロダクト移行完了を目指しています。 我々 SRE チームとしては、 k8s をプロダクトの土台として定着させることが、弊社サービスをより強固にし、開発をよりスムーズに進めていくための源泉になると信じて取り組んでいます。

一方で、課題も出てきています。学習コストの高さには「もくもく会」の開催などで対処してきましたが、徐々にその壁を感じる機会も多くなってきています。また扱う OSS が増える中で、各メンバーの「専門化」が進んでしまった部分も出ています。知識の共有と平準化を改めて見直すことは、直近取り組むべきことの1つです。

さて、そんな感じでまだまだ Cloud Native Journey の途中にいる状況です。今回具体的には触れなかった「ぼくたちのかんがえたさいきょうの k8s 環境」の詳細については、もしかしたらいつか誰かが書くかもしれません。「どうしても読みたい！」という方、ぜひ @chroju までプレッシャーをかけてください。