はじめに
この記事は、freee Developers Advent Calendar 2025 の 18日目の記事です。
freee SREの町田です。 社内ではyokiと呼ばれています。
2年前の弊社のアドベントカレンダーであるfreee 基盤チーム Advent Calendar 2023 でfreeeサインのAWSリージョンを移行した話をご紹介しました。 developers.freee.co.jp 上記の記事でも紹介されている通り、freeeサインのインフラはECS (Amazon ECS、以下ECS)ベースで構築されています。 一方でfreeeの標準的なインフラはEKS (Amazon EKS、以下EKS)ベースで構築されています。 本記事では、SREメンバーがfreeeサインのインフラをECSからEKSへ移行(以降、EKS移行) したときのポイントを共有します。
なぜEKS移行が必要だったのか
freeeサインのEKS移行の目的を一言で表すと「freeeサインをSRE全体で支援しやすい仕組みづくりのため」です。
前述した通りfreeeサインはECSベースで構築されており、freeeサイン専属のSREメンバーをアサインしてインフラの開発・運用をしてきました。 EKSベースのインフラを前提とした支援を行っているSREチームにとってfreeeサインのインフラは認知負荷が高いです。 そのため、新たな環境構築やインシデント等で対応が必要となったときにfreeeサイン専属のSREメンバーに頼らざるを得ない状況でした。 また、freeeサインのインフラへの機能追加・変更等を行うときにも個別の対応が必要となり、開発スピードを低下させる要因となっていました。
EKS移行することで、SREメンバーがfreeeの他のプロダクトと同じようにfreeeサインを支援することができるようになることを目指しました。
加えて、こうしてインフラに大きな変更を加えられる機会はあまりないため、プロダクト開発チームがより開発生産性を高められるように整備することも心がけました。
EKS移行でやったこと
社内共通のTerraform moduleによるAWSリソースの作成
freeeサインのECSベースのAWSリソースの多くは独自のTerraform moduleで作成されていました。 EKS環境を構築するにあたっては、社内共通のTerraform moduleを用いて構築していきました。 こうすることで社内共通のTerraform moduleに入った機能追加や修正をmoduleのバージョンアップだけで取り込むことができるようになります。 また、社内共通のTerraform moduleでは対応できていないfreeeサインの要件については、社内共通のTerraform module側を修正することで対応しました。
terraform planの-generate-config-outフラグによるTerraform fileの自動生成
freeeでAWSリソースは社内共通のGitHubリポジトリで管理されていますが、freeeサインのAWSリソースは別のGitHubリポジトリで管理されていました。
freee共通のGitHubリポジトリ上にEKSベースのAWSリソースを作成していくのですが、VPCやDNSホストゾーンなどfreeeサインで作成したAWSリソースを流用したい場合がありました。
このようなときは、 terraform plan に -generate-config-out フラグをつけ実行することでTerraform fileを自動生成してくれる機能を活用しました。
Import - Generating Configuration | Terraform | HashiCorp Developer
この機能によって、独自のTerraform moduleで書かれたTerraform fileを紐解いて、新たにTerraform fileを作成する手間を省くことができました。
トラフィックの切り替え方式
EKS移行は、ECSからEKSへの切り替えをBlue/Green方式で行いました。
トラフィックの切り替え方式は、ALBのListener ruleによる重み付けを利用しました。 DNSベースでの切り替えも選択肢としてはありそうですが、ALBのListener ruleによる切り替えを選択する理由については、以前公開した弊社nkgwのブログ記事で以下の通り説明しています。
DNS ベースの切り替えではクライアント側の DNS Cache や既存のコネクションが原因で、トラフィックが即座に新環境へ切り替わらない問題が発生したことがあります。
このような問題を避けるため、サーバーサイドで確実かつ即座にトラフィックを制御できる ALB Listener Rule 方式を標準と定めました。
freeeサインでも先人の経験を参考に技術的意思決定をしました。
工夫したポイント
AWSアカウント集約
従来のfreeeサインで使っているAWSアカウントは5つあり、それぞれにECSクラスタがありました。 そのままEKS移行をするとEKSクラスタを5つ作成することになってしまいます。
Kubernetesは約4ヶ月で新しいバージョンがリリースされ、それに合わせてEKSも更新が必要になります。 EKSクラスタが増えるとその更新の作業コストがかかります。
EKS の Kubernetes バージョンライフサイクルを理解する - Amazon EKS
そのため、EKS化に伴いAWSアカウントを検証環境/ステージング環境/本番環境の3つに集約し、EKSクラスタを3つだけ構築することにしました。 これによってEKSの更新のコストの増加を防ぐことができました。
検証環境を増やしやすくする
freeeでは検証環境は1つのプロダクトに対して複数あります。
freeeサインにも2環境あり、それぞれの環境にDB、ALB、ドメインがある状態でした。 これでは開発生産性をアップさせるために環境を増やしたいときに追加で作成しなければならないものが多く、スピード感が出ません。 そのため、EKS移行に伴い、検証環境全体でDB、ALB、ドメインを統合しました。
特にDBの相乗り化についてはコスト削減の観点でも有用であり、過去のブログ記事でも以下のように解説しています。
costの観点
costの観点からみても、効率的ではなくて無駄に多く作られているかと思いました。 多くの開発teamでの機能テストやQA テストのために各integration環境 (検証環境) をそれぞれ構築し、非効率的に使われていました。 これを相乗り化する事でDB clusterの数を減らすと共にコストの削減効果も期待できると思いました。
複数の検証環境でのDB相乗り化 - freee Developers Hub
このような構成によって、新たなAWSリソースを追加しなくても検証環境を増やせるようにしました。
freeeサイン専属SREがいなくても支援できる体制づくり
EKS移行はSREメンバー2,3名がメインで行い、プロダクト開発チームが開発に専念できる体制で進めました。 そのため、EKS移行後に急に開発環境が変わり、プロダクト開発チームの開発生産性が一時的に落ちる懸念がありました。 本番移行前の1,2ヶ月ほど前からSREとプロダクト開発チームと合同でインフラ勉強会を開催し、事前にEKSベースのインフラのキャッチアップを支援しました。 数回に分けて実施し、プロダクトチームからの疑問をベースにECSベースとEKSベースでの開発の違いやfreee標準のインフラの仕組みなどを同期的に話をしていきました。 プロダクト開発チームとしては開発フローの変更に対して特に興味があったため、その点についてはCI/CD周りに詳しい (当時の) SREのDeveloper eXperienceのメンバーに重点的に説明していただきました。
EKS移行後、プロダクト開発チームが本格的にEKSベースのインフラで開発が始まった後も問い合わせや標準化しきれなかった仕組みなどの改修も発生しました。 その際に「この対応はfreeeサイン専属のSREでないとできないのか?」という観点でトリアージしていきました。 Noであれば、背景や条件、目指すべき姿などを伝えつつ、他のSREメンバーに依頼して対応していただきました。 こうした活動により、他のSREメンバーでもfreeeサインのインフラを支援できるように働きかけました。
まとめ
2025年5月に本番環境のEKS移行を無事終え、freeeサイン専属SRE体制を終了し全社的なSRE体制に統合することができました。
freeeサインのEKS移行を行うにあたって、プロダクト開発チームのみなさん、他のSREチームのみなさん、セキュリティチームのみなさんなど、多くの方々に協力いただきました。 この場をお借りして、感謝を申し上げます。
明日はWaTTsonさんから技術の日の折り紙の創作過程についての記事が公開されます。お楽しみに！
