AWS Blu Age 현대화된 애플리케이션의 성능 최적화 - 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구모범 사례에픽문제 해결관련 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

AWS Blu Age 현대화된 애플리케이션의 성능 최적화

Vishal Jaswani, Manish Roy, Himanshu Sah, Amazon Web Services

요약

AWS Blu Age로 현대화된 메인프레임 애플리케이션은 프로덕션에 배포하기 전에 기능 및 성능 동등성 테스트가 필요합니다. 성능 테스트에서 현대화된 애플리케이션은 특히 복잡한 배치 작업에서 레거시 시스템보다 더 느리게 작동할 수 있습니다. 메인프레임 애플리케이션은 모놀리식인 반면 최신 애플리케이션은 멀티티어 아키텍처를 사용하기 때문에 이러한 차이가 존재합니다. 이 패턴은 AWS Blu Age와 함께 자동 리팩터링을 사용하여 현대화된 애플리케이션의 이러한 성능 격차를 해결하기 위한 최적화 기술을 제공합니다.

이 패턴은 기본 Java 및 데이터베이스 튜닝 기능이 있는 AWS Blu Age 현대화 프레임워크를 사용하여 성능 병목 현상을 식별하고 해결합니다. 이 패턴은 프로파일링 및 모니터링을 사용하여 SQL 실행 시간, 메모리 사용률 및 I/O 패턴과 같은 지표의 성능 문제를 식별하는 방법을 설명합니다. 그런 다음 데이터베이스 쿼리 재구성, 캐싱 및 비즈니스 로직 구체화를 포함하여 대상 최적화를 적용하는 방법을 설명합니다.

배치 처리 시간 및 시스템 리소스 사용률이 개선되면 현대화된 시스템의 메인프레임 성능 수준을 일치시키는 데 도움이 됩니다. 이 접근 방식은 최신 클라우드 기반 아키텍처로 전환하는 동안 기능적 동등성을 유지합니다.

이 패턴을 사용하려면에픽 섹션의 지침에 따라 시스템을 설정하고 성능 핫스팟을 식별하고 아키텍처 섹션에서 자세히 다루는 최적화 기술을 적용합니다.

사전 조건 및 제한 사항

사전 조건 

  • AWS Blu Age 현대화된 애플리케이션

  • JProfiler 라이선스

  • 데이터베이스 클라이언트 및 프로파일링 도구를 설치할 수 있는 관리 권한

  • AWS Blu Age 레벨 3 인증

  • AWS Blu Age 프레임워크, 생성된 코드 구조 및 Java 프로그래밍에 대한 중간 수준의 이해

제한 사항

다음 최적화 기능 및 기능은이 패턴의 범위를 벗어납니다.

  • 애플리케이션 계층 간 네트워크 지연 시간 최적화

  • Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 유형 및 스토리지 최적화를 통한 인프라 수준 최적화

  • 동시 사용자 로드 테스트 및 스트레스 테스트

제품 버전

  • JProfiler 버전 13.0 이상(최신 버전 권장)

  • pgAdmin 버전 8.14 이상

아키텍처

이 패턴은 JProfiler 및 pgAdmin과 같은 도구를 사용하여 AWS Blu Age 애플리케이션에 대한 프로파일링 환경을 설정합니다. AWS Blu Age에서 제공하는 DAOManager 및 SQLExecutionBuilder APIs를 통해 최적화를 지원합니다.

이 섹션의 나머지 부분에서는 현대화된 애플리케이션의 성능 핫스팟 및 최적화 전략을 식별하기 위한 자세한 정보와 예제를 제공합니다. 에픽 섹션의 단계는 추가 지침을 위해이 정보를 다시 참조하세요.

현대화된 메인프레임 애플리케이션에서 성능 핫스팟 식별

현대화된 메인프레임 애플리케이션에서 성능 핫스팟은 코드에서 상당한 속도 저하 또는 비효율성을 유발하는 특정 영역입니다. 이러한 핫스팟은 메인프레임과 현대화된 애플리케이션 간의 아키텍처 차이로 인해 발생하는 경우가 많습니다. 이러한 성능 병목 현상을 식별하고 현대화된 애플리케이션의 성능을 최적화하기 위해 SQL 로깅, 쿼리 EXPLAIN 계획, JProfiler 분석의 세 가지 기법을 사용할 수 있습니다.

핫스팟 식별 기법: SQL 로깅

AWS Blu Age를 사용하여 현대화된 애플리케이션을 포함한 최신 Java 애플리케이션에는 SQL 쿼리를 로깅하는 기능이 내장되어 있습니다. AWS Blu Age 프로젝트에서 특정 로거를 활성화하여 애플리케이션에서 실행한 SQL 문을 추적하고 분석할 수 있습니다. 이 기법은 일괄 처리 또는 쿼리 구체화를 통해 최적화될 수 있는 과도한 개별 쿼리 또는 잘못 구성된 데이터베이스 호출과 같은 비효율적인 데이터베이스 액세스 패턴을 식별하는 데 특히 유용합니다.

