ASG 생성에 앞서 서비스 레벨에서 가상환경을 어떻게 최신으로 유지할 것인지에 대해 고민해보아야한다.
이 점을 고려하기 위해서는 먼저 가상환경을 원하는 환경으로 세팅하는 방법을 생각해보아야한다.
가상환경을 원하는 환경으로 세팅하는 방법
우리가 로컬 PC에 Git 중앙 Repository를 구성하는 작업을 한다고 생각해보자.
1. os 설치부터 처음부터 구성한다.
2. Git이 설치된 이미지를 구해서 구성한다.
AWS에서 EC2를 원하는 환경으로 세팅하는 방법도 위와 비슷하다.
1. golden image로 인스턴스를 생성한다, 직접 설치한다.
2. golden image로 인스턴스를 생성한다, 서버가 설치하도록 설정한다.
3. Git이 구성된 AMI로 인스턴스를 생성한다.
더 많은 방법이 있을 수 있지만,
직접 설치하는 방법, 서버가 설치하도록 설정하는 방법, 아예 구성된 이미지 기반으로 생성하는 방법 내가 아는 방법은 이 세가지가 전부이다.
ASG가 어떠한 이유로 ‘확장’이벤트가 발생했을 때, 인스턴스가 생성된다는 것은 이처럼 os만 있든, 어떠한 패키지가 설치되어있든 간에 기준이 되는 이미지가 있다는 것이다.
그리고 이것을 우리는 ASG 시작 구성에서 설정할 수 있다.
- Golden image : 탬플릿, 기준이 되는 이미지.
그래서 코드 레벨에서 가상환경을 어떻게 최신으로 유지할 것인가.
“우리는 CI/CD를 통해서 배포자동화를 구성해놓았으니 고민할 필요없는 문제야.”라고 생각할 엔지니어는 없을 거라 생각이 든다.
배포자동화로 운용 중인 인스턴스들에 대해서 항상 최신의 코드를 반영하고 있다고 하더라도 트래픽이나 리소스 사용량에 따라 ASG의 확장이벤트가 발생 시
새로 생성되는 인스턴스에 대해서는 지금이 아닌 ‘이 전에 설정한 이미지’ 기반으로 인스턴스가 생성될 테니 말이다.
물론, 최신 코드를 기반으로 AMI까지 생성해서 ASG 설정까지 바꿔준다면 논외이다.
서비스 레벨에서 가상환경을 최신으로 유지하기 위해서는 곧 ASG 확장 이벤트에 의해 이미지가 생성될 때 최신의 코드를 반영해서 올라갈 수 있도록 설정을 해야한다.
어떤 설정을 통해 최신의 코드를 반영해서 EC2가 생성될 수 있을까.
1. user data(사용자 데이터)의 활용.
기본적으로 인스턴스 시작 시 최초 부팅에서만 실행되는 Shell 혹은 cloud-init 명령입니다.
사용하는 AMI에 따라 공급업체나 소유주가 실행 방식 및 시기를 지정했을 수도 있습니다. 직접 구성한 golden image가 아니라면 확인이 필요할 것 같습니다.
간단한 패키지 설치나 WAS 서비스 시작 등에서 유용합니다. 로드밸런서의 Healthy Check가 모든 명령 구성을 완료하기전에 있을 수 있으므로 주의해야합니다.
모든 스크립트 혹은 명령을 완료하는 시점까지 Healthy Check를 미룰 수 있도록 설정을 해두면 조금 더 견고한 구성이 될 것 같습니다.
해당 내용은 grace period 라는 키워드로 검색하면 더 많은 자료를 얻을 수 있으며, AWS Docs에서도 명시된 사항입니다.
Grace Period를 추가는 CLI와 콘솔에서 가능합니다.
2. lifecycle hook action의 활용.
수명주기 후크는 인스턴스 확장 혹은 축소 이벤트로부터 야기되는 인스턴스의 시작, 종료에서 특정 액션을 취하도록 설정하는 것을 말합니다.
어떠한 액션이 종료되거나, 설정한 시간이 초과되면 해당 인스턴스는 기존 ASG의 수명주기에 따라 대기상태에서 proceed 상태로 전환됩니다.
user data에 비하면 견고한 설정이 가능하다는 장점이 있으나, 다소 복잡하다는 단점이 있습니다.
위 글은 AWS 설명서의 문서를 바탕으로 작성되었습니다.
comments powered by Disqus