AWS Scale Out, ELB

Scale out. (ELB 이용)

 

사용자와 우리가 운영하는 서버(우리가 만든 인스턴스) 인스턴스 하나에는 일반적으로 3개가 설치되어 있을 것이다.

웹서버, 미들웨어, DB가 그것이다. 다른 말로는 Client - MiddleWare Server - DB Server(DBMS)

 

웹서버는 사용자와 매개하는 문지기고 미들웨어는 웹서버와 DB 사이에 위치. 로직 수행. 보안과 로직의 효율성 때문에 존재. 가장 깊은 곳에서 정보를 보관하는 곳이 DB

 

웹서버는 NginX, Apache...

미들웨어 PHP, spring, django...

DB에는 oracle, Mysql, MongoDB...

뭐 이런 게 존재한다.

 

scale out의 예시는 다음과 같다.

 

 

 

DB와 middle ware를 여러 컴퓨터를 통해 확장하여 처리하는 것이다.

문제는 Web Server는 애초에 하나의 IP(Domain)을 가지고 있는 것이기에 다른 해결 방법이 강구된다.

우리는 Load Balancer를 통해 이를 해결 할 것이다.

 

 

아마존에서는 ELB라고 해서 Elastic load balacer가 있다. 한국어로는 그냥 로드 밸런서라고 되어 있고.

 

 

그런데 만들기 전 로드 밸런서 포트와 인스턴스 포트를 구별해야 한다.

사용자가 처음에는 로드 밸런서 포트로 먼저 접근하기 때문이다. (로드 밸런서도 도메인이 있다)

이 말인 즉슨 Elastic ip를 ELB에 줘야 한다는 것이다. 여기에 구매한 도메인 박고.

 

그리고 ELB와 instance 사이의 통신은 https로 굳이할 필요가 없는데 이 둘 사이에서는 안전하게 통신하기 때문이다. 또 웹서버에서 https를 쓰면 컴퓨팅 파워가 http보다 더 들어가기 때문에 비용적인 문제도 껴 있다. 여튼 http로 세팅해도 된다.

 

 

 

위와 같이 세팅해주면 일단 ㅇㅋ

 

ELB를 만들다 보면 health check를 구성하라는 페이지가 나오는데 이는 사용자들의 요청을 분산할 때 어떤 컴퓨터가 죽었는지 안 죽었는지를 확인하기 위함.

 

정기적으로 인스턴스에 접속해서 그 컴퓨터가 죽었는지 살았는지 확인함.

이 확인하는 방식을 어떻게 할것이냐.

 

ping protocol은 http로

ping port는 80

ping path는 지정해야겠지만 일반적으론 index.html로

 

그러면 이 경로로 들어가서 성공하면 컴퓨터는 살아있는 것으로 간주한다. 죽었으면 그 쪽으론 안 보낸다.

여기가 기본이고 Advanced details 에서는

 

몇 초 이내로 접속이 가능해야 하는지(reponse timeout)

몇 초에 한 번 씩 헬스 체크를 할 건지 (health check interval)

헬스 체크를 했는데 몇 번 시도하고 죽었다고 판정할 건지(unhealthy thresold)

이미 죽어도 계속 체크는 하는데 만약 다시 살아난다면 몇 번이나 성공해야 살아난 걸로 판정할 건지 (healthy treshold).

이런 요소가 있다.

 

지정 다 했으면 원하는 인스턴스를 지정.

인스턴스를 나중에 만들어서 후에 적용할 예정이라면 체크 안하고 그냥 넘어가고.

 

끝!(create!)

 

 

 

 

 

그런데 주의할 점은 DB를 아래와 같이 분리한 채로 ELB를 주면 안된다는 것이다.

 

유저가 쓰거나 저장한 데이터가 pc1의 DB에 있는데 ELB에 의해 다른 pc2의 웹서버를 통해 pc2의 DB를 이용하게 된다면 당연히 정보가 없을 것 아닌가. DB가 나뉘어서 정보를 못 받아오는 경우가 발생한다는 말이다.

 

 

 

요런 방식으로 scale out을 한 뒤에 ELB을 해야 한다.

 

여튼, Scale out의 구조를 잘 생각하자