AWS 장애 대응 6단계 설계 방법

AWS 장애 대응 설계는 시스템 구축시 매우 중요합니다. 향후 서비스 운영 면에서 관리적, 비용적인 리소스를 효율적으로 줄일 수 있는 척도가 되기 때문입니다. 그래서 서비스 요구사항에 맞는 설계 뿐만 아니라 장애 시 일어날 수 있는 사항들을 면밀히 분석하여 시스템 설계에 반영해야 합니다.

아래 글을 읽기 전에 클라우드 서비스에 대한 이해가 필요하신 분은 여기 링크를 참고바랍니다.

목표

• AWS 장애 대응 개념에 대해 알아봅니다.
• 기능별 독립형 설계에 대해 알아봅니다.
• 탄력성, 동시성, 보안 설계 시 고려 사항에 대해 알아봅니다.
• AWS 리젼, 가용영역 및 엣지의 개념에 대해 알아봅니다.
• AWS Compute Service에 대해 알아봅니다.
• AWS Database Service에 대해 알아봅니다.

1. AWS 장애 대응 개념

• 서비스 구축 시 언젠가는 장애 발생의 가능성을 염두해두고 견고하게 시스템 설계를 해야 합니다. 장애 시 자동으로 복구, 복원이 가능하도록 시스템을 구축해야 합니다.
• 물리적인 하드웨어 장애가 발생한 경우에라도 어플리케이션이나 서비스 전체에 장애가 발생되지 않도록 하나의 전체 기능을 모아놓은 구조가 아닌 분산된 구조로 단일 부분의 장애 요수(SPOF)들을 제거해야 합니다.
• SPOF( Single Point Of Failure ) 란 단일 장애 요소, 즉 시스템의 하나의 구성 요소가 동작하지 않았을 때 전체 시스템에 영향을 주는 위험 사항을 말합니다. 예를 배달 추적 기능이 안된다고 하여 상품의 결제 기능까지 안되면 매출에 큰 문제가 있습니다. 따라서 해당 기능은 서로 독립적으로 영향을 받지 않게 구성해야 합니다.
• 아래 그림은 하나의 서비스가 장애가 났을 경우 서비스를 지속할 수 있도록 이중화로 구축한 사례입니다.

• AWS 장애 대응 방안을 소개합니다.
  • 정기적인 백업과 복구 정책, 장애 시 자동화를 마련해야 합니다.
  • 예기치 않은 시스템의 재기동 시 오류 파악을 위한 프로세스의 정립이 필요합니다.
  • 서버 간의 데이타의 동기화 오류를 막기 위한 데이터를 리로드 시 재동기화를 위한 프로세스 구축이 되어야 합니다.
  • 지속적으로 저장해야 하는 유저의 정보들을 인메모리 세션에 저장하는 방식은 지양해야 합니다. 이것은 시스템 장애 시 전부 사라지는 데이타이기 때문입니다.

2. 기능별 독립형 설계

• 기능별 독립형 설계 란?
  • 클라우드 서비스를 개발할 때 설계 원칙이 있습니다. 그것은 SOA의 디자인 원칙 중에 하나로 “더 큰 확장을 위해서 시스템의 구성요소들을 보다 기능별로 독립적으로 설계한다”입니다.
  • 서비스는 다양한 기능의 집합체 입니다. 쇼핑몰을 들면 결제, 배송주문, 반품, 이벤트 등 다양한 기능들로 구성되어 있습니다. 만약 이 기능들 간에 서로 밀접하게 연결(tight coupled)되어 있는 구조라면 지양하여야 합니다. 그리고 하나의 기능을 담당하는 서버에 문제가 발생하였을 때 다른 기능을 하는 서버에는 해당 문제와 상관없이 지속적으로 서비스 가능해야 합니다.
• 기능별 독립형 설계 vs 절차지향적인 설계

3. AWS 장애 대응 용 탄력성, 동시성, 보안 구축 설계

• 탄력성 적용
  • 탄력성이란 무엇일까요? 어떤 이슈에도 유연하게 대응할 수 있는 상태를 말합니다. 클라우드 서비스에서 그걸 구현하기 위해서는 업데이트 배포 절차를 자동화하고 구조가 단순한 프로세스를 구성해야 합니다.
  • 인위적인 관리자의 특정 개입 없이 시스템의 상황에 따라 확장이 되어야 합니다. 사용자가 몰려 시스템의 과부하 상태가 되면 서버가 스테일 업/아웃되어 무리가 없게 자동으로 탄력적으로 확정이 되어야 합니다. 부하가 사라지면 다시 스케일 다운/인되어 불필요한 리소스 낭비를 줄여 비용을 최적화해야 합니다.
  • 당연한 이야기지만 실제 발생하는 사용 용도에 맞게 리소스가 제공되어야 합니다. 네트워크 트래픽이 증가하는데 전혀 상관없는 쪽의 리소스가 증가하는 것은 맞지 않습니다.
  • 앞서 이야기했든이 탄력적인 구성은 리소스 자원을 효율적으로 사용할 수 있고 비용의 최적화를 가져올 수 있습니다.
