사례에서 배우는 성능을 고려한 소프트웨어 아키텍처 - KOSTA...2 제8회 2015 한국 소프트웨어 아키텍트 대회 성능이 저하된 시스템 개선을

제8회 2015 한국 소프트웨어 아키텍트 대회

2015(제8회) 한국 소프트웨어 아키텍트 대회

사례에서 배우는 성능을 고려한 소프트웨어 아키텍처

2015. 07. 16

LG CNS

권문수 총괄 컨설턴트

제8회 2015 한국 소프트웨어 아키텍트 대회 2

성능이 저하된 시스템 개선을 지원하다 보면

프레임워크에 이런 기능이 포함되어 있으면 좋을텐데…

초기 소프트웨어 아키텍처 설계 시에 고려되어었야 하는데…

제8회 2015 한국 소프트웨어 아키텍트 대회

Web Presentation

3

성능을 고려한 소프트웨어 아키텍처 설계

성능개선에서 일반적으로 나타나는 일부 개선사항을 공유하여 소프트웨어 아키텍처 설계 시에

검토될 수 있도록 한다

Browser Server Application Data

Client Application

Static Contents

Service Logic Data

Access Database

Security Control

Business Logic

Business Rule

Encode / Decode

Compress

Schema DAO

Security

HTTPS JDBC

캐시

통신 전문

로깅

대량조회

인스턴스 구성


캐시 – 캐시 적용

대량처리 시스템에서 캐시의 적용은 선택이 아니라 필수이다

유형 설명 장점 단점

로컬 Method 레벨에서 데이터 저장 (~수십MB) 구현이 간단함 적용 범위가 작음

세션 WAS 세션에 데이터 저장 (~수KB) 사용자 서비스 요청 간에 데이터

공유

인증, 사용자 정보 등 극소량 데

이터에 제한적으로 사용함

인스

턴스

WAS 내부 힙 메모리에 데이터 저장하여

인스턴스마다 별도 캐시 존재 (~수백MB) 소량인 경우 경우 최고의 성능

중복 캐시로 메모리 낭비

Full GC시 성능저하 가능성

캐시

솔루션

Key-Value 형태의 캐시 솔루션으로 Redis,

Memcached, InfiniSpan이 대표 OSS임

(~ OS 메모리 한계)

WAS 메모리 절약

Failover, Replication, Persistence,

TTL, Sharding등 제공 솔루션 존재

통신 및 Serialize/Deserialize 오

버헤드가 존재

어플리케이션 서버

캐시 솔루션 캐시 서버

DB 서버

포탈화면 앱 목록 정보 방송 정보

공통코드

영업일 고객정보

상품 팩토리 연계 모듈

환경설정, 사용자 서비스 설정, SQL

인스턴스 캐시

로컬 캐시

서비스결과

세션 기초 정보

서브 모듈 결과 조회 결과

사용자

어플리케이션 수행 전 구간에 캐시 적용이 가능하다

인스턴스 캐시는 HashMap(초기로딩), Hashtable(지연로딩)로

간단히 적용할 수도 있다

세션 캐시


캐시 – 캐시 적용(계속)

성능개선 시에 캐시는 항상 검토되고, 개선효과도 크게 나타나는 부분이다

사례유형 문제점 개선방향

앱 스토어 1000TPS 이상 서비스 처리

단순한 업무지만 WAS/DB 과부하 발생

국가, 모델별 앱 목록 서비스 결과 캐시

인스턴스 캐시 적용(24시 초기화, 상시 초기화 가능)

과금

1600 TPS 이상 서비스 처리

메모리 DB 사용

처리량 증가로 성능개선이 필요해짐

메모리 DB를 사용하지만 수행빈도 1위와 수행시간

1위 쿼리를 어플리케이션에서 캐시하여 성능개선

(공통 코드, 상품정보 데이터)

인스턴스 캐시 적용(24시 초기화)

