배열 해체 할당

let [,,third] = [‘red’,’white’,’orange’]
const arr = [1,2,3,4,5];
const [a, ...b] = arr; // a = 1, b = [2,3,4,5]
const [,,...c] = arr; // c = [3,4,5]
const [e=f,f] = [undefined,10] // f is not defined
let a = 10, b = 20;
[a,b] = [b,a]

객체 해체할당

const {
    device,
    device : {
        createAt
    }
} =  {
    device : {
        createdAt : '12',
        deviceId : '00'
        deviceType : 'desktop
    }
};

const {
    name : n,
    version : v = '6+',
    color : c = 'silver'
} = {
    name : 'phone',
    color : undefined
}

const {
    items : [,...products]
} = {
    items : [
        { name : 'test'},
        { name : 'test2'}
    ]
}

const getArea = ({width, height} = {width : 0,height:0}) => { return width + height}

function ({name, nickname = name}){..}

MDN 정의

내부함수 + lexicalEnvironment의 조합 컨텍스트 A에서 선언한 변수를 내부함수 B에서 참조할 경우에 발생하는 특별한 현상

var outer = function() {
    var a = 1;
    var inner = function(){
        console.log(++a);
    }
    inner();
}
outer();

var outer = function(){
    var a = 1;
    var inner = function(){
        return ++a;
    }
    return inner;
}
var outer2 = outer();
console.log(outer2());
console.log(outer2());

컨텍스트 A에서 선언한 변수 a를 참조하는 내부함수 B를 A의 외부로 전달 할 경우, A가 종료된 이후에도 a가 사라지지 않는 현상. =>** 함수 종료 후에도 사라지지 않는 지역변수를 만들 수 있다.!!**

function user (_name){
    var _logged = true;
    return {
        get name() { return _name;}
        set name(v) { _name = v;}
        login() {_logged = true;}
        logout() {_looged = false;}
        get status(){
            return _logged ? 'login' : 'logout';
        }
    }
}

var roy = user('yoonji');
console.log(roy.name); //yoonji; getter 호출
roy.name = 'jinyoung'; //setter 호출
console.log(roy.name);//jinyoung
roy._name = 'yooji';
console.log(roy.name);//jinyoung
roy.logout();
console.log(roy.status);// logout
roy.status = true; //setter가 없어서 무시.
console.log(roy.status);//logout

1. 함수 종료 후에도 사라지지 않고 값을 유지하는 변수
2. 외부로부터 내부 변수 보호(캡슐화)

데이터 통신이 발달하여 컴퓨터 사이에 고속의 효율 높은 전송이 필요하게 되어 ISO에서 HDLC를 제정함. HDLC 절차는 임의의 비트 길이의 정보를 프레임이라는 전송 제어 단위로 분할하여 프레임내의 제어 정보에 포함한 명령과 응답을 이용하여 연속적인 정보를 전달하게 하는 전송 제어 절차임. HDLC는 point-To-point와 multi-point 링크 상에 반이중이나 전이중 통신을 지원하기 위하여 설계된 비트 중심의 데이터링크 프로토콜.(bit-oriented protocol)

• primary station : 링크 동작에 관한 모든 제어권을 가지며 부스테이션에게 명령 프레임을 전송.
• secondary station : 주스테이션으로부터 명령 프레임을 받아 이에 응답 프레임을 주스테이션에게 보냄
• combined station : 각 스테이션이 서로 peer한 관계를 유지하며 전송 성격과 방향에 따라 주스테이션 또는 부스테이션 기능을 수행하도록 프로그램이 구성되어 있음.
• unbalanced configuration : 하나의 주스테이션과 1개 이상의 부스테이션으로 구성되며 전이중 및 반이중 선송을 지원. 하나의 호스트와 하나 이상의 터미널이 연결된 경우.
• balanced configuration : 2개의 조합 스테이션으로 구성. 전이중과 반이중 전송을 지원함. 두 스테이션은 단일 회선으로 연결 구성되며 이 회선은 스테이션 모두에게 제어를 받음.

Reference Basic Frame Structure HDLC 프레임

단순 방화벽(FW) : TCP/IP레벨에 포함된 정보들을 기반으로 차단 룰 설정.네트워크 패킷이 정상인지 여부 판단. L3~L4(network layer)레벨 동작 웹 방화벽(WAF) : 웹 해킹 공격으로부터 웹서비스를 전문적으로 보호하기 위해 탄생한 정보 보호 시스템. 웹 보안 문제나 실수를 보완하기 위해 방파제 역할. 네트워크 패킷이 아닌 사용자의 url이 정상이고 올바른 요청인지 판단. http/https 요청이 있는 L7(Application Layer)레벨에 동작. 웹 서버로 전송되는 모든 HTTP Request Packet을 검사하여 web application에게 의도하지 않은 내용들을 전송하지 못하도록 막는 역할. 웹 서버에서 통과하는 http reply packet내용을 감시하여 특정 정보의 유출을 막는 역할

