E4NET

MSA와의 지난 1년 본문

E4.Tech/IT Technology

MSA와의 지난 1년

E4. 2021. 8. 24. 15:31

지난 2020년에 저는 2개의 사업에 참여했습니다.

첫번째는 모카드사의 온라인결제와 모바일앱을 위한 구조 개선 사업으로 Spring Cloud Nexflix 모델을 적용할 것을 제안하고, 파일럿 테스트를 거쳐 운영환경 개선과 함께 고부하중에도 안정적 서비스를 제공하는 인프라 구성에 성공했습니다. 
단, 기 운영중인 RDBMS의 설계를 변경하지 않는 범위였기에, 고객에게 MSA이지만 MSA가 아니라는 것을 인지시키곤 했습니다.

두번째는 협력사의 AWS위에 MSA로 구현한 라이브커머스 앱 개발 사업이 성능 문제로 인해 오픈이 연기되고 있는 상황에서 긴급 지원 요청을 받고 투입되어 2달 가까이 참여해서 성능 문제 진단과 개선 작업을 진행했습니다.

MSA가 Cloud, DevOps 등과 함께 화두가 된 지도 조금 지났고, 11번가, 쿠팡 및 배민 등 대형 유통사가 MSA로 구축했다는 뉴스도 조금 지났습니다. 
이런 잘 알려진 레퍼런스가 나타나면서 점차 MSA 전환하고자 하는 요구가 발생하고 있는 반면 전반적으로 구축에 필요한 기술 이해도는 아직은 보편화되지 않은 단계인 것 같습니다.
MSA기술을 실무에 적용시킨 두 사업을 통해 MSA를 어떻게 구성해야 하는 지, 어떤 것을 피해야 하는 지를 확인할 수 있었습니다. 
그 중 몇 가지를 이 글을 통해 공유하고자 합니다.

1. DA는 ‘RDB만 DB다’하고 개발자는 SQL타령 

MSA 는 특징 중 하나가 데이터 분리임에도 불구하고, 이에 대한 데이터 관점에서의 실효적인 정보나 전문가가 없는 것으로 보입니다.

PMO : 구매 목록 화면 속도가 느려요
FRONT개발팀 : 구매목록에서 상품명때문에 매 건마다 상품API 호출하느라 느려요. SQL 로 테이블 JOIN 하면 빨라지니까 JOIN하게 해주세요.
AA/TA : 그건 MSA 가 아니에요.
API개발팀 : 상품ID 배열로 조회하는 API 추가했어요. 그걸로 해보세요.
DA : ......

실제 프로젝트에서 있었던 대화이며, 각 파트 모두 서로에게 불편해 하는 상태가 되는 상황이 되곤 했습니다. 
이는 마스터정보와 NoSQL DB까지 포함한 영역에 대한 데이터 구성에 대한 지침을 제시할 전문 인력의 필요성을 느끼게 했습니다. 

2. 어설픈 AA와 공통 개발팀이 빚어낸 대참사

두번째 사업에서는 심각한 성능 저하 문제가 있었습니다. 
부하를 발생시키면서 분석해보니 FRONT서버(Tomcat)는 서비스가 밀리면서 응답속도가 현저히 떨어지는 데 반해, API서버(Undertow) 는 거의 부하가 없는 상태였습니다. 
원인은 API서버는 Non-Blocking 서버로 설정되어 있는데, FRONT서버에서 API서버 호출 시 Non-Blocking 통신을 하지 않고 있었습니다.
API서버 호출을 위한 공통 모듈의 소스를 확인하니 WebClient 를 사용한 Non-Blocking을 시도하는 듯 보였지만 일괄적으로 block 메소드를 호출하여 결과적으로 Blocking 통신이 되고 있었습니다.
보통 Non-Blocking 서버의 Thread-Pool 은 코어별 1~2개 정도를 설정하는 데 반해, Blocking 서버의 Thread-Pool 은 기본값이 200개 일 정도로 차이가 있습니다. 2개의 입구에서 한명씩 줄줄이 끊임없이 들어오게 하려했는데, 200명을 동시에 쏟아둗는 데서 발생한 병목이었습니다.
이를 수정하려면 Spring MVC 형태가 아닌 Spring WebFlux 로 개발을 전면적으로 다시 해야 하는 상황이었습니다.
결국 Non-Blocking을 포기하고 Blocking 통신으로 하도록 설정을 바꾸고 성능테스트를 진행하면서 지표를 맞출 수 밖에 없었습니다.

