잠보

class Node {
	constructor(value) {
		this.value = value;
		this.next = null;
	}
}

class Queue {
	constructor() {
		this.head = null;
		this.tail = null;
		this.size = 0;
	}
	
	enqueue(value) {
		if (this.head === null) {
			this.head = new Node(value);
			this.tail = this.head;
			this.size++;
			return;
		}
		
		this.size++;
		this.tail.next = new Node(value);
		this.tail = this.tail.next;
	}
	
	dequeue() {
		if (this.head === null) return;
		if (this.head.next === null) {
			this.head = null;
			this.tail = null;
			this.size--;
			return;
		}
		
		
		this.head = this.head.next;		
		this.size--;
	}
	
	isEmpty() {
		return this.head === null ? true : false;
	}
	
	get length() {
		return this.size;
	}

	clear() {
		this.head = null;
		this.tail = null;
		this.size = 0;
	}
}

class Node {
	constructor(value) {
		this.value = value;
		this.next = null;
	}
}

class Stack {
	constructor() {
		this.head = null;
		this.tail = null;
		this.size = 0;
	}
	
	push(value) {
		if (this.head === null) {
			this.head = new Node(value);
			this.tail = this.head;
			this.size++;
			return;
		}
		
		this.size++;
		this.tail.next = new Node(value);
		this.tail = this.tail.next;
	}
	
	pop() {
		if (this.head === null) return;
		if (this.head.next === null) {
			this.head = null;
			this.tail = null;
			this.size--;
			return;
		}
		
		let current = this.head;
		
		while(current.next.next) {
			current = current.next;
		}
		
		this.size--;
		current.next = null;
		this.tail = current;
	}
	
	isEmpty() {
		return this.head === null ? true : false;
	}
	
	peek() {
		if (this.head === null) return;
		
		return this.tail.value;
	}
	
	get length() {
		return this.size;
	}
    
    clear() {
		this.head = null;
		this.tail = null;
		this.size = 0;
	}
}

1. AWS 로그인 
2. 상단 메뉴바의 제품에 커서 이동 
3. 보안, 자격 증명 및 규정 준수 커서 이동 
4. AWS Identity and Access Management(IAM) 클릭 후 시작하기 
5. MFA 추가 -> 가상 MFA 디바이스 선택 후 계속 
6. 호환 애플리케이션 목록 클릭 후 원하는 어플리케이션 다운받기(필자는 Microsoft Authenticator 다운받음 추천아님)
7. Microsoft Authenticator 앱바의 점이 세개 있는 메뉴 클릭 후 계정 추가 
8. 회사 또는 학교 계정 클릭
9. QR코드 스캔 누른 후 화면의 QR코드 스캔하면 aws 계정이 앱에 자동으로 추가 된다.
10. 그 후 해당 아마존 웹 서비스 계정을 클릭하면 일회성 암호 코드가 나오는데 그 코드를 MFA 코드 1과 2에 추가하면 된다.(한번 추가하면 30초 기다리고 그 다음 나오는 번호를 2번째에 기입)
11. 그 후 로그인 할때마다 아이디와 비밀번호를 입력하면 키 인증 페이지가 나오며 앱을 켜서 해당 아마존 웹 서비스 계정 클릭 후 모바일 화면에 나오는 인증 코드를 입력하면 된다.

이렇게 간단하게 2단계 보안을 걸어 발생할 수 있는 대규모 금액 청구를 조금이나 막을 수 있기를 바란다!

엘라스틱 서치란?

엘라스틱 서치란 아파치 루씬기반의 오픈소스 실시간 분산 검색 엔진이다.

즉, 텍스트, 숫자, 위치 기반 정보, 정형 및 비정형 데이터 등 모든 유형의 데이터를 위한 무료 검색 및 분석 엔진이다.

서버 확장이 매우 편리하며, 실시간 검색 서비스 지원, 분산 및 병렬 처리, 멀티테넌시 기능을 제공하고 다양한 플러그인 지원, 클러스터로 

