입꼬리 올리고 사는 개발자

Vue.js

로그인을 성공할 시 자기 프로필 페이지로 자동으로 redirect 되도록 라우터를 push 해주었다.

그런데 어느 순간 갑자기 redirect가 되지 않고 로그인 버튼이 무한으로 로딩되는 버그가 발생하였다.

오늘 새벽을 앗아간 이 버그의 해결 과정을 알아보자

내 원래 코드는 이러하다. 인증이 필요한 페이지는 로그인 여부를 확인해야하는데 이 로그인 여부를 jwtToken이 담긴 쿠키가 있는지 여부로 확인해주었다. 

여기서 문제는 이 쿠키값이 분명히 존재하는 것을 개발자모드에서 확인을 했음에도 불구하고 계속 undefined 값을 받아와서 생기는 문제였다.

처음에는 쿠키 인식 처리 과정이 비동기로 이루어져서 너무 빨리 읽어오나? 싶었지만 그게 아니었다!!!

문제는 바로 오후 쯤 서버코드에 넣어주었던 쿠키의 httpOnly 옵션 때문이었다.

어차피 토큰이 담긴 쿠키는 서버에 보내주는 용도로만 쓰이기 때문에 읽을 필요가 없다 생각하고 httpOnly 옵션을 true로 바꾸어줬는데 이 때문에 쿠키 인식을 아예 못하는 상황이었던 것이다.

해결책으로 userinfo 라는 유저 정보가 담긴 쿠키를 기준으로 로그인 여부를 판단하도록 코드를 수정해주었더니 제대로 redirect가 된 것을 확인할 수 있었다.

이건 결국 프론트엔드에 미숙해서의 문제가 아닌 그냥 쿠키에 대한 이해부족이라 할 말이 없군 ㅠㅠ

CS 공부

GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.

GET 메서드는 데이터를 요청할 때, POST 메서드는 데이터를 전송할 때 주로 사용된다.

GET 메서드

사용자가 브라우저에 URL을 입력하거나 링크를 클릭한다 → 브라우저가 URL에 포함된 쿼리 스트링들을 포함한 HTTP Request를 서버에 보낸다 → 서버에게서 Response를 받는다. → 획득한 자원을 브라우저가 활용한다.

특징

1. URL의 쿼리 문자열에 데이터가 그대로 노출되어 보안에 취약하다.
2. URL 길이에 제한이 있어 대용량 데이터 전송에 적합하지 않다 → 읽기에 적합
3. 동일한 요청 시 캐싱한 응답을 반환할 수 있다.

POST 메서드

사용자가 폼에 데이터를 입력한다 → 브라우저가 입력받은 데이터를 HTTP body에 담아 서버에 전송한다 → 서버가 요청을 처리한다 → 획득한 자원이 있다면 브라우저가 활용한다.

특징

1. HTTP body에 직접 담아 전송하므로 상대적으로 보안이 강화된다.
2. HTTP body는 제한이 없어 대용량 데이터 전송에 적합하다 → 쓰기에 적합
3. POST 요청은 캐싱이 불가능하다.

두 메서드 모두 클라이언트와 서버의 데이터 교환에 활용되지만 데이터의 위치와 사용 목적에 차이가 있다.

OSI 7계층에 대해 아는대로 설명해주세요.

Application Layer: 사용자와 직접 상호작용하는 어플리케이션이 존재하는 레이어

어플리케이션과 직접 관련되며 HTTP, SMTP 등이 여기에 속한다.

Presentation Layer: 데이터의 형식(format)을 정의하는 레이어

암호화, 압축 등이 이 계층에서 일어남

Session Layer: 다른 서버와 통신을 하기 위한 세션을 만드는 레이어

통신 세션을 설정, 유지, 종료하는 역할을 하며 데이터 동기화를 담당

Transport Layer: 최종 수신 프로세스로 데이터의 전송을 담당하는 레이어

에러 복구, 흐름 제어, 중복 검사 등을 실시하며 TCP, UDP 등이 이 계층에 속함. 이 계층의 식별자는 포트 번호

