reviews의 새 버전 추가하기

이 모듈에서는 reviews 서비스의 새 버전 _v2_를 배포하는 방법을 배워요. v2는 리뷰어가 제공한 평점(rating)의 숫자와 별 색상을 반환해요. 실제 운영 시나리오라면 배포 전에 정적 분석 테스트, 단위 테스트, 통합 테스트, 엔드투엔드 테스트, 스테이징 환경 테스트를 먼저 수행했을 거예요.

출처: Istio 문서

본문

이 모듈에서는 reviews 서비스의 새 버전인 _v2_를 배포해요. v2는 리뷰어가 제공한 평점의 숫자와 별 색상을 반환해요. 실제 상황이라면 배포 전에 정적 분석 테스트, 단위 테스트, 통합 테스트, 엔드투엔드 테스트, 스테이징 환경 테스트를 수행했을 거예요.

app=reviews 라벨 없이 reviews 마이크로서비스의 새 버전을 배포하세요. 그 라벨이 없으면 새 버전이 reviews 서비스를 제공하도록 선택되지 않아요. 따라서 프로덕션 코드가 새 버전을 호출하지 않아요. 다음 명령을 실행해서 reviews 마이크로서비스 버전 2를 배포하되, app: reviews 라벨을 app: reviews_test로 바꿔요.

$ curl -s https://raw.githubusercontent.com/istio/istio/release-1.31/samples/bookinfo/platform/kube/bookinfo.yaml | sed 's/app: reviews/app: reviews_test/' | kubectl apply -l app=reviews_test,version=v2 -f -
deployment.apps/reviews-v2 created

애플리케이션에 접속해서 배포한 마이크로서비스가 애플리케이션을 중단시키지 않았는지 확인하세요.
이전에 배포했던 테스트용 컨테이너를 이용해 클러스터 내부에서 새 버전의 마이크로서비스를 테스트하세요. 테스트 동안 새 버전이 ratings 마이크로서비스의 프로덕션 파드에 접근한다는 점에 유의하세요. 또한 새 버전이 reviews 서비스에 선택되지 않았기 때문에 pod IP를 사용해서 새 버전에 접근해야 해요.

파드의 IP를 확인하세요.

$ REVIEWS_V2_POD_IP=$(kubectl get pod -l app=reviews_test,version=v2 -o jsonpath='{.items[0].status.podIP}')
$ echo $REVIEWS_V2_POD_IP

파드에 요청을 보내서 올바른 결과를 반환하는지 확인하세요.

$ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- curl -sS "$REVIEWS_V2_POD_IP:9080/reviews/7"
{"id": "7","reviews": [{  "reviewer": "Reviewer1",  "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!", "rating": {"stars": 5, "color": "black"}},{  "reviewer": "Reviewer2",  "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare.", "rating": {"stars": 4, "color": "black"}}]}

요청을 10번 연속으로 보내서 간단한 부하 테스트(load testing)를 수행하세요.

$ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- sh -c "for i in 1 2 3 4 5 6 7 8 9 10; do curl -o /dev/null -s -w '%{http_code}\n' $REVIEWS_V2_POD_IP:9080/reviews/7; done"
200
200
...

앞선 단계들로 새 reviews 버전이 잘 작동한다는 걸 확인했고, 이제 배포할 수 있어요. 서비스의 레플리카 하나를 프로덕션에 배포하면 실제 프로덕션 트래픽이 새 서비스 버전으로 흐르기 시작해요. 현재 설정에서는 트래픽의 75%가 이전 버전(이전 버전 파드 3개)으로, 25%가 새 버전(파드 1개)으로 가요. reviews v2를 배포하려면 app=reviews 라벨로 새 버전을 다시 배포해서 reviews 서비스가 주소를 지정할 수 있게 하세요.

$ kubectl label pods -l version=v2 app=reviews --overwrite
pod "reviews-v2-79c8c8c7c5-4p4mn" labeled

이제 애플리케이션 웹페이지에 접속해서 평점에 검은 별이 나타나는 걸 확인하세요. 페이지를 여러 번 접속하면 별이 있는 페이지(대략 25%)와 별이 없는 페이지(대략 75%)가 번갈아 나오는 걸 볼 수 있어요.
실제 상황에서 새 버전에 문제가 생기면 새 버전을 빠르게 배포 해제해서 이전 버전만 사용되게 할 수 있어요.

