마음을 잃지 않고 안전하고 신뢰할 수 있는 AWS 클라우드 아키텍처를 실제로 구축하는 방법

소개

AWS에서 클라우드 아키텍처를 처음부터 설계해 본 적이 있다면 이미 알고 계시겠지만, 자유와 혼돈이 공존하는 곳입니다. 무언가를 구축하는 방법은 수천 가지가 있으며, 망치는 방법도 그에 못지않게 많습니다.

AWS 설명서를 잠깐 살펴보면 "좋아, 모범 사례를 준수하면 되겠지"라고 생각할 수 있습니다. 하지만 실제 국제 환경에서는 실제 상업적 기업의 요구 사항, 가격 범위 제한, 인적 오류로 인해 일류 관행이 그대로 적용되지 않는 경우가 많습니다. 그렇기 때문에 초기에 퍼프시스와 같은 전문가와 함께 운영하면 보호 구멍이 있는 도박을 하고 나중에 문제를 확대하는 것을 방지할 수 있습니다.

목표는 단순히 실행되는 무언가를 얻는 것이 아닙니다. 트래픽이 급증하거나 특정 지역이 먹통이 되어도 무너지지 않는 시스템을 구축하는 것, 그리고 인터넷의 문을 활짝 열어두지 않는 것이 목표입니다.

당연한 것부터 시작하자: AWS는 괴물입니다.

AWS를 사용하면 거의 모든 것을 구축할 수 있습니다. 2인 스타트업부터 대규모 엔터프라이즈 플랫폼까지, EC2, Lambda, RDS, S3, IAM, VPC 등 모든 빌딩 블록이 있습니다. 문제는 무엇인가요? 옵션이 많을수록 복잡하게 얽히기 쉽다는 점입니다.

AWS의 설계가 나쁘다는 것은 아닙니다. 단지 제대로 설계해야 한다는 것입니다. 그렇지 않으면 일부 팀에서 '클라우드 스파게티'라고 부르는 상호 의존적인 서비스, 하드코딩된 비밀, 태깅, 로깅이 없고 비용이 얼마나 드는지 전혀 알 수 없는 상황이 발생할 수 있습니다.

안정성과 보안은 있으면 좋은 것이 아닙니다.

보안과 안정성을 미래의 문제로 치부하고 싶은 유혹에 빠지기 쉽습니다. "서비스를 시작한 후에 보안을 강화하겠습니다." "다음 스프린트에서 모니터링을 추가하겠습니다." 하지만 데이터 유출이나 몇 시간 동안의 서비스 중단을 겪어본 사람에게 물어보세요. 이러한 단계를 건너뛰면 결국 밤을 새우게 됩니다.

안정성이 실제로 의미하는 것

안정성은 슬라이드 데크의 가동 시간 보장에 관한 것이 아닙니다. 장애에 대비한 엔지니어링이 중요합니다. 서비스가 중단됩니다. 디스크가 고장납니다. API가 시간 초과됩니다. 중요한 것은 문제가 발생했을 때 시스템이 계속 작동하는지 여부입니다.

가용 영역 간에 중복성이 있나요? 시스템이 데이터 손실이나 오류 발생 없이 데이터베이스 노드 장애를 견딜 수 있나요? "배포하기 가장 쉬운 방법"이라는 이유로 중요한 워크로드를 단일 리전에서 실행하고 있나요? 이러한 질문은 운영 시스템과 복원력이 뛰어난 시스템을 구분하는 기준이 됩니다.

그리고 보안은요? IAM만이 아닙니다.

네, ID 및 액세스 관리(IAM)가 첫 번째 벽입니다. 하지만 보안은 그 이상으로 확장됩니다. 공개적으로 액세스 가능한 S3 버킷. 권한이 과도하게 부여된 역할. 람다 함수에 하드코딩된 비밀. "비용 절감을 위해" 로깅이 꺼져 있습니다. 이 모든 것은 시한폭탄입니다.