Network Layer: 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 레이어

라우팅, 패킷 전달, 경로 선택등을 다루며 가장 효율적인 경로를 선택해 패킷을 전달함

이 계층의 식별자는 IP 주소이며 IP, 인터넷, 라우터 등이 이 계층에 속함

DataLink Layer: 데이터의 물리적인 전송과 에러 검출, 흐름 제어를 담당하는 레이어

프레임 단위로 데이터를 전송하고 transport layer의 물리 버전이라고 할 수 있음. 이 계층의 식별자는 MAC Address이며 이더넷(LAN에서 사용되는 네트워크 프로토콜) 이 계층에 속함

Physical Layer: 데이터를 전기 신호로 변환해주는 레이어

물리적 매체를 이용하여 비트를 전송하고 전기 신호와 광 신호를 다룸

느낀 점

프론트에 시간 많이 갈어넣고 있는데 기본없이 하려니까 넘 힘들구마..

프론트 서버는 또 언제 띄우냐...

CS 공부

TCP/UDP

TCP와 UDP는 네트워크 계층 중 전송 계층에 사용되는 프로토콜이며,

TCP와 UDP의 가장 큰 차이는 TCP는 신뢰성에 UDP는 속도 측면에 장점이 있다는 것이다.

TCP

먼저 TCP는 연결형 프로토콜이다. 따라서 신뢰성에 중점을 두었다.

1. 연결형 서비스로 가상 회선 방식을 제공
2. 흐름 제어 - 데이터 처리 속도를 조절하여 수신 측의 오버플로우를 방지
3. 혼잡 제어 - 네트워크 내 패킷 수가 과도하지 않도록 조절
4. 높은 신뢰성
5. full-duplex - 전송이 양방향으로 일어날 수 있다. point-to-point - 각 연결이 정확히 2개의 종단점을 가지고 있음.

TCP의 통신 방식은 송신-수신 측이 연결되었음을 확인하기 위해 연결을 설정할 때 3-way handshaking을 한다. 송신측이 수신 측에게 연결 확인을 위해 무작위 값 SYN을 하나 보내는 것이 첫번째, 수신 측이 잘 받았다는 의미로 SYN와 ACK 값을 보내는 것이 2번째, 마지막으로 송신 측도 잘 받았다는 의미로 ACK를 다시 보냄으로서 연결 설정이 완료된다. 연결을 해제할 때는 4-hand로 진행된다.

이 같은 과정을 통해 가상 회선 방식, 즉 발신지와 수신지를 연결하는 논리적 경로를 배정하는 절차를 거친다.

이처럼 수신 여부를 확인하는 절차 때문에 연결 자체도 시간이 오래 걸리고, 전송 순서 보장 등의 검증도 해주기 때문에 시간은 오래 걸리지만 그만큼 높은 신뢰성을 보장한다.

UDP

UDP는 비연결형 프로토콜이고 속도에 중점을 두었다.

1. 데이터그램 방식을 사용 - 데이터의 전송 경로가 다르고 그로 인해 순서가 보장되지 않는다.
2. 데이터 수신 여부를 확인하지 않음 - no hand shaking
3. 2번의 이유와 흐름 제어를 따로 하지 않기 때문에 신뢰성이 낮다.
4. TCP보다 검증 과정이 적기 때문에 속도가 빠르다
5. 1:1 1:N N:N 통신이 가능하다.

http, https 차이점

HTTP 는 클라이언트와 서버 간의 통신을 위한 규약으로 네트워크 통신을 작동하게 하는 기본 기술이다.

HTTPS는 HTTP에 secure를 더한 것으로 브라우저와 서버가 데이터를 전송하기 전 암호화된 연결을 설정한다.

HTTP는 OSI 7계층의 어플리케이션 계층 프로토콜이며 Request인지 Response인지에 따라 첫 줄에 startline 혹은 status line, 또한 header, body 이렇게 3가지 부분으로 이루어져 있다.

이 3가지 형태에 일치하게 데이터를 송수신하자 하는 게 HTTP 규약이다.