웹 방화벽 원리 : 웹서버에 들어오고 나가는 모든 패킷을 proxy server 원리를 적용하여 패킷 내용을 검사하고 차단.

• One armed : 웹애플리케이션을 보호하기 위해 가장 좋은 구성 방식. http/https 트래픽만을 웹방화벽으로 전달시켜 주기만 하면 됨.
• Inline(bridge-proxy) : 네트워크 사이에 삽입시키는 방식으로 HTTP와 HTTPS 와 같은 웹 애플리케이션 트래픽만을 검사하고 다른 나머지 트래픽은 통과시킴. Bridge-Proxy 모드는 투명하며(Transparent), 기존의 네트워크 구성을 바꾸지는 않지만 로드 밸런싱, 컨텐츠 스위칭, 네트워크 방화벽과 같은 웹방화벽의 특정 기능을 사용 못함.

WAF 도입시 고려 사항 웹 방화벽 보호 대상 서버 선정 웹 방화벽 트래픽 용량 산정 웹 방화벽 설치 구간 선정

AWS WAF : CF, ALB, API Gateway와 연동 가능.

WAF

• NoSQL(Not only SQL) 데이터베이스
• 매우 빠른 쿼리 속도
• auto-Scaling 기능 탑재
• key-value 데이터 모델 지원
• 테이블 생성시 스키마 생성 필요 없음
• 모바일, 웹 iot 데이터 사용시 추천됨
• SSD 스토리지 사용

Primary Kye(PK)

• pk를 사용하여 데이터 쿼리
• DynamoDB에는 두가지의 PK 유형이 있음
• partition key 고유 특징(Unique Attribute) 실제 데이터가 들어가는 위치를 결정해줌 파티션키 사용시 동일한 두개의 데이터가 같은 위치에 저장될 수 없음.
• Composite Key 복합키 partition key + sort key 예시 : 똑같은 고객이 다른 날짜에 다른 물건을 구매 파티션 키 : 고객id, 정렬키 : tiemStamp 같은 파티션키의 데이터들은 같은 장소에 보관, 그다음 정렬키에 의해 데이터가 정렬됨.

DynamoDB 데이터 접근 관리

AWS IAM으로 관리 가능. 테이블 생성과 접근 권한을 부여할 수 있음. 특정 테이블만, 특정 데이터만 접근 가능케 해주는 특별한 IAM 역할 존재

Index

특정 컬럼만을 사용하여 쿼리 테이블 전체가 아닌 pivot을 사용해 쿼리가 이뤄짐. 매우 큰 쿼리 성능 효과 두가지의 Index 유형 존재

• Local Secondary Index
• Global Secondary Index

Local Secondary Index(LSI) 테이블 생성시에만 정의해줄 수 있음. 따라서 테이블 생성 후 변경, 삭제 불가능. 똑같은 파티션키 사용 그러나 다른 정렬키 사용.

Global Secondary Index(GSI) 테이블 생성 후에도 추가, 변경, 삭제 가능 다른 파티션키, 정렬키 사용

Query

• pK를 사용하여 데이터 검색
• query 사용시 모든 데이터(컬럼) 반환
• ProjectionExpression 파라미터로 필요한 데이터만 쿼리 가능

Scan

• 모든 데이터를 불러옴(pk x)
• ProjectionExpression 파라미터
• lookup용

scan은 불필요한 데이터까지 조회하게 될 경우가 많기 때문에 성능/비용 측면에서 query를 추천. Scan은 pk가 없고 데이터가 많지 않을때 사용.

Reference DynamoDB

kubernetes 스케쥴링 기법 3가지

• taint&tolerations
• NodeSelector
• Node Affinity

taint&tolerations

taint(얼룩?)가 설정된 node에는 일반적으로 pod는 배포될수 없고, taint가 지정된 노드에는 toleration(관용)을 적용하면 배포 가능. taint가 설정된 node는 동일한 값의 toleration이 적용된 pod가 배포되도록 허용

taint는 Node에 key=value:effect 형태로 할당. toleration은 pod에 할당 taint&toleration이 적용되어 있어도 특정 조건에 의해 pod는 다른 node에 배포 가능함.

NodeSelector

nodeSelector로 key/value label을 설정하고 해당 label에 맞추어 pod를 node에 배포 가능.

Affinity

Pod를 특정 Node에 배포되도록 하는 정책

Node affinity

pod가 특정 pod로 배포되도록 하는 기능. hard affinity : pod가 조건이 딱 맞는 node에만 배포 되도록 하는 기능(=node selector) soft affinity : pod가 조건에 맞는 node에 배포 되도록(반드시x)

Inter-Pod affinity

