애플리케이션 점검 대상

📌 패턴과 아키텍처는 잘 구성되어 있는가?

너무 많은 패턴을 사용하지 않았나?
많은 패턴을 적용하면 유지보수성이 떨어지고, 문제 발생시 추적이 어려워진다. 따라서 무작정 사용하지말고, 꼭 필요한 패턴만을 사용하자.
데이터를 리턴할 때 TO(VO)를 패턴을 사용했는가? Collection 관련 클래스를 사용했는가?
데이터를 주고 받을 때, 일반적으로 TO 패턴을 사용한다. 때에 따라서 Collection을 사용하기도 하는데 표준을 정하지 않는다면 유지 보수성이 떨어지게 된다. 예를 들어 HashMap으로 주고 받으면, 소스를 완전히 뜯어봐야 알 수 있기 때문이다.
서비스 로케이터(Service Locator) 패턴은 적용되어 있는가?
이를 사용하면 필요한 대상을 찾는 룩업 작업을 할 때 소요되는 대기 시간을 줄일 수 있다. CPU 사용량이 높지 않을 때, 응답 속도가 느리다면 적용해야 할 부분이 없는지 찾아봐야 한다.

📌 기본적인 애플리케이션 코딩은 잘 되어 있는가?

명명 규칙은 잘 지켰는가?
클래스의 이름을 보고 어떤 일을 하는지 짐작이 되어야 한다. 일일이 보면서 확인할 시간이 없다.
필요한 부분에 예외 처리는 되어 있는가?
예외 처리를 제대로 하지 않으면 아무 응답을 받을 수 없는 상황이 생긴다. 문제 발생시 원인을 파악하기 위해서는 예외 처리는 필수이다.
예외 화면은 지정되어 있는가?
지정하지 않는다면 우리가 사용하는 서버가 무엇이고, 시스템에 어떤 클래스가 있는지 확인할 수 있는 상황이 생길 수 있다.
예외 정보를 e.printStackkTrace()로만 처리하고 있는가?
필요한 정보만 로그를 남기는 것이 좋다. e.printStackkTrace()를 이용하면 필요하지 않은 부분까지 모두 쌓아두기 때문에 서버에 부하가 생길 수 있다.
System.gc() 메서드가 소스에 포함되어 있는가?
GC가 언제 되어야 할지 절대로 신경쓰지말자. 오히려 서버를 2배 늘려야 하는 상황이 생길 수 있다.
System.exit() 메서드가 소스에 포함되어 있는가?
WAS의 프로세스가 죽을 수 있다.
문자열을 계속 더하도록 코딩하지는 않았는가?
계속 더하는 경우 새로운 객체를 생성하므로 조심하자.
JDK 5.0 이상은 자동으로 StringBuilder 클래스로 변환하지만, 루프를 수행하는 경우 컴팡리러도 어쩔 수 없다. 따라서 조심하자.
StringBuffer나 StringBuilder 클래스를 적절하게 사용했는가?
제대로 이해하고 사용해야 한다. 때에 따라 적절하게 사용하자.
무한 루프가 없는가?
static을 남발하지 않았는가?
필요한 부분에 synchronized 블록을 상용했는가?
필요 없는 부분에 사용하면 성능 저하가 발생할 수 있다.
필요 없는 로그를 제거했는가?
아까운 메모리를 사용하고, GC 해야 하는 상황을 만들지 말자.
System.out.println은 모두 제거했는가?
무조건 지워라! 애초에 log로 확인하는 버릇을 만들자.

📌 웹 관련 코딩은 잘 되어 있는가?

이미지 서버를 사용할 수 있는 환경인가?
이미지, 자바스크립트, CSS, 플래시 등 정적인 컨텐츠가 많고, 사용자 요청이 많다면 웹 서버 이외에 이미지 서버를 고려할 수 있다.
사용 중인 프레임워크는 검증이 되었는가?

📌 DB 관련 코딩은 잘 되어 있는가?

적절한 JDBC 드라이버를 사용하는가?
DB Connection, Statement, ResultSet은 잘 닫았는가?
DB Connection Pool은 잘 사용하고 있는가?
ResultSet.last() 메서드를 사용했는가?
전체 건수를 가져오기 위한 last() 메서ㅓ드는 자제하자.
PreparedStatements를 사용했는가?
Statement는 매번 쿼리를 수행할 때마다 SQL 쿼리를 컴파일 하게 된다. 이는 DB에 많은 부하를 준다.
쿼리를 동적으로 변경되어야 하는 경우를 제외하면 PreparedStatements를 사용하자.

📌 서버 설정은 잘 되어 있는가?

자바 VM 관련 옵션은 제대로 설정되어 있는가?
메모리는 몇 MB로 설정했는가?
기본값을 확인하고, 설정하자
GC 설정은 어떻게 되어 있나?
서버가 운영 모드인지 개발 모드인지 확인했나?
개발 모드면 주기적으로 변경된 클래스가 있는지 확인한다. 이 작업은 많은 부하를 주게 된다.
WAS 인스턴스가 몇 개 기동되고 있나?
CPU는 4개인데 인스턴스가 30개 정도 있는 것은 아닌지 확인하자.
DB Connection Pool 개수와 스레드 개수는 적절한가?
스레드 개수는 DB Connection Pool 수보다 절대로 적어서 안 된다.
세션 타임아웃 시간은 적절한가?
검색 서버가 있다면, 검색 서버에 대한 설정 및 성능 테스트를 했는가?
주기적으로 데이터를 모으기 위해 서버 리소스를 많이 사용하는데, 점검하지 않는다면 예기치 못한 부분에서 시스템 리소스를 점유하고 있을지도 모른다.

📌 모니터링은 어떻게 하고 있는가?

웹 로그를 남기고 있는가?
추후 용량 산정의 기초 자료가 될 수 있다. 반드시 남겨서 관리하자.
verbosegc 옵션은 남기고 있는가?
GC가 어떤 형태로 발생하는지 확인하려면, 해당 옵션을 사용해서 로그를 남기자
각종 로그 파일에 대한 규칙은 있는가?
그냥 몇 기가씩 쌓이고 있지 않은가?
서버의 시스템 사용률은 로그로 남기고 있는가?
WAS나 DB가 얼마나 사용하고 있는지 로그를 남겨야 한다.
모니터링 툴은 사용 중인가?
WAS를 모니터링하기 위한 툴은 설치되었는가?
모니터링 툴에 대한 설정은 적절한가?
제대로 활용하지 못한다면 소용없다.
서버가 갑자기 코어 덤프가 발생시키지는 않는가?
10,000건 이상 조회하는 것이 있나 확인하자. 한꺼번에 많은 양의 데이터를 처리하기 위해 메모리가 필요하다. 따라서 지정된 메모리보다 클 수 있기 때문에 확인을 꼭 하자.
메모리 릭이 없는가 확인하자.
응답 시간이 너무 느리지 않는가?
이유는 너무나 많다. 이를 해결하기 위해 상황을 파악하는 것이 매우 중요하다. 어느 단에서 느려진 것인지 확인하고, 프로파일링을 해서 확인해야 한다.
TOP