어제 서버 장애로 인한 대책으로 오토스케일링 구성하여 내용 공유합니다. 도움이…

어제 서버 장애로 인한 대책으로 오토스케일링 구성하여 내용 공유합니다.
도움이 될지 모르겠으나 참고하세요.

저희가 사용하는 인스턴스는 m3.medium 3개씩 두개의 존에 할당해서 elb로 묶어서 서비스 하고 있었습니다.
트래픽이 평소보다 많으면 웹서버의 아파치가 먹통이 되면서 elb에서 제외됩니다.
알림을 받고 아파치를 바로 재실행하면 문제 없이 다시 elb로 정상 서비스됩니다.
하지만 어쩔 수 없는 상황에서는 바로 처리하지 못하면 인스턴스가 하나씩 먹통이 되면서 최악의 경우는 6대의 모든 웹서버가 죽는 상황이 되었습니다.
어제가 그런 상황이었구요.

오토스케일링이란걸 알고는 있었지만 구성상 적용이 좀 어렵다고 생각했습니다.
그래서 적용을 안하고 있었는데 서비스가 더 커지기 전에 대책이 필요해서 어제 장애 이후에 오토스케일링 설정하고 이것 저것 테스트 하면서 사용법을 익혔습니다.

aws의 최대 장점은 마음대로 구성 추가 삭제가 가능하여 테스트가 무척 자유롭다는 것이겠죠~^^
여러번의 테스트로 기본 사용법 익히고 오늘 부터 실서비스에 적용해서 모니터링 했는데 문제 없이 정상적으로 잘 돌아가는 것을 보니 왜 진작 적용 안했는지 후회가 될 정도네요.

오토스케일링을 적용 못했던 이유는 기존 인스턴스를 이미지 생성해서 새로 인스턴스를 생성하면 바로 사용을 못하는 구성이었습니다.
인스턴스 생성 후 추가적인 설정 작업이 필요했습니다.(이 부분도 자동화를 하면 가능한데 방법을 모름)
그래서 어제 고민해서 생각한 방법이 추가 설정을 모두 완료하고 오토스케일링에 문제되는 부분을 수정해서 이미지를 생성했고 그것을 기반으로 Launch Configurations를 생성했습니다.
즉 자동으로 인스턴스가 생성되어 로드밸런스에 바로 붙더라도 정상적인 서비스가 가능하도록 별도 이미지를 생성한거죠.

오토스케일링 설정은 최대 6, 최소 0으로 해서 elb에 기본으로 인스턴스 6개가 항상 유지되도록 했습니다.
일부러 웹서버 몇대 죽이면 바로바로 자동으로 인스턴스 생성되어 elb에 추가되고 6개가 넘으면 자동으로 생성된 인스턴스를 순차적으로 삭제하도록 설정했습니다.
스케일링 정책에는 elb High-Unhealthy-Host, High-Healthy-Hosts 알림을 사용하였습니다.
즉 1분동안 UnHealthy-HostCount >= 3 상황이 되면 알림을 받고 인스턴스가 추가되고 HealthyHostCount >= 4 상황이 되면 인스턴스를 제거합니다.

aws는 쓰면쓸수록 매력적인것 같아요.
물론 모두가 장점은 아니겠지만 aws가 주는 장점을 생각하면 aws를 안쓰는게 이상할 정도에요.
관리콘솔만 봐도 1년전과 비교해보면 정말 빠르게 발전하는게 눈으로 보입니다.
그 혜택을 서비스에 바로 적용할 수도 있구요.

5 thoughts on “어제 서버 장애로 인한 대책으로 오토스케일링 구성하여 내용 공유합니다. 도움이…

  1. Hojoon Cho 저도 처음에 배울때는 아무것도 몰라 뭔가 좀 볼 수 있는게 없어서 고생을 좀 했는데 하나씩 알아가는 재미가 무척 쏠쏠해요.신세계를 발견한것 같은~^^

Comments are closed.