기존에 배포된 pod 기준으로 배포될 Pod rufwud. DB의 master/slave pod가 다른 node에 배포되도록 하기 위해서 master pod가 배포된 nod를 피해서 배포하거나, 클러스터 시스템에서 클러스터를 이루는 각각의 pod가 다른 node에 배포되도록 사용 가능.

Reference NodeSelector 공식문서

• remote Dictionary System 약자로 In-Memory Data Structure Store
• 메모리 기반의 key/ value store
• 비정형 데이터를 저장하고 관리하기 위한 오픈소스 기반의 비관계형 데이터베이스 관리 시스템.
• 메모리에 저장된 내용을 지속시키기 위해 파일을 동기화하는 기능 제공

사용하는 이유?

In-memory 기반으로 빠른 속도! 용량은 다소부족. 메인 DB보다는 보조적인 수단으로 캐시 데이터 서버로 사용.

Redis특징

• 메모리 기반이기 때문에 휘발성, 전원이 꺼지면 모든 데이터가 사라짐.
• 파일 메모리상의 데이터를 저장해두고 redis 서버 실행시 다시 그 파일에서 데이터를 읽어와 메모리상에 올리는 방법 이용
• 데이터 크기가 메모리에 제한되므로 메모리 크기 이상의 데이터를 저장하기 위해선 redis Cluster 추가 필요
• Redis는 2가지 RDB와 AOF의 지속성을 제공 두가지 지속성 중에 한가지만 선택하는 것이 아닌 두가지 모두 사용 가능 두가지 지속성 모두 사용하도록 설정한 상태에서 redis-server를 실행하면 AOF를 이용, 메모리에 데이터를 올림.

Redis 데이터 타입

• String : MAX 512MB의 문자 저장 기능, 문자 뿐만 아니라 이진 데이터도 저장 가능
• Lists : Redis Lists는 String형 Lists, LPUSH와 RPUSH로 나뉨
• Sets : 순서를 보장하지 않는 String Collections(테이블), 한 key에 중복된 데이터 존재 불가
• Hashes : String Field와 String Values 사이의 맵, 객체를 나타내는데 사용 가능한 데이터형
• Sorted sets : Sets와 유사, 비반복 String Collection,Score 순서를 보장해주는 Collection

Reference

블로그 우아한테크세미나 REDIS

Create

• vue() 인스턴스의 라이프사이클 중 맨 처음에 실행
• 컴포넌트들이 dom에 추가 되기전이기 때문에 dom 접근 불가. vm.$el 사용x
• SSR 적용시 서버사이드에서도 실행 가능한 단계

beforeCreate

• 제일 먼저 실행되는 훅.
• 데이터와 이벤트들이 설정되지 않아 접근 불가.(vm.$on, vm.$once,vm.$off)

created

• beforecreated와는 다르게 injection이후에 이뤄지므로 데이터나 이벤트들을 사용할 수 있음.
• 템플릿과 가상 dom이 마운트 및 렌더링 되지 않은 시점

Mount

• 렌더링 직전에 컴포넌트에 접근 가능
• 서버 사이드에서 호출되지 않아 접근 불가

beforeMount

• 함수들이 컴파일 직후 렌더링 직전에 실행

mounted

• dom이 메모리에 생성되고 렌더링 된 이후에 실행됨
• vm.$el이 생성된 시점이라 요소에 접근 가능
• vm.$nextTick으로 전체 렌더링 상태 보장 가능, child가 있을 경우 child 컴포넌트의 mounted를 기다린 후에 실행됨

update

• 컴포넌트가 재 렌더링시에 실행
• 서버 사이드에선 실행 불가

beforeUpdated

• 컴포넌트에서 사용되는 속성이 변하여, 업데이트 사이클이 시작되었을때 실행, 정확히는 dom이 재렌더링되기 전에 실행

updated

• 재 렌더링 이후에 실행. DOM과 관련된 로직 처리가 가능.
• 모든 child 컴포넌트들의 렌더링 상태를 보장하지 않음.
• mounted와 마찬가지로, vm.$nextTick를 사용 시에 전체 렌더링 상태를 보장할 수 있음.

Destroy

• 서버사이드 실행 불가

beforeDestroy

• Vue 인스턴스가 제거되기 전에 실행. 컴포넌트는 원래 모습과 원래 기능들을 가지고 있음.
• 이벤트 리스너나 subscription 제거에 사용하면 좋음.

destroyed

• Vue 인스턴스 제거 후에 실행. 모든 인스턴스와 디렉티브가 바인딩 해제되고, 모든 이벤트들이 제거됨.
• 하위 Vue 인스턴스도 제거됨.

Reference 공식문서 vuejs.org

• serverless의 주축을 담당
• Event를 통하여 lambda를 실행
• nodejs, python, java, Go등 다양한 언어 지원
• Lambda Function
• 최대 300s(5분) 런타임 시간 허용
• 512MB의 일시적인 디스크 공간 제공(/tmp)
• 최대 50Mb deployment package 허용

