안녕하세요. 이제 막 발을 디딘 개발자인데요. 몇가지 궁금한게 생겨 이렇게…

안녕하세요. 이제 막 발을 디딘 개발자인데요.
몇가지 궁금한게 생겨 이렇게 질문을 드립니다.

첫째, ami를 이용해 ec2를 다량 생성(autoscailing) 후, 업데이트를 위해 ec2를 수정(파일 교체, 추가 등)해야 할 시 기존 ec2들의 내용을 한번에 바꾸는 방법이 있을까요?

둘째, 가성비가 좋은 ec2 마이그레이션 순서를 알려주시면 감사하겠습니다. 게임은 간단한 캐쥬얼 게임이라 데이터 통신이 잦지 않습니다.

5 thoughts on “안녕하세요. 이제 막 발을 디딘 개발자인데요. 몇가지 궁금한게 생겨 이렇게…

  1. 첫번째 같은 경우 자주 해야 된다면 처음부터 chef를 이용해서 꾸미시면 어떨까 싶구요…

    수작업으로 한다면 AWS CLI를 이용한 스크립트를 만들던지, GIT을 이용해서 각서버에서 업데이트 하는 방식으로 한다거나, NFS나 rsync를 이용하는 방법도 생각 해보실수 있을꺼구요…

    자주할께 아니고 바뀐 내용이 크다면 기존 서버를 업데이트하는것 보다 새로운 업데이트 된 서버로 런치컨피규레이션을 만들고, 오토스케일에 셋팅하고, 기존 서버 하나씩 죽이면 새로운 서버가 뜰테고 잘동작하는지 보면서 교체를 할것 같습니다… 기존서버가 1시간 못채우고 죽으니 비용은 쪼끔 더 나가는 셈이죠…

  2. 첫번째 문제로 저도 고민했었는데요. 제가 사용한 트릭은 이렇습니다. ec2를 수정한 후 ami를 새로 생성하고 새 ami를 사용하는 launch configuration도 새로 만듭니다. 그리고 auto scaling 설정에서 새로 만든 launch configuration을 사용하게 하고요. 그리고 desired capacity를 현재 떠 있는 instance 수의 2배로 설정합니다. 이렇게 하면 기존 ami 로 떠 있는 instance와 새 ami 로 떠 있는 instance 수가 같아질 것이고요. 시간이 지나면서 정해놓은 policy에 따라 instance 수가 감소하면서 기존 ami로 만들어진 instance가 terminate 되게 했습니다. 참고로 termination policies에 첫번째로 OldestLaunchConfiguration 을 지정해두어서 이렇게 동작하게 했습니다.

  3. 한방에 모두 안전하게 바꾸실려면 김호승님 방법이 좋은 것 같습니다. 말씀하신대로 termination policies 첫번째를 OldestLaunchConfiguration으로 지정하는게 중요하겠네요. 그래도 한두개 먼저 테스트 해보시고 바꾸시는걸 추천 드립니다. 새 ami가 문제 있으면 대량 낭패 ㅋ

  4. 저는 위 방법으로 하다가 종종 의도치 않은 초기화 도중 termination과, 웹 서버의 특성상 동일 페이지에서 엘리먼트별로 다른 인스턴스로 접근 하기도 하는 문제 때문에 새로운 방식을 생각중입니다.
    현재 autoscaling group의 instance 두배수로 새 instance 띄운 후 -> ELB에 붙으면 -> 예전 instance를 바로 떼어내는 방식으로 패치 스크립트를 만들 계획을 하고 있습니다.
    바빠서 스크립트 작성을 자꾸 미루고 있는데 현재는 패치 직전에 instance를 1개만 남도록 한 후 새 instance 1개를 띄우고 교체 -> 이후 새 설정으로 인스턴스를 더 올리는 식으로 진행하고 있네요. 스크립트는 python + boto 사용하고 있어요.

Comments are closed.