네?! 페이지가 안뜬다구여!?

나는 지금 스파르타코딩클럽에서 항해99 7기 부트캠프와
미니튜터4기에 이어 5기 활동을 하고 있다.

슬랙에서 수강생 분들이 강의를 듣던 중에 에러가 발생했다고 해서 (사진참고)
마이페이지와 내 강의실을 들어가보았다.

해당 문제를 보고 바로 사이트를 들어가보았는데 나는 이상없이 작동이 잘되었다.

해당 문의사항

문제 내용

• 내 강의실, 마이페이지의 504 Gateway Time-out
• 두번째 사진의 내용이 구체적이지는 않아서 어떤 문제인지는 모르겠으나
  동일하게 504 Gateway Time-out으로 보여진다.
• 동영상 강의 듣고 난 후 다음 강의로 넘어가 지지 않음.

최초 발생한 시간은 12시 55분으로 추정된다.

복구는 2시 22분쯤 된 것 같다. 약 1시간 반 정도가 걸린 것 같다....
지금 블로그를 작성하는 시간은 2:30분인데..
왜 나는 이상없이 잘 되는데, 다른 분들은 안되었을까?

왜 발생했을까? 고민

아마 언젠가 클라이언트 입장에서는 한번 쯤은 봤을 것 같은데
개발 공부를 하고 나서 504에러는 처음 본다.
서비스가 잘 되고 있던 사이트가 갑자기 왜..?

https://blog.lael.be/post/9251

원인을 설명한 블로그가 있어 읽어보았다.

이 504 Gateway Time-out 오류는 리버스 프록시 프로그램에서 < == > 해당 프록시(upstream)와의 통신이 오래걸렸고, 리버스 프록시 프로그램에서 지정한 시간 제한을 초과해서 발생한 오류입니다.

여기서 봐야할 점은 리버스 프록시 프로그램이다.
리버스 프록시 프로그램은 99% nginx를 사용한다.

스파르타코딩클럽은 nginx를 사용하고 있다.

항해를 들어오기 전에 여러번 봤었던 백엔드 채용공고.

웹서버를 nginx를 사용하는 것도 알고 있었는데, 이게 뭔지는 아직 자세하게 알아보진 못했었는데
이번 기회에 알 수 있을 것 같다.

• 리버스 프록시 프로그램은 99% nginx 를 사용한다.

이 내용 때문이다.

리버스 프록시 프로그램이 무엇인지도 알아봐야겠다.

관련 내용의 블로그 가져와보았다!

게이트웨이란? Gateway

• 게이트웨이는 (통신 분야에서) 서로 다른 네트워크 연결을 위한 출입구를 의미합니다.
  단어 자체는 관문, 출입구라고 번역됩니다.
  한 지역과 다른 지역을 연결하는 톨게이트나, 빌딩 건물과 외부를 연결하는 중앙현관문을 비유로 들 수 있습니다.

일반적인 nginx 네트워크는 이렇다고 한다.

nginx 는 reverse proxy server 이며, 뒷부분 처리하는 곳은 upstream 이라고 하며, 그 연결 부분은 (위 그림에서 동그라미 부분) Gateway 가 됩니다.
upstream 은 대부분 php, nodejs, python, tomcat 중 하나를 사용합니다.

음~ upstream 이라는 것이 있는데 대부분 php, node.js, python, tomcat 에서 쓰는구나
그렇다. 지금 스파르타 코딩클럽은 개발언어로 TypeScript와 python 을 사용중이다.

참고 : nginx 는 reverse proxy server 이며, 뒷부분 처리하는 곳은 upstream 이라고 하며, 그 연결 부분은 (위 그림에서 동그라미 부분) Gateway 가 됩니다.
upstream 은 대부분 php, nodejs, python, tomcat 중 하나를 사용합니다.
NGINX 와 PHP-FPM 의 통신을 위한 저 굵은점이
(NGINX 입장에서) Gateway 가 됩니다.

nginx?

