자바 성능 튜닝 이야기(1)

디자인 패턴 꼭 써야 한다

MVC 모델

한 화면에서 모든 것을 처리하는 ASP(Active Server Page : PHP 등)에서 J2EE 패턴을 사용하기 위해서는 MVC모델을 몰라서는 안된다. 각 로직(모델, 뷰, 컨트롤러)별 클래스를 각각 만들어서 개발하는 모델이다.
이를 스윙이나 SWT 기반의 2-tier Application의 관점에서 접근해보자.

2-tier application이란?

• 같은 역할을 하는 서버들을 같은 tier에 있다고 말한다.
• 2 tier란 ec2같은 웹 서버가 DB에 연결 되어 있는 형태를 말하며 보통 트래픽이 많지 않은 경우 사용된다.
• 한 클라이언트에 한 서버가 배분된다.

2-tier vs 3-tier

• 2-tier에서 was서버가 추가된 형태를 3-tier라고 하며, 백엔드용 서버가 따로 존재한다. 백엔드용 서버가 존재하기에 2-tier보다 무거운 작업을 처리하기에 좋지만, 구조가 복잡한 단점이 있다.

모델 - 뷰 - 컨트롤러의 관계

• 뷰는 사용자가 결과를 보거나 입력할 수 있는 화면이라고 생각하면 된다. 이벤트를 발생시키고, 이벤트의 결과를 보여주는 역할을 한다.
• 컨트롤러는 뷰와 모델의 연결자로, 뷰에서 받은 이벤트를 모델로 연결하는 역할을 한다.
• 모델은 뷰에서 입력된 내용을 저장, 관리, 수정하는 역할을 한다.

JSP는 모델 1과 모델2로 나누어져 있는데,

• 모델 1은 JSP에서 자바 빈을 호출하고, 데이터베이스에서 정보를 조회, 등록, 수정, 삭제 업무를 한 후 결과를 브라우저로 보내 주는 방식이다. 간단하지만 추후 수정이 굉장히 어렵다.
• 모델 2는 MVC 모델을 정확히 따른다. 모델 1에서 servlet이 컨트롤러의 역할을 수행하면서, MVC 패턴을 완성시킨다.
  보통 3티어 JSP모델은 모델1, 모델2를 사용하고, 웹이 아닌 2티어 구조에서는 MVC를 사용한다.

J2EE 디자인 패턴이란 무엇인가?

'J2EE 디자인 패턴'이라는 용어가 생소할 수 있다. 한 단어씩 띄워서 생각해보자.
먼저, 패턴(pattern)이란, 무엇인가를 만들기 위한 모델이나 가이드, 설명의 집합을 의미한다.
즉, 시스템을 만들기 위해 전체 중 일부 의미 있는 클래스들을 묶은 각각의 집합을 디자인 패턴(design pattern) 이라고 한다. 그리고 스프링이 있기 전 사용되었던 프레임워크인 J2EE 프레임워크의 이름을 따서 J2EE 디자인 패턴이라고 하는 것이다.

디자인 패턴의 종류

사용자의 요청이 처리되는 순서대로 티어를 나눈다면,
프레젠테이션 - 비즈니스 - 인테그레이션 티어 순으로 나눌 수 있겠다. 프레젠테이션 티어쪽으로 갈 수록 View에 가깝고, 인테그레이션 티어는 DB와 같은 repository에 가깝다고 생각하면 이해하기 쉽다.
Core J2EE patterns를 보면서, 몇 가지 패턴들을 살펴볼 수 있겠으나,
디자인 패턴은 공부하고 실제 사용하기 전까지는 너무 이론적인 느낌이라 지금 포스팅하지는 않겠다.
그 중, 대표적인 패턴 두가지만 알고 가보자.

Transfer Object 패턴

VO(Value Object)라고도 불리는 Transfer Object는 데이터를 전송하기 위한 객체에 대한 패턴이다.
DTO를 잘 만들어 놓으면, 내가 원하는 정보만 넘겨줄수도 있고, 각 source에서 일일히 null체크를 할 필요가 없기 때문에 오히려 더 편해진다.
또한 toString을 오버라이딩하여 객체를 보다 쉽게 구분할 수 있다.

