Adobe의 셀 기반 아키텍처(Cell-based Architecture)를 중심으로 한 “Scaling Adobe’s Service Delivery Foundation” 백서를 한글 번역 및 재구성하겠습니다. 원문 내용을 충실히 반영하면서, 주요 개념에 대한 설명을 추가해 IT 의사결정자가 이해하기 쉽도록 구성하겠습니다.

Adobe는 최근 몇 년간 내부 개발자 플랫폼을 구축해 왔으며, AWS와 Azure 같은 클라우드 인프라 위에 자체적인 컴퓨팅 레이어를 제공하고 있습니다. 그 상위에는 엔드투엔드 개발자 경험(Developer Experience) 계층을 두어 개발자들이 소프트웨어 개발 생애 주기(Software Development Life Cycle, SDLC)의 모든 단계를 원활하게 수행할 수 있도록 지원합니다. 이 플랫폼 전반에는 보안, 컴플라이언스, 운영 지원, 비용 효율성 등의 크로스컷팅(공통) 요구사항이 적용되어 있습니다.

Adobe는 자사 개발자들에게 보다 빠르게 더 나은 소프트웨어를 작성할 수 있는 풍부한 개발자 경험을 제공하고 있습니다. 예를 들어, 아이디어를 실제 코드로 전환하고 이를 클라우드에 배포하여 고객에게 전달하기까지 모든 단계가 원활하게 이루어지도록 표준화된 툴체인과 워크플로우를 제공합니다. Adobe 내부에서 이 GitOps 기반 서비스 제공 파운데이션(Service Delivery Foundation)에 붙여진 코드명이 “Flex”입니다. 아래는 Flex가 제공하는 주요 기능 요약입니다:

개발자가 아이디어를 현실화할 때, Adobe는 표준화된 부트스트래핑 템플릿(golden template)을 통합 개발자 포털(Adobe 내부 포털, 오픈소스 Backstage 기반)에서 제공합니다. 이를 통해 애플리케이션과 인프라에 대한 보일러플레이트 코드를 자동 생성하며, 생성 직후 로컬에서 애플리케이션을 실행하고 테스트할 수 있습니다. 생성된 인프라 코드에는 해당 서비스의 CI/CD 파이프라인에 필요한 Kubernetes 매니페스트와 구성도 포함됩니다. (툴체인: Adobe 개발자 포털은 오픈소스 Backstage 기반으로 구현되었습니다.)

이렇게 생성된 코드와 환경 덕분에, 개발자는 첫 코드 작성 후 즉시 로컬 실행 및 테스트가 가능합니다. 이는 모범 사례를 내장한 표준 템플릿 덕분입니다.

작성한 코드를 클라우드에 배포하는 단계에서, Adobe는 GitOps 기반의 유연하고 확장 가능한 CI/CD 파이프라인을 제공합니다. 개발자들은 처음에는 포장된(paved) 경로(표준 파이프라인)을 따르되, 필요하면 단계를 추가하거나 파이프라인 DAG를 변경하는 등 파이프라인을 커스터마이징할 수 있습니다. 이 CI/CD 파이프라인은 배포 시점에 필요한 리소스를 즉시 프로비저닝(just-in-time provisioning)해주므로, 예를 들어 배포 시 필요한 DNS 엔드포인트, Kubernetes 네임스페이스, Argo CD 앱 등을 자동으로 생성합니다. 또한 Canary 배포나 블루-그린(Blue-Green) 배포 같은 고급 배포 전략도 기본 제공됩니다. (툴체인: 이 단계에는 CNCF Argo 프로젝트군 – Argo CD, Argo Workflows, Argo Events, Argo Rollouts – 을 활용한 GitOps 방식을 사용합니다.)

클라우드에 배포된 서비스는 Adobe의 통합 개발자 포털 상에서 “원스톱(single pane of glass)” 관리 경험으로 운영됩니다. 예를 들어 “Flexperience”라 불리는 개발자 경험을 통해, 개발자는 백스테이지(Backstage) 기반 포털 플러그인을 통해 애플리케이션 상태 모니터링, 환경 관리 등을 한 곳에서 수행할 수 있습니다. (툴체인: 이 경험은 Backstage 플러그인 형태로 포털에 제공됩니다.)

이러한 서비스 제공 워크플로우의 컨트롤 플레인 (control plane)은 AWS의 관리형 쿠버네티스 서비스인 EKS 상에서 구현되어 있습니다. 다시 말해, Flex의 GitOps 기반 CI/CD 제어 로직은 AWS EKS 클러스터들로 구성된 컨트롤 플레인을 기반으로 동작합니다.

Flex 성장과 문제 인식 – Flex 플랫폼은 2022년 출시 이후 빠르게 성장하여, 2024년 10월 기준으로 다음과 같은 규모를 처리하고 있습니다.

• 360개 이상의 원격 Kubernetes 클러스터
• 22,000개 이상의 Argo CD 애플리케이션
• 매월 30,000건 이상의 배포(deployments)
• 1,000개 이상의 프로덕션 서비스 (마이크로서비스)

그리고 이 수치들은 나날이 증가하고 있습니다. 이러한 폭발적 성장으로 인해, 초기 아키텍처로는 한계에 직면하게 되었습니다. 아래에서는 Flex의 초기 아키텍처와 그로 인해 나타난 과제들을 살펴보고, 확장을 위해 고려한 잠재적 솔루션과 재설계 필요성에 대해 논의하겠습니다. 이후 Adobe가 도입한 새로운 “Flex-in-a-Box (FiaB)” 아키텍처를 깊이 들여다보면서, 해당 아키텍처의 핵심 요구사항과 이를 구현하는 과정에서 참조한 “셀 기반(cell-based) 아키텍처” 개념을 소개하겠습니다. 마지막으로 새로운 아키텍처의 이점과 효과, 남은 도전 과제, 향후 활용 사례 및 미래 계획에 대해 설명드리겠습니다.

Adobe는 클라우드 네이티브(Cloud Native) 기술을 적극 도입하여 내부 플랫폼을 구축하고 있습니다. 특히 Cloud Native Computing Foundation(CNCF) 산하의 여러 오픈소스 프로젝트들을 핵심 구성요소로 활용 중입니다.

Adobe 내부 개발자 플랫폼의 기반을 이루는 오케스트레이션 기술로, Adobe의 거의 모든 컨테이너화된 워크로드가 Kubernetes 클러스터에서 실행됩니다. Kubernetes는 Adobe의 서비스들을 클라우드 환경에서 자동으로 배포, 확장, 관리할 수 있게 해주며 사실상 표준 인프라 플랫폼 역할을 합니다.

Kubernetes 상에서 애플리케이션 배포 시 Helm 차트를 활용하는 패키지 매니저로 사용됩니다. Helm을 통해 복잡한 Kubernetes 매니페스트를 패키징하고 재사용 가능한 차트로 관리하여, 설정을 추상화하고 필요한 값만 values.yaml 로 노출함으로써 배포를 간소화하고 일관성을 높였습니다.

Adobe는 CNCF Argo 프로젝트군의 모든 구성 요소를 CI/CD 파이프라인에 활용하고 있습니다. 구체적으로 Argo CD(v2.9.22), Argo Workflows(v3.4.6), Argo Events(v1.9.0), Argo Rollouts(v1.6.0) 등을 도입하여 GitOps 기반 지속적 배포, 워크플로우 자동화, 이벤트 처리, 고급 배포전략(롤링업데이트·카나리·블루그린 등)을 구현했습니다. Argo 제품군은 Flex의 CI/CD 엔진을 구성하는 핵심 요소입니다.

오픈소스 내부 개발자 포털 플랫폼으로서 Adobe의 통합 개발자 포털 백본(backbone) 역할을 합니다. Adobe는 Backstage 기반으로 개발자 포털을 구축하여, 다양한 개발 관련 도구와 정보를 한 곳에서 제공하고 있습니다. Flexperience와 같은 플러그인을 통해 개발자 경험을 표준화하고, 서비스 정보 열람 및 관리, 템플릿 제공 등의 기능을 구현했습니다.

