[90DaysOfDevOps] Day 80

클라우드/DevOps

[90DaysOfDevOps] Day 80 - Service Mesh

dayeonsheep 2024. 4. 16. 15:19

Day 80

<주요 트래픽 관리 개념>

트래픽 관리 = 마이크로서비스 통신 세계에서 중요한 주제

한 두 개가 아니라 서로 요청하는 수천 개의 서비스가 있기 때문
물리적 네트워킹의 세계에서는 네트워크 장치를 흐름 제어 및 패킷 라우팅에 사용할 수 있지만,
마이크로서비스 통신을 수용하기 위해 네트워크 규모가 커졌기 때문에,
각 연결에 대한 경로를 수동으로 생성하는 것은 잘 확장되지 않습니다.

Kubernetes는 CNI, Ingress(최근), Gateway API와 같은 기술을 통해 마이크로서비스의 네트워킹을 단순화하기 위해 많은 작업을 수행했습니다. 맞춤형 솔루션으로 해결할 수 있는 트래픽 라우팅과 관련된 다른 과제도 있습니다.

트래픽 관리와 관련하여 해결해야 할 주요 영역:

라우팅 요청
트래픽 분할
트래픽 이동
출시(앱의 새 버전)
트래픽 미러링
로드 밸런싱

+ 에 대한 설명

### 1. Request Routing

들어오는 요청을 특정 서비스 또는 버전으로 전달하는 과정을 의미합니다.

Istio는 가상 서비스 (VirtualService)를 사용하여 트래픽 라우팅 규칙을 정의하고, 요청의 경로를 다양한 방법으로 조절할 수 있습니다. 예를 들어, 특정 HTTP 헤더 값에 따라 요청을 다른 서비스 또는 버전으로 라우팅할 수 있습니다.

### 2. Traffic Splitting

트래픽의 일부를 여러 서비스나 버전으로 분할하는 기능입니다.

이를 통해 A/B 테스팅, 카나리아 배포 등의 전략을 적용할 수 있습니다. Istio는 가상 서비스의 `weight` 속성을 사용하여 트래픽을 분할할 수 있습니다.

### 3. Traffic Shifting

서비스나 버전 간의 트래픽 비율을 점진적으로 변경하는 것을 의미합니다.

예를 들어, 새로운 버전의 서비스를 10% 씩 점진적으로 트래픽에 노출시키면서 성능이나 안정성을 모니터링할 수 있습니다.

### 4. Releasing (new versions of your app)

새로운 애플리케이션 버전을 안전하게 배포하는 과정을 의미합니다.

Istio의 가상 서비스와 DestinationRule을 이용하여 카나리아 배포나 블루-그린 배포와 같은 배포 전략을 쉽게 구현할 수 있습니다. 이를 통해 새로운 버전의 애플리케이션을 출시하고, 문제가 발생할 경우 빠르게 롤백할 수 있습니다.

### 5. Traffic mirroring

복제된 트래픽을 새로운 서비스나 버전에 전송하는 기능입니다.

이를 통해 실제 트래픽을 방해하지 않으면서 새로운 버전의 서비스를 테스트하거나 모니터링할 수 있습니다.

### 6. Load-balancing

서비스 인스턴스 간의 트래픽 분산을 의미합니다.

Istio는 Envoy 프록시를 통해 로드 밸런싱을 수행하며, 라운드 로빈, 가중치 기반, 최소 연결 기반 등 다양한 로드 밸런싱 알고리즘을 지원합니다. 이를 통해 서비스의 확장성과 가용성을 높일 수 있습니다.

트래픽 또는 요청은 항상 Istio-Ingress-Gateway와 같은 일부 수신을 통해 서비스 메시로 들어갑니다.

메시에 들어가면 최종 응답이 형성되기 전에 요청이 여러 서비스를 거쳐야 할 수도 있습니다.

각 마이크로서비스에는 요청을 처리하고 일부 응답을 반환하는 사이드카가 있습니다.

그러나 이러한 각 서비스가 다른 서비스에 어떻게 도달하는지, 이러한 인바운드 요청이 들어올 때 수행할 작업도 알아야 합니다.

Client ---> Bookinfo ----> | ProductPage ---> Reviews ---> Ratings |