금융 성능이 요구되는 업무에서 상품 팩토리에 의

한 성능저하 발생

사례1)

상품 팩토리 모듈 처리결과 캐시

캐시 솔루션(24시 초기화, 상시 초기화 가능)

사례2)

상품 팩토리 SQL 조회결과 캐시

인스턴스 캐시 (1만개 한계, 24시 초기화)

입사지원 입사지원 시 사용하는 어플리케이션은 한정

적이나 공통코드를 빈번하게 조회함

사용빈도가 높은 24개 공통코드 캐시

인스턴스 캐시 적용(1시 주기 초기화, 상시 초기화)

금융 배치 대량 데이터 처리 시 공통 참조 데이터 성격

의 SQL 반복 수행이 성능에 영향을 미침

공통 성격의 데이터를 사전에 조회하여 반복 사용하

기 위해 인스턴스 캐시 적용

개선사례

DB와 데이터 동기화 조건이 의외로 복잡하지 않거나 실시간일 필요가 없는 경우가 많다


캐시 – 요청 캐시

단일 서비스 내에서 업무 로직이 복잡하여 동일한 쿼리나 서브 모듈이 반복 호출되는 경우

요청 캐시(Request cache)를 적용하면 제거할 수 있다

개별 스레드인 사용자 서비스 호출 단위 내에서만 유효한 캐시이다

자바의 경우 ThreadLocal이나 Service Context를 캐시 저장소로 사용하며, 사용자 서비스 호출(HTTP Request)이 시작될 때 캐시가 초기화되고, 호출이 종료되면 캐시가 제거된다

스레드 간에 캐시는 공유되지 않고, 데이터의 생명주기가 짧아 DB와 데이터 동기화에 대한 부담이 없다

단일 서비스 요청 내에서만 동작하므로 캐시 Hit률은 낮으나, 다양한 쿼리에 캐시를 적용할 수 있는 장점이 있다

프레임워크에 캐시 로직을 추가하면 응용 코드 수정을 최소화할 수 있다 (캐시 시킬 모듈과 SQL ID를 서비스 시작부분이나 DB 환경설정 정보에 추가하는 것만으로 캐시 동작)

요청 캐시 특성


금융1 처리 단위당 수천 건에서 수만 건씩 데이터를 처리

데이터 처리건 간에 동일한 빈번한 동일 쿼리 수행

프레임워크의 공통 DAO 요청 캐시 적용

하여 제거

금융2

사업 특성상 핵심업무의 복잡도가 높음

복잡도가 높으면서도 내부는 반복 로직이 다수 존재

CBD 개발로 타 모듈간에도 동일한 공통 정보 조회가 빈

번함

프레임워크의 공통 DAO에 요청 캐시 적

용 및 프로그램 일부 모듈 단위에 캐시

코드 추가하여 반복 호출 제거

동일 업무 차세대(3곳 적용)

개선사례


캐시 – 요청 캐시 로직

서비스 요청

서비스 종료

RequestCache ThreadLocal (캐시)

cache (HashMap)

sql_id (HashMap)

sql_id (HashMap)

CacheFilter (doFilter)

RequestCache.initialize()

RequestCache.remove()

캐시 초기화

캐시 제거

SalesMngt (processSale)

RequestCache.set(sql_id)

캐시할 sql_id 지정 Framework DAO (executeQuery)

HashMap<String, HashMap> cache =RequestCache.get(sql_id)

해당 쿼리의 캐시 사용 여부 확인(캐시가 미지정이면 null 반환)

if(cache != null){ 동일 바인드 변수로 캐시된 데이터가 있으면 복제해서 반환 }

if(cache != null){ 조회값을 복제해 캐시에 저장 }

SQL 수행

반환되는 cache는 sql_id의 HashMap

①

② ③

④

요청 캐시 구조 요청 캐시의 기본 구조는 단순하다

