[ASAC 06] 서버 구축 방식, Serverless, Load Balancer

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.

서버 구축 방식

서버 구축 방식에는 2가지가 있다.

1. On-Premises
2. Cloud

1. 온프레미스 (물리)

데이터 센터 구축에 따른 1. 고정 비용(생성과 유지) 2. 직접 운영과 관리를 필요로 한다.
ex1) 대표적인 물리 서버 호스팅 업체로 카페 24가 있다.
ex2) 은행, 금융 서버는 민감한 데이터를 다루기 때문에 규제로 인하여 온프레미스 방식으로 서버 구축을 해왔다.

2. 클라우드 사용 (가상)

데이터센터 임대에 따른

1. 온디맨드 비용(필요에 따라서 서버를 늘리거나 줄여서 비용 산정) 2. aws가 대신 운영과 관리

 

사용자는 유지보수를 고려할 필요가 없다.

 

임대(렌트)의 개념이다. 많이 쓸 때는 서버를 많이 할당하고, 적게 쓸 때는 서버를 적게 할당하면 된다.

Serverless?

서버리스는 진짜로 서버가 없는 것이 아니다.

일반적으로 클라우드 서버를 대여한다고 하면, 해당 서버는 사용과 관계없이 항상 유지되어야 한다.예를 들어서 도서관에서 책을 대여해서 읽는다고 하면, 대여 기간 동안 계속해서 책을 읽지 않더라도 대여 상태를 계속 유지해야하는 것과 비슷하다.

서버리스는 사용자가 사용할 때에만 서버를 대여해주는 것이다. 사용자가 등록한 함수를 호출하게 되면 일시적으로 서버를 사용하고 호출하지 않을 때에는 서버를 사용하지 않는다.

 

1.별도의 서버 설정이 필요없다. 2. 함수 수행 요청 횟수에 따라 과금한다.

그러나 최대로 쓸 수 있는 메모리는 설정해야 한다. (threshold)

ex) aws lambda, vercel

서버리스 문제점

1. 비용
   • 서버리스 비용은 생각보다 비싸다.
   • 서버리스는 호출에 따라서 비용을 산정하기 때문에 서버를 대여하는 것보다 비용이 적게 들거라 생각하기 쉽다. 그러나 서버리스의 호출 당 비용은 생각보다 비싸기 때문에, 차라리 서버를 대여하는 게 나은 경우가 많다.
   • 예상되는 자원 사용량과 호출 횟수로 비용을 미리 계산하고 비교하여 선택해야 한다.
   • 예를 들어 호출 횟수가 적은데 자원 사용을 많이 하는 (메모리 사용량이 큰) 작업은 서버리스를 사용하는 것이 낫다! 10GB 짜리 서버를 상주시키는 것은 비용이 크기 때문에.
2. 가용성
   • 서버리스가 서버 보다 가용성이 낮을 수 있다.
   • Lambda는 가용성이 EC2보다 낮다 (약 98% 정도)
   • 서버 가용성은 소수점 차이도 성능 차이가 많이 발생함.

Load Balancer

로드 밸런서 사용 목적

로드 밸런서를 사용하는 이유는 크게 두가지이다.

1. 가용성
   • Scale-Out : 하나의 서버로 몰릴 수 있는 부하를 분산 (같은 서비스를 제공하는 서버를 여러 개 둔다.)
   • Scale-Up : 서버 자원 할당량을 늘려서 서버의 성능을 높인다.
   • (ex. AWS ELB 사용)
2. 무중단 배포
   • 기존 버전을 정지시킨 후 새 버전을 구동하는 동안 유저는 서비스를 사용할 수 없다.
   • 클라이언트가 요청을 각각의 서버 ip로 직접 하는 대신, 로드 밸런서의 ip에 하도록 한다. 로드밸런서가 적절한 서버에게 요청을 전달하고 서버가 요청을 처리한다.
     • nginx, apache와 같은 서버 1개가 로드 밸런서가 되어 로드밸런서도 ip를 가지게 된다.
     • 로드 밸런서는 적절한 서버를 선택하는 업무 분배를 한다.
   • 배포 이슈 해결 : 클라이언트는 로드 밸런서의 ip만 호출하기 때문에 서버가 죽든말든 알 필요가 없다. (로드 밸런서 = 인터페이스 역할)
     • 새로운 버전을 배포하는 경우, 혹은 스케일업을 하는 경우에 로드밸런서는 새로운 서버로 트래픽을 이동시킨다.
   • 트래픽 이슈 해결 : 아무리 많은 요청이 들어와도 로드 밸런서 뒷단의 서버 수만 늘리면 된다. => 수평적 확장

ex) 클라우드 로드 밸런서 - AWS ELB, 네이버 클라우드 로드 밸런서
=> 해당 서비스들을 사용하여 서버에 업무 분산 및 Auto Scaling(트래픽 많아지면 자동으로 Scale out)이 가능하다.

웹 서버 뿐만 아니라 DB 서버도 로드 밸런싱이 가능하다.

DB 서버 로드 밸런싱

• transaction : 대량 트래픽이나, 다수 요청이 DB에 접근 -> 동시성 제어
  • 다수의 웹 서버에서 (대량 트래픽) -> 단일 DB에 접속 시 충돌 (서로 DB를 쓰겠다고 싸움)
  • 하나의 웹 서버에서 다수의 요청이 -> 단일 DB에 접속 시 충돌 (서로 DB를 쓰겠다고 싸움)
• DB의 로드 밸런싱 => DB 서버의 이중화(2개). 혹은 다중화(2개 이상)
• 로드 밸런싱이 가능한 이유 : DB 접근의 80%는 조회 (읽기) 목적이기 때문이다.
  • 쓰기와 읽기를 동시에 하거나, 쓰기와 쓰기를 동시에 하는 것은 문제가 될 수 있다.
  • 그러나 읽기를 동시에 하는 것은 문제가 되지 않는다.
    => 읽기만을 위한 DB 서버와 쓰기만을 위한 DB 서버를 80:20 비율로 둔다.
    ex) 읽기 DB 서버 4개와 쓰기 DB 서버 1개를 둔다.
  • 버전관리 문제로 쓰기용 DB 서버는 웬만해선 1개만 둔다.