AWS WAF(Well-Architecture Framework)

지난 시간에 Cloud란 무엇인가?에 대해 살펴보았습니다.

다양한 관점에서 Cloud 서비스의 등장 및 장점에 대해 살펴 보았구요. 이번 포스팅부터는 AWS에 대해 본격적으로 살펴보도록 하겠습니다.

그 첫번째로 AWS CAF, AWS WAF를 살펴보고 아키텍처에 대한 검증 과정에 대해 살펴보겠습니다.

 

# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.

 

먼저 AWS 기반 클라우드는 크게 3가지로 나눌 수 있습니다.
IT 운영팀 - IaaS : EC2, S3, VPC - 인프라 기반의 서비스라고 볼 수 있죠.
개발자 - PaaS : DataBase, Elastic Beanstalk - IaaS 기반에 올라가는 플랫폼 들이라고 볼 수 있죠.
End User - SaaS - 서비스 제공 플랫폼 그냥 단순히 네이버에서 제공하는 전화번호 동기화 서비스도 SaaS라고 볼 수 있어요.

 

이러한 클라우드 서비스를 성공적으로 수행하기 위해서는 무엇보다 아키텍처링이 중요한데 그럼 내가 만든 아키텍처를 매번 AWS 솔루션 아키텍트에게 검토 받을 수도 없고, 물론 돈도 많이 들구요.

내가 설계한 아키텍처가 얼마나 잘 설계된 것인가에 대한 접근 방식이 있어야 실패하지 않을 프로젝트를 설계할 수 있을 것이라 생각하는데요.

AWS에서는 바로 이러한 우리의 고민을 위해 CAF / WAF 서비스를 제공합니다.

Well Architected 프레임워크 (WAF)

충격적인건 이 WAF 서비스가 바로 무료라는 점입니다. 한번 AWS WAF 서비스에 접근해 보도록 하겠습니다.

안타깝게도 아직 아태 지역에서는 시드니만 지원되고 있네요. 지역을 시드니로 변경하고 한번 다시 들어가 볼께요.

우리나라에도 정식 서비스가 얼릉 런칭했으면 좋겠네요. 다만 WAF 서비스의 경우 어느 지역이든 상관없이 사용이 가능해요. 기본적으로 제공하는 것이 문서 형태로 제공되기 때문이라 우리가 어떻게 설계하면 좋은지 살펴 볼 수 있습니다.

AWS에서 제공하는 프레임워크는 두가지가 있습니다. 바로 CAF, WAF 서비스 인데 다음과 같은 차이가 있습니다.
- CAF : Cloud Adoption Framework (Cloud Migration 전 준비 용도 / 문서 형태 제공) - 어떠한 것들이 변경되고, 이것들이 준비가 되어 있는지? 문서를 다운받아 체크하고 점검하는 용도
- WAF : Well Architected Framework (실제 운영에 맞게 준비 되었는지 검토 / 문서 형태로 제공되었다가 최근 서비스 형태로도 제공 / AWS Well-Architected Tool) - 보안, 안정성, 비용 최적화, 성능 효율성, 운영 우수성 등에 맞게 아키텍트가 되어 있는지 여부를 검토

이러한 서비스가 무료로 제공된다는 것 자체가 대단하기도 한데요.

WAF를 통해 검토 가능한 다양한 설계 방식을 지금부터 알아보겠습니다.

Well Architected Framework (WAF) 설계 원칙

WAF 설계 원칙 1. 보안

Public Cloud 공간의 다양한 장점이 있음에도 사용자들이 왜 Private을 선호하는지를 가만히 들여다 보면 바로 Public 공간에 개인정보나 민감정보가 유출되는 것은 아닌가에 대한 두려움이 있기 때문이죠. 특히 이커머스 플랫폼의 경우 고객 정보가 어마어마하게 방대하기 때문에 유출시 발생할 위험도 또한 엄청난 파장을 일으킬 수 있죠.

