이 글은 AWS re:Invent 행사의 한국어 세션에서 "우아한 형제들의 클라우드 여정" 이라는 제목으로 우아한형제들 기술이사 임정기님이 하신 발표를 간략히 정리한 글이다.

DNB

DNB(Digital Native Business)
: 컴퓨터 모바일 인터넷과 같은 디지털 환경을 생활처럼 사용하는 세대를 대상으로 비즈니스를 하는 기업들을 일컫는 말

AWS는 이렇게 DNB를 하는 기업들과 함께 이런 변화에 대해 발빠르게 대응하고 유연하게 움직이기 위해 팀을 구성하여 고객들을 지원한다.

우아한형제들에 대하여

우아한형제들은 좋은 음식을 먹고싶은 곳에서 라는 기업 비전을 가지고있는 대표적인 대한민국의 푸드테크 기업이다. 2010년 '배달의 민족'을 시작으로, 꾸준히 서비스를 확장했다. 2015년부터 2020년까지 5년간 총 6개의 서비스를 런칭했다.
2016년 AWS로의 All in Migration을 발표한 이후, 모든 온프레미스 환경을 클라우드로 migration했다. 2020년 11월부로 데이터 센터에 남아있던 금융권 워크로드를 모두 이관하게 되었다. 국내에서는 처음으로 모든 환경을 클라우드로 migration하는 사례가 되었다.

이번 발표에서는 지난 4년간의 과정을 간략히 설명한다.

서비스 확장을 지탱하기 위한 기술적 도전 과제

Challenge #1 서비스의 확장

Challenge #2 트래픽 증가

그림에서 보듯이 배달의민족은 점심과 저녁, 즉 하루 두번의 피크시간이 존재한다.
원하는 시간에 식사를 하는 것이 매우 중요했기 때문에 이런 트래픽에서도 서비스를 안정적으로 제공하기 위한 노력이 필요했다.

Technical Challenges

크게 세가지를 해결해야했다.

1. 서비스의 확장에 따른 가용성과 유연성 확보

2016년 AWS 클라우드로 전환시에는 몇개의 주요 앱들이 하나의 메인 DB를 사용하는 monolithic 아키텍쳐였고 메인 DB는 클라우드가 아닌 온프레미스 환경에서 운영되고있었다. 메인 DB는 수백개의 테이블과 수천개의 프로시저로 아주 복잡했기때문에 마이크로 서비스 단위로 주문하고, 서비스 중단 없이 마이그레이션하는 과정에서 많은 시행착오를 겪었다. 4년에 걸친 마이그레이션 과정에서 Aurora, ES, NoSQL 등도 적극적으로 사용했다.

따라서 현재 우아한형제들의 많은 서비스는 600개 이상의 마이크로서비스들로 구성된 아키텍쳐로 전환되었고, 각 마이크로서비스들은 도메인에 최적화된 가용성과 유연성을 확보하게 되었다.

2. DB의 부하를 줄여 안정적인 속도로 서비스를 제공하는 것

트래픽의 증가에 따른 DB 부하를 해결하기 위해 캐시 아키텍쳐로 전환을 시작했다. 데이터영역의 높은 복잡도는 마이크로서비스 아키텍쳐로 전환되면서 개선됐지만 마이크로서비스 아키텍쳐로 인한 내부 트래픽이 증가하면서 각 도메인별로의 DB 부하가 보통수준으로 증가했다.
이 문제를 해결하기 위해 자주 변경되지 않거나 실시간 반영이 필요하지 않은 데이터의 경우 캐시레이어를 추가하여 DB 부하를 최소화했다. 이 방법으로 트래픽이 증가해도 안정적인 서비스를 제공할 수 있게 되었다.

3. 서비스의 강한 결합을 제거하여 장애의 전파를 방지

마이크로서비스로 전환하면서 서로 API를 호출하는 구조가 매우 복잡해짐에 따라 도메인간의 강한 결합으로 인해 작은 실수나 이슈가 서비스의 큰 장애로 전파되는 경우가 종종 있었다. 이 점은 AWS에서도 '느슨한 결합'을 추천하고 있는데, 이를 최소화하기 위해 이벤트 드리븐을 도입했다. 처음에는 SNS, SQS, MQ 등 AWS Managed Services를 사용했고 보다 안정적인 이벤트 스토어를 제공하기 위해 자체 Kafka도 운영하고 있다.
뿐만 아니라 CQRS를 적용해서 조회와 변경의 시스템을 분리하여 상호간의 영향을 최소화하고 각각 도메인 목적에 맞게 개발하였다. 또한 지속적인 최적화를 통해 성능과 확장성을 높여서 보안적으로도 완전한 아키텍쳐가 되었다.

또 다른 문제

