6하 원칙으로 알아보는 AWS 환경에서의 태그 전략
여기서 다루는 내용
· 시작
· Why – 태깅은 왜 하지?
· What – 무엇에 태깅하지?
· When – 태깅은 언제 하지?
· Where – 태깅은 어디에서 하지?
· How – 태깅전략은 어떻게 하지?
· Who – 태깅은 누가 관리하지?
· 마치며
시작
안녕하십니까, GS네오텍 최준승입니다.
오늘은 이전과 좀 다른 형식으로 글을 써보려고 합니다. 이곳은 일종의 기술 블로그(?)다보니. 대부분 캡쳐를 바탕으로 여러 스텝을 밟아가며 글이 전개되기 마련인데요. 오늘 선정한 주제는 그 일반적인 형식에 잘 맞지 않는다는 생각이 들었습니다. 따라서 오늘은 캡쳐를 최대한 배제하고. 주어진 주제를 최대한 잘 설명할 수 있는 형태로. 하나의 잘 읽히는 수필같은 글을 써보고자 합니다.
금일 주제는 “태그”입니다. “태그”를 다는것. 관리하는 것으로 의미를 확장하면 “태깅”이 되겠습니다. 클라우드. 아니 AWS에서 태깅이 중요하단 내용은 곳곳에 등장합니다. 심지어 AWS 업데이트 내용 중에는 “어느 리소스에 드디어 태그를 달 수 있게 되었습니다”라는 꼭지도 꽤 자주 나오곤 합니다. 그렇다면 EC2 인스턴스에. EBS 볼륨에. S3 버킷에 각각 이름표 딱지를 붙이는게 뭐가 그리 중요한 일일까요? 집에서도 서랍에 양말이 들었는지. 초코파이가 들었는지. 알 수 있게 표시해 놓는 이유는 서랍을 두번 열기 싫으니까.. 즉 귀차니즘.. 아니 “효용”이 있기 때문입니다. AWS 환경에서도 다르지 않습니다. 태그를 달고 관리하게 되면 뭔가 “이득”이 있으니까. 다른 행위를 하는데 도움이 되니까 중요하다고 말하는 것이겠죠.
결국 오늘 주제는 태깅을 하면 어떤 효용이 있는지. 어떤 방법으로 해야 하는지. 어떻게 누가 관리해야 하는지에 대한 얘기로 환원됩니다. 이 얘기들을 오늘은 특별히 6하 원칙에 입각해 서술해보려고 합니다. 근본적으로 무리한 설정이다보니. 좀 부자연스러운 부분이 생기는 점은 이해해 주시구요. 이 글을 다 읽고 정말 인상깊었다는 감상문과 함께 택배받을 주소를 이메일로 보내주시면 선착순으로 초코파이 한상자를 보내드리도록 하겠습니다. 물론 제 이메일 주소는 알려드리지 않습니다. 더불어 AWS 환경의 태그와 관련된 기본적인 속성도 여기서는 따로 설명드리지 않겠습니다.
그럼 시작!
Why – 태깅은 왜 하지?
제일 중요한 질문입니다. 어떤 행위의 필요성을 제일 먼저 알아보는 이유는. 필요하다고 인식을 해야 사람이 움직이기 때문입니다. 이글도 마찬가지로 “태깅”이 유의미하다는 생각이 들어야 뒤따라오는 글을 읽겠죠. 오늘 포스팅에서는 이 부분을 설명하는데 가장 많은 영역을 할애하려고 합니다. 결론부터 말씀드리면 태깅은 쓸모가 많습니다. 그리고 이어 설명드리는 상황이 독자분의 상황과 교집합이 있다면 “여러분에게도” 태깅은 쓸모가 있는것이지요.
첫번째 쓸모는 “특정 작업대상”을 분리할 수 있습니다. 예를 들어 이런거죠. 제가 DLM이나 AWS Backup을 통해 일 단위로 EBS 볼륨을 백업(스냅샷 생성)을 하고 있다고 가정해 보겠습니다. 만약 백업 대상 목록을 볼륨ID 단위로 관리해야 한다면 매우 귀찮은 일입니다. 시시각각 EBS 볼륨이 생성되고 삭제되는데. 이 갱신시점마다 별도로 백업 대상 목록도 갱신해야 하죠. 물론 자동화하면 된다지만. 어떤 것은 백업 대상에 넣고 어떤 것은 백업 대상에서 제외할지 구분하는 기준도 필요합니다. 그래서 결국 태그같은 “부가정보”가 필요합니다. 애초에 DLM이나 AWS Backup에서는 백업 시점마다 태그 기준으로 대상을 재탐색하도록 기능을 만들어 놓았습니다. EBS 볼륨을 생성할때 “Backup”이란 키에 “Yes”라는 키값을 넣어놓으면. 다른 일체 작업 없이 해당 볼륨을 백업 대상에 포함시킬 수 있습니다. 이 Bulk Action이라고 하는 작업들은 AWS System Manager라는 서비스와 연계되어 특정 태그를 갖고 있는 그룹단위로 패치작업이나 리소스삭제도 쉽게 실행할 수 있도록 기능이 이미 다 만들어져 있습니다.
두번째 쓸모는 “비용”을 분리할 수 있습니다. AWS 환경에서 비용을 가장 깔끔하게 분리할 수 있는 방법은 “AWS 계정을 분리”하는 것입니다. 하지만 AWS 계정이 늘어난만큼 관리 포인트도 그만큼 늘어나고 공용으로 쓰는 인프라가 있을수도 있고 그럼 또 연계 구성을 만들어야 하고. 원하는 단위로 비용을 분리하기 위해 N개의 계정을 만드는 것에는 현실적인 한계가 있습니다. 이때 하나의 AWS 계정 안에서 “태깅”을 사용하게 되면 비용을 분리할 수 있게 되죠. 예를 들어 내가 게임 서비스를 하고 있는데 3개의 게임이 모두 하나의 AWS 계정 내에 구성되어 있다고 칩시다. 이때 “Game”이란 키에 “맞고”, “섯다”, “고스톱”이란 키값을 넣게 되면. 저 단위로 비용을 분리해서 볼 수 있습니다. “env”에 “dev”, “stage”, “prod”라는 값을 넣어서 비용을 분리해서 볼 수도 있겠죠. 좀 깊게 들어가면. 완벽히 발라지지 않는 영역도 일부 있고. 실제 특정 태그 기준으로 AWS의 빌링 원본 데이터를 나눠 받고 싶으면 미리 설정해야 하는 부분도 있습니다만. 이 부분에 대해서는 자세히 설명하지 않겠습니다.
세번째 쓸모는 “권한”을 분리할 수 있습니다. AWS 환경에서는 IAM User/Role 단위로 일단 사용자를 분리하지요. 그리고 각 사용자 단위에게 적절한 권한을 최소로 줍니다. 이때 태그를 기준으로 권한을 더 잘게 쪼갤 수가 있습니다. 예를 들어 jack이라는 IAM User에게 “owner” 태그가 “jack”인 EC2 인스턴스만 “시작/중지”할 수 있도록 IAM Policy를 만들어 줄 수 있습니다. Condition 필드에 StringEqual이나 뭐 여러가지 방법을 통해 Action의 제약조건을 설정해 줄 수 있는 것이지요. 여기서도 깊게 들어가면. Condition을 줄 수 있는 Action의 범위가 제한되어 있고. 고려할 부분들이 더 있습니다만 이 부분도 각자 찾아보시면 되니 자세히 설명하지는 않겠습니다.
What – 무엇에 태깅하지?
태깅을 하는 대상은 물론 AWS 리소스입니다. EC2 인스턴스가 될수도 있고 EBS 볼륨이 될수도 있고. S3 버킷이 될수도 있고. Glue의 크롤러가 될수도 있고. 말하자면 끝이 없죠. 아마 AWS에서 목록을 정리한 문서도 있을겁니다. 앞에서 말씀드린 것처럼 태그를 지원하는 대상은 순차적으로 확대되고 있습니다. 이 말은 즉 제가 태그를 달고 싶어도 달 수 없는 리소스가 있다는 말입니다. 한가지 더 말씀드리면 여기서 말하는 태그는 일반적으로 리소스에 붙은 “Name”과는 또다른 계층일 수 있습니다.
사용자를 좀 더 혼란스럽게 하는것 중 하나는 “태깅 방법”에 따라 그 대상 범위가 다르다는 점입니다. 예를 들어 태그를 애초에 지원하지 않는 리소스가 있고. 태그를 지원하고 CLI/SDK에서는 태그를 관리할 수 있지만. AWS Management Console에서는 관리를 지원하지 않는 리소스가 있고. 뒤에서 설명할 Resource Group에서 태그를 관리할 수 있는 리소스가 또 따로 있고. 이런식으로 다계층으로 구성이 되어 있습니다. 이 목록을 실시간으로 파악하고 있을 필요는 없습니다만. 제어 수단에 따라 대상군이 달라질 수 있다는 점은 알아두면 좋겠죠.
그럼 여러분은 “내가 무언가 분리하고 싶은 대상이 태깅을 지원”하는지를 먼저 알아봐야 할 것입니다. AWS에서도 활용도가 높은 애들부터 태그를 만들어 놨을테니. 아마 대부분의 주요 리소스는 태깅을 지원하고 있을 확률이 높습니다. 만약 현재 미지원인데 태그가 꼭 필요한 대상이 있다면. 앞으로 태그를 지원할때까지 AWS 업데이트를 기다려야 겠죠. 경험적으로 신생 서비스거나 인기가 낮은 서비스의 경우 태그 지원이 상대적으로 지연될 수 있습니다.
When – 태깅은 언제 하지?
세번째 질문입니다. 그럼 리소스에 태그 딱지는 언제 붙일까요? 여러가지 상황이 있을 수 있습니다. AWS Management Console을 주로 활용하시는 분은 못느끼실 수 있지만. 사실 대부분 Tag를 다는 API는 별도입니다. 즉 EC2 인스턴스를 만들때 파라미터로 태그값을 넣는게 아니라. EC2 인스턴스를 생성하고 난 후에 해당 인스턴스ID에 딱 찍어서 특정 태그값을 나중에 붙이는 방식입니다. 이걸 GUI 환경에서는 한번에 하는 것처럼 편리하게 만들어놨지요. 따라서 CLI/SDK 환경에서는 태깅 작업을 별도로 찍어주는 과정이 필요합니다.
태깅은 리소스 생성때 할수도 있지만. 추후에 값을 붙이거나 수정할수도 있습니다. 사실 이 관리 작업이 더욱 중요합니다. 이 작업은 사람이 수동으로 할수도 있고. Lambda같은 서비스를 통해 자동화를 할 수도 있습니다. 예를 들어 EC2 인스턴스가 생성될때마다 해당 API를 CloudWatch Event로 캐치해다가 기본값 태그를 박아주는 람다를 연계한다거나. EC2 인스턴스 이름에 맞춰서 디펜던시가 있는 EBS 볼륨에 동일한 태그를 넣어준다거나 하는 작업을 자동화할 수 있습니다. 이런식의(Dependency가 있는 객체에 태그를 일괄적으로 붙여주는) 예시는 구글링 하시면 꽤 나오니까 잘 활용하시면 됩니다.
뒤에서 설명드릴 Resource Group에서는 태깅이 안된 애들을 일괄적으로 탐색하는 것도 가능합니다. 이건 “언제”의 문제가 아니라 “어떻게”의 문제에 가까우니 뒤에서 다시 설명드리도록 하겠습니다.
Where – 태깅은 어디에서 하지?
네번째 질문입니다. 그럼 태깅은 어디에서 할까요? 이 부분은 앞의 설명과 좀 겹치는 부분이 있어서. 여기서는 Resource Group에 대한 설명에 집중하도록 하겠습니다.
Resource Group이라는 AWS 서비스(기능)이 있습니다. 이게 좀 혼동될 수 있는게 Legacy 버전이 있고. 18년쯤에 새로 나온 AWS Resource Group이라는 애가 따로 있습니다. 혹시 예전에 Legacy한 버전을 사용해보셨다면 차이점은 링크에서 확인해보시구요. 가장 큰 특징은 신버전에서는 API를 지원한다는 점과 Regional로 범위가 축소되었다는 점인것 같네요. 암튼 이 Resource Group이라는 서비스를 통해 AWS 리소스의 태깅을 관리하고. 만든 그룹 단위로 특정 커맨드를 날리거나 로그를 보는 등의 행위를 분리해서 할 수가 있습니다.
먼저 여러분은 Resource Group 객체를 만드셔야 합니다. 이 그룹에 속하는 리소스는 태그를 기준으로 정의합니다. 예를 들어 “맞고-dev”라는 Resource Group을 만드시려면 “Game”=”맞고”이고(AND) “env”=”dev”인 태그 기준을 주시면 됩니다. 그럼 저 두가지 태그 조건을 만족하는 리소스들이 이 그룹 안으로 고스란히 들어옵니다. 실시간으로 갱신되서 말이죠. 그렇게 그룹을 하나 만드셨으면 이 그룹단위로 원하는 행위들을 이어갈 수가 있습니다. 예를 들어 System Manager에 Built-In insight이라는 부분이 있는데요. 여기서 각 리소스 그룹 단위로 Config이나 CloudTrail 로그를 제한적이지만 분리해서 볼 수 있습니다. 물론 이 그룹단위로 패치를 하거나 Run Command를 날리는 것도 아주 손쉽게 할 수 있죠. 좀 궤를 달리하는 얘기지만 CodeDeploy에서 배포할 대상을 태그 기준으로 지정하는 것도 외부적으로는 CodeDeploy에서 제어하는 영역으로 봐야 하나. 아마 AWS 내부적으로는 비슷한 로직을 거쳐 이런식으로 그룹핑을 하고. 관련 Action을 수행하도록 구현되어 있을 것입니다.
흥미로운 점중의 하나는 AWS Resource Group(신버전)의 경우 nested 형태로 다계층을 구현할 수가 있습니다. 즉 A라는 Group 객체를 하나 만들고. A1이라는 Group 객체를 하나 만들어 A 그룹 아래 넣어주는 것도 가능합니다. 좀 복잡하긴 하지만. 이런 구조를 Native하게 지원하게 되면. 초기 그룹을 어떻게 설계하느냐에 따라 관리단에서 신경쓸 점이 몇가지는 줄어들게 됩니다. 이것도 관심 있으신 분들은 AWS 공식 문서를 참조하시면 되겠습니다.
How – 태깅전략은 어떻게 하지?
자. 이번엔 “어떻게”의 영역까지 왔습니다. 거의 끝났으니 힘내시구요. 우선 태깅을 한다고 하면 키구조부터 설계를 해야 합니다. 몇개의 키를 가져갈거냐. 키값은 어떻게 할것이냐. 어느키만 일원화해서 별도 관리할 것이냐. 기본값을 만들것이냐. 이런 여러가지 질문에 대해서 사전에 정해진 규격을 만드는 것이 필요합니다. 이것이 명확히 정해져 있지 않으면 태그 체계와 값들이 지저분해지고. 지저분해지면 자연스럽게 이후 활용성이 떨어질 수 있습니다.
제 생각에는 각 사용자가 아닌. 별도의 “태그맨”이 일원화해서 관리할 키들을 미리 정의해서 관리하는 것이 중요할 것 같습니다. 사용자의 영역은 그것대로 분리해서 두고요. 태그 키네임을 기준으로 태그 권한을 분리할 수 있는지까지는 저도 잘 모르겠네요. 암튼 “태그맨”이 관리할 태그키를 정의해 놓고. 이 태그에 대해서는 철저하게 생성부터 이후 삭제되기까지 태그값을 관리하고 갱신하는 영역을 수동이든/자동이든 꾸준히 관리해야 합니다. 그래야 맨 앞에서 설명드린 효용의 측면에서 그 효과가 깔끔하게 극대화될 수 있습니다.
각 사용자도 기본적인 태그 속성에 대해 아는것이 좋습니다. 각 Tag의 Value에 몇글자까지 들어가는지. 리소스당 최대 몇개의 키를 넣을 수 있는지. 대소문자는 구분되어 취급되는지 이런 부분들을 사전에 숙지하면 아무래도 나중에 손이 덜가겠죠. 손이 덜 가려면. “태그맨”은 사전에 이런 부분들을 사전에 사용자에게 고지하는 것도 좋은 방법입니다. Resource Group의 Tag Editor에서는 통해 일정 조건(예를 들어 untag된)의 리소스를 쫙 스캔해서 일괄적으로 태그를 붙여주는 기능도 제공하고 있습니다.
Who – 태깅은 누가 관리하지?
제 생각에는 태그를 주기적으로 관리하는 “태그맨”이 꼭 필요하다고 생각합니다. 그리고 이 태그맨에게는 IAM에서 태그 관련 권한을 줘야겠죠. 물론 각 리소스의 목록을 볼 수 있어야 하니 대부분의 서비스에 대한 읽기 권한도 필요할 것이고. 만약 Resource Group을 사용한다면 “ResourceGroupsandTagEditorFullAccess” 같은 권한도 추가로 필요할 수 있습니다.
태그를 단순히 식별용도로 쓴다면 태그값의 중요성이 떨어질 수 있지만. 비용을 분리하거나. 권한을 분리하거나. 배포대상을 정의하는데 태그가 사용된다면 값이 잘못된 경우 심각한 불상사가 발생할 수도 있습니다. 사실 이 부분이 양날의 검처럼. 태그를 활용하기 어려운 이유가 될수도 있다고 생각합니다. 태그를 확실하게 활용하려면. 반드시 태그값을 관리하고 제어하는 IAM의 권한도 확실히 분리되서 사전에 선언되어 있어야 합니다. 이게 사실 말이 쉽지 간단한 일이 아닙니다. 수많은 시행착오가 필요합니다. 일례로 일반 사용자에게 태그 권한을 제거하면. 몇가지 문제점이 생길 것 같긴 합니다.
그럼에도 불구하고. 태그를 중요하게 활용해야 한다면 주기적으로 태그를 관리하는 전담 “태그맨”이 있어야 합니다. 그리고 이 태그맨은 전체적인 AWS 리소스에 대한 인사이트와 관리 전략을 이해하고 있어야 합니다. 사실 이런게 Devops 측면에서 제일 먼저 고려해야 할 부분 중 하나인데.. 제가 보면. 이 부분을 제대로 완벽하게 활용하고 있는 곳은 좀처럼 보기 어려운 것 같습니다.
마치며
이제 마칠 시간입니다. 요약하면 태그는 AWS 리소스를 분리하고 관리하는데 분명히 중요한 역할을 할 수 있는 도구임은 분명합니다. 도구를 쓸지 말지는 여러분이 판단할 문제구요. 이미 AWS에서는 이 도구를 효율적으로 쓸 수 있도록 많은 기능을 개발자스럽게(?) 연계해 놓았습니다. 관련해서 더 알아보실 분은 AWS Resource Group 페이지나 AWS Tagging Strategies 문서를 참조하시면 됩니다.
캡쳐 없이 건조한 글을 썼더니 작성이 훨씬 빠르네요.
이번 포스팅을 통해 AWS 태그와 관련된 인싸이트가 약간이라도 생기셨길 빕니다.
그럼 마치겠습니다. 끝!
최신 댓글