서비스 ID별 적용 SQL ID를 관리하는 설정을 두면

편리하다


캐시 – 시스템 캐시 구성

복수 캐시 사용 (A 금융)

요청캐시 캐시

인스턴스 캐시

캐시 솔루션

캐시서버 A, B (Redis)

AP서버 A, B

분산저장(Sharding)

소량 데이터, 변경가능성 낮음, 다수 프로그램에서 사용 공통코드 조직코드 …

적용범위 넓음, 서비스 내 무수정, 단일 서비스 요청 내 중복 호출 제거 고객정보 인사정보 조직정보 권한정보 상품팩토리 (프로세스 공유 캐시와 중복) 업무처리룰 (프로세스 공유 캐시와 중복) …

대량 데이터, 변경 가능성 낮음, 다수 프로그램에서 사용 <8:2의 원칙에 따라 일부 적재> 상품팩토리 업무처리룰 소수 SQL 상품팩토리와 업무처리룰은 테이블 적재가 아니라 비즈니스 모듈단위 적재로 데이터량을 줄이기 위해 8:2의 원칙에 따라 각 10개 내외 모듈 서비스 ID 적재함

요청캐시가 프로세스 공유 캐시보다 우선 적용된다 (요청캐시가 속도가 빠름)

어플리케이션에 따라 선별적으로 캐시가 적용된다


캐시

코드 데이터에 대한 반복 조회 존재

인사 공통, 조직 공통 데이터에 반복 조회

어플리케이션간에 반복 쿼리 수행

사용자는 많으나 단순한 로직으로 처리되는 결과가 한정적인 경우가 많다 (IPTV, 단말 App 관리, 포탈)

단순한 로직의 대량 수행

컴포넌트 기반으로 다수의 개발자가 서로 유관 프로그램 개발 시 반복 쿼리 수행이 다수 발생한다

단일 서비스 내 반복 쿼리/로직 수행

캐시를 적용한 쿼리/로직 수행 제거

요청 캐시를 적용한 쿼리 제거

캐시 솔수션(Redis, MemCached)

간단한 캐시 코드(HashMap, Hashtable)

SQL 조회결과보다 업무 처리결과를 캐시하는 것이 효과가 크다 (생각보다 할 수 있는 경우가 많다)

■ 어플리케이션의 문제점 ■ 개선사례

사용자 서비스 요청 단위내에서 반복되는 쿼리나 로직 제거


로깅 – 요청단위 로그레벨 설정

환경설정 정보

Thread 1

Thread 2

Logging Logging

Logging Logging

Service A 요청

Service B 요청

참조

참조

참조 참조

환경설정 정보

Thread 1

Thread 2

Logging Logging

Logging Logging

Service A 요청

Service B 요청

참조

참조 참조

참조

Service Context

Service Context B 요청의

로그레벨 값

A 요청의 로그레벨 값

서버/인스턴스 단위로 전체 사용자가 동일한 로그 레벨을 적용 받는다

테스트는 느리고, 운영은 성능저하가 우려되어 디버그를 상상할 수도 없다

금융권에서 서비스ID 단위로 조정하기도 한다

사용자 서비스 전문 내에 로그레벨 설정이 가능한 구조를 설계한다 (기본 값은 전문 내에 로그 레벨이 없음)

필요에 따라 서비스 개별 호출 단위로 로그레벨 설정이 가능하도록 한다

서비스 전문 내에 존재하는 로그레벨이 환경설정 정보 내에서 로그레벨보다 높은 우선순위를 갖는다

테스트 서버 성능향상

테스트 재현이 어려운 경우, 운영서버에서 상세 로깅이 가능하다

서버/인스턴스 단위 로그 설정

요청 단위 로그 설정

적용사례: 통신 차세대


로깅 – 온라인상에서 로그레벨 조정

Info Info Error

이벤트 전에 로그레벨을 관리화면에서 동적으로 조정할 수 있도록 개선하였다

