사용자 도구

사이트 도구


web:신규서비스

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
다음 판 양쪽 다음 판
web:신규서비스 [2020/05/20 11:19]
kwon37xi [Batch 처리]
web:신규서비스 [2020/06/25 14:33]
kwon37xi [Database / 저장소]
줄 166: 줄 166:
     * offset/limit 방식(페이징)이 아니라 **''nextPk,limit''**을 조회 조건으로 거는 더보기 방식을 사용해야 성능저하 없이 균일한 응답성을 보장받을 수 있다.     * offset/limit 방식(페이징)이 아니라 **''nextPk,limit''**을 조회 조건으로 거는 더보기 방식을 사용해야 성능저하 없이 균일한 응답성을 보장받을 수 있다.
   * 사용자 ID 같은 경우에는 소문자로통일해서 받는것이 좋다. 대문자로 입력해도 소문자로 변환한다. 사용자는 자신이 대소문자를 어떻게 입력했는지 혼동하는 경우가 많다. 단 email 같은 외부 값을 받는 경우는 있는 그대로 넣어야 한다.   * 사용자 ID 같은 경우에는 소문자로통일해서 받는것이 좋다. 대문자로 입력해도 소문자로 변환한다. 사용자는 자신이 대소문자를 어떻게 입력했는지 혼동하는 경우가 많다. 단 email 같은 외부 값을 받는 경우는 있는 그대로 넣어야 한다.
 +  * DB Connection Pool 의 **connectionTimeout** 값(커넥션풀에서 커넥션을 가져오는데 걸리는 최대시간)을 2~3초 정도로 짧게 가져간다. 또한 JDBC 사용시, **connectionTimeout**(실제 DB에 접속하는데 걸리는 시간)도 1초 이내로 짧게 가져가야한다. 그래야 DB 서버 Fail Over 에 빠르게 반응하게 된다.
 ===== 사용자에게 전달하는 메시징 솔루션 ===== ===== 사용자에게 전달하는 메시징 솔루션 =====
   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.
줄 244: 줄 245:
   * 내부 서버간의 인증시에 IP Address 기반 인증을 하지 말고, 동적 서버 증가에 대비한 인증 수단을 마련해야 한다.    * 내부 서버간의 인증시에 IP Address 기반 인증을 하지 말고, 동적 서버 증가에 대비한 인증 수단을 마련해야 한다. 
     * AWS 같은 동적 서버 증가가 가능한 상태에서 IP 기반 인증은 서비스 확장의 유연성을 떨어뜨린다.     * AWS 같은 동적 서버 증가가 가능한 상태에서 IP 기반 인증은 서비스 확장의 유연성을 떨어뜨린다.
 +
 +===== 설정 =====
 +  * 개발팀에서 제어할 수 없는 외부 연동 정보가 있을 경우 해당 정보(특히 API 접속 주소라든가) 등은 [[https://cloud.spring.io/spring-cloud-config/reference/html/|Spring Cloud Config]] 등을 사용하여, 설정 변경을 재배포없이 즉시 적용 가능하게 하는게 좋다.
 +  * 제어 불가능한 외부 환경의 경우 어떤일이 일어날지 알 수없고, 대응이 언제 될지등도 알 수 없다(예, 갑자기 외부 시스템 운영자의 실수로 API 서버 IP 주소가 바뀌어버렸다).
 ===== 서버 모니터링 ===== ===== 서버 모니터링 =====
   * [[:monitoring|서버 모니터링 툴]]을 통해 초반부터 모니터링을 강화한다.   * [[:monitoring|서버 모니터링 툴]]을 통해 초반부터 모니터링을 강화한다.
줄 318: 줄 323:
   * DB를 읽을 때 reader/writer 를 올바로 읽는지 테스트를 잘 해야한다. batch 때문에 write node가 불필요한 부담을 동시에 받는일이 생기지 않게 한다.   * DB를 읽을 때 reader/writer 를 올바로 읽는지 테스트를 잘 해야한다. batch 때문에 write node가 불필요한 부담을 동시에 받는일이 생기지 않게 한다.
   * Batch 가 올바로 시작됐는지, 혹은 올바로 종료됐는지를 모니터링 한다. **시작** 모니터링도 매우 중요할 수 있다. 시작조차 안되면 실패 알람조차도 안오기 때문에 아예 배치가 시작 안됐음을 모르고 며칠이 지나는 경우도 생길 수 있다. [[monitoring:grafana|Grafana]] 혹은 [[logging:kibana|Kibana]] 로 관련 모니터링이 가능하다.   * Batch 가 올바로 시작됐는지, 혹은 올바로 종료됐는지를 모니터링 한다. **시작** 모니터링도 매우 중요할 수 있다. 시작조차 안되면 실패 알람조차도 안오기 때문에 아예 배치가 시작 안됐음을 모르고 며칠이 지나는 경우도 생길 수 있다. [[monitoring:grafana|Grafana]] 혹은 [[logging:kibana|Kibana]] 로 관련 모니터링이 가능하다.
 +  * 배치 실행 실간을 가정으로 만들지 말 것. 예를들어 앞선 배치가 1시간 걸릴테니 그에 관한 후속 배치는 2시간 이후 실행되게 했는데, 앞선 배치가 2시간이 넘게 걸리는 등의 현상 발생. Job 들간 의존 관계가 있을 경우 명확하게 의존 관계를 코드나 스케줄로 표현할 것.
 ===== 기타 ===== ===== 기타 =====
   * 날짜 <-> 문자열간 변환이 많이 필요한데, 처음부터 포맷을 결정하고 간다.    * 날짜 <-> 문자열간 변환이 많이 필요한데, 처음부터 포맷을 결정하고 간다. 
web/신규서비스.txt · 마지막으로 수정됨: 2024/03/08 11:26 저자 kwon37xi