brunch

You can make anything
by writing

C.S.Lewis

by Master Seo Jan 23. 2023

NCP 10탄-서비스 연속성 확보 13/35

서비스 연속성 확보를 위한 클라우드 아키텍처 설계

네이버 클라우드 서비스 구성에서  데이터센터 이중화 하는 법이 설명된다.



<1> 서비스 연속성 확보는 왜 필요할까?

<2> 서비스 연속성 확보의 문제?

<3>  안정적인 시스템 구성

<4> 대응

<5> 고가용성 구성을 위한 네이버 클라우드 상품

<6>  RPO와 RTO

<7>  멀티존 이중화 구성하는 법



<1> 서비스 연속성 확보는 왜 필요할까?


손실발생 : 매출, 주가 하락, 서비스 단절로 인한 보상. 광고수익 감소

중요 시스템 : 공공, 데이터, 통신, 발전소, 교량, 철도 등 문제 발생 시 큰 문제 발생




<2> 서비스 연속성 확보를 위한 문제?


비용 증가

이중화에 따른 운영 비용이 얼마나 드는지 따져보고 진행해야 한다.

장애 발생 시 예상되는 손실 확인해 감수 가능한 범위 내에서  서비스 연속성을 갖추기 위해 고민을 해야 한다.



<3>  안정적인 시스템 구성


이중화 구성

순간적인 과부하 환경 대비

서비스 트래픽 분산

백업과 DR



<4> 대응


1

순간적인 과부하 환경?

이벤트를 감지하여 동작하면 실제 서버가 확장되어서 서비스 프로세스까지 올라와 트래픽처리가 가능할 때까지 시간이 걸리는 경우

특정 이벤트 데이나 주기적인 서비스 흐름이 예측 가능하다면 스케줄 기반으로 운영하는 것이 더 안정적일 수 있다.


2

서비스 트래픽 분산?

HTTP/HTTPS  =  ALB 사용

TCP 사용  =  Network LB  , Network Proxy LB

TCP , DSR 지원 = Network LB

TCP , DSR 지원 불필요  = Network Proxy LB


3

이중화 서비스 사용

PaaS 상품으로 관리형 DB인 Cloud DB


4

백업과 DR



<5> 고가용성 구성을 위한 네이버 클라우드 상품


1

리전

존 - 하나의 존은 1개 이상우 데이터 센터로 구성된다.

데이터 센터



2

서버

LB

CDB (Cloud DataBase)

Global Route manager (gslb 기반 상품)

BackUp




<6>  RPO와 RTO


1

RPO 복구 시점 목표는 1일?

Recovery Point Object

매일 데이터를 백업 보관 했다면  RPO는 1일이다.

데이터 백업 주기에 따라 RPO는 결정된다.


2

RTO 복구 시간 목표는 3시간?

Recovery Time Object

복구시작 후 3시간 후 서비스를 복구하겠다면 RTO는 3시간이 된다.

금융 감독 기관에서 금융기관은 3시간 이내로 하는 것을 가이드하고 있다.

짧으면 좋지만 비용이 증가한다.




<7>   멀티존 이중화 구성하는 법


1

구성도?

2

사용된 상품?

LB를 통한 멀티존 서비스 구성

관리형 DB상품인 Cloud DB for MySQL로 멀티존 HA기능 활용.


3

애플리케이션 LB와 프락시 LB는 프락시로 동작해서 서버에서 볼 때 LB에서 들어오는 트래픽의 소스 IP가 

클라이언트 IP가 아닌  LB의 서브넷 대역의 임의 IP로 들어오기 때문에 ACG에서 필수적으로 LB의 서브넷 대역을 오픈해야 한다.


4

서버에서 실제 클라이언트 IP정보가 필요할 경우에는 X-forwarded를 사용하면 된다.


5

멀티존 이중화  AutoScale 

CPU 80% 이상인 경우 AutoScale 사용


6

CDB생성 시  고가용성 지원 체크해서 생성한다.

멀티존 구성함.


7

READ 하는 DB가 여러대라면  L4로 묶어 제공하면

READ/Write용 마스터 서버의 URL과 Read Only용 슬레이브 서버 URL만 구분해 구성하면 된다.


8

Active Master DB장애 시 다른 Zone의 Standby Master가 Active 되어 Master가 된다.

마스터 정보의 접속 정보는 IP가 아닌 도메인 기반의 URL로 제공이 된다.

DB클라이언트 서버들은 별도로 절체 작업이 필요 없다.

DB에 접속하는 서버들은 접속 정보인 Private 도메인만 알고 있으면 된다.

Master DB서버가 Fail-over 될 경우 DNS의 A레코더에 Fail-over 된 Master DB서버의 IP로 자동 변경된다.

Fail-over는 DNS loolkup으로 확인하자.



9

하이브리드 구성은?

IP Sec VPN이나 전용회선 이중화나  회선사업자인 ISP를 이중화하면 된다.


10

DR구성은?

서버 중지 상태로 운영하면 서버 비용은 적게 나온다.


금융클라우드 DR구축 사례?

멀티존을 활용한 핫사이트 구축 사례.

IPsev VPN까지 존별로 구성

DR복구 시나리오 작성함.



11

리전을 활용한 DR구성?

리전의 경우 로드밸런서를  리전별로 각각 구성해야 하는 점이 다르다.

트래픽 Fail-ove를 위한 Global Router Manager를 활용하여 구성하자.

CNAME으로 한국 리전의 LB  URL과 해외 리전의 LB  URL을 설정하고 페일오버 설정을 한다.

서버에 디비도 리전 단위로 각각 구성되기 때문에 데이터와 파일 동기화를 고려해야 한다.

일반적으로 3rd Party설루션을 사용하여 구성한다.



12

민간 클라우드는 국가 단위로 구분한다.

공공 기관은 수도권과 남부권이 존이 아닌 리전으로 구성되어 있다.

공공은 리전 단위 DR구성에 대한 검토가 필요하다.



다음

https://brunch.co.kr/@topasvga/2957


감사합니다.

매거진의 이전글 NCP 10탄-12. BCP 12/35
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari