기억 파편

내가 맡고 있는 프로젝트 중 지금은 보기 힘든 프래임워크를 사용하는 것이 있는데, 구조가 낯설기에 매번 어려움을 느낀다.

(20년은 된 소스인데 지금까지 잘 돌아가는거 보면 잘 짜져있음은 분명하다ㅋㅋ)

오늘은 해당 프로젝트를 오랜만에 보면서 MVC framework 중 webwork에 대해 기술한다.

• 환경: webwork-2.2.7 / xwork-1.1.1(or 1.2.3? 1.2.4? 관련 jar의 버전이 다 달라 혼동스럽다)

struts / webwork / xwork 이것들의 차이는 무엇인가..

팀장님이 처음에 나에게 설명해주실 때 이 소스를 두고 struts를 사용했다고 하셨는데, 직접적인 struts*.jar이 임포트 되어 있진 않다. webwork를 기반으로 하고 있으며 그냥 구조가 struts와 유사하여 그렇게 부른 것 같다..

그래서 더 혼동스러웠다.

요즘에는 잘 사용하지 않는 framework여서인지 정확한 정보는 현재로서 찾기는 힘드나 여러 글들을 종합한 바 아래와 같다.

• 우선 webwork와 xwork는 만든 회사가 같다(opensymphony; 지금 찾아보니 인수되었거나 망한 듯.. 홈피가 안나온다).
• webwork은 커맨드 패턴에 기반하여 설계되었고, xwork의 wrapper다. 그래서인지 webwork으로 통합되었다는 말도 많고 webwork와 xwork 를 같게 보는 글이 많다. 하지만 계속 헷갈리는 건 소스안의 파일에 두 이름이 혼용되어 사용되고 있기 때문이다.

And webwork is just a wrapper for xwork into servlet environment.

WebWork is designed around the principle of the command pattern. In fact, it is really a wrapper XWork - a generic command-pattern framework.

• struts는 webwork을 기반을 만들어진 프래임워크다. 초기의 struts framework 는 webwork framework 와 같다고 여겨진다.

관련파일

web.xml : 필터 매핑, 서블랫 매핑

xwork.xml : 각 화면별 인터셉터 정의, url에 맞는 액션 클래스 매핑, execute()함수 결과값에 따른 화면 정의

webwork.properties : 확장자 정의, method지정 변수 설정, 인코딩, i18n 등 프래임워크 안의 세팅 값

보통 디버그할 때 xwork.xml을 열어서 url 매핑을 확인하고 액션.java 나 연관된 화면(.jsp)을 열어서 분석한다.

보던 소스가 인터셉터 덩어리라(한 화면에 기본30개) 액션에 대한 로그를 확인하기가 어려운 문제가 있다. 근데 로그를 잘 보니 인터셉터가 여러번 불리는 것 같은데(정확히는 인터셉터 -> 액션 -> 인터셉터) 이해가 잘 안간다.

자세히 설명하자면...

모니터링 - before interceptor > 점검 interceptor > 유저 interceptor > action > 유저 - PreResultListener interceptor > 모니터링 - after interceptor > 모니터링 - before interceptor > 점검 interceptor > 유저 interceptor > 유저 - PreResultListener interceptor > 모니터링 - after interceptor

위처럼 인터셉터만 두번 돌았다.. 소스만 봤을 때에는 위 회색 부분은 안 돌았어야 하는데 말이다.

혹시 다른 요청이 또 들어오나 싶어 네트워크 창을 같이 봤는데, 딱히 다른 액션 요청은 없고, 액션 요청 후 리소스를 불러오는 부분 뿐이었다.

디버그 걸린상태에서 관찰한 결과 첫번째 루프(정상이라고 생각한)에서 액션이 바로 200 응답을 받고(qna.nhn; 사진의 보라색 동그라미시점) 두번째 루프(회색)가 시작할 때 보니 .css, .js 등 모든 리소스파일이 pending 이었다. 두번째 루프의 디버그를 풀어갈 때 쯤 점차적으로 불러져왔다.

지금 추측은 리소스 파일을 불러오려는 시점에 내부 콜?이 더 있지 않을까 싶은데, 딱히 잡히는건 없다.. ㅠㅠ

