문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2020/06/25 14:31] kwon37xi [서버 운영] |
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,... |