web:신규서비스
차이
문서의 선택한 두 판 사이의 차이를 보여줍니다.
| 양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
|
web:신규서비스 [2020/05/20 11:19] kwon37xi [Batch 처리] |
web:신규서비스 [2020/07/06 15:59] kwon37xi [API Gateway] |
||
|---|---|---|---|
| 줄 60: | 줄 60: | ||
| * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다. | * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다. | ||
| + | ===== API Gateway ===== | ||
| + | * **내부 애플리케이션 API를 외부(브라우저, | ||
| + | * 이는 치명적인 보안 위협이 된다. | ||
| + | * 특히 인증만 하고, 권한 검사를 제대로 안하고 노출시키는 일이 빈번해서, | ||
| + | * Netflix 의 [[java: | ||
| + | * 즉, 외부 노출용 API는 그 안에서 사용자를 인증하고, | ||
| + | * 이게 싫다고 **내부용 API 에 권한 로직을 넣는 것도 하지 말라.** | ||
| + | * 권한은 **외부 노출**시에 작동하는 것이다. 외부 노출은 보통 " | ||
| + | * 이러한 권한을 내부 MSA 서비스 API에 전가하기 시작하면 **MSA 서비스 갯수 * 권한 갯수**의 권한 체크 로직이 분포하게 된다. | ||
| + | * 게다가 그 와중에 또다른 권한 군이 들어오게 되면 모든 MSA 서비스가 그것들을 모두 신경써가면서 개발해야하게 되어 개발 속도를 떨어뜨리고 보안 위협이 시작되게 된다. | ||
| + | * **외부 노출 API가 인증과 권한을 전담해야 한다.** | ||
| ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 ===== | ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 ===== | ||
| * 각각의 모듈간의 호출은 '' | * 각각의 모듈간의 호출은 '' | ||
| 줄 166: | 줄 177: | ||
| * 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은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | ||
| 줄 236: | 줄 248: | ||
| * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다. | * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다. | ||
| * 전체 공용 계정을 만들게 되면 해당 권한이 있는 디렉토리가 난장판이 되고 누가 무슨 일을 했는지도 구분하기 힘들다. | * 전체 공용 계정을 만들게 되면 해당 권한이 있는 디렉토리가 난장판이 되고 누가 무슨 일을 했는지도 구분하기 힘들다. | ||
| - | * 서버 이름에 대한 공통 규칙을 미리 만들어놔야 한다. | + | * 서버 이름에 대한 공통 규칙을 미리 만들어놔야 한다. |
| * 프로젝트 이름 | * 프로젝트 이름 | ||
| * 서버 번호는 2~3자리로 구성 : 예) xxx-01 ~ xxx-20, 혹은 xxx-001,... | * 서버 번호는 2~3자리로 구성 : 예) xxx-01 ~ xxx-20, 혹은 xxx-001,... | ||
| 줄 244: | 줄 256: | ||
| * 내부 서버간의 인증시에 IP Address 기반 인증을 하지 말고, 동적 서버 증가에 대비한 인증 수단을 마련해야 한다. | * 내부 서버간의 인증시에 IP Address 기반 인증을 하지 말고, 동적 서버 증가에 대비한 인증 수단을 마련해야 한다. | ||
| * AWS 같은 동적 서버 증가가 가능한 상태에서 IP 기반 인증은 서비스 확장의 유연성을 떨어뜨린다. | * AWS 같은 동적 서버 증가가 가능한 상태에서 IP 기반 인증은 서비스 확장의 유연성을 떨어뜨린다. | ||
| + | |||
| + | ===== 설정 ===== | ||
| + | * 개발팀에서 제어할 수 없는 외부 연동 정보가 있을 경우 해당 정보(특히 API 접속 주소라든가) 등은 [[https:// | ||
| + | * 제어 불가능한 외부 환경의 경우 어떤일이 일어날지 알 수없고, 대응이 언제 될지등도 알 수 없다(예, 갑자기 외부 시스템 운영자의 실수로 API 서버 IP 주소가 바뀌어버렸다). | ||
| ===== 서버 모니터링 ===== | ===== 서버 모니터링 ===== | ||
| * [[: | * [[: | ||
| 줄 318: | 줄 334: | ||
| * DB를 읽을 때 reader/ | * DB를 읽을 때 reader/ | ||
| * Batch 가 올바로 시작됐는지, | * Batch 가 올바로 시작됐는지, | ||
| + | * 배치 실행 실간을 가정으로 만들지 말 것. 예를들어 앞선 배치가 1시간 걸릴테니 그에 관한 후속 배치는 2시간 이후 실행되게 했는데, 앞선 배치가 2시간이 넘게 걸리는 등의 현상 발생. Job 들간 의존 관계가 있을 경우 명확하게 의존 관계를 코드나 스케줄로 표현할 것. | ||
| ===== 기타 ===== | ===== 기타 ===== | ||
| * 날짜 <-> 문자열간 변환이 많이 필요한데, | * 날짜 <-> 문자열간 변환이 많이 필요한데, | ||
web/신규서비스.txt · 마지막으로 수정됨: 2024/03/08 11:26 저자 kwon37xi
별도로 명시하지 않을 경우, 이 위키의 내용은 다음 라이선스에 따라 사용할 수 있습니다: CC Attribution-Share Alike 4.0 International