마찬가지로 공공기관 역시 이러한 두려움 때문에 Public 보다는 아직은 Private Cloud를 선호하고 있습니다.

따라서 AWS에서는 보다 강력한 보안 기능을 통해 안전하게 데이터를 보호하고 있으며, 아래와 같은 기능에 대한 확인이 필요합니다.

---

- 자격 증명 기반 (IAM)
- 추적 가능성 활성화 (CloudTrail)
- 방화벽 서비스 / L7 (WAF)
- 위험 평가 및 완화 전략 (Cloud Front)

---

WAF 설계 원칙 2. 안정성

안정성 측면은 클라우드의 장점을 그대로 가져갈 수 있는 핵심 포인트입니다. 기존 인프라 중심의 환경에서 발생하는 단일 장애 지점(SPOF - Single Point Of Failure), 동적 리소스 확보를 통한 자동화 / 탄력성 확보 여부 그리고 고가용성, 내결함성 확보등을 설계에 적절히 적용했는지 판단합니다.

---

- 동적 트래픽에 맞게 적용했는지 여부 (ELB, CloudWatch, Autoscaling Group)
- 복구 정책
- 특정 데이터센터가 장애가 발생했을때도 가용성 확보가 가능한지 여부

---

WAF 설계 원칙 3. 비용 최적화

Public Cloud 서비스로 전환되면서 가장 고려해야 할 부분은 비용 문제입니다. 비용적인 관점에서 모든 사용료를 지불하게 되는 리스 방식이다보니 때로는 Private 환경보다 저렴할수도 때로는 불필요한 트래픽 등으로 인한 과비용 지불 등의 문제를 발생 시킬수도 있습니다.

이를 적절히 극복해 나가기 위해서는 정말 많은 노력을 설계에 적용해야 하는데, 이 또한 WAF에서 적절히 적용할 수 있도록 가이드하고 있습니다.

또한 예기치 안게 비용이 발생하는 경우에 대비하여 다음과 같은 사항을 검토해 보아야 합니다.

교육 당시에도 강사님이 강조하신 내용 중 하나인데 나는 사용 안했는데 갑자기 비용 폭탄이 날라오는 경우가 종종 있다고 합니다.

대표적으로 RDS의 AMI 비용 청구 문제나, ESB 볼륨만 삭제하고 스냅샷을 제거하지 않는다거나, EIP를 생성하고 사용하지 않는다거나, Instance를 기동하고 종료하지 않은 상태로 유지한다거나 하는 상황이 발생하면,, 1년 뒤 갑자기 비용 폭탄 청구서를 받았을때 얼마나 끔직할지..

아래는 예기치 않은 비용을 방지하기 위한 AWS의 지침서입니다.

https://docs.aws.amazon.com/ko_kr/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html

예기치 않은 비용 방지 - AWS Billing and Cost Management

비용에 대한 고려는 PI, POC, 이행 단계에서는 물론 오픈하고 난 이후에도 아니 시스템이 운영되는 모든 시간에 항상 고려해야 할 포인트입니다. 현재보다 최적을 고민하면서도 어떻게 하면 비용을 적게 지불 할 것인지에 대한 고민은 끊임없이 고려해야할 아키텍처의 역할이라고 볼 수 있습니다.

---

- 효율성 측정에서의 설계
- 불필요한 비용 제거 (Over Provisioning 발생 여부 검토)
- 관리형 서비스 사용을 고려
AWS에서 제공하는 서비스 형태는 3가지가 있습니다.
1) D.I.Y (EC2 방식으로 어플리케이션을 직접 배포하는 방식)
2) 관리형 서비스 (RDS 서비스 - AWS가 직접 관리해주는 방식 (Master / Slave 형태로 관리 해주면서 고가용성, 확장성 등에 대한 설정은 직접 선택해야 함) / 비용이 조금 더 비쌈 / 오히려 인력비나 사이드 적인 관리 플랫폼 사용으로 인한 비용 절감이 될 수도 있음)
3) 완전 관리형 서비스 (DynamiDB - 설정은 물론 가용성, 확장성, Scaling, 장애 발생 등 모든 부분을 자동 관리해주는 방식)