AWS의 잘 설계된 프레임워크를 사용하면 이러한 문제가 폭발하기 전에 식별하는 데 도움이 될 수 있습니다. 아키텍처를 보안, 안정성, 운영 우수성, 성능 효율성, 비용 최적화의 다섯 가지 주요 영역으로 세분화하여 팀에서 각각을 정직하게 평가하도록 합니다. 만병통치약은 아니지만 어려운 질문을 던지도록 유도합니다.

실제로 중요한 빌딩 블록

자, 이제 본론으로 들어가 보겠습니다. AWS에서 안전하고 안정적인 아키텍처를 구축할 때 중요한 사항과 팀이 가장 자주 실수하는 부분은 다음과 같습니다.

올바른 방법으로 IAM 역할 사용(예, 정말)

IAM 역할은 강력합니다. 때로는 너무 강력합니다. 무언가 작동하지 않는다고 해서 'AdministratorAccess'를 추가하고 나중에 고치겠다고 약속한 다음 고치지 않는 것이 너무 쉽습니다.

이를 조기에 차단해야 합니다. 최소 권한 원칙은 모범 사례일 뿐만 아니라 유일하게 정상적인 운영 방식입니다. 즉:

• 서비스별 범위가 지정된 역할

• 권한에서 와일드카드 사용 방지

• 수명이 짧은 자격증명

• 인간 사용자를 위한 필수 MFA

귀찮게 들리나요? 그렇죠. 하지만 상사에게 누군가 잘못 설정된 람다에서 고객 데이터를 유출한 이유를 설명하는 것도 마찬가지입니다.

의미 있는 네트워크 분리

이것은 지름길이 역효과를 내는 또 다른 영역입니다. 매우 복잡한 네트워크 설정이 필요하지는 않지만 몇 가지 기본 사항만 잘 지켜도 큰 도움이 됩니다:

• 인터넷과 마주해야 하는 것(예: ALB)에만 공용 서브넷 사용

• 그 외 모든 것을 위한 비공개 서브넷

• 아웃바운드 액세스 제어를 위한 NAT 게이트웨이

• 공용 인터넷에 접속하지 않고 AWS 서비스 트래픽을 위한 VPC 엔드포인트

모든 것이 동일한 서브넷에 있는 평면 VPC는 쉽게 느껴질 수 있습니다. 문제가 발생하여 모든 것을 망가뜨리기 전까지는 말이죠.

로깅 및 모니터링: 보이지 않는 것은 고칠 수 없습니다.

이제 더 이상 논쟁의 대상이 되어서는 안 됩니다. 로깅은 선택 사항이 아닙니다. CloudTrail, CloudWatch 메트릭, VPC 플로우 로그를 캡처하지 않으면 아무것도 볼 수 없습니다.

하지만 문제는 로깅만으로는 충분하지 않다는 것입니다. 로그를 실제로 살펴봐야 합니다. 중요한 항목에 대한 알림을 생성하세요. 노이즈를 걸러내세요. 그리고 모든 계정과 지역에서 로그를 중앙 집중화해야 합니다. 파편화된 가시성은 가시성이 아닙니다.

모든 것을 암호화하세요(예외 없이)

미사용 데이터에는 KMS를 사용하세요. 전송 중인 데이터에는 TLS를 사용하세요. 키를 순환하세요. 액세스를 모니터링하세요. 이것은 지금 게으르면 나중에 큰 대가를 치르게 되는 영역 중 하나입니다.

그리고 RDS 암호화, EBS 볼륨 설정, API 게이트웨이 TLS 적용과 같은 것들도 잊지 마세요. 이러한 작은 세부 사항들이 쌓이면 큰 문제가 됩니다.

코드형 인프라 또는 망가진 인프라

아직도 AWS 콘솔을 클릭해서 배포하시나요? 개발에는 괜찮지만 프로덕션에는 위험합니다.

