AWS Opsworks - Chef11 vs Chef12 차이점

머리글

AWS Opsworks는 Chef를 기반으로한 강력한 DevOps 도구이다. 오픈소스로 사용되는 각종 cookbook을 사용하며 AWS 인터페이스를 그대로 사용 할 수 있는 점이 큰 장점 중 하나이다. 2017년 9월 5일 당시 AWS Opsworks는 Chef11, Chef12 두 가지 버전으로 운영되고 있다. 둘 다 사용해본 생각을 간단히 정리 하려고한다.

공통

위에 설명한대로 Opsworks는 Chef cookbook을 기반으로 돌아간다. opsworks-agent-cli라는 프로그램이 Opsworks 대시보드에서 명령을 받아 내부적으로 custom cookbook을 업데이트하고 chef-client를 실행해준다. 

차이점1. Built-in Cookbook

Chef11과 Chef12의 가장 큰 차이점은 기본 Cookbook 유무이다. Chef11은 아래처럼 기본으로 해주는 작업이 많다. 반면에 Chef12는 기본 Cookbook이 없다.

 이는 장단점이 존재하는데, 장점으로 Chef11의 경우 ulimit설정이나 모니터링을 위한 ganglia 설정 등을 자동으로 해줘 신경을 쓰지 않아도 된다. 단점으로는 위 작업이 필요없는 유저에게는 불필요한 설치과정이되어 불필요한 리소스나 시간을 잡아먹게된다. 위에 있는 기본 Cookbook은 여기에서 확인 할 수 있다.

차이점2. Monitoring - Ganglia

 Chef11에만 있는 기능이 Monitoring을 위해 Ganglia를 설치해주는 것이다. 위에 기본 Cookbook 중 opsworks_ganglia::client를 살펴보면 node[:opsworks][:layers].has_key?('monitoring-master') 라는 구문으로 monitoring-master 레이어를 찾는 것을 볼 수 있다. 유저가 monitoring-master라는 이름으로 레이어를 만들면 Chef11은 기본적으로 metric을 수집하는 레이어로 인식한다. 그 후 모든 instance에서 그 metric을 수집하게된다. opsworks_ganglia::configure-client를 보면 monitoring-master를 ganglia서버로 gmond 설정하는 것을 볼 수 있다. 이렇게 모아진 metric은 쉽게 graphite, grafana 등과 연동 될 수 있다.

차이점3. Node Attribute

 Chef11과 Chef12의 Node attribute 보관법이 완전 달라졌다. 기본적으로 Opsworks 실행 정보는 Stack, Layer, Instance, App, SSH Key 등이 있다. Chef11은 이 모든 정보를 node attribute에 담아서 chef-client를 실행했다. 그러나 Chef12는 이 정보를 data_bag에 담고 있다. 개인적으로 이 부분에 있어서는 두 버전의 장단점을 논하는것은 무의미하고 Chef12가 압도적으로 좋다고본다.

1) Chef11의 Node Attribute

custom json을 설정하지 않아도 기본으로 설정되는 json 값이 stack의 모든 정보로 복잡하고 많다. 만약에 실행 중인 instance의 layer정보를 알고 싶으면 아래와 같이 찾아야한다. (instance와 layer가 1:1로 설정되어 있다고 가정한다.)

instance = node[:opsworks][:instance]
layer_name = instance[:layers].first
layer = node[:opsworks][:layers][layer_name]

이 정보는 Opsworks에서 command를 실행 할 때 생성되는데, 불필요한 정보가 한꺼번에 node attribute에 포함되어있어 한 눈에 들어오지 않는다. 그리고 유저가 사용하고 싶은 attribute key name이 이미 Opsworks에서 사용 중이면 사용 할 수 없다. 

 그리고 무엇보다 가장 큰 단점은 stack의 모든 정보를 node attribute json에 담고 있기 때문에 chef-client를 사용 할 때 메모리를 어마어마하게 많이 쓴다는 것이다. 실제로 한 Stack에서 임의로 Instance 80개와 App 40개를 설정하고 테스트를 해봤을 때, custom cookbook이 아무 것도 없는데도 메모리를 2.5GB까지 쓰는 것을 확일 할 수 있다. node attribute 사이즈가 커지면 커질 수록 chef-client를 실행 할 때 필요한 메모리가 늘어난다는 것인데, 이는 불필요하게 instance type을 올려야하는 치명적인 단점이 된다. AWS Support에 문의해본 결과 이를 수정 할 생각은 없는 것 같다.

2) Chef12의 Data bag

 Chef12에서는 data_bag을 적극적으로 활용한다. 실제로 AWS Opsworks에서 사용하는 data_bag은 여기에서 확인 할 수 있다. Chef11에서처럼 실행 중인 instance의 layer정보를 찾아보자.

instance = search('aws_opsworks_instance', "hostname:#{node[:hostname]}").first
layer_id = instance[:layer_ids].first
layer = search('aws_opsworks_layer', "layer_id:#{layer_id}").first

 사실상 코드는 그렇게 큰 차이가 없다. 위에서도 말했듯이 메모리 사용량에 큰 차이가있어 Chef12를 권장한다. Chef12에서는 아무리 많은 App이나 Instance가 있더라도 t1.micro에서도 Opsworks command가 성공적으로 실행되는 것을 볼 수 있다.