DEVELOPyo

Amazon MemoryDB for Redis 는 OpenSource 인 Redis 를 Amazon 클라우드 컴퓨팅 자원을 사용해 AWS 에서 지원하는 것으로, Redis 와 거의 모든 면에서 동일합니다.

다만 AWS Redis 를 사용할 경우, Redis 서버를 직접 구축하는 것 보다 Performance와 Durability 면에서 이점을 가지며, 설정이 편리한 장점이 있습니다.

이 글에선 Redis의 Persistence(영속성)/Durability(내구성) 측면을 중점적으로 다뤄보겠습니다.

[ Redis RDB vs AOF  ] 

메모리는 휘발성이므로 memory DB 인 Redis 프로세스를 종료하게 되면 데이터가 모두 유실됩니다.

따라서 단순 캐시용도가 아닌 Persistence 한 DB로 활용하기 위해서는 데이터를 Disk 에 저장하여 데이터 유실이 발생하지 않도록 해야합니다.

이를 위해 Redis 엔 RDB(snapshot) 와 AOF(Append Only File) 기능이 존재합니다.

1. RDB

• RDB 는 memory snapshot 파일의 확장자인 .rdb 를 의미
• 특정 시점/간격 마다 메모리의 전체 데이터를 디스크에 바이너리 파일로 저장(snapshot)하는 방식
• 특정 시점마다 백업을 받을 때 사용
• AOF 파일보다 사이즈가 작다는 특징이 있고 사이즈가 작으므로 로딩 속도도 AOF 보다 빠른 장점이 있습니다.
• RDB 관련주요 redis.conf 파라미터

• RDB 방식의 문제점
  Redis 장애 발생시 .rdb 백업 시점 이후에 발생한 데이터는 유실됨

# .rdb 데이터 유실 예시
> SET key val
> SET key1 val1
> SAVE
> SET key val2 #SAVE 이후로 데이터 유실
> SET key1 val3 #SAVE 이후로 데이터 유실

2. AOF

• Append Only File 이라는 의미에서 알 수 있듯이 .aof 파일에 모든 쓰기 명령을 기록 (조회는 제외)
• redis client 가 redis 에 쓰기 명령을 요청하면 Redis 는 해당 명령을 .aof 파일(디스크)에 저장한 후, 해당 명령을 수행하는 방식으로 RDB 방식과 달리 특정 시점이 아닌 항상 현재 시점까지의 로그를 기록
• CUD 를 계속 append 하며 기록하게 되므로 파일 크기가 계속 커지게 되는데, Rewrite 를 하게 되면 최종 데이터만 기록되어 파일 크기가 작아진다

# 기존 appendonly.aof 파일 예시
SET key value
SET key value2
SET key value3
SET key value4

# AOF REWRITE 실행 후 appendonly.aof 파일
SET key value4 # 최종 데이터인 key value4 만 남게된다

• AOF 관련 주요 redis.conf 파라미터

• AOF 를 사용한 복구 예시 
  .aof 파일에서 문제가 되는 명령어를 수정/제거한 후 redis 서버를 재시작하면 데이터 손실없이 DB를 살릴 수 있다

# .aof 를 사용한 복구 예시
*1
$8
flushall #문제가 되는 해당 명령어 삭제 후 저장

• AOF 방식의 문제점
  모든 쓰기 기록이 남아있는 파일이므로 RDB 방식에 비해 백업 데이터 크기가 크고, 모든 라인이 한 줄 씩 재수행 되므로 서버자원을 많이 사용

[ RDB vs AOF 무엇을 써야하는가? ]

특정 시점을 기준으로 메모리 DB의 데이터를 백업하는 snapshot 방식의 RDB 방식과

조회 명령을 제외한 모든 쓰기 명령을 기록하는 AOF 방식은

각각의 장단점이 명확하므로 AOF 를 default로 사용하고 RDB 를 optional로 사용하는 방식으로 둘을 조합하여 사용합니다.

→ 서버가 실행될 때 백업된 .rdb 를 reload 하여 복구하고, snapshot 시점과 shutdown 사이의 데이터만 AOF 로그로 복구하여 서버 재기동 시간과 서버자원을 절약

그렇다면 RDB 와 AOF 방식을 통해 memory DB 인 Redis 를 Persistence 하게 사용 할 수 있을까요?

모든 쓰기 명령을 로그로 기록하는 AOF 방식도 아래와 같은 데이터 손실 가능성이 있다고 합니다.

