これは🎄GMOペパボ エンジニア Advent Calendar 2024の15日目の記事です。

14日目はk4tayaさんのDKIM2についての所感でした。 ペパボのエンジニアAdvent Calendarにはもうひとつの会場もありますので、ぜひこちらもご覧ください。

HerokuからAmazon EKSへ移設

SUZURIでは2014年のサービス開始当初からHerokuを利用しており、2018年からはHeroku Enterpriseを契約し、ここまで運用してきました。

今年、10年間使ってきたHerokuからAmazon EKSに移設することを決定し、2024年6月に完了しました。 これまでHeroku関連の記事をいくつか書いたり、Salesforceのセミナーで登壇する機会もいただくなど、長年付き合ってきたプラットフォームなので思い出深いものがあります。

移設の意思決定は、インフラの専門部署である技術部プラットフォームグループとSUZURI事業部の共同で行いました。なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのかに詳しいのでこちらをご覧ください。

移設作業はプラットフォームグループが行い、私は事業部のアプリケーションエンジニアとして主に以下を担当しました。

  • アプリケーションコードの修正
  • Amazon ECRにイメージをプッシュするようにビルドパイプラインを変更
  • Private Spacesで動くアプリケーションのうち、小規模なものを通常版Heroku（Common Runtime）に移設
  • 事業部のアプリケーションエンジニアに向けたドキュメントの作成

アプリケーションコードの修正

HerokuはThe Twelve-Factor Appを提唱しており、疎結合でステートレスなアプリケーション設計が強制されるようになっています。

たとえばDBやRedisといったミドルウェアの接続先は環境変数で管理され、変更は環境変数を書き換えるだけで済みます。 ログはファイルではなく標準出力に出力され、収集・解析はAddonを用いて行います。 ローカルにファイルを保存しても再起動時に消滅するため、永続化する必要のあるすべてのデータはDBやオブジェクトストレージに保存しなければなりません。そのためHerokuから別のコンテナプラットフォームへの移設は比較的容易だと言えます。 実際、アプリケーションコードはほぼ変更していません。

しかしHeroku特有の事情に基づいて分岐している箇所はあったのでそれらを修正したほか、ミドルウェアの接続先についても、移行期間中はHeroku AddonとAWSの両方を参照できるようにするなどを行いました。

コードとは直接関係ありませんが、IPアドレスで制限されている外部サービスがいくつかあり、その洗い出しが一番苦労したポイントかもしれません……。

Amazon ECRにイメージをプッシュするようにビルドパイプラインを変更

HerokuではbuildpackによるデプロイのほかにDockerイメージによるデプロイにも対応しています。 SUZURIではEKSへの移設以前からDockerデプロイにしていたため、プッシュ先をECRに変えるだけでDockerfileはほぼそのまま流用できました。 Herokuから別のコンテナプラットフォームへの移行を検討している場合、まずはDockerデプロイにしておくと環境差分が少なくなるのでおすすめです。

また、SUZURIではAPMとしてDatadogを利用しています。HerokuではDatadog AgentをDockerイメージに追加し、コンテナ内の別プロセスとしてAgentを起動する方法を用いていました。 この方法は（非効率ではあるものの）EKSでも動くため、移設時点ではそのままとしました。 現在はDatadog Operatorを使ってDaemonSetとして起動する方式に移行しています。

こういった変更はついでにやりたくなりがちですが、思わぬトラブルが起こったり、単純にタスクが増えてスケジュールを圧迫してしまうリスクがあるため、できる限り差分を減らして移設する方針を取りました。

Private Spacesで動くアプリケーションのうち、小規模なものを通常版Heroku（Common Runtime）に移設

Heroku EnterpriseではPrivate Spacesと呼ばれる分離環境を構築でき、SUZURIではこれを利用して日本リージョンにデプロイしていました。 Private SpacesにはSUZURIのメインアプリケーション（モノリス）以外にも小規模なアプリが乗っていましたが、これはEKSではなく通常版Heroku（Common Runtime）に移設しました。

小規模なのでEKSへの移設コストをかけるメリットが薄いことと、これ以外にもいくつかのアプリがCommon Runtime上で動いており、Herokuの知見は今後も残り続けることから、わざわざHeroku以外のプラットフォームを採用する理由はないと判断したためです。 したがってHeroku Enterpriseは解約したものの、通常版Herokuについては継続利用しています。

事業部のアプリケーションエンジニアに向けたドキュメントの作成

EKSを採用するにあたっては、インフラがアプリケーションエンジニアの手に負えなくなることで、これまでよりもアジリティが落ちてしまうことが一番の懸念でした。 以下のようなオペレーションはアプリケーションエンジニアでも行えるよう、ドキュメントを随時作るようにしています。

  • kubectlコマンドを用いたPodの操作やログの確認
  • 環境変数の変更（秘匿情報はAWS Secrets Manager、そうでないものはConfigMap）
  • CronJobリソース、Jobリソースの作成変更

サービス運用では時折アドホックなデータの変更や処理の再実行が必要になることがあります（ここではoneshot taskと呼びます）。 Herokuではheroku runコマンドによって簡単にoneshot taskを実行できました。 このheroku runに相当するオペレーションができないとアジリティが落ちるのは目に見えていたため、ラッパースクリプトを用意してJobリソースを楽に作成できるようにしてあります。

まとめ

10年間利用してきたプラットフォームからの移設は事業部にとっても挑戦でしたが、こうした取り組みにより無事完遂でき、今のところ大きな問題は起こっていません。

定量的なデータとして、ペパボではFour Keysを集計しているので観測したところ、移設前後の半年間で、

  • デプロイの頻度：やや増加
  • 変更のリードタイム：やや減少
  • 変更障害率：変わらず
  • サービス復元時間：変わらず

という結果が得られました。 デプロイ頻度とリードタイムについては開発生産性を上げるために別途取り組んでいたり、障害にはプラットフォーム起因だけでなくアプリケーション起因もあるため、厳密にEKS移設による影響を評価することは難しいですが、少なくともFour Keysにおいてはアジリティの低下は見られないと言えそうです。

今後はKubernetesをより活用し、開発者体験とユーザー体験の両面でさらなる向上を目指したいと思っています。