[최은수] 데이터 중심 애플리케이션 설계 1주차, 6주차 정리

2024-designing-data-intensive-applications/최은수/1장.md

@@ -0,0 +1,24 @@
+### 애플리케이션이 유용하기 위해 충족시켜야하는 요구사항
+## 기능적 요구사항
+- 여러 방법으로 데이터를 저장하고 조회하고 검색하고 처리하게끔 허용하는 작업 등
+## 비기능적 요구사항
+- 보안
+- 신뢰성
+- 법규 준수
+- 확장성
+- 호환성
+- 유지보수성
+
+
+### 신뢰성
+> 결함이 발생해도 시스템이 올바르게 동작하도록 만드는 것
+- 내 결함성 기술은 최종 사용자에게 특정 유형의 결함을 숨길 수 있게 해줌
+
+### 확장성
+> 부하가 증가해도 좋은 성능을 유지하기 위한 전략
+- 성능 측정 방법 : 응답 시간 백분위
+
+### 유지보수성
+> 엔지니어와 운영 팀의 삶을 개선
+- 좋은 추상화는 복잡도를 줄이고 시스템 변경을 쉽게 만든다
+- 좋은 운용성이란 시스템의 건강상태를 잘 관찰 할 수 있고 시스템을 효율적으로 관리하는 방법을 보유한다는 의미

2024-designing-data-intensive-applications/최은수/2장.md

@@ -0,0 +1,22 @@
+### 다양한 종류의 데이터 모델
+## 계층 모델
+- 하나의 큰 트리 모양
+- 다대다 관계 표현에 적절하지 않음
+
+## 네트워크 모델
+- 코다실 모델이라고도 불림
+- 계층모델을 일반화
+
+## 관계형 모델
+- 적합하지 않은 애플리케이션이 있음
+
+## 비관계형 데이터 저장소 NoSQL
+- 문서 데이터베이스
+  - 데이터가 문서 자체에 포함되어있으면서 하나의 문서와 다른 문서 간 관계가 거의 없는 사용사례를 대상으로 함
+- 그래프 데이터베이스
+  - 모든 것이 잠재적으로 관련 있다는 사용 사례를 대상으로 함
+
+### 쓰기 스키마(schema-on-write)
+- 관계형 데이터베이스의 전통적인 접근 방식으로 스키마는 명시적이고 데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장한다
+- 반대되는 읽기 스키마(schema-on-read)
+  - 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석된다

2024-designing-data-intensive-applications/최은수/8장.md

