마이크로 서비스, 서버리스란? (MSA : Micro Service Architecture, Serverless)

서버 개발을 하다보면 여러가지 많은 기능들을 만들어야 되는데 이걸 하나의 프로젝트에 다 넣어서 개발하다보면 생기는 문제들이 있습니다.

일단 프로그램 안에 수많은 기능들이 들어있어서 뭐 하나 망가뜨리지 않으면서 개발하는게 어렵습니다.

신기능을 하나 개발했다고 해도 신기능이 잘 되는지 테스트하고 컴파일하고 배포를 해야하는데 프로그램이 크면 그 작업이 좀 오래 걸리기 때문에 개발자들이 애를 먹을 수 있습니다.

프로젝트가 크면 거기서 쓰는 프레임워크나 라이브러리 버전을 업데이트하는 순간 여기저기 오류가 나면서 대참사가 일어나는게 대부분입니다.

그로 인해 코드가 업데이트가 안되고 고여서 생기는 문제들이 있습니다. 소스코드가 너무 복잡해지다보니 새로운 개발자를 채용해도 그 사람을 코드에 적응시키는데 어려움이 있을 수 있습니다.

 

Micro Service Architecture

그래서 등장하게 된 것이 마이크로서비스 아키텍처라는 것입니다!

마이크로 서비스 아키텍처는 하나의 프로그램에 여러가지 기능들을 다 넣지 말고, 기능들을 잘게 잘라낸 다음에 하나의 독립적인 서비스로 만들어서 운영해도됩니다!

예를 들어 쇼핑몰을 만든다고 했을 때, 서버에 여러 기능들을 만들어놔야합니다. (장바구니, 결제, 주문..) 이걸 하나의 프로그램에 전부 쑤셔넣어서 개발하는게 아니라, 각각 독립적인 프로그램으로 만들어놓고 이걸 필요할 때 마다 동작시켜서 서버운영을 합니다. 

예를들어, 어떤 유저가 가입을 하고싶으면 회원관리서비스를 동작시키면 됩니다. 어떤 유저가 결제를 하고싶으면 결제서비스를 동작시키면됩니다. 근데 결제할때 재고파악을 먼저 해야한다고 하면 재고관리 서비스 요청을 먼저 하고, 결제 서비스를 동작시키면됩니다.

cf) 한곳에 모아놓고 개발하는것을  모놀리스(Monolith) 아키텍처라고 합니다.

 

마이크로서비스 형태로 개발하면 장점?

1. 기능 수정과 업데이트를 매우 빠르게 진행할 수 있습니다. 이것이 가장 큰 장점입니다. 기능 수정 같은 걸 하고 싶으면 예전처럼 큰 프로젝트가 아니라 작은 서비스 하나만 수정하면 됩니다.
2. 그렇기 때문에 기존에 쓰던 라이브러리나 프레임워크 버전 업하는것도 훨씬 쉽고 간단해져서 코드가 고여서 썩을일 적어집니다.
3. 서비스들이 서로 독립적으로 돌아가다보니까 이 서비스에서는 파이썬, 여기서는 자바 이런식으로 자유롭게 기술 스택을 선정해도 상관없습니다.
4. 트래픽이 몰리는 서비스가 있으면 그 서비스만 사이즈를 키울 수 있기 때문에 클라우드 자원을 효율적으로 관리할 수 있다는 장점도 있습니다. 

이러한 장점으로 큰 기업들은 마이크로서비스아키텍처를 도입해서 개발하는 경우가 많습니다.

마이크로서비스를 운영할 때 자주 쓰는 기술이나 툴들이 있습니다. 컨테이너같은거에 담아서 서비스를 배포할 수 있는 기술(docker)를 쓰기도 하고 컨테이너가 매우 많아지면 이걸 관리하기 위해서 쿠버네티스(Kubernetes) 같은걸 쓰기도 합니다. 서비스간의 메시지를 주고받을 때 빠르고 효율적으로 주고받기 위해서 kafka 같은것도 쓰고, 서비스들을 모니터링하기 위해 Prometheus 툴을 사용하는 경우도 있고, 서비스 배포를 자동화하고 편리하게 하기 위한 툴들도 사용하는 경우가 많습니다. 

 