AWS Blu Age 현대화된 애플리케이션에서 SQL 로깅을 구현하려면 application.properties 파일의 SQL 문에 DEBUG 대해 로그 수준을 로 설정하여 쿼리 실행 세부 정보를 캡처합니다.

level.org.springframework.beans.factory.support.DefaultListableBeanFactory : WARN
level.com.netfective.bluage.gapwalk.runtime.sort.internal: WARN
level.org.springframework.jdbc.core.StatementCreatorUtils: DEBUG
level.com.netfective.bluage.gapwalk.rt.blu4iv.dao: DEBUG
level.com.fiserv.signature: DEBUG
level.com.netfective.bluage.gapwalk.database.support.central: DEBUG
level.com.netfective.bluage.gapwalk.rt.db.configuration.DatabaseConfiguration: DEBUG
level.com.netfective.bluage.gapwalk.rt.db.DatabaseInteractionLoggerUtils: DEBUG
level.com.netfective.bluage.gapwalk.database.support.AbstractDatabaseSupport: DEBUG
level.com.netfective.bluage.gapwalk.rt: DEBUG

로깅된 데이터를 사용하여 최적화 대상을 식별하여 빈도가 높고 성능이 느린 쿼리를 모니터링합니다. 일반적으로 성능에 가장 큰 영향을 미치기 때문에 배치 프로세스 내의 쿼리에 집중합니다.

핫스팟 식별 기법: 쿼리 EXPLAIN 계획

이 메서드는 관계형 데이터베이스 관리 시스템의 쿼리 계획 기능을 사용합니다. PostgreSQL 또는 MySQL 또는 OracleEXPLAIN PLAN에서와 같은 명령을 사용하여 데이터베이스EXPLAIN가 지정된 쿼리를 실행하려는 방식을 검사할 수 있습니다. 이러한 명령의 출력은 인덱스를 사용할지 또는 전체 테이블 스캔을 수행할지를 포함하여 쿼리 실행 전략에 대한 중요한 인사이트를 제공합니다. 이 정보는 쿼리 성능을 최적화하는 데 매우 중요하며, 특히 적절한 인덱싱으로 실행 시간을 크게 줄일 수 있는 경우에 중요합니다.

애플리케이션 로그에서 가장 반복적인 SQL 쿼리를 추출하고 데이터베이스와 관련된 EXPLAIN 명령을 사용하여 성능이 느린 쿼리의 실행 경로를 분석합니다. 다음은 PostgreSQL 데이터베이스의 예입니다.

쿼리:

SELECT * FROM tenk1 WHERE unique1 < 100;

EXPLAIN 명령:

EXPLAIN SELECT * FROM tenk1 where unique1 < 100;

출력:

Bitmap Heap Scan on tenk1 (cost=5.06..224.98 rows=100 width=244) 
Recheck Cond: (unique1 < 100) 
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=100 width=0)
Index Cond: (unique1 < 100)

다음과 같이 EXPLAIN 출력을 해석할 수 있습니다.

  • 가장 안쪽에서 가장 바깥쪽(아래에서 위로) 작업까지 EXPLAIN 계획을 읽습니다.

  • 주요 용어를 찾습니다. 예를 들어, Seq Scan는 전체 테이블 스캔을 나타내고 인덱스 사용량을 Index Scan 표시합니다.

  • 비용 값 확인: 첫 번째 숫자는 시작 비용이고 두 번째 숫자는 총 비용입니다.

  • 예상 출력 행 수는 rows 값을 참조하세요.

이 예제에서 쿼리 엔진은 인덱스 스캔을 사용하여 일치하는 행을 찾은 다음 해당 행()만 가져옵니다Bitmap Heap Scan. 개별 행 액세스 비용이 더 높더라도 전체 테이블을 스캔하는 것보다 더 효율적입니다.

EXPLAIN 계획 출력의 테이블 스캔 작업은 누락된 인덱스를 나타냅니다. 최적화를 위해서는 적절한 인덱스를 생성해야 합니다.

핫스팟 식별 기법: JProfiler 분석

JProfiler는 느린 데이터베이스 호출과 CPU 집약적인 호출을 식별하여 성능 병목 현상을 해결하는 데 도움이 되는 포괄적인 Java 프로파일링 도구입니다. 이 도구는 느린 SQL 쿼리와 비효율적인 메모리 사용량을 식별하는 데 특히 효과적입니다.

쿼리 분석 예제:

select evt. com.netfective.bluage.gapwalk.rt.blu4iv.dao.Blu4ivTableManager.queryNonTrasactional

JProfiler 핫스팟 보기는 다음 정보를 제공합니다.

  • 시간 열

    • 총 실행 기간(예: 329초)을 표시합니다.

    • 총 애플리케이션 시간의 백분율을 표시합니다(예: 58.7%)

    • 대부분의 시간 소모적인 작업을 식별하는 데 도움이 됩니다.

  • 평균 시간 열

    • 실행당 기간 표시(예: 2,692마이크로초)

    • 개별 작업 성능을 나타냅니다.

    • 느린 개별 작업을 포착하는 데 도움이 됩니다.

  • 이벤트 열

    • 실행 수를 표시합니다(예: 122,387회).

    • 작업 빈도를 나타냅니다.

    • 자주 호출되는 메서드를 식별하는 데 도움이 됩니다.

