Application Modernization-MSA

 

대형 어플리케이션을 개발 및 운영하다 보면 여러 문제에 봉착하게 된다.

1. 특정 서비스에 사용자가 폭증하여 대형 트래픽이 발생하여, 장애가 나는 경우
2. 어플리케이션을 기능을 수정하여 운영에 배포 했는데 테스트 하지 못한 케이스 때문에 오류가 나는데, 사용자가 자주 사용하는 서비스여서 장애를 발생하는 경우
3. 특정 서비스의 코딩이 잘못되어 Out Of Memory 같은 오류를 발생시켜 서버에 Full GC를 발생시키는 경우

위의 문제 모두 개발 및 운영을 해본 어플리케이션 개발자 및 인프라 담당자의 경우 한번 이상씩은 겪어본 문제이고, 항상 주의하면서 개발 및 운영을 하고 테스트를 꼼꼼히 해서 문제가 없도록 엄청난 노력을 한다.

하지만 사람은 언제나 실수를 할 수 있고, 모든 예외 상황을 예측할 수 있는 능력이 없기 때문에 위의 상황을 100% 예방할 수는 없다.

이러한 상황에 대해서 IT부서 이외의 부서에 왜 오류가 났는지를 설명을 하며 사후 방지대책을 고려하여 프로세스를 보완을 하지만, 오류와 장애는 피할 수 없다.

 

필자가 운영을 하면서 자주 들었던 얘기는 왜 이체처리가 몰려서 시스템 부하가 생겼는데,

“왜 운영업무 처리하는 단말에 접속을 하지 못해요?"

“왜 장애가 났는데 사용자가 로그인을 못하죠? 로그인 프로그램 문제가 아닌데요?”

라고 물어봤을때 계정계 시스템이 문제가 생기면 영향을 받는다고 얘기를 한다. 그런데 IT부서 직원이 아닌 경우 위의 문제에 대해서 전혀 이해할 수가 없다. 윈도우에서 엑셀프로그램이 멈췄다고 해서, Outlook, 인터넷 등이 안되는 것은 아니니까…

사실 우리의 과제는 장애를 내지 않고 서비스 개선을 지속적으로 하고 새로운 상품과 서비스들을 출시하여 사용자의 경험이 좋게 하는 것이다. (사용자는 단순히 고객이 아닌 시스템을 사용하는 직원도 될 수있다.)

그렇다면 문제는 무엇인가? 해결할 방법은 없는가?

문제는 모놀리식한 어플리케이션의 구조 때문에 그렇다.

 

Monolithic Architecture

모놀리식 구조는 전통적인 구조로 특정서비스를 제공하는 서버에 모든 기능을 구현한 아키텍쳐이다. 예를 들어 아래 그림과 같이 은행의 계정계 BackEnd 서비스를 구성할 때에 수신업무, 고객업무, 여신업무 등의 모든 업무를 하나의 서버에 구현한 방식이다.

모놀리식 구조

장점

1. 개발이 용이하고 Java 프로그램인 경우 프로그램 재사용성이 높아 생산성이 좋다.
2. 테스트 시에 하나의 구조로 되어있어 End to End로 확인하기 용이하다.

단점

1. 시스템이 방대해지면 각 프로그램들의 영향도를 고려하지 않고 개발하면 장애가 발생하기 쉽다.
2. 작은 수정사항이 생겨서 수정하더라도 시스템 전체에 배포를 해야되고 배포의 시간은 시스템의 규모에 따라 증가한다.
3. 일부의 장애나 오류는 전체의 장애로 커질 확률이 높다.
4. 운영 유지보수가 어렵다.

위의 이유로 많은 회사들이 기술난이도 높음에도 불구하고 MSA를 선택하는 것 같다.

MSA(Micro Service Architecture)

과거부터 모놀리식 구조에 대한 문제점 인식과 이를 해결하기 위한 노력의 일환으로 MSA를 도입하고 있다.

MSA는 Micro Sevice Architecture의 줄임말로 각각의 서비스들이 서로 종속적이지 않고 독립적으로 수행하는 방식을 지칭하는 개념이다.

완전히 독립가능하기 때문에 각각이 다른 기술 스택이어도 사용이 가능하고 마이크로 서비스 단독으로 배포 및 서버관리를 할 수 있다.

MSA 구조

 

모놀리식 구조에 비해 MSA는 보다 더 복잡해 보인다. 서버 하나가 한 작은 서비스를 하나를 수행하는 것, 그리고 서로 독립적으로 수행하는 것이 특징이다.

