사용자 도구

사이트 도구


web:신규서비스

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
다음 판 양쪽 다음 판
web:신규서비스 [2020/06/25 14:31]
kwon37xi [서버 운영]
web:신규서비스 [2020/07/06 15:59]
kwon37xi [API Gateway]
줄 60: 줄 60:
     * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다.     * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다.
  
 +===== API Gateway =====
 +  * **내부 애플리케이션 API를 외부(브라우저, 앱)로 노출시키는 역할에 API Gateway를 사용하지 말라.**
 +    * 이는 치명적인 보안 위협이 된다.
 +    * 특히 인증만 하고, 권한 검사를 제대로 안하고 노출시키는 일이 빈번해서, 인증 받은 특정 사용자가 API Gateway 로 열려있는 내부 API에서 본인이 아닌 다른 사용자의 정보를 읽을 수 있게 된다.
 +    * Netflix 의 [[java:zuul|Zuul - Edge Service]] 을 보면, 내부 API를 노출시키는 용도가 아니라, 외부 API인데, 인증 방식이 다른 것들을 API Gateway 로 구성하는 식으로 만든 것이다.
 +  * 즉, 외부 노출용 API는 그 안에서 사용자를 인증하고, 다른 API를 호출하고, 권한을 검사하는 로직을 다 직접 작성하는 것이 낫다.
 +  * 이게 싫다고 **내부용 API 에 권한 로직을 넣는 것도 하지 말라.**
 +    * 권한은 **외부 노출**시에 작동하는 것이다. 외부 노출은 보통 "일반 사용자", "내부 관리자", "외주 직원", "입점 업체 운영자" 등 그 종류가 매우 다양하다.
 +    * 이러한 권한을 내부 MSA 서비스 API에 전가하기 시작하면 **MSA 서비스 갯수 * 권한 갯수**의 권한 체크 로직이 분포하게 된다.
 +    * 게다가 그 와중에 또다른 권한 군이 들어오게 되면 모든 MSA 서비스가 그것들을 모두 신경써가면서 개발해야하게 되어 개발 속도를 떨어뜨리고 보안 위협이 시작되게 된다.
 +  * **외부 노출 API가 인증과 권한을 전담해야 한다.**
 ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 ===== ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 =====
   * 각각의 모듈간의 호출은 ''interface'' 기반으로 약한 결합도 높은 응집도를 유지해야 한다.   * 각각의 모듈간의 호출은 ''interface'' 기반으로 약한 결합도 높은 응집도를 유지해야 한다.
줄 166: 줄 177:
     * 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은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.
줄 236: 줄 248:
   * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다.   * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다.
   * 전체 공용 계정을 만들게 되면 해당 권한이 있는 디렉토리가 난장판이 되고 누가 무슨 일을 했는지도 구분하기 힘들다.   * 전체 공용 계정을 만들게 되면 해당 권한이 있는 디렉토리가 난장판이 되고 누가 무슨 일을 했는지도 구분하기 힘들다.
-  * 서버 이름에 대한 공통 규칙을 미리 만들어놔야 한다.+  * 서버 이름에 대한 공통 규칙을 미리 만들어놔야 한다. - Cloud 를 사용하지 않을 경우
     * 프로젝트 이름     * 프로젝트 이름
     * 서버 번호는 2~3자리로 구성 : 예) xxx-01 ~ xxx-20, 혹은 xxx-001,...     * 서버 번호는 2~3자리로 구성 : 예) xxx-01 ~ xxx-20, 혹은 xxx-001,...
web/신규서비스.txt · 마지막으로 수정됨: 2024/03/08 11:26 저자 kwon37xi