## 로드밸런서

> 로드 밸런싱이란, 부하 분산을 위해서 가상 IP를 통해 여러 서버에 접속하도록 분배하는 기능을 말한다.

로드 밸런싱에서 사용하는 주요 기술은

- NAT(Network Address Translation): 사설 IP 주소를 공인 IP 주소로 바꾸는 데 사용하는 통신망의 주소 변조기이다.
- DSR(Dynamic Source Routing protocol): 로드 밸런서 사용 시 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념이다.
- Tunneling: 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념으로, 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.

로드 밸런서는, 네트워크에서 IP 주소와 MAC주소를 바탕으로 목적지 IP주소를 찾아가고, 다시 출발지를 되돌아 오는 구조로 작동된다.

[출처: naver d2](https://d2.naver.com/helloworld/284659)

## HAProxy

![ha-proxy](https://i0.wp.com/foxutech.com/wp-content/uploads/2019/01/What-is-HAProxy-and-how-to-install-and-configure-in-Linux.png?fit=2000%2C1000&ssl=1)

HAProxy는 reserve proxy형태로 작동한다. 흔히 브라우저에서 사용하는 proxy는 클라이언트 앞에서 처리하는데, 이를 forward proxy라고 한다. 반대로 reserve proxy는 실제 서버 요청에 대해 서버 앞단에 존재하면서, 서버로 들어오는 요청을 대신 받아 서버에 전달하고, 요청한 곳에 그 결과를 다시 전달한다.

### 작동 흐름

1. 최초 접근 시 서버에 요청 전달
2. 응답 시 쿠키(cookie)에 서버 정보 추가 후 반환
3. 재요청 시 proxy에서 쿠키 정보 확인 > 최초 요청 서버로 전달
4. 다시 접근 시 쿠키 추가 없이 전달 > 클라이언트에 쿠키 정보가 계속 존재함(쿠키 재사용)

![haproxy-flow](https://d2.naver.com/content../../../images/2015/06/helloworld-284659-1.png)


## 로드밸런서 > 로드 밸런싱이란, 부하 분산을 위해서 가상 IP를 통해 여러 서버에 접속하도록 분배하는 기능을 말한다.  로드 밸런싱에서 사용하는 주요 기술은  - NAT(Network Address Translation): 사설 IP 주소를 공인 IP 주소로 바꾸는 데 사용하는 통신망의 주소 변조기이다. - DSR(Dynamic Source Rout...

HAProxy

제법 규모가 있었던 전 회사에서는 특별하게 인프라에 대해 고민을 별로 할 필요가 없었다. 많은 부분이 자동화되어 있었고, 또 적당한 툴로 잘 만들어져 있었기 때문에 개발에 온전히 집중할 수 있었다. 하지만 새롭게 온 스타트업은 (당연하게도) 그런게 없으므로, 회사에서 사용하고 있는 AWS 인프라와 배포 시스템에 대해서 직접 공부할 필요가 있었다. 그 중에서도 처음 접하는 것이 docker 였다.

## Docker

예전 부터 이름은 많이 들어봤지만 이런저런 이유로 (귀찮아서) 한번도 써본적이 없었다. **docker는 컨테이너 기반의 오픈소스 가상화 플랫폼** 이라고 정의할 수 있다. 여기서 중요한 용어 중 하나가 컨테이너라고 생각한다.

### 컨테이너

docker의 컨테이너에 백엔드 프로그램, DB, 메시지 큐 등 다양한 프로그램을 컨테이너에 집어 넣어 추상화 한 다음, 이를 어디서든 배포할 수 있는 상태로 만들어 준다.

![docker-container](https://codingthesmartway.com/wp-content/uploads/2019/02/010.png)

docker는 기존의 virtual machine과는 다르게 프로세스를 격리 시키는 방법으로 가상화를 한다. docker가 동작하기 위한 cpu나 메모리만 격리해서 사용하므로, 성능적으로도 손실이 적은 방식이다.

### 이미지

이미지는 **컨테이너의 실행에 필요한 파일 및 설정을 포함하고 있는 것** 으로 별도의 상태값을 갖고 변하지 않는다. 컨테이너는 이미지를 실행하는 것이라 볼 수 있고, 추가되거나 변화가 필요한 값은 컨테이너에 저장된다. 말 그대로, 컨테이너를 실행하기 위한 모든 정보를 갖고 있기 때문에 의존성 파일을 컴파일/설치할 필요가 없다. docker를 이용한다면 이제 이미지를 다운받고 컨테이너를 생성면 된다.

### Dockerfile을 시작으로 실제해보기

[여기](https://subicura.com/2017/01/19/docker-guide-for-beginners-2.html)를 참고하자. 친절하게 정말 잘 써주셨다.

## ECR

[아마존 ECR](https://aws.amazon.com/ko/ecr/)은 docker 컨테이너 이미지를 손쉽게 저장, 관리 배포할 수 있게 도와주는 일종의 레파지토리 같은 개념이다.

![AWS_ECR.png](../images/AWS_ECR.png)

이렇게 생성된 이미지를 푸쉬해서 관리 할 수 있다.

## ECS

docker를 사용하다보면 컨테이너를 적절하게 배치하거나 관리할 도구의 필요성을 느끼게 된다. docker에서 만든 [swarm](https://github.com/docker/swarm)도 있지만서도, 가장 유명한건 구글의 [쿠버네티스](https://kubernetes.io/)가 아닐까 싶다. 이런 컨테이너 오케스트레이션 도구 중 하나가 바로 aws의 elastic container system (이하 ECS) 다.

### Cluster

ecs의 가장 기본적인 단위는 클러스터다. 클러스터는 도커 컨테이너를 실행할 수 있는 가상의 공간, 일종의 논리적인 단위 수준이라고 볼 수 있다.

### Task

ECS에서 컨테이너를 실행하는 최소단위를 task라고 부른다. task는 하나이상의 컨테이너로 구성할 수 있다. 같은 task내 있는 컨테이너들은 모두 같은 컨테이너 인스턴스에서 실행되는 것이 보장된다. 이러한 task를 실행하기 위한 것이 task definition 이다. task definition에는 task를 실행하기 위한 다양한 것들을 설정할 수 있다.

![task-definition.png](../images/task-definition.png)

~~귀찮아서~~ 캡쳐는 안했지만, add container에는 이미지 주소, 컨테이너명, 컨테이너 사양, 환경변수 등을 정할 수 있도록 설정이 준비되어 있다. 그리고 설정 변경 / 이미지 변경이 필요할 때마다, task definition을 새롭게 만듦으로써 (create new revision) 이를 해결할 수 있다.

### Service

cluster는 두가지 방식으로 task를 실행할 수 있다. 한가지는 `run task definition`을 통해서 일회성으로 실행하는 것이다. 이 task는 곧바로 실행되고, 더이상 관리되지 않는다. 두 번째 방법은 서비스를 정의하는 것이다. 서비스는 하나이상의 task definition과 연결된다. 서비스는 크게 리플리카 타입과 데몬타입으로 나누어져 있는데, 우리는 리플리카 타입을 사용해서 n개의 태스크가 실행되도록 관리하고 있다.

## 어떻게 썼나

먼저 `dockerfile`을 통해서 이미지를 만들고, 해당 이미지를 `ecr`에 업로드한다. 그리고 배포가 필요할 때마다 `task definition`을 새롭게 만들고, 새롭게 만들어진 이미지를 넣었다. 그리고 서비스에서 실행할 이미지를 새롭게 만들어진 k번째 task definition으로 교체하면 끝이다.

## 써보니까 좋았던 점

의식의 흐름대로 나열해 보았다.

1. 배포 히스토리를 남길 수 있었다 == 롤백이 쉬웠다. 배포할 때 마다 새롭게 만들어진 이미지를 `ecr`에 업로드 하였기 때문에 이미지 목록을 히스토리 느낌으로 남길 수 있었다. 그리고 롤백이 필요하면 이전에 잘 동작했던 이미지로 교체해주면 된다. 사실 이 방법보다 쉬운 것은 그냥 예전에 잘 동작했던 task-definition으로 service를 교체해 주는 것이다.

2. 스테이지 별 로 다른 변수를 task definition - container의 환경변수로 관리할 수 있다. 기존에는 프로젝트에 `.development` `.release` 이런 형식으로 소스파일안에 스테이지마다 다른 변수 값을 두어야 했다. 따라서 이 글로벌 변수에 변동이 있을 때마다 배포를 새로 하는 번거로움이 있었는데, 이 방식 대로 하면 단지 task definition을 새롭게 만들고, 환경변수를 추가해서 service에 올려주기만 하면 된다. 추가로 `dockerfile` 혹은 docker 빌드 과정에 환경변수를 따로따로 주입하지 않는 다면, 어떤 스테이지 든지 간에 동일한 이미지로 대처할 수 있다.

~~3. 드디어 docker를 써볼 수 있었다.~~

~~4. 아마존에 많은 돈을 지출할 수 있다.~~


제법 규모가 있었던 전 회사에서는 특별하게 인프라에 대해 고민을 별로 할 필요가 없었다. 많은 부분이 자동화되어 있었고, 또 적당한 툴로 잘 만들어져 있었기 때문에 개발에 온전히 집중할 수 있었다. 하지만 새롭게 온 스타트업은 (당연하게도) 그런게 없으므로, 회사에서 사용하고 있는 AWS 인프라와 배포 시스템에 대해서 직접 공부할 필요가 있었다. 그 중에서...

yceffort

infrastructure

HAProxy

Docker와 ECR, ECS 경험