그러나 HTTP는 암호화되지 않은 데이터를 보내기 때문에 제3자가 가로챌 수 있는 위험성이 있다. 이 위험을 방지하기 위해 보안 계층이 추가된 HTTPS 프로토콜이 등장하였다.

HTTPS를 적용한 웹 사이트를 만들기 위해서는 독립된 인증 기관에서 발부하는 SSL/TLS 인증서를 획득해야한다. HTTPS가 적용된 웹사이트는 신뢰를 구축하기 위해 데이터 교환 전 브라우저와 인증서를 교환공유한다.

SSL 인증서는 암호화 정보도 포함하므로 서버와 웹 브라우저는 암호화된 데이터나 스크램블된 데이터를 교환할 수 있다.

HTTPS를 선택하면 좋은 이유

1. 보안 - HTTP는 텍스트 기반이기 때문에 가로채기 쉽다.
2. 권위 - 검색 엔진은 HTTPS 기반 웹사이트의 순위를 더 높게 지정한다. 고객도 이를 더 선호한다.
3. 성능도 더 좋다.

CS 공부

브라우저의 작동 방식

브라우저의 주요 기능은 URI 주소로 서버에 자원을 요청하고 그 자원을 브라우저에 표시하는 것이다.

사용자 인터페이스 - 브라우저 엔진, 자료 저장소 - 렌더링 엔진 - 통신, 자바스크립트 해석기, UI 백엔드

로 이루어져 있다.

서버에 요청을 보내는 과정

브라우저 주소창에 url을 입력하면 브라우저는 js 명령어와 http 포맷에 따라 HTTP Request 메시지를 생성한다. 그 후 DNS 서버에 url에 해당하는 ip 주소를 조회한 후 tcp 프로토콜을 통한 메시지 전송을 OS에게 의뢰한다.

서버에서 요청을 받은 후

서버에게서 HTTP Response 메시지를 받은 후 브라우저는 이를 렌더링하여 사용자에게 출력해준다.

이때 렌더링 엔진의 HTML 파서와 CSS 파서에 의해 DOM 트리, CSSOM 트리로 파싱되고 다시 렌터 트리로 결합되는 구조를 가진다. 이 렌더 트리가 완성되면 객체들의 위치와 크기를 결정해 레이아웃을 만들어준 뒤 UI 백엔드가 동작하며 렌더 트리를 화면에 나타낸다.

자바스크립트는 렌더링 엔진이 아닌 자바스크립트 엔진이 처리한다.

HTML 태그가 <script> 태그를 만나면 DOM 생성 프로세스를 잠시 중단하고 js 엔진으로 권한을 넘긴다. 그러나 브라우저는 동기적으로 작동하기 때문에 js 엔진이 완성되지 않은 DOM을 조작하면 에러가 난다. 그래서 body 태그 아래 script 태그들이 존재하는 것이다.

쿠키와 세션

쿠키

쿠키는 HTTP의 특성인 stateless 를 보완하기 위해 나타난 개념이다.

client와 server는 요청을 주고 받으면 서로를 기억할 방법이 없다.

그렇다면 로그인 후에는 이 요청을 보낸 사용자가 누구인지 알아야할 필요성이 있는데 이때 가장 간단한 아이디어는 모든 request에 사용자 정보를 넣어준 채 요청을 하면 된다.

그러나 이 경우도 브라우저를 종료하고 다시 키면 해당 정보가 사라지기 때문에 쿠키가 도입되었다.

유저가 로그인 request 를 보내면 서버는 쿠키에 유저 정보를 담아 response 를 보내준다.

브라우저는 해당 정보를 저장해두었다가 같은 서버에 요청을 보낼 때 함께 전송한다.

이를 통해 쿠키는 사용자의 상태나 세션을 유지하는데 도움을 주고 사용자 경험을 개선하기 위해서도 사용된다.

그러나 이 쿠키는 클라이언트 사이드에서 저장하고 관리하기 때문에 보안에 위협이 있다.

세션

쿠키의 보안적인 단점으로 인해 나온 것이 세션이다.

