2019.02.11

서버리스 컴퓨팅의 3대 문제점과 해결 방법

Peter Holditch | InfoWorld
서버리스 컴퓨팅이 대세다. 누구든 이미 구축했거나, 구축을 고려하거나 둘 중 하나에는 속한다. 지금 동참하지 않으면 뒤처지게 될지도 모른다.

이렇게 서버리스가 화제인 이유가 무엇일까? 서버리스 컴퓨팅은 시스템 확장을 위해 필요할 때 서버 리소스를 시스템에 적용할 수 있게 해주는 인프라를 제공한다. 즉, 수도나 전기처럼 현재 부하의 필요에 따라 컴퓨팅 성능을 소비할 수 있다.

따라서 런타임에서 개별 서버를 신경 쓸 필요가 없다(솔직히 처음부터 아무도 신경 쓰지 않았다). 규모의 경제를 통해 클라우드 서비스 업체에 비용 효율적으로 대규모 서버를 아웃소싱할 수 있지만, “서버리스” 인터페이스는 계약을 최소화함으로써 이 아웃소싱 관계를 최대한 간소화해준다.

ⓒ GettyImagesBank

많은 사람들의 즉각적은 반응은 서버에 연결했던 차트, 트래픽 지표, 경보를 개별 서버리스 함수와 관련된 차트, 트래픽 지표, 경보로 교체하는 것이다. 그러나 이 방법으로는 근본적인 애플리케이션 관리 문제를 해결하지 못한다. 아무도 서버에 신경을 쓰지 않는 것과 마찬가지로, 아무도 서버리스 함수에 따로 신경을 쓰지는 않기 때문이다.

사람들이 신경 쓰는 것은 시스템이 사용자에게 제공하는 서비스 수준이다. 이는 모니터링이 유용해야 하고 잘못될 가능성이 있는 요소에 초점을 맞춰야 함을 의미한다. 서버리스 맥락에서는 “서버 용량 소진”이라는 개념이 사실상 없으므로 “잘못된다”는 것은 대부분 물리 법칙을 위반하려는 시도를 의미한다.

그렇다면 일반적인 서버리스 문제는 무엇이고, 어떤 방식으로 드러날까? 서버리스 배포와 관련하여 만연한 대표적인 세 가지 문제와 이 문제를 완화하는 방법을 살펴보자.
 

콜드 스타트 비용

서버리스 시스템과 관련하여 자주 언급되는 사안이다. 서버리스 제공업체는 사용률을 최대화하기 위해 비활성 함수를 완전히 종료하는 방법을 택하는 경우가 종종 있다. 부하가 재개될 때 이 함수의 시작 비용이 응답 시간에 영향을 미치게 된다. 하나의 비즈니스 함수가 상호 연결된 다수의 서버리스 함수로 구성되면 이 영향도 누적될 수 있다.

해결법은 많은 사용자가 핑(ping)을 통해 함수가 활성 상태인지 여부를 확인하는 것이다. 체인으로 연결된 서비스 네트워크에서 이 방법을 효과적으로 적용하려면 서비스 간의 엔드 투 엔드 관계를 파악해서 종속성 체인의 모든 서비스가 활성 상태를 유지하도록 해야 한다. 따라서 비즈니스 트랜잭션의 엔드 투 엔드 추적이 필수적이다.
 

쓰로틀링

서버리스 플랫폼에서는 서버리스 함수가 실행하는 동시 요청의 수가 계정과 개별 함수, 두 가지 수준에서 모두 제한되는 경우가 많다. 일단 동시 실행 제한에 도달하면 이후의 사용자 요청은 대기열에 추가되고, 이로 인해 응답 시간이 길어진다. 사실상 무제한인 컴퓨팅 리소스 풀을 쓰로틀링한다는 것이 얼핏 납득이 되지 않을 수 있지만, 쓰로틀링은 무제한 비용 청구가 발생하지 않게 해준다. (용량 비용은 소비한 양에 따라 계산된다는 것을 잊지 말아야 한다.)