예제 결과의 경우:

  • 높은 빈도: 122,387건의 실행이 최적화 가능성을 나타냄

  • 성능 문제: 평균 시간의 2,692마이크로초는 비효율성을 시사합니다.

  • 중요한 영향: 총 시간의 58.7%가 주요 병목 현상을 나타냄

JProfiler는 애플리케이션의 런타임 동작을 분석하여 정적 코드 분석 또는 SQL 로깅을 통해 명확하지 않을 수 있는 핫스팟을 공개할 수 있습니다. 이러한 지표는 최적화가 필요한 작업을 식별하고 가장 효과적인 최적화 전략을 결정하는 데 도움이 됩니다. JProfiler 기능에 대한 자세한 내용은 JProfiler 설명서를 참조하세요.

이러한 세 가지 기법(SQL 로깅, 쿼리 EXPLAIN 계획 및 JProfiler)을 함께 사용하면 애플리케이션의 성능 특성을 전체적으로 파악할 수 있습니다. 가장 중요한 성능 핫스팟을 식별하고 해결하면 원래 메인프레임 애플리케이션과 현대화된 클라우드 기반 시스템 간의 성능 격차를 해소할 수 있습니다.

애플리케이션의 성능 핫스팟을 식별한 후 다음 섹션에 설명된 최적화 전략을 적용할 수 있습니다.

메인프레임 현대화를 위한 최적화 전략

이 섹션에서는 메인프레임 시스템에서 현대화된 애플리케이션을 최적화하기 위한 주요 전략을 간략하게 설명합니다. 기존 APIs 사용, 효과적인 캐싱 구현, 비즈니스 로직 최적화의 세 가지 전략에 중점을 둡니다.

최적화 전략: 기존 APIs 사용

AWS Blu Age는 성능을 최적화하는 데 사용할 수 있는 DAO 인터페이스에서 몇 가지 강력한 APIs를 제공합니다. DAOManager와 SQLExecutionBuilder라는 두 가지 기본 인터페이스는 애플리케이션 성능을 개선하기 위한 기능을 제공합니다.

DAOManager

DAOManager는 현대화된 애플리케이션에서 데이터베이스 작업을 위한 기본 인터페이스 역할을 합니다. 특히 간단한 CRUD(생성, 읽기, 업데이트 및 삭제) 작업 및 배치 처리를 위해 데이터베이스 작업을 개선하고 애플리케이션 성능을 개선하는 여러 방법을 제공합니다.

  • SetMaxResults 사용합니다. DAOManager API에서 SetMaxResults 메서드를 사용하여 단일 데이터베이스 작업에서 검색할 최대 레코드 수를 지정할 수 있습니다. 기본적으로 DAOManager는 한 번에 10개의 레코드만 검색하므로 대규모 데이터 세트를 처리할 때 여러 데이터베이스 호출이 발생할 수 있습니다. 애플리케이션이 많은 수의 레코드를 처리해야 하고 현재 레코드를 검색하기 위해 여러 데이터베이스 호출을 수행하는 경우이 최적화를 사용합니다. 이는 대규모 데이터 세트를 반복하는 배치 처리 시나리오에서 특히 유용합니다. 다음 예제에서 왼쪽의 코드(최적화 전)는 기본 데이터 검색 값인 레코드 10개를 사용합니다. 오른쪽의 코드(최적화 후)는 setMaxResults 설정하여 한 번에 100,000개의 레코드를 검색합니다.

    SetMaxResults를 사용하여 여러 데이터베이스 호출을 방지하는 예제입니다.
    참고

    이 최적화는 메모리 공간을 늘리기 때문에 더 큰 배치 크기를 신중하게 선택하고 객체 크기를 확인합니다.

  • SetOnGreatorOrEqual을 SetOnEqual로 바꿉니다. 이 최적화에는 레코드 검색 조건을 설정하는 데 사용하는 메서드를 변경하는 작업이 포함됩니다. SetOnGreatorOrEqual 메서드는 지정된 값보다 크거나 같은 레코드를 검색하는 반면, SetOnEqual은 지정된 값과 정확히 일치하는 레코드만 검색합니다.

    정확한 일치가 필요하고 현재 SetOnEqual SetOnGreatorOrEqualreadNextEqual 사용합니다. 이 최적화는 불필요한 데이터 검색을 줄입니다.

    SetOnEqual을 사용하여 정확한 일치를 기반으로 레코드를 검색하는 예제입니다.

  • 배치 쓰기 및 업데이트 작업을 사용합니다. 배치 작업을 사용하여 여러 쓰기 또는 업데이트 작업을 단일 데이터베이스 트랜잭션으로 그룹화할 수 있습니다. 이렇게 하면 데이터베이스 호출 수가 줄어들고 여러 레코드가 포함된 작업의 성능이 크게 향상될 수 있습니다.

    다음 예제에서 왼쪽의 코드는 루프에서 쓰기 작업을 수행하므로 애플리케이션 성능이 저하됩니다. 배치 쓰기 작업을 사용하여이 코드를 최적화할 수 있습니다. WHILE 루프를 반복할 때마다 배치 크기가 미리 정해진 크기인 100에 도달할 때까지 배치에 레코드를 추가합니다. 그런 다음 미리 결정된 배치 크기에 도달하면 배치를 플러시한 다음 나머지 레코드를 데이터베이스로 플러시할 수 있습니다. 이는 업데이트가 필요한 대규모 데이터 세트를 처리하는 시나리오에서 특히 유용합니다.

    여러 작업을 단일 데이터베이스 트랜잭션으로 그룹화하는 예제입니다.

  • 인덱스를 추가합니다. 인덱스 추가는 쿼리 성능을 크게 개선할 수 있는 데이터베이스 수준 최적화입니다. 인덱스를 사용하면 데이터베이스가 전체 테이블을 스캔하지 않고도 특정 열 값이 있는 행을 빠르게 찾을 수 있습니다. WHERE 절, JOIN 조건 또는 ORDER BY 문에서 자주 사용되는 열에 인덱싱을 사용합니다. 이는 대용량 테이블이나 빠른 데이터 검색이 중요한 경우에 특히 중요합니다.