서버에서 인증 정보를 보관하며 로그인 연결을 유지하는 방법이 session이다.

유저가 로그인 요청을 보내면 서버에서는 임의의 sessionId를 생성해 session 저장소에 유저 - sessionId 를 매칭하여 저장한다.

이후 response 객체에 이 sessionId를 담은 쿠키를 유저에게 전달한다.

이후 쿠키를 담은 요청이 올 때마다 sessionId로 session 저장소를 조회해 어떤 유저가 요청을 보냈는지 확인한다.

세션은 유저에 대한 정보가 클라이언트에게는 하나도 없다는 점에서 세션 개념을 도입하지 않은 쿠키 통신보다 안전하다.

프로젝트 피드백

Restful한 API를 짜자

원하는 자원(도메인)을 복수형으로 명확히 표기하고.

이 API 요청이 들어올 상황의 플로우를 명확히 이해하고(프론트엔드에서 어떻게 작동할지) 써야한다.

라이브러리나 프레임워크의 사용 버전과 사용 이유를 명확히 하자.

납득이 간다면 추가된 하나의 기능만 기억해도 괜찮으나 웬만하면 알고 쓰자. 롬복, 타임리프 까지는 알 필요는 없다.

3.2.1 이라 하면 앞의 3.2 까지의 변동사항은 알고 있으면 좋다.

CS 공부

RDBMS 정규화

정규화란 테이블 간의 중복된 데이터를 허용하지 않는 것이다.

이 과정을 통해 삽입, 변경, 삭제 이상을 예방하여 데이터의 무결성을 지키고 DB의 저장 용량을 줄이는 효과가 있다.

비공식적으로는 제 3정규화까지 진행된 데이터베이스를 정규화되었다라고 한다.

제 1 정규화는 컬럼이 하나의 값을 가지도록 테이블을 분해하는 것이다.

예를 들어 내가 주문한 음식이 피자, 치킨 이라면 (나, 피자&치킨)이 아니고 (나, 피자), (나, 치킨) 이렇게 두개의 레코드로 분리하는 것이다.

제 2 정규화란 제 1 정규화가 완료된 테이블을 대상으로 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다.

어떤 속성 A를 알면 속성 B도 정해지는 관계를 종속성 관계라고 하며 A를 B의 결정자라고 부른다.

완전 함수 종속은 기본 키의 부분집합이 결정자가 되어서는 안됨을 의미한다.

예를 들어 (학번, 강의 이름)을 복합 키로 강의실, 성적 컬럼이 존재한다고 생각해보자.

성적은 (학번, 강의 이름) 이 함께 있어야 결정이 되지만, 강의실은 강의 이름 하나만으로도 결정이 되는 값이다. 이 경우 기본 키의 부분집합이 성적 속성의 결정자 이므로 (학번, 강의 이름) → 성적, 강의 이름→ 강의실 로 테이블을 분해해준다.

제 3 정규화란 제 2 정규화가 완료된 테이블을 대상으로 이행적 종속이 없도록 테이블을 분해하는 것이다. 이행적 종속이란 A가 B의 결정자이고 B가 C의 결정자일 때 A가 C의 결정자가 되는 것을 의미한다.

학번 → 강의 이름 → 수강료 가 한 테이블에 있다면 학번 → 강의 이름, 강의 이름 → 수강료 테이블로 분리해준다.

이렇게 되면 학번에 따른 강의 이름이 변경되었을 때, 강의와 다른 수강료가 기록되는 상황을 예방할 수 있다.

BCNF 정규화

제 3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것이다.

(학생번호, 강좌 이름) 기본키가 교수 이름을 결정하고 있다고 하자.

그러나 교수 이름이 강좌 이름의 결정자이지만 후보 키가 아니기 때문에 학생번호 → 교수, 교수 → 강좌 이름으로 분리해준다.

Primary Key, Foreign Key에 대해 설명해주세요.

기본 키

기본 키란 해당 레코드를 판별할 때 기준이 되는 아주 중요한 키로 후보키의 성질인 유일성과 최소성을 가진다. 값이 변동이 적은 것이 좋고, Null 값이 포함될 수 있는 후보키는 부적절하다.

