1. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
조성열
클라우드 지원 엔지니어, 아마존 웹서비스 시드니 기술지원센터
AWS Support에서 제안하는
멋진 클라우드 아키텍처 디자인

2. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
장애를 예방하기 위해 아키텍쳐 설계 시 알아둬야 할 것들
주요 장애별 대응 방법
AWS Support
Q&A

3. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
장애를 예방하기 위해
아키텍쳐 설계 시 알아둬야 할 것들

4. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Limit

5. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Service Limits
• AWS 서비스들은 계정별/리전별 Limit이 존재
• Limit 도달 시 추가 리소스 프로비저닝 불가
• Limit 증가에 최소 1영업일 이상 소요되므로
사전에 Limit 증가 요청하는 것을 권장
EC2
인스턴스 대수
EBS
용량
CodeDeploy
동시 배포 갯수
Lambda
동시 실행 갯수

6. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
API Limit
• AWS의 모든 기능은 API로 제공되어 사용자가 API를
이용하여 리소스 관리/모니터링할 수 있음
• 각 API별 Request Rate Limit이 존재하여 많은 API
호출이 동시에 일어날 경우 호출에 실패할 수 있음
• 예방할 수 있는 방법
• Polling
• Retires or batch processing
• Calculating the sleep interval

7. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
제품 별 고려사항

8. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
EC2
• 단 한대의 인스턴스를 사용하더라도 Auto Recovery 설정
혹은 Auto Scaling Group을 통하여 장애 발생 시
자동으로 인스턴스가 교체되게 설정
Auto Scaling group
Auto Recovery

9. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
EC2
• Multi AZ 구현으로 AZ Failure 발생 시 장애 방지
Availability Zone Availability Zone Availability Zone

10. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
S3
• 워크로드가 S3에 초당 100개 이상의 요청을 할 것으로
예상될 경우 순차적 키 이름 대신 임의성을 가진 키를
사용해야 함
순차적 키 적용
examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg
examplebucket/2013-26-05-15-00-00/cust3857422/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust1248473/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust8474937/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust1248473/photo3.jpg
...
examplebucket/2013-26-05-15-00-01/cust1248473/photo4.jpg
examplebucket/2013-26-05-15-00-01/cust1248473/photo5.jpg
examplebucket/2013-26-05-15-00-01/cust1248473/photo6.jpg
examplebucket/2013-26-05-15-00-01/cust1248473/photo7.jpg
...
16진수 해시 키 적용
examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg
examplebucket/7b54-2013-26-05-15-00-00/cust3857422/photo2.jpg
examplebucket/921c-2013-26-05-15-00-00/cust1248473/photo2.jpg
examplebucket/ba65-2013-26-05-15-00-00/cust8474937/photo2.jpg
examplebucket/8761-2013-26-05-15-00-00/cust1248473/photo3.jpg
examplebucket/2e4f-2013-26-05-15-00-01/cust1248473/photo4.jpg
examplebucket/9810-2013-26-05-15-00-01/cust1248473/photo5.jpg
examplebucket/7e34-2013-26-05-15-00-01/cust1248473/photo6.jpg
examplebucket/c34a-2013-26-05-15-00-01/cust1248473/photo7.jpg
...

11. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
CloudFormation
• 한 스택에 특정 종류의 리소스가 많을 경우 API 호출이
과다하게 일어나 리소스 생성 실패 가능
• DynamoDB Table 동시 생성 개수 제한
• EC2 인스턴스 수십 대 동시 생성
• DependsOn 속성을 사용하여 리소스 생성 순서를
정해주면 장애 방지 가능
200 OK
503 RequestLimitExceeded

12. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Elastic Beanstalk
• Elastic Beanstalk Health Check는 장애 발생 시 Elastic
Beanstalk 환경 상태를 바꾸어 사용자에게 경고하지만
WAS 재시작/인스턴스 교체 등의 복구는 하지 않음
• Elastic Beanstalk 환경의 Auto Scaling Group Health
Check를 EC2에서 ELB로 변경하여 ELB Health Check 실패
시 인스턴스를 교체하도록 설정하면 장애 발생 시 자동
복구 가능

13. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
OpsWorks
• OpsWorks는 Auto Healing 기능을 통해 5분 이상
인스턴스가 OpsWorks Endpoint와 통신에 실패할 경우
인스턴스를 Stop 후 Start 함
• 따라서 Auto Healing이 Disable된 Layer에 인스턴스들을
배치할 경우 NAT Instance에 장애 발생 시 Private
Subnet에 위치한 인스턴스들이 단체로 재부팅 되는
현상을 막을 수 있음

14. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
모니터링

15. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Personal Health Dashboard
• Personal Health Dashboard를 통해
시스템에 영향을 미칠 수 있는 이벤트가
발생하거나 발생할 예정일 경우 알림과
수정 지침을 제공받을 수 있음
• Open Issues, Scheduled Changes, Other Notification
• SNS 등의 제품들과 연동을 통해 정보들을 실시간으로
받아볼 수 있음

16. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
주요 장애별 대응 방법

17. 중점적으로 다룰 서비스
Amazon
Elastic
Compute
Cloud (EC2)
Auto Scaling Classic
Load
Balancer
(ELB)

18. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Amazon EC2

19. EC2 사용시 만날 수 있는 운영 이슈
• 유형 1: 상태 확인 이슈
• 유형 2: 인스턴스 자동 재시작
• 유형 3: 인스턴스 생성 이슈

20. 유형 1: 상태 확인 이슈
• EC2 상태 확인 유형
물리적 호스트
EC2 EC2 EC2 EC2 시스템 상태 확인
인스턴스 상태 확인

21. 유형 1: 상태 확인 이슈
• 시스템 상태 확인 이슈 원인
• 네트워크 연결 끊김 / 시스템 전원 중단
• 물리적 호스트의 소프트웨어 문제
• 물리적 호스트의 하드웨어 문제로 인한
네트워크 접속 문제
• 인스턴스 상태 확인 이슈 원인
• 시스템 상태 확인 실패
• 잘못된 네트워킹 또는 스타트업 구성
• 메모리가 모두 사용됨
• 파일 시스템 손상, 호환되지 않는 커널
(System)

22. 유형 1: 시스템 상태 확인 이슈 시 해결방법
• 인스턴스 재시작 (인스턴스 스토어 데이터 손실)
• AMI를 통한 인스턴스 재생성
• CloudWatch Alarm을 통한 자동 복구

23. • 인스턴스 재시작 (인스턴스 스토어 데이터 손실)
• 인스턴스 리부팅
• 대부분은 운영체제 단에서 문제 발생
유형 1: 인스턴스 상태 확인 이슈 시 해결방법
2. 다른 인스턴스에 데이터 볼륨으로 연결 후
설정 파라미터 변경
• Linux: 커널 파라미터 파일 수정
• Windows: EC2Rescue를 이용한 수정
1. 루트 볼륨을 인스턴스에서 분리
3. 루트 볼륨 인스턴스에 연결

24. 유형 2: 인스턴스 자동 재시작 발생 시
• 예정된 이벤트가 있었는지 확인
• EC2의 Events, Personal Health Dashboard에서 이벤트 확인
• 인스턴스 로그 확인
• 예: syslog, dmesg, Windows event logs
• CloudTrail을 통해서 확인

25. running
Stop
• 인스턴스 생명 주기
유형 3: 인스턴스 생성 이슈
shutting-down
stopping
pending
stopped terminated
Launch
Start
Terminate

26. • 인스턴스가 생성 즉시 바로 종료된다면?
유형 3: 인스턴스 생성 이슈
shutting-downpending
Launch Terminate