해결책은 임계값을 높이는 것이다. 또는 최소한 응답 시간 및 동시 사용 측면의 비함수 요구 사항을 충족하도록 임계값을 설정한다. 이번에도 마찬가지로 정확히 무엇이 쓰로틀링되었는지, 최종 사용자 환경에 쓰로틀링이 어떤 영향을 미쳤는지 정확히 파악하기 위해 엔드 투 엔드 가시성이 필요하다.
 

컴퓨팅과 무관한 병목 현상

서버리스 환경의 모든 병목을 제거하면, 함수는 동시 요청을 수에 제한없이 지원한다. 그러나 이렇게 해서 문제가 해결됐다고 생각한다면 착각이다. 실상은 문제의 위치가 바뀐 쪽에 가깝다. 조만간 함수는 어디선가 상태를 지속해야 하는 상황에 처하게 된다. 그 지점이 어디인지에 따라 오히려 문제가 더 커질 수도 있다. 얼마 안 가 데이터를 읽거나 쓰려면 기다려야 하고, 무제한으로 확장된 람다는 모두 데이터 액세스를 기다려야 하고, 이러한 비생산적인 대기 시간에도 비용은 청구된다.

함수가 이와 같이 대기하는 정확한 이유는 영구 저장소에 따라 다르다.

- 클라우드 데이터 스토리지 : 클라우드 데이터 서비스의 탄력성은 계속 높아지는 중이지만, 여전히 동시 읽기 및 쓰기 볼륨을 기반으로 리소스를 구성해야 하는 경우가 많다.

- 전통적인 시스템 : 모든 함수가 연결되어 있으며, 서버리스 기업 사용자의 상당수는 서버리스 함수로 기존 시스템을 래핑한다(메인프레임인 경우도 있고, 일반적인 서버 기반 배포인 경우도 있음). 임계값을 높여서 함수 확장을 허용하기는 쉽지만, 이 경우 쉽게 확장할 수 없는 백엔드에 가해지는 부담 역시 폭증하기 쉽다.

백엔드 시스템이 이론상의 최대 부하를 처리할 수 있도록 보장하려면 함수 쓰로틀과 병행해서 백엔드를 튜닝해야 한다. 이렇게 하면 처음부터 끝까지 원활한 시스템 작동을 보장해 불필요한 비용과 고객 불만을 방지할 수 있다. 경우에 따라 여러 시스템이 여러 위치에서 액세스할 수 있도록 데이터를 복제해야 할 수 있다. (물론 이 경우 데이터 관리 복잡성 증가, 데이터에 비일관성이 발생할 위험이라는 비용이 따라온다.)

이번에도 마찬가지로, 트랜잭션 수준에서 시스템을 통과하는 엔드 투 엔드 흐름을 이해하는 것이 중요하다. 그래야 프로덕션의 병목 지점을 파악해 경보를 보내고 튜닝을 위해 시스템을 종합적으로 분석할 수 있기 때문이다.
 

서버리스 운영은 데브옵스

물론 “나는 개발자다! 내가 왜 함수도 아닌 이 이상한 배포 문제에 신경을 써야 하는가?”라고 반문할 수 있다.

하지만 서버리스가 갖는 가장 큰 의미는 이제 구성이 코드(또는 최소한 코드의 일부)라는 점이다. 개발자가 서버리스 환경의 프로덕션에 제공하는 것은 함수 조각이 아니라 전체 패키지다.

즉, 과거에는 IDE를 사용해서 프로덕션 문제를 디버깅했지만 서버리스 환경에서는 성능 관리 솔루션에 익숙해지는 것이 좋다. 어쨌든 “버그”의 최소 절반은 배포와 관련된 버그일 수 있기 때문이다. 더 이상 “그쪽(즉, 운영 팀) 잘못”이 아니다. 시스템의 운명은 전적으로 개발자의 손에 달려 있다. 그리고 이 문제를 해결하는 데는 애플리케이션 수준의 엔드 투 엔드 가시성이 필수적이다.

*Peter Holditch은 앱다이내믹스(AppDynamics)의 수석 제품 책임자이다.
editor@itworld.co.kr