Adobe Flex의 초기 아키텍처는 다음과 같이 구성되었습니다. Flex는 소스(SCM인 GitHub)와 다양한 배포 대상 환경(쿠버네티스 클러스터 등) 사이에서 중추적인 허브 역할을 담당합니다. 아래 그림은 Flex 플랫폼이 소스(Git)와 대상(Kubernetes 등), 그리고 그 위에서 동작하는 개발자 경험 계층(포털, UI 등) 사이에서 어떻게 접착제(glue) 역할을 하는지 보여주는 고수준 다이어그램입니다.

그림 1: Adobe의 CI/CD Foundation(Flex)가 소스 코드 저장소(GitHub)와 원격 Kubernetes 클러스터(및 기타 배포 대상) 사이의 허브로 동작하는 개략도. 개발자 포털 등의 상위 개발자 인터페이스 계층은 이 CI/CD 파운데이션을 기반으로 다양한 사용 사례에 대한 포장된 표준 경로(paved road)와 원활한 워크플로우를 제공합니다.

초기 구현에서 Flex는 허브-스포크(Hub-and-Spoke) 아키텍처 패턴을 따랐습니다. 중앙에 하나의 Hub가 있고(Adobe에서는 이를 Flex Hub Kubernetes 클러스터라 부름), 이 Hub가 여러 원격(Remote) Kubernetes 클러스터들(스포크)과 연결된 구조입니다. 아래 그림은 Adobe가 초기에 사용한 Hub-and-Spoke 아키텍처 다이어그램을 보여줍니다.

그림 2: Flex의 초기 Hub-and-Spoke 아키텍처. 왼쪽의 Git 저장소(소스)가 이벤트를 발생하면 중앙 Flex Hub 클러스터의 CI/CD 파이프라인을 통해 처리되고, 그 결과가 오른쪽의 여러 원격 Kubernetes 클러스터들(배포 대상)에 배포됩니다. 이때 Hub 클러스터에는 Argo Workflows(파이프라인 생성), Argo CD(GitOps 배포), Argo Events(이벤트 트리거) 등이 실행되며, 원격 클러스터들에는 Argo Rollouts가 설치되어 Argo CD와 연계된 고급 배포 전략을 제공합니다.

초기 아키텍처에서는 Git이 소스 코드 및 배포 매니페스트의 싱글 소스 오브 트루스(single source of truth) 역할을 맡았습니다. 개발자가 애플리케이션 코드를 앱 저장소(app repo)에, 배포 구성을 배포 저장소(deploy repo)에 관리하면, GitHub 이벤트(예: 코드 푸시)가 발생할 때 Argo Events가 이를 감지하여 Argo Workflows 파이프라인을 트리거합니다.

CI/CD 파이프라인은 Hub 클러스터 내 각 서비스별 네임스페이스에서 실행되며, Argo Workflows를 통해 컨테이너 빌드, 테스트, 배포 등의 단계를 거친 후, 최종적으로 Argo CD가 Kubernetes 리소스들을 원격 클러스터(스포크)에 배포합니다. 원격 Kubernetes 클러스터들에는 Argo Rollouts가 설치되어, Argo CD와 협업하여 카나리 배포나 블루-그린 배포 등의 전략을 구현합니다.

또한 Provisioner라는 Adobe의 자체 개발 컴포넌트가 Hub의 CI/CD 파이프라인 단계에서 동작하면서, DNS 엔드포인트나 Kubernetes 네임스페이스 등의 자원을 배포 시점에 실시간으로 생성해주는 지연 프로비저닝(just-in-time provisioning)을 수행했습니다. 아울러 몇 가지 자체 Observability(관측성) 컴포넌트가 배포 과정에서 발생하는 이벤트와 정보를 수집하여 Flex 백엔드로 전송하고, Flex 백엔드는 이를 집계한 후 Flex API로 제공했습니다. 개발자 포털(Backstage 기반)의 Flexperience UI는 이 Flex API를 호출하여 각 서비스의 상태와 정보를 대시보드 형태로 보여주었습니다. 정리하면, 각 서비스는 앱 코드 저장소와 배포 구성 저장소 한 쌍을 가지며, Flex Hub의 CI/CD 파이프라인이 이를 연결해 원격 클러스터에 배포하고, 백엔드/포털을 통해 개발자에게 가시성을 제공하는 구조였습니다.

Flex의 초기 Hub-and-Spoke 아키텍처는 Adobe 내부에 GitOps 기반 CI/CD 플랫폼의 토대를 마련해주었지만, 서비스와 워크로드가 늘어남에 따라 점차 여러 한계점과 문제점이 드러났습니다. Flex 도입 후 약 6개월 시점에 Argo CD 애플리케이션 수가 약 2,500개를 넘어섰을 때, 이러한 문제들이 본격화되었습니다.

• 튜닝 부족

초기에는 Argo CD, Argo Workflows 등 오픈소스 구성요소들을 특별한 튜닝 없이 기본 설정대로 사용했습니다. 운영 중에 점차 알게 된 사실은, 이러한 Argo 컴포넌트들이 제공하는 성능, 안정성, 확장성 관련 수많은 설정(knobs and controls)을 충분히 활용하지 못하고 있었다는 점입니다. 즉, 튜닝 부재로 인해 성능 최적화 기회를 놓치고 있었고, 대규모 환경에서 Argo 기본 설정은 일부 안정성과 성능 이슈를 야기했습니다.

• Kubernetes 컨트롤 플레인 부하

Flex Hub 클러스터는 AWS EKS 기반이었는데, Argo CD와 Argo Workflows가 모두 이 단일 EKS 클러스터 상에서 동작하다 보니, Kubernetes 컨트롤 플레인(API 서버 및 etcd)에 가해지는 부하가 매우 컸습니다. 수천 개의 Argo CD 애플리케이션과 워크플로우가 지속적으로 쿠버네티스 API와 상호작용하면서 API 서버 응답 지연, etcd 부하/과다한 churn 현상이 나타났습니다. 그 결과 Kubernetes 컨트롤 플레인과 상호작용하는 모든 컴포넌트(Argo 포함)의 성능 저하가 발생했고, 결국 CI/CD 파이프라인의 사용자 경험에도 악영향을 미쳤습니다. 배포 시간이 크게 늘어나거나 실패하는 사례가 빈번해졌습니다.

• 공유된 컨트롤 플레인

앞의 이슈와 관련하여, Argo CD와 Argo Workflows 두 시스템이 하나의 EKS 클러스터(K8s 컨트롤 플레인)를 공유한다는 점이 문제를 키웠습니다. 한정된 클러스터 자원과 컨트롤 플레인 용량을 두 가지 워크로드가 경합하면서, 각 컴포넌트의 성능 저하가 증폭되는 결과를 낳았습니다. 같은 컨트롤 플레인을 공유하지 않고 각각 분리했다면 상호 간섭이 줄었겠지만, 당시 구조에서는 하나의 클러스터에서 모든 것을 처리했기에 사용자 파이프라인 지연과 빌드/배포 장애가 누적되었습니다.

• Hub 클러스터 생성의 자동화 부재

Flex Hub (중앙 허브) 클러스터 자체를 반복 가능하게 자동 구축할 수 있는 자동화가 없었습니다. 초기에 이 Hub 클러스터는 몇 분기에 걸쳐 여러 엔지니어들이 수동으로 설정한 환경이었고, 이를 재현 가능한 스크립트나 문서가 명확하지 않았습니다. 만약 Hub 클러스터에 장애가 발생해 클러스터를 새로 구축해야 한다면, 정확한 절차를 몰라 발을 동동 구를 위험이 있었던 것입니다. 플랫폼 팀과 서비스 팀 모두에게 버려서는 안 될 단일 실패 지점(SPOF)이었던 셈입니다. 최악의 경우 Hub 클러스터 장애 시 새 클러스터를 구축하는 데 장시간이 소요되어, 그 동안 모든 고객 서비스 배포가 중단되는 심각한 문제가 될 수 있었습니다.

이러한 문제들로 인해, Flex 플랫폼의 개발자 경험에는 여러 차례의 서비스 중단 및 성능 저하 사고가 발생했습니다. 예를 들어 빌드 속도가 극도로 느려지거나 워크플로우가 중단되는 현상, 배포 작업이 너무 오래 걸리거나 실패하는 문제 등이 보고되었습니다. Adobe는 이를 해결하기 위해 긴급한 개선 노력을 시작하게 되었습니다.

