[aws 패턴] 시나리오별 설계/구축 - 가용성 확보하기

개인 aws study note입니다.

수정이 필요하거나 다른 의견은 댓글로 남겨주세요.

(무단 복제 및 배포를 금함)

다중화 구조로 가용성 확보하기

 

aws 즉 클라우드에서의 서비스 운용을 떠올리면 가장 먼저 따라오는 수식어가 "비용 효율" 그리고 "SLA 99.9999% 보장" 등이다.

비용 효율을 가져가기 위해서는 어떠한 서비스가 운영되는지, 어느정도의 트랜잭션을 유발하는지 기업의 비즈니스 목표가 무엇에 우선순위를 두는지에 따라 나뉘어진다.

 

즉 장애 발생 시, 최우선시 되는것이 빠른 복구 시간(RTO)인지 혹은 그 우선순위가 비용이 아닌 실시간 서비스 연속성을 보장하는 것인지, 완전한 데이터의 복원인지 등등 

각 기업별, 서비스별로 우선순위가 달라지기 때문에 그에 맞는 구축과 설계, 그리고 운영이 필요하다.

(aws에 대한 공부를 시작하려고하면, AWS SAA이나 SAP 자격증 시험을 많이 찾아봤을텐데, AWS 자격증 시험의 경우 위에서 언급한 상황별 즉 시나리오형태의 문제로 출제가 되기 때문에 단순한 자격증 취득을 넘어서서 공부하는데 많은 도움이 되었다. 추후 AWS SAP 자격증 취득 후기 및 공부방법에 대해 포스팅 해보겠다.)

 

 

온프레미스와 클라우드 환경을 통틀어 네트워크 운용에 있어서, 즉 서비스를 제공할 때 가장 중요한 것은 무엇일까?

단연 "서비스 연속성"이다. 

기존 온프레미스 무선망 관제/운용 업무를 수행할 때도 최우선 순위는 서비스 연속성, 가용성과 연결되었다.

상용망을 운영할 땐 얼마나 빠르게 장애 상황에서 절체/우회하여, 서비스 제공에 차질이 없게 하는가에 초점이 맞추어져 있는 것이다.

(장애가 발생하고, 떨어지는 통계수치를 확인 트래픽 우회 등을 통해 서비스 정상화 이후, 장애 원인을 찾고 재발을 방지하는 방향으로 흘러간다..지금 생각해도 아찔한 알람음!)

 

앞서 말했든 다양한 시나리오/환경에 따라 달라지겠지만, 아주 기본적으로 가용성을 확보하는 설계패턴에 대해 알아보자.

 

 

---

1. 다중화

 1-0. AZ

 1-1. ELB를 통한 장애 대비, EC2 Instance Web Server 이중화

    1-1-1. EC2 인스턴스 자동복구

 1-2. RDS를 이용한 DB서버 다중화

    1-2-1. RDS 사용 시 유의사항

2. 오토스케일링

3. 백업사이트(Off Site)에 재해 복구 구현(자동/수동)

 3-1. Route53을 통한 자동 전환 / Region 간 데이터 백업

---

 

1. 다중화

 1-0. Multi-AZ(Available Zone)

AWS에서 가장 기본적으로 가용성을 확보하는 방법은 멀티 AZ를 가져가는 것이다. 동일 리전 내 각각의 AZ들은 별도의 전원/백본망을 가지고 있기 때문에 장애발생 AZ의 영향을 받지않고 서비스를 제공할 수 있다. 다수의 AZ에 다중화하는 것은 가용성을 높이는 가장 기본적이면서도 중요한 부분이다. EC2 여러개를 각각의 AZ에 배치하고, ELB가 클라이언트 요청을 각 AZ에 배치된 EC2로 전달하며, 특정 AZ에 장애가 발생하여 EC2가 응답하지 않을 경우, ELB는 별도의 인스턴스를 시작하여 자동으로 유지하게 하는 기능도 있다.(오토스케일링: 자동확장)  

 

 

 1-1. ELB를 통한 장애 대비, EC2 Instance Web Server 이중화

