클라우드 마이크로 서비스 - Microservice Architecture

Microservice Architecture

Microservice

 

amazon과 Netflix는 클라우드 서비스를 가장 잘 사용하고 활발히 서비스하고 외부로 공개하고 있는 회사라고 알려져 있다.

왼쪽 그림의 검은색 점은 각각의 서비스들로 서로 복잡하게 연결되어 있는 형태로 하나의 아마존 닷컴이라는 서비스를 유지하고 있다. 

 

그림 오른쪽의 넷플릭스라는 회사도 가각 초록색 단말에 해당하는 마이크로 서비스에서 파란색으로 보이는 이 서비스들 간의 호출 작업을 복잡하게 하고 있는 것을 확인할 수 있다. 

 

In 2002, Amazon founder and CEO Jeff Bezo's Email to Employees.

1. All team will henceforth expose their data and functionality through service interfaces.
모든 팀은 서비스 인터페이스를 통해서 데이터 와 기능을 공개해야 된다. 

2. Teams must communicate with each other through these interfaces.
팀은 이런 인터페이스를 통해서만 통신을 해야한다.

 

각각의 팀들의 네트워트에서 인터페이스를 사용하지 않는 방식은 지원하지 않을 것이다. 

 

3.There will be no other form of interprocess communication allowed : no direct linking, no direct reads of another team's data store, no shared-memory model, no back-door whatsoever. The only comminication allowed is via service interface calls over the network.

다른 형태의 프로세스 간 통신은 허용하지 않음  :  직접연결, 다른 팀의 데이터 저장소에 대한 직접 읽기, 공유 메모리 모드, 백도어 등이 있다.

 

어떤 어플리케이션에서 데이터베이스에 접속을 해서 데이터베이스의 자료를 가지고 오거나 저장하는 작업을 해야 한다. 보통 일반적으로 많이 사용하는 방법은 데이터베이스의 IP address라든가 hostnamd, port번호 그리고 아이디, 패스워드를 입력한다. 그러므로써 적절한 권한을 가지고 있는 계정을 통해서 접근을 한다.

 

그런데 이런 위 언급된 직접적인 접근은 허용하지 않을 것이고 반드시 허용되는 유일한 통신 방법은 1,2 조항에 언급된 서비스 인터페이스를 통해서만 접속을 해야 한다는 이야기 이다. 

 

4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols - doesn't matter.
그들이 사용하고 있는 기술은 중요하지 않다. HTTP, Corba 기타등등의 프로토콜 전부 포함해서 상관하지 않는다.

 

프로토콜이라든가 통신 방식이라든가 어떤 것도 중요하지 않다. 

 

5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the ouside world. No exceptions.
모든 서비스 인터페이스는 처음부터 외부에 공개될 수 있도록 디자인 되어야 한다. 다시 말해 팀들은 계획하고 디자인해야 해야한다. 시스템 외부 개발자들에게 인터페이스가 노출 될 수 있도록 예외 없이.

 

이 방식은 현재 AWS 뿐만 아니라 국내에 있는 대다수의 포털회사, IT회사들도 사용하고 있는 API 공개 방식이다. 

6. Anyone who doesn't do this will be fired.
7.Thank you; have a nice day.

 

Microservice의 특징 정리

1) Challenges

 

2) Small Well chosen Deplyable Units

독립적으로 배포가능한 작은 서비스로 이루어져 있다. 그리고 이러한 모든 것들은 하나의 서비스가 다른 서비스의 형태를 조작하고 사용하므로써 전체  어플리케이션을 구성할 수도 있다. 

 

3) Bounded Context

각가의 서비스들은 어플리케이션을 구성하고 있는 전체 도메인의 지식에 따라서 서비스 경계를 잘 구분해야하고 이런 서비스 경계 구분에 의해서 하나의 서비스가 두개가 되기도 하고 여러개의 서비스가 단일화된 서비스 형태 하나로 만들어지기도 한다.

 

4) RESTful

서비스 인터페이스가 RESTful한 API와 관련되어 있다.

 

5) Configuration Management

마이크로 서비스들이 가지고 있는 어떤 환경에 대한 정보나 설정 정보는 코드내에 가지고 있지 않을 것이고, 외부에 있는 시스템을 통해서 관리한다.

 

6)Cloud Enabled

클라우드 네이티브 기술을 최대한 활용해서 서비스를 제공한다. 마이크로 서비스를 지원할 수 있는 백킹 서비스라든가 서비스 메시어 같은 기능들, Configuration과 게이트웨이 같은 모든 것들은 클라우드 상태에서 운영을 할 것이다.

 

7)Dynamic Sacle Up And Scale Down

서비스를 제공하는 인스턴스들은 부하분산 처리나 scale up, scale down등을 동적으로 처리할 수 있도록 구성되어야 한다.

 

하나의 서비스에서 하나의 시스템 또는 인스턴스만 직접 서비스 되는 것이 아니라 여러 개 분산된 형태로서 만약에 첫 번째 있는 마이크로 서비스는 두 개의 호스트(인스턴스)에서 두 번 째 같은 경우는 네개의 인스턴스에서 세 번째 같은 경우는 하나의 인스턴스에서 서비스가 될 수도 있다는 이야기 이다.

 

8)CI/CD

이런 서비스 여러 개가 묶여서 하나의 어플리캐이션을 구성하다 보니까 자동화 배포 기능인 CI/CD가 중요하다.

 