위에서 언급한 문제들을 겪으면서, Adobe 팀은 곧 “하나의 Flex Hub 클러스터만으로는 충분하지 않다”는 결론에 도달했습니다. 초기에는 당면 문제를 해결하기 위해 Hub 클러스터의 수직적 스케일링(Scale-Up)에 집중했습니다. Argo 컴포넌트, EKS 설정, 자체 툴 등에 걸쳐 다양한 튜닝과 최적화 작업을 수행하여 Hub 클러스터의 처리량과 안정성을 끌어올린 것입니다. 예를 들어, Argo CD 애플리케이션 컨트롤러 및 저장소(repo) 서버 레플리카 수를 증설하고, Argo CD가 관리하지 않아도 될 리소스들은 제외시키며, 자가 복구(self-heal) 및 동기화 주기를 튜닝했습니다. 또한 Argo Workflows의 워크플로우 실행 이력을 빨리 아카이브하여(etcd에서) 제거하고, Kubernetes API 호출을 Argo CD 자체 API로 대체하여 인포머 캐시를 활용하는 등 다수의 최적화를 적용했습니다. 이러한 수직 확장(scale-up) 조치들 덕분에 Flex Hub 클러스터는 약 1만 개 이상의 Argo CD 앱을 안정적으로 지원할 수 있을 만큼 개선되었습니다.

참고: 위에서 언급한 Flex Hub 클러스터 수직 확장과 관련된 최적화 내용들은 Adobe가 2024년 발표한 KubeCon 및 GitOpsCon 발표 세션에서 상세히 다뤘습니다. 관심 있는 분들은 “Key Takeaways from Scaling Adobe’s CI/CD Solution to Support 50K Argo CD Apps” (KubeCon Europe 2024) 발표와 “Scaling a GitOps Platform at Adobe” (GitOpsCon 2024) 발표 자료를 참고하시기 바랍니다.

수직 확장으로 한숨 돌리긴 했지만, 근본적인 해결책은 아니었습니다. Adobe 내부 예측으로, 향후 2년간 현재 대비 10배 이상의 서비스 증가가 예상되었는데, 이를 모두 단일 Flex Hub 클러스터로 감당하는 것은 불가능했습니다. 결국 아키텍처 자체의 재설계(re-architecting)가 필요하다는 데 의견이 모였습니다.

두 가지 이상의 대안 설계를 검토한 끝에, Adobe는 기존 Hub 클러스터를 여러 개로 나누는 수평적 확장(Scale-Out) 접근을 선택했습니다. 여러 Hub를 운용하면 앞서 정리한 새 아키텍처 요구사항 다수를 충족할 수 있고, 노력 대비 효과도 가장 크다고 판단했기 때문입니다. 물론 운영 중인 수백 개의 프로덕션 서비스가 있는데 중간에 아키텍처를 바꾸는 것이 쉬운 일은 아니었습니다. 서비스 가동 중단이나 개발자 혼란을 초래하지 않으면서 점진적으로 재설계를 적용해야 했습니다. 이제부터 Adobe가 이 대대적인 아키텍처 확장을 어떻게 접근했는지 구체적으로 알아보겠습니다.

새로운 확장의 첫 단계로, Adobe는 “Flexbox”라는 개념을 고안했습니다. Flexbox란 기존 Flex 플랫폼 구성요소(Argo CD, Workflows, Events, Provisioner 등)를 한데 모아 **하나의 단위(box)**처럼 묶은 것입니다. 쉽게 말해, Flex를 구성하는 GitOps 컴포넌트들의 묶음 하나가 Flexbox에 해당합니다. Adobe는 기존 단일 Hub 클러스터로 이루어진 초기 Flex 환경을 “Flexbox 1”이라고 명명했습니다 – Flexbox 1은 곧 Flex Hub Kubernetes 클러스터 1개로 이루어진 셈입니다.

Flexbox 개념을 도입하면서, Adobe는 Flexbox와 물리 클러스터의 개념을 분리(decouple)해 두었습니다. 즉, 하나의 Flexbox 안에 여러 개의 물리적 혹은 가상 Hub 클러스터를 넣을 수 있는 확장성을 미리 고려한 것입니다. (초기 Flexbox 1에는 물리적으로 하나의 Hub 클러스터만 있었기 때문에 개념적으로 Flexbox 1 = Hub 클러스터 1 이었습니다.) 이러한 유연성을 염두에 둔 설계 덕분에, 이후 Flexbox 내에 복수의 클러스터를 포함시키거나, 혹은 한 Flexbox를 vCluster(가상 쿠버네티스 클러스터) 등으로 구성하는 등의 다양한 시나리오를 실험할 수 있는 토대가 마련되었습니다.

재설계를 시작하면서, Adobe 팀은 새로운 Flex 아키텍처가 충족해야 할 핵심 요구사항들을 다음과 같이 정리했습니다.

• 예측 가능한 확장성

단기적으로든 장기적으로든 필요에 따라 수직적/수평적으로 손쉽게 규모를 확장할 수 있어야 합니다. 증가하는 서비스 수요를 예측 가능하고 신뢰성 있게 감당할 수 있는 구조여야 합니다.

• Flexbox 1의 부하 분산

기존 Hub 클러스터(Flexbox 1)에 몰린 부하를 완화하기 위해, 서비스들을 다른 Flexbox로 옮길 수 있는 능력이 필요합니다.

• 서비스 측의 투명성

각 서비스는 자신이 어떤 Flexbox에서 실행되는지 신경 쓸 필요 없도록 만들어야 합니다. (즉, Flex 플랫폼이 서비스 ↔ Flexbox 매핑을 추상화하여 알아서 처리하고, 서비스 개발팀은 이를 의식하지 않도록 하는 것.)

• 기존 서비스에 대한 무영향

새로운 아키텍처 도입이 기존 Flexbox 1에서 운영 중인 서비스의 런타임이나 CI/CD 파이프라인에 영향을 주어서는 안 된다는 점입니다. (레거시 환경과 신환경이 병렬로 문제없이 공존해야 함.)

• 서비스 런타임 무중단 이관

한 Flexbox에서 다른 Flexbox로 서비스를 옮기는 동안, 서비스의 실행(Runtime)에 중단이 없어야 합니다. (예: 고객 트래픽 처리에는 영향이 없도록.)

• 하나의 서비스 = 하나의 Flexbox

개념적으로 한 서비스(그 서비스의 앱/배포 저장소 쌍)는 한 시점에 하나의 Flexbox에만 속하도록 관리해야 합니다. 서비스 단위로 분리해 운영하고, 중복되거나 동시 다중 Flexbox에 걸쳐 있지 않게 함으로써 관리 복잡도를 줄입니다.

• CI/CD 파이프라인 최소 다운타임

서비스를 Flexbox 간 이관하는 동안 그 서비스의 CI/CD 파이프라인 가동 중단 시간(downtime)을 최소화해야 합니다. 가능하면 중단 없이, 불가피하면 15분 이하 정도로 제한하는 것을 목표로 했습니다.

• 이관 과정 가시성

서비스가 다른 Flexbox로 옮겨질 때 해당 서비스 팀에 이관 상황과 예상 영향도를 명확히 공지할 수 있어야 합니다. (예: “현재 당신의 서비스 배포 파이프라인은 유지보수 중(이관 중)입니다” 등의 상태 표시.)

• Flexbox 내 멀티 클러스터 지원

앞서 언급했듯, 한 Flexbox 안에 둘 이상의 물리적 혹은 가상 Hub 클러스터를 포함할 수 있어야 합니다. (예: Argo CD와 Argo Workflows를 분리한 다른 클러스터로 운영 등.)

• 비(非)컨테이너 워크플로우 지원

향후 서버리스, 클라우드 인프라 프로비저닝 등 컨테이너 외의 워크로드도 Flex 플랫폼에서 수용할 수 있어야 합니다. (이를 염두에 두어 확장 가능한 구조이어야 함.)

새로운 아키텍처를 고안하는 과정에서 Adobe 팀은 “셀 기반(cell-based) 아키텍처”라는 개념에 주목하게 되었습니다. 셀 기반 아키텍처란 대규모 시스템을 여러 개의 독립적인 “셀(cell)”로 구성하여 동일한 작업을 수행하도록 만드는 아키텍처 패턴을 말합니다. 쉽게 말해, 동일한 종류의 워크로드를 처리하는 작은 단위 시스템들을 여러 개 운영함으로써, 필요할 때마다 셀을 추가하여 수평 확장할 수 있게 하고, 한 셀에 장애가 발생하더라도 전체 시스템에 미치는 영향을 국한시키는 설계 방식입니다.

