BackEnd/Server

문제프로젝트 전체를 Spring Cloud를 이용하여 기본 뼈대를 MSA구조로 구축했다. 하지만 여기서 문제가 생겼다. public class App extends BaseTimeEntity { //... @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "user_id", nullable = false) private User user;} 기존에 설계했던 App Entity 는 User Entity와 연관관계 매핑으로 해결하려고 설계했다. 하지만, 지금 프로젝트 구성상 app-service와 user-service를 나누어 두었다. 그래서 app-service에선 user를 참조할 수 없는 것이다. 이에 관련해서 몇 가지 글들을..

https://nginxstore.com/blog/nginx/nginx-%EC%84%B1%EB%8A%A5-%ED%99%95%EC%9E%A5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%84%A4%EA%B3%84-%EB%B0%A9%EB%B2%95/ NGINX는 Master Process아래 여러 worker와 helper가 있다. # ps -ef --forest | grep nginx root 32475 1 0 13:36 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 32476 32475 0 13:36 ? 00:00:00 _ nginx: worker process nginx 32477 32475 0..

ngnix SSL 인증 키가 있다면 다음과 같이 설정하자!! 80포트(HTTP)로 들어올 시 443(HTTPS)로 Redirect하게 설정했다. 추가로, .html 을 rewrite까지 설정했다. /etc/nginx/nginx.conf # For more information on configuration, see: # * Official English Documentation: http://nginx.org/en/docs/ # * Official Russian Documentation: http://nginx.org/ru/docs/ user ec2-user; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /run/nginx...

시세 정보 시세 정보는 거래소로부터 실시간으로 정보를 받는다. 아무래도 시세 정보를 다루려면 실시간으로 다루어야 하기 때문에, 낮은 지연시간, 빠른 장애 복구 를 우선시 해야한다. 토스의 시세정보 처리 과정을 살펴보겠다. 거래소로부터 받아오는 시세 정보를 UDP 멀티캐스트 그룹에 접속해서 읽어온다. 빠른 통신을 위해서 UDP를 사용하는 것 같다. 이 때, 헤더에 수신 시각을 포함하여 처리부에서 총 처리 시간을 측정한다. 처리부가 Redis에 저장하고, REST API를 제공한다. 처리부가 비지니스 로직이 가장 많기 때문에 장애 발생 확률이 가장 높다. 따라서, 처리부를 여러개로 늘리는 방법을 선택했다. 평소에는 한 처리부(처리부 A)를 가동하다가, 장애가 발생하면 빠르게 처리부 B로 전환할 수 있다. Z..

최근에는 많은 기업과 조직이 MSA형식으로 애플리케이션을 개발한다. 하지만 MSA 형식으로 개발한다면, 여러 분산된 서버들이 어떻게 동작하는지 한 눈에 살펴보기 어렵고, 전체 구조를 추적하기 어렵다. Pinpoint : 분산추적 네이버에서 만든 오픈소스 APM(애플리케이션 성능 모니터링)이다. 애플리케이션을 위한 모니터링 도구로, 서버의 트래픽 증가 등으로 인한 성능 감소, 병목 현상을 해결하기 위해 서버를 추적하여 확인할 수 있다. 특히, 분산 추적에 용이한 툴이다. 저장소는 HBase를 사용한다. Hadoop의 HDFS위에 만들어진 분산 컬럼 기반의 비관계형 데이터베이스이다. HBase의 Rowkey를 맞게 설계하면 데이터를 효율적으로 가져올 수 있다. ex) 애플리케이션 이름 + 시간의 조합 Pin..

CORS란? Cross Origin Resource Sharing 요청이 Same Origin, 즉 동일한 출처가 아닌 공유에 대한 접근을 막는 보안 정책이다. 요청을 한 도메인의 주소, 포트번호, 프로토콜이 모두 같아야지 해당 응답을 반응하는 정책이다. 예를 들어, API서버의 도메인이 server.com이고, 요청한는 사이트의 도메인이 page.com이라면 요청을 하는 page.com의 도메인이 server.com의 도메인과 다르기 때문에 응답 요청을 막는 이유이다. CORS 정책의 이유 만약, 다른 도메인의 응답을 처리할 수 있게 된다면, 다른 사이트를 접속했을 때, 해당 브라우저에서 다른 도메인의 요청을 받아 사용자의 인증 토큰을 받을 수 있기 때문이다. 예를 들어, 사용자가 example.com..