[하이퍼레저 패브릭] HR프로젝트 1차 완료 후

초반에 IBM Cloud 계정가입에 문제가 생겨서 차질이 있었지만, 한달동안 하이퍼레저 프로젝트를 잘(?) 완료 하였다. 해당 프로젝트는 웹서비스단(React,Express,Mongo)와 블록체인단(Composer Rest Server, IBM Blockchain) 으로 이루어졌는데, 중간에서 Mongodb가 캐싱역할을 하며, 웹서비스단에서 블록체인에 대한 호출 즉 Composr API 호출을 위임하고 있는 형태. 따라서 Composer Rest 서버를 멀티유저(혹은 싱글서버를 카드별로 여러개) 가 아닌 단일유저가 사용하므로 신뢰의 분산에는 적합치 않은 모습..차후에 이걸 어떻게 분산시킬지.. 분산을 꼭 시켜야할지에 대한 고민과 동시에 하이퍼레저를 다루는 방식이 굉장히 다양할수 있으며, 버전에 따라서 예전 문서가 잘 적용이 안되는 경우도 많아서 나름 고전했던거 같다. 마지막으로 IBM의 구성원들이 얼마나 노력을 많이 하고 있는지에 대해 정말 많이 느꼈다. 그들이 만들어 나가는 기술블로그들은 정말 대단~이번에 레드햇도 인수했던데, 상위권으로 도약하길 바란다. 

p,s

프로젝트하면서 느낀게 중간에 미들웨어에서 다른 트랜잭션이 Composer 트랜잭션과 동시에 일어나는데, 이런 경우 어떻게 완결성을 맺을까 하는 점이었다. 돈이 오고가는 프로젝트가 아니라서 대충 얼버무렸지만.. 장부에는 letter of credit 이 완결되어 Close 시켰다고 트랜잭션이 일어났는데, 은행 트랜잭션에서 송금이 실패했다면?? 외부 트랜잭션과 All or Nothing 전략은 어떤식으로 할 수 있을까?? 생각해볼게 많은거 같다. hyperledger fabric에 rollback 기능이 없고.... 실제 사례에 대한 아티클을 찾아보아야겠다. (요즘 유행하는 마이크로 서비스 패턴들을 잘 버무려야함. SAGA패턴 같은) 

아래는 그러한 트랜잭션에서 고려할만한 전략을 정리한 글이다.

1) 취소 전략: 비즈니스 트랜잭션의 오류 해결책으로 가장 간단한 전략이다. 즉 지금까지 진행된 개별 트랜잭션들을 모두 취소시킨다. 어떻게 보면 이 전략은 2단계 커밋의 롤백 전략과 유사하다. 그리고 별로 좋은 전략 같아 보이지도 않는다. 그러나 현실 세계에서는 그런대로 쓸만하다. 취소함으로 발생하는 손실이 거래를 복구함으로 얻는 이익보다 큰 경우 특히 유효하다. 애플리케이션 개발 시 실행(삽입, 갱신) 기능과 취소(삭제, 갱신)기능을 함께 고려하고, 트랜잭션 조정자는 오류를 감지한 후 각 참여 자원의 취소 기능을 요청한다. 2단계 커밋의 롤백과 다른 점은 하나 이상의 요청이 트랜잭션 중간에 개입될 수 있고 긴 시간의 트랜잭션에서 발생한 오류를 해결하는 전략으로, 이런 문제는 2단계 커밋의 롤백으로는 해결되지 않는다.

2) 재시도 전략: 재시도를 통해 비즈니스 트랜잭션이 성공할 수 있는 업무인 경우 다시 동일한 비즈니스 기능을 시작한다. 예를 들어 외부 자원이 일시적으로 중지된 경우 재시도를 통해 극복될 수 있다. 업무 규칙을 위반한 비즈니스 기능의 요청인 경우 이 전략을 사용하면 안된다. 참여 시스템이 멱등 수신자(Idempotent Receiver)[EIP]가 된다면, 이 전략은 좀더 효과를 발휘한다. 멱등 수신자란 동일한 요구에 대해 수신자의 상태가 변하지 않는 수신자를 말한다. 즉 재시도 전략을 비즈니스 트랜잭션 오류의 전략으로 선택한 경우 각 참여 자원을 멱등 수신자로 만들어야 한다. 멱등 수신자 패턴에 대한 자세한 설명은 [EIP]나 [SDP]를 참조한다. 재시도에는 재시도 횟수를 지정할 수 있다. 재시도 횟수를 넘어선 오류인 경우 다른 해결 전략으로 오류 해결 방법을 변경해야 한다.

3) 보상 전략: 이미 처리된 비즈니스 오류를 별도의 비즈니스 기능으로 보상하는 전략이다. 예를 들어 은행이 고객의 이체 처리 중 출금은 성공했으나 입금에 실패한 경우 출금 액만큼 은행이 고객에게 입금해주는 전략이다. 이를 위해서는 트랜잭션 오류 상태를 해결 상태로 전이할 수 있는 기능(메소드)을 참여 애플리케이션에 포함해야 한다. 비즈니스 트랜잭션 오류가 발생하면 비즈니스 트랜잭션 조정자는 보상 비즈니스 기능을 참여 시스템에 요청해 비즈니스 트랜잭션의 오류 상태를 정상 상태로 전이시킨다.

인용 및 참고 링크: 

1. 분산 비즈니스 트랜잭션과 오류 해결 방법
2. 스타벅스는 2단계 커밋을 사용하지 않는다.
3. 2단계 커밋과 3단계 커밋이란?
4. 3단계 커밋이란?