각 셀은 서로 상태를 공유하지 않고 완전히 독립적으로 동작하며, 전체 워크로드 중 일부 비율의 요청만 처리합니다. 이러한 격리 덕분에 특정 셀에 장애가 발생하더라도(예: 셀 내 일부 서비스의 버그로 인한 장애, 잘못된 업데이트 등), 그 셀에서 처리 중이던 일부 요청에만 영향이 미치고 나머지 셀들은 정상 동작을 이어갈 수 있습니다. AWS 웰-아키텍티드 프레임워크에서는 이 개념을 배(ship)의 격벽(bulkhead)에 비유하는데, 선체 내부를 방수 구획으로 나누어 한 구획에 물이 차더라도 배 전체가 침몰하지 않도록 하는 원리와 같다고 설명합니다. 결국 셀 기반 아키텍처를 적용하면, 동일한 서비스를 복수의 인스턴스(셀)로 운영하면서 장애 시 블라스트 레디우스(blast radius)  한 번의 장애로 영향을 받는 범위를 제한할 수 있습니다. 예를 들어 100% 트래픽을 처리하는 하나의 거대 시스템 대신, 10개의 셀이 각각 10%씩 트래픽을 처리하도록 구성하면, 한 셀이 실패하더라도 전체 요청의 10%만 영향을 받고 나머지 90%는 정상 처리되는 식입니다.

그림 3: 셀 기반 아키텍처의 개념도. 여러 개의 셀이 동일한 기능을 수행하며, 각 셀은 독립적으로 서비스 운영 및 상태 관리를 합니다. 중앙의 셀 라우터(Cell Router)는 들어온 요청을 적절한 셀로 분배하며, 특정 셀에 장애가 발생해도 다른 셀로 격리되어 전체 시스템으로의 파급을 막습니다

참고: AWS 모범사례 가이드에 따르면, 셀 기반 아키텍처에서는 각 셀이 완전한 하나의 독립 워크로드 인스턴스로 간주되며, 셀 라우터라는 얇은 계층을 통해 요청을 해당 셀로 라우팅하게 됩니다. 또한 컨트롤 플레인(control plane)이 별도로 존재하여, 새로운 셀의 프로비저닝이나 셀 간 데이터 이동 등의 관리 작업을 담당할 수 있습니다. 이러한 설계는 대규모 트래픽 처리뿐 아니라 멀티테넌시 환경의 “시끄러운 이웃 문제”를 해결하는 데에도 응용될 수 있습니다. (※ 시끄러운 이웃 문제란 클라우드/멀티테넌트 환경에서 한 사용자의 과도한 리소스 사용이 다른 사용자 성능을 저하시킬 때 흔히 쓰는 표현입니다.)

Adobe 팀은 새로운 Flex 아키텍처를 설계하면서 처음에는 셀 기반 아키텍처를 참고하지는 않았지만, 설계를 거의 완성한 시점에 그 개념적 유사성을 깨닫게 되었다고 합니다. 즉, Adobe의 새로운 Flex-in-a-Box 아키텍처에서 말하는 “Flexbox”가 개념적으로 셀 기반 아키텍처의 하나의 “셀”에 상당히 유사했던 것입니다. 다음 장에서 이 Flex-in-a-Box 아키텍처의 구체적 내용과 구현 방법을 살펴보겠습니다.

위에서 정의한 요구사항들을 만족하기 위해, Adobe는 Flex-in-a-Box(FiaB)라는 새로운 아키텍처를 개발했습니다. 말 그대로 “상자 안의 Flex”라는 의미인데, Flex 플랫폼을 구성하는 핵심 요소들을 하나의 Box(상자) 단위로 캡슐화하여, 필요에 따라 이러한 Box를 여러 개 복제함으로써 규모를 쉽게 확장할 수 있는 구조를 의미합니다.

Adobe는 우선 기존의 Flexbox 1 외에 새로운 Flexbox 2를 추가하는 것부터 시작했습니다. FiaB 이전까지는 모든 서비스가 Flexbox 1에만 연결되어 있었습니다 (모든 서비스의 CI/CD 파이프라인이 Flexbox 1의 Hub 클러스터에서만 동작). 그러나 FiaB 도입 이후에는 새로 만든 Flexbox 2에도 서비스 온보딩이 가능해졌습니다. 앞으로 Flexbox 3, 4… 를 추가하여 계속 확대해나갈 수 있는 수평 확장 기반이 마련된 것입니다.

새 아키텍처 전환에 따른 기존 영향 최소화를 위해, Adobe는 Flexbox 2에도 물리적으로 하나의 Hub 클러스터만 두었습니다. 즉 Flexbox 1과 마찬가지로 Flexbox 2도 하나의 EKS 기반 Hub 클러스터로 시작한 것이죠. 이렇게 함으로써 Flexbox 1과 Flexbox 2의 구조를 최대한 유사하게 유지하여, 새로운 요소 도입으로 인한 변수를 줄이고자 했습니다.

Flex-in-a-Box 아키텍처의 3대 원칙 (3R) – Adobe는 FiaB 아키텍처를 설계하면서 세 가지 R로 시작하는 핵심 개념을 중심에 두었습니다.

• Recreation (재생성)

새로운 Flexbox를 필요 시 반복 가능하고 예측 가능하게 (재)생성 및 업그레이드 할 수 있어야 합니다. 이를 위해 GitOps 기반 CI/CD 파이프라인으로 Flexbox 환경을 코드로 정의하고 자동화합니다.

• Redirection (리다이렉션)

Flex 관리자(Admin)가 어떤 서비스를 어떤 Flexbox로 보낼지 선언형 규칙으로 결정할 수 있고, 이에 따라 서비스별 이벤트(GitHub Webhook 등)를 올바른 Flexbox로 전달해주는 라우팅 계층이 필요합니다.

• Relocation (재배치)

한 번 온보딩된 서비스라도 필요에 따라 자동화된 절차를 통해 다른 Flexbox로 옮길 수 있어야 합니다. 이때 서비스 런타임에는 전혀 지장 없이, 서비스팀의 추가 작업은 없고, CI/CD 파이프라인의 중단 시간도 최소화(15분 이내)해야 합니다.

아래 도식은 이 3R 원칙을 FiaB 아키텍처 관점에서 한눈에 보여줍니다.

그림 4: Adobe Flex-in-a-Box 아키텍처 개념도 – 세 가지 핵심 개념인 Recreation(새 Flexbox 생성), Redirection(서비스 요청 라우팅), Relocation(서비스 이동)이 어떻게 이루어지는지 한눈에 표현한 그림입니다. 여기서 Flexbox 1과 Flexbox 2 두 개가 보여지며, 중앙에 GitHub 및 Redirector 컴포넌트가 자리하여 서비스별 이벤트를 적절한 Flexbox로 전달합니다.

새로운 Flexbox를 만든다는 것은 곧 또 하나의 Hub 클러스터와 그 위에 올라가는 모든 구성요소(Argo CD, Workflows 등)를 세팅한다는 뜻입니다. Adobe는 이를 위해 Flexbox 생애주기(lifecycle) 관리용 GitOps 파이프라인을 구축했습니다. Git 리포지토리에 Flexbox의 구성을 선언적으로 정의해두고, 그 repo에 변경이 생기면 Argo Workflows 기반 자동화 작업이 트리거되어 해당 정의에 따라 새 Flexbox 환경을 생성합니다. 아래 그림은 Flexbox 생성 워크플로우의 작동 방식을 나타냅니다.

그림 5: Flexbox 생성(Recreation) 자동화 워크플로우 예시 – Git 리포지토리에 정의된 Flexbox 설정이 변경되면, Argo Workflow가 자동 실행되어 EKS상에 새로운 Flexbox(Hub 클러스터 및 관련 앱들)를 설치합니다. 이 과정에서 Helm 차트를 생성해 Git에 커밋하고(Argo CD가 이를 sync), 각 구성요소별 Argo CD 앱을 생성하여 Argo of Argos 구조로 배포합니다.

위 워크플로우는 두 가지 주요 작업을 수행합니다.

• Helm 차트 생성

