search

ddps-lab / cloud-usage

MIT License
1 stars 1 forks source link

ec2(stop instance) 관리, ebs 및 snapshot 비용절감 방안 #18

Closed Kim-Yul closed 10 months ago

Kim-Yul commented 1 year ago

stop instance 관리 방안

현재 stop된 ec2 instance와 관련하여 stop instance를 어느 기간 이후 자동으로 terminate할 것인지, 혹은 오랫동안 stop되어 있는 것을 따로 공지할 수 있도록 할 것인지와 관련하여 방안을 생각합니다. (instance의 실제 사용 여부가 중요하기 때문에 이를 고려해야 할 것 같습니다. 현재 ec2는 모두 사용 중입니다.)

ebs 및 snapshot 비용절감 방안

s3와 마찬가지로 비용이 큰 ebs와 snapshot에서 비용절감할 수 있는 부분을 찾습니다. seoul region에 snapshot을 살펴보니 2019년 3월 21일 날짜의 것이 있었고, 이와 관련된 volumes는 이미 삭제된 상태입니다. 즉, volume가 삭제되었다는 것을 ec2를 terminate 하였다고 생각하여 완전히 작업이 끝났다고 가정하였을 때, snapshot의 삭제 여부를 판단하면 될 것 같습니다. snapshot에 volume 여부를 살펴서 volume를 찾을 수 없는 것들을 관리 대상으로 하면 어떨까 싶습니다. 또한, volume가 삭제된 지 며칠이 지났는지 알 수 있다면, snapshot은 다시 사용될 가능성이 있기에 일종의 삭제 유효기간을 두었다가 그 기간이 지나면 삭제될 수 있을지 알아보면 좋을 것 습니다. 일단 이렇게 생각하고 알아보는 것은 어떠할까요?

kmu-leeky commented 1 year ago

유림학생 이슈시작해줘서 땡큐. 대부분의 학생들이 서버를 사용하니 크게 관련이 있을테니 다 함께 보면 좋을것 같아. 정리 방식에 대한 의견을 주면 좋겠다.

우선 stop 된 인스턴스의 경우 지금 공지해주는 내용을 시기별로 구분해서 보여주는것도 좋을것 같아.

Stop 된 기간이 1일 미만인 인스턴스, 3일 미만인 인스턴스, 1주일 이상된 인스턴스 로 구분해두면 계속 stop 되어 있는 인스턴스에 대해서는 본인이 필요에 따라서 종료를 하도록. 파일을 저장해야 한다면, 그런 부분은 S3 를 사용해도 되고, ebs 볼륨 자체를 s3 에 저장하는 방법도 있으니 필요하다면 해당 기능을 구현하는것도 좋을것 같아.

snapshot 의 경우 백업의 느낌이 강해서 쉽게 지우기가 어려울것 같기도 한데.. 우선 snapshot 과 volume 도 지우는 조건을 확인하기 보다는 지금 ec2 하는 것 처럼, 용량 생성일 접근일 등을 슬랙으로 보내보는걸 구현해보는게 어떨까 싶어. 그렇게 보다보면 본인이 만든걸 자연스럽게 지울수도 있을테니.

다른 방안 생각 나는게 있으면 공유해주면 좋겠다.

Kim-Yul commented 1 year ago

파일을 저장해야 한다면, 그런 부분은 S3 를 사용해도 되고, ebs 볼륨 자체를 s3 에 저장하는 방법도 있으니 필요하다면 해당 기능을 구현하는것도 좋을것 같아.

  • 지속적인 stop 인스턴스의 경우 ebs volume을 s3에 저장해두고 terminate를 생각하시는 게 맞는 걸까요?

우선 stop 인스턴스 stop 일자 구분을 진행하겠습니다. 그리고 snapshot의 경우 정렬해서 리스트를 뽑아보는 걸 진행하겠습니다.

kmu-leeky commented 1 year ago

terminate 은 시작한 사용자가 직접 해야 할것 같아요. 지금은 우선 리스트만이라도 보여주면 사용자들이 자원들을 인지하는데 도움이 될것 같아요.

Kim-Yul commented 1 year ago

기존 report 수정

기존에 보여주던 정보를 살짝 수정하여 진행할 예정입니다.

기존 : [리전 / 네임 태그 / 인스턴스 타입 / 인스턴스 ID / 인스턴스 상태 변경 시각 / start 또는 stop 중인 시간] 변경 : [리전 / 네임 태그 / 인스턴스 타입 / 인스턴스 생성 시각 / start 또는 stop 중인 시간]

인스턴스 ID의 경우, 인스턴스를 구별할 수 있는 식별이 되기 하지만, 보통 네임 태그를 더 많이 볼 것으로 예상하여 삭제할까 합니다. 꼭 필요하다면 삭제 없이 기존 설정을 유지하겠습니다. 또한, 인스턴스 상태를 변경한 시각은 이미 그 상태가 진행 중인 시간이 표현되기 때문에 굳이 있을 필요가 없을 것으로 사료되어 간결하게 출력하기 위해 삭제할까 합니다. 그리고 인스턴스 생성 시각을 나타낸 이유는 밑에서 volume와 함께 설명하겠습니다. 이와 관련하여 의견 주시면 반영하겠습니다.

