머릿말
안녕하세요. 개발팀 김형진입니다.
이 글은 이번에 새로이 들어가는 프로젝트에 사용할 아키텍처에 대한 계획 글입니다. 왜 그런 아키텍처를 선택하게 되었는 지 그 안에서 어떤 아키텍처를 사용하고 선택하게 된 이유와 간단한 소개에 대한 글입니다. 이 블로그의 이전글을 보시면 인프라 계획글도 있습니다.
이 글을 쓰는 시점에서 현재 개발 아키텍처는 마이크로서비스로 구현되고 있는 중입니다.
마이크로서비스로 구현을 하게 된 이유는 별 거 없습니다. 그냥 해보고 싶었다. 이게 가장 컷습니다. 과거의 방식인 모놀리식이라고 나쁜 것만 있는 것만 있는 게 아니고 마이크로서비스라고 장점만 있다고 할 수 없으니깐요.
유투브에서 마이크로서비스를 검색하면 2017년도 이후 부터 많은 기업에서 모놀리식에서 마이크로서비스로 전환하는 것을 볼 수 있습니다. 마이크로 서비스는 개발자들의 러닝커브가 좀 큼니다. 하지만 앞으로 개발자로써 살아갈려면 해봐야 한다고 생각했습니다.
현재 개발 트렌드인 DevOps, 마이크로서비스, 애자일을 공부하다 보면 많은 부분이 연관되어 있다는 것을 느낄 수 있습니다. 어느 것이 먼저인지는 모르겠지만 애자일을 알아가다 보면 애자일을 실현하기 위해 DevOps라는 인프라와 마이크로서비스라는 개발 아키텍처가 생긴 것 같이 느껴지고 마이크로 서비스를 공부하면 해당 기술을 구현하기 위한 인프라로 DevOps가 생기고 이슈관리를 위해 애자일이 생긴 것 같다는 느낌이 듭니다.
목표
- 지속적인 개발을 가능하게 하는 빠른 개발
- 손쉬운 스케일링, 수동 또는 자동
개발 규칙
- 데이터베이스의 데이터를 서로 공유하지 않는 다.
- 각각의 레이어들간의 의존성을 최소화합니다.
- 정의된 버전 관리 전략에 따라 안정적이고 잘 문서화되어 있으며 잘 정의된 인터페이스를 통해서만 통신해야 합니다.
- 별도의 런타임 프로세스로 배포해야합니다. 마이크로 서비스의 각 인스턴스는 별도의 런타임 프로세스 (Docker 컨테이너)에서 실행됩니다.
기술스택
기술 스택을 선정할 때 일단 현재 팀에서 잘알고 또한 현업에서 현재 가장 많이 쓰이고 배우기 쉬운(책이나 문서가 많은 것들)것을 고려하려 선정했습니다.
- Java 11, Kotlin
- Maven
- Spring Boot 2.1
- Spring Cloud - 유레카, Config Servier, 주울, 페인, 립본, 히스트릭스
- Spring Fox - Swagger2
- Spring Data - JPA, QueryDSL
- Spring Cloud Stream - Apache Kafka
- JHipster
- Docker
- Elasticsearch
- AWS
Java 11, Kotlin (제목대신 로고 같은 경우도 괜찮을 듯..)
마이크로서비스라는 게 사실 언어나 기술에 제약을 걸면 안되겠지만 너무 많은 기술을 사용해도 관리가 힘들다는 단점이 있습니다. 때문에 두가지 언어를 주요언어로 사용하려고 합니다.
파이썬이나 노드 혹은 Go 같은 현재 뜨는 언어들이 있습니다. 하지만 아직까지는 국내 그리고 세계에서 가장 많이 사용되는 언어는 Java입니다. 그렇다는 거는 현재 만들어진 프로젝트 같은 경우 Java로 만들어진게 많다는 애기이고 조금 다른 애기지만 회사에서 개발자를 뽑을 때도 인력풀이 넓다는 장점이 있습니다.
함수형 프로그래밍을 위해 자바 8이상은 사용할 생각이였고 AWS에서 제공하는 OpenJDK에 11버전이 있어 기본으로 설정했습니다.
코틀린 같은 경우 자바와 소스 호환이 가능하고 안드로이드의 공식언어이자 현재 스프링에서도 코틀린으로 개발하는 경우가 늘고 있는 자바대체 언어입니다. 함수형 프로그래밍, 반응형 프로그래밍을 하기 위해서는 자바보다 용이하기 합니다.
Maven
사실 Gradle이라는 더 좋은 라이브러리 관리툴이 있다. 하지만 Maven에 더 익숙하고 다른 공부할 게 많아서 Gradle이 뒤로 밀렸다.
Spring Boot 2.1
Spring Boot를 채택한 이유는 현재 가장 잘 사용할 수 있고 Java를 사용하는 프레임워크 중에 가장 많이 사용되는 프레임워크이기에 선택했습니다.
2.1 버전을 굳이 적은 이유는 이번에 새로 스프링 부트를 공부하면서(최근책) 대부분의 책들이 2.0 또는 2.1버전을 기준으로 작성되어 있고 현재 최신버전인 2.2 버전 같은 경우 설정 부분에서 많은 부분을 수정해야 하고 원서에서도 2.2 버전을 기준으로 쓴 책이 없기 때문이다. 즉 문서가 많지 않았다. 하지만 다른 분들이 최신 버전을 사용하겠다 하면 말릴 생각은 없습니다.
Spring Cloud
스프링 클라우드를 선택한 이유는 현재 상황에서 가장 많이 사용되는 마이크로서비스 프레임워크이며 책이나 문서가 가장 많다.
Eureka 서버: 미들서버로 마이크로서비스들이 등록됩니다. 외부에서 호출 시 요청이 필요한 마이크로서비스를 찾아서 로드밸런싱을 해준다.
Config Server: 설정 서버, 스프링 클라우드에서는 설정관련 부분을 중앙집중식으로 설정을 관리합니다.
게이트웨이(Zuul): 마이크로서비스의 진입점입니다. 마이크로서비스가 호출될 때 거쳐갑니다. 라우팅, 인증, 로그.. 등 공통으로 사용되는 부분이 포함됩니다.
Hystrix: 내결함성 라이브러리, 네트워크 오류 시 시스템을 보호한다.
Actuator: 간단한 서버의 상태를 모니터링 할 수 있게 한다.
Spring Fox
Swagger API 문서화를 위해 사용합니다. Swagger 같은 경우 Spring이 아닌 다른 곳에서도 API문서 작성에 사용되는 범용적인 툴입니다.
Spring Data
사실 Mybatis 같은 쿼리 조회가 더 편하게 느껴지지만 마이크로서비스 아키텍처 특성상 DDD에 더 적합한 툴은 JPA라 생각하여 JPA를 선택했습니다.
스프링 데이터와, JPA, QueryDSL 같은 경우는 김영한님이 지은 자바 ORM 표준 JPA 프로그래밍 책을 기준으로 했습니다. 그 이유는 현재 국내에 나온 JPA 책 중에서 가장 많이 팔리기도 했고 블로그에 검색해도 가장 많이 나옵니다. 거기에 인프런에 강의도 올려 주셔서 배우기가 가장 좋기 때문이다.
JHipster
JHipster 같은 경우 프로젝트를 구성해주는 프레임워크입니다. 이번에 공부하다가 알게 된 툴로 6버전까지 나온 생각보다 오래된 프레임워크입니다. 이 프레임워크를 사용하려다가 원하지 않은 구성도 있고 안되는 부분도 있어서 괜찮은 부분을 벤치마킹하고 JHipster Registry 같은 경우는 완전히 가지고 왔습니다.
Docker
컨테이너 기반의 가상화 플랫폼입니다. 마이크로 서비스를 하면서 Docker를 사용하지 않고 수동으로 서버를 구성한다는 거는 숟가락으로 땅굴을 파는 거와 같습니다. 필수라고 생각합니다. 찾아보면 다른 컨테이너 기반의 가상화 플랫폼이 몇개 있습니다. 하지만 이미 Docker로 평정되고 있고 오케스트레이션이나 모니터링 툴이 Docker 위주로 나오고 있는 판국에 굳이 다른 툴을 사용해서 갈라파고스가 될 이유는 없는 거 같습니다.
프로젝트 구조
하나의 Git에 모든 프로젝트를 담는 방식은 좋다고 생각을 하지 않기도 하고 배포 시에는 CI서버에서 설정해야 하는 부분도 있지만 아래와 같이 구성한 이유는 마이크로 서비스에 대해서 해본 사람이 없고 공부를 한사람도 나밖에 없었기에 아키텍처 구조를 한번에 알기에는 하나의 Git에 같이 넣어 구성하는 게 좋다고 생각을 했습니다.
api: API에 대한 인터페이스가 들어갑니다. 해당 인터페이스에는 Swagger가 작성되어 문서화에 사용됩니다. DTO 역시 에기에 포함됩니다.
cloud: 본래는 유레카, 컨피그, 게이트웨이로 구성되었으나 JHipster Config가 사용되면서 유레카와 컨피그는 제외되었다.
config: 설정파일을 모은 폴더이다. 여러개의 서버를 띄운다고 해도 한곳에서 관리가 가능하다.
docker: 배포에 사용될 docker-compose 파일이 있는 폴더이다.
microservices: 마이크로소프트 컴포넌트들 프로젝트들이다. core 부분과 composite 부분으로 나뉜다.
core 부분에서는 DB에 접속하여 데이터를 조회하고 composite에서는 프록시 서비스로 core 마이크로 서비스를 호출하여 데이터를 가져와 가공합니다.
util: 프로젝트에서 공통으로 사용될 라이브러리가 정의되고 현재는 전역 에러 핸들러가 정의 되어있다.
앞으로 해야 할 것들
- 일래스틱 서치 적용 (로그 수집기)
- 모니터링 툴 적용
- 쿠버네티스로 전환
PS
본래는 이슈관리를 다음에 쓸려고 했으나 이슈관리는 넘어가고 다음에는 좀 더 기술적인 부분을 쓸까 한다.
이것저것 할려고 하니 하나가 고도화가 안되는 느낌이다. 이것저것 다 한다는 게 좋은 게 아니라는 걸 느낀다. 인프라 엔지니어가 있으면 좋겠다.
댓글