この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
S3는 버킷의 액세스 로그를 다른 S3 버킷에 저장하는 서버 액세스 로깅 기능이 있습니다. 그렇다면 이 저장할 S3 버킷을 다른 버킷이 아닌 자기 자신으로 설정하게 되면 어떻게 될까요? ? 궁금해서 한번 해봤습니다.
예상
예를 들어 파일을 하나 올린다고 생각해 봅시다. S3의 서버 액세스 로깅 기능은 올라온 파일에 대한 액세스 로그를 만들게 될 것 입니다. 액세스 로그가 만들어지게 되면 다시 그 만들어진 액세스 로그에 대한 액세스 로그를 만들게 되지 않을까 싶습니다. 하나의 파일만 올리더라도 액세스 로그를 자가복제하여 엄청나게 많은 액세스 로그 오브젝트를 만들게 될 것 같네요. ? 그러면 직접 한 번 해봅시다.
실험 방법
실험에 앞서 다른 버킷으로 액세스 로그를 저장하는 경우와 자기자신의 버킷으로 저장하는 경우를 비교하기 위해 두가지 방법을 모두 진행해 보겠습니다.
두가지 방법 모두 서버 액세스 로깅이 켜져 있는 상태에서 한개의 파일을 올리고 열어본 뒤 한시간 뒤 서버 액세스 로깅을 끄고 결과를 확인해 보겠습니다.
또한 로그 오브젝트가 겹쳐지는 경우도 생각하여 버전관리도 켜두어 보겠습니다.
다른 버킷으로 저장하는 경우
테스트 할 원본 S3 버킷과 액세스 로그를 저장할 S3 버킷을 만들어 보겠습니다.
원본 버킷을 먼저 만들고 저장할 버킷도 만들어 줍니다. 저장할 버킷은 버전관리를 켜두겠습니다.
두개의 버킷을 만든 후 원본 버킷에서 타겟 버킷을 서버 액세스 로깅 대상 버킷으로 설정해보겠습니다.
설정 후 한개의 파일을 올리고 열어본 뒤 한시간 뒤에 서버 액세스 로깅을 끄겠습니다.
1시간 후 서버 액세스 로깅을 비활성화 시켰습니다.
아직까지 로그가 들어온게 없네요. 좀 더 기다려보겠습니다.
총 16개의 로그 오브젝트가 저장되었습니다. 버전 관리를 켜두었기 때문에 만약 로그가 중복되었다면 확인 할 수 있었겠지만 중복된 로그는 없었습니다.
자기자신의 버킷으로 저장하는 경우
테스트 할 S3 버킷을 만들고
액세스 로그 저장 버킷을 자기 자신으로 설정해 봅시다. 로그가 덮어씌워 질 수도 있으니 버전 관리도 켜두겠습니다.
액세스 로그 저장 버킷을 자기자신으로 설정하게 되면 위와 같은 안내가 나오게 됩니다. 하지만 안내만 나올 뿐 금지가 되지는 않아 보이네요.
버킷의 속성 탭에서 서버 액세스 로깅을 확인해보면
잘 만들어진 것을 확인할 수 있네요. 그러면 이제 파일을 올려 테스트 해 봅시다.
어느정도의 속도로 자가복제를 할 지 모르니 일단은 파일을 하나 올리고 한번 열어보고 1시간 있다 서버 액세스 로깅을 꺼 보겠습니다.
파일을 올리고 열어보고 1시간 뒤 서버 액세스 로깅을 껏습니다.
액세스 로그가 바로 나오지는 않네요. 좀 기다린 후 다시 한번 확인해 보겠습니다.
확인하고 나니 69개의 로그가 생겼네요. 총 70개이지만 1개는 제가 올린 파일입니다.
버전을 표시하여 확인해 보면 덮어씌워진 로그는 없었습니다.
로그에 대한 로그가 폭발적으로 생기는 그런 형태는 아니네요.
결론
본 실험은 서버 액세스 로깅 작동 기간이 1시간이었기 때문에 아래의 AWS 문서로 미루어 보았을 때 약간의 오차가 있을 수도 있지만 두가지 케이스 모두 정상적으로 작동하는 것을 확인할 수 있었습니다.
서버 로그 전송이 항상 보장되지는 않음
서버 액세스 로그 레코드는 최대한 전송하겠지만 항상 모든 레코드가 전송된다고 보장할 수는 없습니다. 버킷에 대해 적절히 로깅이 구성된 대부분의 요청은 로그 레코드가 전송됩니다. 대부분 기록된 지 몇 시간 내로 로그 레코드가 전송되지만 더 자주 전송될 수 있습니다.
모든 서버 로깅이 제때 전송될 것이라고 보장할 수는 없습니다. 특정 요청에 대한 로그 레코드는 요청이 실제로 처리된 후에 오랫동안 전송되거나 전혀 전송되지 않을 수도 있습니다. 서버 로그는 버킷에 대한 트래픽의 특성을 파악할 용도로 제공되며, 실제로 로그 레코드가 누락되는 경우는 매우 드물지만 서버 로깅 자체가 모든 요청을 완벽하게 기록할 목적으로 제공되는 것이 아닙니다.
버킷 로깅 상태 변경 시 일정 기간에 걸쳐 단계적으로 반영됨
버킷의 로깅 상태를 변경한 후 실제 로그 파일의 전송에 반영되려면 어느 정도 시간이 지나야 합니다. 예를 들어, 버킷에 대해 로깅을 활성화할 경우 이후 1시간 동안 이루어진 요청 중 일부는 기록되지만 일부는 기록되지 않을 수도 있습니다. 버킷 A에서 버킷 B로 로깅의 대상 버킷을 변경할 경우 이후 1시간 동안 일부 로그는 버킷 A로 계속 전송될 수 있지만, 다른 로그는 새로운 대상 버킷 B로 전송될 수 있습니다. 그러나 추가 작업을 수행하지 않아도 어느 정도 기간이 지나면 새 설정에 따라 모든 로그가 전송됩니다.
따라서 서버 액세스 로깅을 사용하기 전에 실제 사용시간 전부터 미리 켜두는 것이 좋아보입니다.
또한, 로그 저장 버킷을 자기 자신의 원본 버킷으로 설정하다면 로그의 로그를 만드는 무한 루프가 만들어질 수 있습니다.
Amazon Simple Storage Service(Amazon S3) 버킷에 대한 서버 액세스 로깅을 활성화했습니다. 해당 로그를 동일한 버킷으로 전송할 수 있습니까?
해결 방법
버킷에 대한 서버 액세스 로그를 동일한 버킷으로 푸시하지 마십시오. 이러한 방식으로 서버 액세스 로그를 구성하면 무한 로그 루프가 발생합니다. 이는 버킷에 로그 파일을 쓸 때 버킷도 액세스되고 이로 인해 또 다른 로그가 생성되기 때문입니다. 버킷에 기록된 모든 로그에 대해 로그 파일이 생성되므로 루프가 생성됩니다. 따라서 많은 로그가 생성되고 스토리지 비용이 증가하게 됩니다.
Amazon S3 버킷에 대한 서버 액세스 로그를 동일한 버킷으로 푸시할 수 있습니까?
S3의 서버 액세스 로깅은 버킷에 대한 액세스 로그를 S3 버킷에 저장 할 수 있는 편한 기능입니다. 하지만 이렇게 자기자신의 원본 버킷으로 로그를 저장하게 되면 로그의 로그를 만드는 경우가 생기게 됩니다. 원래의 로그 파일들만 따로 저장하고 싶다면 다른 버킷으로 로그를 저장하는 것이 좋아보입니다. 만약 원본 버킷에 저장한 파일들과 같이 로그를 저장하고 싶은 경우는 접두사를 설정하여 로그 오브젝트들을 분류하는 것이 좋아보이네요.
16