구성 가능하여 검색 대상의 용량이 증가했을 때 대응하기가 매우 수월하다.

엘라스틱 서치는 검색을 위해 단독으로 사용되기도 하며 ELK 스택으로 사용되기도 한다.

ELK 스택 구성

1. Logstash : 다양한 소스(DB, csv 파일 등)의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 ElasticSearch로 전달.

2. ElasticSearch : Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득.

3. Kibana : ElasticSearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링.

특징

1. 오픈소스 
2. 분산 시스템, 확장성 : 엘라스틱 서치는 네트워크상에 있는 노드들과 바인딩 되어있어 클러스터를 구성할 수 있다. 샤드를 기반으로 색인 데이터를 관리하고 운영중에도 노드가 추가되면 샤드를 새로운 노드로 적절히 재분배하여 유지하기 때문에 쉽게 스케일 아웃(확장)이 가능하다.
3. 고가용성 : 샤드는 기본적으로 하나 이상의 복제본을 중복되지 않는 서로 다른 노드에 배치한다. 그러므로 시스템 운영 중 어느 한 노드가 다운되더라도 데이터 유실 없이 동일한 검색 결과를 얻을 수 있다.
4. 실시간 검색 : 실시간에 가까운 속도로 색인된 데이터의 검색과 분석이 가능하다. 클러서가 실행되는 동안 계속해서 데이터가 입력된다(즉, 색인 과정)
5. JSON 문서 기반 : 질의에 사용되는 쿼리문과 결과 모두 JSON이라 직관적이다.
6. RESTful API : REST API를 기본을 지원하며 모든 데이터의 연산 과정을 HTTP 프로토콜 메소드를 통해 처리한다.

단점

1. 진입 장벽이 있다.
2. Document 간의 조인을 수행할 수 없다. (두번 쿼리로 해결 가능)
3. 트랜잭션 및 롤백이 제공되지 않는다.
4. 실시간 처리가 불가능 (색인되 데이터가 1초 뒤에나 검색이 가능)

RDBMS와 비교

※ 클러스터 : 엘라스틱 서치에서 가장 큰 시스템 단위를 의미하며, 최소 하나 이상의 노드로 이루어진 노드의 집합. 서로 다른 클러스터는 서로 접근할 수 없는 독립적인 시스템으로 유지되며, 여러 대의 서버가 하나의 클러스터를 구성할 수 있고 한 서버에 여러 개의 클러스터가 존재할 수 있다.

※ 노드 : 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여한다. 노드는 역할에 따라 Master-eligible, Data, Ingest, Coordinating 노드로 구분할 수 있다.

(1) Master-eligible 노드 : 클러스터를 제어하는 마스터로 선택할 수 있는 노드. 역할로는 인덱스 생성 및 삭제, 클러스터 노드의 추적 및 관리, 데이터 입력 시 할당한 샤드 선택이 있다.

(2) Data 노드 : 데이터가 저장되는 노드이며 데이터가 분산 저장되는 물리적 공간인 샤드가 배치되는 노드이다. 많은 리소스(CPU, 메모리 등)이 필요하며 마스터 노드와는 분리해야한다. 모니터링 작업도 필요.

(3) Ingest 노드 : 데이터를 변환하는 등 사전 처리 파이프라인을 실행하는 역할.

(4) Coordinating 노드 : 사용자의 요청을 받고 라운드 로빈 방식으로 분산을 하는 노드로 클러스터에 관련된 것은 마스터 노드로 넘기고 데이터와 관련된 것은 데이터 노드로 놈긴다. 로드밸런싱 역할.

※ 샤드 : 인덱스 내부에는 색인된 데이터를이 존재하는데 이 데이터들은 하나로 뭉쳐서 존재하지 않고 물리적 공간에 여러 부분으로 나뉘어 존재한다. 이러한 부분을 샤드라고 한다. 스케일 아웃(확장)을 위해 하나의 인덱스를 여러 샤드로 나누었다고 생각하면 된다.

