아키텍처 설계 할 때 무엇을 고려하는가

아키텍처 설계는 사실 완전 새로운 시스템을 도입하지 않는 이상, 기존 구조에 영향을 많이 받게 된다.

먼저 설계 전 구조에 영향을 받을수밖에 없는 제약사항을 검토한다.

제약사항으로 발생할 수 있는 이슈를 정리해보고 이를 고려해서 설계를 진행한다.

 

가장 중요한 건 시스템에서 가장 중요한 품질사항이 무엇이고, 이를 만족시키기 위한 설계가 진행되어야 한다는 것이다.

 

예전에 했던 프로젝트를 예로 들자면, 시스템 정의는 대충 아래와 같다.

※ 참고로, 회사 내에서 했던 내용이라 부서 간의 협의 문제도 있고 억지스럽게 구조가 잡힌 점도 좀 있다는 점을 감안 해주시길..프로젝트에 대한 내용을 설명하는게 아니고 어떤 품질로 어떤 고민을 했는지가 포커스 

 

시스템 정의

이런 프로젝트를 진행했었고 그 중 API Server를 담당했었다.

API Server는 블록체인 기반의 포인트 관리와 다른 시스템 연계가 주 목적이고 간단한 시나리오는

 

1. User는 포인트 사용처에게 주문을 하고 포인트 결제를 한다

2. POS System은 주문 내역과 결제 내역을 API Server로 보내준다

3. Blockchain 에 포인트 트랜잭션을 쌓는다. 

4. App에서 포인트를 차감한다.

3rd Party는 사내 시스템이라 정산 관련된 관리를 위해 외부 연계하는 시스템을 통틀어 퉁쳤다. 

 

 

중요한 품질?!

결제 시스템에서 성능도 물론 중요하지만, 더 중요한 품질은 신뢰성과 보안이다.

신뢰성과 보안을 만족시키기 위해 블록체인을 사용하는 이유도 있다.

 

먼저 보안을 위해서는 Blockchain 전자서명을 위한 Private Key는 보안상 API Server에서 소유하지 못한다.

(그러하다고 한다..)

일단 그래서 전자서명은 무조건 App에서만 하는 것으로 결정되었고 여기서는 신뢰성에 대해서 포커스를 맞춘다.

 

 

포인트 결제 flow

결제 flow에서 보듯이 직접 전자서명해서 포인트 관리하는 wallet에 포인트 전송을 해주는 것 외에는 모든 포인트 관리는 API Server를 통해서 하도록 되어있다. 

하지만, 여기서 결제로 인한 포인트 관리의 신뢰성은 정산이 잘되느냐도 연결이 되어있어 이를 위한 설계가 필요하다.

 

중요하게 봐야 할 내용은 주문 - 결제 - 전자서명 모든게 한 트랜잭션으로 잘 처리가 되도록 해야한다는 점이다.

 

 

설계 전 구조 상 제약 사항

• POS System은 Push를 받지 못한다.
• 전자서명 외에 포인트 관리는 API Server에서만 해야한다.

여기서 설계 상 발생할 수 있는 이슈!

주문이 일어나고 POS에서 영수증이 발행되려면 위 그림과 같이 2. 주문 결제 대기 ~ 5. 결제 완료 까지 되어야 한다.

이 작업들이 끝나기전까지 POS는 Long Polling을 하고 있어야 한다. push를 못받으니까..

그럼 결제 완료되는 시점이 언제일까? 라고 하면 4. 전자서명 이후 포인트가 차감되는 순간인데, 이걸 API Server에서는 파악하지 못한다. 

 

필요한 것은

API Server로 들어오는 요청들이 하나의 트랜잭션으로 기록해야 한다. 각 요청마다 아래의 STATUS를 주어 기록한다. 

COMPLETE 인 트랜잭션에 대해서만 정산을 할 수 있도록 프로세스를 추가하였다.

 

그리고 다는 표현하지 못하지만, 대충 아래처럼 flow 를 가지기로 함.

설계 하는 시점에서는 좀 명확해졌다. 결제 수단은 4. 태깅 을 통해 모바일 NFC 로 결제 요청을 하는 것이고 

이 때 거래 할 트랜잭션ID가 생성되는데, 나중에 블록체인에서 거래가 완료됐다는 요청이 올 때 ID로 사용한다.

 

Push 대신 Long Polling을 위해서 DeferredResult를 사용해 완료 시점에 Response 주었다.

 

각 요청들은 Thread로 처리 되므로 Shared Memory를 통해 통신할건데 

Cache 모듈을 따로 두고 Local Cache를 사용할 것이냐 Global Cache를 사용할 것이냐에 대한 고민을 한다.

1안 : Local Cache 사용

구현이 쉽고 외부 모듈에 대한 의존성이 없음. 내부에 있어 성능상으로 좀 더 빠름

2안 : Global Cache 사용

외부 모듈을 의존해야 하며 모듈간 통신에 대한 비용으로 성능이 조금 느림. 확장성이 좋음.

결국 나중에 트래픽이 많아질 경우 이중화를 위해서 Global로 Redis를 두도록 설계 하였다.

 

 

결론은?

사내 프로젝트 내용이라 모든 걸 담지 못하고, 모든 내용을 넣지 못한다. 그래서 일단 간략하게만 정리해봤다.

(더 복잡함 실제로)

 

결론은, 설계를 하기 위한 흐름이다. 중요한 품질 -> 제약사항 -> 이슈파악 -> 모든걸 고려한 설계

위 예제에서는 신뢰성에 집중하여 다뤘지만 변경용이성, 확장성, 성능 등을 고려한 설계가 필요한 부분도 분명히 있다. 

 

하고자 하는 말은, 설계에서 다루기 위한 중요한 품질이 무엇인지 파악해야 하고 이를 위한 설계를 진행해야 한다는 점!

여기서 트랜잭션을 다루는 것은 기능이 아니다. 포인트 결제라는 기능에서 신뢰성이란 품질을 만족하기 위해 부가적으로 넣은 메커니즘인 것 뿐이다. 

 

다음엔 변경이나 확장성에 대한 설계를 써봐야지