람다함수 코드는 위 그림과 같은 순서로 실행되는데, 저 과정들 중 코드를 실행하기 위한 환경을 준비하는 파란 부분을 콜드 스타트(Cold Start)라고 한다. 이와 반대로 이미 실행 환경이 갖추어져 있다면 Cold Start부분은 스킵하고 바로 노란색 부분부터 실행이 가능한데 이것을 Warm Start라고 한다. 람다는 실행시간에 비례하여 요금이 청구되므로 Warm Start가 훨씬 실행시간도 단축되고 비용도 적게 든다.

로그 분석

Cold Start

우선 실행 환경이 하나도 갖추어지지 않은채 처음부터 준비해야 하는 Cold Start를 해보자.

Duration: 31949.48 ms    Billed Duration: 31950 ms    Memory Size: 2048 MB    Max Memory Used: 645 MB    

첫 번째 실행은 CloudWatch를 이용해 모델 분석 API요청 로그를 보면 무려 31.9초나 걸린것을 볼 수 있다.

로그를 자세히 살펴보니, 실제 모델 추론시간보다 모델을 메모리에 적재하는 초기화 시간이 훨씬 더 오래 걸리고 있었다.

Warm Start

Lambda는 효율성을 위해 일정 시간 동안 실행 환경(컨테이너)을 파괴하지 않고 유지한다. 이 환경이 사라지기 전에 함수를 다시 호출하면 이미 메모리에 모델이 적재된 상태인 Warm Start가 가능하다.

Duration: 214.72 ms    Billed Duration: 215 ms    Memory Size: 2048 MB    Max Memory Used: 653 MB    

이에 반해 두 번째 실행 (Warm Start)에서는 첫 번째와는 다른 사진을 분석시켰음에도 0.2초로 실행시간이 확 줄어든 것을 볼 수 있다.

이는 YOLO모델 로드 코드를 전역 변수 영역에 배치하였기 때문이다. Warm start로 재실행시, 이미 메모리에 적재된 모델 객체를 즉시 참조하게 되면서 무거운 초기화 과정이 생략되었기 때문이다.

Provisioned Concurrency를 통한 Warm Start

그러나 Warm start는 영구적이지 않다. 람다는 일정시간동안 요청이 없으면 리소스를 회수하기 위해 실행 환경(컨테이너)를 삭제한다. 이 경우 다시 Cold Start가 발생한다는 한계가 있다. 이용자가 많은 서비스라면 요청이 잦아 대부분의 요청에서 Warm Start상태를 유지할 수 있겠지만, 개인 프로젝트처럼 사용자가 거의 없는 경우에는 요청이 잦아봐야 몇시간에 한 번일테니 매번 Cold Start가 되어 사진 하나를 분석하는데 30초를 넘게 기다려야 할 것이다.

이를 해결하기 위한 방법으로는 2가지가 있는데

첫번째는 프로비저닝 동시성(Provisioned Concurrency)이다. 이 기능은 EC2처럼 계-속 람다 함수를 켜두는 것이다. 프로비저닝 동시성 기능을 활성화하면, 설정된 개수만큼의 인스턴스를 초기화하여 대기시켜 둔다. 그러면 Cold Start가 발생하지 않고 Warm Start로 즉시 실행되게 된다.

프로비저닝 동시성 기능을 활성시킨후, 람다가 컨테이너를 삭제할만한 시간동안 호출을 하지 않았다.

다시 앱에서 람다 함수를 호출해보았더니 훨씬 단축된 실행시간에, 로그에 Init duration(초기화 시간)도 찍히지 않는 것을 볼 수 있었다. 즉, 성공적으로 Warm Start가 적용된 것이다.

[실행시간이 0.27초로 단축되었다]

다만 이는 EC2처럼 계속 실행시켜 두는 것이나 다름없다보니 비용이 꽤 있는편이다. 그래서 좀 더 심화된 최적화 방법으로, 프로비저닝 오토스케일을 사용하기도 한다고 한다.

프로비저닝 오토스케일링은 트래픽이 높은 시간대에 맞춰 프로비저닝을 오토스케일링하여 가격을 최적화하는 방법이다.

기본 지식

[들어가기전 기본 용어 정리] EC2 : AWS에서 제공하는 가상 서버 대여 서비스의 이름이다. 인스턴스 : EC2서비스를 사용해서 만들어진 실제 가상 서버 한 대 단위를 이르는 말

스케일링 - 자원을 늘리는 것 vertical scale 수직적 스케일링 - 하나의 자원 자체의 '성능'을 높이는것 horizontal scale - 자원의 규모, 수를 늘리는것 - 대게 이걸 씀 (탄력적으로 쪼개기 쉬움) - 대신 아키텍처 복잡

-> Auto Scaling - horizontal scaling 자동화 EC2 Auto Scaling - 정확한 수의 EC2인스턴스를 보유하도록 보장 - 최소, 최대 숫자 인스턴스 설정 가능 - CPU 부하에 따라 인스턴스 크기 조정 - 가용 영역에 인스턴스가 골고루 분산되도록 인스턴스 분배

NAT(Network Address Translation) - 사설 IP를 공용 IP로 변환해주는 방법 - Dynamic NAT - NAT Pool에서 현재 사용가능한 공용 IP하나 가져다 씀 - Static NAT - 이미 사설과 공용 IP가 1:1 매칭이 되어 있음(수가 같음) - PAT(Port Address Translation) - 가장 많이 쓰이는 형식 - 하나의 공용 IP가 사설망 전체를 대표함 - 포트별로 PC를 다르게 구분함 - 포트 포워딩(Port Forwarding) - PAT 원리를 수동으로 설정하여 특정 포트에 특정 기기를 연결시키는 설정작업 - 보통 공유기가 이 역할을 함

CIDR는 그냥 IP주소 표기법. 클래스 단위로 빌리면 너무 비싸기 때문에 정교하게 수를 조정가능한 CIDR표기법이 생긴것. 할당받은 공용 IP 개수에 x 사설 IP주소로 해서 인터넷 연결 가능한 기기를 많이 만들 수 있음.

출처 : https://www.youtube.com/watch?v=IJgAIbxxJCE

보통 EC2 인스턴스로 서버를 띄운다고 한다면, 그 기본 틀의 구조는 위와 비슷하다. 각 구성요소를 하나씩 알아보자

VPC(Virtual Private Cloud)

• 외부와 격리된 가상 네트워크 단위. 쉽게 말해 사설망
• 원칙상으론 퍼블릭 인터넷에서 접근불가,(하지만 인터넷 게이트웨이를 통해 접근 가능) AWS내부에서도 외부를 통해 접근해야함
• 다양한 서브넷 구성 가능
• 인터넷에 노출되지 않는 EC2구성 등 보안 설정 가능
• 하나의 VPC는 하나의 리전밖에 커버하지 못하기 때문에 리전과 리전 사이를 하나의 VPC가 커버할 수는 없음. 리전의 수만큼 VPC가 존재해야 함.
• EC2를 띄우려면 필수적으로 VPC도 설계해야함 애초에 계정을 만들면 디폴트 VPC가 자동으로 생성된다.

왜 VPC가 필요할까? 서버를 냅다 아무 환경에나 띡하고 띄울 순 없다. 일단 네트워크 환경을 만들어주어야 한다. VPC는 쉽게 말하면 거대한 공용 클라우드(AWS)에서 나만의 울타리를 치는거다. 이 울타리가 없으면 밖에서 내 사설 IP주소만 알게 되면 그냥 바로 침범이 가능해진다. 그러나 VPC라는 울타리를 치면 내가 허락한 문(인터넷 게이트웨이)과 규칙(보안 그룹)등을 통과해야지만 들어올수 있기 때문에 보안을 위해서는 필수적이다. 또한 사설 IP대역(내 정원의 크기)도 마음대로 지정이 가능해진다. 그리고 내가 소유한 땅이나 다름없으니 거기 안에서 역할에 따른 구역(서브넷)을 자유롭게 나눌수도 있다. 그렇기 때문에 VPC는 EC2뿐만 아니라 RDS, Lambda등 대부분의 서비스에서도 필수적인 요소이다.

<구성 요소들>

1. 서브넷

• VPC의 하위 단위. VPC에 할당된 IP를 작은 단위로 분할한 개념. 서브 네트워크
• 하나의 서브넷은 하나의 가용영역 안에 위치
• 사용 가능한 IP개수는 -5개
• 외부에서 접근이 가능한 퍼블릭 서브넷은 웹서버 등의 용도로, 외부와 아예 차단된 프라이빗 서브넷은 데이터베이스, 로직 서버등의 용도로 사용됨.(라우트 테이블에 밖으로 나갈 수 있는 IP자체가 없음)
• 가장 작은 서브넷 단위는 CIDR단위 /24(11개, 16-5)

2. 인터넷 게이트웨이

• 기본적으로 외부와 통신이 안 되는 VPC가 외부의 인터넷과 통신할 수 있도록 경로를 뚫어주는 리소스(쉽게 말해 가상환경에 현실세계로 향하는 포탈 뚫어주는 역할)
• 공유기처럼 사설IP와 공용IP간의 변환 역할을 수행함. 다만 공유기와 IGW의 차이라면 공유기는 자신의 고유 IP로 변환해서 내보내고 IGW는 해당 리소스에 할당된 공용 IP와 매핑해서 보냄
• 이름에서 알 수 있듯이 폐쇠적으로 인터넷 필요없이 운영할 서비스면 굳이 필요없기도 함
• 무료임

IGW(인터넷 게이트웨이)도 공유기처럼 그냥 IGW자체가 공용 IP소유하고 있으면 편하지 않나? 공유기는 대게 안에서 밖으로 나가는 요청이 먼저 시작되므로 라우트 테이블에 먼저 어떤 사설IP가 어떤 포트로 나갔는지 기록이 가능함. 그러나 IGW로 연결된 서비스는 대게 웹 서버와 같은 외부에 노출되어야 하는 서비스다. 그런데 만약 인바운드 요청이 아웃바운드 요청보다 먼저 들어오게 된다면, 아직 라우트 테이블에는 아무 기록이 없으니 어디로 매핑을 해줘야 할지 모르게 된다. 그러므로 외부에서 내부로 들어오는 요청이 원활하게 이루어져야 하기 때문에 그냥 리소스 자체에 공용 IP를 박아서 바로 연결이 되도록 한 것이다.

3. 보안그룹

• 방화벽의 역할을 하는 서비스
• 기본적으로 모든 포트 비활성화
• 특정 포트 허용만 가능, Deny는 불가능
• 인스턴스에 붙어있음. 하나의 인스턴스에 여러개의 보안그룹 설정 가능
• 보통 8080번 포트와 3000번 포트 (TCP)를 열어두는데 우리는 웹 애플리케이션 및 API 서버를 주로 만들기 때문에 이와 관련된 통신을 허용하기 위함임
• 보안그룹은 인바운드 들어왔던걸 기억해서 아웃바운드가 자유롭지만(StateFul), NACL은 인바운드가 통과되었던 것이라도 아웃바운드 할 때 또 체크해야함(Stateless)

4. NACL

• 서브넷 단위(서브넷 들어가기전에 NACL을 거쳐야함)
• 포트 및 IP 직접 Deny가능(특정 IP 블락 가능)
• 규칙번호 100번 단위, 작은 수부터 규칙 적용

5. 라우트 테이블

• 트래픽이 어디로 가야 할지 알려주는 이정표
• 0.0.0.0/0(외부 아이피 대역)이 목적지일 때, 인터넷 게이트웨이로 나가도록 설정된 라우팅 테이블을 서브넷에 붙이면, 해당 서브넷은 퍼블릭 서브넷이 되는것임

6. NAT Gateway

• VPC의 프라이빗 서브넷에 있는 인스턴스에서 외부의 인터넷과 통신하기 위한 통로
• 서브넷 단위(퍼블릭 서브넷에 있어야함)
• NAT Gateway는 퍼블릭 서브넷에 위치해서 프라이빗 서브넷에 위치한 인스턴스 대신에 인터넷에 연결해 줌(업데이트나 다운로드 같은 외부 인터넷 연결이 필요할 때)
• 보안을 위해 아웃바운드(안에서 밖으로 일방통행)만 가능

7. Bastion Host

• Private Subnet의 자원에 접속이 되도록 도와주는 호스트
• 이건 NAT Gateway랑 반대로 외부에서 프라이빗 서브넷에 접근하기 위한 EC2 인스턴스
• 퍼블릭 서브넷에 위치해야함(프라이빗 서브넷 중개 역할이니까)
• private서비스에 접근할땐 Session Manager를 사용하기도

8. Elastic Load Balancer