참고: 커맨드 패턴

https://huisam.tistory.com/entry/CommandPattern

webwork

https://blog.naver.com/tyboss/70047272213

webwork properties 항목

https://babtingdev.tistory.com/66

axon을 공부하다 보면 DDD패턴과 aggregate이라는 개념이 계속 나온다. 간단하게 이해해보자.

DDD(Domain Driven Design)란?

• 도메인 중심으로 설계하는 디자인 방법론
• 특히 여기서는 비즈니스 Domain별로 나누어 설계하는 것에 가까움(개발 중심이 아닌, 타 부서와의 communication을 위해)
• DDD의 핵심 목표는 "Loosly coupling", "High cohesion"(어플리케이션 또는 그 안의 모듈 간의 의존성은 최소화하고, 응집성은 최대화)

Domain이란?

• 사전적 의미는 영역 / 집합
• DDD에서의 Domain은 비즈니스 Domain으로, 유사한 업무의 집합으로 이해할 수 있음
• 어플리케이션은 비즈니스 Domain별로 나누어 설계 및 개발될 수 있음
• 예) 어떤 서비스에서 회원가입, 회원탈퇴를 하는 작업은 모두 '회원'과 관련된 작업이다. 여기서 회원이 도메인이다.

Aggregate 란?

• Aggregate는 서로 관련이 있는 도메인 모델들의 집합
• 대부분의 경우 하나의 애그리거트는 하나의 엔티티와 여러 개의 밸류로 구성된다. 드물게 하나의 애그리거트에 여러 개의 엔티티가 존재하기도 한다.
• Agreegate의 키 값을 가진 엔티티를 Agreegate Root이라고 하며 다른 연관된 엔티티의 키를 들고 있다.
• Aggregate 패턴의 특징
  • Aggregate 는 내부의 도메인 객체들을 완전히 독점 소유한다. 객체들은 오직 하나의 Aggregate 에만 속하게 되고 객체들의 lifetime 은 속해있는 Aggregate의 lifetime에 제한된다(Aggregate 가 삭제되면 내부의 객체들도 같이 삭제됨).
  • Aggregate는 항상 내부 객체들의 불변성을 강제해야 한다. Aggregate 내부는 항상 비즈니스 룰에 부합하는 상태를 유지해야 한다.
  • Aggregate 각각이 transaction boundary 가 된다. 즉 하나의 트랜잭션에서는 하나의 Aggregate 만 변경할 수 있다. 여러 개의 Aggregate 들을 한 트랜잭션으로 변경하는 것은 불가능하다.

MSA에서 서비스와 DDD에서 Aggregate의 차이점

1. 서비스 (MSA)
   • MSA 서비스는 비즈니스 기능을 캡슐화한 독립적인 배포 단위입니다. 각 서비스는 자신만의 데이터베이스를 가지고 있으며, 다른 서비스와 통신할 때는 API, 메시지 큐, 또는 이벤트 버스 등을 사용합니다.
   • MSA의 서비스는 특정 비즈니스 도메인을 구현하는 것이 목표입니다. 예를 들어, 주문 서비스, 결제 서비스, 배송 서비스처럼 각 서비스는 독립적으로 개발되고 배포됩니다.
2. 애그리게잇 (DDD)
   • **애그리게잇(Aggregate)**은 하나의 도메인 모델 내에서 일관성을 유지하기 위한 경계입니다. 애그리게잇은 도메인 모델의 일부로 여러 엔티티와 값 객체(Value Object)를 묶어놓은 것으로, 그 내부에서 비즈니스 규칙을 강제합니다. 한 트랜잭션 내에서 일관성을 유지하는 것이 목적입니다.
   • 애그리게잇은 하나의 서비스 내에서도 여러 개가 존재할 수 있습니다. 예를 들어, 주문 서비스 안에 Order 애그리게잇, OrderItem 애그리게잇이 있을 수 있습니다.

서비스가 애그리게잇과 다른 이유