입력으로 주어진 Flexbox 구성(config)을 해석하여, 해당 Flexbox에 필요한 각 구성요소(예: Argo CD, Argo Workflows, Argo Events, Provisioner, 모니터링 등)에 대한 Helm 차트들을 자동 생성합니다. 그런 다음 워크플로우가 이 Helm 차트들을 Git 저장소에 커밋하면, Argo CD 애플리케이션이 이를 감지하고 대상 Flexbox(Hub 클러스터)에 동기화(Sync)하여 설치를 시작합니다.

• 리소스 프로비저닝 및 Argo CD 앱 생성

Flexbox 구성요소들이 필요한 Kubernetes 리소스들을 프로비저닝하고, 각 구성요소별 Argo CD 앱을 만들어줍니다. 예컨대 Flexbox에 Argo CD, Argo Workflows 등을 설치하려면, 우선 해당 네임스페이스나 초기 리소스를 만들어야 하는데, 이런 작업을 자동화합니다. Adobe는 이를 일종의 “Argo of Argos” 아키텍처라고 부르는데, 레벨 0에 해당하는 상위 Argo CD 인스턴스가 레벨 1의 각 구성요소 설치를 위한 Argo CD 앱들을 생성/관리하는 방식입니다. (즉, 최상위 Argo CD가 각각의 Argo 구성요소들을 자신의 자식 앱으로써 Kubernetes에 배포하도록 하는 구조입니다.)

이 Recreation 자동화 덕분에 Adobe는 새 Flexbox(Hub 클러스터)를 만들거나 기존 것을 업그레이드하는 과정을 일관되고 재현 가능하게 수행할 수 있게 되었습니다. 즉, “Stamp” 찍듯이 새로운 CI/CD 인프라 박스를 만들어 붙이는 것이 가능해진 것입니다. 이는 과거에 수동 작업으로 Hub 클러스터를 운영하던 것과 대비되는 큰 발전입니다.

새 Flexbox를 만들어두기만 하면 끝이 아닙니다. 어떤 서비스가 어느 Flexbox에서 동작할지를 정하고, 그 서비스에 대한 GitHub 이벤트나 요청을 해당 Flexbox로 보낼 수 있어야 합니다. 이를 위해 Adobe는 Redirector라는 새로운 컴포넌트를 개발했습니다. Redirector는 GitHub 등 소스로부터 발생하는 이벤트와 각 Flexbox들을 중계하는 경량 라우터 역할을 합니다. 전체적으로 보면, Redirector는 여러 Flexbox를 두고 동작하는 “가난한 사람의 로드밸런서(poor man’s load balancer)”와 유사한 셈입니다.

Redirector의 동작 방식은 다음과 같습니다.

• 새로운 서비스로부터 처음 이벤트(예: 새로운 git commit 푸시)가 발생하면, Redirector는 Flex 관리자들이 사전에 정의한 매핑 규칙(rule)을 참고하여 그 서비스가 어느 Flexbox로 갈지 결정합니다. 이 규칙들은 GitHub에 있는 Redirector 전용 repo에 선언적(Declarative) YAML 형식으로 저장되어 있고, Flex 운영팀이 이를 관리합니다. 예컨대 “팀 A의 서비스는 기본 Flexbox 1로”, “특정 도메인의 서비스는 Flexbox 2로” 등의 규칙을 설정할 수 있습니다.

• Redirector는 결정된 “서비스 ↔ Flexbox” 매핑 정보를 DB에 기록해놓습니다. 이후 해당 서비스의 이벤트가 올 때마다, DB에 기록된 대로 지정된 Flexbox로 이벤트를 라우팅합니다. 만약 규칙이 없는 서비스라면 기본값으로 특정 Flexbox를 할당하거나(예: Flexbox 1), 관리자가 규칙을 추가할 때까지 대기하도록 설계할 수 있습니다.

• 한 번 매핑된 서비스는 특별한 조치 없이는 항상 동일한 Flexbox로 라우팅됩니다. 이를 통해 서비스별로 CI/CD 파이프라인이 일관된 환경에서 동작하도록 보장합니다. (물론 이후 Relocation 기능으로 Flexbox를 바꾸면 Redirector의 매핑도 업데이트됩니다.)

결국 Redirector 덕분에, 서비스 팀 입장에서는 자신의 GitHub 이벤트가 백그라운드에서 어느 Flexbox로 보내지는지 신경 쓰지 않아도 됩니다. Flex 운영팀(Flex admins)이 중앙에서 규칙으로 제어하고, 필요 시 새로운 서비스는 2번 박스로 보내 트래픽을 분산하거나, 특정 팀/도메인의 서비스만 모아 전용 Flexbox에 배치하는 등의 전략적 라우팅이 가능해졌습니다.

Flexbox 2 개발 및 새로운 컴포넌트(예: Redirector) 준비가 한창 진행되는 동안에도, Flex 플랫폼에 새 서비스들의 온보딩은 꾸준히 늘어나고 있었습니다. 즉, Flexbox 1의 부하 증가는 현재진행형이었고, Flexbox 2가 생긴 뒤에도 앞으로 계속 확장 요구가 생길 것이 자명했습니다. 따라서 단순히 새 Flexbox를 추가하는 것만으로는 부족하고, 기존에 Flexbox 1에 몰린 서비스들을 어떻게 다른 Flexbox로 분산시킬지 방법을 마련해야 했습니다.

이 문제를 해결하기 위해 Adobe는 Relocator라는 새로운 컴포넌트를 개발했습니다. Relocator는 말 그대로 서비스를 한 Flexbox에서 다른 Flexbox로 “이전”시키는 작업을 수행합니다. 목표는 서비스의 런타임(운영 환경)에 영향 없이, 서비스 개발팀의 추가 작업 없이, CI/CD 파이프라인의 다운타임을 최소화하면서 자동으로 서비스를 옮기는 것이었습니다.

Relocator가 수행하는 서비스 이관 절차는 크게 네 단계로 이루어집니다.

• 소스 Flexbox에서 서비스 파이프라인 중단

우선 해당 서비스의 기존 CI/CD 파이프라인 실행을 일시 중지합니다. 구체적으로, 소스 Flexbox(예: Flexbox 1)에서 해당 서비스의 Argo CD 동기화(auto-sync)를 멈추고, Redirector에게 이 서비스의 이벤트를 더 이상 소스 Flexbox로 보내지 말라고 지시합니다. 또한 Redirector 내에 이 서비스의 상태를 “relocating”(이전 진행 중)으로 표시하여, 개발자 포털 등에서도 해당 서비스의 배포 파이프라인이 현재 유지보수 중임을 인지할 수 있게 합니다.

• 대상 Flexbox에 서비스 파이프라인 재생성

다음으로 대상 Flexbox(예: Flexbox 2)에 해당 서비스의 CI/CD 파이프라인 환경을 새로 설정합니다. 구체적으로는 소스 Flexbox에 있던 Kubernetes 리소스들(네임스페이스, Argo CD 앱 등)을 복제/재생성하여 대상 Flexbox에 동일하게 만듭니다. (Recreation 자동화의 일부 기능을 활용할 수 있을 것입니다.)

• 대상 Flexbox에서 파이프라인 가동 및 검증

대상 Flexbox에 서비스 파이프라인 구성이 완료되면, Argo CD 동기화 기능을 활성화하여 해당 서비스의 새 파이프라인이 정상 동작하도록 합니다. 그리고 Redirector에게 이 서비스의 이벤트를 이제부터 새 Flexbox로 라우팅하도록 업데이트합니다. 그런 다음 실제로 새 Flexbox에서 배포가 문제없이 작동하는지 검증합니다.

• 소스 Flexbox에서 잔여 리소스 제거

새 Flexbox에서 모든 것이 정상화되었다고 판단되면, 마지막으로 소스 Flexbox에 남아 있던 해당 서비스의 CI/CD 관련 리소스들을 정리(delete)합니다. Argo CD 앱, 네임스페이스, 파이프라인 이력 등의 잔재를 삭제하여 리소스를 해제하고, Redirector 상의 서비스 상태를 “relocating”에서 정상 상태로 복귀시킵니다. 이로써 서비스의 Flexbox 이전이 완료됩니다.

