こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
freee株式会社のエンジニアによる、エンジニアのためのイベントです！
freeeで利用している技術、組織、エンジニアの生態の紹介を皆様に知っていただけるような内容を定期的に配信します。
freeeでの自由度と裁量権の高い独自の開発文化を支えるエンジニア達がどういう想いや熱意でfreeeを開発しているのかに興味を持っていただければ幸いです。 ちょっと短めの時間で、参加しやすい・聞きやすい内容を目指します。
普段はなかなか参加できない…という方も、ラジオを聴く感覚で、ぜひご参加ください！ freeeはクラウド会計・人事労務ソフトを5年以上開発を続けており、技術的な成果や経験を広く公開させていただきます。会計や人事労務などのセキュアなドメインならではの技術的工夫や苦労を、世の中にシェアし役に立てたいという想いから定期的にイベントを開催しています。
多くの方にご参加頂き、経験やノウハウの共有や交換のネットワークを広げるきっかけになれれば幸いです。
会の様子
ChatworkのEKSの運用と課題
Chatworkさんでは、Node数でいうと40-140, Pod数は500-2000くらいになっているということでした。構成的にはEKS on EC2で、80%以上spotインスタンスを活用しており、7クラスタ*1ほどを環境別に動かしているということでした。
また、運用としては、CI/CD面はArgoCDでマニュフェスト管理をして、バージョンアップは基本的にBlue/Greenで毎回実施するようにしているそうです。
課題に感じていることとしては、セキュリティ面でネットワーク制御*2とk8sのコンテナチェックがゆるく悪意があるコンテナが動けてしまう部分が挙げられるということで、CiliumやGatekeeperの導入を実施or検討しているそうです。
また、クラスタ構築は簡単にできるものの、手動構築になってしまっているため、CrossplaneやTerraformを活用してEKSでEKSを作るような世界観をイメージしているそうでした。
freeeのEKSの運用と課題
freeeさんでは、EKS on EC2で構成していて、テナントはシングルテナントを採用しているということでした。ツールとしては、CI/CD周りはGithub Actions, CircleCI, ArgoCDを使い、Manifest TemplatingはHelm, Helmfileを使い、LoggngはFluentdやDatadog-loggingを使っているということでした。
また、EKSクラスタのアップグレードはBlue/Greenで実施をしているということで、
- ArgoCDのApplicationSetでクラスタ入れ替えとともに自動でアプリケーションが作成・削除されるようにしている
- plutoでapiVersionのdeprecatedやremovedを検知
- tentezでALBのListener Ruleの向き先を段階的にSwitch, Rollback
- クラスタ構築した後に疎通確認をするOneshotJobの活用
- Terraform Moduleの活用
を工夫しているそうでした。
課題としては、クラスターアップグレードの工数が大きい、連鎖障害問題、AWS Quota問題、認証認可問題があるということです。
フリートーク
EKSを採用した背景
freeeさんでは、ECSはAWSが独自で作っているのに対してEKSを使ったほうがAWS以外の様々な会社のOSSを活用できる見込みがあったことが理由で、EKSの採用に至ったということでした。
Chatworkさんも、エコシステムに未来を感じていたのと、ECSはEKSを採用した当時拡張性が低かったことがEKSの採用理由になったということです。*3
プロダクト特性によって出てくる違い
Chatworkさんでは、国内利用に限定されていることとピーク時間帯がわかりやすいというプロダクト特性を利用して、コスト削減やスケールアップ/ダウンの速度調整を実現させているということでした。
freeeさんでは、ピークこそある程度あるものの使われどきは割と満遍なくばらついている&確定申告期間の終了直前の負荷が高いということで、負荷に応じた工夫をしているということでした。
最初のArgoCDのクラスタにどうやってArgoCDを入れているのか(Chatwork->freeeへの質問)
最初は、helmfile templateしてkubectl applyしているので手動でやっているということでした。
開発チームとコミュニケーションを取るときのインターフェースは？(freee->Chatworkへの質問)
チャット(Chatwork)だということでした笑
クラスタアップグレードは開発チームが担当しているのかSREが担当しているのか？(Chatwork->freeeへの質問)
最近は、クラスタ作成と切り替えは開発チームがすべてできるようにしているということで、周辺ツールや手順書を整備しているそうです。(PRレビューの一部のみSREが担当している)
インフラ知識がサイロ化しないようにする工夫(freee->Chatworkへの質問)
Chatworkさんでも同じ課題感を抱いているそうです。
具体的には、開発チームのモチベーションに左右されてしまうのに困っているということで、SREに任せきりになってしまうチームと自発的にがんがんSREに提案してくるチームがいて悩んでいるそうです。
Q&A
EKS on Fargateを使っていない理由
Chatworkさんでは、制約が多いのとパフォーマンスが全然出ないことが理由でFargateを使用していないということでした。(1個だけパフォーマンス要件が全然ないやつのみFargateを利用しているそうでうす)
freeeさんも基本的にはChatworkさんと一緒で、デーモンセットが使えないことやセキュリティ要件の都合上Fargateを使っていないということでした。
クラスタアップグレードに手間がかかっているということだが技術選定自体を見直す必要があるか？
Chatworkさんでは、eksctlで作っているのでまずはTerraformにしたいということでした。その上で、Terraform自体をk8sで動かしてKaaS的にすることで開発者自身がクラスタのカスタムリソースを定義すればよいという話も出ていました。(Crossplaneを採用したい)
freeeさんでは、資産移動のコストなどを考えるとEKSをやめてECSに移ることはあまり考えていないということでした。(ただしECSでやってくれればいいのにと個人的に思うことはあるそうです)
クラスタアップグレードに3−4人日というのは思ったより少ないのだが、これはチームが組んでいるクラスタあたりの単位か？
これは両社さんともYesだということでした。
オートスケールで使っているものは？
両社さんとも、クラスターオートスケーラーとHPAを採用しているそうでした。(VPAはアグレッシブに使われると怖い)
EKSを使ったことで一番大きかったビジネスインパクトは？
Chatworkさんでは、リリース速度やロールバック速度が圧倒的に上がったのが一番大きいということでした。
freeeさんでも、デプロイで怒られる頻度が大幅に減ったのと、バグを仕込んでもすぐに戻せるというメリットが大きかったということでした。
クラスタAPIを技術選定する可能性はあるか？
Chatworkさんでは、EKSに関して言えばTerraformがあればあまり恩恵を受けられないのでないかな、ということでした。
freeeさんでは、より自動化を目指すという文脈で既にPJの進行がされているといことでした。
マルチテナントシングルクラスタとシングルテナントマルチクラスタはどちらの方が運用しやすいのか？
Chatworkさんでは、マルチテナントシングルクラスタしかやっていないという前提で、クラスタ数を作るコスト的にクラスタ数を減らす方向の方がいいと思っているということでした。(ただしクラスタ数を作るコストが下がればシングルテナントマルチクラスタの方がよい)
freeeさんでは、クラスタ数を作るコストには多少目をつぶって、どこかのクラスタが落ちた際に他のクラスタに影響が出ないことを最重要視しているからこそシングルテナントマルチクラスタを採用しているということでした。
会全体を通した感想
具体的な構成の話を聞いた上で、技術の詳細に踏み込んだパネルディスカッションやQ&Aが聞けて非常によかったです。
お互いのプロダクト特性ごとにどのような構成の違いや運用方針の違いが出ているのか？という話も幾つか聞けたのも非常に面白かったです。
