반응형
많은 회사에서 마이크로서비스를 주목하고 있고 도입하고있다.
그 이유가 무엇인지 궁금했고, 알아보기 위해서 마이크로 서비스관련 책을 하나 구입하였다.
생각보다 책이 두껍지만 외국 저서 같지 않게 설명이 자세하게 되어있다. (사례도 많다.)
그럼 이제 마이크로 서비스가 무엇인지 알아보자.
아래 사진을 보자.
우리회사도 그렇고 기존에 웹 애플리케이션은 왼쪽의 사진처럼 하나의 구조로 이루어져있어 war 형태로 배포된다.
모든 서비스가 하나의 애플리케이션으로 구성되어있을 경우에는 새로운 기능을 추가하거나, 성능을 위해 시스템을 나누기 위하는 작업 등등이 너무 어렵다.
그래서 요새 대형 서비스에서는 서비스를 새로 추가하기도 쉽고, 더 많이 사용하는 서비스에 물리적인 자원을 더 할당할 수 있도록 마이크로서비스를 지원한다.
마이크로서비스에 대해 본격적으로 공부에 들어가기 전에 정리부터 해봤다.
[마이크로 서비스 특징]
- 서비스를 잘게 쪼개서 만드는 서비스
- 하나의 아키텍쳐에 서비스를 올리는 방식을 지나 서비스별로 모듈을 나누는 마이크로 서비스가 유행이다.
- 빠르게 개발하고 서비스 하기 위해서 스프링 부트를 많이 사용한다.
- 각 서비스가 Rest API 뒤에 숨어있기 때문에 어떤 개발언어, db등을 사용해도 무관하게 서비스가 가능하다.
- 마이크로서비스는 일체형 애플리케이션을 여러 개의 작은 서비스로 분리하기 때문에 빌드, 테스트, 배포, 확장 까지 모두 자동화해서 진행한다.
-> git, travis, jenkins등의 형상관리 툴을 사용하여 자동화한다.
- 가장 큰 장점은 서비스를 분리할 수 있다.
-> 로그를 기록하는 서비스의 경우 하둡 파일 시스템을 사용하고 실제 동작을 진행하는 서비스는 관계형 데이터베이스를 사용한다고 하였을 때, 두 서비스를 분리함으로써 다른 방법으로 개발을 진행할 수 있어서 효율적이다.
- 결국 위와 같은 이유 때문에 캡슐화가 굉장히 잘 되어있게된다.
- 모듈 자체 구현내용은 은닉되어있고, 앞에 정보 요청에 대한 API만을 공개하게 되며 새로운 기능을 넣고 빼는데 거리낌이 없는 서비스가 될 수 있어서 좋다.
- 또한 기술이 오래된 경우 변경하도록 할 떄, 교체하는 비용과 주기가 줄어든다. (모듈별로 바꿀 수 있다. 점진적 진행 가능)
- 각 모듈별로 버전을 달리할 수 있다. (우리회사만 해도 모두 하나의 apache-tomcat에 올라가기 때문에 자바 버전이나 이런 것에 굉장히 예민하다. 그래서 아직 자바 1.8를 사용하지 못했다. 하지만 이렇게 서로 다른 모듈로서 관리할 수 있으면 버전에 상관없이 서비스를 진행할 수 있다.)
[결론]
물론 단일 애플리케이션의 단점만 존재하는 것은 아니다. 그렇게 많은 서비스를 지원하지 않고 단조로운 서비스에 경우에는 오히려 단일 애플리케이션 구조가 더욱 유지보수가 효울적이다. 하지만 시대가 변하고 많은 서비스를 빠르게 지원하고 관리해야하는 상황에서 마이크로서비스는 많은 잠점을 가지고 있는 것 같다. 넷플릭스, 구글 등등 외국에서 뿐만아니라 한국에서도 배달의민족, 카카오 등등 많은 곳에서 사용하고 있다. 재밌는 공부가 될 것 같다.
모든 서비스가 하나의 애플리케이션으로 구성되어있을 경우에는 새로운 기능을 추가하거나, 성능을 위해 시스템을 나누기 위하는 작업 등등이 너무 어렵다.
그래서 요새 대형 서비스에서는 서비스를 새로 추가하기도 쉽고, 더 많이 사용하는 서비스에 물리적인 자원을 더 할당할 수 있도록 마이크로서비스를 지원한다.
마이크로서비스에 대해 본격적으로 공부에 들어가기 전에 정리부터 해봤다.
[마이크로 서비스 특징]
- 서비스를 잘게 쪼개서 만드는 서비스
- 하나의 아키텍쳐에 서비스를 올리는 방식을 지나 서비스별로 모듈을 나누는 마이크로 서비스가 유행이다.
- 빠르게 개발하고 서비스 하기 위해서 스프링 부트를 많이 사용한다.
- 각 서비스가 Rest API 뒤에 숨어있기 때문에 어떤 개발언어, db등을 사용해도 무관하게 서비스가 가능하다.
- 마이크로서비스는 일체형 애플리케이션을 여러 개의 작은 서비스로 분리하기 때문에 빌드, 테스트, 배포, 확장 까지 모두 자동화해서 진행한다.
-> git, travis, jenkins등의 형상관리 툴을 사용하여 자동화한다.
- 가장 큰 장점은 서비스를 분리할 수 있다.
-> 로그를 기록하는 서비스의 경우 하둡 파일 시스템을 사용하고 실제 동작을 진행하는 서비스는 관계형 데이터베이스를 사용한다고 하였을 때, 두 서비스를 분리함으로써 다른 방법으로 개발을 진행할 수 있어서 효율적이다.
- 결국 위와 같은 이유 때문에 캡슐화가 굉장히 잘 되어있게된다.
- 모듈 자체 구현내용은 은닉되어있고, 앞에 정보 요청에 대한 API만을 공개하게 되며 새로운 기능을 넣고 빼는데 거리낌이 없는 서비스가 될 수 있어서 좋다.
- 또한 기술이 오래된 경우 변경하도록 할 떄, 교체하는 비용과 주기가 줄어든다. (모듈별로 바꿀 수 있다. 점진적 진행 가능)
- 각 모듈별로 버전을 달리할 수 있다. (우리회사만 해도 모두 하나의 apache-tomcat에 올라가기 때문에 자바 버전이나 이런 것에 굉장히 예민하다. 그래서 아직 자바 1.8를 사용하지 못했다. 하지만 이렇게 서로 다른 모듈로서 관리할 수 있으면 버전에 상관없이 서비스를 진행할 수 있다.)
[결론]
물론 단일 애플리케이션의 단점만 존재하는 것은 아니다. 그렇게 많은 서비스를 지원하지 않고 단조로운 서비스에 경우에는 오히려 단일 애플리케이션 구조가 더욱 유지보수가 효울적이다. 하지만 시대가 변하고 많은 서비스를 빠르게 지원하고 관리해야하는 상황에서 마이크로서비스는 많은 잠점을 가지고 있는 것 같다. 넷플릭스, 구글 등등 외국에서 뿐만아니라 한국에서도 배달의민족, 카카오 등등 많은 곳에서 사용하고 있다. 재밌는 공부가 될 것 같다.
반응형
'web > 마이크로서비스' 카테고리의 다른 글
스프링 웹플럭스(spring webflux)를 활용한 간단한 리액티브 마이크로 서비스 (0) | 2018.10.04 |
---|---|
리액티브 스트림의 이해 (0) | 2018.10.04 |
스프링 부트와 RabbitMQ를 사용한 리액티브 마이크로 서비스 (0) | 2018.10.04 |
리액티브 마이크로 서비스 정리 (0) | 2018.10.04 |
애플리케이션 확장 방법 스케일 큐브 (Scale Cube) (0) | 2018.05.27 |