Relocator의 도입으로 Adobe는 Flexbox 간에 서비스들을 자유롭게 이동시킬 수 있는 능력을 갖추게 되었습니다. 예를 들어 Flexbox 1이 과부하 상태일 때 일부 서비스를 Flexbox 2로 옮겨 부하를 분산시키거나, 특정 팀에 Flexbox 3을 신설해 서비스를 이관함으로써 전용 CI/CD 환경을 제공하는 것도 가능해졌습니다. 중요한 것은 이 모든 과정에서 서비스 자체의 가용성에는 영향이 없었다는 점입니다 (배포 파이프라인만 짧은 멈춤).

Adobe의 Flex-in-a-Box 아키텍처와 일반적인 셀 기반 아키텍처는 어떤 관계가 있을까요? 앞서 잠깐 언급했듯이, Adobe는 FiaB를 설계할 당시에는 셀 아키텍처 개념을 참고하지 않았지만, 나중에 보니 개념적으로 매우 유사한 부분이 많았습니다. 셀 아키텍처에서 말하는 “셀(Cell)” 한 개가, FiaB에서의 “Flexbox” 한 개와 대응된다고 볼 수 있습니다. 각 Flexbox는 다른 Flexbox와 격리된 작은 CI/CD 인프라 단위이며, Flex 전체로 보면 셀처럼 동등한 역할을 수행하는 복제 가능한 유닛입니다.

물론 엄밀히 말하면 Flexbox = 셀은 완벽히 일치하는 개념은 아닙니다. Flexbox는 CI/CD 파이프라인 인프라 단위이고, 각 Flexbox 내부에 다시 여러 서비스(마이크로서비스들의 파이프라인)가 존재합니다. 셀 아키텍처에서의 셀은 주로 엔드유저 요청을 처리하는 워크로드 인스턴스를 뜻하기에 맥락이 조금 다르지만, “격리와 복제를 통한 확장”이라는 철학은 동일합니다. Adobe 사례는 이러한 셀 아키텍처 아이디어를 Internal Developer Platform의 CI/CD 영역에 창의적으로 적용한 사례라고 볼 수 있습니다.

새롭게 도입된 Flex-in-a-Box 아키텍처는 Adobe에 여러 가지 긍정적인 효과를 가져왔습니다. 주요 이점들을 정리하면 다음과 같습니다.

• Stamp 방식의 확장
  

새로운 Flexbox 환경을 예측 가능하고 신뢰성 있게 생성할 수 있는 능력을 확보했습니다. 필요할 때면 언제든 동일한 방식으로 Flexbox를 찍어낼 수 있으므로, 갑작스런 수요 증가에도 신속히 대응 가능합니다 (Infrastructure as Code 및 GitOps 자동화의 힘).

• 수평 확장 용이

수평적 확장(horizontal scaling)을 통해 용량 한계를 돌파할 수 있는 구조를 갖추었습니다. 필요한 만큼 Flexbox를 추가함으로써, 더 이상 하나의 클러스터 용량에 전체 성능이 제한되지 않습니다. 이는 클라우드 네이티브 업계에서 검증된 확장 방법이기도 합니다.

• 기존 부하 분산

한 Flexbox (예: Flexbox 1)에 몰린 부하를 다른 Flexbox로 분산시킬 수 있으므로, 성능 병목을 해소할 수 있습니다. 이제 Flexbox 1이 한계치에 다다르면 일부 서비스를 Flexbox 2로 옮겨 무중단으로 부하 완화를 할 수 있게 되었습니다.

• 무중단/최소중단 서비스 이관

앞서 설명한 Relocator 프로세스 덕분에, 서비스의 CI/CD 파이프라인을 최소한의 다운타임으로 Flexbox 간 이전할 수 있습니다. 실제 Adobe는 이관 중 서비스 런타임에는 전혀 영향이 없었고, CI/CD도 15분 이내의 정지만으로 재가동할 수 있었습니다.

• Flexbox 매핑의 추상화

서비스 개발팀은 자신의 서비스가 어떤 Flexbox에서 실행되는지 몰라도 됩니다. Flex 팀이 백그라운드에서 최적의 Flexbox를 지정하고 Redirector가 이를 처리하기 때문에, 개발팀은 여전히 동일한 개발자 경험 (깃 푸시하면 자동 배포 등)을 누릴 수 있습니다.

• 전용 Flexbox 제공 가능

필요에 따라 특정 팀이나 조직을 위한 전용 Flexbox 인프라를 제공할 수 있습니다. 예를 들어 중요한 서비스가 많은 부서를 위해 별도로 Flexbox를 만들어주면, 해당 부서는 전용 CI/CD 클러스터를 쓰는 효과를 얻습니다. 이렇게 하면 멀티 테넌트 환경의 간섭(noisy neighbor) 문제를 줄이고, 비용 청구(Chargeback)도 팀 단위로 명확히 할 수 있습니다.

• 테스트 및 릴리즈 유연성 

Flex 팀(플랫폼 팀)은 여러 Flexbox를 활용하여 새 기능이나 인프라 변경을 실험하기가 쉬워졌습니다. 예를 들어 Flexbox 2에만 새로운 모니터링 스택을 적용해본다거나, Flexbox 3에서만 Argo 최신 버전을 테스트해보는 식으로, 다중 환경을 통해 점진적인 검증이 가능합니다. 이는 실제 서비스에 영향 없이 플랫폼 업그레이드를 시도해볼 수 있는 장점이 됩니다.

• 구성의 유연성

Flexbox마다 서로 다른 버전의 구성요소를 설치하거나, 심지어 서로 다른 구성요소 자체를 포함시키는 것도 가능해졌습니다. 예컨대 어떤 Flexbox에는 Argo Workflows 대신 GitHub Actions 러너를 내장시켜 특정 요구에 대응하거나, 한 Flexbox에는 Hub 클러스터를 두 개 포함시키는 등 맞춤 구성이 용이합니다. (물론 이러한 변형이 지나치면 눈송이(snowflake) 환경이 될 위험이 있어 관리에 주의가 필요합니다.)

• 강화된 감사 추적

Redirector를 통해 어떤 서비스 이벤트가 어떤 경로로 처리되는지 중앙에서 추적할 수 있으므로, 감사 및 모니터링 역량이 향상되었습니다. 각 GitHub 이벤트가 Redirector를 거치며 기록되기에, 문제 발생 시 이벤트 플로우를 추적하고 로그를 감사할 수 있습니다.

• 효율적인 운영

여러 Flexbox를 운용함으로써, 각 Flexbox의 자원 활용률을 최적화할 수 있습니다. 하나의 거대한 Flexbox를 최대치까지 몰아쓰는 대신, 여러 박스에 부하를 분산하면 적정 임계치 내에서 운영할 수 있어, 예측 불가능한 병목을 예방하고 전체 시스템 신뢰성을 높입니다.

• 블라스트 레디우스 감소

만약 하나의 Flexbox에 장애가 발생하더라도, 그 Flexbox에 매핑된 서비스들만 영향을 받습니다. 그리고 우리는 이미 Relocator로 서비스들을 신속히 다른 Flexbox로 옮길 수 있는 능력이 있기 때문에, 장애 상황에서 문제가 된 박스만 고립시켜 파급 범위를 줄일 수 있습니다. 이는 곧 더 나은 장애 복구 전략을 의미하기도 합니다 (유사시 빠르게 다른 Flexbox로 서비스 이전 후 문제 해결).

요약하면, Flex-in-a-Box 아키텍처는 Adobe에 수평 확장의 문을 열어주었고, 이를 통해 안정성과 유연성, 운영 효율성을 크게 높였습니다.

성능 테스트 결과: Adobe 팀은 앞서 언급된 Hub 클러스터 수직 확장 최적화와 Flex-in-a-Box 수평 확장 조치들의 효과를 검증하기 위해 여러 차례 벤치마킹 및 부하 테스트를 진행했습니다architecture.cncf.io. KubeCon EU 2024에서 발표된 자료에 따르면, 이러한 노력 덕분에 Flex 플랫폼은 5만 개 이상의 Argo CD 앱을 지원할 수 있는 수준으로 확장되었음을 확인했습니다. 또한 Argo Workflows(워크플로우 컨트롤러)의 확장성에 초점을 맞춘 블로그 글도 발행하여 세부 데이터를 공유했습니다. (참고 자료: “Argo Workflows Controller Scalability Testing on Amazon EKS” 블로그.)

아무리 좋은 아키텍처라도 트레이드오프(trade-off)는 있게 마련입니다. Flex-in-a-Box 도입으로 많은 이점을 얻었지만, 동시에 새로운 도전 과제와 리스크도 생겼습니다.