SQLExecutionBuilder

SQLExecutionBuilder는 실행할 SQL 쿼리를 제어하고, INSERT를 사용하여 특정 열만 가져오고SELECT, 동적 테이블 이름을 사용하는 데 사용할 수 있는 유연한 API입니다. 다음 예제에서 SQLExecutorBuilder는 사용자가 정의한 사용자 지정 쿼리를 사용합니다.

사용자 지정 쿼리와 함께 SQLExecutorBuilder를 사용하는 예제입니다.

DAOManager와 SQLExecutionBuilder 중에서 선택

이러한 APIs의 선택은 특정 사용 사례에 따라 달라집니다.

  • AWS Blu Age 런타임이 SQL 쿼리를 직접 작성하는 대신 생성하도록 하려면 DAOManager를 사용합니다.

  • SQL 쿼리를 작성하여 데이터베이스별 기능을 활용하거나 최적의 SQL 쿼리를 작성해야 하는 경우 SQLExecutionBuilder를 선택합니다.

최적화 전략: 캐싱

현대화된 애플리케이션에서 효과적인 캐싱 전략을 구현하면 데이터베이스 호출을 크게 줄이고 응답 시간을 개선할 수 있습니다. 이를 통해 메인프레임과 클라우드 환경 간의 성능 격차를 해소할 수 있습니다.

AWS Blu Age 애플리케이션에서 간단한 캐싱 구현은 해시 맵 또는 배열 목록과 같은 내부 데이터 구조를 사용하므로 비용 및 코드 재구성이 필요한 외부 캐싱 솔루션을 설정할 필요가 없습니다. 이 접근 방식은 자주 액세스하지만 자주 변경되지 않는 데이터에 특히 효과적입니다. 캐싱을 구현할 때는 메모리 제약 조건과 업데이트 패턴을 고려하여 캐싱된 데이터를 일관되게 유지하고 실제 성능 이점을 제공합니다.

성공적인 캐싱의 핵심은 캐싱할 올바른 데이터를 식별하는 것입니다. 다음 예제에서 왼쪽의 코드는 항상 테이블에서 데이터를 읽는 반면, 오른쪽의 코드는 로컬 해시 맵에 지정된 키에 대한 값이 없는 경우 테이블에서 데이터를 읽습니다. cacheMap는 프로그램의 컨텍스트에서 생성되고 프로그램 컨텍스트의 정리 방법에서 지워지는 해시 맵 객체입니다.

DAOManager를 사용한 캐싱:

DAOManager를 사용한 캐싱 최적화의 예입니다.

SQLExecutionBuilder를 사용한 캐싱:

SQLExecutionBuilder를 사용한 캐싱 최적화의 예입니다.

최적화 전략: 비즈니스 로직 최적화

비즈니스 로직 최적화는 최신 아키텍처 기능에 더 잘 맞추기 위해 AWS Blu Age에서 자동으로 생성된 코드를 재구성하는 데 중점을 둡니다. 이는 생성된 코드가 레거시 메인프레임 코드와 동일한 로직 구조를 유지할 때 필요하므로 최신 시스템에는 적합하지 않을 수 있습니다. 목표는 원래 애플리케이션과의 기능적 동등성을 유지하면서 성능을 개선하는 것입니다.

