본문 바로가기

System Design

수평적 확장과 수직적 확장이란?

💡
학습한 내용을 정리한 것입니다. 잘못 이해하거나, 잘못 알고 있는 부분에 대한 조언은 항상 감사합니다.

What is scalability?

확장성에 대한 이야기는 많이 듣곤 합니다. 중요하다는 것 또한 인지한 상태인데요! 하지만 확장성이 뭐야? 라는 질문에 답변을 할 때는 머리 속에 떠다니는 단어들이 손에 잘 안 잡혀서 말문이 턱하고 막히는 경험을 했습니다. 그래서 먼저 확장성이 무엇 인지에 대한 정의를 내려보고 시작할게요.

 

확장성이란, 애플리케이션이 지연시간 없이 증가된 트래픽을 처리하고 견딜 수 있는 능력을 말합니다.

 

음식을 주문하는 앱이 있다고 가정해볼게요. 오후 세시 쯤 쏟아지는 잠을 이기지 못하고 커피를 한잔을 주문을 했다고 해보죠! 1초만에 주문이 완료가 되었네요.

시간이 흘러 저녁을 먹을 때 쯤.. 그러니까 6시 30분 쯤 주문을 했는데 하! 필! 그 때 무려 100만 명이 주문을 동시에 한거에요. 그래도 주문은 1초만에 완료 되어야 합니다.

이 이야기는 위의 정의에서 언급한 내용 중 지연시간에 대한 이야기를 하고 싶어서 꺼내 보았습니다.

latency?

지연시간은 사용자가 보낸 요청에 대해 시스템이 응답을 보내는데 필요한 시간입니다.

이 지연시간은 온라인 서비스의 승패를 좌우할 정도로 매우 중요합니다. 바쁜 시간에 배가 너무 고픈데 주문하기를 요청했더니 30초 동안 화면이 빙글빙글 돈다면 제 마음도 돌 것 같습니다. 그렇게 기다림 끝에 주문이 완료 된다면 그나마 낫지만, 만약 주문이 실패한다면? 즉시 다른 앱을 켜서 주문을 할 것 같아요. 아니 꼭 그렇게 합니다.

이처럼 지연시간은 사용자 경험에 치명적이고 해당 앱에 대한 신뢰도는 바닥을 치게 될 것입니다..

그렇다면 지연시간을 사용자가 느끼지 못하게 하려면 어떤 방법이 있을까요?

type of scalability

트래픽이라는 무게가 너무 커져서 서버가 들기 힘들어 하면 방법은 두 가지가 있습니다. 서버에게 프로틴을 공급하여 서버의 덩치를 키우는 (vertical scaling) 것이 있고, 혼자서 힘드니까 같이 들어줄 친구를 만들어 주는 (horizontal scaling) 방법이 있습니다. 두 가지 방법 모두 장단점이 있습니다.

수직적 확장 Vertical Scaling

scaling up이라고 알고 있는 서버의 힘을 키워주는 방법입니다. RAM과 같은 하드웨어를 서버의 빈칸에 추가하는 방법으로 키워 줍니다. 장점과 단점은 다음과 같습니다.

  • 장점
    • 코드를 변경할 필요가 없다.
    • 확장하기가 쉽다. 하드웨어 추가해주면 완료.
  • 단점
    • 그런데.. 서버에 빈칸이 없을 정도로 하드웨어 풀 옵션 장착했는데 그래도 감당이 안되면?

 

한계가 명확합니다. 풀 옵션 장착했는데 더 트래픽이 무거우면? 사이 좋게 사업과 애플리케이션이 손잡고 고꾸라집니다. 이것을 availability risk (가용성 위험)이라고 합니다.

availability risk란 서버가 한 대일 때 그 서버가 다운될 경우 시스템이 마비될 수 있는 위험

 

수평적 확장 Horizontal Scaling

scale out이라고 알고 있는 친구들을 불러주는 방법입니다. 둘? 셋? 서버가 마련만 된다면 킹론상 무한대로 확장이 가능합니다.

이것이 바로 cloud computing이 인기 있는 이유입니다. 지연시간 없이 늘어나는 트래픽에 탄력적으로 대응할 수 있기 때문입니다.

하지만 단점도 있습니다.

  • 관리가 어려워짐
  • 코드를 수정해야함.

 

이 중 코드를 수정해야 하는 부분에 대해 살펴보겠습니다. 분산 처리를 하게 된다면 사용자의 요청은 매 요청마다 여러 대의 서버 중 가장 부하가 낮은 서버로 전달되게 됩니다. 여기서 문제가 발생하는데요. 분명히 나는 로그인하고 음식을 주문했는데 로그인을 다시 하라고 하는 사태가 계속 발생한다는 것입니다.

서버가 세션이라는 상태를 관리하고 있기 때문입니다. 사용자의 요청이 매번 다른 서버로 전송 되기 때문에, 현재 내 요청을 받은 서버가 아까 로그인한 그 서버가 맞는지 사용자는 알 방법이 없습니다. 요청을 받은 서버도 마찬가지구요.

반드시 stateless 해야한다.

서버는 아가입니다. 아무것도 몰라요. 그래서 사용자가 다 알려줘야 합니다. 그리고 내 로그인 정보는 서버 친구들이 같이 볼 수 있는 다른 곳에서 관리를 해야 합니다.

JWT 토큰을 통해 세션을 관리하는 방법이 매우 인기가 있는 이유라고 볼 수 있을 것 같네요.

함수형 프로그래밍의 인기가 왜 증가 했는지도 알 수 있는 대목입니다. 함수는 상태를 저장하지 않으니까요.

 

정리

사용자가 늘어나고, 그만큼 증가한 부하를 견디기 위한 방법을 찾던 중 혼자가 힘들면 함께하자! 라는 낭만적인 방법을 통해 견딜 수 있게 되었습니다.

클라우드 컴퓨팅과 함수형 프로그래밍의 인기가 올라 갈 수 밖에 없었던 이유도 살짝 엿볼수 있었다고 생각합니다.

 

Reference

Web Application & Software Architecture - Learn Interactively
Go step by step through the different components and concepts involved in architecting a web application.
https://www.educative.io/module/web-application-architecture-101

'System Design' 카테고리의 다른 글

HTTP Pull 과 HTTP Push  (0) 2021.06.29
웹 아키텍처  (0) 2021.06.29
소프트웨어 아키텍처의 계층과 장단점  (0) 2021.06.27