クラウドプラットフォームチームの高野です。マイクロサービスプラットフォームの運用・改善を担当しています。 myTOKYOGASのマイクロサービス化については、以下の記事を参照してください。 tech-blog.tokyo-gas.co.jp 2024年11月、1つ目のマイクロサービスをリリースしました。当時はコンテナオーケストレーションサービスとして Amazon EKS を採用していました。その1年後の2025年11月、EKS から Amazon ECS / AWS Fargate へと移行しました。 本記事では、移行の背景、移行後の構成、移行の成果について紹介します。 移行の背景 2024年11月に1つ目のマイクロサービスをリリースし、マイクロサービスプラットフォームの本番運用が始まりました。そして半年ほどが経ち、EKSの設計・構築・運用をリードしていたKubernetesの有識者が社内異動でチームを離れることになり、私が引き継ぐことになりました。 この時、以下の状況でした。 マイクロサービスプラットフォームの運用メンバーは、私を含めて2名 Kubernetesの運用経験は、私はほぼなく、もう1名は経験あり チームの役割は、インフラの運用・保守、プラットフォームの改善、ソフトウェアエンジニアからの依頼対応、SREの推進など多岐にわたる メンバーの増員計画はあったものの、人手不足は否めませんでした。特に、以下の点でEKSクラスターの運用に課題を感じていました。 1. 定期的なバージョンアップの作業負荷が大きい EKS は各バージョンのサポート期間が 14 ヶ月のため、年に 1 回程度はクラスターのバージョンアップが必要です。また、バージョンアップ作業にはリスクが伴うため、十分な準備時間を確保する必要があります。 さらに、EKS クラスター本体だけでなく、EKSアドオン、ノードの AMI、Istio、Argo CD などのエコシステムもバージョンアップしていく必要があります。 少人数のチームのため、バージョンアップ対応中は他の業務が進まなくなることが予想されました。中でも、ソフトウェアエンジニアからの依頼対応が後回しになり、開発のリードタイムに影響が出てしまうことを懸念していました。 2. 日常的な運用負荷が高い ECS と比較して、EKS および Kubernetes は設計・設定の自由度が高いです。これは利点でもありますが、設定変更時の調査や検証にかかるコストが ECS より大きいと感じていました。AWS との統合においても、ECS ではマネージドで完結する部分が、EKS では追加の設定や考慮が必要になることがあります。 また、こちらは私たち側の事情になりますが、初期構築時は将来のスケールや拡張性を見据えた設計が必要であり、当時の判断としては妥当だったと思います。一方で、運用を続ける中で、現時点の規模や将来の見通しに対して、やや過剰な構成になっていることが分かってきました。これが運用コストを押し上げる一因となっていました。 加えて、EKS および Kubernetes は ECS と比べて理解すべきリソースの種類や固有の概念が多く、学習コストの高さも課題でした。経験がなかった私自身もキャッチアップに苦労しましたし、今後チームを拡大する際にもネックになると考えていました。 移行の意思決定 私は過去に ECS / Fargate を運用した経験があり、ECS への移行が前述の課題解決になると考えました。ECS は EKS と比較してシンプルで学習コストが低く、Fargate と組み合わせることで運用コストを抑えることができます。 EKS のまま構成を見直して運用負荷を下げる案も検討しましたが、EKSクラスターのバージョンアップ負荷や学習コストの高さは引き続き残ります。そのため、移行する方が望ましいと考えました。 移行を本格的に検討するにあたっては、以下の2つの点を意識しました。 ECS / Fargate に移行することで、現時点で提供できなくなる機能はないか ECS / Fargate に移行することで、将来的に困ることはないか 1点目については、現時点で EKS 固有の機能に依存しているものがないことを主にチーム内で確認しました。2点目については、ソフトウェアエンジニアリングチームのメンバーとリーダー、そして内製開発チームを管掌するグループマネージャーと対話を行いました。 開発組織は今後どのように成長していきそうか マイクロサービスはどのくらいのペースで増え、どれくらいの規模になりそうか EKS および Kubernetes でなければ満たせない要件が、この先出てきそうか これらを確認および検討した結果、少なくとも当面の範囲では、ECS/Fargateで要件を満たせる見通しが得られました。 もちろん、将来的に EKS の方がマッチする要件が出てくる可能性はあります。しかし現時点では、今移行することで運用コストを下げ、改善業務やアプリケーション開発へリソースを充てることができるため、プロダクト価値向上と事業貢献の観点で効果が高いと判断し、ECS と Fargate への移行を決定しました。 プロジェクト体制と期間 マイクロサービスプラットフォームの開発・運用メンバー2名に、ソフトウェアエンジニアリングチームから1名が加わり、計3名の体制でプロジェクトを進めました。既存環境の運用も並行していたため、関係者間で優先順位をそろえつつ進めました。 プロジェクトの立ち上げから本番環境の移行完了まで、約4ヶ月でした。マイクロサービスが本格的に増え始める前のタイミングだったため、比較的短期間で、リスクが小さい状況下で移行を行うことができました。 設計 EKS から ECS へ移行し、実行環境には Fargate を採用しました。日次のバッチ処理は、Amazon EventBridge、AWS Step Functions、ECS を組み合わせています。デプロイには ecspresso を使用しています。運用負荷の削減を目的に、マネージドサービスを積極的に活用することを意識しました。 以下が移行後の構成図です。ECSに関する箇所のみを記載しています。 構成図 移行の成果 移行から半年が経ち、当初期待していた効果が得られていることを実感しています。特に、クラスターやエコシステムのバージョンアップが不要になったことで、インフラ保守に割く時間はほぼなくなりました。 運用負荷が下がったことで、少人数体制のままでも安定して運用できるようになりました。日々の運用に追われにくくなった分、コスト削減や IaC の推進といった改善活動に加え、プロダクト開発にも貢献できるようになっています。 最後に 現時点では ECS が最適と判断しましたが、組織やプロダクトの成長、今後の要件に合わせて、継続的に見直していきたいと考えています。 意思決定から移行完了までスピーディに進められたのは、内製開発ならではだと感じています。今後も、素早くお客さまに価値を届けられるよう、改善を続けていきます。

Hello, everyone! I’m Xin Wei, working as an SRE here at ONE CAREER. It’s already been a whole year since I joined the company as a new grad in April 2025! Time really flies! I did a short interview for this tech blog when I was in my third month, but today, I want to use my own words to look back on this amazing year. I’ll share the challenges I’ve overcome and how much I’ve grown as an engineer. Today, I’m super excited to share what ONE CAREER's culture really looks like through the eyes of a first-year SRE!

みなさんこんにちは。ワンキャリアでSRE（Site Reliability Engineering）をしているXin Wei（ギ シン）です。 2025年4月に新卒として入社してから、あっという間に1年が経ちました。入社して3ヶ月目の頃にも一度テックブログのインタビューでお話しさせていただきましたが、今回は私自身の言葉で、この1年間でどのような壁を乗り越え、エンジニアとしてどう変化したのかを振り返ってみたいと思います。