3. 영리한 Netflix

Non-Blocking 통신은 적은 리소스로 많은 트래픽을 감당하는 장점이 있지만, Spring MVC에 비해 아직 숙련된 개발자가 많지 않고, 안정적으로 운영할 수 있는 운영자도 적습니다.

첫번째 사업에서 적용한 Spring Cloud Nexflix 모델에서 서비스 진입점 역할을 하는 API Gate-Way 는 Zuul 서버로 구성합니다.
Zuul 서버는 Non-Blocking 으로 서비스를 받아 API에 분산시키고, API서버는 전통적인 Spring MVC Blocking 서비스로 구현합니다.
고객 접점에서는 API Gate-Way 를 통해 Non-Blocking 장점을 취할 수 있었고, API 는 개발 생산성을 고려하여 쉽고 빠르게 배포할 수 있는 장점을 취할 수 있었습니다. 

단, Gate-Way 를 어떤 설정 수치로 몇대를 운영할 지 결정하기 위해, 
한달 가량 부하 테스트를 지속적으로 수행하면서 많은 실패를 경험해야 햇습니다.

4. 어디선가 오류가 발생했는데, 찾을 수가 없다.

첫번째 사업에서는 우리 회사의 OWLOG 를 통해 로그데이터를 수집, 검색하도록 구성하였습니다. 
하지만 이를 사용하기 위해서 예상보다 많은 서버(VM)와 대용량 스토리지의 증설이 필요하게 되었습니다.

작게 쪼개진 API 서버, Gate-Way, Front서버 등 다수의 서버가 자동으로 Scale-Out 되는 환경에서, 어디서 오류가 발생했는 지 찾아내는 건 쉬운 일이 아닙니다. 장애 원인 파악이 늦어진다면 제아무리 배포가 빠르고 용이하다 하더라도 아무 의미가 없을 것입니다.
MSA 시스템 구성을 하고 안정적인 운영을 위해서는 로그 분석과 모니터링을 위한 추가적인 비용이 반드시 고려가 되어야 합니다. 

이상 MSA에 대해 경험을 바탕으로 얻은 제 생각을 정리해 보았습니다.
작성하다 보니 짧은 분량의 글로 설명하기 힘든 내용이었음을 깨달았으나, 마감 시간의 압박으로 인해 돌이킬 수 없었습니다.
언젠가 기회가 되면 이에 대해 우리 개발자들과 함께 토론해 볼 기회가 있었으면 좋겠습니다.

감사합니다.

PS. 
매년 7월 둘째 주 수요일은 ‘정보보호의 날’ 입니다. 
2009년 7월 7일 DDoS 공격을 계기로 제정된 법정기념일입니다.
타인의 정보를 다루는 우리 개발자는 더욱 정보 보호의 중요함을 새기었으면 합니다.

'E4.Tech > IT Technology' 카테고리의 다른 글

퇴직연금 수익률 어떻게 되세요?  (0) 2021.08.25
MSA와의 지난 1년  (0) 2021.08.24
I Love Spring!  (0) 2021.04.09
마이 데이터, 마이 데이터 사업이 뭐지  (0) 2021.03.04
공정하다는 착각  (0) 2021.02.04
체리와 보안  (0) 2020.11.30
0 Comments
댓글쓰기 폼