@@ -0,0 +1,94 @@
+# 분산 시스템의 골칫거리
+
+> 비관주의를 최대한으로 끌어올려 어떤 것이든지 잘못될 가능성이 있다면 잘못된다 고 가정한다
+
+## 결함과 부분 장애
+- 한 컴퓨터
+  - 상당히 예측 가능한 방식으로 동작
+  - 돌아가거나 안돌아가거나
+- 네트워크로 연결된 여러 컴퓨터
+  - 이상화된 시스템 모델에서 동작하지 않음
+  - 어떤 부분은 잘 동작하지만 다른 부분은 그렇지 않음
+    - 부분 장애 라고 부름
+    - 비결정적
+  - 부분 장애 가능성과 비결정성 때문에 분산 시스템이 다루기 어려움
+
+## 클라우드 컴퓨팅과 슈퍼 컴퓨팅
+
+고성능 컴퓨팅
+- 보통 가끔씩 계산 상태를 지속성 있는 저장소에 체크포인트로 저장
+- 노드 하나에 장애 발생 -> 전체 클러스터 작업 부하 중단 -> 장애가 발생한 노드가 복구된 후 마지막 체크 포인트부터 계산 재시작
+- 분산 시스템보다는 단일 노드 컴퓨터에 가까움
+- 부분 장애를 전체 장애로 확대
+
+크라우드 컴퓨팅
+
+
+## 신뢰성 없는 네트워크
+해당 책의 분산 시스템 = 비공유 시스템, 네트워크로 연결된 다수의 장비
+인터넷과 데이터센터 내부 네트워크는 비동기 패킷 네트워크
+- 메세지 도착 보장하지 않음 : 타임아웃으로 문제를 다룸
+
+## 타임아웃과 기약 없는 지연
+타임아웃만이 결함을 감지하는 확실한 수단이라면 타임아웃은 얼마나 길어야할까?
+
+타임아웃이 길면 : 기다리는 시간 길어짐
+타임아웃이 짧으면 : 결함 빨리 발견 가능, BUT 일시적 느림도 죽었다고 잘못 선언할 수 있음
+
+노드가 실제로 살아있는데 죽었다고 선언하면 동작이 두번 실행될수 있기 때문에 문제가 될 수 있다.
+
+패킷이 d 시간내에 전송되거나 손실되고, 장애가 나지 않은 노드는 항상 요청시간을 r 시간 내에 처리한다고 보장하면
+성공한 요청은 모두 2d+r 시간 내에 응답받음. 즉 2d+r을 타임 아웃으로 사용
+
+그렇지만 우리가 사용하는 시스템은 어떤것도 보장하지 않음. 기약없는 지연
+
+## 네트워크 혼잡과 큐 대기
+컴퓨터 네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많다.
+TCP VS UDP
+실험적으로 타임아웃을 선택할 수밖에 없다.
+지연 변동성을 알아내기 위해선 여러 장비에 걸쳐서 긴 기간에 네트워크 왕복 시간의 분포를 측정해야함
+더 좋은 방법
+- 고정된 타임아웃 대신 시스템이 지속저으로 응답시간과 변동성을 측정하고 관찰된 응답 시간 분포에 따라 타임아웃을 자동으로 조절하게 하는 것
+
+## 동기 네트워크 대 비동기 네트워크
+패킷 전송 지연 시간의 최대치가 고정되어있고 패킷을 유실하지 않는 네트워크에 기댈 수 있다면 분산 시스템 간단해짐!
+왜 하드웨어 수준에서 네트워크를 신뢰성있게 만들어서 소프트웨어의 걱정 덜어주지 않는걸까?
+
+전화 네트워크와의 비교
+- 극단적 신뢰성
+- 동기식
+- 제한있는 지연
+
+전화 네트워크의 회선은 고정된 양의 예약된 대역폭이지만, tcp는 가용한 네트워크 대역폭을 기회주의적으로 사용
+데이터센터 네트워크와 인터넷은 순간적으로 몰리는 트래픽에 최적화를 위해 패킷을 사용함
+회선은 통화를 하는 동안 초당 비트 수가 고정되어있는 음성과 영상통화에 적합
+웹페이지 요청, 이메일 전송, 파일 전송은 특별한 대역폭 요구사항이 없음. 
+
+## 단조 시계 대 일 기준 시계
+현대 컴퓨터는 최소 두 가지 종류의 시계를 가지고 있음
+
+일 기준 시계
+- 직관적으로 시계에 기대하는 일을 함
+
+단조 시계
+- 타임아웃이나 서비스 응답시간과 같은 지속 시간을 재는데 적합
+
+잘못된 시계에 대비할 필요가 있다.
+
+## 부산 시스템의 실체
+정족수
+- 노드는 언제든지 장애가 날 수 있고, 노드 자신이 살아있다고 잘못 판단하는 경우도 있음
+- 분산 알고리즘은 노드들간의 투표에 의존한다
+
+리더와 잠금
+- 그러나 완전히 신뢰 불가능
+
+비잔틴 문제
+- 비잔틴 결함
+- 비잔틴 장군 문제
+- 비잔틴 내결함성
+
+
+## 알고리즘
+- 시간 : 동기식, 비동기식, 반동기식
+- 노드 결함 : 죽으면 멈추는, 죽으면 복구하는, 비잔틴 결함

2024-designing-data-intensive-applications/최은수/9장.md

