사용자 도구

사이트 도구


web:신규서비스

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
web:신규서비스 [2021/09/08 08:53]
kwon37xi [용어 통일]
web:신규서비스 [2022/05/12 13:52] (현재)
kwon37xi [신규 개발 조직 구축시 먼저 할 일]
줄 16: 줄 16:
   * 과도하게 개발자 풀이 적은/새로운 언어/프레임워크를 사용해서는 안 된다. 서비스 초창기에는 괜찮지만 서비스가 커질 경우 해당 언어나 프레임워크에 익숙한 개발자를 구하기 어려우며, 그로 인해 신규 유입된 개발자들이 언어/프레임워크에 대한 이해 부족으로 코딩을 잘못하게 되고 이는 개발자들의 자질/언어의 좋고 나쁨과 상관없이 해당 언어가 나쁜 언어로 매도되고, 결국 그들에게 익숙한 언어로 다시 작성하느라 서비스 발전의 발목을 잡는 요인이 된다.   * 과도하게 개발자 풀이 적은/새로운 언어/프레임워크를 사용해서는 안 된다. 서비스 초창기에는 괜찮지만 서비스가 커질 경우 해당 언어나 프레임워크에 익숙한 개발자를 구하기 어려우며, 그로 인해 신규 유입된 개발자들이 언어/프레임워크에 대한 이해 부족으로 코딩을 잘못하게 되고 이는 개발자들의 자질/언어의 좋고 나쁨과 상관없이 해당 언어가 나쁜 언어로 매도되고, 결국 그들에게 익숙한 언어로 다시 작성하느라 서비스 발전의 발목을 잡는 요인이 된다.
   * 따라서 개발자 시장의 현실을 무시하지 말 것이며, 꼭 개발자 풀이 적은 언어를 사용해야 할 경우에는 회사 내에서 해당 언어의 교육과 올바른 언어 사용 컨벤션 정립 등에 대해서도 많은 신경을 써야 하며(이 경우 Pair 프로그래밍이 좋은 방법 같다. 하지만 폭발적으로 개발자가 증가할 경우 잘 안 통할 듯 함) 채용시에도 채용 속도를 천천히 그리고 높은 채용기준을 가지고 하는 것이 좋을 것 같다.   * 따라서 개발자 시장의 현실을 무시하지 말 것이며, 꼭 개발자 풀이 적은 언어를 사용해야 할 경우에는 회사 내에서 해당 언어의 교육과 올바른 언어 사용 컨벤션 정립 등에 대해서도 많은 신경을 써야 하며(이 경우 Pair 프로그래밍이 좋은 방법 같다. 하지만 폭발적으로 개발자가 증가할 경우 잘 안 통할 듯 함) 채용시에도 채용 속도를 천천히 그리고 높은 채용기준을 가지고 하는 것이 좋을 것 같다.
 +
 +===== 신기술 선택 =====
 +  * 다음과 같은 용어를 확인해볼것.
 +  * ''단점'', ''주의할 점'', ''위험성'', ''cons'', ''pitfall'', ''gotchas'', ''warns'', "when not to use"
  
 ===== 용어 통일 ===== ===== 용어 통일 =====
줄 22: 줄 26:
   * 또한 서로 다른팀간의 연동을 할 때, 변수, 메소드, 클래스 이름등이 너무 많이 달라서 이들간의 연동을 할 때 혼란이 매우 커진다.   * 또한 서로 다른팀간의 연동을 할 때, 변수, 메소드, 클래스 이름등이 너무 많이 달라서 이들간의 연동을 할 때 혼란이 매우 커진다.
   * 프로젝트를 시작할 때 **한국어 용어, 그에 대응하는 영어 단어(이를 사용해서 클래스,변수, 메소드 등을 정의) 그리고 그 정확한 의미**를 모두 정리하는 문서화 작업을 하고 이를 전사적으로 공유한다.   * 프로젝트를 시작할 때 **한국어 용어, 그에 대응하는 영어 단어(이를 사용해서 클래스,변수, 메소드 등을 정의) 그리고 그 정확한 의미**를 모두 정리하는 문서화 작업을 하고 이를 전사적으로 공유한다.
-  * 용어를 정의할 때 하나의 용어가 상황에 따라 여러가지 의미를 가지게 하면 안된다. 즉, **용어가 락까지 포함**해야 한다.+  * 용어를 정의할 때 하나의 용어가 상황에 따라 여러가지 의미를 가지게 하면 안된다. 즉, **용어가 락까지 포함**해야 한다.
     * 예) "배달비" : 맥락에 따라 고객에 가게 주인에게 배달비를 지급할 때도 있고, 가게 주인이 배달원에게 지급할 때도 있다. 따라서 두 상황에 맞는 별도의 용어를 정의해야 한다.     * 예) "배달비" : 맥락에 따라 고객에 가게 주인에게 배달비를 지급할 때도 있고, 가게 주인이 배달원에게 지급할 때도 있다. 따라서 두 상황에 맞는 별도의 용어를 정의해야 한다.
 +  * **약자 사용 금지** 업계의 보편적인 약자라도 문제 직군에 따라 그 이해가 달라진다. 약자는 최대한 자제하고 사용하더라도 문서화 돼 있어야 한다.
   * 프로젝트 이름을 nickname 으로 만들지 말것. 프로젝트에 대해 직관적인 이름으로 짓지 않으면 다른 팀/신규 입사자와 소통할 때 매번 설명이 필요해진다.   * 프로젝트 이름을 nickname 으로 만들지 말것. 프로젝트에 대해 직관적인 이름으로 짓지 않으면 다른 팀/신규 입사자와 소통할 때 매번 설명이 필요해진다.
 ===== 영웅 의존 금지 ===== ===== 영웅 의존 금지 =====
줄 66: 줄 71:
     * 이는 치명적인 보안 위협이 된다.     * 이는 치명적인 보안 위협이 된다.
     * 특히 인증만 하고, 권한 검사를 제대로 안하고 노출시키는 일이 빈번해서, 인증 받은 특정 사용자가 API Gateway 로 열려있는 내부 API에서 본인이 아닌 다른 사용자의 정보를 읽을 수 있게 된다.     * 특히 인증만 하고, 권한 검사를 제대로 안하고 노출시키는 일이 빈번해서, 인증 받은 특정 사용자가 API Gateway 로 열려있는 내부 API에서 본인이 아닌 다른 사용자의 정보를 읽을 수 있게 된다.
