개발자는 클라이언트보다 서버를 만들고 다루는 일이 더 많음
일반적으로 클라이언트를 다루는 일반 사용자는 한 번에 한 서버와 메시지를 주고받지만,
서버를 다루는 개발자는 한 번에 수많은 클라이언트와 메시지를 주고받아야 함

서버와 트래픽 관리에 대한 내용

오리진 서버와 중간 서버: 포워드 프록시와 리버스 프록시

오리진 서버: 자원을 생성하고 클라이언트에게 권한이 있는 응답을 보낼 수 있는 HTTP 서버
클라이언트와 오리진 서버 사이에는 많은 중간 서버가 있을 수 있음

위 그림에서 서버의 다중화는 가용성을 높이기 위한 설계라고 볼 수 있음

HTTP 중간 서버 유형

대표적인 HTTP 중간 서버 유형에는 프록시와 게이트웨이가 있음

📌 프록시

: 클라이언트가 선택한 메시지 전달의 대리자로, 주로 캐시 저장, 클라이언트 암호화 및 접근 제한 등의 기능을 제공

• 클라이언트가 어떤 프록시를 언제, 어떻게 사용할지 선택하기 때문에 프록시는 일반적으로 오리진 서버보다 클라이언트와 더 가까이 위치
• 포워드 프록시 라고도 함
• "클라이언트의 심부름꾼 또는 대리인" 정도로 생각하면 됨

📌 게이트웨이

: 오리진 서버(들)을 향하는 요청 메시지를 먼저 받아서 오리진 서버(들)에게 전달하는 문지기, 경비 역할을 수행

• 게이트웨이가 클라이언트의 요청을 받고, 클라이언트에게 응답을 보내기 때문에
• 요청 메시지를 보내는 네트워크 외부의 클라이언트 시각에서 보면 마치 오리진 서버처럼 보임
• 그래서 게이트웨이는 일반적으로 클라이언트보다 오리진 서버(들)에 더 가까이 위치

• 캐시를 저장할 수도 있고, 부하를 분산하는 로드 밸런서로도 동작할 수 있음
• 리버스 프록시 라고도 함

---

고가용성: 로드 밸런싱과 스케일링

가용성과 부하 분산은 서버를 설계할 때 안정성과 관련한 중요 고려 대상

가용성:서버, 네트워크 특정 하드웨어 부품을 비롯한 특정 컴퓨터 시스템이 주어진 기능을 실제로 수행할 수 있는 시간의 비율
고가용성: 가용성이 높은 경우 "고가용성 이다" 라고 표현

가용성

가용성 = $업타임\over 업타임+다운타임$

• 다음과 같이 간단한 수식으로 표현할 수 있음
• 업타임: 정상적인 사용 시간을 의미
• 다운타임: 모종의 이유로 인해 정상적인 사용이 불가능한 시간을 의미

• 흔히 특정 시스템의 안정성을 평가하기 위해 제시된 가용성 수식의 백분율 값을 사용
• "안정적"이라고 평가받는 시스템의 가용성에 대한 백분율 값은 99.999% 이상을 목표로 함
• 99.999% 라는 수치는 "9가 다섯개"라는 의미에서 "파이브 나인스" 라고도 표현

📌 다운타임 발생 원인

다운타임의 발생 원인은 나열하기 어려울 정도로 다양함

• 예기치 못한 소프트웨어 상의 오류
• 하드웨어 장애
• 보안 공격
• 자연 재해 등

다운타임의 발생 원인을 모두 찾아 원천 차단하기는 현실적으로 어려운 일

고가용성을 유지하는 것의 핵심은 "애초에 문제가 발생하지 않도록 하는것"이라기보다
"문제가 발생하더라도 계속 기능할 수 있도록 설계하는 것(결함 감내)"에 가까움

즉, 다운타임을 낮추고 가용성을 높이기 위해서는 서비스나 인프라가 결함을 감내할 수 있도록 설계하는 것이 중요
이를 위한 대표적인 기술이 다중화. 서버를 다중화하면 특정 서버에 문제가 발생하더라도 다른 예비 서버가 이를 대신해 동작할 수 있기 때문