Terraform, CloudFormation 또는 CDK를 사용하세요. 팀에서 선호하는 것이 무엇이든 하나만 선택해서 계속 사용하세요. 템플릿을 버전 관리하세요. CI/CD를 사용하여 배포하세요. 롤백 자동화. 수동 배포는 실수가 발생할 가능성이 높습니다.

또한 모든 것에 태그를 지정하세요. 태그가 없는 리소스는 마치 라벨이 없는 전선과 같아서 아무도 그 용도를 알지 못하고 모두가 건드리기를 두려워합니다.

침몰 없는 확장

확실히 말씀드리자면, AWS는 오버프로비저닝을 좋아합니다. 고객은 '성능'을 얻고, AWS는 수익을 얻습니다. 효율적인 확장은 사용자의 패턴을 파악하고 그에 맞는 계획을 세우는 것입니다.

자동 확장 그룹, 스팟 인스턴스(신중하게), 캐싱 레이어를 사용하세요. 하지만 더 중요한 것은 부하 상태에서 테스트하는 것입니다. 출시 이틀 후 실제 트래픽으로 인해 RDS 인스턴스가 녹아내리는 것을 발견하는 것은 원치 않을 것입니다.

또한 용량을 적절하게 예약하세요. 비용을 절약하고 갑작스러운 프로비저닝 실패를 방지할 수 있습니다.

재해 복구 계획은 선택 사항이 아닙니다

리전이 다운되면 어떻게 되나요? 기본 데이터베이스가 손상되면 어떻게 될까요? "어... 큰일 나겠지"라는 대답이 나온다면 DR 전략을 다시 짜야 할 때입니다.

그렇다고 해서 다른 리전에 동일한 인프라 사본을 구축하라는 뜻이 아닙니다. 알고 있어야 한다는 뜻입니다:

• 복원 대상

• 소요 시간

• 손실되는 데이터(있는 경우)

• 장애 조치 시 누가 무엇을 책임지는지

그리고 복구 계획을 테스트해야 합니다. 그렇지 않으면 허구에 불과합니다.

피해야 할 일반적인 안티 패턴

너무 자주 나타나는 몇 가지 안 좋은 패턴을 빠르게 정리해 보겠습니다:

• 모든 것을 위한 하나의 큰 계정: AWS 조직을 사용하세요. 프로덕션, 개발, 스테이징 등을 분리하세요.

• 기본 VPC 및 보안 그룹을 그대로 두기: 잠그세요.

• "테스트용" t2.micro 인스턴스에 과도하게 의존하는 경우 - 결국에는 프로덕션에 사용하게 됩니다.

• CloudWatch 비용에 대한 예산 미편성: 네, 로깅에는 비용이 듭니다. 로깅을 하지 않으면 더 많은 비용이 듭니다.

• "빨리 고치기만 하면 된다"는 접근 권한 부여: 대신 프로세스를 수정하세요.

마지막으로 하고 싶은 말이 있나요? 유연성 유지, 안정감 유지

클라우드 아키텍처는 완벽한 설정을 찾는 것이 아닙니다. 유연하고 견고하며 작성하는 사람뿐만 아니라 그 이상의 사람들이 이해할 수 있는 것을 구축하는 것입니다.

실제로 "완성"된 것은 결코 없으며, 이는 괜찮습니다. 중요한 것은 의도적인 태도입니다. 어려운 질문을 일찍 던집니다. 자주 감사하기. 중요한 부분을 자동화합니다. 그리고 언제 도움을 요청해야 하는지 알기.

솔직히 말해서 AWS는 강력하지만 길을 잃기 쉬운 곳이기도 합니다. 클라우드 아키텍처와 함께 살아 숨 쉬는 노련한 엔지니어와 함께 일하면 "대부분 작동"과 "밤에 잠만 잔다"의 차이를 만들 수 있습니다.

그리고 그것은 구축할 가치가 있습니다.