비용 lambda function이 실행될때만 돈 지불 매달 1.000.000 함수 호출시 무료 (그 후론 유료)

사용 용례 s3 -> lambda -> DB 데이터 변환 불필요 데이터 삭제

iot -> lambda -> sns

1. Topic으로 lambda 함수 호출.
2. 데이터 변환.
3. 사용자에게 실시간 경고

Reference AWS 공식 문서

• AWS 리소스 사용의 실시간 모니터링 기능 지원
• 다양한 이벤트들을 수집하여 로그 파일로 저장 S3 버켓 파일 업로드 & 삭제 S3 접근시 접근 거부 발생 RDS 데이터베이스 접속 시도
• 이벤트&알람 설정을 통해 SNS, AWS Lambda로 전송 가능
• CloudWatch 사용 가능 서비스 : EC2, RDS, S3, ELB 등

CloudWatch 모니터링 종류

• Basic Monitoring 무료, 5분 간격으로 최소의 metrics 제공
• Detailed Monitoring 유료, 1분 간격으로 자세한 Metrics 제공

CloudWatch 사용 용례

UseCase : 매일 얼마나 많은 사용자들이 모바일앱을 사용하는지 알고 싶음 Potential Issue : 특정날에 수많은 traffic 몰릴수 있어 병목 현상이 생길수 있음 Solution : 매일 traffic rate와 특정 버튼의 유저 클릭 횟수를 분석하여 더 효율적은 앱개발을 할 수 있는 통찰력을 얻을 수 있음.

UseCase : 특정 시간대에 웹서버 상태를 점검하여 비용 절감 목표 Potential Issue : 똑같은 비용을 내며 AWS 리소스들을 사용하지만 낮시간대와 밤시간대에 필요한 서버 성능은 달라질 수 있기 때문에 금전적 손실이 발생 가능.(주로 밤시간대가 낮시간대보다 서버가 오랫동안 idle) Solution : 알람 설정을 통하여 특정 threshold에 도달했을때 개발자에게 상황을 보고해줌으로서 서버 management 가능

Alarm

임의로 정해놓은 값에 도달시 Alarm 울림 (traffic rate) Alarm 발생시 특정 이벤트들을 작동 가능

state Alarm Insufficient - ec2생성하지 않았을때? OK

billing Alarm 우리가 정해놓은 지출 임계값을 초과할 경우 SNS를 통하여 경고 현재 N.virginia지역에서만 이 기능 지원됨.

Reference AWS 공식문서

안전하고 가변적인 Object 저장공간을 제공 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음. 파일 크기는 0KB부터 5TB까지 지원 저장공간 무제한 Bucket이라는 이름을 사용함(디렉토리와 유사) Bucket이름은 고유해야됨. ** S3 Object 구성요소** key : 파일명 value : 파일에 대한 데이터 Version ID : S3 고유 특징, 쉽게 복원 가능. Metadata : CORS(Cross Origin Resource Sharing) : bucket사이에서 네트워크 가능.

S3 Data Consistency Model Read after Write Consistency(PUT) Event Consistency(UPDATE, DELETE)

S3 storage 일반 S3 - 가장 보편적으로 사용되는 스토리지 타입 - 높은 내구성, 가용성(Durability, Availability) S3 - IA(infrequent Access) - 자주 접근되지는 않으나 접근시 빠른 접근이 요구되는 파일이 많을시 유용 - 일반 S3에 비해 비용은 저렴하나 접근시 추가 비용 발생 - 멀티 AZ를 통한 데이터 저장.(가용성이 높음) S3 - One Zone IA - 단일 AZ을 통한 데이터 저장 - 단일 AZ에 의한 데이터 접근 제한 (조금 낮은 가용성) - 데이터 접근시 S3- IA보다 20% 비용 저렴 Glacier - 거의 접근하지 않을 데이터 저장시 유용 - 매우 저렴한 비용 - 데이터 접근시 대략 4-5시간 소요 intelligent Tiering - 데이터 접근 주기가 불규칙할 때 매우 유용 - 2가지 티어 존재(Frequent Tier, Infrequent Tier) - 데이터 접근 주기에 따라 두가지 티어중 하나로 선택됨 - Frequent Tier비용이 약간 더 비쌈 - 최고의 비용 절감 효율을 누릴수 있음.

S3 요금 GB당/ PUT,GET,COPY 요청 횟수당 데이터 다운로드시 / 다른 리소스로 전송시 metadata(object tag)

사용 용례 파일 저장소(로그, 다양한 파일(이미지,비디오,압축파일 등)) 웹사이트 호스팅(html,css,js) CORS(Cross Origin Resource Sharing) : 다른 존에 있는 버킷 shairing 가능

최초 S3 버켓 생성(private)

