Amazon EC2 part.1

Elastic 이라는 단어는 어떤 이미지를 가지고 있을까? 찰랑찰랑한 샴푸? 유연하다? 탄력적이다? 등등의 이미지를 가지고 있다. Amazon에서도 이와 같은 컴퓨터 클라우드 환경을 구축하고 배포하기 위해 Amazon EC2(Elastic Compute Cloud)라는 서비스를 만들었다.

 

이 서비스는 일정한 규모와 크기로 사용하기 위해, 즉 트레픽의 변동이 그다지 크지 않은 일정한 환경에서 운영하는 에플리케이션을 실행하기 위한 컴퓨팅 환경을 제공하는 기능이다.

 

이런 EC2서비스는 온프레미스 환경(현실)에서 서버로 구현했던 '모든 것'을 EC2에서 구현 할 수 있으며 EC2에서 만들어지는 '서버'도 마찬가지로 구현할 수 있다. 즉 EC2서비스는 가상의 서버를 만들고 관리를 하기 위해 만드는 서비스 이름이다.

 

EC2를 사용하기 시작하면 가장 먼저 눈에 띄는 단어는 instance라는 단어이다. 어디선가 많이 본 친숙한 단어가 아닌가? Class, instance, 객체.... JAVA와 같은 객체지향형 언어에서 자주 보던 단어이다. 하지만 거기서 쓰던 단어와는 조금 의미가 다른데 여기서 말하는 instace는 VM웨어 등에서 사용하는 가상의, 일회용 리소스를 사용하는 서버와 같다고 보면 된다. 

 

혹시 서버를 구축해 본 경험이 있는가? 온프레미스환경의 서버는 정말 단어 그대로 '애지중지'아끼고 가꾸고 관리해야한다. 혹시나 어딘가에서 트레픽이 서로 충돌하지는 않는지, 트러블이 발생해 서버가 먹통이 되지 않는지 이것저것 고민하고 걱정해야할 것이 많다. 또한 기본적으로 서버는 '구축' 해야하는데 그 과정은 굉장히 번거롭다.

물리적인 환경을 세팅하고 (기기를 사고 케이블을 연결하고 라우터를 포함한 장비를 연결하는 인프라를 구축해야 한다.) 가상서버를 만들고 성능을 구현하고 OS(운영체제)를 설치한다. 이후 별다른 문제가 없이 잘 구축이 되었다면 이 서버는 따로 스넵샷을 만들어 다른 사람에게 배포하거나 app, service등을 업데이트 해 사용한다. 정전이 발생하거나 특별한 일이 생겨서 서버가 다운이 된다면 안되기에 매일매일을 기도하는...심정으로 서버를 관리해 줘야 한다.

 

하지만 EC2는 이미 가상서버와 운영체제를 사용자에게 쥐어준다. 즉 Amazon에서 스넵샷을 받는 것과 비슷한 개념이라고 생각하면 이해하기가 편한데 이 서비스를 AMI(Amazon machine image)라고 한다. AMI은 반복성, 재사용성, 복구성, AWS Marketplace솔루션, 백업 기능을 가지고 있다. 또한 AMI에는 최소한 1개, 혹은 그 이상의 EBS 볼륨과 root볼륨용 템플릿, 누가 접근하고 사용할 수 있는가에 대한 시작 권한과 제품정보 와 같은 정보가 입력되어 있다.

 

 

AMI를 선택한 이후 놀랍게도 클릭 몇 번이면 서버가(instance)가 만들어 진다. 이 서버는 사용자의 편의에 맞춰 삭제 할 수 도 있으며 어느정도 사용이 된 환경까지도 스넵샷을 만들어 둘 수 있다. 즉 instance는 주기적으로 계속 관리하고 아껴야하는 그런 온프레미스의 환경과 같은 취급이 아닌 언제든지 백업, 스넵샷을 만들 수 있으며 자유롭게 공장에서 찍어내듯 구축할 수 있다.

이런 장점을 가지고 있기 때문에 App으로 인해 OS가 사라지는 큰 에러가 생기더라도 AMI를 통해 금방복구할 수 있다. 무엇인가를 시도할때 생기는 리스크를 최대한 줄일 수 있다는 의미이며 개발자들은 다양한 서비스를 Test해 볼 수 있으며 개발자의 창의력과 사고를 더더욱 확장 시킬 수 있는 아주 좋은 연습환경이 제공이 된다. 또한 인스턴스에서는 온프레미스 환경의 서버와 달리 서버를 자유롭게 증/감 할 수 도 있다. 이를 통해 사용하는 데이터의 양을 기반으로 한 의사결정이 가능해 진다.

 

