최근 AWS를 통한 클라우드 웹어플리케이션을 만드는 도중에 사용하는 서비스들에대한 의문이 있었습니다.
내가 과연 한게 알맞은 방법인가?
최근 AWS KRUG에 계신 분들에게 물어보았고 그에 대한 여러 팁들을 얻을 수 있었습니다.
저도 최근에 자주했던 실수들이고 그것이 실 운영에 올라갔을 경우 장애대비를 하기 힘들다는것을 알게 되었습니다.
여러분도 한번씩 점검을 해보셔서 적용을 해보시면 좋을것 같습니다.
- S3 데이터 관리 측면
- 종료 방지 기능측면
- 기본 VPC 사용
- VPC CIDR 생각 안하고 사용
- AutoScling 서비스 관리
S3 데이터 관리
많은 이용자가 S3버켓을 실수로 삭제하는 경우가 있습니다.
이 경우 복구가 될까요? 라는 질문을 많이 한다고 합니다.
중요한 파일들을 보관하는 용도로 사용하고 있었으나 , 그것을 실수로 다른 버킷과 착각후 삭제를 하게 되면 어떻게 될까요?
정답은 복구하기 힘들다 입니다.
그래서 S3는 여러가지 서비스들을 제공하고 있습니다.
버킷 복제 기능을 사용하시길 바랍니다.
- 동일 리전 복제(SRR)
- 교차 리전 복제(CRR)
- 계정간 복제가 가능합니다.
- 복제가 이루어진 버킷의 스토리지 클래스를 조정해서 비용을 줄일수 있습니다.
- 전체 버킷 또는 접두사, 태그 기반으로 복제가 가능합니다.
- SSL을 통한 안전한 전송이 가능합니다.
버전관리 기능
- 의도치 않은 사용자 작업 및 어플리케이션 장애로 부터 보호할 수 있습니다.
- 업로드할때마다 새 버전을 제공합니다.
- 삭제된 객체를 쉽게 검색하고 이전버전으로 복원이 가능합니다.
종료 방지 기능
자주 사용하는 EC2와 RDS는 종료방지 기능이 있습니다.
중요한 서비스는 이를 적용하는 것이 좋습니다.
사람이 실수로 일어나는 장애를 조심해야 합니다.
만약 실수로 인스턴스를 삭제하려고 할때 방지해주는 기능입니다.
클릭 몇번으로 활성화 가능하기 때문에 꼭 해주는것을 추천드립니다.
만약 클릭하면 문구가 뜨면서 삭제가 안되니까 좋은 기능입니다.
기본 VPC 사용
많은 AWS유저가 처음 클라우드를 사용할때 기본으로 제공해주는 VPC를 사용하게 됩니다.
필자도 최근까지 VPC의 개념을 숙지하지 못했기 때문에 기본 VPC를 가끔 사용해주곤 했는데, 이는 굉장히 위험한 행위입니다.
아키텍처는 다음과 같습니다.
서울리전은 4개의 가용영역을 가지고 있는데, 이 위에 EC2와 RDS를 배포해서 사용이 가능합니다.
하지만 다음과 같은 문제가 생깁니다.
보안 문제
AWS에서 흔히 쓰는 용어 private , public이 있습니다.
말 그대로 개인의 공공의 영역을 말을 하는데, 인터넷에서 바로 액세스가 가능한 영역인지 아닌지를 판별합니다.
만약 default vpc를 사용하게 되면 public이기 때문에 인터넷에서 언제나 접근이 가능해집니다.
public을 사용해서 공격받는 사례가 많습니다.
AWS well architecture를 보면 '인터넷에 액세스할 필요가 없는 VPC의 RDS 데이터베이스 클러스터는 인터넷에 연결되는 경로가 없는 서브넷에 배치해야 합니다' 라는 문구를 확인할 수 있습니다.
운영 문제
웹 오토스케일링이 되는 서버쪽에서 협력사와 통신을 주고받아야할 일이 있을텐데, 협력사 방화벽에 우리 아이피를 등록해줘서 사용합니다.
최초에 적은 대수의 ip는 문제가 안될수도 있지만 ,여러개의 서버가 가동된다고 생각을 해봅시다.
그렇게 하면 매번 whitelist에 ip를 등록해줘야 한다는 문제가 생깁니다.
만약에 ELB와 AutoScalingGroup으로 묶여 있으며 , 외부를 통신할때는 NAT Gateway를 통해서 나가게 되면 등록해야할 IP는 적어지게 됩니다.
그렇게 되면 다른 역할에 서버들이 협력사에 연락할 일도 적어지게 됩니다.
적절한 서브넷과 라우팅테이블 커스텀 VPC 를 꾸리는것을 추천드립니다.
가용 영역 선택
같은 VPC에서 통신을 하더라도 리소스가 많다고 하면,
리소스간에 트래픽을 주고받을 일이 많으면 무시할 금액이 아닙니다.
동일 AWS 리전내 데이터 전송
동일 AWS 리전 내 가용영역 또는 VPC 피어링 연결 전체에 걸쳐 Amazon EC2, RDS , Redshift , DaynamoDB 등 송신 및 수신 되는 데이터는 각 방향에 대해 GB당 0.01USD가 부과됩니다.
위와같은 그림이 있다고 가정을 합니다.
해당 영역에서 불필요하게 데이터 비용이 발생하는 구간이 어디있을까요?
바로 WAS와 DB가 통신하는 구간입니다.
만약 위와같은 상황이면 같은 가용영역에 WAS와 DB를 위치시켜주는것이 좋습니다.
AutoScling 서비스 관리
평소에는 크게 부하를 받지 않는 서비스를 Auto Scaling에 인스턴스를 하나만 올려놓을 경우도 많이 있으실 겁니다.
만약 이 인스턴스가 어떠한 오류로 인하여 헬스체크가 실패할 경우가 있을텐데, 헬스체크 실패의 횟수가 일정량 넘어가면 인스턴스가 종료됩니다.(말 그대로 삭제)
그리고 이상상태의 인스턴스가 제거가 되고 지정해놓았던 인스턴스 갯수대로 인스턴스가 올라오게 됩니다.
만약 EC2의 원본이 되는 AMI가 옛날에 생성했던것이고 그대로 올리게 되면 예전 AMI로 올라가게 됩니다.
백업도 해놓지 않았을 경우는 원상복구가 힘들수도 있습니다.
그래서 AWS는 다음과 같은 행위를 추천합니다.
- 배포 프로세스를 마련하자
- 새로운 인스턴스 패키지가 최신버전이 배포되는 프로세스가 한대밖에 없으면 정상적으로 복구되었을 것입니다.
- 다양한 방법을 사용할 수도 있습니다. AWS CodeDeploy 툴, 단순히 인스턴스가 실행될때 Userdata를 이용해 피키지 S3업데이트 등을 쓰기도 합니다.
- 주기적인 AMI를 업데이트 하자
- 현재 사용하는 AMI가 오래되었는데 userdata를 통해 서비스를 하는 사람이 많다고 합니다. 소스코드 업데이트를 하고 패키지를 업데이트 하려고 하면 시간이 많이 걸리기 마련ㅇ비니다.
- 업데이트를 하지 않는 기간이 길면 길수록 배포에 대한 시간이 소요가 많이 된다고 합니다.
- AMI는 주기적으로 최신본으로 교체하시길 바랍니다.
- 백업을 하자
- 만약에 해당 케이스에 가까운 시일에 있던 AMI가 있었으면 금방 복구할 수 있었을 것입니다.
마무리
이 처럼 여러가지 실수 모음들을 알아보았는데, 저도 처음 배우면서 제공해주는것을 그대로 쓰다 보니까 실 운영환경에 넘어가서 많은 고초들을 겪었습니다.
한번 점검해보시고 만약 실수를 하고 계시면 얼른 고치는것을 추천드립니다!
'AWS' 카테고리의 다른 글
| AWS JAVA sdk 버전 관리에 대하여 (0) | 2021.03.15 |
|---|---|
| AWS IAM Role 이란? (0) | 2021.03.04 |
| 우리는 인프라 환경을 어떻게 구축해야 하는가? - AWS 상담편 (0) | 2020.11.23 |
| AWS완전관리형서비스를 이용한 도커 및 쿠버네티스 개발환경구축과정 - 4주차 (0) | 2020.08.29 |
| AWS완전관리형서비스를 이용한 도커 및 쿠버네티스 개발환경구축과정 - 3주차 (0) | 2020.08.22 |