#3 Resource를 관리하는 자

안녕하십니까, 빅두 입니다.

 

제가 제 글을 읽으면서도 "이게 무슨 말이야?"라는 생각이 들 정도의 글을 보고 쑥쓰러웠습니다. 심려를 끼쳐 드려(?) 즐겁습니다(??).

생각을 해 보니 기준이 잘 서 있지 않고, 해야 할 내용이 너무 많은데, 길게 쓰려니 지루해지는 경향이 있어서 그런 것 같습니다.

그래서 갈치 포 뜨듯이 얇은 주제로 깊게 파보는 그림을 좀 그려볼까 합니다.

 

하지만… 오늘도 주제는 좀 무거운데요. 우선 시작은 미약하게 해 보겠습니다!

아 그리고 AWS를 설명하고 Azure를 설명하는 이유는.. 그냥 제가 AWS가 익숙해서 그렇습니다. 아마 Azure가 익숙해지면 순서는 바뀌지 않을까? 싶습니다.

 

 

AWS를 살펴 보겠습니다.

이 녀석에 대해서 Resource라 함은 고객이 사용하는 무언가 입니다. 이 무언가는 EC2라는 VM이 될 수도 있고, RDS라는 데이터베이스가 될 수도 있고, S3라는 Object Storage가 될 수도 있습니다. 한마디로 정의하자면 "고객이 만든 모든 것"이라고 할 수 있겠네요.

 

그렇다면, 오늘의 주제인 Resource를 관리하는 자는 AWS의 무엇일까요?

아쉽게도 AWS에서는 모든 Resource를 관리하는 그런 녀석이 없습니다.

하지만 비슷한 녀석이 있는데요. 그것이 바로 VPC라는 녀석입니다.

실제로 VPC는 관리라는 측면보다는 Resource의 부사장 정도가 될 것 같은데요. AWS의 일부 Resource들은 VPC에 종속관계를 가지기 때문에 이렇게 표현할 수 있을 것 같습니다.

 

기본적으로 AWS의 모든 Service들은 Endpoint를 가지고 있으며, Service에 생성되는 Resource들은 Endpoint를 가지게 됩니다. 왜냐고요? Amazon Web Service 잖아요.

하지만, 몇몇 Resource들은 설정에 따라 VPC를 통해서만 Resource에 접근이 가능하도록 설계되었습니다. 그 몇몇 Resource들이 바로 단일 EC2로 구성이 가능한 Service들 입니다.

단일 EC2로 구성이 가능하다는 의미는 Network와의 종속관계를 말할 수 있겠는데요. 대표적으로 EC2라든지, RDS, ElastiCache 등이 있겠습니다. AWS의 개념으로 말씀 드리면 Multi-AZ(HA)를 고객이 구현해야 하는 서비스들이 여기에 속한다고 할 수 있겠네요.

 

이 Resource들은 VPC에 종속되기 때문에 다음과 같은 특징을 갖습니다.

  - 사용자가 정의한 Subnet에 구성할 수 있다.

  - Security Group으로 Network 제어가 가능하다.

  - 사설 네트워크 통신이 가능하다.

  - 사설 네트워크로 정의된 Resource와 On-Premise가 통신하기 위해선 VPN 또는 Direct Connect를 구성해야 한다.

 

그렇다면, 그 이외의 Service들은 어떻게 접근하고 활용할 수 있을까?

두 가지의 방안이 있습니다.

1. Public Network로 Service에 접근한다.
2. VPC EndPoint로 연동시킨다.

 

첫 번째 방안인 "Public Network로 Service에 접근한다."는 말은 말 그대로 Private Network에서는 VPC에 종속되지 않은 서비스들에 접근이 불가능 하다는 의미 입니다.

AWS의 Service EndPoint는 Public Network에 존재합니다. 이 EndPoint에 접근하여 API Call을 하여 Service를 제어하도록 되어있기 때문에 Private Subnet에 존재하는 EC2도 Public Network와 통신이 되지 않으면 AWS Service에 접근할 수 없다는 의미 입니다.

 

이쯤에서 위에서 말한 내용을 그림으로 한번 그려 보죠

 

 

생각보다 많은 Service들이 VPC 외부에 존재하는 것을 알 수 있습니다. 위에서 보면 Private Network에 위치한 EC2가 VPC 외부의 Service와 통신하려면 NAT와 같은 Public Network와의 통신이 되어야 한다고 하였는데, S3와 같은 자주 사용하는 저장소가 VPC 외부에 존재하는 것을 보실 수 있습니다.

이렇게 되면 Private Network에 존재하는 WAS가 S3에 접근할 수 없는 어이없는 일이 발생합니다.

그렇다고 백도어를 만들 수도 없고...

 

그래서 두 번째 방안인 "VPC EndPoint로 연동시킨다."는 방법이 생겼습니다. EC2에서 S3로 업로드 할 때 꼭 Internet 구간으로 트래픽이 흘러야 하냐는 불편함의 피드백을 받고 AWS에서 만들어준 Service Gateway같은 녀석 입니다.

