내 데이터들의 lifecycle 관리!?
흔히 사용하는 로그들을 생각해보자.
우선 정책상 쌓아 두거나 추후에 필요가 있을것 같아, 혹은 데이터 마이닝을 선진행 하는 느낌으로 쌓는 경우가 대부분일 것이다.
그런데 이렇게 쌓아만 두고 열어보지도 않는데, 거기에 대한 비용을 일반적으로 활발하게 사용하는 데이터들과 똑같이 지불한다면 배아프지 않은가?
그래서 이번 글의 주제를 lifecycle을 이용한 비용최적화로 잡아봤다.
뭐라구요? 안쓰는 짐들을 창고에다 맡긴줄 알았는데, 여태껏 프리미엄 호텔에다 쑤셔넣고 있었다구요?
그럼 어떤 기준으로 나의 로그 또는 데이터들을 관리하면 좋을까?
가장 흔하게 사용하는 방법은, 자주 접근을 안하는 데이터의 경우, 저장 또는 수정한지 특정 날짜가 지난 후, access tier를 바꾸는 것이다.
이것이 lifecycle 관리구나!
어떻게 쓸까?
Azure는 생각보다 더 친절하다.
아래의 스크린샷과 같이 따로 메뉴를 뽑아놨다.
rule 생성하기
lifecycle 기반, 자동으로 나의 blob들이 챸챸 변경이 되려면 rule이 필요하다. 손으로 한다면 이부분은 필요없다. 추천하지는 않는다.
아래와 같은 rule 생성 화면을 볼 수가 있는데, 몇가지 설정 부분들이 보인다.
먼저, 유의해야 할 점은, 위의 blob type이 2가지가 있는데, append blob 타입은 cool이나 archive로 access tier 변경은 되지 않고 삭제만 된다는 점이다.
rule의 적용 범위에 대해서는, 내가 filter를 걸어서 특정 블랍이나 컨테이너만 타겟으로 할 수도 있고, storage account 안의 모든 blob들을 대상으로도 가능하다.
그 아래의 blob subtype들에 대해서는, 각각 base blob, 블랍의 snapshot, version에 대해서 따로따로 condition을 걸고 처리 할 수도 있다는 점을 미리 알고있자.
lifecycle의 기간과 어떻게 할건지에 대해서는, 각각 base blob, snapshot, version 따로따로 처리가 가능하다.
block blob에 대해서는 cool, archive, 삭제 3가지의 옵션이 주어진다. 지금 보는 rule은 base blob만 적용되는 부분이며, snapshot, version에 대해서도 동일하게 조건을 걸 수 있다.
filter부분은, 아래와 같이 2가지의 조건을 제공하고 있다.
첫번째로는, blob의 prefix에 따른 filter이다.
container이름/blob의prefix
위와 같이 사용하면 내가 원하는 blob들만 선택하여 적용할 수 있다.
두번째는 key value, blob index 매치 부분이다.
blob은 아래와 같이 key value 형태로 index를 가질 수 있다.
즐거운 실험시간
실제로 테스트를 진행해보자.
역시 기능은 이것저것 뜯어봐야 제맛이지?
아래와 같이 설정 해놓고, 날짜에 따라 적용이 되었는지 관찰해 보았다.
stvelog, 기본 동작 확인
lifecycle management rule
test: 각 blob들에 대해 1일 후 delete, move to cool, move to archive
ruletest: container 전체에 modify 날로부터 1일 후 cool > 2일 후 archive > 3일 후 delete
moveallcool: 1일 후 container 전체 cool
moveallarchive: 1일 후 container 전체 archive
확인포인트
- lifecycle이 잘 적용이 되는가?
- lifecycle로 변경되면, 해당 과정은 modify로 쳐지는가?
expected results
test: 각각의 파일들에 명시한 이름과 같이, cool, archive, delete 명령이 수행 되어진다.
ruletest: 처음 생성 put blob 이후, 3일 후에 delete까지 수행 되어진다.
moveallcool: 모든 blob들이 cool로 변경 되어진다.
moveallarchive: 모든 blob들이 archive로 변경 되어진다.
결과
test
업로드한 4개의 blob 모두 변경이 되었다. delete 부분은, 특정 기간이 지나 show deleted blobs로 확인이 되지 않는다.
ruletest2 (오타가 있어 container를 ruletest ->ruletest2로 변경 테스트 하였다.)
바빠서 과정을 확인 못했지만, 최종 과정인 delete가 수행된 부분은 확인이 되니 중간과정도 잘 되지 않았을까 한다. 불행중 다행으로 중간에 오타로 인해 테스트가 되지 않아 다시 했던 부분이 show deleted blobs 부분으로 지워진 blob들을 확인할 수 있었다. 특히나 access tier의 변경은 modified date를 수정하지 않는 부분을 확인할 수 있었다.
moveallcool
아래와 같이 잘 변경되었다.
moveallarchive
아래와 같이 잘 변경되었다.
stvelog2, priority 확인
lifecycle management rule
storage 전체에 1일 후 cool
test2: 1일 후 container 전체에 archive로
test2: 1일 후 특정 blob 삭제
확인포인트
- modify 날짜를 같이 준다면, 더 작은범위의 정책이 더 높은 priority를 가지는가?
expected results
아래의 결과는 모두 1일 후에 동일하게 나타난다.
test: 이 컨테이너는 storage rule만 해당을 받을 테니, cool로 변경 되어진다.
test2: 이 컨테이너 안의 모든 blob들은 모두 archive로 변경 되어진다.
test2의 특정 블랍:
결과
test
아래와 같이 모두 cool로 access tier가 변경된 부분을 볼 수 있다.
test2
아쉽게도 지워진 부분은 시간이 지나서 확인이 되지 않으나, 지워진 것은 확실하다. 4개의 blob을 올렸고, delete_1.bmp 이라는 blob이 없지 않은가? 위의 예상에도 적었듯, archive로 전부 access tier가 변경 되었고, 1개 blob만 으로 변경한 부분은 삭제가 되었다. 즉, network route table 마냥, 설정이 narrow 할수록 더 높은 priority를 가지는 것이 확인되었다.
마치며
딱 3개만 기억하자.
- lifecycle management를 잘쓰면 비용을 보관 비용을 획기적으로 줄일 수 있다.
- lifecycle management로 access tier가 변경되어도 기존의 modified date를 유지한다.
- lifecycle management의 priority는 범위가 작은 부분이 우선된다.
그리고 나에게 쓰는 한마디는... 테스트 걸어놓고 알람걸어 놓자... 항상 확인 시기를 놓치냐...
