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 함 뽑아보면서 분석해보는 것이다.
- 아 이쿼리를 수행하기위하여. 이 만큼이나 많이 기다렷군!! 하고 되짚어볼수있게 된다.