• 경계의 범위: MSA 서비스는 독립적인 배포 및 실행 단위를 의미하며, 도메인 모델 내의 애그리게잇보다 더 큰 경계를 가지고 있습니다. 반면, 애그리게잇은 하나의 서비스 내에서 일관성을 유지하기 위한 내부 경계입니다.
• 트랜잭션 관리: 애그리게잇은 하나의 트랜잭션 내에서 일관성을 유지하기 위해 설계된 반면, 서비스는 서로 다른 트랜잭션을 가지고 상호작용할 수 있습니다. 예를 들어, 주문 서비스와 결제 서비스는 서로 다른 트랜잭션을 사용하지만, 각 서비스 내의 애그리게잇은 그 안에서 트랜잭션을 공유합니다.
• 서비스 간 통신: MSA에서는 서비스 간 통신을 위해 API 호출이나 메시징 시스템을 사용하지만, 애그리게잇은 동일한 도메인 모델 내에서 직접 참조됩니다.

언제 서비스가 애그리게잇처럼 보일 수 있는가?

특정 상황에서는 MSA 서비스가 하나의 애그리게잇과 비슷하게 보일 수 있습니다. 특히, 서비스가 아주 작고, 하나의 도메인 모델에 집중하여 트랜잭션 경계를 관리하는 경우라면, 그 서비스가 그 도메인의 애그리게잇처럼 느껴질 수 있습니다. 예를 들어, 주문 서비스가 "주문"이라는 단일 애그리게잇을 중심으로 동작하고, 그 내부에서 일관성 있는 트랜잭션 처리를 한다면, 서비스와 애그리게잇의 경계가 겹칠 수 있습니다.

하지만 일반적으로, MSA에서의 서비스는 여러 애그리게잇을 포함할 수 있으며, 그 자체로 Aggregate의 개념을 대체하는 것은 아닙니다.

참고

https://sgc109.github.io/2020/08/09/ddd-aggregate/

https://khalilstemmler.com/articles/typescript-domain-driven-design/aggregate-design-persistence/

https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model

https://www.secmem.org/blog/2020/02/19/ddd-aggregate-pattern/

이전 글: 2022.01.11 - [architecture/MSA] - [arch] what is cqrs - 조회와 비조회의 엄연한 분리

이전 글에서 cqrs에 대해 생각해보았는데, 이를 구현하는 방법을 보던 중 Axon framework라는 것을 알게 되었다.

Based on architectural principles, such as Domain-Driven Design (DDD) and Command-Query Responsibility Separation (CQRS), Axon Framework provides the building blocks that CQRS requires and helps to create scalable and extensible applications while maintaining application consistency in distributed systems. 

사실 cqrs나 event driven developlment을 검색했을 때 주로 나오는 기술이 Kafka나 rabbitMQ였고 이전 회사에서도 Kafka를 도입하려고 했었던지라 비동기 메세징에 대해서는 Kafka가 제일 먼저 떠오른게 사실이다.

그만큼 요즘, 딱 지금 이 시기에는 Kafka가 대세아닌 대세를 누리는 것 같은데 그 틈으로 보이는 Axon이 흥미로워 보였고, 차이점이 있지 않을까 싶었다.

거창한 설명과 비교는 인터넷에 널린 자료를 참고하면 되겠고, 내가 생각하는 큰 차이점은 아래와 같다.

• Axon은 개발할 때부터, 즉 뼈속부터 cqrs를 지키며 개발할 수 있게 해주는 framework라면
• Kafka는 이미 있는 그들의 플랫폼에, 그들이 제공하는 api를 이용해서 event를 publish / handling 할 수 있는데 message streaming 위주의 기능을 한다는 것.

(직접 사용해보지 않아서 아닐수도 있음에 주의 ㅋㅋ)

이 글은 Kafka보다는 Axon에 대해 알고 싶은 글이므로 Axon에 대해 더 찾아본다.

Axon Framework란 EventSourcing, CQRS, DDD(Domain Driven Design) 세 가지 Concept을 중심으로 어플리케이션을 개발할 수 있게 도와주는 프레임워크이다. 

Axon Server는 그러한 프레임워크를 작동하게 하는 서버이며 메세지 라우팅, 이벤트 저장소 등의 역할을 수행한다.

Axon Server는 다음과 같은 특징을 갖는다.