running instance

기존에 있던 이모지에서 색을 추가하여 한 눈에 알아볼 수 있게 하려고 합니다.

대부분 취짐 시간에는 stop 해 둘 것을 고려하여, 빨간색 이모지로 경고를 표현하였습니다. 또한, 현재 가장 길게 켜져있는 인스턴스는 예외처리 해두어 초록색으로 뜰 수 있게 해두겠습니다.

stopped instance

stop된 인스턴스를 어떻게 구별할까 하다가, 색으로 보여주는 것이 나을 것 같아 이모지 색을 추가하고자 합니다. 기준은 2개를 둘까 하였다가 혹시 몰라 3개로 하였고, 통상 15일 이상 stop된 것은 더 이상 사용하지 않는다고 가정하였습니다.

인스턴스 정렬 기준

  1. region 올림차순
  2. 실행 중인 시간 내림차순

우선은 위의 기준으로 정렬하고자 하지만, 두 기준 중 어떤 것으로 해야 더 깔끔할 지 모르겠습니다. 두 개 다 해보겠습니다.

volume

기존 인스턴스와 연결되어 있는 volume의 경우 state가 is-use로 되어 있습니다. 그러나 연결이 끊긴 volume의 경우 state가 available 상태인 점을 이용하여, available된 volume의 경우에만 인스턴스 알림에 함께 띄우고, 같이 띄워지는 정보로는 [region / created date / volume id] 를 함께 띄우려고 합니다. created date를 이용하면, volume의 연결 instance가 무엇이었는지 유추 가능할 것으로 판단합니다. 이미 없어진 instance라도, 슬랙 기록을 이용하면 찾을 수 있을 것으로 판단되어 정리가 수월하지 않을까 기대합니다.

위의 코드 수정 중에 있습니다. 완료되는 대로 pull/requests 하겠습니다. 중간에 변경된 내용이 있으면 함께 수정하겠습니다.

kmu-leeky commented 1 year ago

오케이. 유림아. 좋은 방법인것 같아. 인스턴스 정렬 기준은 실행중인 시간 내림차순이 좋을것 같아. 오래동안 사용되고 정지되어 있는걸 강조하는 차원에서. 볼륨도 좋은 생각이다. 우선 이렇게 진행을 해보자.

Kim-Yul commented 1 year ago

ec2 report code 수정

1. 알림으로 띄우던 항목 수정

기존에 띄우던 항목을 조금 변경하였습니다.

기존 : [리전 / 인스턴스 이름 / 인스턴스 타입 / 인스턴스 ID / 인스턴스 상태 / 인스턴스 상태 변경 시각 / start 또는 stop 중인 시간] 변경예정 : [리전 / 네임 태그 / 인스턴스 타입 / 인스턴스 생성 시각 / start 또는 stop 중인 시간] 실제 변경 항목 : [리전 / 인스턴스 이름 / 인스턴스 타입 / 볼륨 ID / running 또는 stopped 시간]

인스턴스 생성 시각이 ec2 정보에 기입되어 있지 않았고, 본래 인스턴스 생성 시각의 의도가 볼륨 ID를 찾기 위함이었다는 것에 의해 그냥 볼륨 ID를 넣어 검색으로 찾기 쉽게 하는 것이 좋을 것 같아 수정하였습니다.

2. 변수 형식 수정

running time or stopped time으로 내림차순 정렬을 원활히 하기 위해 string 타입으로 저장되어 있던 instance 리스트를 딕셔너리로 저장하였습니다. 리스트 형식과 딕셔너리 중, 코드 길이보다 인덱스 접근에 용이하도록, 즉 list[0] 보다 list['region'] 이 더 명확하게 표현되는 것 같아 딕셔너리 형식으로 포맷하였습니다.

instances[string1, string2] -> instances[dic1, dic2]

3. cuurent time 통일

기존에 cuurent time을 함수별로 호출하던 방식에서 한 번 호출하고 인자값으로 넣는 방식으로 바꾸었습니다.

4. 정렬 시간 내림차순

모든 정렬 방식을 시간 내림차순으로 변경하였습니다.

5. 함수 이름 변경 및 주석 처리

함수가 늘어남에 따라 함수가 하는 일에 맞추어 이름을 변경하였고, 혹시 모를 오류를 위해 예외처리 해두어 어느 함수에서 오류가 나는지 파악할 수 있게 해두었습니다. 또한 항목 별로 주석처리를 해두었습니다.

6. 인스턴스의 개수

현재 작동 중인 인스턴스의 개수가 몇 개인지 표시해두었습니다.

modified ec2 report

image

[running EC2 instances]

(예외) : 오랜 시간동안 켜져있어야만 하는 인스턴스의 경우 3일이 지나면 초록색 원을 띄우게 추가해두었습니다. 현재는 빨간색도 표현이 된다는 것을 강조하기 위해 jaeil-sps-collect 빨간색 원으로 해두었습니다. 실제 슬랙에 보내지는 메세지는 맨 아래에 올라간 실행화면입니다.