아래는 AWS memoryDB 관련 가이드 발췌 글입니다. (출처: https://aws.amazon.com/ko/memorydb/faqs/)

How is MemoryDB’s durability functionality different from open source Redis’ append-only file (AOF)?
MemoryDB leverages a distributed transactional log to durably store data. By storing data across multiple AZs, MemoryDB has fast database recovery and restart. Also, MemoryDB offers eventual consistency for replica nodes and consistent reads on primary nodes.
Open source Redis includes an optional append-only file (AOF) feature, which persists data in a file on a primary node’s disk for durability. However, because AOF stores data locally on primary nodes in a single availability zone, there are risks for data loss. Also, in the event of a node failure, there are risks of consistency issues with replicas.

How does MemoryDB durably store my data?
MemoryDB stores your entire data set in memory and uses a distributed Multi-AZ transactional log to provide data durability, consistency, and recoverability. By storing data across multiple AZs, MemoryDB has fast database recovery and restart. By also storing the data in-memory, MemoryDB can deliver ultra-fast performance and high throughput.

위 글에서 알 수 있듯이 Redis AOF는 .aof 파일을 마스터 노드 디스크(싱글 AZ라 할 수 있는)에만 저장하여 데이터 loss risk가 있으며 노드 장애시 슬레이브 노드와 데이터 일관성 문제가 있을 수 있다고 합니다.

AWS memoryDB for Redis 는 모든 메모리 데이터를 분산된 multi AZ 에 transaction log 로 기록하여 durability 와 마스터 노드 ↔ 슬레이브 노드간의 데이터 일관성을 보장한다고 합니다.

아래는 Redis 와 AWS MemoryDB for Redis 의 차이를 정리한 차트입니다.

참고 :

https://redis.io/docs/management/persistence/

https://docs.aws.amazon.com/memorydb/latest/devguide/what-is-memorydb-for-redis.html

https://aws.amazon.com/ko/memorydb/faqs/

https://hyunki1019.tistory.com/169

https://rmcodestar.github.io/redis/2018/12/10/redis-persistence/

https://www.youtube.com/watch?v=Jbq_XZMZEKY

[ Login Shell vs Non-login Shell ]

Login Shell : 계정/암호를 입력하여 Shell 실행하는 것. ex) ssh 로그인 / GUI에서 로그인

Non-login Shell : 로그인 없이 실행되는 Shell. ex) ssh 접속 후 bash 를 다시 실행하는 경우, GUI에서 터미널을 띄운 경우 sudo su 로 계정 변경하는 경우

[ 파일 로드 순서 ]

1. /etc/profile

: /etc/profile.d 디렉토리 안의 모든 쉘 스크립트 실행시킴. /etc/profile.d 엔 vim, qt, lang 등 다양한 설정이 sh 파일 형태로 존재. 쉘에 로그인하면 일단 이 sh 파일을 모두 실행시키는 것.

2. ~/.bash_profile or ~/.profile

: 계정 디렉토리에 있는 .bash_profile or .profile 로드. 이 파일들은 계정에 종속적이기 때문에 계정 디렉토리에 존재하므로 ~/.bash_profile or ~/.profile 파일을 로드하게 되는 것. PATH 같은 환경변수를 설정할 때 이 파일을 수정하는 이유가 여기에 있다.

3. ~/.bashrc

: 계정 디렉토리에 있는 .bashrc 파일 로드. 이 파일은 로그인과 상관없이 bash 콘솔을 새롭게 열 때 실행됨. 파일 안에는 아래와 같은 구문이 있는데, /etc/bashrc 파일을 실행하라는 뜻.

if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

4. /etc/bashrc

마지막으로 /etc/bashrc 파일 실행. 이 파일도 /etc/profile 과 마찬가지로 계정과 상관없이 전역적으로 영향을 미침.

[ /etc/profile , /etc/bashrc ]

이 파일들은 계정과 상관없이 전역적 설정

[ ~/.profile, ~/.bashrc ]

계정 디렉터리로 가면 .bashrc와 .bash_profile or .profile이라는 2개이 파일이 있다.

.bash_profile이란 bash로 로그인 할 때만 로드된다.

반면 .profile은 bash와 상관없이 로그인 하면 로드된다.

두 개 중 하나만 로드되며 bash로 로그인하면 .bash_profile만, bash 외 쉘로 로그인하면 .profile만 로드된다.

이 파일들은 공통적으로 환경변수를 세팅할 때 사용하고, 차이점은 실행되는 시점이 다르다는 것이다

1) .profile : 로그인 되는 시점에 실행 (Login Shell). bash와 상관 없는 것들을 넣는다.
2) .bash_profile : Bash로 로그인 되는 시점에 실행 (Login Shell).
3) .bashrc : 새로운 콘솔을 열 때 실행 (Non-login Shell). 로그인 없이 Bash가 실행될 때 로드된다. bash 쉘이 아닌 경우 각 쉘에 맞는 cshrc, tcshrc, kshrc 파일 등이 동일한 역할을 한다.