$ kubectl delete deployment reviews-v2
$ kubectl delete pod -l app=reviews,version=v2
deployment.apps "reviews-v2" deleted
pod "reviews-v2-79c8c8c7c5-4p4mn" deleted

시스템 전체에 설정 변경이 전파될 시간을 주세요. 그런 다음 애플리케이션 웹페이지에 여러 번 접속해서 이제 검은 별이 나타나지 않는 걸 확인하세요.

새 버전을 복원하려면 다음을 실행하세요.

$ kubectl apply -l app=reviews,version=v2 -f https://raw.githubusercontent.com/istio/istio/release-1.31/samples/bookinfo/platform/kube/bookinfo.yaml
deployment.apps/reviews-v2 created

애플리케이션 웹페이지에 여러 번 접속하면 검은 별이 대략 25%의 경우에 나타나는 걸 볼 수 있어요.

다음으로 새 버전의 레플리카 수를 늘려보세요. 오류 수가 늘지 않는지 주의 깊게 확인하면서 점진적으로 늘릴 수 있어요.

$ kubectl scale deployment reviews-v2 --replicas=3
deployment.apps/reviews-v2 scaled

이제 애플리케이션 웹페이지에 여러 번 접속하면 검은 별이 대략 절반 정도의 경우에 나타나는 걸 볼 수 있어요.

이제 이전 버전을 폐기할 수 있어요.

$ kubectl delete deployment reviews-v1
deployment.apps "reviews-v1" deleted

애플리케이션 웹페이지에 접속하면 검은 별이 있는 reviews만 반환돼요.

앞선 단계들에서 reviews의 업데이트를 수행했어요. 먼저 새 버전을 배포하되 시뮬레이션된 프로덕션 트래픽은 보내지 않았어요. 테스트 트래픽으로 프로덕션 환경에서 새 버전을 테스트하고, 새 버전이 올바른 결과를 제공하는지 확인했어요. 그다음 새 버전을 릴리스하면서 프로덕션 트래픽을 점진적으로 늘렸고, 마지막으로 이전 버전을 폐기했어요.

여기서부터 다음 예제 작업들을 통해 배포 전략을 개선할 수 있어요. 먼저 새 버전을 프로덕션에서 엔드투엔드로 테스트하세요. 그러려면 요청 파라미터(예: 쿠키에 저장된 사용자 이름)를 이용해 트래픽을 새 버전으로 보낼 수 있어야 해요. 또한 프로덕션 트래픽을 새 버전에 섀도잉(shadowing)해서 새 버전이 잘못된 결과를 내거나 오류를 만드는지 확인하세요. 마지막으로 롤아웃을 더 세밀하게 제어하세요. 예를 들어 1%로 배포하고, 서비스에 성능 저하가 보이지 않는 한 매시간 1%씩 늘릴 수 있어요. Istio는 이런 작업을 간단한 방식으로 수행하도록 도와서 쿠버네티스의 가치를 높여줘요. 배포에 대한 더 자세한 정보와 모범 사례는 Deployment models를 참고하세요.

여기서부터 두 가지 선택이 있어요.

서비스 메시(service mesh)를 사용한다. 서비스 메시에서는 모든 리포팅, 라우팅, 정책, 보안 로직을 sidecar 프록시에 넣고, 이 프록시를 애플리케이션 파드에 투명하게 주입해요. 비즈니스 로직은 애플리케이션 코드에 그대로 남고, 애플리케이션 코드는 변경할 필요가 없어요.
필요한 기능을 애플리케이션 코드에 직접 구현한다. 대부분의 기능은 다양한 라이브러리에 이미 준비돼 있어요. 예를 들어 Java 프로그래밍 언어에는 Netflix의 Hystrix 라이브러리가 있어요. 하지만 그러려면 라이브러리를 사용하도록 코드를 바꿔야 해요. 추가 노력이 들고 코드가 비대해지며, 비즈니스 로직이 리포팅·라우팅·정책·네트워킹 로직과 섞일 거예요. 마이크로서비스들이 서로 다른 프로그래밍 언어를 쓰기 때문에 여러 라이브러리를 배우고, 사용하고, 업데이트해야 해요.

The Istio service mesh를 참고해서 Istio가 여기 언급된 작업들과 그 이상을 어떻게 수행하는지 알아보세요. 다음 모듈들에서는 다양한 Istio 기능을 탐구해요.

이제 productpage에 Istio 활성화하기로 넘어갈 준비가 됐어요.

더 알아보기 (Learn more)

Istio 마이크로서비스 예제 문서