27. 유형 3: 인스턴스 생성 이슈
• 인스턴스가 생성 즉시 종료가 되는 경우
• EBS 볼륨 Limit을 초과한 경우: Support Center를 통해 EBS
limit을 증가 요청
• 고객 AMI 이미지가 잘못 생성 되었을 경우: 이미지를 재생성
• 인스턴스가 종료된 원인을 알 수 있는 방법
• EC2 콘솔 상에서 확인
State transition reason Client.UserInitiatedShutdown: User initiated shutdown
State transition reason Client.VolumeLimitExceeded: Volume limit exceeded
• CLI를 통해서 확인:
$ aws ec2 describe-instances --instance-id instance_id
--query 'Reservations[0].Instances[0].StateReason.Message'

28. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Auto Scaling

29. Auto Scaling에서 만날 수 있는 운영 이슈
Scale In/Out
Auto Scaling group
CloudWatch 알람 설정
Auto Scaling group
신규 인스턴스 생성
Auto Scaling group

30. 유형 1: 신규 인스턴스 생성 이슈
• 원인 1. Launch Configure 설정
• Security Group
• EC2 Key Pair
• 해결책
• 새 Launch Configuration 생성
• Auto Scaling Group이 새
Launch Configuration을
이용하도록 변경
Auto Scaling group
New Launch Configuration

31. 유형 1: 신규 인스턴스 생성 이슈
• 원인 2. 각종 Limit 도달
• Instance
• EBS Volume
• Network Interfaces
Auto Scaling group
0
10
20
Limit

32. 유형 1: 신규 인스턴스 생성 이슈
• 원인 2. 각종 Limit 도달
• Instance
• EBS Volume
• Network Interfaces
• 해결책
• Support Center에
Limit Increase 요청
Auto Scaling group
0
10
20
Limit

33. 유형 1: 신규 인스턴스 생성 이슈

34. 유형 2: Scale In/Out 이슈
• 원인 1. Auto Scaling Group이 Suspended 되었을 경우
• 해결책 : Suspended Processes를 제거하여 다시 시작
Auto Scaling group
SUSPENDED

35. 유형 2: Scale In/Out 이슈
• 원인 2. 마지막 Scaling Event로부터 Cooldown 시간이
지나지 않았을 경우
• 해결책 : Cooldown Time이 길지 않은지 확인 후 조정
Auto Scaling group

36. 유형 2: Scale In/Out 이슈
• 원인 3. Lifecycle Hooks를 설정 하였으나, Auto
Scaling에 신호를 보내지 않을 경우
• 해결책 : Complete-lifecycle-action이 제대로 수행
되었는지 확인
$ aws autoscaling complete-lifecycle-action
--lifecycle-hook-name my-lifecycle-hook
--auto-scaling-group-name my-asg
--lifecycle-action-result CONTINUE
--lifecycle-action-token
bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635

37. 유형 2: Scale In/Out 이슈
• 원인 4. Instance Limit에 도달했을 경우
• 해결책
• 필요 없는 인스턴스를 정지
• Support Center에 Limit Increase 요청

38. 유형 3: CloudWatch Alarm 설정
• CloudWatch Alarm은 Consecutive Period 설정 값만큼
연속으로 Threshold를 넘어서야 Alarm이 울림
0
20
40
60
80
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU Utilization (Consecutive Periods : 3)
Value
Threshold
최근 3번의 데이터 모두
Threshold를 넘어서 Alarm 작동

39. 0
20
40
60
80
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU Utilization (Consecutive Periods : 3)
Value
Threshold
유형 3: CloudWatch Alarm 설정
• CloudWatch Alarm은 Consecutive Period 설정 값만큼
연속으로 Threshold를 넘어서야 Alarm이 울림
최근 3번의 데이터가 높은 수치를 기록 하였지만
10번 데이터가 Threshold를 만족하지 못하여 Alarm 미작동