Info 모드 로깅이 전체 CPU 사용량의 38%를 사용하지만 평상시는 안정적으로 운영된다

판매/가입 촉진을 위한 이벤트 시 사용자가 폭주하여 CPU 자원 부족으로 서비스 장애가 발생하였다

서비스 오류로 사용자 불만 접수 시 상세한 로그가 필요하다

시간

Info

서비스 장애

처리량

단일 로그 레벨 유지

온라인 로그 레벨 변경

적용사례: B2C 결제시스템

시스템운영자 JSP 또는 Servlet

import org.apache.log4j.LogManager; import org.apache.log4j.Level; Import java.util.Enumeration Enumeration en = LogManager.getLoggerRepository().getCurrentCategories(); while(en.hasMoreElements()){ ((Catetory)en.nextElement()).setLevel(Level.ERROR); }


로깅 – 저널로그의 비동기/집합처리

A 서비스

데이터베이스

B 서비스

실시간 DB 입력

동기/직접 DB입력

비동기/집합 처리

로그 데몬 프로세스 로그 데몬 프로세스

A 서비스

데이터베이스 B 서비스

로그파일(1만건씩 동시 10개)

로그 데몬 프로세스

1천건 Bulk Insert 처리 (집합처리, 일부 실패 시 보완로직 포함)

비동기처리 분산처리 테이블 범위 파티션(10개)

저널 로그기반으로 정산 및 통계가 이루어져 꼭 저장해야 하는 중요 데이터이다

전 세계를 대상으로 하는 B2C 시스템으로 처리 TPS가 높아 저널 로그로 인한 성능저하로 장애가 발생하였다

AP서버 로컬 파일에 저널로그를 기록하도록 변경하였다

파일 쓸 때 락을 회피하기 위해 로그파일도 동시에 10개를 사용하여 병렬 처리함으로써 속도 보장하였다

저널 로그 파일은 별도 데몬 프로세스에 의해 DB에 Bulk Insert 처리하였다

일반적인 성능개선 기법인 병렬에 의한 분산처리, 비동기처리,

집합처리가 사용되었다

적용사례: B2C 앱시스템


로깅 – 자원낭비 코드수정

for ( int inx = 0; inx < outputFilList.getDataCount(); inx++ ) { output = outputFilList.getLData( inx ); LLog.debug.println( "## [파일서버에 전송할 입력 매개변수]## " ); LLog.debug.println( "파일서버에 전송할 입력 매개변수: " + output ); “String” + Object 존재 LLog.debug.println( "############################" ); … 생략 … } 로깅 여부를 미리 확인해 해당 코드가 수행되지 않게 한다 for ( int inx = 0; inx < outputFilList.getDataCount(); inx++ ) { output = outputFilList.getLData( inx ); if(LLog.debug.isEnabled()){ “문자열” + 객체가 수행되지 않도록 조건부 처리 LLog.debug.println( "## [파일서버에 전송할 입력 매개변수]## " ); LLog.debug.println( "파일서버에 전송할 입력 매개변수: " + output ); LLog.debug.println( "############################" ); } … 생략 … }

“String” + Object 특히 Collection Object 회피 로깅여부 if문 적용

LLog.debug.isEnabled()의 빈번한 호출 회피 local 변수 사용 isDebug = Llog.debug.isEnabled(); if(isDebug){ ……. }

운영 시에는 로깅이 되지 않음에도 불필요하게 필요 이상 많은 CPU 자원을 사용하는 경우가

있는데 개발 시 가이드와 검토가 필요하다


로깅

로깅으로 인한 성능저하로 테스트 지연

많은 로그로 원인분석에 필요한 로그를 찾는데 어렵다

■ 로깅의 문제점 ■ 개선사례

개발 시 테스트 어려움

성능저하를 우려해 로깅 레벨을 낮출 수 없다

온라인 상태에서 로그 레벨을 조절할 수 있는 기능이 없다

