Post

2024-07-10-TIL

Posted
By August
7 min read

2024-07-10-TIL

Today I Learned

Solution Architect and Application Architect

When an application becomes so vast and complex that dealing with the overall technical vision and planning, and translating business needs into technical strategy becomes a full-time job, that is an application architect. Application architects also often mentor and/or lead developers, and know the code of their responsible application(s) well.

When an organization has so many applications and infrastructure inter-dependencies that it is a full-time job to ensure their alignment and strategy without being involved in the code of any of them, that is a solution architect. Solution architect can sometimes be similar to an application architect, but over a suite of especially large applications that comprise a logical solution for a business.

When an organization becomes so large that it becomes a full-time job to coordinate the high-level planning for the solution architects, and frame the terms of the business technology strategy, that role is an enterprise architect. Enterprise architects typically work at an executive level, advising the CxO office and its support functions as well as the business as a whole.

아키텍처를 바라보는 규모의 차이가 있고, 접근하는 방식의 차이도 있다. 애플리케이션 아키텍트는 코드레벨에서부터 서버 구성 단위까지의 아키텍처를 기술적으로 접근하는 포지션이고, 솔루션 아키텍트는 조직의 인프라 구성 전반에 걸쳐서 좀 더 큰 범위의 아키텍처를 설계한다.

  • https://stackoverflow.com/questions/524941/whats-the-difference-between-solutions-architect-and-applications-architect

Send Message After Commit

  1. TransactionSynchronizationManager 및 TransactionSynchronization: 트랜잭션 커밋 후 작업을 직접 등록.
  2. ApplicationEventPublisher와 @TransactionalEventListener: 이벤트 시스템을 활용하여 트랜잭션 커밋 후 작업 처리.
  3. PlatformTransactionManager: 트랜잭션을 수동으로 관리하여 커밋 후 작업 처리.
  4. TransactionTemplate: 간편하게 트랜잭션을 관리하고 커밋 후 작업 처리.
  5. Spring Retry: 재시도 로직을 활용하여 트랜잭션 커밋 후 작업 처리.
  6. Spring Batch: 배치 작업을 통해 트랜잭션 커밋 후 작업 처리.
  7. JTA (Java Transaction API): 분산 트랜잭션을 관리하고 커밋 후 작업 처리.
  8. Spring Integration: 비동기 작업을 처리하고 트랜잭션 커밋 후 작업 처리.

-> 고려할 사항

  1. 트랜잭션 경계 및 일관성 트랜잭션 경계: 이벤트는 트랜잭션 경계를 넘어 발생할 수 있습니다. 트랜잭션이 커밋되지 않으면 이벤트 리스너가 실행되지 않도록 해야 합니다. @TransactionalEventListener를 사용하면 트랜잭션의 특정 단계(예: 커밋 후)에만 이벤트를 처리할 수 있습니다. 일관성 유지: 메시지가 전송되는 시점과 데이터베이스 상태가 일치해야 합니다. 트랜잭션 커밋 후에만 메시지를 전송하도록 보장하는 것이 중요합니다.

  2. 오류 처리 및 재시도 메커니즘 오류 처리: 메시지 전송 중 오류가 발생할 수 있으므로 적절한 오류 처리 로직을 구현해야 합니다. 예를 들어, 메시지큐 서버가 다운되었을 때 재시도 로직을 설정할 수 있습니다. 재시도 메커니즘: 메시지 전송 실패 시 재시도 로직을 구현할 수 있습니다. 스프링 리트라이(Spring Retry)를 사용하여 재시도 메커니즘을 간편하게 추가할 수 있습니다.

  3. 성능 고려 사항 비동기 처리: 메시지 전송 작업이 비동기적으로 처리되도록 해야 합니다. 이는 트랜잭션 커밋 이후에 메시지 전송이 주 작업 흐름을 차단하지 않도록 보장합니다. 스케일링: 메시지 전송 작업이 많아질 경우 시스템 성능에 영향을 미칠 수 있으므로, 메시지큐 서버와의 연결 및 전송 로직이 확장 가능하도록 설계해야 합니다.

  4. 메시지 중복 처리 중복 메시지 처리: 네트워크 문제나 재시도 로직으로 인해 메시지가 중복 전송될 수 있습니다. 메시지큐 소비자 측에서 중복 메시지를 적절히 처리할 수 있도록 해야 합니다. 아이템포턴트: 메시지 소비 작업이 아이템포턴트하게 설계되어야 합니다. 즉, 동일한 메시지가 여러 번 처리되더라도 시스템 상태가 일관성을 유지해야 합니다.

  5. 로깅 및 모니터링 로깅: 메시지 전송 작업의 성공과 실패를 기록하여 문제 발생 시 원인을 추적할 수 있도록 해야 합니다. 모니터링: 메시지큐와 메시지 전송 작업을 모니터링하여 시스템 상태와 성능을 지속적으로 파악할 수 있어야 합니다.

  6. 보안 인증 및 인가: 메시지큐 서버와의 통신에서 인증 및 인가 메커니즘을 구현하여 안전한 메시지 전송을 보장해야 합니다. 데이터 보호: 전송되는 메시지의 민감한 데이터가 보호될 수 있도록 암호화 등의 보안 조치를 취해야 합니다.