• 다수의 트래픽을 분산 시켜주는 서비스
• Health Check를 통해 트래픽을 발생시켜 Instance가 살아있는지 체크
• 지속적으로 IP주소가 바뀌어 고정 불가능하기 때문에 항상 도메인 기반으로 사용
• 서버가 죽으면 로드밸런서가 새로운 복제 서버를 만들어(AMI로) 요청을 거기로 우회시키고 기존 죽은 서버는 삭제시킴(고가용성 설계)
• 얘도 Bastion Host랑 비슷하게 프라이빗 서브넷에 인바운드 요청 전용 길인건 맞지만, 로드밸런서는 외부 요청의 메시지만 서버에 전달하고 답을 받아다주고 외부와 직접 연결되는 것은 막음(reverse proxy). 다시 말해 외부 손님을 위한 길이나 마찬가지라 외부 요청인 HTTP/HTTPS만 알아듣고 80/443번 포트만 열려있음. 이에 반해 Bastion Host는 관리자가 직접 서버 유지보수나 설정을 만지기 위해 길을 뚫어놓는 것에 가까움.(프라이빗 서브넷은 관리자도 함부로 접속 불가능하기 때문에) 그래서 보통 관리용 포트인 22(SSH)번 포트만 열어두고 특정 IP만 들어오게 해 둠.

왜 ELB의 IP는 유동적인가? ELB의 IP는 계속해서 바뀌기 때문에 도메인 주소를 기반으로 작동함. 이유는 ALB도 결국 AWS가 관리하는 인스턴스(서버)인데 모든 트래픽이 ALB를 거쳐가기 때문에, 갑자기 트래픽이 늘어나면 AWS는 로드밸런서를 5대, 10대로 늘이고 이렇게 로드밸런서 서버를 늘릴 때마다 새로운 IP를 계속 추가함. 그리고 이 여러 개의 IP 주소를 하나의 DNS 이름(도메인) 아래에 묶어버림. 만약 IP가 하나뿐이라면 모든 트래픽이 거기로 몰려 병목현상이 일어날것임.

EC2

EC2(Elastic Compute Cloud) 구성요소

1. EBS

• 하드디스크 역할
• 종료 시 삭제 옵션(인스턴스가 종료될때 같이 삭제할 건지 여부)
• 암호화(하드디스크 암호화해서 데이터 저장)

2. 스냅샷

• 특정 시간의 EBS상태의 저장본(S3에 증분식 저장)

3. AMI

• EC2인스턴스를 실행하기 위해 필요한 정보를 모은 단위
• 인스턴스 복제할때 커스텀 AMI를 생성해서 복제가능

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(S):
    stack = []
    mapping = {')':'(', '}':'{', ']':'['}

    for element in S:
        if element in '{[(': # 여는 괄호 나올때때
            stack.append(element)
        else: # 닫는 괄호 나올때
            if not stack: # 스택 비어있으면 중첩 문자열 아님
                return 0 

            tmp = stack.pop()
            if tmp != mapping[element]:
                return 0 
            element

    if stack: # 스택에 남아있음
        return 0
    else: 
        return 1

배열의 A의 원소 3가지 중 A[P] + A[Q] > A[R], A[Q] + A[R] > A[P], A[R] + A[P] > A[Q]. 를 만족하는 숫자 3개 찾기

가장 큰 수가 다른 숫자 2개보다 작아야함 삼각형을 만들 수 있는 3 수가 존재하면 1, 아니면 0 시간복잡도 nlogn 이하, 요소 범위 -2,147,483,648..2,147,483,647(음수 싹 다 제외해야함)

코드

정렬시켜서 0이상인 수부터 3개씩 묶어서 검사하면 될 듯 시간복잡도는 2N

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(A):
    A.sort(reverse = True)

    for idx, num in enumerate(A):
        if idx+2 > len(A)-1 or A[idx+2] < 0: # 음수가 오면 안됨
            return 0
        if A[idx] < A[idx+1] + A[idx+2]: # 삼각형 조건 만족하는지 검사
            return 1

    return 0

배열 A의 원소 3개의 곱 중 가장 큰 것을 찾는 문제 A의 크기는 10만 이하 배열 A의 요소의 크기는 -1000 ~ 1000

A의 범위가 음수를 포함시키니 아마 가장 큰 수의 조합은 양수x양수x양수 이거나 음수x음수x양수가 될것이다.

정렬시켜서 2가지 버전을 만든 다음에 더 큰수를 반환하면 될 것 같다.

최종 제출 코드

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(A):

    A.sort()
    length = len(A)

    return max(A[-1] * A[-2] * A[-3], A[0] * A[1] * A[-1])

배열에서 나오는 숫자의 종류 가짓수를 계산하는 문제이다. N의 범위는 10만, 배열 A의 요소의 크기는 -100만 ~ 100만.

최종 제출 코드

def solution(A):
    x = set()

    for i in A:
        x.add(i)

    return len(x)

set사용법 익히라고 낸 문제인가 풀려서 좀 당황함.

솔직히 문제 이해하는게 너무 어려웠다. 예시로 주어진 예제도 이해를 못 해서 계속 ???상태로 문제만 한 10번 읽었다.

문제를 정리해보자면 가로지르는 차의 수를 구하는게 목표이다. 여기서 passing을 내가 이상하게 해석해서 문제 이해가 안 됐던것... 0은 오른쪽, 1은 왼쪽으로 가는 차이고 차량끼리 서로 교차하게 되는 수를 구한다고 생각하면 된다. 가로지르는 차의 수가 10억개를 넘으면 -1반환하고 수 범위 10만이다.

고민 포인트

역시 시간이 포인트인 문제인듯. 이중포문써서 단순 더하기로 세면 쉽게 풀리겠지만 그러면 무조건 타임아웃 뜰 듯.

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(A):
    count = 0

    for idx, num in enumerate(A):
        if num == 0:
            for num2 in A[idx+1:]:
                if num2 == 1:
                    count += 1

    return count

역시나

트러블 슈팅

핵심은 0이 나온 뒤의 수들 중, 1의 출현수를 구하는 것이다. 그래서 배열의 원소들의 종류가 0과 1뿐인걸 이용해서 sum()을 이용해 전체합(=1의 전체 개수)을 구했다. 그 다음 for문으로 A를 순환하며 현재까지 발견한 1의 수를 카운트해서 전체수에서 빼 주는 방식으로 간단하게 이후에 나오는 1의 수를 계산할 수 있었다.

최종 제출 코드

def solution(A):
    total_num = sum(A) # 배열의 모든 1을 더한 수
    count_1 = 0 # 여태나온 1의 수
    result = 0 # 반환할 결과

    for num in A:
        if num == 0:
            result += (total_num - count_1)
            if result > 1000000000:
                return -1
        else:
            count_1 += 1

    return result

A가 1~N까지의 수가 단 한 번씩만 나오는 순열이 맞으면 1반환, 아니면 0을 반환하는 문제이다.

N is an integer within the range [1..100,000]; each element of array A is an integer within the range [1..1,000,000,000].

라는 조건으로 보아 시간복잡도는 O(nlogn)안에 해결해야 할 것 같고, A의 요소의 범위가 10억인걸 보아 메모리를 신경써야 하는 문제같다.

보통의 코딩문제 메모리 제한이 128MB ~ 512MB 정도이니 리스트는 크기 500만 이내, Set이나 딕셔너리는 크기 100만 이내로 제한해야 한다.

고민 포인트

A가 순열인지는 무조건 배열을 다 돌아야지 알 수 있음 -> 순열의 수의 수가 A의 크기이기 때문

그렇다면 순열이 맞는지 확인하는 것보다 순열이 아닌 조건에서 바로 return 0으로 쳐낸 다음, 반복문을 문제없이 다 돌았다면 순열이 맞다는 방식으로 판단하는게 좋을 것 같다.

순열은 1부터 시작해서 N의 최대 크기가 100000이니, 만약 100000이상인 수가 나오면 볼 것도 없이 바로 순열이 아니다. 그리고 중복된 수도 나올 수가 없으니 이 두 조건을 불충족하면 바로 순열 탈락이다.

2가지 방법을 생각해봤다.

set 방법 Set생성하고 반복문으로 A순환하며 처음 발견한 수 Set에 add하기 중복된 수 나오면 바로 0반환 100000초과인 수 나오면 바로 0반환 무사히 반복문 끝났다? -> 순열 확정!

체크 배열 방법 A의 크기만큼(10만 크기 이하)의 False배열 생성 반복문 돌며 해당하는 수의 인덱스 True로 변환 중복된 수가 나오거나 10만 초과인 수 나오면 바로 return 0 반복문 무사히 끝나면 return 1

Set이 해시테이블을 사용하기 때문에 배열보다 메모리를 아주 조금 더 사용한다는 말에 이번엔 Set말고 배열을 이용해 보기로 하였다.

최종 제출 코드

체크 배열 방법

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(A):
    check_arr = [False] * (len(A) + 1) # 0 인덱스는 안 쓰니까 +1

    for num in A:
        if num > len(A):
            return 0
        elif check_arr[num]: # 중복인 수 발견
            return 0
        else:  # 해당 수가 미발견 상태이면
            check_arr[num] = True

    return 1

# A가 순열이면 1 반환, 아니면 0반환

# 체크 배열 방법
# A의 크기만큼(10만 크기 이하)의 False배열 생성
# 반복문 돌며 해당하는 수의 인덱스 True로 변환
# 중복된 수가 나오거나 10만 초과인 수 나오면 바로 return 0
# 반복문 무사히 끝나면 return 1

Set으로 하면 훨씬 간결하게 할 수 있다해서 그냥 Set도 해봤다. 리스트를 Set으로 변환하고 변환된 Set의 크기가 기존 배열 크기와 같고 요소들의 크기가 모두 A의 길이 이하이면 된다.

set 방법

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(A):
    N = len(A)
    visited = set(A) # 중복 제거된 A

    # 길이가 N과 같고 최대값이 N과 같으면 순열
    if (len(visited) == N) and (max(visited) == N):
        return 1

    return 0

0에 위치한 개구리가 X+1로 가기 위한 최단 시간을 구하는 문제이다. 배열 A에 주어진 숫자들은 각 초(인덱스)에 떨어진 나뭇잎의 위치를 가리킨다. 그리고 X+1로 가기 위한 길이 완성된 최단 시간을 구하면 된다. ex.배열 A가 [1,3,1,4,2,3,5,4]라면 0초엔 1번 위치, 1초엔 3번 위치에 떨어진다는 뜻. 최단 시간은 2번 위치에 나뭇잎이 떨어진 다음 초인 5초.

고민 포인트

문제 주요 조건들을 정리해보면 1. 1X까지가 매워져야함 2. 이동 불가능이라면 -1반환 3. 시간 복잡도 효율성 생각하기~

어떻게 할 지 고민되었던 지점 이미 나온 위치인지 아닌지 어케 구분하지? -> 얘만 구분되면 개수를 세든 해서 길이 완성되었는지 여부 판단은 쉬울듯

일단 1차원적으로 X크기의 배열을 만든 다음에 전부 -1로 초기화해서, A배열에서 해당하는 위치의 숫자를 발견하면 그 배열의 해당 인덱스를 양수로 바꾸는 방법을 생각해보았다. 그런데 이 방법은 배열A를 X번 순회하는 것도 시간복잡도가 큰데, X크기의 배열이 전부 양수가 되었는지 또한 계속해서 검토를 해주어야 하기 때문에 무조건 시간 초과할 것 같아서 기각.

그래서 1X까지 빠짐없이 매워야 한다는 특징을 이용했다. 즉, 랜덤한 숫자를 찾는게 아니므로 1X까지의 정돈된 수를 차례대로 찾아간다는 느낌. 두 방식의 차이라고 한다면 두 번째 방법은 수를 차례대로 찾기 때문에 첫 번째처럼 이미 메워진 위치인지를 검사할 필요가 없이 마지막 칸(X)를 찾으면 바로 다 찾았음을 알 수 있다.

1. 배열에서 1~X까지 하나하나 원소를 찾는데 해당 원소를 찾은 인덱스 위치가 큰 것으로 점점 교체해나가기
2. 만약 중간에 발견되지 않으면 즉시 중단하고 -1반환

   # you can write to stdout for debugging purposes, e.g.
   # print("this is a debug message")
   

def solution(X, A): result_time = 0

for i in range(1, X+1):
    for idx, num in enumerate(A):
        if i == num:
            if result_time < idx:
                result_time = idx
            break # 남은 배열 원소들은 확인할 필요 X

        # 여기까지 왔다는 것은 배열에 해당 요소가 없다는 뜻
        if idx >= (len(A)-1):
            return -1

