web:신규서비스

차이

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

차이 보기로 링크

--- web:신규서비스 [2022/05/24 13:33]
kwon37xi [MQ 등을 통한 비동기 처리 / event driven]
+++ web:신규서비스 [2022/06/07 15:06]
kwon37xi [Team 이 아닌 Project 단위 구성]
@@ 줄 67: / 줄 67: @@
     * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다.
+===== Team 이 아닌 Project 단위 구성 =====
+  * APM, Wiki 공간, 각종 로깅 시스템 구분, Resource Tagging 등을 Team 기준으로 하지 말고 Project 기준으로 해야한다.
+  * Team 은 지속적으로 바뀌지만 Project 는 프로젝트 자체가 폐기 될 때까지 잘 바뀌지 않는다.
+  * 가급적 애플리케이션 관련 모든 정보 조직과 행위의 기준을 Project 를 단위로 가져가고 Project 에 하위 정보로 Team 을 넣는 방식을 취한다.
+  * 이렇게 하지 않고 팀을 기준으로 하면 얼마 안가 고아가 된 정보들이 양산되게 된다.
 ===== API Gateway =====
   * **내부 애플리케이션 API를 외부(브라우저, 앱)로 노출시키는 역할에 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은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.

web/신규서비스.txt · 마지막으로 수정됨: 2024/03/08 11:26 저자 kwon37xi