그렇다고 무조건 마이크로서비스 아키텍처를 도입해야한다? 
마이크로서비스를 사용하게 되면 복잡도가 매우 증가합니다. 마이크로서비스는 전체적인 복잡도를 낮춰주는 툴이 아닙니다. 개발 복잡도는 낮춰주지만 운영복잡도가 높습니다!

마이크로서비스가 100개 1000개 있으면 위에서 언급했던 툴들이 거의 필수이기 때문에 이걸 관리하는 시간과 비용이 매우 늘어납니다.

그래서 개발자가 별로 없는 작은 회사들은 개발 시간보다 관리 시간이 늘어나기 때문에 개발에 쏟을 시간이 줄어들 수도 있습니다.

서비스간의 통신하는데도 어려움이 가끔 있습니다. 통신이 너무 많거나 그러면 좀 오래걸리고 누락되고 그런 경우들도 가끔 발생합니다. 어떤 서비스랑 통신을 해야하는지 한참 찾아야되는 경우도 있습니다. 어떤 버그나 이슈가 생겼을 때의 어떤 서비스가 문제인지 파악하는게 어려운경우도 있습니다.

그래서 언제나 장단점을 잘 고려해서 도입해야합니다.

 

그럼 프로그램 사이즈가 큰데 마이크로서비스로 전환? 
예를 들어서 스택오버플로 사이트는 한달에 1억명이 방문하는데 마이크로서비스아키텍처 도입을 안했다. 근데도 잘 운영되고 있습니다.

스택오버플로에서는 *스케일러블 모놀리스로 운영하고 있는데 이렇게하면 수많은 마이크로 서비스가 필요없을 수 있습니다.

* 스케일러블은 많은 양의 코어와 메모리를 동시 다발적으로 처리하는 고유의 내부 아키텍처 설계입니다. (자세한건 잘 모름)

 

현재 프로젝트가 좀 작은데 미래를 위해서 마이크로 서비스로 미리 도입을 하겠다?
굳이 그러지 않아도 된다. 나중에 코드를 일부분만 잘라내서 마이크로 서비스로 만드는 식으로 시작해도 됩니다. 코드를 짜다보면 복잡한 코드때문에 생산성이 저하되는 시점이 있는데 그 시점부터 천천히 도입을 시작하면됩니다. 아니면 마이크로 서비스 때문에 운영복잡도 같은게 늘어나는게 싫으면 *서버리스형태로 서비스를 배포하는 것도 하나의 방법이다.

 

Serverless

* 서버리스가 뭐지 서버가 없다는건가?

서버리스는 서버가 없다는 뜻이 아니고 직접 서버를 관리하지 않는 경우를 뜻합니다.

왜 서버리스가 탄생했나요? 
이전에 어플리케이션을 배포할 때는 직접 서버를 사야하는 시절이 있었습니다. 거실에 전원을 꼽아야했죠. 서버의 하드웨어, 소프트웨어 둘 다 관리했습니다. 정전되면 서버 다운되는거죠.. 누군가 전원을 뽑으면 웹 사이트 다운되고 .. 웹사이트의 트래픽이 증가했다? 서버의 메모리가 충분하지 않아서 열심히 뛰어가서 메모리를 사와서 서버에 꽂아야하던 시절이 있었단말입니다.. 모든것을 수동으로하던 시절이..

이때 아마존이 등장해서 EC2라는 것을 선보였습니다. 거실에 서버를 설치하는대신에 아마존에 돈을 내면 아마존이 사용하는 최신식 서버를 빌려서 사용할 수 있게 되었습니다.(정전이라던가 각종 사고 걱정 안해도됨) 서버가 작을까 걱정을 안해도되게되었습니다. 돈만내면 아마존이 스토리지 늘려줄테니말이죠. 우리는 돈내고 빌리면되는것입니다. 구글 아마존 마이크로소프트같은 큰 회사들이 서버 하드웨어 부분을 책임지고 관리해주는 시대가 온것입니다. 하지만 서버의 소프트웨어 관리는 직접해야됩니다. 하드웨어적인것만 빌리는거고 서버자체는 텅 비어있다는것이죠.  근데 이것도 은근 귀찮습니다. 업데이트도 해줘야되고, 보안도 봐야하고 데이터 백업 등등 할게 은근 많습니다. 이때 서버리스가 등장하게 되었습니다!