• Event Store(이벤트 저장, 이벤트 전파, 스냅샷 저장 등)에 특화
  • AxonServer 내부에는 Event 저장을 위한 별도 DB가 없으며, File을 직접 다룸
  • EventStore는 오직 데이터 추가만이 가능하기에 수정, 삭제와 관련된 그 어떠한 API도 제공되지 않음
• 높은 가용성
• 클러스터 모드를 지원함
• 핸들러가 먹통이 되었더라도 큐에 메세지를 저장
• 서비스간 통신은 gRPC 방식을 사용

참고로 Axon Framework + Axon Server 조합이 필수는 아니다.

Axon Server대신 Kafka + NoSQL 등을 조합하여 사용할 수도 있다(Axon framework가 제공하는 Kafka-connector를 사용하여 kafka와 연동가능하다).

개념은 이정도로 살펴보고(사실 봐도 와닿지 않는다.. 따라서 개발하면서 더 찾아보고) 몸빵하면서 익혀야겠다.

springboot2, gradle multi project 등 이미 나에게 익숙한 환경에서 axon dependency 를 활용한 샘플 프로젝트 클론코딩을 진행하려고 한다.

클론코딩 참고 블로그: https://cla9.tistory.com/2?category=814447 

axon guide: https://docs.axoniq.io/reference-guide/

axon vs kafka in axon's point of view: https://axoniq.io/blog-overview/axon-and-kafka-how-does-axon-compare-to-apache-kafka

아키텍트의 역할 / 능력이란?

1. 아키텍처 결정

• 기술을 선택해주진 않지만 선택하는데 가이드를 준다(비동기를 써, 그게 카프카인지 래빗인지는 니네가 결정해)
• 하지만 필요 시 기술 지정 할수도..

2. 지속적으로 아키텍처 분석

• 최근 동향 확인, 비즈니스의 흐름에 따른 개선 제안

3. 최신 트랜드 유지

• 롱텀으로 생각, 미래를 대비

4. 결정 사항 준수 확인

• 설계 원칙을 따르는지 지속적으로 검증
• 기대한대로 작동하는지 확인

5. 다양한 경험 필요

• 다양한 기술 프래임워크 플랫폼 환경에 대한 경험
• 다양한 기술에 친숙해야 함
• 기술의 깊이보다는 폭에 집중

6. 업계/도매인의 지식 필요

• 기술 뿐 아니라 비즈니스적 요소도 이해해야 함
• 비즈니스 요구를 만족하는 설계 필요
• 고객/이해당사자 등과 소통 필요

7. 대인 관계 / communication

• 어떠한 일이건 사람의 문제
• 리더쉽, 팀웍, 동기유발

8. 회사 내부 상황 파악 / 정치

• 아키텍트의 결정은 도전을 받음
• 결정에 따라 비용, 시간, 인력 등에 영향
• 협상능력 필요

지금은 개발자이지만, 궁극적으로는 기술 pm이나 팀/그룹 리더, 나아가서는 아키텍트가 되고 싶은 마음에 찾아본 내용
개인적인 취향도 깊이보다 폭, 기술보다는 사람이라 생각하여 나와 맞을 수 있을거라 생각하면서도.. 설득, 협상능력 이런건 자신이 없기에 아직은 막연하다. 뭐 우선 관련 기회가 주어져야겠지..

The Fundamentals of Software Architecture

CQRS는 Command and Query Responsibility Segregation(명령과 조회의 책임 분리)의 약자이다. 

**명령(Command)**와 **조회(Query)**의 책임을 분리하여 시스템의 확장성과 유지보수성을 높이는 데 목적이 있으며..

쉽게 말해서 data에 대한 read와 write는 분리되어 개발되어야 한다는 것이다.

eventually consistent!

1. Before

설명을 하기 전에 그림을 먼저보자. 먼저 아래는 일반적인 우리의 서버 구조이다.