return result_time

## 트러블 슈팅
![](https://velog.velcdn.com/images/hyun_ji/post/d21e6d54-17d2-4158-a4cc-528f63f20d2e/image.png)
정확성 테스트는 모두 통과했는데 성능 테스트는 모조리 타임아웃 에러가 났다.

지금 코드의 시간복잡도는 O(n^2)이니 여기서 더 줄여야한다. 입력 범위가 $N, X \le 100,000$이니, 최악의 경우를 가정했을 때 $O(N)$ 또는 $O(N \log N)$ 복잡도 내에 해결해야한다.

### 데이터 크기에 따른 시간 복잡도
보통 코딩문제 제한시간이 1~6초이고 파이썬의 초당 연산 횟수를 대략 20000000회라고 가정. 
> $N \le 20$    |  $O(2^N)$ 또는 $O(N!)$    | 재귀, 백트래킹, 완전 탐색 (브루트 포스)
$N \le 500$    |     $O(N^3)$    | 플로이드-워셜, 단순 3중 for문
$N \le 2,000$        | $O(N^2)$    | 이중 for문, 삽입 정렬, 거품 정렬
$N \le 100,000$ |    $O(N \log N)$    | 정렬, 이진 탐색, 우선순위 큐(Heap)
$N \le 1,000,000$    | $O(N)$    | 단일 for문, 스택, 큐, 해시(Set/Dict)
$N \ge 10^8$ |    $O(\log N)$    | 유클리드 호제법, 고속 거듭제곱

위의 표는 N의 범위별 적용하기 적절한 시간복잡도이다.  
예를들어 N의 범위가 1,000,000이하라면 시간복잡도가 N이거나 logN인 방법으로 풀 수있다. 이것보다 큰 것들(ex.N^2)을 사용하면 시간초과.

원래 코드는 O(N^2)의 시간복잡도라 100000 x 100000 = 10000000000(100억) 번의 연산이 수행된다. 즉, 100억 % 2천만 = 500(초)가 걸린다는 소리. 

중요한건 N의 입력가능 범위! 가능하면 N의 최악의 연산 횟수가 1000만 단위를 넘지 않게 하는게 좋다. (파이썬의 연산 횟수를 고려했을때)

그래도 이참에 시간복잡도 계산법은 확실히 알고가게 된 듯...

배열을 정렬 후 이진탐색하는것을 생각해봤는데 이건 잎이 떨어진 순서가 섞여버려서 안된다. 

도저히 아이디어가 생각이 안 나서 AI에게 힌트를 달라했더니 Set이나 체크 배열을 활용하여 전체를 단 한 번만 훑어보되 그때그때 새로운 것을 발견하면 찾은 개수를 증가시키라 조언을 주었다. 이러면 언제 다 찾았는지도 쉽게 알 수 있다. 

내가 기존에 짠 코드는 1찾으려고 전체 함 훑고, 2찾으려고 전체 함 훑고 이런 식인데 저 방식은 한 번 쫙 훑을 때 어 3이네? 어 1이네? 하고 새로운 것들 그때그때 찾아내고 한 번 본건 2번 확인하지 않는다. 종료조건 쉽게 알아내는 법에 꽃혀서 효율적인 탐색 방법은 생각 못 한게 패착의 원인인듯. 


## 최종 제출 코드
**Set방식**
```python
# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")

def solution(X, A):
    visited = set()

    for idx, num in enumerate(A):
        if num <= X:
            visited.add(num) 

        if len(visited) == X:
            return idx # 마지막으로 찾은 수의 인덱스가 젤 클테니까 

    return -1 # for문에서 끝나지 않았다면 해당 위치가 존재하지 않는다는 뜻뜻


# A를 한 번 순회
# 처음 찾는 위치면 set에 추가(X보다 작은수만 추가가능)
# set의 크기가 X와 같을때까지 반복

set은 탐색할때 Hash알고리즘을 사용하기 때문에 값을 추가할때 이미 중복된 값인지 검사할때의 시간복잡도가 O(1)이다.

정수X, D, Y가 주어졌을 때, X에 위치한 한 번에 D만큼 점프하는 개구리가 Y와 같거나 큰 거리만큼을 가는데 필요한 최소 점프수를 구하는 문제

단순히 X값이 Y보다 커질때까지 D를 더해주면 되나? 라고 생각하고 코드를 짰는데

def solution(X, Y, D):
    jump_count = 0

    while X < Y: # 현재 위치가 목표 지점에 닿을때까지 반복
        X = X + D
        jump_count += 1

    return jump_count

뭔가 분명 이렇게 쉬울리가 없다는 생각에 예외를 찾아보려고 생각해봤는데... X, Y, D 전부 양의 정수이고 Y값이 X값 보다 크다는 조건까지 전부 잘 명시되어 있어서 일단 제출해보았다.

그럼 그렇지... 생각해보니 성능보다 정확성을 요구했던 이전 문제들과는 달리 이 문제의 테마는 시간 복잡도다.

통과 못 한 케이스들 전부 시간 초과.

트러블 슈팅

O(n)에서는 시간 초과가 나는 것 같으니 시간복잡도를 O(log n)이나 O(1)으로 줄여야 한다.

최종 제출 코드

# you can write to stdout for debugging purposes, e.g.
# print("this is a debug message")
import math

def solution(X, Y, D):

    jump_count = (Y - X) / D
    result = math.ceil(jump_count) # 결과값 올림

    return result

(최종위치 - 현재위치) / 이동거리 의 결과를 올림하면 Y에 도달하기 위한 최종 이동 횟수가 나온다. 시간복잡도는 O(1).

배열 A와 정수 K가 주어지면, 배열 A의 원소들을 K번 오른쪽으로 옮기는 문제이다.

조건이 복잡하지 않고 단순히 모든 원소를 다음칸으로 한 칸씩 회전시킨다는 조건에 처음엔 인덱스를 이용해서 [현재 인덱스 + 1]로 자리를 재지정하면 될려나 라고 생각했다. 근데 간단하게 생각하면 결론적으로 회전한 듯한 모양새만 만들면 되는 것이니 마지막 원소를 떼서 앞에다 붙이면 되는거 아닌가?라는 생각이 들었다.

def solution(A, K):

    for i in range(K):
        last_num = A.pop() # 맨 뒤의 원소 떼서
        A.insert(0, last_num) # 맨 앞에 붙여넣기

    return A

그래서 이렇게 초단순하게 코드를 짰는데 테스트 케이스 3개가 다 통과하는것이 아닌가. 그래서 설마 하는 마음으로 제출해봤는데.

역시 최종 테스트 코드를 100% 통과하진 않았다.

트러블 슈팅

통과하지 못한 테스트 케이스를 살펴보니

 File "/tmp/exec_user_s3cqt9mm/solution.py", line 7, in solution
    last_num = A.pop()
               ^^^^^^^
IndexError: pop from empty list

라는 에러 메시지로, 빈 배열이 주어졌을때 pop()을 해서 생긴 문제 같았다.

최종 제출 코드

주어진 배열이 빈 배열일 경우 예외처리하는 코드를 추가하였다.

def solution(A, K):

    if len(A) == 0:
        return A

    for i in range(K):
        last_num = A.pop()
        A.insert(0, last_num)

    return A

잘 풀었다고 생각했는데 생각지도 못한 예외였다... 앞으로 좀 더 꼼꼼히 예외 케이스를 생각해보아야 할 것 같다.

10진수의 수 N이 주어지면, 이 수의 이진수에서 1로 둘러쌓인 최대 연속된 0의 길이를 구하는 문제이다.

def solution(N):

    binary_num = bin(N)[2:]
    max_count_0 = 0 
    count_0 = 0 

    for char in binary_num:
        if char == 1 and count_0 > 0: # 앞에 0을 낀 닫히는 1
            if max_count_0 < count_0:
                max_count_0 = count_0
                count_0 = 0
        elif char == 0:
            count_0 += 1

    return max_count_0 

고민 포인트

1. 0을 감싸는 시작'1'과 끝나는 '1'의 차이를 무슨 수로 구분하지
2. 이진수 변환 어케 시키지

2번은 파이썬에 bin()이라는 편리한 이진수 변환 함수를 이용하였다. 2진수임을 나타내는 접두사 0b가 붙어서 슬라이싱으로 제거해줬다. 1번은 '1'일때 count_0 > 0이라는 조건을 추가해줬는데, 첫 번째 인덱스의 '1'과 '1'이 연속되어서 오는 경우에는 count_0변수가 증가되지 않아 0일 거라는 생각에서였다.

트러블 슈팅

저 상태의 코드로 제출했더니 테스트 케이스 3개중 2개만 자꾸 통과했다. 결과적으로 놓친 부분이

1. char == 1 과 char == 0 에서 정수가 아닌 문자열와 비교하는 거라서 작은 따옴표를 붙였어야했다.
2. if max_count_0 < count_0:의 if문 안의 count_0 = 0는 if문 안에 들어있지 말고 밖에 나와야 함. 0의 개수가 max_count_0보다 작을지라도 count_0를 초기화해줘야 하기 때문.
3. if char == 1 and count_0 > 0:에서 count_0 > 0조건은 없어도 됨. 어차피 count_0변수가 0이라면 max_count_0보다 클리가 없으니까.

최종 제출 코드

오류 사항 수정하고 조금 더 가독성 좋게 바꾼 코드

def solution(N):

    binary_num = bin(N)[2:]
    max_count_0 = 0 
    count_0 = 0 

    for char in binary_num:
        if char == `0`:
            count_0 += 1

        elif char == `1`: 
            if max_count_0 < count_0:
                max_count_0 = count_0
            count_0 = 0

    return max_count_0 

테스트 케이스를 전부 통과했다.

본 프로젝트는 기존에 제작해두었던 간단한 물고기 종 분류 YOLO 모델을 활용하여, 백엔드 서비스를 혼자서 설계·배포·운영까지 완주해보는 것을 목표로 한 개인 프로젝트이다.

동기

데이터 사이언스를 전공하며 모델을 구현하는 경험은 많았지만, 해당 모델이 실제 서비스 환경에서 어떻게 배포되고 운영되는지는 직접 경험해보지 못한 영역이었다.

특히 이전 팀 프로젝트에서는 주로 기능 구현에 집중했기에, 인프라 설계부터 배포까지의 전 과정을 직접 책임지는 경험에 갈증이 있었다. 이에 본 프로젝트에서는 모델의 성능 고도화보다는 모델을 포함한 백엔드 서비스를 설계부터 배포·운영까지 혼자서 완주하는 경험을 목표로 삼았다.

서비스 구성 및 구현 범위

기존에 제작해두었던 물고기 종 분류 YOLO 모델을 기반으로, 해당 모델을 호출할 수 있는 백엔드 API를 FastAPI로 구성하고, 모바일 클라이언트에서는 Kotlin(Android)을 사용해 서비스를 구현하였다.

또한, 단순히 추론 기능만 있는게 아니라 엄연히 서비스다운 모습을 갖추기 위해 수집 요소를 추가하였다. 포켓몬고의 도감 시스템처럼, 사진 분석 결과로 등장한 종(예: 상어, 해파리)을 사용자가 사전에 등록·확인할 수 있는 기능을 추가하였다.

서비스 운영에 필요한 데이터와 사용자 수집 정보는 DynamoDB에 저장하였으며,클라이언트에서 생성한 랜덤 UUID를 사용자 식별자로 사용하여, 로그인 기능을 따로 구현하지 않고도 사용자 식별이 가능하록 하였다.

Lambda 선택 배경

원래 서버를 EC2로 띄우려고 했는데 프리티어 기간이 만료가 되었다(...)

개인 프로젝트라는 특성상 서버 운영과 비용 관리에 많은 리소스를 쓰고 싶지 않았기 때문에 프리티어를 넉넉하게 제공해주고 운영 부담도 적은 AWS Lambda를 서버 실행 환경으로 선택하였다.

AWS Lambda 서비스는 DynamoDB와 같은 ServerLess서비스이기 때문에, DynamoDB와 연계되어 서버 관리가 거의 필요 없는 완전한 서버리스(Serverless) 아키텍처를 구성할 수 있다는 장점도 있었다.

서버리스라는 표현은 서버가 존재하지 않는다는 의미가 아니라, 개발자가 서버의 운영·확장·장애 대응을 직접 관리하지 않아도 된다는 의미이다. AWS에서 알아서 운영, 수요 예측 등을 다 해주기 때문에 서버 안정성이나 스케일링에 대한 고민없이 개발자는 오직 서비스의 개발에만 집중할 수 있다.

게다가 EC2는 서버가 24시간 내내 돌아가기 때문에 서버를 실행하는 동안 비용이 지속적으로 발생하는 반면, Lambda는 이벤트가 발생할 때만 실행되는 온디맨드 방식으로, 월별 320만초 or 40만 GB-Second 까지 무료라 소규모 개인 프로젝트에서는 거의 무료로 평생 사용할 수 있다.

다만 AWS에서 자체적으로 여러 서비스들을 결합해 자동으로 관리해주는 거라 아키텍처가 복잡하게 얽혀있다는 단점과, 한 번 서버리스 방식으로 서버를 구축하면 다른 방식으로 마이그레이션이 쉽지 않다는 단점이 있다. (한마디로 AWS 람다 서비스 종료되면 내 서비스도 영원히 종료된다는것... 근데 람다 서비스가 끝날 가능성도 거의 0%이긴하다.) 그리고 Stateless한 서비스이기 때문에 EC2처럼 EBS같은 메모리에 데이터 저장이 불가능하다. 람다 자체에 저장 기능이 없기 때문에, 기억해야 할 데이터가 있다면 반드시 S3나 DB같은 외부 저장소가 필요하다.

물론 람다에게도 아주 작은 로컬 디스크 공간인 /tmp 폴더(최소 512MB 제공)가 있긴 하다. 그러나 이 역시 함수가 종료되고 컨테이너가 내려가면 삭제된다. 주로 실행 중에 잠깐 압축을 풀거나, 큰 파일을 임시로 내려받아 처리하는 용도로만 사용된다.

Lambda 이용하여 배포하기

일반적으로 람다에 서버를 배포하려면 그냥 라이브러리와 코드를 zip파일로 묶어서 올리면 된다. 이 방식은 환경설정에 문제만 없다면(EC2랑은 다르게 OS환경이 리눅스로 고정되어있어 다른 OS를 선택할수 없다.) 매우 간단하지만 파일이 50MB 이하여야 한다.

하지만 내가 만든 서비스는

1. 모델 파일이 포함되어 있기 때문에 용량이 500MB를 넘어가고
2. 코드 실행에 필요한 머신러닝 관련 라이브러리들(YOLO (Ultralytics), PyTorch, OpenCV, NumPy)은 C언어로 컴파일된 파일이 포함되어 있기 때문에(계산 속도를 향상을 위해). 그래서 내 컴퓨터에 설치된 라이브러리 버전(윈도우용)을 그냥 압축해서 람다에 올려버리면 람다의 OS(리눅스)와 충돌한다.

그리하여 이런 용량과 버전충돌 문제를 해결하기 위해 도커를 이용하여 배포하기로 하였다.(도커는 10GB까지 가능하다!)

Mangum 라이브러리 설정

먼저 Mangum라이브러리를 설치해주어야 하는데 이게 왜 필요하냐면...

AWS Lambda는 HTTP 서버가 아닌 이벤트 기반 실행 환경이기 때문에, 클라이언트의 HTTP 요청을 직접 처리할 수 없다. 대신 API Gateway가 앞단에서 요청을 받아 이를 Lambda Event(JSON) 형식으로 변환해 Lambda에 전달한다.

이때 람다 안의 FastAPI에게 Lambda Event(JSON)객체를 그대로 전해주면 FastAPI가 무슨 말인지 못 알아먹기 때문에 다시 FastAPI가 이해할 수 있는 ASGI객체로 변환해주어야 한다.(FastAPI는 ASGI 기반의 웹 애플리케이션 프레임워크이기 때문)

따라서 API Gateway를 통해 전달된 Lambda Event(JSON)를 FastAPI가 이해할 수 있는 ASGI 요청 객체로 변환하는 어댑터 계층이 필요하며, 이 역할을 Mangum이 해줄것이다.

• 로컬 환경에서는 주로 Uvicorn이라는 웹 서버가 API 게이트웨이와 Mangum의 역할인 HTTP 소켓 연결과 ASGI 변환을 혼자 수행해준다.

Mangum공식 깃허브에 들어가보면 Fastapi를 사용한 Mangum호출법이 나와있다. [Mangum 공식 깃허브]

간단하게 Handler변수를 기존 코드 밑에 추가해주면 되는데, Handler는 람다가 신호를 받았을때 처음 실행시키는 진입 함수이다.

만들어둔 Fastapi의 app객체를 Mangum에 전달하고 이걸 handler변수에 저장한다. 그럼 람다가 실행되면 자동으로 이 handler 변수(app객체가 전달된 Mangum 객체)를 찾아서 실행하게 된다. [파이썬 람다 핸들러 함수 정의]

클라이언트(https 소켓) -> API 게이트웨이(JSON 변환) -> Lambda -> mangum(ASGI 변환) -> FastAPI 코드 돌아감

대략적으로 이런 구조를 예상했다.

Dockerfile 이미지 만들기

이제 handler까지 추가해준 코드파일을 도커 이미지로 구워보자. 우선 도커 설정이 들어있는 Dockerfile을 작성해주어야 한다.

작성한 내용은 다음과 같다

FROM public.ecr.aws/lambda/python:3.10

RUN yum install -y mesa-libGL

COPY requirements.txt ${LAMBDA_TASK_ROOT}

RUN pip install --no-cache-dir -r requirements.txt

COPY . ${LAMBDA_TASK_ROOT}

CMD [ "main.handler" ]

yum install -y mesa-libGL는 소스 코드에서 사용된 OpenCV와 YOLO가 이미지를 행렬로 계산할 때 사용하는 그래픽 관련 라이브러리인데 람다용 리눅스에는 이게 빠져있기 때문에 별도로 설치해준다.

그리고 requirements.txt의 라이브러리 목록을 설치할때는 용량 확보를 위해 --no-cache-dir옵션을 넣어준다.(보통 pip은 재설치를 대비해 설치 파일을 임시로 저장(Cache)해 두기 때문에.)

라이브러리 설치는 매우 오래 걸리기 때문에 이후 main.py 소스파일 수정이 있을시, 또 다시 처음부터 설치될일이 없도록 Dockerfile 상단에서 먼저 라이브러리를 설치한다. Docker는 위쪽 레이어에 변경이 발생하면 그 아래 모든 레이어의 캐시를 무효화하고 다시 실행하기 때문에, 변경 가능성이 낮은 라이브러리 설치 단계를 앞부분에 배치하고 이후에 소스 코드와 모델 파일을 복사하도록 구성한 것이다.

.dockerignore에 쓸데없는 파일들까지 같이 빌드되지 않도록 파일을 추가해준다. 가상환경에서 테스트로 여러 라이브러리들을 설치하고 실행해보았가 때문에, 무조건 제외 목록에 추가해주어야 쓸데없는 용량이 소모되지 않고 빌드 시간이 길어지지 않는다.

__pycache__/
venv/
.venv/
.git/
.env

또한 프로젝트에 사용된 라이브러리 목록을 기재한 requirements.txt도 작성해준다.

# FastAPI 및 람다 핸들러
fastapi
mangum
python-multipart

# AWS 서비스 연동
boto3

# AI 모델 및 수치 계산 (CPU 전용 버전으로 용량 최적화)
--index-url https://download.pytorch.org/whl/cpu
torch
torchvision
ultralytics

# 이미지 처리 (람다 에러 방지용 화면 띄우는 GUI기능이 없는 headless 버전)
opencv-python-headless
Pillow
numpy

--index-url https://download.pytorch.org/whl/cpu는 torch와 torchvision을 보다 가벼운 CPU버전으로 설치하라는 명령어이다. 그냥 설치하면 도커가 무거운 GPU용 파일(수 GB)까지 다 받아오려고 하는데, 이걸 적어주면 람다에 딱 맞는 가벼운 CPU 전용 파일만 찾아낸다. 애초 람다는 GPU가 없기 때문에 GPU용 파일을 깔아봤자 쓰지도 못하고 실행 속도만 느려진다...

이렇게 준비가 되었으면 docker build -t fish-app . 명령어로 도커를 빌드해준다.

🛠️ Troubleshooting: Docker pytorch 라이브러리 버전 오류

도커 이미지 빌드 중 에러가 뜨며 빌드가 중단되었다.

원인 : 뜬 에러 메시지는 다음과 같다. Looking in indexes: https://download.pytorch.org/whl/cpu ERROR: Could not find a version that satisfies the requirement fastapi

라이브러리들을 설치하는 과정에서 에러가 생겼는데, cpu용 pytorch설치하라고 입력해준 주소에서 쌩뚱맞게 fastapi를 찾아서 다운로드 하려다가 없으니까 뜬 에러 메시지이다. 아무래도 --index-url https://download.pytorch.org/whl/cpu명령이 다른 라이브러리들 설치될때도 적용이 되었던 모양이다.

1차 시도 :

fastapi
mangum
python-multipart
boto3
opencv-python-headless
Pillow
numpy
ultralytics

# torch 종류만 아래 url에서 다운
--extra-index-url https://download.pytorch.org/whl/cpu
torch
torchvision

--extra-index-url명령어로 변경해준다. 해당 명령어는 일단 pip가 PyPI에서 해당 라이브러리를 찾아본다음 없으면 그때 해당 url에서 다운받는 명령어이다.

이제 다시 빌드를 해준다.

=> [4/5] RUN pip install --no-cache-dir -r requirements.txt                                                                                                450.3s
 => => # Installing collected packages: triton, nvidia-cusparselt-cu12, mpmath, urllib3, typing-extensions, sympy, six, pyyaml, python-multipart, pyparsing, psuti 
 => => # l, polars-runtime-32, Pillow, packaging, nvidia-nvtx-cu12, nvidia-nvjitlink-cu12, nvidia-nccl-cu12, nvidia-curand-cu12, nvidia-cufft-cu12, nvidia-cuda-ru
 => => # ntime-cu12, nvidia-cuda-nvrtc-cu12, nvidia-cuda-cupti-cu12, nvidia-cublas-cu12, numpy, networkx, MarkupSafe, kiwisolver, jmespath, idna, fsspec, fonttool 
 => => # s, filelock, cycler, charset_normalizer, certifi, annotated-types, annotated-doc, typing-inspection, scipy, requests, python-dateutil, pydantic-core, pol
 => => # ars, opencv-python-headless, opencv-python, nvidia-cusparse-cu12, nvidia-cudnn-cu12, mangum, jinja2, exceptiongroup, contourpy, pydantic, nvidia-cusolver
 => => # -cu12, matplotlib, botocore, anyio, torch, starlette, s3transfer, ultralytics-thop, torchvision, fastapi, boto3, ultralytics  

그런데 몇십분이 지나도 빌드가 끝나지 않고 딱 봐도 뭔가 웅장한 라이브러리들이 우후죽순 설치되고 있다는 로그가 뜨더니...

결국 WSL(윈도우용 리눅스 가상 엔진) 용량 부족 엔딩.

원인 : --extra-index-url 명령어는 먼저 PyPI를 살펴보고 PyPI에 존재하지 않으면 https://download.pytorch.org/whl/cpu에서 cpu버전을 다운받는다고 하지 않았는가?

그런데 PyPI에 pytorch GPU버전이 이미 존재하기 때문에 pip는 응? https://download.pytorch.org/whl/cpu 갈 필요 없겠는데? 하고 그냥 PyPI에서 GPU버전 다운받아 버린 거다.

위의 여러 라이브러리들 중 nvidia-로 시작하는 라이브러리들은 GPU 연산용 부품들인데(람다에서 돌리지도 못하는), 이것들이 다 합쳐지면 이미지 용량이 어마어마하니 연약한 내 컴퓨터가 버틸리가 없다.

2차 시도 : 일단 wsl --shutdown명령어로 wsl을 강제종료 시키고, docker system prune -a --volumes 명령어로 도커 이미지, 컨테이너, 캐시 등등 전부 다 지워 초기화 시켜 용량을 정상화시킨다. (14GB가 지워졌다ㄷㄷ)

--extra-index-url https://download.pytorch.org/whl/cpu
torch==2.0.1+cpu 
torchvision==0.15.2+cpu
ultralytics
fastapi
mangum
python-multipart
boto3
opencv-python-headless
Pillow
numpy

이번엔 GPU용 라이브러리 설치를 막기 위해, torch와 torchvision 뒤에 cpu버전까지 확실하게 명시해주었다.

그리고 빌드....

C:\Users\khsta\OneDrive\바탕 화면\Python\fish_application>docker build -t fish-app .
[+] Building 685.7s (10/10) FINISHED                                                                                                          docker:desktop-linux

FINISHED문구와 함께 빌드가 성공했다.

*결과 : *

도커 데스크탑에서도 만들어진 이미지를 볼 수 있다.

빌드가 완료되었으니 docker run -p 8080:8080 fish-app명령어로 람다 환경을 모방한 서버를 내 컴퓨터의 8080포트로 띄운다.

그리고 docker run -p 8080:8080 -e AWS_DEFAULT_REGION=ap-northeast-2 fish-app 도커 실행 명령어를 실행하면(-e AWS_DEFAULT_REGION=ap-northeast-2는 리전 환경 변수 정해주는 것)

C:\Users\khsta\OneDrive\바탕 화면\Python\fish_application>curl -XPOST "http://localhost:8080/2015-03-31/functions/function/invocations" -d '{}'
{"errorMessage": "Unable to unmarshal input: Expecting value: line 1 column 1 (char 0)", "errorType": "Runtime.UnmarshalError", "requestId": "57fac8c5-7236-4834-a764-ef6f3dd447b1", "stackTrace": []}

다음과 같은 결과가 나온다. 에러메시지이긴 한데 Runtime.UnmarshalError은 분석할 이미지가 함께 오지 않았다는 뜻이라서 일단 서버가 돌아가고 있다는 뜻이다.

ECR 설치

ECR은 도커 컨테이너 전용 저장소라고 생각하면 된다. 람다에 도커로 배포하려면 무조건 ECR을 거쳐야 한다.

aws 콘솔에서 ECR 리포지토리를 하나 생성해준다.

AWS CLI로 IAM 사용자 로그인을 해 주고

IAM 권한에 EC2ContainerRegistryFullAccess를 추가해주면 된다.(내 IAM계정은 AdministratorAccess가 부여되어 있어 필요없음)

그리고 ECR콘솔창에 있는 푸시 명령 보기버튼을 누르면 다음과 같은 명령어들을 안내해주는데 그냥 복붙하면 된다.(2번은 이미 빌드했으니 패스)

이미지가 ECR에 잘 올라갔다.

람다 함수 생성

이제 람다 함수를 생성해보자. 컨테이너 이미지 옵션을 선택하고 함수 이름을 입력해준뒤 방금 리포에 올린 이미지를 선택해주면 된다.

🛠️ Troubleshooting: Lambda의 'Not Supported' 이미지 에러 해결

콘솔에서 람다 함수를 생성하려는데 에러 창이 떴다

원인 : AWS 람다 공식문서 요구사항 탭을 보면

Lambda는 다중 아키텍처 기본 이미지를 제공합니다. 하지만 함수에 대해 빌드하는 이미지는 아키텍처 중 하나만 대상으로 해야 합니다. Lambda는 다중 아키텍처 컨테이너 이미지를 사용하는 함수를 지원하지 않습니다.

라고 기재되어 있다. 도커의 최신 빌드 엔진인 buildx의 v0.10 이상 버전에서는 여러 CPU 환경을 지원하기 위해 기본적으로 OCI image index 형식을 사용해 멀티 플랫폼 이미지를 빌드하는데, 위 문서 내용처럼 람다는 다중 아키텍처 컨테이너 이미지(=멀티 플랫폼 이미지)를 지원하지 않아 manifest not supported 에러가 발생한것이다.

최신 Docker Buildx 환경에서는 기본적으로 OCI Image Index 형식을 사용하며, 빌드 메타데이터인 Provenance를 포함시킨다. 하지만 AWS Lambda는 단일 플랫폼의 Docker V2 Manifest 포맷만 지원하기 때문에, manifest not supported 에러가 발생한것이다.

해결 방법 : 간단히 메타데이터인 Provenance를 제외시키는 --provenance=false 옵션을 붙여 형식을 강제 변환시킨 후 다시 빌드해주면 단일 이미지 포멧으로 다시 빌드된다.

docker build --platform linux/amd64 --provenance=false -t fish-app:latest .

위 명령어로 다시 이미지를 구워준다. 결과: 굿. 람다함수가 잘 생성되었다.

람다 함수 설정 변경:

함수가 생성되었으니 설정을 조금 바꿔준다. 무거운 모델이 돌아가야 하기 때문에 메모리와 제한 시간을 2048MB, 1분으로 늘려주었다.(기본설정은 128MB에 3초)

또한, AWS Lambda 콘솔 → [구성] → [권한(Permissions)] → 역할 이름(Role name) → [권한 추가] → [정책 연결]에서 AmazonDynamoDBFullAccess_v2 권한을 검색하여** dynamoDB에 대한 권한을 추가해 준다.**

API 게이트웨이

인터넷 게이트웨이랑 다른거다. 람다는 정확히 말하면 일반 서버처럼 데이터를 stream형식으로 받는게 아니라 이벤트에 의해 실행되는 함수이기 때문에 클라이언트와 TCP연결을 맺지 않는다. 이때 람다의 앞에서 API 게이트웨이가 대신 클라이언트와 TCP연결을 맺고, 들어온 HTTP 요청을 JSON 이벤트 객체로 변환하여 람다에 넘겨준다.

왜 JSON으로 변환해줘야 함? 람다(Lambda) 함수가 '입력값'으로 받을 수 있는 유일한 표준 규격이 JSON 형식의 이벤트 객체이기 때문에.

_물론 2022년에 람다 함수 URL(Function URL)이라는 람다 내장 기능이 추가되어, API 게이트웨이 없이 람다만으로도 고유한 URL 엔드포인트를 생성하고 JSON 규격(Payload Format 2.0)으로 변환하는게 가능해졌지만, API 게이트웨이는 JSON 이벤트 형식 변환 외에도 요청 속도 제한(Throttling), 캐싱, 그리고 보안 및 인증 등 여러 기능을 수행해주기 때문에 앵간하면 람다랑 같이 쓰는 게 좋다. _

[API Gateway 개념 설명]

람다 함수의 트리거 추가를 눌러 API 게이트웨이를 생성해준다.

🛠️ Troubleshooting: API 게이트웨이 스테이지 경로 주소 오류

생성된 주소로 Postman을 이용해서 형식을 맞춰 요청을 보내봤지만 계속해서 404 Not Found 응답이 뜨며 2ms대의 짧은 실행 이후 끊겼다.

원인 : Gemini에게 물어보니 "detail": "Not Found" 메시지는 FastAPI 프레임워크가 공식적으로 내보내는 404 에러 양식이기 때문에, 람다 함수쪽이 문제가 아니라 FastAPI 쪽의 문제일 확률이 높고, 이 경우엔 서버(FastAPI)가 요청을 받자마자 담당경로가 아니기 때문에 바로 거절을 한 것 같다고 했다.

API 엔드포인트 주소를 확인해보면 https://아이디.execute-api.리전.amazonaws.com/default/{proxy+} 라고 되어있다. 호스트주소 바로 뒤에 default라는 경로가 붙은 것이 보인다. ({proxy+}는 FastAPI의 api엔드포인트가 오는 곳)

문제는 FastAPI의 라우팅 방식이다. FastAPI는 호스트 주소 이후의 전체 경로인 /default/{proxy+}를 자신의 라우팅 테이블과 대조한다. 하지만 내 서버 코드는 /analyze처럼 루트 경로를 기준으로 설계되어 있다 보니, 앞에 붙은 /default라는 불청객 때문에 경로를 찾지 못하고 404 Not Found를 뱉으며 즉시 종료되었던 것이다.

그렇다면 저 default의 정체는 무엇인가?

API Gateway는 개발용(dev), 테스트용(test), 실제 배포용(prod)등의 버전(Stage)을 관리하기 위해 https://아이디.execute-api.리전.amazonaws.com/스테이지명/~~ 같이 스테이지 이름을 주소에 강제로 포함한다.

현재 나의 코드 같은 경우 기본(default) 스테이지를 사용 중이라 주소 중간에 /default가 자동으로 박혀버린 것이다.

[API 게이트웨이의 스테이지]

해결 방법1: 요청 코드 주소 자체를 바꾸어주는 방법이다.

API 게이트웨이의 주소에 맞추어, FastAPI의 루트 주소에 /default를 포함해준다. 기존의 app = FastAPI()를 다음과 같이 바꾸어준다.

app = FastAPI(root_path="/default")

이러면 모든 주소 앞에 /default가 자동으로 붙게되어 /default/{proxy+}형식을 만족시킨다.

*해결 방법2: * 람다에 접속하는 URL을 아예 다른 주소로 사용하는 방법이다.

위에서 명시했듯이 람다 함수 URL을 사용하면, API 게이트웨이 없이 람다만으로도 고유한 URL 엔드포인트를 생성하고 자체적으로 JSON으로 변환하는것이 가능하다.

람다 함수의 [구성] 탭에서 쉽게 함수 URL을 생성할 수 있다.

두 방법으로 만들어진 주소들을 모두 테스트 해봤더니 200 OK 결과와 함께 정상적으로 분석 결과가 나온것을 볼 수 있었다.

최종적으로는 API 게이트웨이 대신 함수 URL을 선택했는데, 그 이유로는

1. API 게이트웨이의 스테이지 경로 문제가 해결되어 FastAPI의 라우팅이 꼬이는 문제가 다시 생길 걱정이 없고

2. API Gateway는 요청 횟수에 따라 별도의 요금이 발생하지만, 함수 URL은 완전히 무료이기 때문에 비용 걱정이 없으며

3. API Gateway는 최대 타임아웃이 29초로 제한되어 있어, 무거운 인공지능 모델(YOLO 등)을 돌릴 때 시간이 부족할 수 있는데, 반면 함수 URL은 람다 자체의 최대 타임아웃인 15분까지 그대로 사용할 수 있어 타임아웃 제한이 완화된다.

물론 API Gateway를 통해 인가(Authorizer)나 유량 제어(Throttling) 등 정교한 기능을 활용할 수 있으나, 나의 프로젝트 같은 경우 1. 서비스의 복잡도가 낮고 2. 별도의 사용자 인증 및 인가를 요구하지 않는 서비스이기 때문에 현재 프로젝트의 규모와 빠른 프로토타이핑이라는 목적을 고려했을 때, 불필요한 복잡성을 줄이고 직관적인 아키텍처를 유지할 수 있는 함수 URL이 더 적합하다고 판단하여 최종 선택하게 되었다.

최종 프로젝트 아키텍처

추가적인 성능 개선은 해당 포스팅에서 -> [Lambda Cold Start 해결]

나는 2년 지원 유형이라 3학년 1학기 부터 장학금을 받았다. 장학금 합격 발표가 꽤나 늦게 났던지라 3학년 1학기 장학금은 선감면 대신 추후에 계좌로 입금되었다. 계절학기를 제외한 이후의 정규학기들은 전부 전액면제로 다닐 수 있었다.

이로서 대학교 8학기중 1-1학기 성적장학금을 포함하여 3학년,4학년까지 총 5번의 장학금을 수혜받았다. (감사합니다 열심히 살게요)

사실 당시에는 전혀 붙을 기대를 하지 않았는데 붙었다는 소식을 듣고, 부모님에게 부담을 덜어드릴 수 있어서 굉장히 기뻤던 기억이 있다. 소식 듣고 나보다 좋아하심

근데 졸업하고 일정기간안에 관련분야로 취업해서 종사하지 않으면 반환해야 된다고 말씀드리니, 취업 할 수 있겠냐고 걱정하시더라 아놔.... (사실 나도 조금 걱정됐음)

근데 최근에 그 의무사항도 폐지되었다고 들었다. 그래도 규정이 언제 또 바뀌었을지 모르니 본인에게 해당되는 요건을 꼼꼼히 잘 살펴보고 확인하자.

(상장이랑 메달도 준다.)

Physical Layer

• 통신 주체끼리 연결이 수립되면 연결이 기하급수적으로 많아짐
• Hub로 다수의 기기를 연결
• Hub : 받은 신호를 묶여있는 다른애들한테 뿌림(확성기 같이)
  • 1:1 통신 불가. 오로지 브로드캐스팅만...
  • 충돌 제어 불가

Data Link Layer

• Frame 단위
• CSMA/CD(충돌 방지)
• Mac 주소라는게 생김
  • 고유값, 변동 X, 기계에 새겨진 번호같은거(IP는 변동)
  • 유니캐스트(1:1 통신) 가능해짐
• Switch를 사용해서 특정 네트워크 내에서 구간을 따로 관리
  • 포트별로 디바이스(MAC주소)가 매핑된 테이블이 있음

Nerwork Layer

• Packet 단위
• 로컬 네트워크간의 연결을 지원
• IP : 인터넷(네트워크와 네트워크 간)에서의 주소라고 생각하면 됨
  • MAC주소는 로컬 네트워크 안에서의 주소
  • 수시로 IP 주소 변동됨
• CIDR : 네트워크 영역을 나누기 위해 IP주소를 묶는 방식
  • ex) 172.0.1.0/24 b -> 네트워크 주소 + 호스트 주소 / 네트워크 주소 bit수
• Router : 네트워크간 패깃을 주고받는 장치
  • IP 대역별 최적 경로 수집 및 관리
    • 로컬 네트워크 주소 아니면 라우터로 전달(외부로 보낸다는 뜻)
• but. 한 번에 하나의 애플리케이션만 통신 가능, 인터넷상 패킷 손실 가능성 있음

Transport Layer

• Segment 단위

• 통신 주체끼리의 데이터 신뢰성 확보하는 층(패킷 순서, 에러 처리 등)

• Port : IP 프로토콜에서 패킷을 올바른 프로세스로 라우팅 하기 위한 논리적 단위

  • 목적지 기기에 도착하더라도 여러 프로세스들이 돌아가고 있음
  • 포트 번호를 통해 알맞은 프로세스를 찾을 수 있음
  • 1~1023번은 보통 잘 알려진 서비스(well-known ports)를 위해 예약되어 있음 -> 사내망이나 서버 테스트용 임의 포트 지정할거면 저거 이외에 다른거 써라(ex.8080, 3000, 9000)
  • 다른 외부 서버에 요청을 보낼 때 사용하는 포트는 보통 임시로 할당받는 동적 포트를 사용

• TCP : 신뢰성 있는 전송 보장

  • 3 way handShake를 통해 패킷의 순서나 전달여부등을 보장
  • HTTP/HTTPS/FTP/SSH/DNS 등에 사용

• UDP : 빠르고 간단하게 데이터를 주고 받을 수 있는 방법을 정의

  • TCP와 달리 데이터의 무결성, 순서, 전달여부 노상관

  • 그래서 신뢰성은 낮지만 속도가 빠르고 세그먼트 용량이 작음

  • DNS/DHCP/VoIP(음성통화) 등에 사용

    내 노트북에서 사용중인 Port 살펴보기

    windows는 터미널 창에 netstat -ano라고 입력하면 현재 사용중인 포트들을 볼 수 있다. 내 노트북 열린 포트들도 뭐 있나 궁금해서 한 번 살펴보았다.

  

  뭐 이리 많아 밑에도 한참 더 있었는데 너무 길어서 잘랐다. 궁금해서 상위 2개 포트가 어따 쓰이나를 검색해봤는데 135번 포트는 주로 Windows 운영체제에서 RPC(원격 프로시저 호출) 서비스에 사용되고, 445번 포트는 SMB(서버 메시지 블록) 프로토콜에 사용되며, 네트워크 상에서 파일 및 프린터 공유를 가능하게 하는 Microsoft-DS 서비스에 사용된다고 한다.

Session Layer

• 통신 주체끼리 연결을 유지할 수 있는 방법을 정의
• HTTP Cookie 같은것

Presentation Layer

• Application layer에서 사용할 수 있도록 데이터를 파싱, 압축 해제 함

Application Layer

• 실제 받은 데이터를 어떻게 처리할 것인지를 정의
• Http의 경우 Method(ex.Get, Post, Put), Header등을 처리

라우터를 통한 네트워크간 통신 과정

1. 사용자가 www.naver.com을 입력함

2. DNS서버를 통해 해당 도메인과 매핑된 IP주소를 반환

3. 목적지 주소를 알았으니 IP패킷 생성

4. 목적지 IP가 같은 네트워크인지 확인

5. 다른 로컬 네트워크라면 라우터(게이트웨이)의 IP로 ARP패킷 브로드캐스트

6. 라우터가 자신의 MAC주소를 알려줌. 해당 주소로 패킷 전송

   • 이 때 전송되는 패킷의 목적지 IP : 최종 목적지 IP, 목적지 MAC : 라우터의 MAC

7. 라우터에 패킷이 도착하고, 라우터가 목적지 IP(최종 목적지) 확인

8. 라우터가 라우팅 테이블을 통해 최적 경로 탐색

9. NAT로 출발지의 사설 IP 주소를 라우터 자신의 공인 IP주소로 변경. (다시 돌아올때 이거 보고 돌아옴)

10. 라우터가 출발지, 목적지 MAC주소 변경해서 전달. (라우터의 MAC주소, 다음 라우터의 MAC주소로)

11. 다음 라우터는 목적지 IP와 자신의 네트워크 IP 주소 대조.

12. 도착할때까지 10번 반복(ARP 브로드캐스팅 통해서 계속 MAC주소 물어봄)

13. 해당 로컬 네트워크 라우터에 패킷이 도착하면 라우터는 ARP 브로드캐스팅을 통해 최종 목적지의 MAC주소를 얻고 마지막 전송을 함.

• 패킷에 새겨진 MAC주소는 한 번 이동될때마다 계속 바뀌고 최종 IP 목적지주소는 절대 바뀌지 않음

왜 IP주소 개념이 필요한가?

공부하면서 이런 의문이 들었는데 MAC주소 자체가 완전 고유한 번호인데 얘만을 이용해서도 경로를 찾을 수 있지 않나? 굳이 IP주소를 도입해서 왜 주소를 2개로 만들지? 라는 생각이 들었다.

하지만 MAC주소만을 이용해 통신을 하게 되면 전 세계적 통신이 불가능했을 것이다.

우선, MAC주소는 특정 네트워크에 속해 있지 않아서, 하나하나가 인터넷이라는 방대한 공간의 노드가 되어 버린다. 이렇게 되면 효율적 경로를 통해 찾아가는 것이 불가능해지고 하나하나 대조를 해봐야 한다. 전 세계의 모든 기기에.... 그리고 브로드캐스트 한 번 했다간 전 세계 사람의 컴퓨터에 요청이 간다...

IP주소는 이러한 단점을 극복하기 위해 만들어진 논리적 주소라고 할 수 있으며 기기들끼리 묶어 로컬 네트워크를 구성할 수 있게 해준다.

위키피디아에 명시된 정의를 그대로 가져오자면

웹 서버(영어: web server)는 웹 콘텐츠(영어판) 배포를 위해 만든 프로토콜 
즉, HTTP 또는 HTTPS를 통해 클라이언트의 요청을 수행하는 서비스 프로그램 및 기반 하드웨어다.

라고 적혀있다.

당연히 이해가 가지 않으니 조금씩 해석해보자. 웹 콘텐츠 배포를 위해 만든 프로토콜 -> 이건 우리가 평소 인터넷에서 보는 보는 사이트나 서비스페이지같은 콘텐츠들을, 불특정 다수가 이용할 수 있도록(배포) 만든 어떠한 통신 약속(프로토콜)이라는 뜻이다.

HTTP 또는 HTTPS를 통해 클라이언트의 요청을 수행하는 서비스 프로그램 및 기반 하드웨어 -> 이 말은 HTTP와 HTTPS라는 어떠한 통신 규칙(프로토콜)이 있는데 이것을 사용해 통신 요청을 보내는 쪽(클라이언트)의 요청을 수행하는 프로그램이나 컴퓨터 기계(하드웨어)라는 뜻이다.

좀 풀어서 설명하긴 했는데 아직도 뭔가 모호하다.

정말 쉽게 요약하자면, 우리가 어디 사이트에 접속할때, 그 사이트의 콘텐츠를 그려내기 위해 html 파일 같은것들이 필요하다. 이러한 사이트의 파일들을 제공해주는 역할을 하는것이 웹서버이다.

웹서버의 종류에는 pache(아파치), Nginx(엔진엑스)등이 있다.

WAS가 웹서버랑 다른 건가?

다르다.

고대의 인터넷에는 웹서버만이 존재했다... 모든 사용자에게 똑같은 화면만을 보여주는 정적 웹(static web)만이 있었다.

하지만 인터넷이 널리 보급되고 사용자 수가 폭발적으로 늘며 웹 서버 만으로는 다양한 서비스를 제공할 수 없었다. 예를 들어 사용자마다 다른 정보를 표시하는 일, 실시간 데이터를 띄워서 보여주는 일. 모두 고정된 정적 문서를 제공하는 웹 서버에서는 불가능한 일이었다.

이때 등장한 것이 웹 애플리케이션 서버 WAS(Web Application Server)이다. Web Server는 기존이랑 똑같은데 그 사이에 Application이라는 단어가 들어갔다. 애플리케이션이 무엇인가? 애플리케이션은 특정 작업을 실행되도록 프로그래밍된 소프트웨어이다. 다시말해, 기존의 딱딱한 웹 서버에 소프트웨어 기능이 붙은 서버이다.

WAS는 정적 웹 페이지와 반대되는 동적 웹페이지를 생성할 수 있다. 동적 웹은 말 그대로 실시간으로 html문서를 만들어 낼 수 있었다.

이러한 WAS와 웹 서버는 이후 백엔드에서 상호 보완적인 관계를 이루게 되는데 특정 로직이 없는 페이지는 정적 페이지는 웹서버가, 로직이 필요한 동적 페이지는 웹서버가 WAS로 요청을 전달해 WAS가 대신 처리할 수 있도록 한다.

우리가 많이 들어본 Apache Tomcat (아파치 톰캣)또한 WAS의 한 종류이다.

웹서버 만들어보기

이제 FastAPI를 이용해 간단하게 서버를 만들어보자.

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def read_root():
    return {"message": "Server is connected!"}

이 5줄의 코드를 통해 현재 웹서버가 만들어졌다! FastAPI는 Uvicorn이라는 WAS 역할을 주로 수행하는 웹서버와 함께 쓰인다.

이제 필자의컴퓨터IP주소:포트번호 를 브라우저 주소창에 입력하면

다음과 같이 서버로부터 응답을 받을 수 있다!

이제 동일한 네트워크에서 해당 주소를 입력하면 어떤 기기에서든 동일한 응답값을 받을 수 있다!

잠깐, 동일한 네트워크라는 게 무슨 뜻일까?

네트워크를 공부한 사람을 알겠지만, 현재 내 IP주소는 공유기가 할당해준 고유한 번호, 말하자면 정확한 도로명 주소가 아닌 철수네 집, 영희네 집 같은 임시 주소번호이다.

당연히 우리 집 근처에 사는 사람들은 영희네 집, 철수네 집(IP 내부 주소)라고만 해도 어디인지 알겠지만, 저 멀리 미국 텍사스에 사는 제임스한테 영희네 집이라고 한다면 당연히 어딘지 모른다. 영희라는 이름을 가진 사람이 한 두 명도 아니고...(IP 내부 주소는 서로 다른 네트워크에서 중복이 가능하기 때문)

그래서 같은 공유기에 연결된 기기에서는 방금 만든 서버에 접속이 잘 되지만, 그 외의 외부 기기들에서는 필자의IP주소:포트번호를 입력해봤자, IP주소가 영희네 집 같은 알 수 없는 주소이기 때문에 입력해도 접속이 안 된다.

그럼 어떡해!!

나는 전세계적으로 서비스를 하는 초대형 글로벌 서비스를 만들고 싶은데 이러면 구멍가게 밖에 못 만들지 않나!! 싶지만 우리가 많이 들어본 AWS 같은 클라우드 서버를 사용하여 도로명주소같은 공인 IP주소를 할당받을 수 있다.

공인 IP주소는 대한민국 00시 00동같이 전 세계 어디에서나 인터넷을 통해 접근할 수 있는 공식적인 주소이다. 그래서 AWS 서버를 이용한다면 다른 컴퓨터나 스마트폰이 어떤 네트워크에 있든 상관없이 항상 접속할 수 있다.

물론 포트 포워딩등을 사용해 클라우드 서버를 사용하지 않고도 내 컴퓨터 자체를 외부에서 바로 접속이 가능하게 만드는 방법도 있긴 하다. 다만 이 방법은 보안도 취약하고 설정도 좀 만져야해서 꽤나 번거롭다고...

HTTP는 HyperText Transfer Protocol의 약자로, 웹에서 클라이언트(브라우저 등)와 서버 간에 데이터를 주고받기 위한 통신 규약(Protocol)이다.

쉽게 말하면 웹에서 문서, 이미지, 영상 등을 요청하고 응답받기 위한 약속된 통신 방법.

HTTP는 요청-응답을 기반으로 하기 때문에 HTTP의 메시지 형태도 요청/응답 2가지 이다.

클라이언트가 HTTP request를 서버에 보내면 서버는 HTTP response를 보내는 구조

HTTP Request Message

HTTP Response Message

https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/Messages

TCP/UDP/IP

IP

IP는 컴퓨터(호스트)들 사이에서 데이터 패킷을 목적지까지 전달하는 역할을 하는 인터넷 계층의 핵심 프로토콜이다.

IP의 핵심 역할

1. 주소 지정 (Addressing)

• 각 컴퓨터(=노드)는 고유한 IP 주소를 갖는다.
• 예) 192.168.1.12, 8.8.8.8, 2001:db8::1

2. 패킷 전달 (Routing)

• IP는 데이터를 여러 네트워크를 거쳐 목적지까지 전달함.

• 중간에 라우터(router)가 경로를 결정하고, 패킷을 넘겨줌.

3. 비신뢰성 (Unreliable)

• IP는 전달만 해줄 뿐, 순서를 보장하지 않음.

• 중간에 패킷이 유실될 수도 있음

• 중복되거나 깨져도 복구 안 해줌

• 이건 TCP가 처리해줘야 하는 영역임!

IP 주소 체계

1. IPv4 32비트 주소 (총 2³² = 약 43억 개) 형식: 192.168.0.1

2. IPv6 128비트 주소 (엄청 많음… 340 언쩌구 x 10³⁶ 개) 형식: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

TCP

신뢰성 있는 데이터 전송을 보장하는 전송 계층(Transport Layer)의 대표적인 프로토콜. 데이터를 정확하고 순서대로 전송하는 데 최적화되어 있다.

TCP의 핵심 특징

1. 연결 지향(Connection-Oriented) 데이터를 보내기 전, 3-way handshake로 연결을 먼저 설정함

2. 신뢰성 보장(Reliability) 데이터 유실 시 재전송, 순서 보장, 중복 제거

3. 흐름 제어(Flow Control) 수신 측의 수용 능력을 고려해 전송량 조절

4. 혼잡 제어(Congestion Control) 네트워크 상태에 따라 전송 속도 조절

UDP

빠르게 데이터를 전송하고 싶은 상황에서 사용하는 전송 계층(Transport Layer)의 대표적인 프로토콜

3-way handshake를 통해 연결 지향적인 통신을 하는 TCP와 달리 비연결성이라는 특징을 띈다. 클라이언트에서 서버로 마구 데이터를 보내는 것이다(받았다는 응답이 없어도).

이런 특성때문에 속도가 중요하고 약간의 데이터 손실은 크게 상관이 없는 통화나 스트리밍 서비스에 많이 사용되는 프로토콜이다.

Socket

네트워크에서 통신하는 두 개의 프로그램 간의 연결을 설정하고 데이터를 전송하기 위한 인터페이스.

IP주소와 포트 번호를 사용하여 네트워크 상의 특정 컴퓨터와 특정 서비스에 연결된다

소켓 통신

소켓을 이용하여 두 프로그램(서버-클라이언트) 간에 데이터를 주고 받는 과정. TCP와 UDP같은 네트워크 프로토콜을 사용

소켓은 프로토콜,IP주소,포트 넘버로 정의된다.

Echo Server

클라이언트가 전송해주는 데이터를 그대로 되돌려 전송해 주는 기능을 가진 서버를 말한다.

데이터를 그대로 되돌려 받기 때문에 클라이언트와 서버가 제대로 연결됐는지 테스트 용도로 많이 쓰인다.

Client와 Server

통신이 일어날 때 항상 요청을 시작하는 쪽은 클라이언트, 응답을 처리하는 쪽은 서버

Session과 Connection

언듯 비슷한 개념 같지만 그 역할과 범위가 다르다.

Connection

클라이언트와 서버 사이에 데이터를 주고받기 위한 통신 통로가 만들어진 것.

ex) TCP 3-way handshake를 통한 연결

Session

• 클라이언트와 서버 간에 연속된 상호작용을 하나의 논리적인 단위로 묶은 것.
• 연결과는 다르게 "이 사용자가 누구고, 어떤 상태인가"를 추적할 수 있어야 함.
• 즉, 연결 위에서 유지되는 사용자 상태 추적 단위.
• 연결 위에서 유지되기 때문에 세션은 연결에 의존함.

ex) 로그인 세션, 채팅 세션

Unicast / Broadcast / Multicast

Unicast

• 유니캐스트는 가장 일반적인 형태의 데이터 전송 방식으로, 한 개의 송신자가 한 개의 수신자에게 데이터를 전송하는 방식.
• 이 방식은 특정 대상과 1:1로 통신할 때 사용되며, 인터넷에서 흔히 볼 수 있는 데이터 전송 방식.
• 신자와 수신자 각각의 고유한 IP 주소를 사용
• 예) 웹 서버에서 클라이언트 컴퓨터로 웹 페이지를 보내는 경우

Broadcast

• 브로드캐스트는 한 개의 송신자가 네트워크 내 모든 장치에게 데이터를 동시에 전송하는 방식입니다.
• 같은 로컬 네트워크(LAN) 내의 모든 장치에게 신호나 메시지를 보낼 때 사용됨.
• 브로드캐스트에서는 네트워크 내 모든 장치에 데이터를 전송하기 위해 특정한 브로드캐스트 주소를 사용하는데, 반적으로 이 주소는 IP 네트워크의 마지막 주소로 설정됨
• 예) 네트워크 상의 모든 장치에게 서비스나 알림을 보내야 할 때

Multicast

• 멀티캐스트는 한 개의 송신자가 특정 그룹의 수신자들에게만 데이터를 전송하는 방식
• 데이터 스트리밍이나 실시간 데이터 전송에 효과적
• 멀티캐스트에서는 특정 멀티캐스트 그룹의 주소를 사용하고 이 주소는 224.0.0.0에서 239.255.255.255 범위에 속한다.
• 각 멀티캐스트 그룹은 고유한 IP 주소를 갖고 있으며, 그룹의 멤버만이 해당 주소로 보내진 데이터를 수신한다.
• 예) 라이브 비디오 방송이나 원격 회의 시스템

텍스트, 이미지, 오디오 등의 데이터를 고차원 벡터로 표현해 저장하는 데이터베이스입니다. 오늘날 대부분의 데이터는 미리 정의된 구조나 형식이 없는 텍스트, 이미지, 오디오 등의 비정형 데이터이다. 이러한 형태가 일관적이지 않은 데이터들을 RDBMS에 넣기란 어려운 일이다.

이미지를 예로 들자면 이미지는 픽셀값이 저장되기 때문에 특정 이미지를 찾기 위해선 태그나 속성(ex. 고양이, 강아지)을 수동으로 입력해야 한다.

하지만 벡터 데이터베이스는 벡터 임베딩을 통해 인덱싱하고 저장하여 빠른 검색 및 유사성 검색이 가능하다. 다시말해 데이터의 의미 기반 유사성 검색이 가능해진다는 말이다.

그렇다면 벡터 임베딩은 무엇일까?

벡터 임베딩

임베딩은 텍스트나 이미지 같은 데이터를 숫자 리스트, 즉 벡터로 바꾸는 방식이다. 이 벡터들은 데이터의 의미나 특성을 담고 있다.

의미가 비슷한 항목은 벡터 공간에서도 가까운 위치에 놓이게 되기 때문에 코사인 유사도나 유클리드 거리 등을 통해 서로 간의 유사도를 계산하여, 유사한 항목을 쉽게 찾을 수 있다.

벡터 데이터베이스는 이러한 임베딩들을 효율적으로 저장하고 검색하기 위해 만들어졌다. 기존 데이터베이스처럼 정확히 일치하는 값을 찾는 게 아니라, 유사한 것을 찾는 방식이다.

word2vec

대표적인 단어 임베딩 신경망 모델이다. Word2Vec에는 CBOW와 Skip-gram이라는 두 가지 대표적인 구조가 있다.

CBOW

CBOW의 기본 아이디어는 주변 단어를 통해 주어진 단어를 예측하는 것이다. 총 단어가 c개라고 할 때 앞뒤로 c/2개의 단어를 통해 주어진 단어를 예측한다.

Skip-gram 구조 (중심 → 주변 예측)

Skip - gram은 CBOW와는 반대로 하나의 단어에서 여러 단어를 예측하는 방법이다. 즉 중심단어에서 주변단어를 예측하는 방식인데 CBOW보다 성능이 좋아 더 많이 쓰인다.

벡터 인덱싱

벡터 임베딩이 비정형 데이터를 숫자 벡터로 바꾸는 것이라면, 인덱싱은 벡터 공간에 위치한 이미 만들어진 벡터들끼리 비슷한 걸 빠르게 찾도록 구조화하는 작업이라고 할 수 있다.

벡터 DB에서 데이터를 검색할 때 KNN(기준 벡터와 가장 가까운 K개의 벡터를 찾아주는 방법)이 사용되는데, 벡터 인덱싱은 그 작업을 더 빠르게 하기 위해 사용된다.

벡터 공간을 쪼개거나, 비슷한 벡터끼리 그래프처럼 연결하거나, 트리 구조로 나누거나 이런 다양한 방식으로 비슷한 애들끼리 미리 묶어놓고 검색 범위를 줄인다.

vector Indexing 기법

1. Flat Index

   별도의 인덱싱 기법 없이 벡터를 저장하는 방법이다. 모든 벡터들과 유사도를 계산해 가장 높은 유사도를 지닌 벡터를 찾는다. 일반적으로 10000~50000개 정도이 벡터에서 적당한 성능과 높은 정확성을 얻을 수 있다. 하지만 실제로 이렇게 사용한다면 벡터 데이터가 더 많아 탐색 속도가 느려질 것이다.

2. Random Projection

   랜덤한 벡터를 만들어서 원래 벡터와의 내적을 시켜서 차원을 줄 이는 방법이다. 원래 벡터와의 유사성도 유지할수 있고 고차원의 원래 벡터보다 탐색속도가 빠를수 있다고 한다. 하지만 Approxiamtion이기 때문에 정확도는 다소 떨어질수 있다.

3. PQ (Product Quantization)

   원래 벡터를 균등하게 몇개의 서브벡터로 쪼개고, 각 서브벡터들 을 Quantization하여 크기를 줄이는 방법이다. 빠르고 정확도도 좋으며 큰 데이터셋에서 사용하기 좋은 기법이라 고 한다. Quantiztion으로 값을 표현하는데 사용하는 bit수를 줄 이기 때문에 메모리 사용량도 적고, 탐색 속도도 빠르다. 하지만 근본적으로 표현하는 숫자의 범위를 제한하는 방법이기 때 문에 정확도는 다소 떨어질수 있다.

4. LSH (Locality-Sensitive Hashing)

   원래 벡터를 hashing 함수에 한번 돌려서 bucket에 매핑하고, bucket에서 비교하여 찾는 방법이다. 유사도 검색을 할때도 쿼리문에 대한 벡터를 동일한 해싱함수를 사용해서 같은 버킷에 있는 벡터들하고만 비교하여 찾는다. 전체 데이터가 아니라 버킷에 있는 데이터안에서만 찾기 때문에 탐색속도가 빠르다. 하지만 버킷이 많을수록 정확도가 높아지겟지만, 더 많은 메모리 가필요하게 된다.

5. HNSW (Hierarchical Navigable Small World grahp)

   원래 벡터를 가지고 N개의 레이어를 가진 그래프를 생성하고, 그 래프를 기반으로 가장 가까운(유사도가 높은)결과를 찾아내는 방 법이다.

VCS는 Version Control System의 약자로 버전관리 시스템을 이르는 말이다. 이름 그대로 파일의 변화를 버전에 따라 기록하고 관리하기 때문에, 파일을 이전 상태로 쉽게 복구할 수 있다.

git 동작 원리

버전 관리 시스템의 한 종류인 git을 사용하기 위해선 처음에 git init이란 명령어를 실행해야한다. 새 디렉터리나 기존 디렉터리에서 git init을 실행하면 Git은 .git디렉터리를 생성하는데, 이 디렉터리에 Git이 저장하고 조작하는 파일들, 트리 구조, 커밋 등 모든 것이 저장된다.

git 공식 문서를 보면 config, description, hooks/등 여러 파일과 디렉토리가 생성되지만 그 중 가장 중요한 것은 역시 objects 디렉토리이다.(이 단계에서 index파일은 아직 생성되지 않는다.) objects디렉토리는 데이터베이스의 모든 콘텐츠와 버전 정보들을 객체 형태로 저장하는데 이 객체들의 종류는 다음과 같다.

• blob
• tree
• commit

그럼 이제 git add 명령어와 git commit 명령어를 입력하면 각 객체들이 object파일에 어떻게 저장되는지 흐름을 따라가며 알아보자.

1. git add

• 파일1이라는 제목의 파일을 작성한다.
• git add 파일1이라는 명령어를 실행할시, 파일1의 내용은 SHA1 해시알고리즘을 통해 일정한 길이의 문자열로 변환된다.
• 해시된 값의 앞에서 2글자는 object밑의 디렉토리명이 되고, 나머지 해시값은 해당 디렉토리 밑에 파일명이 된다. 이 파일이 blob객체다! 그리고 그 blob객체 파일의 내용에 파일1의 원본 내용이 들어있게 된다.
• 그러면 blob객체에는 실질적으로 파일의 내용만 담기게 되는데 파일제목같은건 어디에 저장될까? 바로 index파일에 저장된다.
• index파일은 첫 add 실행시 생성되고, 여기에 Git의 스테이징 영역 정보를 저장한다. (스테이징 영역은 커밋 될 준비가 된 파일들이 위치한 영역을 뜻한다.)
• index파일에는 해당 파일의 파일이름, 해시값등이 담기게 된다. 나중에 이 정보들을 보고 커밋을 할 수 있다.
• 간단하게 말하면 파일의 내용은 objects디렉토리 밑에, 파일의 이름은 index파일에 저장되게 된다.

2. git commit

• 스테이징 영역에 담긴 파일을 커밋하면, 하위트리와 blob으로 구성된 tree 정보, 커밋한 사용자 정보, 커밋 메시지 등을 담은 commit객체가 만들어진다.
• tree는 index정보를 바탕으로 만들어진다.
• 여기서 만약에 파일을 다시 수정하고 add 한 후에(여기서 index파일의 해시값도 당연히 업데이트 된다.) 또 commit을 하면 새로운 tree가 생성되는데, 만약 커밋한 파일들 중 내용이 변경되지 않은 파일이 있다면 그 파일은 이전 커밋에서의 해시값과 동일한 값을 가진다. 재활용하는 것이다. 그리고 새로 생성된 commit오브젝트는 첫 commit오브젝트를 parent로 가진다.

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 공식문서에 git의 동작흐름이 이해하기 쉽게 그림과 예시와 함께 자세하게 잘 나와있다.

SHA1? zlib?

blob객체를 생성할때 SHA1알고리즘을 사용한다고 하는데 이게 뭘까? SHA-1 해시 값은 40자리 고정 문자열로, 내용이 같으면 무조건 같은 해시 값이 나온다. 이걸 통해서 git은 해시 값을 통해 파일이 변경되었는지, 그대로인지 판단해서 변경된 파일(해시값이 바뀐 파일)만 새로 저장한다.

sha256은 SHA-1보다 더 강력한 해시 알고리즘이다. SHA-1은 160비트 40자리 해시값이고, SHA-256은 256비트 64자리 해시값이다. 이 덕분에 sha256는 SHA-1보다 보안에 훨씬 더 강력하다. 또한 같은 해시값이 만들어질 가능성 또한 매우 적다.

zlib는 또 무엇인가. 간단히 말하자면 압축 알고리즘이다. Git은 저장 효율을 높이기 위해, 저장하는 객체를 zlib 압축해서 .git/objects/에 저장한다.

node.js에는 SHA와 zlib 두 개의 알고리즘 모듈이 모두 내장되어 있다!

파일 상태 용어

<Tracking 단계> git init 직후에는 모든 파일이 Untracked (추적 안됨) 상태, git add <파일>을 하면 → Tracked (추적됨) 상태로 전환됨

Git이 "이 파일은 나중에 커밋할지 말지 확인해야겠군!" 하고 계속 지켜보는 게 Tracking

<Modified 단계> 추적 중인(Tracked) 파일을 수정해서 저장소와 내용이 다른 상태

<Staged 단계> 커밋할 준비가 완료된 상태. Git이 “얘는 커밋할 거야” 하고 인덱스(index)에 올려둔 파일

Fork vs Clone

이건 예전부터 계속 헷갈렸던 개념이었는데 둘 다 대충 남의 코드를 복사해온다는 느낌으로 알고 있어서 차이점을 그리 자세하게 알진 못했다.

좀 더 정확하게 비교를 하자면 Fork는 남의 원격 저장소 -> 내 원격 저장소로 옮기는 작업이다. 이건 당연히 Git의 기능이 아니라 GitHub같은 원격 저장소 서비스에서만 존재하는 기능이다. 보통 외부 프로젝트에 PR을 보내고 싶을때 Upstream저장소(원본 저장소)에 push할 권한을 가지고 있지 않기 때문에 본인의 원격 저장소로 작업물을 복사해오는 걸 뜻한다. 이렇게 되면 원본과 내 저장소 사이에 연결이 생겨 PR요청을 보내는 것이 가능해진다.

Clone은 원격 저장소 -> 로컬 저장소로 복사하는 Git의 명령어이다. 복사할 저장소는 내꺼든 남의거든 상관없이 복사해 올 수 있지만 외부 프로젝트에 연결은 안 되어 있기 때문에 나중에 내 원격저장소에 코드를 올려도 PR이 불가능하다.

보통 오픈 소스 프로젝트에 기여할때는 해당 저장소의 push 권한이 없기 때문에 Fork -> Clone의 순서를 따른다.

권한이 부여된 경우 굳이 번거롭게 외부 저장소를 만들 필요 없이 해당 원본 프로젝트 내에서 직접적으로 브랜치를 통해 작업하기 때문에 Clone만으로 프로젝트에 참여하는 경우가 많다고 한다.

결론적으로 둘 다 저장소를 복사하는건 맞는데 그 용도나 복사되는 장소, 목적등이 다르다.

프로세스가 가족이라면 스레드는 그 가족 구성원 한명한명 이라고 볼 수 있다. 프로세스는 실행 중인 프로그램 인스턴스 그 자체를 가리키는데 스레드는 그 인스턴스에서 실행되고 있는 여러 작업 흐름들을 말한다.

멀티 프로세스? 멀티 스레드?

학습을 하며 든 의문이 멀티 프로세스 개념이 있는데 왜 멀티 스레드라는 개념을 또 만든거지? 라는 생각이었다. 여러 작업을 동시에 처리할 수 있도록 해 주는것은 프로세스를 여러 개 사용하는 멀티 프로세스로도 가능하기 때문이다. 하지만 안 쓰는데는 이유가 있었다.

프로세스는 데이터 공유를 하지 않는다. 즉, 하나의 프로세스가 실행될때, 메모리에 고유의 영역을 할당받고 그 안의 데이터를 다른 프로세스와 공유하지 않는다. 이렇게 되면 당연히 컨텍스트 스위칭(쉽게말해 CPU에서 실행중인 프로세스를 변경하는것)을 할 때 데이터들을 전부 넘겨주어야 하니 작업이 무거워질 수밖에 없다.

그러나 스레드는 같은 프로세스의 스레드라면 전부 같은 메모리를 공유한다(Stack영역만 빼고). 그래서 프로세스와는 다르게 컨텍스트 스위칭이 훨씬 가볍다!

경쟁 조건(race condition)

다만 멀티 스레드도 당연히 단점이 있다. 스레드는 하나의 프로세스에게 할당된 메모리중에서 스택을 뺀 나머지 영역의 데이터를 공유하는데(힙, 텍스트, 데이터) 이 때문에 경쟁 조건(race condition)이 발생할 수도 있다.

경쟁 조건(race condition)이란 여러 스레드나 프로세스가 동시에 같은 자원에 접근하면서 실행 순서에 따라 결과가 달라지는 오류가 발생할 수 있는 상황을 말하는데, 다시 말해 자원을 공유하는 스레드가 병렬적으로 여러 개 존재하다 보니 스레드1과 스레드2가 공유 자원을 거의 동시에 접근해서 변경하면 값이 덮어써지거나, 중복처리 되는 등 해당 변수는 결과가 이상해질 수 있다.

그래서 멀티 프로세스와 멀티 스레드는 공유 자원 동기화가 필요하다! --> 경쟁 조건은 공유자원의 문제가 아니라 실행작업을 동시에 하는게 문제인 것임

멀티 프로세스/스레드 어떻게 동기화 시켜야 하나?

경쟁 조건이 발생하는 이유는 프로세스나 스레드가 동일한 작업을 동일한 시점에 하기 때문에 발생하는 것이다. 그렇다면 해당 작업에 하나의 프로세스/스레드만 진입이 가능하게 하면 경쟁조건이 발생할 가능성이 없어지지 않을까? 해당 함수나 모듈 내에서 사용중인 프로세스/스레드의 유무값을 저장하고, 이후 요청이 들어오면 그 유무값에 의해 거절하든 사용하라고 하든 하면 될 것이다!

이러한 개념을 critical section(임계 영역)이라고 한다. 공유 데이터의 일관성을 보장하기 위해 하나의 프로세스/스레드만 진입해서 실행 가능한 영역이라는 개념이다. 그리고 이러한 임계 영역에 진입하기 위한 요건을 확인하는 영역을 entry section이라고 한다.

그렇다면 공유 불가능한 자원의 동시 사용을 방지해주는 상호 배제 알고리즘에는 어떤 것들이 있을까.

스핀락 - lock값을 이용해 관리하는 방법이다. 실행중인 프로세스나 스레드가 있다면, lock 값이 실행 중 상태에서 벗어날 때까지 반복해서 시도하고, 실행중인 프로세스나 스레드가 완료되면, 비로소 lock값을 얻어 임계 영역에 진입이 가능해진다. 다만 이 방식은 기다리는 동안 계속해서 lock을 확인하기 때문에 CPU를 낭비한다는 단점이 있다.

뮤텍스 - 스핀락과는 다르게 계속해서 문을 두드리는게 아니라 예약을 걸어놓는다고 생각하면 이해가 쉽다. 만약 사용중이라면 해당 스레드를 큐에 넣어 예약을 걸어놓고, 기존 작업이 끝나면 큐에서 값을 꺼내 실행을 시킨다.

세마포어 - 뮤텍스와 어느 정도 유사하나 임계 영역에 여러 프로세스나 스레드가 들어갈 수 있음.

IPC?

멀티 스레드는 자원을 같이 쓰기 때문에 메모리가 자동적으로 공유된다. 그러나 멀티 프로세스는 메모리가 분리되어 있기 때문에 따로 데이터를 주고받는 통신이 필요하다. 그게 바로 IPC이다.

여러 프로세스가 공동 작업하거나, 하나의 프로세스가 다른 프로세스에게 신호나 명령을 전달할 때나, 분산 시스템, 병렬 처리 등에서 프로세스 간 협력이 필요할 때 IPC가 사용된다. IPC는 OS에서 제공하는 통신 메커니즘을 사용한다.

이러한 IPC는 락, 뮤텍스, 세마포어와 결합되어 상호 배제를 위해서도 사용될 수 있다.

비동기 이벤트 매니저

비동기 이벤트 매니저(Asynchronous Event Manager)는 이벤트 기반 프로그래밍에서 이벤트를 등록하고, 발생시키고, 처리하는 과정을 비동기 방식으로 관리하는 시스템 또는 객체를 말한다.

Publisher-Subscriber 패턴

🎙️ Publisher : 어떤 이벤트(메시지)가 발생했다고 알리는 쪽

👂 Subscriber : 어떤 이벤트가 발생하면 반응(처리)하는 쪽

이벤트를 발행한 쪽과 구독한 쪽이 서로를 몰라도 작동하는 구조

비동기 대기큐

지금 당장 실행하지 않고, 나중에 실행해야 할 작업(콜백, 이벤트 처리 등)을 임시로 저장해두는 대기열이다.

Event Emitter

Node.js에서 이벤트 기반 프로그래밍을 할때 사용되는 클래스이다. Node.js에서 가장 기본적인 이벤트 처리 방식 중 하나이다. EventEmitter 클래스를 상속한 객체를 만들고, on() 메서드를 사용해 이벤트 리스너를 등록하여 이벤트가 발생할 때마다 등록된 콜백 함수가 실행된다.

이벤트는 문자열 형태의 이름과 함께 발생하며, 이벤트에 대한 데이터를 선택적으로 전달할 수도 있다.

const { EventEmitter } = require("events");
const emitter = new EventEmitter();

emitter.on("hello", (msg) => console.log("받음:", msg));
emitter.emit("hello", "안녕");

emitter인스턴스는 이벤트 이름에 해당하는 콜백 리스트를 Map 형태로 내부에 저장한다.

.on메서드를 통해 이벤트를 등록하고(이건 subscriber 등록을 의미한다), .emit메서드를 통해 이벤트를 발생시킨다(Publisher가 이벤트 발생시킴).

Promise

Promise는 비동기 작업을 수행하는 함수가 반환하는 객체로, 성공하면 결과 값을 반환하고 실패하면 에러를 반환한다. 이러한 특성으로 Promise는 비동기 작업의 성공 또는 실패 상태를 쉽게 확인하고 처리할 수 있다.