테코톡 정리

유투브에서 재미있는 채널을 발견해서 정리합니다.

 

Proxy

Proxy 서버 대신 처리하는 서버, 클라이언트와 서버 사이에 있는 중계 서버, 캐시 / 보안 / 트래픽 분산의 이점이 있음

• Forward proxy 
  일반적으로 말하는 proxy
  클라이언트 - 포워드 프록시 - 인터넷 - 서버에 위치
  캐싱에 이점이 있다.
  서버에 포워드 프록시가 요청한 것 처럼 요청이 가기 때문에 익명성에 이점이 있다.
  ex. 프록시 서버를 설정한다.
  ex. 해커가 IP 추적 방지를 위해 프록시를 썼다.
  ex. 외국에서 접속하는 것 처럼 테스트하기 위해 프록시 서버를 써라
  ex. 인터넷 서버 속도를 높이기 위해 프록시 서버 설정을 해줘라
• Reverse proxy
  클라이언트 - 인터넷 - 리버스 프록시 - 서버에 위치
  포워드 프록시 처럼 캐싱에 이점이 있고
  서버 정보를 클라이언트에게 숨길 수 있으므로 보안적으로 좋다. 클라이언트는 리버스 프록시가 실제 서버인 것 처럼 통신한다.
  로드 밸런싱 (하기도하고 안하기도함)

 

L4 로드밸런서 : 특정 도메인으로 접근할 때 아무 서버로 로드밸런싱하는 형태
L7 로드밸런서 : 어플리케이션 레벨에서 로드밸런싱 ex. 특정 도메인의 path 나 query param 에 따라 담당 서버로 로드밸런싱하는 형태

 

DTO vs VO

• DTO
  레이어간의 데이터 전달 객체
  getter 외 메소드 x 정렬, 직렬화등 데이터 표현을 위한 기능은 가질 수 있다
• VO 
  값 자체로 의미를 가지는 객체 변하지 않는 값을 가진다. 
  값이 변하지 않음을 보장하여 코드의 안전성과 생산성을 높인다. 
  값이 같다면 동일한 객체 따라서 ID 가 없다. 
  비즈니스 로직을 가질 수 있다.

 

스프링 부트

스프링이 스프링인 이유 : 개발자들의 겨울이 끝났다.

스프링 부트의 철학 : 단독적인 상용화 수준의 어플리케이션을 쉽게 만든다.

간편한 설정 편리한 의존성 관리 내장 서버로 jar 파일로 간단히 배포 가능

 

인덱스

• Clustered index
  군집화된 인덱스
  순서대로 정렬된 인덱스라 범위 검색할 때 아주 강력 대신 데이터를 사이에 추가되면 성능에 최악이다.
  (뒤에 있는 데이터를 하나씩 전부 shift 해줘야 한다.)
  
  PK 는 Clustered index 라고 보면된다. 
  그래서 존재하는 PK 사이에 데이터를 insert 할 경우 대참사가 발생한다. 
  그래서 auto increment 로 PK 를 지정한다. (email 같은걸 PK 로 하면 안된다.)
• Non-clustered index
  순서와 상관없이 저장된 인덱스
  약한 참조 관계로 되어있다.
  
  일반적인 인덱스가 non-clustered index 라고 보면 된다.
  순서에 상관이 없으며 한 테이블에 여러 개를 만들 수 있다.
  대신 약 10% 의 추가 저장공간이 필요하다.
  clustered index 만큼은 아니지만 insert 시 추가 작업이 필요하다.
• 찾아보면 좋은 내용
  B-tree
  Page in InnoDB
  innodb_buffer_pool_size
  log_throttle_queries_not_using_indexes

 

데이터 지역성의 원리

시간 지역성 : for 문에 i 는 계속 사용될 것이다.
공간 지역성 : for 문에서 주로 접근하는 배열이 있다면 이것은 계속 쓸 것이다.
순차 지역성 : for 문에서 array[0] array[1] array[2] 를 접근했다면 그 다음은 array[3] 에 접근할 것이다.

 

HTTP

