Tutorial

[ Trouble Shooting ] 서비스 중 발견한 문제 발생 및 해결

new_challenge 2020. 9. 21. 18:33
반응형

이번 포스팅은 서비스 운영 중 발생한

트러블 슈팅에 대한 기록입니다.

 

 

Invalid request block size

서비스 도중 uwsgi의 로그 확인 도중 아래와 같은 로그 확인

 

[ 문제 발생 ]

 

> uWSGI는 디폴트로 각 요청의 헤더에 대해 매우 작은 버퍼 크기를 할당한다(4096 bytes)

> 해당 요청의 버퍼 크기가 max 사이즈를 초과해서 유효하지 않은 요청이라고 502 Bad Gateway 에러가 발생

 

[ 해결 방안 ]

uWSGI의 buffer size 세팅 값을 변경한다.

buffer-size=32768

 

pymysql timeout 설정

Main DB의 CPU 과부하로 인해 DB connection이 오래 걸리는 문제가 발생함.

pymysql 사용 시 default설정이 no timeout. 따라서 요청이 들어올 때마다, 응답을 기다리느라 요청이 계속 밀리는 문제 발생 > Load Average 증가

 

[ 해결방안 ]

pymysql에서 timeout 설정 추가

각자 상황에 맞게 필요한 timeout을 설정해주면 된다.

import pymysql

class MySQL(self):
    def connect(self):
        conn = pymysql.connect(
                            host=[host],
                            port=[port],
                            user=[user],
                            passwd=[passwd],
                            db=[db],
                            read_timeout=2,
                            write_timeout=2,
                            connect_timeout=2
                            )
        return conn
    def dbClose(self, tunnel, cur):
        cur.close()
        tunnel.close()

    def queryExecute(self, query):
        conn = self.connectMainDB()
        cur = conn.cursor()

        try:
            cur.execute(query)
            result = cur.fetchall()

            return result

        except Exception as e:
            print(e)    

        finally:
            self.dbClose(cur)

 

mysql unauthenticated user [Error]

information_schema DB에서 PROCESSLIST 테이블로 접근하면 현재 작업 중인 프로세스를 확인할 수 있다.

SELECT * FROM `PROCESSLIST`

> 위 쿼리로 확인했을 때 아래와 같은 상황 발생

- unauthenticated user로 현재 실행 중인 프로세스가 가득 차있는 경우

- DB connection 속도 저하로 인해 서버에도 영향을 준다.

- 결국 최대 연결 수를 초과하면 웹사이트 접속에도 영향을 미친다.

- SSH , MySQL 연결 모두 지연 (TIME OUT이 발생할 때까지)

 

> 아래와 같은 상황의 발생 원인

- 클라이언트에서 DB 서버로 접속 시, DB는 처음에 클라이언트가 누군지 확인하기 위해 반대로 요청을 보내는데, 등록되어 있지 않은 IP의 경우 응답이 느려져서 속도가 저하되는 문제가 생긴다. 혹은 DNS 서버가 응답을 하지 않는 경우도 존재함

 

[ 문제 발생 ]

 

[ 해결 방안 ] 

위와 같이 skip-name-resolve 추가 후 mysql 재시작

$ mysql 설정파일위치

[mysqld]
skip-name-resolve

 

filebeat 파일 전송 관련

filebeat를 통해 로그 데이터를 로그스테이시를 거쳐 엘라스틱에 보내는 경우, 데이터가 잘못 올라가서 엘라스틱에 데이터를 삭제하고 다시 올려야 하는 경우가 발생한다.

 

파일비트는 내부적으로 메타데이터를 사용해서 보냈던 데이터는 다시 보내지 않게 되는데, 잘못 올라가서 다시 데이터를 올려야 하는 경우에는 파일비트의 메타데이터를 삭제하고 다시 올려야 정상적으로 재 업로드가 된다.

 

그렇지 않으면, 이전에 이미 보낸 데이터의 경우는 다시 엘라스틱으로 보내지 않는다. 메타데이터에서 지정한 데이터 이후만 전송하게 된다.

 

# 파일비트 중단
$ systemctl stop filebeat

# filebeat 폴더로 접근
$ cd /var/lib/filebet

# filebeat 폴더의 메타데이터 삭제
$ rm -r * 

# 파일 비트 재시작
$ systemctl restart filebeat

# 파일비트 구동확인
$ systemctl status filebeat

> 위와 같이 메타데이터 삭제 후, 재시작을 하게 되면 처음 데이터부터 다시 엘라스틱으로 전송하게 된다.

 

Nginx 재부팅 에러

클라우드 서버의 경우, Downgrade/Upgrade 이후 재부팅 혹은 단순 재부팅 이후 Nginx가 재시작이 안 되는 문제 발생

 

[ 문제 발생 ] 

 

자세한 원인 파악을 위해 아래 명령어로 확인

$ journalctl -xe

# 혹은

$ systemctl status nginx

 

에러 문구를 확인하면 80 포트가 사용 중이기 때문에 재시작할 수 없다고 친절하게 알려준다.

 

 

> 위 문제는 현재 다른 웹서버가 80 포트를 이미 사용하고 있기 때문에 발생한다.

> 기본적으로 Ubuntu에는 httpd가 설치가 되어있어, 재부팅 시 자동으로 실행되는 경우에 위와 같은 문제가 발생한다.

 

[ 해결 방안 ]

1. 현재 80 포트를 사용 중인 프로세스 확인

$ netstat -anp | grep 80

 

> 확인해보면 현재 80 포트를 apache2가 사용 중인 것을 알 수 있다.

 

2. apache2 서버 중단

$ systemctl stop apach2

 

3. Nginx 재시작

# nginx 재시작
$ systemctl start nginx

# nginx 상태 확인
$ systemctl status nginx

 

> Nginx 정상 작동 확인

 

> apache2가 아닌 nginx가 80 포트 사용

반응형