[stopped EC2 instances]

[available volumes]

어떤 볼륨을 삭제해야 하는지 명확하게 알 수 있게 상세 정보를 함께 띄우고 경고 이모지를 추가했습니다. snapshot ID 도 추가하여, 혹시 volume와 관련된 snapshot을 정리할 수 있겠끔 정보를 추가했습니다.

실제 슬랙에 띄어질 화면

image

작업 확인 후 변경 사항이 없다면, 다음 ec2 report부터 현재 세팅으로 적용될 수 있게 변경해두겠습니다.

kmu-leeky commented 1 year ago

very nice! 시각적으로 효과적으로 잘 표현되어서 관리하기가 좋을듯 하다. 코드는 따로 리뷰하자.

Kim-Yul commented 1 year ago

실행 결과

image

오류메세지 슬랙 전송은 따로 테스트하여 update 하겠습니다.

Kim-Yul commented 1 year ago

오류 실행 결과

image

sys.exit()를 사용하여 진행한 결과입니다. 슬랙에서도 잘 나타는 것을 확인했습니다. 다소 난폭한 방법이라고 생각하여 더 나은 방법을 고려 중입니다.

kmu-leeky commented 12 months ago

유림아. 실행중이던 람다에서 종료는 그냥 함수단에서 return 하면 되는것 아닌가?

Kim-Yul commented 12 months ago

처음에는 return으로 하려고 했으나, 함수 반환값이 맞지 않아 에러가 생기는 점이 발생한다는 점과 어느 함수에서 에러가 난 것인지 파악할 수 있게 메세지를 띄우는 부분에서 고민되어 우선 sys.exit()로 해두었습니다. 현재 코드 상 return으로 처리하면 A에서 B로 접근하는 방식인지라 B에서 에러가 나면 A도 에러가 난다는 메세지를 출력하게 됩니다. B에서만 에러가 났다고 출력하고 싶었기에 우선 함수를 종료하는 방안으로 대처해둔 것이고, 정상적으로 종료하고 싶어서 아직 고민 중에 있습니다. 물론 정상적인 종료를 위해 return을 이용할 것인데, 메세지 출력과 로직에 맞게 고민해보겠습니다. 하고 다시 이슈 남기겠습니다!

kmu-leeky commented 12 months ago

음.. 무슨 이야기인지. 어디에서 에러가 발생을 하고, A, B 가 뭔지 종합적으로 잘 모르겠는데 ㅎㅎ 메이저한 이슈 아니라면 다음에 만나서 설명해줘.

Kim-Yul commented 11 months ago

snap shot 진행 과정

snap shot 내용 확인하였고, 다음과 같은 과정을 통해 management 설계 중입니다. 우선 테스트하는 겸 현재 인스턴스가 존재하지 않는 usw1(california)의 snapshot 을 이용했습니다.

  1. volume id와 snapshot id 매핑
    • ec2 하나를 생성하여 ec2에 매핑된 volume id(vol-0cf838b688185d879), owner id(741926482963) 확인
    • volume id(vol-0cf838b688185d879)에서 snapshot id(snap-0da90cc9e2bcc9dd8) 확인
    • snapshot id(snap-0da90cc9e2bcc9dd8)에서 volume id(vol-ffffffff), owner id(099720109477) 확인
    • 위의 결과를 확인하면 instance 에서 확인한 정보 및 volume 에서 확인한 정보, snapshot 에서 확인한 정보가 일치하지 않아 추적-역추적이 어려움.
    • (3만 개의 snapshot이 존재하는 환경에서 확인해보았음.)
  2. usw1 리전에 있는 snapshot 전체 확인
    • 리전 안에 snapshot이 30233개 존재
    • snapshot info에 존재하는 volume id 2960개 존재
      • "vol-ffffffff": 23274개, 이 외 1개씩
    • snapshot info에 존재하는 owner id 205개 존재
      • "958347557273": 4870, "102837901569": 1738, "125523088429": 4546, 등 겹치는 owner id
    • 위의 정보를 토대로, 이상할 정도로 vol-ffffffff 볼륨과 매핑된 snapshot이 많다는 것과 owner id를 이용해서 삭제할 snapshot 구분이 어렵다는 것을 확인하였음.
  3. usw1 리전에 있는 vol-ffffffff에 매핑된 snapshot 삭제 (예상 삭제 : 324개)
    • 30233개 중 500개만 추출하여 vol-ffffffff 인 것을 삭제 시도
    • ec2 기준으로 확인한 실행 시간 : 1분 30초
    • 결과, 모두 삭제 되지 않음.
      • ami가 있거나 사용중인 instance가 있을 경우 삭제가 불가능함.
      • instance가 없는 곳에서 진행하였기에 ami 존재 여부 확인
      • snapshot을 이용하여 생성된 ami가 없다고 확인됌.
      • delete_snapshot() 메서드가 안되는 이유는?
        • 이미 삭제가 되었다고 뜨지만, snapshot 내에는 존재한다.
        • AMI와 연관성은 전혀 없을까?
  4. 테스트 작업 시간 중 snapshot 증가
    • 하지만 테스트를 위해 생성한 ec2의 snapshot이 아니었음.
    • vol-ffffffff 과 연관되어 있는 스냅샷의 증가함.
    • Copied for DestinationAmi ami-07f2403e42fe1fc3a from SourceAmi ami-0afc91967616c3ad3 for SourceSnapshot snap-0ae8e10fc27b0b51e. Task created on 1,696,420,759,624.
    • Debian 11 (20231004-1523)
    • MATLAB Parallel Server on AWS Batch R2023b
    • Created by CreateImage(i-08ead655188b443fa) for ami-02620df3b362b681c
    • 위의 Description은 어떻게 생기는 것인지 확인이 필요함.

