서버리스 아키텍처

서버리스 아키텍처(Serverless Architecture)

서버리스 아키텍처를 이해하는 것은 마치 "음식 배달 앱을 통해 원하는 음식을 주문하고 집에서 편안히 즐기는 것"과 같습니다.

우리는 직접 요리할 필요 없이, 원하는 음식을 선택해서 주문하기만 하면 됩니다.

여기서, 우리가 주목해야 할 점은,

요리하는 복잡한 과정을 거치지 않고도 원하는 결과를 얻을 수 있다는 것입니다.

 

마찬가지로, 서버리스 아키텍처에서는 개발자들이 서버를 직접 관리하는 데 드는 시간과 비용을 줄이면서,

애플리케이션의 개발과 운영에 더 집중할 수 있게 해줍니다.

 

[서버리스의 특징]

서버리스는 "서버 없음"을 의미하지 않습니다.

클라우드 제공 업체가 인프라 관리를 자동으로 처리하기 때문에, 

개발자 입장에서 관리할 서버가 없다 라는 의미로 서버리스라는 단어를 사용합니다.

이로써 개발자는 애플리케이션 로직과 비즈니스 가치에 더 집중할 수 있습니다.

 

[서버리스 아키텍처 구현하는 법]

서버리스 아키텍처를 실현하기 위한 방법은 다양합니다.

AWS Lambda, Google Cloud Functions, Azure Functions와 같은 서비스는 함수를 중심으로 서버리스 아키텍처를 제공합니다.

이들은 코드를 작은 함수 단위로 배포하여, 특정 이벤트에 반응하도록 설정할 수 있습니다.

 

여기서 "함수 단위로 코드를 실행한다는 것"은

개발자가 작성한 코드를 작은, 독립적인 함수 형태로 배포하고 실행한다는 의미입니다.

 

각 함수는 특정 작업을 수행하도록 설계되며,

특정 이벤트가 발생했을 때(파일이 업로드되는 것, HTTP 요청, 데이터베이스의 상태 변경 등) 자동으로 트리거되어 실행됩니다.

 

더 복잡한 애플리케이션의 경우, Docker와 Kubernetes를 사용하여 서버리스 환경을 구축할 수 있습니다.

Docker는 애플리케이션과 그 의존성을 컨테이너로 패키징하여, 어느 환경에서나 동일하게 실행할 수 있게 해줍니다.

Kubernetes는 이러한 컨테이너들을 자동으로 배포, 확장 및 관리해주는 시스템입니다.

 

이 조합을 통해, 개발자는 여러 서비스를 독립적으로 배포하고 관리할 수 있습니다.

 

[서버리스의 장점]

 

트래픽이 증가하면 자동으로 리소스가 조정되어 애플리케이션의 성능을 유지할 수 있으며,

반대로 사용량이 감소한다면 자동으로 축소되기 때문에 비용을 절약할 수 있습니다.

이처럼 실제로 사용된 컴퓨팅 리소스에 대해서만 비용을 지불하게 하므로, 불필요한 비용을 크게 줄일 수 있습니다.

 

또한 클라우드 제공 업체가 서버의 프로비저닝, 스케일링, 유지보수를 자동으로 처리해주기 때문에,

개발자는 코드 작성과 비즈니스 로직에 더 집중할 수 있습니다.

이는 신속한 기능 개발과 기존 기능의 효율적인 개선을 가능하게 합니다.

 

[서버리스의 단점]

콜드 스타트 문제가 발생합니다.

콜드 스타드란 함수가 처음 실행될 때 발생하는 지연 시간을 의미하는데,

이는 함수가 자주 호출되지 않아 "차가워진" 상태에서 새로운 요청이 들어올 때, 초기화 과정으로 인한 지연이 발생하는 상황을 의미합니다.

특히 성능에 민감한 애플리케이션에서 사용자 경험에 부정적인 영향을 미칠 수 있습니다.

 

서버리스 환경은 특정 클라우드 제공 업체의 기술 스택과 운영 환경에 종속되는 벤더 종속성의 문제가 발생합니다.

만약 서비스 이전이 필요한 경우 추가적인 작업과 비용 복잡도가 증가됩니다.

 

또한 개발자가 특정한 시스템 요구사항이나 커스텀 설정이 필요한 경우,

제공 업체의 API, 서비스 제약 사항, 그리고 가격 정책에 따라야 하기에 개발자의 서버 제어력이 제한됩니다.

 

MSA와 서버리스

MSA는 시스템을 작고, 독립적으로 배포 가능한 서비스들로 구성하여, 각 서비스가 특정 비즈니스 기능을 수행하도록 하는 아키텍처입니다. 

 

서버리스 아키텍처와 MSA는 서로를 보완합니다.

서버리스는 마이크로서비스의 개발과 배포를 더욱 단순화하고 가속화할 수 있는 환경을 제공하며,

MSA는 서버리스 환경에서의 운영을 더욱 유연하고 확장 가능하게 만듭니다.

 

이 조합을 통해 개발자는 인프라의 복잡성을 최소화하고 비즈니스 가치에 더 집중할 수 있는, 강력하고 유연한 시스템을 구축할 수 있습니다.

 

[MSA와 서버리스의 장점]

각 마이크로서비스의 배포와 확장이 용이해집니다.

이는 개발자가 각 서비스를 독립적으로 개발하고 관리할 수 있게 하여, 전체 시스템의 안정성을 향상시킵니다.

또한, 서버리스 환경에서의 자동 스케일링 기능은 각 마이크로서비스의 트래픽 변화에 신속하게 대응할 수 있게 해줍니다.

 

[MSA와 서버리스의 문제점와 해결 방안]

MSA 환경에서 각 서비스 간 통신은 네트워크 호출을 통해 이루어집니다.

이러한 네트워크 호출은 추가적인 지연 시간을 발생시킬 수 있고, 시스템의 복잡도를 증가시킵니다.

이를 해결하기 위해서는 API 게이트웨이와 같은 중앙 집중식 통신 계층을 도입하여, 서비스 간의 통신을 관리하고 최적화할 수 있습니다.

 

각 마이크로서비스가 자신만의 데이터베이스를 관리할 경우,

전체 시스템에서 데이터 일관성을 유지하는 것이 어려워질 수 있습니다.

분산된 데이터 관리 전략이 필요하며,

이벤트 소싱(Event Sourcing)이나 CQRS(Command Query Responsibility Segregation) 같은 패턴을 적용하여,

시스템 전반에 걸친 데이터 일관성을 유지할 수 있습니다.

 

위에서 서버리스의 단점에 대해 이야기하며 콜드 스타트에 관한 문제를 이야기 했었는데,

마찬가지로 사용 빈도가 낮은 함수의 경우 이 문제가 두드러질 수 있습니다.

이 문제 해결을 위해 함수의 초기화 시간을 최소화하는 경량화된 라이브러리의 사용, 함수를 정기적으로 호출하여 따뜻하게 유지하는 스케줄링 기법 등을 고려할 수 있습니다!