로드 밸런싱

과도한 트래픽은 서버의 가용성을 떨어뜨림
서버를 다중화하더라도 특정 서버에만 트래픽이 몰린다면, 즉 트래픽이 고르게 분산되지 않는다면 가용성은 떨어질 수 있음
따라서 하나 이상의 서버가 트래픽을 어떻게 고르게 분산하여 수신할지를 고려해야 함

로드 밸런싱: 트래픽의 고른 분배를 위해 사용되는 기술
로드 밸런서: 다중화된 서버와 클라이언트 사이에 위치하며 클라이언트의 요청(들)을 각 서버에 균등하게 분배하는 역할

로드 밸런싱 알고리즘: 부하가 균등하게 분산되도록 요청을 전달할 서버를 선택하는 방법

• 대표적인 로드 밸런싱 알고리즘
  - 라운드 로빈 알고리즘: 단순히 서버를 돌아가며 부하를 전달하는 알고리즘
  - 최소 연결 알고리즘: 연결이 적은 서버부터 우선적으로 부하를 전달하는 알고리즘

📌 로드 밸런싱 고려사항

"다중화된 모든 서버에 균일한 부하를 부여하는" 전략은 모든 서버의 성능이 동일하다는 전재가 있을 때만 유효함

• 예를 들어 4대의 서버로 다중화된 환경을 가정
• 한 서버는 한번에 3의 트래픽을 처리할 수 있고, 총 12개의 트래픽이 주어짐
• 모든 서버의 성능이 동일하다면 각 서버당 3씩 트래픽을 분배하면 될 것임
• 하지만 4대의 서버 중 2대의 서버가 다른 2대의 서버보다 2배 더 좋은 성능으로 2배의 트래픽을 처리할 수 있다면
• 모든 서버에 동일한 트래픽을 분배하는 것이 합리적이지 않음

우측과 같이 성능이 더 좋은 서버에 더 많은 트래픽을 분배하는 것이 합리적

로드 밸런싱 알고리즘에는 이를 반영해 가중치가 부여될 수 있음
즉, 각각의 알고리즘을 바탕으로 동작하되, 가중치가 높은 서버가 더 많이 선택되어 더 많은 부하를 받도록 할 수 있음

스케일링: 스케일 업 / 스케일 아웃 / 오토스케일링

실제로 성능이 뛰어난 장비를 사용하면 그렇지 못한 장비를 사용할때와 비교해 가용성이 높아짐
다만 꼭 비싼 장비를 구비하는 것만이 정답은 아님

📌 스케일 업

: 기존 부품을 더 나은 사양으로 교체하는 방법. 수직적 확장 이라고도 함

• 설치와 구성의 단순함. 더 좋은 장비로 갈아 끼우면 그만
• 장비 성능에는 물리적 한계가 있음, 고장 시 장애 발생 위험

📌 스케일 아웃

: 기존 부품을 여러 개로 두는 방법. 수평적 확장 이라고도 함

• 유연한 확장 및 축소가 가능
• 한 대가 고장나도 나머지가 처리함
• 결함을 감내하기가 더 용이함
• 구성이 복잡함(설치, 네트워크 설정, 데이터 동기화 등)

📌 오토스케일링

필요할 때 자원을 자동으로 늘리고, 불필요하면 줄이는 기능

필요 상황

• 티켓팅 / 수강신청 같이 특정 순간 트래픽이 폭발하는 경우
• 성수기/비수기가 뚜렷한 여행·쇼핑 사이트
• 특정 시간대에만 트래픽이 몰리는 사이트

트래픽 급증/급감 상황에서도 서버가 튕기지 않고, 비용도 아끼게 해주는 경제적+탄력적인 확장 기술

---

Nginx로 알아보는 로드 밸런싱

대표적인 웹 서버 프로그램으로,
정적 파일 제공 + 리버스 프록시 + 로드밸런싱 + 캐싱 + 보안 기능 등을 지원하는 강력한 툴

📌 구성 시나리오 예시

