infrastructure-as-code

레거시 인프라 작살내고 하이브리드 클라우드 만든 썰 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 인프라의 비효율성을 극복하기 위해 오픈소스 기반의 OpenStack 프라이빗 클라우드를 직접 구축하고, 이를 퍼블릭 클라우드와 결합한 'Active-Active 하이브리드 클라우드' 환경을 구현했습니다. 단 2명의 엔지니어가 운영 경험 없이 시작했음에도 불구하고 자동화와 고가용성 전략을 통해 인프라 제어권을 100% 확보했으며, 결과적으로 어떤 환경에서도 즉시 배포 가능한 유연한 기술 기반을 마련했습니다. ### 1,997개의 라우팅이 보여주는 레거시 인프라의 한계 * 과거 인수한 인프라는 네트워크 장비가 아닌 개별 서버가 직접 라우팅 정보를 관리하는 비정상적인 구조로, 서버당 약 2,000개의 라우팅 경로가 설정되어 있었습니다. * 새로운 경로 추가 시 모든 서버를 일일이 수정해야 하는 관리 포인트의 과부하가 발생했으며, 이는 서비스 확장의 심각한 병목 현상이 되었습니다. * 초기에는 퍼블릭 클라우드 도입으로 대응했으나 비용 증가, 환율 변동, 하이브리드 DR 구성의 어려움 및 가시성 부족이라는 새로운 문제에 직면했습니다. ### OpenStack 기반 프라이빗 클라우드 내재화 * 상용 솔루션 대신 오픈소스인 OpenStack을 선택하여 기술 내재화와 유연한 인스턴스 타입(VM, Container, K8S) 대응력을 확보했습니다. * 부족한 운영 경험을 극복하기 위해 3가지 버전의 OpenStack을 수십 번 설치하고 장애 시나리오를 반복 재현하며 아키텍처 이해도를 높였습니다. * 로드밸런서인 옥타비아(Octavia)의 소스 코드를 직접 수정하여 비즈니스 요구에 맞는 로그 포맷을 생성하는 등 오픈소스의 이점을 극대화했습니다. ### 자동화와 모니터링을 통한 운영 효율 극대화 * Ansible과 Terraform 코드를 활용해 모든 자원의 라이프사이클을 자동화했으며, 골든 이미지를 통해 신규 인스턴스 생성 시간을 10초 이내로 단축했습니다. * Zabbix, Prometheus, Mimir, Grafana 등 다양한 오픈소스 툴을 조합하여 모든 메트릭을 수집하고, 실시간 알람 체계를 구축해 장애 감지 능력을 높였습니다. * 운영 인력의 한계를 극복하기 위해 CMDB와 연동된 봇(Bot)을 구현하여 인프라 현황을 실시간으로 조회하고 관리할 수 있도록 했습니다. ### 고가용성을 위한 다중 클러스터 및 Cluster API 전략 * 장애 발생 시 서비스 가용성을 즉시 확보하기 위해 서로 독립된 3개의 OpenStack 클러스터를 구축하고 평상시 Active-Active로 운영합니다. * 특정 클러스터 장애 시 트래픽을 즉시 차단하는 방식으로 복구 시간을 최소화했으며, 클러스터 간 의존성을 완전히 제거했습니다. * K8S 관리를 위해 Cluster API(CAPI)를 도입하여 쿠버네티스 클러스터 자체를 쿠버네티스 리소스로 관리함으로써 퍼블릭 클라우드 수준의 관리 편의성을 프라이빗 환경에서도 구현했습니다. 전통적인 금융 인프라의 보수성을 탈피하고 오픈소스 기술을 깊이 있게 내재화한다면, 퍼블릭 클라우드의 편리함과 온프레미스의 통제권을 동시에 거머쥘 수 있습니다. 인력 부족이나 기술적 난도는 자동화와 표준화된 도구(CAPI, Terraform 등)를 통해 충분히 극복 가능하므로, 비용 최적화와 기술적 가시성이 필요한 조직이라면 하이브리드 클라우드 전략을 적극 권장합니다.

수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기 (새 탭에서 열림)

토스페이먼츠는 수천 개의 API 서버와 배치 설정을 관리하기 위해 설정을 단순한 텍스트가 아닌 '진화하는 코드'로 정의하여 운영합니다. 복사-붙여넣기식의 중복 설정을 제거하기 위해 오버레이 아키텍처와 템플릿 패턴을 도입했으며, 이를 통해 오타나 설정 오류로 인한 대규모 정산 장애 리스크를 원천 차단합니다. 결과적으로 인프라 설정을 테스트 가능한 영역으로 끌어올려 대규모 하이브리드 클라우드 환경에서도 높은 안정성과 유연성을 확보했습니다. ### 실시간 API 서버: 오버레이와 템플릿의 결합 * **오버레이 아키텍처:** 설정을 `global`, `cluster`, `phase`, `application` 순서의 계층형 구조로 설계하여 하위 계층이 상위 계층의 기본값을 덮어쓰도록 구성했습니다. 이를 통해 공통 설정은 한 번만 정의하고 각 환경에 필요한 차이점만 관리할 수 있습니다. * **템플릿 패턴 도입:** YAML의 단순 오버레이만으로는 해결하기 어려운 긴 문자열(예: JVM 옵션) 내의 특정 값만 수정하기 위해 `{{MAX_HEAP}}`과 같은 변수 치환 방식을 사용합니다. * **동적 설정 주입:** 설정 파일 내부에 파이썬 스크립트를 삽입하여 랜덤 포트 생성이나 외부 API 호출을 통한 동적 값 할당이 가능하며, 클러스터 이름에 따른 조건부 로직을 적용해 복잡한 환경 변수 요구사항을 해결합니다. ### 배치 서버: DSL과 GitOps를 통한 단순화 * **Jenkins 기반의 단순화:** 대규모 정산 데이터를 다루는 배치 환경일수록 단순함이 강력하다는 원칙 아래, Jenkins를 활용하면서도 수동 조작의 단점을 보완하는 방향을 택했습니다. * **Groovy DSL 활용:** Jenkins의 웹 UI를 통한 수동 설정을 배제하고, Groovy 기반의 자체 DSL(Domain Specific Language)을 구축하여 수천 개의 배치 Job을 코드 형태로 관리합니다. * **GitOps 체계:** 모든 배치 설정을 코드 저장소에서 관리하고 CI/CD 파이프라인과 통합함으로써, 개발자가 직접 Jenkins에 접속하지 않고도 표준화된 환경에서 배치 작업을 배포할 수 있도록 개선했습니다. ### 인프라의 코드화와 검증 자동화 * **테스트 가능한 설정:** 설정값에 대한 오타나 논리적 오류를 방지하기 위해 설정 코드에 대한 유닛 테스트를 수행합니다. 이를 통해 수천 개의 설정 중 단 하나의 오타가 치명적인 금융 장애로 이어지는 것을 사전에 방지합니다. * **유연한 확장성:** 고정된 설정 체계에 안주하지 않고, 인프라의 변화와 개발자의 요구사항에 맞춰 설정 인프라 자체가 계속해서 진화할 수 있는 구조를 지향합니다. 단순히 설정 파일을 잘 작성하는 것에 그치지 않고, 인프라 설정을 애플리케이션 코드와 동일한 수준의 설계와 테스트를 거쳐 관리하는 것이 대규모 시스템의 안정성을 보장하는 핵심입니다. 초기에 다소 복잡해 보일 수 있는 오버레이나 DSL 도입은 장기적으로 중복을 제거하고 휴먼 에러를 막는 가장 확실한 투자입니다.