또 다른 장점으로는 AMI는 개발자가 직접 한땀한땀 정성들여 만들 수 도 있으며 AWS가 사전에 만들어 둔 서비스를 이용할 수 도 있으며 업체들이 만들어서 기본세팅이 끝난 AMI을 판매하는 Marketplace에서 구매도 할 수 있다. 즉 내가 어떤 환경과 상황을 요구하던 간에 자금만 뒷받침이 되어진다면 만들 수 있다는 의미 이다.

 

만약 서로 다른 가용영역에 intstace들을 만들고 트레픽 분산을 시켜 두었다. 이때 다른 가용영역에 문제가 생겨서 손실이 되었다고 상상해 보자. 이때 이 서버 자체를 AMI화 시켜두었다면 손실된 것을 그대로 복구시킬 수 있다. 즉 특정 상태의 instace를 백업 시켜두는 작업이다.

 

 

이렇게 훌륭한 서비스인 AMI이미지는 사실 관리하는게 사실 굉장히 번거롭다. 보통 AMI는 서버를 새롭게 만들거나 다운된 서버를 복구하기 위해 사용하는데 이때 지금, 현재 다른 서버와 동일한 상태를 유지해야 한다. A라는 서버가 업데이트를 한다면 A-1이라는 AMI도 당연히 업데이트가 되어 있어야 한다. 즉 업데이트를 할 때마다 지속적으로 AMI를 삭제하고 다시 형성해야한다. 이런 귀찮음을 해결하기 위해 EC2 Image Builder라는 서비스를 사용하면 된다.

 

이 서비스를 사용하게 되면

1.원본 이미지가 변경이 될 때 EC2 Image Builder를 통해 변경이 된다.

2.그렇게 되면 실제로 운영이 되는 환경의 instace의 상태도 업데이트가 자연스럽게 되고

3. 이 업데이트가 적용되면서 AMI가 자동화 되어 만들어지는 개념이다.

 

intstace를 만들때 가장 처음으로는 VPC를 통해 네트워크를 구성하게 된다. 이때 특정 리전에 네트워크를 구성하게 되며 그 이후 EC2서비스로 이어지게된다. 인스턴스는 네트워크 없이 형성되지 않기 때문이다. 이후 EC2에서 AMI이미지를 선택한다. 이후 Instace type을 선택한다. 어떤 성능을 가지는 가상의 PC를 만들것인지에 대한 설정을 한다.CPU, RAM등. 이후 configuration을 설정한다.(어떤 네트워크를 구축하며 몇 개를 형성할것인지 권한은 어떤것을 줄것인지 등등. 여기에서 UserData-사용자정보)를 입력한다.

UserData라는 말이 있는데 사용자 정보 라는 의미를 가지는 이 단어는 어떤 의미일까? 혹시 linux를 사용해 본적이 있는가? 없다면 다른 페이지에서 linux와 운영체제 를 읽어보기 바란다. 아파치 실행, yum 업데이트 등을 명령할 수 있는 하나의 쉘 스크립트 이다. 

좀 더 구체적으로 표현하면 인스턴스가 만들어진 직후에 실행하기를 원하는 스크립트 명령어이다. 여기에 스크립트를 기입하게 되면  instace가 만들어진 직 후 '단 한 번'(2회도 3회도 아닌 단 1번이다.) 실행이 된다. 이 userdata는 인스턴스를 만들고 나서 지속적으로, 반복적으로, 혹은 여러개를 만들고 동일하게 명령어를 지정해야하는 작업의 경우 주로 사용하게 된다.

UserData는 '따로따로 설정되는 메타데이터 정보를 활용해 환경변수에 세팅을 하겠다.' 라는 목적을 가질때 종종 사용되기도 한다.

메타데이터는 가상화 레벨에서 instace를 관리하기 위한 추가 정보이다. 운영체제가 직접 이것을 확인할 수 없기 때문에 필요할때마다 확인하기 위한 경로를  설정할 수 있으며 어떤 메타데이터를 읽어야할지도 확인할 수 있다. 운영체제가 메타데이터 정보를 참조할려고 할때 주소값을 입력해 주면 된다. instance-id, mac주소, ip, 각종 hostname 등이 메타데이터의 예시이다. UserData에 명령을 기입해 instance가 최초로 실행이 되며 이 후 메타데이터를 참조한 이후 자동으로 세팅이 되도록 만들 수 있다.