위의 흐름에서 클라이언트는 Bookinfo에 요청을 한 다음(DNS 이름을 통해)

경로의 첫 번째 서비스인 ProductPage에 대한 요청으로 변환됩니다.

그런 다음 리뷰의 존중과 평점의 리뷰를 일반적으로(illicit) 유도해야 합니다.

클라이언트가 Bookinfo 서비스에 요청을 보내면, 이 요청은 먼저 ProductPage 서비스로 전달됩니다.
그런 다음 ProductPage 서비스는 Reviews 서비스로 요청을 전달하고, Reviews 서비스는 Ratings 서비스로 요청을 전달합니다.

이러한 요청의 전달 과정은 서비스 메시(Service Mesh) 내에서 자동으로 처리되며, 각 마이크로서비스는 사이드카 프록시를 통해 이러한 요청을 처리하고 응답을 반환합니다.

🔹Istio Ingress Gateway

= 메시로 들어오는 요청의 진입점

= 로드 밸런서로 정의된 배포 및 서비스와 함께 배포된 리소스

istio.io와 같은 호스트 이름에 대한 요청을 특정 포트(HTTP)에서 수신하는 Istio Ingress 리소스를 생성할 수 있기 때문에 유리
여러 호스트에 대해 이 작업을 수행할 수 있음
동일한 게이트웨이에 대해 여러 Ingress 리소스를 생성하면 리소스에 사실상 과부하가 발생할 수 있으므로 이는 중요합니다.
이렇게 하면 서비스당 여러 로드 밸런서를 조달하는 비용이 절약됩니다.

여기서 말하는 "사실상 과부하"라는 표현은 하나의 게이트웨이에 여러 Ingress 리소스를 연결하면,
이 리소스들이 동시에 처리해야 할 트래픽이 증가한다는 의미입니다.

하지만 이는 실제로 과부하를 초래하는 것이 아니라,
여러 서비스나 호스트에 대한 라우팅 규칙을 중앙에서 효율적으로 관리할 수 있게 해줍니다.

즉, 여러 Ingress 리소스를 하나의 게이트웨이에 연결함으로써, 여러 서비스나 호스트에 대한 요청을 하나의 게이트웨이에서 효율적으로 처리할 수 있습니다. 이는 각 서비스마다 별도의 로드 밸런서를 구축하는 비용을 절약하게 해주며, 관리도 간소화됩니다.

간단히 말해, 이 방법은 비용과 관리 효율성을 향상시키면서도 트래픽 라우팅을 중앙에서 효과적으로 관리할 수 있는 방법을 제공합니다.

Istio Ingress Gateway로 노출되는 모든 서비스는,

해당 서비스 유형이 ClusterIP로 설정된다는 것을 의미
서비스에 직접 연결하지 않고 Ingress 게이트웨이를 통해 연결
-> 이는 TLS를 사용한 보안 계층이기도 함

Istio Ingress 게이트웨이 리소스를 구성한 다음 관련 가상 서비스를 구성하여 서비스로 라우팅합니다.

Istio의 Ingress Gateway는 Istio용으로 특별히 구축된 Envoy 프록시인 Proxyv2 이미지를 사용합니다.

gateway구성을 함 봐보자

~/networking $ cat bookinfo-gateway.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

output 정보

사용하는 특정 istio ingress gateway(label-selector 메커니즘을 사용하고 있는)
"*" : 우리가 수신 대기 중인 호스트(기본적으로 모든 호스트)를 지정
Istio Ingress Gateway는 HTTP 프로토콜을 사용하여 포트 80으로 전달되는 모든 DNS 호스트 이름으로 들어오는 요청을 수신합니다.

Istio Ingress Gateway는 기본적으로 HTTP와 HTTPS 프로토콜을 사용하여 트래픽을 수신하는 역할을 합니다.
이를 통해 포트 80(HTTP)과 포트 443(HTTPS)를 통해 들어오는 요청을 처리할 수 있습니다.

그러나 Istio Ingress Gateway의 동작은 설정에 따라 다를 수 있습니다. 특히, 사용자가 정의한 Ingress 리소스에 따라 특정 도메인 이름(host name)과 경로(path)에 대한 요청만 수신하도록 구성할 수 있습니다.
이렇게 하면 Istio Ingress Gateway는 지정된 도메인과 경로에 대해서만 요청을 처리하고, 그 외의 요청은 무시하거나 기본 라우팅 규칙에 따라 처리됩니다.