• bucket policy 변경
• 접근 제어 리스트 변경 (Access Control List)

S3 보안

1. 파일 업로드/다운로드시
   SSL(Secure Socket Layer)/TLS(Transport Layer Security)
2. 가만히 있을시 SEE(Server-side-Encryption)-S3:Amazon S3가 데이터와 암호화 키를 관리하도록 요구 SSE-KMS:AWS KMS에 저장된 CMK를 사용하여 서버 측 암호화, 누가,언제,어떻게 암호화키를 풀었는지 기록됨. SSE-C:사용자에게 암호화 키 관리를 요구

S3 암호화과정

-PUT 요청이 생성됨

x-amz-server-side-encryption-parameterer

암호화가 걸리지 않은 파일을 버킷에 못올리게 하는 방법? bucket 설정으로 가능.

네트워크 트래픽을 하나 이상의 서버나 장비로 분산하기 위해 사용되는 기술 로드 밸런싱 서비스를 통해 외부에서 발생되는 많은 인터넷 트래픽을 여러 웹 서버나 장비로 부하를 분산하여 처리 가능

로드 밸런서를 통해 부하 분산 및 가용성 확보

Scale-Up을 통해 CPU,메모리,디스크 등 기능을 업그레이드 하는 방식

Scale-out을 통해 저렴한 노드 여러개를 하나의 Cluster로 구성하는 방식

Scale-up은 기존보다 높은 성능으로 시스템을 업그레이드 하는 방식으로 비용이 기하급수적으로 늘어나는 단점이 있어, Scale-out 방법을 통해 가용성 높은 웹서비스 구축.

부하 분산 방법

로드 밸런서에는 서비스를 제공하는 서버의 ip인 리얼 ip와 로드 밸런서에서 서비스르 대표하는 vip가 있음. vip에는 real ip가 바인딩되어 있고 사용자가 vip로 서비스를 요청하면 해당 vip에 연결된 리얼 ip로 해당 요청을 전달. 로드 밸랜서는 부하 분산을 위한 그룹을 만들때 ip주소 서비스 포트까지 지정해 만듬. 로드 밸런서를 L4 스위치라고 지칭하기도함.

Load Balancing 방식

Round Robin

Real 서버로의 session연결을 순차적으로 맺어주는 방식. 연결되어 있는 session 수에 상관없이 순차적으로 연결시키는 방식으로 session에 대한 보장 제공X

Hash

Hash 알고리즘을 이용한 로드 밸런싱 방식. Client와 Server간에 연결된 session을 계속 유지해주는 방식으로 Client가 특정 Server로 연결된 이후 동일 서버로만 연결되는 구조로 Session을 유지해야 하는 서비스에 적합. 서버의 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속 하도록 하기 위한 부하 분산 방식.

Least Connection

session 수를 고려하여 가장 작은 Session을 보유한 서버로 Session을 맺어주는 연결 방식. session에 대한 보장 제공X

Response Time

서버 간의 Resource와 Connection의 차이가 있는 환경에서 사용되는 방식으로 응답시간을 고려하여 빠른 응답시간을 제공하는 서버로 session을 맺어주는 방식이며 session에 대한 보장X

도메인 주소를 ip 주소로 변환하는 역할

DNS 사용하는 이유? 숫자로 구성된 ip 주소보다 의미 있는 문자열로 구성된 도메인 주소가 인식이 쉬움 ip 변경이 필요한 경우 DNS 서버에서 쉽게 변경 가능. 최근 클라우드 기반 인프라 구성이 많아지면서 인프라가 빈번히 변경되며, MSA기반의 서비스 설계가 많아지면서 서비스간 API 호출이나 인터페이스가 많아 복잡한 서비스간 연결로 DNS의 역할 중요.

사용자가 웹 브라우저에 naver.com을 입력하면 DNS 서버에서 naver.com의 ip주소를 사용자에게 응답하고, ip주소를 통해 실제 naver 서버에 접속하게됨.

콘텐츠 제공자와 사용자 간 지리적으로 떨어져 있는 환경에서 콘텐츠를 빠르게 제공하기 위한 기술 CDN 서버에 콘텐츠를 분산시키고 유저의 네트워크 경로 상 가장 가까운 곳의 서버로부터 콘텐츠를 전송받도록 하여 트래픽이 특정 서버에 집중되지 않도록 각 지역 서버로 분산되도록 하는 기술. CDN을 통해 온라인 상의 대용량 콘텐츠를 저렴한 비용으로 빠르게 전송 가능.

CDN 캐싱 방식

캐싱이란 오리진 서버에 저장된 콘텐츠를 지역적으로 분산된 캐시 서버로 저장하는 행위 캐시 서버에 콘텐츠를 갖고 있으면 "Cache hit", 그렇지 않으면 "Cache Miss"

정적 캐싱(Static Caching) 이미지 파일, js, css 등과 같이 변경되지 않는 정적인 콘텐츠 캐싱.