정리

snapshot은 volume의 상황을 복사하여 저장한 형태라고 인식하고 있었으나 실제로 snapshot에 저장되고 있는 것은 그런 류가 아닌 것 같습니다.

image

또한, 위의 경우 snap A 와 snap B는 같은 volume id를 가지고 있어서, volume id를 통해 snapshot을 분류하고 관리할 수 있을 것으로 생각했습니다. 그러나 실제로는 volume id에 1개의 snapshot만 놓여있었고, 다중 snapshot을 가진 볼륨은 vol-ffffffff 뿐이었습니다. 그래서 우선 vol-ffffffff 을 삭제하는 테스트를 진행하였는데, 여러가지를 확인해보았지만 snapshot이 삭제조차 되지 않았습니다. 위의 작업을 토대로 다음에는 ami 삭제 후 snapshot 삭제를 진행해보려고 합니다. snapshot이 삭제가능하게끔 환경을 만들어 보겠습니다.

이 경우 날려도 괜찮다면 california에 있는 모든 ami 가 대상이 됩니다. general 에서 usw1의 ami 삭제 가능한지 확인 후 진행하겠습니다.

kmu-leeky commented 11 months ago

유림아. 우선 이상한게 왜 저렇게 많은 스냅샷이 생겨 있는지 이유부터 한번 분석을 해볼까? 웹 서치를 할 수도 있고, aws billing 에 문의를 남겨도 될것 같아. 결국 스냅샷으로 빌링이 되는데 우리가 만든것 같지가 않으니. 그리고 id 를 보면 우리 계정이 아닌 다른 아이디가 소유주인데 왜 그게 우리 계정에 스냅샷으로 있는지 모르겠네. 어쩌면 우리가 모르고 있는게 있고, 이번에 삭제를 한다고 해도 또 생겨날 여지가 있어서 우리가 의도치 않은 스냅샷이 많이 생성되는 근본 원인 부터 분석해보는게 먼저 일것 같아.

Kim-Yul commented 11 months ago

네 저도 이번에 스냅샷 조사하면서 흔히 알고 있던 생성 외에도 추가로 생성되는 게 있다는 것이 있어 관리로 해결되는 부분이 아닐 같다고 생각하였습니다. 좀 더 이론적으로 파고들어 분석해보겠습니다.

kmu-leeky commented 11 months ago

응 유림아. 이론적으로 파악을 하고 어려우면 Support 에 연락해서 물어봐도 괜찮을것 같아.

Kim-Yul commented 11 months ago

snapshot

volume의 특정 시점을 백업하여 사본으로 사용하는 기능

AMI

스냅샷이 자동으로 생성되는 경우 중, AMI(Amazon Machine Image) 생성과 관련이 있음.

AMI를 만들 때, 시스템 디스크나 추가적인 볼륨은 스냅샷이 생성되어 영구 저장됨. 이 스냅샷은 나중에 ami를 또 사용할 때 사용되기 때문에 ami가 삭제되지 않으면 스냅샷을 삭제할 수 없음. 이 스냅샷들은 주로 public으로 존재하며, 우리 계정에서 생성한 것이 아니기에 owner id가 다름.

public snapshot

해당 스냅샷은 ami 의 삭제 기간에 함께 삭제되는 것으로 보임. 또한, 리전 별로 3만 개 정도를 유지하고 있으며, aws 계정에서 요금을 부과하지 않기 때문에 신경 쓰지 않아도 될 것으로 보임.

private snapshot

해당 스냅샷은 우리 계정에서 만든 스냅샷 목록과 다른 owner id의 스냅샷이 공존함. 다른 소유자의 스냅샷이 존재할 수 있는 이유와 관련하여 이 스냅샷이 private으로 구분된 이유가 무엇인지 support 팀에 질문을 진행 예정. 또한, 요금 snapshot 요금 측정이 private snapshot인지, owner snapshot인지 명확하게 알기 위해 질문을 진행할 예정.

owner snapshot

실제로 과금이 이루어지는 snapshot이라고 판단함. 이 분류에 해당하는 스냅샷을 정리하여 리스트로 출력하면 될 것으로 판단.

management 구상

