1/16 개발일기(이벤트처리, annotation 동작원리)

오늘 공부는 갑자기 Event 에 꽂혀서 보고 있다. 게임 이벤트 같지만... 사실은 이벤트 드리븐 아키텍처이다. 

이벤트 드리븐 아키텍처는 왜 필요할까? 데이터 동기화가 필요한 시점이 있을것이다. 데이터 일관성을 맞춰야 할수도 있으니까? 원자성도 고려해야한다. 그럼 간단하게 생각해볼건 API Call을 이용해서 동기화 시키는건데 이건 좀 위험하다. 하나가 죽으면 이걸 참조하는 다른 서비스도 같이 죽어버릴 수 있다. 그러면 중간에 뭐 하나 두는게 가장 이상적일거 같다. kafka 같은... 

사실은... 

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

오늘은 이걸 좀 보고 리뷰를 해보고자 한다. 

kafka 구조를 보면 producer, consumer 구조라는것을 쉽게 파악할 수 있다. 구독하는 대상자는 consume 을 하게 되는데 여기서 우리가 고민해봐야할것은 공통 data format 구성방법에 대한것이다. 

zero-payload 방식을 알기전에 여기에 위 개념을 도입해보자. 

일단 가게/업주가 당연히 publisher 가 될것이다. 그리고 이벤트 수신자가 subscriber 가 될것이고 아마도 이벤트 수신받은곳은 가게 ID에 대한 응답값만 받게될것이다. 여기에서 가게 ID로 API호출하여 데이터를 한번더 호출하는 방식으로 진행된다. 

이 방식에서 장점은 Event 데이터가 재설계될 필요가 없다. 

zero-payload 는 body 가 없다는 의미인데 여기서는 고유한 값 id만 넘기게 된다. 

너무 과한 데이터가 아니라면 zero-payload 방식을 쓰지 않더라도 적절하게 API로 최소한의 데이터를 응답해서 내릴 수 있을것이다. 

이 Zero-PayLoad의 가장 큰 문제는

가게/업주가 장애가 나면 결과적으로 API Call을 다시 때릴 수 없으니 가게 노출 서비스도 연쇄적으로 장애를 겪을 수 밖에 없다는 의미가 된다. 즉, 이벤트 발행 주체는 서비스 트래픽이 많이 몰리지 않아야 된다. 이런 구조에서는..? 

이걸 왜 보고 있느냐.. 

전시 영역에서 사용하는 디비에 전체 프로세스를 익히기 위함이다.. 

그래서 용어적인것들, 이벤트 설계등에 대해 조금 다뤄보고 있다. 

여유 시간에 잠깐 쓰다가 운동 다녀왔는데 이전에 했던것들이 백업이 안되어서 잠깐 다른 주제로 넘어왔다. 

annotation 동작 방식에 대해 이해해보자. 

우리가 스프링에서 annotation이 있을 때 실제 동작방식은 다음과 같다.

annotation이 뭔지 알아야 겠다. 실제 내부에서는 @interface 키워드를 이용해 정의된다. annotation 자체는 소스 코드 내에 메타데이터로 존재한다. 

@Target({ElementType.[적용대상]})
@Retention(RetentionPolicy.[정보유지되는 대상])
public @interface [어노테이션 이름]{    
			...
 }
 
 //target 같은 경우는 어디 메소드인지 클래스 인지 등등
 ex) method
 //retention 같은 경우는 런타임인지 컴파일 시점인지
 ex) runtime - 컴파일러에 의해 클래스 파일에 기록되고 런타임에 유지된다.

	종류	설명
1	RetentionPolicy.SOURCE	어노테이션이 소스 파일에서만 유지되며, 컴파일러에 의해 처리되고 클래스 파일에는 포함되지 않는다. 따라서 런타임 시 리플렉션을 통해 접근할 수 없다.
2	RetentionPolicy.CLASS	기본값이다. 어노테이션이 클래스 파일에 포함되지만 런타임에는 사용할 수 없다. 즉, JVM이 클래스를 로드할 때 어노테이션 정보는 무시된다.
3	RetentionPolicy.RUNTIME	어노테이션이 런타임 시에도 유지됩니다. 이는 스프링과 같은 프레임워크가 리플렉션을 통해 런타임에 어노테이션 정보를 읽고 처리할 수 있음을 의미한다.

그리고 컴파일을 하고 있다고 가정해보자. 이때 annotation processor 가 동작할 수 있다. 이 processor 가 컴파일 시점에 소스코드를 분석하게 된다. (*모든 annotation에서 annotation processor 가 사용되는것은 아니다.)

byte code를 컴파일하고 나면 .class 이 될텐데 JVM에 의해 실행된다. 스프링 프레임워크는 런타임 시점에서는 reflection을 사용해서 서 annotation이 붙은 클래스, 메소드, 필드등을 분석하게 된다. 이때 빈 생성, 의존성 주입, 트랜잭션 관리등이 스프링 컨테이너에 수행한다.  

단, RetentionPolicy.RUNTIME 이 아니라면 런타임 단계에서 reflection을 이용해 분석할 수 없다. 

마지막으로 스프링에서는 스프링 컨테이너가 실행될텐데 클래스 패스내 클래스들을 스캔하고 annotation을 분석하게 된다. 스프링 컨테이너는 빈을 등록하고 의존성을 주입하여 다른 스프링 관련 설정을 처리한다. 

어디서 ... 사진은 구해왔는데 Lombok 동작 원리이다. 참고해보면 좋을듯 하다.

https://applefarm.tistory.com/136

언뜻 보기에 Parse가 annotation processor를 계속 돌리는거 같기도 하고?