위에서 언급했듯, EC2(서버)를 여러대 구축하여 장애 대비 가용성을 확보한다.  이때 각각의 EC2를 수작업으로 콘솔에서 생성 시 서비스에 따라 작업량이 어마어마하게 많아질 수 있다. 이때 AMI를 활용한다. 서버이미지를 기본 셋업한 뒤 AMI로 등록, 다수의 인스턴스를 생성/배포 할 수 있다. 혹은 IaC 테라폼을 활용하여 코드로 손쉽게 EC2를 필요한 만큼 생성할 수 있다.

 

여러개의 EC2를 생성 후에는 ELB와 연결하여 트랜잭션에 대한 부하분산을 처리 할 수 있도록 셋팅해야 한다.

이때, ELB 생성/셋업 시 엔드포인트와 보안그룹, 상태체크, 타임아웃 등 설정할 부분이 필요하다. ELB는 클라이언트의 요청을 받아, 서버로 뿌려주는 역할을 하기 때문에 보안그룹 설정이 필수적이다. 이때, ELB의 보안그룹과 EC2의 보안그룹을 각각 셋팅한다.

EC2를 웹 서버라고 가정했을 때, 클라이언트의 요청이 들어오면 ELB의 인바운드 룰은 HTTP(port 80), HTTPS(poty443)의 접속을 모두 허용(0.0.0.0/0)해야 한다. 이후, EC2로 향하는 ELB의 아웃바운드 룰은  ELB가 SSL을 복호화 하기 때문에 HTTP로만 내보내는 것으로 셋팅(암/복호화에 따르는 부하 감소 효과*)

