사용자 도구

사이트 도구


web:신규서비스

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
web:신규서비스 [2019/02/14 14:29]
kwon37xi
web:신규서비스 [2019/05/03 16:45] (현재)
kwon37xi [API 설계]
줄 160: 줄 160:
     * 필요한 쿼리는 항상 상황별로 다 따로 만든다.     * 필요한 쿼리는 항상 상황별로 다 따로 만든다.
   * Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/​복구/​FailOver 전략을 각 DB에 맞게 수립해둬야 한다.   * Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/​복구/​FailOver 전략을 각 DB에 맞게 수립해둬야 한다.
 +  * 페이징으로 데이터를 불한/​연속 조회 할 경우에는 항상 **더보기 방식**을 사용한다. API 설계 부분 참조.
 +    * ''​offset/​limit''​ 조회는 ''​offset''​이 뒤로 갈수록 성능이 계단형으로 느려지게 된다. ''​offset''​을 계산하려면 그보다 앞에 있는 데이터들의 조건을 모두 검사해야하기 때문이다.
 +    * 처리처럼 데이터를 분할해서 가져갈 경우 항상 ''​order by PK asc''​를 해줘서 페이징의 순서를 명확히 해줘야한다.
 +    * 대체로 **PK asc**를 하는게 DB에서 가장 성능이 좋다. [[https://​www.percona.com/​blog/​2016/​10/​20/​mysql-8-0-descending-indexes-can-speedup-your-queries/​|MySQL 8.0 descending indexes can speedup your queryds]] ​
 +    * offset/​limit 방식(페이징)이 아니라 **''​nextPk,​limit''​**을 조회 조건으로 거는 더보기 방식을 사용해야 성능저하 없이 균일한 응답성을 보장받을 수 있다.
 ===== 사용자에게 전달하는 메시징 솔루션 ===== ===== 사용자에게 전달하는 메시징 솔루션 =====
   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.
줄 183: 줄 188:
     * 아주 많은 종류의 여러글을 동시에 읽을 때의 테스트와     * 아주 많은 종류의 여러글을 동시에 읽을 때의 테스트와
     * 한 건의 글을 집중적으로 읽을 때를 테스트 해본다. - 해당 게시글을 가리키는 Row의 집중적인 lock으로 인해 이 경우 성능이 떨어질 수도 있다.     * 한 건의 글을 집중적으로 읽을 때를 테스트 해본다. - 해당 게시글을 가리키는 Row의 집중적인 lock으로 인해 이 경우 성능이 떨어질 수도 있다.
 +  * 성능 측정시 실 데이터 갯수 / 구조 기준으로 한다. 적은 데이터 셋으로 하는 성능 테스트는 무의미하다.
   * CSS는 위로 Javascript는 아래로, 개발시에는 코딩상태 그대로, 실서비스에서는 minify 상태로.   * CSS는 위로 Javascript는 아래로, 개발시에는 코딩상태 그대로, 실서비스에서는 minify 상태로.
   * 라이브러리는 별도 관리하여 전반적인 라이브러리 업그레이드가 한 군데만 고치면 될 수 있는 구조로 만들 것.   * 라이브러리는 별도 관리하여 전반적인 라이브러리 업그레이드가 한 군데만 고치면 될 수 있는 구조로 만들 것.
줄 278: 줄 284:
  
 ===== API 설계 ===== ===== API 설계 =====
-  * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 ​''​offset''/''​limit'' ​으로 요청을 받는 것이 낫다.  +  * API 설계시 다중건 결과를 내는 경우 Paging 기반으로 요청을 받지 말고 ​**더보기 방식**으로 요청을 받는 것이 낫다.  
-    * 요청자 측에서 페이징 ​방식으로 ​자기네가 알아서 감싸는 것이 쉽다. 즉, 두가지 ​방식을 모두 요청자측에서 결정해서 할 수 있다.+    * 더보기 ​방식은 항상 Primary Key를 기준으로 ​하여 PK asc 로 정렬을하고,​ 앞서 1~10 의 결과를 읽었다면 다시 파라미터로 앞의 마지막 PK 10을 받은 뒤 ''​pk > 10 limit pageSize''​로 그 다음 조회를 한다. 
 +    * 이 경우 페이지가 뒤로 늘어나도 전혀 성능저하가 발생하지 않고 균일하다.
     * 다음 페이지의 존재 여부를 알고자 한다면 ''​limit''​이 10이면 11개를 쿼리해서 결과가 11개가 나오면 다음페이지가 존재하고,​ 아니면 여기서 끝인 것으로 판단하면 된다.     * 다음 페이지의 존재 여부를 알고자 한다면 ''​limit''​이 10이면 11개를 쿼리해서 결과가 11개가 나오면 다음페이지가 존재하고,​ 아니면 여기서 끝인 것으로 판단하면 된다.
 +    * ''​offset''/''​limit''​ 방식도 전체 카운트를 하는 Paging 보다는 낫지만 offset 값이 커질 수로 조건에 맞는 그 앞 데이터에 대한 카운팅을 해야해서 성능이 점점 느려진다. ​
 +      * ''​offset''/''​limit''​은 요청자 측에서 페이징 방식으로 자기네가 알아서 감싸는 것이 쉽다. 즉, 두가지 방식을 모두 요청자측에서 결정해서 할 수 있다.
   * API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다.   * API 의 경우 호출자에 대한 정보를 HTTP Header 등에 주입하고 로그로 자세히 남기는 것이 좋다. 이는 SQL 구문도 마찬가지 이다.
     * 호출자 서비스 이름     * 호출자 서비스 이름
     * 호출자 서비스의 구체적 기능(컨트롤러 이름이나 배치 이름 등)     * 호출자 서비스의 구체적 기능(컨트롤러 이름이나 배치 이름 등)
 +    * 인증의 역할
   * 수정/​삭제/​생성 등의 API를 만들 때 기초 데이터를 FORM/JSON 형태의 body로 실어보내면 access log에 정보가 제대로 남지 않는다. 가급적 중요한 핵심 정보는 URL에 Path Variable이나 Query Parameter로 남을 수 있게 해야 나중에 로그 확인이 쉽다.(예:​ member 수정시 /members 에 POST로 모든 정보를 담기보다는 /members/1 로 memberId를 URL에 남기고 나머지 데이터를 POST Body로 전송)   * 수정/​삭제/​생성 등의 API를 만들 때 기초 데이터를 FORM/JSON 형태의 body로 실어보내면 access log에 정보가 제대로 남지 않는다. 가급적 중요한 핵심 정보는 URL에 Path Variable이나 Query Parameter로 남을 수 있게 해야 나중에 로그 확인이 쉽다.(예:​ member 수정시 /members 에 POST로 모든 정보를 담기보다는 /members/1 로 memberId를 URL에 남기고 나머지 데이터를 POST Body로 전송)
   * 다른 API를 호출한 결과는 항상 값이 null 일 수도 있다고 간주한다.   * 다른 API를 호출한 결과는 항상 값이 null 일 수도 있다고 간주한다.
줄 315: 줄 325:
 ===== 마이그레이션 ===== ===== 마이그레이션 =====
   * 서비스를 리팩토링하면서 재구축할 때 실서비스 기준으로 마이그레이션을 먼저 시뮬레이션 해보는게 좋다. 그래야 현재 실제 존재하는 데이터들의 구성을 정확히 파아할 수 있다.   * 서비스를 리팩토링하면서 재구축할 때 실서비스 기준으로 마이그레이션을 먼저 시뮬레이션 해보는게 좋다. 그래야 현재 실제 존재하는 데이터들의 구성을 정확히 파아할 수 있다.
 +
 +===== 프로젝트 관리 : 기본적으로 애자일 =====
 +  * 오픈 예정일이 굉장히 밀도 높고 여러 팀이 엮인 프로젝트를 진행해야 할 경우
 +  * Jira(혹은 관련 이슈 트래커)에 여러 팀별 이슈를 하나로 묶은 보드를 생성한다. (묶음의 조건을 만족시킬 수 있는 이슈 레이블 등이 필요할 듯)
 +  * 모든 팀을 통합하여 스프린트를 일괄로 잡는다.
 +  * Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다.
 +  * 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다.
  
 ===== 참조 ===== ===== 참조 =====
   * [[http://​startupstash.com/​|Startup Stash]] 스타트업에 필요한 도구들 소개   * [[http://​startupstash.com/​|Startup Stash]] 스타트업에 필요한 도구들 소개
  
web/신규서비스.1550122198.txt.gz · 마지막으로 수정됨: 2019/02/14 14:29 저자 kwon37xi