문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2018/11/06 08:46] kwon37xi [API 설계] |
web:신규서비스 [2019/05/03 16:45] kwon37xi [API 설계] |
||
---|---|---|---|
줄 160: | 줄 160: | ||
* 필요한 쿼리는 항상 상황별로 다 따로 만든다. | * 필요한 쿼리는 항상 상황별로 다 따로 만든다. | ||
* Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/ | * Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/ | ||
+ | * 페이징으로 데이터를 불한/ | ||
+ | * '' | ||
+ | * 처리처럼 데이터를 분할해서 가져갈 경우 항상 '' | ||
+ | * 대체로 **PK asc**를 하는게 DB에서 가장 성능이 좋다. [[https:// | ||
+ | * offset/ | ||
===== 사용자에게 전달하는 메시징 솔루션 ===== | ===== 사용자에게 전달하는 메시징 솔루션 ===== | ||
* Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | ||
줄 183: | 줄 188: | ||
* 아주 많은 종류의 여러글을 동시에 읽을 때의 테스트와 | * 아주 많은 종류의 여러글을 동시에 읽을 때의 테스트와 | ||
* 한 건의 글을 집중적으로 읽을 때를 테스트 해본다. - 해당 게시글을 가리키는 Row의 집중적인 lock으로 인해 이 경우 성능이 떨어질 수도 있다. | * 한 건의 글을 집중적으로 읽을 때를 테스트 해본다. - 해당 게시글을 가리키는 Row의 집중적인 lock으로 인해 이 경우 성능이 떨어질 수도 있다. | ||
+ | * 성능 측정시 실 데이터 갯수 / 구조 기준으로 한다. 적은 데이터 셋으로 하는 성능 테스트는 무의미하다. | ||
* CSS는 위로 Javascript는 아래로, 개발시에는 코딩상태 그대로, 실서비스에서는 minify 상태로. | * CSS는 위로 Javascript는 아래로, 개발시에는 코딩상태 그대로, 실서비스에서는 minify 상태로. | ||
* 라이브러리는 별도 관리하여 전반적인 라이브러리 업그레이드가 한 군데만 고치면 될 수 있는 구조로 만들 것. | * 라이브러리는 별도 관리하여 전반적인 라이브러리 업그레이드가 한 군데만 고치면 될 수 있는 구조로 만들 것. | ||
줄 249: | 줄 255: | ||
* 동기식으로 중앙 수집할 경우 서비스가 커지거나 특정 시점에 트래픽이 몰릴 때 Logging 자체가 병목이 되어버린다. | * 동기식으로 중앙 수집할 경우 서비스가 커지거나 특정 시점에 트래픽이 몰릴 때 Logging 자체가 병목이 되어버린다. | ||
* [[logging: | * [[logging: | ||
+ | * 에러 로그 메시지는 최대한 에러를 유발한 요청 파라미터를 상세하게 남기도록 한다. 안그러면 디버깅할 때 상하단의 모든 로그를 다 확인해야 하고, 그나마 요청 정보 로그도 존재하지 않으면 아예 새로 로그를 남겨 배포해야만 확인 가능해진다. | ||
===== Production Server ACL ===== | ===== Production Server ACL ===== | ||
줄 277: | 줄 284: | ||
===== API 설계 ===== | ===== API 설계 ===== | ||
- | * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 | + | * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 |
- | * 요청자 측에서 페이징 | + | * 더보기 |
+ | * 이 경우 페이지가 뒤로 늘어나도 전혀 성능저하가 발생하지 않고 균일하다. | ||
* 다음 페이지의 존재 여부를 알고자 한다면 '' | * 다음 페이지의 존재 여부를 알고자 한다면 '' | ||
+ | * '' | ||
+ | * '' | ||
* API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다. | * API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다. | ||
* 호출자 서비스 이름 | * 호출자 서비스 이름 | ||
* 호출자 서비스의 구체적 기능(컨트롤러 이름이나 배치 이름 등) | * 호출자 서비스의 구체적 기능(컨트롤러 이름이나 배치 이름 등) | ||
+ | * 인증의 역할 | ||
* 수정/ | * 수정/ | ||
* 다른 API를 호출한 결과는 항상 값이 null 일 수도 있다고 간주한다. | * 다른 API를 호출한 결과는 항상 값이 null 일 수도 있다고 간주한다. | ||
줄 311: | 줄 322: | ||
* 각 분야별(OS, | * 각 분야별(OS, | ||
* 장애 대응시 [[:5why|5 Whys]]와 [[: | * 장애 대응시 [[:5why|5 Whys]]와 [[: | ||
+ | |||
+ | ===== 마이그레이션 ===== | ||
+ | * 서비스를 리팩토링하면서 재구축할 때 실서비스 기준으로 마이그레이션을 먼저 시뮬레이션 해보는게 좋다. 그래야 현재 실제 존재하는 데이터들의 구성을 정확히 파아할 수 있다. | ||
+ | |||
+ | ===== 프로젝트 관리 : 기본적으로 애자일 ===== | ||
+ | * 오픈 예정일이 굉장히 밀도 높고 여러 팀이 엮인 프로젝트를 진행해야 할 경우 | ||
+ | * Jira(혹은 관련 이슈 트래커)에 여러 팀별 이슈를 하나로 묶은 보드를 생성한다. (묶음의 조건을 만족시킬 수 있는 이슈 레이블 등이 필요할 듯) | ||
+ | * 모든 팀을 통합하여 스프린트를 일괄로 잡는다. | ||
+ | * Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다. | ||
+ | * 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다. | ||
===== 참조 ===== | ===== 참조 ===== | ||
* [[http:// | * [[http:// | ||