데이터베이스 연결 풀 이해

최근에 우리는 생산 과정에서 Postgres 실례의 CPU가 99퍼센트에 달하는 문제에 부딪혔다.그것은 요구를 만족시키기 어려웠고, 결과적으로 우리의 API는 실패했다.
우선, 이 문제는 Golang을 기반으로 한 마이크로 서비스에서 발생했다.이것은 매우 간소화된 마이크로 서비스로 두 개의 경량급 API를 제공하기 때문에 이 서비스는 자주 닿지 않고 아무도 관심을 가지지 않는다.

1674개의 이벤트 연결은 이 서비스에 있어서 터무니없이 높다.
이 사진을 보면 활동 데이터베이스 연결의 수량이 끊임없이 증가하고 있음을 알 수 있다. 코드를 빨리 보면 우리가 연결 탱크를 사용하지 않았다는 것을 알 수 있다.

데이터베이스 연결 비용이 많이 듭니다.

프로그램이 어떤 내용을 조회해야 할 때, 원격 데이터베이스에 대한 새로운 연결을 만들고, 이 연결을 사용하여 조회를 한 다음, 연결을 포기합니다.
새 접속을 생성하는 데 드는 비용은 다음과 같습니다. -
응용 프로그램은 데이터베이스 연결 문자열을 읽고 데이터베이스 실례에 TCP/IP 호출을 보내야 합니다. 데이터베이스는 현재 요청에 대해 인증/권한을 부여한 다음에 응용 프로그램에 새로운 연결을 만들어야 합니다.응용 프로그램은 현재 새로운 연결을 사용하여 실제 검색을 할 수 있습니다.
애플리케이션에 DB 접속이 필요할 때마다 이러한 문제가 발생하므로 시간과 리소스가 낭비된다는 점을 감안하면 신규 접속이 생성되는 이유costly입니다.
이것이 바로 연결 탱크가 해결하는 문제다.

연결 풀이란?

이름과 같이 연결 탱크는 연결을 만들고 캐시합니다.그리고 이 캐시 연결은 필요에 따라 응용 프로그램에 제공되며 데이터베이스 작업을 수행할 수 있습니다.프로그램이 연결 작업을 마치면 연결을 풀로 되돌려주고 연결을 다시 사용해서 새로운 연결을 만들 수 있습니다.결과적으로 애플리케이션의 성능이 향상됩니다.
Golang SQL 드라이버는 3개의 연결 풀 변수를 지원합니다.

MaxOpenConns

이것은 데이터베이스와 만들 수 있는 최대 연결 수를 지정합니다.우리의 예에서 정의가 없기 때문에 기본적으로 무한한 연결을 허용합니다.DB 접속이 늘어나는 이유다.
가령 MaxOpenConns 변수가 5 로 설정되어 있다면, 현재 모든 연결이 사용되고, 프로그램이 다른 연결을 필요로 한다면, 프로그램이 이 다섯 연결 중 하나를 연결 탱크로 되돌릴 때까지 기다려야 한다.
이 값을 설정하기 전에 두 가지를 추정해야 한다. 하나는 데이터베이스에서 처리할 수 있는 연결수이고, 다른 하나는 응용 프로그램이 사용하기를 원하는 병렬 작업 프로그램이다.

We have set the `MaxOpenConns` at 30 for our instances.

MaxIdlecons

이것은 연결 탱크에서 비어 있을 수 있는 연결 수를 지정합니다. (프로그램이 사용하지 않았습니다.)기본값은 2입니다.
가령 MaxOpenConns 변수를 30으로 설정하고 MaxIdleConns를 10으로 설정한다.프로그램이 현재 12개의 연결만 사용하고 있다면, 빈 연결의 수량은 18개입니다.허용된 연결 수MaxIdleConns가 10이기 때문에 나머지 8개의 연결은 데이터베이스로 되돌아갈 것이다.
만약 당신의 서비스가 수시로 데이터의 갑작스러운 증가를 얻을 수 있다면 MaxIdleConns에 더 높은 값을 제공하는 것을 고려해야 한다. 그러면 데이터가 급증할 때 새로운 연결을 많이 만들지 않을 것이다.따라서 부하 모드에 따라 빈 연결 수량을 설정할 수 있습니다.

We have set the `MaxIdleConns` at 20 for our instances.

코너 최대 수명

이것은 연못의 연결의 유효성을 지정합니다.만료되면 연결을 다시 설정해야 합니다.기본적으로 유효 기간은 영구입니다.데이터베이스가 부하 균형기와 교환 데이터베이스 뒤에 있지 않으면 이 값을 상당히 높게 설정할 수 있습니다.

We have set the `ConnMaxLifetime` at 30 minutes for our instances.

이러한 변수를 설정하면 연결 수는 180으로 줄어듭니다(6개의 POD가 있음). 그러나 CPU는 99%입니다.문제는 일부 조회가 그들이 필요로 하는 시간을 초과했기 때문이라는 사실이 증명되었다.데이터가 시간의 추이에 따라 급격히 증가하기 때문에 조회를 완성하는 데 많은 시간이 걸리기 때문에 반드시 한 열을 인덱스해야 한다.
경험 교훈: 항상 대규모 작업 코드를 작성합니다!