Update README.md

2020-04-19 14:22:32 +09:00
parent 331138d709
commit b5b66cc5a7
1 changed files with 99 additions and 2 deletions
--- a/README.md
+++ b/README.md
@@ -153,7 +153,7 @@ http localhost:8080/주문s 품목=피자 수량=2 주소=서울    #성공
 ## 운영


-### 동기식 호출 / 서킷 브레이킹 / 장애격
+### 동기식 호출 / 서킷 브레이킹 / 장애격리

 * 서킷 브레이킹 프레임워크의 선택: Spring FeignClient + Hystrix 옵션을 사용하여 구현함

@@ -354,12 +354,109 @@ Longest transaction:	        9.20
 Shortest transaction:	        0.00

 ```
- 63.55% 가 성공하였고, 운영시스템은 죽지 않고 지속적으로 CB 에 의하여 적절히 회로가 열림과 닫힘이 벌어지면서 자원을 보호하고 있음을 보여줌. 물론, 46% 의 실패율은 좋지 않기 때문에 동적 Scale out (replica의 자동적 추가,HPA) 을 통하여 시스템을 확장 해주는 후속처리가 필요.
+- 운영시스템은 죽지 않고 지속적으로 CB 에 의하여 적절히 회로가 열림과 닫힘이 벌어지면서 자원을 보호하고 있음을 보여줌. 하지만, 63.55% 가 성공하였고, 46%가 실패했다는 것은 고객 사용성에 있어 좋지 않기 때문에 Retry 설정과 동적 Scale out (replica의 자동적 추가,HPA) 을 통하여 시스템을 확장 해주는 후속처리가 필요.
+
+- Retry 의 설정 (istio)
+- Availability 가 높아진 것을 확인 (siege)
+
+### 오토스케일 아웃
+앞서 CB 는 시스템을 안정되게 운영할 수 있게 해줬지만 사용자의 요청을 100% 받아들여주지 못했기 때문에 이에 대한 보완책으로 자동화된 확장 기능을 적용하고자 한다. 
+
+
+- 결제서비스에 대한 replica 를 동적으로 늘려주도록 HPA 를 설정한다. 설정은 CPU 사용량이 15프로를 넘어서면 replica 를 10개까지 늘려준다:
+```
+kubectl autoscale deploy pay --min=1 --max=10 --cpu-percent=15
+```
+- CB 에서 했던 방식대로 워크로드를 2분 동안 걸어준다.
+```
+siege -c100 -t120S -r10 --content-type "application/json" 'http://localhost:8081/orders POST {"item": "chicken"}'
+```
+- 오토스케일이 어떻게 되고 있는지 모니터링을 걸어둔다:
+```
+kubectl get deploy pay -w
+```
+- 어느정도 시간이 흐른 후 (약 30초) 스케일 아웃이 벌어지는 것을 확인할 수 있다:
+```
+NAME    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+pay     1         1         1            1           17s
+pay     1         2         1            1           45s
+pay     1         4         1            1           1m
+:
+```
+- siege 의 로그를 보아도 전체적인 성공률이 높아진 것을 확인 할 수 있다. 
+```
+Transactions:		        5078 hits
+Availability:		       92.45 %
+Elapsed time:		       120 secs
+Data transferred:	        0.34 MB
+Response time:		        5.60 secs
+Transaction rate:	       17.15 trans/sec
+Throughput:		        0.01 MB/sec
+Concurrency:		       96.02
+```
+

 ### 무정지 재배포
+
+* 먼저 무정지 재배포가 100% 되는 것인지 확인하기 위해서 Autoscaler 이나 CB 설정을 제거함
+
+- seige 로 배포작업 직전에 워크로드를 모니터링 함.
 ```
+siege -c100 -t120S -r10 --content-type "application/json" 'http://localhost:8081/orders POST {"item": "chicken"}'
+
+** SIEGE 4.0.5
+** Preparing 100 concurrent users for battle.
+The server is now under siege...
+
+HTTP/1.1 201     0.68 secs:     207 bytes ==> POST http://localhost:8081/orders
+HTTP/1.1 201     0.68 secs:     207 bytes ==> POST http://localhost:8081/orders
+HTTP/1.1 201     0.70 secs:     207 bytes ==> POST http://localhost:8081/orders
+HTTP/1.1 201     0.70 secs:     207 bytes ==> POST http://localhost:8081/orders
+:
+
 ```

+- 새버전으로의 배포 시작
+```
+kubectl set image ...
+```
+
+- seige 의 화면으로 넘어가서 Availability 가 100% 미만으로 떨어졌는지 확인
+```
+Transactions:		        3078 hits
+Availability:		       70.45 %
+Elapsed time:		       120 secs
+Data transferred:	        0.34 MB
+Response time:		        5.60 secs
+Transaction rate:	       17.15 trans/sec
+Throughput:		        0.01 MB/sec
+Concurrency:		       96.02
+
+```
+배포기간중 Availability 가 평소 100%에서 70% 대로 떨어지는 것을 확인. 원인은 쿠버네티스가 성급하게 새로 올려진 서비스를 READY 상태로 인식하여 서비스 유입을 진행한 것이기 때문. 이를 막기위해 Readiness Probe 를 설정함:
+
+```
+# deployment.yaml 의 readiness probe 의 설정:
+
+
+kubectl apply -f kubernetes/deployment.yaml
+```
+
+- 동일한 시나리오로 재배포 한 후 Availability 확인:
+```
+Transactions:		        3078 hits
+Availability:		       100 %
+Elapsed time:		       120 secs
+Data transferred:	        0.34 MB
+Response time:		        5.60 secs
+Transaction rate:	       17.15 trans/sec
+Throughput:		        0.01 MB/sec
+Concurrency:		       96.02
+
+```
+
+배포기간 동안 Availability 가 변화없기 때문에 무정지 재배포가 성공한 것으로 확인됨.
+
 ###