하나의 테이블에는 하나의 기본 키만이 존재한다.

외래 키

외래 키란 테이블 간의 관계를 나타내며 다른 테이블의 기본 키를 참조해 외래 키로 사용한다.

외래 키의 가장 큰 장점은 데이터 무결성을 보장해준다는 점이다.

외래 키를 가진 테이블이 참조하는 테이블의 기본 키가 변경되었을 때 자동으로 외래 키도 변경되게 하여 무결성을 보장한다.

슈퍼 키

유일성을 만족하고 최소성을 만족하지 않는 키이다.

슈퍼 키가 얼마나 길이가 길던 간에 이 슈퍼 키가 하나의 레코드만을 보장한다면 슈퍼 키라고 부를 수 있다.

예를 들어 학생 번호가 테이블 내에서 유일한 값임을 보장한다고 하자.

이러면 학생 번호는 단독으로도 슈퍼 키인데, (학생번호, 학생 이름, 학생 학점, 학생 머리 스타일) 이라는 복합 키도 학생 번호 덕분에 유일한 레코드를 보장해주기 때문에 이 복합 키 또한 슈퍼 키이다.

후보 키

후보 키는 유일성을 만족하고 최소성 또한 만족하는 키이다.

위 슈퍼 키 예시에서 나머지 부분을 빼고 학생 번호만 주어진다면 이것이 후보 키이다.

복합 키

두 개 이상의 컬럼을 묶어서 기본 키로 설정하는 것

대체 키

기본 키를 제외한 나머지 후보 키들을 말한다.

느낀 점

진짜 팀장급 실력 아닌데 리더를 맡게 되어서 힘들지만 오히려 기회다 화이팅하자.

ERD 설계

SQL에서의 cardinality란

특정 컬럼에 나타나는 데이터의 고유값 수.

예를 들어 수백개의 row 중 성별 컬럼에는 남, 여 값밖에 없을 때 성별 column의 cardinality는 2

자연키(natural key) vs 대체키(surrogate key)

기본키: 테이블에서 레코드를 유일하게 식별할 수 있는 가장 적합한 후보 키

자연키: 테이블의 컬럼 중 의미를 가지고 있는 후보 키

대체키: 컬럼 가운데 유일하게 식별하기 적합한 후보 키가 존재하지 않을 때 임의의 식별번호를 부여함.

만약 자연키가 숫자로 이루어져 있다면 굳이 대체키를 쓸 이유는 없다.

데이터베이스 테이블의 대다수는 작성되는 것보다 읽히는 경우가 더 많다!!!

복합키의 장단점(vs 대체키)

장점

고유성 보장 - 중복값 없앨 수 있다. - 어플리케이션 단에서 중복데이터인지 검증을 한다면 성능 차이는 별로 없지만 데이터 고유성을 테이블 레벨에서 보장해주는 것.

쿼리 성능 향상 - PK 인덱스를 이용해 조회가 더 빨라진다(근데 복합키 너무 길어지면 오히려 손해)

정규화를 줄일 수 있음 - 추후 더 공부

더 많은 정보를 제공 - 여러 컬럼을 조합하면 더 상세한 정보를 키로 활용할 수 있다.

단점

여러 컬럼의 조합으로 이루어지기 때문에 인덱스 크기가 증가할 수 있다.

수정이 복잡해짐. - 데이터 일관성 문제의 위험

쿼리 작성이 복잡해짐 - 가독성과 유지보수 문제.

복합키에 포함된 엔티티에는 cascade 적용 불가.

우리 ERD 상에서의 유저-파티가 필요한 이유는?

파티에 있는 유저들을 조회해야하기 때문.

그렇다면 복합키 없이 대체키 두고 where party_id = 2 이렇게 해도 조회 성능의 차이가 나나?

일단 데이터가 어마무시하게 많다고 생각하면 조회성능의 차이가 난다. 왜냐면 party_id PK를 우선으로 인덱스를 만들게끔 하면 party_id = 2인 데이터들이 뭉탱이로 있을테니까

