DevOps를 위한 AWS Opsworks에 대해서.

일단 제가 가진 이력을 잠깐 설명을 해야 하는데, 저는 일본에서 8년정도 소프트웨어 관련 일을 했습니다. 개발도 하고, 입으로 사기치는 컨설턴트 같은 일도 하고, 다시 개발도 하고.... 일본만의 특수한 경우인지는 모르겠지만, 서버관련 직종(인프라)과 소프트웨어 개발 관련 직중이 명확하게 나뉘어져 있는데 저는 소프트웨어 개발 관련이라, 서버는 거의 다루어 본적이 없습니다.(이상 자기 소개끝)

그런 제가 최근에 서비스를 하나 개발했습니다. 일반적인 Ruby On Rails로 만든 서비스입니다. 아무런 생각없이 서버는 AWS로 해야지.. 했었는데 웬걸, 막상하려니 대체 어디부터 손을 대야 할지 난감했었어요. 우선,

EC2 인스턴스를 만들어서 인스턴스안에 서버 깔고, 레일즈 깔고, 깃 깔고, 깔고 깔고, 연결하고...

이건 당연히 나보다 머리 좋은 사람들이 뭔가를 해놓았을 것이다...

라는 귀차니즘에서 오는 추측으로 찾던 중 제 일을 도와주던 동료로 부터 Opsworks에 대해서 듣게 되었고 바로 이거다 라는 생각에 바로 구축하게 되었습니다. 그 경험을 공유했으면 합니다.

1. DevOps

소프트웨어 회사가 어느정도 규모가 있으면, 개발팀, 그리고 운용팀으로 나뉘어 집니다. 저 역시 그런 환경에 있었던지라 운용은 그냥 따분한 일..정도로만 생각하고 있었습니다. 그런데 이게 1인개발 혹은 소규모개발이 되면 바로 내 일이 되게 되는데....

1. 개발
2. 소스 푸쉬
3. 서버 접속
4. 소스 다운로드
5. 빌드
6. 올리기
7. 제대로 동작하는지 확인하기
8. 다시 개발
9. 제대로 동작하는줄 알았는데 뭔가 이상이 있음이 발견됨
10. 그걸 고침

Welcome to the chaos

하루에 디플로이를 몇번씩이나 해야 하는 상황이 되면 너무 불편하고 무엇보다 서비스의 품질을 보장할 수가 없게 됩니다. 이 상황을 탈피하기 위한 개발 방법으로 제안된 것이 DevOps입니다. 대충 설명드렸는데 조금 다를지도 모르니 검색해 보심을 추천합니다;;

2. AWS에서의 DevOps

DevOps가 뭔지는 알았다. 자 그럼 이제 방법을 보여주시오.. 가 되겠는데, 여러가지 방법이 있다고 합니다.(아주 명쾌한 대답이네요.) 클라우드 컴퓨팅의 선두주자인 AWS에서도 몇가지 방법을 제공하고 있습니다.

• Elastic Beanstalk
• Deploy
• provision
• monitor
• Simple
• Opsworks
• Elastic Beanstalk와 기능은 같으나 Chef를 통해서 좀 더 세밀한 설정이 가능
• CodeDeploy
• Only Deploy
• CluodFormation
• Only provision(연계만 해줌,,)

흠, 이중에서 저는 Opsworks를 선택해서 구축했습니다. 고로 다른 것들은 잘 모릅니다...

3. Opsworks의 특징

• 하나의 단위를 Stack이라고 한다
• Stack안에 Layer라는 기능 단위가 존재한다. (레이어의 예: ELB, App Server, RDB)
• EC2 Instance를 늘리거나 줄일 수 있다.
• GitHub의 레포지토리로부터 Deploy를 할 수 있다.
• RollBack기능이 있다..
• 각 레이어간의 연결은 콘솔에서 설정이 가능하다. 예를들어 RDB와App의 연결은 콘솔에서 하므로, 소스를 손댈 필요가 없다. 같은 방법으로 Redis와의 연결도 Chef custom recipe를 통해 가능하다.

이 것 이외에도 기능이 있지만, 제가 써 본 기능은 이것들 입니다.

4. Opsworks의 실제

Opsworks그 자체에 대해서는 검색하면 여러가지 정보가 나오니, 설정하는 방법이라든지, 시작하는 법이라든지 하는 방법은 생략하도록 하겠습니다. 실제로 제가 어떻게 쓰는지를 설명함으로써 이걸 가지고 무얼 할 수 있는지 대충 감을 잡으셨으면 하네요.

• 개발환경, Production환경을 따로 Stack을 만든다.
• 개발환경은 Github repository의 master branch를 참조하고, Production환경은 production branch를 참조한다.
• master로 소스를 개발해 개발환경으로 디플로이한 다음 문제가 없으면 production브랜치에 머지 해서 Production환경을 업데이트 한다.
• 서버 설정
• 서버 설정에 있어 기본적인건 Opsworks에서 제공해준다. 예를 들어 nginx와 유니콘의 인스톨이라든지, Rails그 자체의 인스톨이라든지,
• 그 외의 설정은 Custom Recipe 를 통해서 할 수 있다. Recipe는 Chef 문법에 맞춰서 기술한다. 저도 여기에 빠삭한건 아닙니다. 필요한 설정을 검색해서 붙여 쓰는 정도 입니다.
• 예를 들어, BasicAuth, 서버의 시간대 설정 등등..
• infrastructure as code 라는 개념인데, 이것으로 인해서 서버가 항상 깨끗한 상태로 유지된다. 이게 뭔 소린가 하면, 서버에 이것저것 인스톨하고 버전도 제각각이고 한 상태가 되면 서버가 박살나거나 해서 재구축이 필요하게 되었을때 "박살나기 전 상황과 똑같은" 상태로 만드는 게 애매하게 되는데, 이것을 미연에 방지하고, 서버를 늘릴때도 손쉽게 똑같은 서버를 늘릴 수가 있다.
• 디플로이
• AWS콘솔 상에서 디플로이 버튼을 클릭함으로써 디플로이를 할 수 있다. 좀 더 스마트한 방법은 아래에서 소개.

SSH로 서버에 들어갈 필요조차 없습니다 여러분!

5. 조금 더 스마트한 방법

아래 같은 시나리오를 생각했다.

1. Github에 푸쉬
2. 테스트 코드 실행
3. 테스트 코드가 OK면 디플로이 실행
4. 실행 결과를 통지

이걸 가능하게 해주는 서비스가 있는데, werker라는 서비스다. 이 서비스는 GithubRepository(branch)에 푸쉬가 오면 기술된 동작을 실행하고(Rspec등등) 문제가 없으면 Opsworks에 Kick을 해줌으로 해서 위의 시나리오대로 동작을 시켜준다. 실행 결과는 Slack의 Incoming WebHooks로 받을 수 있다.

좀 더 자세하게 쓰면 좋았겠지만, 요즘 세상은 Theory만 알면 검색하면 다 나오는 세상이니 생략했습니다.(사실 좀 귀찮은 것도 있었지만요;;) 대신에 질문 주시면 성심성의껏 대답해 드리겠습니다. 그럼 좋은 하루 되세요.