こんにちは。技術部プラットフォームグループのshibatchです。プラットフォームエンジニアとして、主にSUZURIとminneをより良くするおしごとをしています。
さて私が主として携わっているSUZURIですが、2014年のサービス開始以来、一貫してHerokuを利用してきました。このたび、10年間使っていたプラットフォームを卒業し、新たにAmazon EKS(Elastic Kubernetes Service)へ移す方針に決めた経緯についてお話しします。EKSに移すという決定にするまでに多角的に検討し、時に悩みながら決定した過程について明らかにしていきます。
なお、現在プラットフォーム移設の真っ最中であり、移設の詳細な内容はこの記事に含めません。移設作業はほぼ完了に向かっており、また別途お話しする予定です。
この記事は以下の3部構成になっています。
- Herokuから移行しようと思った経緯
- AWSがよいと思った理由
- ECS？EKS？それともApp Runner？
その前にちょこっとだけPRさせてください。現在SUZURIではTシャツセールを開催中です！(6/23まで) もしよければお気に入りのTシャツを見つけてみてくださいね。
Herokuから移そうと思った経緯
Herokuは運用する上でラクで非の打ちどころがないPaaS
Herokuから移設する理由を述べる前に、まずはHerokuが現在でも非常に良いPaaSであることをお伝えしたいです。HerokuではDatabaseのアドオンやRedisのアドオンも含めてSUZURIのシステムで全面的に利用しています。
その中で運用している上で障害らしい障害はなく、トラフィックが増えた場合でもWebコンソールやCLIからラクにスケールできる簡便さを備えています。レイテンシが悪化したような体験もまれで、デプロイやロールバックもしやすく、アプリケーションエンジニアがエンジニアリングに集中できる環境でありました。
なぜHerokuから移設することに？
では、なぜHerokuから移行することにしたのでしょう？
いちばん大きな理由、それはGMOペパボでは複数のサービスを提供しており、SUZURIがサービス開始した当初よりプラットフォームを自身でコントロールしていける知見がたまってきたため、Herokuほどのフルマネージド加減が必要なくなってきたことです。
例えばGMOペパボで他に提供しているサービスとしてminneがありますが、Kubernetesで運用しており、デプロイフローも社内で標準的に用いられている基盤で運用されています。SUZURIにおいても、画像変換機能の部分はKubernetesで運用しています（SUZURIにおけるKubernetesの構成は以前私が書いた記事にあります）。
また、フルマネージドであることは便利な反面、そのプラットフォームの制約がサービス特性と合わなくなってきたと感じることも増えてきました。例えばHerokuで用いているアドオンとしてデータベースがありますが(Heroku Postgres)、1インスタンスあたりの接続数の制限により、CPUやメモリといったリソースは問題なくてもスケールアウトしなければならないような状況も見受けられるようになりました。これはSUZURIが事業成長していったことにより露見してきた問題なので喜ばしいことではあるのですが、徐々に無視していくのは難しい問題となっていったのでした。これは一例ですが、「もっと自身でSUZURIの特性に合ったインフラ運用していきたい」という欲求が大きくなってきたことは移設を決定づける大きな要素となりました。
AWSがよいと思った理由
移設先をAWSにしたわけ
SUZURI事業部CTOの@kurotakyから「SUZURIのさらなる成長のため、適切なコストコントロールを行いながら、アジリティの高い環境を実現するためにHerokuから移行したい。」と最初に相談があったのは昨年の初めごろと記憶しています。最初は予備調査として現状のHerokuの利用状況やコスト構造、移行先の候補を検討しました。
最終的に移行先はAWSに決まりましたが、これには複数の理由があります。
AWS RDSの社内での採用実績
移行先の選定にあたり、まず検討すべきはデータベースの配置場所です。データベースが不安定だと即障害につながりますし、データベースとコンテナのネットワーク上の距離はレイテンシに影響を与えます。データベースの配置は移行先選定で大きな要素となります。RDSは社内でも採用実績が多く、知見もたまっており、コストを削減する仕組みやノウハウもあるため、リスクの見積もりがしやすいです。
すでにSUZURIでも一部AWSを使っている
SUZURIではメディアストレージにS3を使っています。S3は画像変換の際に使用されるため、今回移行するWebのコンテナと直接関係はありませんが、今後の組み合わせで面白いことができる可能性があり、その余地を感じます。
実はHeroku自体がAWSの上にあることによる移設リスクの低さ
これが最大の理由です。実はHerokuはAWSのVPCの上で構成されており、Enterprise版だと専用環境(Private Space)を構築できます。まさにSUZURIはそのような使い方をしているのですが、この場合はVPC Peeringを通じて自身で構築したVPCと疎通することができるのです。
私はプラットフォームエンジニアだから？それとも私自身の特性？かはわかりませんがプラットフォーム移設では相当手堅さを重視します。移設は分割して小規模に段階を踏むほど不確実性が減り、サービス影響を抑えながらできるものです。VPC Peeringを利用できるということは、コンテナより先にRedisキャッシュやデータベースを移設してしまって、HerokuコンテナからVPC Peeringを経由して移設先のキャッシュやデータベースに接続することが可能です。ビッグバンメンテナンスを避けることができるので手堅く移設ができると考えました。
ECS？EKS？それともApp Runner？
コンテナの移設先には複数選択肢がある
さて移設先はAWSに決まりました。SUZURIを構成しているHerokuのサービスを考えると以下のような移行先の組み合わせになります。
- Heroku RedisCloud(HerokuにあるRedisのアドオン) → Amazon ElastiCache
- Heroku PostgreSQL(HerokuにあるPostgreSQLのアドオン) → Amazon Aurora
- Herokuのアプリコンテナ → どうする？
コンテナはAWSの何のサービスを利用するか？AWSではコンテナを動かすサービスが複数提供されています。調査した範囲で Amazon App Runner / Amazon Elastic Container Service(ECS) / Amazon Elastic Kubernetes Service(EKS) の3つを候補として挙げました。
これらはマネージド具合が異なります。App Runnerは独立したVPCを構成し、デプロイフローも専用に用意されたものであるため、Herokuに近いPaaSとして提供されています。ECSは自身で構築したVPC内にコンテナを動かす環境を作ります。EKSはKubernetesクラスタをVPC内に構築して動かし、コンテナを動かすという点ではECSと同じですが、Kubernetesのリソースや権限管理、デプロイフローの構築はユーザーに委ねられています。ざっくり言うと、マネージド具合はApp Runner ＞ ECS ＞ EKS の順です。
App Runnerは候補から除外した
この中で、まずApp Runnerは候補から除外しました。少し検証してみると動作は確認できたのですがコンテナに設定できる環境変数の数に制限があったことと(この問題自体はアプリ改修すれば解決しますが)、利用していくうちにこのような未知の制限事項に遭遇し解決していく不確実性を嫌いました。ECS、EKSと比較して若いプロダクトなのでもう少し利用事例が確認とれれば追加検証したかもしれません。 私が技術選定した時期より後になりますが、他社でApp Runnerを使った先行事例が発表されていました。大変参考になる事例です。
ECS or EKS、どちらを採用するか
候補はECSとEKS、2つに絞ったのですが、これがとても悩ましかったです。複数の観点から長所、短所を出してみようにも、何を判断する際に重視するかによって結論はいかようにも変わります。
金額のコストが明確に違えばわかりやすくどちらが良いかを判断できますが、これはほぼ変わらないです。どちらもFargate、EC2の2パターンの構築方法がありますが料金体系は同じと言えます。ただしEKS FargateはECS Fargateと比較するとSpotインスタンスという安価なインスタンスを使えない点でハンデがあります。EC2を用いるならば変わらないと判断しました。
CI/CDに関してはEKSの場合は社内ではGitHub ActionsやArgoCDを用いた環境が整備されているため、そのまま流用できるメリットがあります。ECSではCodePipeline、 CodeBuild、CodeDeployといったマネージドサービスを組み合わせた環境を整備する必要はあるでしょう。
学習コストについては、私が新しく学ぶのであればEKSよりECSのほうが低いだろうという感覚がありました。ただし、GMOペパボではECSを用いたサービス運用事例がなく、逆にKubernetesは展開している各サービスで利用されている状況です。ECSを推進するには明確なメリットを提示する必要があり、他サービスでKubernetesが既に運用されている中でSUZURIのみECSを用いるのはスケールしない考え方です。
結論の話をする前に、GMOペパボの体制の話
上記の学習コストの話に関連しますが、少しだけGMOペパボの組織体制について触れます。なぜなら、移行先を検討するにあたり今後のSUZURIのプラットフォーム運用の主体をどうするかという検討をした話をしたいからです。
GMOペパボでは事業部制を敷いています。また、その組織を横断してサポートする部署として技術部があります。
私はSUZURIのプラットフォームの改善が業務の中心ですが、SUZURI事業部ではなく、技術部のプラットフォームグループという横断組織の「minne/SUZURIチーム」に所属しています。minne / SUZURIという両サービスはどちらもコンテナ技術主体で構成されている点で技術スタックに共通点があるため、minneとSUZURIは同じチームになっています。事業部の垣根を越えて、俯瞰した立場からインフラの構成を提案したり運用したりする立場にいます。
さて今までSUZURIというサービスにおけるHerokuの運用はSUZURI事業部内のエンジニア主体で行われていました。それはHerokuの安定性の高さゆえ、運用管理する手間が少ないので、アプリケーションエンジニア主体の組織である事業部内のエンジニアでも特に問題がなかったのです。
ECSを使った場合は、Herokuよりは管理工数が増えるかもしれませんが、今までと同様SUZURI事業部のエンジニアで行っていくであろうことが予想できました。
EKSを用いた場合、リソース管理や四半期ごとのKubernetesのバージョンアップといった管理工数が避けられないことを考えると事業部内のエンジニアで運用を完結することは難しいと予想しました。運用の主体はSUZURI事業部ではなく、技術部プラットフォームグループである我々が行うのが自然でしょう。
どちらにするかは集合レビューで結論を出した
ECSにするか、EKSにするかの判断は、社内の横断的なインフラの運用戦略に関わります。私が独断で決めるより、周囲のコンセンサスが必要と判断し、SUZURI事業部と技術部のステークホルダを集めて結論を出しました。
要点をまとめると以下の通りです。
- SUZURI事業部としてはプラットフォームはPaaS的に運用したい。その目的に沿えば手段は問わないので、フルマネージドなものにするか、プラットフォームグループ中心で運用するかにしたい。
- ECSにするメリットを挙げるならば社外の知見は多そうであること、事業部主体で運用できるならば技術部の負荷が高くならない期待がある。
- 運用は一人でするものではないので、EKSにする場合は組織内でのコンセンサスがほしい。
- Kubernetesは社内で運用されているので困ったときに社内で解決する確度が高いのはEKSと思われる。EKSのほうが人的冗長性を確保できる。
- したがって、EKSを採用するほうがよいだろう。
このように、組織的な人的冗長性の観点や、すでにCI/CD環境が整備されているアドバンテージから、EKSを採用する運びとなりました。実を言うと、私自身の本音は当初、ECSのほうが良いのではないかという考えはありました。ところがこの集合レビューを通じて自分の組織でKubernetesを推進していくぞ！という意気込みや後ろ盾を感じてKubernetesでやっていけるという確信が持てたため、Kubernetesで構築することに気持ちが入っていきました。複数サービスを運用しているGMOペパボにおいてはKubernetesを採用して横断的に運用していくのが良いだろう、と考えを改めました。
さいごに
プラットフォームをどこに移設するか、はたまたECSにするか、EKSにするかという判断は各会社や組織の環境によって結論は変わります。GMOペパボがSUZURIのみ運用していたのであれば別の結論であった可能性は十分あります。
私がこの記事を書こうと思った理由はこの難しい判断に結論をつけるプロセスを公開することがもし他社さんの参考になればと思ったこともありますが、自社内で10年ぶりのインフラ刷新の過程を残しておくと、何かあったときに判断を振り返ることができるという、社内のエンジニア向けの側面もあります。今回の判断が多くの方の参考になれば幸いです！