-    * Netflix 의 [[java:zuul|Zuul - Edge Service]] 을 보면, 내부 API를 노출시키는 용도가 아니라, 외부 전용 API 서비스인데, 인증 방식이 다른 것들을 API Gateway 로 노출하가게 구성하는 식으로 만든 것이다.+    * Netflix 의 [[java:zuul|Zuul]] 을 보면, 내부 API를 노출시키는 용도가 아니라, 외부 전용 API 서비스인데, 인증 방식이 다른 것들을 API Gateway 로 노출하가게 구성하는 식으로 만든 것이다.
   * 즉, 외부 노출용 API는 그 안에서 사용자를 인증하고, 다른 API를 호출하고, 권한을 검사하는 로직을 다 직접 작성하는 것이 낫다.   * 즉, 외부 노출용 API는 그 안에서 사용자를 인증하고, 다른 API를 호출하고, 권한을 검사하는 로직을 다 직접 작성하는 것이 낫다.
   * 이게 싫다고 **내부용 API 에 권한 로직을 넣는 것도 하지 말라.**   * 이게 싫다고 **내부용 API 에 권한 로직을 넣는 것도 하지 말라.**
줄 73: 줄 78:
     * 게다가 그 와중에 또다른 권한 군이 들어오게 되면 모든 MSA 서비스가 그것들을 모두 신경써가면서 개발해야하게 되어 개발 속도를 떨어뜨리고 보안 위협이 시작되게 된다.     * 게다가 그 와중에 또다른 권한 군이 들어오게 되면 모든 MSA 서비스가 그것들을 모두 신경써가면서 개발해야하게 되어 개발 속도를 떨어뜨리고 보안 위협이 시작되게 된다.
   * **외부 노출 API가 인증과 권한을 전담해야 한다.**   * **외부 노출 API가 인증과 권한을 전담해야 한다.**
 +  * 하나의 API 애플리케이션은 하나의 인증만 처리한다. 인증이 여러 종류가 섞이는 순간 혼동으로 인해 보안 사고가 발생할 확률이 높아진다. 특히, **Front 서버에 내부용 API를 넣는 행동은 절대로 해서는 안된다.**
 ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 ===== ===== 약한 결합도 높은 응집도의 Inteface 기반 개발 =====
   * 각각의 모듈간의 호출은 ''interface'' 기반으로 약한 결합도 높은 응집도를 유지해야 한다.   * 각각의 모듈간의 호출은 ''interface'' 기반으로 약한 결합도 높은 응집도를 유지해야 한다.
줄 122: 줄 128:
   * 비추천(계정관련만 https) : ''https://account.example.com'', ''http://www.example.com'', ''http://articles.example.com''   * 비추천(계정관련만 https) : ''https://account.example.com'', ''http://www.example.com'', ''http://articles.example.com''
   * 개발용 도메인을 ''example.**dev**'', 통합 테스트 도메인 ''example.**test**'' 처럼 전혀 다른 최상위 도메인으로 끝나게 하면 실서비스와 쿠키 정보가 섞이지 않아 편해질 수 있다. 또한 실서비스에서 테스트인 줄 착각하는 일도 줄어든다.   * 개발용 도메인을 ''example.**dev**'', 통합 테스트 도메인 ''example.**test**'' 처럼 전혀 다른 최상위 도메인으로 끝나게 하면 실서비스와 쿠키 정보가 섞이지 않아 편해질 수 있다. 또한 실서비스에서 테스트인 줄 착각하는 일도 줄어든다.
 +  * 내부망용 도메인 네임 규칙과 외부망용 도메인 네임 규칙을 명확히 가져가야 보안 이슈 발생시 대응이 쉽다.
 ===== 안정성 ===== ===== 안정성 =====
   * SPoF(Single Point of failure)를 제거하라.   * SPoF(Single Point of failure)를 제거하라.
줄 128: 줄 135:
  
 ===== 확장성 고려 ===== ===== 확장성 고려 =====
-  * 선형 증가 데이터와 지수적 증가 데이터를 잘 구분하여 선형 증가 데이터는 RDBMS(혹은 상황에 따라 다른 적합한 것), 지수적 증가 데이터베이스는 RDBMS sharding 혹은 [[:nosql|NoSQL]]을 고민한다.+  * 선형 증가 데이터와 지수적 증가 데이터를 잘 구분하여 애초에 저장소를 분리한다. 
 +    * 선형 증가 데이터 : 상품, 사용자 등 
 +    * 지수적 증가 데이터 : 주문, 배송 등 상품에 대해 사용자가 행위하는 것 
 +    * 선형 증가 데이터는 RDBMS(혹은 상황에 따라 다른 적합한 것), 지수적 증가 데이터베이스는 RDBMS sharding 혹은 [[:nosql|NoSQL]]을 고민한다.
     * 초반부터 지나친 확장성 대비는 오히려 악영향을 줄 수 있는 것은 사실이지만,     * 초반부터 지나친 확장성 대비는 오히려 악영향을 줄 수 있는 것은 사실이지만,
     * 현재(2013) 상황으로 봤을 때 처음부터 NoSQL을 도입하는 것이 RDBMS를 도입하는 것과 비교해서 특별히 더 어렵지도 않게 되었다.     * 현재(2013) 상황으로 봤을 때 처음부터 NoSQL을 도입하는 것이 RDBMS를 도입하는 것과 비교해서 특별히 더 어렵지도 않게 되었다.
줄 154: 줄 164:
   * SQL에서 데이터를 생성하지 말라. 예를들어 ''now()'', ''password()'' 같은 것 사용금지. **데이터 생성/변형은 애플리케이션에서 일관되게 처리**한다. 그렇지 않으면 추후 확장시 문제요소가 될 수 있다.   * SQL에서 데이터를 생성하지 말라. 예를들어 ''now()'', ''password()'' 같은 것 사용금지. **데이터 생성/변형은 애플리케이션에서 일관되게 처리**한다. 그렇지 않으면 추후 확장시 문제요소가 될 수 있다.
   * Production 서버 애플리케이션에서 사용할 계정은 최소 권한만으로 생성한다. 안그러면 개발자 실수로 drop table, 혹은 hibernate ''hbm2ddl.auto'' 옵션에 의해 DB를 날릴 수 있다.   * Production 서버 애플리케이션에서 사용할 계정은 최소 권한만으로 생성한다. 안그러면 개발자 실수로 drop table, 혹은 hibernate ''hbm2ddl.auto'' 옵션에 의해 DB를 날릴 수 있다.
 +    * DDL 권한은 없어야 한다.
 +    * DML(''update'',''delete'')도 ''where'' 조건이 없으면 실행 불가로 하는 것이 좋다.
   * 특별한 이유가 없다면 무조건 ORM 혹은 이에 준하는 솔루션을 사용하라. DB 쿼리 튜닝보다는 ORM으로 객체지향적이고 유지보수성 높은 코드를 짜고서, Cache 등으로 거시적 튜닝을 하는 것이 좋다.   * 특별한 이유가 없다면 무조건 ORM 혹은 이에 준하는 솔루션을 사용하라. DB 쿼리 튜닝보다는 ORM으로 객체지향적이고 유지보수성 높은 코드를 짜고서, Cache 등으로 거시적 튜닝을 하는 것이 좋다.
   * 저장소에 Script Code 성 데이터(Stored Procedure나 이에 준하는 것들)를 넣지 않는다.   * 저장소에 Script Code 성 데이터(Stored Procedure나 이에 준하는 것들)를 넣지 않는다.
     * 데이터와 코드의 경계가 불분명해지고, 코드의 커버리지, 히스토리(VCS) 관리, 리팩토링 등이 불가능해지고,     * 데이터와 코드의 경계가 불분명해지고, 코드의 커버리지, 히스토리(VCS) 관리, 리팩토링 등이 불가능해지고,
     * 배포 단계(develop, integration, production ..)에 따라 서로 다른 코드가 주입되기 때문에 올바른 테스트가 어려워 진다.     * 배포 단계(develop, integration, production ..)에 따라 서로 다른 코드가 주입되기 때문에 올바른 테스트가 어려워 진다.