EC2의 인바운드 룰은 Source가 ELB의 보안그룹이면서, HTTP(port 80) 프로토콜만 허용하는 것으로 셋팅하면 보안상의 문제나, 불필요한 암/복호화로 인한 부하를 줄일 수 있다.

    (*HTTPS: 클라이언트와 서버간 통신을 암호화 하는 프로토콜(ELB 자체에 SSL 인증서 확인 및 암/복호화를 처리해주는 기능이 있어서                       EC2 각 서버별로 SSL를 관리 할 필요성이 없음.)

 

 

 

 

    1-1-1. EC2 인스턴스 자동복구(Auto Recovery)

EC2 인스턴스의 상태를 감지한 후, 자동 복구 기능을 제공한다. 이때 상태를 감지하기 위해 필요한 모니터링 서비스인 CloudWatch(클라우드워치)서비스를 사용해야 한다. EC2 인스턴스의 상태, 사용량, 로그 등을 모니터링하고 관리자에게 노티/알람을 주는 기능을 설정할 수 있다. aws 공식문서에서 AWS EC2 인스턴스 지표를 확인 할 수 있다.

 

-EC2/StatusCheckFailed_System: Host HW level HealthCheck(0:nomal, 1:anomal)

-ELB/HealthyHostCount: ELB와 연결된 정상 EC2 인스턴스 갯수

-ELB/BackendConnectionErrors: ELB-EC2 연결 에러 갯수 

 

등, 위와 같은 모니터링 지표를 분석하여, 이상상태 유무를 체크 및 자동복구 설정을 통해 EC2 자동 재기동 시켜 복구할 수 있다.

또한 이러한 클라우드워치에 의한 감시/알람은 오토스케일링 트리거로도 사용된다.

 

 

 1-2. RDS를 이용한 DB서버 다중화

기본적인 웹서버에 대한 다중화, 클라우드워치 모니터링 기능을 이용, EC2의 상태에 따른 ELB 부하분산 등으로 기본적인 가용성 확보 방법에 대해 알아보았다. 이어서 DB서버의 다중화를 알아보자. 먼저 AWS에서 DB를 구성할 수 있는 방법은 두 가지이다. 첫 번째로 EC2에 관리자가 OS와 DB환경을 자유롭게 구성하여 관리하는 방법, 두 번째로 관리형 RDS를 사용하는 방법이다. 첫 번째 방법은 구성이 자유롭지만 직접 패치 적용, 백업 등 DB를 관리해야한다. 두 번째 방법은 자동화된 패치(유지보수 포함)와 백업이 이루어져 운영 관리 측면에서는 편리하나 OS 접속, 다중화 기능등을 사용할 수 없어 자유롭게 DB를 운영하는데 제약이 따른다.(정기적으로 DB가 중지되는 메인터넌스도 유의해야 함) 따라서 필요에 따라 즉,  비즈니스 운영 목적에 따라 적절한 방법을 구성하여 운영하면 된다.

 

DB서버는 데이터의 일관성 유지가 중요하며, 이를 충족시키기 위해 Active(Master)-Standby(Replica) 구조로 하나의 세트로 구성하는 것이 일반적이다. 다중화 시 가장 먼저 언급했던 멀티AZ 기능을 사용하여, Master서버의 데이터를 대기서버인 Standby서버로 동기화하는 구성을 사용한다.(데이터 손실 방지)

  **멀티AZ: RDS에서 두 개의 가용영역(AZ)에 각각 서브넷을 만들고, 이를 그룹화하여 DB서브넷 그룹을 구성한다.

 

만약, Master DB에 장애가 발생하면, Standby DB서버가 Master로 승격된 후 Master DB역할을 수행하며 장애 복구 후, 원래의 Master DB가 Master를 잡도록 설정해주어야 한다.

 

    1-2-1. RDS 사용 시 유의사항

자동 백업을 선택하면 관리에 용이하지만, 데이터 보존 기간에 제한이 있기 때문에 영구적으로 데이터를 보관할 수 없다. 따라서 스냅샷 방법을 사용하는데, 초기설정이 완료된 시점에서의 스냅샷과 시스템의 유지보수를 위한 복구용 스냅샷 등등 적절한 스냅샷을 만들어 보관하는게 관리용이/복구에 있어 중요하다. 

 

또한, 대부분 멀티-AZ로 구성하는데 RDS 동기화(데이터 업데이트) 시, 다음 업데이트를 수행할 수 없는 단점이 있는데 이는 AWS Auror등 적절한 서비스를 사용할 수 있다. 또한 신규 갱신의 경우에만 데이터 일관성을 위한 잠금이 발생하는 것이므로, 읽기 데이터 즉 참조 트랜잭션이 많을 경우에는 큰 영향을 받지 않는다.(이 또한 비즈니스 속성에 따라 달라지므로, 앞서 말한 각 기업/비즈니스의 특성을 고려한 설계가 반드시 필요한 이유이다.) 

 

세 번째로는 AWS에 의한 자동 메인터넌스로 인한 DB연결 끊어짐이다. 마이너/메이저 업데이트로 인한 버전업 시 일정시간 DB연결이 끊어지는데 AWS console에서 RDS 메인터넌스 실시 시간 제한 설정을 할 수 있다. 다음은 유지관리기간에 DB연결이 끊어지는 예이다.

-자동 마이너 버전 업그레이드

-하드웨어/OS 유지관리

-선택(다음 유지관리기간에 수정 선택 시, 끊어짐 제한)

   .DB인스턴스 식별자/클래스 수정

   .백업 보존 기간

   .DB포트/엔진 수정

   .새서브넷 그룹 연결 등

 

 

2. 오토스케일링

 AWS는(Cloud) 특정 시기 혹은 예상하지 못한 이벤트에 대한 트래픽 처리량 급증의 경우, 자동으로 서버의 부하를 감지하여 서버를 시작/중지/확장 할 수 있는 오토스케일링 서비스를 제공한다. 서버의 부하/상태를 감지하기 위한 모니터링이 필요한데, CloudWatch서비스가 서버의 부하를 모니터링하여 임계치에 도달할 경우, 오토스케일링이 서버 확장을 실시한다.

 

 서버(EC2 인스턴스)의 수를 확장하고 축소하기 위해서는 기준이 필요한데, 스케일링 정책에서 설정한다. 

인스턴스의 확장/축소를 위한 모니터링은 클라우드워치에서 수행한다. 임계치를 설정에 맞게 인스턴스 축소/확장을 위한 트리거를 생성한다. 다음으로, 예약조정과 동적 조정을 선택하여, 증가/축소 정책을 설정한다. 이때 주의할 점은 새로운 인스턴스를 시작하여 기동되기 까지 시간이 소요되므로, 생성시간을 반영한 임계치 설정이 필요하다.  오토스케일링 그룹에 속한 인스턴스들의 부하, 에러 갯수 등을 모니터링하다가 지정한 임계치에 도달하면 경보가 발생하고, 알람을 받으면 새로운 EC2 인스턴스를 기동하여 서버 확장을 수행한다.

 

 

3. 백업사이트(Off Site)에 재해 복구 구현하기(자동/수동)

 가용성에 더욱 민감한 비즈니스의 경우, 재해 복구에 대응하기 위한 다중화 인프라 설계 사항이 필요하다. 데이터센터, 멀티 리전, 장애 자동/수동 복구 등이 있다. 이러한 설계사항은 재해 시에도 서비스 연속성을 가져가기 위함이다. 재해 복구에 대해 서비스/기능별 우선순위를 레벨로 지정해놓고, 해당 레벨에서 제공해야만 하는 즉, 필수 애플리케이션 서비스의 연속성을 보장하는 설계를 인프라 초기 설계 단계에서 수행하는게 이상적이다.(네이버클라우드 2022 서밋에서 확인한 네이버클라우드의 이중화 구조 및 레벨은 굉장히 이상적이었다. 1/31일까지 네이버클라우드 서밋 공식 홈페이지에서 다시보기가 가능하니, 꼭 한 번 쯤 보길 추천한다!)

 

 우선, 단일 리전에서의 멀티-AZ로 다중화로 구성하고, 앞서 살펴본 ELB로 부하분산 및 장애를 대비 할 수 있다. 또한 자동 복구 서비스 기능을 제공하는 아마존 클라우드워치(Amazon CloudWatch)서비스, 그리고 메인사이트와 다른 리전에 백업 사이트를 설치하여 동기화 할 수 있도록 RDS 다중화를 구성한다. 온프레미스 데이터를 AWS에 백업하는 경우 등 백업에 대한 자세한 내용은 다른 포스팅에서 상세하게 다뤄 보겠다. (메인 사이트의 마스터에 장애가 발생하면, 백업 사이트의 읽기전용 복제본 DB가 마스터로 승격되며, 장애 복구 후 기존의 마스터로 자동으로 돌아갈 지에 대한 설정이 필요하다.)  

 

마지막으로, 장애를 감지하여 백업사이트에 동적으로 라우팅 해주는 아마존 라우트53 서비스를 사용할 수도 있다.

 

 

 

 3-1. Route53을 통한 자동 전환 / Region 간 데이터 백업

라우드53을 이용한 자동 전환 방식, Failover 기능을 사용할 경우, 콘솔에서 미리 설정 해둔 백업 사이트의 ELB로 연결을 재설정하게 되어, 수동 조치를 할 필요가 없다. 다만, 자동전환 후 원활하게 서비스를 제공할 수 있도록 사전 구성을 잘 해놓아야 한다. 백업 사이트로의 데이터 동기화가 필요하며, 데이터 동기화의 방식은 각 서비스마다, 구성하는 방법마다 또 각 기업에서 인프라 운용 시 우선순위를 어떻게 가져가느냐에 따라 다르므로 필요에 따라 구성하도록 한다.(비용우선/데이터 실시간 동기화 우선 등)

 

 위 그림에서는 다른 리전에 위치한 RDS를 읽기 전용 복제본으로 구성하였다.

이때 메인 사이트의 장애가 발생할 경우, 읽기 전용 복제본DB의 마스터 승격 기능을 실행하여, 마스터로의 역할을 수행하게 된다. 마스터로 승격되기까지 시간이 소요되므로 앞서 오토스케일링에서 언급했던대로, 클라우드워치 모니터링 기능을 사용하여 이벤트를 감지하고, 이후에는 트리거기능을 사용하여, 마스터로 승격시키는 API를 호출하여 정상적으로 복제본이 마스터로 승격될 수 있도록 구성해야 한다.

추가로 S3에 스냅샷을 저장하여 데이터를 백업하는 방법도 함께 사용하는 것을 추천한다. 

 

 

다음 패턴/구축 포스팅에서는 데이터 백업이 필요로되는 케이스를 알아보고, 케이스별 백업 방법을 알아보도록 하겠다.