[ 환경변수 설정 ]

전역 파일 설정 :

환경설정은 /etc/profile에, 기타 함수나 alias 설정은 /etc/bashrc에..

/etc/profile : 

# System wide environment and startup programs, for login setup
# Functions and aliases go in /etc/bashrc

/etc/bashrc :

# System wide functions and aliases
# Environment stuff goes in /etc/profile

[ 사용자 계정 파일 설정 ]

사용자 디렉터리에 있는 .bash_profile 또는 .profile 과 .bashrc 가 위의 전역 파일들에 대응된다고 볼 수 있다. 다만 로드 순서는 전역 파일이 먼저고 사용자 파일이 그 다음이다. 두 파일에서 중복되지 않는 내용들은 둘 다 적용된다고 볼 수 있다. 하지만 만약 내용이 중복된다면 사용자 계정 파일의 내용이 우선된다.

가급적 사용자 계정 디렉터리에 있는 환경설정 파일을 수정하고, 전역 설정을 변경해야 하는 경우에도 직접 전역 파일을 건드리지 말고 사용자 계정의 환경설정 파일 내에서 연속성을 유지할 수 있도록 수정해야 한다.

ex)  PATH를 수정해야 하는 상황에 놓였을 때, /etc/profile 를 직접 수정하는 것이 아니라 ~/.profile을 아래와 같이 전역 설정을 기반으로 연속적으로 수정한다.

/etc/profile

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

~/.profile

PATH="$PATH:/usr/home/test"

https://projooni.tistory.com/entry/bashrc-%EC%99%80-profile-%EC%B0%A8%EC%9D%B4%EC%99%80-%EC%9E%91%EB%8F%99%EC%9B%90%EB%A6%AC

1. aws 에서 생성한 키페어를 사용하여 외부 접근이 허용된 서버 (ex: 0.0.0.0/0 에 대한 인바운드 허용 Security Group 사용중인 bastion 서버) 에 접속

ssh -i key.pem ubuntu@bastion서버publicIP

2. aws 에서 생성한 키페어 를 home 디렉토리에 key.pem 생성

sudo vi key.pem

3. bastion 서버에서 내부망 서버 접속

ssh -i key.pem ubuntu@내부망ip

[ 보다 쉽게 접속을 위한 ssh rsa 공유키/개인키 설정하기 ]

1) bastion 서버에서 공개키 생성

ssh-keygen -t rsa

2) bastion 에서 접속할 내부망 서버에 접속하여 공개키 추가 (공백 라인 추가 후 1)번의 bastion 서버 공개키 붙여넣기)

vi ~/.ssh/authorized_keys

3) 접속

ssh ubuntu@내부망서버IP

※ bastion 서버 /etc/hosts 에 내부망서버IP 를 등록 후 alias 사용하여 접속 가능

vi /etc/hosts
192.168.52.129 db

설정 후 접속

ssh db

https://johncom.tistory.com/42

1. VPC 생성

- ex) 192.168.52.0/24 생성

2. 서브넷 생성

- 할당할 IP 갯수를 고려하여 구성

※ 서브넷마스크 테이블 

ex)

192.168.52.0/26 : 192.168.52.0 ~ 192.168.52.63 (64개 할당) - 서비스 외부망

192.168.52.64/26 : 192.168.52.64 ~ 192.168.52.127 (64개 할당) - 서비스 외부망

192.168.52.128/27 : 192.168.52.128 ~ 192.168.52.159 (32개 할당) - DB 내부망

192.168.52.160/27 : 192.168.52.160 ~ 192.168.52.191 (32개 할당) - bastion 외부망

3. Internet Gateway 생성 

- 서버와 인터넷망 연결에 필요. VPC 생성시 자동 생성

* Nat Gateway 생성

내부망서버가 인터넷 망으로 나가기 위해 Nat Gateway 필요 (eg: nat gw 없인 내부망 DB 서버에서 yum install mysql 불가)

라우팅 테이블에 0.0.0.0/0 nat gateway 지정 필요

4. Route Table 생성

1) 내부망 subnet (ex: DB) : 내부ip 대역 로컬 대상 설정

2) 외부망 subnet (ex: bastion) : 내부ip 대역 로컬 대상,

                                                     0.0.0.0/0 인터넷게이트웨이 설정

5. Security Group 설정

bastion 서버 inbound : 내공인IP 22번 port 허용

