<ps>
- a : all
- x : all 프로세스 해당 터미널이 아닌것까지
- u : 해당 유저프로세스
- $USER : 현재 로그인한 유저
- $(변수명 길경우) : 이런식으로 괄호쳐도 됨
- VSZ (Virtual memory SiZe) : 가상 메모리 크기. 해당 프로세스가 접근할 수 있는 모든 메모리의 크기.
- RSS (Resident Set Size) : 실제로 RAM에 차지하고있는 메모리 사이즈
- TTY : 가짜 터미널
<less, more>
-페이지 단위로 볼수있음
- 파이프라인에서 이용시 유용하다
<top>
- shift m :메모리순정렬
- shift t : time순 정렬
-up : uptime
- tasks : 프로세스 개수
- id : idle
-us 유저프로세스
<bc>
basic calculator
<free>
- 메모리 사용량
- buff/cache와 available이 0에 가까울경우 매우 위험 경계한다
- t옵션 total붙일수있다
- 여러 컨테이너를 한꺼번에 띄울수있다.
- 장점: develop할때, config바꾸고 서비스 하나하나 변경할 필요없이 docker-compose만 띄우면 되니까 짱 편하다.
- private network 자동으로 만들어준다. 외부와 격리되므로 안전!
- 컨테이너를 서비스 별로 분리
- 버전, 서비스, port , depends_on 등의 키워드를 명시한다
<도커 컨테이너끼리 커뮤니케이션 하는 방법.>
- 특징
1) private ip를 부여받는다
2) embeded dns
1. bridge
- 디폴트
- 명시하지 않을경우 docker network create하면 브릿지로 만들어진다.
- 도커 컨테이너끼리 ip를 할당받으며 이 ip로 소통한다. host는 모름.
2. host
- 호스트와 소통가능
3. none
- 다른 도커 컨테이너들과 커뮤니케이션 할 수 없다.
--
특이사항!!
- 무지무지 짱인거-> 도커 컨테이너 명을 그대로 hostname으로 사용할 수 있다
- 도커 짱이다.. 이제 vm 쓰지말구. 도커파일 하나 딱 작성해서. RUN커맨드 명시하구 끝일듯... 파일두 걍 마운트해서 공유하면되고.. 귀찮게 scp안해도 되구..
- 실제 프로덕션에서 도커 쓰는거는 고려해야 할거같은데 (넘 경량화라는 게 장점이자 단점인듯. 프로세스 죽이면 다 날라가는 것두 있으니..) 개발환경에서는 넘넘 활용가능성이 좋아보인다.
<도커 컨테이너끼리 파일을 공유하는 방법.>
- 컨테이너끼리 target과 source를 정의하여 파일을 공유한다!!
1. volume
- 더 권장되는 방식이라고 함
- 호스트와 별개로 논리적인 공간을 부여받는다
- 마운트 type설정하지 않을 시 디폴트.
- 호스트와 독립적으로. 컨테이너들끼리 파일공유하고싶을때.
2. bind
- 호스트의 파일시스템에 묶인다
- 컨테이너의 위치를 변경하는 경우 영향을 받게됨
- 해당 위치에 파일쓰면 컨테이너 바깥으로 빠져나와도. 마운트 된 그위치- 에 호스트에도 파일이 생겨있다! 신기~~
- 실시간으로 호스트의 파일내용 공유하고 싶을때 유용(git 소스 코드 실시간으로 반영한다던지)
3. tmpfs
- volume과 동일하나 컨테이너stop할경우 해당 파일들 날라가게 된다
- 잠시동안만 사용하는 보안 파일들에적절
1. 도커란 : 격리된 환경에서 어플리케이션 실행
2. 장점: vm 보다 훨씬 가볍다. 리소스를 많이 안잡아먹음 - develop환경에서 쓰기 좋다 . 내 로컬에서는 되는디요? -난 안된다고요~ => 이런 상황 줄어들것임 ㅎ
3. 용어 :
1) image : 재료
2) container : 실제로 실행중인 이미지
3) dockerfile: 명령어들을 모아놓은 문서
4) docker hub: 이미지들 모아놓는 저장소 repository
4. 도커 파일을 손수 작성하여 -> 이미지를 만들고 ->그 이미지로부터 컨테이너를 생성한다.
5. 도커파일에는 uppercase로 되어있는 키워드들이 존재함
- base이미지를 다운받고, 어느 디렉토리에서 실행할지 명시하고, 어떤 명령어를 실행할지를 명시한다
6. docker run 명령어: 이미지를 만들고, 실행하는 것 한꺼번에 편하게 할수있다. 다양한 옵션이있다
- detach 모드 실행
- port 포워딩
- name옵션
등등
7. 한번 만든 컨테이너 삭제하여도image란에 캐시되기때문에 훨씬 빠르게 또 컨테이너 만들 수 있다.
8. 이미지 자체는 프로세스가 아니므로 cpu자원 잡아먹지 않는다 개꿀~ 그러나 용량은 차지하므로 필요없으면 삭제
9. docker exec -it
interactive 로 실행한다
빠져나올때는 ctl P ctl Q
---
dockerfile keyword
- FROM : 베이스 이미지 명시
- RUN : 실행할 이미지 명시
- CMD : 실행할 커맨드 명시
- WORKDIR : 컨테이너가 실행되는 위치
- COPY : 파일들을 해당 컨테이너로 복사하여라
- EXPOSE : 포트번호를 명시적으로 알려줌
- 운영체제
- 서버 아키텍처
- distributed computing
- cpu
-network performance
- disk I/O
- RAM , HEAP사이즈
- 페이지 캐시
- 카프카와 주키퍼
---
- swappiness설정 : 최대한 disk I/O를 줄이고 메모리를 사용하라
- KAFKA_HEAP_OPTS : java heap메모리설정 . Xms는 설정하지 않는다 시작하면서 점점 메모리 늘려가면 됨. starting heap메모리를 고정할 필요 x
- 나머지 남는 메모리는 페이지 캐시로서 이용한다
- 카프카는 데이터 파싱을 따로 하지 않으므로 빠르다. 그러나 SSL등 설정한경우 이에대한 cpu성능이 필요할 수 있음
- file 디스크립터 설정을 무지 크게 해두어야 함. 1개 파티션의 1개 세그먼트 별로 3개의 file오픈하기 때문에 부딪힐수있다
- delete토픽을 하면 일단 delete했다는 태그 표시를 달고 - 일정시간 경과후 실제 삭제된다. 이 시간 gap이 있으므로 여유있게 메모리 설정해두어야 함
- disk I/O : 부족한 경우 EBS 더 mount한다
- network : 카프카 클러스터 region최대한 가깝게. (latency) + bandwidth설정 고려
1. zookeeper역할
- 브로커 등록
- leader브로커 선출
- 각종 config 관리(ACL등)
- Topic관리
- 클러스터 관리
2. zookeeper 적절한 개수
- 주키퍼는 vote시스템이다.
- voting 정족수는 과반수이다. 따라서 홀수로 설정하는 것이 적절하다.
- 1, 3, 5, 7....(2n+1) 개의 zookeeper
- 1개의 주키퍼 -> 죽으면 안됨
- 3개의 주키퍼 -> 1개까지 죽어도 ok (보통 그래서 3개로 많이 함)
- 5개의 주키퍼 -> 2개까지 죽어도 ok.(정말정말 정말 커다란 카프카 시스템을 구축하고자 할때. 거의 없음. 5개의 주키퍼가 서로 소통한다)
+ broker적절한 개수
- n-1개 까지 죽을수있다
- 보통은 3개
1. aws인스턴스생성
2. advertised.hostname에 public dns를 적는다(이상하게 . ip를 적으면 접속이 안되더라.. 이유를 모르겠음)
3. security group 9092열어둔다
4. --bootstrap-server 를 public ip로 해서 접속한다
1. virtualbox에 ubuntu로 zookeeper, kafka server , producer띄우고
2. NAT설정
3. 포트포워딩 9092로 열어두고
4. 로컬에서 9092포트로 consumer접속
5. Connection to node 0 could not be established. Broker may not be available 에러
server.properties
6. advertised.listeners=127.0.0.1://9092
변경후 잘됨!!ㅇㅇ
cpu mem 1GB
KAFKA_HEAP_OPTS -Xmx400 -Xms400
으로 설정했을때
카프카 컨슈머 그룹을 설정해도 리더 컨슈머에게만 데이터가 가는현상 발생
(인스턴스 1개에서 zookeeper, producer, consumer 다 돌렸더니. 오버헤드 나는듯)
메모리를 4GB로 늘려서 다시 시도해보니 이번엔 골고루 분배됨
1. Topic
: 데이터
2. Partition
: 토픽 은 각각의 파티션으로 나누어짐, 파티션은 오프셋을 가지고 있음, 파티션 안에서만 order를 보장
3. Broker
: 서버 역할. 여러 파티션을 가지고 있을 수 있음.
4. Replication
: 리더 브로커는 오로지 한명뿐. 카프카 주키퍼가 리더파티션을 뽑고 걔가 죽으면 다시 선출하는 것을 뒤에서 조정
5. ISR
:in sync replicaiton. 리더 브로커는 오로지 한명, 나머지는 전부 그냥 데이터 복제만. 머리가 두개 되는것을 방지 -sync로 한다.
6. Producer
: 데이터를 만드는 주체, source로부터 여러 파티션에게 데이터를 보낸다
7. Partition key
: null일 경우 라운드로빈으로 그냥 파티션 암데나 보내짐, 키 해싱하여 지정(예를들면 pk) 할경우 해당 해싱된 파티션으로만 데이터가 들어가게 된다.
8. consumer
: 카프카로부터 데이터를 받아서 . process한뒤 목적 대상으로 보낸다
9. offset
: 데이터베이스커밋같은개념. 나 process했어 - 후에 커밋할건지아님 걍받았기만하면 커밋할건지조정- 이것으로. 성능 & 데이터 중복의 반비례 관걔
10. consumer group
: 하나의 어플리케이션. 내 경우에는 java어플리케이션이라고 생각하면 됨. 파티션개수>=컨슈머그룹개수.
11. zookeeper
:레디스 센티넬같은. 브로커들을 관리하고, topic 의 변경사항을 nofify하는 역할, 선출의 right이 있다
12. kafka discovery
: 메타데이터를 보낸다. 프로듀서는 메타데이터를 받아서 카프카와 소통, 직접적으로 파티션과 관계맺지않음
1. 트랜잭션이란
- a unit of work
- 일련의 작업단위
- 생명주기 : begin ~ commit
- commit : 메모리에 있던 데이터들이 disk로 flush 되는 것
- commit 이전에 crash 하면 -> rollback
- commit 도중에 crash 하면 -> rollback
- commit 은 디스크에 쓰는과정이라 느릴 수 있다
- 롤백은 메모리를 샷 없에는거라서 빠르다
- 존재하는 데이터- 하나의 스냅샷을 본다
2. atomicity
- cannot be splited
- 1개라도 실패하면 -> failure -> rollback 되어야 한다
- DB 는 트랜잭션이 crash 했는지를 알아차리고 restart 했을때 rollback 전부 해야한다
- lack of atomicity는 inconsistent 한 데이터로 이어지게 된다
1. ElastiCache : redis , memcached지원
2. multi-az 정책, HA, stand-by로 레플리카를 준비한다.
3. scaling. (이건. 캐시라서 굳이 필요없을듯.)
4. 데이터 백업 정책.
5. 캐시정책
- read중심 : 일단 캐시에서 읽는다. hit하면 그대로 가져오고. miss하면 db에서 가져오고 해당 데이터 캐시에 쓴다. 단점- miss했을때 네트워크 3번이나 탐. & 데이터가 stale했을 가능성 있음.
- write중심: 데이터가 update되면 일단 db에 쓰고, 캐시에도 쓴다. stale할 가능성은 없어지나 유저가 원하는 데이터가 캐시에 있을 확률이줄어든다
6. stale데이터에 대한 방지
- TTL을 지정한다
- LRU정책을 쓴다
7. redis: failover정책 있음, 데이터 백업있음, 싱글 스레드
memcached: pure cache, 멀티 스레드, 고성능.
1. EFS 란
- Elastic File System. 기존의 NFS와 기능 동일, 아마존에서 제공하는 네트워크 파일시스템.
- vpc안의 AZ를 넘나들며 사용이 가능함.
- performace 및 I/O를 커스텀할 수 있다.
2. 사용방법
- EFS를생성한다.
- efs용 security group을 만든다.
- efs에 접속할 인스턴스의 security group 을 만든다.
- 해당 인스턴스security group을 efs의 프로토콜: NFS에 등록해준다.
3. 인스턴스에 efs-utils를 설치한다.
- 설치한후, 마운트할 폴더를 만들고 마운트 한다(efs의 연결- 탭)
- 연결된 인스턴스끼리 실시간으로 네트워킹하며 파일공유가 가능하다!!
- db작업과 같이 I/O 성능이 중요한 경우, EC2 instance store를 고려한다.
- EBS 의 volume 타입에는 4가지가 있다.
- IOPS , throughput, size별로 차이가 있다.
- SSD / HDD
- IOPS란 ? 초당 처리하는 트랜잭션의 수.
- 어떤 어플리케이션을 돌릴것인지 용도에 맞는 EBS를 선택한다.
- AMI를 사용하여, bootstrap하는 속도를 향상시킬수있다.
- AMI를 사용할경우 해당 EBS안의 데이터도 복사된다. 보안 소프트웨어등 필수적으로 들어가야하는 소프트웨어 및 프로그램이 있다면, AMI를 생성해서 복사해두면 편리하다.
- Elastic Block Storage.
- AZ에 bound되므로, 만약 해당 EBS를 다른 AZ로 옮기고 싶다면 스냅샷을 찍어서 새로 EBS를 만들어야 한다.
- 하나의 인스턴스에 bound된다. n:1관계
- 마치 네트워크로 연결하는 usb. 따라서 네트워크 latency를 탄다.
- 프로비져닝이 가능하다.
- 붙였다 뗐다 할수있고, instance가 terminate될때 같이 삭제할것인지 체크하는 옵션이 있다. 만약에 해당 instance종료해도 데이터 보존하고 싶으면, 이 옵션체크박스를 해제하면 됨.
1. on-demand : 사용한 시간(초단위) 만큼 지불
- 호텔, 투숙하는 기간만큼 돈을 지불
2. reserved : 1년혹은 3년계약, 선불(upfront)하면 더 싸다
- instance 고정하면 더 싸고, convertible하게 하면 조금 덜 싸지만 . 그래도 on-demand보다 50퍼센트 정도더싸다고 함
- 호텔, 장기계약하여 더 싸게 투숙
3. spot instance : 내가 지불하는 금액(spot 금액)보다 더 비싸게 지불하려는 유저가 나타나면 쫓겨남ㅋㅋㅋ
- aws는 어짜피 남는게 서버라서 비어두면 손해. 그래서 생겨난 타입
- 쫌 이상한 호텔, 투숙중에 나보다 더 비싸게 지불하려는 사람이 나타나면 쫓겨남
- 언제 종료되도 상관없는- shutdown에 resilence하고 데이터 손실이 있어도 그렇게 치명적이지 않은 job들에 적절하다. batch job, image processing, machine learning등.
4. dedicated : 물리적으로 그 공간을 나만 사용한다.
- 뭔가 강력한 complience규약이 있는 어플리케이션의 경우. 은행권같으면. 이런거 써야할듯?
- 호텔, 전속계약으로 아무도 안들여보내고 나만 투숙.
1. port (프로토콜) , ip (혹은 security group) , 인바운드 아웃바운드 편집
2. 인바운드는 allow기반(화이트리스트), outbound는 all allow
3. 22번 ssh포트의 경우. 매우~ 매우 중요하므로 security group 따로 만들어서 붙이기를 권장.
4. LB와 함께 - security group 자체를 인바운드에 넣어서 활용가능.
5. 일종의 방화벽
6. timeout -해당 포트 security group 이 허용 x
7. refused - 해당 포트 인바운드 열어두었으나 어플리케이션에 뭔가 문제가 있음 (해당 포트로 돌아가는 프로그램이 현재 없다거나.)
- SDK, CLI를 사용하려면 액세스 키를 발급받아야 한다. 이것은 일반적인 아이디/비밀번호개념과 같다고 보면된다.
- 사용자를 생성하여(IAM유저) role과 그룹별로 관리할 수 있다.
- 인스턴스 등 aws서비스에 role을 부여할 수 있다.
- 패스워드 정책을 설정할 수 있다.
- MFA를 사용할 수있다 . Authy 같은 어플.
---
- instatnce connect를 사용하여 인스턴스에 접속할 때, 만든 EC2용 IAM role를 보안 -편집해서 붙일 수 있다.
- 해당 인스턴스에 접속하는 유저가 개인정보(액세스 키, 액세스 패스워드)를 알면 곤란하므로 이런식으로 보안을 강화할 수 있다.
- private한 서브넷 영역에 있는 인스턴스가 인터넷에 접속하기위하여.
- public 서브넷은 라우팅테이블에 인터넷 게이트웨이가 있으므로 인터넷 접속이 가능하다.
- NAT 게이트웨이를 만든후 public 서브넷에 해당 NAT를 붙여준다.
- private 서브넷의 라우팅 테이블에 destionation 에 NAT 게이트웨이 id를 넣어준다.
- private instance -> 라우팅 테이블 -> NAT gateway -> public subnet의 인터넷 게이트웨이 -> 인터넷통신이 가능해진다.
- 서버와 클라이언트의 소통
- 올바른 프로토콜과 port로 소통
- dns서버가 도메인 이름을 ip address로 라우팅테이블에서 바꾸어서 전달
- 네트워크 성능 : bandwidth 와 latency
- bandwidth는 전송할수있는 데이터의 양. how much
- latency는 distence
- 아무리 bandwidth가좋다고 해도 최대 빛의속도 7할밖에 안되고, 거리가 길면길수록 결국 latency가 생기게된다 . 밀리세컨드로 변하는 주식 거래 등 어플리케이션의 성격에 따라서 매우 치명적일수있음. voice data 라든지, 조금이라도 끊기면 상대편에서 뭐라고 하는지 알수가 없게됨
- ip v4 : private ip를 할당할 때에는 예약된 번호 이외를 사용하자 (RFC규약)
- 네트워크 ip (= base ip)를 CIDR로 서브넷팅해서-> 가용한 호스트 ip의 범위를 구한다
1 . elastic ip
- 고정 아이피 할당
- running중에는 과금 x , instance stop하면과금
- 인스턴스에 remap할수있다.
- 하지만 elastic ip를 할당하느니, 유동적인 public ip를 받고 DNS설정을 하는 것이 좋다.
2. placement group
- 전략 : cluster, spread
1) cluster
- 하나의 AZ, rack에 함께 배치
- 높은 networking power , 머신러닝 같은 경우 적합
- 단점: 해당 rack이 fail하면 다 망한다.
2) spread
- 여러 AZ,rack에 분산 배치
- 장점: HA, 고가용성 보장. risk에 강하다
- 단점 : zone이 현재 7개까지만 최대 보장한다고 함
1. - base ip 와 서브넷으로 구성되어있다.
- base ip기준으로
- subnet (/32, /24, /16, /8, /0등)
2.
- /32 -> 딱 그 아이피만
- /24 -> 마지막 자릿수까지 (0~255, 2의 8승 개) 할당가능
- /16 -> 2의 16승 개
- /8 -> 2의 24승 개
- /0 -> 모든 ip 따라서 security groups에서 보는 0.0.0.0/0은 모든 아이피를 의미하고 있었던 것이다. outbound룰에 있는 인터넷 게이트웨이!!
3. ipaddr사이트를 통해서 할당가능한 인터넷 ip주소를 계산가능하다
4. public ip 는 온 인터넷 세상에서 단 한개이지만 private ip는 겹쳐도 상관없다는 것!
- 그 private ip의 범위를 설정하고 -> security group에서 활용한다.
1. 정할 수 있는 룰
1) ip
2) port
3) 방향 : Inbound, outbound
2. 알아두면 좋은 특징들
- 하나의 security group은 여러개의 인스턴스에 할당될 수 있다. 1:n관계
- 하나의 security group은 하나의 vpc에 소속된다.
- 기본적으로 inbound는 다 막고, outbound는 all allow하는 정책이다.
- 인스턴스에 접속할때 connection time out인 경우 -> security group을 안열어줘서일 가능성이 크다.
- 인스턴스에 접속할때 connection refused 인 경우-> security group은 열어두었으나, 어플리케이션의 문제일 가능성이 높다.
- security group 의 source에는, ip대신 security group id를 할당할수있다.(매우유용)
1. 5가지 고려사항
- RAM (memory)
- CPU
- I/O
- Networking
- GPU
2. RAM이란
- random access memory
- 메모리를 많이 잡아먹는 프로세스를 돌리기위한 인스턴스라면, 메모리 사이즈를 늘리는 것을 고려한다.
- Hot memory 이다. (<-> 디스크는 cold memory)
- reboot하면 내용이 날라간다.
- 속도빠르다.
- 비싸다.
- free -m명령어 사용해서 확인할 수있다.
-top 명령어 -> shift + m 사용해서 어떤 프로세스가 메모리 많이 사용하는지 desc로 확인할 수 있다.
3. CPU란
- 계산하는 역할
- core와 frequency (GHz)로 이루어져있다
- frequency: cpu의 속도라고 할수있다.
- 코어가 여러개인 경우-> 멀티코어라고 부른다.
- 코어 수가 무조건 많으면 좋은가? -> No. 어플리케이션이 싱글스레드로 돌아간다면, 코어 수가 많아도 하나의 코어만 사용한다. 따라서 어떤 어플리케이션을 돌릴것인가를 생각한다.
- 계산하는 작업(ex. 피보나치 수열 계산) 이 많은 어플리케이션이라면, 멀티코어를 고려한다.
- top 명령어를 통해서 cpu사용량을 확인할 수 있다.
4. I/O란
- 디스크로부터 읽기 쓰기를 하는 것을 I/O라고 한다.
- I/O 성능이 나쁠경우, 인스턴스 slowdown한다.
- SSD같이 I/O성능이 좋은 인스턴스를 고려한다.
- 이를테면 db를 돌리는 인스턴스. 디스크에서 데이터를 읽고, 디스크에 데이터를 쓰는 작업이 많으므로. 이러한 작업에 특화된 인스턴스를 선택할 수 있다.
- IOPS: I/O per second. 저장장치(디스크)의 속도를 나타낸다.
5. Network란
- 다른 machine에게 web을통해 데이터를 전달하는것.
- ftp서버, apache kafka 등, 다른 인스턴스들과 인터넷을 이용하여 소통해야 하는 일이 많다면, 네트워크 성능이 좋아야 한다.
- 네트워크성능 구성요소 : bandwith, latency
- 네트워크 bandwidth가 낮으면-> 어플리케이션 time out이 발생한다.
6. GPU란
- 매우 특수한 경우에만 사용된다. 머신러닝 . 비디오 프로세싱.
- 대부분의 일반적인 인스턴스의 경우 GPU탑재하고 있지 않다.
---그외
- cpu credit : unexpected traffic이 발생하는 경우 cpu burst하면서 힘을 쥐어짜낼수있다. 즉, 필요할때 순간적으로 cpu의 성능을 높이는 기능.
- cpu credit은 인스턴스에 따라 쌓이는 정도 및 max 가 다르다.
- cpu credit소모하고 다시 쌓이는 식이다.
1. ec2 instance 생성 (기본 VPC, 기본 서브넷)
2. 키페어 다운로드, chmod 400, ssh 접속
3. ~/.ssh/config에 호스트 alias 설정
4. 퍼블릭 ip, 프라이빗 ip
- 퍼블릭 ip는 전 인터넷세계에서 유일.
- ec2인스턴스 stop시 퍼블릭 ip재할당된다.
- private ip는 겹쳐도 상관없다.
- aws 가 public ip 인터넷게이트웨이 할당 -> 그 인터넷 게이트 안에 있는 ec2인스턴스끼리 소통 가능 (private ip로)
5. bootstrap script : user data
- 인스턴스 첫 기동 시의 script를 userdata 로 넘길수있고(프로세스를 자동화할수있으므로, 일일이 인스턴스에 들어가서 설치하지 않아도되어서, 편하다)
- var/log/messages에서 bootstrap할때의 로그를 확인해볼수있다
6. my ami
- 한번 설정한 인스턴스를 my ami로 만들어서,똑같은 설정으로 인스턴스 뽑아낼수있다!
- 다른 유저가 만든 public ami도 많다 -> but, malware일가능성!! 함부로 사용하지 않는다. 또한 과금되는 것들도 많음.
7. ami 저장위치
- aws free tier S3 에 저장된다
- 저장 용량에 따라 과금되는 정책. 사용하지 않는 ami 는 삭제하도록 하자.
1. Transaction Isolation level
- read uncommited : 커밋이안된것도 읽을 수 있다 dirty read발생
- read commited : 커밋된 것만 본다 . 하나의 트랜잭션 안에서 repeatable read발생 . 하나의 트랜잭션안에서 다른 update된 데이터 보는것이 가능함
- repeatable read : 트랜잭션에 각각 id를 부여하여 본인 트랜잭션 id보다 적은 id의 데이터만 읽을 수 있다 . phantom read발생 (insert는 허용하기 때문에)
- serializable: 가장 엄격한 수준의 트랜잭션 그러나 성능 하락 심각
2. index사용과 lock
- 인덱스 사용 -> examined되는 row의 수 감소 -> lock카운트를 감소시킬 수있다
- lock은 buffer pool 영역에 저장된다
3. information schema
- 트랜잭션관련 정보 볼수있다
1. 쿼리튜닝 어디서 시작할까?
-> explain analyze
- 갑자기 time이 점프하는 지점에 주목하라
2. 인덱스
- 클러스터링 인덱스 : 물리적으로 모여있다
- primary key = 클러스터링 인덱스
- secondary index : primary키를 가리킨다
따라서 secondary 인덱스로 search하면 일단 secondary 인덱스 접근해서 -> primary key를 찾고 -> 실제 데이터의 물리적인 위치로 간다
3. 클러스터링 인덱스는- 물리적으로 모여있기 때문에. 어떤 키를 primary key로 하는가가 중요하다
- auto-increment로 primary key 잡으면. 그냥 넣는 순서대로 sequential하게 들어가므로 insert할때 비용이 적게 든다
- 만약에 uuid같은 값을 primary key로 잡으면. 넣을때마다 데이터 순서의 조정이 필요하고. 페이지사이즈(MySQL의 경우, 16kb) 안에 넣기 위한 물리적인 조정이 계속필요하게 됨
- 데이터 분산이 일어나고, random I/O를 높여 read할때에도 성능이 떨어지게 된다.
4. secondary index왜 필요한가?
- examined되는 쿼리 양을 줄이기 위하여
- sort비용을 줄이기 위하여
- find max/min비용을 줄이기 위하여등등.
1. performance_schema 에서 알아내면 좋은 것들
- statement summary digest
- I/O 관련 지표들
- error일으킨것 없는지 (데드락)
2. 쿼리 플랜
- 옵티마이저: 쿼리 플랜을 짠 후 실행한다
- full scan: 바로 데이터 fetch. 작은 테이블인경우 유리
- covering index : 인덱스 탄 후 데이터 가져온다.
- 통계를 통해서 cost를 계산한다.
3. explain
- explain명령어 사용하여 해당 쿼리의 실행계획을 알아볼 수 있다
- format 옵션 = json사용하면 가장 자세하게 살펴볼 수 있다
- explain : 실행 계획을 추정한 결과치를 출력
- explain analyze : 실제로 실행한후 결과치를 출력
- 쿼리 성능최적화를 위한 단계별 전략!!
- 먼저 - 왜 쿼리 수행해서 response주기까지 시간이 걸리는지? 생각해보아야 한다.
- 어디에서 시간이 소요되는지 정보를 먼저 수집하는 것이다!
- 어떤 쿼리에서 시간이 많이 소요되는지를 performance_schema 에서 확인할 수 있다!!
- 잘모르겠을땐 일단 sum timer wait 기준으로 top 10 함 뽑아보면서 분석해보는 것이다.
- 아 이쿼리를 수행하기위하여. 이 만큼이나 많이 기다렷군!! 하고 되짚어볼수있게 된다.
1. MySQL은 세개의 레이어로 구성되어있다.
1) Utility Layer
- SQL문법에 어긋난것이 없는지 검사한다.
- 해당 테이블이나 컬럼이 실제로 존재하는지 체크한다.
- 쿼리를 실행하는 유저의 권한을 체크한다.
2) SQL Layer
- 쿼리 실행 최적의 계획을 계산한다.
- 옵티마이저의 영역!!
- 쿼리실행 통계를 구하고 cost가 낮은 계획을 선택, 실행할 쿼리를 조정한다.
3) Storage Engine Layer
- 실제로 쿼리를 실행한다.
- 스토리지 엔진에는 여러 종류가 있으며, 가장 general하게 사용되는 것은 InnoDB엔진이다.
- InnoDB엔진은 동시성제어에 뛰어난 가장 보편적인 MySQL엔진이다.
- 엔진의 종류는 쿼리실행에 영향을 미칠 수 있다. 특화된 다른 엔진들도 존재하지만 역시 보통은 InnoDB를 많이들 쓴다.
2. MySQL 쿼리는 결과를 바로바로 유저에게 쓰는것이아니라,일단 버퍼에 담아둔다음에 보낸다. 이것이 성능의 병목이 될수도 있다.
1. ftp서버쪽에서 vsftpd데몬을 실행. ftp의 pub라는 디렉토리가 ftp디렉토리로서사용되게된다
2. 클라이언트는 ip를 가지고 접속, anonymous유저로 접속할경우 id: ftp, 패스워드 없이 그냥 들어갈수있다
3. 특정 유저로 id, pw를 가지고 접속하여 해당 유저의 home디렉토리안에 있는 파일을 가져오고 쓸수있다.
4. /etc/vsftp.conf파일의 옵션(yes,no)를 수정하여 익명유저~로그인유저 등 읽기쓰기 권한을 다르게 설정할 수 있다.
5. 위 파일을 수정했으나 권한에러가 자꾸떠서 -> selinux설정을 변경한다.
setsebool -P ftpd_full_access=1
1. NFS관련 데몬들은 포트번호고정이 아니기때문에 우선 포트번호를 고정시켜준다
iptables관련서비스가 없어서
yum install -y iptables-services로 설치
yum install nfs-utils로 설치
2. 각종 환경설정파일들의 포트번호를 고정시켜준후
3. 방화벽 오픈
4. 서비스들 재시작
https://minidora.tistory.com/208 <<많은 참고가 되었다!!
systemctl restart rpcbind
systemctl restart nfslock
systemctl restart nfs
마운트할 폴더 지정해서 /etc/exports에 넣고
chmod로 권한 변경해서 클라이언트가 접근할수있도록한다
(아까 666으로 권한줬더니 해당 폴더 못들어가는 문제가 있었다 ㅋㅋ 777로 변경)
5. 클라이언트 쪽에서
마운트할 ip어드레스 지정하고 마운트할 위치 지정하면 . exports한 폴더안 파일들이 들어와있다!!! 놀라움~~~
6. 마운트한 폴더에 파일을 생성하고 수정하면. 서로 실시간으로 반영된다.. 클라이언트쪽이든 서버쪽이든. 마치 그 폴더로 하나로 이어진듯한.. 신기하다.
7. umount -l으로 마운트해제하면
클라이언트는 더이상 마운트폴더안 파일들을 확인할수없게된다
안에있던 파일내역들이 없어져있는것을 확인할수있다
permanent하게 바꾸고 싶다면 /etc/fstab을 수정하고 mount -a로 다시 모든것 마운트
df -h커맨드로 확인해보면 마운트지정폴더에 내용물이 있는것을 확인할수있다
!!
1. 일단 필요한 util들을 받아놓고
2. hostname설정
3. network-config설정에서 static 아이피 할당
4. 브릿지 네트워크 설정
5. /etc/hosts에서 도메인 네임설정
6. ping날려서 테스트.
---
telnet, ssh실험
- 방화벽 enable되어있을경우 telnet 했을때 먹히지 않는다.
- ssh로 접속하여 들어간다. (방화벽리스트에, ssh추가하기)
1. vpc를 만든다. = logical한 네트워크 공간. 한 네트워크 안에 있는 인스턴스끼리는 private ip로 소통할 수 있다.
2. subnet을 두개 생성하여 하나는 public subnet, 다른 하나는 private subnet으로 생성
3. 라우팅 테이블에 각각의 서브넷을 붙여준다.
4. 인터넷게이트웨이를 vpc에게 할당한 후, public 서브넷에 해당 인터넷 게이트웨이를 붙여준다.
5. NAT 게이트웨이를 private서브넷에 할당한다. (private이 인터넷으로 outbound통신할 수 있게끔.)
6. public, private에 각각 인스턴스를 생성한다. 이때 public instance는 public IP자동할당을 선택하지만 private instance에는 할당하지 않는다. 그러므로 외부에서 직접적으로 private에 접근하는 것이 불가능하다.
7. private instance의 보안그룹을 편집, 모든트래픽 - src에 public instance의 보안그룹ID를 넣어준다.
8. public instance에 ssh로 접속한후 private instance 에 Ping테스트를 해본다.
성공!!
- sentinel : 레디스 모니터링 프로세스
1. aws에 세대의 인스턴스 설치
1) master + sentinel
2) slave + sentinel
3) slave + sentinel
https://velog.io/@ssoop/AWS-EC2%EC%97%90-Redis-%EC%84%A4%EC%B9%98
<<요기를 참고해서설치했다!!
2. redis.conf 및 sentinel.conf설정하기
- 특히 중요한것 : replicaof 설정해서 slave로 만들기
서로다른 conf 파일을 만들어서. log, dbdump, port번호,
replicaof 설정을 통해서 slave를 만든다
src/redis-server redis.conf&
해당 conf로 실행
마스터에만 넣은 데이터를 slave에서도 확인할 수 있다
slave는 read-only이기때문에 넣으려고 하면 에러를뿜뿜
아주좋군~
1. 람다
- 사용이유 : 서버없이 코드실행이 가능, 실행된 만큼만 과금된다는 장점
- 어떤 작은 코드를 실행하기위해서 서버를 24시간 켜놓는 것보다, 해당 이벤트가 발생했을때 트리거로 작동하도록 하여 - 비용을 줄일수있다는 것이다. serverless ..
2. cloudfront
- CDN서비스 . 멀리있는 사용자도- 마치 자기 앞에있는것처럼 빠르게 콘텐츠를 다운로드 할 수 있게 된다.
- 원본 콘텐츠와의 동기화 주기를 어느정도로 할 것인지 생각해야 한다.
3. cloudWatch
- 로그 기록하는 서비스
4. S3
- 파일 저장 스토리지. 동적인 페이지는 어플리케이션에서 보여주고, 정적인 페이지는 S3에서 관리하도록 할 수 있다. 미디어 파일같이 용량이 큰 정적 파일들만 따로. 저장에 특화된 서비스를. 일일이 EC2 볼륨 늘려서 생성하지 않고 더욱 저렴한 비용으로 . 어플리케이션 안에있는 스토리지 (volumn)과 달르게 운영할 수 있어서 어플리케이션 용량은 가볍게 유지하고 따로 파일 스토리지로서 이미지나 커다란 콘텐츠 저장이 가능
5. glacier
- 아카이빙, 즉 백업서비스
- 백업해두었다가 retrieve할때 비용발생
6. EFS
- Network File System서비스
- 다른 서버에 있는 데이터를 마치 내 디스크에 있는것처럼 네트워크를 통해 사용이 가능하다. (mount 해서)
7. KMS서비스
- 데이터의 encryption을 해주는 서비스.
- ALB : 7계층에서 동작 . spring의 api-gateway역할과 유사
- NLB : 4계층에서 동작. 빠르다(url등 안봄. 포트번호 , ip만 본다)
- ELB: elastic load balancer : dns가 ip주소로 바꾸고 -> lb한테 보내고 -> auto-scaling정책에 따라서 인스턴스를 등록하고 없애고한다
- scale out, scale in정책을 세워야 함 (언제, 어떻게 auto-scale할것인가.)
- scale in할때, data loss가 없어야 함. app서버의 경우 데이터를 인스턴스자체에 저장하지 않으므로 (stateless) auto-scale의 대상에 적절하다.
- 이를테면, cpu utilization이 80퍼센트 이상이면 인스턴스를 늘린다던지.
- launch configuration을 통해서 어떤 타입 어떤 구성의 인스턴스를 늘릴것인지 미리 정해둔다.
- minimum instance사이즈, maximum인스턴스 사이즈 등 auto-scale policy가 있어야 한다.
1. security group
- 개개의 인스턴스에 설정
- ALLOW 온리이다
2. network ACL
- 서브넷 단위로 설정 (그러므로, 어떤 서브넷에 적용할 것인지 붙여줘야 한다 )
- allow, deny 설정
- 번호 순번대로 평가된다.
3. 공통점 : 어떤 port를 어떤 ip대역에 개방할 것인지 결정하는 보안 설정이다.
1. VPC : cloud에서 제공하는 네트워킹서비스. Amazon Virtual Private Cloud(Amazon VPC) , 사용자가 정의한 가상 네트워크
2. 물리적인 네트워킹은 AWS가 알아서 제공하고, 논리적인 네트워킹을 VPC라는 서비스를 통해서 제공한다.
3 .Region 이 있고, 그안에 ZONE이 있고, VPC로 나누고(네트워킹) , 서브넷팅하고, ACL(일종의 방화벽) 인바운드 아웃바운드를 편집하고, security group 으로 또 인바운드 아웃바운드를 편집한다. ACL과 security group 은 역할은 비슷하지만 security group은 ACL안에서 동작한다 (ACL이 먼저 거른다.)
4. VPC내부에 있는 인스턴스끼리는 자유롭게 커뮤니케이션이 가능하다. private ip로 소통, 같은 네트워크 대역에 있기 때문이다.
5. VPC외부(이를테면 인터넷) 와 소통하기 위해서는 public ip가 필요. 이것을 위한 라우팅 테이블이 있으며internet gateway를 통과 한다.
6. 외부의 클라이언트가 VPC내부의 인스턴스에 접근하기 위해서는 public ip 를 가지고 internet gateway를 이용하여 소통한다.
7. 서로다른 VPC끼리 (즉, 서로다른 network)소통하기 위해서는 라우팅 테이블에 해당 vpc의 네트워크 id를 서로 등록해 주어야 한다.
8. private ip만 가지고 있는 호스트가 바깥 인터넷과 연결하기위해서는 Network access transfer하는 NAT게이트웨이가 필요하다
1. 보안그룹
- 일종의 방화벽, 어떤 port를 허용할 것인지 를 지정 (인바운드, 아웃바운드)
- 어떤 port의 요청을 허용할것인지 - ufw랑 역할 비슷한듯
- 아웃바운드는 기본적으로 all이다
2. 많이 허용하는 포트 : 22, 443, 80, 53(DNS서버) , 21 (FTP) 가 있다.
3. 보안 그룹을 유동적으로 설정하고 tag하여 이름 붙일 수 있다.
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하면 해당 컴퓨터를 완전히 제외시키며 데이터 복구가 불가능하다.
1. 먼저 전세계를 region 으로 나누고
2. region을 zone으로 나눈다 . 실제로 물리적인 서버(하드웨어) 장비가 위치하게 된다.
3. zone은 region안에서 독립된 위치에 있지만 서로 네트워킹이 가능
4. 이렇게 zone을 나눈 이유는 쓰나미같은 자연재해 등에서 발생할 물리적 피해를 예방하기 위해서이다
5. region과 zone에는 각각의 네이밍 label이 붙여져서 존재
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방식을 고려해 볼 수 있다.
간단한 Fruit클래스 만든 후 redis-cli로 테스트
- ttl 설정해두었기 때문에 해당 시간이 지나가면 자동으로 삭제된다
- id 랜덤하게 생성되어 들어가 있음.
- type으로 해쉬자료구조임을 확인
- hash 자료구조로 특정 필드만 조회할수도 있고 모든 필드를 위와같이 조회할 수도 있다
- semebers로 set의 모든 멤버를 확인한다
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하는 것을 확인할 수 있다.
https://shanepark.tistory.com/195 <<많은 도움을 받은 글!!
키 생성 후 pub 키를 scp명령어로 보낸후
원격지 서버에 authorized_keys 파일을 생성하여 실행권한을 주고 해당 pub키 파일 내용을 복사 붙여넣기하면 끝!! 아주 간단!!
이제 비밀번호보다도안전하게 접속이 가능하다!