-    * 또한 코드가 데이터 저장소에 들어가면서 production에서 실 데이터로 일부 서버만 적용하여 테스트해보거나 하는 분할 배포를 할 수가 없게 되어 production 과 동일 데이터를 사용하는 stage 환경 테스트가 불가능해진다.+    * 또한 코드가 데이터 저장소에 들어가면서 production에서 실 데이터로 일부 서버만 적용하여 테스트해보거나 하는 분할 배포를 할 수가 없게 되어 production 과 동일 데이터를 사용하는 staging 환경 테스트가 불가능해진다.
   * SQL에 로직 넣지 말자. SQL에서 충분히 가능한 간단한 연산도 애플리케이션 코드에서 처리해서 최종 결과를 적절한 이름의 변수에 설정해서 넘겨줘야 코드 유지보수성이 높아진다.   * SQL에 로직 넣지 말자. SQL에서 충분히 가능한 간단한 연산도 애플리케이션 코드에서 처리해서 최종 결과를 적절한 이름의 변수에 설정해서 넘겨줘야 코드 유지보수성이 높아진다.
   * 자연키(Natural Key)를 주키(Primary Key)로 사용해서는 안 된다. 가급적 인공키(Surrogate Key)를 PK로 사용한다.   * 자연키(Natural Key)를 주키(Primary Key)로 사용해서는 안 된다. 가급적 인공키(Surrogate Key)를 PK로 사용한다.
줄 168: 줄 180:
   * 항상 올바른 타입을 사용하려고 노력한다. 날짜는 날짜 타입, boolean, 숫자 등 항상 적합한 타입을 사용해야 쓰레기 데이터를 막을 수 있다.   * 항상 올바른 타입을 사용하려고 노력한다. 날짜는 날짜 타입, boolean, 숫자 등 항상 적합한 타입을 사용해야 쓰레기 데이터를 막을 수 있다.
   * **PK가 아닌 숫자값과 boolean 타입은 모두 NOT NULL**로 설계한다. 그렇지 않으면 숫자 연산에 대해 ''0''인 상태와 ''NULL''인 상태 모두에 대해 항상 조건을 걸거나 ''NULL -> 0'' 변경을 수행해야만 하게 된다. 또한 boolean도 상태가 ''true/false/null'' 세가지 상태가 되어 버린다.   * **PK가 아닌 숫자값과 boolean 타입은 모두 NOT NULL**로 설계한다. 그렇지 않으면 숫자 연산에 대해 ''0''인 상태와 ''NULL''인 상태 모두에 대해 항상 조건을 걸거나 ''NULL -> 0'' 변경을 수행해야만 하게 된다. 또한 boolean도 상태가 ''true/false/null'' 세가지 상태가 되어 버린다.
 +    * 만약에 숫자값의 ''null''이 의미가 있다면 정확하게 주석을 단다.
   * 모든 테이블에는 insert 시간과 modify 시간을 모두 기록한다(''createdAt'', ''modifiedAt'').   * 모든 테이블에는 insert 시간과 modify 시간을 모두 기록한다(''createdAt'', ''modifiedAt'').
   * 중요 테이블의 경우 최종 수정된 내용만 가지고 있고 그에 대해 제약 조건을 모두 지키도록 설계한다. 다만, 변경시마다 **중요 변경사항을 history 테이블을 따로 두어** 남기도록 한다. 그래야 서비스 유지보수시 알 수 없는 오류에 대한 참고 데이터로 삼아 고객의 요구에 대해 올바로 대응 할 수 있다. history는 RDBMS 가 아니라 NoSQL로 남기는 것도 좋다.   * 중요 테이블의 경우 최종 수정된 내용만 가지고 있고 그에 대해 제약 조건을 모두 지키도록 설계한다. 다만, 변경시마다 **중요 변경사항을 history 테이블을 따로 두어** 남기도록 한다. 그래야 서비스 유지보수시 알 수 없는 오류에 대한 참고 데이터로 삼아 고객의 요구에 대해 올바로 대응 할 수 있다. history는 RDBMS 가 아니라 NoSQL로 남기는 것도 좋다.
   * **컬럼의 의미를 바꾸지 말 것.** DB의 역사가 오래될 수록 컬럼의 의미를 중간에 바꾸는 경우가 있는데, **컬럼의 의미를 변경하려면 기존 데이터를 모두 마이그레이션 하던지, 새로운 컬럼을 만들어서 새로운 의미를 부여하든지 한다.** 기존 데이터를 그대로 남겨둔 상태로 컬럼의 의미를 바꾸면 매핑되는 객체 구조 설계에도 문제가 생기고 쿼리 결과를 처리하는 모든 구문에 상황에 따른 조건문이 계속 추가되어 개발 부담을 가중시키게 된다.   * **컬럼의 의미를 바꾸지 말 것.** DB의 역사가 오래될 수록 컬럼의 의미를 중간에 바꾸는 경우가 있는데, **컬럼의 의미를 변경하려면 기존 데이터를 모두 마이그레이션 하던지, 새로운 컬럼을 만들어서 새로운 의미를 부여하든지 한다.** 기존 데이터를 그대로 남겨둔 상태로 컬럼의 의미를 바꾸면 매핑되는 객체 구조 설계에도 문제가 생기고 쿼리 결과를 처리하는 모든 구문에 상황에 따른 조건문이 계속 추가되어 개발 부담을 가중시키게 된다.