private snapshot 에 해당되는 스냅샷을 출력하는 형식을 고려하고 있습니다. owner snapshot 에 포함되는 스냅샷은 확실하게 요금을 낼 테지만, private은 아직 판단이 서지 않아서 support 팀에 문의해보고자 합니다. 문의 결과에 따라 다르겠지만, 우선 private snapshot을 포함시켜서 구상한 후 추후 제거해도 될 것으로 판단됩니다. snapshot 리스트를 코드로 불러오면, private 뿐만 아니라 public이 모두 호출되어 O(n)의 개수가 3만 개 이상이었습니다. 이에 기존에 public snapshot 역시 정리해야 하는 대상이라고 착각하여 진행에 어려움을 겪었습니다.

현재는 public인지 아닌지 스냅샷 옵션을 통해 구분할 수 있기 때문에 필터로 소량의 스냅샷만을 출력할 수 있을 것 같습니다. 스냅샷의 정보로 owner id, start time, snapshot id, volume id, storage tier을 저장하려고 합니다.

선택된 정보에서 private나 owner ami를 통해 생성된 snapshot인지, volume를 통해 생성된 snapshot인지 판단한 후, 현재 사용 중인지 아닌지를 슬랙에 공유하면 될 것 같습니다. 사용 중인지 아닌지는 ec2의 여부로만 판단할 예정이며, ami를 통해 생성된 snapshot의 경우 ami id를 추가하여 ami 관리를 진행하게끔 하면 될 것으로 판단됩니다.

내용 확인 후 괜찮으시면 진행하겠습니다.

어쩌면 우리가 모르고 있는게 있고, 이번에 삭제를 한다고 해도 또 생겨날 여지가 있어서 우리가 의도치 않은 스냅샷이 많이 생성되는 근본 원인 부터 분석해보는게 먼저 일것 같아.

이 부분에 대한 답변으로는 public snapshot의 경우 매일 20~30개 안팎의 스냅샷이 자동으로 생성되는 것 같습니다. 그러나 그 수가 3만개 언저리라는 점에서 ami 의 관리에 따라 스냅샷의 수가 유지되는 것 같습니다. 따라서 public snapshot은 따로 관리할 필요가 없어보입니다. (삭제불필요) 연구실 계정 외에 개인 계정으로 확인해 보았는데, 그 결과 청구서에 요금이 청구되지 않는 것을 확인하였습니다.

Kim-Yul commented 11 months ago

우선 현재 기존에 스냅샷 목록을 출력하는 것은 가능합니다. usw2(oregon) 기준으로 private의 스냅샷 130개의 리스트를 확인할 수 있습니다. 현재 고민하고 있는 것은 이 130개의 스냅샷 중 현재 쓰고 있는 것과 정리가 필요한 것을 어떻게 구분할 것인지 고민하고 있습니다. ec2의 volume 백업용의 스냅샷은 거의 없고 대부분 ami 를 위한 스냅샷인 것 같아서 어떻게 정리해서 목록을 띄워야할 지 고민하고 있습니다.

oregon 기준으로 25개의 ami 중 16개는 스냅샷을 가지고 있다는 결과가 나왔는데, 하나의 ami가 여러 개의 스냅샷을 가질 수도 있기 때문에 이 부분을 어떻게 반영해야 할지 그런 부분을 고민하고 있습니다. 이 부분 좀 더 다듬으면 스냅샷 목록 출력이 가능할 것 같아 좀 더 시행착오를 겪을 에정입니다.

kmu-leeky commented 11 months ago

오케이. 유림아 잘 정리했다. public snapshot 이라는게 있구나. 잘 배웠다 ㅎㅎ 유림의 말대로라면 public 은 신경을 쓸 필요는 없어보이네. 그런데 이야기한대로 private 이 실제 어떤 ami, 볼륨과 연결이 되는지는 고민이 필요할것 같기도 하다. volume 이 ami 에서 사용되고 있다면 해당 ami 를 반드시 삭제해야 하는거지? 조금 더 복잡해질수는 있는데, ami 리스트에서 사용자 지정 ami 를 읽어온 후 snapshot id 도 알 수 있을까?

Kim-Yul commented 11 months ago

volume 이 ami 에서 사용되고 있다면 해당 ami 를 반드시 삭제해야 하는거지?

이 부분에서 volume이 아닌 snapshot이라고 생각해 주시면 될 것 같습니다. 실제로 확인해보면 ami와 snapshot이 연관되어 있고, instance와 volume이 연관되어 있습니다. ami를 삭제하면 이에 묶여있는 snapshot을 정리할 수 있습니다. volume를 삭제하여도 ami과 관련이 없습니다.

이와 관련하여 snapshot을 통해 ami를 만들고 이를 통해 instance를 생성 후 terminated 시켜보았습니다. 이 후 ami를 삭제해보았는데, snapshot을 통해 ami를 만든 경우 ami를 삭제하더라도 snapshot이 삭제되지 않습니다. 그래서 이와 반대로 ami를 만들면서 생성된 snapshot은 생성한 ami를 삭제하였을 때 자동으로 삭제 되는지 확인할 필요가 있습니다. 이 부분은 snapshot 관련 테스트 하면서 확인해보겠습니다.