기본적으로 Http 에는 어떤 전송 계층 프로토콜을 사용해도 상관없으나 일반적으로 TCP 를 사용한다.

• Http 1.0
  요청 하나당 응답 하나
  요청 마다 connection 을 만들어서 성능이 저하됨
• Http 1.1 
  Persistent connection 지정한 timeout 동안 커넥션을 닫지 않는 방식 
  Pipelining 으로 요청을 순차적으로 그냥 연속해서 보내고 응답을 받아서 알아서 순서대로 다시 조합하는 방식 Head of line blocking 문제가 존재 TCP 성능 면에서 근본적인 문제 해결이 되지 못함
• Http 2.0 
  Binary framing 구조화된 계층을 사용해서 파싱, 전송 속도를 높이고 오류를 낮췄다. 
  Server push 로 어차피 보내줘야 할 것으로 예상되는 파일을 (ex. 이미지, css 파일) 미리 서버가 준다. 
  Header compression 
  Stream 의 도입으로 멀티 플렉싱을 지원 
  Stream priority 로 응답 우선순위를 정할 수 있게했다. 
  Http 1.1 에서 발생하던 Head of line blocking 문제를 해결 (하지만 TCP 에 존재하는 Head of line blocking 문제는 존재)
• Quic 
  UDP 기반의 전송 계층 프로토콜 
  구글에서 개발 연결 성공시 Connection UUID 를 가지고 있다가 새로운 연결 요청이 오면 connection 연결 수립 과정을 생략한다. 
  TLS 지원 
  IP spoofing 이나 Replay attack 방지 
  독립된 스트림으로 멀티 플렉싱 지원
• Http 3 
  Quic 기반의 Http 
  Quic 의 독립된 스트림 덕분에 TCP 에서 발생하던 Head of line blocking 문제를 해결

 

리눅스 메모리

youtu.be/OPdjLaW0flU

 

메모리 오버레이 : 프로그램의 크기가 실제 메모리 보다 클 때 적당한 크기로 잘라서 가져오는 기법. 나머지는 가상 메모리에 저장 되어있는다.
vmstat 메모리 모니터링

• swap-in, swap-out 을 유의깊게 봐라 가상 메모리에서 메모리가 스왑되면서 메모리가 성능에 영향을 끼치고 있는 것을 의미한다.
• memory swpd : 사용하고 있는 가상 메모리의 양
• memory free : 사용 가능한 메인 메모리의 양
• memory buff / cache : 파일 I/O 작업을 메모리에 올리기 위해 사용되는 공간

 

WS, CGI, Servlet, WAS, Spring

• WS
  Web (정적 페이지) Server. (ex. apache)
• CGI 
  동적 웹페이지를 만들고 싶은데 WS 만으로는 부족하다. 
  HTML 은 Application 이 아니다. → 다른 방법을 찾기 시작 
  웹서버와 Application 사이에 통신 규약을 만들어서 Application 의 결과를 렌더링하자.
  
  즉 WS 위에서 동적 웹페이지를 만들기위해 처리하는 인터페이스
  요청이 들어올 때마다 Process 를 만드는 방식으로 만들어졌다.
  게다가 요청마다 구현체를 만들어주었어서 비효율적이였다.
  Servlet CGI 의 규칙을 따르지만 CGI 가 가지던 문제를 해결하고자 나섬.
  Process 사용에서 Thread 사용으로 바꾸고 구현체를 싱글톤으로 바꿈
• WAS 
  Web Application (동적 페이지) Server. (ex. tomcat) 
  웹서버로 요청이 들어오면 웹 컨테이너(서블릿 일 경우 서블릿 컨테이너)를 통해 스레드를 만들고 Servlet 구현체의 메소드를 실행 시켜주는 역할
• Spring
  기존의 Servlet 방식에서는 Url 마다 Servlet 을 만들어 줬어야함.
  Spring Web MVC 에서는 Dispatcher servlet 하나로 처리

 

Sharding / Clustering / Replication

공통 목표 : 데이터 베이스를 여러개로 만든다.

• DB : Databse server + Database storage
• Clustering : Database server 를 여러개로 만들자.
  1. Active - Active
  2. Active - Standby