-  * DB 자체의 타입 enum 을 사용하지 말라. 또한 프로그래밍 언어 enum 을 사용할 때 절대로 순서 숫자값(ordinal)로 저장하면 안된다. 이 둘은 모두 enum 항목들의 순서 변경이 발생하는 순간 엄청난 마이그레이션을 수행해야한다. 그에 비해 성능 향상은 그리 크지 않아보인다.+  * DB 자체의 타입 enum 을 사용하지 말라. 또한 프로그래밍 언어 enum 을 사용할 때 절대로 순서 숫자값(ordinal)로 저장하면 안된다. 이 둘은 모두 enum 항목들의 순서 변경이 발생하는 순간 엄청난 마이그레이션을 수행해야한다. 그에 비해 성능 향상은 그리 크지 않아보인다. MySQL의 enum은 겉보기와는 달리 ordinal 로 작동하기 때문에 **enum 의 순서가 변경**되면 단순 alter table로 문제가 해결되지 않고 기존 데이터를 모두 마이그레이션 해야 한다.
   * 과도한 동적 쿼리를 생성하지 말라. - 특히 iBatis/MyBatis/문자열 기반으로 쿼리 짤 때 null 을 체크해서 조건문을 넣었다 빼었다 하는 경우   * 과도한 동적 쿼리를 생성하지 말라. - 특히 iBatis/MyBatis/문자열 기반으로 쿼리 짤 때 null 을 체크해서 조건문을 넣었다 빼었다 하는 경우
     * 상태에 따라 WHERE 절이 나타났다 사라졌다하는 식의 동적 쿼리는 자칫 실수하면 모든 조건이 없어져서 엄청난 부하를 일으키는 SELECT 쿼리나 모든 데이터를 삭제하는 DELETE 문이 될 수 있다.     * 상태에 따라 WHERE 절이 나타났다 사라졌다하는 식의 동적 쿼리는 자칫 실수하면 모든 조건이 없어져서 엄청난 부하를 일으키는 SELECT 쿼리나 모든 데이터를 삭제하는 DELETE 문이 될 수 있다.
줄 177: 줄 190:
     * 필요한 쿼리는 항상 상황별로 다 따로 만든다.     * 필요한 쿼리는 항상 상황별로 다 따로 만든다.
   * Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/복구/FailOver 전략을 각 DB에 맞게 수립해둬야 한다.   * Backup/Fail Over 전략을 수립해둔다. : DB 생성 초기 부터 백업/복구/FailOver 전략을 각 DB에 맞게 수립해둬야 한다.
