부하 분산을 위한 이중화 기초
MSA(MicroService Architecture)는 소프트웨어 시스템을 작은, 독립적인 서비스 단위로 분해하여 구축하는 아키텍처 디자인 패턴으로, 특정 기능을 수행하는 서비스들이 서로 통신하여 전체 시스템을 형성한다.
트래픽이 많아지면 서비스에 장애가 발생할 수 있는데, MSA는 장애가 발생해도 전체 서비스는 이용할 수 있도록 최대한 보장하는 아키텍쳐다.
재난 복구를 위한 미러사이트가 Active상태이기 때문에 다운타임이 거의 발생하지 않는다.
하나의 서버는 Active, 하나는 Standby상태로 세팅하고 Active에 문제가 생기면 Standby 상태의 서버가 Active로 전환되어 짧은 다운타임을 갖는다.
하나의 프로그램에 진입시 해당 프로그램이 각기 다른 서버에 요청을 분산처리 할 수 있다.

많은 장점이 있지만 그만큼 다양한 문제점이 발생하기 때문에 이를 보완하기 위한 장치가 마련되어야 한다.
클라이언트가 로그인하면 서버 컴퓨터의 메모리 세션영역에 저장된다.
이때 서버가 분산되어 있으면 다른 서버로 연결될 때 그 세션 영역에는 로그인 정보가 들어있지 않아 로그인이 되지 않은 것 처럼 처리된다.
세션 로그인 방식은 쿠키와 함께 사용한다.
각 서버에 세션정보를 동기화 시킨다(다른 서버의 메모리에 같은 값을 등록한다)
장점: DB에 비해 상대적으로 빠르다
단점: 서버를 여러대 추가했을 때 추가적인 작업을 해줘야하며, 하나의 정보를 모든 서버의 메모리에 복사해야 하기 때문에 메모리 낭비가 심하다.
DB에 저장해두고 불러온다
장점: 웹 서버를 여러대 늘려도 따로 설정해줄 게 없다.
단점: 사용자 요청이 있을 때마다 DB를 조회(느림)
로그인을 하면 분산처리를 할 때 세션정보가 등록된 서버로만 가도록 처리한다.
장점: DB에 비해 상대적으로 빠르다
단점: 부하 분산이 제대로 되지 않을 수 있다.
요즘 가장 많이 쓰는 방식
로그인을 하면 클라이언트(브라우저)에 쿠키형태로 토큰이 생기는데 이 토큰의 암호화를 풀면 JSON형태의 데이터로 변경된다.
변조에 대한 우려가 있을 수 있지만 JSON의 내용을 변경해봤자 암호화 알고리즘을 거친 토큰값은 속일 수 없다.
장점: 서버에 저장할 게 하나도 없다. 서버에 부담이 줄어든다.
단점: 보안이 취약하다.(id,pwd가 없이도 쿠키에 토큰명,토큰값만 입력한다면 로그인할 수 있다 | 다른 방법도 쿠키를 사용하기 때문에 결국 마찬가지이다)
위의 세 가지 방식은 세션의 만료시간을 정해두지만 JWT 토큰은 Refresh토큰을 같이 사용한다(Refresh토큰은
메모리에 저장하는 Redis를 DB처럼 사용
장점: 웹 서버를 여러대 늘려도 따로 추가할 게 없음
단점: Redis 서버 관리를 따로 해줘야함
세션이 서버에 저장되는 데이터라면, 클라이언트에 저장하는 정보가 바로 쿠키이다.
이를 통해 서버는 해당 사용자의 로그인 여부나 각종 이용 내역등 다양한 정보를 확인할 수 있다.
토큰의 값(쿠키)을 훔쳐서 로그인처리


수동으로 로그인이 잘 되어있음

개발자 도구에서 쿠키를 찾아보면 위와 같이 로그인 토큰값을 찾을 수 있는데

로그인이 안된 사이트에서 개발자 도구를 켜고 쿠키에서 찾은 토큰값을 추가하고 새로고침하면



id와 pwd없이도 로그인에 성공한 것을 볼 수 있다.
DB에서 로그인 정보가 삭제되면 로그인이 풀림

정상적으로 로그인이 되어있는 상태

usermeta에 있는 데이터를 삭제하면?



잘 로그인 되어있다가 로그인이 풀리는 것을 볼 수 있다.
vi /etc/my.cnf.d/mariadb-server.cnf
[mariadb] <- 이건 추가 X 이 아래에 추가
log-bin
server_id=1
log-basename=master1
binlog-format=mixedshow master status;CREATE USER 'slave_user'@'%' IDENTIFIED BY 'qwer1234';
GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%';mysqldump -u root [DB 이름] > web.sql
scp web.sql [SLAVE 서버의 IP]:/root/web.sql백업할 DB생성
CREATE DATABASE [DB 이름];
DB 서버 설정(고유한 server_id부여)
vi /etc/my.cnf.d/mariadb-server.cnf
[mariadb] <- 이거는 추가하는거 아님
server_id=2
DB 재시작
systemctl restart mariadb
slave에서 master 지정
CHANGE MASTER TO
MASTER_HOST='[Master 서버 IP]',
MASTER_USER='slave_user',
MASTER_PASSWORD='qwer1234',
MASTER_PORT=3306,
MASTER_LOG_FILE='[마스터에서 show master status 했을 때 File 이름]',
MASTER_LOG_POS=[마스터에서 show master status 했을 때 position 번호],
MASTER_CONNECT_RETRY=10;
replication start
START SLAVE;
slave 확인
SHOW SLAVE STATUS\G
(아래와 같이 표시되어야 함
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

웹 서버 이중화와 DB 서버 이중화를 동시에 하면 아래와 같다.

/var/log/messages => 리눅스의 모든 로그가 담김
tail -f(계속 조회) /var/log/messages
하나를 이렇게 세팅하고 다른 윈도우로 실행하면서 로그를 분석해본다
다른 컴퓨터에 붙여넣기 하고싶으면 scp명령어 사용