그리고 또 하나 필요한 이유는 내가 대체키를 쓰면 Long을 사용할텐데 중간테이블은 두 엔티티에 연관된 테이블이기 때문에 레코드 훨씬 많아질 가능성이 농후하다.

그러면 Long 범위를 넘어서는 대체키가 나올 수 있기때문에 복합키가 현명하다.

복합키는 cascade를 적용하는 방법이 따로 있는지(아니라면 자식 엔티티까지 하나하나 조회해서 다 없애야 한다?), 삭제여부 필드를 두는지?

disable 필드 정도만 만들어놓고. 엔티티들에만 disable 판단해 놓고 쓰는 게 낫다.

JpaAuditing 사용 시에 무조건 created_at과 modified_at도 같이 써줘야한다?

일대 다에서 다 쪽이 보통 중요한 데이터이다. 누가 와서 클릭을 했기 때문에 다대다 테이블에 들어가는 것이고. 실제 현업에 가면 데이터 하나하나가 마케팅 요소. 다 뽑아서 줘야한다.

컬럼이 하나 늘어나면 성능 이슈가 발생하지 않나요?

컬럼이 15개만 넘지 않으면 괜찮다. 일단 튜터님 같은 경우 무조건 들어가는 컬럼이 엔티티에 따라 4, 5개 무조건 있다고 생각하신다. 삭제여부, 생성시간, 수정시간.(무조건) 나머지 유저(매핑까지는 안해도), 1,2개 옵션 필수적 만약 컬럼이 15개 이상 넘어가면 일대일 테이블로 분리.

다단계의 계층구조 테이블이 존재할 때 조회를 어떻게?

댓글이 존재하는 보드를 댓글-카드-컬럼-보드 순으로 올라가서 판단하기 보다는(서비스단)

요청에 보드아이디를 넣어준다.

시큐리티 컨텍스트에 내가 만든 보드들을 넣어놓고 검증

argument resolver 컨트롤러 단의 어노테이션

예를 들어 보드 1번이 와슨데

1번 보드가 없는 경우 - > 보드레포지토리에서 해결

보드 2번이 왔고 댓글 3번이 왔는데 (보드 2번에 댓글 3번이 존재하는지 확인)

서비스의 성격에 따라 다르다

퍼블릭 서비스- 권한 따로 필요없는. 룰에 따라서 혼용하여 사용하면 좋다.

느낀 점

진짜 팀장급 실력 아닌데 리더를 맡게 되어서 힘들지만 오히려 기회다 화이팅하자.

ERD 설계

내배캠 최종 프로젝트에 진입하면서 ERD를 설계하게 되었다.

1. 식별관계 - 비식별관계 구별

식별관계와 비식별관계는 참조를 하는 테이블(자식 테이블)과 참조를 당하는 테이블(부모테이블) 사이에 맺어지는 관계이다.

일단 식별관계의 정의는 부모 테이블의 기본 키가 자식 테이블의 기본 키로 할당되는 관계이고

비식별관계는 부모 테이블의 기본 키가 자식 테이블의 외래키가 되는 관계이다.

고로 식별관계는 부모 테이블에 참조하고자 하는 데이터가 없다면 자식 테이블의 데이터 생성이 불가한 구조이다.

식별관계의 장점으로는 데이터의 정합성을 보장해준다는 점이 되겠다.

그러나 테이블간의 제한사항이 빡빡하기 때문에 테이블 관리가 어렵고 비즈니스 로직 변경 시에 난항을 겪을 수 있다.

프로젝트에 따라 관계를 적절히 설정하는 것이 좋다고 하지만 현업에서는 웬만하면 비식별관계로 설정하는 경우가 많다고 하니, 복합키 같은 특수한 경우가 아닌 이상 비식별관계로 설정하는 것으로 결정했다.

2. 일대일 관계를 맺을 것인가?

테이블 설계를 고민하다가 유저 정보와 유저 프로필에 대한 테이블을 따로 만들자는 팀원 분의 의견이 있었다.