9)Visibility

마이크로 서비스들은 시각화 할 수 있는 관리 도구를 가지고 있어야 한다.

 

 

🤔"Everything should be a microservice"

그러면 기업에서는 기존의 4가지 시스템들을 마이크로 서비스로 전환을 하거나 신규 프로젝트를 무조건 마이크로 서비스로 개발해야 할까? 모든 것이 전부다 마이크로 서비스가 되어야 할까? → 그렇지 않다. 🙅‍♀️❌

 

 

마이크로 서비스 아키텍처 도입을 고려하기 전에 고려해 볼 질문들 

 

Q1) Multiple Rates of Change(어느 정도 변화가 생길 것인가)

기존 개발 대비 시간과 비용을 더 투자 해야 하는 것은 분명하다. 그럼에도 불구하고 도입해야 한다고 하면 어느정도의 공수를 고려하고 받아들일 수 있을 것인가.

 

Q2) Independent Life Cycles(독립 라이프 사이클)

어플리케이션을 구성하고 있는 각각의 서비스들이 독립적으로 개발되고 운영될 수 있도록 서비스 경계가 잘 만들어져 있는가에 대한 문제이다. 

 

Q3) Independent Scalability(독립적인 확장성)

각각의 서비스를 운영함에 있어서 서비스 유지 보수 및 확장성이 가능한가, 스케일링이 쉽게 할수 있도록 되어 있는가?

 

Q4) Isolated Failure(격리된 오류)

오류 자체가 발생할 수 없는 게 제일 좋지만, 컴퓨터 소프트웨어의 오류를 완전히 피하는 것은 불가능하다. 그렇기 때문에 되도록 오류가 발생 하더라도 오류사항이 독립적인가에 대해 판단할 수 있어야 한다. 마이크로 서비스의 부분적인 오류가 발생되었 다고 하더라도 해당 서비스에 대해서만 오류가 영향 받도록 설계되었는지, 다른 마이크로 서비스들은 오류에 최소한의 영향을 받으면서 해당 서비스를 우회할 수 있는 대체 서비스가 준비되어 있는지를 고려해봐야 한다. 

 

Q5) Simplify Interactions with External Dependencies(외부 종속성과의 상호작용을 단순화)

물론 외부뿐만 아니라 종속성 자체의 커플링이라는 것은 좋지 않은 것이다. 그렇기 때문에 시스템이나 서비스 간의 종속성을 최소화하고 반대로 응집력을 높일 수 있도록 서비스 경계가 잘 구분되어 있는가를 고려해야 한다. 

 

Q6) Ployglot Technology(여러가지 프로그램언어, 여러가지 프토리지 기술을 사용할 수 있게 지원)

각각 서비스들이 제공해야 되는 기능에 맞는 프로그램의 언어와 데이터베이스 운영환경을 자유롭게 선택할 수 있고 지정할 수 있는가 

 

 

지금까지 설명한 마이크로 서비스들은 그 서비스를 구성하는 서비스의 경계, 업무의 범위, 용도와 사용 시나리오 등에 따라서 하나의 비지니스 로직이 하나의 서비스일 수도 있고, 더 작은 서비스일 수도 있다. 하나의 서비스와 다른 분리된 서비스 를 조합해서 새로운 영역의 서비스를 생성할 수도 있다. 이런 기능은 마치 장난감 레고와도 같다. 다양한 형태의 모양과 크기를 가지고 있지만 기본적인 구조는 동일하고 필요에 따라서 자유롭게 배치해서 블록과 같은 서비스를 생성할 수 있는 것이다. 

 

 

Microservice Team Structure

• Two Pizza team
• Teams communicating through API contracts
• Develop, test and deploy each service independently
• Consumer Driven Contract

 

 

점심 한 끼를 같이 먹을 때 피자 투 판을 같이 나눠 먹을 수 있는 인원이 가장 이상적인 DevOps의 구성원이라는 것에서 나오게 된 용어이다. 이렇게 나누게 된 배경은 커뮤니케이션 비용이 적게 발생하고 개발과 테스트와 운영 배포등에 각각 독립적으로 개발할 수 있는 최소 단위라는 판단에서 나온 이야기 같다.

 

예를 들어서 5명의 인원이 2주 동안에 어떤 서비스 기능을 만들어야 한다고 가정해 보자. 2주라는 절대적인 시간을 조건으로 해서 구현할 수 있는 기능의 범위가 어느정도 될까? 서비스 개발을 위한 분석과 설계, 구현과 테스트 그리고 배포를 모두 포함하는 프로세스여야  한다. 아마도 이러한 기능이 그렇게 어렵거나 복잡한 기능을 아닐 것이다. 단기간에 끝나야 될 작은 기능일 가능성이 높다. 

 

모든 사항이 다 그렇지는 않지만 마이크로 서비스의 규모는 물론 어플리케이션에서 정한 범위나 고객의 요구 사항에 따라 달라지겠지만, 각각 분리되어야 하는 서비스의 경계를 기준으로 쪼개져 있다고 생각하면된다. 이름 그대로 조금한 기능을 가진 마이크로 서비스 수십, 수백 개 개발을 해서 서로 서비스 인터페이스로 연결해 사용하는 구조로 전체 어플리케이션을 구성 하는 것이다. 

 

 

[출처 - Spring Cloud로 개발하는 마이크로 서비스 애플리케이션, 저 Dowon Lee]

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의