문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2020/05/20 11:19] kwon37xi [Batch 처리] |
web:신규서비스 [2020/06/25 14:33] kwon37xi [Database / 저장소] |
||
---|---|---|---|
줄 166: | 줄 166: | ||
* offset/ | * offset/ | ||
* 사용자 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:// | ||
+ | * 제어 불가능한 외부 환경의 경우 어떤일이 일어날지 알 수없고, 대응이 언제 될지등도 알 수 없다(예, 갑자기 외부 시스템 운영자의 실수로 API 서버 IP 주소가 바뀌어버렸다). | ||
===== 서버 모니터링 ===== | ===== 서버 모니터링 ===== | ||
* [[: | * [[: | ||
줄 318: | 줄 323: | ||
* DB를 읽을 때 reader/ | * DB를 읽을 때 reader/ | ||
* Batch 가 올바로 시작됐는지, | * Batch 가 올바로 시작됐는지, | ||
+ | * 배치 실행 실간을 가정으로 만들지 말 것. 예를들어 앞선 배치가 1시간 걸릴테니 그에 관한 후속 배치는 2시간 이후 실행되게 했는데, 앞선 배치가 2시간이 넘게 걸리는 등의 현상 발생. Job 들간 의존 관계가 있을 경우 명확하게 의존 관계를 코드나 스케줄로 표현할 것. | ||
===== 기타 ===== | ===== 기타 ===== | ||
* 날짜 <-> 문자열간 변환이 많이 필요한데, | * 날짜 <-> 문자열간 변환이 많이 필요한데, |