2019.02.11

서버리스 컴퓨팅의 3대 문제점과 해결 방법

Peter Holditch | InfoWorld
서버리스 컴퓨팅이 대세다. 누구든 이미 구축했거나, 구축을 고려하거나 둘 중 하나에는 속한다. 지금 동참하지 않으면 뒤처지게 될지도 모른다.

이렇게 서버리스가 화제인 이유가 무엇일까? 서버리스 컴퓨팅은 시스템 확장을 위해 필요할 때 서버 리소스를 시스템에 적용할 수 있게 해주는 인프라를 제공한다. 즉, 수도나 전기처럼 현재 부하의 필요에 따라 컴퓨팅 성능을 소비할 수 있다.

따라서 런타임에서 개별 서버를 신경 쓸 필요가 없다(솔직히 처음부터 아무도 신경 쓰지 않았다). 규모의 경제를 통해 클라우드 서비스 업체에 비용 효율적으로 대규모 서버를 아웃소싱할 수 있지만, “서버리스” 인터페이스는 계약을 최소화함으로써 이 아웃소싱 관계를 최대한 간소화해준다.

ⓒ GettyImagesBank

많은 사람들의 즉각적은 반응은 서버에 연결했던 차트, 트래픽 지표, 경보를 개별 서버리스 함수와 관련된 차트, 트래픽 지표, 경보로 교체하는 것이다. 그러나 이 방법으로는 근본적인 애플리케이션 관리 문제를 해결하지 못한다. 아무도 서버에 신경을 쓰지 않는 것과 마찬가지로, 아무도 서버리스 함수에 따로 신경을 쓰지는 않기 때문이다.

사람들이 신경 쓰는 것은 시스템이 사용자에게 제공하는 서비스 수준이다. 이는 모니터링이 유용해야 하고 잘못될 가능성이 있는 요소에 초점을 맞춰야 함을 의미한다. 서버리스 맥락에서는 “서버 용량 소진”이라는 개념이 사실상 없으므로 “잘못된다”는 것은 대부분 물리 법칙을 위반하려는 시도를 의미한다.

그렇다면 일반적인 서버리스 문제는 무엇이고, 어떤 방식으로 드러날까? 서버리스 배포와 관련하여 만연한 대표적인 세 가지 문제와 이 문제를 완화하는 방법을 살펴보자.
 

콜드 스타트 비용

서버리스 시스템과 관련하여 자주 언급되는 사안이다. 서버리스 제공업체는 사용률을 최대화하기 위해 비활성 함수를 완전히 종료하는 방법을 택하는 경우가 종종 있다. 부하가 재개될 때 이 함수의 시작 비용이 응답 시간에 영향을 미치게 된다. 하나의 비즈니스 함수가 상호 연결된 다수의 서버리스 함수로 구성되면 이 영향도 누적될 수 있다.

해결법은 많은 사용자가 핑(ping)을 통해 함수가 활성 상태인지 여부를 확인하는 것이다. 체인으로 연결된 서비스 네트워크에서 이 방법을 효과적으로 적용하려면 서비스 간의 엔드 투 엔드 관계를 파악해서 종속성 체인의 모든 서비스가 활성 상태를 유지하도록 해야 한다. 따라서 비즈니스 트랜잭션의 엔드 투 엔드 추적이 필수적이다.
 

쓰로틀링

서버리스 플랫폼에서는 서버리스 함수가 실행하는 동시 요청의 수가 계정과 개별 함수, 두 가지 수준에서 모두 제한되는 경우가 많다. 일단 동시 실행 제한에 도달하면 이후의 사용자 요청은 대기열에 추가되고, 이로 인해 응답 시간이 길어진다. 사실상 무제한인 컴퓨팅 리소스 풀을 쓰로틀링한다는 것이 얼핏 납득이 되지 않을 수 있지만, 쓰로틀링은 무제한 비용 청구가 발생하지 않게 해준다. (용량 비용은 소비한 양에 따라 계산된다는 것을 잊지 말아야 한다.)

