Building Microservices

endsoul·2022년 1월 21일
0

1. What Are Microservices?

대부분의 경우에 마이크로서비스 아키텍쳐는 데이터베이스를 공유하지 않는다. 대신 각각의 마이크로서비스들은 자신의 데이터베이스를 가진다.

마이크로서비스는 Information Hiding이라는 개념을 가진다. 이 개념은 가능한 많은 정보를 컴포넌트 내부에 숨기고 최대한 적은 정보를 외부 인터페이스를 통해서 노출한다. OOP의 객체와 비슷하게 생각하면 된다.

마이크로서비스가 backward-incompatible한 방법으로 외부에 노출하는 네트워크 인터페이스를 변경하지 않는한 외부로부터 숨겨진 구현은 자유롭게 변경할 수 있다. 반대로 외부 인터페이스를 backward-compatible하게 변경하지 않는다면 이 마이크로서비스와 커뮤니케이션하는 마이크로서비스들도 수정, 재배포, 릴리즈를 해야한다.

따라서 외부 인터페이스를 backward-compatible하게 유지한다면 마이크로서비스들 간에 어떤 커뮤니케이션 인터페이스를 사용하건(JSON, TCP/IP 등...) 내부 구현은 자유롭게 변경할 수 있다.

SOA(SERVICE-ORIENTED ARCHITECTURE)는 모든 것이 데이터베이스와 결합되어 있다. 그래서 배포를 할 때 데이터베이스도 함께 수정하고 그 데이터베이스를 사용하는 다른 것들도 함께 배포해야 한다. 이것은 마이크로서비스가 아니다. 마이크로서비스는 SOA를 구현하는 하나의 방법이다.

Independent deployability는 어떤 마이크로서비스가 변경이 필요해서 변경한다면 이 서비스만 배포, 릴리즈 한다. 이 서비스가 변경된다고 다른 서비스들도 같이 변경, 배포, 릴리즈 해야 한다면 그건 마이크로서비스가 아니다.


three-tiered architecture 에서는 변경이 발생하면 3개의 layer 모두 변경해야 한다.


예전에는 기술에 따라서 팀을 조직했다. 예를 들어 프론트, 백엔드, DBA 팀이다.
이렇게 나누는 것 보다는 비즈니스 로직 기능 단위로 팀을 나눈다. 하나의 기능을 수정한다면 그 기능을 담당하는 팀에서만 작업하면 된다.


Profile 기능을 변경한다면 Customer profile team이 가진 해당 마이크로서비스의 Frontend, Business logic, Data를 수정한다. 물론 Data도 해당 마이크로서비스에 저장된다. 예를 들어 사용자가 가장 선호하는 장르를 선택하는 기능을 만든다면 Catalog 마이크로서비스에서 사용 가능한 장르 리스트를 가져오고 사용자에 따른 추천 장르 리스트를 Recommendation 마이크로서비스로부터 가져온다.

Monolith 아키텍쳐는 점차 시스템이 커지면서 single-process monolith -> modular monolith -> distributed monolith 로 변해간다. 그러나 여러 Monolith 아키텍쳐들 모두 변경이 발생한다면 배포 시에 거의 전체 시스템을 배포해야 한다.

마이크로서비스를 사용하려 한다면 많은 기술들에 압도되지 말고 하나하나씩 자신의 서비스 크기를 키우면서 문제가 있을 때 해결할 수 있는 기술들을 리서치하고 도입하면 된다. 그러나 적어도 log aggregation tool(Jaeger)은 초기에 적용하는게 좋다.

컨테이너를 사용하면 시스템에 문제가 발생했을 때 그 문제가 다른 시스템에 전파되지는 않는다(isolation).

0개의 댓글