style

border-bottom-glow

AWS에서 로그 보존 관리: S3 수명 주기 규칙 및 Terraform 모범 사례

클라우드 비용이 눈에 띄지 않게 증가하는 가장 쉬운 방법 중 하나는 로그 보존입니다. 많은 조직이 로그 수집의 중요성을 이해하고 있지만, 로그에서 얻은 데이터를 최적화하고 활용하는 방법을 이해하는 조직은 더 적고, 로그를 얼마나 오래 보관해야 하는지 이해하는 조직은 더욱 드뭅니다. 회사에서 이러한 로그에 얼마나 자주 액세스하는지, 그리고 현재의 스토리지 전략이 비즈니스 요구 사항에 여전히 부합하는지 파악하는 것이 중요합니다.

고객과 함께 로깅 전략을 검토하는 과정에서 공통적인 문제점을 발견했습니다. 로그가 필요 이상으로 오래 보관되고 있었고, 스토리지 비용은 계속 증가하고 있었으며, 환경 전반에 걸쳐 표준화된 수명 주기 정책이 없었습니다.

이 문제를 해결하기 위해 Amazon S3 수명 주기 관리 및 IaC(Infrastructure as Code)를 기반으로 하는 공식적인 로그 보존 정책을 개발했습니다. 그 결과, 로그 관리 방식이 더욱 일관성 있게 개선되었고, 저장 비용이 절감되었으며, 운영 및 규정 준수 요건에 더욱 부합하는 보존 전략을 수립할 수 있었습니다.

저장 클래스가 아닌 목적부터 시작하세요

조직이 저지르는 가장 큰 실수 중 하나는 비즈니스 요구사항보다 기술부터 시작하는 것입니다.

많은 보존 정책은 "만약에"라는 시나리오를 기반으로 수립됩니다.

2년 전의 로그가 필요하다면 어떻게 해야 할까요?
만약 조사에 12개월 전의 과거 데이터가 필요하다면 어떻게 해야 할까요?
만약 우리가 더 이상 가지고 있지 않은 기록을 누군가 요청한다면 어떻게 해야 할까요?

이러한 질문들은 타당하지만, 종종 모든 정보를 무기한으로 보관하게 되는 결과를 초래합니다.

대신, 몇 가지 간단한 질문부터 시작해 보세요.

이 로그들의 실제 목적은 무엇인가요?
얼마나 자주 접속하시나요?
해당 정보에 접근할 때, 어떤 비즈니스 가치를 제공합니까?
보존 기간을 규정하는 법규 준수 요건이 있습니까?
로그 보존에 대한 결정권은 누구에게 있습니까?
어떤 것도 희생하지 않고 저장 비용을 줄이는 방법은 무엇일까요?

회사마다 차이가 있지만, 많은 경우 팀들은 몇 달 이상 된 로그는 거의 접근되지 않고 운영상 가치도 제한적이라는 사실을 발견합니다. 그것들은 안심을 주기 위해 존재하는 것이지만, 어느새 원치 않는 비용이 수 테라바이트에 달해 공간을 차지하고 불필요한 파일들을 쌓아두게 됩니다.

궁극적인 목표는 불필요한 저장 비용을 피하면서 조사, 문제 해결, 규정 준수 및 감사에 필요한 기간 동안 로그를 보존하는 것입니다.

환경마다 필요한 것이 다릅니다.

모든 환경에서 동일한 보존 기간이 요구되는 것은 아닙니다.

운영 로그는 감사, 사고 대응 및 보안 조사에 자주 활용됩니다. 개발 로그는 일반적으로 단기적인 디버깅에 사용되며, 보존 기간도 훨씬 짧습니다.

우리의 인재 유지 전략은 환경별 요구 사항을 중심으로 구축되었습니다. 아래는 이러한 예시를 보여주는 그림입니다.

생산

유지 기간: 12개월

운영 로그는 다음과 같은 이유로 가장 긴 보존 기간이 필요합니다.

보안 조사
사고 대응
규정 준수 및 감사 요건
역사적 운영 분석

생명주기 전략:

0~30일: S3 표준
31일~90일차: S3 표준-IA
91일~365일: S3 빙하 유연 회수
12개월 후 삭제

QA

보존 기간: 90일

QA 로그는 주로 다음을 지원합니다.

릴리스 검증
회귀 분석
과거 문제 해결

생명주기 전략:

0~60일: S3 표준-IA
90일 후 삭제

개발

보존 기간: 30일

개발 로그는 주로 다음과 같은 용도로 사용됩니다.

애플리케이션 디버깅
문제 해결
개발 지원

생명주기 전략:

0~30일차: S3 표준-IA
30일 후 삭제

각 환경에 맞게 보존 기간을 조정함으로써, 불필요한 곳에 비용이 많이 드는 프로덕션 수준의 보존 요건을 적용하는 것을 방지했습니다.

적합한 S3 스토리지 클래스 선택하기

Amazon S3는 다양한 액세스 패턴에 맞춰 설계된 여러 스토리지 클래스를 제공합니다.

