- 작성자가 질문을 받을 수 있는 게시판입니다.
- AMA는 Ask me anything (무엇이든 물어보세요)라는 뜻입니다.
| Date | 21/05/15 10:19:48 |
| Name | [익명] |
| Subject | 3년차 스타트업 서버개발자입니다. |
|
아무거나 물어보시면 답해드립니다. 경력이 길지 않아 부정확할 수 있어도 최대한 아는 선에서 답변해드리겠습니다. 이번주가 온콜이라 심심하네요. 0
|
|
Java Spring boot vs Node.js Express or Nest.js vs Python django
대용량 트래픽에 대비하는 아키텍쳐 전략과 구성은 어떻게 하시는지, 분산처리 시 생길 수 있는 문제들은 어떤식으로 해결하시는지 궁금합니다
대용량 트래픽에 대비하는 아키텍쳐 전략과 구성은 어떻게 하시는지, 분산처리 시 생길 수 있는 문제들은 어떤식으로 해결하시는지 궁금합니다
저희 팀의 아키텍쳐 기준으로 이야기해보겠습니다. 제가 설계한게 아니다 보니 틀린 해설도 섞여있을지도 모릅니다;;;
SPOF인 DB는 scalable하고 안정적인 AWS Aurora를 사용하고, 최대한 DB 부하가 가지 않도록 특정 시간 이상 걸리는 쿼리를 시스템적으로 막아두었습니다. 해당 타임아웃에 걸리는 쿼리는 분할해서 조회하는 식으로 변경해두고 있습니다. 그리고 전반적인 부하를 줄이기 위해 DB 콜이 자주 일어나는 구간에는 Cache를 적극적으로 쓰고 있습니다.
각 MSA는 로드 밸런서나 MQ를 사용해 여러 노드를 사... 더 보기
SPOF인 DB는 scalable하고 안정적인 AWS Aurora를 사용하고, 최대한 DB 부하가 가지 않도록 특정 시간 이상 걸리는 쿼리를 시스템적으로 막아두었습니다. 해당 타임아웃에 걸리는 쿼리는 분할해서 조회하는 식으로 변경해두고 있습니다. 그리고 전반적인 부하를 줄이기 위해 DB 콜이 자주 일어나는 구간에는 Cache를 적극적으로 쓰고 있습니다.
각 MSA는 로드 밸런서나 MQ를 사용해 여러 노드를 사... 더 보기
저희 팀의 아키텍쳐 기준으로 이야기해보겠습니다. 제가 설계한게 아니다 보니 틀린 해설도 섞여있을지도 모릅니다;;;
SPOF인 DB는 scalable하고 안정적인 AWS Aurora를 사용하고, 최대한 DB 부하가 가지 않도록 특정 시간 이상 걸리는 쿼리를 시스템적으로 막아두었습니다. 해당 타임아웃에 걸리는 쿼리는 분할해서 조회하는 식으로 변경해두고 있습니다. 그리고 전반적인 부하를 줄이기 위해 DB 콜이 자주 일어나는 구간에는 Cache를 적극적으로 쓰고 있습니다.
각 MSA는 로드 밸런서나 MQ를 사용해 여러 노드를 사용하고 있습니다. 트래픽 대응을 위해 auto scale out이 적용되어 있고, 고가용성을 확보하기 위해 Cache나 MQ도 Replication를 사용합니다. 이정도 구성이면 일반적인 사용 상황에서는 문제가 없습니다. 다만, hot loading 되는 시간 문제가 있기에 급작스러운 Usage Peak에 어떻게 빠르게 scale out 하는가가 고민거리중 하나입니다.
MSA간 통신은 MQ를 사용하고 있습니다. MQ 자체가 어느정도 안정성을 가지고 있어서 중복처리는 일어나지 않고, 처리 실패시가 문제가 되겠죠. 이 부분은 오류처리를 해서 모니터링을 하고 있습니다. 다행히 오류율도 충분히 낮고, 비즈니스가 강한 수준의 정합성을 요하지는 않는 상황이라 별도의 처리가 필요하지는 않습니다.
제가 개인적으로 아키텍쳐에 대해 공부할때는 데이터 중심 애플리케이션 설계(Designing Data-Intensive Applications) 이 책에서 많이 배웠던거 같습니다.
SPOF인 DB는 scalable하고 안정적인 AWS Aurora를 사용하고, 최대한 DB 부하가 가지 않도록 특정 시간 이상 걸리는 쿼리를 시스템적으로 막아두었습니다. 해당 타임아웃에 걸리는 쿼리는 분할해서 조회하는 식으로 변경해두고 있습니다. 그리고 전반적인 부하를 줄이기 위해 DB 콜이 자주 일어나는 구간에는 Cache를 적극적으로 쓰고 있습니다.
각 MSA는 로드 밸런서나 MQ를 사용해 여러 노드를 사용하고 있습니다. 트래픽 대응을 위해 auto scale out이 적용되어 있고, 고가용성을 확보하기 위해 Cache나 MQ도 Replication를 사용합니다. 이정도 구성이면 일반적인 사용 상황에서는 문제가 없습니다. 다만, hot loading 되는 시간 문제가 있기에 급작스러운 Usage Peak에 어떻게 빠르게 scale out 하는가가 고민거리중 하나입니다.
MSA간 통신은 MQ를 사용하고 있습니다. MQ 자체가 어느정도 안정성을 가지고 있어서 중복처리는 일어나지 않고, 처리 실패시가 문제가 되겠죠. 이 부분은 오류처리를 해서 모니터링을 하고 있습니다. 다행히 오류율도 충분히 낮고, 비즈니스가 강한 수준의 정합성을 요하지는 않는 상황이라 별도의 처리가 필요하지는 않습니다.
제가 개인적으로 아키텍쳐에 대해 공부할때는 데이터 중심 애플리케이션 설계(Designing Data-Intensive Applications) 이 책에서 많이 배웠던거 같습니다.
| 목록 |
|
