_Async/Await_

비동기란 무엇일까?

비동기

비동기는 하나의 동작이 완료되는 것을 기다리지 않고, 동시에 다른 작업을 처리하는 방식이다.

자바스크립트는 싱글 스레드 언어이기 때문에 필수 불가결적으로 비동기 함수를 선택하게 되었다.

하나의 스레드를 가지고 다른 작업이 마칠때까지 대기해야 한다면, 작업이 너무나도 느려지기 때문이다.

비동기 처리를 지원하는 방식으로는 Promise와 async/await이 있다.

예시

비동기 함수는 에어프라이어에 음식 넣고 돌린 후, 다른 재료를 손질하면서 틈틈이 에어프라이어를 체크하는 것과 유사하다.

에어프라이어가 음식을 조리하는 것이 완료될 때 까지 기다리는 것이 아닌, 동시에 다른 작업을 진행하는 것이다.

동기

동기는 하나의 동작이 완료된 후에 다음 동작으로 실행하는 순차적 방식이다.

개인적인 헷갈림 정리

처음에 비동기와 동기의 개념을 반대로 생각하고 있었다.

오히려 동기를 "병렬 처리"와 개념적으로 혼동하고 있었던 것 같다.

동기는 "순차적", 비동기는 "동시에"라고 외워야 겠다.

참고 링크

- 주니어 웹 개발자가 알아야 할 "비동기 통신" (https://yozm.wishket.com/magazine/detail/1982/)

Golang은 뛰어난 동시성 지원이 장점이라고들 한다.

일반적으로 쓰레드를 활용하여 동시성 프로그래밍을 하지만, Golang은 고루틴 goroutine으로 가능하다.

고루틴 Goroutine

공시적인 설명으로는 경량 쓰레드이다. 실제 OS의 쓰레드를 사용하는 것이 아닌, golang의 런타임에서 관리되는 논리적 / 가상적 쓰레드이다.

사용법

go func() {

    // 대충 코드

  }()

이게 끝이다.

thread VS goroutine

1. 메모리 사용량

• goroutine: 생성시 약 2KB의 스택 메모리 혹은 힙 메모리 공간만을 사용한다.
• thread: 약 1MB 의 메모리 공간을 사용한다.
• P.S. Guard Page: 쓰레드가 사용할 메모리 공간과 각 메모리 간의 경계 역할
• 따라서 스레드 기반의 동시성 처리는 결국 메모리 부족 현상(OutOfMemory) 문제 발생할 수 있으므로, 스레드를 미리 생성해 재활용하는 형태가 될 수 있음.

2. 비용

• goroutine: 런타임에서 논리적으로(하드웨어와 상관 없이) 생성되고 소거되기 때문에 가볍다.
• thread: OS 에 스레드 생성을 요청해 사용하고 작업 완료 시 다시 OS에 반환해야 한다.
• 따라서 쓰레드 생성시마다 OS에 요청해 생성하고 다시 반환하는 방식이 더 리소스 사용량이 많다.

3. Context Switching 비용

• 하나의 스레드가 특정 작업 처리를 위해 사용(Blocking)된다면, 다른 쓰레드가 대신하여 처리하도록 스케쥴링 됨
• goroutine: 3개의 레지스터(PC(Program Counter)), SP(Stack Pointer), DX)만 save/restore 작업을 함
• thread: 스레드가 스케쥴링고 교체되는 동안 스케쥴러에서는 모든 레지스터들을 save/restore 해야함
• 일반적으로 16개의 범용 레지스터, PC, SP, Segment 레지스터, 16개의 XMM레지스터, FP coprocessor state, 16개의 AVX 레지스터, 모든 MSR들 등 save/restore 작업을 진해해야함
• 따라서 Context Switching 할 때 save/restore 해야하는 레지스터의 개수부터가 큰 차이가 남

결론

golang이 메모리 사용량과 쓰레드 생성과 작업처리에 있어서의 비용 측면에서 효율적이다.

마지막

goroutine의 동작 방식과 쓰레드 종류에 대해선 다음에 서술하고자 한다.

REFERENCE

- https://velog.io/@khsb2012/go-goroutine

_Event Loop_

이벤트 루프란 무엇일까?

Event Loop

이벤트 루프는 node.js의 기본적인 동작 방식이다.

Call Stack과 Callback Queue의 상태를 체크하여, Call Stack이 빈 상태가 되면 Callback Queue의 첫번째 콜백을 Call Stack으로 밀어넣는다. 이를 틱(Tick)이라 한다.

