Figmaは、同社のコンピュート・プラットフォームをAWS ECSからKubernetes (EKS)へ、顧客への影響を最小限に抑えながら12ヶ月以内に移行した。同社は、コンテナ化されたワークロードを実行するためにKubernetesの採用を決定したが、これは主にCNCFがサポートする大規模なエコシステムを活用するためだった。さらに、コスト削減、開発者エクスペリエンスの向上、回復力の強化を追求したことも、この移行を決定づけた。
Figmaは、コンテナでアプリケーション・サービスを実行するように移行し、2023年初頭までにコンテナ・オーケストレーション・プラットフォームとしてElastic Container Service（ECS）を採用した。ECSを使用することで、同社はコンテナ化されたワークロードを迅速に展開できたが、それ以来、エンジニアはECSを使用する際の特定の制限、主にStatefulSet やHelmチャートのサポート不足、TemporalのようなOSSソフトウェアを簡単に実行する機能の不足といった問題に直面するようになった。
さらに同社は、Keda やKarpenterを使用した高度なオートスケーリング、Istio /Envoyを使用したサービスメッシュ、その他多数のツールや機能など、CNCFコミュニティ内でKubernetes向けに提供されている幅広い機能を見逃していると認識していた。同組織はまた、ニーズに合わせてECSをカスタマイズするために必要な多大なエンジニアリングの労力と、Kubernetesの経験が豊富なエンジニアが転職市場で入手可能であることも考慮した。
/filters:no_upscale()/news/2024/09/figma-ecs-kubernetes-eks/en/resources/1figma-ecs-k8s-1725279367947.jpeg)
Kubernetes移行のタイムライン（出典：Figma Engineering Blog）
Kubernetes（EKS）への移行を決定した後、チームは移行範囲について合意し、遅延やリスクを回避するためにサービスに必要な変更を最小限に抑えることに注力した。プロジェクトのスコープを限定したものの、開発者のエクスペリエンスを向上させるためのリソース定義の簡素化や、バグやオペレーターエラーの影響を避けるためにデプロイを3つのKubernetesクラスタに分割することによる信頼性の向上など、具体的な改善点を盛り込みたいと考えていた。
Figmaのソフトウェア・エンジニアリング・マネージャーであるIan VonSeggern氏は、移行プロジェクトのコスト最適化の目標についてこう語る：
この移行の一環として、あまり複雑なコスト効率化作業には取り組みたくなかったが、1つだけ例外がある：ノードの自動スケーリングを最初からサポートすることにした。EC2上のECSサービスでは、単純にオーバープロビジョニングを行い、デプロイ時にサージアップするのに十分なマシンを用意した。これは高価なセットアップだったため、移行にこの追加スコープを追加することにした。オープンソースのCNCFプロジェクトKarpenterを使い、需要に応じて動的にノードのスケールアップとスケールダウンを行った。
プロジェクトを成功させるために、Figmaは、移行作業を推進し、より広い組織と関わり、彼らの賛同を得るために、十分なスタッフを揃えたチームを作った。エンジニアは、Kubernetesセットアップの負荷テストを実施してサプライズを回避し、重み付けされた DNS エントリを使用して段階的な切り替えメカニズムを実装し、プロセスの早い段階でステージングKubernetesクラスターにサービスをデプロイして問題を解決することで、本番ロールアウトに備えた。コンピュート・プラットフォーム・チームは、サービス・オーナーと協力してゴールデン・パスを提供し、一貫性とメンテナンスのしやすさを確保した。
最初の移行には12ヶ月弱を要し、コアサービスの移行後、チームはKedaベースのオートスケーリングの導入などのフォローアップ活動を検討し始めた。さらに、ユーザーからのフィードバックに基づき、エンジニアは3つのKubernetesクラスタと新しいきめ細かなRBACロールで動作するように開発者ツールを簡素化した。