따라서 Istio Ingress Gateway는 항상 포트 80(HTTP)과 포트 443(HTTPS)를 통해 들어오는 모든 요청을 수신하는 것이 아니라, 설정에 따라 특정 도메인 이름과 경로에 대한 요청만 처리할 수 있습니다. 설정에 따라 Istio Ingress Gateway의 동작을 유연하게 조정할 수 있어 다양한 요구 사항에 맞게 트래픽을 관리할 수 있습니다.

🔹Side car

= 각 마이크로서비스 바로 옆에 위치하며 이를 대신하여 요청을 프록시하는 중요한 트래픽 관리 도구

Istio Ingress Gateway와 동일한 방식으로 작동하며 요청을 수신 및 처리하고 적절하게 응답을 제공합니다(구성된 대로).
사이드카는 관찰 가능성과 보안 측면에서도 큰 역할
사이드카도 Proxyv2 이미지 envoy 프록시를 사용함

"대신하여 요청을 프록시한다"
=> 사이드카 컨테이너가 해당 마이크로서비스의 네트워크 트래픽을 중개하고 관리한다는 의미입니다.

여기서 "프록시"는 사이드카 컨테이너가 마이크로서비스와 외부 시스템 간의 통신을 중개하는 역할을 수행한다는 것을 의미합니다.
사이드카 컨테이너는 마이크로서비스의 프로세스와 함께 실행되며, 네트워크 트래픽을 가로채어 추가적인 작업을 수행할 수 있습니다.

예를 들어, 사이드카는 로깅, 모니터링, 보안, 부하 분산 등의 기능을 제공할 수 있습니다. 이러한 방식으로 사이드카는 마이크로서비스의 코드 변경 없이도 다양한 네트워크 관리 및 보안 기능을 쉽게 추가할 수 있게 해줍니다. 따라서 사이드카는 마이크로서비스 아키텍처에서 중요한 트래픽 관리 도구로 활용되며, 시스템의 유연성과 확장성을 높이는 데 기여합니다.

Virtual Service

가상 서비스는 Istio의 "how do we get there" 규칙 집합
요청에 대한 라우팅 규칙
특정 서비스를 대상으로 하는 요청이 수신되면 여기로 라우팅

음... 그래서 뭐라고?

Istio에서 가상 서비스(VirtualService)는 특정 서비스로의 네트워크 트래픽 라우팅 규칙을 정의하는 리소스입니다.
가상 서비스는 요청의 소스, 대상, URI 경로 등 다양한 조건에 따라 트래픽을 특정 서비스 또는 버전으로 라우팅할 수 있게 해줍니다.

가상 서비스의 주요 기능:
1. **라우팅**: 가상 서비스는 트래픽을 특정 서비스나 서비스의 버전으로 라우팅하는 규칙을 정의할 수 있습니다.
2. **헤더 조작**: 요청 헤더를 수정하거나 추가하여 트래픽을 조건부로 라우팅할 수 있습니다.
3. **유연한 매칭**: 가상 서비스는 호스트 이름, 경로, 헤더 등 다양한 조건을 기반으로 트래픽을 매칭하고 라우팅할 수 있습니다. 4. **타임아웃 및 재시도 설정**: 트래픽에 대한 타임아웃, 재시도 등의 네트워크 정책을 설정할 수 있습니다.
5. **가상 피어 및 가중치 설정**: 가상 서비스는 다양한 서비스 및 버전 간의 가중치를 설정하여 트래픽을 분산할 수 있습니다.

가상 서비스를 통해 Istio 사용자는 마이크로서비스 아키텍처 내에서 트래픽의 흐름을 세밀하게 제어하고, 롤아웃 전략을 쉽게 구현할 수 있습니다. 이를 통해 서비스의 가용성, 성능, 보안 등을 효과적으로 관리할 수 있습니다.

(90데옵레퍼런스에서) 4개의 가상 서비스 구성이 있으며

- 각 구성의 "호스트" 필드는 마이크로서비스 및 Kubernetes Service 리소스에 해당합니다.