내부망서버(DB) inbound : DB port (3306)

                                          bastion서버 SG

외부망서버(웹서버) inbound : 서비스 port (ex: 8080, 443, 80) 

                                                bastion서버 SG 

6. EC2 생성

1~5 설정한 정보 기준으로 생성

※ AZ(Availability Zone) 은 이중화 구조에선 DR등을 고려하여 #1과 #2를 각각 다르게 설정

[ bastion (배스천) 서버란? ]

내부와 외부 네트워크 사이에서 내부망을 보호하기 위한 게이트웨이 역할을 수행하는 호스트서버

bastion 서버의 inbound 를 특정 ip(ex: 내 공인IP) 로 security group 을 설정해주고,

내부 서버의 inbound 설정은 22번 port 를 bastion 서버에게만 허용하여

bastion 서버에 보안을 집중.

https://www.youtube.com/watch?v=lqnncuQgz28&t=800s

[현상]

공개키와 개인키를 사용하여 서버 접속 시도시 하기와 같은 에러가 발생할 경우.

ubuntu@ip-192-168-52-177:~$ ssh ubuntu@db
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for db has changed,
and the key for the corresponding IP address 192.168.52.148
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:e0+0wN11IMq46zRTMCLGotYpg3hm/oPWUAbPF1K72Zk.
Please contact your system administrator.
Add correct host key in /home/ubuntu/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/ubuntu/.ssh/known_hosts:4
  remove with:
  ssh-keygen -f "/home/ubuntu/.ssh/known_hosts" -R "db"
ECDSA host key for db has changed and you have requested strict checking.
Host key verification failed.

[원인]

기존에 접속한 적이 있는 서버와 RSA 공유키를 교환한 상태에서 서버가 바뀌었기 때문에 발생. 기존 서버 정보를 찾아갔으나 다른 서버로 접속된, man-in-the-middle attack(중간자 공격)으로 감지된 상황.

(ex: /etc/hosts 의 ip alias 에서 ip 정보가 바뀐 경우 발생 192.168.52.148 db 와 같이 로컬에 호스트정보가 있었으나, 접속한 이력이 있던 상태에서 로컬 hosts 설정의 ip를 바꾼경우 발생)

[해결]

하기와 같이 alias 혹은 ip 에 대한 인증키 제거

> ssh-keygen -R ip

https://cpuu.postype.com/post/30065

[node.js란]

자바스크립트는 런타임이 브라우저에 존재하여 이 한계를 극복하기 위해 등장한

서버에서 자바스크립트를 동작할 수 있도록 하는 플랫폼.

[nvm : Node Version Manager]

Node.js 버전 관리자

Node.js 에서 제공하는 여러 버전의 사용을 돕는 프로그램

Node.js 설치 툴

※ 설치 순서

nvm -> Node.js -> npm 

[npm : Node Package Manager]

Node.js 패키지 매니저

Node.js 로 개발된 프로그램(npm 패키지)를 편리하게 설치, 업데이트/삭제 해 주는 프로그램

Node.js 가 설치된 상태에서 npm 명령어를 통해 npm 서비스에 등록된 Node.js 로 작성된 패키지 관리

Node.js 설치시 npm 이 같이 설치됨

[ 노드설치 ]

1. brew 사용하여 nvm 설치

brew install nvm

2. 디렉토리 생성

mkdir ~/.nvm

3. .zshrc 

vi ~/.zshrc

하기 텍스트 삽입

