현재 띵동이 운영하고있는 환경과, 배포, 그리고 겪었던 이야기들을 조금은 현실적으로 적어보려합니다.
이전 띵동의 Legacy System은 전통적인 Monolithic Architecture로 설계, 개발 되었습니다. 우리가 가장 비중있게 고민했던 이슈들은 다음과 같았습니다.
연관없는 도메인, 프로덕트들의 재배포(Domain Decoupling) 규모가 있는 시스템을 구축하고 코드로 구현할때, decoupling은 가장 중요한 이슈 입니다. 예를 들어 “가맹점” 에 대한 코드수정시, 앱과, 어드민, 가맹점 웹까지 모두 배포가 이뤄져야 했으며, 모든 프로덕트들을 한번에 Sync 맞추기가 상당히 어려웠습니다. 또한, 프로덕트 들이 가지는 책임의 영역을 넘어, 안정적인 코드들도 재 배포를 해야하는 상황이 자주 있었습니다.
CI/CD에 대한 필요성 및 인프라 복잡도 줄이기 개발 생산성을 저해하는 요인들을 찾아 줄이는것을 중요하게 생각합니다. 배포에 있어서 개발자가 개입하는 부분의 비중이 상당히 컸고, FTP, 또는 원격연결( Windows Server ) 로 변경된 부분에대한 파일업로드, 반영, 재시작 구조로 배포에대한 학습이 필요한 상황이었습니다. 또한 KT ucloud, AWS 를 사용하다보니, 클라우드에 대한 이중 이해도가 필요하고, 배포 후 테스트까지, 개발 외적인 부분에서 소모되는 비용이 높았습니다.
전사 소프트웨어 개발 프로세스 정리 필요(Requirement Engineering) 모바일/웹 서비스 회사들은 다양한 채널로 피드백을 받게 됩니다. 이때 요구사항을 어떻게 정리하고 반영할 것인가에 대한 체계가 없다면, 결국 개발팀에 업무 과중으로 돌아옵니다. 우리는 요구사항 장애 발생시 VOC 인입 => 메신저, 정산팀, 파트너스팀 => 개발팀 등 연쇄적인 컨택 포인트로, 모든 팀들의 업무 효율이 감소되는 이슈가 있었습니다. 띵동은 24시간 운영하는 서비스입니다. 다양한 요구사항을 효율적으로 정리하고, 장애를 신속하게 처리할수있는 새로운 프로세스가 필요했습니다.
우리는 더 쉽게 확장가능하고(scalability), 지속적으로 쉽게 배포 할 수있는 환경을 가지며(continuous integration), 안정적(stability)으로 운영할수있는 새로운 설계가 필요했습니다.
우리가 테스트하고, 고려 했었던 기술들을 간략하게 적어 보려고합니다.
Serverless AWS Lambda가 각광받기 시작하면서, 자연스럽게 접근하게 되었던것 같습니다. “인스턴스없이 서버를 만들수있다고?” aws-serverless-express 모듈을 사용하면, 정말 너무도 쉽게 배포가 가능한 수준이었습니다. Serverless의 매커니즘은 경이로울 정도로 매력적이고, 배포하기 쉬웠으나, Lambda의 Concurrency Limitation이 존재 하였습니다. 우리가 가져가야할 유연한 트래픽 설계를 위해서, 조금은 무리수가 있다고 판단하여 선택하지 않았지만, 분명 유용한 서비스임에는 틀림없어 보입니다.
Kubernetes — EKS( AWS ), GKE( Google Clound Platform) Dockerize로 Micro Service들이 구성되고, 이미지화된 서버를 배포한다는 매커니즘은 가장 핫하게 제시 되곤 합니다. 우리가 가장 좋은 설계를 가져가기 위해서는, 최대한 많은 옵션이 제공되고, 쉽게 관리될수있는 환경이라고 생각했습니다. Kubernetes가 가지는 직관적인 Dashboard와, Scale in-out, Rollback 메커니즘은 우리가 그리던 그림에 가장 근접했습니다. 다만, 조금은 셋업하기 어려운 환경과, AWS 의 단일화를 지향 하여 GKE는 배제되었고 EKS 베이스로 제공되는 다른 비슷한 서비스 들을 찾아 보기로 했습니다.
Fargate 우리가 실제로 운영 환경까지 셋업 하였고, 최종적으로 가져갈 서비스였습니다. Kubernetes 보다 배포환경 구성도 훨씬도 수월함에 큰 만족을 느끼기도 했습니다. 그러나 수많은 우리의 Micro Services( User, Order, Branch, AutoOrder, Messenger, ETC ) 들을 모두 커버하기에는, ECS 환경과 비교시 상대적으로 너무 높은 금액이 예상 되었습니다. 우리는 조금더, 고려해볼 필요가있었고, 결국 아래에서 소개될 ECS로 변경하여 운영하기로 하였습니다.
ECS( Elastic Container Service ) ECS는 Fargate 가 가지는 메커니즘은 동일합니다. 다만 EC2( Container Instance ) 베이스에서 운영하는 환경이므로, 추가적인 관리포인트가 조금은 생길수있습니다. 현재는 많은 부분 개선이되어 이전에는 존재하지 않았던, Container Instance Auto Scaling 도 컨트롤 할수있게되었으며, 관리적인 측면은 더이상 신경쓰지않아도 될수준으로 발전하였습니다. ECS를 채택하기까지 많은 고민이 있었지만, 우리가 지향했던 부분에있어서 가장적합한 서비스라고 판단되었고, 현재 운영에서 안정적으로 운영되고있습니다.
띵동의 시스템 아키텍처는 간략하게, 다음과 같이 구성되게 되었습니다.
띵동 시스템 아키텍처( ECS )
Service 단위로 Scale In-Out 되는 메커니즘은 MSA(Micro Service Archetecture) 구조를 채택하고 있는 띵동 서비스가 반드시 가져가야할 부분이었습니다. 유연한 확장으로 개발자가 개입할수있는 비용을 최소화 할수있게 되었습니다.
시스템 아키텍처가 구성된후,우리는 배포 자동화에 집중했습니다.
Service Update( ECS )
ECS 배포 자동화 셋업이 생각보다 쉽지 않았습니다. AWS-CLI로 Micro Services 들을 컨트롤 하다보니, 세부적으로 체크해야할 Shell Script 복잡도가 증가되기 시작했습니다. 다행스럽게도, https://github.com/silinternational/ecs-deploy 에서 제공되는 Script들은, 너무도 유용했으며, 더욱더 간결하고, 안전하게 배포할수 있게되었습니다.
띵동 서비스가 ECS로의 운영으로 전환된 다음, 상당부분 문제들이 해소되었지만, 긴급 배포나, 갑작스런 장애 발생시 ECS로의 배포보다 조금 더 빠른 배포방법이 필요하였습니다. 우리는 항시대기(Active Standby) 시스템을 생각하게 되었고, 하이브리드 방식의 서브 아키텍처를 통해 좀 더 안정적인 서비스 제공이 필요하였습니다.
Active Stanby
PM2의 배포 방식은 강력했습니다. ECS의 모든 서비스들의 배포가 8분정도 소요된다면, PM2 배포시 1분이내로 모든 서비스들을 업데이트할수있었습니다. Active Stanby는 ECS의 배포가 완전히 업데이트 되기까지, EC2 only 환경으로 잠시나마 변경되는 구조를 가지고, 현재 아주 유용하게 사용하고있습니다.
띵동의 Legacy System에서, 신규 시스템 아키텍처까지 많은 부분에서 변화가 있었습니다. 고객의 니즈는 증가하고, 기술은 빠르게 발전하며, 변화에 빠르게 적응해야 합니다.
띵동의 제품 개발팀은 언제나 비중있게 이슈사항 다루고, 다같이 고민하며, 지속가능한 조직입니다. 피드백은 언제나 환영합니다.
가입하기