@TransactionalEventListener

  • https://velog.io/@guswns3371/TransactionalEventListener-%EC%82%AC%EC%9A%A9%EC%8B%9C-%EC%A3%BC%EC%9D%98%ED%95%A0-%EA%B2%83
  • https://findstar.pe.kr/2022/09/17/points-to-consider-when-using-the-Spring-Events-feature/
  • https://stackoverflow.com/questions/37981524/spring-transactionaleventlistener-not-working-as-expected
  • https://docs.spring.io/spring-framework/docs/4.3.22.RELEASE_to_4.3.23.RELEASE/Spring%20Framework%204.3.23.RELEASE/org/springframework/transaction/event/TransactionalEventListener.html
  • https://github.com/micronaut-projects/micronaut-data/issues/2578
  • https://jun-codinghistory.tistory.com/658

Kafka Messaging Sementics (Message Delivery Guarantees)

  • https://leejaedoo.github.io/kafka-detail/
  • https://docs.confluent.io/kafka/design/delivery-semantics.html

Batch vs Scheduler

  • https://velog.io/@songmag/%EB%B0%B0%EC%B9%98-%EC%8A%A4%EC%BC%80%EC%A5%B4%EB%9F%AC-batch-scheduler

Message Queue Based Architecture

  • https://news.hada.io/topic?id=15456
  • https://news.ycombinator.com/item?id=40723302
  • https://www.reddit.com/r/csharp/comments/166zz25/what_is_message_queue_and_whats_its_use_case/
  • https://www.linkedin.com/pulse/message-queues-modern-architecture-rosalina-das/
  • https://www.quora.com/What-are-the-disadvantages-of-using-message-queues-as-compared-to-pipes-or-sockets-for-interprocess-communication
  • https://systemdesignschool.io/blog/message-queue

Graceful Shutdown

  • https://velog.io/@dongvelop/Springboot-Graceful-Shutdown
  • https://bravenamme.github.io/2020/10/06/graceful-shutdown/
  • https://medium.com/@contact.technovisionconsulting/how-to-achieve-a-graceful-shutdown-in-spring-boot-ec93d55916ed
  • https://www.techtarget.com/whatis/definition/graceful-shutdown-and-hard-shutdown
  • https://2kindsofcs.tistory.com/53
  • https://docs.spring.io/spring-boot/reference/web/graceful-shutdown.html
  • https://velog.io/@byeongju/SpringBoot%EC%9D%98-Graceful-Shutdown

Spring Batch with Airflow

  • https://dahye-jeong.gitbook.io/spring/spring/2020-03-23-batch/2021-11-24-batch-scheduler
  • https://kominjae.tistory.com/141
  • https://ngela.tistory.com/50
  • https://www.bucketplace.com/post/2021-04-13-%EB%B2%84%ED%82%B7%ED%94%8C%EB%A0%88%EC%9D%B4%EC%8A%A4-airflow-%EB%8F%84%EC%9E%85%EA%B8%B0/
  • https://stackoverflow.com/questions/77476483/use-airflow-to-schedule-spring-batch-jobs
  • https://github.com/spring-batch/springbatch-in-action
  • https://mungyu.tistory.com/18#google_vignette
  • https://medium.com/harinathselvaraj/batch-job-scheduling-using-apache-airflow-in-docker-container-in-aws-599a2590b605
TIL, 2024-TIL
TIL
This post is licensed under CC BY 4.0 by the author.