implements Serializable
Serializable을 구현할 때 반드시 구현해야 하는 메서드가 있는 것도 아니고, 변수가 존재하는 것도 아니다. 그러나 Serializable을 구현하면 객체를 직렬화할 수 있다. 다시 말해 서버 사이의 데이터 전송이 가능해지고, 원격지 서버에 데이터를 전송하거나, 파일로 객체를 저장할 경우에는 이 인터페이스를 구현해야 한다.

Service Locator 패턴

Service Locator 패턴은 예전에 많이 사용되었던 EJB의 EJB Home 객체나 DB의 DataSource를 찾을 때 소요되는 응답 속도를 감소시키기 위해 사용된다. cache에 어떤 객체를 찾은 결과를 보관하고 있다가, 누군가 그 객체를 필요ㅎ로 할 때 메모리에서 찾아서 제공하고, 해당 객체가 cache에 없으면 메모리에 들어가서 찾는 패턴이다.

정리

DTO가 왜 필요한지, 무엇인지는 알고 있었지만, 이 또한 디자인 패턴이라는 것은 알지 못했다.
어쩌면 내가 무의식적으로 알고 있는 모든 것이 디자인 패턴의 일종일지도 모르겠다는 생각을 했다.
패턴을 한번씩 더 찾아보면서 Read Only인지, R/W가 가능한지에 따라 VO와 DTO로 나뉜다는 글을 보며 예전의 중구난방식의 개발에서 조금 더 디자인 패턴이 가미된 개발 문화로의 전환이 이루어지고 있음을 느꼈다.
또한 JSP등의 ASP에서 전문적인 뷰단으로의 분화가 이루어졌기 때문에(React, Vue 등) 점점 더 프레젠테이션 티어쪽으로의 협업과 관련된 디자인 패턴보다는, 내부에서 lookup이나 처리속도를 조금이라도 더 빠르게 할 수 있는 디자인 패턴이 중요해진 것 같다.

내가 만든 프로그램의 속도를 알고 싶다.

성능이 느릴 때는 병목 지점이 어디인가?를 파악하는 것이 가장 중요하다. APM이나 프로파일링 툴을 이용하여 분석하는 곳도 있고, 손수 디버깅을 하는 곳도 있다.

프로파일링 툴 vs APM

간단히 설명하자면, 프로파일링 툴은 개발자용 툴이고, APM 툴은 운영 환경용 툴이라고 할 수 있다. 표를 보면서 비교해 보자.

구분	특징
프로파일링 툴	- 소스 레벨의 분석을 위한 툴이다. - 애플리케이션의 세부 응답 시간까지 분석할 수 있다. - 메모리 사용량을 객체나 클래스, 소스의 라인 단위까지 분석할 수 있다. - 가격이 APM툴에 비해 저렴하다. - 보통 사용자수 기반으로 가격이 정해진다. - 자바 기반의 클라이언트 프로그램 분석을 할 수 있다.
APM 툴	- 애플리케이션의 장애 상황에 대한 모니터링 및 문제점 진단이 주 목적이다. - 서버의 사용자 수나 리소스에 대한 모니터링을 할 수 있다. - 실시간 모니터링을 위한 툴이다. - 가격이 프로파일링 툴에 비해 비싸다. - 보통 CPU수를 기반으로 가격이 정해진다. - 자바 기반 클라이언트 프로그램 분석이 불가능하다.

프로파일링 툴은 느린 메서드나 느린 클래스를 찾는 것을 목적으로 하지만, APM 툴은 목적에 따라 용도가 상이하다.
프로파일링 툴은 다음과 같은 기능을 공통적으로 제공한다.

• 응답 시간 프로파일링 기능
  하나의 클래스 내에서 사용되는 메서드 단위의 응답 시간을 측정하고, 툴에 따라 소스 라인 단위로 응답 속도를 측정한다.