• 동시성 적용
  • 클라우드 서비스는 다양한 기능을 동시에 수행하는 시스템 구축이 가능합니다.
    • 예를 들어, 어떤 특정 시점에 데이터를 저장하면서 수시로 들어오는 요청을 처리하는 작업을 실행할 수 있습니다.
  • 클라우드는 여러 작업을 병렬화시켜 동시에 처리하고 자동화가 가능합니다.
• 보안 적용
  • AWS 장애 대응 기반 보안 설계는 어떤 서비스든지 필수적으로 적용되어야 하는 조건입니다. 특히 멀티테넌시 같은 클라우드 환경에서는 보안이 가장 중요한 고려사항입니다.
  • Multi-tenancy는 특정 사용자들이 특정 자원이나 어플리케이션들 단의 하드웨어 자원을 공유하며 각가의 환경에 대해 논리적으로 분리하고 접근을 제어하며 사용하는 구성 환경을 의미합니다.
  • 보안 적용 사항
    • 데이터를 전송시에 암호화를 통한 정보를 보호합니다. 데이타가 그대로 네트워크 상에 노출된다면 중요한 데이타의 속성이 외부로 유출될 수 있습니다.
    • 데이터 저장 시 암호화를 통한 정보 보호는 특히 혹시 모를 사용자의 개인 정보 유출시 개인신상정보를 막기 위한 최소한의 조치입니다.
    • 어플리케이션 자체의 암호화 패키징 보호를 통해 어플리케이션 자체의 해킹을 1차로 방지할 수 있습니다.
    • 클라우드 리소스의 접근성 제약으로 외부의 침투를 막을 수 있습니다.
    • 역할에 따른 사용자 별 권한에 대한 적용 및 보호로 관리자, 일반 사용자의 접근 권한을 체계적으로 관리, 운용할 수 있습니다.

4. AWS 리전, 가용영역 및 엣지

• 리전, 가용영역
  • AWS는 해외 각국에 AWS 데이티 센터를 구축하여 이 리전(Region) 구성을 통해 다양한 클라우드 서비스들을 세계에 제공합니다.
  • Availability Zone(가용 영역)은 어는 국가, 지역에 설치된 물리적인 데이터 센터입니다. 이 데이터 센터들이 모여 Region을 이룹니다. 따라서 이 가용영역에서 AWS 리소스들을 구축할 수 있도록 지원합니다.
  • 예를 들면 대한민국 서울에는 서울 Region이 있고 미국 캘리포니아에는 N.California Region이 있습니다. AWS 장애 대응 뿐 아니라 서비스하려는 국가나 지역의 리전에 서비스를 구축하면 서비스 속도 품질면에서 이점이 있습니다.
• 지역(Region)
  • 많은 리전들이 대한민국, 일본, 미국 서부, 미국 동부, 유럽, 남미, 중앙 아시아, 극동 아시아 및 호주 등에 구축되어 있습니다.
• 가용영역
  • AWS 장애 대응 용 가용영역은 하나의 지역(서울, 대전) 안에 속하여 AWS 서비스를 구성 가능하도록 IT 리소스 등을 제공합니다.
  • 가용 영역은 선택이 가능하며 다수의 가용영역에 동일한 기능을 하는 리소스를 구성하여 장애 시 대응 가능한 서비스 구축이 가능합니다.
• 엣지(Edge)
  • 컨텐츠를 전송할 수 있는 네트워크입니다. 웹 사이트, API, 동영상 파일 또는 기타 웹 리소스의 전송 속도를 보장하는 서비스이다.
  • HTTP 또는 HTTPS 프로토콜을 통해 콘텐츠를 다운로드, RTMP 프로토콜로 콘텐츠를 스트리밍하여 배포할 수 있게 지원합니다.
• AWS 리전, 가용영역에 대한 공식 참고사이트는 여기를 참고바랍니다.

5. AWS Compute 서비스

• Elastic Compute Cloud(EC2)
  • EC2는 AWS에서 가장 기본이 되는 Low-Level에 속하는 컴퓨팅 서비스입니다.
  • EC2를 활용하면 원하는 만큼의 클라우드 서버를 탄력적으로 구축할 수 있습니다.
  • 그리고 보안 및 네트워크 구성하여 더 나아가 스토리지 관리까지 가능합니다.
  • EC2 요소
    • 인스턴스 : 클라우드 컴퓨팅 환경을 의미합니다.
    • AMI : Amazon 머신 이미지로 인스턴스에 필요한 OS와 소프트웨어가 구성된 템플릿입니다. 이 AMI를 통해 다양한 OS 설치가 가능해집니다.
    • 인스턴스 타입 : 클라우드 서버의 CPU, Memory 사이즈 용량 등을 말합니다.
    • EIP(Elastic IP) : 클라우드 컴퓨팅 서버에 할당되는 고정 공인 IP을 의미합니다.
    • VPC : 클라우드 컴퓨팅 서버가 속하는 독립된 네트워크 블럭입니다.
