AWS를 공부하는 입장에서 바라봤습니다! 이해를 위해 중간중간 견해나 비유가 들어갈 수 있습니다. 틀리거나 잘못된 부분이 있으면 언제든지 댓글 달아주시면 감사하겠습니다😀
들어가기
앞에서 API로 클라우드를 제어하는 것을 알게 되었다면, 이번에는 API로 직접 서버 리소스를 제어하는 방법에 대해서 살펴봅니다. 저는 평소에 AWS를 사용하며 웹 콘솔을 이용해 주로 제어를 해왔습니다. 버튼 몇 번 누르기만 하면 생기던 EC2 인스턴스들이 생성되기 위해 뒷면에서 어떤 과정으로 진행됐는지 이해하려는 시각으로 이 장을 폈습니다.
1. 서버 리소스의 제어를 위한 기본 API
서버 리소스
서버 리소스는 타입과 이미지로 구성되어있습니다. 제가 사용하던 AWS에서는 EC2(인스턴스)입니다. 타입은 리소스의 크기와 속성을 정리한 것이고, 이미지는 서버의 기동 이미지를 뜻합니다. AWS에서는 AMI(Amazon Machine Image)가 됩니다. 서버는 반드시 하나의 타입과 이미지로부터 만들어지는데, 타입과 이미지는 여러 개의 서버를 만드는데 이용될 수 있습니다. 마치 Windows10을 깔 때, 이미지 파일을 하나 다운받으면 여러 컴퓨터에 설치할 수 있는 것과 마찬가지같습니다.
서버 리소스와 API
가상서버를 생성할 때 호출되는 API가 있습니다. 유저가 서버를 생성하는 명령어를 입력한 후 대략적인 API의 호출방식은 다음과 같습니다.
- 인증 기능을 담당하는 컴포넌트에 유저의 인증 정보를 보낸 후, 토큰과 엔드포인트를 발급받는다.
- 발급받은 토큰을 이용해 유저의 아이디로 서버를 생성할 때 사용할 이미지를 찾는다.
- 이미지가 존재한다면, 발급받은 토큰과 함께 설정할 서버 정보를 이용해 서버의 생성을 요청한다.
- 이후 서버가 생성되었다면, 서버 id를 이용해 서버의 정보를 확인할 수 있다.
마치 일반적인 서비스에서 유저가 로그인하고, 글을 생성하는 것과 같은 맥락인 것 같다고 느꼈습니다. 이번에는 더 자세히 알아보겠습니다.
- 인증
모든 API의 호출 과정에서는 1번 과정에서 발급받은 토큰을 이용해 통신을 해야합니다. 이 때, 토큰 뿐만이 아니라 엔드포인트도 반환합니다. 이 반환된 엔드포인트를 이용해 유저는 다음 통신해야 할 URL을 알게됩니다.
- 템플릿 이미지의 유효성 검증
템플릿 이미지가 서버에 존재하는지 확인하는 과정입니다. 이미지의 UUID를 통해 존재 여부를 확인합니다. 해당 이미지가 없거나 접근 권한이 없는 경우에는 에러로 응답합니다. 결제를 하려고 카드를 긁을 때, 보통은 잘 결제가 되겠지만 가끔 잔액부족이 뜨면 많이 창피할 수도 있는데, 그 전에 카드 잔액을 확인해보는 과정이라고 생각하면 되겠습니다. 결제가 안되면 카드사가 결제를 막아뒀는지, 잔액이 없는지, 분실 신고를 당했는지 많은 생각이 들 것 같습니다! 이와 비슷하게 서버에서도 이 과정을 생략하면 어떤 문제인지 정확하게 파악하기 힘들기 때문에 실제 서버 생성 전, 한 번 체크하는 과정이라고 생각하면 될 것 같습니다. (얼리리턴)
- 가상 서버의 생성
가상 서버를 생성하는 데는 많은 시간이 소요가 됩니다. 서버를 생성하는데 필요한 정보를 유저로부터 받고 나면, 우선 UUID를 응답하고 뒤에서 실제 구축작업이 실행됩니다. 제가 Dynamic Link를 다수 생성할 수 있는 API를 만든 적이 있는데, 하나 만드는데 생각보다 시간이 오래걸려 응답으로 진행사항을 알 수 있는 ID를 먼저 주고, 서버에서 비동기로 Dynamic Link를 만들었는데 이 과정과 같은 것 같습니다. 실제로 AWS EC2에서 인스턴스를 생성할 때, 즉각적으로 생성되지 않고 수 분 뒤에 생성이 완료되는 것을 알 수 있습니다!
- 생성된 가상 서버의 상태 확인
아까 Dynamic Link를 비동기로 만들었다고 했죠? 이 진행상황을 조회하기 위한 ID를 이용해 조회하게 되면 몇 개가 완료되었는지, 전체가 완료되었는지 알 수 있었습니다. 이와 같이 서버 생성 명령을 한 후, 지속적으로 상태체크를 할 수 있습니다. 서버 생성 후 해야하는 작업이 있다면, 완전히 생성된 후에 처리를 할 수 있게 됩니다.
가상 서버의 수명 주기
가상서버는 수명주기가 있습니다. 마치 컴퓨터를 하나 산 것과 비슷합니다. Windows 10 이미지를 이용해 컴퓨터를 켜고(시동), 재시작을 할 수 있고(재구동), 사용하지 않을 때는 전원을 끕니다.(정지) 그리고 완전히 컴퓨터를 사용하지 않는다고 생각하면 완전 본체를 버려버릴 수 있습니다.(삭제) 이렇게 가상서버는 기동, 재구동, 정지 마지막으로 삭제까지 크게 4가지로 분류할 수 있습니다. 서비스마다 다를 수 있으니 사용하는 서비스의 문서를 읽어보는 것이 좋습니다!
메타 데이터와 사용자 데이터
메타 데이터와 사용자 데이터는 가상서버의 환경 설정에 활용되는 데이터입니다.
메타데이터는 서버별로 따로 만들어지고, 여러개의 서버가 같은 메타 데이터를 공유할 수 없습니다. 메타데이터는 가상서버에 대한 정보를 제공하며, 주로 자동화 스크립트나 구성 관리 정보에 활용됩니다.
사용자 데이터는 가상서버에 액션을 실행해야 할 때 사용합니다. 예로는 쉘 스크립트가 있습니다. 미리 저장된 쉘 스크립트에 있는 정보로 실행할 수 있지만, 처리량이 많아지면 관리가 복잡하기 때문에 오픈스택이나 AWS에서는 Cloud-init이라는 툴을 사용해서 설정 내용을 룰로 정의합니다.
이미지 생성과 공유
Windows 10에서 이미지 백업을 할 수 있는 것 아시나요? 현재 내 컴퓨터 상태를 이미지로 본떠 저장해 나중에 이상태 그대로 복원할 수 있습니다. 이와 같이 가상 머신에서도 이미지를 추출해 관리할 수 있습니다. 오픈스택에서는 글랜스(Glance)로 관리하고 다른 유저와 공개 여부도 설정할 수 있습니다. AWS에서는 'CreateImage' API에서 이미지를 만들고, 'DescribeImages' API에서 이미지 정보를 얻어올 수 있습니다.
VM 이미지 가져오기
각 클라우드 서비스에서 만든 다양한 서버 이미지들을 서로 이동할 수 있습니다. AWS에서 오픈스택으로, 오픈스택에서 AWS로 또 다른 클라우드 서비스인 Microsoft Azure나 GCP에서도 가져올 수 있습니다. 만약 클라우드 서비스를 옮길 일이 생긴다면 이런식으로 이미지를 떠서 이사해도 괜찮겠다는 생각을 했습니다.
2. 서버 리소스의 내부 구성
앞에서는 API를 실행하는 과정만 알아보았습니다. 이제 실제 클라우드 내부에서 가상서버를 생성하는 과정을 소개합니다.
가상서버가 처리되기까지의 처리 흐름
다음은 오픈스택의 Nova를 예로들어 설명합니다.
- 메타데이터가 들어오면 가상 서버 생성 요청 메세지를 큐에 넣은 후, DB에 현재 상태를 기록한다.(
Building) - 스케쥴러는 큐에서 요청 메세지를 꺼내어 가상 서버 생성을 위한 준비를 한다.
- 스케쥴러가 상태관리 DB를 이용해 호스트들이 상태를 확인하고 가상 서버를 생성할 곳을 결정한다. 상태관리 DB에는 이미 주기적으로 호스트 리소스의 사용현황을 최신화하고 있다.
- 가상 서버를 생성할 호스트가 없다면 에러 응답!
- 스케쥴러가 가상 서버를 생성할 곳을 결정했다면, 가상 서버를 만들기로 한 호스트가 큐에서 요청 메시지를 꺼내고 가상서버를 기동한다.
- 이미지 찾기 불가, 네트워크 설정 실패 등 생성 못한 경우에는 에러 응답!
- 1번의 현재 상태를
Building에서Active로 갱신한다.
마치 여관에서 방을 대여해주는 것과 같은 프로세스같습니다. 내가 원하는 방을 주문하면, 주문을 받고 방을 찾기 시작합니다. 조건에 맞는 방이 찾아지면 방을 청소하고 손님을 맞을 준비를 합니다. 준비가 되면 손님에게 방을 대여해줍니다.
그 외의 API
클라우드의 API들은 GET메소드만 즉각적인 응답을 받을 수 있고, 나머지 POST, PUT, DELETE 방식을 사용하면 모두 비동기로 진행되어 GET메소드를 통해서 완료 여부를 파악할 수 있습니다. GET메소드를 제외한 직접 데이터를 조작해야하는 경우에는 많은 리소스를 소모하고, 비교적 오래 시간이 걸리기 때문인 것 같습니다.
마무리
AWS EC2 인스턴스를 조작할 때 마다 시간이 오래걸려서 그냥 그런가보다.. 생각을 하고 있었는데, 이런 작업이 뒤에서 진행되는 것을 알게 되었습니다. 클라우드에 대한 이해가 조금 더 넓어진 것 같습니다. 클라우드 서비스간 이미지가 호환될 수 있다는 것도 처음 알았고, 지금은 AWS 콘솔을 이용하고 있지만 언젠가는 API를 이용해 자동화시키는 경험도 해보고 싶습니다.
참고
- 그림으로 배우는 클라우드 인프라와 API의 구조 - 히라야마 쯔요시 저