- HTTP인 프로토콜이 지정되며, 대상과 라벨이 부착된 특정 마이크로서비스로 변환되는 하위 집합이 지정됩니다.

- 이는 동일한 리소스의 여러 버전을 구별하는 데 중요합니다. 또한 구별하는 데 도움이 되는 또 다른 리소스인 대상 규칙 리소스가 필요합니다.

Destination Rules

가상 서비스는 서비스를 알려주고 서비스가 있는 위치의 항목을 호스트하는 반면, 목적지 규칙은 세부적인 작업 목록을 제공합니다.

요청이 이 목적지 대상에 도착하면 어떻게 되나요?

목적지 규칙을 사용하면 하위 집합을 사용하여 백엔드 포드를 기반으로 서비스의 여러 버전을 지정할 수 있습니다.
이는 가상 서비스 리소스에서 참조하여 라우팅할 수 있는 사용 가능한 서비스를 설정합니다.
이는 다크 출시 및 카나리아 출시에 유용할 수 있으므로 트래픽을 다른 버전으로 분할할 수 있습니다.

>> VS는 어디로 어떻게 갈지 알려주고 , DR은 어디로 가야할지를 알려줍니다 .

>> 간단히 말하면, 가상 서비스는 "어디로 트래픽을 보낼지"에 대한 지시를 제공하고, 대상 규칙은 "어떻게 트래픽을 처리할지"

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
---

review를 v1만 설정했을 때

cat samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

v2 IF 및 ONLY IF 로 라우팅하도록 구성을 업데이트

최종 사용자로서 문자열 "jason"이 포함된 요청 헤더를 전달합니다.

그렇지 않으면 내 요청은 계속해서 v1 으로 이동됩니다.

>> jason으로 sign in 해주면

review-v2로 표시됨

>> Destination Rule works with our Virtual Service Configuration이구나~ 를 알 수 있던 실습.

그렇담

Traffic을 Shift 해보자

이전에 적용한 가상서비스 세팅 delete 한 후에 적용해야됨

cat samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 70
    - destination:
        host: reviews
        subset: v3
      weight: 30

v1은 Reviews-v1을 가리키고 v3는 Reviews-v3을 가리킵니다. 이 리뷰 VS 리소스를 적용하면 v1으로 가는 요청의 70%로 트래픽을 분할하고, v3는 요청의 30%를 수신합니다.

for i in {1..10}; do curl -s http://bookinfo.io/productpage | grep "reviews-v"; done

for 루프에서 컬 명령을 사용하여 이를 테스트할 수 있음.
for 루프는 10번 실행되어 제품 페이지에 요청을 보내고 grep을 사용하여 출력을 v1 또는 v3으로 좁혔으며 70/30 Reviews-v1이 요청의 70%를 가져오는 것을 확인했습니다.

v3과 v1이 왔다갔다 하는 모습을 새로고침하면 확인 가능

그래서... 결론: allow requests to flow within a Service Mesh인 traffic management components들을 살펴볼 수 있었다!

Day 81

저작자표시 비영리 변경금지 (새창열림)

'클라우드 > DevOps' 카테고리의 다른 글

CI/CD에서 파생된 잡다한 이야기(kaniko, aws glue cicd, tekton, git flow, k8s&helm operator...) (1)	2024.04.18
[90DaysOfDevOps] Day 82~83 - Service Mesh (0)	2024.04.16
[90DaysOfDevOps] Day 77~78 - Service Mesh (0)	2024.04.16
[90DaysOfDevOps] Day 70 - CI/CD (1)	2024.04.09
[90DaysOfDevOps] Day 84~89 - Engineering for Day 2 Ops (1)	2024.04.02

현재글[90DaysOfDevOps] Day 80 - Service Mesh

Dayeons Development & DevOps blog / 소프트웨어전공 학부생 메모장

web_crawling, 라우팅프로토콜, 앱 애플리케이션 방화벽, Django, 우분투설치, Python, 보안 아키텍처, BGP, beautifulsoup, SDN, 컴퓨터네트워크, kustomize, es, WAF, kubernetes, KRO, aws, elasticsearch, crossplane, AWS WAF,

Today :
Yesterday :

일	월	화	수	목	금	토
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

DDD