WAF와 EBS 개념 정리

md/Amazon_Web_Services/[EBS]개념.md

@@ -0,0 +1,118 @@
+# EBS
+
+* 특정 가용 영역에 위치하며 여기에서 자동으로 복제된다.
+  * 단일 구성 요소에 장애가 발생하더라도 보호할 수 있다.
+* 모든 EBS 볼륨 유형은 안정적인 스냅샷 기능을 제공하여 99.9999%의 가용성을 제공
+
+
+
+## SSD 지원 볼륨(IOPS 집약적)
+
+### 프로비저닝된 IOPS SSD(io1) 볼륨
+
+* 중요한 I/O 집약적 데이터베이스 및 애플리케이션 워크로드와 처리량 집약적 데이터베이스 및 데이터 웨어하우스 워크로드를 위해 설계된 고성능 EBS 스토리지 옵션
+* 매우 짧은 지연 시간을 요구하는 IOPS 집약적 및 처리량 집약적 워크로드 모두에 적합
+* 50 IOPS/GB에서 최대 20,000 IOPS의 일관된 기준 성능을 제공
+* io1의 이점을 극대화 하려면 EBS 최적화 EC2 인스턴스를 사용하는 것이 좋다.
+  * io1 볼륨은 EBS 최적화 EC2 인스턴스에 연결되는 경우 지연시간이 10ms 미만으로 감소하고, 연중 99.9%의 시간동안 프로비저닝된 성능을 유지하도록 설계됨
+
+
+
+
+
+### 범용 SSD(gp2) 볼륨
+
+* Amazon EC2 인스턴스의 기본 EBS 볼륨 유형
+* 개발/테스트 환경, 짧은 지연 시간의 대화형 애플리케이션 및 부트 볼륨을 비롯한 광범위한 트랜잭션 워크로드에 적합
+* 10ms 미만의 지연 시간 제공
+* 3 IOPS/GB에서 최대 10,000 IOPS의 일관된 기준 성능을 제공
+* 최대 160MB/초의 볼륨당 처리량을 제공
+* 1TB보다 적은 GP2 볼륨이 최대 3,000 IOPS까지 버스트할 수 있다.
+
+
+
+
+## HDD 지원 볼륨 (MB/초 집약적)
+
+### 처리량 최적화 HDD(st1) 볼륨
+
+* MapReduce, Kafka, 로그 처리, 데이터 웨어하우스 및 ETL 워크로드와 같이 대규모 데이터 세트와 큰 I/O 작업이 필요하거나 자주 액세스하고 처리량 집약적인 워크로드에 적합
+* 초당 MB로 측정되는 처리량과 관련한 성능을 제공
+  * TB당 40MB/초의 기준 처리량과 볼륨당 500MB/초의 최대 처리량을 제공
+  * TB당 최대 250MB/초까지 버스트 할 수 있다.
+
+
+
+### 콜드 HDD(sc1) 볼륨
+
+* 모든 볼륨 유형 중 GB당 비용이 가장 저렴
+* 대량의 콜드 데이터 세트가 있고 액세스 빈도가 낮은 워크로드에 적합
+* SC1은 ST1과 비슷한 버스트 모델을 제공
+  * TB당 80MB/초까지 버스트 가능
+  * TB당 12MB/초의 기준 처리량과 볼륨당 250MB/초의 최대 처리량을 제공
+* SC1은 액세스 빈도가 낮은 데이터에 매우 저렴한 스토리지를 제공
+
+
+
+## 탄력적 볼륨
+
+* 애플리케이션 요구 사항이 변경됨에 따라 볼륨을 손쉽게 적용할 수 있는 기능
+  * 가동 중단이나 성능 저하 없이 동적으로 용량을 늘리고, 성능을 튜닝하며, 볼륨 유형을 변경할 수 있음
+* CloudWatch를 Lambda와 함께 사용하면 자동으로 볼륨 변경이 가능
+
+
+
+## 스냅샷
+
+* 특정 시점의 스냅샷을 S3에 저장할 수 있는 기능 제공
+  * 증분 방식으로 저장
+  * 즉, 마지막 스냅샷을 저장한 이후에 변경된 블록만 저장되며, 변경된 블록에 해당하는 비용만 청구
+
+
+
+## Amazon EBS 최적화 인스턴스
+
+* 소액의 시간당 요금을 추가로 지불
+* EC2 인스턴스에서 EBS 볼륨에 프로비저닝된 IOPS를 십분 활용할 수 있다.
+* Amazon EC2와 EBS 간에 전용 처리량을 제공하며, 사용하는 인스턴스 유형에 따라 500 ~ 10000Mbps 범위에서 처리량을 선택할 수 있다.
+* 전용 처리량 덕분에 EBS I/O와 EC2 인스턴스의 기타 트래픽 간에 경합이 최소화되어 EBS 볼륨의 성능이 극대화된다.
+* EBS 최적화 인스턴스는 모든 Amazon EBS 볼륨 유형과 함께 사용 가능
+
+
+
+## 가용성 및 안정성
+
+* 고가용성 및 안정성을 갖추도록 설계되어 있음
+* 단일 구성 요소의 장애로 인한 데이터 손실을 방지하기 위해 가용 영역의 여러 서버에 복제된다.
+  * 이에 따른 추가 요금은 없음
+* AFR(연간 고장률)이 4% 정도인 상용 하드 디스크보다 20배 이상 안정적 (EBS는 0.1~0.2%)
+  * 1000개의 EBS 볼륨을 1년간 실행하는 경우 1~2개 정도의 볼륨에 장애가 발생할 것으로 예상
+
+
+
+## 암호화 및 AWS Identity and Access Management
+
+* EBS 데이터 볼륨, 부팅 볼륨 및 스냅샷에 대한 원활한 암호화를 제공
+* EC2 인스턴스와 EBS 데이터 및 부팅 볼륨 간에 이동하는 데이터도 암호화
+* EBS 볼륨에 대한 액세스가 AWS IAM와 통합 되었다.
+  * IAM을 사용하여 EBS 볼륨에 대한 액세스 제어가 가능
+
+
+
+
+## 용어
+
+* 워크로드 : 업무량, 작업량
+* 워크로드 사용료 : 고객이 설정한 시스템 용량에 기초한 소프트웨어 사용 요금 방식
+* IOPS(Input/Output Operations Per Second) : HDD, SSD, SAN과 같은 컴퓨터 저장 장치를 벤치마크 하는데 사용되는 성능 측정 단위
+  * IOPS 측정값은 벤치마크 프로그램에 따라 다르다.
+* RPM(revolution per minute) : 하드디스크의 플래터(platter)가 1분당 회전하는 수. 
+  * 일반적으로 7200RPM 하드 디스크는 약 75~100 IOPS.
+  * 15000RPM 하드 디스크는 175~210 IOPS.
+* 플래터(platter) : 하드디스크 드라이브안에 있는 디스크를 다른 종류의 디스크와 구별하기 위해 부르는 용어
+  * 하드디스크의 데이터를 기록하는 둥근 원판
+  * 플래터가 하드디스크의 자료를 읽기 위해서는 회전을 해야 하는데, 회전 속도가 빠를 수록 저장 용량이 많고, 읽는 속도도 빨라진다.
+  * 고석으로 회전하기 때문에 발열량이 많고 소음이 커지는 단점이 있음.
+  * RPM이 높을 수록 고급 제품이며 가격도 비쌈
+* 프로비저닝(provisioning) : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해두는 것
+* ETL(Extraction, Transformation, Loading) : 다양한 소스 시스템으로부터 필요한 데이터를 추출하여 변환 작업을 거쳐 타겟 시스템으로 전송 및 로딩하는 모든 과정을 말한다.