@@ -0,0 +1,105 @@
+# 일관성과 합의
+
+## 일관성 보장
+복제 데이터베이스는 대부분 최소한 최종적 일관성을 제공
+그러나 언제 복제본이 수렴될지는 아무것도 보장하지 않음
+
+## 선형성
+시스템에 데이터 복제본이 하나만 있으면 더 단순하지 않을까
+
+최신 보장성
+
+선형성 대 직렬성
+- 직렬성 : 트랜잭션들의 격리 속성, 직렬성은 각 트랜잭션들이 어떤 순서에 따라 실행되는 것처럼 동작하도록 보장 
+- 선형성 : 개별 객체에 실행되는 읽기와 쓰기에 대한 최신성 보장
+
+## 선형성에 기대기
+잠금과 리더 선출
+- 단일 리더 복제 시스템은 리더가 하나만 존재하도록 보장해야 한다. 
+- 이를 구현하는 한가지 방법은 잠금을 사용하는 것이고, 이는 어떻게 구현하든지 선형적이어야 한다.
+
+제약 조건과 유일성 보장
+- 유일성 보장 조건은 데이터베이스에서 흔하다.
+- 이 제약 조건을 강제하고 싶다면 선형성이 필요하다.
+
+채널 간 타이밍 의존성
+- 선형성 보장이 없으면 두 채널 사이에 경쟁 조건이 발생할 수 있다.
+
+## 선형성 시스템 구현하기
+가장 간단한 해답은 데이터 복사본을 하나만 사용하는 것이다.
+하지만 이 방법으로는 결함을 견뎌낼 수 없다.
+
+단일 리더 복제
+- 리더는 쓰기에 사용되는 데이터의 주 복사본을 갖고 있고 팔로워는 데이터의 백업 복사본을 보관한다.
+- 리더나 동기식으로 갱신된 팔로워에서 실행한 읽니는 선형적이 될 가능성이 있다.
+- 그러나 모든 단일 리더 데이터베이스가 선형적인 것은 아니다
+
+합의 알고리즘
+- 단일 리더 복제를 닮음
+- 스플릿 브레인과 복제본이 뒤처지는 문제를 막을 수단이 포함
+- 이런 세부 사항 덕에 선형성 저장소를 구현할 수 있다.
+
+다중 리더 복제
+- 일반적으로 선형적이지 않다.
+
+리더 없는 복제
+- 정족수 읽기와 쓰기로 일관성을 달성할수 있다고 주장
+- 정족수의 설정에 따라, 엄격한 일관성을 어떻게 정의하느냐에 따라 다를 수 있다.
+
+
+## 순서화 보장
+
+선형성 레지스터는 데이터 복사본이 하나만 있는 것처럼 동작하고, 모든 연산이 어느 시점에 원자적으로 효과가 나타나는 것처럼 보인다고 했다.
+이는 연산들이 잘 정의된 순서대로 실행 된다는 것을 암시한다.
+
+### 순서화와 인과성
+
+순서화는 인과성을 보존하는 데 도움을 준다.
+인과성은 이벤트에 순서를 부여한다. 
+이는 무엇이 무엇보다 먼저 일어났는가를 정의한다.
+시스템이 인과성에 의해 부과된 순서를 지키면 그 시스템은 인과적으로 일관적 이다
+
+선형성 vs 인과성
+- 선형성 : 연산의 전체 순서를 정할 수 있다.
+- 인과성 : 두 이벤트에 인과적인 관계가 있으면 순서가 있지만, 동시에 실행되면 비교할 수 없다. 전체 순서가 아닌 부분 순서를 정의한다. 어떤 연산들은 서로에 대해 순서를 정할 수 있지만 어떤 연산들은 비교할 수 없다
+
+선형성은 인과성을 포함한다.
+어떤 시스템이던지 선형적이라면 인과성도 올바르게 유지한다.
+많은 경우에 선형성이 필요한 것처럼 보여도 사실 진짜 필요한 것은 인과적 일관성이다.
+
+### 인과적 의존성 담기
+
+인과성을 유지하기 위해 어떤 연산이 다른 연산보다 먼저 실행됐는지 알아야 한다.
+전체 데이터베이스에 걸친 인과정 의존성을 추적해야 하고, 이를 위해 버전 벡터를 일반화해 사용한다
+
+단일리더 시스템이라면, 일련번호나 타임스탬프를 써서 이벤트의 순서를 정할 수 있다.
+이런 일련번호나 타임스탬프는 크기가 작고 전체 순서를 제공한다.
+특히 인과성에 일관적인 전체 순서대로 일련번호를 생성할 수 있다.
+
+단일리더가 아니라면, 위와 같은 방법이 가능해보이지않아 다른 여러 방법을 사용한다.
+- 각 노드가 자신만의 독립적인 일련번호 집합을 생성한다
+- 각 연산에 일 기준 시계 타임스탬프를 붙인다
+- 일련번호 블록을 미리 할당한다
+- 이런 방법들은 잘 동작하지만 생성한 일련번호가 인과성에 일관적이지 않다.
+
+## 램포트 타임스탬프
+## 전체 순서 브로드캐스트
+두 가지 안전성 속성을 항상 만족해야 한다
+- 신뢰성 있는 전달 : 어떤 메시지도 손실되지 않는다. 메시지가 한 노드에 전달되면 모든 노드에도 전달된다
+- 전체 순서가 정해진 전달 : 메시지는 모든 노드에 같은 순서로 전달된다
+
+노드나 네트워크에 결함이 있더라도 신뢰성과 순서화 속성이 항상 만족되도록 보장해야 한다.
+전체 순서 브로드캐스트의 중요한 측면은 메시지가 전달되는 시점에 그 순서가 고정된다는 것이다.
+이 사실 때문에 전체 순서 브로드캐스트가 타임스탬프 순서화보다 강하다.
+
+## 분산 트랜잭션과 합의
+
+합의는 분산 컴퓨팅에서 가장 중요하고 근본적인 문제중 하나다.
+합의의 목적은 여러 노드들이 뭔가에 동의하게 만드는 것이고, 겉으로 보기에 간단해 보인다.
+노드가 합의하는 것이 중요한 상황은 여러가지가 있다
+
+- 리더 선출
+- 원자적 커밋
+
+
+### 원자적 커밋과 2단계 커밋