api 만 다를 뿐 결국 같은 서비스 안에서 같은 디비를 바라보고 있다. 백 만 건의 조회가 생겨 디비 행이 걸리면 업데이트에도 지연이 있을 수 있고 반대로 몇 천 건을 수정할 경우 디비 락이 걸려 조회가 안될 수도 있다. 이를 개발하는 소스 안에서도 게으른 개발자는 등록과 조회가 같은 dto를 사용할 수도 있고 한 dto 안에서 등록용 함수, 조회용 함수 등이 덕지덕지 섞여 어느샌가 리팩토링 조차 힘든 상황이 올 수도 있다.

2. Initial CQRS

그렇다면 CQRS는 어떤 개념인가. 아래 그림을 보자.

CQRS를 처음 제시한 사람은 CQRS에 대해 아주 단순하게 말했다.

It has one simple assumption: instead of having one big model for reads and writes, you should have two separate models. One for writes and one for reads.

단순하게 말하면 등록/조회 같은 dto 쓰지마라..ㅋ (사실 더 나아가선 application도 분리해야한다; 녹색이 어플리케이션, 노란색이 dto라고 보면 된다)

그리고 두 가지 개념을 들고온다: query와 command

Query should not modify anything, just return the data.
Command is the opposite one: it should make changes in the system, but not return any data.

나는 query는 조회용, command는 업데이트(수정,등록 등)용이라고 이해했다(다른 원문에서는 read와 update 라고 분리하기도하는데 공통된 의미라고 생각한다).

위 그림에서도 내부적인(service; dto, 함수 등) 분리는 된 듯 한데, DB의 분리는 아직이다. 사실 이 정도만 분리해도 괜찮다(현실적이다)는 평도 있다.

3. Ultimate CQRS

하지만 모든 원론이 그러하듯 궁극적인  CQRS는 한 단계 더 진화한다. 필자도 경험해봤지만 결국 대용량 서비스는 조회의 싸움이다.

특히 MSA 구조에서 데이터 조회란, 수 많은 테이블의 join의 결과체이며 이로인해 DB cpu가 100을 찍는 경우도 허다하다.

궁극적인 CQRS는 아래와 같이 제안한다.

차이점은 read, write의 완전한 분리 그리고 event sourcing

여기서 핵심 내용은 write 와 read 할 때 사용되는 db(물리적인 db, in-memory db 등 데이터를 저장하는 모든 것을 일컬음)는 communicate이 불가하고 오로지 event를 통해서만 communicate 할 수 있다는 점이다.

위 플로우를 write -> event storage(업데이트 로그) -> events -> event handler -> write 라고 설명하는 사람도 있는데, 이 때 event storage가 전체 플로우 중 transactional 이 가능한 유일한 아이라고 설명하는 사람도 있다(write할 때도 event storage에 event생성만 하고 끝이니 딱히 transacitonal할 필요 없음). 적당히 이해하고 보면 될 듯 하다.

정리하면 아래와 같다.

위 처럼 분리되었을 경우의 아래와 같은 장점을 얻을 수 있게 된다.

• 각각의 상황에 맞게 optimize가 가능(ex. read - view with cache)
• read와 write가 서로 독립적(즉 서로 영향을 미치지 않는다; 조회하다 부하가 걸려 업데이트가 안 될 일이 없다).
• 독립적인 scaling(조회가 많으면 조회 쪽 성능에 대한 개선만 하면 됨/ 관련 인프라의 scale out)이 가능

이를 공부하면서 의문이 생기는 것은 배달 주문 메뉴 수정/실시간 잔액 조회와 같이 실시간 반영이 필요할 때 event driven의 경우 아무래도 write -> read로 가는 약간의 지연이 있을 것 같은데 이는 어떻게 해결할 수 있는지, 무시할만한 수준인건지 궁금하다..(왠지 진짜 실시간은 write 테이블을 보고 약간의 지연을 허용하면 read 테이블을 보고 그런식으로 할 것 같다..는 과거의 나ㅋㅋ)

+ 후에 실습을 해보니 write -> read 로 이벤트 전파가 거의 동시에 이루어지는 것을 확인할 수 있었다. 다만 실 운영 환경에서는 트래픽이나 시스템의 환경에 따라 약간씩 다르지 않을까 생각된다.

참고

https://threedots.tech/post/basic-cqrs-in-go/

https://www.youtube.com/watch?v=qJA6MaQ90YY