샤드는 프라이머리 샤드와 레플리카 샤드로 나뉜다.

(1) 프라이머리 샤드 : 데이터의 원본. 엘라스틱 서치에서 데이터 업데이트 요청을 날리면 프라이머리 샤드에 요청하게 되고 해당 내용은 레플리카 샤드에 복제된다. 검색 성능 향상을 위해 클러스터의 샤드 개수를 조정하기도 한다.

(2) 레플리카 샤드 : 프라이머리 샤드의 복제본이다. 기존 원본 데이터가 위험해졌을 때 그 대신 사용하면서 장애를 극복한느 역할을 수행.

프라이머리 샤드와는 다른 노드에 배정.

프록시 서버란?

프록시 서버란 클라이언트와 서버 사이에 위치하여 중개인처럼 동작하는 서버이다.

프록시 서버 사용 예시

• 어린이 필터 : 성인 콘텐츠 차단. 부적절한 사이트의 접근을 거부할 수 있다.
• 보안 방화벽 
• 웹 캐시 : 자주 사용하는 콘텐츠를 저장해놨던 요청 시 빠르게 응답할 수 있다. CDN 서버가 대표적.
• 익명화 프록시 : HTTP 메세지에서 신원을 식별할 수 있는 특성들(IP, From header, Referer header, 쿠키 등)을 제거함으로써 개인 정보 보호와 익명성 보장에 기여할 수 있다.
• 트랜스 코더 : 콘텐츠를 클라이언트에게 전달하기 전에 포맷을 수정할 수 있다.
• 콘텐츠 라우터 : 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 라우터로 동작 가능하다. CDN 서버가 대표적.
• 대리 프록시 : 리버스 프록시라고 불리며 웹 서버나 다른 프록시 서버와 요청하게 되는 서버이며 로드 밸런싱과 웹 서버의 보안을 위해 사용된다.
• 문서 접근 제어자 : 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 할 수 있다.

프록시 서버의 종류

1. Forward Proxy

일반적으로 프록시라고 말하면 Forward Proxy를 뜻한다.

클라이언트 요청 시 바로 서버로 가는게 아닌 프록시 서버를 거쳐서 요청된다. 이 경우 서버는 클라이언트의 IP를 받는게 아닌 프록시 서버의 IP를 받는다. 즉, 서버에게 클라이언트가 누구인지를 감추는 프록시.

특징과 역할

(1) Cache : 동일한 요청이 여러 번 들어올 경우 프록시 서버에 캐싱된 내용을 전달해줌으로써 성능을 향상시킬 수 있다.

(2) IP 우회 : 서버에서 클라이언트의 IP를 받는게 아닌 프록시 서버의 IP를 받게 되어 클라이언트의 정보를 숨길 수 있다.

(3) 제한 : 보안이 중요한 사내망에서 정해진 사이트에만 연결할 수 있도록 설정하는 등의 환경을 제한할 수 있다.

2. Reverse Proxy

한 대 이상의 서버로부터 자원을 추출해주는 프록시 서버이다. 그런 다음 이런 자원들이 웹 서버 자체에서 나온 것처럼 클라이언트에게 반환시켜준다. 즉, Forward Proxy와는 달리 클라이언트가 본 서버를 호출하는게 아니라 프록시 서버를 통해 호출하기 때문에 본 서버를 감추는 역할을 한다. 또한 하나의 IP로 다수의 웹 서비스를 수행할 수 있다.

특징과 역할

(1) 로드 밸런싱 : Reverse Proxy 뒤에 여러 개의 WAS를 사용함으로써 사용자 요청을 분산 처리할 수 있다.

(2) 본 서버로의 직접적인 접근 차단 : 클라이언트가 셀지 본 서버를 직접 호출하는게 아닌 Proxy Server를 통해 호출하므로 보안이 좋다.

웹 서버란?