• Call Stack: 코드가 실행될 때 쌓이는 곳. Stack 형태로 쌓임. 함수를 실행하고 값을 **return 하면 call Stack에서 제거**된다.
• Callback Queue: 비동기적으로 실행된 콜백함수가 보관된 영역. eg. setTimeout에서 타이머 완료 후 실행되는 함수 등...

이벤트 루프는 총 6개의 단계를 가진다.

이벤트 단계

• Timer 단계
  • 이벤트 루프의 시작 단계이다.
• Pending(I/O) 콜백 단계
• Idel, Prepare 단계
• Poll 단계
• Check 단계
• Close 단계

microTaskQueue

이벤트 루프는 우선적으로 Microtask Queue를 먼저 확인한다.

MicroStack Queue에 콜백이 있다면 이를 먼저 Call Stack에 담는다.

이벤트 루프는 계속 공부를 더 해야겠다..

참고 링크

• JavaScript 비동기 핵심 Event Loop 정리 (https://medium.com/sjk5766/javascript-%EB%B9%84%EB%8F%99%EA%B8%B0-%ED%95%B5%EC%8B%AC-event-loop-%EC%A0%95%EB%A6%AC-422eb29231a8)
• Event Loop와 비동기 (https://pozafly.github.io/javascript/event-loop-and-async/)

_Node.js Logo_

Node.js가 무엇일까?

JS의 역사

자바스크립트는 브라우저에서 동적 페이지를 다루기 위해 시작된 언어였다.

그러나 브라우저에서 소스코드를 그대로 확인할 수 있었기 때문에 보안에 취약하다는 인식과 함께 프로그래밍 언어로써 인정을 받지 못하였다.

Node.JS

Node.JS는 자바스크립트 런타임이다. 즉 브라우저에서만 사용 가능했던 자바스크립트를 로컬에서 사용할 수 있게끔 해 주는 역할을 한다. 이 덕분에 자바스크립트는 프론트엔드 뿐만 아니라 백엔드에서 까지 활용할 수 있게 된 것이다. 거기에 V8엔진을 이용했기 때문에 성능 역시 인정을 받는다.

특징

싱글 스레드 방식

싱글 스레드는 작업에 사용하는 스레드를 하나 사용하는 방식이다. 그러나 엄밀히 말하면 개발자가 직접 스레드 풀을 관리하지 않고 node.js에 포함된 **libuv**가 스레드 풀을 관리하기 때문에 단일 스레드에서 동작하는 것처럼 이해하기 쉬운 코드를 작성할 수 있다.

추가로 웹 서버를 운용할 때는 프로세서(CPU)를 분산해서 관리하므로, 실질적으로는 여러 개의 코어에서 별개로 처리된다.

- P.S.

작업 요청이 동시에 발생했을 때 각 작업을 처리하기 위한 스레드를 만들고 할당하는 방식은 멀티 스레드인데, 여러 작업을 동시에 처리하기 때문에 빠르지만 자원을 관리하는 노력이 많이 들어가고 쓰레드의 개수만큼 메모리를 차지하므로 메모리 관리에 문제가 생길 수 있다.

non-blocking I/O

앞의 작업이 끝날때까지 기다리지 않고(non-blocking) 비동기로 처리한다. 즉, 입력은 하나의 스레드에서 받지만 순서대로 처리하지 않고 먼저 처리된 결과를 이벤트로 반환해줌을 의미한다.

_RESTful API_

백엔드 코드를 구현할 때 RESTful API 라는 개념이 자주 등장한다. 과연 이게 무엇일까

API란?

우선 API가 무엇인지 이해를 해야 할 것 같다.

API란 Application Programming Interface의 약자로, 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙이다.

즉 데이터와 기능의 집합을 제공하여 프로그램 간 상호 작용을 통해, 정보를 교환 가능하도록 하는 것

HTTP URI

리소스를 고유하게 식별하는 것, URL과 보통 혼용되고 있다.

- ex. www.example.com/font/2 에서 2가 리소스

REST 란?

목표

1. 컴포넌트 간 확장성을 가진 상호 연동성 확보
2. 범용 인터페이스
3. 각 컴포넌트들의 독립적인 배포
4. 지연 감소, 보안 강화, 레거시 시스템을 인캡슐레이션 하는 중간 컴포넌트로의 역할

인캡슐레이션: 데이터에 헤더가 추가되는 과정. 즉, 한 프로그램에서 다른 프로그램으로 데이터를 전송할 때 데이터를 패키지화 하는 과정

개념

REST는 Representational State Transfer(REST)의 약자로, API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처 스타일이다.

네트워크 상에서 Client와 Server 사이의 통신 방신 중 하나로, 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미하는 것이다.

HTTP Method (POST, GET, PUT, DELETE)를 통해 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

• 자원: 해당 소프트웨어가 관리하는 모든 것
  • 문서, 그림, 데이터, 소프트웨어 자체 등...
• 자원의 이름(자원의 표현)
  • 학생 정보가 자원일 때, 'student'를 자원의 표현으로 정한다.
• 상태 전달
  • 데이터가 요청되는 시점의 자원의 상태를 전달
  • 일반적으로 JSON 혹은 XML 포맷을 통해 주고받는다.

CRUD Operation

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

REST 특징

• 클라이언트 / 서버 구조
  • 클라이언트는 유저 관련 처리, 서버는 REST API 제공으로 역할 분리
  • 때문에 서버와 클라이언트 간 의존성이 줄어든다.
• REST Server: API 제공, 비즈니스 로직 처리 및 저장
  • Client: 사용자 인증 / Context(세션, 로그인 정보) 등을 직접 관리 및 책임
• 무상태성 (Stateless)
  • 서버에서 어떤 작업을 하기 위해 상태 정보를 기억할 필요가 없고, 들어온 요청에 대해 처리만 해주면 된다.
• 캐시 처리 가능 (Cacheable)
• HTTP 웹 표준을 사용하기에, 기존 웹 인프라를 그대로 사용
• 대량의 요청을 효율적으로 처리. 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상
• 자체 표현 구조 (Self- Descriptiveness)
  • JSON을 이용한 메세지 포맷을 이용해 요청에 대한 이해가 쉽다
• 계층화
  • 클라이언트와 서버가 분리되어 있기 때문에, 프록시 서버 / 암호화 계층 등 중간매체를 사용할 수 있음
• 유니폼 인터페이스
  • HTTP 표준에만 따른다면 모든 플랫폼에서 사용 가능하며, 리소스 조작이 통일되기 때문에 특정 언어나 기술에 종속되지 않는다

RESTful API란?

REST 기반으로 API를 구현한 것을 RESTful 웹 서비스라고 지칭한다.

즉 REST 하게 자원으로 구분을 잘 한 API라는 의미

확장성과 재사용성을 높여 유지보수 및 운용의 편리성을 확보할 수 있다.

개인적으로 정의하자면, 통신의 표준화라고 생각한다.

규칙

1. 슬레시(/)는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬레시(/)는 사용하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용한다.
4. 밑줄 (_)은 URI에 사용하지 않는다.
5. URI는 최대한 소문자를 사용한다.
6. 파일 확장자는 URI에 포함하지 않는다.

참고 링크

- REST, REST API, RESTful 특징 (https://hahahoho5915.tistory.com/54)

gRPC란 무엇일까? 이를 알기 위해선 RPC를 먼저 알아봐야 한다.

RPC (Remote Procedure Call)

_RPC 메커니즘_

RPC는 API를 구축하는 접근 방식이다.

클라이언트 - 서버 간 상호 작용 방식으로, 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스간 통신 기술이다. 즉, 로컬 위치 혹은 원격 위치에 있는 기능을 수행할 수 있게 하는 것이다.

정리하자면, 원격으로 특정 함수나 프로시져를 호출할 수 있게 하는 것이다.

• 교환이 간단하다.
• 내용이 가볍다.
• 따라서 프로그래밍 부담이 적고 속도가 빠르다.

방법

• 양쪽의 인터페이스 규약을 IDL등의 언어로 정의
• 해당 프로그래밍 언어가 부를 수 있는 형태의 코드로 생성

함수 - 프로시져

• 함수: 입력값(input)에 따른 출력값(output)을 내보내는 것.
• 프로시져: __명령 단위가 수행하는 절차__에 집중한 개념. 따라서 출력값은 없을 수도 있으며, 함수보다 큰 단위의 실행에 사용된다.

IDL (Interface Definition Language)

RPC는 IDL을 이용한다. IDL이란 인터페이스 정의 언어로, 어느 한 언어게 국한되지 않게 인터페이스를 표현하는 방법

• 서버 호출 규약 정의
• 함수명, 인자, 반환값에 대한 데이터 타입 지정

gRPC (Google Remote Procedure Call)

gRPC는 구글에서 개발한 RPC 기반의 통신 방식이다.

_gRPC 메커니즘_

왼쪽 service가 서버, 오른쪽 client가 클라이언트이다.

그리고 각각 프로그래밍 언어가 적혀있는 것은 서로 다른 언어들끼리도 통신할 수 있다는 것을 예시로 든 것이다.

특징

• JSON 혹은 XML이 아닌 프로토콜 버퍼 기반의 메시지를 바이너리 형식으로 직렬화 통신
• 프로토콜 버퍼로 원하는 메시지 타입을 미리 정의
• HTTP/2를 사용하기 때문에, 요청-응답을 넘어 스트리밍도 지원

프로토버퍼 (Proto Buffer)

gRPC에서 통신하기 위해 서비스 인터페이스를 정의하는 방법.

• 프로토 파일로 정의된 메세지 포맷들을 이용하여 직렬화(Serialize)
• 프로토 파일을 토대로 받은 메세지를 역직렬화

RPC vs REST API

• REST API는 JSON 혹은 XML 형식을 사용하여 통신하기에 크기가 크고 따라서 상대적으로 느리다.
• REST API 서버는 클라이언트와 **엔드포인트(End Point)**를 공유한다. 반면 gRPC는 클라이언트와 __함수__를 공유한다.
• REST API는 HTTP 상태 코드로 표시하는 반면, gRPC는 에러 코드를 사용한다.

장점

• 속도가 빠름
• 엄격한 타입 검사
• 이중 스트리밍

단점

• 엄격한 타입 검사 때문에 주기적으로 변경하고 업데이트하는 것이 부담이 될 수도 있다.
• 부족한 생태계: 비교적 최근 기술이기 때문에 환경이 국한되어 있고 자료가 부족하다.

호화 방식에는 크게 두 가지가 존재한다.

양방향 암호화와 단방향 암호화가 바로 그것이다.

단방향 알고리즘

단방향 알고리즘은 암호화는 가능하지만 복호화는 불가능한 방식이다.

데이터의 진위여부는 확인하고 싶으나, 데이터 내부의 privacy는 지키고 싶을 때 사용

전자 서명에서 많이 사용한다.

대표적으로 HASH 방식에 기반한 알고리즘들이 있다.

MDC 방식: Modification Detection. 키 없음

- SHA, MD5, HAVAL, ...

MAC 방식 (메시지 인증, 디지털 서명): Message Authentication. 키 있음

- HVAC, NMAC, ...

양방향 알고리즘

양방향 알고리즘은 암호화가 가능하고 복호화도 가능한 방식이다.

크게 **대칭키 방식**과 **비대칭키 방식**이 있다.

대칭키 방식

_대칭키 방식_

데이터 암호 목적

암호화 키 == 복호화 키

Stream 방식

_Stream 방식_

1bit씩 연산. XOR 연산. H/W 구현 용이

예시

• True Random: OTPad
• Psuedo Random: RC4(PPTP, WEP, TKIP)

Block 방식

_Block 방식_

2bit 이상 묶음 연산. S/W 구현 용이

예시

• Festel: DES
• SPN: **AES**
• 기타: IDEA

단점

1. 키가 탈취되었을 때, 모든 정보가 털린다.
2. 안전하게 사용하기 위해서는 모든 사용자가 서로 다른 키를 가져야 하므로 키 관리를 어떻게 할 것인가? 라는 문제에 대한 고민 필요.
3. 키를 안전하게 주고 받는 방법에 대한 고민 필요.

비대칭키 방식

_공개키 방식_

대칭키 교환 용도

암호화 키 != 복호화 키

예시

1. client가 private key/public key를 암호화하여 server에 전달
2. server가 전달받은 public key로 평문을 암호화하여 client에게 전달
3. server로부터 전달받은 암호를 client가 가진 private key로 복호화

종류

• 인수분해방식: RSA(디지털서명)
• 이산대수: DH(키교환), DSA(디지털서명)
• 타원곡선방정식: ECC

참고 링크

• 암호화 알고리즘 종류와 분류 (https://velog.io/@inyong_pang/Programming-%EC%95%94%ED%98%B8%ED%99%94-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EC%A2%85%EB%A5%98%EC%99%80-%EB%B6%84%EB%A5%98)
• 개인정보와 암호화(단방향, 양방향 암호화) 정리 (https://akku-dev.tistory.com/33)

보안을 위해서라면 암호화는 중요하다.

해시 계열

해시(Hash)

해시는 암호화 과정이라고 하기에는 어렵고 보안이 이미 뚫린 바가 있으나,

암호화 기법과 함께 사용하여 시너지를 발휘할 수 있다.

•  임의의 크기를 가진 데이터를 하나의 고정된 데이터로 변환시킨 것
• 예시: "12345" -> 고정 길이 해시 값

MD5 (Message Digest algorithm 5)

RFC1321로 지정된 128비트의 해시 함수.

본 데이터가 다를지라도 같은 해시 값이 생성(충돌) 되고 이미 보안이 뚫린 바가 있기에, 보안 관련 용도로는 사용하지 않음.

• 원프로그램 / 파일 무결성 검사할 때 사용
• 32개의 16진수로 이루어진 해시 값 생성 (16^32)

SHA (Secure Hash Algorithm)

서로 관련된 암호학적 해시 함수들의 모음.

• TLS, SSL, PGP, SSH, IPSec 등 많은 보안 프로토콜에서 채택
• 원본 데이터의 작은 변화에도 해시 값의 변동이 매우 큼
• SHA-2 계열 알고리즘은 현재까지 많이 쓰이고,SHA-256 / SHA-512가 널리 쓰임

암호화 알고리즘

Adaptive Key Derivation Dunction

• 다이제스트(해시화된 데이터)를 생성할 때 **Salting**과 **Key-Stretching**을 반복하여 공격자가 유추할 수 없게 보안의 강도를 선택할 수 있는 함수
• Salting: 해시 함수 실행 전 원문에 임의의 문자를 덧붙여 보안성을 높이는 기법
• Key-Stretching: 입력한 패스워드의 다이제스트를 생성하고, 생성된 다이제스트를 입력값으로 하여 다이제스트를 생성하는 것을 반복하는 기법

PBKDF2 (Password-Based Key Derivation Function)

해시 함수의 컨테이너 역할을 하는 함수

• 검증된 해시함수만을 사용
• 해시함수와 salt를 적용하여 해시함수의 반복 횟수를 지정하여 암호화
• 가장 많이 사용되는 ISO 표준에 적합한 알고리즘

Bcrypt

패스워드 해싱 함수 (Blowfish 암호 기반)

• 현재까지 가장 강력한 암호화 알고리즘
• 해시화 반복횟수를 늘려 연산속도를 늦출 수 있어, 연산 능력이 강화된 Brute-Force 공격에 대비 가능

Blowfish 알고리즘

- 32비트 ~ 448비트의 가변길이의 키를 이용하는 비밀키 블록암호

Brute-Force

- 랜덤한 값을 무차별적으로 대입하여 해시 알고리즘의 원본 데이터를 알아내는 공격 기법

Scrypt

PBKDF2와 유사한 함수

• 다이제스를 생성할 때 메모리 오버헤드를 갖도록 설계되어 Brute-Force 시도 시 병렬화 처리 어려움
• Bcrypt보다 더 경쟁력 있다고 평가 됨

Seed

한국인터넷진흥원(KISA)에서 개발한 128비트의 대칭키 블록 암호 알고리즘

스프링(Spring) 프레임워크

• 엔터 프라이즈 어플리케이션 개발을 위해 만들어진 경량 프레임워크
• 특징
  • POJO (Plain Old Java Object)
  • 모듈식 프레임워크
  • 높은 확장성, 범용성, 광범위한 생태계
  • 경량급 오픈소스 프레임워크

POJO Plain Old Java Object

• POJO: 특정 기술에 종속되지 않는 순수 자바 객체
• 모든 스프링 어플리케이션은 POJO 객체와 스프링 컨테이너를 포함한다.
• POJO 클래스를 개발하고, 스프링 컨테이너는 이 POJO 객체들을 관리한다.
  • 스프링 컨테이너는 이 POJO 객체들의 생성, 의존성 주입, 생명주기를 관리한다.
• 스프링 컨테이너가 관리하는 객체를 Bean 이라고 한다.
• 스프링 컨테이너: o.s.Context.ApplicationContext 인터페이스를 구현한 구현 클래스

스프링 프레임워크의 세가지 핵심 요소

• 의존성 주입 (Depenency Injection)
  • 런타임 시점에 의존성을 주입함으로써, 객체간 종속성을 유동적으로 하기 위함
• 관점 지향 프로그래밍 (AOP: Aespect Oriented Programming)
  • 기능적 요구사항과 비기능적 요구사항 분리
• 서비스 추상화 (Service Abstraction)

용어 정리

• Bean: 스프링 컨테이너가 관리하는 객체
• POJO: 특정 기술에 종속되지 않은 순수 자바 객체
• 도메인: 소프트웨어 상에서 해결해야 할 비즈니스 영역의 문제
• 기능적 요구 사항: 사용자에게 직접 서비스하는 기능을 정리한 것
• 비기능적 요구 사항: 서비스 기능은 아니고, 개발에 필요한 기능을 정리한 것
  • 예시: 로그 남기기, RDBMS 트랜잭션 시작 & 커밋하는 코드
  • 다시 말하자면, 사용자가 알 수 없는 내용