해결책은 임계값을 높이는 것이다. 또는 최소한 응답 시간 및 동시 사용 측면의 비함수 요구 사항을 충족하도록 임계값을 설정한다. 이번에도 마찬가지로 정확히 무엇이 쓰로틀링되었는지, 최종 사용자 환경에 쓰로틀링이 어떤 영향을 미쳤는지 정확히 파악하기 위해 엔드 투 엔드 가시성이 필요하다.
 

컴퓨팅과 무관한 병목 현상

서버리스 환경의 모든 병목을 제거하면, 함수는 동시 요청을 수에 제한없이 지원한다. 그러나 이렇게 해서 문제가 해결됐다고 생각한다면 착각이다. 실상은 문제의 위치가 바뀐 쪽에 가깝다. 조만간 함수는 어디선가 상태를 지속해야 하는 상황에 처하게 된다. 그 지점이 어디인지에 따라 오히려 문제가 더 커질 수도 있다. 얼마 안 가 데이터를 읽거나 쓰려면 기다려야 하고, 무제한으로 확장된 람다는 모두 데이터 액세스를 기다려야 하고, 이러한 비생산적인 대기 시간에도 비용은 청구된다.

함수가 이와 같이 대기하는 정확한 이유는 영구 저장소에 따라 다르다.

- 클라우드 데이터 스토리지 : 클라우드 데이터 서비스의 탄력성은 계속 높아지는 중이지만, 여전히 동시 읽기 및 쓰기 볼륨을 기반으로 리소스를 구성해야 하는 경우가 많다.

- 전통적인 시스템 : 모든 함수가 연결되어 있으며, 서버리스 기업 사용자의 상당수는 서버리스 함수로 기존 시스템을 래핑한다(메인프레임인 경우도 있고, 일반적인 서버 기반 배포인 경우도 있음). 임계값을 높여서 함수 확장을 허용하기는 쉽지만, 이 경우 쉽게 확장할 수 없는 백엔드에 가해지는 부담 역시 폭증하기 쉽다.

백엔드 시스템이 이론상의 최대 부하를 처리할 수 있도록 보장하려면 함수 쓰로틀과 병행해서 백엔드를 튜닝해야 한다. 이렇게 하면 처음부터 끝까지 원활한 시스템 작동을 보장해 불필요한 비용과 고객 불만을 방지할 수 있다. 경우에 따라 여러 시스템이 여러 위치에서 액세스할 수 있도록 데이터를 복제해야 할 수 있다. (물론 이 경우 데이터 관리 복잡성 증가, 데이터에 비일관성이 발생할 위험이라는 비용이 따라온다.)

이번에도 마찬가지로, 트랜잭션 수준에서 시스템을 통과하는 엔드 투 엔드 흐름을 이해하는 것이 중요하다. 그래야 프로덕션의 병목 지점을 파악해 경보를 보내고 튜닝을 위해 시스템을 종합적으로 분석할 수 있기 때문이다.
 

서버리스 운영은 데브옵스

물론 “나는 개발자다! 내가 왜 함수도 아닌 이 이상한 배포 문제에 신경을 써야 하는가?”라고 반문할 수 있다.

하지만 서버리스가 갖는 가장 큰 의미는 이제 구성이 코드(또는 최소한 코드의 일부)라는 점이다. 개발자가 서버리스 환경의 프로덕션에 제공하는 것은 함수 조각이 아니라 전체 패키지다.

즉, 과거에는 IDE를 사용해서 프로덕션 문제를 디버깅했지만 서버리스 환경에서는 성능 관리 솔루션에 익숙해지는 것이 좋다. 어쨌든 “버그”의 최소 절반은 배포와 관련된 버그일 수 있기 때문이다. 더 이상 “그쪽(즉, 운영 팀) 잘못”이 아니다. 시스템의 운명은 전적으로 개발자의 손에 달려 있다. 그리고 이 문제를 해결하는 데는 애플리케이션 수준의 엔드 투 엔드 가시성이 필수적이다.

*Peter Holditch은 앱다이내믹스(AppDynamics)의 수석 제품 책임자이다.
editor@itworld.co.kr


X