동적 캐싱(Dynamic Caching) 사용자의 요청이나 데이터 정보를 기반으로 즉석에서 생성되는 동적 콘텐츠의 경우 캐싱하더라도 cache hit율이 낮아 캐싱의 이점을 갖긴 어려우나 TTL을 설정하여 오리진 서버 간의 빠른 통신 가능.

TTL(Time to Live)? 콘텐츠를 캐싱하여 유지하는 기간. 동적 캐싱은 실제 콘텐츠를 캐싱하지 않기 때문에 TTL=0으로 설정

Cloud Front

AWS에서 제공하는 오리진 대상의 콘텐츠를 캐싱하여 짧은 지연 시간과 빠른 전송 속도로 전 세계 사용자에게 콘텐츠를 전송하는 CDN 서비스

• Origin : AWS 서비스중 EC2, ELB, S3가 오리진 대상이 될 수 있음.
• Distribution : 오리진과 edge location중간에 콘텐츠를 배포하는 역할을 수행하는 CF의 독립적인 단위. http(s) 전용의 Web Distribution과 동영상 콘텐츠 전용의 RTMP Distribution으로 나눠짐.
• Edge Location : Origin에서 Distribute을 통해 배포되는 콘텐츠를 캐싱하는 장치. 큰단위로 리전별 edge Cache가 있고 하위에 edge Location이 구성되어 콘텐츠를 캐싱.
• 보안장치 : OSI 3/4계층 Ddos를 완화하는 AWS shield 및 OSI 7계층을 보호하는 AWS WAF와 원활하게 통합하여 보안 강화
• 도메인 구성 : Distribution을 생성하면 xxxx.cloudfront.net이라는 도메인 이름이 생성되며 사용자는 해당 도메인 이름으로 접근이 가능. 이때 route 53과 연결하여 사용자가 원하는 도메인 이름으로 별칭 부여 가능.

Reference CloudFront

서버사이드 렌더링 프레임워크. Vue.js로 빠르게 웹을 제작할 수 있도록 도와주는 프레임워크. vuex, router, axois와 같은 라이브러리를 미리 구성하여 SPA,SSR,정적 웹 사이트(Static Generated Website)를 쉽게 제작 가능.

장점

• 검색 엔진 최적화
• 초기 프로젝트 설정 비용 감소 및 생산성 향상 ESLint,Prettier 라우터, 스토어 등의 라이브러리 설치 및 설정 파일 필요X 파일 기반의 라우팅 방식. 설정 파일 자동 생성.
• 페이지 로딩 속도와 사용자 경험 향상 브라우저가 하는 일을 서버에서 부담 코드 스플리팅 기본 설정

특징

• 서버 사이드 렌더링
• 규격화된 폴더 구조 (layout, store, middleware, plugin 등)
• pages 폴더 기반의 자동 라우팅 설정
• 코드 스플리팅
• 비동기 데이터 요청 속성
• ES6/ES6+ 변환
• 웹팩을 비롯한 기타 설정

서버 사이드 렌더링이란? 서버에서 페이지를 그려 client(browser)로 보낸 후 화면에 표시하는 전통적인 기법

클라이언트 사이드 렌더링이란? browser에서 js를 사용해 화면 렌더링 하는 기법.

SSR를 사용하는 이유?

구글,네이버와 같은 검색 사이트에서 검색시 결과가 사용자에게 많이 노출될 수 있도록 검색 엔진 최적화 가능. 특히 SNS 공유시 Og tag를 페이지별로 적용하기 위해선 SSR이 효율적 서버에서 미리 그려서 브라우져로 보여주기 때문에 빠른 페이지 렌더링 가능

공식문서 캡틴판교 문서

monolithic architecture

장점

• end-to-end 테스트가 용이
• 빠르게 간단한 서비스 만들 수 있음.

단점

• 간단한 수정사항이 있어도 전체 다시 빌드하고 배포 필요
• 유지보수가 어려움
• 덩치가 커지면 구동시간이 늘어나 생산성이 떨어짐
• 일부분 오류가 생기면 전체 장애 발생
• 각 기능에 따라 다른 언어 선택 못함

microservice architecture

장점

• 서비스별 독립적인 배포 가능.
• 요구사항을 신속하게 반영하여 빠르게 배포 가능
• 특정 서비스에 대한 확장성이 쉽고 유지보수 용이
• 클라우드 사용에 적합함
• 장애가 전체 서비스로 확장될 가능성이 적어 부분 장애 처리가 수월함
• 각 기능에 따라 다른 언어 선택 가능

단점

• 서비스가 분리되어 있기 때문에 통신 비용(Latency)이 높음.
• 한번에 모니터링이 어려움
• end-to-end 서비스 구동 불편. 즉,테스트가 불편하고 트랜잭션의 복잡도가 증가하여 많은 자원이 필요함
• 데이터가 여러 서비스에 분산되어 한번에 조회가 어렵고, 데이터 정합성 어려움.