서버리스의 특징 및 장점
서버리스를 활용하면 백엔드를 서버에 올리는게 아니고 백엔드를 작은 함수단으로 쪼개서 직접 관리하지 않는 서버로 올립니다. (aws lamba 같은) 이게 서버리스의 가장 큰 특징입니다. 서버리스가 아닌경우 서버는 24시간 돌아가고 있습니다. 언제나 요청에 응답할 준비를 하고있습니다. 서버리스의 경우 우리가 업로드한 함수는 잠을 자고있습니다. 그러나 리퀘스트가 오는 순간 aws는 함수를 깨우고 요창한 작업을 수행후 다시 함수는 잠에 듭니다. 이거 서버리스의 혁명입니다. 즉 24시간동안 대기하지 않아도 됩니다. 그래서 엄청 저렴해졌습니다. 

이전의 경우에는 유저가 0명이든 100명이든 같은 돈을 내야했지만, 서버리스에서는 우리가 수행한 함수만큼만 돈을내면 됩니다.(함수가 잠들면 돈 안내도되고!) aws람다는 엄청 저렴합니다. 1백만개의 함수 수행을 20센트(현재기준 약 2만천원)이면 할 수있고 스케일 조정을 더 잘 할 수 있습니다. 갑자기 천명의 유저가 생기면 aws는 같은 함수의 복사본을 천개 만들어서 수행을 하고 유저들이 사라지면 잠이 드는 형식입니다. 

 

그렇다면 서버리스의 단점은?

1. 함수는 잠자고 있는데 리퀘스트가 와서 함수를 깨우는데 아무래도 시간이 걸립니다. 길진 않겠지만 어쨌든 시간이 걸립니다. 보통 항시 대기하고 있는 서버보다는 시간이 좀 걸립니다.(일어나서 작업을 해야하니까.. 1밀리세컨드정도? 느린건 아냐. 하지만 그 시간차도 허용되지 않는경우는 안되겠지..) 이런 경우때문에 aws람다의 경우 어떤 함수가 자주 쓰이는지 파악해서 해당 함수는 아예 잠들지 않도록 할 수 있습니다. 서버가 응답하는 시간이 걸릴 수 있다는게 단점!이라는거죠.
2. 두번째는 서버 제공자에 너무 의존하게된다는것입니다. 서버리스 백엔드를 asw에 배포했습니다. 한 서버리스에서 다른쪽으로 마이그레이팅하는것은 쉽지 않습니다. aws에서 서버를 빌렸다가 구글 클라우드로 이사가는건 쉽습니다. 하지만 서버리스에서 이사가는건 간단하지 않습니다. 서버리스로 작업하면 어플리케이션의 구조 자체가 바뀌게되기 때문이죠. 우리가 서버를 통제한다는 마인드에서 바뀌게됩니다.

 

그럼 누가 서버리스를 사용해야하는가?
사이드프로젝트하는 개발자 혹은 빠르게 프로토타입을 출시하고 싶은경우입니다. 서버리스로 작업하면 코드에만 집중하면됩니다. 설정은 신경끄고, 빠르고 쉽게 서버를 활용해서 제품을 내놓기 좋습니다. 서버 관리설정하는데 시간을 줄이고싶다면 서버리스를 사용해보면 좋습니다! (빠르게 제품출시가능하고 돈도 절약되므로..) 그러나 구조를 변경해줘야하기때문에 서버에 대한 통제를 잃을 수도 있습니다.

 

여기까지 간단하게 마이크로서비스 아키텍처와 서버리스에 관련해 알아보았습니다!

[출처]
https://youtu.be/ZRpsB3ODr6M?si=bTNYDwGU2kJDHdi_
https://youtu.be/ufLmReluPww?si=fGEqp-7EF8Ln4Mqu