핵심 교훈은 스토리지 클래스 선택은 추측이 아닌 실제 사용 사례를 기반으로 해야 한다는 것입니다.

다음과 같은 질문들을 고려해 보세요:

로그 파일은 얼마나 자주 접근되나요?
특정 종류의 통나무가 다른 종류보다 더 가치가 있나요?
현재 저희 S3 버킷은 어떻게 설정되어 있나요?
첫 달 이후에는 거의 접속하지 않는 건가요?
그것들을 얼마나 빨리 회수해야 합니까?
회수 비용은 허용 가능한 수준인가요?

저희 사용 사례의 경우:

S3 표준

즉시 접근이 중요한 새로 생성된 프로덕션 로그에 사용됩니다.

S3 표준-IA

로그에 가끔 접근해야 하지만 표준을 준수할 만큼 시급한 요구 사항은 더 이상 필요하지 않을 때 사용됩니다.

S3 빙하 유연 회수

접근이 드물지만 필요시 검색이 가능한 장기 보관용으로 사용됩니다.

AWS는 사용 가능한 S3 스토리지 클래스와 각 클래스의 장단점에 대한 자세한 정보를 제공하며, 해당 정보는 여기에서 확인할 수 있습니다.
https://aws.amazon.com/s3/storage-classes/

코드형 인프라(Infrastructure as Code)는 거버넌스를 더욱 쉽게 만들어줍니다.

보존 정책은 일관되게 시행될 때에만 가치가 있습니다.

환경 전반에 걸쳐 라이프사이클 규칙을 수동으로 구성하는 대신, Terraform을 사용하여 라이프사이클 정책을 구현했습니다.

이는 다음과 같은 몇 가지 이점을 제공했습니다.

재사용 가능한 라이프사이클 구성
버전 관리되는 변경 사항
풀 리퀘스트를 통한 동료 검토
다양한 환경에 걸쳐 일관된 배포
구성 변경 위험 감소

코드형 인프라(Infrastructure as Code)는 보존 관리를 일회성 구성 작업에서 반복 가능한 운영 프로세스로 전환했습니다.

실수로부터 자신을 보호하세요

수명주기 정책은 삭제 및 저장소 전환을 자동화합니다. 그것은 그들을 강력하게 만들지만, 동시에 잠재적으로 위험하게 만들기도 합니다.

자동 만료 및 전환 기능을 활성화하기 전에:

S3 버킷 버전 관리를 활성화합니다.
비운영 환경에서 라이프사이클 규칙을 검증합니다.
전환 시간 계산을 확인하십시오.
테스트 객체 만료 동작
검색 워크플로 검증
적절한 버킷을 대상으로 하세요

버전 관리는 실수로 인한 삭제나 잘못 구성된 수명 주기 규칙으로부터 추가적인 보호 기능을 제공합니다.

생산 전 테스트

우리는 출시 전에 간단한 검증 절차를 마련했습니다.

개발 전용 버킷을 생성하세요.
개발 로그를 버킷에 보관합니다.
제안된 생명주기 정책을 적용합니다.
스토리지 클래스 전환을 검증합니다.
만료 동작을 확인합니다.
문서 검색 결과입니다.
다른 개발 버킷으로 이동하기 전에 승인을 받으세요.
더 높은 환경으로 승진시키세요

이러한 접근 방식을 통해 위험을 최소화하면서 구성 문제를 조기에 파악할 수 있었습니다.

지배구조는 중요합니다

로그 보존은 특정 엔지니어 한 사람이 독점해서는 안 됩니다.

성공적인 인재 유지 정책을 위해서는 다음 간의 협력이 필요합니다:

DevOps 팀
보안팀
규정 준수 팀
인프라 리더십

명확한 소유권은 시스템이 발전함에 따라 보존 기간이 비즈니스 및 규제 요구 사항과 일치하도록 보장하는 데 도움이 됩니다.

마지막으로

가장 효과적인 로그 보존 정책은 반드시 로그를 가장 오랫동안 보관하는 정책은 아닙니다.

균형을 잡아주는 것이 바로 그것입니다.

비용
규정 준수
보안
운영 가시성
간단

조직들은 실제 사업상의 필요성보다는 미래에 필요할지도 모른다는 가능성 때문에 데이터를 보관하는 경우가 많습니다. 로그 사용 방식을 이해하고, 환경별 요구 사항에 맞춰 보존 기간을 조정하고, 적절한 S3 스토리지 클래스와 스토리지 전환을 활용하고, IaC를 통해 정책을 구현함으로써 팀은 실제로 필요한 가시성을 유지하면서 스토리지 비용을 크게 절감할 수 있습니다.

무엇보다 중요한 것은 모든 조직이 다르다는 점을 기억하는 것입니다. 여기에 설명된 수명주기 전략은 저희 사례에서는 효과적이었지만, 보존 기간, 스토리지 유형 및 아카이빙 일정은 항상 운영 요구 사항과 규정 준수 의무에 따라 결정되어야 합니다.