마이크로서비스, 캐시, 이벤트 드리븐, CQRS 등 다양한 아키텍쳐의 변화를 통해 문제를 해결했지만 또 다른 문제가 생겼다. 개발 조직은 DevOps 전략을 통해 각 도메인 특성에 맞게 빠르게 성장했지만 다음과 같은 문제들이 있었다.

• 표준화되지 않은 기술정책
• 중복된 시스템
• 개발 조직간의 사일로 현상(Silo Effect)

따라서 기존의 DevOps 문화를 유지하면서 이 문제를 극복하기 위한 SRE(Site Reliability Engineering)를 시작했다.

Silo Effect
: 조직 내 다양한 부서들이 다른 부서와는 서로 담을 쌓은 것 처럼 교류하지 않고, 자기 부서의 내부적인 이익만을 추구하는 현상

SRE는 표준화된 기술 정책을 수립하고 중복으로 개발되고있던 도구들을 플랫폼화했다. 플랫폼을 개발하면서 표준화된 기술 정책들이 자동으로 적용될 수 있게 했다. 대표적으로 배포, 모니터링 플랫폼을 시작으로 메시징 플랫폼, 인증 권한 플랫폼 등을 제공했다. 개발 조직에서는 이 플랫폼들을 사용해서 표준화된 보안, 인프라, 기술 정책들을 적용할 수 있었기 때문에 기존보다 비즈니스 개발에 더 집중할 수 있게 되었다.

해결 방안

대표 플랫폼 개발

표준화의 첫번째 미션으로 공통으로 사용하는 대표 플랫폼을 개발했다. 처음에는 AWS 서비스를 최대로 활용해서 표준화 정책이 쉽게 반영될 수 있게 했고 카나리 배포, 블루그린 배포와 같이 다양한 배포 전략을 제공해서 보다 안정적으로 서비스가 릴리즈될 수 있게 했다.

이제는 서비스의 개발 운영을 빠르고 안정적으로 할 수 있도록 컨테이너 환경으로 전환중이다. 이 과정에서 기존의 배포 플랫폼과 몇개의 서비스를 컨테이너 환경에서 시범 운영했던 노하우가 많은 도움이 되었다고 한다.

모니터링 플랫폼 구축

시스템 상태에 대한 가시성을 확보하기 위해 메트릭, 로깅 등의 모니터링 플랫폼을 자체적으로 구축했고 APM을 적극 돌입하여 시스템에 문제가 생기면 빠르게 파악했다.

APM(Application Performance Management) - 응용프로그램 성능 관리
: APM은 응용 소프트웨어의 성능과 서비스 이용성을 감시하고 관리하는 데 초점을 둔 시스템 관리 원칙을 일컫는다. 또, 운영 중인 시스템에 대한 응답시간과 같은 성능이나 처리량, 가용성, 및 기능적 무결성, 신뢰성을 확보하고 다운타임의 최소화 등을 통해 안정적인 시스템 운영을 위한 도구로써 부하량, 접속자 파악, 장애진단, 통계, 분석 등을 목적으로 하는 성능 모니터링 제품으로 정의할 수도 있다.

출처 - 위키피디아

개발문화 개선

시스템적인 문제들은 다양한 플랫폼을 사용함으로써 극복했지만 사일로 현상을 극복하기 위해서는 개발 문화를 개선해야했다. 그래서 SRE는 플랫폼을 제공하는 것에서 그치지 않고 도메인 개발팀과 함께 신뢰성 확보를 위한 다양한 활동을 하고있다.
대표적으로 아키텍쳐 리뷰, 변경 관리, 장애 관리를 통해 지속적으로 경험을 공유할 수 있는 환경과 문화를 만들어간다. 특히 SRE는 개발팀과 함께 장애의 책임을 공유한다.

AWS와 함께 많은 기술적인 도전을 하나씩 해결한 결과, 업타임 개선, 서비스 전달속도 향상, 디도스같은 분당 만배 이상의 트래픽을 소화할 수 있었다.

핀테크 클라우드 마이그레이션

우아한형제들은 2019년부터 핀테크 클라우드 마이그레이션에 대한 도전을 시작했다. 커머스의 기본이 되는 결제, 정산, 포인트, 서비스 외에도 간편결제 서비스인 배민페이와 선물하기 서비스 등을 제공해오고있다. 뿐만 아니라 배달앱 최초로 정산주기를 일주일에서 하루로 줄이는 등 고객의 니즈를 만족시키기 위한 핀테크 서비스를 위해 노력했다.
전자금융업 규제로 인해 주문 프로세스 끝부분에 있는 결제, 정산과 같은 핀테크 서비스는 온프레미스 환경에서 개발되고있었다. 따라서 앞에 설명한 아키텍쳐를 적용하기 힘들었다. 또한 전산 플랫폼이 AWS 클라우드 기반으로 만들어지면서 기존 온프레미스 환경을 지원하는데 어려움이 컸다.

