Java 소프트웨어 개발 노하우

Java 소프트웨어 개발 노하우

• IDE는 무조건 고민하지 않고 Intellij IDEA를 사용한다. 현재 적수가 없는 절대 강자이다. 기업에서도 무료 사용이 가능한 커뮤니티 에디션 만으로도 프로덕션 레벨의 백엔드 마이크로서비스를 개발하는데 충분한 기능을 제공한다. [관련 링크]
• 연습 목적이 아닌 프로덕션 레벨의 엔터프라이즈 애플리케이션 개발이 목적이라면 하나의 완성된 .jar 파일을 생성하는 Fat JAR(Uber-JAR)를 지원하는 프레임워크를 사용한다. Spring Boot와 Dropwizard가 대표적이다. 상태가 없는 지속적인 배포가 가능한 마이크로서비스의 개발은 Fat JAR에서 시작됨을 명심한다. [관련 링크]
• 이러한 마이크로서비스 구현을 위한 프레임워크 중에는 Spring Boot가 가장 성능이 우수하다. 그 뒤를 JAX-RS 구현체인 JBoss RESTEasy가 바짝 쫒고 있다. 가벼움을 강조하는 Javalin과 Spark는 의외로 가장 성능이 안 좋다. [관련 링크]
• 한편, 마이크로서비스 내에서 다른 마이크로서비스를 호출하는데 필수적으로 사용되는 REST API 클라이언트 중에는 OkHttp 클라이언트가 가장 성능이 우수하다. 그 뒤를 Unirest가 바짝 쫒고 있다. [관련 링크]
• 빌드 자동화 도구인 Gradle로 프로젝트를 생성하고 관리한다. 편리한 의존성 관리의 혜택과 표준화된 Maven 컨벤션을 따를 수 있게 된다. /src/main/java, /src/main/resources/, /src/test/java, /src/test/resources 같은 표준화된 컨벤션을 따르면 처음 보는 오픈 소스 프로젝트도 쉽게 적응할 수 있다.
• 프로젝트는 초기 단계부터 Domain-Driven Design, Test-Driven Design을 주요 철학으로 설계한다. 처음에는 귀찮아도 프로젝트의 크기가 커질수록 생산성과 안정성에서 위력을 발휘한다.
• 프로젝트는 끊임 없이 리팩토링을 수행한다. 리팩토링은 천재의 영역이 아니다. 탄탄한 기본기와 시간과 정성의 싸움이다. 역시 프로젝트의 크기가 커질수록 가독성과 생산성에서 위력을 발휘한다.
• DDD는 어려운 주제가 아니다. DDD의 시작은 비즈니스 관점에서 의미가 있는 단위를 Value Object(VO)로 추출하는 것에서 시작한다. 예를 들어 이메일 주소, 우편번호는 단순한 문자열이 아니라 의미를 가지기 때문에 유효성 검사 로직이 동반되어야 한다. 그동안 이들을 단순히 String 타입의 필드에 담았다면 EmailAddress, ZipCode 등의 클래스로 전환하자. Lombok 라이브러리를 사용하면 VO 설계의 복잡성을 낮추고 생산성을 높일 수 있다.

캐시를 적절히 활용하자

• 극단적인 동시성이 요구되면서 읽기 요청이 압도적으로 많은 애플리케이션을 개발한다면 캐시의 활용은 필수이다. 전통적인 RDMBS 앞에 Redis와 같은 세계 최고 속도를 가진 저장소를 분산 캐시(Distributed Cache)로 활용할수 있으며, 각 애플리케이션 노드에서는 cache2k와 같은 로컬 캐시(Local Cache)를 활용할 수 있다. 최근에는 니어 캐시(Near Cache)라는 개념으로 분산 캐시와 상호 작용하는 로컬 캐시의 개념을 저장소 레벨에서 제공하는 것들도 등장했다. 대표적으로 뒤에 언급할 Redisson, Apache Ignite 등이 있다.

저장소를 이해하자

• 좋은 엔터프라이즈 Java 애플리케이션이란 무엇일까? 꽤나 단순하다. 수정이 쉬우면서 중단 없이 잘 버티고 응답이 빠른 서비스를 만들면 된다. 이를 위해서는 단순히 애플리케이션 레벨에서의 이해보다 원격지에 위치한 다양한 종류의 저장소에 대한 올바른 이해가 중요하다. 그리고 이러한 이해가 Java 소스 코드에 녹여져야 한다. 과거에는 Oracle, MySQL과 같은 전통적인 RDBMS 1개를 잘 다루면 훌륭한 개발자로 인식되었다. 하지만, 점차 극단적인 동시성 처리와 스케일링 능력이 요구되면서 굉장히 다양한 NoSQL 저장소에 대한 이해가 필요하게 되었다.
• Redis는 세계에서 가장 빠른 인메모리 NoSQL 저장소이다. 단일 쓰레드 기반으로 설계되어 한 순간에는 오직 하나의 명령어를 극단적으로 빠른 속도로 처리하는데 최적화되어 있다. RDBMS의 부담을 줄어줄 캐시의 역할을 훌륭하게 수행할 수 있다. Redis는 CPU보다 I/O 의존적인 저장소이다. 병목 현상이 발생한다면 대개 네트워크 대역폭, 메모리 대역폭 순서로 원인을 찾아봐야 한다. CPU 사용량이 병목의 원인인 경우는 드물다. 그럼에도 CPU 사용을 극대화하고 싶으면 하나의 시스템 안에서 여러 개의 Redis로 분산 운영하면 된다. 이 경우 인스턴스마다 저장하는 데이터의 성격을 명확하게 분류하면 관리 편의성이 좋아진다. [관련 링크1] [관련 링크2] 최근 Redis 4.0 이상에서는 모듈 기능이 도입되면서 RediSearch와 같은 실시간 인메모리 풀텍스트 검색 엔진 모듈도 공개되어 사용성이 확장되었다. [관련 링크]
• 최근에는 In-Memory Data Grid(IMDG) 저장소가 각광을 받고 있다. 메모리 기반의 고속의 클러스터 확장이 가능한 데이터 저장소라고 말할 수 있는데 무료 오픈 소스 중에는 Redis 기반의 Redisson, JVM 기반의 자체적인 인메모리, 온디스크 저장소인 Apache Ignite가 좋은 반응을 얻고 있다. [관련 링크]

참고 글

• DDD Building Blocks – Value Objects
• SPRING I/O 16: BRIDGING THE WORLDS OF DDD & REST