[reinvent 2024] Mercado Libre 엔지니어들이 Amazon EKS를 사용하여 NoOps 경험을 어떻게 달성했는지

들어가며

목차

목차는 아래와 같습니다.

1. 플랫폼 엔지니어링에 대해서
2. 운영 모델 및 과제
3. 내부 개발 플랫폼 (IDP) 구현 이점
4. 모범사례
5. Mercado Libre’s 플랫폼 Fury 소개
6. Amazon EKS를 활용한 Fury Compute 서비스
   
   

플랫폼은 이미 새로운 개념이 아니며, 많은 산업에서 플랫폼을 만들어 제품을 만들어 가고 있다고 이야기 합니다.

플랫폼 엔지니어링 이란

플랫폼은 셀프 서비스 API, 도구, 서비스, 지식 및 지원으로 구성된 기반이며 매력적인 내부 제품으로 설계됩니다.

또한 플랫폼은 내부 개발자를 위한 제품으로 인식해야 한다고 이야기 합니다.

개발팀은 계속적으로 다양하고 많은 요청을 운영팀에 하게 되엇고 이로 인해 운영 팀은 다양한 요청에 압도되어 회사를 확장하기 어려움을 가지게 됩니다.

또 개발팀과 운영팀의 관점의 차이를 이야기 하고 있습니다. 개발팀은  자율성을 가지고 싶어 하지만 운영팀은 표준과 거버넌스를 원하게 됩니다.

이 상반된 입장의 균형을 찾는 것을 플랫폼 엔지니어링이라고 이야기를 합니다. 플랫폼 엔지니어링은 양쪽을 모두 돕는 역할을 합니다.

플랫폼의 이점 3가지는 아래와 같습니다.

1. 속도 : 플랫폼으로 개발자가 코딩을 시작하고 배포하는 시간까지를 단축 가능하게 만듭니다.
2. 거버넌스 : 플랫폼 내부에 보안, 신뢰성, 확장성을 일부 구현하여 개발자가 인프라 세부 사항을 고민할 필요가 없게 만듭니다.
3. 효율성 : 한 곳에 중앙 집중화 하여 비용을 관리할 수 있고, 멀티 테넌트 환경을 관리하여 비용 절감을 할 수 있습니다. 팀의 비용도 포함됩니다.

플랫폼 도전 과제

플랫폼을 도입할 때 4가지 도전 과제가 있습니다. 

첫 번째는 플랫폼의 소유자를 명확하게 정의를 해야 한다는 것입니다. 일반적으로 플랫폼 개발팀을 이 책임을 집니다.

두번째는 추상화 수준입니다. 플랫폼은 어디서 시작해야 하는지에 대한 명확한 정의가 없습니다. 그러기 위해서는 각 팀과 논의를 하고 합의를 해야 합니다.

세번째는 고객과 대화를 하고 플랫폼을 도입하여 고객과 지속적으로 대화하고 지속적으로 지원을 해야 합니다. 내부 교육에도 투자하고, 좋은 문서화 작업을 해야 하며, 웹사이트나 동영상등으로 제공하는 것도 고려애 햐 합니다.

네번째는 문제 해결 부분입니다. 플랫폼을 도입하였는데, 문제가 발생하거나 디버깅이 필요할 때 문제를 해결할 수 있도록 모니터링 툴 과 문제 해결 툴에 투자하는 게 중요합니다.

모범 사례

모범사례에는 6가지를 이야기 하고 있습니다.

1. 고객과 함께 구축하십시오  ( 개발자들과 지속적으로 연락을 취하고 협력 )
2. 모든 것을 한꺼번에 하려고 하지 마세요 ( 작은 문제 하나를 해결하는 플랫폼으로 생각하면서 성장 시켜 나가세요 )
3. 모든 워크로드에 맞는 하나의 크기는 없습니다. ( 각 애플리케이션이 다르게 구성되어야 하므로 다양한 옵션을 제공해야 합니다. )
4. 탈출구를 제공하세요. ( 모든 개발자들이 이 플랫폼을 사용하는게 아니기 때문에 다양한 기술을 사용하게 탈출구를 제공해야 합니다. )
5. 문서화와 교육의 중요성 ( 좋은 문서를 개발자들에게 제공을 하는 것이 중요하며, 교육 및 훈련, 비디오등의 자료를 제공해야 합니다. )
6. 플랫폼을 제품처럼 다루세요.

Mercado Libre’s 플랫폼 Fury 소개

Mercado Delivery 회사는 16,000명이 IT 부서, 35,000개의 마이크로서비스를 관리, 하루에 23,000회의 배포를 수행하는 라틴 아메리카에서 선도적인 전자상거래 및 금융 서비스 회사입니다.

Fury는 내부 개발 플랫폼(IDP) 이며 10년 동안 구축된 시스템입니다.

개발자들이 전체 개발 생애 주기 동안, 즉 코드에서 프로덕션까지 도움을 주고 있습니다. 오늘날 Fury는 30개 이상의 서비스를 제공하며, 대부분은 셀프 서비스 방식으로 제공됩니다. 이 서비스들은 대부분 추상화된 형태로, 클라우드 비용 절감, 회사 차원의 보안 표준 적용, 인지 부하 감소, 기술 생산성 향상 등을 돕습니다. 이 모든 것은 노옵(NoOps) 스타일로 이루어지고 있다고 합니다.

Fury 추상화 구조를 보여주는 이미지입니다.

1단계는 Fury를 통해서 애플리케이션을 생성하며, 2단계는 코드를 Git에 푸시를 하면 Fury를 통해서 빌드된 이미지를 생성합니다.

3단계에서 API를 통해서 관리를 위한 사이카를 같이 배포를 수행합니다.

예로 Key Value 데이터베이스를 사용할 때 Fury가 추상화 형태로 인터페이스가 되어 있으므로, Apache Cassandara 에서 DynamoDB 전환하는데 개발의 문제가 되지 않는다고 합니다.

Fury Computing 모델

기존의 Fury는 EC2 Compute Service를 사용하였지만 Application 하나당 1대의 EC2가 필요로 하였기 때문에 자원 낭비와 유휴 상태의 인스턴스가 발생했다고 합니다.

그래서 EKS를 도입을 하였으며 아래와 같은 장점을 가졌다고 합니다.

1. 추상화된 컴퓨팅 레이어: Fury 는 클러스터와 Kubernetes의 세부 사항을 알 필요 없이 API를 통해 동작
2. 클러스터 기반 데이터 플레인 : 클러스터를 중요도와 범위 유형에 따라 분리하여 효율적으로 배치
3. 불변 인프라 적용 : EKS 클러스터의 업그레이드를 하더라도 동일한 인프라를 구성

Fury를 통해서 Yaml 파일도 수정 할 필요가 없고 Control Plane/ Data Plane을 제어할 필요도 없고 인지적 부담도 없어졌다고 합니다.

결론

Fury를 적용하여 99.95% 의 가동 시간을 지원하며, NoOps 전략을 사용함으로 써 혁신하고 빠르게 전환할 수 있게 되었다고 합니다.

EKS와 NoOps 전략으로 컴퓨팅 비용을 30% 이상 절감하였다는 것은 굉장히 놀라운 수치입니다.

이 세션을 통해서 좋은 내부 플랫폼의 중요성을 배울 수 있었으며, 우리도 좋은 플랫폼을 만들/활용 해 나갈 수 있게 준비를 해야 겠습니다.