문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
web:신규서비스 [2022/05/24 13:33] kwon37xi [MQ 등을 통한 비동기 처리 / event driven] |
web:신규서비스 [2022/07/27 08:47] kwon37xi |
||
---|---|---|---|
줄 19: | 줄 19: | ||
===== 신기술 선택 ===== | ===== 신기술 선택 ===== | ||
* 다음과 같은 용어를 확인해볼것. | * 다음과 같은 용어를 확인해볼것. | ||
- | * '' | + | * '' |
===== 용어 통일 ===== | ===== 용어 통일 ===== | ||
줄 67: | 줄 67: | ||
* MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다. | * MSA 로 갈 때는 팀간에 공통 라이브러리를 만들기 보다는 **공통의 규약**을 정립하는 것이 나아 보인다. 프로젝트간 의존성이 묶이는 것은 피해야 각 팀별로 다양한 언어, 기타 라이브러리 의존성 업그레이드 등이 가능해 진다. | ||
+ | ===== Team 이 아닌 Project 단위 구성 ===== | ||
+ | * APM, Wiki 공간, 각종 로깅 시스템 구분, Resource Tagging 등을 Team 기준으로 하지 말고 Project 기준으로 해야한다. | ||
+ | * Team 은 지속적으로 바뀌지만 Project 는 프로젝트 자체가 폐기 될 때까지 잘 바뀌지 않는다. | ||
+ | * 가급적 애플리케이션 관련 모든 정보 조직과 행위의 기준을 Project 를 단위로 가져가고 Project 에 하위 정보로 Team 을 넣는 방식을 취한다. | ||
+ | * 이렇게 하지 않고 팀을 기준으로 하면 얼마 안가 고아가 된 정보들이 양산되게 된다. | ||
===== API Gateway ===== | ===== API Gateway ===== | ||
* **내부 애플리케이션 API를 외부(브라우저, | * **내부 애플리케이션 API를 외부(브라우저, | ||
줄 141: | 줄 146: | ||
* 초반부터 지나친 확장성 대비는 오히려 악영향을 줄 수 있는 것은 사실이지만, | * 초반부터 지나친 확장성 대비는 오히려 악영향을 줄 수 있는 것은 사실이지만, | ||
* 현재(2013) 상황으로 봤을 때 처음부터 NoSQL을 도입하는 것이 RDBMS를 도입하는 것과 비교해서 특별히 더 어렵지도 않게 되었다. | * 현재(2013) 상황으로 봤을 때 처음부터 NoSQL을 도입하는 것이 RDBMS를 도입하는 것과 비교해서 특별히 더 어렵지도 않게 되었다. | ||
- | * RDBMS 샤딩은 어려운 것은 사실이지만 NoSQL 도입은 초반 부터 고려해도 괜찮아 보인다. | + | * RDBMS 샤딩은 어려운 것은 사실이지만 NoSQL 도입은 초반 부터 고려해도 괜찮아 보인다. 혹은 샤딩을 안하더라도 지수적 증가 데이터의 PK 혹은 Unique Key 설계시 샤딩 가능하게 설계하는 것도 좋아보인다. |
* RDBMS와 유사하게 MQ, Cache 등도 도메인별로 분할하라. 처음부터 분할하면 서버 대수가 너무 많이 늘어나게 되는데, 그 경우에는 최소한 Major 도메인에 대해서만이라도 분할하거나 혹은 물리 장비는 하나로 묶더라도 논리적으로는 분할해 두어 추후 Scale Up이 필요할 때 물리적 분할로 인한 코드 변경이 필요없게 해주는게 좋다. | * RDBMS와 유사하게 MQ, Cache 등도 도메인별로 분할하라. 처음부터 분할하면 서버 대수가 너무 많이 늘어나게 되는데, 그 경우에는 최소한 Major 도메인에 대해서만이라도 분할하거나 혹은 물리 장비는 하나로 묶더라도 논리적으로는 분할해 두어 추후 Scale Up이 필요할 때 물리적 분할로 인한 코드 변경이 필요없게 해주는게 좋다. | ||
* Sharding은 꼭 필요한 경우에만 어쩔 수 없을 때 하고, 선형적 증가 데이터라면 되도록 기능별 DB 분할을 고려하는 것이 낫다. | * Sharding은 꼭 필요한 경우에만 어쩔 수 없을 때 하고, 선형적 증가 데이터라면 되도록 기능별 DB 분할을 고려하는 것이 낫다. | ||
줄 208: | 줄 213: | ||
* 기본적으로 Slow Query 모니터링을 걸고 알람을 한다. slow query 시간에 따라 알람 레벨을 주는 것도 좋을 것 같다. | * 기본적으로 Slow Query 모니터링을 걸고 알람을 한다. slow query 시간에 따라 알람 레벨을 주는 것도 좋을 것 같다. | ||
* '' | * '' | ||
+ | * **즉 모든 데이터 조회는 상방이 무제한 커질 수 없게 제한을 걸어야한다. 그래야 서비스의 증가에 따라 장애가 나는 일이 없어진다.** | ||
===== 사용자에게 전달하는 메시징 솔루션 ===== | ===== 사용자에게 전달하는 메시징 솔루션 ===== | ||
* Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. | * Email, SMS, Mobile Push 등의 Messaging은 초반에는 적을 수 있으나 서비스의 증가에 따라 시스템의 부하 요소가 될 수 있다. |