마이크로 서비스와 서버리스

서버리스는 무엇일까?

말 그대로 서버가 없다는 뜻이지만, 실제로 서버가 없이 백엔드 로직을 처리할 수는 없다.

서버리스는 서버의 소프트웨어적인 부분, 즉 보안, 업데이트, 백업과 같은 관리과정을 대신해 줌으로써 서버에 대한 걱정 없이 애플리케이션 개발에만 집중할 수 있도록 하는 서비스이다.

AWS의 EC2로 인해 서버를 하드웨어적으로 구축해야하는 부담을 덜어주었다면, 서버리스로 인해 소프트웨어적으로 관리해야 하는 부담을 덜어주었다.

 

마이크로 서비스는 무엇일까?

기존에는 프론트, 백, 데이터 베이스 개발팀으로 나뉘어 각자의 기능들을 개발하여 하나의 애플리케이션을 만들었었다. 이를 모놀리틱(Monolitic)이라 한다.

마이크로 서비스는 필요한 비즈니스 로직 별로 각 개발자들을 구성하여 하나의 독립된 서비스를 개발할 수 있도록 하였다. 이를 마이크로 서비스 아키텍쳐(Micro Service Architecture)라 한다.

성공적인 MSA를 위해 각 서비스는 원칙들이 존재한다.

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

---

서버리스와 마이크로 서비스는 어떤 관계가 있을까?

소프트웨어 개발에 앞서 방법론을 선택하는 일은 정말 중요한 일이다. 가용성, 확장성, 성능 등 고려해야 할 것들이 많지만, 확장성을 생각한다면 서버리스와 마이크로 서비스 두 방법이 있다. 서버리스와 마이크로 서비스의 특징을 바탕으로 차이점을 살펴보자.

 

차이점

	마이크로 서비스	서버리스
작동	각 서비스는 24/7 항시 대기 중	필요할 때만, 함수가 호출되어 실행됨
단위	서비스	함수
운영	내부 팀이 컴퓨팅 자원을 모니터링, 배포, 지원, 유지 함	AWS, MS 등 벤더사에게 위임함
비용	운영 팀이 필요하므로, 비용 발생	요청 수별로 요금이 부과되므로, 비용 저렴
런타임	제한 없음	제한 있음(Lambda는 한 함수당 15분을 넘길 수 없음)

두 방법은 차이가 커보이지만, 목표하는 방향은 동일하다. 목표는 기존 모놀리딕으로 개발했던 애플리케이션을 잘게 나누어 가용성과 확장성을 높이기 위함이다. 그래서 두 방법을 혼용하여 사용하는 경우도 있다.

 

혼용하여 사용하기

마이크로 서비스가 특정 상황에서 함수처럼 작동하게 설계하기 위해, 이벤트 트리거를 넣는 경우도 있다.

또한 서버리스의 각 함수가 통합적으로 작동하게 설계하기 위해, Amazon의 Step Functions를 사용하는 경우도 있다. 이때 여러 함수가 마치 마이크로 서비스의 하나의 서비스처럼 작동하게 할 수 있다.

 

서버리스 컴퓨팅의 장단점?

서버리스는 서버에 신경쓰지 않고, 애플리케이션 개발에만 집중하여 빠른 서비스 배포를 위한 개발팀에게 적합하다. 그러나 모든 소스를 AWS와 같은 벤더사에 위임하므로, 벤더사의 lock-down과 같은 위협이 항상 존재하며, 타 벤더사로의 코드 이동이 너무 어렵다.(자료구조가 완전히 다르다고 들었다.)

 

그래서 둘의 관계는?

마이크로 서비스를 케첩이라 한다면, 서버리스는 감자튀김이라 비유할 수 있겠다. 둘은 같이 먹으면 맛있지만, 감자튀김을 꼭 케첩에 찍어먹지 않고 머스터드 소스에 찍어먹을 수 있는 것처럼, 마이크로 서비스와 서버리스는 항상 함께 쓰여야 하는 것은 아니다.

---

AWS에서 제공하는 서버리스는?

이 예시는 AWS에서 제공하는 ToDo 웹 어플리케이션 아키텍쳐이다.

애플리케이션을 API 기능별로 나누어 각 Lamda에 함수 형태로 올려놓았다. 그리고 API gateway를 연결하여 필요한 API 요청 별로 서버를 깨우고 사용할 수 있게 구성하였다.

 

AWS 공식문서를 참고하면 컴퓨팅, 애플리케이션 통합, 데이터 스토어별로 제공되는 서비스를 만나볼 수 있다.

---

서버리스는 무상태성(Stateless)이다?

위 ToDo App의 아키텍쳐를 보면, Todo를 불러오는 getTodo 요청을 보내면 ToDo API에 의해 getTodo 함수가 입력된 람다로 안내된다. 해당 람다는 서버 실행 후, 요청에 대한 응답을 처리하고 다시 잠든다. 그렇기에 사용자는 어떠한 파일이나 디스크를 함수에서 저장하고 실행했다 해서 다음에도 있을 거라 보장할 수 없다. 왜냐하면, 각 람다는 다른 컨테이너 상에서 실행되기 때문이다. 

마치 http 프로토콜이 지닌 특성과 비슷하다.

---

참고

https://www.techmagic.co/blog/serverless-vs-microservices-which-architecture-to-choose/

Serverless vs Microservices - Which Architecture to Choose in 2022?

https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9

What is Serverless Architecture? What are its Pros and Cons? | HackerNoon

https://www.sumologic.com/blog/microservices-vs-serverless-architecture/

Microservices vs. serverless architecture | Sumo Logic