2024-http-the-definitive-guide/최은수/14장.md

@@ -0,0 +1,90 @@
+## 14장 보안 HTTP
+
+### HTTP를 안전하게 만들기
+> 서버인증, 클라이언트 인증 , 무결성, 암호화, 효율, 편재성, 관리상 확장성, 적응성, 사회적 생존성을 제공하는 HTTP 보안 기술이 필요하다
+- HTTPS
+  - 요청과 응답이 네트워크로 보내지기전 암호화
+  - HTTP 하부에 전송 레벨 암호 보안 계층을 제공하면서 동작함
+  - 보안계층 = 안전 소켓 계층 (SSL), 전송 계층 보안(TLS)
+### 디지털 암호학
+> 암호, 키, 대칭키 암호 체계, 비대칭키 암호 체계, 공개키 암호법, 디지털 서명, 디지털 위증서
+- 비밀 코드의 기술과 과학
+- 암호
+- 암호 기계
+- 키가 있는 암호
+  - 코드 알고리즘과 기계가 적의 손에 들어가더라도 올바른 다이얼 설정(키 값)이 없으면 디코딩 못함
+- 디지털 암호
+### 대칭키 암호법
+- 키 길이와 열거 공격
+  - 대부분의 경우 인코딩/디코딩 알고리즘은 알려져있으므로 키가 중요
+  - 무차별적으로 모든 키 값을 대입하는 공격 = 열거공격
+- 공유키 발급하기
+  - 대칭키 암호의 단점 : 발송자와 수신자가 둘 다 공유키를 가져야함
+  - 관리자 입장에서 힘듬
+### 공개키 암호법
+> 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용 X
+> 공개키 암호법은 두 개의 비대칭 키를 사용 (인코딩을 위한 키(공개), 디코딩을 위한 키(비공개, 호스트만 알고 있음))
+- RSA
+  - 공개키, 가로채서 얻은 암호무의 일부, 메시지와 그것을 암호화한 암호문을 알더라도 비밀인 개인 키 계산 X
+  - 위를 만족하는 공개키 암호 체계 중 하나가 RSA
+- 혼성 암호 체계와 세션 
+  - 공개키 알고리즘은 계산이 느리다
+  - 노드들 사이의 안전한 의사소통 채널 수립 = 공개키
+  - 만들어진 채널을 통해 임시의 무작위 대칭 키 생성/교환 -> 데이터 암호화 = 대칭키 사용
+### 디지털 서명
+- 서명은 암후 체크섬이다
+  - 서명은 메세지를 작성한 저자가 누구인지 알려줌
+  - 서명은 메시지 위조를 방지한다
+  - 디지털 서명은 보통 비대칭 공개키에 의해 생성됨
+  - ![img_3.png](img_3.png)
+### 디지털 인증서
+디지털 인증서(흔히 certs라고 불림)는 신뢰할 수 있는 기관으로부터 보증받은 사용자나 회사에 대한 정보를 담고 있음
+- 인증서의 내부
+  - 공식적으로 '인증 기관'에 의해 디지털 서명된 정보의 집합이 담겨있음
+  - 대상의 이름, 유효 기간, 인증서 발급자, 인증서 발급자의 디지털 서명, 대상에 사용된 서명 알고리즘에 대한 정보, 대상의 정보키
+- 서버 인증을 위한 인증서 사용하기
+### HTTPS의 세부사항
+> HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한것
+- HTTPS 개요
+  - HTTPS는 암호화되지 않은 HTTP메세지를 TCP를 통해 보내기 전에 그것을 암호화 하는 보안계층으로 보내는것.
+  - ![img_4.png](img_4.png)
+- HTTPS 스킴
+  - 만약 URL이 http 스킴을 가지고 있다면 클라->서버에 80번 포트로 연결, 평범한 HTTP 명령
+  - 만약 URL이 https 스킴을 가지고 있다면 클라->서버에 443번 포트로 연결, SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고 암호화된 HTTP 명령
+- 보안 전송 셋업
+  - HTTPS에서， 클라는 먼저 웹 서버의 443 포트(보안 HTTP 기본포트)로 연결한다.
+  - 일단 TCP 연결이 되고 나면， 클라와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다.
+  - 핸드셰이크가 완료되면 SSL 초기화는 완료되며， 클라는 요청 메시지를 보안 계층에 보낼 수 있다. 
+  - 이 메시지는 TCP로 보내지기 전에 암호화된다
+- SSL 핸드셰이크
+  - 암호화된 HTTP 메세지를 보내기 전, 클라와 서버는 SSL 핸드셰이크를 해야한다.
+  - SSL 핸드셰이크
+    - 프로토콜 버전 번호 교환
+    - 양쪽이 알고 있는 암호 선택
+    - 양쪽의 신원 인증
+    - 채널을 암호화하기 위한 임시 세션 키 생성
+- 서버 인증서
+  - SSL은 서버 인증서를 클라이언트로 나르고, 다시 클라이언트 인증서를 서버로 나르는 상호 인증을 지원한다
+  - BUT 오늘날 클라이언트 인증서는 웹브라우징에서 흔히 쓰이지는 X
+  - 보안 HTTPS 트랜젝션은 항상 서버 인증서를 요구
+- 사이트 인증서 검사
+  - 날짜 검사, 서명자 신뢰도 검사, 서명 검사, 사이트 신원 검사
+- 가상 호스팅과 인증서
+  - 가상 호스트(하나의 서버에 여러 호스트 명)
+  - 보안 트랜잭션을 시작하는 모든 사용자들을 리다이랙트하는 방법
+
+### 진짜 HTTPS 클라이언트
+- SSL 클라이언트와 서버 프로그래밍을 쉽게 만들어주는 상용 혹은 오픈 소스 라이브러리
+  - OpenSSL
+### 프락시를 통한 보안 트래픽 터널링
+- 클라가 서버로 보낼 데이터를 서버의 공개키로 암호화 -> 프락시가 HTTP 헤더를 읽을 수 없음 -> 프락시가 요청을 어디로 보내야하는지 모름
+- 이를 위해 클라가 프락시에게 어디에 접속하려고 하는지 말해주는 방법을 수정해야한다.
+- 인기 있는 기법이 HTTPS 터널링 프로토콜
+  - 클라이언트가 프락시에게 자신이 연결하고자하는 안전한 호스트와 포트를 말해준다
+  - 클라이언트는 이 내용을 프락시가 읽을 수 있도록 암호화가 시작되기 전에 평문으로 말해줌
+  - HTTP가 CONNECT라 불리는 확장 메서드를 이용해 평문으로된 종단 정보를 전송
+  - CONNECT 메서드는 프락시에게 희망하는 호스트 와 포트번호로 연결을 해달라고 말해준다
+  - 위에서 요청한 연결이 완료되면， 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.
+  - CONNECT 메서드는，안전한 원 서버의 호스트명과 포트를 콜론으로 구분된 형태로 제공하는， 한 줄로 된 텍스트 명령
+    - 호스트:포트에 뒤이어 스페이스 하나와 HTTP 버전 문 자열과 CRLF가 순서대로 온다.
+    - 0개 이상의 HTTP 요청 헤더줄들이 이어진 다음， 빈 줄. 빈 줄 다음에， 만약 커넥션을 수립하기 위한 핸드셰이크가 성공했다면，SSL데이터 전송이 시작된다.