• Replication : Database storage 의 손실 방지, 복제하자
• Sharding : 테이블을 나눈다.
  어떻게 잘 분산시켜서 저장할 것인가?
  분산된 데이터를 어떻게 읽을 것인가?
• Shard key
  Hash sharding : 해시 함수 기반의 샤드키 생성 방식
  Dynamic sharding : id range 기반의 샤드키 생성 방식
  Entity group : hash, dynamic shard 는 RDB 에는 다소 부적합, Entity group 는 관계를 중심으로 샤드키 생성

 

가비지 콜렉션

GC 의 기본 가정

1. 객체는 금방 garbage 가 된다.
   
2. 오래된 객체에서 새로운 객체로의 참조는 상대적으로 적다.

youtu.be/vZRmCbl871I

 

트랜잭션

트랜잭션 격리 수준 : 동시에 DB 에 접근할 때 어떻게 접근할 것인가

• READ-UNCOMMITTED
  동시성 (성능 Up)
  격리 수준이 낮음
  커밋 전의 트랜잭션 값을 다른 곳에서 읽을 수 있음 
  [o] Dirty read 
  [o] Non-repeatable read 
  [o] Phantom read
• READ-COMMITTED
  커밋이 완료된 값만 다른 곳에서 읽을 수 있음
  [x] Dirty read 
  [o] Non-repeatable read 
  [o] Phantom read
• REPETABLE-READ
  한 트랜잭션이 조회한 데이터는 일관된 값만 반환하도록 한다.
  [x] Dirty read 
  [x] Non-repeatable read 
  [o] Phantom read
• SERIALIZABLE
  데이터 정합성 (성능 down)
  한 트랜잭션이 사용하는 데이터를 다른 트랜잭션에서 접근 불가
  성능은 떨어지지만 ACID 를 모두 만족한다.

트랜잭션 격리 수준에 따라 발생할 수 있는 현상

• Dirty read :  커밋 되지 않은 값인데 다른 곳에서 읽힌다.
• Non-repeatable read : 하나의 트랜잭션인데 같은 쿼리 결과가 다르게 반환 될 수 있다.
• Phantom read : Non-repeatable read 의 한 종류, 데이터가 새로 생성되거나 삭제 될 수 있다.

 

트랜잭션 어노테이션의 전파타입

1. REQUIRED 진행중인 트랜잭션이 있으면 그대로 사용, 없으면 새로운 트랜잭션 생성
2. MANDATORY 진행중인 트랜잭션이 있으면 그대로 사용, 없으면 에러 발생
3. REQUIRES_NEW 진행중인 트랜잭션이 있으면 보류하고 새로 생성, 없으면 새로운 트랜잭션 생성
4. SUPPORTS 진행중인 트랜잭션이 있으면 그대로 사용, 없으면 없이 진행
5. NOT_SUPPORTED 진행중인 트랜잭션이 있으면 보류, 없으면 새로운 트랜잭션 생성
6. NEVER 진행중인 트랜잭션이 있으면 에러 발생, 없으면 없이 진행
7. NESTED 진행중인 트랜잭션이 있으면 새로운 트랜잭션으로 중첩 진행, 없으면 새로운 트랜잭션 생성

 

ETC

• Library 와 Framework 의 차이점은 응용 프로그램의 흐름 주도권을 누가 가지고 있느냐
• 빌드 : 컴파일 + 링크
• 빌드 도구 : 소스 코드로 부터 실행 가능한 어플리케이션을 생성하는 것을 자동화하는 프로그램 ex. maven, gradle
• OCP 위반을 해결하기 위한 패턴이 전략 / 템플릿 메소드 패턴이다. 
  상속으로 해결한 것이 템플릿 메소드 패턴이고 Composition 으로 해결한 것이 전략 패턴이다.
• search.naver.com 에서 naver.com 은 도메인이고 search 는 host 이며 search.naver.com 은 FQDN 이다.
  cafe.naver.com 에서 naver.com 은 도메인이고 cafe 는 host 이며 cafe.naver.com 은 FQDN 이다.