12か月以内にK8sへ移行した方法

 (figma.com)
1 ポイント 投稿者 GN⁺ 2024-08-10 | 1件のコメント | WhatsAppで共有

Cookie設定とニュースレター購読

  • このWebサイトは、パフォーマンス、パーソナライズ、マーケティングを目的として、Cookie、ピクセルタグ、ローカルストレージを使用する。
  • 必須Cookieのみがデフォルトで有効化されている。
  • ニュースレターを購読できる。

FigmaのKubernetesへの移行

  • 著者: Ian VonSeggern、Figma ソフトウェアエンジニアリングマネージャー
  • テーマ: Figmaが12か月以内にKubernetesへ移行した過程とその理由

Figmaのコンピューティングプラットフォーム

  • 2023年初頭、すべてのサービスをコンテナで実行する作業を完了した。
  • AWSのElastic Container Service（ECS）を使用して、コンテナ化されたワークロードを迅速に立ち上げた。
  • 長期的な観点から、コンピューティングプラットフォームの次世代版を検討するようになった。

Kubernetes機能の不足

  • ECSのいくつかの制限により、多くのエンジニアリング時間が必要になった。
  • KubernetesのStatefulSets機能がECSにはなく、etcdクラスターを実行するのが難しかった。
  • Helmチャートによるサービス定義のサポートが不足していた。
  • ECSでEC2を実行する際、単一のEC2マシンを終了させるのが難しかった。

Cloud Native Computing Foundationエコシステムへのアクセス

  • ECSを使うと、CNCFエコシステムのオープンソース技術を活用できなかった。
  • Kubernetesエコシステムは自動スケーリング機能に優れている。
  • サービスメッシュ導入の可能性も検討した。

人気のあるプラットフォームの利点

  • Kubernetesは多くの大企業で使われており、安定性が検証されている。
  • ベンダーロックインを避けられる。
  • Kubernetes経験のあるエンジニアを採用しやすい。

移行範囲の設定

  • 安全な移行のため、コアシステムの変更を最小限に抑えた。
  • EKSへの移行を目標とした。
  • 一部の改善事項を移行範囲に含めた。

移行に含まれた改善事項

  • 開発者体験: サービス定義とデプロイプロセスを簡素化した。
  • 信頼性向上: 3つのEKSクラスターを使用してサービスの信頼性を高めた。
  • コスト効率: ノードの自動スケーリングをサポートし、コストを削減した。

範囲外とした作業

  • ログパイプラインの複雑さを解消する作業は除外した。
  • Podレベルの自動スケーリング作業は除外した。

安全な移行の実施

  • 負荷テスト: クラスターの性能を把握するために負荷テストを実施した。
  • 段階的ロールアウトの仕組み: 重み付きDNSエントリを使って、段階的にトラフィックを移行した。
  • 実サービスの実行: ステージング環境で実際のサービスを動かし、問題を早期に発見した。
  • カスタムYAMLの最小化: ユーザーを混乱させる可能性のあるYAML定義を最小限に抑えた。
  • サービスオーナーとの緊密な協力: サービスオーナーと協力して監視とアラートを更新した。
  • 適切な人員配置: 予期しない問題に対応できるチームを編成した。

移行結果

  • 2024年1月までに主要サービスをEKSクラスターへ移行した。
  • コスト削減、信頼性向上、開発者体験の改善といった利点を得た。

リリース後の期間

  • クラスターとロールの自動推論により、ユーザーアクセスツールを改善した。
  • ログパイプラインの簡素化、Horizontal Pod Autoscalingのサポート、Gravitonプロセッサへの移行などを計画している。

GN⁺のまとめ

  • FigmaはECSからKubernetesへの移行を通じて、コスト削減、信頼性向上、開発者体験の改善を実現した。
  • CNCFエコシステムのオープンソース技術を活用し、自動スケーリングやサービスメッシュ導入の可能性を高めた。
  • 移行プロセスでは、負荷テスト、段階的ロールアウト、実サービスの実行といった安全な方法を用いた。
  • リリース後はユーザーアクセスツールを改善し、追加の最適化作業を計画している。

関連記事

1件のコメント

 
GN⁺ 2024-08-10
Hacker Newsの意見

  • k8sを好むユーザーがいる

    • 複数の小規模で複雑なカスタムECショップを運営している
    • マーケティング、財務、顧客サービスまですべて担当している
    • 以前は専用サーバーを使っていたが、デプロイは悪夢だった
    • k8sへの移行には1か月かかった
    • 25種類のサービスを運用している
    • クラスター構成を1か所に集約し、サービスの状態を正確に把握できるようになった
    • ダウンタイムなしでローリングデプロイが可能になった
    • 複雑ではあるが、プログラマーとして複雑さには慣れている
    • k8sアーキテクチャを理解すれば、さらに多くのことを学べる
    • 高可用性（HA）が非常に役立つ
    • ホスティング費用は月400ドル程度かかる

  • インフラ改善のためのマイグレーションは良い

    • Helmチャートを使うためにTerraformへ変換しないのは意外だ
    • Helmチャートを修正なしで使うのは一貫性がない
    • Helmは保守が難しいツールだ
    • Terraformで書き直すほうがよい
    • Helmの問題点が解決されたのか気になる

  • HNでk8s反対の意見が多いのは意外だ

    • 多くのコメント投稿者はHeroku、Fly.io、Render.comのようなサービスを使っているか、VMでアプリを動かしている開発者なのかもしれない

  • TerraformとECSを使ったデプロイ管理は過度に複雑だ

    • 環境変数を追加するだけでも複雑だ
    • テンプレート生成の部分は理解できるが、全体として複雑だ

  • Kubernetesへのマイグレーションに何年もかかるという意見には疑問を感じる

    • 企業がなぜこのようなマイグレーションを試みるのか理解できない
    • 顧客にどんな利益があるのか疑問だ
    • 技術的欲求に基づく決定がユーザーにとって意味があるのか疑問だ

  • 大規模組織の決定は、ユーザーや会社の必要に基づいていないように見える

    • Figmaの以前のデータベース関連投稿でも似た印象を受けた
    • 技術的欲求に基づく決定がユーザーにとって意味があるのか疑問だ

  • 現代のシステムやサービスで、1年以内のマイグレーションを誇れるようなものがあるのか気になる

  • 現場レポートを読むのが好きだ

    • いつも新しいことを学べる
    • 共有してくれてありがとう

  • この記事はKubernetesの利点を明確に説明している

    • 多くの人は利点を知らないままKubernetesへ移行する
    • ここで示されている理由は良い

  • マイグレーションをやめるまでにどれくらいかかるのか気になる