일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 백준
- 위상정렬
- 포트앤어댑터 아키텍처
- DP
- java
- springboot
- pandas
- UML
- 헥사고날 아키텍처
- BFS
- docker
- 비트마스크
- 다익스트라
- equals
- Redis
- 알고리즘
- spring security
- 자바
- series
- 데이터 flow
- 파이썬
- 스프링
- 세그먼트 트리
- disjoint set
- 문자열
- ddd
- dfs
- JPA
- dataframe
- 이펙티브 자바
- Today
- Total
코딩못하는사람
Nginx 헬스 체크 본문
1.문제점
제작한 웹서비스의 반응시간이 엄청나게 길어지는 문제가 발생했다.
고가용성(High Availability)를 지키지 못한 예이다.
2.접근
반응시간이 길어지지만 결국에는 정상 API를 수행하는점을 바탕으로 로드밸런싱 과정에서 일어난 문제라고 추측하였다.
3.원인
로드밸런싱 해 놓은 서버를 가지고 있는 EC2가 서비스 기간이 만료되어 서버가 죽었던 것을 까먹고 있었다.
그에 따라서 라운드 로빈 방식으로 다운된 서버에 계속 부하를 보낸 후 default 설정만큼 대기하고 살아있는 서버에서 작업을 해온 것이다.
(default 설정은 max_fails=1,fail_timeout=10이다.)
옵션
- ip_hash : 같은 방문자로부터 도착한 요청은 항상 같은 업스트림 서버가 처리 할 수 있게 한다.
- weight=n : 업스트림 서버의 비중을 나타낸다. 이 값을 2로 설정하면 그렇지 않은 서버에 비해 두배 더 자주 선택된다.
- max_fails=n : n으로 지정한 횟수만큼 실패가 일어나면 서버가 죽은 것으로 간주한다.
- fail_timeout=n : max_fails가 지정된 상태에서 이 값이 설정만큼 서버가 응답하지 않으면 죽은 것으로 간주한다.
- down : 해당 서버를 사용하지 않게 지정한다. ip_hash; 지시어가 설정된 상태에서만 유효하다.
- backup : 모든 서버가 동작하지 않을 때 backup으로 표시된 서버가 사용되고 그 전까지는 사용되지 않는다.
4.해결방법
내가 처한 상황에서는 클라우드를 다시 구입하거나 죽은 서버에 밸런싱하지 않는 간단한 해결법이 두가지 있다(일단 후자를 선택했다).
하지만 생각해보면 서버의 상태를 실시간으로 점검해서 정상 서버에게만 트래픽을 분배해주는 방법인 Health check를 고려할 수 있다. 고가용성을 지키기 위해서는 SPOF(Single Point Of Failure, 단일 실패 지점)을 시스템에서 제거하는게 중요한데 로드밸런서가 서버의 상태를 파악하고 알맞게 로직을 처리해야 한다.
하지만 nginx 오픈소스 버전은 트래픽 분배까지 가능하다(상용버전인 nginx plus를 사용하면 헬스 체크까지 제공한다).
nginx plus가 아니라면 아래 오픈 소스 모듈을 활용하여 헬스 체크 기능을 사용해보자.
https://github.com/yaoweibin/nginx_upstream_check_module
공부한 곳 및 출처
http://nginx.org/en/docs/http/ngx_http_upstream_module.html
'issue 기록' 카테고리의 다른 글
JPA/ could not initialize proxy - no Session (9) | 2021.09.14 |
---|---|
JPA delete관련 에러 (Cascade 영속성 전이 관련 에러) (3) | 2021.08.19 |
BCryptPasswordEncoder 패스워드 암호화 관련 이슈 (0) | 2021.07.23 |
@AllArgsConstructor,@NoArgsConstructor (0) | 2021.06.05 |
JPA 중복 칼럼 에러 (0) | 2021.04.18 |