IT/Istio

[Istio] Istio는 무엇일까(개론)

wookiist 2021. 3. 5. 10:38

[Istio] Istio는 무엇일까(개론)

Kubernetes Korea Group에서 진행하고 있는 Istio 스터디 첫 날 내용을 정리해봅니다. 현업에 투입된지 얼마 되지 않았다보니 Kubernetes 외적으로 다양한 이야기가 나왔지만 모두 이해하긴 어려웠습니다. 앞으로도 꾸준한 스터디와 자기계발이 필요하겠다는 걸 절실히 느낄 수 있는 시간이었습니다.

Microservice Architecture (MSA)

Istio를 이야기하기 전에, MSA를 먼저 정리해보겠습니다. MSA는 작은 Service 단위로 큰 프로젝트를 잘게 나누어 구성하는 구조를 의미합니다. 여기에서 말하는 Service는 기능의 단위라고 생각하면 됩니다. 하나의 Service는 하나의 기능만을 수행하도록 역할을 세밀하게 분리하고 구조를 단순화한 것입니다. 따라서 기존 Monolithic Architecture에 비해 기능별로 서비스를 구성하게 되니 기능 당 유지보수가 쉽습니다. 또한 기능이 서로 독립적이니, 하나의 기능 장애는 해당 Service에만 영향을 미친다는 장점이 있습니다.

단점이 없는 것은 아닙니다. 각각의 Service가 서로 호출하는 Mesh 구조를 가지므로, Service 간의 모니터링이 어렵다는 점, 또 Service가 통신을 위해 네트워크를 사용하므로, 네트워크 쪽의 부하가 몰리게 된다는 점 등은 MSA의 단점으로 꼽고 있습니다.

MSA 구현 방식

Response / Request Microservice


(출처 : https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture)

Sync Request/Response 기반 통신 메커니즘을 사용하는 경우, HTTP를 이용한 REST API 통신 방식이 특히 많이 사용되고 있습니다. Request/Response 기반 통신 메커니즘은 특히 Client Application에서 실시간 데이터를 쿼리하는 데 적합합니다.

Event-Driven Microservice

(출처 : https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/asynchronous-message-based-communication)

각 Service가 공통적으로 사용하는 메시지 구조를 미리 알고 있어야 하는 Request/Response 방식과는 달리, Event-Driven 방식에서는 이를 알고 있을 필요가 없습니다. Service 간의 통신은 각 Service가 생성하는 Event를 통해 이루어지기 때문입니다. 메시지를 전달해주는 Broker가 중간에 위치한 것은 Request/Response 방식과 유사하지만, 각 Event의 세부 내용을 알 필요가 없다는 점이 특징입니다. Event-Driven 방식에서 각 Service는 Event의 메시지가 아닌, Event가 발생했다는 그 사실 자체에 반응하기 때문입니다.

MSA의 발전

초기의 MSA는 Client Library를 이용해 개발되었습니다. Spring Cloud에서 MSA를 신속하게 구축할 수 있는 도구를 제공해왔고, 특히 Netflix에서 제공하던 Netflix Eureka, Netflix Ribbon, Netflix Hystrix를 도입하여 더 쉽고 빠르게 Service를 구축할 수 있도록 도와주었습니다.

그러나 이런 방식에도 단점이 있었습니다. Service를 개발하기 위해 Spring을 이용해야 했기에 개발 언어에 제약 사항이 많다는 점이 첫 번째였습니다. 또한 특정 Library에 종속되어 있다 보니, Library가 업데이트 되더라도, 이를 업그레이드하는 데에 공수가 많이 들었습니다.

Service Proxy 방식의 MSA는 이러한 초기 MSA 형태의 단점을 모두 커버할 수 있었는데요. 특정 라이브러리를 사용할 필요가 없기 떄문에 개발 언어에 제약 사항이 없었고, 통신을 수행하는 Service Proxy가 독립적인 프로세스이기 때문에 업그레이드를 수행하기에도 용이했습니다.

MSA 구성 요소

Service Discovery

이미 만들어진 MSA 구조에 새로운 Service를 추가한다고 가정해보겠습니다. 이 새로운 Service는 기존 Service와 상호작용하려면, 기존 Service들의 정보를 파악하고 있어야 합니다. 또한 기존 Service들도, 새로운 Service가 이상한 Service는 아닌지, 정상적으로 추가된 기능인지 확인하고 해당 Service의 정보를 파악할 필요가 있습니다. 만약 이러한 작업을 개발자나 운용자가 직접 수행해야 했다면 정말 힘들었을텐데요. 이러한 인스턴스의 상태를 동적으로 관리하는 기능이 바로 Service Discovery입니다.