웹 서버란 클라이언트로부터 HTTP 프로토콜로 요청을 받아 HTML 문서 등과 같은 정적 웹 페이지를 응답해주는 소프트웨어.

하드웨어 측면 : 컴포넌트 파일(html, images, css, javascript 등)들을 저장하는 컴퓨터. 도메인 이름을 통해 접속 가능.

소프트웨어 측면 : 웹 사용자가 어떻게 호스트 파일들에 접근하는지를 관리.

흔히 웹 서버라고 부르면 정적 웹 서버를 생각하면 되고 동적 웹 서버는 WAS를 생각하면 될 듯 하다.

웹 서버의 분류

1. 정적 웹 서버 : 서버가 클라이언트가 요청한 파일을 가지고 있어 그래도 전송해주는 것.
2. 동적 웹 서버 : 서버가 클라이언트가 요청한 것을 기반으로 컨텐츠를 데이터베이스로부터 생성하거나 처리하여 제공하는 것.

웹 서버의 종류

1. Apache : 오래전부터 사용되어 온 웹 서버. 멀티 프로세스 모듈 방식 처리. 다양하고 검증된 기능을 사용하고 하는 경우.
2. Nginx : 이벤트 처리. Apache의 점유율을 따라잡고 있다. 성능과 가벼움을 중요시하는 서비스에 많이 사용.
3. IIS : 윈도우 서버

WAS란?

WAS란 일종의 미들웨어로 동적 서버 콘텐츠를 수행하는 서버이다. 

예를 들어 웹 서버(Nginx)와 웹 애플리케이션(Django)간의 연결을 중계한다.

대표적으로 Tomcat, Jetty, Undertow 등이 있다.

여기서는 의문점으로는 Apache나 Nginx도 동적 처리가 가능하며 Tomcat 등 WAS들도 정적 처리를 할 수 있는데 왜 분리할까? 라는

의문이 있을 수 있는데 옛날에는 각각 처리 속도가 달라서 의미가 있었지만 지금은 빨라져서 의미가 없으며 그래서 이유로는 

Apache나 Nginx는 reverse proxy 기능을 사용하여 서버의 IP를 숨기는 기능을 사용할 수 있고 다양한 보안 기능들을 제공하며 또한

로드밸런싱을 제공하여 분산 처리를 가능하게 여러 개의 WAS에 일 분담을 시킬 수 있다. 그리고 캐싱을 사용하여 캐시 안에 있는 데이터의 

경우 빠르게 제공하는 기능까지 제공하여 웹 서버와 WAS는 기능적인 측면으로 분리하며 보안 과정도 생각한다고 보면 된다.

레디스란?

레디스(REmote Dictionary Server)란 Key와 Value를 가진 NoSQL DBMS이다.

In-memory 데이터 저장소이며, 보통 DB, 캐시, 메시지 브로커 등의 용도로 사용하는 NoSQL DBMS.

초당 10만 ~ 15만건의 명령을 수행 가능하며, 파이프링을 통해 리눅스 시스템에서 초당 100만건의 요청도 수행이 가능하다.

레디스의 특징

• In-memory 데이터 구조 : 디스크가 아닌 메모리 기반으로 한 데이터 구조 안에 데이터를 저장한다.
• 디스크에 접근할 필요를 없애 검색 시간으로 인한 지연을 방지하며 CPU 명령을 적게 사용하는 좀 더 간단한 알고리즘으로 접근 가능하다.
• Pub/Sub을 사용하여 메시징 시스템에 유용하며 불필요한 데이터를 채우지 않게하는데 유용.
• 캐시를 사용하여 속도가 빠르다.
• 싱글 스레드 기반 명령 수행 : Atomic operations을 보장하며 동시성을 지원한다.
• 다양한 데이터 타입 지원 : strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatitial indexes, streams 등을 지원하며 lists의 경우 일반적인 RDB와 비교하면 10배 빠른 속도를 지원.
• Master-Slave 구성 가능 : Master-Slave와 같은 Redis Replication뿐만 아닌 Redis cluster를 이용한 분산처리, Redis Sentinel을 이용한 장애복구 시스템도 제공한다.