이 최적화 접근 방식은 단순한 API 조정 및 캐싱 전략을 넘어섭니다. 여기에는 애플리케이션이 데이터를 처리하고 데이터베이스와 상호 작용하는 방식에 대한 변경 사항이 포함됩니다. 일반적인 최적화에는 간단한 업데이트를 위한 불필요한 읽기 작업 방지, 중복 데이터베이스 호출 제거, 최신 애플리케이션 아키텍처에 더 잘 맞게 데이터 액세스 패턴 재구성이 포함됩니다. 다음은 몇 가지 예입니다.

  • 데이터베이스에서 직접 데이터 업데이트. 루프가 있는 여러 DAOManager 작업 대신 직접 SQL 업데이트를 사용하여 비즈니스 로직을 재구성합니다. 예를 들어 다음 코드(왼쪽)는 여러 데이터베이스 호출을 수행하고 과도한 메모리를 사용합니다. 특히 루프 내에서 여러 데이터베이스 읽기 및 쓰기 작업, 배치 처리 대신 개별 업데이트, 각 반복에 대한 불필요한 객체 생성을 사용합니다.

    다음 최적화된 코드(오른쪽)는 단일 Direct SQL 업데이트 작업을 사용합니다. 특히 여러 호출 대신 단일 데이터베이스 호출을 사용하며 모든 업데이트가 단일 문에서 처리되므로 루프가 필요하지 않습니다. 이 최적화는 성능 및 리소스 사용률을 개선하고 복잡성을 줄입니다. SQL 주입을 방지하고 더 나은 쿼리 계획 캐싱을 제공하며 보안을 개선하는 데 도움이 됩니다.

    루프가 있는 DAOManager 작업 대신 직접 SQL 업데이트를 사용하여 코드 재구성.
    참고

    항상 파라미터화된 쿼리를 사용하여 SQL 주입을 방지하고 적절한 트랜잭션 관리를 보장합니다.

  • 중복 데이터베이스 호출을 줄입니다. 중복 데이터베이스 호출은 특히 루프 내에서 발생하는 경우 애플리케이션 성능에 상당한 영향을 미칠 수 있습니다. 간단하지만 효과적인 최적화 기법은 동일한 데이터베이스 쿼리를 여러 번 반복하지 않는 것입니다. 다음 코드 비교는 retrieve() 데이터베이스 호출을 루프 외부로 이동하면 동일한 쿼리의 중복 실행을 방지하여 효율성을 개선하는 방법을 보여줍니다.

  • SQL 절을 사용하여 데이터베이스 호출을 줄입니다JOIN. SQLExecutionBuilder를 구현하여 데이터베이스 호출을 최소화합니다. SQLExecutionBuilder는 SQL 생성에 대한 더 많은 제어를 제공하며 DAOManager가 효율적으로 처리할 수 없는 복잡한 쿼리에 특히 유용합니다. 예를 들어 다음 코드는 여러 DAOManager 호출을 사용합니다.

    List<Employee> employees = daoManager.readAll();
for(Employee emp : employees) {
    Department dept = deptManager.readById(emp.getDeptId());  // Additional call for each employee
    Project proj = projManager.readById(emp.getProjId());     // Another call for each employee
    processEmployeeData(emp, dept, proj);
}

    최적화된 코드는 SQLExecutionBuilder에서 단일 데이터베이스 호출을 사용합니다.

    SQLExecutionBuilder builder = new SQLExecutionBuilder();
builder.append("SELECT e.*, d.name as dept_name, p.name as proj_name");
builder.append("FROM employee e");
builder.append("JOIN department d ON e.dept_id = d.id");
builder.append("JOIN project p ON e.proj_id = p.id");
builder.append("WHERE e.status = ?", "ACTIVE");

List<Map<String, Object>> results = builder.execute();  // Single database call
for(Map<String, Object> result : results) {
    processComplexData(result);
}

최적화 전략을 함께 사용

이러한 세 가지 전략은 시너지 방식으로 작동합니다. APIs 효율적인 데이터 액세스를 위한 도구를 제공하고, 캐싱은 반복적인 데이터 검색의 필요성을 줄이며, 비즈니스 로직 최적화는 이러한 APIs가 가능한 가장 효과적인 방식으로 사용되도록 보장합니다. 이러한 최적화를 정기적으로 모니터링하고 조정하면 현대화된 애플리케이션의 안정성과 기능을 유지하면서 지속적인 성능 개선을 보장할 수 있습니다. 성공의 핵심은 애플리케이션의 특성과 성능 목표에 따라 각 전략을 적용하는 시기와 방법을 이해하는 데 있습니다.

도구

  • JProfiler는 개발자와 성능 엔지니어를 위해 설계된 Java 프로파일링 도구입니다. Java 애플리케이션을 분석하고 성능 병목 현상, 메모리 누수 및 스레드 문제를 식별하는 데 도움이 됩니다. JProfiler는 CPU, 메모리 및 스레드 프로파일링과 데이터베이스 및 Java 가상 머신(JVM) 모니터링을 제공하여 애플리케이션 동작에 대한 인사이트를 제공합니다.

    참고

    JProfiler의 대안으로 Java VisualVM을 사용할 수 있습니다. 이는 CPU 사용량, 메모리 사용량, 스레드 관리 및 가비지 수집 통계에 대한 실시간 모니터링을 제공하는 Java 애플리케이션을 위한 무료 오픈 소스 성능 프로파일링 및 모니터링 도구입니다. Java VisualVM은 기본 제공 JDK 도구이므로 기본 프로파일링 요구 사항에 대해 JProfiler보다 비용 효율적입니다.

  • pgAdmin은 PostgreSQL용 오픈 소스 관리 및 개발 도구입니다. 데이터베이스 객체를 생성, 유지 관리 및 사용하는 데 도움이 되는 그래픽 인터페이스를 제공합니다. pgAdmin을 사용하여 간단한 SQL 쿼리 작성부터 복잡한 데이터베이스 개발에 이르기까지 다양한 작업을 수행할 수 있습니다. 여기에는 SQL 편집기를 강조하는 구문, 서버 측 코드 편집기, SQL, 셸 및 배치 작업을 위한 예약 에이전트, 초보 사용자와 숙련된 PostgreSQL 사용자 모두를 위한 모든 PostgreSQL 기능 지원이 포함됩니다.