운영 시 디버그 어려움

저널 로그를 온라인으로 처리하여 성능저하

대량처리에서 저널로그 성능저하

로깅 여부에 상관없이 CPU 자원을 사용하는 코딩 스타일

자원 낭비

요청단위로 로그레벨 설정

온라인상에서 로그레벨 조정

저널로그의 비동기/집합 처리

자원낭비 코드 수정


통신전문 – 전문유형별 특성

전문 종류 처리 성능 메모리 사용량 전문 크기

XML 4 1 (가장 많음) 1 (가장 큼)

JSON 3 2 2

텍스트 기반 구분자 2 3 3

바이너리 1 (가장 빠름) 4 4

대량 데이터 처리나 네트워크 환경이 열악한 경우 XML, JSON 이외 다른 전문 포맷도 검토한다


해외서비스

해외사용자 RTT 100~ 400ms

HTTP 통신

응답시간 저하

바이너리 전문 적용

Keepalive 시간 연장

NULL 항목 비전송

국내 대량 데이터

조회 건수가 5,000건 이상인 화면들이 다수 존재

XML 기반 전문처리

OutOfMemoryError와 응답시간 저하 발생

항목명을 1회만 명기하는 변형 JSON 적

용

다수 전송속도로 인해 속도저하

콘텐츠 크기로 인한 속도저하

텍스트 압축 원문크기 압축크기 압축률 51,635 2,669 94.9% 14,361 1,224 91.5% 5,182 840 83.8%

최적화된 이미지(품질조정)

화면 구성 콘텐츠 수 축소 및 Aging 적용

개선사례

전문비교


통신전문 – 전문유형별 특성

네트워크 턴 수를 증가시키는 요소는 어플리케이션 턴 수와 전문크기 외에 네트워크 연결종료와

Slow start가 있다 (KeepAlive 적용, 전문 크기 감소 방안 적용)

5

6

7

8

재전송 타임아웃 중복

ACK

혼잡 탐지 혼잡 윈도우 크기

시간 연결

1

2

4

8

10

12 12

1

2

4

8 9

10 11

1

2

4

6

7

8 9

10

중복 ACK로 인해 윈도우 50% 수준에서 혼잡 회피 시작

재전송 타임아웃 인해 다시 슬로우 스타트

슬로우 스타트

혼잡 회피

혼잡 회피

윈도우의 50% 감소

ssthresh (slow start threshold)

슬로우 스타트 (1부터 2배씩 증가)

혼잡 회피 (1씩 증가)

ssthresh

국가 인도네시아 호주 미국 네덜란드 페루 RTT 120ms 150ms 190 ~ 200ms 220 ~ 300ms 320 ~ 500ms

시스템 위치 RTT(가정) 서비스

네트워크 턴 수 네트워크 소요시간

(=RTT * 네트워크 턴 수) 시스템

처리 시간 사용자

응답시간 로컬 네트워크 2 ms

100 200 ms

3,000 ms 3,200 ms

한국 10 ms 1,000 ms 4,000 ms 유럽 220 ms 22,000 ms 25,000 ms

한국에서 국가별 RTT

RTT에 따른 응답시간 차이


통신전문 – 병렬처리

클라이언트에서 서버 서비스 요청의 병렬처리는 성능을 확보하기 위한 기본 요소이다

시간

콘텐츠

병렬처리

순차처리

웹 브라우저는 도메인당 6개 이상 네트워크 연결을 맺어 병렬(동시)처리함으로써 응답시간을 개선한다

서버 내 서비스 개별 처리시간은 빠르나 클라이언트와 서버간 서비스 요청을 순차 처리하여 성능이 저하되는 경우들이 있다 (클라이언트 솔루션 – A, B 금융, 클라이언트 프레임워크 – C 금융)

개선

선정할 화면 솔루션이 병렬처리가 가능한지 검토한다

