Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

FireDAC 연결 풀링(Connection Pooling)을 RAD 서버와 함께 사용하기


Recommended Posts

Rizzato Fernando"Using FireDAC Connection Pooling with RAD Server" 을 번역했습니다. (원문 작성: 2024년 6월, 최종 번역: 2024년 6월)

 

차례


연결 풀링(Connection Pooling) 의미

연결 풀(Connection Pool)은 데이터베이스 연결들을 모아 캐시(cache)해 놓고는 것이다. 따라서, 그 연결들을 재사용하기 때문에, 그 후에 데이터베이스에 대한 요청이 필요할 때 바로 대응할 수 있도록 한다. 연결 풀을 사용하는 목적은 데이터베이스에 대한 명령 실행 성능이 향상시키기 위해서다. 각 사용자에 대해 데이터베이스 연결을 열고 유지 관리하는 것, 특히 동적인(dynamic) 데이터베이스-기반 애플리케이션에 대한 요청은 비용이 많이 들고 리소스를 낭비한다. 하지만, 연결 풀링 안에서는, 연결(connection)이 생성되고 나면,  그것은 풀(pool) 안에 들어간다. 그래서 다시 사용될 수 있다. 즉 새 커넥션을 다시 맺을 필요가 없다.

여러분은 또한 풀(Pool)이 생성할 수 있는 최대 연결 수를 정의할 수 있다. 이를 통해 매우 재미있는 효과를 얻을 수도 있다. 즉, 여러분에게 필요한 데이터베이스 라이선스 수를 줄일 수 있다. 풀(Pool)이 한도에 도달한 상태에서 새 요청이 도착하는 경우에는, 그 요청이 처리되지 않는다. 즉, 사전에 정의된 특정 시간을 초과한 것이 있거나 또는 그 이전에 사용할 수 있는 빈 연결을 생기지 않았다면 말이다.

연결 풀링 그리고 데이터베이스 연결 한도를 함께 사용할 때의 핵심은 그 풀에게 이상적인 개수를 정의하는 것이다. 그 기준은 최종 결정된 사용자 수 그리고 애플리케이션 아키텍처여야 한다. 이에 대한 자세한 내용은 아래 예제에 있다.
 

FireDAC의 연결 풀링 메커니즘

FireDAC의 연결 풀링 메커니즘은 꽤 쉽게 사용할 수 있다. 그리고 여러분의 연결(connection)에서 연결 프로퍼티 하나만 추가로 지정하면 활성화된다(Pooled=True).

물론, 풀링 기능은 다중 스레드(Multi Thread) 애플리케이션 안에서 빛을 발한다. 거기에서는 여러 개의 짧은 작업이 동시에(또는 거의 동시에) 실행되는데, 각 작업마다 연결 설정이 필요하기 때문입니다. 기능을 사용되고 있다면, 연결이 이미 설정되어 있는 상태에서 작업을 기다리고 있게 된다. 따라서, 훨씬 더 처리 시간이 빠르고, 리소스 소모도 적다.

좀 더 수준 높게 활용하는 경우에는, "Pooled(풀링됨)" 파라미터 외에도, 아래의 세 가지 파라미터를 더 사용할 수 있다.

파라미터 설명 예시
POOL_CleanupTimeout 이 시간(밀리초)이 되면 FireDAC이 해당 연결을 제거(remove)한다. 지정된 POOL_ExpireTimeout 시간이 넘도록 사용되지 않는다면 말이다. 기본값은 30000밀리초(30초)다.  3600000
POOL_ExpireTimeout 시간(밀리초)가 지나면 비활성 연결이 풀에서 삭제(remove)되고 파기(destroy)된다. 기본값은 90000밀리초(90초)다.  600000
POOL_MaximumItems 풀 안에 들어가는 최대 연결 개수다. 이보다 더 많은 연결을 애플리케이션이 요구하는 경우, 예외(exception)가 발생한다. 기본값은 50이다. 100

FireDAC를 사용할 때, 여러분이 선택할 수 있는 연결을 다음과 같이 3 가지가 있다.

  • Persistent(영구) 연결: FireDAC의 .ini 파일 안에 저장됨
  • Private(비공개) 연결: 응용 프로그램 1개의 메모리 안에서 사용 가능
  • Temporary(임시) 연결: FDManager에 의해 저장되지도, 이름이 지정되지도, 관리되지도 않음

연결(풀 사용 유무에 관계없이)을 정의하고 설정하는 방법에 대해 자세히 알려주는 문서는 다음과 같다: 

연결 풀링을 RAD 서버(EMS)와 함께 사용하기

중요한 백엔드 애플리케이션이라면(RAD 서버 역시 여기에 해당됨), 풀링 메커니즘을 갖추는 것이 거의 필수다. 그래야 여러분의 애플리케이션이 커지고 호출이 많아지는 것에 따라 맞춰갈 수 있기 때문이다. 우리 예시에서는 "Private(비공개)" 연결을 사용하겠다. 이는 FDManager를 통해 정의하면 된다. 물론, 여러분은 이미 FireDAC의 .ini 파일에 정의된 연결을 재사용 할 수도 있다. 또는 FDManager를 통해 .ini 파일을 로드하고 그 파일을 수정하여 여러분의 특정 서버 애플리케이션에 대한 특정한 연결 풀링 파라미터를 추가할 수도 있다. 하지만, 데스크탑 앱에서는 그렇게까지 할 필요가 별로 없다.

우리의 데모 앱은 RAD 서버 마법사(https://docwiki.embarcadero.com/RADStudio/en/Creating_a_RAD_Server_Package)를 사용해 만들었다. 그리고 최근에 추가된 EMSDataSetResource(https://docwiki.embarcadero.com/RADStudio/en/Using_RAD_Server_Componentshttps://blogs.embarcadero.com/using-emsdatasetresource-comComponent-with-rad-server/)를 활용한다. 하지만, 이와 똑같게 RAD 서버의 엔드포인트(endpoint)에 명시적으로 적용해도 된다.

알아야 할 중요한 점이 있다. 애플리케이션 인스턴스당 오직 하나의 FDManager 인스턴스만 존재할 수 있다. 따라서 FDManager가 생성되는 곳은 우리의 EMS 리소스의 initialization 구역이라는 점을 눈 여겨 보기 바란다. 다음과 같다.

spacer.png
 

스트레스 테스트를 데모 프로젝트를 대상으로 실행하기

아래 비디오는 풀링 메커니즘이 테스트 되는 것을 보여준다. JMeter를 사용해 총 100명의 사용자 부하를 적용해 봤다.

추가 팁으로, 여러분의 RAD 서버 애플리케이션이 여러 개의 패키지들로 구성된 경우라고 해도, 풀링 메커니즘을 사용할 수 있다. 여러분이 해야 할 일 이라고는 RAD 서버 리소스를 하나 생성해서 오직 연결 풀링 구성(configuration)만을 정의하고(해당 FDManager를 사용), 그 리소스를 여러분의 배포 환경에서 첫 번째 리소스로 적재(load)하기만 하면 된다.

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.