시스템 디자인에서 확장성은 "증가한 부하에 대처하는 시스템 능력을" 설명하는 데 사용하는 용어라고 한다. 그럼 확장성을 고려한 설계는 다양한 부하(load)를 고민해 보는 설계가 필요하다. 그럼 이 부하는 어떻게 표현할까?
부하 매개변수와 측정 방법
부하는 부하 매개변수(load parameter)라고 부르는 몇 개의 숫자로 나타낼 수 있는데, 이러한 부하 매개변수에 대한 선택은 시스템 디자인에 따라 달라진다고 한다. 예를 들어, 웹 서버의 초당 요청 수, 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자, 캐시 적중률 등이 될 수 있다.
그럼 부하가 생겼을 때, 시스템의 성능을 어떻게 검증할 수 있는 지도 알아봐야한다. 온라인 시스템에서 대표적인 부하 관련 지표로는 응답 시간(response time)이 있다. 응답 시간은 "요청을 처리하는 실제 시간 외에도 네트워크 지연 및 큐 지연"을 포함하는 용어로서, 부하를 처리하는데 사용할 수 있는 중요한 지표 중 하나다.
여기서 재미있는건, 응답시간은 항상 일정하지 않다는 말이다. 똑같은 요청을 보내더라도, 프로세스의 컨텍스트 스위치, 네트워크 패킷 손실, GC가 돌아가면서 생기는 Stop-The-World 등 다양한 요인 때문에 응답시간은 매번 달라질 수 있다. 그래서 응답 시간은 단일 숫자가 아닌, 측정 가능한 값의 분포로 생각해야 한다.
이렇게 분포로 보게 된다면, 우리는 백분위(percentile)을 사용함으로서 응답 시간을 좀 더 효율적으로 측정할 수 있다. 예를 들어서 99분위로 백분위를 확인한다면, 클라이언트 요청에 따른 응답시간의 99퍼센트가 특정 응답시간 이하로 나타날 수 있다는걸 쉽게 알 수 있다. 하지만 산술 평균(Arithmetic mean)을 사용하게 된다면, 사용자가 실제로 경험한 지연 시간을 정확하게 알려줄 수 없기 때문에 그다지 좋은 지표라고 말하기가 어렵다.
부하를 고려한 확장 방식
지금까지 부하와 어떻게 지표를 바라봐야 하는지 알아봤으니, 이 부하를 어떻게 대응 하는지에 대해서도 한 번 알아보자. 대표적인 확장성을 고려한 디자인 방식으로는 용량 확장(Scaling Up a.k.a Verical Scaling)과 규모 확장(Scaling Out a.k.a Horizontal Scalining)이 있다.
용량 확장의 방식은 간단하지만, 시스템 장비의 성능이 좋아질수록 가격이 매우 비싸지기 때문에 대규모 확장에 부담이 될 수 있다. 그래서 규모 확장과 용량 확장을 적절히 섞어서 사용하는 방식이 필요하다. 예를 들어서 적절한 사양의 장비 몇 대가 대량의 사양이 낮은 장비보다 훨씬 간단하고 저렴할 수 있다.
일부 시스템은 탄력적(elastic)으로 운영이 되서, 부하 증가를 감지하면 자동으로 컴퓨팅 자동을 추가를 할 수 있다. 예를 들어 Azure Serverless Fucntion이나 AWS의 Lambda가 있을 수 있다.
우리가 확장성을 고려한 시스템 아키텍처를 만들 때 알아야될 사실은 모든 상황에 맞는(one-size-fits-all) 같은 아키텍처는 없다는 사실이다. 상황에 따라서 읽기의 양, 쓰기의 양, 저장할 데이터의 양 등 다양한 요소를 고려해야 하기 때문에, 그 때에 맞는 부하 매개변수를 고려하는 아키텍처를 만들어야 할 것 같다.