우리는 보통 새로운 애플리케이션을 만들 때, 하나의 개발환경을 세팅하고(OS는 RedHat, JDK1.8에 Mysql5.7 등등)
작은 애플리케이션부터 만들기 시작한다.
이후 애플리케이션에 새로운 기능이 추가될수록 코드의 양은 점점 많아지고 하나의 모듈도 거대해지게 된다.
만약 버그라도 생기면 오류를 찾아내기가 쉽지 않을 뿐더러 조금만 변경하기도 두려워진다.
마이크로서비스 아키텍처는 하나의 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 각각의 애플리케이션들은 작고 독립적인 서비스로 구성된다.
즉, 각각의 작은 애플리케이션들로 세분화함으로써 서로의 API에만 의존하게 된다.
이러한 마이크로서비스는 이전부터 존재하던 방식이다. 기존에는 객체지향 프로그래밍 언어 등으로 추상화, 캡슐화하거나 모듈화 하여 설계를 했다.
그러나 2013년 컨테이너 방식의 가상화인 도커(Docker)의 등장과 함께 최근에는 쿠버네티스(Kubernetes)로 Private Cloud 환경이 핫해지면서 마이크로서비스를 클라우드에서 좀 더 쉽게 구현과 운영할 수 있게 되었다.
애플리케이션을 크게 모놀리스와 마이크로서비스 2종류로 나눌 수 있다.
모놀리스 애플리케이션은 모든 기능과 컴포넌트를 하나의 단위에서 구축하여 하나의 애플리케이션으로 배포된다.
마이크로서비스로 구현된 애플리케이션은 독립된 서비스 또는 모듈이 애플리케이션의 기능과 함께 배포된다.
예를 들어 넷플릭스의 서비스를 마이크로서비스로 구현이 되면 회원가입, 검색, 계정관리, 결제, 스트리밍 등이 독립적으로 운영이 되는 것이다. 결제를 담당하는 팀 개발자가 스트리밍 모듈의 세부내용까지 알 필요 없으며 API만 알면 된다.
1. 각각의 서비스가 단순하다.
각각의 서비스는 서로 최소의 의존성(API)으로만 연결되어 느슨하게 결합이 되어있다.
2. 독립적인 배포가 가능하다
서비스들 간의 느슨한 결합을 유지하고 있기 때문에 최악의 상황에서 롤백을 해야 되더라도 다른 서비스에는 영향이 없다.
3. 데브옵스(DevOps) 수행 및 지속적인 통합 및 혁신에 용이하다.
급변하는 시장 속에서 개발과 운영의 지속적인 통합을 통해 빠르게 예기치 못한 버그나 업데이트에 대처할 수 있다.
4. 효율적인 자원(리소스) 사용이 가능하다.
어떤 서비스는 많은 리소스가 필요하고, 또 어떤 자원은 적은 리소스로 운영이 될 수 있다. 이럴 때는 AWS나 애저 같은 클라우드를 활용하여 도커나 쿠버네티스로 컨테이너로 마이크로 서비스를 운영할 경우, 필요에 따라 각각의 서비스에서 사용할 자원만큼 리소스를 확장하거나 최소화할 수 있어서 리소스의 낭비를 줄여 애플리케이션 운영 및 배포비용을 최소화 할 수 있다.
위와 같이 애플리케이션에 필요한 만큼 자원을 할당하여 컨테이너를 구성할 수 있다.
1. 서로 통신이 복잡하다.
서비스를 최소 기능을 하도록 쪼개어 API로 연결을 한다면 기존 모놀리식보다 통신 측면에서 비효율적이다.
모놀리식에서는 적은 수의 함수 호출로 곧바로 output을 받을 수 있는 반면에 마이크로서비스에서는 여러 번의 네트워크 통신으로 API를 호출해야 할 것이다.
2. 계단식 실패 허용
서로의 서비스는 네트워크에 의존하여 API를 주고받기 때문에 한 서비스가 호출과 응답에서 오랜 시간이 걸려 리소스가 묶여버리게 되면 모든 스레드를 소진할 수도 있다. 이럴 경우에 하위에 통신해야 할 서비스들은 줄줄이 계단처럼 중단하게 된다.
이런 문제는 클라우드 디자인 패턴을 통해 효율적인 아키텍처를 설계하는 방법으로 해결할 수 있다고 한다.
피드백은 언제나 환영입니다.
RISC-V #3 - 가상화를 통한 RISC-V 부팅 실습 (2) | 2019.07.29 |
---|---|
마이크로서비스#3 - 쿠버네티스란 무엇인가? (0) | 2019.07.27 |
마이크로서비스#2 - 가상화 컨테이너기술에 대한 이해 (0) | 2019.07.22 |
RISC-V #2 - RISC-V와 ARM 명령어 셋 비교 (0) | 2019.07.19 |
RISC-V #1 - 개요 (0) | 2019.07.12 |