Kori 7월 20일, 2022에 포스트됨 공유하기 7월 20일, 2022에 포스트됨 리자토 페르난도 (Rizzato Fernando)의 "Using FireDAC Connection Pooling with RAD Server" 를 번역했습니다. (원문 작성: 2022년 7월 19일, 최종 번역: 2022년 7월 20일) 연결 풀링 (connection pooling)이란? 연결 풀 (connection pool)이란 데이터베이스 연결(들)을 모아두어서 데이터베이스에 대한 요청(request)이 발생하면 재사용될 수 있도록 하는 캐시(cache)이다. 연결 풀 (connection pool)은 데이터베이스에서 명령을 수행하도록 할 때 그 성능 향상시키는 목적으로 사용된다. 사용자들이 각자 데이터베이스 연결을 열고(open) 유지하는 것은, 특히 데이터-중심 애플리케이션인 경우, 비용이 크고 자원(resource)가 낭비된다. 연결 풀링인 환경에서는, 연결이 한번 생성되면, 연결 풀 안에 위치하고 다시 사용될 수 있으므로 새 연결을 반드시 다시 만들어야 할 필요가 없어진다. 개발자는 연결 풀 하나에서 생성할 수 있는 최대 연결 수량을 정의할 수 있으므로, 필요한 데이터베이스 라이선스의 수량을 줄일 수 있다는 점에서도 관심을 가질 만하다. 이런 환경에서는, 연결 풀이 한도에 도달한 상태에서 새 요청이 도착하면, 연결 풀 안에 있는 연결들 중에서 아무것도 풀려서 사용할 수 있게 되지 않은 채 사전에 지정된 제한 시간에 도달하는 경우 해당 요청은 처리되지 못한다. 데이터베이스 연결이 제한 적인 연결 풀링에서는 사용자 수와 애플리케이션 아키텍처를 기반으로 해당 연결 풀에게 가장 이상적인 최대 연결 갯수를 지정하는 것이 중요한 열쇠이다. FireDAC 연결 풀링 (connection pooling)의 작동 방식 FireDAC에서 연결 풀링 (connection pooling)이 작동하는 방식은 상당히 쉬워서, 사용하는 연결의 프로퍼티(property) 하나만 설정하면 작동한다 (Pooled=True). 물론, 연결 풀링은 멀티-쓰레드 애플리케이션에서 더욱 빛난다. 짧은 작업(task) 여러개가 (거의) 동시에 실행되고, 각 작업마다 데이터베이스 연결이 있어야 하기 때문이다. 연결 풀링 기능을 사용할 때는, 해당 연결이 이미 만들어져 있고, 자신을 사용할 작업을 기다리고 있기 때문에, 작업 수행 시간이 훨씬 더 빠르고 자원 소모는 더 적다. 조금 더 수준 높게 활용하려면, "Pooled" 파라미터 뿐만 아니라, 아래 3 가지 파라미터까지도 고려해 볼 수 있다. 파라미터 설명 예시 POOL_CleanupTimeout POOL_ExpireTimeout 시간이 넘도록 사용되지 않는 연결을 FireDAC이 제거할 때까지의 시간이다. 기본값은 30000 밀리초 (30초)이다. 3600000 POOL_ExpireTimeout 연결이 사용되지 않은 채 여기에 지정한 시간 (밀리초)을 넘기면 연결 풀에서 지워지고 파괴될 수 있다. 기본값은 90000 밀리초 (90초)이다. 600000 POOL_MaximumItems 연결 풀 안에 들어갈 최대 연결 수량. 지정된 최대 수량보다 애플리케이션이 더 많은 연결이 필요하게 되는 시점이 되면 예외(exception)이 발생된다. 기본값은 50이다. 100 FireDAC에서는 (FireDAC의 .ini 파일 안에 저장되는) "영속(Persistent)" 연결, (애플리케이션의 해당 메모리에서만 사용할 수 있는) "프라이빗(Private)" 연결, (저장되지 않고, 이름도 없어서 FDManager가 관리하지 않는) "임시(Temporary)" 연결이 있다. 연결을 정의하고 설정하는 방법은 (연결 풀을 사용하든 않하든) 아래 도움말에 자세히 설명되어 있다. [DocWiki 번역] 연결을 정의하기 (FireDAC) Multithreading (FireDAC) FireDAC 연결 풀링 (connection pooling)을 RAD 서버 (EMS)에서 사용하기 진정한 백엔드 애플리케이션이라면, RAD 서버도 마찬가지로, 애플리케이션이 커가면서 늘어날 호출을 처리할 수 있는 풀링(pooling) 작동 방식은 거의 필수이다. 지금 보여 줄 예제에서는 FDManager를 통해 연결을 정의하는 "프라이빗(Private) 연결을 사용한다. 물론, FireDAC의 .ini 파일에 정의된 연결 역시 재사용할 수 있다. 더 나아가 FDManager를 통해 해당 .ini 파일을 적재하고 여기에 연결 풀링 파라미터를 추가할 수도 있다. 이렇게 연결 풀링은 서버 애플리케이션에만 적용되도록 할 수 있는데, 데스크탑 애플리케이션에서는 그다지 쓸 일이 없기 때문이다. 이 데모 앱은 RAD Server Wizard (https://docwiki.embarcadero.com/RADStudio/en/Creating_a_RAD_Server_Package) 를 사용하여 만들었으며, 최근에 추가된 EMSDataSetResource(https://docwiki.embarcadero.com/RADStudio/en/Using_RAD_Server_Components 그리고 https://blogs.embarcadero.com/using-emsdatasetresource-component-with-rad-server/)를 사용했다. 하지만, 직접 정의한 RAD 서버의 엔트포인트에도 똑같이 적용된다. 꼭 알아야 할 중요한 점은 애플리케이션 인스턴스 하나에는 FDManager 인스턴스가 하나만 존재할 수 있다는 점이다. 따라서 FDManager의 인스턴스는 해당 EMS 리소스의 initialization 구역 안에서 생성되어야 한다. 데모 프로젝트를 대상으로 부하(stress) 테스트 이 비디오는 연결 풀링 작동 방식을 설명하고, 이어서 JMeter를 사용하여 100 사용자의 부하를 테스트한다. 비디오 보기: https://blogs.embarcadero.com/using-firedac-connection-pooling-with-rad-server/#Running_a_stress_test_with_our_demo_project 추가 팁, RAD 서버 애플리케이션이 여러 패키지로 구성된 경우에도 풀링 메커니즘을 사용할 수 있다. FDManager에 의해 연결 풀링 구성을 정의하도록는 RAD 서버 리소스를 하나 생성하고 배포 환경에서 이 리소스가 가장 첫 번째 리소스로 적재( load)되도록 하기만 하면 된다. 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.