Part 9. AWS Well Architecture

SMALL

참고자료

커리어 성장을 위한 최고의 실무교육 아카데미 | 패스트캠퍼스

 

Well-Architecture를 위한 필수 요소

AWS 아키텍팅을 하기 전 필수 요소들에 대해 알아보자. 크게 다음 5가지가 있다.

• 운영 우수성
• 보안
• 안정성
• 성능 효율성
• 비용 최적화

 

운영 우수성

말 그대로 운영을 우수하게 해야한다는 것이다. 운영 시 변경 작업이 생기면 변경 작업을 최소 단위로 나누어 수행해야하고 변경 시 문제가 발생할 경우를 고려해서 롤백을 염두한 변경작업을 수행해야 한다. 운영 프로세스를 자주 개선해서 최적의 환경을 유지하는게 중요하며 장애 시나리오를 만들어서 장애를 통해 배우는 과정 역시 중요하다.

 

보안

보안이 빠진 시스템은 완전한 시스템이라 할 수 없다. 좋은 보안을 위해선 시스템의 모든 접근에 대한 추적 및 기록이 필요하고 모든 계층(OSI 7 Layer)에 대한 보안을 적용하고 보안을 위한 자동화 구현 설계가 되어야 하며 모든 데이터(전송 중인 데이터, 정적 데이터)를 보호하도록 설계해야 하고 보안 이벤트(침입탐지, DDOS)를 대비해야 한다.

 

각 계층별 보안 이라는 것은 다음 표처럼 각 구간에서 필요한 보안을 철저히 다루어야 한다는 것이다.

계층	보안 시스템 및 기술	내용
어플리케이션 보안	- AWS WAF&Shield - AWS Inspector	- 웹 방화벽 및 DDOS 공격 방어 - Agent 기반 / Application 보안 진단
네트워크 보안	- Security Group - VPC NACL - VPC Flow logs - Bastion Host - HTTPS/SSL/TLS	- AWS 리소스에 대한 네트워크 접근 통제 - AWS 서브넷 간 네트워크 접근 통제 - VPC 내 트래픽 분석 및 가시화 - 내부 네트워크 접근을 위한 프록시 - 네트워크 전송 구간 암호화
시스템 보안	- Service Catalog - AWS Config - AWS IAM (MFA/Role) - Cloud Watch Logs - Trusted Advisor	- 표준화된 AWS 리소스 생성/접근제어 - AWS 리소스 변경 내역 기록/관리 - AWS 계정 접근제어/권한관리 - AWS 리소스 및 Application 모니터링 - 비용/가용성/성능/보안 측면의 감사
데이터 보안	- AWS KMS - AWS CloudHSM - AWS CloudTrail	- 암호화 키 관리 - 위변조 감시 가능한 암호화 키 관리 - 모든 AWS API 요청에 대한 로그 기록
물리 보안	- 규정 준수 프로그램 - 보호설비 - 물리적 출입통제	- ISO27001, ISMS, PCI DSS, FedRAMP - 화재 감지 및 진압, 전원이중화, 항온항습 등 - 영상감시, 침입탐지, 보안카드, 2중 인증

 

 

안정성

시스템의 안정성을 높이기 위해 장애에 대한 자동 복구 기능을 구축하고 장애 복구 훈련을 수행하며 가용성을 높이기 위한 수평 확장 설계가 필요하고 스펙 추측이 아닌 확장 가능하도록 설계하며 운영 자동화의 지속적 변경 및 관리가 필요하다.

 

 

성능 효율성

좋은 성능을 위해서 최신 기술에 대한 습득 노력과 적용이 필요하며 주기적인 프로토타입을 진행하고 빠른 글로벌 접근 가능한 설계(필요하다면)가 좋고 서버리스 아키텍쳐를 활용해서 성능의 최적화를 해야한다.

 

 

비용 최적화

알맞는 가격 약정을 채택해서 비용 누수가 발생하지 않도록 하며 리소스에 대한 Right Size 분석과 클라우드로 마이그레이션을 통해 온프레미스 운영비용을 최소화하고 관리형 서비스를 사용해서 운영비용을 최소화하고 지속적인 월 비용 분석을 통해 비용 최적화를 수행해야 한다.

 

 

AWS Well Architecture Infra 

9단계의 AWS 서버 인프라 확장 과정을 통해 본인에게 맞는 인프라를 구축해서 효율적인 서비스를 해야한다.

 

첫번째 단계

AWS EC2에 Elastic IP를 사용해서 외부에서 접근 가능하도록 설계하고 Route53 서비스를 통해 리소스로 라우팅 해주는 구조이다. 가장 간단한 구조라고 보면 된다.

 

두번째 단계

이번엔 가용성을 늘리기 위해 EC2 인스턴스를 하나 더 연결하고 다른 AZ를 활용해서 트래픽 관리를 효율적으로 하게끔 설계했다. 두 개의 가용영역 중 한 곳에 단일 RDS 서비스를 사용해서 데이터베이스로 각 EC2가 접근할 수 있도록 설계했다. 이 설계의 단점이라고 할 것 같으면 하나의 데이터베이스만 사용하기 때문에 트래픽이 과도하게 몰릴 때 성능 저하나 복구 대비가 부족하다.

 

 

세번째 단계

두번째 단계에 확장해서 RDS 서비스를 하나 더 만들고 Master - Slave 관계를 구축해서 Master에서 장애가 발생하는 경우 Slave쪽으로 Failover할 수 있도록 구현했다. 위 두번째 단계의 단점인 장애복구를 다룬 단계이다.

 

 

네번째 단계

위 단계에서 로드밸런서를 도입하여 적절한 부하분산과 트래픽 처리에 용이하게 설계됐다.

 

 

다섯번째 단계

위 단계에서 AutoScaling 기술을 통해 EC2의 성능 고려를 추가로 보완했다.

 

 

여섯번째 단계

위 단계에서 S3 서비스를 도입하여 정적 컨텐츠를 따로 관리하여 EC2의 리소스 할당에 무리가 가지 않도록 설계했다.

 

 

일곱번째 단계

위 단계에 CloudFront 서비스를 도입해서 캐싱을 통해 요청을 처리할 수 있는 가장 빠른 엣지 로케이션으로부터 정적 컨텐츠를 받아올 수 있도록 성능 개선을 했다. 

 

 

여덟번째 단계

위 단계에서 정적 컨텐츠 뿐 아니라 동적 컨텐츠까지 CloudFront를 통해 응답받게 설계했다. 로드밸런서를 통해 특정 EC2에 접근할 때 장애가 발생하는 경우 다른 EC2로부터 요청을 처리할 수 있고 캐싱 기술을 통해 더 빠른 응답을 할 수 있게 했다.

 

 

아홉번째 단계

위 여덟번째 구조에서 더 나아가 글로벌하게 구조를 변경했다. 

 

 

결론

현재 주어진 상황과 프로젝트 규모에 맞게 인프라를 설계하면 된다는 것과 설계 시 필요한 핵심 요소들에 대해 정리해보았다.