12/15/2016

Spring-boot에 Swagger2 설정

Written by Giljae Joo (주길재) in Springboot, Swagger with 댓글 없음

RESTful API를 만들 경우에는 문서화가 중요하고, API문서와 코드와의 변경 사항을 반영하는 것은 지루한 일입니다.

일반적으로 Swagger를 사용할 경우에는 @Api, @ApiOperation과 같은 Annotation을 사용하여Swagger에 보여질 내용을 설정하게 됩니다.

Swagger2의 구현체인 Springfox를 사용할 경우에는 이런 부분들이 자동화되게 됩니다.

타겟 프로젝트

REST 서비스는 아래의 URL을 참조하여 Swagger2를 적용할 수 있도록 생성해야 합니다. (본 문서의 범주가 아니므로 링크로 대체합니다.)

Build a REST API with Spring 4 and Java Config article
Building a RESTful Web Service.

메이븐 의존성 추가

생성한 프로젝트의 pom.xml 내에 아래의 의존성을 추가합니다.

<!-- Swagger2 -->
<dependency>
  <groupId>io.springfox</groupId>
	<artifactId>springfox-swagger2</artifactId>
	<version>2.4.0</version>
	</dependency>
<!-- Swagger UI -->
<dependency>
	<groupId>io.springfox</groupId>
	<artifactId>springfox-swagger-ui</artifactId>
	<version>2.4.0</version>
</dependency>

view raw swagger2_dependency.pom hosted with ❤ by GitHub

프로젝트에 설정하기

Swagger 설정은 Docket Bean으로 합니다.

@Configuration
@EnableSwagger2
public class SwaggerConfig {
	@Bean
	public Docket api() {
		return new Docket(DocumentationType.SWAGGER_2).select().apis(RequestHandlerSelectors.any())
				.paths(PathSelectors.any()).build();
	}
}

view raw SwaggerConfig.java hosted with ❤ by GitHub

위의 설정을 통해 스프링 부트에 Swagger2를 통합할 수 있습니다.

확인하기

설정이 완료되었으면, 스프링 부트 어플리케이션을 실행하여 아래의 URL로 확인할 수 있습니다.

http://localhost:8080/{your-app-root}/v2/api-docs

JSON type의 response를 보게 되면 올바르게 설정이 된 겁니다. Swagger에서는 보다 편하게 확인하기 위해 Swagger-UI를 제공해줍니다.

Swagger-UI로 확인하기

이미 Swagger-UI 의존성을 pom.xml에 추가하였기에, 브라우저에서 아래의 URL로 확인합니다.

http://localhost:8080/{your-app-root}/swagger-ui.html

기타 고급 설정에 대한 부분은 아래의 참조 URL을 확인하세요. 테스트에 사용된 Full-source는 https://github.com/giljae/sandbox/tree/master/swagger-springboot에서 확인할 수 있습니다.

Redis Java client -lettuce 소개

Written by Giljae Joo (주길재) in Client, Java, Lettuce, Redis with 댓글 없음

Lettuce는 synchronous, asynchronous, reactive usage를 지원하는 scalable thread-safe한 Redis Java client 입니다.

lettuce — IntroductionLettuce is a scalable thread-safe Redis client for synchronous, asynchronous and reactive usage. Multiple threads may… redis.paluch.biz

Micro Service Architecture(MSA)를 적용하면서, 앞단의 Gateway의 Discovery영역에 redis로부터 active instance를 read하는 부분에서 Jedis를 사용하였지만 Jedis는 Multiple threads상에서 connection pool 성능이 생각보다 만족스럽지 않았고 차선책으로 Lettuce를 사용하였고 결과는 만족스럽습니다.

개발 방법론 고찰

Written by Giljae Joo (주길재) in 개발, 방법론 with 댓글 없음

요즘 주위에 애자일(특히 스트럼)로 프로젝트를 진행하는 곳이 많아지고 있지만, 대부분은 실패로 마무리 됩니다. 이유는 무엇일까? 방법론을 올바르게 숙지하지 못해서? 아니면 팀 문화가 따라주지 않아서? 아래의 내용은 개인적인 생각임을 미리 밝혀둡니다. 저는 “사기(士氣)”의 문제라고 생각합니다. 스크럼을 이용할 경우 아래의 장점들을 취할 수 있습니다.

진척 사항의 시각화
관리자 측면에서는 일이 잘 진행되고 있다는 느낌을 받는다
해야할 업무에 대해서 놓치지 않게된다

위의 장점들은 그냥 만들어지는 것이 아닙니다. 스크럼의 근본 취지는 work 시간에 제한을 두고 최대한 생산성을 끌어내는 것이 핵심입니다. 추정을 통해 작업 시간을 정하고 스프린트를 진행하게 됩니다. 만약, 추정이 틀렸다면 인공적으로 만들어진 스프린트를 완수하기 위해서 과부하가 걸리던지 프로세스를 속이는 플래닝을 해야 합니다. (스프린트의 변경은 수많은 미팅을 통해야 하지요)

틀린 추정이 빈번해지고 이런 상황들이 계속 발생하게 되면 사업쪽은 기술쪽이 목표를 놓치고 있다고 생각할 것이고 기술쪽은 사업쪽이 목표를 변경하고 있다라고 생각할 수 있습니다. 이렇게 되면 양쪽다 사기가 꺽이게 됩니다.

그리고, 진척 사항의 시각화로 인해 개발팀은 컨트롤을 받고 있다 혹은 도구가 된 것 같다라는 느낌을 받을 수 있고 이 또한 사기에 영향을 주게 됩니다. 그렇다고 여유로운 스프린트를 수행하게 되면 관리의 리스크에 직면하게 됩니다. 스크럼의 규약이 우리팀에는 적합하지 않다라는 판단이 들었습니다. 우리는 다시 생각할 필요가 있습니다. 애자일이 나오게 된 배경이 무엇이었는지에 대해서… 개인적으로 느낀 스크럼에 대한 대안으로 칸반을 고려하게 되었습니다.

사업팀과 기술팀의 분리
업무에 대한 연속적인 흐름
Work-In-Process(WIP)를 통한 생산성과 벨로시티를 제어
도구로 느껴지지 않도록, 능동적으로 일 할 수 있도록
프로젝트 관리 오버헤드 감소

칸반 프로세스는 스크럼에 비해 단촐합니다. 칸반을 이용하게 됨으로써 스프린트 플래닝이 사라지게 되었고 PO(사업팀)에서는 “To Do”만 관여하게 되고 나머지 보드는 기술팀이 관리를 하게 됩니다.

즉, “To Do”의 일거리가 개발팀으로 push 되는 것이 아닌 pull하는 당김 방식으로 업무가 흐르게 됩니다.

칸반으로 작업의 흐름을 보기 위해 Asana를 활용합니다. (얼마전에 Kanban view 기능이 추가됨) 팀간의 Communication은 Glip을 활용합니다.

회의를 최대한 줄이고 Online 커뮤니케이션을 통해 해결하려고 합니다. 칸반에서는 Work-In-Process (WIP)의 제약을 지키는 것이 핵심입니다.

스크럼의 경우에는 스프린트별 작업량을 제한하지만 칸반은 작업 구간별 작업량을 제한하게 됩니다. 능동적인 팀일 경우에는 이는 큰 생산성으로 다가 옵니다.

칸반은 스크럼에 비해 규칙이 작습니다. 그렇기 때문에 개선하는 노력이 필요합니다.

Giljae Joo (주길재)