애플리케이션 디자인 고려사항
이 주제에서는 애플리케이션 디자인 및 조정에 대한 아키텍처 제안사항에 대해 설명합니다.
애플리케이션 디자인 정보에는 아키텍처 제안사항과 애플리케이션 구현이 포함됩니다. 기존 애플리케이션의 경우 제안사항으로 인해 기존 구현의 변경이 필요할 수도 있습니다. 애플리케이션 서버 및 자원 매개변수의 성능을 조정하면 제대로 디자인된 애플리케이션의 성능면에서 큰 효과를 볼 수 있습니다.
팁 관련 주제의 애플리케이션 디자인 고려사항을 참조하여 애플리케이션이 올바르게 디자인되고 조정되었는지 확인하십시오. 이러한 고려사항에서는 특히, Java™ EE(Java Platform, Enterprise Edition) 스펙에 대한 WebSphere® 확장기능 영역에서 WebSphere 애플리케이션을 디자인하기 위한 우수 사례를 검색할 수 있는 웹 사이트와 기타 아이디어가 포함됩니다.
Java EE 애플리케이션은 관계형 데이터베이스에서 데이터를 로드, 저장, 작성, 제거하며 이 프로세스를 일반적으로 지속성이라 합니다. 대부분의 엔터프라이즈 애플리케이션은 중요한 데이터베이스 액세스 권한을 가집니다. 지속성 계층의 아키텍처와 성능은 애플리케이션의 성능에 중요합니다. 따라서 성능과 관련된 조정이 필요한 아키텍처를 선택할 때 지속성은 매우 중요한 고려 영역입니다. 이 안내서에서는 먼저 아키텍처가 명확한 솔루션을 선택하도록 권장합니다. 명확한 아키텍처에서는 데이터 일관성, 보안, 유지보수, 이식성, 해당 솔루션의 성능을 고려합니다. 이 접근법이 언급한 서비스 품질을 무시하는 솔루션의 수동 코딩에서 얻을 수 있는 절대적인 최고 성능을 확보할 수는 없지만 이 접근법은 데이터 일관성, 유지보수 가능성, 이식성, 보안, 성능을 적절하게 조화시킬 수 있습니다.
지속성을 위해 Java EE에는 CMP(Container-Managed Persistence)나 BMP(Bean-Managed Persistence) 같은 엔티티 Bean을 사용한 세션 Bean, JDBC(Java DataBase Connectivity)를 사용한 세션 Bean 및 JDBC를 사용한 Java Bean 등 다양한 옵션이 제공됩니다. 이전에 언급한 이유로 인해 CMP 엔티티 지속성을 고려하십시오. CMP 엔티티 지속성이 최대 보안, 유지보수, 이식성을 제공하기 때문입니다. CMP도 성능 향상을 위해 권장됩니다. 엔터프라이즈 Bean 및 보다 명확하게 CMP 조정에 대한 애플리케이션 서버 조정 주제의 EJB 컨테이너 조정 섹션을 참조하십시오.
애플리케이션이 EJB 엔티티를 사용하지 않는 엔터프라이즈 Bean을 사용해야 하는 경우 지속성 메커니즘은 일반적으로 JDBC API와 관련됩니다. JDBC는 수동으로 코딩하고 데이터베이스 인스턴스에 대해 실행하는 SQL(Structured Query Language)을 필요로 하기 때문에 애플리케이션 내에서 사용되는 SQL문을 최적화하는 것이 중요합니다. 또한 이러한 SQL문의 최적 성능을 지원하도록 데이터베이스 서버를 구성하십시오. 마지막으로 준비된 명령문과 일괄처리를 포함하여 특정 JDBC API의 사용법을 고려해야 합니다.
고려되는 지속 메커니즘과 상관없이 Bean이 컨테이너에 트랜잭션 관리를 위임하는 컨테이너 관리 트랜잭션을 사용하십시오. JDBC를 사용하는 애플리케이션의 경우 이는 모든 JDBC 기능을 stateless 세션 Bean으로 랩핑하는 세션 façade 패턴을 사용하여 이루어집니다.
마지막으로 EJB 엔티티 Bean 또는 JDBC가 통신하는 연결 조정에 대한 정보는 애플리케이션 서버 조정 주제의 데이터 소스 조정 섹션에 있습니다.
표준 Java EE 프로그래밍 아키텍처 중 하나는 MVC(Model-View-Controller) 아키텍처로서, 제어기 서블릿 호출에는 보기를 구성할 하나 이상의 하위 JSP(JavaServer Pages) 파일이 있어야 합니다. MVC 패턴은 애플리케이션 아키텍처를 위한 권장 패턴입니다. 이 패턴에서는 보기(JSP 파일 또는 프리젠테이션 로직), 제어기(서블릿), 모델(비즈니스 로직)을 명확하게 구별해야 합니다. MVC 패턴을 사용하면 각 계층의 성능 및 확장성을 개별적으로 최적화할 수 있습니다.
클라이언트 사용자 상태 스케일을 저장하지 않고 최상을 수행하는 구현. 상태를 저장하지 않도록 구현을 디자인하십시오. 상태 스토리지가 필요한 경우 상태가 저장되는 상태 날짜 및 시간의 크기가 가능한 최소값으로 저장되도록 하십시오. 또한 상태 스토리지가 필요할 때 장애가 발생하는 경우에는 복제를 통해 상태 실패복구를 하는 대신 상태 재구성의 가능성을 고려해 보십시오.
- 세션 관리 조정
- EJB 조정 팁
- 캐시 모니터로 동적 캐시 조정
대부분의 Java EE 애플리케이션 워크로드에는 쓰기 조작보다 읽기 조작이 더 많이 있습니다. 읽기 조작을 수행하려면 프론트 엔드 웹 서버, 애플리케이션 서버의 웹 컨테이너, 애플리케이션 서버의 EJB 컨테이너, 데이터베이스를 구성하는 여러 토폴로지 레벨을 통해 요청을 전달해야 합니다. WebSphere Application Server는 웹 서비스를 포함하는 네트워크 토폴로지 및 Java EE 프로그래밍 모델의 모든 레벨에서 결과를 캐시할 수 있습니다.
캐싱은 대부분의 프로그래밍 모델 레벨에서 통합되기 때문에 애플리케이션 디자이너는 애플리케이션 아키텍처를 디자인할 때 캐싱을 고려해야 합니다. 캐싱은 애플리케이션에서 MVC 패턴을 강화하는 또 다른 이유입니다. 캐싱과 MVC를 결합하면 프리젠테이션 기술과 무관하게 애플리케이션의 클라이언트에 대한 프리젠테이션이 없는 경우에 캐싱을 제공할 수 있습니다.
캐싱은 또한 대부분의 네트워크 토폴로지 레벨에서 통합되기 때문에 네트워크 디자이너는 네트워크 계획을 수행할 때 캐싱을 고려해야 합니다. 공용 인터넷에서 사용 가능한 애플리케이션의 경우 네트워크 디자이너는 WebSphere Application Server 캐싱이 공용 인터넷으로 확장될 때 ESI(Edge Side Include) 캐싱을 고려하고자 할 수 있습니다. 네트워크 캐싱 서비스는 WebSphere Application Server, WebSphere Edge Component Caching Proxy 및 WebSphere 플러그인에 대한 프록시 서버에서 사용 가능합니다.
Java EE 워크로드는 일반적으로 두 가지 유형의 조작으로 이루어집니다. 시스템 요청에 응답하려면 첫 번째 유형의 조작을 수행해야 합니다. 조작을 시작한 사용자 요청이 이행된 후에 두 번째 유형의 조작을 비동기식으로 수행할 수 있습니다.
이 차이의 예로는 구매 주문을 제출할 수 있고, 시스템이 주문의 유효성을 검증하는 동안 계속할 수 있으며, 원격 시스템을 조회하고, 나중에 구매 주문 상태를 알려주는 애플리케이션이 있습니다. 응답을 대기 중인 클라이언트와 동기식으로 이 예를 구현할 수 있습니다. 동기식으로 구현하려면 애플리케이션 서버 자원이 필요하며 사용자는 전체 조작이 완료될 때까지 대기해야 합니다. 결과가 비동기식으로 계산되는 동안 프로세스가 계속할 수 있게 하는 경우 애플리케이션 서버는 다른 요청과 관련하여 최적의 상태일 때 처리가 발생하도록 계획할 수 있습니다. 사용자에 대한 알림은 이메일이나 애플리케이션 내의 일부 다른 인터페이스를 통해 트리거할 수 있습니다.
비동기 접근은 최적의 워크로드 스케줄 및 최소 서버 자원을 지원하기 때문에 비동기 아키텍처를 고려해 보십시오. WebSphere Application Server는 Java EE Java Message Service(JMS) 및 메시지 구동 Beans(MDB)과 Java Message Service 조정 및 MDB 조정 주제에서 설명하는 Concurrency Utilities for Java EE를 통해 비동기 프로그래밍을 지원합니다.
애플리케이션이 사용하는 모든 라이브러리가 서버 측 성능에도 맞게 디자인되어 있는지 확인하십시오. 일부 라이브러리는 클라이언트 애플리케이션 내에서 잘 작동하도록 디자인되어 있지만 메모리 활용, 동기화, 풀링과 같은 서버 측 성능 관심사는 고려하지 않았습니다. 따라서 애플리케이션의 일부로 개발되지 않은 모든 라이브러리는 애플리케이션에 사용한 것과 동일한 테스트 방법을 사용하여 성능 테스트를 하는 것이 좋습니다.
추가 참조: IBM® WebSphere Developer Technical Journal: 상위 10개의 Java EE 우수 사례XML 애플리케이션의 성능 개선, 파트 2