하지만 2018 전자 금융 감독 규정이 개정되면서 핀테크 서비스도 클라우드를 사용할 수 있게 되었고, 핀테크 서비스를 클라우드 환경에서 사용하려면 두가지를 해결해야했다.

• 감독기관에 레퍼런스가 없는 클라우드 이용 지정 보고를 해야한다.
• 온프레미스 환경보다 높은 수준의 클라우드 보안 아키텍쳐가 필요하다.
  
  

클라우드 이용 지정 보고

클라우드 이용 지정 보고에는 두가지 문제가 있었는데, 첫째는 준비해야하는 서류가 많다는 것과 둘째는 레퍼런스가 없다는 것이었다. 그림에서 확인할 수 있듯이 준비해야하는 서류가 아주 많다. 발표를 맡은 우아한형제들 기술 이사 임정기님은 준비를 시작할때부터 관련 부서가 함께 고민하고 작성하는 것을 권장한다고 했다. 또한 준비서류 중 클라우드 사업자가 준비해야하는 문서와, 클라우드 이용자가 준비해야하는 문서를 사전에 정확하게 파악해야한다고 덧붙였다. 아래 보고제출 서류 준비시 몇개의 체크포인트들을 알고있으면 도움이 될 것이다.

• 전자 문서 교환 시스템을 통한 전자 공문 보고
• 전자 공문 등록 전 금감원 담당자와 사전 협의 가능
• 클라우드 이용일 7 영업일 이전 보고
• 중대 변경사항 발생 시 별도 보고 필요
  
  

온프레미스보다 높은 수준의 보안

클라우드에서 온프레미스보다 더 기술적으로 안전해야했기 때문에 접근 및 권한 관리, 그리고 안정적인 인프라와 클라우드 보안에 대한 고민을 시작했다. 온프레미스에서는 서비스별로 유기적 네트워크를 분리하고 인가된 사용자만 IDC에 출입할 수 있도록 관리하고있다. 마찬가지로 클라우드에서는 핀테크 서비스별로 AWS 계정을 분리하고, IAM을 통해 권한을 관리했다. 또한 KEYCLOAK과 AD를 이용하여 접근 및 권한 관리를 했으며 접근 관리를 강화하기 위해 IAM으로 필요한 최소한의 권한만 부여했다. 혹시 모를 보안사고 방지를 위해 pem키 생성 및 사용을 시스템적으로 차단했다.

코드로 인프라 관리

안정적인 클라우드 인프라를 운영하기 위해 코드로 인프라를 관리하고 프라이빗 네트워크 허브를 구축했다. 누가 작업하더라도 일관성을 유지해야했고, 변경에 대한 추적도 하기 위함이었다. 이것을 위해 테라폼 등의 기술을 사용했다. 그 결과 많은 인프라 변경을 빠르게 할 수 있었고, 형상 관리를 통해 인프라 변경을 쉽게 파악할 수 있게 되었다.

기존에는 네트워크 연동을 추가할 때마다 메시지 형태로 복잡도가 증가하는 구조였다. 이 구조에서는 복잡도가 높아지면서 작업에 필요한 시간이 증가하고, 실수확률 또한 증가했다. 하지만 새롭게 네트워크 허브를 구축한 후에는 복잡도도 낮아지고 관리 비용이 감소했다. 또한 신규 네트워크를 쉽게 연동할 수 있었다.

높은 보안 수준 유지

온프레미스 환경보다 더 높은 보안 수준을 클라우드 환경에서도 유지하기 위한 아키텍쳐가 필요했다. 예를 들면 클라우드 기반 보안 솔루션 적용, 로깅시스템 구축, 온프레미스와 같은 수준의 웹/앱 공격, 디도스, 봇에 대한 솔루션 등이다. 클라우드 환경에서는 인라인 구조로 보안 인프라를 구성하면 복잡도가 높아져서 장애 발생시 트러블 슈팅이 아주 어렵다.
그래서 AWS에서 제공하는 Managed Services를 활용했고, 부족한 부분은 클라우드 기반 보안 플랫폼 및 클라우드 워크로드 보호 플랫폼을 도입했다. 이런 보안 솔루션을 활용해서 클라우드 보안 아키텍쳐를 구현했다. 그리고 multi-account 환경에서 보안로그의 보관과 복원, 접근제어, 요구 접근에 대한 감사 추적 등이 필요했다. 이런 문제를 해결하기 위해 중앙 로깅 시스템 구축, SIEM과 같은 로그 분석 시스템을 통해 실시간으로 분석하고 있다.

다시 한번 말하지만, 이 글에 사용된 주제와 사진들은 모두 AWS re:Invent 행사의 한국어 세션에서 "우아한 형제들의 클라우드 여정" 이라는 제목으로 우아한형제들 기술이사 임정기님이 하신 발표를 간략히 정리한 글이다.