관리형 서비스가 대체로 일반 D.I.Y 방식보다 지불 비용이 비싸지만, D.I.Y 방식에서 범하기 쉬운 문제들을 자동으로 해결해 주고 비용 효율적인 아키텍처를 설계할 수 있도록 해준다는 장점도 있습니다. 추가적으로 연동해야할 여러 서비스들에 대한 자동 설계까지 지원해주고 오토 프로비저닝 관리 역시 지원되는 관리형 또는 완전 관리형 서비스를 사용하는 것이 오히려 비용적인 이점을 가져 갈 수 있다는 것 역시 고려해 봐야 합니다.

---

WAF 설계 원칙 4. 운영 우수성

클라우드 서비스 그리고 나아가 마이크로 서비스를 제공해야 할 아키텍처 입장에서 과연 무엇이 가장 중요한가를 묻는다면 단연 운영 우수성입니다.

세분화된 서비스와 프로비저닝 된 다양한 클라우드 서비스 간의 모니터링 / 로깅 / 트레이싱을 어떻게 관리해 갈 것인가를 고민하는 것은 사실 클라우드 서비스를 어떻게 설계할 것인가와 비교할 만큼 중요한 요소입니다.

또한 클라우드 서비스가 제공하는 애자일 방법론에 맞춰 개발을 위한 자동화 과정은 물론 배포/업데이트/운영 방식을 자동화 설계하고 효율성에 대한 검토를 지속적으로 진행해야 합니다.

 

WAF 설계 원칙 5. 성능 효율성

성능 효율성을 논하기 위해서는 먼저 제한적인 리소스 즉 클라우드에서는 제한적인 비용 정책을 고려해 둔 상태로 효율성을 고려해야 합니다.

무슨소리냐면 바로 클라우드 서비스가 엄청난 확장 서비스를 제공한다고 한들 무작정 EC2 VM 또는 컨테이너를 늘린다면? 비용 폭탄을 맞고 해당 사이트는 마비되버리겠죠. 돈이 없으니.. 이를 위해 제한된 비용안에 어떻게 최적화 할 것인가를 고민해 보는 것이 중요합니다.

---

- 효율적인 리소스를 선택하고 수요 변화에 맞춰 효율성을 유지하는가? 즉 최선이냐?
- 최근 고급 기술을 적용했을때 성능 개선 포인트가 있는지? 그 기술은 과연 누가 적용해 줄 수 있는지? 벤더사인지? 스스로 할 수 있는지?
- Mechanical sympathy (CPU, MEMORY, I/O 등에 최적화 되어 있는지 여부까지 검토)

---

Well-Architected 프레임워크만 잘 활용해도 어느정도 검토는 가능할 것 같은데요. 물론 이전에 설계가 가능해야 검토도 받을 수 있겠죠. AWS에서 제공하는 수많은 서비스를 모두 다루는 것은 시간상 오래 걸릴 것이고 전부 내가 필요한 것들도 아닙니다.

앞으로 진행될 포스팅에서 하나씩 살펴 보긴 하겠지만, 대표적인 서비스만 다뤄볼 예정이라, 나머지 서비스들은 직접 테스트 해보고 함께 공유해봐요.

---

AWS-Cost-Optimization-Pillar.pdf

0.20MB

AWS-Operational-Excellence-Pillar.pdf

0.16MB

AWS-Performance-Efficiency-Pillar.pdf

0.24MB

AWS-Reliability-Pillar.pdf

0.59MB

AWS-Security-Pillar.pdf

0.20MB

---

# 첨부한 문서는 AWS에서 제공하는 공개된 WAF Documentation입니다. 아키텍처를 진행할 때 참고해서 설계하세요.

아래 문서는 한글 버전 문서입니다.

Well-Architected_Whitepaper_ko-2016-11.pdf

0.78MB