모범 사례

성능 핫스팟 식별:

  • 최적화를 시작하기 전에 기준 성능 지표를 문서화합니다.

  • 비즈니스 요구 사항에 따라 명확한 성능 개선 목표를 설정합니다.

  • 벤치마킹할 때는 성능에 영향을 미칠 수 있으므로 상세 로깅을 비활성화합니다.

  • 성능 테스트 제품군을 설정하고 주기적으로 실행합니다.

  • 최신 버전의 pgAdmin을 사용합니다. (이전 버전은 EXPLAIN 쿼리 계획을 지원하지 않습니다.)

  • 벤치마킹을 위해 최적화가 완료된 후 JProfiler를 분리하면 지연 시간이 늘어납니다.

  • 벤치마킹의 경우 디버그 모드 대신 시작 모드에서 서버를 실행해야 합니다. 디버그 모드는 지연 시간을 증가시키기 때문입니다.

최적화 전략:

  • application.yaml 파일에서 SetMaxResults 값을 구성하여 시스템 사양에 따라 적절한 크기의 배치를 지정합니다.

  • 데이터 볼륨 및 메모리 제약 조건을 기반으로 SetMaxResults 값을 구성합니다.

  • 후속 호출이 인 경우에만 SetOnGreatorOrEqual을 SetOnEqual로 변경합니다.readNextEqual().

  • 배치 쓰기 또는 업데이트 작업에서 마지막 배치는 구성된 배치 크기보다 작을 수 있고 쓰기 또는 업데이트 작업으로 인해 누락될 수 있으므로 별도로 처리합니다.

캐싱:

  • 각 실행에 따라 변경processImpl되는에서 캐싱을 위해 도입된 필드는 항상 해당의 컨텍스트에서 정의되어야 합니다processImpl. doReset() 또는 cleanUp() 메서드를 사용하여 필드도 지워야 합니다.

  • 인 메모리 캐싱을 구현할 때 캐시의 크기를 조정합니다. 메모리에 저장된 매우 큰 캐시는 모든 리소스를 차지할 수 있으며, 이는 애플리케이션의 전체 성능에 영향을 미칠 수 있습니다.

SQLExecutionBuilder:

  • SQLExecutionBuilder에서 사용하려는 쿼리의 경우와 같은 키 이름을 사용합니다PROGRAMNAME_STATEMENTNUMBER.

  • SQLExecutionBuilder를 사용하는 경우 항상 Sqlcod 필드를 확인합니다. 이 필드에는 쿼리가 올바르게 실행되었는지 또는 오류가 발생했는지를 지정하는 값이 포함되어 있습니다.

  • 파라미터화된 쿼리를 사용하여 SQL 주입을 방지합니다.

비즈니스 로직 최적화:

  • 코드를 재구성할 때 기능적 동등성을 유지하고 관련 프로그램 하위 집합에 대해 회귀 테스트 및 데이터베이스 비교를 실행합니다.

  • 비교를 위해 프로파일링 스냅샷을 유지 관리합니다.

에픽

작업설명필요한 기술

JProfiler를 설치하고 구성합니다.

  1. JProfiler 다운로드 페이지에서 운영 체제(Windows, macOS 또는 Linux)용 JProfiler를 다운로드합니다.

  2. JProfiler 설명서의 지침에 따라 설치 프로세스를 완료합니다.

  3. 초기 구성을 수행합니다.

    1. JProfiler 애플리케이션을 시작합니다.

    2. 라이선스 키를 활성화합니다.

    3. 기본 JVM 설정을 구성합니다.

  4. 설치를 확인합니다.

    1. JProfiler를 시작합니다.

    2. 테스트 프로파일링 세션을 실행합니다. 지침은 JProfiler 설명서의 JVM 프로파일링 섹션에서 로컬 서비스에 연결을 참조하세요. JProfiler

앱 개발자

pgAdmin을 설치하고 구성합니다.