export NVM_DIR="$HOME/.nvm"
[ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && . "/opt/homebrew/opt/nvm/nvm.sh"  # This loads nvm
[ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && 
. "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"  # This loads nvm bash_completion

4. nvm -v 로 nvm 설치 확인

[node js 설치]

1. node.js 설치

# LTS(Long Term Support : 지난 2년간 개선사항에 대한 패치를 보증하는 버전) 버전 설치
nvm install --lts 
# 지정한 버전 설치
nvm install 14.17.4

2. 설치된 node.js 리스트 보기

nvm ls 

3. 특정 버전 node.js 사용하기

nvm use 버전

참고

https://cotak.tistory.com/156

https://velog.io/@minidoo/Node-npm%EA%B3%BC-nvm-%EC%B0%A8%EC%9D%B4

[ 인수테스트 (AT : Acceptance Test) ]

인수테스트란 요구사항을 작성하는데 집중.

블랙박스 테스트의 성격을 가지므로 시스템 내부 코드를 직접 호출하는 것이 아닌 외부에서 요청하는 방식으로 검증.

* 블랙박스란? 결과물의 내부 구현이나 사용된 기술을 기반으로 검증하기 보단 표면적으로 확인할 수 있는 요소를 바탕으로 검증

* ATDD(Acceptance Test-Driven Development)는 기획 단계부터 인수 테스트를 통해 공통의 이해를 도모해 프로젝트를 진행하는 방법

@SpringBootTest 웹서버를 사용하여 테스트

webEnvironment 설정을 통해 웹 서버 환경을 지정

[ MockMvc vs RestAssured vs WebTestClient ]

1. MockMvc

@SpringBootTest 의 webEnvironment.MOCK과 함께 사용가능.

mocking된 web environment(ex Tomcat) 환경에서 테스트

2. WebTestClient

@SpringBootTest의 webEnvironment.RANDOM_PORT나 DEFINED_PORT와 함께 사용, Netty를 기본으로 사용

3. RestAssured

실제 web environment(Apache Tomcat)을 사용하여 테스트

[ RestAssured 사용법 ]

RestAssured.given().log().all()

.body(params)

.contentType(MediaType.APPLICATION_JSON_VALUE)

.when()

.post("/~")

.then().log().all()

.statusCode(HttpStatus.CREATED.value())

.header("", notNullValue();

[ 인수 조건 작성법 ]

Feature: 간략한 기능 서술
  Scenario: 시나리오 제목
    Given: 사전조건
    And: 앞선 내용의 추가적인 내용
    And: 앞선 내용의 추가적인 내용
    When: 발생해야하는 이벤트
    Then: 사후조건

영속성 

CascadeType.ALL: 모든 Cascade를 적용
CascadeType.PERSIST: 엔티티를 영속화할 때, 연관된 엔티티도 함께 유지
CascadeType.MERGE: 엔티티 상태를 병합(Merge)할 때, 연관된 엔티티도 모두 병합
CascadeType.REMOVE: 엔티티를 제거할 때, 연관된 엔티티도 모두 제거
CascadeType.DETACH: 부모 엔티티를 detach() 수행하면, 연관 엔티티도 detach()상태가 되어 변경 사항 반영 X
CascadeType.REFRESH: 상위 엔티티를 새로고침(Refresh)할 때, 연관된 엔티티도 모두 새로고침

Question N : User 1 관계일 때

User user = new User(?);

Question question = Question.builder(?).title(?).user(user).build();

questionRepository.save(question);

할 경우 exception 발생.

=> Question Entity 연관관계 매핑(@ManyToOne)에서 CascadeType.PERSIST 를 지정할 경우 User 객체도 영속성이 전이됨(영속화)

https://zzang9ha.tistory.com/350

POSIX 명세에 따라 텍스트 파일끼리 구분을 짓기 위해 소스 마지막 부분은 개행한다.

https://blog.coderifleman.com/2015/04/04/text-files-end-with-a-newline/

[ Object equals ]

equals 메서드는 같은 객체(인스턴스) 일 경우에만 동일하다고 판단.

reflexive : x.equals(x) 는 항상 참

symmetric : x.equals(y) 가 참이라면 y.equals(x) 역시 참이어야 한다

transitive : x.equals(y) 가 참이고 y.equals(z) 가 참일 때 x.equals(z) 역시 참이어야 한다

consistent : x.equals(y)가 참일 때 equals 메서드에 사용된 값이 변하지 않는 이상 몇번을 호출해도 같은 결과가 나와야 한다

x가 null이 아닐 때 x.equals(null) 은 항상 거짓이어야 한다

[ JPA 에서의 equals ]

엔티티 매니저의 영속성 컨텍스트에서 1차 캐시를 이용해 같은 ID의 엔티티를 항상 같은 객체로 가져올 수 있다. 하지만 1차 캐시를 초기화 한 후 다시 데이터베이스에서 동일한 엔티티를 읽어오는 경우 초기화 전에 얻었던 객체와 초기화 이후에 얻은 객체가 서로 다른 객체로 생성된다.

이는 equals 메서드의 consistent 원칙을 위반하는 것이며 엔티티는 자바 객체라기 보단 데이터베이스 테이블 레코드에 가깝기 때문에 엔티티 객체의 필드(pk)가 동일하다면 같은 레코드, 즉 객체라고 판단해야 한다. 

이와 같은 이유로 equals 메서드와 hashCode 메서드를 재정의 해야 한다.

* 준영속 상태의 엔티티 간 비교, 비교할 두 인자가 둘 다 null 인 상태에서의 비교 등을 고려하여 

Objects.hash 메서드를 사용하여 hashCode 구현

https://velog.io/@park2348190/JPA-Entity%EC%9D%98-equals%EC%99%80-hashCode