클라이언트 화면 프레임워크 또한 병렬처리를 염두에 두고 선정 또는 개발한다

순차처리에 의한 성능저하는 서버 내부의 성능개선으로는 개선효과가 제한적이다

병렬처리 외에 AJAX를 사용한 비동기 처리하는 것도 성능개선 방안이다

시간

콘텐츠

개별 서버 서비스 요청


통신전문

데이터 수천 건 이상를 XML 전문 처리 시 CPU 사용량 증가하고 전문 크기 증가하여 성능이 저하된다

해외 사용자는 RTT(Round Trip Time)으로 인한 영향도가 높다

■ 통신전문의 문제점 ■ 개선사례

환경을 무시한 전문구성

클라이언트와 서버간 순차처리에 의한 성능저하가 발생하는 경우가 있다

성능을 고려하지 않는 통신 구조

전문크기 감소

연결유지(KeepAlive)

병렬 통신 처리

바이너리 포맷 전문 적용

변형 JSON 적용

NULL 항목의 비전송 알고리즘 적용

압축

TCP Connection handshake 회피

TCP Slow start 회피


기타 – 대량조회 아키텍처

대량 조회로 인한 시스템 장애나 성능저하는 시스템 오픈 초기 흔하게 나타나는 문제이다

일반 개선방안 설명

최대 조회건수 제약 DAO의 Select에서 조회 가능한 건수를 제약하여 예방

조회조건 강화 데이터 조회건수를 줄일 수 있는 조건이 필수 조회조건으로 입력하도록 제약

페이징 처리 모든 목록 조회를 페이징 처리하여 한번에 Select하는 건수 제약

별도 인스턴스 구성 대량 건을 조회하는 업무는 별도 인스턴스로 구성하고 일반 온라인 업무가 영향을 받

지 않도록 구성함

파일 다운로드 대량 건은 서버 내에서 목록을 파일로 생성한 다음 다운로드함

대량 조회를 인한 급진적인 메모리 누수

시간

자바 힙 사용량

일정한 값 유지

순간적으로 급격히 증가

OutOfMemory

부주의한 페이징으로 인한 전체건 조회 시 트랜잭션 분포

시간

서비스 처리시간

첫 페이지부터 마지막 페이지까지 읽어오는데 사용된 서비스 호출의 분포


기타 – 대량조회 아키텍처

비즈니스 모듈

프레임워크 DAO

JDBC ResultSet Statement

Connection

LargeResult result = null; try { result = LargeDao.execute(sql, inputData); ResultSet rs = result.getResultSet(); ArrayList meta = makeMetaData(rs); LData readData, processedData writeHeader(): while(rs.next()){ readData = makeLData(rs, meta); processedData = processBusiness(readData); writeMessage(processedData); } writeTail(); } finally { if(result != null){ result.close(); } }

매 건마다 전문 생성

Connection con = get Connection(); PreparedStatement stmt = con. prepareStatement(sql) stmt.setString(…); ResultSet rs = stmt.executeQuery(); LargeResult result = new LargeResult(con, stmt, rs); return result;

JDBC ResultSet과 사용자에게 전달되는 전문생성을 직접 연동하면 조회 데이터 건수와

무관하게 메모리 사용량은 증가하지 않고, 데이터 액세스는 1회로 끝난다

여기에 일반적으로 적용되는 개선안을 같이 적용하면 효과적이다 긴 타임아웃 적용을 위해 대량조회는 별도 WAS 인스턴스 구성(URL 구분 가능해야 함) 일반 OLTP는 최대 조회가능 건수를 제약하여 대량조회를 차단


기타 – 업무별 인스턴스 구성

Full GC시에 시간이 오래 걸리는 단계는 Compact이며, Compact는 살아있는 오브젝트의 양에

가장 큰 영향을 받으므로 살아있는 오브젝트가 적도록 WAS 인스턴스를 구성한다

WAS Heap