• 인프라 비용 증가
  

Flexbox를 추가할 때마다 추가적인 쿠버네티스 클러스터(Hub)를 운영해야 하므로, 인프라 비용이 증가합니다. 각 Flexbox는 자체 컨트롤 플레인을 가지기에, 여유 용량(buffer)까지 고려하면 단일 환경보다 비용이 더 들 수밖에 없습니다.

• 아키텍처 복잡도 증가

GitHub과 Flexbox 사이에 Redirector라는 새로운 컴포넌트가 생김으로써 전체 아키텍처가 복잡해졌습니다. Redirector 자체가 모든 Flexbox의 단일 의존성(SPOF)이 되므로, 이 부분의 고가용성 설계나 장애 대비도 추가로 고민해야 합니다.

• 용량 분할 기준 설정

각 Flexbox 별로 서비스 수용 한계치(threshold)를 어떻게 정하고 운영할지가 새로운 과제가 되었습니다. 예를 들어 Flexbox 1은 최대 N개 서비스, Flexbox 2는 M개 서비스로 제한할 것인지 등의 샤딩 전략과 모니터링이 필요합니다.

• 운영 지원 복잡도

플랫폼 운영팀과 지원팀 입장에서는, Redirector와 Relocator 같은 신규 컴포넌트의 동작을 완전히 이해하고 장애 조치 시나리오를 숙지해야 합니다. 예전에는 한 곳만 보면 되었지만 이제는 서비스가 여러 Flexbox와 Redirector를 거치므로, 문제 발생 시 원인 파악과 트러블슈팅 과정이 더 복잡해졌습니다.

• 사용자 경험 변화

서비스가 이관되면, 개발자 포털이나 CI/CD URL 등 일부 링크나 접속 경로가 변경될 수 있습니다. (예: Argo CD UI URL, Argo Workflows UI URL 등이 Flexbox별로 다를 수 있음.) 이러한 변경은 서비스 개발자들에게 혼란을 줄 수 있으므로, 명확한 공지와 안내가 필수입니다.

Adobe 팀은 위와 같은 단점들을 인지하고, 이를 완화하기 위한 운영 지침과 기술적 보완책을 함께 마련했습니다. 예를 들어 Redirector의 고가용성을 위해 다중 인스턴스 및 이중화, 각 Flexbox의 서비스 수는 일정 기준 이하로 유지, 이관 시 자동 리디렉션 페이지 제공 등입니다. 결국 아키텍처의 유연성과 운영 복잡성은 트레이드오프 관계이기에, 이를 어떻게 균형 잡을지가 앞으로도 중요한 과제로 남아 있습니다.

Flex-in-a-Box 아키텍처의 도입으로, Adobe는 앞으로 다양한 활용 시나리오를 모색하고 있습니다architecture.cncf.io. 몇 가지 잠재적 Use Case는 다음과 같습니다.

앞서 언급했듯이, 특정 조직이나 팀이 전담하는 서비스들이 많은 경우 해당 팀만을 위한 Flexbox를 제공할 수 있습니다. 이를 통해 다른 팀과 완전히 격리된 CI/CD 환경에서 노이즈 네이버 문제 없이 작업하고, 팀 단위 비용 측정/배분도 용이해집니다. 실제로 Adobe 내부에서도 몇몇 팀들이 자신들만의 전용 Flexbox를 요청했다고 합니다.

• 이러한 팀별 분리 운영은 클러스터 샤딩 측면에서도 유용합니다. 조직별/서비스 도메인별로 Flexbox를 분리하면, 각 Flexbox의 Argo CD가 모니터링해야 할 원격 클러스터 수도 줄어들어 성능 최적화에 도움이 됩니다 (현재는 모든 원격 클러스터가 Flexbox 1과 2에 모두 등록되어 있어, 추후 이를 개선할 계획입니다).

특정 도메인/기술 스택에 특화된 Flexbox를 운영할 수 있습니다. 예를 들어.

• Windows 빌드

Windows 애플리케이션을 빌드/배포하는 워크로드는 Linux 컨테이너와 많이 다릅니다. Windows 빌드에 필요한 도구(예: Windows 컨테이너 지원 등)를 갖춘 전용 Flexbox를 두면 효율적입니다.

• 데스크톱/모바일 앱

데스크톱 응용 프로그램이나 모바일 앱의 빌드 파이프라인은 별도의 대형 빌드 팜이나 시뮬레이터 환경이 필요할 수 있습니다. 이러한 워크로드를 위한 Flexbox를 분리하여, 일반 웹/서버 서비스와 격리할 수 있습니다.

• 클라우드 인프라 프로비저닝

Terraform 등을 활용한 인프라스트럭처 코드(IaC) 파이프라인이나 쿠버네티스 커스텀 오퍼레이터 기반 배포는 일반 애플리케이션 배포와 다르게 추가 권한과 리소스를 요구합니다. 이러한 작업을 수행하는 서비스들은 전용 Flexbox에 격리하여, 일반 워크로드에 영향을 주지 않게 할 수 있습니다.

• FaaS/WASM 등 신기술

컨테이너 외에도 서버리스 함수(FaaS)나 WebAssembly(WASM) 모듈 배포 등 새로운 유형의 워크로드가 등장하고 있습니다. 이들도 요구사항이 다르기 때문에, 별도의 Flexbox 환경에서 실험적으로 운영해볼 수 있습니다.

Flexbox를 사용 기술 스택별로 분리하는 것도 고려하고 있습니다. 예를 들어, 일반적인 Flexbox들은 Argo Workflows를 CI 파이프라인 엔진으로 쓰지만, 일부 서비스는 GitHub Actions를 선호할 수 있습니다. 이 경우 GitHub Actions 러너들을 내장한 Flexbox를 별도로 두어 그 서비스들만 거기서 빌드/배포하게 할 수 있습니다. 마찬가지로, Jenkins 등을 쓰는 레거시 파이프라인을 위한 Flexbox 등도 생각해볼 수 있습니다.

요약하면, Flex-in-a-Box 아키텍처는 Adobe에게 매우 유연한 CI/CD 인프라 구획화 전략을 제공하며, 다양한 상황에 맞게 커스터마이징된 플랫폼 경험을 선사할 잠재력이 있습니다.

Adobe는 Flex-in-a-Box 아키텍처를 기반으로 계속해서 플랫폼을 진화시킬 계획입니다. 몇 가지 미래 탐색 영역은 다음과 같습니다.

현재는 모든 원격 Kubernetes 클러스터가 Flexbox 1과 2 양쪽 Argo CD에 모두 등록되어 있습니다. 이로 인해 원격 클러스터 입장에서는 여러 Argo CD 인스턴스에 중복으로 관찰되는 부담이 있습니다. Adobe는 장차 서비스/조직별로 원격 클러스터를 분리 등록하는 등 더 효율적인 클러스터 샤딩을 구현하려 합니다. 예를 들어 특정 조직의 서비스는 Flexbox 2에서만 관리되도록 하여, Flexbox 1의 Argo CD는 그 조직의 클러스터들을 볼 필요 없게 만드는 식입니다.

앞서 초기 아키텍처 문제에서 지적된 바와 같이, 여전히 Flexbox 내부에서는 Argo CD와 Argo Workflows가 같은 클러스터에서 돌고 있습니다. 이를 개선하기 위해, Argo CD와 Workflows를 서로 다른 클러스터에서 동작시키는 방안을 고려 중입니다. 예를 들어 Argo Workflows는 기존처럼 Hub 클러스터에서 돌리되, Argo CD는 별도의 (물리 또는 가상) 클러스터에 설치하는 것입니다. 이렇게 하면 두 시스템이 컨트롤 플레인을 공유하지 않게 되어 성능 간섭을 줄일 수 있습니다. 이 새로운 Argo CD 클러스터는 Flexbox 내에 추가되는 두 번째 물리 클러스터일 수도 있고, 혹은 기존 클러스터 위에 띄운 가상 클러스터(vCluster)일 수도 있습니다.