유저 정보에는 인증/인가에 대한 내용을 담고 프로필에는 라이트한 데이터를 담으면 독립성 측면에서 좋다는 의견이었다.

나도 오 뭐 나눠서 나쁠 게 있을까? 라는 생각으로 동의하였는데 후에 튜터 님의 조언으로 테이블을 수정하게 되었다.

일대일 관계의 테이블은 최소한으로 만드는 게 좋다는 말씀이었다.

일단 테이블 수를 최대한 줄이는 것이 전체 테이블을 관리하는 데 용이하고

컬럼이 엄청 많은 것이 아니라면 부모 테이블 데이터의 외래키를 찾아 탐색하는 비용이 또 증가하기 때문에 

일대일 관계 테이블은 최소화하는 것이 좋을 것이다.

3. 새로운 테이블 구현방식

하이브(모임) 나 파티(약속)에 변동사항이 생기면 유저에게 알림을 보내주는 기능을 구현하려 했다.

그러면 알림 테이블에 하이브와 파티의 기본 키를 외래키로 가져야 하는데 다대다 관계이기 때문에 이를 테이블로 만들 경우 테이블 구조가 너무 복잡해지는 상황에 봉착했다.

해결 방법은 테이블간의 관계를 맺는 대신 우리가 필요한 건 참조관계까지는 아니기 때문에

알림 테이블 컬럼에 하이브, 파티 둘 중에 어떤 엔티티의 알람인지 + 엔티티(하이브 or 파티)의 기본 키.

이렇게 두개의 컬럼을 추가하여 해결하였다 신박하였다.

느낀 점

진짜 팀장급 실력 아닌데 리더를 맡게 되어서 힘들지만 오히려 기회다 화이팅하자.

Spring

무중단 배포

무중단 배포란 서비스의 중단없이 배포를 완료하는 것을 말한다.

새로운 버전의 서비스가 다운로드되고 로딩되는 도중에 생기는 다운타임 동안 유저는 서비스를 이용할 수 없다.

이같은 문제를 막기 위해 무중단 배포에 대한 고려가 시작되었고 오늘은 대표적인 3가지 무중단 배포에 대해 알아보겠다.

1. Rolling Deployment

롤링 배포는 인스턴스를 증가시키지 않고 인스턴스 일부를 점진적으로 업데이트하는 방식이다.

인스턴스 일부를 잠시 중단시킨 후 새로운 서비스를 로딩하고, 나머지 인스턴스에서 실시간 서비스를 담당하는 방식이다

장점으로는 가지고 있는 인스턴스만으로도 배포가 가능하고 순서대로 업데이트를 진행하며 롤백도 쉽다는 점이지만

단점으로는 일부 인스턴스가 서비스를 담당하는동안 과부하가 걸릴 가능성이 있고, 어느 인스턴스는 구버전 어느 인스턴스는 신버전인 상황으로 유저들간의 호환성 문제가 발생할 수 있다.

2. Blue-Green Deployment

블루그린 배포는 구버전 인스턴스들(블루), 신버전 인스턴스들(그린)을 따로 둔 후에  신버전의 업로드가 완료되면 트래픽을 전환하는 방식이다.

장점으로는 구버전의 인스턴스들이 남아있어 활용이 가능하고 운영환경에 영향을 주지 않는 인스턴스들이 있기 때문에 테스트에도 용이하다.

단점으로는 시스템 자원이 두배가 되어야한다.

3. Canary Deployment

카나리 배포는 광부들이 카나리아 새를 이용해 가스 누출을 감지했던 것에서 유래한 것으로 잠재적 문제 상황을 미리 발견하고자 하는 방식이다.

신버전을 소수의 유저들에게 배포해보고 문제 상황을 확인한 후 점차 많은 유저들에게 배포하는 방식이다.

블루그린과 다른 점은 한번에 모든 트래픽을 전환하지 않기 때문에 문제 상황을 최소화할 수 있다.

느낀 점

대략적으로만 알아봤는데 최종 프로젝트에 꼭 적용해보자.