Live objects

통합 WAR

웹 서버

A,B,C 업무 A,B,C 업무 A,B,C 업무

통합 WAR

웹 서버

A 업무 B 업무 C 업무

GC후 살아있는 오브젝트량이 감소함

업무별 서비스 인스턴스

통합 서비스 인스턴스

로딩 클래스 감소 캐시 정보 감소

- 서비스 기초정보(전문,제어) - SQL 문자열 - 응용 캐시

배포는 통합 WAR로 하여 A업무에서 B업무가 연계되는 경우 A업무가 있는 인스턴스에서 연계된 B업무가 수행되도록 함(XA 회피)

업무 그룹별로 웹 서버에서 라우팅할 수 있는 URL 경로를 가지고 있어야 한다

사용 데이터만 로딩하도록 지연로딩을

사용해야 한다


기타 – 서비스 다중화 구성

시스템 가용성은 서버와 WAS 인스턴스 수가 많을수록 높아진다

x86 리눅스 서버

A, B, C

유닉스 서버

인스턴스

A B C

장애 시 Failover를 고려할 때 AP 서버 대수와 인스턴스 수가 많은 것이 유리하다

단일 서버 내에서도 인스턴스를 다중화하면 장애 시 영향도를 낮출 수 있다

OSS의 사용이 증가할수록 앞으로 더욱 x86 리눅스 서버의 사용 또한 증가할 것이고, 서버와 인스턴스 다중화는 일반화될 것이다

다중화함으로써 인스턴스당 처리하는 트랜잭션이 감소하여 GC 발생빈도가 감소하고 Old 영역으로 넘어가는 메모리량이 감소하여 인스턴스당 Full GC 발생빈도가 감소하여 서비스 시간이 보다 안정화되는 측면도 있다

서버와 인스턴스 수가 증가할수록 장애 영향도 감소


기타 구성

인스턴스가 2개면 1개 장애 시 다른 인스턴스의 서비스 요청은 100% 증가하게 된다

서비스가 집중되면 내부 락에 대한 경합이 증가하여 서비스 성능이 저하된다

인스턴스가 적으면 GC에 의한 영향도가 증가한다

■ 문제점 ■ 개선사례

인스턴스 2개만으로는 안정성 부족

Full GC에서 오래 걸리는 부분은 Compact이며, 이는 Live 오브젝트량에 좌우된다

한 인스턴스에서 전체 서비스를 처리하면 메모리 사용량이 증가한다

GC로 인한 성능저하

일반 프레임워크는 조회결과를 Collection 객체에 담아서 전달하므로 대량 조회에는 취약한 구조이다

대량 조회로 인한 서비스 장애 및 성능저하

서비스 다중화 구성

업무 유형별 인스턴스 구성

대량건 처리 프레임워크 구성

업무별 인스턴스 구성

지연로딩 적용

JDBC ResultSet과 OutputStream 연결

서비스 가용성이 증가


성능개선 방안

① 병렬/분산 처리

화면 내 서비스 요청을 병렬로 처리할 수 있는가?

서버내 오래 걸리는 작업들을 병렬로 처리할 수 있는가?

웹 서버, 애플리케이션 서버의 작업 스레드 풀과 DB 연결 풀 등 병렬 자원을 늘릴 수 있는가?

트랜잭션이 집중되는 테이블은 파티션으로 분산할 수 있는가?

DB를 분산 저장(Sharding)해서 사용자 요청을 분산할 수 있는가?

파일 입출력을 분산해 병렬 처리할 수 있는가?

② 비동기 처리

화면에서 처리 시간이 오래 걸리는 항목을 비동기 처리할 수 있는가?

온라인 서비스에 포함된 필수 작업 이외에 부가 기능을 후행(비동기) 처리할 수 있는가?

디스크 입출력을 비동기 처리할 수 있는가?

업무 처리와 로깅 작업을 비동기로 분리할 수 있는가?