이 단계에서는 데이터베이스를 쿼리하도록 DB 클라이언트를 설치하고 구성합니다. 이 패턴은 PostgreSQL 데이터베이스와 pgAdmin을 데이터베이스 클라이언트로 사용합니다. 다른 데이터베이스 엔진을 사용하는 경우 해당 DB 클라이언트에 대한 설명서를 따르십시오.

  1. pgAdmin 다운로드 페이지에서 운영 체제에 대한 pgAdmin을 다운로드하고 설치합니다. 설치 중에 마스터 암호를 설정합니다.

  2. 데이터베이스 서버에 연결합니다. 지침은 pgAdmin 설명서를 참조하세요.

  3. pgAdmin 쿼리 도구를 사용하여 기본 SQL 쿼리를 실행하여 설치를 확인합니다.

앱 개발자
작업설명필요한 기술

AWS Blu Age 애플리케이션에서 SQL 쿼리 로깅을 활성화합니다.

아키텍처 섹션에 설명된 대로 AWS Blu Age 애플리케이션의 application.properties 파일에서 SQL 쿼리 로깅에 대한 로거를 활성화합니다.

앱 개발자

쿼리 EXPLAIN 계획을 생성하고 분석하여 데이터베이스 성능 핫스팟을 식별합니다.

자세한 내용은 아키텍처 섹션을 참조하세요.

앱 개발자

JProfiler 스냅샷을 생성하여 성능이 느린 테스트 사례를 분석합니다.

  1. JProfiler 시작:

    1. JProfiler 애플리케이션을 엽니다.

    2. 시작 센터에서 빠른 연결 탭을 선택합니다.

    3. 목록에서 Tomcat 프로세스를 선택합니다.

    4. 시작을 선택합니다.

  2. 프로파일링 설정 구성:

    1. 권장 샘플링 옵션을 선택합니다.

    2. 구성 화면에 기본 옵션을 그대로 두고 확인을 선택합니다.

    3. 연결됨 상태가 상태 표시줄에 표시될 때까지 기다립니다.

  3. 성능 데이터 기록:

    1. 도구 모음에서 레코딩 시작을 선택합니다.

    2. 테스트 사례를 실행하고 완료될 때까지 기다립니다.

    3. 레코딩 중지를 선택합니다.

  4. 스냅샷을 저장하고 봅니다.

    1. 스냅샷 저장을 선택합니다.

    2. 스냅샷을 저장할 위치를 선택한 다음 저장을 선택합니다.

앱 개발자

JProfiler 스냅샷을 분석하여 성능 병목 현상을 식별합니다.

다음 단계에 따라 JProfiler 스냅샷을 분석합니다.

  1. 스냅샷을 엽니다.

    1. 파일, 스냅샷 열기를 선택합니다.

    2. 저장된 스냅샷 위치로 이동합니다.

    3. 분석을 시작하려면 새 창 열기를 선택합니다.

  2. 데이터베이스 작업 분석:

    1. JDBC/데이터베이스 섹션으로 이동하여 JPA/최대 절전 모드 탭을 선택합니다.

    2. 시간별로 쿼리를 검토합니다(기본 정렬 옵션).

    3. 최적화를 위한 최상위 쿼리를 선택합니다.

  3. CPU 사용량 검토:

    1. CPU 섹션에서 핫스팟 뷰를 선택합니다.

    2. 최적화를 위한 시간 백분율로 최상위 코드를 식별합니다.

    3. 반복되는 패턴을 기록해 둡니다.

  4. 핫스팟을 식별한 후 다음 에픽에서 설명한 대로 기준을 설정한 다음 적절한 최적화 전략을 구현합니다. 다음과 같은 최적화에 중점을 둡니다.

    • 느린 쿼리의 경우 SQLExecutionBuilder 또는 DAOManager 최적화를 사용합니다.

    • 빈번한 데이터 액세스를 위해 캐싱 메커니즘을 구현합니다.

    • 복잡한 비즈니스 로직의 경우 로직을 단순화하고 데이터베이스 호출을 너무 많이 수행하지 않으며 간단한 쿼리를 실행하여 코드를 단순화할 수 있는지 확인합니다. 예를 들어 코드가 테이블 A의 데이터를 테이블 B에 삽입하는 경우이 코드를 다시 작성하여 다음과 유사한 SQL 명령을 실행합니다.

      INSERT INTO TABLE A SELECT * FROM TABLE B

  5. 애플리케이션이 성능 요구 사항을 충족할 때까지 영향을 순서대로(가장 높음에서 낮음) 코드를 계속 분석하고 최적화합니다.

JProfiler 사용에 대한 자세한 내용은 아키텍처 섹션 및 JProfiler 설명서를 참조하세요.

앱 개발자
작업설명필요한 기술