조금 더 복잡해질수는 있는데, ami 리스트에서 사용자 지정 ami 를 읽어온 후 snapshot id 도 알 수 있을까?

말씀해주신 이 부분은 확인 가능합니다. 사용자 지정 ami는 public이 아니거나 aws 계정이 생성한 ami라고 필터를 지정하면 확인 가능합니다. ami 에서 연결된 snapshot id 역시 확인 가능합니다. 다만, ami에 여러 개의 snapshot이 묶여 있을 가능성도 고려해야 해서, 이 부분은 몇 번 테스트 및 확인이 필요할 것으로 생각됩니다.

Kim-Yul commented 11 months ago

snapshot management

스냅샷 관리와 관련하여 현재 진행된 사항 보고 드립니다. 현재 ec2 실험이 멈춰서 oregon 리전에서 테스트를 해보았고, 이에 대한 결과와 함께 어떻게 관리하면 좋을지 생각했던 아이디어를 올립니다. oregon 리전에서만 결과를 확인하였습니다.

우선 우리 계정에서 소유하고 있는 스냅샷 목록을 추출할 수 있습니다. 이를 기반으로 오리곤 리전에 있는 총 131개의 private snapshot을 확인하였습니다. 131개 중 단 한개의 스냅샷은 현재 리전에서 사용 중인 볼륨과 연결되어 있었습니다. 리전에 있는 볼륨은 총 9개였으며 이 중, 2개의 볼륨이 하나의 스냅샷과 연결되어 있었습니다. 하나의 볼륨에 여러 개의 스냅샷이 묶여있는지, 하나의 스냅샷에 여러 개의 볼륨이 묶여있는지 그 형식을 자세하게 몰라서 테스트를 진행해보았습니다. 그 결과 하나의 스냅샷에 2개의 볼륨이 묶여있는 형태가 가능하다는 것을 알게 되었고, 하나의 볼륨이 여러 개의 스냅샷을 가지고 있는지에 관련해서는 좀 더 확인해보겠습니다.

이후 사용하고 있는 것이 확실한 하나의 스냅샷을 제외한 총 130개의 스냅샷에서 ami와의 연관성을 확인했습니다. public ami를 제외한 private ami와 스냅샷을 비교해보았습니다. 우리 계정의 소유인 18개의 ami와 타 계정의 소유인 8개의 ami를 합쳐 총 26개의 ami 가 private ami에 포함됩니다. 이 중 우리 계정의 소유인 16개의 ami는 스냅샷과 연결되어 있었고, 이 스냅샷을 제외하면 114개의 스냅샷이 현재 어떤 것과도 연결되지 않은 채 리전에 존재하는 것 같습니다.

결과

이를 통해 총 114개의 스냅샷은 어느 ami나 볼륨과도 연결되지 않는 것 같습니다. 만약 관리하게 된다면, 더는 사용하지 않는 ami 와 ami 의 스냅샷, 용도를 알 수 없는 스냅샷을 관리해야 할 것 같습니다.

의아한점

우리 소유의 ami 중에서도 2개의 ami는 스냅샷이 존재하지 않습니다. 실제로 존재하지 않는지 콘솔과 비교해서 확인해보았는데, 코드 상의 결과와 다른 부분이 있어서 추가로 남깁니다. 직접 콘솔에서 확인해본 결과 ami 중 한 개는 확실하게 스냅샷이 존재하지 않는다는 것을 발견했습니다. 다만, 다른 하나의 ami 는 snapshot이 존재하는 것을 콘솔에서 확인했습니다. 코드 상으로는 발견할 수 없었던 부분이기에 boto3와 콘솔 내의 결과가 다른 이유는 한 번 찾아보아야 할 것 같습니다. 이 부분은 다시 이슈 남기겠습니다.

우선 snapshot과 ami와 관련하여 궁금한 부분을 support에 남겨두었습니다. 답변 확인 후 반영하겠습니다.

슬랙으로 보내는 메세지 형식

snapshot ID (생성일) - 볼륨 ID (생성일) 또는 snapshot ID (생성일) - ami ID (생성일)

위의 형식으로 관리를 진행하면 어떨까 싶습니다. 자동으로 삭제되는 것보다도 우선 리스트 출력에 초점을 맞추었습니다. 다만 ami나 snapshot 중 현재 사용하지 않는 것이 분명히 있는 것 같아, 가능하면 관리 초기에는 일부는 삭제하는 것이 좋을 것 같습니다.

이후로는 답변 및 테스트 추가 진행, 다른 리전(서울)에서도 결과를 확인해볼 예정입니다.

kmu-leeky commented 11 months ago

응 유림아. 자세하게 잘 분석했다. 그렇다면 현재 대부분의 snapshot 은 어떤 ami 와도 연결되어 있지 않네. 사실상 AMI 도 삭제해도 될것들이 제법 보이는것 같기는 하다. 우선 슬랙으로 메시지를 보내보고, 해당 리스트에서 삭제할것들 선별한 후에 수동으로 삭제한 후에, 새롭게 생성된 사용되지 않는 스냅샷을 주기적으로 삭제하는 코드를 만들도록 하자.