장점

1. 특정 서비스의 장애는 그 서비스 만의 장애이다. 타 서비스에 영향을 주지 않는다.
2. 서비스의 단위가 모놀리식에 비해 작기 때문에 배포가 쉽다.
3. 컨테이너 기반으로 구현하면 배포 후 장애가 발생했을 때에 롤백이 쉽다.

단점

1. 모놀리식에 비해 복잡한 구조를 가지고 있으며, 개발난이도가 어렵다.
2. DB transaction 관리가 어렵다.
3. End to End 테스트가 어렵고 로그 분석이 어렵다.

시스템이 단위가 커지면 커질 수록 모놀리식의 경우 배포에 대한 시간이 늘어나고 어플리케이션의 영향도가 크기 때문에 수정에 대한 영향도 분석 등의 요인으로 생산성이 줄어들게 된다.

(자료출처 https://www.samsungsds.com/kr/insights/msa.html)

필자가 지금 재직 중인 케이뱅크는 이미 리소스 수는 몇만 단위는 우습게 넘어갔고, 각각의 클래스들이 거미줄처럼 얽혀있어서 복잡도는 엄청 높아져 있다. 모놀리식의 장점은 이미 사라진지가 오래이다.

MSA 기술

MSA의 기술의 핵심은 Micro Service들을 관리하고 서비스들을 독립적인 단위로 수행할 수 있게 하고, 서비스 수행을 통제하는 기술이 핵심이다.

Docker Container : Micro Service들을 독립적으로 수행할 수 있게 서버안의 서버를 가상으로 구성하게 하여 타 서비스와의 종속성 없이 서비스를 처리할 수 있도록 한다.

Netflix-Eureka API Discovery 서비스 : 수 많은 Micro Service들이 서로 통신할 수 있도록 관리하고 탐색하게 하는 서비스

Cloud API Gateway 서비스 : 서비스 시작 및 종료의 Gate역할을 수행하여 입력 및 출력에 대하여 통제 하는 서비스

Docker 컨테이너

컨테이너는 물리적인 서버 상에 논리적인 구획(컨테이너)를 만들고 어플리케이션을 작동시키기 위해 라이브러리나 어플리케이션을 모아 마치 별도의 서버인 것처럼 사용할 수 있게 만드는 기술이다. 서버안의 서버가 있게 하는 가상서버 기술이다.

도커 컨테이너

 

Netflix-Eureka API Discovery 서비스

• Application 서버의 Micro 서비스들을 관리하고 각 서비스들의 수행의 로드밸런싱 역할을 수행하는 서비스
• MSA는 수 많은 각기 독립적인 서비스들이 Docker 컨테이너기반으로 수행되고 있는데 이 서비스들은 수 많은 기동과 삭제를 반복하는데 이것을 사람이 관리할 수 없다. 이를 해결해주는 것이 Eureka 이다.
• Eureka의 기능은 주요기능은 서비스 탐색과 서비스 등록이다.
• Eureka의 주체는 Eureka 서버와 Eureka 클라이언트이다.

Eureka 클라이언트

1. MSA환경 위에서 수행되는 Eureka 서비스 외에 모든 서비스는 클라이언트이다.
2. 클라이언트가 기동될 때 서비스의 관련정보(IP, Port, 서비스명)이 등록된다.
3. 클라이언트들은 Eureka 서버가 보내준 각 Micro 서비스들의 정보를 Local환경에 저장되어있어 Micro 서비스들을 알고 있다.

Eureka 서버

1. Eureka 서비스를 의미
2. 각 Micro 서비스들의 클라이언트가 기동될 때 정보를 저장소에 등록하고 각 클라이언트들에게 지속적으로 전파한다.
3. 등록된 Micro 서비스들에게 주기적으로 heart beat를 보내서 정상적인지를 확인하고 정상응답을 주지 않으면 삭제되었다고 간주하고 저장소에서 제거한다.

Eureka 레지스트리 화면

 

Cloud API Gateway 서비스

• API Gateway는 클라이언트와 Micro 서비스 사이에 프록시(대리자) 처럼 위치하여 클라이언트로 온 요청을 라우팅하는 역할을 수행
• Micro 서비스들은 독립적인 서비스로 port가 전부 다른데, 만약에 수신입출금 서비스를 수행해야 한다고 가정하면 입출금 서비스 정보를 알아야하는데, 그럴 필요없이 Gateway 서비스에 요청하면 알아서 라우팅을 해준다.

API Gateway

 

API Gateway가 인입과 출력의 말단에 존재하기 때문에 여러 기능을 수행해 줄 수 있다.

• 인증 : 로그인 서비스 수행시에 JWT(JSON Web Token)을 발행하여 서비스 수행시마다 인증
• 모니터링, 로깅 : API 호출 모니터링을 통해서 응답시간 오류 호출횟수 등을 기록할 수 있다.
• 플로우컨트롤 : 필터 기능을 추가해서 신규소스와 이전소스의 트래픽을 제어하여 카나리 배포를 할 수 있다.(카나리 배포는 소규모 사용자 그룹에 변경 사항을 처음으로 배포하는 배포 전략)

위 기술로 계정계 특정 서비스를 MVP로 구현해 보았고 잘 수행되었다. MSA를 반드시 넷플릭스OSS(Netflix Open Source Software)로 해야되는건 아니다. 서비스 디스커버리와 게이트웨이 역할을 해주는 오픈소스는 많다.(이스티오 등) 여러가지 기술에 대한 검토와 적용을 통해 케이뱅크에 맞는 오픈 소스 도입과 체계를 마련해 갈 것이다.

MSA를 도입한 넷플릭스는 MSA를 구현한 이유를 “생존하기 위해서”라고 했다. 배민도 마찬가지 이유로 MSA를 도입했다고 한다. 수 많은 이벤트들이 수행되고 갑작스러운 일로 서비스를 사용하는 사용자가 많아지게 되었을 때, 빠르고 안정적인 서비스를 하려면 MSA는 필수이다.

사람들이 생각하기에 뱅킹서비스는 예측 가능하고 사용자의 인입도 일정할 것이라고 생각해서 MSA를 굳이 해야할 이유가 있을거라고 반문할지 모른다. 하지만 현재 수 많은 금융의 이벤트들과 여러 사업군들과의 금융 이벤트들로 인해 사용자가 갑자기 많아지는 경우가 매우 많다. 그때마다 장애와 지연되는 서비스로 사용자 경험이 나빠지게 할 수는 당연히 없다. 단순히 이것 뿐일까?

MSA를 도입하면 시스템 안정성 이외에도 생기는 이점이 더 있다.

Agile 개발문화

물론 DevOps 체계와 CI/CD(Continuous Integration/Continuous Deployment, 지속적인 통합/지속적인 배포)방식이 있어야 겠지만 모놀리식으로 구현되어있는 어플리케이션은 Agile한 DevOps를 구현할 수 없다. 배포하는데 몇 십분이나 걸리는데 DevOps가 제대로 동작할리가 없다.

CI/CD DevOps

 

MSA로 구현된 독립적인 서비스는 단위가 모놀리식에 비해 작기 때문에 배포가 빠르고 카나리 배포 등을 이용할 수 있기 때문에 변경된 서비스를 극히 일부 고객에게 노출시켜 반응을 확인하고 측정하여 보완하고 다시 반영하는 Agile한 개발을 할 수 있게 한다.

 

콘웨이의 법칙 : 조직구조가 소프트웨어의 구조를 결정

역콘웨이의 법칙 : 소프트웨어의 구조가 조직구조를 결정

 

Agile 개발 조직문화를 위해 엄청난 비용을 지불하면서 조직구조를 변경하고 컨설팅도 받는다. 조직을 바꾸고 교육한다고 사람들의 일 하는 방식은 쉽게 바뀌지 않는 것 같다. 하지만 개발환경을 바꿔버리면 개발환경에 맞게 바뀔 수 밖에 없다.

MSA 개발을 진행하면 위 문화를 갖는 집단을 덤으로 얻을 수 있다.

MSA의 여러 이점 때문에 금융권에서 MSA로 전환하기 위한 많은 프로젝트들이 시작되고 있다.

안정적인 서비스를 제공하고 민첩한 개발 문화를 갖고 싶은 건 모두의 바램일 것이고 그것을 구현할 방법 중 하나가 MSA일거라 확신한다. 하지만 어떻게 구현해 낼 것이냐는 모두의 숙제이다.

 

15세기~17세기 경에 자원확보와 미지의 지역을 탐험하기 위해서 많은 나라들이 알려지지 않은 지역으로 범선을 보냈다. 금융권에서 불고 있는 오픈소스들에 대한 사용과 진보된 아키텍쳐와 방법론, 개발문화 속에 우리는 대항해시대 때와 같이 IT 기술의 바다를 항해하고 있는지도 모르겠다.

 

 

케이뱅크와 함께 하고 싶다면 🚀