ㅁ 풀어야 할 문제
각 서버에서 대량으로 발생하는 로그나 백업 파일은 일정 기간 보관해야 한다. 그러나 그 때문에 대용량 디스크를 준비하는 것은 비용적으로 효율이 좋지 않고, 특히 규모가 커져가는 시스템에서는 보관할 파일 용량을 산정(Capacity Plan)하기가 쉽지 않다.
각 서버의 로그를 공유 스토리지에 저장하고 단기간 로테이션하면 각 서버의 디스크 확장을 위한 점검 시간을 없앨 수 있다. 그러나 공유 스토리지에 대해서도 위와 같은 캐퍼시트 플래닝에 대한 문제가 존재한다.
ㅁ 해결/패턴
클라우드에서는 실제 용량 제한이 없는 인터넷 스토리지가 있는 경우가 많고, 이 인터넷 스토리지를 로그 저장소로 이용할 수 있다. 이 경우, 디스크 확장을 위한 점검과 사전에 Capacity Planning을 고려할 필요 없이 쉽게 공유 스토리지에 로그를 저장할 수 있다.
S3는 고가용성과 안정성을 가지고 있고 로그 저장소로 적합하다. S3로의 업로드는 툴(예를 들어, s3층나 s3sync 등)을 이용하면 쉽게 업로드가 가능하다.
- EC2에서 출력되는 각종 로그를 로그 로테이션 소프트웨어(logrotate 등)로 로케이션 한다.
- 로테이션 타이밍에 로그를 S3에 보관한다. (로테이션 스크립트에 S3로 업로드하는 처리를 넣어준다.)
- S3에 로그를 보관하면 디스크 공간을 신경 쓰지 않아도 되며, 또한 장애에 따른 로그 손실 위험성도 없어 로그를 안전하게 계속 보관할 수 있다.
- 백업 파일 보관도 같은 구조를 이용할 수 있다.
- EBS는 정액제 요금 부과 방식이지만, S3는 종량제 요금 부가 방식이다. 보다 합리적인 운영이 가능하다.
- 로그 로테이션을 하기 전에 EBS에 장애가 발생하는 경우는 이전 로테이션부터의 로그는 분실된다.
- Auto Scaling을 이용할 때는 EC2의 종료 시에도 해당 로그를 S3에 보관해야 한다.
'AWS Design Pattern > 운영 유지 보수 패턴' 카테고리의 다른 글
Weighted Transition - 가중치 라운드 로빈 DNS적용을 이용한 이전 (0) | 2021.02.05 |
---|---|
Monitoring Integration - 모니터링 툴 일원화 (0) | 2021.02.05 |
Server Swapping - 서버 이전 (0) | 2021.02.05 |
Stack Deployment - 서버 군의 템플릿화 (0) | 2021.02.05 |
Cloud DI - 변경이 많은 부분의 분리 (0) | 2021.02.05 |