적응하기 힘든 속도로 소프트웨어 아키텍처는 상당한 변화를 겪어왔고 현재 그 속도는 더욱 가파르게 진화하고 있습니다.
개인적인 생각으로 큰 변화로 다가왔고 앞으로 많은 영향을 끼친 아키텍처는 서버리스 였다고 생각합니다.
그렇다면 서버리스란 무엇이고 무슨 이점때문에 사용하는것일까요?
서버리스 컴퓨팅 이란 무엇인가요?
서버가 있지만 서버가 없는것처럼 개발하고 운영한다.
처음 서버리스에 대해 접했을 때, 이전 회사의 CTO님이 말씀해주셨고 지금와서보면 가장 적합한 설명이라 생각합니다.
말 그대로 특정 요구사항에 대해서 해결을 위한 개발만 하고 그 외의 다른 부분은 크게 신경 쓰지 않아도 관리가 되는 아키텍처입니다.
즉, 개발자는 서버에 대한 인프라를 관리할 필요가 없으며, 필요한 코드만 작성하고 해당 코드만 배포합니다.
무엇이 다른가요?
이전 회사에서 모놀리식 기반의 서버를 운영했고, 마이크로서비스를 점차 도입하다 나왔으며 현재 회사에서는 서버리스를 운영하고 있는 찍먹 개발자의 지극히 개인적인 입장에서 각 아키텍처의 장단점에 대해 써보겠습니다.
모놀리식
장점
- 간단한 구조: 하나의 서버 운영으로 모든 기능을 구현할 수 있습니다.
- 개발 및 유지보수의 용이성: 하나의 서버로 개발 및 유지보수가 간단합니다.
단점
- 확장성의 한계: 애플리케이션의 크기가 커지면 확장이 어려워질 수 있습니다.
- 장애의 전파: 하나의 컴포넌트의 장애가 전체 시스템에 영향을 미칠 수 있습니다.
- 기술적 부채: 시간이 지남에 따라 기술적 부채가 쌓일 수 있습니다.
마이크로서비스
장점
- 모듈화: 각 기능을 독립적으로 개발하고 배포할 수 있습니다.
- 확장성: 필요한 서비스만 확장할 수 있습니다.
- 기술적 다양성: 각 마이크로서비스는 독립적으로 기술 스택을 선택할 수 있습니다.
단점
- 운영의 복잡성: 여러 개의 서비스를 관리해야 하므로 운영이 복잡해질 수 있습니다.
- 데이터 일관성: 여러 서비스가 동작하기 때문에 데이터 일관성을 유지하기 어려울 수 있습니다.
- 테스트의 어려움: 여러 서비스 간의 테스트가 복잡해질 수 있습니다.
서버리스
장점
- 비용 효율성: 사용한 만큼만 과금되므로 비용을 효율적으로 관리할 수 있습니다.
- 확장성: 자동으로 확장되므로 트래픽 증가에도 대응할 수 있습니다.
- 유지보수의 용이성: 서버 관리와 업그레이드 등에 대한 걱정이 없어져 개발자는 코드에 집중할 수 있습니다.
- 빠른 배포: 코드를 더 빠르게 개발하고 배포할 수 있습니다.
- 자동화된 관리: 인프라 관리가 자동화되어 개발자는 인프라에 대해 신경 쓸 필요가 없습니다.
단점
- 제한된 실행 환경: 서버리스 환경에서는 실행 환경이 제한되어 일부 라이브러리나 환경 변수를 사용하기 어려울 수 있습니다.
- 모니터링 및 디버깅의 어려움: 코드 실행과 관련된 모니터링 및 디버깅이 어려울 수 있습니다.
- 플랫폼 종속성: 특정 클라우드 사의 플랫폼에 종속성을 띈다.
- 콜드스타트: 하나의 세션이 종료 된 후 일정 시간이 지난 후, 함수 실행시 큰 지연시간이 발생한다.
서버리스, 모놀리식 아키텍처, 마이크로서비스 아키텍처는 각각 장단점이 있으며, 사용하는 상황에 따라 적절한 아키텍처를 선택해야 합니다. 서버리스는 비용 효율성과 개발 생산성을 높일 수 있지만, 실행 환경의 제약과 모니터링의 어려움을 고려해야 합니다.
다만, 서버리스의 경우 이전글에서 설명한 aws cdk와 같은 iac의 등장과 발전으로 인해 1,2,3번의 단점은 충분히 해결 되어 가고 있다고 생각이 듭니다. 하지만 콜드스타트의 경우, 요청이 들어왔을 때만 실행 시키는 서버리스의 컨셉상 가장 지금까지 해결되지 않고 있는 문제점 입니다.
콜드스타트의 해결방법은 없는건가요?
물론 각 클라우드사에서도 해결방법을 제시하고 몇가지 대표적인 방안이 있습니다.
aws의 람다를 기준으로 말씀드리면
1. lambda snapstart
함수의 실행 환경을 실행 시마다 빌드 및 함수 실행의 과정을 거치는것이 런타임 실행전 필요한 실행 환경 시점을 snapshot 형태로 caching 하여 런타임을 실행하는것을 뜻합니다.
다만, 이 컨셉상 java만을 지원하고 있고 당연하게도 python, node의 경우 지원하지 않고 만약 지원한다 하더라도 해당 언어의 특성상 큰 성능 개선은 되지 않을것입니다.
2. warmup
aws lambda의 경우, cold start가 발생하는 시점은 람다 함수를 실행하고 이후 요청이 들어오지 않고 5분이 지난 시점입니다.
즉, cold start를 발생 시키지 않는 방식은 5분이 지나기전에 최소 1회씩 계속해서 함수를 실행 시키는 방식입니다.
물론, 원하는 문제는 해결되겠지만 서버리스의 사용 이유중 큰 장점인 비용 효율성 측면에서 결국 이점을 챙기지 못하는 문제가 발생합니다.
3. scale up
단순합니다. cpu와 ram 사용량을 늘리면 어느정도 개선이 됩니다.
당연하게도 불필요한 과금은 지속되고 기본적인 cold start에 대한 부분의 직접적인 해결책은 아니라고 생각이 듭니다.
그래서 해결책이 무엇이냐고요?
개인적인 의견으로는 현재로써는 답은 없다고 생각됩니다. 여러 방식을 제안하고는 있지만 이러한 노력에도 불구하고 큰 성능 개선 사항은 없고 cold start로 인한 문제가 지속해서 발생한다면 당장은 다른 아키텍처를 고려해보는것이 정답이라고 생각됩니다.
그저 서버리스의 특성상 각자 사용하는 클라우드 플랫폼에서의 개선을 기다리는게 답이라는 생각이 듭니다.
결론
서버리스는 현재 가파르게 성장하고 있으며, 앞으로 더 많은 기업들이 서버리스를 채택할 것으로 예상됩니다.
시장 동향을 보면 현재 AWS, Azure, Google Cloud를 중심으로 한 경쟁이 치열하게 벌어지고 있으며, 이를 통해 서버리스 서비스의 품질과 다양성이 증가할 것으로 기대됩니다. 앞서 말한 큰 문제점인 cold start또한 각 기업들이 문제 파악을 하고 있고 지속해서 성능 개선에 대한 노력을 기울이고 있기 때문에 조만간 개선 될것이라 생각듭니다.
새롭게 마이그레이션 하는 서비스라면 한번 서버리스 아키텍처 도입을 고려해보는것 아주 좋은 선택이라고 생각됩니다.
찐 결론) 서버리스에 대한 빌드업은 끝났다!! 다음글부터 cdk 폭탄글 우수수 떨어집니다!
'기술 > Devops' 카테고리의 다른 글
"aws cdk" 누구냐, 넌? (1) | 2024.04.27 |
---|---|
aws(2)VPC(Virtual Private Cloud) (0) | 2022.04.19 |
aws(1)S3(Simple Storage Services) (0) | 2022.04.19 |
도커(4)-이미지 (0) | 2022.01.19 |
도커(3)-도커 컴포즈 (0) | 2022.01.17 |