개요

이번에는 간단하게 에러가 나는 상황을 만들고, 이를 서비스 메시의 기능으로 대응하는 실습을 해본다.
이전에 전체적인 개념 설명을 끝냈으므로 바로 실습을 진행할 것이다.

실습 진행

여태 이스티오 문서에서 예제로 제공해준 bookInfo를 이용해서 실습을 진행하고 있다.
책에서는 독자적인 예제를 사용해 랜덤하게 에러를 발생시킨 후 재시도 횟수를 늘려 성공률을 높이는 실습을 보여주는데, 이스티오 공식 문서에 bookInfo 실습 관련 문서와, 예제 양식 파일을 봤을 때는 비슷하게 실습할 수 있는 설정이 없었다.
bookInfo에서 진행할 수 있는 에러 주입 관련 실습은 다음과 같은 방식이다.

• jason이란 유저로 로그인하면 에러 주입(이스티오의 fault injection 기능 활용)
  • 이때 브라우저로 productpage에 들어가 로그인을 해서 세션을 얻어야 한다.
  • 
  • 세션 정보가 생기면 productpage에서 이후 api 요청을 날릴 때 헤더에 end-user 필드를 넣어서 전달한다.
  • curl로 세션키가 들어간 쿠키 파일을 저장하는 방법이 있긴 하지만, 반복 자동화를 하긴 번거롭다.

그러나 직접적으로 소스 코드를 파보니 애플리케이션 단에서 에러를 발생시킬 수 있는 설정을 찾을 수 있었다.^[1]
문서를 조금 더 제대로 뒤져보면 관련한 부분이 나올지도 모르겠다.

rating 어플리케이션에 환경 변수 설정을 통해 데이터소스로 mysql이나 몽고 db를 사용할 수 있도록 돼있다.
근데 여기에 추가적으로 에러를 발생시킬 수 있도록 코드가 세팅돼있다.
그래서 파드 환경 변수로 특정 값을 설정하여 에러를 확률적으로 발생시키는 것이 가능하다.
이를 활용해 책의 예제와 비슷하게, 재시도 횟수를 늘리는 것만으로 성공률을 높이는 실습을 해보겠다.

에러 발생시키기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ratings-v1
  labels:
    app: ratings
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ratings
      version: v1
  template:
    metadata:
      labels:
        app: ratings
        version: v1
    spec:
      serviceAccountName: bookinfo-ratings
      containers:
      - name: ratings
        image: docker.io/istio/examples-bookinfo-ratings-v1:1.20.2
        imagePullPolicy: IfNotPresent
        env:
          - name: SERVICE_VERSION
            value: v-faulty
        ports:
        - containerPort: 9080

일단 에러를 발생하게 하는 것은 간단하다.
rating 디플로이먼트에서 컨테이너에 환경 변수로 SERVICE_VERSION을 세팅해주기만 하면 끝이다.
에러 상황과 관련한 값들은 다음의 것들이 있다.

• v-unavailable - 컨테이너 시작 직후 60초 동안 서비스를 이용불가 상태로 만든다.
• v-unhealthy - 15분 간격으로 컨테이너가 건강하지 않은 상태가 된다.
• v-faulty - 50퍼센트 확률로 요청이 실패한다.
• v-delayed - 50퍼센트 확률로 응답이 7초 지연된다.

v1, v2 같은 값을 세팅하면 mysql과 mongodb를 데이터 소스로 두는 설정이 된다.

보다시피 ratings에서 50퍼센트 확률로 에러가 발생 중이다.

재시도 설정을 통해 에러율 개선

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - retries:
      attempts: 5
      perTryTimeout: 7s
      retryOn: 5xx
    route:
      - destination:
          host: ratings

ratings에 재시도 설정을 넣는 virtualservice 리소스를 만든다.
참고로 아무 설정을 하지 않으면 클러스터 전역 설정에 기반해 재시도를 하게 되는데 재시도는 2회, 재시도 발동 조건은 500에러나 커넥션 닫힘 등이 세팅된다.

참고로 telemetry api를 제대로 세팅하기 이전의 사진으로, 이것 때문에 조금 헤맸다.
아무리 기다리고, 재시도 횟수를 20회로 높이기까지 했는데도 에러율에 변화가 없었다.
50퍼센트 확률로 실패하는 서버에 5번의 재시도를 하게 된다면 최종 실패 확률은 1/32인데, 아무리 기다려도 그 정도의 에러율로 내려가지 않는다.
이렇게 표시되는 이유는 키알리에서 가져오는 프로메테우스 메트릭 때문이다.
기본 설정으로 이스티오는 서비스 간 트래픽에서 서버의 메트릭과 클라이언트의 메트릭을 전부 수집한다.
이것 때문에 에러로 인한 재시도를 할 때, 해당 에러까지 메트릭으로서 표시되고 이것을 키알리가 수집하기 때문에 에러율에서는 변화가 관측되지 않는 것이다.

하지만 막상 로그를 뜯어보면, 재시도 횟수가 제대로 반영이 되어 200이 잘 뜨고 있는 걸 볼 수 있다.

정말 간혹 가다 503에러가 뜨는 것을 확인할 수 있다.

트래픽 그래프에서 오른쪽에 나오는 값을 봐도 에러율이 현저하게 줄어든 것이 제대로 표시된다.

예거로 확인해봤을 때도, 에러로 표시되는 요청들 중 상당 수는 여러 재시도를 거쳐서 결국 성공한 트레이스라는 것을 확인할 수 있다.
즉, 키알리에서 그래프로 표시하는 에러율은 그저 트래픽이 전송 과정 상에서 에러가 한번이라도 발생했을 때 에러로 표시하고 있기에 변화가 없는 것처럼 보인다는 것이 확실하다.

그라파나에서 역시 설정에 맞게 정직하게 에러율을 표시해주고 있다.
일단 실제 트래픽 장애율이 줄어드는 것은 확인했으니 이스티오의 기본 실습 코드에 대한 테스트는 마치고자 한다.

결론

어플리케이션 단에서 발생하는 에러가 간헐적이라면, 위와 같이 재시도 횟수를 늘리는 것만으로 성공률을 높일 수 있다.
이밖에도 응답 지연시간에 대한 타임아웃을 세팅하여 정상 트래픽의 범주를 명확히 하는 것도 가능하다.
공식 문서에서는 에러가 많이 나는 버전에 대해 아예 트래픽 분산 비율을 줄이는 설정을 보여주기도 하는데, 어플리케이션 로직에 대한 수정을 하지 않고도 인프라 단에서 각종 에러를 대응할 수 있다는 것도 이스티오의 큰 매력 중 하나라고 생각이 든다.

에러가 나더라도 서비스 메시에 모니터링 설정을 통해 간편하게 에러를 파악할 수 있어 빠르게 확인하고 대응하기에 용이하다.

이전 글, 다음 글

• 1W - 서비스 메시와 이스티오: 1
• 1W - Gateway API를 활용한 설정: 3

다른 글 보기

관련 문서

참고