Kim-Yul commented 11 months ago

support 답변 정리

1. private 스냅샷 항목에 우리 계정 외의 스냅샷이 존재하는 이유 및 생성된 대중적인 이유

2. 스냅샷 요금 부과 방식

⇒ 즉, 우리 계정 소유의 스냅샷이 아닌 경우 스냅샷 요금이 부과되지 않으며, 스냅샷을 복사한 경우에는 복사한 스냅샷에 한정하여 우리 계정의 소유가 되는 것을 확인하였습니다.

3. private 스냅샷 목록 중 우리 계정이 소유하지 않은 스냅샷을 삭제할 수 있나요.

⇒ 확인차 물어본 질문이었으며, 현재 private 스냅샷에 우리 계정이 아닌 것은 존재하지 않습니다.

regions us-east-1 us-west-2 ap-east-1 ap-northeast-2 ap-northeast-1
private snapshot 12 131 4 171 1
owned by snapshot 12 131 4 171 1

4. private ami 에 우리 계정 외의 ami가 존재하는 이유 및 생성된 대중적인 이유

⇒ 복사를 해서 복사한 이미지는 삭제가 되는 것인 확인해보려고 하였는데, 복사가 허용되지 않는 접근으로 뜹니다.

⇒ 또한, 인스턴스를 생성하려고 보니 aws marketplace amis 쪽으로 검색이 됩니다.

⇒ 세부 내역 중 snapshot 정보를 찾을 수 없습니다.

⇒ 제 생각으로는 계정 소유의 ami가 아니라면 관리 대상으로 하지 않아도 될 것 같습니다.

5. private ami 중에서 우리 계정이 소유하지 않은 스냅샷은 삭제해도 되나요?

계정의 데이터 손실보다 AWS 사용에 어려움이 있는지 확인하기 위해 질문하였습니다.

ami에 스냅샷을 발견할 수 없었던 것

이전에 오리건 리전에서 테스트하던 와중에 우리 계정 소유의 AMI에 연결된 스냅샷이 없는 것을 확인했습니다.

총 2개의 AMI에 연결된 스냅샷이 없었으며, 해당 AMI ID는 다음과 같습니다.

1. ami-0cb57b7f84eb98fe3
2. ami-059d5b3b50a6e3307

이 중 첫 번째 AMI는 분명히 스냅샷이 존재합니다. (snap-032f967cb2e0354d7)

그러나 이는 콘솔에서 확인한 부분이며, boto3에서는 스냅샷이 없는 것으로 확인이 되었습니다.

이 부분에 대한 질문을 하였으나 좀 더 자세한 질의가 필요한 부분이라 다시 한 번 support 할 예정입니다.

추가적으로 AMI에 스냅샷이 존재하지 않는 이유에 관해서도 질문할 예정입니다.

정리

스냅샷을 정리하기 위해서는 우리 소유의 스냅샷만 목록으로 불러와서 정리하면 될 것 같습니다.

다만 백업용으로 snapshot만 남겨둔 경우에도 정리 대상이 될 수 있어, 이를 분류할 수 있는 방법을 고려하겠습니다. (Tag나 Name을 식별할 수 있는지 확인해볼 예정입니다.)

서울 리전에서도 고려해야 하는 변수가 있는지 테스트 후 코드 작성 시작하겠습니다.

Kim-Yul commented 11 months ago

서울리전 테스트 결과

서울리전에는 인스턴스가 한 개 생성되어 있고, AMI가 없어 유의미한 결과를 얻지 못했습니다. 따라서 오레곤 리전에서 얻은 값을 고려하여 코드를 작성하겠습니다.

스냅샷 구분

개인이 사용하기 위해 스냅샷으로 백업해두는 경우, 태그를 추가해두면 관리가 유용합니다. 예를 들어 제가 s3를 자동으로 관리하기 위해 만들어둔 스냅샷의 경우 태그와 스냅샷 이름을 지정해두었는데, 이 결과 스냅샷의 정보에 태그 값이 추가되어 있었습니다. 현재 스냅샷에 있는 대부분은 스냇샷 이름이 지정되어 있지 않습니다. 이를 이용하여 스냅샷 정리를 할 수 있을 듯합니다.

image

  1. usage : s3 management

    • 이 태그는 제가 tags에 직접 입력한 값입니다.

  2. Name : usage-s3-management

    • 이 태그는 스냅샷에 이름을 주었을 경우에 얻는 값입니다.
kmu-leeky commented 11 months ago

유림아. 잘 분석했다. 대부분의 내용은 잘 수긍이 가. 중간에 있는 내용 중 "현재 private 스냅샷에 우리 계정이 아닌 것은 존재하지 않습니다." 이 이야기는 모두 우리가 소유한 스냅샷이라는 거지? 그렇다면 우리가 만든거고 삭제도 우리가 해야 하는거고? 전에 봤을때 몇만개가 있던것 같은데, 그게 전부 private 은 아닐테고, private 은 위표에 지정된 320여개 정도가 있는거지? 아마도 대부분이 주인이 없을것 같기는 한데.. 유림이가 이야기한 태그 다는 것 좋다. 강제할수 있다면 좋을텐데..