-  * 페이징으로 데이터를 불한/연속 조회 할 경우에는 항상 **더보기 방식**을 사용한다. API 설계 부분 참조.+  * 페이징으로 데이터를 불한/연속 조회 할 경우에는 항상 **더보기 방식(ID 기반 페이징)**을 사용한다. API 설계 부분 참조.
     * ''offset/limit'' 조회는 ''offset''이 뒤로 갈수록 성능이 계단형으로 느려지게 된다. ''offset''을 계산하려면 그보다 앞에 있는 데이터들의 조건을 모두 검사해야하기 때문이다.     * ''offset/limit'' 조회는 ''offset''이 뒤로 갈수록 성능이 계단형으로 느려지게 된다. ''offset''을 계산하려면 그보다 앞에 있는 데이터들의 조건을 모두 검사해야하기 때문이다.
     * 처리처럼 데이터를 분할해서 가져갈 경우 항상 ''order by PK asc''를 해줘서 페이징의 순서를 명확히 해줘야한다.     * 처리처럼 데이터를 분할해서 가져갈 경우 항상 ''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]]      * 대체로 **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]] 
 +    * [[https://use-the-index-luke.com/sql/partial-results/fetch-next-page|OFFSET is bad for skipping previous rows]] [[database:seek_method|seek method]] 라고 부름
     * 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 에 빠르게 반응하게 된다.   * DB Connection Pool 의 **connectionTimeout** 값(**커넥션풀에서 커넥션을 가져오는데 걸리는 최대시간**)을 2~3초 정도로 짧게 가져간다. 또한 JDBC 사용시, **connectionTimeout**(**실제 DB에 접속하는데 걸리는 시간**)도 1초 이내로 짧게 가져가야한다. 그래야 DB 서버 Fail Over 에 빠르게 반응하게 된다.
-  * DB 트랜잭션 내부에서 다른 API 호출등을 하지 말아야한다. API 호출 지연이 발생하면 실제로 DB 작업을 하지 않아도 Connection Pool 이 고갈돼 버려서 API를 호출하지 않는 다른 DB 호출까지 모두 연쇄 지연되는 현상이 발생한다.+  * Write 트랜잭션(Transaction)은 최소로 유지해야한다. 만약 write 트랜잭션 내에서 다른 데이터의 과도한 조회 등이 발생한다면 write 를 위한 선행 데이터 조회와 write 그 자체의 트랜잭션을 따로 분할해서  DB Lock 을 줄여야 한다. 
 +  * 위의 상황과 유사하지만 비록 순수 Read라 하더라도 트랜잭션을 짧게 가져가야 한다. Long Transaction을 일으키는 큰 문제중의 하나가 DB 트랜잭션 내부에서 다른 API 호출하는 것이다. 외부 API 호출등  DB와 무관하고 긴 시간이 걸리는 행위는 트랜잭션 안에서 하지 말아야한다. API 호출 지연이 발생하면 실제로 DB 작업을 하지 않아도 Connection Pool 이 고갈돼 버려서 API를 호출하지 않는 다른 DB 호출까지 모두 연쇄 지연되는 현상이 발생한다.
   * MySQL 은 항상 증가하는 값을 PK로 사용해야 한다(''BIGINT AUTOINCREMENT''). Insert 시에 PK를 기준으로 지속적으로 물리적 정렬를 하기 때문에 정렬되지 않은 PK insert 가 발생하면 성능이 저하된다. 만약에 비즈니스키가 증가하는 값이 아니라면 항상 인공키로 ''BIGINT AUTOINCREMENT''로 잡아준다.   * MySQL 은 항상 증가하는 값을 PK로 사용해야 한다(''BIGINT AUTOINCREMENT''). Insert 시에 PK를 기준으로 지속적으로 물리적 정렬를 하기 때문에 정렬되지 않은 PK insert 가 발생하면 성능이 저하된다. 만약에 비즈니스키가 증가하는 값이 아니라면 항상 인공키로 ''BIGINT AUTOINCREMENT''로 잡아준다.
   * DB 에 직접 실행하는 update/delete 쿼리는 항상 PK기반으로 한다.   * DB 에 직접 실행하는 update/delete 쿼리는 항상 PK기반으로 한다.
줄 191: 줄 206:
     * 처음에 쿼리를 짜던 시점과 실제 실행 시점 사이에 뭔가 변경된 데이터가 있을 때 그걸 알아채기도 쉬움.     * 처음에 쿼리를 짜던 시점과 실제 실행 시점 사이에 뭔가 변경된 데이터가 있을 때 그걸 알아채기도 쉬움.
   * 여러건 조회시 항상 정렬 조건(order by)를 지정해야한다. 정렬을 넣지 않고 어도 PK로 정령돼 있는 경우들이 있는데 이걸 믿고 있다가 나중에 순서가 예상과 다르게 나와서 장애가 나는 경우가 있다(특히 non-clustered index 조회일경우). 가급적 PK기준으로 지정한다.   * 여러건 조회시 항상 정렬 조건(order by)를 지정해야한다. 정렬을 넣지 않고 어도 PK로 정령돼 있는 경우들이 있는데 이걸 믿고 있다가 나중에 순서가 예상과 다르게 나와서 장애가 나는 경우가 있다(특히 non-clustered index 조회일경우). 가급적 PK기준으로 지정한다.
 +  * 기본적으로 Slow Query 모니터링을 걸고 알람을 한다. slow query 시간에 따라 알람 레벨을 주는 것도 좋을 것 같다.
 ===== 사용자에게 전달하는 메시징 솔루션 ===== ===== 사용자에게 전달하는 메시징 솔루션 =====
   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.   * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다.
줄 223: 줄 239:
   * Web Load Balancer 의 경우 최초에 서버를 띄운 직후에 분산 weight를 낮게 줬다가 차츰 올리는 설정이 있는 것이 좋아보인다. 서버 띄운 직후에 초기화를 하면서 서버 부담이 지나치게 크게 올라가서 최초 접속자들에게 응답이 매우 늦을 가능성이 보이고 서버 불안이 야기된다.   * Web Load Balancer 의 경우 최초에 서버를 띄운 직후에 분산 weight를 낮게 줬다가 차츰 올리는 설정이 있는 것이 좋아보인다. 서버 띄운 직후에 초기화를 하면서 서버 부담이 지나치게 크게 올라가서 최초 접속자들에게 응답이 매우 늦을 가능성이 보이고 서버 불안이 야기된다.
   * 전체 갯수를 가지고 계산하는 페이징 UI는 말들지 말아야 한다. 결국엔 전체 갯수 계산으로 인해 서비스가 사용할 수 없을 정도로 느려진다. "이전", "이후", "첫페이지", "마지막페이지" 로 가는 버튼만 만들고 전체 갯수는 "마지막페이지" 버튼을 눌렀을 때만 계산하고 다른때는 전혀 신경쓰지 않게 처리한다.   * 전체 갯수를 가지고 계산하는 페이징 UI는 말들지 말아야 한다. 결국엔 전체 갯수 계산으로 인해 서비스가 사용할 수 없을 정도로 느려진다. "이전", "이후", "첫페이지", "마지막페이지" 로 가는 버튼만 만들고 전체 갯수는 "마지막페이지" 버튼을 눌렀을 때만 계산하고 다른때는 전혀 신경쓰지 않게 처리한다.
-===== 캐시 =====+ 
 +===== Excel Download / 통계 제공 / bulk 작업 ===== 
 +  * Excel 다운로드나 통계 제공 혹은 인자를 받아서 일괄적으로 수많은 데이터를 갱신하는 등의 bulk 작업은 실시간 쿼리로 API 서버에서 실행해서는 안 된다. 
 +  * 이런 대용량 작업은 개발 시작 시점에는 데이터가 적어서 괜찮지만 나중에 데이터 증가후 전체 장애 유발 요인이 된다. 
 +  * 보통 DB 커넥션을 장시간 점유해서 connection 고갈을 일으키거나 
 +  * 혹은 Excel 다운로드의 경우 비록 [[java:poi|Apache POI MS Office Document]]의 [[https://poi.apache.org/apidocs/dev/org/apache/poi/xssf/streaming/SXSSFWorkbook.html|SXSSFWorkbook]] 를 통해 메모리를 최소화 하더라도 DB에서 가져온 데이터를 트랜잭션 단위로 잘 분할하지 않으면 memory 과점으로 ''OutOfMemory''를 일으키기도 한다. 
 +  * 이런 작업은 항상 batch 를 통해 비동기로 처리하도록 한다. 
 + 
 +===== Backend 캐시 =====
   * Local 캐시는 변화가 적고, 일시적인 값 Mismatch는 상관 없고 성능이 더 중요할 때   * Local 캐시는 변화가 적고, 일시적인 값 Mismatch는 상관 없고 성능이 더 중요할 때
   * 분산 캐시를 사용하면 성능은 떨어지만 ''expire''등에 대해 전 서버가 일제히 대응이 가능해져 일관성이 보장 될 수 있다.   * 분산 캐시를 사용하면 성능은 떨어지만 ''expire''등에 대해 전 서버가 일제히 대응이 가능해져 일관성이 보장 될 수 있다.
줄 233: 줄 257:
   * CDN 같은 정적 리소스 서빙 시스템을 두자.   * CDN 같은 정적 리소스 서빙 시스템을 두자.
   * CDN이 아니더라도, 별도의 도메인에서 정적 리소스를 통합 서비하는 것이 좋다.   * CDN이 아니더라도, 별도의 도메인에서 정적 리소스를 통합 서비하는 것이 좋다.
 +  * CDN도 이중화 해야한다.
   * JS, CSS 등은 버저닝하여 정적 리소스 서빙 시스템에 미리 배포한다.   * JS, CSS 등은 버저닝하여 정적 리소스 서빙 시스템에 미리 배포한다.
   * 이렇게 해야 리소스 로딩 속도가 조금이라도 빨라지고(깔끔한 HTTP 헤더와 별도 도메인으로 인한 다중 로딩 지원때문), 배포 중간에 발생하는 일시적 CSS, JS mismatch 현상을 조금이나마 줄일 수 있다(Sticky 세션 사용시 정적 리소스 미스매치 현상은 완화 가능할 수도).   * 이렇게 해야 리소스 로딩 속도가 조금이라도 빨라지고(깔끔한 HTTP 헤더와 별도 도메인으로 인한 다중 로딩 지원때문), 배포 중간에 발생하는 일시적 CSS, JS mismatch 현상을 조금이나마 줄일 수 있다(Sticky 세션 사용시 정적 리소스 미스매치 현상은 완화 가능할 수도).
줄 240: 줄 265:
     * 컨텐츠는 시간이 지나면 점점 액세스가 줄어든다.     * 컨텐츠는 시간이 지나면 점점 액세스가 줄어든다.
     * 접근이 적은 썸네을을 삭제하는 방식으로 용량을 줄일 수 있고, 업로드 시간도 확보 가능할 것으로 보임.     * 접근이 적은 썸네을을 삭제하는 방식으로 용량을 줄일 수 있고, 업로드 시간도 확보 가능할 것으로 보임.
 +  * Javascript 등을 캐시하면, 코드를 고쳐 배포해도 사용자가 캐시로 인해 변경된 프로그램을 못 사용한다.
 +    * 따라서 filehashing 혹은 timestamp 등을 파라미터로 붙이는 기법을 각 JS framework 별로 제공해주므로 해당 방법으로 배포시마다 캐시를 무력화해줘야 한다.
 ===== HTML ===== ===== HTML =====
   * HTML과 유사하게 꺽쇠(''<>'') 기반의 커스텀 태그를 사용하는 템플릿 엔진은 사용하지 말라. HTML과 템플릿 코드가 섞여보여서 유지보수성이 현저히 저하된다(JSP, Freemarker 등 쓰지 말라는 얘기).   * HTML과 유사하게 꺽쇠(''<>'') 기반의 커스텀 태그를 사용하는 템플릿 엔진은 사용하지 말라. HTML과 템플릿 코드가 섞여보여서 유지보수성이 현저히 저하된다(JSP, Freemarker 등 쓰지 말라는 얘기).
줄 268: 줄 295:
   * 뭔가를 막아야할 때는 blacklist 보다는 whitelist 방식 권장. blacklist 는 또 다시 막아야할 것이 발견될 가능성이 높다.   * 뭔가를 막아야할 때는 blacklist 보다는 whitelist 방식 권장. blacklist 는 또 다시 막아야할 것이 발견될 가능성이 높다.
     * 문자 필드에 어떤 문자를 사용할 수 없게 해야하는 상황일 경우에도, ''한글,영문 대소문자, 숫자, _, ...'' 식으로 whitelist 를 지정하는게 낫다.     * 문자 필드에 어떤 문자를 사용할 수 없게 해야하는 상황일 경우에도, ''한글,영문 대소문자, 숫자, _, ...'' 식으로 whitelist 를 지정하는게 낫다.
 +  * 인증 토큰(token) 은 변조가 불가하면서 애플리케이션 사용에 필요한 최소한의 데이터를 담도록 한다. [[web:jwt|JWT]] 등을 암호화 하는 방법을 권장함.
 +  * DDoS 공격 방어를 위해 WAF(Web Application Firewall, 웹방화벽) 설정을 해야한다.
 ===== 서버 운영 ===== ===== 서버 운영 =====
   * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다.   * 절대로 여러 사람이 공유하는 공용 계정으로 서버를 관리하지 말라(AWS 등 포함). 이는 치명적인 보안 사고로 이어진다.
줄 307: 줄 336:
       * 이렇게 해야 ''주문 취소건'' 이라는 검색어로 주문 취소와 관련된 연관 로그를 한 번에 검색 가능해진다.       * 이렇게 해야 ''주문 취소건'' 이라는 검색어로 주문 취소와 관련된 연관 로그를 한 번에 검색 가능해진다.
     * 절대로 예외를 먹지 말것. 정말 특별한 경우가 아니면 항상 예외의 stacktrace까지 모두 남길것. 특별한 경우에는 왜 특별한지 주석 달 것.     * 절대로 예외를 먹지 말것. 정말 특별한 경우가 아니면 항상 예외의 stacktrace까지 모두 남길것. 특별한 경우에는 왜 특별한지 주석 달 것.
 +  * UI 관점에서 사용자 행위 로그를 꼭 남기도록 하고 이를 분석하여 개선 방향을 도출할 수 있도록 한다.
 ===== Production Server ACL ===== ===== Production Server ACL =====
   * 운영 시스템에 대한 ACL은 개발 초기부터 망 분리 등을 통해 운영시스템에서만 접속가능하도록 하고 **절대 개발자 PC, 테스트 시스템 등에서는 접속이 불가능**하도록 구성한다(여기서 말하는 접속은 서버에 대한 SSH 접속이 아니라 DB,Redis,MQ 같은 시스템, API 서버 등에 대한 접속을 뜻한다).   * 운영 시스템에 대한 ACL은 개발 초기부터 망 분리 등을 통해 운영시스템에서만 접속가능하도록 하고 **절대 개발자 PC, 테스트 시스템 등에서는 접속이 불가능**하도록 구성한다(여기서 말하는 접속은 서버에 대한 SSH 접속이 아니라 DB,Redis,MQ 같은 시스템, API 서버 등에 대한 접속을 뜻한다).
줄 316: 줄 345:
   * 중앙 집중형으로 만들면 초기에는 편하지만 프로젝트가 증가하면 관리가 어렵고 하나 고치다가 다른데 영향을 주거나 하기 쉽다. 또한 중단된 프로젝트에 관한 설정을 제거할 때도 망설이게 되어 계속 크기가 증가만 하게 된다.   * 중앙 집중형으로 만들면 초기에는 편하지만 프로젝트가 증가하면 관리가 어렵고 하나 고치다가 다른데 영향을 주거나 하기 쉽다. 또한 중단된 프로젝트에 관한 설정을 제거할 때도 망설이게 되어 계속 크기가 증가만 하게 된다.
   * [[https://m.blog.naver.com/PostView.nhn?blogId=muchine98&logNo=220267437777&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F|Blue/Green 배포]]([[https://martinfowler.com/bliki/BlueGreenDeployment.html|Blue Green Deployment]])를 가능하게 설계한다.   * [[https://m.blog.naver.com/PostView.nhn?blogId=muchine98&logNo=220267437777&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F|Blue/Green 배포]]([[https://martinfowler.com/bliki/BlueGreenDeployment.html|Blue Green Deployment]])를 가능하게 설계한다.
 +
 +===== 배포 Profile 통합 =====
 +  * 배포 프로필을 전사적으로 통일하지 않으면 여러 Micro Service에 대해 각종 테스트시 혼란이 유발된다.
 +  * local, dev, qa, prod, staging 등의 의미를 통합해서 구축하고 항상 동일한 명칭 동일한 의미로 사용하게 한다.
 +
 +
 ===== Mobile App ===== ===== Mobile App =====
   * 항상 최신버전을 유지할 수 있는 웹과는 달리 Mobile App은 그럴 수 없다.   * 항상 최신버전을 유지할 수 있는 웹과는 달리 Mobile App은 그럴 수 없다.
줄 352: 줄 387:
   * API 호출 내부에서 다른 API를 호출해서 결과를 합치는 일을 하는 것은 좋지 않다. 내부 호출 API의 장애가 전체적으로 다 전파 돼 버린다.   * API 호출 내부에서 다른 API를 호출해서 결과를 합치는 일을 하는 것은 좋지 않다. 내부 호출 API의 장애가 전체적으로 다 전파 돼 버린다.
     * 최초의 API호출자는 여러 API 호출이 필요하면 다른 API에게 또 다른 API호출을 요청하기 보다는 스스로 모든 요청을 하는게 장애 포인트를 줄여나가는 방법이다.     * 최초의 API호출자는 여러 API 호출이 필요하면 다른 API에게 또 다른 API호출을 요청하기 보다는 스스로 모든 요청을 하는게 장애 포인트를 줄여나가는 방법이다.
-===== MQ 등을 통한 비동기 처리 =====+  * 오류가 나면 오류를 발생시키는게 낫다(''4xx'', ''5xx'' 응답 권장). 
 +    * 오류 발생시 API 응답은 ''200'' 으로 정상으로 내리면서, 응답 데이터에 오류 코드등을 넣게 설계하는 경우가 있는데 
 +    * 이렇게 되면 모든 호출자가 응답에 오류코드가 있는지 일일이 확인해야 한다. 
 +    * 이를 확인하지 않고 데이터를 사용할 경우 에러가 즉각 발생했으면 오히려 문제가 덜 발생했을 것을 더 큰 문제로 커지게 된다. 
 +    * 예를들어 에러코드는 존재하고, 응답 데이터는 empty 로 주는데, 이때 오류를 확인하지 않고 empty 로 온 데이터를 직렬화하면 응답 객체의 필드가 ''null'' 혹은 기본값으로 채워지게 되고, 이를 가지고 정상응답으로 착각하고 나머지 프로세스를 타면 아주 치명적인 문제가 될 수 있다. 
 +===== MQ 등을 통한 비동기 처리 / event driven =====
   * 비동기 처리는 반응 속도를 높이고 전송 신뢰도를 높여주는 등 좋은 점이 있지만 단점들도 많으므로 확실히 이해해야 한다.   * 비동기 처리는 반응 속도를 높이고 전송 신뢰도를 높여주는 등 좋은 점이 있지만 단점들도 많으므로 확실히 이해해야 한다.
   * 메시지 전송이 실패하는 경우(클라이언트측 버그로 메시지를 먹어버리고 종료되는 경우, 프로듀서는 보냈다고 됐지만 네트워크 단절 등으로 안 가는 경우등이 발생함)에 대비히 철저하게 메시지 재전송이 가능하도록 솔루션을 만들어야 한다.   * 메시지 전송이 실패하는 경우(클라이언트측 버그로 메시지를 먹어버리고 종료되는 경우, 프로듀서는 보냈다고 됐지만 네트워크 단절 등으로 안 가는 경우등이 발생함)에 대비히 철저하게 메시지 재전송이 가능하도록 솔루션을 만들어야 한다.
줄 358: 줄 398:
   * **비동기 타이밍 문제도 심각하다.** 이 경우 비동기를 사용하면 안되는데 비동기를 사용한 경우일 수 있다. A -> B로 메시지를 보냈는데 B 가 메시지를 Consuming 하기 전에 A 혹은 C 등의 다른 서비스가 B가 메시지를 받았다는 가정하에 어떤 행위를 할 경우 오류가 발생한다. 매우 빈번히 발생하는 문제이다. 비동기를 사용하면 안 되거나 B가 메시지를 받았는지 확인할 수 있는 방안을 강구해야 한다.(JMX의 경우에는 Consume 확인 기능이 존재함)   * **비동기 타이밍 문제도 심각하다.** 이 경우 비동기를 사용하면 안되는데 비동기를 사용한 경우일 수 있다. A -> B로 메시지를 보냈는데 B 가 메시지를 Consuming 하기 전에 A 혹은 C 등의 다른 서비스가 B가 메시지를 받았다는 가정하에 어떤 행위를 할 경우 오류가 발생한다. 매우 빈번히 발생하는 문제이다. 비동기를 사용하면 안 되거나 B가 메시지를 받았는지 확인할 수 있는 방안을 강구해야 한다.(JMX의 경우에는 Consume 확인 기능이 존재함)
   * MQ Consumer 서버를 API 서버와 분리한다. MQ Consumer 가 DB 커넥션 쓰레드나, 애플리케이션 쓰레드를 점유해버릴 경우 API가 원인 모르게 느려지고 작동을 안하는 현상이 발생한다. 이 둘을 분리해서 장애시 원인이 MQ Consumer 인지, 특정 API 호출인지를 명확히 구분할 수 있다.   * MQ Consumer 서버를 API 서버와 분리한다. MQ Consumer 가 DB 커넥션 쓰레드나, 애플리케이션 쓰레드를 점유해버릴 경우 API가 원인 모르게 느려지고 작동을 안하는 현상이 발생한다. 이 둘을 분리해서 장애시 원인이 MQ Consumer 인지, 특정 API 호출인지를 명확히 구분할 수 있다.
 +  * Event body 에 모든 데이터를 심는 방법은 이벤트 전송 부담을 키운다. 이벤트에는 이벤트를 발생시킨 데이터의 종류(상품,사용자,..)와 해당 Primary Key, 그리고 이벤트 발생 요인(생성,수정,삭제)만 전달하고, 실제 데이터는 이벤트를 받은 시스템에서 API 등으로 호출하여 확인하게 한다. 그리고 상황에 따라 API로 봐야하는 데이터가 너무 크다면 그 중에 어떤 데이터가 변경됐는지(상품중에서 가격이 변경 됐는지 여부?)를 함께 담아 보낸다.
 ===== Single Page Application? ===== ===== Single Page Application? =====
   * 2020년 현재 대부분의 Front End Framework 이 SPA 기반이다. SPA를 사용하지 말라는 것은 유효하지 않다.   * 2020년 현재 대부분의 Front End Framework 이 SPA 기반이다. SPA를 사용하지 말라는 것은 유효하지 않다.
줄 372: 줄 413:
   * 배치 애플리케이션은 DB 커넥션을 최소로 맺으며 시작하고 필요에 따라 늘려가게 한다. API와는 달리 DB 커넥션 맺는 속도가 문제가 되지 않는다. 오히려 DB 커넥션을 과점유하면 여러 배치 애플리케이션이 동시에 돌 때 문제가 된다.   * 배치 애플리케이션은 DB 커넥션을 최소로 맺으며 시작하고 필요에 따라 늘려가게 한다. API와는 달리 DB 커넥션 맺는 속도가 문제가 되지 않는다. 오히려 DB 커넥션을 과점유하면 여러 배치 애플리케이션이 동시에 돌 때 문제가 된다.
   * DB를 읽을 때 reader/writer 를 올바로 읽는지 테스트를 잘 해야한다. batch 때문에 write node가 불필요한 부담을 동시에 받는일이 생기지 않게 한다.   * DB를 읽을 때 reader/writer 를 올바로 읽는지 테스트를 잘 해야한다. batch 때문에 write node가 불필요한 부담을 동시에 받는일이 생기지 않게 한다.
-  * Batch 가 올바로 시작됐는지, 혹은 올바로 종료됐는지를 모니터링 한다. **시작** 모니터링도 매우 중요할 수 있다. 시작조차 안되면 실패 알람조차도 안오기 때문에 아예 배치가 시작 안됐음을 모르고 며칠이 지나는 경우도 생길 수 있다. [[monitoring:grafana|Grafana]] 혹은 [[logging:kibana|Kibana]] 로 관련 모니터링이 가능하다.+  * Batch 가 올바로 시작됐는지, 혹은 올바로 종료됐는지를 모니터링 한다. **시작** 모니터링도 매우 중요할 수 있다. 시작조차 안되면 실패 알람조차도 안오기 때문에 아예 배치가 시작 안됐음을 모르고 며칠이 지나는 경우도 생길 수 있다. [[:batch|Batch / Scheduled / Cron Jobs]][[monitoring:grafana|Grafana]] 혹은 [[logging:kibana|Kibana]] 로 관련 모니터링이 가능하다.
   * 배치 실행 실간을 가정으로 만들지 말 것. 예를들어 앞선 배치가 1시간 걸릴테니 그에 관한 후속 배치는 2시간 이후 실행되게 했는데, 앞선 배치가 2시간이 넘게 걸리는 등의 현상 발생. Job 들간 의존 관계가 있을 경우 명확하게 의존 관계를 코드나 스케줄로 표현할 것.   * 배치 실행 실간을 가정으로 만들지 말 것. 예를들어 앞선 배치가 1시간 걸릴테니 그에 관한 후속 배치는 2시간 이후 실행되게 했는데, 앞선 배치가 2시간이 넘게 걸리는 등의 현상 발생. Job 들간 의존 관계가 있을 경우 명확하게 의존 관계를 코드나 스케줄로 표현할 것.
 ===== 기타 ===== ===== 기타 =====
줄 395: 줄 436:
   * Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다.   * Sprint 를 1주 단위 정도로 잘게 쪼개는 게 좋다. 목표를 명확히 가시화 한다.
   * 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다.   * 스프린트당 통합 테스트를 목표로 정하는게 좋다. 허접해도 통합해서 뭔가를 보는게 좋다.
 +
 +===== 외부 연결 정보와 인증서 관리 =====
 +  * 외부 API 연동 Key 혹은 HTTPS 인증서 등의 목록을 면밀히 관리해야 한다.
 +  * 특히 인증서 자체의 숫자가 늘어나서 관리가 안 될 수 있기 때문에 소스코드에 API Key 등을 두지 말고, 특정 저장소에서 일관되게 사용할 수 있게 해야 한다.
 +  * HTTPS SSL 인증서의 경우 만료일 관리 스케줄링을 하고, 관리 주체를 명확히 가져가도록 한다.
 +
  
 ===== 신규 개발 조직 구축시 먼저 할 일 ===== ===== 신규 개발 조직 구축시 먼저 할 일 =====
줄 412: 줄 459:
     * [[:docker|Docker]], [[aws:localstack|LocalStack]], [[devops:vagrant|Vagrant]] 등을 활용하여 개발자 전용 개발 환경을 만들어주고     * [[:docker|Docker]], [[aws:localstack|LocalStack]], [[devops:vagrant|Vagrant]] 등을 활용하여 개발자 전용 개발 환경을 만들어주고
     * [[java:database:migration:flyway|Flyway Java Database Migration]], [[java:database:migration:liquibase|Liquibase]], [[devops:terraform|Terraform]], [[devops:ansible|Ansible]]같은 Infrastructure As Code 툴로 운영환경을 Local 에서 복구하는 것이 자동화 돼 있어야 한다.     * [[java:database:migration:flyway|Flyway Java Database Migration]], [[java:database:migration:liquibase|Liquibase]], [[devops:terraform|Terraform]], [[devops:ansible|Ansible]]같은 Infrastructure As Code 툴로 운영환경을 Local 에서 복구하는 것이 자동화 돼 있어야 한다.
 +  * 개발 시간도 아니면서 개발 시간이 부족하게 만드는 요소들(배포 복잡도로 인한 배포 시간이 너무 오래걸린다던가, 매우 반복적인 통계 생성 요청이나 기타 운영 요청을 받아주느라 개발을 못한다던가)이 있는지 확인하고 개선하여 개발 시간을 확보하고 또한 이를 계속 반복 확인한다.
   * 기술 선언서를 만든다.   * 기술 선언서를 만든다.
     * 장애대응 방법과 태도(비난하지 말고 함께 문제를 해결한다던가)     * 장애대응 방법과 태도(비난하지 말고 함께 문제를 해결한다던가)
줄 424: 줄 472:
       * Test 방법       * Test 방법
     * 그리고 지속적인 회고로 기술 선언서를 개선한다.     * 그리고 지속적인 회고로 기술 선언서를 개선한다.
 +
 +
 +===== git push force 금지 =====
 +  * ''git rebase'' 하는 습관이 있는 개발자들로 인해 지속적인 conflict 가 발생한다.
 +  * conflict 발생은 그 자체로 개발 시간을 잡아먹는 요소이고
 +  * 무엇보다 문제는 conflict 해결중에 잘못 해결해서 소스코드가 사라지거나 꼬여버리는 문제로 버그가 양산된다.
 +  * 아예 rebase 를 금지시키고, rebase 시에 하게 되는 push force도 금지시킨다.
 +  * rebase 대신 리포지토리 fork 후 개발이 끝난 것을 **squash merge request** 방식으로 해소하도록 한다. 작업 완료 후 fork 한 리포지토리는 무조건 삭제하고 그걸 받았던 local 리포지토리도 삭제한다.
  
 ===== 지속적인 업그레이드 ===== ===== 지속적인 업그레이드 =====
web/신규서비스.1631058803.txt.gz · 마지막으로 수정됨: 2021/09/08 08:53 저자 kwon37xi