Amazon EKSの採用
freeeではAmazon EKSをシングルテナント構成（1サービスにつき1クラスタを利用する構成）で使っています。
前述したとおり、もともとはkube-awsを利用し、Kubernetes on EC2の構成で運用していたのですが、Amazon EKSと比べマスターコンポーネントを自前で運用しなければなりませんでした。なので、Amazon EKSが利用できるようになった時点で移行を決めていました。この移行によって、マスターコンポーネントの運用が不要になりました。
また、Amason EKSだけでなくElastic Load Balancing、Amazon RDS、Amazon ElastiCacheなどのマネージドサービスをフル活用し、できるだけSREの負荷を減らしてクラスタの運用を行えています。もちろん本番環境にも利用していて、マイクロサービスを含め10以上のサービスがAmazon EKSで稼働しています。
最近ではfreeeの根幹をなすような非常に重要度の高いサービスもKubernetesで運用されていますし、今後も比較的大きなサービスをKubernetesに移行していく予定です。
なぜ進化し続けられるのか
なぜfreeeのアーキテクチャは進化を続けられるのか。その理由は3つあります。まず、マネージドサービスであるAmazon EKSがクラスタ運用の負担を大幅に軽減したことによって、SREはセキュリティや耐障害性を考慮し、いかにdeveloper friendlyにできるかだけを考え続けられるということです。
AWS Identity and Access Management（IAM）やElastic Load Balancing、Amazon RDSといったAWSのマネージドサービスは、そのまま利用し続けることができ、今まで培ってきたプラクティスを応用できるのも非常にありがたいことでした。
2点目の理由にはfreeeの文化が寄与しています。freeeには「失敗して攻めよ」という文化が根付いており、新しいことに挑戦したり良いと思ったことを即座に取り入れたりする文化があります。開発者に少し負担がかかっても、（それがfreeeのためになると思って）開発しているサービスをKubernetes上で運用することに挑戦したいと発言した開発者がいました。そのおかげで、Kubernetesへの導入もSREと開発者が一丸となって進められることができ、SREが構築した新しい基盤自体のアップデートにも開発者が意欲的に協力してくれました。
3点目の理由は、開発者からのKubernetes基盤へのフィードバックをもとに、SREが継続的に基盤の改善を図れることです。SREが、Kubernetes基盤を使う側からほしい機能や改善要望点を聞き出し、個々の要望に一つずつ対応し解決するプロセスが確立しています。
まとめ
freeeでは、1年半ほど前からKubernetes上でサービスが本番稼働しています。さらにその導入当時と比べて基盤自体が大きく成長しています。それでもまだまだ開発者にとってKubernetesクラスタの運用やアプリのデプロイは煩雑であり、キャッチアップも大変です。コンテナやKubernetesのエコシステムの利益を最大限享受しつつ、開発にもっと集中できるような最高のKubernetes基盤を作るため、これからも爆速で進化させていきたいと考えています。
AWSソリューションアーキテクトより一言
freeeのAWSサービス活用のここがポイント！
「なぜ進化し続けられるのか」で述べられているfreeeのエンジニアリング文化は、健全にエンジニア組織を運営するにあたって大変示唆に富むところであるように思います。マネージドサービス、Amazon EKSを利用することで運用負荷を軽減し、リスクをとって挑戦することが促進され、開発者とSREの間でフィードバックループが回っているわけですね。Kubernetesの運用が開発速度の向上や重要なサービスの提供といった価値そのものにつながっている、さすがの事例だと思います。今後の情報発信も見逃せませんね。
