'IT_Infra/Architecture'에 해당되는 글 27건

웹 서버의 서버 이중화

1. DNS 라운드 로빈(Round Robin) 이중화

- 호스트 명에 대하여 복수의 IP 주소를 등록해 둔다

- DNS는 질의에 대해 순서대로 IP 주소 반환

1) 장점

- 매우 간단하게 서버 이중화

2) 단점

- 서버 상태 감시 X, 서버가 정지된 경우에도 이 서버의 주소 반환

- DNS가 세션 상태를 파악하지 않는다

: 웹 서버에 동적 콘텐츠가 있어서 세션 상태를 저장하고 있어야 하는 경우 부적합

2. 부하분산 장치를 이용한 이중화(Load balancing)

- DNS 라운드 로빈의 단점 극복

1) 부하분산장치(l4, l7)

- 이전에 어느 웹 서버에 요청을 할당 했는지 쿠키에 저장하고 있다

- 쿠키를 통해 세션 상태를 저장한다

* 세션 테이블

- 클라이언트에 요청을 반환할 때는 이 테이블을 참조

* 퍼시스턴스(persistence)의 종류

- 세션 상태 저장을 실현하는 기능

- 소스 IP 주소 : 클라이언트 IP 주소를 기반으로 요청을 할당할 웹 서버를 결정

- 쿠키 : HTTP 헤더 내에 접속한 웹 서버 정보를 저장

- URL : URL 구조 내에 접속한 웹 서버 정보를 저장

* 부하분산 장치의 할당 알고리즘

a. 라운드 로빈(round robin) : 서버의 IP 주소에 순서대로 요청

b. 최소 연결(least connection) : 현재 활성 세션 수보다 세션 수가 가장 적은 서버의 IP 주소에 요청을 할당

c. 응답시간(response time) : 서버의 CPU 사용률이나 응답 시간 등을 고려해서 가장 부하가 적은 서버의 IP 주소에 요청 할당

2) 페일 오버(failover)

- 웹서버 장애를 감지한 부하분산 장치는 클라이언트 요청을 동적으로 다른 서버에 할당 할 수 있다

* 클라이언트 처리에 영향을 준다?

- 정적콘텐츠는 상관없지만 동적 콘텐츠라면 페일 오버와 세션 정보가 사라지기 때문에 세션 상태가 초기화 된다

- failover와 함께 세션 정보를 유지하는 구조가 필요

안정성 및 이중화

1. 안정성

- 고가용성 이라고 한다

- 시스템 서비스가 가능한 한 멈추지 않도록 하는것

1) 실현수단

- 컴포넌트 이중화

: 고장, 장애에 의한 정지가 발생하지 않을 것

: 고장, 장애가 발생해도 복구할 수 있을 것

- 컴포넌트 감시

: 고장, 장애가 발생한 것을 검출할 수 있을 것

- 데이터 백업

: 고장, 장애가 발생해도 데이터가 보호될 것

2. 이중화

- 하나의 기능을 병렬로 여러 개 나열해서 하나에 장애가 발생해도 다른 것을 이용해서 서비스를 계속할 수 있는 것을 가리킨다

1) 구조

- 부하분산 구조

- 내부적 생존 감시 구조

- 마스터 결정

- 페일오버

마스터-슬레이브(master-slave)

1. 마스터-슬레이브(master-slave)?

- 한 명이 관리자가 돼서 다른 모든 것을 제어한다

- 상호 관리라는 의미에서 피어 투 피어(peer-to-peer) 관계와 반대 의미이다

2. 사용되는 곳

1) 복제(replication)

- 실제 데이터가 마스터, 어떤 정보를 언제 전파할지는 마스터가 결정하며 어디까지 전파 됐는지도 관리

- 마스터 측의 부하가 높아지는 것은 피할 수 없다

2) 오라클 RAC(Real Application Cluster)

- 마스터 슬레이브 + 피어 투 피어의 장점만으로 구성

- 특정 서버가 마스터가 아니라 모두가 대등한 관계에 있다

- 리소스 단위로 관리 마스터가 달라진다.

- 만약 물리 서버가 다운되면 해당 서버가 마스터로 관리하던 것을 다른 마스터 서버가 관리

복제(replication)

1. 복제(replication)?

- 장애 시 데이터 손실을 예방

- 복제를 이용한 부하분산이 가능

- 사용자가 데이터에 엑세스할 때 복제한 것이라는 것을 의식할 필요없다

- 백업과 달리 실제 데이터가 복제 데이터와 실시간으로 동기화

2. 사용되는 곳

1) MySQL 복제

- 데이터 '추가, 갱신, 삭제' 등의 변경 처리(트랜잭션)을 복제 측으로 보낸다

- 실제 데이터 블록을 전송하는 것이 아니기 떄문에 복제 데이터 전송량을 줄인다

- 복제 전송량을 트랜잭션 수와 비례한다

3. 주의 사항

- 복제 위치가 많으면 갱신이 많은 시스템과 같이 복제 오버헤드 높아진다

- 복제와 실제 데이터를 완전히 일치 시키려면 복제 데이터의 쓰기 완료 처리 보장해야함

- 설계나 운용 난이도가 높다