Adobe는 자사의 이러한 플랫폼 기술을 오픈소스로 공개하는 것도 적극 검토하고 있습니다. Adobe는 CNCF의 CNOE (Cloud Native Operations Excellence) 이니셔티브에 참여하여 여러 기업들과 협력 중이며, 이들과 함께 Adobe Flex 플랫폼(혹은 그 일부)의 오픈소싱 방향을 모색하고 있습니다. 궁극적으로 Adobe 내부에서만 유용한 것이 아니라, 업계 전체에 도움이 될 수 있는 툴과 모범 사례를 공유하려는 취지입니다.

Adobe는 최근 “통합 CI/CD”라는 새로운 이니셔티브도 시작했습니다. 이는 현재 주로 컨테이너 워크로드에 집중된 Flex 플랫폼을 컨테이너 외의 다양한 소프트웨어 배포로 확대하고, 보안과 표준화 수준을 한층 끌어올리는 것이 목표입니다. 구체적으로

• 컨테이너 너머(Beyond containers): 모바일 앱, 정적 웹사이트, 데스크톱 앱, 서버리스 등 비컨테이너 시나리오도 지원하는 CI/CD를 구축.

• 기본 제공 보안(Security by default): 파이프라인 단계에 필수 보안 베스트프랙티스를 자동으로 적용하고 강제하여, 초기에부터 안전한 배포를 구현.

• 봉인된 포장도로(Sealed Paved Roads): 가장 흔한 사용 사례들에 대해 표준화되고 안전한 파이프라인 템플릿을 제공하고, 개발자들이 함부로 그것을 벗어나지 않도록 하는 것입니다. 이를 통해 조직 전반의 일관성, 규정 준수, 보안을 높입니다.

• 단순화된 워크플로우: 온보딩 속도를 높이고 “아이디어 → 코드 → 첫 배포”까지 걸리는 시간을 단축하기 위해 파이프라인 설정과 개발자 경험을 더욱 간소화합니다.

이러한 미래 계획을 통해 Adobe는 Flex 플랫폼을 더 넓은 범위의 소프트웨어에 적용하고, 개발자 생산성과 운영 품질을 한층 향상시키고자 합니다.

Adobe의 Flex 플랫폼을 구축하고 확장해 온 과정에서, 팀은 수많은 교훈과 통찰을 얻었습니다. 이를 요약하면 다음과 같습니다.

• 개발자 경험을 하나의 제품으로 여길 것
  

 Developer Experience(DX)도 기능적 요구사항 못지않게 중요하다는 인식이 필요합니다. Adobe는 Flex 플랫폼을 통해 DX를 제품(product)처럼 다루었고, 확장성, 안정성, 성능 등의 비기능적 요구사항(NFR)도 처음부터 철저히 고려해야 함을 깨달았습니다.

• 초기부터 미래의 규모를 계획

수평적/수직적 확장 계획을 미리 고민하고 아키텍처에 녹여놓는 것이 중요합니다. Adobe는 일정 시점까지 Flex Hub를 수직확장하는 데 집중했지만, 애초에 셀 아키텍처 개념을 적용했다면 더 수월했을 것입니다. 현재의 요구뿐 아니라 미래 2배, 5배, 10배 성장까지 견딜 수 있는지 염두에 두라는 교훈입니다.

• 샤딩 전략 수립

서비스나 테넌트를 어떻게 샤딩(분할)할지 일찍부터 고민해야 합니다. Adobe의 경우 조직별/서비스별로 Flexbox를 나누는 전략이 효과적이었지만, 다른 조직이라면 지역별 셀, 기능별 셀 등 다양한 기준이 있을 수 있습니다. 우리 시스템에 최적인 셀/샤딩 전략은 무엇인지 미리 구상해 두는 것이 좋습니다.

• 인프라 자동화(Flexbox 자동화)의 중요성

플랫폼 자체를 구성하는 인프라(Flexbox 등)를 자동화하는 노력을 초기에 기울일 것을 권고합니다. Adobe는 처음엔 수동으로 Hub를 구축했다가 뒤늦게 GitOps 자동화를 도입했는데, 처음부터 이를 갖췄다면 예측 가능성과 신뢰성이 훨씬 높았을 것입니다.

• 성능 모니터링의 선제적 실행

핵심 성능 지표들을 초기에 정의하고 꾸준히 모니터링해야 합니다. Adobe는 쿠버네티스 API 서버 부하가 심각해질 때까지 통계를 세심히 보지 못했고, 결국 문제가 터진 후에야 조치를 했습니다. 성능 지표를 미리 주시했다면 사용자에게 영향 가기 전에 선제 대응할 수 있었을 것입니다.

• K8s 컨트롤 플레인의 병목 인지

Kubernetes 컨트롤 플레인(K8s API 서버 & etcd)이 대규모 GitOps 시스템의 병목이 될 수 있음을 명심해야 합니다. Adobe는 Argo CD와 Workflows를 같은 클러스터에 둠으로써 컨트롤 플레인 병목을 악화시켰고, 이를 통해 배운 것은 가능하면 이러한 컴포넌트들을 분리 운영하고, K8s API 호출을 줄이는 방향으로 설계해야 한다는 것입니다.

• 장애 대비 및 서비스 이관 계획

재해/장애 상황을 가정한 시나리오를 사전에 준비해야 합니다. 클러스터 장애는 언제든 발생할 수 있으므로, 워크로드를 다른 클러스터나 Flexbox로 옮길 수 있는지, 이관 전후의 개발자 경험을 어떻게 유지할지 등을 미리 생각하고 연습해보는 것이 중요합니다. Adobe는 Relocator를 개발함으로써 이러한 장애 대비 능력을 내재화했습니다.

이러한 교훈들은 Adobe의 사례에 국한되지 않으며, 대규모 Internal Developer Platform을 운영하거나 Cloud Native CI/CD를 구축하려는 모든 팀에 시사하는 바가 큽니다. 핵심은 개발자 경험의 품질과 플랫폼의 확장성을 지속적으로 개선하는 방향으로 아키텍처를 진화시켜야 한다는 것입니다.

글로벌 대규모 사용자에게 서비스 하는 경험은 개발자의 생산성을 배가시키고, 결과적으로 기업의 비즈니스 경쟁력을 높여줍니다. Adobe의 Flex-in-a-Box 아키텍처 도입 사례는 이러한 개발자 경험 플랫폼을 유연하게 확장하여 급증하는 수요를 감당한 좋은 예시입니다. 셀 기반 아키텍처의 개념을 내부 CI/CD 플랫폼에 접목함으로써, Adobe는 현재뿐 아니라 미래의 다양한 요구 사항(Windows 빌드, 서버리스, 데스크톱/모바일, 정적 웹사이트 등)에 대비할 수 있는 견고한 토대를 마련했습니다.

Adobe의 사례는 쿠버네티스 기반 Internal Developer Platform을 운영하는 다른 기업들에게도 유용한 통찰을 제공합니다. 핵심은 필요한 때 과감히 아키텍처를 재설계하고, 자동화와 격리를 통해 확장성 문제를 해결한 점입니다. 물론 이러한 과정에는 어려움도 있었지만, Cloud Native 생태계의 오픈소스 도구들(Kubernetes, Argo, Backstage 등)을 적극 활용하고, CNCF 커뮤니티와 교류하며 모범 사례를 구축해나간 점은 인상적입니다.

궁극적으로, Adobe의 Flex 플랫폼 여정은 “개발자 플랫폼도 하나의 제품”이라는 철학 아래 지속적인 개선과 확장을 추구해온 이야기입니다. 이 글이 유사한 도전을 겪고 있는 국내 IT 리더 여러분께 하나의 참고가 되길 바라며, 클라우드 네이티브 시대의 플랫폼 스케일링 전략에 대한 이해를 높이는 데 도움이 되었기를 바랍니다.

• <(Adobe 개발자 플랫폼 Flex 아키텍처 확장 사례를 다룬 CNCF 기고 문서)>
• <(AWS 웰아키텍티드 가이드: 셀 기반 아키텍처 개념 설명)>
• <(클라우드 멀티테넌트 환경의 “시끄러운 이웃” 문제 정의)>
• <(오픈소스 개발자 포털 플랫폼 Backstage 소개)>
• <(Adobe CI/CD 솔루션 확장에 대한 KubeCon EU 2024 발표 영상)>
• <(Adobe의 GitOps 플랫폼 확장 사례에 대한 GitOpsCon 2024 발표 영상)>
• <(Adobe가 수행한 Argo Workflows 컨트롤러 확장성 테스트 결과 공유 블로그)>