이것을 통해서 다음 그림과 같은 아키텍처를 그릴 수 있게 되었습니다.

 

 

즉, AWS Resource와 VPC를 연결해주는 연결고리를 만들어 줌으로써 EC2 Instance가 Public Network와 통신이 되지 않더라도 AWS Service에 접근하여 Resource와 통신할 수 있게 되었습니다.

물론, 모든 Service가 다 되지는 않습니다.

 

AWS에는 Resource들을 JSON설정에 의해 제작해주는 CloudFormation이라는 서비스가 있습니다.

종속관계와 Resource에 대한 정의가 되어있는 JSON 파일을 CloudFormation에 업로드 하게 되면 정의한 설정대로 Resource들이 짠! 하고 제작되어 집니다.

문제는 Resource 수정에 있습니다.

CloudFormation은 Resource를 생성할 때에 한꺼번에 생성해주긴 하지만, CloudFormation에 의해 생성된 Resource들은 각각 Service에서 개별적으로 조작이 가능하며, Resource가 수정된 정보는 CloudFormation Stack에 반영되지 않습니다. 그렇기 때문에 수정된 Resource들의 조직을 CloudFormation Stack으로 새로 제작해야 하는 작업이 발생하며, 기존 CloudFormation Stack은 수정된 Resource들을 추적하지 못해 삭제 또는 수정 시 어떤 Resource에 영향을 받는지에 대한 부분도 전부 추적해야 하는 어려움이 있습니다.

따라서, 재활용성이 높고 수정이 적으며, 도장처럼 한번 파고 수정하지 않는 Resource들을 제작할 때 CloudFormation을 사용하는 것이 좋을 것 같습니다. 아니면 복잡한 구성을 배포할 때에도 배포시에는 유용하게 사용할 수 있을 것 같네요.

 

 

다음으로 Azure를 살펴 보겠습니다.

사실 이 블로깅을 Azure의 Resource Group을 찬양하기 위해 만들어 졌다고 해도 과언이 아닙니다.

그래서... Azure에 대한 내용은 아주 짧게 끝날 것 같습니다. 왜냐하면? 다 되는 기능이니까요.

 

Azure에는 Resource를 관리하는 자가 존재합니다. 그 이름 바로 Resource Manager(Group)가 되겠습니다.

Azure에서 말하는 Resource는 AWS와 별반 다를 것이 없습니다. 마찬가지로 "고객이 만든 모든 것" 이라 지칭할 수 있겠는데요. Azure는 Resource Group이라는 녀석을 생성하고 Azure에서 생성하는 모든 Resource들은 Resource Group이라는 것에 배치하도록 되어 있습니다.

 

별거 아닌 것 같지만, 산재되어 있는 Resource들을 한 곳에 모아서 Grouping 할 수 있다는 것은 매우 가치있는 것 같습니다. AWS와 1:1 비교를 하자면, AWS의 경우 Resource들이 어디에 존재하는지 알려면, 모든 Service들을 모든 Region을 대상으로 전부 찾아봐야 확인이 가능합니다. AWS를 좀 더 잘 활용하시는 분 같은 경우 TrustAdvisor나 Billing Page 등을 이용하긴 합니다만, 일부 리소스만 확인할 수 있거나, 접근 권한 제어를 꼭 설정하는 페이지이기 때문에 접근이 쉽지 않습니다. (고로 나는 찬양한다 Resource Group을)

 

Azure에서 권장하는 Resource Group 사용 방법은 Life Cycle이 같은 Resource들 끼리 모으라는 이야기를 많이 합니다. 이유는, Resource Group을 삭제하는 것으로 하위 Resource들을 한꺼번에 지워버릴 수 있기 때문입니다. 삭제도 쉽구나~

 

Resource 제작도 AWS의 CloudFormation처럼 생성하는 Stack을 Import함으로써 누군가가 제작한 JSON 파일과 동일한 구성을 할 수 있으며, Export 기능으로 Resource Group의 상태를 JSON파일로 꺼내볼 수도 있으니 얼마나 편한지 모르겠습니다.

 

 

실제로 두 개의 서비스를 다 써보시면 아시겠지만, Resource관리에 대해서는 Azure가 훨씬 편한 것을 느끼실 수 있습니다.

제가 Azure에 대해서는 아직 다 공부를 하지 않아서 한가지 빠진 부분이 있습니다. 바로 Service EndPoint에 대해 Private Network에 있는 VM이 Azure Service EndPoint에 접근이 되는가? 에 대한 내용입니다만, 해당 내용은 공부 하면서 수정 업데이트 하도록 하겠습니다.

테클로 댓글 달아 주시면 좀 더 좋은 컨텐츠를 만드는 데에 도움이 될 것 같습니다!

긴 글 읽어주셔서 감사합니다.