TroubleShoot.md

JPA

우선 학습욕구가 컸다. 객체와 테이블을 맴핑하므로 데이터 지향적이지 않은 객체지향적인 코드를 작성할 수 있다고 생각했다. 메서드로서 다루기 힘든 복잡한 쿼리는 QueryDSL, JPQL로서 해결 가능하다 생각했다.

MariaDB

학습해야할 기술 스택들이 많았기 때문에 크루들 모두가 알고있어 쉽게 다가갈수 있는 Mysql과 고민을 했다. 그 중 가장 큰 이유는 일단 무료이다. 그리고 Mysql보다 빠르고 가볍다. Mysql과 높은 호환성을 갖는다. MySQL에서 MariaDB로 바꾼 사례가 있다고 한다.

Spring Securtiy

우선 시큐리티를 적용하기 전에 Form 형식의 회원가입을 통해 Member를 생성하였다. 그러던 도중 우연히 Stored XSS 를 알게 되었고 여럿 팀들에게 새벽에 몰래 적용해 보았다. 결과는 놀랍겠도 쉽게 공격이 먹혔다. 이 사건을 계기로 단순히 Https만 적용한다고 사이트의 보안이 충분히 이루어지는 것이 아니구나 라고 생각했고 높으 보안 수준을 구축해둔 Spring Security를 이용해 대형 웹서비스사와 비슷한 수준의 보안을 유지하려고 사용했다. 실제 운영될 서비스이기 때문에 보안에 좀더 신경쓰고 싶었고 물론 인증 인가에대해 시큐리티를 안쓰고 구현할 수 있지만 이미 높은 보안 수준을 다 구축해둔 스프링 시큐리티를 사용한다면 좀더 안전한 서비스가 되지 않을까 생각했다.

OAuth2

보안의 수준을 알 수 없는 애플리케이션에서 일일이 계정을 만들어 사용하면 ID/PW관리가 어렵고 개인정보가 유출되면 연쇄적으로 피해가 심각해질 수 있기 때문에 보안의 수준이 어느정도 검증된 사이트(OAuth provider(ex. google, facebook))의 API를 이용해서 인가 위임해 접근 권한을 받는 방법(OAuth)이 보안상 좋기 때문이다. 스프링 시큐리티를 사용한이유와 비슷하다. OAuth를 사용하지 않으면 Password가 노출이 될 수 있다. 그래서 이미 보안수준이 검증된 대형 서비스에게 인가 프로세스를 대신 위임하는 OAuth를 이용해 보안상 안전한 인증인가를 구현하고 싶었다.

JWT

Session을 사용하면 서버 확장시 세션정보의 동기화 문제가 있습니다. 초반에 무중단 배포를 하고자 했기에 동시성문제를 해결하는데 비용이 크다고 생각했ㄷ. 또 세션은 서버에 저장하던가 DB에 저장하기 때문에 오버헤드가 생긴다고 생각했습니다. Restapi는 무상태성을 지향한다. 그렇기 떄문에 JWT의 stateless한 성격과 self-contained한 성질을 갖고 있고 서버 자체에서 토큰인증을 하기 때문에 두 단점을 보완 할수 있다고 생각했다.

jwt의 단점으로는 담으려는 data가 많아지면 토큰길이가 길어저 네트워크에 부하를 줄 수 있다는 것이고 무상태성이기때문에 한번 만들면 서버에서 제어가 불가능하다.

현재 토큰에 담는 데이터는 그리 크지 않기 떄문에 문제가 되지 않았고 expiretime을 걸어주었다.

왜 Nginx?

우선 apache와 nginx 에 있어서 고민을 하였습니다. apache는 MPM(multi process module)이다. Apache는 MPM아키텍처를 기반으로 클라이언트 요청을 처리하는 하고 있다.. MPM은 3가지 아키텍처를 근간으로 하고있다. 그렇기 때문에 프로세스 중심의 접근법이고 각 요청에대해 새로운 쓰레드가 필요하기 때문에 많은 요청이 대규모로 있다면 성능 측면에서 많은 이슈가 생길 수 있다.

Nginx는 프로세스 또는 쓰레드라는 개념을 사용하지 않고 이벤트 개념으로 접근한다. 단일 Nginx Worker가 동시에 수천개의 요청을 처리할 수 있다는 의미이다. Nginx의 Worker들이 이벤트가 트리거 될 때 마다 새로운 요청을 빠르게 선택할 수 있도록 내부 시스템을 사용하는 방식이다. 이벤트 중심의 접근 방식이고 하나의 쓰레드에서 여러개의 요청을 처리한다.

nginx는 효율성에 중점을 두어 동시웹 요청에 대한 처리를 효율적으로 할 수 있다는 것이다. 단점으로는 동적컨텐츠를 처리하기가 복잡해 프로세스의 효율을 잡아 먹는다. 하지만 저희는 프론트를 apk로 다루기 떄문에 nginx에서 동적 컨텐츠를 다루지 않기 떄문에 아파치보다 nginx를 사용하는것이 훨씬 효울적이라고 생각했다.

우리는 nginx 를 프록시 서버로 사용한다.

PreFork MPM (다중 프로세스)

• Client 요청에 대해 apache 자식 프로세스를 생성하여 처리.
• 요청이 많을 경우 Process 를 생성하여 처리합니다. 이 방식은 Apache 설치시 default 로 설정
• 하나의 자식프로세스당 하나의 스레드를 갖음 (최대 1024개)
• 스레드간 메모리 공유를 하지 않습니다. 이 방식은 독립적이기에 안정적인 반면, 메모리 소모가 크다는 단점이 있다

Worker MPM (멀티 프로세스-스레드)

• Prefork 보다 메모리 사용량이 적고 동시접속자가 많은 사이트에 적합합니다. 각 프로세스의 스레드를 생성해 처리하는 구조
• 스레드 간의 메모리 공유가 가능
• 프로세스 당 최대 64개의 스레드처리가 가능하며, 각 스레드는 하나의 연결만을 부여

Event-Driven 방식

• 작업을 하다 I/O, socket read/write 등 CPU가 관여하지 않는 작업이 시작되면 기다리지 않고 바로 다른 작업을 수행

• 참고

• 참고

MongoDB

RDB 는 정형화된 데이터를 다뤄 구조를 빠르게 확장해나갈 수 있는 장점인 DB인데 메시지와 같은 비정형데이터를 다루기엔 맞지 않다고 생각한다. 그래서 Nosql을 사용했다. 또 그 중 MongoDB를 사용한 가장 큰 이유는 다른 Nosql 보다 접근성이 쉬웠다. 문서화가 스키마가 없을 뿐더러 스키마가 없으니 필요할 때마다 필드를 쉽게 변형시킬 수 있다. 또 범용 데이터베이스라 CRUD의 작접외에도 다양한 기능을 제공한다.

이정도의 이유만으로 충분히 쓸 근거가 된다 생각한다.