첫 서비스 구현시엔 모노로식! 추후 지속적으로 발전 가능성이 있다면 마이크로서비스 아키텍쳐!

마이크로서비스 통신 패턴

Synchronous solution

• 동기
• Rest api
• 서비스 A에서 서비스 B로 직접 요청을 보내고 동기적으로 응답을 기다림.

Asynchronous Messaging

• 비동기적
• 메세지 브로커를 사용하여 서비스A에서 서비스B로 메세지를 보냄
• 서비스 A는 응답을 기다리지 않음.
• 서비스B는 일반적으로 동일한 메시징 시스템을 통해 결과를 사용할 수 있을때 결과를 보냄
• RabbitMQ와 Apache Kafaka

서비스 A,B가 동기적으로 데이터를 요청하고 응답받을때, 만약 서비스 B가 장애가 있어 실패하는 경우 어떻게 해야될지에 대한 처리가 필요함.

Producer에서 Costomer로 메세지를 전달하고 B에서 A로 메세지를 전달할 때 중개자 역할을 하는 Message Broker로 해결 가능. Message Broker는 Producer에서 메세지를 수신하여 Customer에게 메세지를 전달하여 작업을 수행, Customer의 연결이 끊어졌을때 임시 message 저장소를 제공하여 독립성 확보 가능.

Reference https://martinfowler.com/articles/microservices.html

HTTP Proxy(또는 Load Balancers, Caching Server) 등을 통해 웹서버에 접속하는 클라이언트의 ip 주소를 식별하기 위한 사실상 표준 헤더 (표준화된 버전 HTTP Forwarded Header)

웹서버(또는 WAS)와 클라이언트 사이에 Proxy Server(또는 Load Balancers, Caching Server)등의 장비가 있는 경우, 웹서버는 실제 클라이언트 IP가 아닌 앞단에 있는 Proxy Server IP를 요청한 IP로 인식하고, Proxy 장비 서버 IP로 웹로그를 남기게 됨. 서버 접근 로그는 Proxy Server의 ip만 갖고 있기 때문에 장비 서버 ip에 접속한 것으로 인식.
그렇기 때문에 X-Forwarded-For 헤더를 통해 웹프로그램이 실제로 요청한 클라이언트의 IP 파악 가능.

X-Forwarded-For : <client>,<proxy1>,<proxy2>
여러 프로시들을 거칠 때 ip주소들이 차례로 열거되어 첫번째 IP주소는 클라이언트 IP주소로 식별 가능 
(Apache,Nginx에서 X-Forwarded-for을 사용하기 위해 별도 설정 필요)

public IP -> ELB(private IP) -> EC2(private IP)

EC2는 private ip Address만 갖고 있어, 실제 요청한 public ip를 알 수가 없음. HTTP header에 X-Forwarded-For의 정보를 넣어서 확인 가능.

Connectionless 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징.(HTTP1.1 connection헤더에 keep-alive라고 설정하면 connection 유지 가능) Stateless 통신이 끝나면 상태를 유지하지 않는 특징. 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식. stateful 경우(로그인 후 인증상태 등)를 대처하기 위해 쿠키/세션 사용.

HTTP프로토콜 특징이자 약점을 보완하기 위해 쿠키와 세션을 사용함.

쿠키 vs 세션

저장위치 쿠키는 로컬, 세션은 로컬과 서버 보안 쿠키는 탈취,변조 가능. 세션은 id값만 가지고 있고 서버에 저장되어 있기때문에 비교적 안전. lifecycle 쿠키는 브라우저를 종료해도 파일로 남아있지만, 세션은 브라우저 종료시 세션 삭제 속도 쿠키는 파일에서 읽기 때문에 상대적으로 빠르고, 세션은 요청마다 서버에서 처리하기 때문에 비교적 느림.

쿠키

클라이언트 로컬에 저장되는 key-value쌍의 작은 데이터 파일

• 이름,값,만료일(저장기간설정),경로정보로 구성
• 클라이언트에 총 300개의 쿠키 저장 가능.
• 하나의 도메인당 20개 쿠키 가능
• 하나의 쿠키는 4KB(=4096byte)까지 저장 가능

  동작순서

1. 클라이언트가 페이지 요청.
2. 웹서버 쿠키 생성
3. HTTP 헤더에 쿠키를 포함하여 클라이언트에 응답
4. 로컬 PC에 저장한뒤 다시 서버에 요청할때 쿠키 전송.
5. 동일 사이트 재방문시 클라이언트의 PC의 해당 쿠키가 있는 경우 요청 페이지와 함께 쿠키 전송 예) 아이디/비밀번호 자동 입력

세션

브라우져가 종료되기 전까지 클라이언트의 요청을 유지하게 해주는 기술