NGINX 는 외부프로그램과 통신을 하여 결과를 출력하는 프로그램이다.

게이트웨이 타임아웃이란? Gateway Timeout?

외부 프로그램과 통신이 오래 지연된다면 시간 초과(timeout)가 일어나게 됩니다.
nginx 와 upstream 이 통신을 할 때, 어느 부분이 nginx 에서 설정한 시간 제한보다 오래걸리면 504 timeout 이 발생하게 됩니다. (timeout : 연결을 끊어버리고 오류 메세지 표시)

Gateway Timeout 의 종류

• connect_timeout (default : 60s) : upstream 연결이 지연되는 경우 발생한다. 대부분의 upstream 은 내부망이나 가까운 곳에 위치해 있기 때문에, connect timeout 이 발생할 확률은 거의 없다. (upstream 연결이 proxy 방식이고, 이 proxy 연결이 방화벽으로 막혀있을때 일어날 수도 있다.)
  TCP/IP 에서 연결은 3 way handshake 방식으로 동작하는데, SYN 을 보낸 후 SYN+ACK 을 시간 내에 받지 못하면 connect_timeout 이 발생한다. 더 알아보기 : TCP-3-WayHandshake-4-WayHandshake
• send_timeout (default : 60s) : 프록시 연결 후 데이터 전송이 지연되는 경우 발생한다. 사용자가 파일을 업로드 하는 중이고, 업로드 속도가 매우 느려서 send_timeout 을 초과하면 발생한다.
  일반적으로 대용량 파일은 관리자나 지정된 사용자만 업로드하며, 이들은 좋은/안정적인 인터넷 환경을 사용할 확률이 크기 때문에 이 문제는 거의 발생하지 않는다. (일반적인 인터넷 전송 속도와, upload_max_filesize 값을 비교해서, 60초 이상을 초과할 확률이 있는지 확인해 보도록 하자.)
• read_timeout (default : 60s) : 거의 모든 504 Gateway Time-out 의 원인은 이것이다. upstream 에 정상적으로 연결했고, 응답 요청도 정상적으로 보냈으나, 응답이 지연되는 경우이다.
  백엔드 서버가 느리거나, 복잡한 작업을 하거나, 기타 이유로 지연되어 발생할 수 있다.

해당 사진은 php이나, 사례와 참고로 알아두어야겠다.
아래와 같은 코드를 작성하면, PHP-FPM로 부터 응답이 70초 후에 오게 되며, read_timeout 기본값 60초를 초과하기 때문에, NGINX는 default read_timeout 60초가 되는 순간 연결을 끊고 504 에러를 표시하게 된다고 한다!

NGINX 에서 read_timeout 의 경우, 요청(send)는 전송된 상태이기 때문에, upstream 과 연결을 강제로 끊더라도 upstream 프로세스의 작업은 계속 동작한다. (PHP 의 경우 max_execution_time 시간까지 실행된다. FPM 에서 request_terminate_timeout 을 설정한 경우 이 값의 영향도 받음.)

Upstream 과 연결 방법