Circuit Breaker

Circuit Breaker는 MSA의 특정 서비스에 문제가 발생하더라도, 장애가 전반적으로 확산하지 않도록 차단해주는 기능을 일컫습니다. 아무리 세밀하게 나눠진 구조라고 하더라도, 특정 서비스의 과부하로 인해 전체 서비스에 영향을 주는 일이 없을 수는 없기 때문입니다.

또한 Circuit Breaker는 FallBack 기능도 수행합니다. 정해진 시간 내에 Service의 호출이 실패하면, 예외처리의 개념으로 대신 동작하는 기능입니다. 개발자가 Exception을 구현하는 것과 유사하다고 생각하면 됩니다.

마지막으로 각 서버의 상태를 확인할 수 있는 모니터링 서비스까지 제공하고 있어, 로그를 중앙 집중형으로 관리, 검색할 수 있습니다.

Service Mesh

Service-to-Service 통신을 처리하는 작업만을 수행하기 위한 dedicated infra layer입니다.

Service Mesh's Control Plane

Service Mesh의 Control Plane은 Service Proxy가 제어와 메트릭 수집을 할 수 있도록 합니다.

Service Mesh

어제 스터디를 진행해주셨던 안승규님의 발표 자료와 내용에서 정리된 자료임을 먼저 밝힙니다.

  • Service Mesh는 Application과 이들 사이의 상호 작용을 구성하고 있는 Microservice Network를 의미합니다.
  • Service Mesh의 크기가 커지면, 그물망(Mesh) 구조가 되기 때문에 Application의 관리와 운영이 힘들어집니다.
  • Application의 관리를 위해 Service Discovery, Load Balancing, Failure Recovery, Metrics and Monitoring이 필요합니다.
  • Application의 운영을 위해 A/B Testing, Canary Rollouts, Rate Limiting, Access Control, End-to-End Authentication이 필요합니다.

Sidecar 패턴은 Application의 Service 앞단에 Service 사이의 통신 제어를 담당하는 경량 Service Proxy를 배치하는 디자인 패턴입니다. Application 자체에 내장하는 것이 아닌, 옆단에 배치하는 것이기 때문에 기본 Application을 수정하지 않고도 Service 사이의 통신 기능을 수행할 수 있습니다. 그리고 이 Proxy를 이용해 시스템의 상태 등을 파악할 수 있는 System Metric 등의 자원 정보를 공유할 수 있는 구조로 개발이 가능하다는 장점도 있습니다.

대표적인 Sidecar 패턴의 오픈소스로는 금일 포스팅의 메인 주제인 Istio가 있습니다. Istio는 Google, IBM, Lyft가 함께 주도하는 Kubernetes 기반 솔루션입니다.

Istio

Istio는 Service Mesh에 Control Plane 기능을 부여합니다. Data Plane 구성도 용이하게 해주지만 주 목적은 Control Plane 으로 볼 수 있다고 합니다. Istio는 Service Proxy로 Envoy Proxy를 사용하고 있습니다. Envoy는 추후 자세히 다뤄볼 예정입니다만, 간단하게 요약하자면, C++로 구현한 고성능 분산 Proxy입니다. Istio는 이 Envoy Proxy를 관리하는 기능을 제공하고 있는 것이죠.

Istio는 Spring Cloud Netflix와 많은 유사점이 있지만, Java라는 언어에 종속된 Spring Cloud Netflix와는 달리, Istio는 플랫폼의 영역에서 동작하기 때문에 개발 언어와 무관하게 사용할 수 있습니다.

다음 포스트에서는 Istio의 각 컴포넌트에 대해 정리해보겠습니다.

혹여나

혹여나 지금까지 서술된 내용 중 사실과 다르거나, 오류가 있는 경우 댓글로 짚어주시면 정말 감사하겠습니다. 아직까지 스터디를 통해 '들'은 내용과 '본' 내용을 적고 있을 뿐, 직접 경험해보면서 습득한 내용이 아니다보니 오류가 뿜뿜일 것 같아 걱정입니다.

그래도 내용이 괜찮았다면 아래의 '좋아요'! 한번 눌러주시면 하루 종일 행복할 것 같습니다 🙂

참고

반응형
저작자표시 비영리 변경금지

'IT/Istio'의 다른글

  • 현재글[Istio] Istio는 무엇일까(개론)
댓글

티스토리툴바