• 웹서버의 저장되는 쿠키(=세션 쿠키)
• 각 클라이언트에게 고유 id 부여
• 보안면에서 쿠키보다 우수
• 사용자가 많아질수록 서버 메모리를 많이 차지함.

  동작순서

1. client가 서버에 처음으로 request 보냄(첫 요청이므로 session id 미존재)
2. 서버는 session id 쿠키값이 없는 것을 확인하고 새로 발급해서 응답
3. 이후 클라이언트는 전달 받은 session id값을 매요청마다 헤더 쿠키에 넣어서 요청
4. 서버는 session-id를 확인하여 사용자 식별
5. 클라이언트가 로그인을 요청하면 서버는 session을 로그인한 사용자 정보로 갱신하고 새로운 session id를 발급하여 응답
6. 이후 클라이어트는 로그인 사용자의 session id 쿠키를 요청과 함께 전달하고 서버에서도 로그인된 사용자라 식별 가능.
7. 클라이언트 종료시 session id제거, 서버에서도 세션 제거 예) 로그인

비동기 함수란? 자바스크립트는 싱글스레드이기 때문에 한번에 하나의 작업만 수행 가능. 여러가지 이벤트를 처리할때에 동기식으로 처리하게 된다면 하나의 이벤트라 모두 처리될 때까지 다른 업무를 수행하지 못하는 단점 존재. 이를 해결하기 위해 비동기가 필요. 즉시 처리하지 못하는 이벤트들을 web api로 보내 콜스택이 비었을때 먼저 처리된 이벤트들을 줄세워 다시 이벤트 큐에 줄세워 놓게되는데 이를 이벤트 루프라 부른다. web api로 들어오는 순서는 중요하지 않고, 먼저 처리되는냐가 중요하다. 자바스크립트는 즉시 처리 못하는 이벤트들을 이벤트 루프에 모아두고, 먼저 처리해야하는 이벤트를 실행함.

비동기 처리란? 특정 코드의 연산이 끝날 때까지 코드의 실행을 멈추지 않고 다음 코드를 먼저 실행하는 작업 즉, 특정 코드의 처리가 끝나기 전에 다음 코드를 실행할 수 있는 것.

사용 이유? 서버 데이터 요청시에 응답을 기다리지 않고 다음 작업을 수행하기 위해. 동기식 처리를 하게 되면 응답이 올때까지 대기시간이 길어 작업 시간이 길어짐.

비동기 방식 사용시 문제점? 로직이 끝났을 때 원하는 동작을 수행하기 위해 콜백함수를 사용하는데, 이때 콜백 지옥 발생. 가독성도 떨어지고 로직 변경하기 어려움.

콜백 지옥 해결 방법?

1. Promise 사용

   getData(productInfo)
   .then(priceInfo)
   .then(display);
   

var productInfo = { id : 1, name : 'test' }

function priceInfo(){ return new Promise({ }); }

function display(){ return new Promise({ ..// }); }

2. Async 사용.
비동기 처리할 메서드는 promise객체를 반환해여 await 동작 가능.

async function getData(){ try{ var user = await fetchUser(); if(user.id){ var todo = await fetchTodo(); } } catch(e){ }
} ```

확장성(Scalability) 서비스나 응용 프로그램이 증가하는 성능 요구에 맞게 향상될 수 있는 정도.

• 단일 하드웨어에 대해 시스템 리소스(프로세서, 메모리,디스크,네트워크 어뎁터 등)을 추가하거나 기존 하드웨어를 더욱 강력한 것으로 교체하는 작업 포함 (scale-up)
• 서버를 여러 대 추가하여 처리 능력 향상시키는 작업 (scale-out)

AWS autoScaling을 통해 고가용성 시스템을 설계하고 인프라의 증설/축소를 손쉽게 하여 확장성 및 탄력성 높은 시스템 구축 가능.

AWS AutoScaling 서버나 어플리케이션을 모니터링하고 리소스를 자동으로 조정(Scale In/Scale Out)하여,최대한 저렴한 비용으로 안정적이고 예측 가능한 성능 유지. AutoScaling 사용으로 별도 비용 발생은 없지만, AWS 리소스에 대한 비용과 CloudWatch 비용 부가됨.

• 성능과 비용을 최적화 하도록 애플리케이션 규모 조정
• 사용자가 정의한 조건에 따라 EC2용량이 자동으로 확장/축소
• 실행 중인 ec2 인스턴스 수를 원하는 수준으로 유지 가능.
• 수요가 급증할 경우 인스턴스의 수 자동으로 증가.
• 수요가 적을 경우 용량을 자동으로 감소시켜 비용 낭비 최소화.
• 수요 변화가 많지 않은 애플리케이션과 사용량이 시,일,주 단위로 변하는 애플리케이션 모두에 알맞게 적용 가능.