김철호
(Department of Software, Graduate School of Information Science, Soongsil University)
,
박경원
(Department of Software, Graduate School of Software Soongsil University)
,
최용락
(Department of Software, Graduate School of Software Soongsil University)
대부분의 Web Service는 성능 개선을 위해 사용자 접속 로그를 생성하여 관리한다. 생성된 접속 로그를 통해 트래픽이 많이 발생하는 시간대와 어떤 Resource가 많이 사용되는지 확인할 수 있으며 로그 분석을 통해 Web Service의 성능 측정 및 개선하는데 이용된다. 하지만, 많은 공공부문 Web Service와 같이 일정 기간 동안에 접속량이 증가할 때, 처리 할 사용자 접속 로그 수 증가로 인해 Web Service의 성능이 저하된다. 이를 해결하기 위해, 시스템의 성능을 개선하거나 튜닝을 필요로 하지만 많은 비용이 발생하게 되며 일정한 시간이 지나면, 사용자의 접속이 줄어들게 되어 더 많은 비용이 발생한다. 본 논문에서는 사용자 접속 로그 처리의 성능을 개선을 통한 Web Service의 성능개선을 제안한다. 또한, 최근 대용량 데이터를 처리하기 위하여 많이 사용되고 있는 Redis를 활용하여 NoSQL을 일부 적용한 방법을 제안한다.
대부분의 Web Service는 성능 개선을 위해 사용자 접속 로그를 생성하여 관리한다. 생성된 접속 로그를 통해 트래픽이 많이 발생하는 시간대와 어떤 Resource가 많이 사용되는지 확인할 수 있으며 로그 분석을 통해 Web Service의 성능 측정 및 개선하는데 이용된다. 하지만, 많은 공공부문 Web Service와 같이 일정 기간 동안에 접속량이 증가할 때, 처리 할 사용자 접속 로그 수 증가로 인해 Web Service의 성능이 저하된다. 이를 해결하기 위해, 시스템의 성능을 개선하거나 튜닝을 필요로 하지만 많은 비용이 발생하게 되며 일정한 시간이 지나면, 사용자의 접속이 줄어들게 되어 더 많은 비용이 발생한다. 본 논문에서는 사용자 접속 로그 처리의 성능을 개선을 통한 Web Service의 성능개선을 제안한다. 또한, 최근 대용량 데이터를 처리하기 위하여 많이 사용되고 있는 Redis를 활용하여 NoSQL을 일부 적용한 방법을 제안한다.
To improve performance, most of Web Services produce and manage User Access Logs. Through the Access Logs, the record provides information about time when the most traffic happens and logs and which resource is mostly used. Then, the log can be used to analyze. However, in case of increasing high tr...
To improve performance, most of Web Services produce and manage User Access Logs. Through the Access Logs, the record provides information about time when the most traffic happens and logs and which resource is mostly used. Then, the log can be used to analyze. However, in case of increasing high traffics of Web Services at the specific time, the performance of Web Service leads to deterioration because the number of processing User Access Logs is increasing rapidly. To solve this problem, we should improve the system performance, or tuning is needed, but it makes a problem cost a lot of money. Also, after it happens, it is not necessary to build such system by spending extra money. Therefore, this paper described the effective Web Service's performance as using improved User Access Log performance. Also, to process the newest data in bulk, this paper includes a method applying some parts of NoSQL using Redis.
To improve performance, most of Web Services produce and manage User Access Logs. Through the Access Logs, the record provides information about time when the most traffic happens and logs and which resource is mostly used. Then, the log can be used to analyze. However, in case of increasing high traffics of Web Services at the specific time, the performance of Web Service leads to deterioration because the number of processing User Access Logs is increasing rapidly. To solve this problem, we should improve the system performance, or tuning is needed, but it makes a problem cost a lot of money. Also, after it happens, it is not necessary to build such system by spending extra money. Therefore, this paper described the effective Web Service's performance as using improved User Access Log performance. Also, to process the newest data in bulk, this paper includes a method applying some parts of NoSQL using Redis.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
따라서 본 논문에서는 테이블간의 조인이 불필요한 데이터에 대해서 RDBMS가 아닌 Redis를 이용하여 대용량의 접속정보를 빠르게 처리할 수 있는 NoSQL에서 사용하는 데이터 저장방식을 일부 적용함으로써 사용자 급증으로 인한 대량의 접속정보 처리의 성능 향상을 통해 전반적인 Web Service의 성능을 개선하고자 한다.
본 논문에서는 사용자의 증가에 따른 문제를 해결하기 위해 Web Service의 성능을 향상시키고 원활한 서비스를 제공하기 위해 복잡한 연산을 하지 않고 조인을 필요로 하지 않은 사용자 접속정보를 처리과정을 기존의 RDBMS가 아닌 Redis를 활용하여 NoSQL의 키-밸류 데이터 저장소를 적용하는 방안을 제안하였다.
가설 설정
3) 데이터베이스 스키마가 고정되어 있지 않다.
제안 방법
PostgreSQL과 Redis를 활용하여 데이터의 Insert, Select, Update, Delete 명령에 대해서 처리하는 시간을 측정한 후 비교하는 방식으로 진행한다. 실험을 수행하기 위해서 Table.
DB설계를 위해 논리 ERD와 물리 ERD를 작성 하였으며 현재 운영 중인 Web Service와 거의 유사한 환경으로 구축하기 위해서 Web Service의 사용자 정보와 사용자 접속정보를 참조하여 설계했다.
RDBMS 모델링은 PostgreSQL에서 사용할 RDBMS 모델링과 Redis에서 사용할 NoSQL 모델링으로 진행하였다.
Redis의 데이터모델 설계는 화면에서 조회하는 항목을 사용자ID(USER_ID), 세션키정보(SESSION_KEY _INFO), 로그인일시(LOGIN_DTM), 로그아웃일시 (LOGOUT_DTM), 사용자IP주소(USER_IP_ADR), 사용자명(USER_NM)으로 정의하고 진행하였다. 따라서 PostgreSQL의 기본키에 해당하는 Key를 사용자ID, 로그인일 시의 결합으로 Key가 유일성(Uniqueness)을 가지도록 설계 하였으며 사용자의 이름을 보여주기 위하여 Fig.
따라서 PostgreSQL의 기본키에 해당하는 Key를 사용자ID, 로그인일 시의 결합으로 Key가 유일성(Uniqueness)을 가지도록 설계 하였으며 사용자의 이름을 보여주기 위하여 Fig.4의 사용자정보 테이블의 사용자이름을 추가하였다. Fig.
성능측정 실험은 설계를 마친 각각의 데이터베이스 모델을 바탕으로 하여 Insert, Select, Update, Delete 의 처리 시간을 측정하고 정량화된 수치로 비교가 가능하도록 시나리오를 작성하여 단계별로 성능측정을 수행하였다.
동일한 조건에서 실험하기 위해서 동일한 하드웨어에 PostgreSQL과 Redis를 함께 설치하였으며 Insert, Select, Update, Delete 등에 필요한 데이터는 형식에 맞추어 텍스트파일로 작성하였다. 그 후 성능테스트에 사용할 데이터가 들어있는 File을 읽어내어 배열(Array) 형태로 저장함으로써 성능테스트에 필요한 데이터와 데이터를 읽어 들이는 시간을 동일하게 맞추어 하드웨어로 인하여 발생하는 성능테스트의 영향을 최소화 하였다.
텍스트파일로 작성하였다. 그 후 성능테스트에 사용할 데이터가 들어있는 File을 읽어내어 배열(Array) 형태로 저장함으로써 성능테스트에 필요한 데이터와 데이터를 읽어 들이는 시간을 동일하게 맞추어 하드웨어로 인하여 발생하는 성능테스트의 영향을 최소화 하였다. 위의 방법을 통해서 동일한 조건에서 PostgreSQL 과 Redis를 사용하여 데이터를 처리함으로써 성능 테스트의 정확성을 확보하였을 뿐만 아니라 프로그램 실행 후에 생성되는 버퍼(Buffer)에 남아있는 데이터의 영향을 최소화하기 위해서 모든 테스트는 총 10회를 진행하였으며 최종 5회의 결과의 평균값으로 성능을 측정하였다.
그 후 성능테스트에 사용할 데이터가 들어있는 File을 읽어내어 배열(Array) 형태로 저장함으로써 성능테스트에 필요한 데이터와 데이터를 읽어 들이는 시간을 동일하게 맞추어 하드웨어로 인하여 발생하는 성능테스트의 영향을 최소화 하였다. 위의 방법을 통해서 동일한 조건에서 PostgreSQL 과 Redis를 사용하여 데이터를 처리함으로써 성능 테스트의 정확성을 확보하였을 뿐만 아니라 프로그램 실행 후에 생성되는 버퍼(Buffer)에 남아있는 데이터의 영향을 최소화하기 위해서 모든 테스트는 총 10회를 진행하였으며 최종 5회의 결과의 평균값으로 성능을 측정하였다.
따라서, 본 실험에서는 PostgreSQL과 Redis의 데이터량에 따른 메모리 사용량과 시간을 분석하기 위해 10건, 100건, 5, 000건, 10, 000건, 50, 000건, 100,000건의 데이터의 Insert, Select, Update, Delete 성능을 총 10회의 테스트하여 하위 5번의 결과 값의 평균을 데이터 건수에 대한 실행시간과 메모리사용량에 대해서 그래프로 나타내었다.
성능테스트는 RDBMS로는 PostgreSQL을 사용하고 NoSQL로는 Redis를 사용하여 두 데이터베이스에 데이터의 Insert, Select, Update, Delete의 처리시간과 메모리사용량을 측정하였다. Insert, Select, Update, Delete에 대한 데이터 처리와 관련된 실행시간과 메모리사용량을 비교했을 때, 소량의 데이터의 경우 PostgreSQL 이 Redis보다 메모리 사용량이 적었으며 실행 시간에는 큰 차이가 없으나 데이터량이 증가할수록 Redis가 PostgreSQL보다 더 적은 메모리를 사용하였으며 실행 시간도 더 짧은 것으로 나타났다.
대상 데이터
데이터는 Redis에서 지원하는 해시 데이터를 이용하였다. 해시데이터는 하나의 Key에 여러 개의 Value를 가질 수 있어 PostgreSQL의 데이터 저장구조와 유사하게 사용이 가능하다.
이론/모형
그러나 NoSQLe 각 테이블이 독립적으로 설계되어 데이터를 여러 서버에 분산시키는 데이터 분산이 용이하며 이로 인하여 서버에서 다루는 데이터양을 분산시킴으로써 대량의 데이터 처리에 이점을 가지고 있다. 또한 RDBMS는 대량의 데이터처리 서버의 성능을 높이기 위해서 하나의 서버에 CPU 또는 Memory 사이즈를 증설하는 Scale-Up 방식을 사용하여 성능을 높이지만 이는 하드웨어의 제약으로 인하여 한계가 있는 반면 NoSQLe 데이터 분산에 용이한 설계로 인하여 서버 하나의 성능을 높이는 방식이 아닌 서버 자체를 더 추가하는 Scale-Out 방식을 사용하여 시스템의 용량을 증대시킨다.
성능/효과
급증하였다. 데이터의 급증으로 인해 Fig. 1과같이 2018년까지 모바일 데이터 트래픽은 향후 3년간 약 11배 증가해 연평균 190EB(1ExaByte: 1018Bytes)에달할 것이라고 시스코(Cisco)사에서 전망했다.
나타내었다. Fig. 15에서 10건의 데이터의 Update 했을 때에는 PostgreSQL에서의 실행시간이 Redis에서의 실행시간보다 짧았으나 100건의 데이터를 Insert 했을 때부터는 Redis에서의 실행시간이 PostgreSQL에서의 실행시간보다 단축되는 것을 알 수 있으며 데이터의 Insert수가 많을수록 그 격차는 더 큰 것으로 나타났다. Fig.
Fig. 17은 PostgreSQL과 Redis의 데이터의 Delete 성능을 총 10회의 테스트중 하위 5번의 결과 값의 평균을 그래프로 나타낸 것으로 10건의 데이터 처리에서는 PostgreSQL이 좋은 성능을 보였고 100건에서는 거의 동등한 성능을 보였지만 데이터의량이 5,000건 이상으로 증가할수록 Redis의 성능이 약 3.5배가량 좋은 것을 확인할 수 있다. Fig.
5배가량 좋은 것을 확인할 수 있다. Fig. 18 PostgreSQL과 Redis의 Delete 를 처리할 때의 메모리사용량으로 10건, 100건의 데이터를 처리할 때에는 PostgreSQL이 적은 메모리를 사용하지만 5,000건의 데이터를 처리할 때에는 거의 동등한 사용량을 나타냈으며 10, 000건 이상으로 데이터를 처리할 때에는 Redis의 메모리 사용량이 PostgreSQL에비해 적게 사용하는 것으로 나타났다.
측정하였다. Insert, Select, Update, Delete에 대한 데이터 처리와 관련된 실행시간과 메모리사용량을 비교했을 때, 소량의 데이터의 경우 PostgreSQL 이 Redis보다 메모리 사용량이 적었으며 실행 시간에는 큰 차이가 없으나 데이터량이 증가할수록 Redis가 PostgreSQL보다 더 적은 메모리를 사용하였으며 실행 시간도 더 짧은 것으로 나타났다.
후속연구
있다. 하지만, 앞으로 더 많은 데이터를 처리하기 위해서는 메모리의 사용량을 위의 방법보다 더 개선시킬 필요가 있다.
참고문헌 (10)
Hyung-Nam Shim, TK-Indexing:An Indexing Method for SNS Data Based on NoSQL, 2012
Terminology Dictionary in MK, http://dic.mk.co.kr/menu New2006/desc.php?dic_key1765, 2014
※ AI-Helper는 부적절한 답변을 할 수 있습니다.