우선 지금 있는 private 스냅샷에 연결된 특별한 정보가 없다면 삭제해도 될것 같아.

Kim-Yul commented 11 months ago

네, 맞습니다. 원래 private snapshots 카테고리에 존재하는 스냅샷은 다른 계정의 비공개로 공유된 스냅샷이나 우리 계정의 스냅샷 항목이 나타납니다. 확인해보았을 때는 현재 모두 우리 계정의 스냅샷만 존재하고 있었습니다. 즉, 위 표에 있는 스냅샷의 개수는 모두 요금이 나가는 우리 계정 소유의 스냅샷입니다.

전에 보았을 때 있던 몇 만개는 자세하게 조사하지 않았을 때라 혼동이 있었습니다. 그때 그것은 public snapshot으로 aws에서 제공하고 있는 것입니다. 따라서 요금이 부과되지 않고, 계정에서 관리할 항목이 전혀 아닙니다.

스냅샷 삭제를 원하지 않는다면, 스냅샷을 만든 사용자가 스냅샷에 이름을 부여하거나 태그를 달면 될 것 같습니다. 현재 대부분 스냅샷에 이름이 부여되어 있지 않기에, 그것만으로도 사용하는 것인지 아닌지 구분이 가능합니다. 또한, 이름이 부여된 스냅샷만 남은 경우, 필요하지 않은 스냅샷이라면 정리할 수 있게 슬랙에 리스트로 보내는 것만으로도 관리가 가능할 것 같습니다.

general 채널에 혹시 스냅샷을 백업해둔 경우, Name 태그를 달아달라고 요청하고 작업 진행하겠습니다. 그리고 AMI나 볼륨과 연결되지 않은 항목부터 삭제 진행하겠습니다. 현재 오레곤 리전에는 특이 케이스의 스냅샷이 존재하고 있어, 작업을 진행하면서 삭제를 하게 된다면 인스턴스와 AMI이 존재하지 않는 서울리전부터 진행하겠습니다.

Kim-Yul commented 11 months ago

ec2(stop instance 및 volume) 관리 완료하였습니다. 코드 수정 및 머지 진행하였습니다. 서울 리전에 있는 람다에 반영하였습니다.

kmu-leeky commented 11 months ago

오케이. 유림아. 관리 완료 했다는건 삭제를 했다는건가? 아니면 다음 주기에 보내지게끔 설정을 했다는 이야기야?

"오레곤 리전에는 특이 케이스의 스냅샷이 존재하고 있어" 이건 어떤 내용이었지?

Kim-Yul commented 11 months ago

말이 모호했던 것 같습니다. 서울 리전에 람다에 반영되도록 수정하였고, 오늘 아침부터 수정된 코드로 반영되었습니다. 또한 새로운 코드를 적용하다가 혹시나 이상이 있을까 하여 새로운 람다에 적용하여 연결해두었고, 제대로 작동하는 것을 확인하고 이전에 사용하던 람다는 제거해두었습니다.

오레곤 리전에 특이 케이스 AMI 및 스냅샷

1. ami-0cb57b7f84eb98fe3
2. ami-059d5b3b50a6e3307

오레곤에는 총 18개의 AMI가 존재합니다. 이는 콘솔 상에서 확인했을 때입니다. 그러나 boto3를 이용하여 코드 내에서 확인해보면 총 17개의 AMI가 검색됩니다.

2번째 ami는 boto3를 통해 인식되지 않습니다. 그러나 ami에 연결된 스냅샷은 boto3로 확인이 가능합니다. 이 부분에 대해서 aws 지원팀에 문의 해두었습니다.

또한 1번째 ami는 boto3에서 ami 인식이 가능하지만, 연결된 스냅샷이 boto3로 인식할 수 없습니다. 콘솔에서는 스냅샷을 확인할 수 있습니다. 이 부분에 대해서도 aws 지원팀에 문의 해두었습니다.

위의 사례가 오레곤에 존재하여, 답변을 받아야 진행할 수 있을 것 같아 오레곤 리전을 제외하고 다른 리전부터 정리하려고 한 것입니다.

regions us-east-1 ap-east-1 ap-northeast-2 ap-northeast-1
private snapshot 12 4 171 1
owned by snapshot 12 4 171 1

따라서 오레곤 리전 외 4개 리전 먼저 삭제 진행하겠습니다.

kmu-leeky commented 11 months ago

오케이. 이번기회에 우리 자원들이 깔끔하게 정리가 되겠다.

Kim-Yul commented 10 months ago

24 이슈 작업 완료하였습니다.

람다에 반영 완료했습니다.

추가적으로

Kim-Yul commented 10 months ago

ec2 및 snapshot 을 통해 자원관리 진행 완료하여 클로즈하겠습니다.