• Nginx 설치 서버: 10.10.10.1
• 백엔드 서버: 10.10.10.2, 10.10.10.3, 10.10.10.4

📌 주요 설정 경로

• 가장 기본적인 설정 파일이자 모든 설정들의 시작점이 되는 $(nginx)/nginx.conf 파일
• Nginx 관련 로그가 저장되는 $(nginx)/log/nginx/디렉터리
• 각종 설정 파일들이 포함되는 $(nginx)/conf.d/디렉터리

📌 $(nginx)/nginx.conf 파일 주요 내용

1️⃣ http: 웹서버 관련 설정
2️⃣ access log: 웹 서버가 수신한 개별 요청 관련 로그는 '/var/log/nginx/access.log'에 남김
3️⃣ error log: 웹 서버와 관련한 오류 발생 시 오류 관련 로그는 '/var/log/nginx/error.log'에 남김
4️⃣ conf.d: '/etc/nginx/conf.d/' 경로에 놓인 <파일명>.conf의 내용은 모두 웹 서버 관련 설정으로 간주함

...


http {
...

	access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
...


	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

즉 $(nginx)/conf.d의 <파일명>.conf에 담긴 내용은 모두 웹 서버 관련 설정이 됨

📌 호스트의 경로 $(nginx)/conf.d/에 로드 밸런싱을 수행하도록 설정

1️⃣ 웹 서버 관련 설정(server)으로, 서버 이름(server_name)을 localhost로 삼고, 80번 포트를 LISTEN 상태로 대기(listen)하고 있다는 의미
2️⃣ 특정 경로(URL)에 대한 설정으로, '경로 /(location /)'에 대한 설정을 의미. 바로 다음 행에 있는 'proxy_pass http://backend;'는 '경로 /'에 대한 HTTP 요청은 'backend'라는 서버 그룹으로 넘기겠다는 의미. 즉 'proxy_pass'는 요청을 넘기라는 의미이고, 이 요청을 넘기는 대상이 'backend'인 셈

• weight: 가중치를 의미(기본값은 1이며, 생략 가능)
• backup: 두 서버에 문제가 발생하여 연결이 불가능할 경우 사용할 서버를 의미

예시처럼 아무런 로드 밸런싱 알고리즘을 명시하지 않을 경우에는 기본적으로 라운드 로빈으로 동작함

하지만 아래와 같이 로드 밸런싱 알고리즘을 지정할 수도 있음

• 연결 수가 가장 적은 서버로 요청을 전달하는 리스트 커넥션(least_conn),
• 단순히 임의로 선택하는 랜덤(random),
• IP 주소 기반의 해시를 활용하느 IP 해시(ip_hash) 등

📌 업스트림/다운스트림, 인바운드/아웃바운드

업스트림: 상위 서버로 데이터를 보내는 방향을 의미. 업스트림 트래픽은 클라이언트에서 오리진 서버로 향하는 트래픽인 셈
다운스트림: 상위 서버에서 클라이언트로 데이터를 보내는 방향을 의미. 오리진 서버가 응답 메시지를 생성해 클라이언트로 보낼 경우, 메시지가 향하는 방향이 다운스트림인 셈

인바운드 트래픽: 트래픽은 단순히 네트워크 외부에서 내부로 들어오는 트래픽을 의미

• 주로 외부 사용자가 내부 네트워크의 서버나 서비스에 접근하려는 요청을 가리킴
• 예를 들어 외부 인터넷 사용자들이 회사 웹사이트에 접속하는 트래픽은 회사 입장에서 인바운드 트래픽에 해당
  아웃바운드 트래픽: 내부 네트워크에서 외부로 나가는 트래픽을 의미
• 내부 시스템이나 사용자들이 외부 서버나 서비스에 요청을 보내는 경우를 가리킴
• 예를 들어 회사 직원이 외부 웹사이트를 방문할 때 생성되는 트래픽은 회사 입장에서 아웃바운드 트래픽에 해당

---

참고: 북스터디 - 이것이 취업을 위한 컴퓨터 과학이다 (Chapter 5-7)