md/Amazon_Web_Services/[WAF]개념.md

@@ -0,0 +1,103 @@
+# WAF
+
+* Amazon CloudFront 또는 Application Load Balancer로 전달되는 HTTP 및 HTTPS 요청을 모니터링 할 수 있는 웹 애플리케이션 방화벽.
+* 콘텐츠에 대한 액세스를 제어할 수 있다.
+  * 요청이 시작되는 IP주소 또는 쿼리 문자열의 값과 같이 사용자가 지정하는 조건에 따라 CloudFront 또는 ALB는 요청된 콘텐츠 또는 HTTP 403 상태코드로 요청에 응답.
+
+
+
+## 동작
+
+* 지정한 항목을 제외하고 모든 요청을 허용
+* 지정한 항목을 제외하고 모든 요청을 차단
+* 지정한 속성과 일치하는 요청 계산
+
+
+
+## 장점
+
+* 웹 요청의 특성을 사용하여 웹 공격에 대한 추가 보호를 제공
+  * 요청이 시작되는 IP 주소
+  * 요청 헤더 값
+  * 요청에 나타나는 문자열
+  * 요청 길이
+  * SQL Injection 코드의 존재
+  * 악성 스크립트의 존재 (교차 사이트 스크립팅)
+* 지정된 조건을 충족하는 웹 요청을 허용, 차단 또는 계수 할 수 있는 규칙
+* 여러 웹 애플리케이션에 재사용할 수 있는 규칙
+* 실시간 지표 및 샘플링된 웹 요청
+* AWS WAF API를 사용하여 자동화된 관리
+
+
+
+## 작동 방식
+
+조건, 규칙, 웹 ACL(웹 액세스 제어 목록)을 생성하고 조건을 정의한 후 규칙에 결합하며, 규칙을 웹 ACL에 결합한다.
+
+### 조건
+
+조건은 AWS WAF가 웹 요청에서 감시할 기본 특성을 정의
+
+* 악성일 가능성이 있는 스크립트
+* 요청이 시작되는 IP 주소 또는 주소 범위
+* 쿼리 문자열과 같은 요청에서 지정된 부분의 길이
+* 악성일 가능성이 있는 SQL 코드
+  * SQL Injection
+* 요청에 나타나는 문자열
+  * ex) User-Agent 헤더에 나타나는 값 또는 쿼리 문자열에 나타나는 텍스트 문자열
+
+
+
+### 규칙
+
+조건을 규칙에 결합하여 허용,차단,계수 하려는 요청을 정확하게 대상으로 지정할 수 있음
+
+* 일반 규칙 : 조건만 사용하여 특정 요청을 대상으로 선택
+  * ex) 공격자로부터 확인한 최근 요청을 기반으로 다음 조건이 포함된 규칙을 생성할 수 있다.
+    * 요청이 192.0.2.44에서 나옴
+    * 요청의 User-Agent 헤더에 BadBot이라는 값이 포함되어 있음
+    * 요청의 쿼리 문자열에 유사 SQL 코드가 포함되어 있는 것으로 보임
+  * 여러 조건이 포함되면 AND연산. 즉, 위의 모든 조건이 일치하는 요청을 찾아냄
+  * **적어도 하나의 조건을 정의 해야한다.**
+    * 조건이 없는 규칙은 어떠한 요청에도 트리거되지 않음.
+* 비율 기반 규칙 : 일반 규칙과 비슷하지만 비율 제한이 추가된다는 점이 다름. 
+  * 지정된 IP 주소로부터 도착하는 요청의 개수를 5분 단위로 계산
+  * 요청 수가 비율 제한을 초과할 경우 이 규칙이 작업을 트리거 할 수 있다.
+  * 조건을 비율 제한과 결합하게 되면 요청이 모든 조건과 일치하고 5분간 요청 수가 비율제한을 초과할 경우 웹 ACL에 지정된 작업을 트리거한다.
+  * ex) 공격자로부터 확인한 최근 요청을 기반으로 다음 조건이 포함된 비율 기반 규칙을 생성할 수 있음.
+    * 요청이 192.0.2.44에서 나옴
+    * 요청의 User-Agent 헤더에 BadBot이라는 값이 포함되어 있음
+  * 위 조건에 비율 제한을 15000으로 정의한 경우 위 두 조건을 충족하고 5분간 15000개 요청을 초과하는 요청은 웹 ACL에 정의된 대로 규칙의 작업(허용 또는 차단)을 트리거한다.
+  * 웹 사이트의 특정 페이지에 대한 요청을 제한하는 것도 가능
+  * **조건 지정은 선택사항**
+    * 조건이 없는 경우 모든 요청이 규칙과 일치하는 것으로 가정.
+    * 동일한 IP 주소로부터 요청이 올 경우 비율 제한으로 계산됨.
+
+
+
+### 웹 ACL
+
+조건을 규칙으로 결합한 후 웹 ACL로 결합한다.
+
+* 각 규칙에 대한 작업
+  * 웹 요청이 규칙의 모든 조건과 일치하면 WAF는 요청을 차단하거나 CloudFront 또는 Application Load Balancer로 전달하도록 허용할 수 있다.
+* 기본 작업
+  * WAF가 웹 ACL의 하나의 규칙에서 모든 조건과 일치하지 않는 요청을 허용 또는 차단할지 결정.
+  * 지정한 규칙에 세가지 조건이 존재하는 경우 여기서 해당 요청이 모든 조건에 일치하지 않고, 기본 작업이 ALLOW로 설정되어 있다면 WAF는 해당 요청을 CloudFront 또는 ALB로 전달한다.
+  * 즉, 두개 이상의 조건이 설정된 경우 모든 조건을 충족하지 않는 경우에 WAF는 기본 작업을 수행한다.
+  * 드문 경우지만 요청을 허용할지 차단할지에 대해 CloudFront 또는 ALB에 대한 응답이 지연되는 내부 오류가 WAF에 발생할 수 있는데, 이런 경우 일반적으로 CloudFront 또는 ALB가 콘텐츠를 제공한다.
+
+
+
+## 용어
+
+* 오리진 서버 : 웹 서버를 의미
+
+
+
+
+
+## 참고
+
+* [WAF 시작하기](http://docs.aws.amazon.com/ko_kr/waf/latest/developerguide/getting-started.html)
+

md/Nginx/Nginx.md

@@ -0,0 +1,8 @@
+# Nginx
+
+## 아파치와 비교
+
+* 아파치의 방대한 모듈과 HTTP 요청이 들어올 때마다 메모리에 로드하는 여러 콤포넌트 때문에 많은 요청이 동시에 들이닥치면 서버 효율성이 급격히 떨어진다.
+  * 기능성에 집중하느라 최적화와 처리 속도는 포기했다고들 말함.
+* 엔진엑스는 아파치에 비해 RAM과 CPU 시간을 적게 사용하면서 더 많은 요청을 서비스함으로써 경량성과 안정성이 둘 다 뛰어난 것으로 입증되었다.
+* ​