40. 0
20
40
60
80
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU Utilization (Consecutive Periods : 3)
Value
Threshold
유형 3: CloudWatch Alarm 설정
• CloudWatch Alarm은 Consecutive Period 설정 값만큼
연속으로 Threshold를 넘어서야 Alarm이 울림
최근 3번의 데이터 모두
Threshold를 넘어서 Alarm 작동

41. 0
20
40
60
80
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU Utilization (Consecutive Periods : 3)
Value
Threshold
유형 3: CloudWatch Alarm 설정
• CloudWatch Alarm은 Consecutive Period 설정 값만큼
연속으로 Threshold를 넘어서야 Alarm이 울림
• 해결책 : Threshold를 조정
Threshold를 60에서 55로 변경 후 11번 째 데이터 지점에서 Alarm이 일찍 울림

42. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Classic Load Balancer

43. ELB에서 만날 수 있는 운영 이슈
HTTP 5xx errors Instance Out of Service Health Check Failure
HTTP 502
HTTP 503
HTTP 504
Instance
Out of Service

44. HTTP 502
Bad Gateway
HTTP 504
Gateway Timeout
HTTP 503
Service Unavailable
유형 1: HTTP 5xx errors
Header: @(!*#*^%*$@^&(
or

45. 유형 1-1: HTTP 502 Bad Gateway
• 원인. 백엔드 인스턴스로부터 온 응답을 ELB가 받지 못할
경우 발생
• 해결책
• 인스턴스의 WAS 로그를 참조하여 응답이 제대로 갔는지 확인
• 응답이 정상이었음에도 불구하고 이슈 발생 시
Support Center에 케이스 오픈
Header: @(!*#*^%*$@^&(

46. 유형 1-2: HTTP 503 Service Unavailable
• 원인 1. 인스턴스가 한 대도 등록되어 있지 않을 경우
• 해결책
• 인스턴스 등록
No instance

47. 유형 1-2: HTTP 503 Service Unavailable
• 원인 2. 모든 인스턴스가 Unhealthy 상태일 경우
• 해결책
• Health Check 점검으로 Healthy 인스턴스를 만들어 해결
• Security Group 등 VPC 설정을 점검하여 인스턴스가 ELB와
통신 가능한 상태인지 점검
All Instances are unhealthy.

48. 유형 1-2: HTTP 503 Service Unavailable
• 원인 3. 짧은 시간에 Request가 급격하게 들어오는 경우
• 해결책
• 예상된 피크 트래픽일 경우 Pre-warming 신청
• 일시적으로 ELB의 Scaling 시간이 부족하여 발생할 수 있으며
이 경우 수 분 이내로 해결됨
• 이슈가 지속될 경우 Support Center에 케이스 오픈

49. 유형 1-3: HTTP 504 Gateway Timeout
• 원인 1. 인스턴스의 요청 처리 시간 > ELB Timeout 시
HTTPCode_ELB_5XX 및 Latency metrics 동시 증가
• 해결책
• 인스턴스 CPU Utilization이 높을 경우 새 인스턴스 추가
• 프로그램이 데이터베이스나 외부 API 등 외부에
Dependency가 있을 경우 해당 Dependency 점검
2017-04-20 00:00:00
2017-04-20 00:01:01
Timeout:60s

50. 유형 1-3: HTTP 504 Gateway Timeout
• 원인 2. 인스턴스가 ELB 요청을 닫을 경우 발생
• 해결책
• 백엔드 서버의 Keep-alive를 활성화
• 백엔드 서버의 Keep-alive Timeout을 ELB Timeout보다 높게 설정

51. 유형 2: Instance Out of Service
• 원인 1. Instance is in stopped state
• 해결책
• 인스턴스 시작
Instance is in stopped state.

52. 유형 2: Instance Out of Service
• 원인 2. Instance registration is still in progress
• 해결책
• 인스턴스가 최근에 추가되었을 경우 등록 진행 중이며
짧은 시간 이내로 자동으로 해결
• 이슈가 지속될 경우 Support Center에 케이스 오픈
Instance registration is still in
progress

53. 유형 2: Instance Out of Service
• 원인 3. Instance has failed at least the Unhealthy
Threshold number of health checks consecutively
• 해결책
• Health Check 이슈 해결 방법과 동일하게 해결
Instance has failed at least the
Unhealthy Threshold number of
health checks consecutively.

54. 유형 3: Health Check 이슈
• 원인 1. Health Check Target Page가 200 이외의 코드를
반환할 경우
• 해결책
• ELB는 Health Check Target Page가 non-200 코드를 반환 시
인스턴스를 Unhealthy 처리. 특히 HTTP 302 (Redirect)를
반환하여 Health Check 이슈가 자주 일어남
• Health Check Target이 HTTP 200 코드를 반환하도록 수정
Header: HTTP 302 Redirect

55. 유형 3: Health Check 이슈
• 원인 2. Health Check Timeout
• 해결책
• 백엔드 서버의 Keep-alive를 활성화
• 백엔드 서버의 Keep-alive Timeout을 ELB Timeout보다 높게 설정
• Health Check 페이지의 외부 Dependency (DB 등) 점검
2017-04-20 00:00:00
2017-04-20 00:00:21
Health Check
Timeout:20s

56. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
AWS Support

57. AWS Support
• 전 세계의 AWS Support 직원들이 24x7x365 지원
• 한국어 가능 엔지니어들을 통해 제한적인 한국어 지원
• 4개의 Support Plan 지원
• Basic
• Developer
• Business
• Enterprise
• 한국어 지원 포럼

58. Support Plan
Basic Developer Business Enterprise
고객 서비스 및
커뮤니티
고객 서비스, 설명서, 백서 및 지원 포럼에 연중무휴 24시간 액세스
모범 사례 4개 핵심 Trusted Advisor 검사에 접근 전체 세트 Trusted Advisor 검사에 접근
기술 지원 업무 시간 내
이메일 연락
연중무휴 24시간
이메일, 채팅 및 전화로 연락
연중무휴 24시간
선임 클라우드 엔지니어에게
이메일, 채팅 및 전화로 연락
사례 심각도/
응답 시간*
일반 지침: <24업무 시간**
시스템 손상: <12업무 시간**
일반 지침: <24시간
시스템 손상: <12시간
프로덕션 시스템 손상: <4시간
프로덕션 시스템 중단: <1시간
일반 지침: <24시간
시스템 손상: <12시간
프로덕션 시스템 손상: <4시간
프로덕션 시스템 중단: <1시간
비즈니스 크리티컬 시스템 중단:
<15분
아키텍쳐 지원 일반 지침 사용 사례에 따라 컨텍스트
기반 지침
애플리케이션에 따라 컨설팅
형태의 검토 및 지침
인프라 이벤트 관리 추가 이용료 지불 후 지원 포함
사전 지침 전담 기술 지원 담당자
*AWS에서는 해당하는 시간 이내에 초기 요청에 응답하기 위해 최선을 다하고 있습니다.
**업무 시간은 내 계정 콘솔에 설정된 바와 같이 일반적으로 고객 국가 기준으로 휴일과 주말을 제외한 오전 8시부터 오후 6시까지로 정의됩니다. 여러 시간대를 가진 국가에서는 이 시간이 달라질 수 있습니다.

59. 한국어 케이스 올리는 방법

60. 한국어 케이스 올리는 방법

61. 한국어 케이스 올리는 방법

62. 한국어 케이스 올리는 방법

63. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
AWS Summit 모바일 앱과 QR코드를
통해 강연 평가 및 설문 조사에 참여해
주시기 바랍니다.
내년 Summit을 만들 여러분의 소중한
의견 부탁 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의 행사
소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로
공유될 예정입니다.
여러분의 피드백을 기다립니다!

64. 감사합니다