Istio - 1 (MSA, Service Mesh)

1. 마이크로서비스(MSA)

• 기존의 모놀리틱에서 서비스를 기능별로 작게 나누는 방법론입니다.
• 모놀리틱 방식보다 성능과 유지보수 측면이 우수하기 때문에 MSA로 전환하는 추세지만, 모든 서비스 구조를 파악하지 못할 만큼 규모가 커진다면 역효과를 낳게 됩니다.

 

MSA 대표 사례

 

 

※ 서비스가 서비스를 호출하는 방식이 되면, 아래와 같은 이슈가 생길 수 있습니다.

1. service A가 service B에게 요청을 해서 응답을 기다리는 중인데 service B는 정상 작동하지 않는상태

2. service A는 요청을 받을때까지 대기 상태가 되며, 그사실을 모르는 service A의 다른 thread도 대기상태가 됨

3. 모든 thread가 대기상태인 service A는 이후 다른 service가 service A를 호출하는 상황에도 응답하지 못함

4. 3번과 같은 상황이 파도타기 처럼 발생하면, 이슈 원인을 파악하기가 더욱더 힘들어짐  (장애 전파 현상)

 

 

 

1.1 써킷 브레이커(Circuit breaker)

1. service B가 정상 작동하지 않을때 써킷 브레이커가 service A의 요청을 끊고 에러를 받게 함

2. 편안~

 

※ 써킷 브레이커를 넷플릭스에서 오픈 해놓은 Hystrix로 구현 가능함 

 

 

2. 서비스 매쉬(Service Mesh)

MSA를 소프트웨어에서 코드로 풀어내려고 하니 복잡성이 커지는 문제때문에 인프라에서 해결하는 방법임

 

• 기존의 서비스가 서비스를 호출하는 방식

 

• 모든 서비스 앞단에 proxy를 두고 호출하는 방식
• proxy가 써킷 브레이크 역할을 해줌
• Client의 정보로 보여줄 service를 구분지을 수 도 있음

 

• 서비스 최적화는 했지만, 서비스 수만큼 늘어나는 Proxy의 설정을 하기가 어려운 탓에 Proxy 설정을 중앙 관리화 하는 구조가 나오게 되었음

Data Plane      :  서비스의 트래픽을 제어하는곳 

Control Plane  :  Proxy의 설정을 관리하는곳

 

Istio 구조