0204 네트워킹

 1. 같은 네트워크 안에 있다 = 커뮤니케이션이 가능하다 = 데이터를 주고받는 것이 가능하다

2. 네트워크 대역 : CIDR표기로 구분 . 네트워크 id

3. public Ip, private Ip 

4. 클라이언트가 서버에 접속하기 위해서는 : 프로토콜, ip, port가 필요

5. public ip가 -> 라우팅 테이블에 의해 private ip로 변환된다. 

0204 AWS EC2

 1. EC2 : aws에서 제공하는 서버

2. configuration 

- 어떤 os (리눅스, 우분투, 등등)

- processor 개수 (cpu 및 코어 개수 조절)

 - 하나의 컴퓨터에는 여러개의 cpu가 존재할 수 있다.

 -  cpu는 단일 코어일수도 있고 멀티코어일수도 있다. 

- memory 용량

    - 위두개 - 프로세서와 메모리 합쳐서. type으로 구분한다

    - GPU 최적화, 머신러닝 최적화 , general등 다양한 family타입 제공하여 선택할 수 있게끔 하고있음. 

- storage (SSD) : 추가 가능. 하드디스크

3. public Ip 

- aws는 클라우드 컴퓨팅 서비스. 위와같은 설정구성을 마친후- 유저는 인터넷으로 서버에 손쉽게 접속이 가능하다. 그 인터넷 접속을 위한 public IP & key pair로.

4. EC2 type : 프로세서 및 메모리 수를 elastic하게 변경이 가능하다. 데이터는 그대로!! (scale up)

5. EC2 state : stop하여 서버를 중지시킬 수 있다. 메모리에 있던 데이터는 사라지지만 디스크(volumn)에 있는 것은 남아있다.

6. stop-hibernate 옵션이 붙어있는 EC2 type이 존재한다.

7. terminate하면 해당 컴퓨터를 완전히 제외시키며 데이터 복구가 불가능하다.  

0204 AWS availability zone

 1. 먼저 전세계를 region 으로 나누고

2. region을 zone으로 나눈다 . 실제로 물리적인 서버(하드웨어) 장비가 위치하게 된다. 

3. zone은 region안에서 독립된 위치에 있지만 서로 네트워킹이 가능

4. 이렇게 zone을 나눈 이유는 쓰나미같은 자연재해 등에서 발생할 물리적 피해를 예방하기 위해서이다

5. region과 zone에는 각각의 네이밍 label이 붙여져서 존재

0204 클라우드 컴퓨팅

 1. 클라우드 컴퓨팅이란:

- user는 오로지 install의 책임만 있고 관리는 aws가 한다

- 보다 비지니스에 집중할 수 있게 된다

- 반대로 on-premise의 경우 하드웨어의 관리 . 설치. 보안. 프로비저닝 등등.. 모든것을 스스로 user가 책임져야 한다

2. 클라우드 컴퓨팅 모델

- IaaS : infrastructure as a service : 클라우드 아키텍트, 데브옵스의 역할. 인프라 영역( 네트워크, 가상화 등) 영역은 aws에게 맡긴다

- PaaS : platform as a service : 일반적인 개발자, os및 미들웨어는 맡긴다

- SaaS : Software as a service : 대부분의 이용자, 이를테면 ms office. 

3. 클라우드 컴퓨팅과 보안

- private, hybrid, public 

- private의 경우 그 클라우드의 owner가 된다

- public : 일반적인 aws, GCP , ms azure등. 

- 보안을 생각하여 application 단은 public, database단은 private으로 하는 hybrid방식을 고려해 볼 수 있다.

0202 레디스 with spring boot

 

간단한 Fruit클래스 만든 후 redis-cli로 테스트

- ttl 설정해두었기 때문에 해당 시간이 지나가면 자동으로 삭제된다

- id 랜덤하게 생성되어 들어가 있음.

- type으로 해쉬자료구조임을 확인

- hash 자료구조로 특정 필드만 조회할수도 있고 모든 필드를 위와같이 조회할 수도 있다 

- semebers로 set의 모든 멤버를 확인한다

0202 레디스 data persistence

 1. 레디스는 인메모리 데이터 베이스

2. NoSQL의 일종. key-value스토어

3. java언어로 되어있다

4. 빠르다

5. 인메모리이기 때문에 데이터 유실이 발생할 수 있다 < 실험

6. 데이터를 넣은후 - 갑자기 어떤이유로 프로세스 종료 (kill -9해서 실험) . 다시 client로 접속해서 확인해보니 넣었던 데이터가 없어져 있다.

근데 이전에 넣었던 데이터는 유실되지 않고 있었다. 

어떤경우에는 디스크에 저장하고 어떤경우에는 유실되는 건지? 그렇다면 이 유실을 방지하기 위한 레디스의 data persistence전략은 어떤것일지?

---

레디스 data persistence전략

1. RDB 

1) 데이터 스냅샷을 일정 주기로 rdb에 저장한다. 

2) 스냅샷을 찍어 저장할뿐이므로 과부하가 적다(성능 good)

3) 일정 주기적으로 저장되므로 데이터 유실이 있을 수 있다.

2. AOF 

1) append only file

2) redis에서 실행한 커맨드를 전부 append only로 기록한다

3) 데이터 유실이 없다 

4) 동기화 정책에 따라서 성능저하가 있을 수 있다 (매번 똑같은 커맨드 기록)

5) 유연성이 있다. 이를 테면 flushall를 하면 그 커맨드도 물론 기록되는데. 다시 데이터 찾아올때는 파일에서 해당 커맨드 삭제하고 찾아온다던지 .

3. 하이브리드

위 두 전략을 함께 가져간다.

--- 

1. 레디스 rdb data.dmp전략

- redis.conf에서 어디에 rdb덤프 파일 존재하는지 경로 확인

- save 30 1 => 1개 데이터 업데이트 시 30초간격으로 데이터 덤프스냅샷뜬다

- 해당 주기를 조절하여 얼만큼 주기로 스냅샷 찍을건지 결정할 수 있음

- 여기에 dump되어 데이터가 들어가면. 갑자기 레디스 죽더라도 다시 client로 들어가 확인해보았을때 데이터 유실없이 들어가 있는 것을 확인할 수 있음

레디스를 재시작할때 db파일에서 데이터를 읽어오는 것을 로그를 통해서 확인해볼 수 있다

2. --pipe메서드로 대량의 데이터를 한꺼번에 넣을 수 있다

- awk를 활용한다. 

3. 레디스 한글 깨질경우

- 원래는 utf-8로 인코딩하지만 한글그대로의 데이터를 보고싶을때 : redis-cli --raw옵션사용한다. 

4. 레디스 appendonlyfile전략

- 기본적으로 second단위로 저장. 그러므로 최대 유실가능한 데이터는 1세컨드 안에서 행해진 명령어의 데이터라고 할 수 있다

- dir 은 기본적으로 rdb와 같은위치

- appendonly를 yes로 수정한후 테스트 확인해볼수있다

- 이 aof파일의 명령어를 수정해서 원하는 데이터로만 원복이 가능하다

append only file로부터 데이터를 불러들여와 start하는 것을 확인할 수 있다. 

0202 비대칭키로 ssh 접속하기

 https://shanepark.tistory.com/195 <<많은 도움을 받은 글!!

키 생성 후 pub 키를 scp명령어로 보낸후

원격지 서버에 authorized_keys 파일을 생성하여 실행권한을 주고 해당 pub키 파일 내용을 복사 붙여넣기하면 끝!! 아주 간단!!

이제 비밀번호보다도안전하게 접속이 가능하다!