주제 - 도서관 시스템
도서관의 책 대여 및 예약, 관리 시스템입니다.
구현 Repository
총 5개 https://github.com/Juyounglee95/bookRental https://github.com/Juyounglee95/gateway https://github.com/Juyounglee95/bookManagement https://github.com/Juyounglee95/gateway https://github.com/Juyounglee95/view
서비스 시나리오
기능적 요구사항
- 관리자는 도서를 등록한다.
- 사용자는 도서를 예약한다.
- 도서를 예약 시에는 포인트를 사용한다. 3-1. 예약 취소 시에는 포인트가 반납된다.
- 사용자는 도서를 반납한다.
비기능적 요구사항
- 트랜잭션
- 결제가 되지 않은 경우 대여할 수 없다. Sync 호출
- 장애격리
- 도서관리 기능이 수행되지 않더라도 대여/예약은 365일 24시간 받을 수 있어야 한다 Async (event-driven), Eventual Consistency
- 결제시스템이 과중되면 사용자를 잠시동안 받지 않고 잠시후에 결제하도록 유도한다 Circuit breaker, fallback
- 성능
- 사용자는 전체 도서 목록을 확인하여 전체 도서의 상태를 확인할 수 있어야한다. CQRS
체크포인트
-
분석 설계
-
이벤트스토밍:
- 스티커 색상별 객체의 의미를 제대로 이해하여 헥사고날 아키텍처와의 연계 설계에 적절히 반영하고 있는가?
- 각 도메인 이벤트가 의미있는 수준으로 정의되었는가?
- 어그리게잇: Command와 Event 들을 ACID 트랜잭션 단위의 Aggregate 로 제대로 묶었는가?
- 기능적 요구사항과 비기능적 요구사항을 누락 없이 반영하였는가?
-
서브 도메인, 바운디드 컨텍스트 분리
- 팀별 KPI 와 관심사, 상이한 배포주기 등에 따른 Sub-domain 이나 Bounded Context 를 적절히 분리하였고 그 분리 기준의 합리성이 충분히 설명되는가?
- 적어도 3개 이상 서비스 분리
- 폴리글랏 설계: 각 마이크로 서비스들의 구현 목표와 기능 특성에 따른 각자의 기술 Stack 과 저장소 구조를 다양하게 채택하여 설계하였는가?
- 서비스 시나리오 중 ACID 트랜잭션이 크리티컬한 Use 케이스에 대하여 무리하게 서비스가 과다하게 조밀히 분리되지 않았는가?
- 팀별 KPI 와 관심사, 상이한 배포주기 등에 따른 Sub-domain 이나 Bounded Context 를 적절히 분리하였고 그 분리 기준의 합리성이 충분히 설명되는가?
-
컨텍스트 매핑 / 이벤트 드리븐 아키텍처
- 업무 중요성과 도메인간 서열을 구분할 수 있는가? (Core, Supporting, General Domain)
- Request-Response 방식과 이벤트 드리븐 방식을 구분하여 설계할 수 있는가?
- 장애격리: 서포팅 서비스를 제거 하여도 기존 서비스에 영향이 없도록 설계하였는가?
- 신규 서비스를 추가 하였을때 기존 서비스의 데이터베이스에 영향이 없도록 설계(열려있는 아키택처)할 수 있는가?
- 이벤트와 폴리시를 연결하기 위한 Correlation-key 연결을 제대로 설계하였는가?
-
헥사고날 아키텍처
- 설계 결과에 따른 헥사고날 아키텍처 다이어그램을 제대로 그렸는가?
-
-
구현
-
[DDD] 분석단계에서의 스티커별 색상과 헥사고날 아키텍처에 따라 구현체가 매핑되게 개발되었는가?
- Entity Pattern 과 Repository Pattern 을 적용하여 JPA 를 통하여 데이터 접근 어댑터를 개발하였는가
- [헥사고날 아키텍처] REST Inbound adaptor 이외에 gRPC 등의 Inbound Adaptor 를 추가함에 있어서 도메인 모델의 손상을 주지 않고 새로운 프로토콜에 기존 구현체를 적응시킬 수 있는가?
- 분석단계에서의 유비쿼터스 랭귀지 (업무현장에서 쓰는 용어) 를 사용하여 소스코드가 서술되었는가?
-
Request-Response 방식의 서비스 중심 아키텍처 구현
- 마이크로 서비스간 Request-Response 호출에 있어 대상 서비스를 어떠한 방식으로 찾아서 호출 하였는가? (Service Discovery, REST, FeignClient)
- 서킷브레이커를 통하여 장애를 격리시킬 수 있는가?
-
이벤트 드리븐 아키텍처의 구현
- 카프카를 이용하여 PubSub 으로 하나 이상의 서비스가 연동되었는가?
- Correlation-key: 각 이벤트 건 (메시지)가 어떠한 폴리시를 처리할때 어떤 건에 연결된 처리건인지를 구별하기 위한 Correlation-key 연결을 제대로 구현 하였는가?
- Message Consumer 마이크로서비스가 장애상황에서 수신받지 못했던 기존 이벤트들을 다시 수신받아 처리하는가?
- Scaling-out: Message Consumer 마이크로서비스의 Replica 를 추가했을때 중복없이 이벤트를 수신할 수 있는가
- CQRS: Materialized View 를 구현하여, 타 마이크로서비스의 데이터 원본에 접근없이(Composite 서비스나 조인SQL 등 없이) 도 내 서비스의 화면 구성과 잦은 조회가 가능한가?
-
폴리글랏 플로그래밍
- 각 마이크로 서비스들이 하나이상의 각자의 기술 Stack 으로 구성되었는가?
- 각 마이크로 서비스들이 각자의 저장소 구조를 자율적으로 채택하고 각자의 저장소 유형 (RDB, NoSQL, File System 등)을 선택하여 구현하였는가?
-
API 게이트웨이
- API GW를 통하여 마이크로 서비스들의 집입점을 통일할 수 있는가?
- 게이트웨이와 인증서버(OAuth), JWT 토큰 인증을 통하여 마이크로서비스들을 보호할 수 있는가?
-
-
운영
- SLA 준수
- 셀프힐링: Liveness Probe 를 통하여 어떠한 서비스의 health 상태가 지속적으로 저하됨에 따라 어떠한 임계치에서 pod 가 재생되는 것을 증명할 수 있는가?
- 서킷브레이커, 레이트리밋 등을 통한 장애격리와 성능효율을 높힐 수 있는가?
- 오토스케일러 (HPA) 를 설정하여 확장적 운영이 가능한가?
- 모니터링, 앨럿팅:
- 무정지 운영 CI/CD (10)
- Readiness Probe 의 설정과 Rolling update을 통하여 신규 버전이 완전히 서비스를 받을 수 있는 상태일때 신규버전의 서비스로 전환됨을 siege 등으로 증명
- Contract Test : 자동화된 경계 테스트를 통하여 구현 오류나 API 계약위반를 미리 차단 가능한가?
- SLA 준수
분석/설계
이벤트 도출
액터, 커맨드 부착하여 읽기 좋게
어그리게잇으로 묶기
바운디드 컨텍스트로 묶기
- 도메인 서열 분리
- Core Domain: bookRental, bookManagement : 핵심 서비스
- Supporting Domain: marketing, customer : 경쟁력을 내기위한 서비스
- General Domain: point : 결제서비스로 3rd Party 외부 서비스를 사용하는 것이 경쟁력이 높음 (핑크색으로 이후 전환할 예정)
폴리시 부착
폴리시의 이동과 컨텍스트 매핑 (점선은 Pub/Sub, 실선은 Req/Resp)
- View Model 추가
기능적/비기능적 요구사항을 커버하는지 검증
<기능적 요구사항 검증>
-관리자는 도서를 등록한다. ok -사용자는 도서를 예약한다. ok -도서를 예약 시에는 포인트를 사용한다. ok -예약 취소 시에는 포인트가 반납된다. ok -사용자는 도서를 반납한다. ok
- 사용자는 예약을 취소할 수 있다 (ok)
- 예약이 취소되면 포인트가 반납되고, 도서의 상태가 예약 취소로 변경된다 (ok)
- 사용자는 도서상태를 중간중간 조회한다 (View-green sticker 의 추가로 ok)
- 도서가 등록/예약/예약취소/반납 시, 도서의 상태가 변경되어 전체 도서 리스트에 반영된다. 사용자와 관리자 모두 이를 확인할 수 있다. ok
비기능 요구사항에 대한 검증
- 마이크로 서비스를 넘나드는 시나리오에 대한 트랜잭션 처리 - 도서 예약시 결제처리: 예약완료시 포인트 결제처리에 대해서는 Request-Response 방식 처리 - 결제 완료시 도서 상태 변경: Eventual Consistency 방식으로 트랜잭션 처리함. - 나머지 모든 inter-microservice 트랜잭션: 데이터 일관성의 시점이 크리티컬하지 않은 모든 경우가 대부분이라 판단, Eventual Consistency 를 기본으로 채택함.
헥사고날 아키텍처 다이어그램 도출 //////수정예정
- Chris Richardson, MSA Patterns 참고하여 Inbound adaptor와 Outbound adaptor를 구분함
- 호출관계에서 PubSub 과 Req/Resp 를 구분함
- 서브 도메인과 바운디드 컨텍스트의 분리: 각 팀의 KPI 별로 아래와 같이 관심 구현 스토리를 나눠가짐
구현:
분석/설계 단계에서 도출된 헥사고날 아키텍처에 따라, 각 BC별로 대변되는 마이크로 서비스들을 스프링부트로 구현함. 구현한 각 서비스를 로컬에서 실행하는 방법은 아래와 같다 (각자의 포트넘버는 8081 ~ 808n 이다) bookManagement/ bookRental/ gateway/ point/ view/
cd bookManagement
mvn spring-boot:run
cd bookRental
mvn spring-boot:run
cd gateway
mvn spring-boot:run
cd point
mvn spring-boot:run
cd view
mvn spring-boot:run
DDD 의 적용
- 각 서비스내에 도출된 핵심 Aggregate Root 객체를 Entity 로 선언. 이때 가능한 현업에서 사용하는 언어 (유비쿼터스 랭귀지)를 그대로 사용함.
package library;
import javax.persistence.*;
import org.springframework.beans.BeanUtils;
import java.util.List;
@Entity
@Table(name="PointSystem_table")
public class PointSystem {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Long id;
private Long bookId;
private Long pointQty =(long)100;
@PostPersist
public void onPostPersist(){
PointUsed pointUsed = new PointUsed(this);
BeanUtils.copyProperties(this, pointUsed);
pointUsed.publish();
}
public Long getBookId() {
return bookId;
}
public void setBookId(Long bookId) {
this.bookId = bookId;
}
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
public Long getPointQty() {
return pointQty;
}
public void setPointQty(Long pointQty) {
this.pointQty = pointQty;
}
}
- Entity Pattern 과 Repository Pattern 을 적용하여 JPA 를 통하여 다양한 데이터소스 유형 (RDB or NoSQL) 에 대한 별도의 처리가 없도록 데이터 접근 어댑터를 자동 생성하기 위하여 Spring Data REST 의 RestRepository 를 적용하였다
package library;
import org.springframework.data.repository.PagingAndSortingRepository;
public interface PointSystemRepository extends PagingAndSortingRepository<PointSystem, Long>{
}
- 적용 후 REST API 의 테스트
# bookManagement 서비스의 도서 등록처리
http POST http://52.231.116.117:8080/bookManageSystems bookName="JPA"
# bookRental 서비스의 예약처리
http POST http://52.231.116.117:8080/bookRentalSystems/returned/1
# bookRental 서비스의 반납처리
http POST http://52.231.116.117:8080/bookRentalSystems/reserve/1
# bookRental 서비스의 예약취소처리
http POST http://52.231.116.117:8080/bookRentalSystems/reserveCanceled/1
# 도서 상태 확인
http://52.231.116.117:8080/bookLists
동기식 호출 과 비동기식
분석단계에서의 조건 중 하나로 예약(bookRental)->결제(point) 간의 호출은 동기식 일관성을 유지하는 트랜잭션으로 처리하기로 하였다. 호출 프로토콜은 이미 앞서 Rest Repository 에 의해 노출되어있는 REST 서비스를 FeignClient 를 이용하여 호출하도록 한다.
- 결제서비스를 호출하기 위하여 Stub과 (FeignClient) 를 이용하여 Service 대행 인터페이스 (Proxy) 를 구현
# (app) pointSystemService.java
@FeignClient(name="point", url="http://52.231.116.117:8080")
public interface PointSystemService {
@RequestMapping(method= RequestMethod.POST, path="/pointSystems", consumes = "application/json")
public void usePoints(@RequestBody PointSystem pointSystem);
}
- 예약을 받은 직후(@PostPersist) 결제를 요청하도록 처리 -> BookRental의 생성은 BookManageSystem에서 도서를 등록한 직후 발생하기 때문에, Post요청으로 예약이 들어온 후 결제 요청하도록 처리함.
# BookRentalSystemController.java (Entity)
@PostMapping("/bookRentalSystems/reserve/{id}")
public void bookReserve(@PathVariable(value="id")Long id){
PointSystem pointSystem = new PointSystem();
pointSystem.setBookId(id);
PointSystemService pointSystemService = Application.applicationContext.
getBean(library.external.PointSystemService.class);
pointSystemService.usePoints(pointSystem);
}
}
결제가 이루어진 후에 도서대여시스템으로 이를 알려주는 행위는 동기식이 아니라 비 동기식으로 처리하여 도서대여시스템의 처리를 위하여 도서 상태 업데이트는 블로킹 되지 않도록 처리한다.
- 이를 위하여 결제이력에 기록을 남긴 후에 곧바로 결제승인이 되었다는 도메인 이벤트를 카프카로 송출한다(Publish)
#PointSystem.Java (Entity)
{
@PostPersist
public void onPostPersist(){
PointUsed pointUsed = new PointUsed(this);
BeanUtils.copyProperties(this, pointUsed);
pointUsed.publish();
}
}
결제 완료 이벤트를 도서대여시스템의 리스너가 받아, 도서의 상태를 예약완료로 변경한다.
(BookRentalSystem) PolicyHandler.JAVA
{
@StreamListener(KafkaProcessor.INPUT) //포인트 결제 완료시
public void wheneverPointUsed_ChangeStatus(@Payload PointUsed pointUsed){
try {
if (pointUsed.isMe()) {
System.out.println("##### point use completed : " + pointUsed.toJson());
BookRentalSystem bookRentalSystem = bookRentalSystemRepository.findById(pointUsed.getBookId()).get();
bookRentalSystem.setBookStatus("Reserved Complete");
bookRentalSystemRepository.save(bookRentalSystem);
}
}catch (Exception e){
e.printStackTrace();
}
}
}
도서상태가 변경되면, Reserved라는 이벤트를 발행한다.
BookRentalSystem.java (Entity)
{
@PostUpdate
public void bookStatusUpdate(){
if(this.getBookStatus().equals("Returned")){
Returned returned = new Returned(this);
BeanUtils.copyProperties(this, returned);
returned.publish();
}else if(this.getBookStatus().equals("Canceled")){
ReservationCanceled reservationCanceled = new ReservationCanceled(this);
BeanUtils.copyProperties(this, reservationCanceled);
reservationCanceled.publish();
}else if(this.getBookStatus().equals("Reserved Complete")){
Reserved reserved = new Reserved(this);
BeanUtils.copyProperties(this, reserved);
reserved.publish();
}
}
}
결과 : 포인트가 사용된 후에, 예약이 완료되는 것과 도서의 상태가 변경된 것을 확인 할 수 있다.
운영
CI/CD 설정
각 구현체들은 각자의 source repository 에 구성되었고, 사용한 CI/CD 플랫폼은 azure를 사용하였으며, pipeline build script 는 각 프로젝트 폴더 이하에 azure-pipeline.yml 에 포함되었다.
동기식 호출 / 서킷 브레이킹 / 장애격리
- 서킷 브레이킹 프레임워크의 선택: Spring FeignClient + Hystrix 옵션을 사용하여 구현함
시나리오는 단말앱(app)-->결제(pay) 시의 연결을 RESTful Request/Response 로 연동하여 구현이 되어있고, 결제 요청이 과도할 경우 CB 를 통하여 장애격리.
- Hystrix 를 설정: 요청처리 쓰레드에서 처리시간이 610 밀리가 넘어서기 시작하여 어느정도 유지되면 CB 회로가 닫히도록 (요청을 빠르게 실패처리, 차단) 설정
# application.yml
hystrix:
command:
# 전역설정
default:
execution.isolation.thread.timeoutInMilliseconds: 610
- 피호출 서비스(결제:pay) 의 임의 부하 처리 - 400 밀리에서 증감 220 밀리 정도 왔다갔다 하게
# (pay) 결제이력.java (Entity)
@PrePersist
public void onPrePersist(){ //결제이력을 저장한 후 적당한 시간 끌기
...
try {
Thread.currentThread().sleep((long) (400 + Math.random() * 220));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
- 부하테스터 siege 툴을 통한 서킷 브레이커 동작 확인:
- 동시사용자 100명
- 60초 동안 실시
$ siege -c100 -t60S -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
HTTP/1.1 201 0.73 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 0.75 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 0.77 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 0.97 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 0.81 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 0.87 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.12 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.16 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.17 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.26 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.25 secs: 207 bytes ==> POST http://localhost:8081/orders
* 요청이 과도하여 CB를 동작함 요청을 차단
HTTP/1.1 500 1.29 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 1.24 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 1.23 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 1.42 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 2.08 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.29 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 1.24 secs: 248 bytes ==> POST http://localhost:8081/orders
* 요청을 어느정도 돌려보내고나니, 기존에 밀린 일들이 처리되었고, 회로를 닫아 요청을 다시 받기 시작
HTTP/1.1 201 1.46 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.33 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.36 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.63 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.65 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.68 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.69 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.71 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.71 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.74 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.76 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 1.79 secs: 207 bytes ==> POST http://localhost:8081/orders
* 다시 요청이 쌓이기 시작하여 건당 처리시간이 610 밀리를 살짝 넘기기 시작 => 회로 열기 => 요청 실패처리
HTTP/1.1 500 1.93 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 1.92 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 1.93 secs: 248 bytes ==> POST http://localhost:8081/orders
* 생각보다 빨리 상태 호전됨 - (건당 (쓰레드당) 처리시간이 610 밀리 미만으로 회복) => 요청 수락
HTTP/1.1 201 2.24 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.32 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.16 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.19 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.19 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.19 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.21 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.29 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.30 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.38 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.59 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.61 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.62 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 2.64 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.01 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.27 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.33 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.45 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.52 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.57 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.69 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.70 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.69 secs: 207 bytes ==> POST http://localhost:8081/orders
* 이후 이러한 패턴이 계속 반복되면서 시스템은 도미노 현상이나 자원 소모의 폭주 없이 잘 운영됨
HTTP/1.1 500 4.76 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.23 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.76 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.74 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.82 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.82 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.84 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.66 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 5.03 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.22 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.19 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.18 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.69 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.65 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 5.13 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.84 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.25 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.25 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.80 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.87 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.33 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.86 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.96 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.34 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 500 4.04 secs: 248 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.50 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.95 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.54 secs: 207 bytes ==> POST http://localhost:8081/orders
HTTP/1.1 201 4.65 secs: 207 bytes ==> POST http://localhost:8081/orders
:
:
Transactions: 1025 hits
Availability: 63.55 %
Elapsed time: 59.78 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
Successful transactions: 1025
Failed transactions: 588
Longest transaction: 9.20
Shortest transaction: 0.00
-
운영시스템은 죽지 않고 지속적으로 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 가 변화없기 때문에 무정지 재배포가 성공한 것으로 확인됨.
신규 개발 조직의 추가
-
마케팅팀의 추가
- KPI: 신규 고객의 유입률 증대와 기존 고객의 충성도 향상
- 구현계획 마이크로 서비스: 기존 customer 마이크로 서비스를 인수하며, 고객에 음식 및 맛집 추천 서비스 등을 제공할 예정
-
이벤트 스토밍
추가된 조직에 따른