• Lambda
  • Lambda가 동작하는 방식은 특정 이벤트에 응답하여 코드를 실행합니다. 그리고 이런 동작을 하면서 동시에 자동으로 기본 컴퓨팅 리소스를 관리하는 Serverless 컴퓨팅 서비스입니다.
  • AWS 장애 대응 방안을 위한 백엔드 서버와 운영 체제 유지 관리, 용량 프로비저닝 및 자동 조정, 코드 및 보안 패치 배포, 코드 모니터링 및 로깅 등 모든 컴퓨팅 리소스 관리를 수행합니다.

6. AWS 데이터베이스

• AWS 데이타베이스 개요
  • AWS 데이터베이스는 서비스 사양에 맞는 데이터베이스의 용량과 성능에 맞게 조정 가능하며 시간소모적인 관리 작업들(패치, 백업, 확장)등으로부터 자유롭게 해줍니다.
  • AWS에서는 관계형 데이터베이스는 RDS, 비관계형 데이터베이스는 DynamoDB 등으로 제공합니다..
• RDS 관계형 데이터베이스
  • 가장 일반적인 유형의 데이터베이스로 키 값에 의해 서로 관련되는 각 테이블로 구성되어 있습니다.
  • AWS 장애 대응을 기반한 관계형 데이터 베이스가 효율적이고 정확하게 운용되기 위해서는 ACID 트랜잭션 특징을 가지고 있어야 합니다.
    • ACID : Atomicity(원자성) , Isolation(고립성), Consistency(일관성), Durability(지속성)
• NoSQL
  • NoSQL은 특정 스키마가 없으며 각 테이블에는 각각의 데이터 항목을 고유하게 식별하는 기본 키가 있어야 합니다. 하지만 키가 아닌 다른 속성인 값에 대해서는 특별한 제한이 없습니다.
  • AWS에서 제공하는 DynamoDB는 JSON 문서를 비롯한 정형 또는 비정형 데이타를 관리할 수 있습니다.
  • NoSQL은 아래의 BASE의 특징을 갖습니다.
    • Basically Available, Soft-state, Eventually consistency
• 데이터베이스 영역에서의 AWS 장애 대응
  • 확장성 : AZ단위로 확장 가능하며 다른 AZ로의 두번째 구성이 가능해야 합니다.
  • 백업 및 운영 관리 : API와 대시보드를 통해 손쉽게 관리할 수 있어야 합니다.
  • 이중화 : 여러 가용영역에 DB를 구성하여 장애 대응에 맞게 구성해야 합니다.
  • Failover : 데이터가 기능, 속성별로 독립적으로 저장되어 있어 대체작동이 가능해야 합니다.

AWS 장애 대응 정리

• AWS 장애 대응 개념
  • 자동으로 장애를 복구,복원이 가능하도록 시스템을 구성하고 어플리케이션이나 서비스의 장애 요소(SPOF)들을 제거해야 합니다.
• 기능별 독립형 설계
  • 무중단 서비스를 위해 하나의 서버에 장애가 발생했을 시 다른 서버는 그 장애와 무관하게 지속적으로 서비스가 가능하도록 분리하여 동작하게 설계해야 합니다.
• 탄력성, 동시성, 보안을 고려한 구성
  • 탄력성을 통해 자원의 낭비를 줄이고 비용의 과도 청구를 막을 수 있습니다. 그리고 동시 다발적인 요청 사항을 처리할 수 있는 시스템 설계를 통해 서비스에 소요되는 물리적인 소요 시간을 단축하고 자동화할 수 있습니다.
  • 클라우드의 다양한 보안 사례 및 방법을 감안하여 서비스의 보안 요구사항에 맞는 구성으로 안정적인 보안 레벨을 높일 수 있습니다.
• AWS의 리전, 가용영역 및 엣지
  • Region(지역)은 Availability Zone(가용 영역)이라고 불리우는 물리적으로 격리된 데이터센터들의 집합이며, 이 가용영역에서 인스턴스와 데이터를 저장하고 이중화 구성을 할 수 있도록 지원합니다.
• AWS의 Compute 서비스
  • AWS 시스템의 가장 기본적인 구성자원인 컴퓨팅 리소스들은 가용영역 안에서 구축됩니다. 그리고 원하는 만큼 클라우드 서버를 사용 가능하여 보안 및 VPC 네트워크를 구성하고 운영상 추후에 일어날 장애 발생 소지를 피하기 위한 모니터링 시스템 설정이 가능합니다.
• AWS의 데이터베이스
  • 서비스 요구사항에 적합한 데이터베이스의 용량과 성능을 구성하고 시간소모적인 관리 작업(패치, 백업, 확장)을 효율적으로 지원합니다.