람다(Lambda)

람다의 뜻은 대표적으로 2개로 나뉘어진다.

1. AWS에서 제공하는 서버리스 컴퓨팅 플랫폼
2. 프로그래밍 언어 차원에서 제공하는 람다 표현식

AWS 람다(Lambda)

AWS 람다는 서버리스 컴퓨팅 플랫폼을 지칭하는 말로서 서버가 없다는 뜻이 아닌 개발자가 서버의 존재를 신경쓸 필요가 없다는 뜻이다. 오직 코드에만 집중할 수 있으므로 편한 플랫폼이다. 사용한 컴퓨팅 시간, 용량에 대해서만 비용을 지불하면 된다.

여기서 EC2와 람다랑 헷갈릴 수 있는데 EC2는 코드가 한 번 이상 실행되지 않더라도 즉, 사용하지 않더라도 서버 비용을 지불해야하는 것.

장점

1. 특정 기간 또는 특정 주기로 코드를 실행시켜야할 경우
2. 트리거가 실행될때만 코드를 실행시켜야할 경우
3. 서버를 띄우지 않고 간단한 코드를 실행시켜야할 경우

단점

1. 개발자에게 편리를 제공해주는 대신 비용이 비싸다
2. 처음 함수 호출 시 Cold Start를 하게되어 초기 지연시간이 발생

람다 표현식(Lambda Expressions)

람다 표현식이란 메서드로 전달할 수 있는 익명 함수를 단순환한 것으로 함수의 이름이 없다.

특징

• 익명 : 보통의 메서드와 달리 이름이 없다.
• 특정 클래스에 종속되지 않는다.
• 메서드 인수로 전달하거나 변수로 저장할 수 있다.
• { } 를 사용하지 않고 = or => or ->을 사용하여 간결하게 표현할 수 있다.

보일러 플레이트(Boiler Plate)

보일러 플레이트란 모든 코드를 작성하기 위해 항상 필요한 부분을 의미한다. 즉, 반복적으로 비슷한 형태를 띄는 코드를 작성할 필요없이 자동으로 작성해 주는 것을 보일러 플레이트라고 한다.

예를 들어 getter, setter, toString, toJson, fromJson, import, export 등이 있다.

요약

• 반복적으로 사용되는 부분을 재사용하여 단순 작업에서 해방시켜준다.
• 최소한의 수정으로 다시 사용한다.

REST

• 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미.
• 즉, 자원의 표현에 의한 상태 전달.
• 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식.

REST의 구체적인 개념

• Create : 생성(POST)
• Read : 조회(GET)
• Update : 수정(PUT)
• Delete : 삭제(DELETE)
• HEAD : header 정보 조회(HEAD)

REST가 필요한 이유

• 애플리케이션 분리 및 통합
• 다양한 클라이언트의 등장
• 최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
• 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 필요해 졌다.

REST 구성 요소

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재.
• 자원을 구별하는 ID는 HTTP URI다.
• Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청.

• HTTP 프로토콜의 Method를 사용.
• HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공.

• Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
• REST에서 하나의 자원은 JSON, XML, RSS 등 여러 형태로 나타난다.
• JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적.

REST 특징

• 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
• REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
• Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
• 서로 간 의존성이 줄어든다.

• HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
• Client의 context를 Server에 저장하지 않는다.
• 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
• Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
• 각 API 서버는 Client의 요청만을 단순 처리한다.
• 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
• 물론 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용한다.
• Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.

• 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
• 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
• HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
• 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
• 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.

• Client는 REST API Server만 호출한다.
• REST Server는 다중 계층으로 구성될 수 있다.
• API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다. 또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다.
• PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.

• Server로부터 스크립트를 받아서 Client에서 실행한다.
• 반드시 충족할 필요는 없다.

• URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• 특정 언어나 기술에 종속되지 않는다.