③ 캐시

반복 사용되는 DB 조회 결과를 캐시할 수 있는가?

반복되는 계산 값을 캐시할 수 있는가?

프레임워크와 애플리케이션 로직에서 사용하는 기초 데이터는 캐시됐는가?

상품 팩토리처럼 변경주기가 길고, 빈도는 낮은 기준 정보를 캐시할 수 있는가?

화면의 정적 콘텐츠를 캐시할 수 있는가?

게시판 목록 같은 포털 메인 화면의 일부를 캐시할 수 있는가?

성능개선이 필요한 시스템이 있을 때 아래 질문에 해당 부분이 있는지 체크해 본다


성능개선 방안(계속)

④ 집합 처리

처리 건수가 많은 DB DML은 집합처리하고 있는가?

DB Fetch 단위당 건수는 적절한가?

파일을 읽고 쓸 때 레코드 단위로 처리하는가? 파일을 읽고 쓰는 단위가 너무 작지 않은가?

네트워크 데이터는 대량으로 송수신하고 있는가?

웹 화면에서 HTTP 호출 수를 줄일 수 있는가? (애플리케이션 턴 수를 줄일 수 있는가?)

⑤ 오버헤드 제거

필요한 결과를 얻기 위한 최적화된 로직인가?

불필요하게 수행되는 쿼리나 로깅이 없는가?

업무 로직에서 필요 이상의 DB 데이터를 조회하는가?

스레드 내 또는 스레드 간에 반복 수행되는 기능을 제거할 수 있는가?

필요 이상으로 크게 설정된 자원이 존재하는가?

⑥ 경합 제거

배타적으로 락을 획득해서 수행하는 코드는 락 범위가 필요한 부분만으로 최소화됐는가?

업무 처리 단계에서 DB 락을 최소화하도록 경합 DML이 로직 뒤에 위치하는가?

로그 파일에 경합이 발생하고 있는가?

⑦ SQL 개선

실행 계획은 적절한가? (적절한 인덱스를 사용하고 있는가? 전체 테이블 스캔하는 SQL이 존재하는가?)

주기적으로 테이블 통계는 갱신되고 있는가?

SQL의 바인드 변수 처리는 잘 돼 있는가?


성능개선 방안(계속)

⑧ 송수신 효율화

송수신 전문은 네트워크 특성을 고려해 적절한 크기를 가지는가?

네트워크 턴 수를 줄일 수 있는가?

압축해서 전송할 수 있는가?

전송하는 이미지는 크기를 최소화하는 이미지 품질과 포맷을 가지고 있는가?

네트워크 전송 품질(RTT, 재전송)을 개선할 수 있는가?

⑨ 자원 사용 효율화

CPU를 많이 사용하는 함수를 개선 또는 대체할 수 있는가?

메모리 사용량을 줄일 수 있는가?

불필요한 파일 입출력을 제거할 수 있는가?

메모리 누수를 제거할 수 있는가?

자바 GC를 효율적으로 수행할 수 있는가?

자바 GC를 효율화하기 위해 메모리 사용 패턴을 개선할 수 있는가?

⑩ 물리적인 자원 증설

CPU, 디스크, 메모리 등 서버 자원 중에서 증설이 필요한 자원이 있는가?

보다 고성능 스토리지로 교체할 필요성이 있는가?

스토리지와 서버 간 입출력 개선을 위해 채널 수를 늘릴 필요가 있는가?

네트워크 대역폭은 여유가 있는가?


lTop+IT Optimization

Service시스템 최적화

아키텍처 진단

대외 서비스

솔루션사업본부 아키텍처부문 리드아키텍처담당 아키텍처최적화팀

Documents

사례에서 배우는 성능을 고려한 소프트웨어 아키텍처 - KOSTA...2 제8회 2015 한국 소프트웨어 아키텍트 대회 성능이 저하된 시스템 개선을