최적화를 구현하기 전에 성능 기준을 설정합니다.

  1. 초기 성능 측정으로 최적화 없이 테스트 사례를 실행합니다. 현재 상태의 JProfiler 스냅샷을 생성하고 다음 지표를 문서화합니다.

    • 총 실행 시간

    • 데이터베이스 호출 수

    • CPU 사용률

    • 메모리 사용 패턴

  2. 문서 기준을 생성합니다.

    1. 타임스탬프 및 테스트 조건을 사용하여 모든 지표를 저장합니다.

    2. 성능에 영향을 미칠 수 있는 외부 요인을 기록해 둡니다.

    3. 최적화 후 비교를 위해 JProfiler 스냅샷을 저장합니다.

  3. 다음 에픽에 설명된 최적화 변경 사항을 계획합니다.

    1. 기준 지표를 검토합니다.

    2. 최적화하려는 작업을 식별합니다.

    3. 현재 코드의 백업을 생성합니다.

    4. 예상되는 개선 사항을 문서화합니다.

  4. 구현 전에 각 변경 사항을 측정합니다.

    1. 기준 조건을 사용하여 테스트 사례를 실행합니다.

    2. 실행 시간을 기록합니다.

    3. 현재 동작을 문서화합니다.

앱 개발자
작업설명필요한 기술

읽기 호출을 최적화합니다.

DAOManager SetMaxResults 메서드를 사용하여 데이터 검색을 최적화합니다. 이 접근 방식에 대한 자세한 내용은 아키텍처 섹션을 참조하세요.

앱 개발자, DAOManager

데이터베이스에 대한 여러 호출을 방지하기 위해 비즈니스 로직을 리팩터링합니다.

SQL JOIN 절을 사용하여 데이터베이스 호출을 줄입니다. 자세한 내용과 예제는 아키텍처 섹션의 비즈니스 로직 최적화를 참조하세요.

앱 개발자, SQLExecutionBuilder

캐싱을 사용하여 읽기 호출의 지연 시간을 줄이도록 코드를 리팩터링합니다.

이 기법에 대한 자세한 내용은 아키텍처 섹션의 캐싱을 참조하세요.

앱 개발자

간단한 업데이트 작업을 위해 여러 DAOManager 작업을 사용하는 비효율적인 코드를 다시 작성합니다.

데이터베이스에서 직접 데이터를 업데이트하는 방법에 대한 자세한 내용은 아키텍처 섹션의 비즈니스 로직 최적화를 참조하세요.

앱 개발자
작업설명필요한 기술

기능적 동등성을 유지하면서 각 최적화 변경을 반복적으로 검증합니다.

  1. 최적화를 구현한 후:

    1. 설정한 기준과 동일한 테스트 사례를 실행합니다.

    2. 새 실행 시간을 기록합니다.

    3. 결과가 기준 출력과 일치하는지 확인합니다.

  2. 최적화가 개선되면 실제 이익을 문서화한 다음 다음 최적화를 진행합니다.

    문제가 발견되면 변경 사항을 롤백하고 접근 방식을 검토한 다음 대체 솔루션을 시도합니다.

  3. 각 변경 사항에 대한 진행 상황을 추적합니다.

    1. 새 지표를 기준 지표와 비교합니다.

    2. 개선 비율을 계산합니다.

    3. 실행 중인 총 이득을 유지합니다.

참고

기준 지표를 참조로 사용하면 시스템 신뢰성을 유지하면서 각 최적화의 영향을 정확하게 측정할 수 있습니다.

앱 개발자

문제 해결

문제Solution

최신 애플리케이션을 실행하면 오류가 있는 예외가 표시됩니다Query_ID not found.

이 문제를 해결하려면:

  1. 이름이 인 파일이 애플리케이션 서버의 작업 디렉터리에 있는 sql 폴더에 query.sql 존재하는지 확인합니다.

  2. .sql 파일 이름이 프로그램 이름과 일치하는지 확인합니다. 예를 들어 이름이 인 프로그램의 경우 ABC파일 이름은 여야 합니다ABC.sql.

인덱스를 추가했지만 성능 개선이 보이지 않습니다.

다음 단계에 따라 쿼리 엔진이 인덱스를 사용하고 있는지 확인합니다.

  1. PostgreSQL을 사용하는 경우 명령을 실행합니다EXPLAIN <sql query>.

  2. Seq Scan 또는에 대한 명령의 출력을 확인합니다Index Scan.는 SQL 쿼리의 where 절에서 사용 중인 열에서 인덱스 세트를 사용할 수 없음을 Seq Scan 의미합니다.

  3. 올바른 열 집합에 인덱스를 생성하고 생성된 인덱스를 사용하는 쿼리를 생성해 봅니다.

out-of-memory 예외가 발생합니다.

코드가 데이터 구조에서 보유한 메모리를 해제하는지 확인합니다.

일괄 쓰기 작업으로 인해 테이블에 레코드가 누락됨

코드를 검토하여 배치 수가 0이 아닐 때 추가 쓰기 작업이 수행되는지 확인합니다.

SQL 로깅은 애플리케이션 로그에 표시되지 않습니다.

  1. 로깅 구성 파일 위치 및 구문을 확인합니다.

  2. 지정된 패키지에 DEBUG 대해 로그 수준이 로 설정되어 있는지 확인합니다. 예:

    level.com.netfective.bluage.gapwalk.rt.blu4iv.dao: DEBUG
level.org.springframework.jdbc.core: DEBUG

  3. 애플리케이션 서버 로그 파일 권한을 확인합니다.

  4. 구성을 변경한 후 애플리케이션 서버를 다시 시작합니다.

관련 리소스