차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- web:신규서비스 [2022/05/24 11:10]
kwon37xi [Database / 저장소]
+++ web:신규서비스 [2022/06/07 15:05]
kwon37xi [프로젝트 구성과 Microservices Architecture]
@@ 줄 66: / 줄 66: @@
     * 프로젝트를 실서버와 개발자 PC에서 띄우는데 너무 오랜시간이 걸려(JVM 기반의 경우) 개발 생산성이 급격히 낮아지고, 수정해야 할 코드를 찾는 시간, 배포 시간 등이 지나치게 오래 걸리는 시점이 오게 된다. 이 때는 MSA로 분할하는것이 Monolithic 보다 개발 생산성이 더 높아지게 된다.
     * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다.
+===== Team 이 아닌 Project 단위 구성 =====
+  * APM, Wiki 공간, 각종 로깅 시스템 구분, Resource Tagging 등을 Team 기준으로 하지 말고 Project 기준으로 해야한다.
+  * Team 은 지속적으로 바뀌지만 Project 는 프로젝트 자체가 폐기 될 때까지 잘 바뀌지 않는다.
+  * 가급적 애플리케이션 관련 모든 정보 조직과 행위의 기준을 Project 를 단위로 가져가고 Project 에 하위 정보로 Team 을 넣는 방식을 취한다.
 ===== API Gateway =====
@@ 줄 208: / 줄 213: @@
   * 기본적으로 Slow Query 모니터링을 걸고 알람을 한다. slow query 시간에 따라 알람 레벨을 주는 것도 좋을 것 같다.
   * ''in'' 조건 등의 쿼리 생성시 항상 ''in'' 안에 들어오는 값의 갯수가 제한될 수 있도록 한다. 이는 bulk insert/update 에서도 마찬가지이다. **SQL 문자열의 길이에 제한이 있다는 사실**을 잊지말고, **SQL 길이가 무제한 커질 수 있는 쿼리가 절대 만들어질수 없게 한다.** ''in''의 경우 [[java:guava|Guava]] [[https://guava.dev/releases/21.0/api/docs/com/google/common/collect/Lists.html#partition-java.util.List-int-|Lists.partition]] 으로 나눠서 조회해서 합치는 방식등을 사용한다.
+  * **즉 모든 데이터 조회는 상방이 무제한 커질 수 없게 제한을 걸어야한다. 그래야 서비스의 증가에 따라 장애가 나는 일이 없어진다.**
 ===== 사용자에게 전달하는 메시징 솔루션 =====
   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.
@@ 줄 399: / 줄 405: @@
   * **비동기 타이밍 문제도 심각하다.** 이 경우 비동기를 사용하면 안되는데 비동기를 사용한 경우일 수 있다. A -> B로 메시지를 보냈는데 B 가 메시지를 Consuming 하기 전에 A 혹은 C 등의 다른 서비스가 B가 메시지를 받았다는 가정하에 어떤 행위를 할 경우 오류가 발생한다. 매우 빈번히 발생하는 문제이다. 비동기를 사용하면 안 되거나 B가 메시지를 받았는지 확인할 수 있는 방안을 강구해야 한다.(JMX의 경우에는 Consume 확인 기능이 존재함)
   * MQ Consumer 서버를 API 서버와 분리한다. MQ Consumer 가 DB 커넥션 쓰레드나, 애플리케이션 쓰레드를 점유해버릴 경우 API가 원인 모르게 느려지고 작동을 안하는 현상이 발생한다. 이 둘을 분리해서 장애시 원인이 MQ Consumer 인지, 특정 API 호출인지를 명확히 구분할 수 있다.
-  * Event body 에 모든 데이터를 심는 방법은 이벤트 전송 부담을 키운다. 이벤트에는 이벤트를 발생시킨 데이터의 종류(상품,사용자,..)와 해당 Primary Key, 그리고 이벤트 발생 요인(생성,수정,삭제)만 전달하고, 실제 데이터는 이벤트를 받은 시스템에서 API 등으로 호출하여 확인하게 한다. 그리고 상황에 따라 API로 봐야하는 데이터가 너무 크다면 그 중에 어떤 데이터가 변경됐는지(상품중에서 가격이 변경 됐는지 여부?)를 함께 담아 보낸다.
+  * Event body 에 모든 데이터를 심는 방법은 이벤트 전송 부담을 키운다. 이벤트에는 이벤트를 발생시킨 데이터의 종류(상품,사용자,..)와 해당 Primary Key, 그리고 이벤트 발생 요인(생성,수정,삭제)만 전달하고, 실제 데이터는 이벤트를 받은 시스템에서 API 등으로 호출하여 확인하게 한다. 그리고 상황에 따라 API로 봐야하는 데이터가 너무 크다면 그 중에 어떤 데이터가 변경됐는지(상품중에서 가격이 변경 됐는지 여부?)를 함께 담아 보낸다(zero payload).
+  * zero payload 상황에서 consumer는 producer 에게 실제 데이터를 API로 요청해야하는데, 이 때 DB replication이 돼 있을 경우 replica 에 데이터 복제 지연이 발생해서 못 읽는 경우가 있을 수 있다. MQ의 전송지연 기능으로 3~5초 정도 지연해서 메시지를 받게 해주면 이 문제가 줄어든다.
+  * zero payload가 이벤트를 받는측에서 데이터를 조회해야해서 producer 측에 DB부담을 가중시킬 가능성도 있다. 혹은 어떤 상황에서는 이벤트 발행 그 시점의 데이터가 필요할 때도 있다. 따라서 데이터를 넣어서 전송해야 할 일이 있다면 그 정책을 producer가 payload 생성으로 인해 쓰레드가 길어지거나 너무 많은 데이터 조회로  부담되지 않게 잘 정의해줘야 한다.
 ===== Single Page Application? =====
   * 2020년 현재 대부분의 Front End Framework 이 SPA 기반이다. SPA를 사용하지 말라는 것은 유효하지 않다.

권남

사용자 도구

사이트 도구

차이

문서 도구