• FastCGI 연결 : 프로그램 자체와 연결. 프로그램에서는 FastCGI 라는 프로토콜을 지원하며, 이것으로 NGINX 와 통신 가능. (fastcgi:// 또는 unix:/blabla/sample.sock 형태로 나타남)
• Proxy 연결 : 프로그램에서 HTTP 프로토콜을 지원하고 이것으로 NGINX 와 통신하는 경우.(http://some-ip-addr:9000 형태로 나타남)

NGINX 에서 timeout 을 다루는 방법 (504 Gateway Timeout 해결방법)

• 먼저 자신의 서버가 upstream 과 어떤 형태로 통신하는지 알아야 한다. 이것은 nginx 에서 사이트환경설정 conf 파일을 보면 알 수 있다.
  
  fastcgi_pass 라고 쓰여 있으면 fastcgi 연결이고, proxy_pass 라고 쓰여 있으면 proxy 연결이다.

• 아래와 같이 변경하면 504 에러가 해결된다.
  둘 다 하는게 아니라 둘 중 하나, proxy 이면 proxy 설정을, fastcgi 이면 fastcgi 설정을 하면 된다.
  connect_timeout 과 send_timeout 은 기본값인 60초를 넘길 일이 거의 없고, upstream 에게 정상적인 응답 요청(request)을 보내기 전이므로 시스템적으로 큰 문제가 발생하지 않는다. (따라서 무시하는 편임.)
  되도록 read_timeout 만 설정하도록 하자.

알아두면 좋은 참고 사항

• timeout 이 되었을 때 실행중이던 작업은 어떻게 처리될까?
• 이것은 upstream 의 환경설정에 따라 달려있다. 대부분 request 가 오래 걸리더라도 중간에 끊지 않고 다 처리하는 편이다.
• 외부 호출(인터럽트/system/mysql query)등이 일어나면 카운트가 중지함. 즉 max_execution_time 이 10초로 설정되어 있어도, 1시간 동안 동작하는 mysql query 를 실행할 수 있다.
  request_terminate_timeout 값은 기본값이 0(사용안함) 인데, 이 값을 사용해서 절대적인 실행시간 제한을 둘 수 있다. system 의 명령어는 request_terminate_timeout 제한에 걸렷을때 강제 종료가 되지만 mysql query 는 종료되지 않는다.

중간의 내용은 거의 내가 작성한 내용이 아니라 블로그의 내용을 이해하며
보기 좋게 복사붙여넣기 했다. 그래도 어떤 에러가 발생할 때에 이 원인으로 인한 에러가능성, 해결방법 등의 한 가지 사례를 얻고 갈 수 있던 의미있는 시간이었다.

이번 에러로 발생할 수 있는 영업 손실

이번 에러 발생으로 인해서 발생할 수 있는 영업 손실에 대해서도 생각해보았다.
에러는 일요일 오후 1시에 발생된 것으로 추정되고, 2시 반 안쪽을 해결이 된 듯 보인다.

사실 하루의 트래픽이 가늠이 안가서 모르겠지만,
코딩의 관심이 높아지고 있기도 하고, 최근 개발자에 대한 이슈가 많이 되고 있다보니
많은 분들이 찾아볼 수 있는 황금기라고 생각해서 많이 들어올 것 같다.

클라이언트 입장

주말에는 14:00 - 17:00 즉문즉답이 이루어지는 스파르타 코딩클럽 서비스 특성 상
해당 서비스를 이용하기 위해서 그 시간을 할애 할 기존 수강생들이 많았을 것으로 판단된다.

기업 교육으로 강의를 들으시는 분들도 계실텐데 주말을 반납하고 강의를 듣고자 했던 직장인 수강생이라면 적잖이 언짢을것으로 보인다. (주말에는 채널톡도 쉬는데..)

개발자 입장

기본적으로 온라인을 베이스로 한 서비스를 제공하기 때문에
이런 이슈들이 모여 기업의 브랜드 이미지가 형성된다고 생각한다. (개발자의 책임감 중시)
오늘과 같은 이슈는 기업의 영업 손실이 결제가 이루어지지 않는 것 보다는 적을 것이다.

개발자를 준비하는 내 입장에서 상상해봤을 때 (물론 신입이지만...)
강한 책임감이 필요할 것 같았다. 그리고 이를 빠른 시간내에 해결하기 위해서 소통능력과 빠른 대처를 위한 해당 지식도 많이 배워야겠다고 생각했다.

그래서 코딩만 잘하는 개발자 보다는
우리가 풀고자하는 문제가 무엇인지를 정확하게 이해를 해서
주어진 비지니스 문제를 해결하는 개발자가 되어야겠다고 다짐해본다.

스파르타코딩클럽 입장

기업 입장에서는 ....황금같은 주말에 마음써야 할 일이 생겼다는 것인데..
이 문제를 해결하기 위해서 소중한 시간을 썼을것이다...
....화이팅..