[02-02] 서버의 구성과 트래픽

1. Infrastructure

1.1 물리 서버

• 자체적으로 구축한 데이터 센터 => On-Premise
• 단점 => 고정 비용 + 직접 운영 관리
  - 건물 유지비용, 서버 구매비용, 유지보수 등
  - 한번 구매, 설정하면 수요에 상관없이 계속 보유, 관리필요

1.2 가상 서버(클라우드 서버)

• 데이터 센터에서 임대 => 온디맨드 비용 + AWS가 대신 운영 관리(아마존은 신이야)
• 장점
  - 간편한 설정
  - 고정되지 않은 유동적인 비용

1.3 서버리스(Serverless)

• 서버 구축 X
• only 상시 서버가 아닌 필요할 때마다 빌림
  1) 서버 필요 요청
  2) 서버 활성화(= 타 서버 대여)
  3) 작업 이후 서버 비활성화(= 서버 반납)
• 요청 횟수에 따른 과금이기에 
  => 낮은 트래픽, 고메모리 필요시에 유용(= 호출 횟수는 적고, 작업의 필요 자원이 큰 경우)
          Ex) 이미지 프로세싱, AWS 람다,
          Ex) Vercel 을 통해 Next.js 배포 시 모든것이 Serverless

---

2. 트래픽 분산

: only 1개의 WS를 통해 웹 어플리케이션 서비스를 제공하는 경우

    1) 대량의 트래픽이 한개의 웹 서버에 집중될 경우
        -> 펑!

        => 수직/수평적 확장 필요

    2) 새 버전의 웹 어플리케이션 배포 시

        -> 기존 웹 서버의 IP ≠ 새 버전의 웹 서버의 IP  

        -> 전환 과정에서 서비스 중단

2.1 CDN(= L1 Reverse Proxy)

목적	설명
- 캐싱	- 요청에 따른 응답을 중간에 캐싱 -> 동일 요청 시, 저장값 반환(준 실시간성 데이터)
	- 원 서버의 문제 시, CDN이 캐싱 값으로 대신 응답     -> 고가용성 보장     ==> 고가용성을 보장해주는 버퍼의 역할 - 원 서버에 가해지는 DDos공격을 대신 탱킹
- 지역성 해결	- 리소스 제공 서버와 클라이언트의 물리적 거리가 멀 경우     -> 각 지역의 CDN을 통해 응답 속도 개선     -> CDN을 통해 장애허용(Fault Tolerance) 제공

 

2.2 Load Balancer(= L2 Reverse Proxy)

목적	설명
- 배포 이슈 해결	- 로드 밸런서에 대표IP 부여     - 클라이언트에서 해당 IP를 호출(뒷단의 서버는 몰라도 됨)
- 트래픽 이슈 해결	- 로드 밸런서 뒷단의 서버의 수를 늘리는 수평적 확장을 통해 해결(요청을 분산하기에)

: DNS를 통해 로드밸런서 구현도 가능

 

2.3 메세지 큐를 이용한 요청 트래픽 비동기 처리

: 수직/수평적 확장의 경우, 요청에 대한 동기적 처리 목적

: 실시간성이 중요하지 않은 비실시간성 요청에 대한 비동기적 처리 방식

    1) 요청이 들어오면 큐에 적재

    2) 서버의 여유 시, 큐의 내용 처리

- Producer/Consumer 패턴을 가짐

• Producer : 메세지(요청)를 발행
• Queue : 메세지를 저장하는 버퍼
• Consumer : 메세지(요청)을 처리

- 메세지 큐 장점

• 비동기 : Queue 라는 메세지를 저장하는 버퍼(임시 저장소)가 있기 때문에 나중에 처리 가능
• 탄력성 : Consumer 서비스가 다운되거나, 문제가 생겨도 다시 살아나서 메세지를 소비만하면 된다.
• 확장성 : Producer 가 엄청 많아져도, Consumer 가 적어도 서비스를 원하는대로 확장할 수 있음
• 낮은 결합도 : Consumer 와 분리되어 있어, Consumer 에 문제가 생겨도, 구현체가 바뀌어도 상관없음
• 보장성 : 결국 Queue 안에 있는 모든 메시지는 Consumer 서비스에서 모두 처리됨을 보장

- Ex) AWS SQS, Kafka(애는 큐에서 화살표만 이동하는 것으로 이해, 큐에서 내용 삭제 X), RabbitMQ(내용 삭제-처리)

---

3. 다수의 트래픽을 고려한 배포 방법

3.1 Rolling 배포 방식

Rolling

• Rolling 방식
  : 1죽이고 1교체 -> 반복
  : 버전 간 트래픽이 의도치 않게 섞인다.
  : 변경 시, 한쪽에 과한 트래픽이 몰림

---

Rolling with Additional Batches

• Rolling with Additional Batches 방식
  : 한개의 추가 서버를 구동
  : 1죽이고 1교체 -> 반복
  : 트래픽은 섞이지만 트래픽 커버지리 유지 가능

---

Immutable

• Immutable 배포 방식
  : 새 ASG로 트래픽을 꺾는다.

3.2 Canary 배포 방식

: 신버전 테스트(구버전과 신버전으로 나누어 트래픽 분산처리 및 테스트) -> 신 버전으로 전체 전환

: 버전 간의 트래픽이 섞임(의도적, 테스트 목적)

: A/B테스트나 성능 테스트에 용이

 

3.3 Blue-Green 배포 방식

: 그룹을 기준으로 구버전/신버전 구별 -> 즉, n개의 서버를 추가 생성

: 문제 발생 시, 즉시 롤백 가능

---

깨알 단어 사전

* 수직적 확장: 서버 자체의 성능 업

* 수평적 확장: 비슷한 성능의 서버의 수를 늘림

 

* Proxy: client-server 사이의 중간 서버

    - Forward Proxy: Client 측에 가까이 위치, 다수의 Client와 연결

    - Reverse Proxy: Server 측에 가까이 위치, 다수의 Server와 연결(L1, L2 ...등으로 추가 분류된다.)

 

* 장애 허용(Fault Tolerance): 시스템이 일부 부분에서 장애가 발생하더라도 전체 시스템이 멈추지 않고, 다른 방법으로 계속 작동할 수 있도록 설계

 

* SRE(Site Reliability Engineer): 시스템 안정성과 서비스 가용성을 유지, 시스템 운영을 최적화하는 역할

 

* immutable(불변성): 데이터 생성 시, 그 값은 변경되지 않는다.
    => 수정의 경우, 새 객체를 생성 및 값 할당 후 이전 객체와 바꿈

    => 상태 변화 X를 꼭 기억할 것

 

* ASG(Auto Scale Group): 트래픽별 서버 수의 min-mid-max를 그룹화

 

* Scale up/down: 기존 시스템의 성능 업/다운

* Scale out/in: 비슷한 시스템 병렬적 배치

 

 

---

출처: https://webmobilez.com/awsmaterial/elastic-beanstalk-deployment/?ref=joojae.com

Elastic Beanstalk Deployment Models – Webmobilez