Studying IT with cobinding

[Redis] 운영환경에서 ElastiCache(Valkey)를 사용할 때 알아야 할 지식: 기본 구조, ClusterMode, MultiAZ, 업그레이드 동작방식

sebinChu — Sun, 7 Jun 2026 23:58:04 +0900

개요

최근 Redis To Valkey 업그레이드 전환을 주도하면서 실제 작업을 통해 배운 운영 환경에서의 ElastiCache 사용방법에 대해 정리한다.

1. ElastiCache 기본 구조

1.1. Shard와 Node

ElastiCache를 생성할 때 Cluster Mode로 생성하면, Shard, Node 구성을 선택해야 한다. Shard와 Node(Replicas Per Shard)의 역할은 각각 다음과 같다.

1.1.1. Shard

데이터를 여러 샤드에 나눠 저장하여 CPU, 메모리 사용량을 분산한다.
각 Shard는 데이터에 대한 Slot을 나눠서 가진다.
- key-value Store인 ElastiCache는 각 key에 대해 Hash Slot을 할당하고, Slot Number를 기준으로 key-value 데이터 쌍을 관리한다. (여러 키가 Slot을 공유한다.) 이렇게 하는 이유는, Shard가 추가되고 줄어들 때, Slot 단위로 데이터를 움직이게 하기 위해서다. 또한, get/set 데이터 라우팅의 기준이 되기도 한다. Client가 명령을 보낼 때마다 CRC16 (key) mod 16384로 Slot을 계산하고, 그 slot을 소유한 Shard로 명령을 보낸다.
- 만약 Key-Shard가 직접적으로 매핑된다면 Shard가 바뀔 때마다 매핑이 흔들리게 된다. Shard가 바뀔 때마다 전체 데이터의 이동이 필요해지기 때문이다. 따라서 Slot 단위로 묶고 리샤딩 때도, 데이터는 Slot 단위로 이동한다.

1.1.2. Node

노드는 key-value 데이터가 실제 RAM에 사는 물리적 단위다. 하나의 Shard는 Master Node 1개 + Replica 0~5개의 Node로 구성된다. [위 그림 참고]

Master(Primary): 해당 Slot 범위의 모든 Wirte를 처리한다. Read도 가능하다.
Replica: Master를 async로 복제한 사본이다. 1) Read 분산에 사용되고, 2) Master 장애 시, Failover 대상(HA)이다.

1.2. Replica의 활용 2가지

1.2.1. HA (자동 Failover)

Multi-AZ 활성화, Replica가 1대 이상이 조건이다.
Master 장애가 감지되면 가장 최신 Replica를 Master로 승격한다. 뒤에서 자세히 설명할 테지만 이때 Node DNS Topology가 변경되어 Client Connection은 끊긴 후에 재연결되며 애플리케이션과 ElastiCache 사이의 Topology 갱신이 필요하다. (클라이언트 설정으로 컨트롤 가능하다.)

1.2.2. Read 분산

Replica로 Read 트래픽을 분산한다. 노드당 Read 부하를 감소시킬 수 있다.
ElastiCache는 Reader Endpoint를 제공한다. 일반적으로는 Client의 READONLY 옵션 등을 통해 직접 분산시킨다.
만약 강한 일관성이 필요한 Read라면 Master로 보내야한다. (예컨대, Wirte 직후 즉시 Read가 필요함)

1.3. 현재 인프라 구성

기본적으로 우리 인프라에서는 Master 1 + Replica 1 구조를 갖는다. 이렇게 한 이유는 SRE팀 인프라 표준 AZ 정책을 기반으로, 각 Zone 설정 통합을 위해서다. EKS 워커 노드들도 A, C Zone에만 배치되도록 표준화되어있다.

추가로, 경험 상 Replica를 2대 이상 둘 가치가 있는 상황은 다음과 같다.

Failover 진행 중에도 Read 가용성을 유지해야 할 때
Read 트래픽이 압도적으로 많은 패턴의 애플리케이션

서비스 특성을 고려해서 필요하다면 Replica를 2대 이상 둘 수 있도록, 사내 플랫폼에서 Self-Service 기능을 제공하고 있다.

2. Cluster Mode와 MultiAZ

2.1. Cluster Mode

클러스터 모드는 Sharding을 하냐/하지 않냐에 따라 나뉜다. 세부적으로 달라지는 부분들이 있지만 크게 중요한 건 다음과 같다.

Cluster Mode Enabled를 통해 데이터를 여러 샤드에 분산해서 CPU/메모리 사용량을 분산시킬 수 있다. 즉, 수평 확장이 가능하다.
Cluster Mode Enabled 클러스터의 Parameter Group 설정은 반드시 cluster_enabled=true 값을 설정해야 한다.

2.2. MultiAZ(Availability Zone)

AZ는 한 리전 안에서 물리적으로 분리된 데이터센터를 의미한다. 예를 들어 ap-northeast-2a, ap-northeast-2b 요런식...

AZ를 분리하면 한 AZ가 통째로 죽어도, 다른 AZ는 멀쩡하도록 분리되어있다. 서비스 안정성을 위해 각 존별로 노드를 띄우는 전략을 취하기도 한다.

3. ElastiCache 노드 유형, 노드 버전 업그레이드 작동 방식

3.1. ElastiCache 노드 유형

선택할 수 있는 노드 유형은 대표적으로 t, m, r 시리즈가 있다. 큰 차이는 다음과 같다.

T: 가장 저렴하고 사양이 낮은 노드 유형이다. T 시리즈는 저렴하긴 하지만 개발 환경에서만 권하고 있다. t 시리즈는 필요할 때만 순간적으로 성능을 높이는 Burst Credit 기반의 인스턴스이기 때문이다. 실제로 적은 사용량에 메모리가 충분함에도 불구하고 메모리 스왑이 지속적으로 발생하는 경우도 있었다.
M: General Purpose. 메모리 집약적인 연산이 없는 일반적인 캐시의 경우, M 시리즈 사용을 권장한다.
R: 메모리 성능에 특화된 유형으로, vCPU 당 메모리가 가장 많은 유형이다. 같은 사이즈(.large)로 비교하면, R이 M보다 메모리가 약 2배 정도다.

3.2. ElastiCache 노드 유형/버전 업그레이드 동작방식

노드 유형 업그레이드와 노드 버전 업그레이드는 기본적인 메커니즘이 같다. 이번에 Redis To Valkey 전환 작업을 주도하면서 가장 많이 살펴봤던 것이 해당 부분이다.

3.2.1. in-place 업그레이드

ElastiCache 노드 업그레이드는 in-place 방식으로 진행된다. [참고 문서] 새로운 클러스터를 만들어서 데이터를 옮기는 것(blue-green 등)이 아니라, 지금 쓰는 클러스터를 그대로 둔 채로 노드 버전을 올리는 것이다. 애플리케이션 입장에서는 접속 Endpoints DNS가 바뀌지 않는다. 덕분에 클라이언트 재배포 없이 업그레이드가 가능하지만, 대신 순단은 감수해야 한다.

3.2.2. 실제 동작 순서

Redis Note

3.2.3. 업그레이드와 Topology 갱신

in-place 방식대로 업그레이드를 진행한다면 짧은 순단(Write 실패)이 발생한다. 동기화 단계에서는 기존 노드가 정상적으로 트래픽을 처리하기 때문에 영향이 없고, 전환 시점에 한해서 기존 Primary로의 connection이 끊긴다. 실제 전환 시에 샤드당 단절 수준은 N초 정도였지만, 에러율은 최대 5분까지 이어졌다.

새로운 connection을 위해 클라이언트는, 재연결 후 Cluster Topology를 갱신해서(CLUSTER SLOTS/ CLUSTER NODES) 새 노드를 찾아야 한다. Redis To Valkey로의 전환을 권장하기 위해 아래와 같이 언어별 가이드를 만들어서 배포했다.

경험으로 배운 운영 지식

토폴로지 갱신이 느리거나 MOVED/ASK Redirect를 따라가지 못하느 클라이언트는 짧은 순단동안 에러를 낸다.
각 클라이언트별로 Redis Version과 호환성을 잘 체크해야한다.
- 예컨대, go-redis v8은 Redis 6.x와 호환된다. Valkey 7.x로의 업그레이드를 위해서는 go-redis를 v9로 업그레이드하는 선행 작업이 요구된다. 실제로 클라이언트 라이브러리 업그레이드를 놓치고 Valkey 전환을 진행했을 때 Valkey 연결에 지속적인 Panic이 발생하기도 했었다.

{"level":"panic","error":"got 4 elements in cluster info address, expected 2 or 3","time":"2026-06-01T09:27:37Z","message":"redis.New(session) failed"}

Write보다 Read 연산이 압도적으로 많은 작업을 하는 클러스터라면, 미리 Replica를 늘리고 전환을 시도하는 것이 순단 영향을 많이 줄여줄 수 있다.

결론은 Client별 재연결/Topology Refresh, Max Redirec 설정 등 클라이언트 설정을 미리 점검해두는 것이 순단 영향을 줄이는 것의 핵심이었다.

나의 경우는 사내 배포 플랫폼에 AWS API를 구조적으로 구성하여 전사 모든 클러스터의 전환 과정이 동일했다. AWS 콘솔에서 직접 진행하는 경우는 전환 이후의 Parameter Group 설정이나 cluster_enabled같은 값이 의도대로 잘 넘어왔는지 확인하는 것도 좋을 듯하다.

[BackEnd] Index를 통해 DB 조회 성능 1.2만배 개선하기

sebinChu — Sun, 8 Mar 2026 10:56:42 +0900

개요

어느 날부터 리소스를 조회하는 GET 요청에 대해 적게는 20초 많게는 120초까지 조회가 오래 걸리는 현상이 생겼다. 이를 해결하기 위해 했던 작업들과 개선 결과를 정리한다.

1. 간단한 프로젝트 구조 설명

사내 배포 플랫폼에 기여하며 인프라 & 개발 업무 경험을 쌓고 있다. 주업무 중 하나는 AWS 리소스 관련 CRUD 개발인데, 프레임워크는 FastAPI를 사용하고 대부분의 요청은 Celery Task를 통해 동작한다.

AWS 생성과 같은 요청은 본질적으로 느리고 실패할 수 있는 작업이다. S3 버킷, Redis 클러스터, EC2 인스턴스 등 생성에 수십 초~수 분 소요되며, 특히 Redis의 경우 여러 단계를 순서대로 실행해야 하는 복잡한 워크플로우를 따라야 한다. (ex. Subnet Group → Replication Group → Tagging) 그렇기 때문에 대부분의 요청은 Celery Task를 통해 실행되며, 리소스 상태를 추적하기 위해 이 값을 DB에 저장하고 있다.

2. 문제 파악을 위한 Datadog APM 설정

우선 이 문제 파악을 위해서 API 요청 흐름을 정리하고, 이 과정에서 느린 쿼리가 있는지 분석해보았다.

어느 날부터 리소스를 조회하는 GET 요청에 대해 적게는 20초 많게는 120초까지 조회가 오래 걸리는 현상이 생겼다.

문제가 될 만한 로직은 다음 부분이었는데,

def solve_xxx (self, resource: Resource):
    """ResourceGroup 내의 Resource 목록을 조회할 때 사용하는 함수
    relation(lazy-loading) 이 설정된 모델 애트리뷰트를 직접 참조해서 데이터 형태를 완성한다.
    """

    # XXX: 현재는 단순 참조 로직으로 데이터를 완성하지만
    #      n+1 문제를 유발하므로 성능에 문제가 있는 경우 튜닝해야 함.
    #      리소스는 2env(alpha, prod) * 4region(kr, jp, ca, gb)
    #      총 8개의 리소스이므로 크게 문제는 없을 듯.

    for event in resource.events:
        event.celery_task

SQLArchemy 동작 방식에 따르면 resource.events, event.celery_task와 같이 relationship 속성에 접근하면 DB 쿼리를 수행하게 된다. 위 코드에서 celery_task 조회는 event 개수만큼 실행된다.

따라서, 아래 두 가지 데이터 개수를 확인 후, 느린 쿼리에 대해 판단해야 한다.

resource별 event 개수 (resource_events 테이블)
event별 celery_task 연결 여부 (celery_tasks 테이블)

처음에 실수?를 한 건, 이 resource 별 event 개수에만 집중해서 `for event in resource.events`에 대한 쿼리만 분석했다. 그 결과는 800개 수준이었고 당연히 느린 쿼리가 아닐 것이라고 판단했다. 그래서 좀 더 세밀한 분석을 위해 데이터독 도움을 받고자 APM을 설정하였다.

3. Datadog APM 설정 및 Latency 분석

APM 설정을 위해 필요한 작업은 ddog 가이드 문서를 참고했다. 새삼 우리 팀의 플랫폼 & 모니터링 인프라가 잘 되어있다는 걸 느낀 점은 Datadog Agent Pod 설정과 환경변수 주입은 아주 쉽게 해결할 수 있었다.

3.1 Datadog 가이드 문서를 따라 Trace 설정

Python ddtrace 라이브러리 추가
DockerFile에서 실행 부분(CMD)에 ddtrace 패키지 사용 명령어 `ddtrace-run` 추가
Datadog 태그 환경 변수 설정

세팅해야 할 환경변수들이 Pod에 잘 설정되어 있는 점

ddtrace-run 추가!

3.2 APM 설정 완료

이렇게 데이터독 대시보드에서 관련 지표를 확인할 수 있다. 모니터링 준비가 끝나서 바로 느린 요청에 대해 확인을 시작했다.

GET 요청에 대해 22s가 걸리는데, 그 중에서 특정 쿼리들이 느린 점을 trace를 통해 확인할 수 있었다. trace를 통해 느린 쿼리를 확인해보니, 처음에 의심했던 로직에 문제가 있었다.

3.3 Full Scan, 느린 쿼리 확인

데이터독을 통해 확인한 느린 쿼리와 관련해서 비슷한 쿼리를 만든 다음, EXPLAIN을 통해 어떻게 쿼리가 동작하는지 확인해보았다. 아래 두 가지 결과를 통해 느린 쿼리의 원인임을 판단했다.

type=all 즉, full-scan(테이블의 모든 행을 읽음)한다. → 테이블의 모든 행을 스캔해야 하기에, 데이터가 많아질 수록 성능 부하
show index를 했을 때 primary_index만 생성되어있다. → PK에 대한 primary_index만 생성되어있었다. 문제가 되는 task_id에 대한 인덱스는 존재하지 않는 상황이다.

결론적으로 이 내용을 조합해보면, 리소스를 한번 조회할 때, task_id에 대해서 6만 행에 대한 full-scan이 발생하고 있었다.

4. Index 추가 (SQLAlchemy, MySQL)

원인 분석 후, 해결 방법은 해당 컬럼에 대한 index를 생성하는 것이었다. index 생성이 이 문제를 해결해줄 것이라고 판단한 기준은 다음과 같다.

4.1 Index 추가로 해결 가능한 이유는?

해당 컬럼에 대해 `SELECT`만 빈번히, `UPDATE` 및 `DELETE` 쿼리는 거의 일어나지 않는 패턴이다.
카디널리티가 높다.
- task_id는 uuid같은 값을 가지고 있다. 카디널리티 확인을 위해 null, "", `GROUP BY`를 통한 중복값을 확인하였다.

4.2 SQLAlchemy로 Index 추가하기

DB에서 바로 Index를 추가할 수 있지만, 그러면 코드 <> 마이그레이션 히스토리 <> DB 간 정합성이 깨진다. 그래서 모델 수정 + Alembic 마이그레이션을 통한 index 생성 작업을 진행했다.

이 방법이 가능한 이유는 다음과 같다.

MySQL(InnoDB)에서는 UNIQUE 제약 조건이 붙은 열에 대해서, secondary index를 자동 생성한다.
코드 수정을 통한 SQLAlchemy 모델 변경 → Alembic을 통한 DDL Script 실행 →MySQL이 index 생성

이를 반영하기 위해 아래와 같이 코드를 수정 후, DB 마이그레이션을 진행했다.

5. 결과!

대부분의 GET 응답 Latency가 5s 미만을 유지하게 되었다! 그리고 특히 해당 쿼리는 21.6s → 1.68ms (약 1.2만배) 정도의 개선 결과가 있었다.

[Redis] Redis 운영 지식: redis-cli 명령어 정리

sebinChu — Mon, 2 Mar 2026 22:11:57 +0900

개요

자주 사용하는 redis-cli를 미리 정리해두고, 장애 대응이나 모니터링 상황 시에 활용하자.

1. ElastiCache Endpoints

1.1 Connection Endpoints

각 엔드포인트의 역할을 잘 이해하고, 특히 클러스터 모드일 때의 접근 방법을 기억하자.

필자의 상황은 클러스터 모드를 활성화하고 샤드 2, 노드 2 구성을 가진 ElastiCache Engine을 하나 준비해두었다. 이와 같이 클러스터 모드가 활성화된 엔진이라면, 위 이미지처럼 Configuration Endpoint를 주로 활용한다. 참고로, 클러스터 모드를 비활성화한 경우는 Primary Endpoint가 생성되고, 해당 엔드포인트를 활용한다.

이와 같이 Shards and nodes 섹션에서 각 노드들의 Endpoint 또한 확인할 수 있다. 보통은 첫 번째 이미지의 Configuration Endpoints를 활용하고, 특정 샤드/노드에 대한 특수한 확인이 필요할 때만 이 개별 Endpoint를 사용한다.

# Endpoints 정리!

Configuration Endpoints: 클러스터 모드일 때 일반적으로 커넥션을 맺는 주소
Primary Endpoints: 클러스터 모드가 아닐 때 일반적으로 커넥션을 맺는 주소
Shards and nodes 섹션의 개별 Node에 대한 Endpoints: 특정 샤드/노드에 대한 커넥션을 맺는 주소

1.2 redis-cli를 통해 엔드포인트에 연결

redis-cli -h ${cluster-endpoint} -p 6379 -c

-c: 여러 노드가 생성된 클러스터 모드 엔진의 경우, key가 여러 샤드/노드에 분산되어있다. 이 옵션을 통해 redis-cli가 자동으로 해당 키가 있는 노드에 접근할 수 있도록 리다이렉트를 해주기에, 클러스터 모드일 경우 이 옵션이 필요하다.

간단한 list, info 명령어로 확인

# tls로 접속하기

redis-cli --tls -h <host> -p <port>

2. Redis 리소스 상태 확인

# 전체 정보
info all

# 섹션 별 조회
info memory
info stats
info commandstats
info clients
info replication
info keyspace
info server
info persistence

2.1 INFO memory

지표	의미	메모
used_memory_human	실제 사용 메모리	dataset(실제 key&value) + overhead(내부 사용 메모리)
used_memory_rss_human	OS가 Redis 프로세스에 할당한 메모리 (Resident Set Size)
mem_fragmentation_ratio	RSS/ used_memory → 메모리 단편화 비율!	- 1.0~1.2 수준이면 정상이고, 1.5가 넘어가면 위험할 수 있다. 1.0보다 낮으면 스왑 발생 → config set activedefrag yes/ failover/캐시 사용 패턴 개선
used_memory_peak_human	지금까지 사용한 최대 메모리	- 피크를 기준으로 메모리 용량 산정해야한다. - slowlog get 10 - info commandstats
used_memory_peak_perc	현재 사용량이 피크 대비 몇 %인가
max_memory_policy	사용 가능한 최대 메모리 한도 → 이 값을 초과하면 Policy 동작	- config set maxmemory 12gb - 시스템 메모리의 60~75% 수준으로 설정 권장 → 나머지는 os, 버퍼 등에 사용
mem_allocator	현재 사용 중인 메모리 할당자 정보 - 대부분 jemalloc-5.x.x이고, - 간혹 lib, tcmalloc	jemalloc: 기본이자 권장 할당자. 단편화 관리가 우수하고, activedefrag 기능이 jemalloc에서만 동작한다.

2.2 INFO clients

지표	메모리	메모
connected_clients	현재 연결된 클라이언트 수	maxclients와 비교한다. max에 도달하면 전부 연결이 거부된다.
blocked_clients	블로킹 명령(blpop, brpop, xread block)으로대기 중인 클라이언트 수

# 자세한 클라이언트 정보 → client list

redis-cli CLIENT LIST

id=123 addr=10.0.0.5:54321 fd=8 name=order-service age=3600 idle=10 
flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 obl=0 oll=0 omem=0 cmd=get

idle: 마지막 명령어 이후 지난 시간 → 좀비 커넥션 확인(보통은 주기적인 헬스체크를 통해 수백초까지 가지 않음)
- Redis 3.2부터는 TCP keepalive가 활성화되어 약 300초로 설정되어 있다. (문서)
- ElastiCache의 경우 Parameter Group에서 관리한다.
omem: 해당 클라이언트의 출력 버퍼에 쌓인 메모리. 이 값이 크면 큰 응답을 받고 있거나 느리게 응답을 소비 중..
cmd: 마지막으로 사용한 명령어

3. 성능/트래픽

3.1 INFO stats (성능 관련 지표)

INFO stats의 필드는 두 종류가 섞여 있다.

# 순간값(instantaneous_xxx)

instantaneous_ops_per_sec: 현재 초당 처리 명령 수
instantaneous_input_kbps: 현재 클 → 서 Network Bytes
instantaneous_output_kbps: 현재 서 → 클 Network Bytes

# 누적값(서버 기동 이후 계속 쌓임)

이 값들은 Redis를 재시작하거나 config resetstat을 하지 않는 한 계속 올라가기만 한다. 그래서 요것만 보면 이게 지금 문제인지, 6개월에 한 번 있었던 건지 알기 어렵다.

total_commands_processed
keyspace_hits / keyspace_misses
evicted_keys / expired_keys
rejected_connections
sync_full / sync_partial_err
그 외 대부분

그래서 info stats은 사실상 exporter, grafana에서 사용하기 유용한 값들이다.

3.2 INFO commandstats

만약 그라파나 상에서 latency나 ops/s가 치솟는 걸 확인했다면, 어떤 명령어가 영향을 주었는지 commandstats를 통해 확인할 수 있다.

redis-cli INFO commandstats
```
```
# 출력 예시
cmdstat_get:calls=5823120,usec=2914560,usec_per_call=0.50,rejected_calls=0
cmdstat_set:calls=1203400,usec=721800,usec_per_call=0.60,rejected_calls=0
cmdstat_hgetall:calls=45200,usec=1582000,usec_per_call=35.00,rejected_calls=0
cmdstat_keys:calls=12,usec=8520000,usec_per_call=710000.00,rejected_calls=0

여기서 봐야할 건 usec_per_call인데, 위 예시에서 keys가 호출당 710ms를 발생한 걸 알 수 있다.

# usec_per_call 기준으로 정렬해서 느린 명령 찾기

redis-cli INFO commandstats | sort -t, -k3 -rn | head -10

3.3 slowlog

Redis는 특정치를 넘어선 명령어를 큐에 저장해서 slowlog get으로 보여준다. Redis 구조인 단일 스레드 특성 상, 한 명령어가 오랫동안 리소스를 독점하면 전체 성능에 영향이 있으므로, 이를 확인하고 개선하는 것이 중요하다.

이때 측정 시간은 Network I/O, 응답 전송 시간을 제외한 순수 명령어 실행 시간이다.

# 주요 지표 의미

slowlog-log-slower-than (임계값, 마이크로초 μs) : parameter group에서 확인할 수 있다.

현재 기본값이고 engine version에 따라 이 값을 aws에서 설정해준다. 나중에 테스트하고 추가해봐야지..

slowlog-max-len: 최대 보관 개수

4. 고가용성

4.1 INFO replication

현재 노드에 대한 replication 정보를 알 수 있다.

많은 정보들이 나오는데, 하나씩 살펴보자.

master_host: 동기화 대상인 마스터의 주소
master_link_status: `up`이면 정상 연결, `down`이면 끊긴 상태
master_last_io_seconds_ago: master와 마지막으로 통신(I/O)한 지 몇 초가 지났는지 → 보통 값이 작을 수록 정상이다. (0~수 초)
master_sync_in_progress: master가 replica에 대해 sync를 수행 중인지 나타냄. 1이면 동기화, 0이면 아님
slave_read_only: replica가 읽기 전용인지 나타낸다. 1이면 read-only
master_failover_state: 현재 진행 중인 failover가 있/없는지

5. 여러 샤드가 있을 때 유용한 명령어

5.1 샤드별 데이터 저장 분포 확인

redis-cli --cluster call {endpoints} DBSIZE

[AWS] EC2 EBS와 Instance Storage, Root/Local/Ephemeral

sebinChu — Sun, 18 Jan 2026 19:13:57 +0900

개요

EC2 관련 작업을 도맡으면서 서버 운영을 위해서는 Storage 개념을 잘 이해하고 있어야 한다는 점을 알게되었다. 운영 관점에서 고려해보니 루트 볼륨, 이퍼머럴 스토리지, 부팅 디스크 등등 여러 용어도 확실히 알아야 겠다 싶어서 이번 포스팅을 통해 정리해보려 한다.

1. EC2 Storage: EBS와 Instance Store

EC2에 연결할 수 있는 스토리지는 크게 다음과 같다. 이 포스팅에서는 EBS, Instance Store를 중점적으로 알아본다.

  EC2 스토리지
  ├── * EBS (Elastic Block Store)
  │   ├── 루트 볼륨 (부팅용)
  │   └── 추가 볼륨 (데이터용)
  │
  ├── * Instance Store (Ephemeral / Local Storage)
  │
  └── EFS (Elastic File System)

EBS와 Instance Store를 직관적으로 이해할 수 있는 이미지는 다음과 같다.

EBS는 EC2와 네트워크로 연결되고, Instance Store는 물리 서버에 같이 설치된다.

2. EBS(Elastic Block Store)

2.1 Block Store

블록 단위로 데이터를 저장하는 스토리지 방식으로, SAN(Storage Area Network)나 클라우드 기반 스토리지 환경에서 사용되는 기술이다.

데이터를 일정한 크기의 블록으로 나누고, 각 블록에는 고유 주소가 부여된다.
이 식별자를 통해서 데이터를 매우 빠르게 검색할 수 있다.
빠른 성능에 최적화되어있기에 다른 스토리지에 비해 비쌈!

* Block Storage 이외에는 File Storage(EFS), Object Storage(S3) 등이 있다. (이미지 참고)

2.2 Elastic Block Store

EC2에 연결하여 사용하는 블록 스토리지로, EC2 Instance와 독립적으로 데이터 유지가 가능하다.

EC2 Instance와 네트워크로 연결되어, 독립적으로 구성되므로 인스턴스 종료 후에도 데이터가 보존된다.
하나의 EC2 Instance에 여러 용도의 EBS를 붙일 수 있다.
- 단, 속도를 위해 동일한 가용영역 내의 EC2만 연결이 가능하다.
- 거꾸로, 하나의 EBS를 여러 EC2에 장착 가능하다. (EBS Multi Attach)

2.3 루트 볼륨/부팅 디스크

EC2 Instance를 생성하면 EBS가 루트 볼륨으로 설정된다.

루트 볼륨의 역할

부팅 순서를 보면 루트 볼륨의 중요도를 알 수 있다! 루트 볼륨(root device)은 EC2 인스턴스와 같은 서버가 부팅할 때 사용하는 스토리지로, 운영체제와 기본 파일 시스템(/)을 포함한다.이 스토리지를 통해 커널이 메모리에 올라가고, 일반적으로 서버에서 하려는 작업들이 가동 가능한 시스템을 구축하게 된다.

루트 볼륨: Instance Store(Ephemeral) Vs. EBS

EC2 Instance의 루트 볼륨은 EBS, Instance Store 모두 가능하지만 일반적으로는 EBS를 사용한다. (관련 문서)

⚫️ Amazon EBS-backed AMI

EBS를 Root Volume으로 사용하는 AMI다. 현재 AWS에서 생성되는 대부분의 EC2 인스턴스는 EBS-backed AMI를 사용한다. 공식문서에도 나와있듯, AWS에서는 EBS를 루트 볼륨으로 사용할 것을 권장한다.

이유는 뭘까?

인스턴스 서버는 언제든 실패할 수 있는데, EBS의 경우 인스턴스의 중단과 상관없이 데이터가 유지된다.
- 가령 스케일링, 운영 중 설정 변경, 하드웨어 장애 등으로 인해 인스턴스의 중단이나 재생성은 피할 수 없는 이벤트인데, EBS를 루트 볼륨으로 사용하면 인스턴스의 중단 여부와 관계없이 루트 볼륨의 데이터는 그대로 유지된다.
point-in-time스냅샷을 여러 AZ에 복제된 형태로 저장하기 때문에, 필요 시 완전한 볼륨 복구가 가능하다. (안정성 측면!) (관련 문서)
- point-in-time snapshot: 특정 시점(point)의 볼륨 상태를 그대로 보존한 복사본을 의미한다. 단순한 파일 복사가 아니라 파일 시스템, 블록 레벨 데이터, 메타데이터를 포함한 볼륨 전체 상태 등의 특정 시점 기준으로 freeze해서 저장한다. 그래서 스냅샷으로부터 새 볼륨을 만들면 그 시점에 존재하던 특정 디스크 상태 그대로 복원된다.
- 주의할 점 ⚠️ : 이러한 스냅샷은 자동으로 백업되지 않기 때문에 정기적으로 EBS 스냅샷을 생성하거나, Amazon Data Lifecycle Manager, Backup 기능을 사용하여 자동 생성을 구축하는 등의 조치를 사용자가 취해야 한다.

⚫️ Amazon S3-backed AMI

Instance Store를 Root Volume으로 사용하는 AMI다. AMI 자체는 S3에 저장되고, 실제 루트 볼륨은 인스턴스 내부의 로컬 스토리지(Instance Store) 에 생성되는 구조다.>

과거에 사용되다가 deprecated 되어가는 이유는 뭘까?

Instance Store는 인스턴스의 생명 주기와 완전히 결합된 스토리지다. 즉, 인스턴스 장애가 OS 및 서버 상태 전체 유실로 이어진다.
스토리지 계층에서의 장애 복구 모델이 없다.

그렇다면 언제 사용할까?

성능이 생존보다 중요한 상황
기본 설정이 모두 코드로 관리되는 경우 (AMI나 user-data Script를 통해 부팅 시 설치)
데이터는 외부(S3, DB, Redis 등)에 존재

2.5 EBS 볼륨 유형 타입

EBS 볼륨 타입은 일반 컴퓨터에서 SSD를 쓸지, HDD를 쓸지 고르는 것과 비슷한데, AWS는 용도별로 세분화해서 제공한다.

SSD: gp3, gp2, io2, io1
- gp: 웹서버, 개발환경, 소규모 DB에 사용하고 가격 대비 성능 균형이 좋아서 보편적으로 사용
- io: 대규모 DB가 필요할 때 사용하고 IOPS를 직접 지정 가능
HDD: st1, sc1

3. Instance Store

3.1 Instance Store

Instance Store는 EBS처럼 붙였다 떼었다 하는 것이 아니라, EC2 인스턴스가 실행되는 물리 호스트에 직접 연결된 스토리지다. Amazon에서는 인스턴스 유형으로 EC2에 Instance Store가 포함되었는지, 아닌지 구분한다.

EBS가 인스턴스와 논리적으로 분리된 블록 스토리지라면, Instance Store는 인스턴스 타입 자체에 물리적으로 포함된 스토리지라는 점에서 근본적인 차이가 있다.

이 때문에 Instance Store는 다음과 같은 특성을 가진다.

인스턴스 생성 시 함께 제공됨
"attach / detach 개념이 없음
다른 인스턴스에 재사용 불가
인스턴스 생명주기와 완전히 결합됨

AWS 공식 문서에서도 Instance Store를 다음과 같이 정의한다.(유저 가이드 문서)

Instance store provides temporary block-level storage for your instance.
This storage is physically attached to the host computer for an EC2 instance.

즉, Instance Store는 ‘임시(temporary)’ 스토리지이며, 인스턴스가 종료되거나 물리 호스트에 문제가 발생하면 데이터는 복구할 수 없다.

3.2 Instance Store와 NVMe

Instance Store의 높은 성능은 NVMe(Non-Volatile Memory Express) 인터페이스 덕분이다.

NVMe란?

NVMe는 SSD를 빠르게 사용하기 위해 설계된 스토리지 프로토콜이다. 기존 SATA 인터페이스는 HDD 시절에 만들어진 규격이라 SSD의 성능을 온전히 발휘하지 못했는데, NVMe는 PCIe 레인을 통해 CPU와 거의 직통으로 연결되어 훨씬 빠른 I/O를 제공한다.

SATA SSD:  CPU ──(SATA 컨트롤러)──→ SSD
NVMe SSD:  CPU ──(PCIe 직통)──────→ SSD

쉽게 말해, 같은 SSD라도 어떤 인터페이스로 연결하느냐에 따라 속도가 달라진다. NVMe는 SSD를 더 빠르게 전송하는 인터페이스!

Instance Store가 빠른 이유

Instance Store는 EC2가 실행되는 물리 호스트에 장착된 NVMe SSD에 직접 연결된다. 네트워크를 경유하지 않고 PCIe로 바로 붙어있기 때문에 낮은 지연시간과 높은 IOPS를 제공한다. (관련 문서)

Instance Store:  EC2 ──(PCIe)──→ 물리 NVMe SSD (로컬)

그럼 EBS는?

Nitro 기반 EC2에서는 EBS도 NVMe 디바이스로 노출된다. 다만 실제로는 네트워크를 경유하는 원격 스토리지이고, OS에게 NVMe처럼 보이도록 에뮬레이션하는 것이다. NVMe 드라이버가 더 효율적이기 때문에 이런 방식을 사용한다. (관련 문서)

EBS (Nitro):     EC2 ──(가상 NVMe)──→ 네트워크 ──→ EBS 볼륨 (원격)

실제로 Nitro 인스턴스에서 lsblk를 치면 EBS 볼륨도 nvme로 표시된다.

$ lsblk
nvme0n1      259:0    0   8G  0 disk         # EBS 루트 볼륨
└─nvme0n1p1  259:1    0   8G  0 part /
nvme1n1      259:2    0 100G  0 disk /data   # EBS 추가 볼륨
nvme2n1      259:3    0 900G  0 disk /local  # Instance Store (진짜 로컬 NVMe)

* Instance Store는 상황에 따라 다른 이름으로 불리기도 한다.

Local Storage: 네트워크가 아닌 물리적 서버로 붙어있는 것
Ephemeral Storage: 인스턴스가 종료될 때 사라지는 임시 스토리지 (↔ EBS는 인스턴스가 다운되어도 영구 저장됨.)

3.4 Instance Storage 특성

로컬 스토리지는 날아가도 되지만 속도가 중요한 데이터에 사용한다. (로컬 캐시와 같은...) 아래와 같은 활용 케이스가 대표적이다.

Kafka Broker
- >메시지 쓰기/읽기가 초당 수십만건: 속도 필요
- 카프카는 여러 복제본(3대)를 유지하기 때문에 1대가 죽어도 데이터는 그대로!
Spark/EMR
- 여러 Stage 간 데이터를 주고 받을 때, Shuffle 데이터를 Instance Store에 저장
- 대략 이런 구조임: [Stage 1] → shuffle 데이터 → [Stage 2] → shuffle 데이터 → [Stage 3]
캐싱! Redis
로그 버퍼 (S3 전송 전 임시 저장)
- 실제 장애 상황에서 i3en.24xlarge 인스턴스를 여러 대 띄우고, Tantivy 라이브러리로 특정 필드가 존재하는 파일을 다운로드하는 케이스를 본 적 있다.
- S3로 보내기 전에 잠깐 모아두는 용도이고 주기적으로 S3로 Flush하는 방식
ML 임시 데이터
- S3 원본 데이터를 로컬에 복사해서 학습 중 빠른 I/O를 확보

3.5 Instance Store와 인스턴스 유형

Amazon EC2에서는 모든 인스턴스 유형이 Instance Store를 제공하지 않는다. AWS는 인스턴스 유형 자체로 Instance Store 포함 여부를 구분한다. 대표적으로 d suffix가 붙은 인스턴스 유형은 Instance Store를 포함한다. 여기서 d는 dense storage를 의미하며, 로컬 NVMe SSD 기반의 Instance Store가 포함된 인스턴스를 나타낸다.

m5d, c5d, r5d
c6gd, r6gd 등

또한 다음과 같은 suffix들도 Instance Store와 관련이 있다.

i : I/O 최적화 (예: i3, i4i)
h : HDD 기반 대용량 스토리지 (예: h1)

실제 운영에서 알게된 Local Storage 관련 지식(Local Storage 제약 정책)

업무하면서 알게된 것. kubelet의 Disk Pressure는 특정 컨테이너의 Instance Local Storage 점유로 인해서 발생할 수 있다.

이러한 특정 파드의 노드 로컬 스토리지 점유를 막기 위해서 아래와 같은 정책을 적용할 수 있다.

resources:
  limits:
    ephemeral-storage: 10Gi
  requests:
    ephemeral-storage: "0"

해당 정책으로 죽은 Pod는 ContainerStatusUnknown 또는 Failed 상태를 보인다. (Pod ephemeral local storage usage exceeds the total limit of containers 와 같은 메시지도 참고할 수 있다.)

마무리!

EC2 운영을 하려면 스토리지 선택 기준과 각 볼륨의 역할을 알아두는 게 중요한 것 같다.

EBS vs Instance Store: 네트워크로 연결되는 영구 스토리지 vs 물리 서버에 붙은 휘발성 로컬 스토리지
루트 볼륨 vs 추가 볼륨: 부팅 디스크 vs 데이터 저장용 볼륨
- 부팅 디스크 역할! EC2가 시작될 때 OS를 로드하는 루트 볼륨
Ephemeral / Local Storage: Instance Store를 부르는 다른 이름들로, 빠르지만 인스턴스 종료 시 사라지는 스토리지
- 로컬 스토리지의 역할: 캐시, 임시 데이터, shuffle 데이터 등 빠른 I/O가 필요한 용도
NVMe: EBS와 Instance Store 모두에서 사용하는 스토리지 인터페이스 표준

또, 스토리지 용도를 잘 알고 사용하는 것

영구 저장이 필요한 데이터를 Instance Store에 두거나
반대로 빠른 I/O가 필요한 워크로드를 EBS에만 의존하거나
루트 볼륨과 데이터 볼륨의 역할을 명확히 나누지 않은 경우

[회고] 2025년 첫 커리어 1년간 한 일

sebinChu — Sun, 11 Jan 2026 14:52:34 +0900

개요

2025년 첫 커리어를 시작하고 SRE로서 회사에 기여한 일들을 정리해본다.

(그대로 옮기니까 가독성이 좀 떨어지긴 한데..ㅋㅋ 작업 관련 스레드 링크를 모두 붙였다가 이걸 이미지와 글로 풀어내려니까 어려운 점..)

1) 서비스 캐시 성능 향상 및 인프라 비용 절감을 위한 ElastiCache for Valkey 도입

| Problem

안정적인 서비스 운영과 성능/비용 최적화를 위해 Valkey로의 전환을 추진

| Task

사내 플랫폼 ElastiCache 기능 개발 및 출시
- 사내 플랫폼 API 개발
  - boto3 API 검토 및 기존 Redis 워크플로우 기반 Valkey 생성 기능 구현
  - Engine Version 조회 API 리팩토링: Redis 5.x/6.x 지원 중단, Valkey 7.2/8.x 버전 추가
  - Parameter Group 검증 로직 개선 (Redis ↔ Valkey 전환 시 engineType 버그 수정)
- 사내 플랫폼 UI 개발
  - ElastiCache 생성 화면에 Redis/Valkey 엔진 선택
  - 구버전(Redis 5.x, 6.x) 생성 제한 및 Valkey 버전 목록 확장
- 오픈 공지

Valkey 모니터링을 위해 redis exporter v1.74.0 업그레이드
마이그레이션 검증 및 클라이언트 호환성 테스트
- Redis → Valkey 전환 시, 우려사항과 성능 비교에 대한 글 작성 후 전사 발표를 통한 공유
  - 성능 비교 테스트: https://cobinding.tistory.com/309
프로젝트 완성도를 위한 외부 미팅 주도
- AWS ElastiCache Specialist와의 미팅을 통해 공식 가이드 및 베스트 프랙티스 검증
- 당근 내 ElastiCache를 적극적으로 사용하는 팀과의 미팅을 통해 실사용 사례 및 운영 노하우 공유(/w Lani)
관련 운영 지원
- 엔진 업데이트 주의사항 공유
- 사내 플랫폼 Redis 마이그레이션 작업
- Redis 관련 운영 질문 & 업데이트 고려사항 등

사내 개발자들에게 Redis 엔진 업데이트 안내 및 대응 / 마이그레이션 업무 진행

| Impact

ElastiCache Redis → Valkey 마이그레이션을 통해 Alpha 21.9%, Prod 20.2%의 전환율 달성. Valkey는 Redis 대비 20% 저렴하여, 현재 전체 ElastiCache 비용의 약 4% 절감 효과.
- feature-platform 전환 사례: 대략 일 $500, 월 $15,000 절감
Valkey 마이그레이션의 배경과 효과를 전사에 공유하고, 개발자 관점의 전환 가이드를 제공

오른쪽 가장 위에 오프라인으로 참석해서 발표한 영상..ㅎㅎ 우리 회사에서는 매주 전사적으로 기술적 이야기를 공유하는데 그 자리를 빌려 발키 소개했다. 보통은 온라인으로 참여하고 원하는 사람이나 발표자는 오프라인으로 참여한다.

2) 인프라 E2E 장애 모니터링 가시성 확보 1: CloudFront Additional Metrics

| Problem

CloudFront는 모든 트래픽이 통과하는 첫 진입점이지만, 해당 구간의 모니터링 부재

| Task

CloudFront 관련 모니터링 강화를 위한 Additional Metrics 활성화
Additional Metrics 예상 비용 확인 후 적용

관련 미팅 문서를 만들었고 팀 내에 공유

| Impact

지금까지 모니터링 되고있지 않은 영역들(Cache Hit, Origin Latency 등)에 대한 메트릭 확보 → 확보된 지표로 CloudFront 대시보드 제작 → CloudFront 모니터링 가시화
개발팀의 트래픽 확인 요청 해소

처음 PromQL & Grafana를 활용해서 작업하고, 개발팀에게 공유해본 경험

3) 인프라 E2E 장애 모니터링 가시성 확보 2: CloudFront Alert 시스템 구축

| Problem

CloudFront 레거시 자원 점검을 계기로 인프라 최앞단인 CloudFront 모니터링을 강화
Anomaly Request와 403 Error Rate 얼럿을 통해 트래픽 이상 감지 체계를 구축.
이후 false positive를 지속적으로 개선하며, 인프라 전반의 장애 대응 역량 강화를 목표로 진행중

| Task

Datadog False Alert 평가 및 정리

CF에 대한 Add Metrics을 활성화한 이후 Ddog 얼럿에 문제가 생겼고 이를 grafana alert rule로 풀어보는 작업으로 확장되었다.

(위 결과에 따른) Grafana Alert Rule 설계 및 구현
- Request Anomaly
  - Z-Score 기반 단기(3h)/장기(2주) 추세 반영 쿼리 직접 구현
  - 테스트 결과를 분석하며 단기 추세 계산을 24h → 8h → 3h로 최종 적용
    - 3h가 이상치 얼럿에 대한 최선의 판단이라고 결론
    - 장기 & 단기 추세 알고리즘 문서 (링크 첨부)
    - 트래픽 이상치 유효성 검증 결과 분석 문서 (링크 첨부)
  - Alert 계산 효율을 위해 특정 규모의 트래픽이 있는 Dist에 대해서만 수행하도록 하한선 설정
    - 하한선 측정 방법에 대한 문서: 위 알고리즘 문서와 동일

요렇게... PromQL로 알고리즘을 구현하고 그 얼럿 추이를 지켜본 뒤, 유효성을 검증했다. 지금은 Prod 환경에서 얼럿이 동작하고 있고, 계속해서 개선을 하다보니 쿼리가 많이 길어져서 레코딩룰로 전환하는 작업으로 이어졌다.

403 Error Rate
- DDoS, Origin 권한 문제 감지

지속적인 False Positive 개선 (/w Hun, Aidan)
- false positive 최소화를 위한 개선 작업
- Alert 가독성을 위한 메시지 포맷 개선 (project_name, Distribution ID 등 정보 추가)
- 특정 프로젝트 자원 예외처리 및 사이드이펙트 대응
- Alert Delivery 적용하여 서비스팀 전달 체계 구축
- HAProxy, big-picture 등 Edge Case 예외처리

| Impact

DDoS 감지

실제로 DDoS 감지에 활용되고 있고 Q보다 빠르게 잡은 성과가 있었다. DDoS 패턴이 다양해지고 있는데 여러 건 얼럿을 받아봐서 후속조치 등에 대한 고민을 하고있다.

프로모션 이벤트 감지
- 프로모션 이벤트가 생기면 사용자가 몰리는데, 이에 대한 이상치도 감지되고 있다.
전사 Traffic Anomaly Detection 활용 기대
- 지속적인 False Positive 개선을 통해 인프라 앞단(CloudFront)의 트래픽 이상 감지 체계 고도화
- 향후 다른 레이어(istio 등)의 Anomaly Detection에도 해당 알고리즘 적용을 통한 모니터링 기대

4) 멀티 리전 환경에서 EC2 SSM 접근 로깅·암호화 구조 표준화

| Problem

리전별로 EC2 접근 로깅 및 암호화 설정이 서로 달라서, 리전마다 보안 설정을 확인해야 하는 비용이 발생할 수 있는 구조
주요 인스턴스 서버에 대한 접근 이력이 일관된 기준으로 관리되고 있지 않음

| Task

문제 발견 및 작업 직접 제안
- EC2 기능 사내 플랫폼 오픈 준비 중 SSM KMS 설정과 세션 로그 S3 버킷이 KR 리전에만 존재하는 것 발견
- 모든 환경/리전별 SSM 로킹 & 암호화 설정 표준화 필요성 직접 제안

글로벌 리전 SSM 인프라 구축
- Alpha/Prod 환경의 글로벌 리전에 세션 로그 S3 버킷 생성
- 리전별 KMS Key 생성
- SSM Session에 대해 KMS 암호화 설정 적용

| Impact

SSM 접근 로깅과 암호화 설정을 적용 → 환경/리전 관계 없이 접근 기록과 암호화 적용 여부가 보장되도록 인프라 구조 표준화
세션 로그는 개인정보·인증 정보가 포함된 보안 핵심 로그이기에, 보안팀 일부 인원만 접근 가능하도록 설정
해당 작업을 통해 인프라 보안, SSM Logging 역량 강화

5) 전사 EC2 SSM 접근 관리를 위한 공용 IAM Policy 적용 및 인프라 표준화

| Problem

SSM 로깅·암호화 설정 후
- CA 리전 인스턴스(i-056...)에서 SSM 접속 불가 문제
- EKS 클러스터 노드 접근 불가 문제
- 프로덕션 worker Role 권한 문제

| Task

미적용 Role 추출 및 문서화
- 환경/리전별로 SSM 접근 Policy 미할당 Role 추출

공용 Policy 정의 및 일괄 적용
- - 공통 Policy 에 최소 권한 원칙 적용 (KMS, S3 PutObject 등)
    - Alpha/Prod 환경의 모든 리전 Instance 관련 Role에 스크립트로 일괄 적용
적용 검증
- 환경/리전별 haproxy 머신에 SSM 명령어로 접근 가능 여부 검증

| Impact

전사 인프라 모든 EC2 인스턴스에 일관된 SSM 접근 정책 적용 완료
신규 인스턴스 생성 시에도 동일한 Policy가 자동 적용되는 표준화된 구조 확보
인프라실 위클리 발표를 통해 네트워크팀, DB팀 등 SSM 사용 부서에 변경사항 공유

6) 플랫폼 기반 인프라 프로비저닝·운영 자동화: EC2 Instance 기능 도입

| Problem

(SRE) 인스턴스 타입, 스토리지, AMI, 보안 그룹, IAM Role 설정과 SSM 접근 방법을 매번 수동으로 처리
- 서버 스펙을 위한 커뮤니케이션 비용 증가
- 수동으로 설정하다보니 인프라 비표준화, 보안 유의사항을 누락하기 쉬운 구조
(개발팀) 테스트용 서버가 필요할 때마다 SRE 요청 후 대기해야 하므로 PoC 속도 저하 및 자율성 제한

| Task

Tech Spec

테크 스펙을 작성하고 논의했다.

EC2 Instance 서버 보안 강화를 위한 설정들 (w/보안팀)
- 모든 Instance에user-data Script를 통한 CrowdStrike 강제화
- 모든 Instance에 IMDSv2 설정 강제화
- Security Group Inbound 제한
- 보안상 최소 권한 부여를 위한 논의 스레드:
사내 플랫폼 EC2 생성·수정·삭제 작업

| Impact

Test용 서버를 플랫폼으로 쉽고 빠르게 생성
앞으로 생성되는 EC2 Instance는 CrowdStrike, IMDSv2, SSM 접근 등 보안 사항 준수 → 인프라 표준화

7) CloudFront SaaS Manager 도입

| Problem

FE 배포된 프론트엔드 사이트의 도메인 변경 건이 필요할 때마다 개발팀 → SRE 요청
- SRE는 사내 플랫폼 API를 통해 도메인/ACM 인증서를 직접 수정하고, 사내 플랫폼 DB 값도 별도로 수정해야 함
전사의 프론트엔드 배포 건수가 많아지면서 CloudFront, 서브도메인 관리 부담도 함께 증가

| Task

사내 플랫폼 API 구현 및 PoC 진행
- boto3 API로 multi-tenant 생성 기능 검증 및 테스트
개발팀 미팅 및 요구사항 협의
- 1차 (7/14): SaaS Manager 기능 소개 도입 가능성 논의
- 2차 (10/23): API 스펙 및 multi-tenant 구조 논의
- 결정 사항: FE 배포 전용 multi-tenant 1개 구성, 사내 플랫폼 즉시 도입은 보류 SRE팀 내부 검토 및 결정
구조 설계 재검토 및 선행 작업
- 초기 구조 설계가 복잡해 동료와 협업하여 워크플로우 재검토
- SaaS Manager 도입을 위한 선행 작업으로 사내 플랫폼 도메인 스코프 정리 진행
- 도메인 스코프 정리 완료 후 CF multi-tenant 사내 플랫폼 API 스펙 재정의

| Impact

사내 플랫폼 StaticWebsite 도메인 스코프 정리 및 개선 완료
PoC 기술 검토 완료, FE 배포 전체 방향성 논의로 확장

8) AWS 비용 이상치 탐지 시스템 구축을 통한 비용 관리

| Problem

MAU 2000만, 서비스가 점점 커지고 다양한 시도를 하면서 인프라 비용 꾸준히 증가
GCP는 비용 이상치 감지 시스템이 구축되어있지만, AWS는 수동 확인에 의존
- 이상 비용은 운영 이슈로 이어질 수 있고, 인프라 비용 관리 관점에서 중요도가 높음.

| Task

출시 공지(기능, 사용법, 실제 탐지 내용)

프로젝트 단계
- 중간 과정 및 의사결정에 대한 정리 문서 (문서 링크)
Slack 채널 자동 알림

| Impact

결과물: threshold=$1,000이 넘는 비용 이상치에 대한 모니터링
- 모니터링 과정을 거쳐 threshold 값 설정

예시 얼럿 유형:
- 예시1(MSK 스케일업)
- 예시2(prod---x 관련 DB 스케일업)
- 예시3(ppxx-platform $2,000 증가)
얼럿 유효성이 검증되어 개발팀 온콜 멘션 그룹 활성화 계획(2026 1분기)

9) StaticWebsite SLI 정의 및 사내 플랫폼 대시보드 구성

| Problem

StaticWebiste(R53, CloudFront, S3) 장애 감지 및 대응 체계 강화

| Task

CloudFront SLI 정의를 위한 아이데이션
CloudFront SLI Info, success_request 관련 작업
CloudFront 메트릭을 위한 레거시 Tag 제거 작업
R53 SLI 개선 작업
사내 플랫폼 SLI 가시화 작업
클라우드파트 SLI 문서 정리 작업

| Impact

사내 플랫폼 StaticWebsite 모니터링 가시화
R53 Exporter DNS Lookup 대상 추가
R53 Exporter 메트릭 수집 성능 개선

운영 업무

| 장애 대응

| Pay Oncall

SRE 클라우드 파트 Pay 업무 온콜 담당
- 목적: 온콜 운영 경험을 통한 Pay 업무 이해도 향상 및 파트 내 지식 공유
  - Pay 업무 사흘 간 느낀 점 회고
  - 온콜 일지

| Market Oncall

| 기타 운영

멀티 리전 Prod 환경의 KMS 삭제 및 비활성화 권한 Deny (/w Lu)
AWS GuardDuty 비용 증가 원인 파악을 위해 비용 모니터링 Budgets 설정
StaticWebsite 관련 도메인 변경

발표 및 공유

[25.03.07 | 인프라 위클리] 신규입사자가 느낀 개선점과 방향성 발표

[25.05.16 | 인프라 위클리] Kost Anomaly Detection 기능 소개

[25.07.18 | 인프라 위클리] CloudFront Saas Manager 기능 소개 및 협업 과정

[25.08.28 | Tech Allhands] Kontrol ElastiCache for Valkey 출시와 관련 내용

[25.12.05 | 인프라 위클리] Kontrol EC2 도입 과정 중 인프라 & 보안 개선점 소개

기타

[25.09.03] Builder's Camp 해커톤 시뮬레이션 참여

[DevOps] SSH 없이 안전하게 EC2 운영하기: SSM 기반 접근 제어와 전역 정책 설계

sebinChu — Sun, 7 Dec 2025 21:46:09 +0900

개요

서비스가 점점 커지면서 개발자의 다양한 PoC 니즈를 충족하기 위해, EC2 Instance Self-Service 기능을 준비했다. 프라이빗 환경에서 서버가 뜰 테지만, 아무래도 서버를 오픈하는 건 여러 위험성이 있기에 작업 전에 테크 스펙을 작성해서 여러가지 인프라/보안 이슈에 대해 검토했다. 그 중에서도 가장 레슨런이 많았던 Session Manager와 SSM Logging에 대해 정리해보려고 한다.

1. EC2 Instance 접근 방식

EC2 Instance에 접근하는 다양한 방식이 있다.

1.1 EC2 Instance Connect (문서)

브라우저 기반 SSH 연결 방식으로, AWS가 일시적인 SSH 퍼블릭 키를 자동 생성하여 60초간 인스턴스 메타데이터에 푸시한다. SSH Client와 다른 점은 직접 .pem과 같은 Key를 사용하는 것이 아니라, 사용자는 IAM Role을 통해 SSH에 접근 권한을 평가 받는다.

콘솔 연결 시, Public IP 주소가 필요
인바운드 22포트 허용 필요
`ec2-instance-connect:SendSSHPublicKey` 권한 필요
CLI 명령어로는 다음과 같이 접근 가능

aws ec2-instance-connect ssh --instance-id i-1234567890example

인스턴스 커넥트를 사용할 때는 endpoint가 필요한데..! 이거 작업 추기로 해보기

1.2 Session Manager (문서)

AWS SSM의 기능으로, SSH 키 없이 IAM 기반으로 인스턴스에 접근하는 방식이다. HTTPS(443) 프로토콜을 사용한다.

인바운드 22 포트 개방 X
Public IP 불필요
SSM Agent 설치 필수
IAM 역할 필수
CloudWatch, S3로 세션 로깅 가능

1.3 SSH Client (문서)

SSH 프로토콜을 사용해서 로컬 터미널에서 직접 인스턴스에 연결하는 방식이다.

키 페어 파일(.pem) 필수 -> 사용자가 키 직접 관리
인바운드 22 포트 필요
Public IP or Pirvate 경로 필요
로컬 SSH 클라이언트 사용(OpenSSH, PuTTY 등)

1.4 EC2 Serial Console (문서)

인스턴스의 직렬 포트(serial port)에 직접 접근하는 방식이다. 특이한 점은 네트워크 연결 없이 인스턴스 접근이 가능해서, 네트워크 장애 시 유용한 접근 방법으로 통한다.

계정 수준에서 명시적 활성화 필요
인스턴스당 1개의 동시 세션만 허용
인스턴스가 반드시 running 상태여야 함

항목	Instance Connect	⭐️ Session Manager	SSH Client	Serial Console
네트워크 필요	필수 (퍼블릭 IP)	필수 (Private 가능)	필수	불필요
키 관리	자동 (60초 임시)	불필요	수동 (.pem)	SSH 키 또는 패스워드
인바운드 포트	22 필요	불필요	22 필요	불필요
주 용도	간편 SSH 접속	대규모 관리	전통적 접속	부팅/네트워크 장애 해결
IAM 인증	O	O	X	O

2. Session Manager 적용과 그 이유

2.1 Session Manager가 필요한 이유

⚫️ 기존 SSH 접근 방식의 한계

기존 SSH 기반 EC2 접근 방식은 다음과 같은 문제점이 있다.

Private Subnet 환경에 있는 인스턴스에 접근하기 위해서는 따로 전용 서버 운영이 필요하다.
EC2 인스턴스마다 Key Pair 생성 및 안전한 보관이 필요하다. (만약 키가 노출된다면...! )
Key 사용을 위한 Inbound Port 22 오픈이 필요하다.
접속 로그나 실행 명령어를 추적할 방법이 부족하다.
해당 인스턴스 사용자가 증가할 수록 키/권한 관리가 복잡하다.

Inbound 22 Port 오픈이 왜 위험할까?

22번 포트를 여는 것은 외부에서 SSH로 해당 서버에 접속할 수 있도록 허용하는 것을 의미하기 때문이다.
SSH(Secure Shell) 서비스의 표준 포트로, IANA(Internet Assigned Numbers Authority)가 공식 할당한 포트 번호다.

⚫️ SSM Session Manager 이점

인바운드 포트를 열 필요가 없고, HTTPS(443) 프로토콜을 사용하여 추가 포트 개방이 불필요하다.
EC2 인스턴스의 Public IP 주소도 필요없다.
IAM 기반으로 조직 내에 어떤 구성원이 세션을 시작할 수 있는지, 어떤 노드에 접근할 수 있는지 제어가 가능하다.
CloudWatch Logs, S3 버킷을 통한 모든 세션 활동을 기록할 수 있다.

위와 같은 이유로 SSM Session Manager를 활용하여 Session 을 시작한 모든 ① 사내 유저 Id와 ② 해당 로그를 기록하도록 설정하였다.

2.2 Session Manager 동작 방식

먼저 Session Manager 동작 방식을 살펴보자.

유저가 SSM으로 인스턴스에 접근하기 위해 가장 처음하는 것이 StartSession API 호출이다.
- Session API를 호출하면, Session Manger가 Stream URL과 토큰을 return한다. 유저는 이 값으로 Session Manager에 Websocket 연결을 하고, Session Manager를 프록시로 사용하며 인스턴스와 소통한다.

{
   "SessionId": "string",
   "StreamUrl": "string",
   "TokenValue": "string"
}

EC2 Instance에 연결된 IAM Role을 통해 Session Manager와 통신하는 데 필요한 권한 & 세션 로깅 권한을 설정한다.
- SSM Agent가 인스턴스를 시작할 때, Instance Profile에 연결된 IAM Role을 assume한다. 이 권한으로 Session Manager 서비스에 아웃바운드 연결하고, WebSocket 채널을 유지할 수 있게 된다. (Instance Profile에 대한 글!)
- 세션 로깅이 활성화된 경우에는 버킷에 접근할 권한이 필요하다.
- 세션 데이터 암호화를 활성화했다면, 세션 데이터 암복호화 권한이 필요하다.

3. Session Manager를 통한 Session 로깅 & 모니터링 설정

3.1 AWS System Manager의 Session Manager 설정

System Manager는 계정・리전 단위로 설정된다. 필자가 속한 회사의 경우 Alpha, Prod 두 환경을 운영하고 있기에 각각의 계정과 KR, JP, CA, GB 리전에 대해 설정해주었다.

필자의 경우 General Preferences, S3 logging 부분을 활성화 해주었다.

⚫️ General Preferences

가장 첫 번째 옵션은 세션 데이터를 KMS 키로 암호화하는 것에 대한 설정이다. 이 설정을 하지 않으면 세션 데이터가 평문으로 전송/저장되어, 보안을 위해 활성화하였다.

사용자와 EC2 인스턴스 간 주고받는 모든 명령어와 출력이 암호화된다.
- SSM 접근 및 통신을 위해 KMS 암복호화 관련 권한이 추가로 요구된다.
S3에 저장되는 세션 로그가 암호화되어 저장된다.

⚫️ S3 Logging

SessionLog에 대한 정보를 볼 수 있다. 누가, 언제, 어떻게 접근하였고 어떤 명령어를 썼는지 모두 확인 가능하다.

해당 이미지가 그 예시다. Session Manager의 S3 Logging 활성화를 통해서 위와 같이 session을 시작한 사내 이메일과 접속 시각, 로그를 확인할 수 있다.

여기서 주의할 점은 이러한 Session 데이터를 남겨서 보안 이슈에 대응할 수 있지만, 그 반대로 Session 데이터가 노출되면 보안 위험에 처할 수 있다. 따라서 해당 버킷 접근 권한은 root 계정과 보안팀 일부 구성원들로 한정했다.

4. 마주한 문제

Session 암호화 & Logging을 전역 설정하다보니… 글로벌 리전에 대한 SSM 접근이 실패하는 현상을 겪었다.

4.1 트러블 슈팅을 위해 SSM으로 접근했는데 실패

4.2 HAProxy Ansible 실패

4.3 [해결법] SSM 접근을 위한 전역 공통 IAM Policy 정의 및 등록

AWS 여러 계정/리전을 함께 운영하면서 많이 헷갈려왔던 것인데..!

각 AWS System Manager는 각 리전/환경별로 설정되는 값이기 때문에 모든 환경/리전에 대한 관련 권한을 등록해야한다.

IAM Role의 경우 글로벌 서비스여서... SSM 접근을 위한 공용 Policy를 설정하였다.

1) ⭐️ 최소 권한만 갖도록 Policy 정책을 재정의

모든 인스턴스가 물고있는 Role에 부여할 Policy이므로, 보수적으로 접근하여 허용할 권한(JSON)을 작성하였다.

허용한 목록은 다음과 같다.

AmazonSSMManagedInstanceCore
KMSEncryptionForSessionManager
S3BucketAccessForSessionManager
S3EncryptionForSessionManager

2) 환경/리전별로 공용 Policy가 바인딩 되지 않은 Role을 추출 및 적용

SSM 접근이 필요한 인스턴스가 물고있는 Role에 대해서만 적용하였다.

기존 Policy에 부족한 권한을 추가하는 일이라 장애는 없을 테지만, Sciprt 대상 목록을 추출해서 공유

그리고 해당 목록을 공유하고, 공지 후에 작업 진행!

3) 접근 권한 부여 완료...!

5. 레슨런

이번 일을 하면서 인프라의 표준화와 정책의 중요성을 알게되었다. 하나의 작업을 할 때에, 다양한 관점에서 고민하고 일관된 정책을 적용해본 특별한 경험이었다. 옆의 팀원들이 정책을 잘 설계하는 것과 기술 부채를 고민하는 모습들을 종종 보았는데 왜 그러한 고민들을 하는지 온전히 이해할 수 있게 되었다.
특히 보안 관점에서는 기존의 나라면 SG이나 Inbound 정도 고민했었을 텐데, 다양한 보안 고려사항을 알 수 있게 되었다. AMI, CroudStrike, 접근 방식, 표준화된 인프라 등등...
그리고 SSM 동작 방식에 대해 깊이 있게 살펴본 점도 도움되었다. 원래는 그냥 SSM을 사용했다면 이제는 왜 SSH가 위험한지, SSM은 어떠한 문제가 있는지 고민할 수 있게 되었다.
- 그래서 좀 더 구체적으로 고민이 드는 것은 SSM 접근은 ssm-agent가 정상 상태일 때만 가능하기 때문에 대책/가이드 필요하다는 것이다. 요고는 조금 더 신경써서 공부하고 챙겨보려고 한다.
- (추가 작성) 당장 경험으로는 일단 4가지 접근 방식 중 4번이 간단하긴 한데, 너무 느린 점. 1번의 경우에는 커넥션을 위한 엔드포인트가 필요하다. 이것도 공용으로 미리 만들어 두는 게 좋을지..?

[BackEnd] 비동기 테스크 큐와 DI Container (feat. Celery)

sebinChu — Sun, 16 Nov 2025 21:17:05 +0900

개요

지금 학습 흐름이 아래와 같다.

IoC & DIP & DI
FrameWork의 DI Container로 여러 의존성 관리
싱글톤 패턴 & DI Container 직접 만들어서 사용하기

이 흐름에 따라서, 이번에는 DI Container를 직접 구현해서 사용할 때, 비동기 테스크 큐들이 어떤 이점을 누릴 수 있는지 살펴보자.

먼저 비동기 테스크 큐와 파이썬 생태계의 대표적 라이브러리인 Celery를 알아보고,
규모가 큰 분산 환경 프로젝트에서 Celery와 같은 비동기 테스크 큐를
DI Container에 등록하는 방법과 이점을 살펴볼 것이다.

1. 비동기 테스크 큐

1.1 비동기 테스크 큐란?

쉽게 말해서 지금 당장 처리하지 않아도 되는 일을, 나중에 따로 처리하게 만드는 시스템이다.

백엔드 서버는 보통 아래와 같은 구조다.

클라이언트가 HTTP 요청 보냄
서버가 요청 처리
응답 반환

⚫️ 그런데 어떤 작업들은...

오래 걸림 (예: 이미지 리사이즈, 영상 인코딩, 대용량 CSV 처리)
외부 API를 여러 번 호출 (결제 정산, 써드파티 연동)
꼭 실시간일 필요 없음 (알림 발송, 이메일 발송)

⚫️ 이들을 기존 구조로 처리하면 :

사용자는 쓸데없이 오래 기다림
웹 서버 스레드를 금방 소진해서 전체 서비스가 느려짐

=> 따라서 위와 같은 작업들은 큐에 넣어두고 나중에 따로 처리하게 한다!

1.2 동작 구조(아주 기본적인)

웹 서버(Producer)
- 사용자의 요청을 받음
- 해당 작업은 할일 목록(큐)에 넣어두고, 바로 응답을 돌려줌
큐(메시지 브로커)
- 할일 목록
- Redis, RabbitMQ, SQS 등
- 작업 하나하나가 메시지처럼 저장됨
워커(Consumer)
- 메시지 브로커 큐에서 할일을 하나씩 처리함

1.3 장점

오래 걸리는 작업은 워커 서버에 위임 하고, 사용자에게는 빠른 응답을 제공해서 서비스 품질을 높인다.
- ex. 메일 전송, 알림, 로그 등의 작업
요청 처리 시간이 큐에 넣는 시간 정도로 짧아진다.
트래픽이 많아질 때는 워커 수만 스케일 아웃하면 되므로, 적은 비용으로 많은 효과를 누릴 수 있다.

2. 파이썬 생태계의 작업 큐, Celery

Celery는 Python 언어로 작성된, 분산시스템에서 복잡한 작업들을 효과적으로 정의하고 처리할 수 있도록 도와주는 비동기 작업 큐 라이브러리다.

2.1 간단한 코드 예시

celery task 정의

from celery import Celery

app = Celery(
    "my_app",
    broker="redis://localhost:6379/0",        # 브로커 (예: Redis)
    backend="redis://localhost:6379/1",       # 결과 저장용 (옵션)
)

# celery 환경의 테스크임을 표현하는 데코레이터
@app.task
def resolve_domain(domain: str): 
	# dnspython으로 dns 조회 로직...
    # redis 저장... 
    return {"domain": domain, "ip": "1.2.3.4"}

HTTP API에서 활용

from fastapi import FastAPI
from app import resolve_domain

app = FastAPI()

@app.post("/lookup")
def lookup(domain: str):
	# 비동기로 테스크 큐에 넣기
    task = resolve_domain.delay(domain)
    return {"task_id": task.id}

결과적으로 `/lookup` 호출은 금방 응답하고, 실제 DNS 조회는 Celery 워커가 백그라운드에서 처리한다.

2.2 Celery 개념들

⚫️ Task

사용자가 비동기로 처리하려는 작업 그자체(메소드)다. 함수 단위로 정의되는 작업들을 Celery의 라이프사이클로 싣기 위해서 데코레이터 표현으로 정의할 수 있다.

from celery import Celery

app = Celery(__name__)

# celery 데코레이터 표현
@app.task
def simple_task():
	return hello

⚫️ Task Signature

`.apply()`, `.delay()` 등의 표현으로 메시지 브로커에 작업을 보내는 코드를 작성하게 되는데, 이러한 코드는 내부적으로 다음과 같은 처리 과정을 거친다.

`add.delay(1, 2)` 호출
내부에서 `add.s(1, 2)`같은 Signature 객체 만듦(또는 재사용)
그 시그니처를 기반으로 메시지를 직렬화(보통 JSON)해서
브로커에 발행
워커가 그 메시지를 가져와서 역직렬화 + 해당 함수 실행

=> Celery Signature 프로토콜에 맞게 작업 요청 메시지를 작성해서 브로커로 보내면, 이 언어가 무엇이든 Celery 워커가 받아서 작업을 처리할 수 있다.

⚫️ Kombu

Celery는 이벤트 메시지 포맷, 워커 로직에만 집중한다.

실제 브로커와의 통신은 kombu의 trasport 시스템이 맡아서, 다양한 브로커를 URL만 바꿔 끼우면 되는 수준으로 추상화 해준다.

kombu: 여러 브로커(RabbitMQ, Redis, SQS...)를 같은 방식으로 다룰 수 있게 해주는 플러그블 메시징 레이어

GitHub - celery/kombu: Messaging library for Python.

Messaging library for Python. Contribute to celery/kombu development by creating an account on GitHub.

github.com

⚫️ 작업 컨트롤

Rate Limiting: 워커가 특정 테스크를 수행하는 것에 대한 속도를 조절할 수 있다.
Schedular[ETA 방식, Countdown 방식]: 원하는 시간에 작업이 시작될 수 있도록 한다.
Retry: 작업이 실패하면 적절한 Backoff 메커니즘을 가지고 재시도를 수행한다.
Expiration: 오래 쌓여있던 작업들은 처리하지 않고 만료시킨다.
Task Routing: 작업들을 격리하거나 우선순위를 위한 큐를 정의하고, 작업들을 라우팅한다.
Canvas: Backend를 활용해 작업 결과들을 파이프라이닝해서 처리할 수 있는 메커니즘을 제공해 준다.

3. DI Container와 비동기 테스크 큐

지금 필자는 회사에서 클라우드 자원 관리 서비스에 기여하고 있는데, 비즈니스 특성 상 클라우드 자원 관리 작업이 복잡하고 오래 걸리는 경우가 많다. 그래서 클라우드 리소스들을 프로비저닝하는 작업은 Celery로 관리되는데... 이 예시로 해당 주제를 풀어보자.

3.1 웹 애플리케이션과 워커의 프로세스

FastAPI App과 Celery Worker가 처리하는 것은 완전 다른 별개의 프로세스다. Worker 프로세스는 FastAPI 프로세스의 메모리에 접근할 수 없으므로, 각자 초기화해야 한다. 하지만 프로젝트 전체를 관통하는 CoreDIContainer 클래스와 같은 설정을 사용해야 하므로 코드 레벨에서 통일성을 보장한다.

3.2 웹 App과 워커가 같은 설정을 사용해야 하는 이유

FastAPI는 사용자 요청을 받아서 "무엇을 할지" 기록하고, Celery Worker는 실제로 클라우드에서 "그 작업을 수행"한다.

예를 들어, 사용자가 "alpha 환경에 S3 버킷을 만들어주세요"라고 요청하면, FastAPI는 이 요청을 DB에 기록한다. 그 후 Celery Worker가 이 기록을 보고 AWS에 실제 버킷을 생성한다.

그런데 이때, 애플리케이션과 Celery Worker의 설정이 다르면 DB에는 Alpha 환경에 버킷 생성이라고 되어있지만, 실제로는 Prod 환경에 버킷이 만들어진다. 시스템이 알고있는 정보와 클라우드 상태가 달라지는 것이다. 비용 청구도 잘못되고, 보안 문제도 발생할 수 있다.

따라서 FastAPI와 Celery Worker가 다른 프로세스에서 실행되더라도, 반드시 같은 Settings를 기반으로 DIContainer를 초기화해야 한다. 같은 AWS 계정에 접근하고, 같은 DB를 사용하며, 같은 환경 정책을 적용해야 전체 시스템이 일관되게 동작한다.

1) Broker Mode일 때의 DI Container 주입: 초기화 클래스 정의

프로젝트가 실행될 때, 가장 먼저 공용 커스텀 DI Container를 초기화하고, 이 객체가 Celery App 생성에 사용되도록 전달한다.

@asynccontextmanager
async def lifespan(app: FastAPI):
    core = KrpCore(app.state.settings)                        # 1. DI Container 초기화
    celery = create_celery_app(app.state.settings, core=core) # 2. Celery에 core 전달
    core.load_services(celery)                      # 3. 서비스들 초기화
    app.state.core = core                           # 4. FastAPI state에 저장
    yield

이 구조에 따라서 Celery로 처리되는 프로비저닝 작업들은 AWS Client Map이나 DB 세션 메이커 등 필요한 의존성 항목들이 기대한 대로 준비된다.

class LoadKrpCoreStep(bootsteps.StartStopStep):
    """Celery Worker가 시작될 때 공용 DI Container를 초기화 한다.

    - 공용 컨테이너 초기화,
    - celery app state에 KrpCore(공용 컨테이너) 셋업
    - Fast API 구동과 동일한 접근성을 보장하기 위함.
      - fastapi.state.aws
    """

    requires = {"celery.worker.components:Pool"}

    def create(self, parent, **kwargs):
        logger.info("Prepare KrpCore")
        app.state.core = KrpCore(settings)

2) Eager Mode에서의 DI Container 주입: 초기화

Eager 모드에서는 Worker 프로세스가 없으므로, Worker에서처럼 공용 컨테이너 초기화 로직이 실행되지 않는다. 따라서 FastAPI가 전달한 core를 통해 의존성을 처리하게 된다.

프로젝트가 실행될 때, 가장 먼저 공용 커스텀 DI Container를 초기화하고, 이 객체가 Celery App 생성에 사용되도록 전달한다.

@asynccontextmanager
async def lifespan(app: FastAPI):
    core = KrpCore(app.state.settings)                        # 1. DI Container 초기화
    celery = create_celery_app(app.state.settings, core=core) # 2. Celery에 core 전달
    core.load_services(celery)                      # 3. 서비스들 초기화
    app.state.core = core                           # 4. FastAPI state에 저장
    yield

Celery App을 초기화할 때, 전달받은 공용 DI Container 객체를 사용한다.
- Worker 프로세스들이 FastAPI App과 동일한 접근성을 보장하기 위함이다.

def create_app(settings: KrpSettings, core: KrpCore | None = None):
    app = Celery()
    app.state = State()
    app.state.core = core  # FastAPI가 준 core를 celery.state에 저장!

이렇게 비동기 큐와 인프라 리소스 프로비저닝 & 비동기 큐 활용 및 프로젝트 관리법을 알아보았다..! 하나하나 따라가느라 시간도 많이 오래걸리고 어려웠지만 앞으로 작업에 많은 도움이 될 학습이었다.

[BackEnd] 싱글톤 패턴 & DI Container 직접 만들어서 사용하기

sebinChu — Sun, 9 Nov 2025 17:12:38 +0900

개요

IoC, DI, DIP 알아보기
DI Container 구현하고 Framework 이해하기

^ 위 글에 이어 DI Container를 직접 구현해서 여러 객체 간의 의존성을 관리하는 것에 대해 더 깊이 이해해보고자 한다. 요즘 가장 많이 쓰는 프레임워크가 FastAPI이기에, 글도 이를 중점적으로 작성해 나갈 것이다.

1. Framework가 여러 의존성을 관리하는 방법 : Depends

FastAPI의 의존성 주입은 함수 시그니처를 통한 선언적 의존성 관리와 Depends()가 핵심이다. Depends()는 한마디로 쉽게 "이 함수를 실행해서 결과를 여기에 넣어줘"라고 프레임워크에게 알려주는 도구다.

이 Dependency Injection의 핵심 기능인 Depends()를 사용하지 않고 의존 관계를 구현했을 때의 현상은 이 글에 작성이 되어있으니 참고

1.1 Depends()의 동작으로 이해해보는 의존성 관리

from fastapi import Depends, FastAPI

# 의존성 함수
def get_database():
	db = Database()
    try:
    	yield db
    finally:
    	db.close()

# API Endpoint에서 사용
@app.get("/items/")
def get_items(db = Depends(get_database)):
	return db.query("SELECT * FROM items")

위 코드를 실행하면 다음 과정이 실행된다.

API 실행 전에 FastAPI가 Depends()를 스캔한다.
get_database 함수를 의존성으로 등록한다.
내부적으로 get_database 함수를 호출하고 Database() 객체를 반환해서 엔드포인트에 주입한다.

  # FastAPI가 자동으로 처리:
  get_items(db=db)  # yield된 db 객체를 파라미터로 전달

마지막으로 API 응답 생성 후, 프레임워크가 db.close() 등의 정리 작업을 실행하고, 200 OK와 같은 응답을 반환한다.

2.2 Depends()만 사용할 때의 문제

이러한 의존성 주입은 대규모 애플리케이션에서 몇 가지 한계가 있다.

⚫️ 무거운 객체의 반복 생성

def get_aws_client(settings = Depends(get_settings)):
    # boto3 클라이언트는 생성
    return boto3.client('s3', region_name=settings.aws_region)

@app.get("/buckets")
def list_buckets(aws = Depends(get_aws_client)):
    return aws.list_buckets()

@app.post("/buckets")
def create_bucket(aws = Depends(get_aws_client)):
    return aws.create_bucket(...)

get_aws_client 메소드의 활용, 생명주기 관리는 Depends를 통해 프레임워크가 도맡아서 할 수 있지만
- 요청마다 관련 클라이언트 새로 생성(boto3 클라이언트는 생성 비용이 큼)
- 연결 풀을 효과적으로 사용할 수 없음
- 초기화 비용이 큰 객체일 수록 성능 저하

* 참고로 Depends()의 캐싱은 "같은 요청 내"에서만 동작한다. 다음 요청이 오면 다시 생성된다.
FastAPI의 use_cache(request-scoped cache): 같은 요청 안에서 dependenc가 여러 번 선언되면, 캐싱된 내용을 사용한다.

⚫️ API Parameter 복잡도

@app.post("/resources")
def create_resource(
    aws_client = Depends(get_aws_client),
    db = Depends(get_db),
    redis = Depends(get_redis),
    slack = Depends(get_slack),
    prometheus = Depends(get_prometheus),
    katalog = Depends(get_katalog),
    # ... 
):
    pass

가독성 저하
테스트 시 모든 파라미터를 Mock으로 준비해야 함
새로운 의존성 추가 시 모든 엔드포인트 수정

2. DI Container의 등장 배경 : 싱글톤 패턴

2.1 싱글톤 패턴 등장 배경

Depends()와 같은 프레임워크가 제공하는 DI를 사용하면 많은 이점이 있지만, 애플리케이션 규모가 커질 수록 불편함 또한 생긴다. 클라이언트가 요청을 보낼 때마다 새로운 객체를 만들어서 반환한다. 가령 고객의 트래픽이 초당 100만큼 발생하면 초당 100개의 객체가 생성 - 소멸 과정을 겪는다.

⚫️ 무거운 초기화를 매 요청마다 수행하면

응답시간 증가
리소스 낭비: CPU, 메모리, 네트워크 연결 반복 생성
외부 서비스 부하: AWS API, Redis 서버에 불필요한 연결 요청

⚫️ 문제 사례

AWS Client Boto3 세션 생성, credential 로딩, region별 endpoint 연결
Redis TCP 연결 생성, 인증, connection pool 초기화
DB 커넥션 풀 생성, 스키마 메타데이터 로딩

2.2 싱글톤 패턴으로 해결

이를 해결하기 위해서 객체를 하나만 만들어놓고, 클라이언트가 동일한 객체를 요청하면 이 객체를 반환해서, 모든 클라이언트(요청)가 하나의 객체를 공유하게끔한다. 이것이 바로 싱글톤 패턴이다.

  # 1. 앱 시작 시 한 번만 생성 (lifespan)
  @asynccontextmanager
  async def lifespan(app: FastAPI):
      core = KrpCore(settings)  # 딱 한 번만 실행
      app.state.core = core      # 앱 전역에 저장
      yield

  # 2. Depends로 접근 (매번 실행되지만 같은 객체 반환)
  def with_krp_core(request: Request) -> KrpCore:
      return request.app.state.core  # 저장된 싱글톤 반환

  # 3. 엔드포인트에서 사용
  @app.get("/s3")
  def list_s3(core: KrpCore = Depends(with_krp_core)):
      ...

주로 클라우드 서비스를 셀프 서비스하는 프로젝트를 운영/개발하는 우리 팀에서는 AWS Client, Redis, GCP Client와 같이, 여러 객체에서 반복 사용되며 무거운 초기화를 가진 클라이언트들에 대해 앱 시작 시 초기화한다.

3. Framework가 제공하는 DI Cotainer

3.1 FastAPI

FastAPI는 DI Container 객체를 노출하진 않지만, Depends + 내부 dependency resolver가 사실상 DI Container의 역할을 한다. 이는 FastAPI Dependency Injection 문서에 잘 나와있는데, 핵심을 정리하면 다음과 같다.

별도의 컨테이너 객체를 직접 다루지 않더라도 대부분의 웹 애플리케이션에서 충분히 쓸 수 있는 의존성 주입 기능을 제공한다.
- 함수 시그니처에 의존성을 선언하면
- 프레임워크가 의존성 그래프를 만들고
- 요청 단위로 생성/캐싱/정리까지 자동으로 처리

3.2 Spring IoC Container & Bean

Spring DI Cotainer는 FastAPI와 다르게 Spring IoC Container가 직접 Bean 객체를 관리하며 IoC를 제공한다. 이또한 Spring IoC & Bean 문서에 잘 나와있다!

`org.springframework.context.ApplicationContext` 인터페이스가 Spring IoC 컨테이너를 대표하며, 컨테이너는 애플리케이션에서 사용할 bean들을 인스턴스화, 설정, 조립하는 책임을 가진다. (문서 바로가기)
IoC 컨테이너는 XML, 애너테이션, Java 코드 같은 configuration metadata를 읽어서 “어떤 객체를 생성·구성·연결할지”에 대한 지시를 받고, 그에 따라 빈과 빈 사이의 의존성을 설정한다. (문서 바로가기)

@Configuration
class AppConfig {

    @Bean
    AwsClient awsClient(AppSettings settings) {
        return new AwsClient(settings.getRegion());
    }

    @Bean
    UserService userService(AwsClient awsClient) {
        return new UserService(awsClient);
    }
}

public class Main {
    public static void main(String[] args) {
        ApplicationContext ctx =
            new AnnotationConfigApplicationContext(AppConfig.class);

        UserService userService = ctx.getBean(UserService.class);
        userService.process();
    }
}

-> 이건 커스텀 컨테이너를 설정했다기 보다 Spring이 제공하는 DI 컨테이너(ApplicationContext)에 빈 설정을 등록해서 쓰는 것

4. Custom DI Container

앞에서 살펴본 것처럼, 무거운 클라이언트(Boto3, Redis, DB 커넥션 풀 등)를 요청마다 새로 만드는 문제는 FastAPI의 `Depends`만으로 해결하기 어렵다. 그래서 lifespan과 `app.state`를 이용해 애플리케이션 시작 시점에 한 번만 생성하는 싱글톤 패턴을 도입해 성능 문제는 어느 정도 해결할 수 있었다.

하지만 애플리케이션 규모가 더 커지면, 단순히 “전역 싱글톤 몇 개”만 두는 방식으로는 다음과 같은 설계상의 문제가 남는다.

모든 의존성을 직접 주입하면 API 엔드포인트 파라미터 목록이 길어지고, 핵심 도메인 로직이 의존성 목록에 묻힌다.
서비스 간 의존 관계가 엔드포인트/의존성 함수 곳곳에 흩어져 있어서, 시스템 전체 의존성 그래프 파악이 어렵다.
도메인 서비스가 FastAPI의 `Depends`에 직접 의존하게 되어, HTTP 이외의 진입점(배치, Celery, CLI, 테스트 등)에서 재사용하기가 불편하다.

4.1 프레임워크 DI와 전역 싱글톤만으로는 부족한 의존성 관리를 커스텀화해서 해결!

이러한 설계상의 문제를 해결하기 위해, 우리 팀에서는 애플리케이션 전용 DI 컨테이너인 `KrpCore`를 두고 있다.

⚫️ Custom DI Container 정의하기

애플리케이션 공통 클라이언트 초기화

class KrpCore:
    """KRP 애플리케이션의 의존성 컨테이너"""

    def __init__(self, settings: KrpSettings):
        self._settings = settings
        self._aws_client_map = load_aws_client_map(settings)
        self._gcp_client_map = load_gcp_client_map(settings)
        self._prometheus_client = PrometheusClient(
            api_url=settings.prometheus_api_url,
            api_token=settings.prometheus_api_token,
        )
 
@property
	def aws_client_map(self) -> AwsEnvironmentRegionClientMap: ...
    
@property
	def sessionmaker(self): ...

⚫️ 공용 컨테이너는 앱 시작 시 한 번만 만들고, 이후 Depends로 사용

app = FastAPI(lifespan=lifespan)

@asynccontextmanager
async def lifespan(app: FastAPI):
    core = KrpCore(settings)       # 앱 시작 시 한 번만 생성
    core.load_services(celery)     # 서비스들도 한 번만 초기화
    app.state.core = core          # 전역 싱글톤처럼 보관
    yield                          # 앱 종료 시 정리 로직 실행 가능

def get_core(request: Request) -> KrpCore:
    return request.app.state.core  # 항상 같은 core 인스턴스 반환

@app.post("/s3")
def create_s3(
    payload: s3Create,
    core: KrpCore = Depends(get_core),
):
    service = core.services["s3"]
	...

4.2 프레임워크 제공 DI Container 사용 VS 커스텀 장단점

좀 길지만 중요한 내용..!

관점	프레임워크 제공 DI	커스텀 DI Container
학습 비용 / 생산성	이미 프레임워크와 깊게 통합되어 있어서 팀원이 문서만 보고 바로 쓰기 쉽다.	컨테이너 개념, 등록/해결 규칙, 라이프사이클 정책 등 팀이 새로 익혀야 할 추상화가 하나 더 생긴다. 초기 설계와 가이드 정리가 필요하다.
성능 / 라이프사이클	기본이 요청 스코프(request-scoped)라 요청마다 새 인스턴스를 만들기 쉽고, 싱글톤/글로벌 스코프는 별도 패턴(lifespan, app.state 등)을 직접 도입해야 한다.	Boto3, Redis, DB 커넥션 풀 등 무거운 객체를 컨테이너 내부에서 명시적으로 singleton처럼 관리해 여러 요청에서 재사용하기 쉽다. 라이프사이클 정책을 컨테이너 기준으로 설계 가능.
엔드포인트 시그니처 / 가독성	Depends를 많이 쓰면 엔드포인트 파라미터가 길어지고, 도메인 로직보다 “의존성 목록”이 먼저 보일 수 있다.	엔드포인트는 core: KrpCore나 UserService 같은 “굵은 서비스 단위”만 받도록 정리할 수 있어서, 시그니처가 더 단순해지고 도메인에 집중하기 쉽다.
의존 관계 가시성	의존성이 각 엔드포인트/의존 함수에 흩어져 있어서, 전체 시스템의 의존성 그래프를 한눈에 보기 어렵다.	컨테이너 초기화/등록 코드(KrpCore, load_services 등)에 의존 관계가 모이므로, “어떤 서비스가 무엇에 의존하는지”를 한 곳에서 파악하기 좋다.
테스트 / 의존성 교체	FastAPI의 dependency_overrides 등으로 일부 의존성을 쉽게 바꿀 수 있지만, 깊고 복잡한 서비스 그래프를 통째로 갈아끼우기에는 다소 불편할 수 있다.	컨테이너에 등록된 구현만 바꾸면(Fake 서비스, In-memory Repo 등) 테스트 환경 전체 의존성을 한 번에 바꿀 수 있다. 특정 토큰 이름(예: "s3", "redis")만 기준으로 교체 가능.
프레임워크 독립성 / 재사용성	서비스/로직이 프레임워크의 DI 메커니즘(Depends, 애너테이션 등)에 더 밀접하게 묶이기 쉽다. HTTP 이외 진입점에서 재사용하려면 별도 어댑터가 필요할 때가 많다.	컨테이너를 중심으로 의존성을 주입하면, 서비스는 “컨테이너에서 주어지는 것”만 의존한다. 같은 서비스 코드를 Celery, 배치, CLI, 테스트 등 다양한 환경에서 재사용하기 쉽다.
복잡도 / 운영 비용	“프레임워크가 해주는 대로” 쓰면 되기 때문에 구조가 단순하고 디버깅 포인트도 비교적 적다. 대신 프로젝트가 커질수록 점진적으로 난잡해질 수 있다.	설계가 잘 되면 구조가 정돈되지만, 컨테이너가 또 하나의 인프라 코드가 되어 관리 포인트가 늘어난다. 설계가 어설프면 “의존성이 어디서 만들어지는지 더 헷갈리는” 역효과도 가능.

[BackEnd] Framework 이해하기 - DI Container로 여러 의존성 관리

sebinChu — Mon, 3 Nov 2025 10:47:39 +0900

개요

이전 글에서 IoC, DI, DIP를 알아보았다. 이제 여기서 확장해서 DI Container와 생명 주기 관리, Web Framework의 원리를 알아보자.

1. Framework

프레임워크 본질 중 하나가 IoC다. 일반적으로는 개발자가 직접 코드 흐름을 제어하지만, 프레임워크는 이 흐름을 뒤집는다. (제어의 역전)

프레임워크가 애플리케이션 코드를 호출 및 흐름을 제어하고, 개발자는 의존 관계만 정의하는 방식이다.

framework라고 하면 DI 패턴을 통해서 여러 자원을 관리할 수 있는데, 이게 바로 IoC를 실현하는 구체적인 방법이다.

FastAPI: 함수 인자에 Depends()를 명시한다. FastAPI가 호출 시점에 자동으로 의존성을 주입한다.
Spring: @Component, @Service, @Repository Spring IoC 컨테이너가 의존를 생성하고 주입한다.

2. DI Container로 의존성 관리하기

2.1 DI Container가 없는 상황 (문제 코드)

# DI Container가 없는 상황
from abc import ABC, abstractmethod

class Teacher:
    def __init__(self, name: str):
        self.name = name
    
    def teach(self):
        return f"{self.name} 선생님이 수업합니다."

class Student:
    def __init__(self, name: str):
        self.name = name
    
    def study(self):
        return f"{self.name} 학생이 공부 중이에요."

class ClassRoom:
    def __init__(self, teacher: Teacher, student: Student):
        self.teacher = teacher
        self.student = student

    def conduct_session(self):
        print("== 수업 시작 ==")
        print(self.teacher.teach())
        print(self.student.study())
        print("== 수업 끝 ==")

if __name__ == "__main__":
    # file: classroom.py
    teacher1 = Teacher("김선생")
    student1 = Student("cobinding")
    classroom1 = ClassRoom(teacher1, student1)
    classroom1.conduct_session()

    # file: exam.py
    teacher2 = Teacher("이선생")
    student2 = Student("cobinding") # 다른 객체를 또 생성하게 됨
    classroom2 = ClassRoom(teacher2, student2)
    classroom2.conduct_session()

2.2 실제 웹 프레임 워크 상황에 빗대면...

# 실제 웹 프레임 워크 상황이 되면...
@app.get(f"/class/{student_id}")
def start_class(student_id: int):
    # 각 api 경로에서 아래와 같은 객체들을 매번 생성해야 함.
    db = Database("localhost:5432")
    cache = Redis("localhost:6379")
    logger = Logger("app.log")

    teacher = Teacher("김선생")
    student = db.get_student(student_id)
    classroom = ClassRoom(teacher, student)
    result = classroom.conduct_session()

    db.close()

    return result

모든 API에서 db, redis, logger 등 필요한 코드를 반복하게 되어, 어떤 비즈니스 로직이 담겨있는지 보다 무엇을 만들어야 하는지에 대한 코드가 대부분이 된다.
객체의 생성/소멸 라이프사이클을 개발자가 직접 제어하게 된다.
테스트 시에도 진짜 DB/Redis 인스턴스가 계속 만들어진다.
ClassRoom은 구체 클래스(Teacher, Student)에 직접 의존하게 된다. (DIP 실패)
의존성이 늘수록 생성 코드가 폭발..

웹 프레임워크가 없다면 이러한 어려움을 겪게 된다.

위 문제를 한번 DI Container를 생성하고 웹 프레임워크의 핵심 메커니즘을 이해해보자!

3. DIContainer로 여러 의존성 관리

3.1 DIContainer 구현

의존성 주입 컨테이너를 만들어서 위 문제를 해결해보자.

앞선 코드에는 다음과 같은 한계가 있다.

Student("cobinding")을 여러 번 생성하는 문제
여러 파일/모듈 간에 동일 객체를 공유하기 어려운 구조
전역 변수를 사용하지 않고는 의존성을 중앙에서 관리하기 어려움

이번에는 DI(Dependency Injection) Container를 직접 구현해보며, FastAPI의 Depends()와 같은 프레임워크가 내부적으로 어떻게 의존성을 주입하는지 이해해보자. 이를 통해 웹 프레임워크가 의존성을 생성/관리/주입하는 원리를 간단한 예제로 살펴본다.

"""
DI Container: 의존성 주입 컨테이너

main.py의 문제 해결:
1. Student("cobinding")을 여러 번 생성하는 문제
2. 여러 파일/모듈에서 같은 객체 공유 어려움
3. 전역 변수 없이 중앙에서 관리

"""

class CoreDIContainer:
    """ 의존성 주입 컨테이너 """

    def __init__(self):
        self._services = {} # 싱글톤 객체 저장소

    def register(self, name: str, instance):
        self._services[name] = instance
        print(f" `{name} 등록됨. ID: {id(instance)}")

    def get(self, name: str):
        """ 의존성 가져오기 """
        if name not in self._services:
            raise ValueError(f"{name}이 등록되어 있지 않습니다.")
        return self._services[name]
    
    def has(self, name: str) -> bool:
        """ 의존성 존재 여부 확인 """
        return name in self._services                                                       

    def clear(self):
        """ 모든 의존성 제거 """
        self._services.clear()
        print("모든 의존성 제거 완료")

3.2 DIContainer 사용 예제

이를 실제로 사용하는 구현은 다음과 같다. 이전 코드에서 발생했던 문제를 DI Container를 통해 어떻게 해결할 수 있는지가 담겨있다.

if __name__ == "__main__":
    from main import Teacher, Student, ClassRoom

    print(" == DI Container 사용 예시 == ")

    # 1. 컨테이너 생성
    container = CoreDIContainer()

    # 2. 의존성 등록 (한번만)
    container.register("teacher_kim", Teacher("김선생"))
    container.register("teacher_lee", Teacher("이선생"))
    container.register("student_co", Student("cobinding"))

    # 3. file: classroom.py
    print("[classroom.py] 첫 번째 수업")
    teacher = container.get("teacher_kim")
    student = container.get("student_co")
    print(f"student ID: {id(student)}")

    classroom1 = ClassRoom(teacher, student)
    classroom1.conduct_session()

    # 4. file: exam.py => 같은 객체 재사용
    print("[exam.py] 두 번째 시험")
    teacher = container.get("teacher_lee")
    student = container.get("student_co") 
    print(f"student ID: {id(student)}")

    classroom2 = ClassRoom(teacher, student)
    classroom2.conduct_session()

    print()

1. 컨테이너 생성
CoreDIContainer()를 한 번만 생성한다. 이 컨테이너는 모든 의존성을 중앙에서 관리하는 저장소 역할을 한다.

2. 의존성 등록
Teacher, Student 같은 객체를 register() 메서드로 한 번만 등록한다.
이 단계에서 객체는 “싱글톤처럼” 관리되며, 이후 어디서든 동일한 인스턴스를 꺼내 쓸 수 있다.

3. classroom.py 실행
container.get("teacher_kim")과 container.get("student_co")를 호출해 필요한 의존성을 주입받는다.
직접 Teacher()나 Student()를 생성하지 않아도 되고, 객체의 생성 위치가 코드 전역에 흩어지지 않는다.

4. exam.py 실행
같은 방식으로 container.get()을 호출하면 동일한 객체 인스턴스가 재사용된다.
출력된 student ID가 동일한 값으로 찍히는 것을 보면,
“Student("cobinding")이 여러 번 생성되는 문제”가 해결된 것을 확인할 수 있다.

알게된 점

그동안은 웹 프레임워크를 사용할 때 내부 동작보다는 제공되는 편의성에만 의존해왔다. 하지만 이번에 DI Container와 IoC 원리를 직접 구현해보며, 프레임워크가 어떻게 의존성을 관리하고 주입하는지를 구체적으로 이해할 수 있었다. 회사에서 자주 보는 프로젝트에서도 KRPCore라는 중앙 의존성 컨테이너가 있는데, 이제는 왜 그렇게 설계했는지, 어떤 장점을 가지는지 명확히 이해할 수 있게 되었다! FastAPI Depends()의 원리나 내부 구조, 프레임워크의 장단점 같은 걸 더 공부해봐야겠다고 생각들었다.

[BackEnd] IoC & DIP & DI

sebinChu — Mon, 20 Oct 2025 10:42:29 +0900

개요

Inversion of Control, Dependency Inversion Principle, Dependency Injection에 대해 학습한다.
DIP를 위해 → IoC 개념으로 → DI를 사용하는 큰 흐름을 가지고 각 내용을 살펴본다.

1. IoC (Inversion of Control) : 제어(관리)의 역전

프로그램의 제어 흐름을 개발자가 아닌 프레임워크/컨테이너가 담당하는 설계 원칙이다.

1.1 제어(관리)의 두 가지 의미

객체 생명 주기 제어(생성, 소멸)
프로그램 실행 흐름 제어(언제, 어떤 순서로)

1.2 전통적 방식 vs IoC

IoC 적용 전

class Teacher:
	def teach(self): 
		student = Student() # 내가 직접 생성
		result = student.study() # 내가 직접 호출
		return result

# main에서 내가 모든 걸 제어함
def main():
	teacher = Teacher() # 내가 생성
	result = teacher.teach() # 내가 호출

IoC 적용 후

class Learner(ABC):
	@abstractmethod
	def study(self) -> str:
		pass

class Student(Learner):
	def study(self) -> str:
		return "학생이 공부 중이에요."
		
class CollegeStudent(Learner):
	def study(self) -> str:
		return "대학생이 공부 중이에요."
		
class Teacher:
	# DI로 구현하는 것이 가장 일반적이다.
	def __init__(self, learner: Learner):
		self.learner = learner # 외부에서 생성 받아옴 => 제어권 역전
	
	def teach(self):
		return self.learner.study()

# main, continer의 제어
def main():
    # 외부에서 제어 (IoC, DI)
    student = Student()
    teacher1 = Teacher(student)  # DI

    college = CollegeStudent()
    teacher2 = Teacher(college)  # DI

    print(teacher1.teach())  # 학생이 공부 중이에요.
    print(teacher2.teach())  # 대학생이 공부 중이에요.

Teacher는 교육 로직에만 집중한다. (SRP 준수)
- SRP(Single Responsibility Principle) : 단일 책임 원칙
- 한 클래스는 오직 하나의 책임(역할)만 가져야한다.
외부에서 다른 Student를 Teacher에 주입 가능하다.

2. DIP(Dependency Inversion Principle)

DIP는 IoC 철학을 “무엇에 의존할 것인가”로 구체화한 설계 원칙이다.

'상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야한다. 추상화는 세부 사항에 의존해서는 안된다.’

구체적인 것이 아니라 추상적인 것에 의존한다. 의존 방향이 상위 → 추상 ← 하위 로 둘다 추상에 의존한다.

2.1 DIP 적용 전후 의존 관계

# DIP 적용 전
Teacher --> Student (고수준 모듈이 저수준 모듈(구체 class)에 바로 의존)

# DIP 적용 후
Teacher --> Learner <-- Student
            (추상화)      (하위 구체 클래스)
            ^ 의존 방향 역전

Teacher : 고수준 모듈 (비즈니스 로직)
Learner : 추상화 (인터페이스/추상 클래스)
Student : 저수준 모듈 (구체적 구현) </aside>

from abc import ABC, abstractmethod

# 1. 추상화 정의
class Learner(ABC):  # 추상 클래스 (인터페이스)
    @abstractmethod
    def study(self) -> str:
        """공부하는 행위"""
        pass

# 2. 구체 클래스들이 추상화를 구현
class Student(Learner):
    def study(self) -> str:
        return "학생이 공부 중이에요."

class CollegeStudent(Learner):
    def study(self) -> str:
        return "대학생이 공부 중이에요."

## 새로운 학습자를 추가하더라도 ... Learner를 상속 받는 구체 클래스만 추가하면 됨

# 3. Teacher는 추상화에 의존 : Learner 인터페이스만 알고, 구체 구현은 몰라도 됨
class Teacher:
    def __init__(self, learner: Learner):  # 추상 클래스에 의존해야함! (DI)
        self.learner = learner

    def teach(self) -> str:
        return self.learner.study()

# 4. 사용 (DI + DIP)
if __name__ == "__main__":
    # 이제 모든 Learner 구현체 사용 가능!
    student = Student()
    college = CollegeStudent()

    teacher1 = Teacher(student)
    teacher2 = Teacher(college)
    
    print(teacher1.teach())  # 학생이 공부 중이에요.
    print(teacher2.teach())  # 대학생이 공부 중이에요.

2.2 왜 “역전(Inversion)”인가?

전통적 의존 방향
- Applicatiion Layer → Business Logic → DB Layer
DIP 적용 후
- Application Layer → Interface ← DB Impl

3. Dependency Injection

DI는 런타임 시점의 의존 관계 결정을 코드 외부로 위임함으로써, 컴파일 타임 의존성과 런타임 의존성을 분리하는 설계 기법이다.

: 컴파일 단계에서는 소스 코드 자체(타입/인터페이스)만 확인하고, 런타임에 실제로 어떤 구체 객체를 사용할지 동적으로 결정할 수 있다.

핵심은 객체가 자신의 협력 객체를 직접 생성(new)하지 않고, 외부에서 주입 받음으로써 결합도는 낮추고 응집도는 높이는 것이다.

# Case 1 : DI 적용 X
class Teacher:
	def teach(self):
		student = Student() # 소스코드에 Student가 명시됨 -> 컴파일 타임 의존성
		return student.study()

# Case 2 : DI 적용 O
class Teacher:
    def __init__(self, student: Student):  # 타입 힌트만 있음
        self.student = student

student = Student()
student = CollegeStudent() # 다른 객체도 가능
teacher = Teacher(student) # 여기서 의존 관계 결정!

3.1 의존성

어떤 코드가 다른 코드에 기대고 있는 것. 즉,변경 전파 가능성을 의미한다.
A가 B에게 의존한다 → B의 변경이 A에게 전파될 수 있다.
```
class Teacher:
	def teach(self):
		student = Studnet() # 구체 클래스에 직접 의존
		return student.study()
```
- Teacher는 Student라는 구체 클래스에 소스코드 레벨에서 결합됨
- Teacher가 협력 객체의 생성과 사용이라는 두 가지 책임을 가진다. (SRP 위반)
- 새로운 학습자 타입을 추가할 때 Teacher 코드는 수정이 필요하다. (OPC 위반)
  - OCP(Open-Closed Principle)
  - 새로운 기능 추가는 가능하되, 기존 코드 수정은 하지 않아야 한다.

class Student:
    def study(self):
        return "공부 중이에요."

class Teacher:
    def teach(self):
        student = Student()
        return student.study()

Teacher 클래스가 Student 클래스의 메소드를 직접 사용하면서 의존하고 있음

→ 나중에 Student 코드가 변경되면 Teacher 코드도 변경되어야함. 강한 의존

3.2 강한 의존을 피하기 위한 외부 의존성 주입

class Student:
    def study(self):
        return "공부 중이에요."

class Teacher:
    def __init__(self, student: Student):
        self.student = student  # 외부에서 주입받음

    def teach(self):
        return self.student.study()

student = Student()
teacher = Teacher(student) # 외부에서 만들어서, 객체 의존성 주입
print(teacher.teach())  # "공부 중이에요."

Teacher는 클래스 내부에서 직접적으로 Student 객체에 의존하지 않고, 외부를 통해 의존한다.

→ Student 내부 구현이 바뀌어도 상관없음 → 유지보수, 테스트, 확장이 쉬워진다.

4. DI 방식 3가지

생성자 주입
메서드 주입
필드 주입

4.1 생성자 주입 → 권장. KRP Core.

객체를 만들 때 필요한 것을 받아서, 변동 없이 그것만 사용한다.
- 객체를 __init__으로 받아서 붙여줌 → 의존성이 명확하다. __init__ 보면 바로 알 수 있음
- 한번 주입되면 변경 불가능 → 불변성 보장
- 클래스 전체에서 일관된 의존성 사용 ↔ 변경하려면 새 객체 생성
- 매번 파라미터 전달 안해도됨

class Student: 
	# 1. 생성자 정의
	def __init__(self, name="sb"):
		self.name = name 
		
	# 2. 출력 형식(문자열) 정의
	def __str__(self):
		return self.name
		
	def study(self):
		return "학생이 공부 중이에요."
		
class Teacher:

	# 주입받을 의존성을 private 필드로 선언
	_student: Student  
	
	# 외부에서 객체를 파라미터로 받아서 생성자 주입 
	def __init__(self, student: Student):
		self._student = student 
	
	def teach(self):
		return self._student.study()
		
	# 주입받은 Student 객체를 Teacher 클래스의 모든 메서드에서 자유롭게 활용 가능하다.
	def check_homework(self):
		return f"{self._student.study()} 숙제를 확인합니다."
		
	def give_feedback(self):
		return f"{self._student} 에 대한 피드백"

if __name__ == "__main__": 
	student = Student()
	teacher = Teacher(student) # 외부에서 student를 생성하고 주입
	print(teacher.teach()) # 학생이 공부중이에요.
	print(

4.2 Method Injection → 일반적으로 사용하지 않는다.

생성자가 아닌 일반 메서드의 파라미터로 의존성을 주입 받는다.
- 메서드마다 다른 의존성 주입 가능하다.
- 필요한 메서드만 의존받을 수 있다.
- 매번 파라미터로 전달해야 하는 번거로움과 명확하지 않은 의존성(함수마다 달라지기 때문)

class Student:
	def __init__(self, name="sb"):
		self.name = name

	def __str__(self):
		return self.name
	
	def study(self):
		return "학생이 공부 중이에요."
	
class Teacher:
	# 생성자에서는 의존성을 받지 않음
	def __init__(self):
		pass
	
	# 메서드 파라미터로 의존성을 주입 받음
	def teach(self, student: Student):
		return student.study()
	
	def check_homework(self, student: Student):
		return f"{student.study()} 숙제를 확인합니다."
	
	def give_feedback(self, student: Student):
		return f"{student}에 대한 피드백"
	
if __name__ == "__main__":
    student = Student()
    teacher = Teacher()  # 의존성 없이 생성

    # 메서드 호출 시마다 의존성을 주입
    print(teacher.teach(student))              # 학생이 공부 중이에요.
    print(teacher.check_homework(student))     # 학생이 공부 중이에요. 숙제를 확인합니다.
    print(teacher.give_feedback(student))      # sb 에 대한 피드백

4.3 Field Injection → @Autowired

객체 생성 후, 필드에 직접 할당한다. teacher.student = student
- 약간 구현부에서 setter 선언하는 것처럼 사용하는 느낌
- 객체 생성과 의존성 주입 분리가 가능하다.
- 불변성 보장 안됨(언제든 변경 가능)
- 테스트 하기 어려움
- @Autowired 이 방식인데 deprecated 추세

class Student:
	def __init__(self, name="sb"):
		self.name = name
	
	def __str__(self):
		return self.name
	
	def study(self):
		return "학생이 공부 중이에요."

class Teacher:
	def __init__(self):
		# 필드만 선언해두고 생성자에서 의존성 받지 않음
		self.student = None
	
	def teach(self): 
		return self.student.study()
	
	def check_homework(self):
		return f"{self.student.study()} 숙제를 확인합니다."
	
	def give_feedback(self):
		return f"{self.student}에 대한 피드백"
	
if __name__ == "__main__":
    student = Student()
    teacher = Teacher()  # 의존성 없이 생성

    # 필드에 직접 의존성을 주입
    teacher.student = student

    # 메서드 호출 시 파라미터 불필요
    print(teacher.teach())              # 학생이 공부 중이에요.
    print(teacher.check_homework())     # 학생이 공부 중이에요. 숙제를 확인합니다.
    print(teacher.give_feedback())      # sb 대한 피드백

[K8S] 자주 사용하는 Kubernetes CLI 정리

sebinChu — Sun, 28 Sep 2025 17:13:42 +0900

개요

업무를 하면서 점점 파드에 접근해서 정보를 확인할 일이 늘어나고 있다. 온콜이나 장애 상황 시에 노션에 붙여둔 명령어를 일일이 찾아보는게 허들이라 느껴져서 아예 블로그에 정리해보기로 했다!

Kubectl

Kubernetes API를 사용해서 쿠버네티스 클러스터의 컨트롤 플레인과 통신하기 위한 커맨드 라인 툴이다.

리소스 관리: Pod, Service, Deployment, ConfigMap 등 k8s 리소스를 생성하고 관리할 수 있다. YAML 파일을 통해 선언적으로 리소스를 정의하거나 명령형 커맨드로 직접 다룰 수 있다.
클러스터 상태 확인: 클러스터에서 실행 중인 애플리케이션의 상태, 노드 정보, 이벤트 로그 등을 조회할 수 있다.
애플리케이션 배포 및 업데이트: 컨테이너 이미지를 배포하고, 롤링 업데이트를 수행하며, 필요 시 롤백할 수 있다.

0. aws-vault 로그인

나의 경우 aws-vault를 사용하고 있기에, 클러스터 접근을 위한 특정 프로필을 사용하여 로그인을 한다.

aws-vault exec daangn/prod -- zsh
aws-vault exec daangn/alpha -- zsh
aws-vault exec daangn/data -- zsh

~/.aws/config 하위에 정의된 자격 증명에 관련한 프로필로 인증한 뒤, aws에 접근할 수 있다.
—zsh : aws-vault 실행 후 zsh 셸을 시작한다는 뜻!

1. cluster contexts 확인 및 등록

1.1 cluster contexts란?

컨텍스트에는 다음과 같은 정보가 담겨있다.

Cluster: 연결할 k8s 클러스터의 API 서버 주소와 인증서 정보
User: 해당 클러스터에 접속할 때 사용할 사용자 인증 정보(토큰, 인증서, AWS IAM 등)
Namespace: 기본으로 작업할 네임스페이스

작업을 하기 전에 항상 이 컨텍스트를 확인해야 한다. 그래서 나의 경우는 kube-ps1을 통해 터미널 가장 앞 쪽에 현재 접속중인 context가 표시 되도록 해두었다! 컨텍스트 실수로 인한 프로덕션 장애가 발생하는 경우가 실제로도 종종 있다. 예를 들어서, 개발 서버를 살제하려다가 실수로 프로덕션에서 실행하는.. 실수는 누구나 할 수 있으니까 이 컨텍스트의 중요성을 알고, kube-ps1과 같은 도구를 활용하자!

1.2 cluster contexts 정보 확인하기

# 로컬 kube config 정보를 통해 로컬 환경에 등록되어 있는 컨텍스트 확인
kubectl config get-contexts

# 콘솔 eks 클러스터 확인
aws eks list-clusters --region ap-northeast-2

로컬 ↔ 콘솔에 등록된 클러스터 컨텍스트를 비교하고, 작업이 필요한 클러스터가 있다면 context를 등록해준다.

1.3 로컬 환경에 contexts 등록 및 사용하기

⚫️ eks update-kubeconfig로 로컬 config 업데이트

aws eks update-kubeconfig --name ${cluster} --region ap-northeast-2 --alias ${cluster}

나의 경우, 콘솔에 없는 kmkr 클러스터 컨텍스트를 위 명령어를 통해 추가해주었다.

이 kubeconfig는 개인 설정 파일(~/.kube/config)에 나의 kubectl이 클러스터에 연결하는 방법을 정의하는 명령어다.

⚫️ config use-context로 사용할 컨텍스트 지정

kubectl config use-context ${cluster}

사용할 컨텍스트 지정 명령어

2. Namespace 접근

use-context를 통해 특정 클러스터에 접근했다면, 이제 그 하위 namespace에 접근할 수 있다.

2.1 namespace란?

namespace는 클러스터를 하나의 큰 건물이라고 치면, 건물 내부 방이다. namespace는 동일한 물리적 클러스터를 여러 가상 클러스터로 나누는 방법으로, 단일 클러스터 내에서 리소스 그룹을 격리하는 메커니즘이다. (자세한 namespace 내용)

2.2 namespace 목록 추출 및 접근

# 모든 네임스페이스 목록 확인
kubectl get namespaces
kubectl get ns

STATUS: namgspace 상태
- active: 정상 작동 중
- terminating: 삭제 중
AGE: namespace가 생성된 후 경과 시간

2.3 특정 Namespace의 Pod 확인

보통 특정 namespace의 pod에 접근해서 리소스 상태를 확인하는 작업이 많다. 아래와 같은 명령어로 특정 네임스페이스의 pod들을 확인할 수 있다.

kubectl get pods -n ${namespace}

⚫️ Pod는 Node Group의 컨테이너인데, namespace로 접근하는 이유는?

실제로 Pod는 Node 위에서 실행되지만, 여러 이유로 다른 Node로 이동을 하게 된다.

Node 장애 시 다른 Node로 스케줄링
Node 유지보수를 위한 Pod drain
새 노드가 추가되면 Pod 재배치

물리적 구조(실제 Pod가 실행되는 곳)

Cluster
  ㄴ Node1 (EC2 인스턴스)
      ㄴ Pod A (production namespace)
      ㄴ Pod B (development namespace)
      ㄴ Pod C (production namespace)
  ㄴ Node2 (EC2 인스턴스)
      ㄴ Pod D (monitoring namespace)
      ㄴ Pod E (production namespace)

논리적 구조(실제 우리가 관리하는 방식)

Cluster
  ㄴ production namespace
      ㄴ Pod A (Node1에서 실행 중)
      ㄴ Pod C (Node1에서 실행 중)
      ㄴ Pod E (Node2에서 실행 중)
  ㄴ development namespace
      ㄴ Pod B (Node1에서 실행 중)
  ㄴ monitoring namespace
      ㄴ Pod D (Node2에서 실행 중)

3. Pod 상세 정보

3.1 get으로 pod 상태 확인하기

# Pod 빠르게 확인
kubectl get pods -n ${namespace}

# Node, IP 정보까지 확인
kubectl get pods -n ${namespace} -o wide

READY: 준비된 컨테이너 수 / 전체 컨테이너 수를 나타낸다.
- 1/2의 경우, 메인 앱은 정상이고 사이드카는 죽은 상태다.

3.2 get + grep 조합으로 Pod Status 필터링 하기

kubectl get pods -n production | grep Error
kubectl get pods -n production | grep Pending
kubectl get pods -n production | grep CrashLoopBackOff
kubectl get pods -n production | grep Terminating

Error: 컨테이너가 exit code로 종료된 상황이다. 애플리케이션 에러로 파드가 죽은 경우
Pending: Pod가 Scheduling 대기 중인 상태다. 주로 리소스 부족이나 노드 조건 불일치에 의해 발생한다.
CrashLoopBackOff: 컨테이너가 시작 → 죽음 → 재시작을 반복하고 있는 상황이다.
Terminating: Pod가 삭제 중인데 아직 완전히 사라지지 않은 상태로, 보통 graceful shutdown 대기중인 상태다.
ImagePullBackOff: 이미지 다운로드가 실패한 상황이다.

+) get + grep 조합에 대한 옵션

kubectl get pods -A -o wide | grep 10.11.1.11..

-o wide: 파드 IP, 노드 이름 등 추가 정보를 포함한 넓은 출력 형식을 받을 수 있다.
-A: 모든 네임스페이스에서 조회할 수 있다.

3.3 Pod 로그 확인

kubectl logs --tail=${n} ${pod} -n ${namespace}

--tail 옵션을 통해 최근 n줄에 대한 로그를 출력한다

3.4 Pod 리소스 사용량 확인 / 조정

kubectl top pods -n ${namespace}

top 명령어를 통해 개별 Pod의 리소스 사용량을 확인할 수 있다. CPU = 8m 이라는 것은 CPU를 0.8% 사용하고 있다는 뜻이다. 만약 CPU에 950m와 같은 수치가 보인다면 한 Pod가 CPU를 95% 사용하고 있다는 뜻으로, 리소스를 비효율적으로 사용하고 있음을 의심해볼 수 있다.

⚫️ Pod는 Node의 리소스를 할당 받아 사용한다.

Pod는 개별 CPU/Memory를 가지는 것이 아니라, Node의 리소스를 할당 받아서 사용한다. 즉, 다음과 같은 구조를 가진다.

Node (EC2 인스턴스: t3.xlarge)
├── 실제 리소스: 4 CPU cores, 16GB RAM
│
├── ⚫️ Pod A: 1 CPU, 2GB 할당받음
├── ⚫️ Pod B: 0.5 CPU, 1GB 할당받음
├── ⚫️ Pod C: 2 CPU, 4GB 할당받음
└── 남은 리소스: 0.5 CPU, 9GB

3.5 describe로 Pod 세팅 상세 확인하기

kubectl describe pod ${pod} -n ${namespace}

단순 get pod, top pod 명령어와 다르게 해당 Pod에 설정된 구체적인 내용들(IP, Port, Liveness, Readiness 등등)을 확인할 수 있다.

K8S도 GUI 환경을 제공하지만 보통 업무를 할 때 kubectl 명령어를 많이 사용해서 정리해보았따.

장애 일지 보면서 필요한 명령어들은 조금씩 더 추가해볼 예정이다.

쿠베 공부 부단히 해야겠다 ㅠ_ㅠ

[회고] 사내 해커톤 시뮬레이션 회고!

sebinChu — Wed, 24 Sep 2025 22:52:53 +0900

개요

회사에서 외부인을 대상으로 해커톤을 주최했다. 이 해커톤의 성공적인 진행을 위해 미리 사내 개발자를 대상으로 시뮬레이션을 진행했고, 자진해서 8시간 해커톤을 참여하게되었다.

참여 동기

[ 지식 관점 ] 인프라실에서 자연스럽게 인프라 역량을 키우는 데 몰입하다 보니 상대적으로 프로덕트 개발에 대한 집중은 줄어들었다. 그래서 이번 시뮬레이션 대상자 지원은, 놓쳤다고 느꼈던 개발 지식과 열정을 다시 끌어올리기 위해 스스로에게 동기부여를 주기로 했다!
[ 협업 관점 ] 시즌테크로 입사한지 6개월차가 되었다. SRE팀은 당근 인프라를 관리하며 서비스 안정성을 책임진다. 또한, 개발자들이 개발에 집중할 수 있도록 인프라 기능을 추상화하고, 서비스 개발에만 집중할 수 있도록 플랫폼을 개발 및 운영한다. 그래서 개발자들의 목소리를 잘 듣는게 중요하다고 생각한다. 사내 개발자들이 평소 어떤 업무 사고방식을 가지고 있는지, 무슨 일을 하는지 더 잘 알고싶었다.

1. 8시간 스프린트로 빠르게 서비스 2개 출시하기

(해커톤 방식은 구체적으로 설명하지 않고, 주로 느낀점을 바탕으로 방향성을 정리해보는 회고글이다.)

여느 해커톤과 비슷하게 주제를 오픈하고, 그 주제에 대해 기획하고 개발한다. Claude Code가 등장하고 나서 개발 패러다임이 많이 바뀌었는데, 아니나 다를까 해커톤도 예전과는 양상이 많이 바뀌었다고 느꼈다. (물론 시뮬레이션이었지만…)

일단 해커톤 준비를 할 때도, 나는 아이디어나 코드베이스를 공부하기 보다는, 클코를 어떻게 하면 더 잘 쓰지?에 대해 고민하고, 미리 학습했다. 그 이유는 빠른 시간 안에 최대한 효율을 내야 하는 해커톤에서는 AI를 잘 활용하는게 이득일 것이라 판단했기 때문이다.

미리 준비한 Claude Code 잘 사용하기 전략과 능력자 팀원을 만나, 8시간 안에 2개의 서비스를 출시할 수 있었다. (사실 클코도 클코지만 팀원의 능력이 더 한몫한 것같다.. 존경해요..)

2. AI를 잘 쓰려면? 프롬프트 엔지니어링과 Context

2.1 프롬프트 엔지니어링

프롬프트 엔지니어링을 잘 하려면 텍스트를 잘 다뤄야 한다는 점을 배웠다.

내 생각을 뽑아내서 글로 잘 쓰는게 첫 단계이기 때문이다. 책 많이 읽고, 글 많이 써야겠다고 다짐하게 되었다.

그리고 개발지식과 경험이 탄탄해야 한다.

이번 해커톤에서도 99% 코드를 Claude Code가 작성해주었지만 아래와 같은 지식이 없었다면 엄청 헤맸을 것을 예상한다.

구체적인 요구사항 명세서
API 스펙
이 프로젝트에서 사용할 기술과 그로부터 얻으려고 하는 이점
서빙 방식
- 팀원이 알려준 방식으로 했던거.. 간단하게 구조라도 그려서 추가해보자..!

CLAUD.md 파일에 내가 구현하고자 하는 명세와 스펙을 마크다운으로 작성했다. 중간중간 기능 구현에 필요한 기술은 팀원과 토의하고, Claude Code에게 구현하게 했다. 구현 과정과 결과물은 당연히 사람이 검토하고 반영하도록 했다.

2.2 Context 다루기

Claude Code를 쓰면서 하면 좋은 습관은 중간중간 컨텍스트를 관리해주는 것이다. Context가 너무 방대해지면, AI도 길을 잃는다. 그리고 한번 AI가 많은 코드 베이스 변화를 주면, 나 또한 따라가기가 힘들다. 그래서 항상 작업 Point를 찍어가면서 지금 나와 AI가 어느 지점에 있는지, 어느 방향으로 가는지 Contex Point를 맞춰가면서 나아가야 한다. 이걸 잘 하려면

작업 중간 Context를 Claude.md에 정리
중요한 피쳐 작업은 Claude Code에게 변경을 맡기기 전에 Point 설정(마음에 안들면 롤백해야 하니까)

3. 소회

AI가 발전하면서 엔지니어 자리를 위협하는거 아닌가 하는 의심이 도처에 도사리고 있다. 하지만 오히려 엔지니어의 생산성을 높여주고, 엔지니어들이 특히나 잘 활용할 수 있는 분야이기에, 엔지니어의 역량은 더더욱 중요도가 높아질 것이다.

따라서 부단히 지식과 경험을 쌓으려 노력하는 걸 멈추지 않아야 한다. 오히려 내 생각과 지식에 대한 구현을 도맡아줄 동료가 생겼으니, 더 시간을 잘 쓸 수 있고, 더 똑똑해질 수 있다. 그래서 나는 앞으로도 지식과 경험을 쌓는 일에 Aggressive한 태도로 임하며, 변화의 파도 위에서 더욱 성장해 나갈 것을 다짐했다.

[Network] CIDR, IP, Subnet Mask

sebinChu — Sun, 21 Sep 2025 16:42:35 +0900

개요

볼 때마다 헷갈려서 아예 각 잡고 정리해보는 CIDR, IP, Subnet Mask 개념

확실하게 짚고 넘어가자!

1. CIDR(Classless Inter-Domain Routing)

IP/비트수로 네트워크 범위를 표현하는 방식
x.x.x.x/ab 형식

2. IP

1.1 IP 의미

네트워크 + 호스트를 8비트씩 점으로 구분해서 10진수로 표기하는 방법
- Network Address: 해당 IP가 속한 네트워크 구역을 알 수 있다.
  - 192.168.1.0/24 네트워크에 있는 모든 장비는 네트워크 주소가 192.168.1.0으로 같다. (서브넷 마스크를 통해 알 수 있다.)
  - 192.168.1.1/24, 192.168.1.12/24 ,192.168.1.2/24가 목적지인 패킷은 라우터에 의해 모두 같은 네트워크로 라우팅된다.
- Host Address: 한 네트워크 영역 안에서 특정 장비(호스트)를 구분하는 고유 주소다.
  - 192.168.1.10 → 프린터
  - 192.168.1.20 → 내 노트북
  - 192.168.1.30 → 서버
  ⇒ 이들은 전부 192.168.1.0/24라는 네트워크에 속해 있고, 마지막 옥텟(.10, .20, .30)으로만 서로를 구분한다.

2.2 공인 IP와 사설 IP

Public IP: 인터넷에서 유일하게 식별 가능한 주소

Private IP: 내부 네트워크 전용, 인터넷에서는 직접 안 보임. RFC1918에서 정의된 범위만 사용 가능

사설 IP는 3가지 블록으로 정해져 있다.

클래스	범위	크기
A	10.0.0.0 ~ 10.255.255.255	/8 (16,777,216 개 주소)
B	172.16.0.0 ~ 172.31.255.255	/12 (1,048,576 개 주소)
C	192.168.0.0 ~ 192.168.255.255	/16 (65,536 개 주소)

클래스 A(0~127 대역): 보통 클라우드 환경이나 대기업 내부 네트워크에서 많이 사용(ex. 10.x.x.x)
- 8비트 네트워크. 기본 서브넷 마스크가 255.0.0.0(/8)으로 호스트 영역이 매우 큼
클래스 B(128~191 대역): RFC1918에서 정의된 Private IP 대역 중 하나(ex. 172.x.x.x)
- 클라우드 서비스에서도 종종 VPC CIDR 기본값으로 쓰인다.
- 내부망을 나누는 용도로 적합하다
클래스 C(192~223 대역): 비교적 작은 네트워크 대역, 흔히 집/소규모 사무실/공유기에서 많이 사용(ex. 192.168.x.x)

3. Subnet Mask

마스크는 “가린다”, “숨긴다”라는 뜻이 있다. 네트워크에서 Subnet Mask는 IP 주소에서 네트워크 부분만 드러내고, 호스트 부분은 가려내는 도구다.

3.1 Subnet Mask의 역할

만약 192.168.1.10같은 IP만 있고, 마스크 정보가 없다면 이 IP가 어떤 네트워크에 속해있는지 알 수 없기에, 라우터가 어떤 네트워크로 패킷을 보내야할 지 판단할 수 없다.
- 192.168.1.10이 192.168.1.0/24에 속한 건지, 192.168.1.0/16 에 속한 건지 알 수 없다.
데이터센터, VPC 등에서는 큰 네트워크를 잘게 쪼개서(Subnetting) 나눠 써야 한다.
- 10.0.0.0/8을 한 회사가 다 쓸 수 있지만,
  - 인프라팀: 10.0.1.0/24
  - 개발팀: 10.0.2.0/24
  - 보안팀: 10.0.3.0/24
- 이렇게 네트워크를 쪼개 쓰는 기준이 바로 서브넷 마스크다.
브로드캐스트 패킷은 네트워크 전체에 퍼지므로, 네트워크가 크면 불필요한 트래픽이 엄청 늘어난다. 마스크를 이용해서 네트워크를 쪼개면, 브로드캐스트 범위를 작게 제한할 수 있다.

3.2 계산 예시

3.5.232.128/25

네트워크 영역은 25 비트, 호스트 영역은 32-25 = 7 비트이므로, 2**7 개의 호스트 사용 가능
- 하지만 네트워크에서는 항상 다음과 같은 규칙이 있다.
  - 호스트 비트가 전부 0 → 네트워크 주소
  - 호스트 비트가 전부 1 → 브로드캐스트 주소
  ⇒ 따러서 실제로 사용 가능한 호스트 주소 수 = 2^7 -2 = 126개

3.3 Subnet Mask 해석 방법

IP : 192.168.1.10
Subnet Mask : /24

Subnet Mask가 24라는 건, 앞에서부터 24비트가 네트워크 부분이라는 뜻이다.

/24: 11111111.11111111.11111111.00000000 = 255.255.255.0
/16: 11111111.11111111.00000000.00000000 = 255.255.0.0
/30: 11111111.11111111.11111111.11111100 = 255.255.255.252
- 1로 되어있는 부분이 네트워크 주소로 묶이고, 나머지는 호스트 주소 영역이라는 뜻이다.
- 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255
- 128 + 64 + 32 + 16 + 8 + 4 + 0 + 0 = 252

4. BroadCast

같은 네트워크 안에 있는 모든 호스트에게 동시에 메시지를 보낸다. “동네 사람들 다 들어!”
- 한 네트워크 안에서 어떤 장치에 패킷을 보내야 할 지 모를 때, 네트워크에 있는 모두에게 물어보는 방식으로 쓰인다.
- 브로드캐스트가 네트워크 성능에 부담되기에, 서브넷을 쪼개서 범위를 제한한다.
호스트 부분을 모두 1로 채운 IP가 브로드캐스트 주소다.
- 192.168.1.0/24
  - 네트워크 부분은 192.168.1 이고, 나머지 192.168.1.255가 브로드캐스트 주소!

[Monitoring] 시계열 데이터와 TSDB

sebinChu — Mon, 15 Sep 2025 23:25:40 +0900

개요

인턴 때부터 Grafana 작업을 하면서 Metrics, TSDB, PromQL 관련 내용들을 개인 노션에 쭉 작성했는데, 블로그에도 새로운 카테고리를 생성하고 정리하는 공간을 만들었다. 요즘 Alert Rule을 세팅하는 작업을 하고 있는데, 노션 문서를 자주 참고하게 되어서 아예 블로그로 올려버리기로 결심!

1. 시계열 기반 모니터링

시간의 변화에 따라 축적된 데이터들을 수집, 저장, 분석, 알람하는 시스템

예를 들어서.. Prometheus는 다음과 같은 일을 한다.

15초마다 /metrics 에 접속해서 현재 상태값 긁어오기
수집한 메트릭을 시간과 함께 저장
PromQL 쿼리를 통해 과거 1시간 평균 rate같은 걸 분석

1.1 운영 시스템에서 시계열 데이터

과거에 무슨 일이 있었는지?
변화 추이는 어떠한지?
- 어제보다 CPU가 더 많이 사용되는가?
- 5분 요청량이 급증/급락 했는가?
- 등등…

시간의 흐름을 기반으로 서비스를 운영한다.

2. TSDB(Time Series Database)

RDB는 레코드 중심(row-based) 데이터라서 시간 순으로의 수많은 데이터를 다루기 어렵다.

TSDB는 데이터를 table 형식이 아니라 아래와 같이 저장한다.
metric_name: node_cpu_seconds_total labels: {mode="user", instance="web-1"} timestamps: [10:00:00, 10:00:01, 10:00:02, ...] values: [23.5, 25.1, 22.8, ...]

3. Prometheus

3.1 Prometheus는 시계열 기반의 모니터링 시스템 (문서)

Prometheus Server: Scraping, TSDB, PromQL
Exporter: 매트릭을 내보내는 앱 or 에이전트 → 이 Exporter를 node에 접근해서 설치하는 건가?
metric + label 조합을 하나의 시계열로 간주한다. 따라서, 아래 두 개는 다른 시계열이다.
http_requests_total{method="GET", status="200"} http_requests_total{method="POST", status="500"}

3.2 Prometheus 동작 흐름

Pull 기반 수집: endpoint에 직접 가서 /metrics 데이터를 긁어온다.
Time Series: 내부 TSDB에 메트릭을 시간 기준으로 저장
PromQL로 쿼리: 매트릭 조회, 시각화

3.3 What is Prometheus not? (아티클)

프로메테우스는 로깅 시스템이 아니라, 메트릭 수집용 도구다.
- cpu 사용률, 에러율, 요청 수와 같은 숫자 중심 지표를 수집한다.
- 메트릭은 Prometheus, 로그는 Loki/ELK/CloudWatch Logs 등으로 분리
long-term DB를 지원하지 않는다.

3.4 Prometheus Storage (문서), (alice님 블로그)

Prometheus는 시계열 데이터 조각(chunk)를 메모리에 유지한다.
storage.local.path 라는 플래그로 수집한 시계열 데이터를 디스크에 저장한다.

3.5 Prometheus Metric Type (문서)

Counter: 항상 증가하는 값(단조 증가), 재시작 시 0으로 리셋
- increase: 내부적으로는 rate() * seconds로 계산
- rate: 1초당 얼마나 증가했는지
Gauge: 현재 메모리 사용량과 같은 증감값, 시스템 자원 상태
Histogram

4. Chunk Data와 Metrics Data의 차이

Metric은 측정 대상을 나타내는 이름 + 라벨 조합으로, aws_cloudfront_requests같이 수집한 덩어리다.
Chunk는 각 시계열에 대해서 일정 시간 동안의 값을 묶어서 저장한 덩어리다.
예를 들어서, http_requests_total{method="GET", status="200"} 라는 메트릭의 데이터가 있다고 했을 때 chunk는 다음과 같다.
chunk 1: [10:00:00 → 100, 10:00:15 → 110, 10:00:30 → 125, ...] chunk 2: [12:00:00 → 500, 12:00:15 → 530, ...]

[Network] CDN(Content Delivery Network)

sebinChu — Mon, 8 Sep 2025 00:11:40 +0900

개요

Valkey 발표 및 전환을 앞두고..! 이번 스프린트에서 드디어 CloudFront Datadog Alert 작업을 시작하게 되었다. 윈터테크 인턴 시절 CloudFront 리소스에서 Additional Metrics가 비활성화된 점을 발견하고, 프로덕션 환경에 한해 이를 활성화하여 모니터링을 강화하자는 제안을 했으며 팀에서 이를 받아들여 적용하였다.

그러나 Additional Metrics 활성화 이후 기존 CloudFront Datadog Alert의 정확도가 떨어지는 문제가 발생했다. 이번 스프린트에서는 이 문제를 개선하여 Alert 정확도를 높이고, CDN 모니터링을 체계적으로 강화하는 것을 목표로 한다. 이번 포스팅으로 CDN에 대해 잘 정리해보겠다!

1. CDN 기본 구조와 목적

CDN은 정적/동적 컨텐츠(HTML, CSS, JS, 이미지, 동영상)을 전 세계에 분산 배치된 Edge 서버에서 제공하는 시스템이다. CDN이 점점 발전하면서 단순 캐싱 이외에도 DDoS 방어, WAF, 동적 라우팅 등등의 기능을 제공하게 되었다. 이 포스팅은 이러한 CDN의 근본적인 내용을 학습하고 정리하는 목적으로 작성한다!

사용자와 가까운 위치에서 응답해서 Latency를 줄인다.
Origin(원본) 서버의 부하를 낮춘다.
CDN은 전 세계 Edge Location에 분산되어 있기 때문에, Origin Server보다 더 많은 트래픽을 처리할 수 있다.
네트워크 트래픽 비용을 절감시킨다.

2. Why CDN?

2.1 클라이언트 <-> 서버 Latency 해소

이미지와 같이 Client와 Server 간 지리적 위치가 차이나면, 단순히 요청이 한번 왔다갔다 하는 데에도 많은 응답 시간이 걸린다. 이에 CSS와 같이 바뀌지 않는 정적 파일에 대해 Edge Location Server에 저장(캐싱)하여 빠르게 전송하는 방식을 고안하였고, 그게 CDN이다.

현재는 정적 파일 뿐만 아니라 Cache-Control 헤더를 활용하여 API 응답과 같은 동적인 부분도 캐싱한다.

2.2 HTTP/1.1의 도메인 연결 제한

또한 HTTP/1.1 시절, 브라우저는 도메인당 동시 연결 수를 제한했다. (HTTP Connetion Management Guide From MDN)

As a solution, browsers open several connections to each domain, sending parallel requests. Default was once 2 to 3 connections, but this has now increased to a more common use of 6 parallel connections. There is a risk of triggering DoS protection on the server side if attempting more than this number.

브라우저가 하나의 도메인에 동시에 열 수 있는 TCP 연결이 최대 6개로 제한된다는 뜻이다. 7번째 패킷은 앞의 1~6 번째 패킷의 통신이 끝날 때까지 대기해야 하므로, 응답 성능이 좋지 않다.

  <!-- 모두 example.com → 총 6개 연결만 사용 -->
  example.com/logo.png     [연결 1]
  example.com/banner.jpg   [연결 2]
  example.com/icon1.png    [연결 3]
  example.com/icon2.png    [연결 4]
  example.com/style.css    [연결 5]
  example.com/script.js    [연결 6]
  example.com/footer.png   [대기...]  <!-- 7번째는 대기 -->

(참고) HTTP/2.x로 업그레이드되면서 이 점은 해소되었다. 2015년에 IETF에서 RFC 7540으로 공식 발표되었고, 현재 대부분의 브라우저와 서버가 지원하고 있다. 아래는 필자의 깃허브 페이지에 접속했을 때 주고받는 프로토콜이 대부분 h2(HTTP/2)로 설정되어있음을 확인할 수 있다.

3. CDN Architecture

CDN은 전 세계에 Edge Server를 두고 Origin Server의 콘텐츠를 캐싱한다. 사용자 요청이 들어오면 가까운 Edge에서 빠르게 캐싱된 내용을 응답으로 제공한다.

CloudFront는 브라우저와 Origin 사이에 끼어있는 CDN이다. 모든 요청은 무조건 CF를 먼저 거치게 된다.

Last Mile: 지역 ISP로부터 일반 사용자에게 콘텐츠가 전달되는 구간
Middle Mile: Edge Server들과 ISP 사이 구간
First Mile: Origin Server와 ISP 사이 구간

3.1 Edge Server와 PoP(Point of Presence)

각 PoP는 CDN의 물리적 위치를 나타낸다. 하나의 PoP는 여러 대의 Edge Server로 구성된다. 사용자의 요청은 가장 가까운 PoP로 라우팅 된 뒤, 그중 내부 Edge Server 하나가 응답을 한다.

- 서울 PoP(ICN)
- 도쿄 PoP(NRT)
- 싱가폴 PoP (SIN)
- 샌프란시스코 PoP(SFO)

3.2 Origin Shield

Origin Shield는 Origin Server 바로 앞단에 위치한 캐시 계층이다. 모든 CDN Edge 요청을 단일 지점으로 모은다.

Shiled가 없을 때
- 100개의 Edge Server Cache Miss로 인한 -> Origin 동시 요청
  - 같은 콘텐츠를 동시에 100번 요청으로 Origin 부하가 폭증한다.
Shiled가 있을 때
- Origin Shiled가 100개의 Edge Server 요청을 모아서 한 번에 Origin에 요청
  - Shiled가 대표로 1번만 요청하고 나머지 99개는 Shield에서 대기한다.

4. CDN과 DNS

CDN은 DNS를 시작점으로 사용한다.

사용자가 cdn.example.com 요청
DNS 서버가 해당 도메인의 위치를 CDN 서비스에 알려줌
CDN은 Location PoP의 Edge Server에 캐싱된 내용 요청

CloudFront 예시를 통해 알아보자.

AWS CloudFront를 통해 Origin에 대한 CDN을 설정하면, Alternate Domain Name (CNAME) & Custom SSL Certificate 또한 입력 및 생성된다. CloudFront를 생성하면 기본 도메인이 xxxxx.cloudfront.net 이런 도메인이 생성되는데, 이는 사용자가 기억하기 어려운 도메인이다.

그래서 CF 자신의 도메인(xxxxx.cloudfront.net)을 R53에서 생성된 도메인과 CNAME으로 연결한다.

AWS CloudFront 생성 화면

하위 Tenant 화면이긴 하지만.. 하나의 Distribution에 Domain 설정과 ACM 설정이 되어있는 걸 확인할 수 있다.

5. CDN Cache 정책

5.1 TTL(Time To Live) 설정

TTL은 패킷이 네트워크 내부에서 존재하도록 설정된 기간이다. 인터넷 환경에서 목적없이 라우터 <-> 라우터간 무한정으로 떠도는 유령 패킷을 방지하기 위해 설계되었다.

CDN은 이 TTL을 사용하여 Origin 업데이트 사안을 가져오기 전에 캐싱된 콘텐츠를 얼마나 유지할 것인지 결정한다.

TTL 값이 너무 길면, Origin과 Edge의 콘텐츠 내용이 차이가 날 수 있다. 반면 TTL 값이 너무 짧으면 Edge Server에 캐싱하는 게 무의미할 수 있기에 잘 설정해야 한다.

이러한 TTL 설정은 보통 Cache-Control 헤더에서 확인할 수 있다.

헛 cloudflare의 blog의 js 파일을 열었을 때의 Cache-Control 헤더;; 31536000이면 1년 설정이다.

보통 이렇게 설정하는 건 파일 이름에 해시값이 들어간다. 내용이 바뀌고 빌드가 되면, 파일명도 바뀐다. 사용자는 새로운 파일명을 로드하므로, 캐시와 상관없이 최신 파일을 받는다. 뭔가 업데이트가 드문 리소스의 경우에는 TTL 설정을 길게 잡고, Origin에 요청이 많이 가지 않도록 한다.

5.2 Cache-Control Header

브라우저에서 오고가는 패킷을 살펴보면 위와 같은데, Cache-Control에 다양한 옵션들이 보인다.

public: CDN이 자유롭게 캐싱해도 문제 없는 공개 자원으로, 응답을 모든 캐시(브라우저 & CDN/Proxy)에 저장 가능
private: 오직 개인 캐시(브라우저)에만 저장 가능하고, 공유 캐시(CDN/Proxy)에는 저장 불가능
max-age: Origin에서 브라우저와 Edge Server에 얼마나 캐싱할 건지 유효시간(TTL) 설정한 값
- age: CDN POP에 캐싱된 시간(CDN POP에서 자동으로 등록하는 것)
s-maxage: 공유 캐시(CDN/Proxy)에만 적용되는 캐시 유효 시간
no-cache: 캐시에 저장은 가능하지만, 사용 전에 항상 Origin Server에 검증
no-store: 아예 저장 자체 금지!
must-revalidate: TTL이 지난 후, 반드시 Origin Server 검증 필요
immutable: 바뀌지 않는값이니, 캐시된 걸 그대로 써라는 뜻
stale-while-revalidate, stale-if-error: 만료 후에도 일정 시간은 캐시를 그대로 사용(옛 캐시 보여줌)

CDN에 대한 기본적인 내용을 정리해보았다. TLS를 CDN에 설정하면 어떻게 될까?. Dynamic/Static CDN 등등 더 공부해야할 내용이 많은데.. 심화 버전으로 찾아와보도록 하겠음

[Redis] Redis 7.x → Valkey 8.x 마이그레이션 PoC

sebinChu — Mon, 25 Aug 2025 00:33:46 +0900

개요

Redis Laps가 SSPL로 전환하면서, Redis 7.x 버전을 fork한 Valkey Engine 프로젝트가 시작되었다. Valkey 7.x는 Redis 7.x를 그대로 fork한 것과 다름 없어서, 마이그레이션을 할 때 클라이언트 라이브러리를 변경하는 것 이외에는 크게 신경 쓸 점이 없다. 하지만 Valkey 8.x Engine부터는 Redis와 꽤 다른 지점이 생긴다. 직접 ElastiCache Redis, Valkey Engine을 생성해서 마이그레이션 과정을 정리해본다.

1. 기본적인 읽기 전용 Cache

기본 환경 정보

- Node Type: cache.t4g.small
- Cluster Mode: Enabled
- Shards/Nodes: 1개 / 2개
- Encryption in transit/rest: Disabled

1.1 ElastiCache Redis에 CLI를 통해 데이터 넣기 & 기본 정보 확인

ElastiCache Redis → Valkey 마이그레이션 전후 비교를 위해서 기본 정보를 확인해본다.

반복문으로 데이터 넣기

for i in {1..100000}; do
  redis-cli -h <endpoint> SET "key:$i" "value:$i"
done

데이터가 잘 들어갔는지 확인(DBSIZE, GET KEY)

Cluster Mode Info 확인

Replication Info 확인

- Replica(=Slave) 노드가 1개 붙어있다.

- lag=0: Primary와 Replica 사이의 지연 없음

- 현재 Failover 상황 아님!

- offset: 복제 로그의 위치를 뜻한다.

1.2 redis-benchmark를 통한 GET 요청(읽기) 성능 테스트

redis-benchmark 명령어를 통해 간단하게 성능을 비교해본다.

redis-benchmark -h "$H" -p 6379 -n <총 요청 수> -c <동시 연결 수> -t <테스트할 명령>

100,000 번의 GET 요청으로 부하 테스트를 진행한다.

100,000개의 key를 넣고 성능 테스트를 했을 때, 결과를 해석해보면,

QPS(초당 처리량)은 3313.45로, 1초 당 약 3300개의 요청을 처리했다는 뜻이다. 네트워크 왕복 시간까지 합쳐서 계산하게 되는데, 나는 로컬 PC에서 redis-benchmark를 수행하였고, 실제 같은 VPC에 존재하는 인스턴스에서 실행하면 더 빠른 성능을 보일 수 있다.
지연시간 분포(percentile) 중 50퍼센타일. 즉, 전체 요청 중 절반은 약 14.9ms 이하로 걸렸다는 뜻이다.

redis-benchmark -h "$H" -n 100000 -c 50 -t get

50개의 클라이언트로 100,000 번의 GET 요청 부하 테스트를 진행한다.

-c: 동시에 클라이언트 N(50) 개를 생성하여 병렬로 요청을 보내는 것처럼하는 옵션이다.
-t: 테스트할 명령어를 지정한다.

100,000개의 key를 넣고, 50개의 클라이언트를 만들어서 성능 테스트를 했을 때, 결과를 해석해보면,

총 10만 건의 요청을 126.48초에 처리했다. 이는 약 790 QPS(초당 처리량) 수준이다.
동시에 50개 클라이언트 연결을 유지했다.
각 값(value)는 3 byte 문자열
대부분의 요청(p99) 이 0.1초 이내(280ms)에 처리되었다.

1.3 TTL 값 확인

Redis 엔진에서 Key의 수명을 설정하고, Valkey로 마이그레이션 했을 때 이 TTL이 유효한지 검증해본다.

key: 12, {1..5}에 대한 TTL 확인

TTL(Time To Live)는 키의 남은 수명을 보여준다.

양수: 해당 키가 만료되기까지 남은 초
-1 : 키가 존재하지만, 만료 시간 설정이 없음. 즉, 영구 키를 뜻한다.
-2: 키가 존재하지 않음. 즉, 이미 만료되었거나 삭제되었다.

Valkey로 마이그레이션 이후 이 TTL 설정이 잘 남아있는지 확인하기 위해 특정 키(500)에 대해서 TTL(expire)을 설정했다. 초 단위로 TTL을 설정할 수 있기에, 604800초 == 7일로 부여했다.

2. Redis 7.x → Valkey 8.x 마이그레이션 이후, 지표 확인해보기

Redis 7.x → Valkey 8.x 전환에는 boto3의 modify_replication_group API를 사용하였다. parameter_group 또한 같은 워크플로우 내에서 API로 변경하였다. 사내 배포 플랫폼을 통해 변경하였기 때문에 이 부분은 내부 시스템에만 적용된다는 점.. API 이외에도 콘솔에서 Modify하거나 Upgrade to Valkey를 하면되는데, 이 각 방법의 차이점은 AWS Support 미팅 이후에 추가해볼 예정이다!

2.1 CLI를 통해 Valkey Engine 기본 정보 확인

Redis Engine에서 Valkey Engine으로 마이그레이션하고, 데이터 변동 사항을 redis-cli를 통해 확인해본다.

데이터가 잘 있는지 확인(DBSIZE, GET KEY)

오 Key-Value 쌍이 문제 없이 잘 남아있는 모습 확인

Cluster Mode Info 확인

Cluster State ok에 Node도 2개로 잘 마이그레이션된 점을 확인할 수 있다. Redis일 때와 크게 다른 점은 없어 보인다.

Replication Info 확인

Valkey로 in-place 전환 즉, 엔진 교체가 이루어지면서 Primary Node의 재시작이 일어나서 master_replid가 재생성된 점을 확인할 수 있다. 여기서 second_repl_offset이 마이그레이션 이전에는 -1이었는데, 그 이유는 Redis Engine에서는 재시작이나 failover가 없었기 때문이다. Valkey로 엔진 교체를 하면서 replid가 한번 바뀌었고, 이 점이 반영되어 second_repl_offset 값이 바뀌었다.

Master: Primary Node
second_repl_offset: 이전 master_replid가 마지막으로 유효했던 offset 위치)

2.2 redis-benchmark를 통한 GET 요청(읽기) 성능 테스트

Redis Engine에서 Valkey Engine으로 마이그레이션 한 후, 간단한 성능테스트를 통해 두 엔진 간 차이를 실제로 확인해본다.
오..? 사실 크게 기대 안했는데 읽기 성능이 월등히 좋아진 점이 확인된다.

10만 건 요청을 Redis Engine에 비해서 약 6배 정도(126초 → 28초) 더 빠르게 처리한 점을 확인할 수 있다.
대부분의 요청(p99)이 46ms 정도로 처리되었고, 이 또한 이전 테스트에 비해서 약 7배 정도(280ms → 46ms) 성능이 좋아졌다.

2.3 TTL 값 확인

Redis Engine에 설정한 Key TTL이 마이그레이션 이후에도 잘 남아있는지 확인해본다.

처음 설정한 TTL 이후에 한 8시간(28,800초)이 지났으니까 Key TTL 설정값도 문제없이 마이그레이션 된 점을 확인할 수 있다..!

알게된 점

이렇게 Redis -> Valkey Engine을 직접 마이그레이션하면서 기본 정보들을 알아보았다. 실제로 직접 해보는 거랑 문서로 보는 거랑은 차이가 많이 나서, 기본적이지만 베이스가 되는 것들을 직접 살펴보니 와닿는 것도 많았다. Valkey가 진짜 성능이 좋은게 확 느껴졌다.

또 redis-cli 명령어 사용법도 익힐 수 있었고, TTL 설정이나 Primary Node의 재시작 관점도 눈여겨 볼 수 있었다. 사실 Redis/Valkey Client 변경 사항이 가장 클 것같은데... 이점은 AWS Support 미팅에서 잘 챙겨봐야겠다.

[Redis] 캐시와 Redis, ElastiCache

sebinChu — Sat, 16 Aug 2025 08:57:44 +0900

개요

이번에 ElastiCache와 관련한 하나의 에픽을 마무리하게 되었다. AWS 셀프 서비스를 위해서 작업에 집중했는데, 본격적인 사내 개발자 사용자 가이드와 안내 문서를 작성하기에 앞서 캐시와 Redis, ElastiCache, 더 나아가 Redis > Valkey 엔진별 특성/ 마이그레이션 내용을 정확히 공부하고자, 블로그 글을 통해 정리해보려고 한다.

그래서 다음과 같은 순서로 글을 쭉 작성하며 정리할 예정!

캐싱 개념 | Redis & ElastiCache
Python으로 통신하면서 단일 노드 ElastiCache 실습해보기
클러스터 모드의 ElastiCache 사용하면서 구조 파악하기
Redis, Valkey 각 엔진을 생성하고, 성능 및 비용 비교하기
Redis, Valkey 엔진별 차이점 파악하기

이번 포스팅은 첫 번째 단계로, 일단 캐싱과 Redis, ElastiCache에 대해 이해해보려 한다.

1. 메모리와 캐시

캐시는 자주 접근하는 데이터를 빠르게 제공하기 위해 임시 저장소에 보관하는 방법이다. 데이터를 매번 원본 저장소(RDB와 같은 디스크)에서 가져오면 네트워크 통신, 디스크 I/O 등의 비용이 발생한다. 이를 줄이기 위해서 조금 더 빠른 저장소에 데이터 사본을 저장해두고, 요청시 바로 꺼내쓴다.

1.1 우리가 캐시 이야기를 하면 보통 Redis를 바로 떠올리게 되는데, 그 이유는 뭘까?

먼저 로컬 캐시와 원격 캐시의 차이를 살펴보자.
웹 애플리케이션 서버에 직접 캐시를 저장해서 로컬 캐시로 사용하면, 비교적 구현이 쉽고 빠르며, 작은 작업에서는 상당한 개선 효과를 볼 수 있다. 우선 외부 I/O 통신이 없기 때문에 응답 속도가 훨씬 빠르다.

근래의 서비스들은 고가용성을 위해 동일한 서버를 2대 이상 운영하는 경우가 많다. 이때, 로컬 캐시를 이용하면 각 서버 간 데이터 정합성 문제를 일으킬 수 있다.

자주 변화하지 않는 데이터에 대한 잦은 조회는 로컬 캐시를 사용하는 것이 좋다. 각 서버 간 데이터를 실시간으로 완벽히 동기화하는 것이 요구된다면 데이터 최신화를 위한 Redis를 사용한다. [Pay Tech : 분산 시스템에서 로컬 캐시 활용하기]

1.2 캐시 주요 지표

Cache Hit Ratio
- 요청 중 캐시에서 바로 응답한 비율이다. 하나의 호출 결과를 여러 요청 또는 작업에 사용할 수 있을 경우 사용하는 게 좋다. 각 요청에서 종속 서비스에 대해 고유한 쿼리를 실행하고, 요청 별로 결과값이 달라진다면 캐시 히트 적중률이 낮으므로, 캐시를 통해 얻을 수 있는 이점이 적다.
Latency
Evictions
- 캐시는 데이터의 복사본이므로, 캐시 메모리가 부족해지면 삭제 후 나중에 다시 캐시하는 등의 작업을 수행한다. Redis에서는 Evictions 설정을 통해, 캐싱된 데이터의 크기가 메모리 크기를 초과할 때, 키를 제거하는 정책을 지정할 수 있다.
- Expiration이랑 헷갈리면 안된다! Expired는 TTL 만료로 자연 삭제된 것이고, Evictions는 메모리 부족으로 인해 정책에 따라 강제로 제거된 키를 의미한다.

rate(redis_evicted_keys_total[5m]) # 메모리 초과로 인해 삭제된 키를 5분마다 측정해서 통계
rate(redis_expired_keys_total[5m]) # TTL 만료로 인해 삭제된 키를 5분마다 측정해서 통계

1.3 캐싱 전략

캐시를 이용함에 있어서 주의 깊게 다뤄야 하는 것은 바로 데이터 정합성(캐시 일관성) 문제다. 앞서 Hit Ratio에서 언급한 것처럼, 어떤 종속 서비스에 대해서 하나의 호출 결과를 여러 요청 또는 작업에 활용할 수 있는 경우에 캐시를 쓰는 것이 좋다.

시간이 지나면서 캐싱된 데이터는 source(DB)와의 일관성이 점점 떨어진다. (cdn에서 invalidation을 하는 이유)
따라서, 원본 데이터의 변경률과 데이터 캐싱을 잘 관리해서 데이터 정합성 문제를 일으키지 않으려면 이러한 캐싱 전략이 중요하다.

캐싱 전략에는 3 가지 패턴이 있다.

캐시 읽기 전략(Read Cache Strategy)
- Cache-aside(Lazy Loading)
- Read-through
캐시 쓰기 전략(Wrirte Cachce Strategy)
- Write-through
- Write-arount
- Write-back (Write-behid)

대부분의 서비스는 Read - Write 조합을 활용한다. 캐싱 전략은 여기서 깊이 있게 다루기 보다는, 따로 정리해볼 예정이다.

2. Redis(Remote Dictionary Server)

레디스는 메모리 기반의 Key-Value 데이터 저장소다. Table 구조로 데이터가 저장되는 RDBMS와 달리, 비관계형 구조로서 데이터를 단순히 키밸류 쌍으로 저장한다.

In-memory: 데이터를 디스크가 아니라 메인 메모리(RAM)에 저장하기에, 지연 시간이 훨씬 짧고 처리량이 높다.
Remote Data Storage이기에, 여러 서버에서 같은 데이터를 공유할 수 있다.
다양한 자료구조를 지원한다. (String, Set, Hashes, List...)
쓰기 성능 증대를 위한 클라이언트 측 샤딩을 지원한다.
- Sharding: 같은 테이블 스키마를 가진 데이터(row)를 다수의 db에 분산해서 저장한다.
레디스는 기본적으로 싱글 스레드로 수행되기 때문에, 안정적인 인프라를 구축하기 위해서는 Replication 구조가 필요하다.

3. ElastiCache 살펴보기

Cluster Mode

노드는 캐시 엔진을 실행하는 서버다. 클러스터는 이러한 노드들을 모아놓은 그룹으로, 전체 캐시 시스템이다. 노드는 Primary Node와 Replica Node로 나뉘는데, 보통 Primary Node는 쓰기 전용, Replica Node는 읽기 전용으로 사용된다. 노드는 독립적으로 데이터를 가지고 있고(하나의 독립적인 인스턴스), 필요한 경우 다른 노드들과 통신한다.

하나의 샤드는 Primary Node와 Replica Node로 구성된다. Replica Node는 FailOver를 위해 Primary Node를 복제하여 대체되기도 한다. 샤드 수를 늘려서 처리량(Throughput)과 저장 용량을 증가할 수 있다. 또한, 여러 개의 Primary Node를 통해 읽기/쓰기를 분산하여 병렬 처리를 통한 이점을 얻을 수 있다.

Multi AZ(Availability Zone)

고가용성(HA) 확보를 위해 여러 Zone에 노드를 분산하는 방식이다. Primary Node와 Replica Node를 서로 다른 Zone에 배치하여, AZ 장애가 발생했을 때 대응 체계를 마련한다.

열심히 공부했던 것들이 스터디에서만 빛을 발하는 슬픈 현실;ㅠ 일단 이번에 Redis, Valkey 업무를 맡으면서 이쪽은 아예 정복을 해야겠다는 다짐을 했다. 캐쉬 이야기 2탄도 곧 작성해보겠다.

[Git] Git Rebase 학습하고 실습해보기

sebinChu — Sun, 3 Aug 2025 15:02:52 +0900

개요

git rebase를 실무에서 여러 브랜치에 적용하려니까 헷갈리는 점이 많아서 이번 기회에 git 공부를 확실히 하고자 블로그를 작성하게 되었다. 이 포스팅에서는 git 명령어 뿐만 아니라 fork라는 도구도 함께 사용하며 익힐 것!

1. git rebase

git rebase는 말 그대로 브랜치의 base를 다시(re) 설정한다. git rebase를 통해 커밋 그래프를 단순하게 가져가고, 의미 있는 커밋들만 남겨서 더 원활한 협업을 지원한다.

현재 master 브랜치의 a3 커밋을 베이스로 작업을 진행하고 있고, master 브랜치는 또 다른 작업들이 진행된 상황이다. 이 master 브랜치의 최신 작업 내용을, 내가 현재 작업 중인 feature 브랜치에도 적용하고 싶을 때 rebase 명령어를 사용한다.

보통 main 브랜치에 merge하기 이전에, rebase 작업이 요구된다. 이유는 다음과 같다.

내 feature 브랜치의 커밋을 최신 main 위로 재적용해서, 마치 main에서 방금 브랜치를 만든 것처럼 히스토리를 정리한다.
충돌 방지 & 문제가 발생하더라도 미리 rebase 과정을 통해 해결할 수 있다.
rebase -i HEAD로 커밋을 깔끔하게 정리할 수 있다.

간단하게 다음과 같은 방법으로 rebase를 할 수 있다.

# main 브랜치로 이동
git checkout main
# 최신 main 적용
git fetch origin 
git pull origin main
# feature 브랜치로 이동
git checkout feature
# main을 base로 rebase 실행
git rebase main

이 과정을 거치면 git history가 다음과 같이 정리된다.

2. fork로 rebase main 실습해보기

의도적으로 만든 상황: 그래프 잘보기ㅜ

기존 Initial commit에서 로컬 feature 브랜치가 분기
로컬 feature-001에서 작업 후 add/commit, origin push는 X
origin main 변경사항 있음!

fork에서 제공하는 git history 그래프를 잘 활용하면 좋은데, 지금 origin/main이 local/feature-001보다 앞선 상황이다. 즉, 로컬브랜치가 origin main pull 했을 당시보다 origin 작업이 진행된 것.

요기서 main에 rebase를 하면(=내 로컬 변경 사항을 오리진 main 위로 올리기)

옵션 뜻: 현재 워킹 디렉토리에 수정 사항이 있을 경우, 그것을 임시로 stash해놓고 rebase가 끝난 후 다시 적용하는 옵션으로 rebase를 안전하게 진행할 수 있게 해줌

rebase 이후에 깔끔해진 분기 모습!

이 상태에서 push --force를 내 로컬 브랜치에 하면, origin main 변경 사항 위에 커밋들이 깔끔하게 올라가는 걸 확인할 수 있다.

조금 더 깔끔하게 진행하려고 local main - orign main도 싱크 맞춰줌

rebase로 정리된 상태에서 force push 해보면

요렇게 PR을 깔끔하게 생성할 수 있다.

PR이 머지되면 rebase된 내용 또한 잘 반영되어있는 걸 확인할 수 있다.

rebase 이후에는 왜 force push를 해야할까?

Rebase는 "히스토리를 다시 쓰는 작업"이기 때문이다!

커밋 내용이 같아 보여도 커밋 ID가 새로 생성됨
그래서 기존 원격 브랜치의 히스토리와 일치하지 않음
Git은 이걸 “위험한 덮어쓰기”라고 생각해서, 기본 푸시 거부
대신 --force를 사용해서 "내 히스토리로 강제로 덮어쓰겠다" 라고 명시해야 함

3. rebase로 내 로컬 커밋 깔끔하게 정리하기(rebase -i)

(작성 예정)

4. 알게된 점

origin feature branch에 push 하기전에 main과 rebase를 하자.
main rebase 이전에는 local main - origin main 요렇게도 fetch를 하자

[AWS] CloudWatch 비용 숨바꼭질 : per metric-month

sebinChu — Thu, 19 Dec 2024 01:34:17 +0900

개요

이제 KAU 크레딧이 끝나서 운영 비용을 줄일 방법을 다시 고안 중이다.

청구서를 유심히 보다가 발견한 CloudWatch 비용...!

CloudWatch Agent를 EC2에 설치하면서 구성파일을 만든다. 이때 Agent가 수집할 내용을 설정했기에 발생하는 비용이다. 한 달에 $ 2 정도 청구되고 있는데 현재는 CloudWatch Agent를 사용하지 않으므로 설정만 깔끔하게 없애주었다!

CloudWatch Agent 파일 접근

에이전트 설정 파일 위치 : /opt/aws/amazon-clouwatch-agent/bin/config.json

파일 접근

sudo vi /opt/aws/amazon-cloudwatch-agent/bin/config.json

파일 내용 및 삭제

{
        "agent": {
                "metrics_collection_interval": 60,
                "run_as_user": "cwagent"
        },
        "logs": {
                "logs_collected": {
                        "files": {
                                "collect_list": [
                                        {
                                                "file_path": "/var/log/messages",
                                                "log_group_class": "STANDARD",
                                                "log_group_name": "koala-admin-dev",
                                                "log_stream_name": "i-0a1e93421c6feb72e",
                                                "retention_in_days": -1
                                        }
                                ]
                        }
                }
        },
         "metrics": {
                // 생략
                
                "metrics_collected": {
                   //   수집 항목 제거  
                }
        }
}
~

삭제 및 저장
- 에디터의 명령 모드에서 dd를 누르면 빠르게 지울 수 있다! ➡️ ESC 누르고, 키보드 dd 누르기
- 위 부분을 지운 뒤에 esc + ZZ로 저장하자.

변경 사항 적용 및 Agent 종료

변경사항을 적용하려면 재부팅한다. 더이상 쓸일이 없으면 종료시켜도 좋다.

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a stop
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a start

잡았다 요놈 !

[Spring] 처리율 제한(Rate Limit)으로 악의적인 공격 차단하기

sebinChu — Sat, 23 Nov 2024 17:08:22 +0900

개요

KOALA 서비스 회원가입에서는 총 2 가지의 인증이 요구된다.

이메일 인증
문자 인증

문자 인증은 1 건당 대략 20원 정도 청구된다.

만약 누군가 의도적으로 많은 요청을 보내면, 불필요한 요청이 쌓이고 비용이 지불된다.

이를 예방하기 위한 처리율 제한 기능을 추가해보자!

처리율 제한(Rate Limit)

일정 시간 내에 요청되는 최대 횟수를 제한하는 기술이다.

과도한 요청으로 인한 서비스 장애 및 피해를 방지한다.

예시

사용자가 5회 이상 잘못된 비밀번호를 입력할 경우, 15분 동안 해당 계정의 로그인 시도를 차단
초당 최대 1000명의 사용자가 접속할 수 있도록 제한하며, 초과 시 대기열에 넣거나 "사이트가 과부하 상태입니다"라는 메시지를 표시
한 사용자가 특정 API에 1초에 100번의 요청을 보내고자 할 때, 1분 동안 60회의 요청만 가능하도록 제한

처리율 제한 알고리즘

이를 구현하는 방법은 3가지가 있다.

1. 토큰 버킷 알고리즘(Tocken Bucket Algorithm) ✔️

https://www.krakend.io/docs/throttling/token-bucket/

버킷과 토큰으로 요청을 관리한다.
일정 속도로 버킷에 토큰이 채워지며, 요청이 발생할 때마다 토큰이 소비된다.
버킷 안의 토큰이 모두 소진되면 요청이 제한된다.
짧은 시간에 집중되는 트래픽(burst of traffic)도 처리 가능하다. ➡️ 버킷에 토큰이 남아있기만 하다면 시스템에 요청이 전달된다.

2. 누출 버킷 알고리즘(Leaky Bucket Algorithm)

https://www.geeksforgeeks.org/leaky-bucket-algorithm/

바구니에 물이 들어오고 구멍을 통해 일정한 속도로 물이 빠져나간다. 양동이의 물높이는 일정하게 유지되면서 물이 넘치지 않도록 설계되어 있다. ➡️ 양동이에 물이 가득차면 더 이상 물을 붓지 못하듯이, 시스템의 처리 능력을 초과하는 요청이 들어오면 새로운 요청은 거부 및 대기한다.
요청은 큐(Queue)에 저장되고 FIFO으로 요청이 처리된다.
큐 크기를 제한하여 메모리 사용량을 조정할 수 있다.
단시간에 요청이 몰리면 큐에 요청이 쌓이고, 제때 처리하지 못하면 최신 요청들은 버려지게 된다.

3. 슬라이딩 윈도우 알고리즘(Sliding Window Algorithm)

time-based! 요청이 들어오는 시간을 "윈도우"로 설정한다. ➡️ 윈도우는 고정값이 아닌 동적으로 변한다.
이 시간 범위 내에서 허용된 요청을 카운트하여 처리한다.
일정 시간 내에(슬라이딩 윈도우 안에) 요청이 초과되면 더 이상 요청을 받지 않는다.

토큰 버킷 알고리즘을 선택한 이유

① 토큰 버킷 알고리즘은 정해진 기간 동안 사용자마다 개별적인 토큰을 갖게 되고, 이를 통해 처리율을 제한한다. 리딩 버킷은 다수의 사용자를 대상으로 처리율을 제한하므로 토큰 버킷 알고리즘이 더 적합하다.

② 슬라이팅 윈도우도 마찬가지로 특정 시간 동안 모든 사용자로부터의 요청 수를 카운트하여 제한한다.

③ 유연성있는 처리율 제한을 지원한다.

// Param: (버킷에 담을 최대 토큰 개수, 버킷에 토큰을 채우는 주기)
Refill.intervally(MAX_REQUESTS_PER_DAY, Duration.ofDays(1))

이러한 구현 방식으로 토큰 생성 주기나 소비 속도를 유연하게 조정할 수 있다!

토큰 버킷 알고리즘 라이브러리

토큰 버킷을 구현하기 위한 라이브러리는 3 가지가 있다.

Bucket4j
Resilence4j
Guava LateLimiter

1. Bucket4j

Java 기반으로 구현된 처리율 제한 라이브러리다.
thread- safe하도록 구현되어 있다.
- 원자적 변수: AtomicInteger, AtomicLong과 같은 클래스를 사용해서 스레드 간의 경쟁 조건을 방지하였다.
- CAS(Compare-And-Swap) 연산: 토큰을 소비할 때 CAS 연산을 통해 현재 토큰 수를 확인하고 새로운 수로 업데이트 한다.

2. Resilence4j

MSA 등과 같은 분산 환경에서 사용하기 좋다.
Circuit Breaker, Fallback 기술을 통해 다른 모듈로 장애가 퍼지지 않도록 방지하고, 대체 처리를 하는 등 분산 환경 운영에 도움된다.
분산 환경에서의 사용을 위해 Hazelcast, Consul 등의 분산 저장소와 연동 가능

3. Guava

구글에서 제공하는 라이브러리로, 동기식 API만 지원한다.

Bucket4j를 선택한 이유

float, double 자료형을 사용하지 않고 오직 정수형으로만 연산을 처리한다.
부동 소수점 연산은 과학/공학 계산용으로 설계되어 있다. 넓은 범위의 수를 빠르게 정밀한 ‘근사치’로 계산하는 것에는 유용하지만 정확도를 요구하는 연산에서는 사용하면 안 된다. ( 정수형의 안정성에 대한 상세한 내용 )

이 라이브러리는 기본적으로 lock-free, thread-safe하도록 설계되었다. 멀티 스레딩 환경에서의 확장성이 높고, 다양한 동시성에 대응 가능하다.
해당 깃허브에서 Atomic 구현 & CAS에 대해 자세히 확인할 수 있다.

GC(Gabage Collector) 부담 최소화를 위해 boxing type 대신 primitive type을 사용한다.
(Boxing vs. Primitive에 대한 상세한 내용)

spring boot의 Interceptor 기능을 통해서 요청 처리 전후 Rate Limit 적용이 가능하다.

Interceptor - MVC Handler

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
       bu registry.addInterceptor(new MyInterceptor())
                .addPathPatterns("/**")
                .excludePathPatterns("/login", "/logout");
    }
}

Bucket4j로 처리율 제한하기

1. 라이브러리 의존성 추가

implementation 'com.github.vladimir-bukhtoyarov:bucket4j-core:7.6.0'

2. Refill, Bandwidth, Bucket class 사용

Refill refill = Refill.intervally(10, Duration.ofMinutes(1));
Bandwidth limit = Bandwidth.classic(10, refill);
Bucket bucket = Bucket.builder()
    .addLimit(limit)
    .build();

for (int i = 1; i <= 10; i++) {
    assertTrue(bucket.tryConsume(1));
}
assertFalse(bucket.tryConsume(1));

✶ 프로젝트 보안을 위해 상세 구현은 Baeldung에서 제공하는 예시 코드로 대체하도록 한다.

Refill: 토큰 리필 방식을 정의한다.
- intervally(토큰 리필 개수, 토큰 리필 주기) 메서드로 버킷을 컨트롤한다.
Bandwidth: 버킷이 허용하는 요청수와 리필 전략을 정의한다.
Bucket: 실제 요청을 처리한다.
- addLimit: 처리율 제한을 정의한다.
- tryConsume: 요청에 따른 토큰 소비를 시도한다.

실제 적용하며 발생한 문제

개선 전

요청 IP를 HttpServletRequest의 getRemoteAddr()를 통해 받았다. 이 메서드를 사용하면 클라이언트의 공인 IP 주소를 받게되는데 그게 문제 발생의 원인이었다..!

왜냐하면 해당 서비스를 이용하는 학생은 주로 항공대 학생으로,

같은 IP에 접속할 가능성이 높기 때문이다.

따라서 다음과 같이 개선하였다.

개선 후

String userRandomId = RandomUtils.getRandomString(36);

이런식으로 요청이 들어오면 랜덤값을 생성하고, 이러한 randomId를 통해 버킷을 생성함으로써 해결하였다.

[Spring] HTTP Request Client(webclient, feignclient)

sebinChu — Sun, 10 Nov 2024 22:18:01 +0900

개요

HTTP Client에 대해서는 인턴십 때 익히 알고 있었다. 당시 회사 코드는 단순한 MVC 구조가 아니라 모두 HTTP Client 요청을 날렸다. 이때 Webclient를 사용했는데, Asynchronous & Non-blocking으로 리소스 자원의 효율성을 극대화했다.

보통 front → back
회사 코드는 front → back → platform

아무튼 그렇게 첫 HTTP Client를 사용했었고.. 이후 KOALA 프로젝트에서 Feign을 접했다. 작년 10월부터 올해 7월, HTTP Client를 사용하며 노션에 정리해둔 내용을 오픈한다... 당시에 feign의 동시성 관련해서 헷갈리는 점이 너무 많았으나, 공식문서와 사례를 읽으면서 모두 정리해봤다!!

1. HTTP Request Client

HTTP 프로토콜을 사용하여 외부 API나 서비스와 통신하기 위한 기능을 제공하는 라이브러리다.

HTTP 메서드를 사용하여 서버에 요청을 보내는 기능
요청 헤더 및 본문 설정
응답 처리
오류 처리

Spring에서 HTTP Request Client를 구현하는 방법은 대표적으로 3가지가 있다.

① WebClient

② FeignClient

③ RestClient ④ RestTemplate

가 있다.

이 중, 마지막 RestTemplate은 deprecated된다는 말이 나올 만큼 선호도가 낮은 방식이므로 이 글에서는 생략한다.

궁금한 점이 있다면 이 문서를 추천한다.

2. Http Request Client를 왜 사용했는가?

KOALA 서비스 API 구현을 위해서 백준 사이트 문제를 가져와야 했었다.
문제를 가져올 수 있는 방법은 두 가지 ① 백준 사이트 크롤링 ② 직접 JSON 파싱해서 사용
- 크롤링은 법적 문제와 부하 문제가 항상 동반한다. ➡️ 실제로 백준 사이트에서도 크롤링을 법적으로 금지하고 있다.
- 백준 문제 크롤링은 응답값 자체가 복잡하고, JSON 배열에 있는 값을 일일이 파싱해서 원하는 값만 도출하는 로직이 필요하다.

백준(https://www.acmicpc.net/) 크롤링 금지 관련 공지

JSON 배열... 상당히 복잡하다.

방법을 리서치 하다가 비공식 API 문서를 발견했다! 이 비공식 문서 API를 HTTP Client로 호출하면 개발시간 단축과 효율적인 구현 가능하다. 따라서solved.ac API를 FeignClient를 통해 사용하기로 결정했다.

3. Http Request Client의 여러 구현 방식을 이해하기 위한 상식

1) Reactive Streams API

asynchronous processing with non-blokcking
비동기 스트림 처리를 위한 표준 인터페이스를 정의
Publisher, Subscriber, Subscription, Processor 등의 인터페이스를 제공하여 데이터 스트림을 효과적으로 처리
JDK 9에 포함되어 다양한 Reactive 라이브러리에서 사용

⇒ 기존의 요청-응답 방식과는 차이가 나는 스트림 형태의 데이터 처리 방식이다.

1. 데이터가 생산되면 Publisher → Subscriber에게 전달
2. Subscriber는 데이터를 비동기적으로 처리

2) Spring MVC와 Spring Webflux

Spring Webflux: Reactive Streams 기반의 웹 프레임워크로, Servlet 기반의 웹 애플리케이션 모델인 Spring MVC와는 다르다.

종류 Feign Client Web Client

종류	Feign Client	Web Client
방식	Spring MVC	Spring Webflux
모델	요청-응답 모델	Reactive Stream 기반
동작	synchronous & blocking - 클라이언트는 응답을 기다리는 동안 블로킹되어 다른 작업 불가능 (완전 불가능은 아니다. 간단한 방법이 있는데 프로젝트에 어떻게 적용했는지 뒤에 설명해보겠다.)	asynchronous & non-blocking
데이터 처리	단일 객체 또는 컬렉션 데이터 ex) 사용자가 특정 상품 정보를 요청하면 서버는 해당 상품 정보 객체 반환	Reactive Streams API를 사용하여 데이터 스트림을 처리 ex1) 실시간 주식 시세 정보 요청이 들어오면 서버는 주식 시세 데이터를 실시간으로 스트리밍 형태로 전송 ex2) 대용량 파일 다운로드 요청이 들어왔을 때, 서버는 파일 데이터를 청크 단위로 나누어 스트리밍 형태로 전송
스레드 관리	- thread pool 사용 - 각 요청마다 스레드 생성	- 적은 수의 스레드 - 논블로킹 방식의 I/O 작업

4. WebClient

Spring webflux 기반의 라이브러리, HTTP 요청을 수행하는 클라이언트가 포함되어있다. 스레드나 동시성 처리를 할 필요없이 비동기 논리의 선언적 구성이 가능하다.

“It is fully non-blocking, it supports streaming“ - docs.spring.io

→ 비동기성과 논블로킹 처리에 초점을 둔 Http Client

WebClient Configuration

@Configuration
public class WebClientConfig {

    @Bean
    public WebClient webClient(WebClient.Builder webClientBuilder) {
        return webClientBuilder
                .baseUrl("${feign.svc1.url}")
                .build();
    }
}

Webclient Interface

@Component
public class SolvedAcProblemSearchClient {

    private final WebClient webClient;

    public SolvedAcProblemSearchClient(WebClient webClient) {
        this.webClient = webClient;
    }

		// 빌더 패턴
    public Mono<ProblemResponse> searchProblems(int page, String query, String sort, String direction) {
        return webClient.get()
                .uri(uriBuilder -> uriBuilder
                        .queryParam("page", page)
                        .queryParam("query", query)
                        .queryParam("sort", sort)
                        .queryParam("direction", direction)
                        .build())
                .accept(MediaType.APPLICATION_JSON)
                .retrieve()
                .bodyToMono(ProblemResponse.class);
    }
}

5. FeignClient

Spring MVC 기반의 HTTP 클라이언트 구현체다. 선언적 방식의 웹 서비스 클라이언트로, 쉽게 웹 클라이언트를 생성할 수 있다. → 동기식 처리/블로킹 방식

Netflix에서 개발된 Http Client Binder → Spring Cloud 진영에 통합되면서 spring-cloud-starter-openfeign로 사용
HTTP 요청을 추상화/표준화하는 과정의 복잡성을 줄이기 위해 만들어졌다.
- 웹 서비스 클라이언트 구현이 쉽고 직관적이다. 이건 써보면 안다.. 사용성이 월등히 높은게 느껴진다! 익숙한 Spring MVC 구조를 가지고 있으며 어노테이션으로 개발이 가능하다. 참고로 WebClient는 빌더 패턴으로 구현하고, 각각의 메서드 파라미터를 유의해야 한다. (실제로 인턴십 중에 platform으로 요청하는 client를 짜면서 URL 관련 문제로 허둥댄 적이 있다..) 아래 코드 예시를 보자.
- API의 Restfulness에 관계없이 일관된 방식으로 API 호출 가능하다. (비표준적인 URL 구조나 HTTP 메서드 등을 사용하더라도 표준화된 방식으로 API 호출이 가능하다.)

예시 코드를 통해 간단하게 둘의 구현 비교(좌: webclient 우:feignclient)

FeignClient와 동시성 처리

Feign과 동시성을 이해하는 것에 많은 어려움이 있었다. 여기에 작성하면 너무 길어져 노션 링크로 대체한다.

Feign을 사용할 사람이라면 한 번 읽어보는 것을 추천한다!

결론만 공유하면 다음과 같다.

1. feign의 내부 구현이 자바 11 HttpClient, 자바 17에서의 synchronized → reentrantLock로 변경되면서 많은 부분이 해결됨
2. 블로그 구현 방식도 괜찮은 부분이 있다. Apache Client 등을 사용 → 안정적
3. 동시성 문제를 일으킬 만큼 다량의 스레드를 쏟아내는 로직 자체를 feign과 함께 만나기가 어려움 → 동시성이 걱정되는 로직이 있다면 webclient를 쓰면 됨

Feign을 구현하기 위해 공부하면서 "동시성 문제가 있을 수 있다고....?"에서부터 출발하였고, 결론은 위와 같다.

우리 서비스는 단 하나의 호출만 했고, 확장 가능성을 고려해도 동시성 문제가 우려될 만큼의 외부 API 호출 기능이 도입되지 않을 것이다. Feign을 통해 구현하면 사용 편의성뿐만 아니라 Spring의 Scheduler와 @Async를 활용한 비동기 요청이 가능한 구조로 설계할 수 있다. 따라서 사용 편의성과 비동기 처리를 모두 갖춘 Feign을 선택했다!

6. FeignClient 사용방법

6-1. FeignClient 활성화

Application 단에 @EnableFeignClients 적용 → Feign 클라이언트를 찾아서 자동으로 등록

6-2. 의존성 추가

implementation 'org.springframework.cloud:spring-cloud-starter-openfeign:4.0.0'

6-3. Feign용 Conf Class

@Configuration
public class FeignClientConfig {

  @Bean
  Request.Options requestOptions() {
    return new Request.Options(5, TimeUnit.SECONDS, 3, TimeUnit.SECONDS, false);
  }

  @Bean
  Retryer retry() {
    return new Retryer.Default(500, 1000, 2);
  }

  @Bean
  Logger.Level feignLoggerLevel() {
    return Level.ALL;
  }

  @Bean
  public RequestInterceptor requestInterceptor() {
    return requestTemplate -> {
      requestTemplate.header("Content-Type", "application/json");
      requestTemplate.header("Accept-Encoding", "gzip");
    };
  }
}

✶ RequestInterceptor

Feign 클라이언트에서 HTTP 요청을 보내기 전에 HTTP 요청을 수정할 수 있는 인터페이스

6-4. @FeignClient 인터페이스

@FeignClient(name = "solvedAc", url = "${feign.solved-ac.url}", configuration = FeignClientConfig.class)
public interface SolvedAcClient {

    @GetMapping("/search/problem")
    ProblemResponse searchProblems(
        @RequestParam("page") int page,
        @RequestParam("query") String query,
        @RequestParam("sort") String sort,
        @RequestParam("direction") String direction
    );
}

개별 Feign Client에 적용할 인터페이스
사용할 이름과 요청 url은 하드코딩하지 않고 YAML 파일에 정의 → 유연성/재사용성/관리 용이/보안

6-5. 호출

이렇게 요청할 API와 관련한 인터페이스를 정의하고,
서비스 함수에서 사용할 특정 FeignClient interface에 대한 의존성 주입 + 호출만 하면 구현 끝이다.
간단하죠

public class CreateAlgorithmService {

  private final SolvedAcClient solvedAcClient;
  private final AlgorithmRepository algorithmRepository;
  private static final int NUMBER_PER_PAGE = 30;

  public void createAlgorithm() {
    AlgorithmResponse initResponse = solvedAcClient.searchAlgorithm(1);
    int pageCount = initResponse.getCount() / NUMBER_PER_PAGE + 1;

    for (int page = 1; page <= pageCount; page++) {
      log.info("{}번 페이지 알고리즘 저장", page);
      AlgorithmResponse algorithmResponse = solvedAcClient.searchAlgorithm(page);
      List<AlgorithmDto> algorithmDtoList = algorithmResponse.getAlgorithmList();

      List<Algorithm> algorithmList = new ArrayList<>();
      for (AlgorithmDto algorithmDto : algorithmDtoList) {
        algorithmList.add(algorithmDto.toEntity());
      }
      algorithmRepository.saveAll(algorithmList);
    }
  }
}

6-7. 결과

7. 느낀점

- webclient가 web flux로부터 나와서, fully asynchronous & non-blocking에 유의하자.

인턴십 사례처럼...

요청은 synch로 받더라도 이 요청을 실제로 처리하는 platform 서버로는 비동기식으로 요청 및 처리를 하게 되는 구조
⇒ 이런식의 전략이 필요할 때 webclient를 사용하는 것이지 간편하다고만 해서 사용하면 안 되는 것을 알았다.

- 블로그는…. 내용의 질도 중요하지만 날짜도 중요하다.
계속해서 개선이 되고 있는 기술은 이전에 작성된 블로그와 맞지 않는 부분이 많기에 주의해야 한다. 또, 한 번 오개념이 작성된 블로그가 뜨면 그 오개념을 여러 사람이 따라가고, 이게 AI 답변에도 영향을 준다고 느꼈다. 최대한 공식적으로 작성된 기술 문서를 참고하고, 그 기술이 나온 기반과 배경을 따라가면 유추할 수 있는 부분이 있다. 그걸 해석하는 능력 또한 개발에 있어서 중요하며, 이를 함양하기 위해 노력해야 한다.

지식의 확장은 곧 나의 확장 !

[Network] 네트워크 원리(6) 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다

sebinChu — Tue, 5 Nov 2024 21:40:40 +0900

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

STORY 1 | 서버의 개요

1-1) 클라이언트와 서버의 차이점

서버 머신은 용도에 따라 다양한 OS, 하드웨어가 있다. 하지만 네트워크에 관한 부분( LAN 어댑터, 프로토콜 스택, 소켓 라이브러리 등)의 기능은 클라이언트와 서버가 같은 구졸르 갖는다.

→ TCP/IP 기능은 하드웨어나 OS가 무엇이든지 달라지지 않기 때문에 기능이 통일되어 있다고 봐도 무방하다.

■ 그렇다면 차이점은?

소켓 라이브러리의 connection과 데이터 송수신
서버 애플리케이션은 동시에 다수의 클라이언트 PC와 대화
- 하나의 프로그램으로 여러 클라이언트를 다루는 것은 X. 보통은 1:1로 대화

1-2) 서버 애플리케이션의 구조

(b): 클라이언트가 새로 접속할 때마다 잇달아 기동되며, 서버와 클라이언트가 일대일로 대응한다.
서버는 소켓을 미리 만들어 두고 접속 대기 상태로 변경한다.

1-3) 서버측의 소켓과 포트번호

■ 서버의 연결과정

[디스크립터] 소켓 작성
[bind] 소켓에 포트 할당
[listen] 대기 상태라는 정보를 기록
[accept] 소켓 복제 후, 접속을 접수하는 대기

■ 접수를 기다리는 첫 소켓은 계속 복제용으로 사용된다.

접속 대기 중인 상태에서 accept를 호출하고, 클라이언트의 요청을 받을 때 클라이언트의 소켓과 접속하기 위한 소켓은 접속 대기 중인 소켓을 복제해서 만든다.

새소켓을 만들지 않고 접속 대기 소켓을 그대로 사용하면, 다음 클라이언트가 접속할 때 곤란해진다.
이러한 사태를 막기 위해 소켓은 항상 복제해서 사용된다.

■ 접속 대기 중인 소켓을 복제해서 쓰면 포트 번호는 어떻게 구분할까?

포트 번호는 소켓을 식별하기 위해 사용되는 것이다. 하지만 소켓들이 모두 다른 포트 번호를 사용하는 것은 아니다. 소켓은 총 4 가지 정보를 통해 식별된다.

scr IP
scr Port
des IP
des Port

*서버 측의 포켓에는 같은 포트 번호를 가진 여러 개의 소켓이 존재한다. 하지만 클라이언트 측의 소켓은 모두 다른 포트 번호를 할당하므로, 클라이언트 측의 포트 번호에 따라 소켓을 지정할 수 있다.

STORY 2 | 서버의 수신 동작

2-1) ⭐️⭐️LAN에 데이터가 도착했을 때

(도착한 패킷의) 프리앰블 부분에서 클록을 추출한다.
추출한 클록을 같은 간격으로 연장한다.
- 프리앰블은 신호가 일정 간격으로 규칙적으로 변화한다. 변화의 타이밍을 조사하면 클록이 어느 위치에 있는지 알 수 있다.
클록이 위치한 곳을 찾고, 여기서 데이터 신호의 변화 방향(+,- 전압)을 조사한다.
이 변화방향을 통해서 디지털 신호(1,0)로 바꾼다.

*클록: 타이밍 신호를 제공하는 것. 딱 이 시점에 데이터를 전송하면, 온전한 데이터 전송이 가능하다.

■ 전기 신호 → 디지털 데이터를 추출하고…

패킷의 맨 마지막에 있는 프레임 체크 시퀀스(FCS)를 통해 오류 유무를 검사한다.
패킷 맨 앞의 MAC 헤더의 수신처를 조사해서 자신이 이 패킷의 수신처가 맞는지 확인한다.
- 이더넷의 원리에 따르면 일단 패킷 뿌리고 받는 쪽이 확인하는 구조
이 디지털 데이터를 LAN 어댑터 내부의 버퍼 메모리에 저장한다.
CPU는 다른 일을 하고 있기에 인터럽트로 패킷이 도착했음을 알린다.

■ 인터럽트가 실행된 CPU는

실행하고 있던 작업을 중단하고 LAN 드라이버로 실행을 전환한다.
LAN 드라이버가 버퍼에 있는 패킷을 추출하고, MAC 타입에 따른 프로토콜을 판별한다.
프토로콜을 처리하는 장치를 호출한다.
IP 프로토콜이라면 TCP/IP의 프로토콜 스택을 호출하고, 패킷을 건네준다.

2-2) IP 담당 부분의 수신 동작

대상이 자신인지 주소를 확인한다.
Fragmentation에 대해 확인한다. 만약, 분할되어 있는 경우에는 임시로 메모리에 저장해두고 분할된 패킷이 모두 도작한 시점에 조립한다.
IP 헤더의 프로토콜 항목(TCP or UDP)을 조사후, 담당 부분에 패킷을 건네준다.

2-3) TCP 담당 부분이 접속 패킷을 수신했을 때 (3way-handshaking)

■ 서버 측에서 대기 중인 소켓을 확인한다.

TCP 헤더의 SYN = 1이면, 접속 접수 동작을 뜻한다. 따라서 해당 패킷과 같은 포트 번호를 가진 대기 상태의 소켓이 있는지 확인한다. 만약 없으면 그 포트 번호에 해당하는 대기중인 서비스나 프로세스가 없다는 뜻으로, 오류를 통지한다.

예를 들어서 서버 포트는 80인데 클라이언트가 81로 요청해서, 서버의 81에는 대기 중인 소켓이 없는 상황

■ 대기 중인 포트를 가진 소켓을 확인했다면 패킷을 복사하여 소켓을 만들고 TCP 헤더를 만든다.

대기 중인 소켓의 복제본을 만들고, 여기에 필요한 정보를 기록한다. 동시에 메모리 영역을 확보한다.
패킷을 받았음을 나타내는 ACK, 시퀀스 번호, 윈도우 값 등을 기록한 TCP 헤더를 만든다.
만들어진 TCP 헤더를 IP 담당 부분에 보내고, 클라이언트에 반송한다.
클라이언트는 다시 ACK를 보내고, 접속 동작이 완료된다.

2-4) TCP 담당 부분이 데이터 패킷을 수신했을 때(전송 과정)

■ TCP 담당 부분이 수신하는 과정

4 가지 정보를 통해 제대로 도착한 건지 확인한다.
패킷을 통해 데이터 송수신 진행 상황과 TCP 헤더 정보를 확인하고, 데이터 송수신이 올바르게 동작하고 있는지 점검한다.
분할된 패킷이라면 수신 버퍼에 저장한다. 지난 번 패킷에서 수신한 데이터 조각의 다음에 연결하는 식으로 데이터가 분할되기 전의 상태로 되돌린다.
이 과정을 통해 수신 버퍼에 데이터가 저장되면 응답용 TCP 헤더를 만든다.
ACK를 기록하고, IP 담당 부분에 의뢰하여 클라이언트에게 반송한다.

■ 애플리케이션이 소켓을 받는 과정

애플리케이션이 소켓 라이브러리 호출을 통해 데이터를 기다리는 상태를 유지한다.
TCP 담당 부분이 수신 동작이 끝나는 것과 동시에 애플리케이션에게 데이터를 건네준다.
제어는 애플리케이션으로 넘어가고, HTTP request 내용을 확인한다.
브라우저에 데이터를 반송한다.

2-5) 연결 끊기(4 way handshaking)

■ 서버측에서 연결 끊기를 요청하는 상황이라면

애플리케이션이 소켓 라이브러리의 close()를 호출한다.
TCP 담당 부분이 FIN = 1을 설정한 TCP 헤더를 만들고, IP 담당 부분에 전송한다.
IP 담당 부분은 클라이언트에 이를 보낸다.
클라이언트는 ACK를 반송하고, close()를 계속 호출하며 FIN을 보낸다.
서버가 ACK를 반송하고, 연결이 끊긴다.

STORY 3 | 웹서버 SW가 리퀘스트 메시지의 의미를 해석하고 이에 응한다.

3-1) 조회의 URI를 실제 파일명으로 반환한다.

■ 웹 서버의 경우, read에서 받은 데이터의 내용이 HTTP Request Message다.

Request Message에 따라 적절한 처리를 실행하여 응답 메시지를 만든다.

■ URI에 기록된 경로는 가상 디렉토리 구조에서의 경로명이다.

Like… ubuntu 심볼릭 링크처럼,

파일을 읽어올 때 가상 디렉토리와 실제 디렉토리의 대응 관계를 조사하고 실제 디렉토리의 경로명으로 변환한 후 파일을 읽어 데이터를 반송한다.

3-2) CGI 프로그램을 작동하는 경우

■ 웹 서버에서 프로그램을 작동시키는 경우

단순히 HTTP의 리퀘스트 메시지가 HTML 문서에 액세스할 때와는 다르다. 웹 서버에서 프로그램을 작동시키는 경우, 프로그램에서 처리하는 데이터를 HTTP 리퀘스트 메시지 안에 넣어 브라우저에서 웹 서버로 보내는 것이 일반적이다.

■ 리퀘스트 메시지를 보낸 웹 서버의 동작

URI에 쓰여있는 파일명을 통해 이게 프로그램인지 판단한다.
예를 들어 .php, .exe와 같은 확장자를 등록해두고, 파일명의 확장자가 이와 일치하면 프로그램으로 간주한다.
프로그램이라고 판단되면 웹 서버는 이 프로그램을 작동시키도록 OS에 의뢰한다.
리퀘스트 메시지에서 받은 데이터를 작동시킨 프로그램에 전송한다.
프로그램은 받은 데이터를 처리하여 출력을 웹 서버에 돌려준다. ← 웹 서버는 이에 관여 X

3-3) 웹 서버로 수행하는 액세스 제어

■ 특정 부서, 특정 사용자 등 조건에 따라 접근을 제어하는 액세스 제어

주로 다음 세 가지에 적용한다.

클라이언트의 주소
클라이언트의 도메인명
- DNS 서버를 이용해서 IP 주소 조사
사용자명과 패스워드
- 서버에 사전 등록
- 클라이언트에게 입력하라는 Request 통지
- 클라이언트가 입력한 내용과 사전 등록된 암호를 비교 대조

3-4) 응답 메시지를 되돌려 보낸다.

■ 클라이언트의 요청에 대한 응답을 되돌려 보낸다.

이때 동작 방식은 클라이언트가 Request한 것과 같다.

소켓 라이브러리의 wirte를 호출하여 응답 메시지를 프로토콜 스택에 건네주고, 디스크립터를 통해 통신에 사용되고 있는 소켓 통지

STORY 4 | 웹 브라우저가 응답 메시지를 받아 화면에 표시한다.

4-1) 응답 데이터의 형식을 보고 본질을 파악한다.

웹 서버가 전송한 응답 메시지는 다수의 패킷으로 나뉘어 클라이언트에게 도착한다. 클라이언트는 이를 받아, LAN에서 디지털 신호로 변환하고, 프로토콜 스택이 분할된 패킷을 모아서 원래의 응답 메시지로 되돌린 후 브라우저에 건네준다.

■ 브라우저가 화면 표시를 할 때는 데이터 유형에 따라 달라진다.

웹에서 취급하는 데이터는 문장, 화상, 음성, 영상 등 다양하고 종류에 따라 표시 방법이 다르다.

■ ‘Content-Type’ 헤더를 통해 데이터 종류를 미리 파악한다.

응답 메시지의 맨 앞의 Content-Type 헤더로 종류를 파악하는 것이 원칙이다. 여기에는 다음과 같은 형식의 데이터 종류를 쓴다.

Content-Type: text/html (주타입/서브 타입)

이 예시와 같이 데이터의 종류가 텍스트인 경우에는 어떤 문자 코드를 사용하는지 판단해야 한다. 따라서 다음과 같이 charset으로 문자 코드의 정보를 부가한다.

Content-Type: text/html; charset = utf-8

*Content-Type에 정의되는 데이터 종류는 MIME 사양에 규정되어 있다. 파일 확장자나 데이터 내용의 포맷 등에서 종합적으로 판단하는 방법도 있다. 예를 들어 .html 이라면 HTML 문서로 간주하거나 문서의 젤 앞부분을 보고 <html>이라고 되어 있으면 HTML 이라고 간주한다.

■ ‘Content-Encoding’ 헤더를 통해 데이터 변환에 대해 조사한다.

압축 기술이나 부호화 기술에 따라 원래 데이터를 변환하고 나서 메시지에 저장한 경우에는 어떤 변환을 했는지 이 Content-Encoding 헤더에 기록하고, 응답을 받은 브라우저는 이 필드를 조사하여 필요에 따라 데이터를 원래대로 되돌린다.

4-2) 브라우저 화면에 웹 페이지를 표시하여 액세스를 완료한다.

데이터 종류가 판명되면 종류에 따라 화면 표시 프로그램을 호출하여 데이터를 표시한다.

■ HTML

[기본 html을 화면에 표시]

html의 경우 문장의 레이아웃이나 글꼴의 종류 등을 기록한 태그가 내장되어 있으므로 태그의 의미를 해석하여 문장을 배치하면서 화면에 표시한다. 실제 화면 표시 동작은 OS가 담당하므로, OS에 대해 화면의 어떤 위치에 , 어떤 문자를 어떤 글꼴로 표시할 것인지 지시하는 것이다.

[화상 데이터가 포함된 경우]

HTML 문서 데이터와 화상 데이터를 별도의 파일에 저장하고, html의 문장 데이터 안에 화상이 내장되었음을 나타내는 태그를 사용해야 한다.

[애플리케이션 데이터의 경우]

플러그인이든 독립된 애플리케이션이든 호출 프로그램이 브라우저에 설정되어 있으므로, 그에 따라 프로그램을 호출하여 데이터를 브라우저에 건네고, 이를 화면에 표시한다.

드디어 네트워크 스터디가 끝났다...!! 중요한 내용이니까 앞으로 복기 잘 하자!

[Network] 네트워크 원리(5) 서버측의 LAN에는 무엇이 있는가?

sebinChu — Thu, 24 Oct 2024 00:41:41 +0900

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

Chapter 5 - 방화벽과 캐시 서버의 탐험

STORY 1 | 웹 서버의 설치 장소

1-1) 사내에 설치

클라이언트의 POP/프로바이더로부터 오는 패킷을 방화벽에서 한 번 거르는 방법이 보편화되어 있다.

특정 서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외 패킷은 모두 차단한다.
액세스를 허가한 애플리케이션에 보안 구멍이 있을 수 있지만, 클 to 서구조에 비하면 위험성이 낮다.
현재는 이 구조를 빠져나가는 다양한 수법이 많이 생겨셔 더불어서 바이러스 검사, 부정 침입 검사 등의 구조를 함께 사용한다.

1-2) 데이터 센터에 설치

데이터 센터로부터 서버를 빌리는 형식

데이터 센터는 프로바이더의 중심인 NOC에 접속되어 있거나, IX와 직접 연결되어 있기도 해서 고속 접근이 가능하다.
내진 구조의 건물 / 자가 발전 장치 / 24시간 관리되는 시설이 많으므로 안정성이 높다.

STORY | 방화벽의 원리와 동작

2-1) 패킷 필터링형이 주류이다

네트워크 상에는 다양한 패킷이 흐르므로… 이를 분별하는게 쉽진 않았다.
→ 패킷 필터링이 성능, 가격, 편의성 등에서 가장 많이 보급되었다.

2-2) 패킷 필터링의 조건 설정 개념

패킷의 헤더 통신과 관련한 여러 제어 정보가 있다. 이 헤더로 필터링한다.

■ 사내 랜과 공개 랜이 분리되어 있고, 웹 서버에서 인터넷측에 액세스하는 것을 금지하고 있는 상황에서 패킷의 움직임

송수신처 IP 주소로 시종점을 판단한다.
인터넷 → 웹 서버로 보내는 패킷의 송신처(시작점)은 정확히 알 수 없다. 하지만 종점이 웹 서버라는 점이 명확하므로, 시점이 어디든 상관없이 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다는 조건을 설정하면 된다.
받은 패킷에 대한 ACK(수신 확인 응답)을 보낸다.

2-3) 애플리케이션을 한정할 때 포트 번호를 사용한다

수선처의 IP 주소 + 포트 번호를 함께 확인해서 일치하는 패킷만 통과하도록 한다.

2-4) 컨트롤 비트로 접속 방향을 판단한다 - TCP의 SYN, ACK

TCP를 사용하는 웹은 양방향으로 패킷이 흐른다.

그래서 단순히 웹 서버 → 인터넷으로 흐르는 패킷을 정지시키면, 인터넷 → 웹 서버 액세스 동작도 정지된다.

■ 웹 서버 → 인터넷 통신 막기

패킷의 액세스 방향을 판단하여 정지시켜야 하는데, 이를 TCP 헤더의 컨트롤 비트로 판단한다.

TCP의 최초의 패킷만 SYN=1, ACK=0이 헤더에 설정된다. 따라서 이 헤더의 컨트롤비트 값을 확인하고, 최초의 패킷이면서 수신처가 인터넷, 송신처가 웹 서버라면 이것을 차단하도록 설정한다. 그럼 최초의 패킷에 대한 전송이 실패하고 그에 따라 두 번째 SYN, ACK를 받을 수 없으므로 TCP connection에 실패하여 통신이 불가능해진다.

■ 인터넷 → 웹 서버 패킷은?

최초의 패킷은 수신처가 웹 서버이고 컨트롤 비트를 확인했을 때 최초의 패킷이므로 패킷 필터링을 통과한다. 두 번째 패킷은 송신처가 웹 서버이지만 컨트롤 비트 값이 바뀌었기에 최초값으로 추정되지 않고 패킷 필터링을 잘 통과하여 통신에 성공한다.

■ UDP는 TCP와 달리 접속관계(SYN, ACK)가 없어서 액세스 방향 판단이 불가능하다.

어느 정도 위험을 각오한 상태에서 애플리케이션의 패킷을 전부 통과
불편을 감수하고 애플리케이션을 전면적으로 차단

2-5) 사내 LAN에서 공개 서버용 LAN으로 조건 설정

사내 LAN ↔ 공개 서버용 LAN 각각의 IP 주소를 양쪽 모두 잘 설정해주어야 한다.

❓ 2-6) 밖에서 사내 LAN으로 액세스 할 수 없다

■ 패킷 필터링형 방화벽은 주소 변환의 기능도 가지고 있다.

사내 LAN ↔ 인터넷을 왕래하는 패킷은 주소 변환이 필요하다. 인터넷에 있는 라우터는 Private 주소를 테이블에 등록하지 않기 때문이다. 따라서 이 구조의 패킷 통신에서는 주소 변환이 필요하다. → 주소 변환을 할 지/ 하지않을 지에 대해 설정해주면 된다.

패킷 필터링형 방화벽의 내장 라우터는 Private 주소도 OK.

2-7) 방화벽을 통과한다

조건에 따라 차단 대상이 된 패킷은 버리고, 버린 기록을 남긴다. 이를 분석하여 침입자의 수법 확인, 향후 부정 침입에 대한 대책 등으로 보안을 강화한다.
통과된 패킷의 중계 동작은 라우터의 동작과 같다. → 라우터에 부가기능을 넣은 것과 같다고 생각하자.

2-8) 방화벽으로 막을 수 없는 공격

■ 웹 서버에 취약점이 있어 특수한 데이터를 포함한 패킷을 받으면 서버가 다운되는 상황일 때

방화벽에 설정한 송수신 IP와 포트만 확인한다. 패킷의 데이터는 전혀 고려하지 않기에 방화벽은 이러한 구조에 대처할 수 없다.

대처법은?

웹 서버의 취약점/버그 고치기
패킷 내용을 조사하여 해당 데이터가 포함된 패킷을 차단하는 장치를 별도로 두기
미지의 위험성은 완벽히 대처하기 어렵다

STORY 3 | 복수 서버에 리퀘스트를 분배한 서버의 부하 분산

3-1) 처리 능력이 부족하면 복수 서버로 부하 분산된다

■ 서버에 액세스가 증가할 때

회선을 빠르게 하기 → 서버의 처리 능력이 따라잡지 못할 수 있다.
서버 머신을 고성능으로 교체하기 → 한계가 있다.
⇒ 복수 서버를 사용하여 서버 한 대당 처리량을 줄인다.

■ 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄인다.

DNS 서버에서 분배

DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록한다. DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 되돌려 준다. ⇒ 라운드 로빈
1. 192.0.2.60 → 192.0.2.70 → 192.0.2.80
2. 192.0.2.70 → 192.0.2.80 → 192.0.2.60
3. 192.0.2.80 → 192.0.2.60 → 192.0.2.70
DNS는 웹 서버의 상태를 확인하지 않고 중계만 하므로, 웹 서버가 중단/고장된 상황에 대응하기 어렵다.
라운드 로빈을 통해 웹 서버를 분배하면 웹 사이트의 연속성이 끊긴다. 예를 들어서, 첫 번째 페이지에서 성명 입력 후에 두 번째 페이지에서 신용카드 번호를 입력하는 케이스가 있다.
TO-DO : GCP LB 라운드 로빈….

3-2) 부하 분산 장치를 이용해 복수의 웹 서버로 분할된다

부하 분산 장치 IP를 웹 서버 IP 대신 DNS에 등록한다.

■ 대화가 복수의 페이지에 걸쳐있다면…

HTTP stateless: HTTP의 기본 동작은 먼저 Request Message를 보내기 전에 TCP 연결을 하고, 전송이 끝나면 연결을 끊는다.
Cookie: HTTP 전후 관계를 파악하기 위한 값을 HTTP 헤더 필드에 부가하는 방법이 고안되었다.

STORY 4 | 캐시 서버를 이용한 서버의 부하 분산

4-1) 캐시 서버의 이용

■ 캐시 서버는 프록시 구조를 사용하여 데이터를 캐시에 저장하는 서버다.

캐시 서버는 웹 서버의 데이터를 디스크에 저장한다. 이후, 클라이언트에서 요청이 오면 이를 확인해서 바로 송신한다. 즉 데이터를 읽고 송신만 하므로 서버보다 빠르다.

■ 캐시 서버 또한, 부하 분산처럼 웹 서버 대신 DNS에 캐시 서버 IP를 등록한다.

4-2) 캐시 서버는 갱신일로 콘텐츠를 관리한다

■ 두 가지 케이스

저장되어 있든 없든, 일단 리퀘스트를 전송하는 것까진 동일하다!

■ 데이터가 캐시 서버에 저장되어 있지 않은 경우

헤더 중에 Via 필드 & URI의 디렉토리(어떤 웹 서버에 캐시 정보를 요청해야 할 지 판단)→ URI의 디렉토리를 보고, 리퀘스트 주인이 어느 웹 서버인지 판단하여 소켓 통신을 한다. → 캐시 서버는 요청을 받으면 ‘Via’ 헤더 필드를 추가하여 웹 서버에 리퀘스트를 보낸다.

캐시에 데이터가 없으면 ‘If-Modified-Since’를 추가하지 않고 그대로 요청을 보내서 웹 서버는 데이터를 그대로 전송해준다. 이후, 캐시 서버는 이 내용들을 캐시로 저장해둔다.

■ 데이터가 캐시 서버에 저장되어 있는 경우

‘If-Modified-Since’ 필드를 통해서 캐시: “이때의 값을 디스크에 저장하고 있다.” 라고 알린다. 서버는 이 값을 확인하고, 변경이 없었던 경우에는 304 Not Modified를 보내준다. → 이때 서버는 데이터의 최종 갱신 일시를 조사하는 것으로 끝나고, 응답 메시지 내용도 짧아서 부담이 훨씬 적어진다.

데이터가 변경된 경우, 웹 서버는 최신 데이터를 반송한다. 캐시서버는 ‘Via’ 헤더를 추가하여 사용자에게 전송하고 데이터를 캐시에 저장한다.

4-3) 프록시의 원점은 포워드 프록시다

■ 포워드 프록시는 클라이언측에 두는 캐시 서버로, 프록시 서버의 원형이다.

처음 포워드 프록시가 등장했을 때는 방화벽을 실현하는 목적이 있었다. 앞서 패킷 필터링형 방화벽은 단순히 IP주소와 포트로 패킷 송수신을 제어한다. 그러면 패킷의 내용 등에 대한 보안 설정을 하기에 어려움이 있다. 이를 해결하기 위해서 포워드 프록시를 방화벽으로 사용한 것이다.

→ 프록시는 리퀘스트의 내용을 조사한 후 전송하므로 리퀘스트의 내용에 따라 액세스가 가능한지 판단할 수 있다.

■ 포워드 프록시를 사용할 때에는 브라우저 설정 화면으로 세팅한다.

보통 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정한다.

포워드 프록시를 설정하면 URL과 상관없이 모든 요청이 포어드 프록시로 들어오며, http://….를 그대로 request에 작성한다. → 캐시 서버와 같이 어느 서버에 보낼 지 판단하지 않아도 되고, 모든 웹 서버에 전송할 수 있다.
포워드 프록시를 설정하지 않으면 http://…..에서 웹 서버의 이름을 제외하고, 파일이나 프로그램의 경로명의 일부를 추출하여 이것을 리퀘스트의 URI 부분에 기록한다.
URL과 URI의 차이 ⇒ URL은 요청을 보낼 서버의 주소를 찾는 거고, URI는 해당 주소에서 이 요청을 처리하는 방을 찾는 것

4-4) 포워드 프록시를 개량한 리버스 프록시

■ 포워드 프록시를 사용하기 위해 반드시 해야하는 브라우저 설정은 수고나 장애의 원인 및 제약사항이 된다.

이에 따라 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 개량되었다. 즉, URI에 http:// … 이 부분을 모두 적지 않아도 리퀘스트 메시지를 보낼 수 있다.

■ 포워드 프록시 vs. 리버스 프록시

목록 포워드 프록시 리버스 프록시

설정	브라우저에 직접	프록시 서버 IP를 DNS에 등록
URI 형식	‘http://….’ 모두	URI 경로만 → 클라이언트가 URI의 세부 정보를 입력하지 않고도 서비스에 접근할 수 있도록 도움. 즉, 서버의 요청 중개
위치	클라이언트와 서버 사이에	서버 측에
활용	보안, 캐싱 등	부하 분산, 종료, SSL 등

4-5) 트랜스페어런트 프록시

■ 패킷의 IP 헤더를 조사하여 액세스 대상 웹서버를 알아내는 방법을 트랜스페어런트 프록시라고 한다.

보통의 리퀘스트 메시지와 같이 요청값을 작성할 수 있어서, 포워드 프록시처럼 브라우저에 설정할 필요가 없다. 또한, 리버스 프록시처럼 프록시 서버 IP를 DNS에 등록하는 것이 아니다. 따라서 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치한다.

STORY 5 | 콘텐츠 배포 서비스

5-1) 콘텐츠 배포 서비스를 이용한 부하 분산

■ 캐시 서버를 놓는 장소가 어디인지에 따라 장단점이 있다.

서버 쪽에 배치
- 웹 서버 부하만 억제, 인터넷 트래픽 X
클라이언트 쪽에 배치
- 혼잡에 휘말려드는 일이 없으므로, 패킷의 흐름이 안정된다.
- 클라이언트 측의 네트워크 관리자가 소유하므로, 웹 서버 관리자가 접근할 수 없다.
양쪽의 장점을 활용
- 클라이언트 측의 프로바이더에 캐시 서버를 두고, 이를 서버 관리자가 컨트롤 할 수 있다.
- 인터넷 트래픽을 억제하는 효과 + 웹 서버 관리자가 캐시 서버를 관리할 수 있다
- 인터넷에 공개하는 서버는 인터넷의 어디에서 액세스하는지 알 수 없다. 따라서 이 방법을 실행하기 위해 프로바이더의 POP 전부에 캐시 서버를 설치해야 하므로 비현실적이다. 이를 해결하기 위해 CDS 방법을 쓴다.

■ CDS(Content Delivery Service)

캐시 서버를 설치하고, 웹 서버 운영자에게 대출하는 서비스다. 이 서비스를 제공하는 사업자는 프로바이더와 계약해서 캐시 서버를 설치하고, 이를 판매한다. CDSP가 설치한 캐시 서버는 여러 웹 서버 운영자가 공동으로 이용 가능하다.

5-2) 가장 가까운 캐시 서버의 관점

■ DNS 동작 방식과 라우팅 테이블을 활용한다.

인터넷에 총 4개의 캐시 서버가 있다고 가정했을 때, 각각 장소의 라우터에서 경로 정보를 모아둔다. 이 각각의 라우터에서 경로 정보를 모아 DNS 서버에 저장한다.
이 테이블로 DNS 메시지의 송신처(클라이언트)에 이르는 경로를 조사한다. (DNS 연대로 조사)
모든 라우터에 대해 조사하고 비교하면 어느 캐시 서버의 라우터가 클라이언트와 가까운지 알 수 있다.

5-3) 리피터용 서버로 액세스 대상을 분배한다

■ 리다이렉트 서버와 HTTP Location 요청 헤드

Location: 그 데이터는 이쪽 서버에 있으므로, 그쪽으로 다시 액세스하세요. 이런 접근을 리다이렉트라고 한다.

클라이언트가 웹 서버의 IP 주소를 조회하면 DNS 서버는 라다이렉트용 서버의 IP 주소를 회답한다.
- 리다이렉트용 서버를 웹 서버 측의 DNS 서버에 등록해야 한다.
리다이렉트용 서버가 가장 가까운 캐시 서버를 찾아서 Location 헤더를 붙여 응답을 돌려 보내면 클라이언트는 캐시 서버에 다시 액세스 한다.
- 리다이렉트용 서버도 DNS 서버와 같이 라우터 정보를 모은 테이블이 있다.
- 리다이렉트는 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하므로 정밀도가 높다.

패킷의 왕복시간을 계산하여 최적의 캐시 서버에 액세스 하도록 스크립트 프로그램을 내장한 페이지를 반송하는 방법도 있다.

5-4) 캐시 내용의 갱신 방법에서 성능의 차이가 난다

최초에 저장 후, 두 번째에 갱신 → 비효율
이를 방지하기 위해서 웹 서버에서 데이터를 갱신할 경우, 즉시 캐시 서버도 갱신하는 구조
이때 동적인 부분과 정적인 부분을 구분하고 변하지 않는 부분만 캐시에 저장

[BackEnd] 커뮤니티 게시물 목록 조회 API 쿼리를 QueryDsl로 구현해보기

sebinChu — Wed, 23 Oct 2024 00:57:22 +0900

개요

코알라 커뮤니티 기능 중 게시판 목록 조회 API를 위해 QueryDsl을 학습 및 구현해보았다.

요구사항은 다음과 같다.

정렬 (최신순, 조회수, 좋아요수)
검색 (제목, 내용, 작성자)
페이징

이 세 가지 조건 하에, DB에서 값을 가져오기 위해 QueryDsl을 활용하였다.
* JPQL 대신 QueryDsl을 사용한 이유

필요한 Entity, Request

게시판 전체 목록을 조회할 때 단순히 GET을 하는 것이 아니라, 개요에서 언급한 3가지 조건을 만족시켜야 한다.

조회 조건을 만족하기 위해 다음과 같은 Request record를 생성한다.

@Schema(description = "게시글 목록 검색 요청 객체")
public record SearchBoardRequest(

    @Schema(description = "검색 키워드(게시글 제목, 게시글 내용, 작성자)")
    String searchKeyword,

    @Schema(description = "게시글 카테고리")
    BoardCategory category,

    @Schema(description = "게시글 정렬 조건", allowableValues = {"LATEST", "LIKE", "VIEW_COUNT"})
    BoardSort sort,

    @Min(1)
    @Schema(description = "페이지 번호", type = "integer", requiredMode = RequiredMode.REQUIRED)
    int page,

    @Min(10)
    @Schema(description = "페이지별 개수", type = "integer", requiredMode = RequiredMode.REQUIRED)
    int size
) {

    public PageRequest pageRequest() {
        return PageRequest.of(page - 1, size);
    }

}

PageRequestJPA에서 제공하는 페이지 번호는 0부터 시작한다. 하지만 웹사이트 상에서의 페이지는 1부터 시작하므로 항상 -1을 설정한다.
- 이 Request 쿼리를 실행하면 결과로 Page<T> 객체가 반환되는데, 전체 데이터 수, 페이지 수, 현재 페이지의 데이터 목록 등을 포함하고 있다. 요청한 페이지 번호와 페이지 크기(한 페이지에 포함될 데이터 수)를 기반으로, DB 쿼리에서 데이터 범위를 지정할 수 있다.

Request 객체를 record로 설정하는 이유
1. 기본적으로 불변이라서 일관성 유지에 좋다.
2. 생성자, toString() , hashCode(), equals() 메소드를 자동으로 생성한다.
3. DTO(데이터 전송 객체)로 사용되어, 필드의 의미가 명확하다.

전체 코드를 나눠서 쿼리 살펴보기

1. select로 조건에 따른 결과를 Dto 형태로 반환

  List<ListBoardDto> boardList =
      queryFactory
        .select(Projections.fields(
            ListBoardDto.class,
            board.id.as("boardId"),
            board.category.stringValue().as("category"),
            board.title,
            board.member.name.as("createdName"),
            board.createdTime,
            Expressions.booleanTemplate(
                "case when {0} > {1} then true else false end",
                board.createdTime, LocalDateTime.now().minusDays(3))
              .as("newBoardYn"),
            board.viewCount,
            board.fixYn,
            board.deleteYn
          )
        )

category는 다음과 같은 Enum 타입으로 정의되어 있다.
이런 enum 값을 문자열로 변환해야 DB에서 사용할 수 있다. 따라서 stringValue()로 변환해준다.

@Getter
@AllArgsConstructor
public enum BoardCategory {
    NOTICE("공지"),
    FREE("자유"),
    QUESTION("질문"),
    INFO("정보"),
    PROMOTION("홍보");

    private final String name;
}

Expressions.booleanTemplate
최신글 여부를 위한 조건부로직(SQL의 CASE)이다. Template을 사용해서 복잡한 SQL 쿼리 로직을 동적으로 보다 간편하게 작성할 수 있다.

2. where 절로 카테고리, 키워드 설정

.where(
    searchCategory(request.category()),
    searchKeyword(request.searchKeyword()),
    board.saveYn.isTrue()
)

searchCategory 메소드에 따라 게시물의 카테고리랑 요청 카테고리랑 비교해서 일치하는 게시물만 반환한다.board 객체의 category를 QueryDsl의 eq 메소드로 일치하는지 비교한다.

private static Predicate searchCategory(BoardCategory category) {
    if (category == null) {
      return null;
    }
    return board.category.eq(category);
  }

searchKeyword도 마찬가지.
그런데 키워드는 세 가지 옵션이 가능하기에 다음과 같은 BooleanBuilder로 구현한다.

  private Predicate searchKeyword(String searchKeyword) {
        if (!StringUtils.hasText(searchKeyword)) {
            return null;
        }
        BooleanBuilder builder = new BooleanBuilder();
        builder.or(board.title.contains(searchKeyword));
        builder.or(board.content.contains(searchKeyword));
        builder.or(board.member.name.contains(searchKeyword));
        return builder;
    }

builder.or(...)를 사용하여 여러 조건을 결합하면, 주어진 키워드가 제목이나 내용, 작성자 이름 중 하나라도 포함될 경우 조건이 참이 된다.

BooleanBuilder
조건을 or, and로 결합할 때 가독성이 좋아진다.
여러 조건을 동적으로 추가할 수 잇다.

프로젝트에서 처음 QueryDsl을 적용하며 Template이나 where절에 넣는 메소드 등 배운 점이 많아서 정리해보았다!

[백준/1987] 알파벳 | DFS와 백트래킹

sebinChu — Fri, 11 Oct 2024 23:07:25 +0900

알파벳

오랜만의 백준 포스팅!!

코테에서 부족함을 절실히x99 느끼고 다시 알고리즘을 본격적으로 시작했다..

문제 바로 가기

알고리즘

말이 보드를 탐색하는 조건은 다음과 같다.

① (1,1)부터 탐색한다.

② 지금까지 지나온 모든 칸에 적혀있는 알파벳과 달라야 이동할 수 있다.

이 조건 아래에서 가능한 경로 중 최대한 큰 수를 구하는 것이 목표다.

따라서, DFS를 통해 탐색하는 방법을 선택했다.

def dfs(y,x,cnt):
    visited[y][x] = True
    alphabet[ord(graph[y][x])-65] = True
   # print('시작점: ', graph[y][x])

    # 현재 위치에서 네 방향의 위치 확인
    for dy, dx in dr:
        ny, nx = y+dy, x+dx
        if 0 <= ny < r and 0 <= nx < c :
            alpha = graph[ny][nx]
            #print('탐색 과정: ', alpha, " 좌표: ", ny,nx)
            if not alphabet[ord(alpha)-65]:
                visited[ny][nx] = True
                alphabet[ord(alpha)-65] = True
                cnt = dfs(ny,nx,cnt+1)
    return cnt

DFS는 모든 경로에 대해서 깊이 있는 탐색을 한다. 하지만 도착지점이 중복되면 다른 경로는 탐색하지 않는다.

재귀 호출 되면 바로 방문 처리를 하니까 아래 if에서 걸림

① A-B-C, ② A-D-C 경로 중에 ①이 먼저 탐색되면 ②는 탐색하지 않는 것이다.

반면에 백트래킹은 방문 시도 - 재귀 탐색 - 방문 해제 이 과정을 거쳐서, 목적지 노드가 중복되더라도 여러 경로를 탐색한다.

DFS는 모든 노드를 최대한 깊게 탐색하지만, 목적지가 중복되는 경로라면 하나의 경로만 탐색함 => O(V+E)
백트래킹은 3단계를 통해서 여러 노드를 탐색한다. (각 단계마다 최선의 선택) => O(2^V)

이 문제는 탐색 문제인데도 범위가 낮은 이유가 있엇다..! 이걸 보고 백트래킹으로 최장경로를 탐색한다고 유추할 수 있으면 좋았을 것..

전체 코드

from sys import stdin, setrecursionlimit
setrecursionlimit(3000)
input=stdin.readline

r,c = map(int, input().split())
graph = [input().rstrip() for _ in range(r)]
alphabet = [False] * (ord('Z')-ord('A')+1)
dr = [(1,0),(-1,0),(0,1),(0,-1)]
max_cnt = 0

def dfs(y,x,cnt):
    global max_cnt
    alphabet[ord(graph[y][x])-65] = True

    max_cnt = max(max_cnt, cnt)
    for dy, dx in dr:
        ny, nx = y+dy, x+dx

        if 0 <= ny < r and 0 <= nx < c :
            alpha = graph[ny][nx]
            if not alphabet[ord(alpha)-65]:
                alphabet[ord(alpha)-65] = True # 노드 방문
                dfs(ny,nx,cnt+1) # 재귀 탐색
                alphabet[ord(alpha) - 65] = False # 방문 해제!

dfs(0,0,1)
print(max_cnt)

여기서도 DFS에서는 cns를 누적하고, return 하는 식으로 구현했는데 백트래킹은 탐색하는 경로마다 max값을 찾아주는 식으로 구현을 수정했다. 또한 좌표 자체에 대한 방문 체크 대신 alphabet 방문 체크만 잘 해주면 되니까 좌표 방문 체크는 없애주었다.

알게된 점

백트래킹 - DFS 차이
백트래킹으로 최장경로 찾기 ➡️ 이게 DFS로 안 되는 이유

[Network] 네트워크 원리(4) 액세스 회선을 통해 인터넷의 내부로

sebinChu — Mon, 30 Sep 2024 14:00:38 +0900

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

Chapter 4 - 액세스 회선과 프로바이더의 탐험

5장과 더불어 가장 생소하고 어려웠던 내용.... 라우터부터 액세스 회선에서 이동하는 부분은 잘 알아두면 좋을 듯하다.

STORY 1 | ADSL 기술을 이용한 액세스 회선의 구조와 동작

1-1) 인터넷의 기본은 가정이나 회사의 LAN과 같다.

패킷을 중계하는 부분과 라우터의 기본적인 구조/동작은 같다.

■ 인터넷과 LAN의 차이점

중계 장치 간의 거리 : 가정이나 회사의 LAN은 멀어봤자 수백미터 정도이지만, 인터넷은 한국과 미국을 연결하는 부분은 태평양을 넘어야 하므로 케이블로 연결하는 것이 어려울 정도로 중계 장치 간의 거리가 멀다.
패킷의 중계 대상을 제어하는 부분 - 히 경로 정보를 테이블에 등록하는 점 : 인터넷의 라우터는 경로 정보가 10만 개 이상 등록되어 있고, 이는 시시각각 변한다. 이 모든 걸 사람이 통제하기 어렵기 때문에 자동화해야 한다.

1-2) 사용자와 인터넷을 연결하는 액세스 회선

패킷 IP 헤더의 수신처 IP와 테이블을 비교하여 해당 위치로 보낸다는 점(패킷 중계 동작)은 같다.

■ 이더넷과 인터넷의 패킷 송신 동작의 차이점

인터넷 접속용 라우터는 액세스 회선의 규칙에 따라 패킷 송신 동작을 실행한다.

액세스 회선(통신회선, 접근회선)
- 일반 가정이라면 ADSL, FTTH, CATV, 전화회선 등을 이용한다. 회사의 경우 전용 회선이 추가된다.
ADSL(Asymmetric Digital Subscriber)
- 전봇대에 부설된 전화용 금속제 케이블을 이용하여 고속으로 통신하는 기술
- 상향(사용자 → 인터넷 : 업로드)과 하향(인터넷 → 사용자 : 다운로드)의 통신 속도가 서로 다르다.

1-3) ADSL 모델에서 패킷을 셀로 분할한다.

■ 인터넷 접속용 라우터를 거친 패킷은 총 3가지(PPP, PPPoE, MAC) 헤더가 붙는다.

■ ADSL 모뎀은 패킷을 셀 단위로 작게 분할한다.

셀: 맨 앞 부분에 헤더(5 BYTE)와 데이터(48 BYTE)로 이어지는 작은 데이터의 덩어리
- ATM 통신 기술에 사용하기 위해서 패킷 → 셀로 분할한다. 셀을 사용하는 상태로 두면 전반적인 설비들과 연대할 수 있기에 패킷을 굳이 셀로 분할한다. ** 셀로 분할하지 않는 ADSL 사업자도 있다! 반드시 써야하는 건 x 설계에 따라 달라진다.
ATM(Asynchronous Transfer Mode)
- 전화 회선의 개념에 기초한 구형 전화 기술의 연장선에 있는 통신 방식
- 셀을 운반하는 부분은 TCP/IP와 비슷(but, 컴퓨터 통신에는 적합하지 않고 인터넷 통신에 적합하다!)

1-4) ADSL은 변조 방식으로 셀을 신호로 변환한다.

■ LAN의 경우, 사각형 신호를 통해 0과 1을 나타내는 신호로 변환했지만 ADSL은 좀 더 복잡한 방식을 쓴다.

사각형 신호의 경우…

파형이 뭉개지기 쉽다.
거리가 떨어졌을 때 오류가 발생하기 쉽다.
넓은 범위의 주파수가 포함되어 있다. (낮은 주파수 ~ 높은 주파수 모두 케어) 즉, 잡음을 제어하기 어렵다.

■ 직교 진폭 변조(QAM) = 진폭 변조(ASK) + 위상 변조(PSK)

진폭 변조 (그림의 빨간색 부분)
- 파동의 진폭 크기에 따라 0과 1을 대응
- 대응하는 비트 수를 늘리면 전달하는 데이터 양이 많아지면서 속도를 올릴 수 있다.
- 하지만 과도하게 늘리면 수신측에서 인접 단계와 오인할 가능성이 커져 오류의 원인이 된다. 이러한 일을 방지하기 위해서 단계 수를 억제해야 한다.
위상 변조 (그림의 파란색 부분)
- 파는 일주기만에 원래의 모습으로 돌아간다. 이 주기별로 파의 각도를 나타낸 것을 위상이라고 한다.
- 위상변조는 이 위상에 따라 비트를 대응하는 것이다.

직교 진폭 변조는 신호의 진폭과 위상에 각각 1비트를 대응시켜, 한 개의 파에 2비트 분의 데이터를 대응하여 두 방식을 결합한 방식이다.

1-5) ADSL은 파를 많이 사용하여 고속화를 실현한다.

주파수가 서로 다른 파를 혼합하여 파를 합성한다.
특정 주파수만 통과 가능한 필터 회로를 통해 주파수마다 파를 분리한다. 이를 통해 여러 주파수의 파를 합성한 것을 신호로 사용하는 것도 가능하다.
다수의 파에 비트값을 대응시켜 고속화한다.
잡음이 없는 주파수의 파에는 다수의 비트를 대응시키고, 잡음이 많은 주파수의 파에는 소수의 비트를 대응시킨다. 모든 비트 수의 합계로 전체 전송 속도가 결정된다.

*ADSL은 다운로드 속도가 더 빠르다! → 비트 수 차이

1-6) 스플리터의 역할

■ ADSL 모뎀과 DSLAM 모델 사이에서 ADSL용 신호와 전화용 신호를 분리한다.

전화기 측에 ADSL 신호가 흐르지 않도록 한다. → 전화기에는 전화 신호만 흐르고 ADSL 모뎀으로 향하는 신호는 그대로 흐른다.

이 스플리터는 전화기로 들어오는 ADSL을 차단할 뿐만 아니라, ADSL로 가는 전화기의 영향도 차단하는 기특한 기능을 가졌다!
- 스플리터를 통해서 수화기를 들고 / 내려논 경우의 신호 전달을 제어할 수 있다. 만약 스플리터가 없다면 수화기를 든/내린 경우의 신호 전달 방향이 달라서 ADSL에서 트레이닝을 이에 맞춰 다시 실행해야 한다. 그러면 그 사이에 통신이 수십 초 중단된다.

1-7) 전화국까지의 여정

■ 스플리터의 모듈형 커넥터 → 배선반(IDF, MDF) → 보안기

배선반MDF(Main Distribution Frame): 주 배선반
IDF(Intermediate Distribution Frame): 중간 배선반
보안기
낙뢰와 같이 외부 전화선에서 과대한 전류가 흘러들지 않도록 보호하는 장치

배선반 용어가 낯설어서 찾아봤는데 사진을 보니 딱 감이 온다! 아파트에 살면 한 번쯤은 꼭 보는 구조물

■ 신호는 보안기까지 지나서 전주(電柱 - 전봇대)의 전화 케이블로 이동한다. 전체의….

전화 케이블은 사용자와 가까우면 전봇대 내부에 부설되어있다. 도중에 전주의 둘레에 묶은 금속 파이프 속에 들어가 여기에서 지하로 들어간다. - 이를 궤선점이라고 한다.

많은 케이블을 한꺼번에 전주를 통해 전화국까지 연결하는 것은 비현실적이기에, 전화국에 어느 정도 가까운 곳에서 지하에 케이블을 매설한다. 전화국에 가까워지면 지하 케이블 수가 증가하므로, 이것을 모아서 매설하는 부분은 지하도처럼 된다. - 이를 동도라고 한다.

이 동도를 통해 전화국에 들어간 케이블은 MDF에 하나씩 연결된다.

■ 전화 케이블 속을 신호가 통과할 때 여러 가지 잡음의 영향을 받는다.

전화 케이블은 금속제 신호선 속에 전기 신호가 흐른다는 점이 이더넷 트위스트 케이블과 공통된다. 또한, 전화 케이블은 ADSL과 같은 높은 주파수의 신호가 흐른다는 점을 가정하지 않았기에 잡음의 영향을 받기 더 쉽다. → 이더넷과 같이 케이블 외부의 주파수 / 케이블 내부에서 발생하는 잡음의 영향으로 신호가 변형된다.
잡음이 많은 장소에 전화 케이블이 가설되면 속도가 저하될 가능성이 있다. ex) 전철의 선로 옆
케이블의 쿼드 속/인접한 서브 유닛의 가까운 위치에 ADSL 신호선과 ISDN 회선의 신호선이 함께 들어있는 경우, ISDN에서 누설되는 잡음의 영향이 있다. (최근엔 많이 해결된 상황)

1-9) DSLAM을 통과하여 BAS에 도달한다.

■ 배선반, 스플리터를 통과하여 DSLAM에 도착하면 전기 신호가 셀로 복원된다. → ADSL과 같음

셀로 복원하는 작업을 여러 개의 ADSL로 하면 장소 차지 + 동작 감시가 어렵기에, ADSL 모뎀의 기능을 하나로 묶어, DSLAM으로 만들어서 사용한다. 즉, DSLAM은 ADSL을 여러 개 모아둔 장치다!
한 가지 다른 점은, ASDL 모뎀은 이더넷 인터페이스, DSLAM은 ATM 인터페이스를 가진 것이 대부분이다.

■ DSLAM을 나온 셀은 BAS라는 중계 장치에 도착한다. - 패킷 복원 및 터널링 중계

BAS는 ATM 인터페이스로 구성되어, 수신한 셀을 원래의 패킷으로 복원한다.
수신한 패킷의 맨 앞부분의 MAC 헤더와 PPPoE 헤더를 버린다.
- MAC과 PPPoE는 BAS에 도착하기 위해 사용된 것이기 때문에, 이더넷 인터페이스의 라우터가 패킷을 수신했을 때 MAC 헤더를 버리는 것과 같다.
이후, 터널링용 헤더를 붙여 터널링 출구로 중계한다.

STORY 2 | 광섬유를 이용한 액세스 회선(FTTH)

2-1) 광섬유의 기본

빛 신호를 전달하는 가느다란 유리 또는 플라스틱 섬유의 일종이다. 안쪽에 있는 코어 속에 광신호를 흘려서 데이터를 전달한다.

광신호는 의외로 단순하다. 등이 켜지면 1, 꺼져서 어두우면 0을 나타내는 것 뿐이다.

■ 광섬유를 이용한 통신의 원리

디지털 데이터를 전기 신호로 변환한 후, 전기 신호를 광신호로 변환한다.→ 전압이 높으면 밝아지고, 낮으면 어두워진다.
전기 신호를 LED나 포토 다이오드같은 광원에 입력하면, 입력된 전기 신호의 전압에 따라 빛을 발한다.
이 빛을 광섬유 안에 통과시켜서 흘려 보낸다.
수신측에서는 수광 소자(빛에 감응하여 밝기에 따라 전압을 일으킴)를 통해 빛으로부터 전기 신호를 낸다.
이 전기 신호를 디지털 데이터로 변환해서 수신한다.

2-2) 싱글모드와 멀티모드의 차이

광섬유로 빛을 통과시켜서 전달하는 건 꽤나 직관적이지만, 그 빛의 전달 방법이 상당히 복잡하다..... 상당히...상당히...!

■ 입사각이 작은 빛만 경계면에서 전반사되어, 코어를 통해 흐른다.

광원(LED 등)에서 나온 빛은 광섬유의 코어 부분에 들어간다. 광원에서 나온 빛은 흩어지므로 광섬유의 코어 부분에 여러 각도로 들어간다. 입사각이 크면 경계선에서 굴절되어 밖으로 나가버린다.

입사각이 작은 빛이 전부 코어 속을 진행하는 것은 아니다. → 위상차가 없는 경우에만 소멸되지 않고 광섬유 속을 흐른다.
- 빛은 코어와 클래드의 경계면에 부딪혀서 반사될 때 위상이 달라진다. 따라서 빛이 소멸되지 않고 유지되는 환경 유지를 위해, 코어와 클래드의 위상이 달라지지 않는 각을 찾아서 코어의 직경을 설정한다.

■ 빛 소멸 방지 → 코어와 클래드의 위상이 달라지지 않는 각도 찾기 → 코어의 직경 제어

코어의 직경은 2 가지가 있다.

싱글모드

가장 작은 빛만 입사되도록 코어를 가늘게 만든 광섬유다.
신호의 변형이 적다. → 케이블 길이가 길어져도 상관없다. → 멀리 떨어진 장소에 있는 건물 사이에 사용한다. (FTTP)

멀티모드

코어의 직경이 굵고 입사각이 큰 빛도 들어가므로 위상이 가장 작은 것, 두 번째로 작은 것, 세 번째로 작은 것과같이 복수의 빛이 코어속을 진행하는 광섬유다.
빛의 양이 많다 → 신호의 변형이 잦다. → 광섬유의 길이를 짧게 해야 오류를 줄일 수 있다. → 한 건물 내에서 사용한다.

2-3) 광섬유를 분기시켜서 비용을 절감한다.

ADSL 대신 광섬유를 사용해서 사용자 측의 인터넷 접속용 라우터와 인터넷 측의 BAS를 연결하는 것이 FTTH다.

STORY 3 | 복수 서버에 리퀘스트를 분배한 서버의 부하 분산

3-1) 처리 능력이 부족하면 복수 서버로 부하 분산된다

■ 서버에 액세스가 증가할 때

회선을 빠르게 하기 → 서버의 처리 능력이 따라잡지 못할 수 있다.
서버 머신을 고성능으로 교체하기 → 한계가 있다.
⇒ 복수 서버를 사용하여 서버 한 대당 처리량을 줄인다.

■ 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄인다.

DNS 서버에서 분배

DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록한다. DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 되돌려 준다. ⇒ 라운드 로빈
1. 192.0.2.60 → 192.0.2.70 → 192.0.2.80
2. 192.0.2.70 → 192.0.2.80 → 192.0.2.60
3. 192.0.2.80 → 192.0.2.60 → 192.0.2.70
DNS는 웹 서버의 상태를 확인하지 않고 중계만 하므로, 웹 서버가 중단/고장된 상황에 대응하기 어렵다.
라운드 로빈을 통해 웹 서버를 분배하면 웹 사이트의 연속성이 끊긴다. 예를 들어서, 첫 번째 페이지에서 성명 입력 후에 두 번째 페이지에서 신용카드 번호를 입력하는 케이스가 있다.
TO-DO : GCP LB 라운드 로빈….

3-2) 부하 분산 장치를 이용해 복수의 웹 서버로 분할된다

부하 분산 장치 IP를 웹 서버 IP 대신 DNS에 등록한다.

■ 대화가 복수의 페이지에 걸쳐있다면…

STORY 4 | 프로바이더의 내부

4-1) POP와 NOC

■ 액세스 회선, 터널링을 통과한 패킷은 프로바이더의 POP에 설치된 라우터에 도착한다.

POP(Point Of Center): ADSL/FTTH같은 액세스 회선은 사용자가 계약한 프로바이더의 설비에 연결되어있는 것

NOC(Network Operation Center): POP에서 들어온 패킷이 여기로 모여든다. 이곳에서 목적지 근처의 POP나 다른 프로바이더로 패킷이 흘러간다.

4-2) 건물 밖은 통신 회선 등으로 접속한다.

■ 건물 내부에서 모든 패킷이 모이는 종점 라우터, POP & NOC

POP나 NOC는 건물 안에 하나씩은 있는 서버룸/머신룸과 비슷하다. 건물 안의 어딘가에 있으므로 그 안에 있는 라우터는 케이블로 직접 접속하거나, 스위치를 경유하여 접속한다.

건물 밖과는….

케이블로 연결

보통 이 케이블은 트위스트 페어 케이블을 사용하는데 아무래도 패킷 송수신양이 엄청 많다보니, 트페케이블의 한계에 도달할 때가 있다. 이런 경우는 광섬유 케이블을 사용한다.
광섬유 케이블

광섬유 케이블을 건물 각각에 가지고 있다는 것은 현실적인 측면(기술, 비용)에서 어렵다. 따라서 광섬유를 가진 회사는 자체적으로 사용 + 다른 곳에 광섬유 대출해주기를 동시에 한다. 이 광섬유를 세분화해서 일부분을 고객에게 빌려주는 형태다. → 이런 종류의 서비스를 통신 회선이라고 한다!

STORY 5 | 프로바이더를 경유하여 흐르는 패킷

5-1) 프로바이더끼리의 접속

■ 서버 -클라이언트가 같은 프로바이더에 접속한 경우

라우터는 라우터끼리 정보 교환 후 테이블 자동 업데이트해서 패킷을 중계한다.

■ 서버 -클라이언트가 다른 프로바이더에 접속한 경우

프로바이더는 다른 프로바이더와 정보 교환도 하므로, 라우팅 테이블에 송신할 프로바이더의 경로 정보가 등록되어 있다.

⇒ 결국 인터넷에는 동일 프로바이더인지, 다른지 상관없이 모든 경로가 등록되어 있다. 이러한 경로표로 패킷 중계

5-2) 프로바이더끼리 경로 정보 교환하기

■ BGP(Border Gateway Protocol)

주변의 여러 라우터들에게 어떤 라우터가 어느 AS에 속해 있는지에 대한 정보를 소문 내는 것 이다.

트랜지트(transit): 한 프로바이더로부터 경로 정보를 받아, 모든 프로바이더에 패킷을 보낼 수 있게 되는 상태. 즉, 한 프로바이더로부터 모든 프로바이더의 주소 정보를 알아낸다.
비트랜지트/피어(peer) : 피어들 간의 정보만 교환한다.

5-3) 사내 네트워크에서 자동 등록하기

최단 경로를 선택하되, 의도하지 않은 상대로부터 오는 패킷을 중지하는 구조로 되어있다. 단순히 최단경로로만 구성하면 의도치 않게 비용 부담에 응하지 않는 프로바이더로부터 패킷이 흘러올 수 있고, 다른 회선을 이용해버릴 수도 있기 때문이다.

경로 정보를 교환하는 상대 지정하기
사내에서는 무차별적으로 모든 라우터와 경로 정보를 교환하지만, 프로바이더 간에는 특정 라우터와 1:1로 한다. 이 일대일으로 대응된 경로 정보를 통지한 상대 이외의 패킷은 흘러들어오지 않는다.

5-4) IX(Internet eXchange)의 필요성

프로바이더끼리 직접 1:1로 연결하지 않아도 IX를 통해 통신할 수 있다.
자연재해에 대비하여, 자가 발전 설비를 갖춘 내진 구조의 건물 안에 있다.

정확히 말하면 건물 어딘가에 IX가 있고, IX의 중심에는 고속 LAN의 인터페이스를 다수 장착한 레이어 2 스위치가 있다. 이때 IX의 스위치는 스위칭 허브와 같이 동작한다. → ARP를 통한 중계 대상 라우터의 MAC 조사 → MAC 헤더에 기록하여 패킷 전송

[Network] 네트워크 원리 (3) 케이블의 앞은 LAN 기기였다.

sebinChu — Tue, 3 Sep 2024 18:04:30 +0900

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

Chapter 3 - 허브와 스위치, 라우터의 탐험

STORY 1 | 케이블과 리피터, 허브 속에 신호가 흘러간다.

1-1) 하나하나의 패킷이 독립적으로 동작한다.

컴퓨터에서 송신된 패킷은 중계 장치(허브, 라우터 등)에 의해 운반된다. 이때, 중계장치는 어떤 데이터인지 전혀 신경쓰지 않고 전송에만 집중한다.

1-2) LAN 케이블은 신호를 약화시키지 않는 것이 핵심이다.

■ 높은 주파수와 낮은 주파수

1-3) ‘꼼’은 잡음을 방지하기 위한 방법이다.

트위스티 페어 케이블은 마주 꼬여있는 상태를 통해서 잡음을 막는다.

■ 잡음의 원인은 케이블에서 발생하는 전자파다.

전자파가 금속 등의 도전체에 닿으면 그 내부에 전류가 발생한다. → 케이블 주위에 전자파가 있으면 보내는 신호와 다른 전류가 케이블 내에 흐르게 되고, 이러한 잡음이 신호와 뒤섞여서 파형이 변형된다.

■ 케이블에 영향을 주는 전자파

기기에서 누설되는 전자파
- 신호선에 전자파가 닿으면, 전자파 진행 방향의 오른쪽으로 전류가 생긴다. 케이블의 선을 마주 꼬면 형태가 나선형이 되어 꼰 옆의 선에서 전류가 흐르는 방향이 반대가 된다. 전자파로부터 오른쪽으로 전류가 생기면, 이 나선형 모양으로부터 전류가 다시 왼쪽으로 흘러 서로 상쇄되어 잡음에 의한 전류가 약해진다.
이는 케이블 밖에서 오는 것으로, ‘선을 꼼’으로써 막을 수 있다.
같은 케이블 안의 인접한 신호선에서 누설되는 전자파 - 크로스토크(crosstalk)
- 신호선 안에는 신호라는 전류가 흐른다. 이 전류에 의해 주위에 전자파가 생기고, 다른 신호선에 대한 잡음이 된다. 이 잡음은 거리가 가까운 것이 문제다. 전자파는 발생 근원에서 떨어지면 확산되어 약해진다. 하지만 한 개의 케이블 안에서의 신호선들은 거리가 매우 가깝다.
- 신호선을 마주 꼴 때 어떤 부분에서는 + 신호가, 어떤 부분에서는 - 신호가 가까워지면 이 +, -에서는 잡음의 영향이 반대가 되어 각각의 균형이 잡히면서 잡음의 영향이 줄어ㅈ든다.
이것을 막는 대책도 신호선을 마주 꼬는 것이다.

1-4) 리피터 허브는 연결되어 있는 전체 케이블에 신호를 송신한다.

■ 리피터 허브의 송신 원리

신호가 리피터 허브에 도착하면 일단 LAN 전체에 신호를 모두 뿌린다. → 이더넷의 기본 원리와 상통한다. 일단 모두 뿌리고, 수신처 MAC 주소에 해당하는 기기만 이 신호를 받는 것.

■ 리피터 허브 내부

PHY & RJ-45(회로와 커넥터)

각 커넥터의 안 쪽에 LAN의 PHY와 똑같은 역할을 하는 회로가 있다.
이 PHY와 RJ-45를 거쳐서 제대로 송수신 하려면 단자를 교차시켜서, ‘송신 단자’에서 보낸 신호를 ‘수신 단자’에서 받을 수 있도록 해야 한다.

MDI/MDI-X

리피터 허브 끝의 커넥터에는 MDI/MDI-X와 같은 전환 스위치가 붙어있다.
- MDI: RJ-45 커넥터와 송수신 회로를 직접 결선한 것
- MID-X: 교차하여 결선한 것
허브의 커넥터 부분은 보통 MDI-X이므로 허브끼리 접속할 때는 한쪽을 MDI로 설정해야 한다.
- 만약 MDI가 없고 모두 MDI-X인 경우, 크로스케이블로 허브들을 접속한다.

리피터 허브의 기본은 신호를 그대로 뿌리는 것이다.

리피터 허브의 회로에 신호가 들어오면 이 모든 신호를 연결된 커넥터 부분에 뿌려준다.
이후, 커넥터에 온 신호는 모두 나가면서 리피터 허브에 접속한 전체 기기에 도달한다.
신호를 수신한 기기는 맨 앞에 있는 MAC 헤더에 쓰여 있는 수신처 MAC 주소를 조사하여 자신이 수신처에 해당하면 이 신호를 받는다.

STORY 2 | 스위칭 허브의 패킷 중계 동작

2-1) 스위칭 허브는 주소 테이블로 중계한다.

스위칭 허브도 PHY에서 커넥터까지 수신되는 부분은 앞의 리피터 허브와 같다. 즉, 커넥터와 PHY 회로는 MDI-X로 연결되어 있고, 트위스트 페어 케이블에서 신호가 들어오면 PHY 회로의 수신 부분에 신호가 들어간다.

이후, 신호는 공통의 신호 형식으로 변환되어 MAC 회로로 들어간다. 그리고 여기에서 디지털 데이터로 변환한 후, 패킷의 가장 끝에 있는 FCS와 비교하여 오류 유무를 검출한다. 문제가 없으면 이를 버퍼 메모리에 저장한다.

■ 스위칭 허브가 수신처 MAC 주소를 조사하는 방법

스위칭 허브의 포트(커넥터와 안쪽에 있는 회로 부분)는 수신처 MAC 주소를 검사하지 않고, 모든 패킷을 수신하여 버퍼 메모리에 저장하고 나서, MAC 주소표를 확인한다. 이 MAC 주소표에는 MAC 주소와 포트가 짝을 이루고 있다. 이를 통해 수신한 패킷을 어느 포트에서 송신하면 좋을지를 판단한다.

허브는 중계 장치니까 송신 패킷을 다시 어디로 보낼지 수신처 MAC 주소와 송신 포트를 저장해 두는 것.

■ 스위치 회로의 구조

신호선이 격자 모양으로 배치되고, 교점에 스위치가 있다. 이 스위치는 전자적으로 개폐 조절이 가능하다. 이를 통해 신호가 흐르는 대상을 제어한다. 그리고 입력측은 수신측 포트에, 출력층은 송신쪽 포트에 접속되어 있다.

포트 사이에 패킷을 운반할 때, 이 회로에 패킷의 신호를 흘린다. 신호의 교점에 있는 스위치는 각각 독립하여 움직이므로 신호가 중복되지 않으면 복수의 신호를 동시에 흘릴 수도 있다.

■ 스위치 회로에서의 송신 동작 → LAN 어댑터의 송신 동작과 같다.

이더넷의 규칙에 따라 먼저 신호가 흐르고 있는지 확인
소켓을 디지털 데이터에서 신호로 변환하여 송신
송신 동작 중에 다른 기기가 보낸 신호가 수신측에 들어오면 패킷이 충돌하므로, 재밍 신호를 보낸 후 송신 동작을 중지하고 잠시 기다렸다가 다시 송신

2-2) MAC 주소 테이블을 등록 및 갱신한다.

■ 스위칭 허브는 패킷을 중계할 때 MAC 주소표의 내용을 갱신한다.

패킷 수신 시, 송신처 MAC 주소와 입력 포트 번호
사용하지 않고 일정 시간이 지나면 삭제(노트북 들고 다른 방으로 이동하는 경우)

⇒ MAC 주소는 스위칭 허브가 자체가 스스로 등록하거나 사라지므로, 수동으로 관리할 필요가 없다.

2-3) 스위칭 허브의 예외적인 동작

■ 스위칭 허브에 리피터 허브가 접속되어 있는 경우

이 경우는 송신할 패킷의 포트와 수신한 패킷의 포트가 같기 때문에, 패킷을 중계하지 않고 폐기한다.

■ MAC 주소표에 수신처 MAC 주소와 일치하는 주소가 없는 경우

패킷이 한 번도 스위칭 허브에 도착하지 않음
시간이 지나서 삭제된 경우

→ 어느 포트에서 송신해야 할지 판단할 수 없으므로, 수신 포트 이외의 전체 포트에서 송신한다.

이렇게 해도 결국 올바른 수신처만 패킷을 받음 + 두 번째부터는 기록이 되므로, 네트워크 혼잡도에 큰 영향 X

2-4) 전이중 모드에서 송수신을 동시에 실행

전이중 모드: 송신과 수신을 동시에 할 수 있는 모드 → 신호의 충돌을 검출하는 회로를 무효화

■ 스위칭 허브는 전이중 모드에서 송수신을 동시에 실행 가능(리피터 허브는 안됨)

이론상으로, 여러 대의 컴퓨터가 동시에 송신 동작을 개시하면 허브 내부에서 신호가 뒤섞여서 신호가 파괴된다. 하지만 리피터 허브는 전이중 모드가 필요 없는 게, 어차피 ‘트위스트 페어 케이블’로 구성되어 있어서 신호가 따로 흐른다.

2-5) 최적의 전송 속도로 보내는 자동 조정

자동 조정(auto negotiation): 접속한 상대가 전이중 모드를 지원하는지 검출하고 동작 모드를 자동으로 전환하는 기능이다. 동작 모드뿐만 아니라 상대의 전송 속도를 검출하여 이도 자동으로 전환한다.

링크 펄스: 데이터가 흐르지 않을 때 펄스형의 신호를 흘려서 상대가 올바르게 작동하는지, 케이블 이상 없는 지 등을 확인할 수 있다. (이더넷에 초록색 LED 확인 가능)

■ 두 기기가 전원 켜고, HW 초기화가 끝난 다음 펄스 신호를 보내기 시작한다.

먼저 펄스 신호를 보내서 상대에게 신호가 도착한다. 이 도착한 펄스의 패턴을 읽고 상대가 어느 모드를 지원하는지 조사한다. 모드의 우선순위대로 조사하면서 자신과 상대 모두가 지원하는 동작 모드를 찾는다.

2-6) 스위칭 허브는 복수의 중계 동작을 동시에 실행한다.

스위칭 허브는 수신처 MAC 주소와 매핑된 포트 외에는 송신 동작을 실행하지 않으므로, 이 포트에서 데이터를 흘릴 수 있다.
리피터 허브는 들어온 신호를 모든 포트에서 뿌리므로 동시에 두 개 이상의 신호가 들어왔을 때 패킷이 충돌하기 때문에 복수의 신호를 동시에 흘릴 수 없다.

STORY 3 | 라우터의 패킷 중계 동작

3-1) 라우터의 기본

허브를 경유한 패킷은 결국 라우터에 도착하고, 라우터에서 다음 라우터로 중계된다. 중계할 때 table을 확인하고 해당 기기에 데이터를 보낸다는 점은 허브와 비슷하지만, 라우터에는 IP 개념이 추가된다.

■ 라우터의 내부 구조는 중계 부분, 포트 부분 두 가지로 나뉜다.

중계 부분: 패킷의 중계 대상을 판단한다. → IP 담당 부분과 같다.
포트 부분: 패킷을 송수신한다. → LAN 어댑터와 같다.
- 라우터의 포트 부분에 다양한 통신 기술의 HW를 장착하면, 이를 지원할 수 있다. 예를 들어서 무선 LAN용 HW를 장착하면 무선 LAN을 지원할 수 있다.

→ [기본 동작] 포트 부분에서 패킷을 수신하고, 중계 부분에서 중계할 대상을 판단한다. 그리고 중계 대상측의 포트로 패킷을 옮기고, 포트 부분의 hw 규칙에 따라 패킷 송신 동작을 실행한다.

■ 스위칭 허브는 table의 MAC 주소, 라우터는 table의 IP 주소를 통해 중계한다.

스위칭 허브는 table에 MAC 주소와 그에 매핑되는 포트를 저장했지만, 라우팅 테이블은 조금 더 복잡한 내용을 담고 있다.
허브는 패킷을 중계함과 동시에 정보를 갱신하지만, 라우터는 중계하면서 정보를 갱신하거나 하는 등의 작업은 하지 않는다.
- 사람이 수동으로 정보 갱신
- 라우팅 프로토콜(RIP, OSPF, BGP 등)을 통해 라우터들끼리 정보를 교환하고, 라우터 자체에서 라우팅 테이블에 등록

■ 라우팅 테이블 살펴보기

‘주소 집약’을 통해 서브넷을 묶어서 한 개의 서브넷으로 간주하기
경로가 겹치면 그 부분만 일괄적으로 통합해서 해당 주소에만 패킷을 중계하느 것
한 개의 서브넷을 세분화하여 복수 개로 보이도록 하기
호스트 번호 부분에 값이 들어있는 개별 컴퓨터를 나타내는 주소를 ‘수신처’ 항목에 등록할 수 있다.
게이트웨이, 인터페이스 - 패킷의 중계 대상
매트릭 - 목적지가 가까운지, 먼지 나타냄

3-4) 경로표를 검색하여 출력포트를 발견한다.

라우터는 패킷 수신 동작이 끝나면 맨 앞의 MAC 헤더를 폐기한다. 패킷을 수신하면 MAC 헤더의 역할이 끝나기 때문.. 폐기하고, MAC 헤더 뒤에 있는 IP 헤더의 내용을 보고 패킷 중계 동작에 들어간다.
우선 수신한 패킷의 IP 주소와 라우팅 테이블의 수신처 부분을 비교한다. 이때, 32 비트 전부를 비교하는 것이 아니라 ‘넷마스크’ 항목에 등록된 값에서 네트워크 번호 부분만 비교한다.
- 255.255.255.0 이라는 넷마스크는 네트워크 부분이 24비트, 호스트 부분이 8비트니까 왼쪽부터 24비트 먼저 조사한다.
- 만약 이 넷마스크를 조사해서 복수의 후보가 생기면 네트워크 번호의 비트 수가 가장 긴 것을 찾는다.
- 네트워크 번호의 비트 수까지 동일하면, 메트릭 값으로 판단한다. 메트릭 값이 작을 수록 가까운 것이기에 작은 쪽으로 중계한다.
- 만약 일치하는 행이 하나도 발견되지 않으면, 패킷을 폐기하고 ICMP 메시지를 송신처에게 보낸다.
  → 스위칭 허브는 그냥 모든 포트에 흘렸지만..스위칭 허브는 많아봐야 수천대 정도의 네트워크지만, 라우터는 인터넷이기에 규모가 크다.

3-5) 해당하는 경로가 없는 경우에 선택하는 기본 경로

넷마스크 항목이 0.0.0.0이라는 것은 비교 동작을 실행하지 않는다는 것이다. → 패킷의 수신처 IP 주소와 라우팅 테이블 수신처 항목을 비교할 때 비트수가 0이라는 것이기 때문이다. 즉, 모든 주소에 일치한다. 따라서 이 0.0.0.0 이라는 넷마스크는 기본 경로/기본 게이트웨이를 나타낸다.

3-6) 패킷은 유효 기간이 있다.

■ 라우터는 중계 대상을 찾고, 포트 부분으로 패킷을 옮기고 송신하기 전에 해야할 몇 가지 일이 있다.

TTL(Time To Live, 생존기간)설정
- 라우터를 경유할 때마다 이 값을 1씩 줄이다가 0이되면 패킷을 폐기한다.
- 패킷이 같은 장소를 무한대로 돌아다니는 경우를 방지한다.

3-7) 큰 패킷은 분할한다.

■ 중계하는 패킷의 크기가 출력측의 패킷 최대 길이를 초과하면 패킷을 그대로 송신할 수 없다.

이 경우에는 IP 프로토콜에 규정된 Fragmentation을 통해 패킷을 분할하고, flag를 붙여서 중계한다.

패킷 최대 길이는 포트의 종류에 따라 결정된다.

출력측의 MTU를 조사하여 중계하려는 패킷을 송신할 수 있는지 체크한다.
IP 헤더의 플래그 필드를 조사하여 분할해도 좋을지 확인한다.
- 분할이 불가능하면 패킷을 폐기하고, ICMP 메시지로 송신처에 통지한다.
- 분할이 가능하면 출력측의 MTU에 맞춰서 앞에서부터 차례대로 분할한다.
  - 분할할 때는 TCP 헤더 뒤 데이터부터 분할한다.
분할한 데이터에 IP 헤더를 덧붙인다.

3-8) 라우터의 송신 동작은 컴퓨터와 같다.

■ 송신 동작은 출력 포트가 무엇이냐에 따라 다르다.

이더넷이라면 이더넷 규칙에 따라, ADSL라면 ADSL 규칙에 따라 신호를 변환하여 송신한다.

■ 회사 등의 LAN에 사용하는 라우터라고 가정하자…

패킷 송신 동작의 기본은 프로토콜 스택의 IP 담당이 패킷을 보낼 때와 같다. 맨 앞부분에 MAC 헤더를 부여하고, 값을 설정하여 패킷을 완성시킨 후 전기 신호로 변환해서 보낸다.

[수신처 MAC 주소] MAC 헤더에 정보를 쓰기 위해서 라우팅 테이블의 ‘게이트웨이’ 항목에서 패킷을 건네줄 상대를 판단한다.
- 게이트웨이 부분이 공란이면 IP 헤더의 수신처가 건네줄 상대의 주소
[수신처 MAC 주소] 라우팅 테이블에서 상대의 IP를 결정했으면, ARP로 해당 IP 주소에서 MAC 주소를 조사하고, 결과를 수신처 MAC 주소로 설정한다.
[송신처 MAC 주소] 출력측의 초트에 할당된 MAC 주소를 설정하고 16진수(0800)를 추가한다.

3-9) 라우터와 스위칭 허브의 관계

■ 라우터(IP)는 패킷을 실제로 보내기 위해 허브(이더넷)에 의뢰해야 한다.

라우터는 IP 기반, 허브는 이더넷을 기반으로 만들어졌다. 따라서 이 IP와 이더넷의 관계가 라우터와 허브의 관계다. → 즉, 라우터는 패킷을 운반하는 것을 허브에 의뢰해야 한다.

실제 라우터에서는 이더넷 기능을 내장한 기종이 있기에 순수 라우터와 순수 허브에 대해 이야기 한다.

■ 이더넷 이외에 LAN/통신 회선에는 어떻게 의뢰할까?

똑같이 그들에게 의뢰한다.

STORY 4 | 라우터의 부가 기능

4-1) 주소 변환으로 IP 주소를 효율적으로 이용한다.

■ 라우터의 주소 변환 기능

인터넷이 발달하고 주소 부족 현상에 대비하기 위해 IP를 두 가지로 구분하여 사용

private
- 글로벌 주소에 포함된 범위 내에서 IP 주소를 만들어서 사용한다. 이건 사내에서만 사용하는 것이므로 바깥에 있는 IP와 중복돼도 상관없다. 단, 사내에서 중복은 피해야 한다.
- 이러한 사내 IP는 외부 인터넷과 직접 패킷을 주고받지 않는다.
global
- 인터넷과 직접 통신하는 부분이다.

4-2) 주소 변환의 기본 동작

패킷을 인터넷에 중계할 때 송신처의 IP 주소를 private → global으로 변경한다. 포트도 마찬가지로 변경한다.
그리고 이 네 가지를 한 묶음으로하여 주소 변환 장치 내부 table에 기록한다.
바뀐 IP, port로 외부 인터넷과 통신한다.
응답을 받으면 주소 변환 장치가 글로벌 주소와 포트를 찾아서 private으로 다시 바꿔서 사내 네트워크에 패킷을 보낸다.
접속 동작이 끝나고 연결이 끊기면 대응표에 적힌 ip, port를 삭제한다.

4-3) 포트 번호를 바꿔 쓰는 이유

IP를 수만 개의 포트에 대응하기 위해서. 즉, IP를 더 많이 쓰기 위해서다.

4-4) 인터넷에서 회사로 액세스 한다.

사내에서 외부 인터넷으로 패킷을 중계할 때는 송신처의 private, port가 등록되어 있지 않아도 중계할 수 있다. 어차피 글로벌 주소는 주소 변환 장치(라우터)에 할당되어 있고 포트는 적당히 비어 있는 것을 사용하면 되기 때문이다.

그러나 인터넷에서 사내로 패킷을 중계할 때는 주소 전환 장치가 주소를 전환해주어야 하므로, table에 기록이 되어 있어야 한다. → 외부로부터의 부정 침입을 방지하는 효과가 있다.

4-5) 라우터의 패킷 필터링 기능

패킷을 중계할 때 MAC 헤더, IP 헤더, TCP 헤더에 기록되어 있는 내용을 조사하여 사전에 설정한 조건에 맞으면 패킷을 중계/폐기하는 것을 말한다.

[Network] 네트워크 원리(2) - TCP/IP의 데이터를 전기 신호로 만들어 보낸다

sebinChu — Tue, 27 Aug 2024 10:38:26 +0900

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

Chapter 2 - 프로토콜 스택과 LAN 어댑터 탐험

STORY 1 | 소켓을 작성한다.

1-1) 프로토콜 스택의 내부 구조

인터넷에서 데이터를 운반할 때는 데이터를 작게 나누어 패킷이라는 형태로 운반한다.
패킷을 통신 상대까지 운반하는 것이 IP의 주 역할이다.
IP 안에는 ICMP와 ARP라는 프로토콜을 다루는 부분이 포함되어 있다.
- ICMP: 패킷 운반 통제 및 제어용 메시지 통제
- ARP: 이더넷의 MAC 주소

1-2) 소켓의 실체는 통신 제어용 제어 정보

소켓은 개념적인 것이어서, 실체가 없다. 굳이 말하자면 제어 정보, 즉 제어 정보가 기록된 프로토콜 스택 내부의 메모리 영역이다.

제어 정보에는 통신 상대의 IP 주소, 포트 번호, 통신 동작의 상태 등이 있다.
소켓에는 응답이 돌아오는지의 여부와 송신 동작 후의 경과 시간 등이 기록되어 있다. → 이 정보를 보고 포기하거나 다시 보내는 동작을 실행해야 하기 때문
netstat 명령어

1-3) 소켓을 호출했을 때의 동작

브라우저가 소켓이나 connect같은 소켓 라이브러리의 부품을 호출했을 때, 프로토콜 스택의 내부는 어떻게 움직일까?

브라우저에서 gethostnyname같은 걸로 요청하면…
TCP/IP layer에서 소켓 생성하기
- 소켓의 제어 정보를 기록할 메모리 영역 확보하기
- 소켓을 작성한 직후에는 송수신 동작이 시작되지 않은 상태이므로, 초기 상태임을 나타내는 정보 기록
소켓을 만들고, 디스크립터를 애플리케이션에 알려주기
애플리케이션은 앞으로 통신할 때 이 디스크립터를 활용

STORY 2 | 서버에 접속한다.

2-1) 서버에 접속 == 소켓에 정보를 기록

소켓을 만든 직후는 아무것도 기록되어 있지 않다. 이 상태로는 송신 의뢰가 와도 제대로된 통신을 할 수가 없다. → 소켓을 호출하여 만드는 것만으로는 프로토콜 스택에는 아무것도 전달되지 않기 때문에 IP 주소나 port 번호같은 내용을 프로토콜 스택에 알리는 동작(접속 동작)이 필요하다.

접속을 위해.. 즉, 통신을 위한 정보를 만들기 위해
1. 통신 상대와 제어 정보를 주고받아 소켓에 필요한 정보를 기록한다. (ex. 클라이언트 측의 IP 주소나 포트 번호를 서버 측에 알리는 것)
접속 동작에서 주고받는 제어 정보는 규칙이 정해져 있다.

2-2) 맨 앞부분에 제어 정보를 기록한 헤더를 배치한다.

TCP 헤더 내용

통신 동작 전체에서 어떤 정보가 필요한지 검토하는 TCP 프로토콜의 사양으로 규정되어있다.
이 항목들은 고정화되어 있어, 송수신/연결끊기/대화할 때마다 각 단계에서 이 제어 정보를 사용한다.
즉, 데이터를 나눈 패킷마다, 패킷의 가장 앞부분인 헤더에 이 내용이 부가되어 있다.
- 제어 정보만 있는 패킷은 뒷부분 데이터가 없고 제어 정보가 적힌 헤더만 존재

2-3) 접속 동작의 실체

애플리케이션이 socket 라이브러리의 connect를 호출하는 것부터 시작된다.

connect(<디스크립터>, <서버 IP>, <서버 PORT>)

접속 동작의 순서

클라이언트의 TCP 담당 부분에 ip와 port 전달 → 서버의 TCP 담당 부분에 전달
- 포트번호: 클라이언트 소켓의 수신처가 되는 서버측의 소켓을 지정할 수 있는 관문
포트를 통해 접속 소켓을 확실히 하고, 컨트롤 비트인 SYN = 1 세팅
위와 같이 TCP 헤더를 만들고 IP 담당 부분에 건넴
IP 담당 부분이 패킷 송신 동작 실행
네트워크를 통해 패킷을 서버에 보냄
서버측의 IP 담당 부분이 TCP 담당 부분에 건네어, 헤더 조사
수신처 소켓 즉, 포트 번호를 찾아서 필요한 정보를 기록하고 상태 변경(접속 동작 진행중)
응답 … 응답을 보낼 때도 마찬가지로, TCP 헤더 만들고, ACK = 1 세팅
응답을 받은 클라이언트는 또 다시 TCP 분석하고, SYN = 1 확인 후 소켓에 접속 완료를 나타내는 제어 정보를 기록
서버에게 응답을 잘 받았다는 ACK = 1 반송

⇒ 이 접속 동작이 끝나면 비로소 데이터를 송수신할 수 있는 상태가 된다. 파이프와 같은 것으로 소켓이 연결되었다고 생각하면 된다!

STORY 3 | 데이터를 송수신한다.

서버와 연결이 완료되면 애플리케이션 단에서 write 요청을 보낸다. 이때 프로토콜 스택은 송신 데이터의 내용을 알지 못한다. 데이터 길이만큼만 바이너리 데이터가 1바이트씩 차례로 나열되어 있다고 알고 있다.

3-1) 송수신 시, 내부 송신용 버퍼 메모리 활용

프로토콜 스택은 애플리케이션으로부터 받은 데이터를 일단 내부 송신용 버퍼 메모리에 저장한다.⇒ OS의 종류나 버전에 따라 버퍼의 수용 가능한 크기, 데이터를 보내는 시점이 다르다.
⇒ 송신 요청이 올 때마다 작은 소켓을 네트워크 상에 흘려보내면 네트워크 이용 효율이 저하되므로, 어느정도 데이터를 저장하고 나서 송수신 동작을 한다.

3-2) 일반적으로 데이터를 보내는 시점은?

2 가지 기준

1. MTU로 판단한다.

MTU(Maximum Transmission Unit): 패킷 하나로 운반가능한 데이터 최대 길이
MSS(Maximum Segment Size): MTU에서 TCP/IP의 헤더를 뺀 부분 ⇒ 즉, 페이로드 부분

2. 타이밍

애플리케이션의 송신 속도가 느려지는 경우 → 프로토콜 스택 내부의 타이머 활용

*두 기준의 trade-off를 잘 생각해야 한다. MTU에 너무 집중하면 네트워크 이용효율이 높지만 서비스/통신 지연 가능성이 생기고, 2번을 기준으로 타이머를 너무 짧게 잡으면 느려짐은 없어도 네트워크 이용 효율이 좋지 않아진다. → 이에 대한 명확한 기준은 없고 OS/프로토콜 스택 개발자에 달려있는 상황이다.

*타이밍 제어는 옵션으로 지정 가능하다.

3-3) 데이터가 크면 분할해서 보내기

블로그나 게시판 등에서 긴 문장을 투고하는 등 한 개의 패킷에 다 담기지 않는 경우 → 송신 버퍼에 저장된 데이터는 MSS 길이를 초과하므로, 맨 앞부터 차례대로 MSS 크기에 맞게 분할하고 분할한 조각을 한 개씩 패킷에 넣어 송신한다.

3-4) ACK를 통해 패킷이 도착했는지 확인

송신 측이 한 데이터를 N 바이트씩 나누어서 그 시작점을 시퀀스 넘버로 설저하고, 시퀀스 번호와 데이터 크기를 수신측에 같이 전송 → 수신측은 송신측으로받은 시퀀스 넘버 단위로 데이터를 받았다는 OK 사인을 전송
1. → seq: 1, 1460 byte
2. ← ACK 1461
3. → seq: 1461, 1460 byte
4. ← ACK 1462

그런데, TCP의 송수신 동작은 양방향이므로, 두 가지의 데이터 흐름이 있다. (→, ←) 이에 대응하기 위해서 클라이언트 측에서도 ACK를 전송, 서버측에서도 시퀀스 넘거를 전송해준다.

먼저 시퀀스 넘버를 양쪽에서 산출하고, 접속 동작을 할 때 서로 통지한다. → 이때도 서로 ACK 반송
시퀀스 번호와 ACK 번호가 준비되면 데이터 송수신 동작에 들어간다.
최초 클라이언트가 요청하면 서버에서 ACK를 반송하는 방식으로 데이터를 주고받는다.

→ TCP는 상대의 데이터 수신을 확인할 때까지 송신용 패킷을 버퍼 메모리에 저장해둔다. 만약 이에 대응하는 상대의 ACK가 오지 않으면 다시 이 데이터를 보내야 하기 때문이다.

→ TCP의 이러한 통신 방식으로 인해, 송수신을 TCP에만 맡겨두면 LAN 어댑터, 라우터 등 어디에서도 오류 검출을 할 필요가 없다. 네트워크의 어디에서 오류가 발생하더라도 TCP의 통신 특성만으로 회복 처리를 취할 수 있기 때문이다. 단, 도중에 케이블이 분리되거나 서버가 다운되는 등의 문제가 생기면 TCP가 아무리 데이터를 다시 보낸다고 해도 해결할 수 없다. 이럴 때에는 TCP가 몇 번 다시 보낸 후 회복의 전망이 없는 것으로 보고 데이터 송신 동작을 강제로 종료하고 애플리케이션에 오류를 통지한다.

3-5) ACK의 대기시간은?

ACK의 반송이 지연되는 상황은 보통 혼잡인 경우가 많으므로, 너무 자주 다시 데이터를 보내면 혼잡을 더 악화시킬 수 있다. 하지만 대기 시간을 너무 길게 잡으면 패킷을 다시 보내는 동작이 지연돼서 속도 저하의 원인이 될 수 있다. (→ 아까 내부 송신용 버퍼에 저장하고 데이터를 보내는 시점을 설정하는 것과 비슷한.. trade-off)

동적으로 TCP 대기시간 변경이 가능하다.
- ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 판단한다. 데이터 송신 동작을 실행하고 있을 때 항상 ACK가 돌아오는 시간을 계측해 두고, 조정한다.

3-6) 윈도우 제어 방식으로 패킷 송수신 효율 높이기

수신 측의 능력을 초과할 만큼 데이터를 한 번에 쏟아내버리면?수신 가능한 데이터의 최대양을 윈도우 크기라고 한다.
- 감당 가능한 데이터의 양을 정해서 송신(클라이언트)측에 알려준다. 클라이언트는 데이터를 보낼 때 보낸 데이터의 크기와 용량을 비교하면서, 가능한 남은 영역이 0이 되면 송신을 중지한다.
윈도우 통지 타이밍
- 송신측은 한 번 통지를 받으면 송신한 데이터와 비교하여 스스로 남은 값을 계산할 수 있다. 그러므로, 수신 측에서 애플리케이션에 데이터를 건네주고 수신 버퍼의 빈 영역이 늘어났을 때 송신측에 통지해야 한다.
ACK와 윈도우 통지 패킷을 줄이고 효율적인 통신을 하는 방법
1. 소켓을 바로 보내지 않고 잠시 기다린다. 이때 다음 통지 동작이 일어나면 양쪽을 상승 시켜서 함께 하나의 패킷으로 묶어 보낸다.
2. ACK 번호 통지가 여러 번 연속해서 일어나면 최후의 것만 통지한다. (도중의 것 생략 가능)

STORY 4 | 서버에서 연결을 끊어 소켓을 말소한다.

서로 FIN, ACK를 주고 받는다. (데이터 전송이 끝난 측에서 먼저 FIN 전송)
소켓이 말소되면 모든 정보가 없어진다. → 이때 애플리케이션이 다른 소켓을 작성하면 말소된 포트 번호를 사용할 수 있기 때문에 마지막 FIN에 대한 ACK는 어느정도 시간을 두고 말소한다.

STORY 5 | IP 패킷 송수신 동작

큰흐름

TCP 담당 부분에서 패킷을 바이너리로 전달받은 IP는 IP헤더, MAC 헤더 만들어서 이더넷에 보내고, 이더넷은 이 IP 패킷(디지털 데이터)를 전기 신호/빛으로 변환해서 케이블로 데이터를 흘려보낸다. 모든 소켓관련 내용은 위에서 다 해주기 때문에 이더넷은 모든 기기에 공통적으로 행동한다.

5-1) 앞에서 프로토콜스택.. TCP로부터 의뢰받은 IP는 어떻게 동작할까?

송신처에서 소켓을 가장 가까운 중계처(라우터 등)로 전송하면, 소켓 헤더에 저장된 정보 + 중계처의 표(수신처/가까운 또다른 중계처의 방향에 대한 정보)를 통해 데이터를 전송한다.

허브: 이더넷의 규칙에 따라 패킷 운반
라우터: IP의 규칙에 따라 패킷 운반

■ 실제로 송신처 컴퓨터부터 중간 중계장치들(라우터, 허브 등)을 거치는 과정

송신처에서 패킷이 가려는 서버의 IP 주소를 IP 헤더의 수신처에 기록한다.
패킷의 목적지가 분명해지므로, IP는 이 수신처가 어느 방향에 있는지 + 라우터를 조사한다.
이어서 다음 방향의 라우터 조사한다.
다음 방향의 라우터로 패킷을 보내도록 이더넷에 의뢰한다.
다음 라우터에 할당된 이더넷의 주소(MAC 주소)를 이더넷이 알려주고, 이를 MAC 헤더에 기록한다.
이더넷 추천 경로에 따라 허브에 도착한다.
허브에서는 수신처 정보와 표를 결합해서 목적지를 판단 및 중계한다.
패킷은 다음 라우터에 도착한다.
라우터에는 IP용 표가 있으므로, 이것과 IP 헤더의 수신처를 결합해서 다음 중계지(라우터)를 결정한다.
해당 라우터의 MAC 주소를 헤더에 붙여서 송신한다.

5-2) 패킷 송수신 동작의 개요

■ 패킷 송수신은 TCP 담당부분이 IP 담당 부분에 패킷을 의뢰하는 것부터 시작된다.

TCP 담당 부분은 [TCP 헤더 + 데이터 조각]을 IP 부분에 건네준다.

■ TCP 담당으로부터 송신 의뢰를 받은 IP 담당 부분은 추가적인 헤더를 붙여, 네트워크용 HW에 건네준다.

IP 헤더: IP 프로토콜에 규정된 규칙에 따라 패킷을 목적지에 보낼 때 사용하는 제어 정보
MAC 헤더: 이더넷 등의 LAN을 사용하여 가장 가까운 라우터까지 패킷을 운반할 때 사용하는 제어 정보

■ 네트워크 HW, 이더넷 등에서는 0과 1로 구성된 디지털 데이터를 받아서 전기 신호 상태로 바꾸어 케이블에 송출한다.

신호는 허브나 라우터 등의 중계 장치에 도착하고, 이 장치가 상대가 있는 곳까지 패킷을 전달한다.

IP 패킷 송수신 동작은 패킷의 역할에 관계없이 모두 같다. IP 담당 부분은 TCP 담당으로부터 받은 데이터를 그냥 하나의 바이너리 데이터로 간주하고 내용물에 대해서는 전혀 관심이 없다. 당연히 TCP의 동작 단계도 신경쓰지 않는다. 어떤 형식이든 의뢰받은 내용물을 패킷의 모습으로 만들어 상대에게 송신 및 전달하기만 할 뿐이다.

5-3) IP 헤더

가장 중요한 것은 수신처(목적지) IP 주소(애플리케이션에서 통지된 통신 상대의 IP 주소)다. IP는 애플리케이션이 지정한 것이 잘못되었어도 그대로 송신한다. 애플리케이션 측 책임으로 간주하기 때문이다
송신처 IP 주소는 사실 컴퓨터에 할당되는 것이 아니라 LAN 어댑터에 할당되므로, 복수의 LAN 어댑터가 있을 경우 한 대의 컴퓨터에 할당된 IP가 여러 개다.
- 따라서 어느 IP 주소를 송신처 주소로 설정할 지 판단해야 한다. → 이 판단은 패킷을 건네주는 상대의 라우터를 결정하는 것과 같다.
- 상대 라우터가 결정되면 LAN 어댑터에서 패킷을 송신해야 하는지 결정되고, LAN이 결정되면 IP 주소가 결정되기 때문이다.

■ 패킷을 건네주는 상대의 라우터를 판단하는 방법?

라우터가 IP용 표를 사용하여 다음 라우터를 결정하는 것과 같다.
route print 명령어
- interface: 네트워크용 인터페이스
- Gateway: 다음 라우터의 IP 주소
- 넷마스크: 기본 gateway
- 프로토콜 번호: 어디에서 의뢰받은 것인지 설정(TCP: 06, UDP: 17)

5-4) 이더넷용 MAC 헤더 - IP 헤더 만들고, MAC 헤더 만들어 붙이기

■ IP 헤더를 통해 목적지 주소를 알 수 있지만, 이더넷에는 TCP/IP 개념이 통용되지 않는다. 따라서 이더넷 패킷을 운반하기 위해서 수신처를 판단할 때 MAC 헤더를 사용한다.

송신처 MAC 주소: 하나의 48비트, LAN 어댑터의 MAC 주소 설정
- MAC 주소는 LAN을 제조할 때 그 안의 ROM에 기록한다.
수신처 MAC 주소: 패킷을 건네주는 상대의 MAC 주소
- 패킷을 건네줄 상대의 주소는 경로표 ‘Gateway’에 기록되어 있다.
이더 타입: 패킷의 내용물이 무엇인지 나타냄
- 이더타입까지가 MAC 헤더이고, 그 뒤에 이어지는 것은 패킷의 내용물
- 이더넷의 내용물은 IP, ARP같은 프로토콜의 소켓이며, 각각에 대응하는 값이 규칙적으로 정해져 있으므로 여기에 값을 기록한다.

5-5) ARP로 라우터의 MAC 주소 조사한다.

상대가 자신과 같은 네트워크에 존재하면 단순히 브로드캐스트로 “OO라는 IP 주소 있는 분?” 이렇게 찾을 수 있다. 그럼 "저요~"하는 상대방의 MAC 주소를 MAC 헤더에 설정하면 끝이다.

■ ARP 캐시

패킷을 보낼 때마다 "있으신 분 - 저요" 동작을 반복하면 ARP 패킷이 불어나기 때문에 ARP 캐시라는 메모리 영역에 보존하여 재사용한다.
ARP 캐시를 먼저 확인하고, 없는 경우에만 브로드캐스트한다.
캐시에 저장된 내용은 일정 시간이 지나면 삭제된다. (오류 방지를 위해)

■ 이러한 MAC 주소/헤더를 붙이는 것까지 IP 담당 부분의 역할이다.

LAN 어댑터에 건네주기 전에 IP 담당 부분에서 패킷을 완성하면 LAN은 전송만 하면 되기 때문에 IP 쪽이 담당한다!

STORY 6 | 이더넷 패킷 송수신 동작

5-6) 이더넷의 기본

MAC 헤더의 수신처 MAC 주소를 가진 상대에게 패킷을 전달한다.
송신처 MAC 주소로 송신처를 나타낸다.
이더 타입으로 패킷의 내용물을 나타낸다.
‘이더넷’이라는 하나의 사양에 기초하여 동작하기 때문에 클라이언트, 라우터 등 상관없이 모든 기기에 공통적으로 적용된다.

5-7) IP로부터 받은 패킷(디지털 데이터)을 전기/빛의 신호로 변환하여 송신한다.

■ IP 패킷으로 받은 디지털 데이터를 전기 신호로 변환하는 것은 LAN 어댑터다.

하지만 LAN 어댑터는 단독으로 일할 수 없고, 이를 제어하는 LAN 드라이버 소프트웨어가 필요하다. (모든 HW의 공통.. 이를 제어하는 SW가 필요함)
전원 공급 → OS 시동 → 드라이버가 어댑터 초기화(MAC 주소 설정) → OK

■ IP한테 패킷을 받으면 LAN 어댑터의 버퍼 메모리에 복사 후, 패킷을 송신하도록 MAC 회로에 명령을 보낸다.

5-8) 패킷에 3개의 제어용 데이터를 추가한다.

프리앰블(preeamble): 송신하는 패킷을 읽을 타이밍을 잡기 위한 것. → 101110… 이라는 비트 패턴을 신호로 바꾸면 파형이 일정한 모습을 갖는다. 수신측은 신호를 수신할 때 이 파형에서 타이밍을 잡는다.
스타트 프레임 딜리미터: 패킷의 시작을 나타내는 표시
FCS(Frame Check Sequence): 운반하는 도중 파형이 흐트러져 데이터가 변한 경우, 이를 검출하기 위해서 사용한다. 계산의 바탕이 된 데이터 값이 1비트라도 변화하면 달라진 값을 취하도록 고안이 되어 있다. 패킷을 운반하는 도중 잡음 등의 영향으로 데이터가 변하면, 수신측에서 계산한 FCS가 송신측과 달라진다. 이 차이를 통해 전달 과정에서 문제가 발생했음을 파악한다.

5-9) 허브를 향해 패킷을 송신한다.

위 세 가지를 부가하면, 케이블에 송출하는 패킷이 완성된다. 드디어 신호를 송신할 수 있는 상태가 된다!

■ [반이중 모드] 이더넷 구조를 따라 패킷이 변환되어 케이블까지 흘러가는 과정

케이블에 다른 기기가 송신한 신호가 흐르고 있는지 조사하고, 끝날 때까지 기다린다. (신호 충돌 방지)
MAC 회로가 프리앰블의 맨 앞부터 1비트씩 차례로 전기 신호로 변환한다.
- 이때 디지털 데이터를 신호로 변환하는 속도가 전송 속도다. →만약 1초 동안 10MB 디지털 데이터를 신호로 변환하여 보낸다면 전송률은 10MiB/초
이후 변환된 전기 신호를 PHY(MAU) 신호 부분에 보낸다. 이 전기 신호를 다시 케이브렝 송출하는 형식으로 변환하여 송신한다. 즉, PHY는 MAC 회로가 송신한 전기 신호의 형식을 케이블 형시긍로 변환하기 위한 변환회로다!
- PHY는 송신 동작만 하는 것이 아니라 수신 신호선에서 신호가 흘러들어오는지 감시한다.

*이더넷은 송신한 신호가 상대에게 완전히 도착했는지 확인하지 않는다. 이더넷은 사양에서 기기와 기기 사이를 연결하는 케이블 길이를 100m 이내로 정한다. 그래서 오류가 좀처럼 발생하지 않는다.

■ PHY는 송신 동작만 하는 것이 아니라 수신 신호선에서 신호가 흘러들어오는지 감시한다.

이때, 리피터 허브(b)를 사용한 반이중 모드의 경우에는 서로의 신호가 뒤섞여서 분간할 수 없는 상태(충돌)가 된다.
그러면 송신 동작을 중단하고 충돌 사실을 다른 기기에 알리는 재밍 신호를 흘린다. 재밍 신호를 흘리고 잠시 기다렸다가 다시 송신 동작을 시도한다.
스위칭 허브(c)를 사용한 전이중모드는 송수신을 동시에 실행하면서 충돌은 일어나지 않는다.

5-10) 돌아온 패킷을 받는다.

■ 리피터 허브를 이용한 반이중 동작의 이더넷에서의 동작 과정

1대가 송신한 신호가 리피터 허브에 접속된 케이블 전부에 흘러간다.
프리앰블, 스타트 프레임 딜리미터가 나오면 그 다음 비트부터 디지털 데이터로 변환한다. (그러니까 송신의 거꾸로)
1. 먼저 PHY회로에서 신호를 공통 형식으로 변환하여 MAC 회로에 보낸다.
2. MAC 회로에서 신호를 맨앞부터 차례대로 디지털 데이터로 변환하여 버퍼 메모리에 저장한다.
3. 신호의 마지막에서 FCS 검사 ➡️ 잡음 확인
FCS에 문제가 없으면 MAC 헤더의 나의 MAC 주소와 비교하여 자신에게 오는 것인지 판단한다.
자신에게 오는 게 맞으면 인터럽트를 통해 컴퓨터 본체에 통지한다.

■ 인터럽트의 동작 과정

LAN 어댑터가 확장 버스 슬롯 부분에 있는 인터럽트용 신호선에 신호 전송 → 본체는 이 신호를 받고 CPU가 실행하고 있던 작업을 일시적으로 보류 → OS 내부 kernel 모드 실행 → LAN 드라이버 호출 → LAN 드라이버가 LAN 어댑터를 제어하여 송수신 동작 실행

5-11) 서버의 응답 패킷을 IP에서 TCP로 넘긴다.

■ LAN은 TCP/IP(0800)임을 확인하고 IP 부분으로 올려 보낸다. IP 담당 부분은 헤더 부분부터 조사하여 문제가 없는지 확인한다.

만약 수신처 IP 주소가 잘못 적혀 있다면, ICMP라는 메시지를 사용하여 통신 상대에게 오류를 통지한다. (181p의 다양한 메시지 종류)
IP 헤더의 플래그를 확인해서 이 패킷이 만약 분할된 패킷(IP Fragmentation)이라면 IP 담당 부분 내부의 메모리에 일시적으로 보관한다. 그리고 같은 frag를 가진 패킷이 도착하기를 기다리고, 모든 패킷이 도착하면 각각의 패킷마다 붙어있는 offset 순서대로 원래의 모습으로 되돌린다. 이 되돌리는 동작을 리어셈블링이라고 한다.

■ 리어셈블링이 끝난 패킷을 TCP 담당 부분에 전송한다.

송수신처의 ip, port를 통해 해당 소켓을 찾아 적절한 통신을 한다. (소켓에는 통신 진행 상태가 기록되어 있다.)
만약 연결 끊기(FIN같은) 패킷이라면 애플리케이션에게 통지하거나 응답 패킷을 반송한다.

[CloudType] AWS에서 cloudtype으로 DB 마이그레이션하기

sebinChu — Sat, 10 Aug 2024 17:58:33 +0900

개요

앞편에서 cloudtype의 MariaDB를 생성해주었다. 이에 이어서 AWS MySQL로부터 cloudtype MariaDB로 마이그레이션을 함으로써 비용을 절약해보자.

가장 먼저 cloudtype 프로젝트 전체 설정(나의 경우 koala)에서 TCP 허용이 되어있는지 확인하자.

1) RDS 외부 접근을 위한 작업

일단 마이그레이션을 하려면 AWS RDS에 직접 내 로컬에서 접근이 가능해야 한다.

1-1) 마스터 암호 설정

DB 수정을 통해 마스터 암호를 설정하자.

1-2) 퍼블릭 액세스 허용

1-3) 보안그룹이 설정되어 있다면 인바운드에 나의 IP 등록

DB에 보안그룹이 설정되어있다면, 나의 IP가 접근 가능하도록 정보를 등록해준다.

2) 로컬 터미널에서 명령어를 통해 AWS RDS에 접근하기

mysql -h [endpoint] -u [user명] -P [port번호] -p

해당 명령어를 입력해서 AWS RDS에 접근한다. 엔드포인트와 유저명은 AWS RDS 콘솔의 속성에서 확인할 수 있다!

아까 설정한 마스터 암호를 입력하고 접속하면 위와 같이 접근 성공 메시지와 mysql> 이라는 터미널이 뜬다. 이렇게 되면 접근 성공이다!

여기서 SHOW databases; 명령어를 통해 내가 접근할 database 이름을 확인해두자.

2-1) mysqldump 명령어를 통해 데이터 백업하기

DB 연결 및 정보를 확인한 뒤, exit로 종료하고 나서 mysqldump 명령어를 통해 DB의 정보를 백업한다.

mysqldump --set-gtid-purged=OFF -u [사용자명] -p[비밀번호] --host=[AWS RDS 엔드포인트] [데이터베이스명] > [원하는 파일명].sql

이 과정에서 다양한 에러가 발생할 수 있는데, 확인해볼 점은 다음과 같다.하나의 철자라도 틀리면 접근할 수 없으니 여기서 꼼꼼히 할 수 있도록 주의하자..!

보안그룹 인바운드 규칙(1번 참고)
AWS DB 정보(RDS명, DB명, 마스터유저, 마스터비밀번호 등)
로컬에서 mysql이 실행중이라면 확인 후, 이 프로세스를 죽이고 명령어를 실행할 것

또 주의할 점

이 문서에서 잘 알 수 있는데, mysqldump 명령어를 사용할 때, --set-gtid-purged=OFF 옵션을 빼먹지 않도록 주의하자.

필자는 ERROR 1227 (42000)를 마주하고나서야 알게되었다. 보통의 mysql db 복구는 GTID를 사용하지 않기 때문에 백업 단계에서 꼭 이 옵션을 추가해주어야 한다!

GTID를 간단하게 말하자면 MySQL 복제에서 서버의 각 트랜잭션을 구분하는 고유한 식별자로, 백업 과정에 쓰이는 기능이다.

해당 명령어를 실행하면 내 로컬 컴퓨터 루트 경로에 sql 파일이 하나 생겨있음을 확인할 수 있다.

3) cloudtype MariaDB에 접속하기

AWS에 접근했을 때와 거의 동일하다.

mysql -h [endpoint] -u [user명] -P [port번호] -p

사용할 데이터베이스를 use [database명]; 으로 ON 해주고, source [로컬경로/백업파일명.sql] 명령어를 통해 백업 파일을 실행해주자.

ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'

MySQL Workbench에서 해당 부분을 모두 'utf8m64_general_ci'로 변경해준다. 워크벤치의 Replace 기능을 활용하면 훨씬 수월하다.

쿼리문이 뜨고 데이터들이 잘 담긴 모습을 확인할 수 있다.

4) DataGrip, IntelliJ에서 데이터와 API 확인해보기

이후에 IntelliJ의 MySQL 의존성을 모두 MariaDB로 변경해준다.
환경변수도 바꿔주고,
API 몇 개 테스트 한 뒤 서버에 적용하면 끝..!

배포까지 완료

cloudtype이 아직 활발히 쓰이진 않아서 다양한 자료를 찾기 어려웠다. (GCP를 쓸 때 하도 당해서 익숙하다..~)

꽤나 까다로웠던 마이그레이션 덕분에 4배 정도는 비용을 아낄 수 있게 되어 다행이다!

추가))

AWS 예상 비용을 확인해봤더니, RDS 없애기 + VM 인스턴스 스펙 낮추기로 비용이 확연히 줄었다!

[CloudType] cloudtype으로 DB 호스팅 비용 줄이기

sebinChu — Fri, 9 Aug 2024 14:53:05 +0900

개요

koala 프로젝트를 하다가 첫 난관(?)이 생겼다..! 바로 서버 비용이 없다는 것

이 설계에 맞춰서 클라우드 환경을 구축하기 전에, "이렇게 가면 비용이 꽤 들 것같은데 우리 얼마 쓰고 있지?" 확인하는 것에서부터 서버 비용에 대한 걱정이 시작되었다.. ㅋㅋ

RDS에서 가장 많은 비용이 발생하고 있었고, 프로젝트X를 수강하지 않는 이상 지원을 받기 힘들기에.. 어떻게든 방법을 찾아야 했다!

아예 cloudtype 서비스로 옮겨보자!

사실 첫 시도에서는 AWS를 이용하지 않고 아예 cloudtype을 사용하자는 생각이었다. 하지만 cloudtype을 구축하는 과정에서 만난 문제들을 해결하지 못했고, 가장 비용이 많이 드는 RDS만이라도 cloudtype을 이용하자는 결론을 도출하게 되었다.

난 아직 한참 멀었구나..

cloudtype은 비교적 합리적인 비용으로 웹사이트/데이터베이스 등을 호스팅할 수 있는 국내 서비스다. 디스코드 채널에서 실시간으로 문제 해결도 공유 가능한 아주 친절한 서비스다..! 가격도 저렴하고 무료 호스팅까지 가능하니, 나처럼 돈이 없는데 프로젝트를 호스팅해야 한다면 추천한다.!!

Mariadb 사용하기

서론은 끝마치고, cloudtype에서 RDS 호스팅을 해보자.

우선 나의 경우 이미 초기 세팅은 모두 마친 상태다. 또한 test 서버와 연동될 mariaDB가 이미 하나 실행되고 있는 상태다.

초기 세팅이라고 해도 사실 별 거 없다. 여러 서비스를 호스팅할 프로젝트(나의 경우 화면상 보이는 koala)를 하나 생성해주고 워크스페이스처럼 사용하면 된다.

프로덕션 환경용 DB를 생성해주기 위해 화면상 오른쪽 하늘색 화살표를 클릭해서 DB를 생성해주자.

그럼 이렇게 다양한 옵션들을 확인할 수 있다! 여기서 MariaDB를 검색해주자. 참고로, Dockerfile로 올릴 수 있는 도커 템플릿도 있고 SpringBoot 템플릿도 있고, Github 저장소와 바로 연동하여 배포도 할 수 있다.

MariaDB를 검색해서 클릭하면, DB 세팅 화면이 나온다.

DB 설정과 버전, 패스워드를 입력한다. 필자는 안전한 운영을 위해 더 많은 옵션을 이용해서username, password까지 추가하였다!

마지막으로 성능을 선택해준다. cloudtype은 무료료 제공하는 CPU와 메모리 수준이 있다. 만약 대용량 데이터를 담아야 하거나, 성능이 매우 좋은 DB를 써야 한다면 구독 플랜을 업그레이드 시켜주면 된다.

모든 설정을 마치고 DB의 워크로드를 확인해보면 정상적으로 실행 중임을 확인할 수 있다.

다음 포스팅에서는 이 DB를 직접 AWS 서버와 연결해서 운영하는 내용에 대해 담아보면 좋을 것같다.

이로 인해 서버 비용을 확실히 줄일 수 있어서 다행이다!! 길이 없으면 길을 만들며 간다는 말이 떠오른다. 런칭까지 아주 파이팅이다.

[Network] 네트워크 원리(1) 웹 브라우저가 메시지를 만든다.

sebinChu — Thu, 8 Aug 2024 20:36:21 +0900

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

STORY 1 | HTTP 리퀘스트 메시지를 작성한다.

1.1) URL 입력과 해독, HTTP 메시지 주고 받기

URL(Uniform Resource Locator)

URL은 사실 http: 뿐만 아니라 ftp:, file:, mailto:로 시작하는 것 등 여러가지가 있다.

보통 우리가 브라우저를 사용할 때는 웹 서버에 접근하는 클라이언트로 사용하지만, 브라우저의 기능은 다양하기 때문이다. 파일을 다운로드/업로드하는 FTP의 클라이언트 기능이나 메일 전송 클라이언트 기능도 가지고 있다.
브라우저는 몇 개의 클라이언트 기능을 겸비한 복합적인 클라이언트 소프트웨어다.

각종 URL 형식 예시와 공통점

가장 앞부분에서 브라우저에 액세스하는 방법을 나타낸다. ex) http: ftp: news:..
맨 앞부분의 액세스하는 방법(프로토콜)에 따라 뒤 형식이 달라진다.

1.2) 브라우저는 먼저 URL을 해독한다.

브라우저는 웹 서버에 보내는 Request Message를 작성하기 위해서 URL을 먼저 해독한다.

→ URL 형식으로부터 어떤 통신인지(프로토콜)를 알 수 있고, 이에 따른 정보들이 존재하기 때문이다.

→ URL 해독을 통해 클라이언트의 접근 위치를 파악한다.

(a) URL의 요소

<http://csstudy.com/network/login.html>

http: 데이터 출처에 접근하는 방법 즉, 프로토콜
// : 나중에 이어지는 문자열이 서버의 이름임을 나타냄
/디렉토리명/+ … +/파일명: 데이터 출처의 경로
login.html은 파일명으로 생략 가능하다.

http://csstudy.com/network 이런식으로 작성하면 되는데, URL 끝 부분이 /로 끝나는 것은 뒤에 파일이 생략되어 있다는 뜻이다.

파일명을 생략할 때는 미리 서버측에서 ‘index.html’, ‘default.html’ 등과 같은 파일명을 설정해둔다. 젤 뒤의 / 마저 생략하는 경우도 있다. 하지만 이렇게 디렉토리명까지 생략해버리면 무엇을 요청하는지 알기 힘드므로, 지나친 생략일 수 있다. 경로명이 아무것도 없는 경우에는 루트 디렉토리의 아래에 미리 설정된 파일명의 파일로 접근하는 방식으로 인정되고 있다.

1.3) HTTP

URL 해독 후, HTTP 프로토콜을 사용하여 웹 서버에 접근한다.

클라이언트는 서버측에 ‘무엇을(URI)’ ‘어떻게(HTTP method)’ 하겠다는 요청을 보낸다.
URI에 나타낸 데이터를 읽고싶다거나, 클라이언트 측에서 입력한 데이터를 URI로 나타낸 프로그램에 전달하고 싶다는 식의 동작이 대표적이다.
요청을 받은 서버는 그 속에 쓰여있는 내용을 해독한다. 그리고 URI와 메시지를 조사하여 요구에 따라 동작하고, 결과 데이터를 응답 메시지에 저장한다. 응답 메시지의 맨 앞부분에는 실행 결과가 정상 종료인지 이상이 있는지를 나타내는 상태 코드가 있다.

HTTP Request Message

HTTP는 쓰는 방법이 정해져 있으므로, 이에 맞게 브라우저가 Request Message를 제작한다.

메소드, URI, HTTP 버전
메시지 헤더

- 리퀘스트 메시지에 쓰는 URI는 한 개만으로 결정되어 있으므로 파일을 한 번에 한 개씩만 읽을 수 있기 때문에 파일을 따로따로 읽어야 한다.
- 첫 번째 행에서 주어진 내용보다 더 자세한 정보가 필요한 경우에 2행부터 메시지 헤더를 사용한다.

HTTP Response Message

Request에 대한 결과를 나타낸다.

응답 상태 코드와 문구를
응답 메시지가 돌아오면 데이터를 추출한 후 화면에 표시한다.

- 서버 측은 단순히 한 개의 리퀘스트에 대해 한 개의 응답만 돌려 보낸다. 필요한 파일을 읽고 레이아웃을 정하여 화면에 표시하는 상태로 전체 동작을 조정하는 것은 결국 브라우저의 역할이다.

STORY 2 | 웹 서버의 IP 주소를 DNS 서버에 조회한다.

2.1) 도메인 - IP 매핑

HTTP 메시지를 만들면 OS에 의뢰하여 웹 서버에게 송신한다.

브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 직접 전송하고 네트워크에 송출하는 기능은 없다.
OS에 송신 의뢰를 할 때에는 도메인명이 아니라 IP 주소로 상대를 지정한다. 따라서 HTTP 메시지를 만드는 동작의 다음은 도메인명을 통해 IP 주소를 조사하는 것이 된다.

2.2) IP 주소

TCP/IP 네트워크는 작은 서브넷을 라우터로 연결하여 전체 네트워크를 완성한다. 쉽게 말해서 서브넷은 아파트 주소의 동, 호수는 ip 주소라고 생각하면 된다. 택배 받는 사람 기입란에 접근 대상의 주소를 기입하여 데이터를 보낸다. 그러면 라우터가 받는 사람을 보고 이것이 어떤 호수에 있는지 조사하여 그곳으로 데이터를 중계한다.

IP는 주소와 같은 것이므로 다른 곳에 같은 값이 할당되면 안 된다. →
OO동 XX호의 OO동은 서브넷 번호 즉, 네트워크 번호다. XX호는 호스트 번호로, 이 둘을 합쳐서 IP 주소라고 한다.
IP 주소 = 네트워크 주소 + 호스트 주소

송신측이 메시지를 보내면, 서브넷 안에 있는 허브가 데이터를 운반한다.
송신측에서 가장 가까운 라우터까지 운반된다.
그리고 라우터가 이 메시지 상대를 확인하여 다음 라우터를 판단하고, 거기에 보내도록 지시한다.
이후 다시 서브넷의 허브가 라우터까지 메시지를 보낸다.
이 동작을 반복하면 최종적으로 상대의 데이터가 도착한다. (TCP/IP의 기본 개념)

IP 주소 표기

(a) IP 주소 본체의 표기 방법

10.11.12.13

(b) IP 주소 본체와 같은 방법으로 네트워크를 표기하는 방법

10.11.12.13/255.255.255.0(넷마스크)

(b) 네트워크 번호의 비트 수로 넷마스크를 표기하는 방법

10.11.12.13/24

10.11.12.0/24
- 이 부분이 모두 0이면 서브넷 자체를, 1이면 서브넷 전체에 대한 브로드캐스트를 나타낸다.
- 브로드캐스트 주소 → 네트워크 내의 모든 주소에 데이터를 전달할 때

넷마스크

a.a.a.a처럼 8비트씩 점으로 구분하여 10진수로 표기하는 것이 일반적인 IP 주소다. 이것만으로는 어느 부분이 네트워크 번호인지, 호스트 번호인지 알 수 없다. → IP 주소의 규칙에서는 네트워크 번호와 호스트 번호의 두 가지를 합쳐서 32비트로 한다는 것만 결정되어 있을 뿐, 내역은 결정되어 있지 않다.

네트워크를 구축할 때 사용자가 직접 내역을 결정할 수 있다.
이 내역을 나타내는 정보를 IP 주소에 덧붙이는데, 이 정보를 넷마스크라고 한다.
- 1으로 표기된 것이 네트워크 번호, 0으로 표기된 것이 호스트 번호
- 1111111 / 111111 / 0000000 / 00000

2.3) 도메인명과 IP 주소를 구분하여 사용하는 이유

■ 사용자가 IP 주소를 일일이 외우는 것에 대한 어려움은 공감이 가는데… 그럼 OS 측에도 도메인명을 알려준 다음, 상대를 지정하고 통신하면 안 될까?

실행 효율이라는 관점에서 좋은 방법이 아니다. 인터넷 내부에는 다수의 규칙이 있고, 그것들이 연대하여 데이터를 운반한다.
IP는 32비트, 즉 4 바이트에 해당하는 개수밖에 없지만, 도메인명은 적어도 수십 바이트부터 최대 255바이트나 있다. 이 문자를 취급하기 위해서 그만큼 라우터가 부하되어 데이터 운반 속도에 직접적인 영향을 미칠 것이다. 도메인 → DNS 서버 …

■ 그렇다면 고성능 라우터를 쓰면 해결되지 않을까?

한계가 있다. 한계로 인해 방대한 양의 데이터가 인터넷 내부에 정체되어 있을 수 있다.
데이터 양도 기술의 발전에 못지 않은 속도로 증가하고 있다.

⇒ 사람은 이름을 사용하고, 라우터는 IP 주소를 사용한다는 방법이 고안되었고, 현재 이 방법이 정착되어 있다. 이름만 알면 IP 주소를 알 수 있다거나, IP 주소를 알면 이름을 알 수 있다는 원리를 사용하여 양쪽의 차이를 해소하는 것이 DNS의 원리다.

STORY 3 | 전세계의 DNS 서버가 연대한다.

3.1) DNS 리졸버

핵심은 IP 주소를 조사하기 위해 ”DNS에 질의를 한다.”는 것이다. 이를 위해 DNS 서버에 조회 요청을 날리고, 그에 대한 응답 메시지를 받는다. 결국 DNS 서버에 대해 클라이언트로 동작한다. 이 DNS 클라이언트를 DNS 리졸버라고 한다.

DNS 리졸버(or 단순히 리졸버): 가장 가까운 DNS 서버에 IP 주소를 질의한다. 즉, DNS 서버에 클라이언트로 동작한다.
네임 리졸루션(name resolution) : DNS 원리를 사용하여 IP 주소를 조사하는 것

3.2) 소켓 라이브러리와 리졸버

소켓 라이브러리

리졸버는 소켓 라이브러리에 내장되어 있는 기능이다. 소켓 라이브러리는 OS가 네트워크 기능을 할 때 필요한 작업들을 모아놓은 것이다.

모든 개발자를 위한 HTTP 웹 기본 지식

브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 직접 전송하고 네트워크에 송출하는 기능은 없기 때문에 OS에 이를 의뢰하게 된다. 따라서 위 이미지처럼 애플리케이션 단에서 소켓 라이브러리와 같은 기능을 호출함으로써 송수신을 부탁하게 된다.

3.3) 리졸버 호출과 위치

https://yeonyeon.tistory.com/243

소켓 라이브러리 내에 구현된 리졸버가 OS에게 실행을 의뢰하고, OS는 이 요청 세미지 대로 송수신을 한다.

세부 내용은 아래와 같다.

3.4) 리졸버 - OS 내부 작동

애플리케이션 안에 <메모리 영역> = gethostbyname(”www.cobinding.tistory.com”)과 같이 쓰면 리졸버가 호출되어, DNS 서버에 대한 IP 주소 조회 동작을 실행할 수 있다.

이 화살표를 하나하나 따라가보면 이해에 도움된다! 풀어쓰면 아래와 같다.

브라우저와 같은 애플리케이션이 리졸버(socket 라이브러리)를 호출
리졸버가 OS에게 DNS 서버에 조회 메시지를 보내야 한다는 메시지 생성해서 프로토콜 스택 호출
- 프로토콜 스택: OS 내부에 내장된 네트워크 제어용 SW
OS가 리졸버에게 메시지 받아서 네트워크 영역의 송수신 담당
LAN 어댑터를 통해서 메시지가 DNS 서버를 향해 송신
DNS 서버의 응답이 클라이언트에게 위 과정을 거꾸로 거쳐서 반송
리졸버는 OS에게 응답 메시지를 받아서, IP 주소를 추출하여 <메모리 영역>에 저장하고 애플리케이션에게 이 IP 주소를 건네줌.

*DNS 서버에 메시지를 송신할 때 IP 주소는 필요 없을까?

→ 컴퓨터에 미리 TCP/IP 설정 하나하나가 되어있다. 리졸버는 여기에서 설정된 DNS 서버의 IP 주소에 조회 메시지를 보낸다!

STORY 4 | 프로토콜 스택에 메시지 송신을 의뢰한다

IP 주소를 조사하고 난 후, 웹 서버에 메시지를 송신하도록 프로토콜 스택에 의뢰한다.

프로토콜 스택: 말 그대로 여러 계층이 쌓여있는, 계층 구조로 이루어진 프로토콜을 말한다.

4.1) 프로토콜 스택에 메시지 송신을 의뢰하는 방법

IP 주소를 조회했을 때처럼, Socket 라이브러리의 함수를 사용하되, 결정된 순서대로 호출한다.

Socket 라이브러리에서는 프로토콜 스택을 호출한다.
컴퓨터 사이에는 파이프같은 것을 통해 데이터를 양방향으로 주고 받는다.

두 컴퓨터가 연결되는 순서

먼저 서버측에서 소켓(데이터 출입구) 생성
소켓에 클라이언트가 연결 요청을 하도록 대기
클라이언트에서 소켓(데이터 출입구) 생성, 파이프를 늘려 서버 측의 소켓에 연결 요청 → IP 주소와 포트 번호 등을 가지고 connect 함수 호출
양쪽의 소켓이 연결되어 송수신 준비 완료

디스크립터: 소켓을 생성할 때 반환되는 정수 값 → 애플리케이션에서 소켓을 식별하기 위해 사용
IP 주소: 액세스 대상 서버의 ip 주소
포트 번호: IP 주소를 통해 어느 컴퓨터인지 알아냈으면,
- 프로토콜 스택: 말 그대로 여러 계층이 쌓여있는, 계층 구조로 이루어진 프로토콜을 말한다.

[python] 파이썬으로 진법변환하기

sebinChu — Thu, 8 Aug 2024 01:01:40 +0900

개요

간단한 듯하면서도 구현을 할 때마다 까먹는 부분이 생겨서 이번 포스팅을 통해 확실하게 잡아보려고 한다.

1) 파이썬 함수를 통해 진법 변환하기

십진수를 이진수로, 이진수를 십진수로 파이썬 함수를 통해 변환하는 것은 상당히 간단하다.

1-1) 십진수를 이진수로 변환하기

십진수를 이진수로 변환할 때는 bin이라는 함수를 사용한다. 이 함수는 정수를 "0b"가 붙은 이진수로 변환해준다. (문서 참조)

Built-in Functions

The Python interpreter has a number of functions and types built into it that are always available. They are listed here in alphabetical order.,,,, Built-in Functions,,, A, abs(), aiter(), all(), a...

docs.python.org

number = 10
binary_number = bin(number) # 0b1010

1-2) 이진수를 십진수로 변환하기

이진수를 십진수로 변환할 때는 우리가 흔히 쓰는 int 함수를 사용하면 된다.

int 함수에 첫 번째 인자로 들어갈 수 있는 자료형은 문자형임을 주의하자!

binary_number = 1010
number = int(str(binary_number), 2) # 10

2) 알고리즘을 통해 직접 진법 변환하기

2-1) 십진수를 N진수로 변환하기

우리가 보통 이진수를 십진수로 변환할 때 위와 같은 과정을 거친다.

2라는 숫자로 자릿수를 나타낸 것이므로, 각 자릿수에 해당하는 숫자와 진수를 곱하여 이를 모두 더하면 십진수를 구할 수 있다.

def to_decimal(binary_number):
    number = 0
    n = len(binary_number)-1
    for i in range(n, -1, -1):
        number += 2**(n-i) * binary_number[i]
    
    return number

2-3) 십진수를 N진수로 변환하기

어떤 십진수가 있을 때 N진수로 변환하고 싶다면 위와 같은 계산 과정을 거친다. 이를 코드로 표현해주면 다음과 같다.

def to_binary(decimal_number):
    binary_list = []
    while decimal_number != 0:
        binary_list.append(decimal_number%2)
        decimal_number //= 2

    # 연산한 값을 reverse하여 이진수 도출
    re_binary_list = []
    for i in range(len(binary_list)-1, -1, -1):
        re_binary_list.append(binary_list[i])
    
    return re_binary_list

코드트리에서 이 문제를 풀면서 정리해보았다! 앞으로 까먹지 말고 필요할 때 잘 쓰자.

[DevOps] 멀티모듈 프로젝트 CI/CD 적용 - 설계 구상 편

sebinChu — Mon, 22 Jul 2024 20:02:41 +0900

개요

실제 운영 환경 인프라를 구축하기 위해 설계를 팀에 공유해보기로 하였다. 사실 3달 정도 전에 Github Actions + Elastic Beanstalk으로 실습을 해보았으나, 실패했던 경험이 있기에 다시 돌아와서 설계 과정을 세세히 기록해본다.

또한, 이전에는 사용해보고 싶었던 기술(Jenkins)과 추천 받은 기술로 구성하였다면, 이번엔 온전히 내 논리와 지식을 활용하여, 배포를 하자마자 사용자가 생길 우리 서버.. 의 아키텍처를 구상해보려고 한다.

1) 이전 시도 복기와 현재 상황

나에게 가장 까다롭게 다가오는 것은 멀티 모듈 설계와 AWS 사용이다. 이 까다로운 문제를 하나씩 풀어 나가는 과정을 작성해보자..!

1-1) 모듈 구조 파악하기

코어 모듈이 라이브러리 형식으로 하위 프로젝트 2개에 사용되고 있다.

core(공통 라이브러리)
admin(관리자 모듈)
user(사용자 모듈)

1-2) 인턴십에 수행했던 PoC를 떠올려 보자.

멀티 모듈 구조의 CI/CD를 설계 및 구축, 운영한 경험이 있다.
멀티 모듈을 자동으로 빌드 및 배포하기 위해서는 다음과 같은 동작 순서를 따른다.

공통 라이브러리 모듈을 빌드 및 저장소에 push
하위 모듈들이 저장소에 있는 공통 라이브러리를 의존하여 빌드 및 실행

GCP에서는 이 과정을 Cloud Build와 Artifact Registry로 수행이 가능하다. 정확히 말하자면 70% 정도만 가능하다.

그 이유는 Instance Group으로 생성되는 인스턴스들이 Registry의 파일을 가져와 자동으로 배포하려면,
Terraform이나 엔서블 등과 같은 도구를 통해 컨트롤 해야한다.

해당 레포에서 필자가 수행한 PoC를 확인할 수 있다. MVN, NPM, Docker에 대한 자료가 있으니, 참고하길 바란다.

GitHub - cobinding/gcp-docker-ci-cd: [DevOps] Docker와 GCP로 CI/CD 구축

[DevOps] Docker와 GCP로 CI/CD 구축. Contribute to cobinding/gcp-docker-ci-cd development by creating an account on GitHub.

github.com

1-3) 현재 프로젝트는 AWS를 사용

나의 경험을 살려서 멀티 모듈 CI/CD 구조를 어림잡아 생각해보면
① 빌드 자동화 도구 ② 공통 라이브러리 저장소 ③ 배포 자동화 도구 이 세 가지가 필요하다.
이에 상응하는 AWS 기술은 codebuild, s3, code deploy 등이 있다.

2) 멀티모듈 CI/CD를 컨트롤할 github actions 이해

2-1) 기존에 사용했을 때 실패했던 이유

개요에서 밝혔듯, 이 기술을 이미 써본 적이 있지만, 당시에 제대로 구축을 못 했었다. 실패했던 이유는 회사에서 PoC를 진행했을 땐 이미 서버, 인프라 구조가 이미 설계 및 구축되어 있었기에 이에 맞춰서 CI/CD에만 집중할 수 있었다. 그런데 지금 프로젝트에서는 인프라 자체를 스스로 설계 및 구상해야 해서 혼동한 점이 많았다. (멀티 모듈 인프라는 직접 설계 및 구축 해보는 것이 이번 프로젝트에서 처음이었다.. ) 그래서 공통 라이브러리를 의존하는 부분이나 개별 인스턴스에 github actions와 EB를 세팅해야 하는 부분 등을 놓쳤었다.

결론적으로 기술 이해도 부족/약간의 조급함ㅎ이 문제였고 백엔드 팀장님과 날밤까며 계속 시도를 했지만 원인 파악도 제대로 하지 못하고 실패를 했었다.. 다시 돌아간다면 나의 경험을 떠올리면서 이 프로젝트에 적용을 어떻게 할지 침착하게 구상 및 설계했을 것같다..!

2-2) github actions 조건문 분기로 변동사항이 있는 모듈만 빌드하기!

아무튼, 위 사고의 과정을 따라 프로젝트에 적용해야할 사항들을 작성해보자.
멀티 모듈 CI/CD를 위해 요구되는 사항과 해결 방법은 다음과 같다.

1. 한 모듈이 수정되면 해당 모듈만 빌드 및 배포되어야 한다.

한 모듈이 수정될 때 모든 모듈이 같이 빌드 및 배포한다면 아무리 자동화가 되어있다하더라도 비효율적이다. 변동 사항 없이 잘 돌아가고 있는 모듈까지 재빌드 및 재실행하기보다, 변동사항이 생긴 모듈만 빌드 및 배포되도록 설정하자.
github actions는 yaml 파일처럼 동작 과정을 작성할 수 있다.

예시 코드

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
    paths:
      - 'common/**'  # common 모듈에 대한 변경
      - 'admin/**'   # admin 모듈에 대한 변경
      - 'user/**'    # user 모듈에 대한 변경

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up JDK
        uses: actions/setup-java@v2
        with:
          java-version: '11'  # 필요한 Java 버전으로 변경

      - name: Build and test
        run: |
          if [[ $(git diff --name-only HEAD^ HEAD) =~ ^common/ ]]; then
            cd common
            ./gradlew build
            cd ..
          fi
          if [[ $(git diff --name-only HEAD^ HEAD) =~ ^admin/ ]]; then
            cd admin
            ./gradlew build
            cd ..
          fi
          if [[ $(git diff --name-only HEAD^ HEAD) =~ ^user/ ]]; then
            cd user
            ./gradlew build
            cd ..
          fi

      - name: Deploy to Elastic Beanstalk
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: 'your-aws-region'
        run: |
          if [[ $(git diff --name-only HEAD^ HEAD) =~ ^common/ ]]; then
            cd common
            ./gradlew assemble
            zip -r application.zip build/libs/*.jar
            eb init your-app-name --region $AWS_REGION
            eb deploy
            cd ..
          fi
          if [[ $(git diff --name-only HEAD^ HEAD) =~ ^admin/ ]]; then
            cd admin
            ./gradlew assemble
            zip -r application.zip build/libs/*.jar
            eb init your-app-name --region $AWS_REGION
            eb deploy
            cd ..
          fi
          if [[ $(git diff --name-only HEAD^ HEAD) =~ ^user/ ]]; then
            cd user
            ./gradlew assemble
            zip -r application.zip build/libs/*.jar
            eb init your-app-name --region $AWS_REGION
            eb deploy
            cd ..
          fi

2. 하위 모듈들은 각각의 EB를 가지면서 이 공통 라이브러리를 항상 의존해야한다.

이는 EB의 .ebextensions 파일로 컨트롤 한다.

3) 결론 및 정리

3-1) Github Actions

하나의 github actions가 여러 EB를 포인팅하고 있는 구조를 갖는다. 이 구조에서 하위 모듈들이 독립적으로 빌드될 수 있도록 조건분기를 실행파일에 설정한다.
* 여기서는 빌드 과정만 신경 쓴다!

이벤트 기반 트리거
- 특정 이벤트(나의 경우 merge)에 반응하여 자동으로 워크플로우를 실행한다.
- on 키워드를 사용하여 어떤 이벤트가 발생할 때 워크플로우가 실행될지를 정의한다. ➡️ 설계에서 정의
워크플로우 정의:
- YAML 형식으로 워크플로우를 정의합니다. 각 워크플로우는 여러 개의 작업(Job)으로 구성될 수 있다.
- 각 작업은 특정 환경에서 실행되며, 다양한 명령어와 스크립트를 실행할 수 있다.
작업 및 단계:
- 각 작업은 여러 단계를 포함 (예를 들어 코드 체크아웃, 의존성 설치, 테스트 실행, 빌드 생성 등)을 포함할 수 있다.
  - 하위 모듈들은 저장소에 저장된 ~~공통 라이브러리의 의존성을 설치하고~~ 빌드를 생성한다.
  - 하위 모듈들은 이 과정을 통해 각각의 모듈을 자신의 변경사항이 바뀌었을 때만 빌드하는 것에 집중한다.
  - 하위 모듈이 공통 라이브러리를 의존하는 것은 EB의 .ebextensions에서 진행한다.

3-2) Elastic Beanstalk

배포 패키지
- Elastic Beanstalk에 배포할 애플리케이션은 ZIP 파일 형식의 배포 패키지로 준비되어야 한다.
- EB 배포를 커스텀하기 위해 .ebextensions/ 에 옵션을 작성한다.
  - ebextenstions: EB를 실행할 때 최초로 실행되는 파일
  - 하위 모듈은 저장소에 저장된 공통 라이브러리 의존
  - 공통 모듈은 빌드된 파일을 저장소에 push

다음 편에서는 직접 설계한 것과 설정 파일들을 다뤄보겠다. 쉽지 않은 길이 예상된다... 그래도 아자아자

[백준/1547] 공 | 두 수의 전환

sebinChu — Fri, 5 Jul 2024 01:03:14 +0900

공

알고리즘

알고리즘을 공부해본 사람이라면 한 번쯤은 겪었을 법한 두 수의 전환을 이용한다.

이 문제에서 주의해야 할 점은 공의 번호와 인덱스를 달리 생각해야 한다는 것이다. 예를 들어, 1번 공과 3번 공의 위치를 바꿀 때 배열의 인덱스는 그대로고 1번 공과 3번 공의 위치만 즉, 인덱스 번호 바뀌는 것이다.

ㅡ

그래서 인덱스로만 다룰 순 없고 for문으로 공의 번호가 저장된 배열을 돌면서 입력으로 주어지는 x,y의 위치를 찾아야 한다.

for _ in range(m):
    x,y=map(int,input().split())

    # x 위치 먼저 찾기
    for i in range(len(arr)):
        if arr[i]==x:
            # x가 있는 위치의 값을 tmp_x 변수에 저장해 둠.
            tmp_x=arr[i]
        
            # 이후 y의 위치 찾기
            for j in range(len(arr)):
                # x,y가 있는 위치의 값을 서로 reverse. 이때, tmp_x 변수에 저장해둔 값 사용
                if arr[j]==y:
                    arr[i]=arr[j]
                    arr[j]=tmp_x
                    flag=True
                    break
                    
            # x,y의 위치 찾기가 끝났다면 루프를 종료
            if flag:break

입력으로 주어진 x,y 즉 서로 바뀌어야 하는 값의 위치를 먼저 찾는다.
위의 그림으로 나타낸 두 수의 전환 알고리즘을 적용하여 값을 서로 바꿔준다.
값 변경이 완료되면 반복문을 종료한다. 이때 flag를 사용해서 바깥 반복문도 종료해준다.

전체코드

import sys;input=sys.stdin.readline

m=int(input())
arr=[0,1,2,3]
tmp_x=0
flag=False

for _ in range(m):
    x,y=map(int,input().split())

    # x 위치 먼저 찾기
    for i in range(len(arr)):
        if arr[i]==x:
            # x가 있는 위치의 값을 tmp_x 변수에 저장해 둠.
            tmp_x=arr[i]
        
            # 이후 y의 위치 찾기
            for j in range(len(arr)):
                # x,y가 있는 위치의 값을 서로 reverse. 이때, tmp_x 변수에 저장해둔 값 사용
                if arr[j]==y:
                    arr[i]=arr[j]
                    arr[j]=tmp_x
                    flag=True
                    break
                    
            # x,y의 위치 찾기가 끝났다면 루프를 종료
            if flag:break
    
print(arr[1])

알게된 점

어려운 문제는 아닌데 예상보다 시간이 걸렸다. 이유는 문제를 풀면서 "어 이 간단한게 왜 안되지?"라는 생각에 사로잡혔기 때문. 즉시 객관화를 하고 천천히 시도해서 다행히 잘 풀었다

이 문제를 풀면서 느낀/앞으로도 유지해야 할 좋은 태도!

1. 큰 문제를 작은 문제 단위로 나누어서 생각

예를 들어, 이 문제에서 두수의 전환이라는 큰 흐름은 잘 잡았었다. 그런데 미세한 부분(값의 위치를 찾는다, 변경은 ~지점에서 한다.) 이런 걸 놓쳤다. 하나씩 1,2,3... #1, #2, #3... 이런식으로 작은 단위로 나누고 차차 풀어나가는 태도를 갖자.

2. 내가 생각한 게 코드로 이어지지 않을 수 있다는 객관화

3. 너무 과몰입하면 산으로 가니까 문제를 풀다가도 한 템포 떨어져서 보기

[Network] 내가 만든 웹 서비스 WireShark로 패킷 분석하기 - 7계층 분석

sebinChu — Sun, 23 Jun 2024 17:25:23 +0900

개요

내가 만든 웹 서비스 WireShark로 패킷 분석하기 1편에 이어서, 2편에서는 본격적인 WireShark 패킷 내용을 살펴보자.

현재 서버는 로컬 컴퓨터에서 spring boot를 IntelliJ로 실행하고, 포트포워딩하여 15001 포트로 클라이언트가 접속할 수 있도록 세팅되어있다.
서버 위주의 패킷을 분석하고, 특정 상황에서는 서버와 클라이언트 양측의 패킷을 각각 분석한다.

유저 시나리오는 다음과 같다.

클라이언트의 접속(채팅방 이용자)
유저 1의 채팅방 만들기
유저 2의 채팅방 접속(다대다 채팅 가능)
서로 채팅하기
방 나가기
이메일 전송하기
클라이언트 브라우저 접속 종료

S1# 클라이언트(채팅방 이용자)의 메인 화면 접속

[서버 측 패킷]

두 클라이언트(51115, 51116)의 요청과 서버의 응답에 대한 패킷 전송과정을 확인할 수 있다. 가장 처음 요청을 한 클라이언트 1의 TCP 연결 요청은 서버측의 [SYN, ACK]를 받지 못해, 서버 측에서 지속적으로 TCP Retransmission을 실행하는 것을 확인할 수 있다.

TCP Retransmission

TCP는 RDT 통신을 한다.

RDT(Reliable Data Transfer)란? 불안정한 네트워크 환경에서도 안정적으로 데이터를 전송하는 기술로, 신뢰성 있는 데이터 전송을 의미한다. UDP와 뚜렷하게 비교되는 TCP 특징 중 하나다.

TCP는 RDT 통신을 위해서 Retransmission 매커니즘을 사용한다.

TCP는 데이터 수신이 잘 되었는지 확인하기 위한 ACK라는 일종의 flag를 사용한다. 통신을 하는 과정에서 ACK 패킷을 받지 못하면 일정 시간 내에 해당 패킷을 다시 전송한다. 불확실한 네트워크 상황에서 데이터 손실을 방지하기 위한 RDT 통신 기술이다!
이러한 Retransmission과 관련하여 timer, Dupicate ACK 등을 알아야 하지만, TCP 관련 포스팅에서 상세하게 다루도록 한다. 패킷 분석에서 서버 측의 SYN, ACK를 받지 못해 Retransmission을 지속적으로 실행하는 것을 확인하는 것이 핵심이다.

RST(Reset) 패킷

연결을 즉시 종료하기 위한 패킷이다. 비정상적이거나 예기치 않은 상황에서 연결을 재설정하거나 아예 끊기 위한 기술이다.

위 패킷 캡처내용에서 클라이언트 1(51115)의 연결 요청에 대해 Retransmission을 하다가, 제대로 연결이 되지 않자 RST로 끊고 511129라는 클라이언트로 재연결을 하는 것을 확인할 수 있다.

TCP 3way-handshaking과 HTTP Request/Response

한 번에 연결이 잘 된 클라이언트 2(51116)의 경우, 3 Way handshaking이 잘 되었고 TCP 연결 이후 HTTP 응답﹒요청을 주고 받는 걸 패킷 캡처를 통해 확인하였다.

GET /HTTP/1.1 살펴보기

[APPLICATION Layer] 해당 패킷은 HTTP의 버전 1.1을 사용함을 알 수 있다.
[TRANSPORT Layer] TCP 프로토콜을 사용하며 src/dst port는 각각 (51116, 8080)이다.
[NETWORK/LINK Layer] 상세 내역을 보면 IPv4 버전을 이용하고, L2 계층에서는 Ethenet을 사용하며 src/dst MAC 주소를 각각(04:09:…, 64:79:…) 확인할 수 있다. IP Fragmentation은 사용되지 않았다. (flag를 통해 확인)

HTTP/1.1 304란?

해당 패킷에서 눈 여겨볼 점은 바로 아래에서 두 번째의 HTTP 상태코드 304 번이다.(No. 20052 패킷) 이는 요청된 자원에 대한 리디렉션, ‘Not Modified’를 뜻합니다. 요청 값에 대해 변경된 사항이 없으므로 캐시되어있는 자원을 이용하겠다는 뜻이다.

실제로 패킷을 캡처하기 전에 팀원들과 테스트를 진행했었다. 이 내용들이 WireShark에 반영되는 것이 신기했다. 만약 이 캐시를 지우려면 서버를 재시작 하거나, chrome 쿠키 삭제 기능을 활용할 수 있다.

[HTTP 304 패킷 상세 내용]

S2# 채팅방 만들기

[서버 측 패킷]

채팅방을 생성할 때 GET, POST 요청을 진행하고 endpoint를 반환받는 모습을 확인할 수 있다. 실제로 서버 측 코드로 구현한 것과 같이 요청이 주고 받는 모습이 캡처되었다.

같은 /chat/create 경로로 GET, POST 요청이 진행된다.

GET: view 표시
POST: view redirect 및 chatRoom DB 저장

S3# 채팅방 접속 및 웹소켓 연결(STOMP)

[클라이언트 측 패킷]

위 패킷 중 이 세가지 부분이 WebSocket(STOMP) 통신의 연결 시작 부분이다. 웹소켓은 처음 연결 방법에서 HTTP를 사용한다.(1편에 잘 나와있음) 하나씩 살펴보자.

HTTP/1.1 304란?

[패킷 상세 내용]

Upgrade-Insecure-Requests: HTTP 요청을 자동으로 HTTPS로 리다이렉트
Accept-Encoding: 콘텐츠 인코딩 방식은 gzip, deflate 압축을 지원한다는 뜻이다. 이러한 방식은 데이터 전송량을 줄여서 네트워크 효율을 높이는 방식이다. 실제로 서버 프로그래밍을 할 때도 대용량 데이터를 통신할 때는 JSON 데이터를 gzip으로 주고 받은 경험이 있어서 이를 직접 확인 해보는 것이 흥미로웠다.
Accept-Language: 클라이언트가 선호하는 언어는 “ko” 즉, 한국어다.

이러한 헤더 정보를 통해 서버는 클라이언트에게 적합한 응답을 전송하고, 소통한다.

WebSocket 연결 설정 및 HTTP 101

HTTP 101는 클라이언트가 서버에게 프로토콜 전환을 요청했으며, 서버는 이를 승인한다는 상태 코드다. 이 패킷을 살펴보면 요청 헤더 부분에 WebSocket과 관련한 stomp 프로토콜 정보가 있음을 확인할 수 있다.

[패킷 상세 내용]

서버 구현부에서 사용한 @EnableWebScoketMessageBroker 애노테이션은 내장된 STOMP 메시징 브로커를 활성화한다. 이렇게 적용된 통신 방식이 WireShark에서도 반영되는 것을 확인할 수 있었다.

또한, 패킷을 통해 구현 내부 상세를 알 수 있었다. 바로 WebSocket 연결 확장 기능이다. 위 패킷 상세 내용을 살펴보면,

permessage-deflate는 WebSocket 메시지 데이터를 압축하여 전송할 수 있게 하여, 네트워크 대역폭을 효율적으로 사용할 수 있도록 한다.
client_max_window_bits=15 라는 필드로 최대 압축창 크기를 지정한다.

[WebSocket 패킷 상세 내용]

FIN: 채팅의 마지막 부분이다
MASK: WebSocket 프로토콜은 보안상의 이유로, 클라이언트에서 보내는 모든 데이터 프레임에 마스킹을 적용하도록 규정하고 있다.
- 중간자 공격(Man-in-the-Middle Attack) 방지
- 4byte 길이의 임의의 값으로, 데이터프레임에 XOR 연산을 적용

[추가 Layer 분석 내용]

해당 부분 또한 각 계층에서 사용되는 정보는 위 상황과 비슷했다.

L2 계층에서는 Ethernet II를 사용하고 있으며, src/dst MAC 정보는 ac:49:db:dd:f1:ae와 88:3c:1c:ed:0b:40이다.
Network Layer 프로토콜은 Ip이며 IPv4 버전을 사용한다.
클라이언트와 서버의 주소가 src/dst 주소인 192.168.219.105, 58.123.180.186으로 나타난다.
IP Fragmentation은 사용되지 않으며 Offset 역시 0이다.
전송 계층의 프로토콜은 TCP이다.
Checksum이 올바르게 되어 [correct] [Good] 등의 표시를 확인할 수 있으며, 문제 없이 통신이 진행되었다.

S3# 채팅하기

WebSocket 연결이 생성된 이후부터는 TCP 통신을 통해 안정적으로 채팅이 오가는 것을 확인할 수 있다.

S5# 이메일 전송하기

해당 API는 Google의 SMTP를 활용한 spring boot로 구현하였다. 따라서 구현한 사람의 gmail 계정과 앱 비밀번호를 사용하였기에, 보낸 사람(나)이 위와 같이 등록되어있다.

[클라이언트 측 패킷]

메일 전송을 위해서 클라이언트가 서버로 POST 요청을 보내는 것이 확인된다. ➡️ 간단하게 이메일 주소만 입력하면 해당 이메일로 소개메일을 보내는 것을 구현했기에, 브라우저에 입력된 이메일 주소를 POST로 서버로 전송하도록 구현하였다.

POST 요청 패킷을 확인해보면, 이메일 전송 값이 인코딩을 통해 헤더에 담긴 모습을 확인할 수 있다.

TCP ACKed unseen segment

이는 패킷이 정상적으로 송수신되었지만 WireShark 상에서 패킷을 찾을 수 없는 경우에 발생한다.

패킷을 자세히 살펴 보면 ACK에 대한 누락임을 알 수 있고, 경고창을 함께 보여준다.

[서버 측 패킷]

패킷을 통해 해당 API의 동작 과정을 알 수 있다.

서버측에서는 메일 전송 POST 요청을 받고 SMTP 프로토콜을 사용하여 자신의 이름을 알린다. (No.2038 패킷)
서버는 클라이언트에게 SMTP 기능을 지원하는 것을 알린다. (No.2047 패킷)
이후, 서버와 클라이언트는 보안 연결을 설정하고, google 서버가 메일을 전송한다.

[EHLO 상세 패킷]

SMTP 전송 프로토콜은 TCP를 이용하므로, 첫 번째 단계에서 클라이언트와 서버 간 연결을 시작한다.
이때, 클라이언트는 특화된 Hello 명령인 HELP or EHLO를 사용한다. 위 패킷에서는 EHLO를 사용했다.

이후 메일 서버와 요청 서버(웹 애플리케이션이 돌아가고 있는 곳)가 TLS 통신을 진행한다.
HTTPS/TLS 관련 패킷 분석은 과제 1 제출물을 통해 확인할 수 있습니다.

후기

HTTP에 관해...

서버 API를 짤 때, 항상 고민되었던 것이 어떤 HTTP method를 사용할 것인가?였습니다.

각 HTTP 요청/응답 메시지를 세부적으로 살펴보면서, 클라이언트와 서버 간의 통신 과정을 실제로 확인할 수 있었습니다. HTTP 메서드, 헤더, 페이로드 등 네트워크 통신의 핵심 요소들이 어떻게 동작하는지 깊이 있게 이해할 수 있었고, HTTP에 한층 가까워졌습니다.

평소에 Serialization과 관련하여 공부해야겠다 생각을 자주 했었는데, 이번 기회를 통해 HTTP 헤더를 직접적으로 분석할 수 있어, 통신에 대한 이해가 깊어짐을 체감했습니다.

네트워크 지식

Wireshark 분석을 통해 네트워크 계층부터 애플리케이션 계층까지 전체적인 통신 과정을 확인할 수 있었습니다. 직접 패킷 분석을 하면서 TCP/IP 스택의 동작 원리, 패킷 구조, 흐름 제어 등 네트워크 기술에 대한 이해도를 크게 향상할 수 있었습니다.

[Network] 내가 만든 웹 서비스 WireShark로 패킷 분석하기 - Spring WebSocket & STOMP

sebinChu — Sun, 23 Jun 2024 02:21:41 +0900

1편 - 소켓 통신 프로젝트 기능 구현 소개

2편 - 패킷 분석 내용 소개

개요

WireShark 패킷 분석을 위한 애플리케이션인 만큼, 소켓 통신을 구현하여 서버와 클라이언트, 클라이언트끼리의 통신이 잘 보이는 채팅 서비스를 구현하였다.

소켓 통신은 KAU 멋쟁이 사자처럼 고기의 소켓통신 세션을 참고하였고, SMTP 프로토콜 통신을 캡처하기 위해 이메일 전송을 추가하였다.소스코드는 해당 깃허브에서 확인 가능하다.

기능 구현은 크게 다음과 같다.

WebSocket 통신
구글 SMTP 서버를 통한 메일 발송

WebSocket 통신 구현에 사용된 기술

크게 3가지로 분류된다.

- WebSocket(HTTP와 비교)

- STOMP

- Message Broker

WebSocket이란? HTTP와 다른 점은 뭘까?

HTTP는 클라이언트가 서버에 요청을 보내고, 서버가 응답을 하는 요청-응답 방식의 프로토콜이다. 이 프로토콜은 connectionless라는 특징을 통해 자원 낭비를 방지하고 효율적인 통신을 한다. 하지만 이러한 비연결성이 오히려 자원의 손실을 야기하는 경우도 있다. 바로 채팅, 주식, 게임 등 실시간 성이 반영되어야 하는 경우다

Application Layer에서 HTTP 프로토콜을 사용하면 실시간 통신에 어려움이 있다.

단방향 통신으로 서버가 먼저 클라이언트에게 요청을 할 수 없다.
요청 없이는 응답을 할 수 없다. 즉, 양방향 실시간 통신이 불가능하다.

HTTP로 실시간 통신이 아예 불가능한 것은 아니다.

HTTP/2부터는 Stream이라는 기능으로 서버와 클라이언트가 동시에 데이터를 주고 받는 실시간 양방향 통신이 가능하다.
HTTP Long Polling 방식을 사용하면, 클라이언트가 서버에 대해 지속적으로 연결을 유지한다.

하지만 이와 같은 극복점이 있다고 하더라도 HTTP는 주로 요청-응답 패턴에 맞추어 설계되어 있다. 따라서 이 프로토콜을 사용할 경우 오버헤드나 요청 헤더가 과도하게 주고받아지는 단점이 있다.

WebSocket도 초기에는 HTTP로 HandShaking한다.

반면, Web Socket은 실시간 양방향 데이터 교환을 위한 프로토콜로, HTTP의 비연결성에서 벗어나 연결 상태를 유지함으로써 데이터를 교환한다.

실제로 패킷 분석 내용의 일부를 보면 , 요청 헤더를 통해 WebSocket으로 업그레이드하는 것을 확인할 수 있다.

[WebSocket 요청 패킷 일부 발췌]

STOMP(Simple Text Oriented Messaging) 프로토콜

STOMP는 사람이 읽고 쓰기 쉬운 형태의 텍스트 기반 프로토콜로, 메시지를 전송하고 수신하기 위한 프로토콜이다.

STOMP 메시지는 프레임 단위로 구성되며, 프레임은 헤더와 바디로 이루어져 있다.
- 프레임은 크게 CONNECT, SEND, SUBSCRIBE, UNSUBSCRIBE 유형으로 나뉜다.
동작과정은 연결(CONNECT)- 구독(SUBSCRIBE) - 메시지 발행(SEND) - 전달(MESSAGE) - 구독 취소(UNSUBSCRIBE) - 연결 종료다.

WebSocket과 함께 사용하여 메시지의 전송, 구독, 취소 등의 작업을 구조화된 방식으로 처리할 수 있다.

만약 이 프로토콜을 정의 및 사용하지 않으면 어떤 형식으로 어떤 데이터를 교환할 것인지 모두 구현해야 하는 번거로움이 생긴다.

해당 프로젝트에서는 JavaScript의 STOMP 클라이언트 즉, @stomp/stompjs 라이브러리를 사용하였다.

const stompClient = new StompJs.Client({
    brokerURL: 'ws://localhost:8080/endpoint'
});

stompClient.activate();

위 코드처럼 StompJs.Client 객체를 생성하고, brokerURL로 WebSocket 서버의 주소를 생성한 뒤, STOMP 클라이언트를 활성화하면 WebSocket 서버와의 연결을 시작한다.

function publish() {
    const destination = "/pub/chat/" + roomId;
    const text = document.getElementById("text").value;
    document.getElementById("text").value = "";

    const message = {
        senderName: myName,
        text: text,
        createdTime: new Date()
    };

    stompClient.publish({
        destination: destination,
        body: JSON.stringify(message)
    });
}

메시지 발행을 위해 stompClient.publish 메서드를 사용하여 메시지 형식을 지정하고, JSON 형식으로 변환하여 발행한다.

이후, showChat 함수를 통해 수신된 메시지를 HTML 요쇼로 생성하여 채팅 로그에 표시한다.

Message Broker

WebSocket 메시지 브로커를 구성하기 위해 Java Spring의 @EnableWebSocketMessageBroker 애너테이션과 WebSocket 인터페이스를 사용하였다.

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        // 구독 경로 설정: 클라이언트로부터 서버로 메시지를 전달
        registry.enableSimpleBroker("/sub");
        // 발행 경로 설정: 서버로부터 클라이언트로 메시지를 전달
        registry.setApplicationDestinationPrefixes("/pub");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        // WebSocket 엔드포인트 설정
        registry.addEndpoint("/endpoint");
    }
}

Spring WebSocket 설정을 통해 엔드포인트('/endpoint')를 등록하고, pub/sub 경로를 메시지 브로커가 처리하도록 한다. 클라이언트 측은 JS로 STOMP 클라이언트를 사용하여 WebSocket 연결을 설정하고, 해당 경로로 메시지를 발행 및 구독한다.

이러한 방식으로 클라이언트와 서버는 WebSocket을 통해 연결되며, 클라이언트는 STOMP 프로토콜을 사용하여 메시지 브로커와 통신한다. 클라이언트는 메시지를 발행하여 서버로 전송하고, 서버는 메시지 브로커를 통해 해당 경로를 구독하고 있는 다른 클라이언트에게 메시지를 전달한다.

이 정도가 가장 핵심적인 내용이고, 이메일 전송 구현은 해당 프로젝트의 핵심 기능이 아니기에 설명을 보태지 않았다.

2편에서 구현된 내용을 WireShark로 캡처하고, 패킷을 분석한 내용에 대해 소개하도록 한다.

[AWS] Cloud Watch Agent 설정하기 | Configuration validation second phase failed 해결

sebinChu — Mon, 3 Jun 2024 15:30:35 +0900

개요

진행하는 프로젝트의 로그 작업을 위해 CloudWatch를 설정하였다.

CloudWatch를 통해 로깅하기 위해서는 로그를 측정할 Agent를 따로 설치해야 한다.

해당 문서에서는 IAM 관련 설정은 생략한다.

CloudWatch Agent 다운로드

해당 문서에서 서버 OS에 맞는 명령어를 찾아, 설치한다.

필자는 ubuntu 서버를 사용 중이므로, 다음과 같은 과정을 통해 설치하였다.

1. EC2에 agent 다운로드

wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

2. 패키지 설치

sudo dpkg -i -E ./amazon-cloudwatch-agent.deb

Agent config 설정

해당 경로에 있는 wizard를 통해 Agent의 config를 설정한다. (이 과정이 생각보다 길다. 당황하지 말고 설정하자. )

Agent wizard 실행

cd /opt/aws/amazon-cloudwatch-agent/bin/
sudo ./amazon-cloudwatch-agent-config-wizard

root@ip-10-0-1-29:~# sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
================================================================
= Welcome to the Amazon CloudWatch Agent Configuration Manager =
=                                                              =
= CloudWatch Agent allows you to collect metrics and logs from =
= your host and send them to CloudWatch. Additional CloudWatch =
= charges may apply.                                           =
================================================================
On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [1]:

Trying to fetch the default region based on ec2 metadata...
I! imds retry client will retry 1 timesAre you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:

......

이런식으로 하나하나 설정하게 된다.

이 세부내용에 관해서는 BigCo 님의 블로그에 잘 나와있다. 필자의 경우 default 값을 위주로 설정해주었다.

Agent 실행

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

wizard를 통해 설정을 하고, Agent를 실행하면 CloudWatch Agent 구성과 시작 내용을 보여준다.

그런데 이 과정에서 쭉쭉 잘 되다가, Configuration validation second phase failed 에러가 발생했다.

sudo apt-get install collectd

에러 메시지 내용처럼 /usr/share/collected/types.db 가 없다는 것인데, collectd라는 것을 통해 해결할 수 있다.( algorijun 님의 블로그에서 본 해결책)

다행히 실행이 잘 되었다.

지표 확인

이런식으로 지표가 잘 생성된 것을 확인할 수 있다.

Agent 관련 명령어

# ps로 동작 중인 agent 확인
ps aux | grep amazon-cloudwatch-agent

# 정지
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop

# 시작
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a start

[AWS] AWS 하나의 LB로 여러 서비스 운영하기

sebinChu — Wed, 22 May 2024 11:08:15 +0900

개요

지난 포스팅에서 하나의 로드밸런서로 여러 서브도메인, 서비스를 운영하는 것을 GCP를 통해 구축해보았다. (GCP를 사용하지 않더라도 앞의 글을 읽는 것을 추천한다.)

[DevOps] 하나의 LB로 여러 서비스 운영하기

개요로드 밸런서는 운영관리 입장에서 상당히 많은 편의성을 제공한다.그래서 그런지 규모가 작은 프로젝트 즉, "부하 분산"이 필요없는 프로젝트임에도 불구하고 정말 많은 사람들이 로드 밸

cobinding.tistory.com

이번에는 AWS의 로드밸런서와 라우팅 설정을 통해서 하나의 LB로 서브도메인을 구분하는 것을 세팅해보도록 한다.

AWS로 구축할 웹사이트는 user와 admin이 구별되어있다.

user-main.example.com
admin-main.example.com

이 두 가지 서브도메인을 하나의 LB에 설정해보도록 하자.

ALB 설정

먼저 Application 로드밸런서를 만들어준다.

기본적으로 전달하고자 하는 대상그룹으로 리스너를 설정해준다.

두 가지 서브도메인 user, admin 중 admin을 기본 서버로 설정하여, 처음 LB를 만들면 admin에 대한 작업과 규칙이 정의되어 있다.

리스너와 대상규칙

리스너(Listner)

클라이언트로부터 트래픽을 수신하기 위해 설정하는 프로토콜 및 포트다. Application LB을 통해 웹 서비스를 운영하기 때문에 HTTP와 80 포트를 기본적으로 설정한다. 추가적으로 HTTPS 요청을 받기 위해 HTTPS와 443 포트를 설정해준다.

기본적으로 AWS의 ALB에서는 다음과 같은 프토토콜, 포트를 지원한다.

프로토콜: HTTP, HTTPS
포트: 1-65535

대상규칙(Target Group)

대상규칙은 리스너를 통해 들어온 트래픽을 EC2 인스턴스와 같은 대상으로 라우팅하는 것이다.

➡️ 이 두 가지 개념을 활용해서 하나의 LB로 여러 서브 도메인을 운영할 수 있게 된다.

리스너 규칙에 서브 도메인 추가

위 이미지에서 보이는 HTTP:80 리스너에 규칙을 추가해준다.

리스너 규칙은 다양한 조건을 추가할 수 있는데, 서브 도메인을 활용하여 트래픽을 분산할 것이므로 호스트 헤더를 정의한다.

이때, 추가하는 규칙은 user에 대한 것이다! 앞서 admin을 default로 가져가기로 정의했기 때문이다. 만약 여러 서브도메인을 설정하고자 한다면 default 서브 도메인을 하나 정하고 이 과정을 각각의 서브 도메인에 반복 설정하면 된다.

추가할 라우팅 조건인 user 서브도메인 작성하기

규칙에 대한 작업 정의

마지막으로 위에서 추가한 규칙에 어떤 작업을 부여할 것인지 정의한다.

추가된 화면 확인

이렇게 리스너 규칙에 기본값으로는 admin, 추가된 조건으로는 HTTP 호스트 헤더가 user-main.example.com 인 대상을 user-tg가 있음을 확인할 수 있다.

➡️ 리스너에 HTTP:80 뿐만 아니라 HTTPS:443을 만들어주었기에 HTTPS도 이 과정을 똑같이 진행해준다!

Route 53 서브 도메인 설정 및 로드 밸런서 연결하기

이렇게 설정된 로드 밸런서를 각각의 도메인과 연결해준다. 이는 AWS의 Route53을 통해 진행한다.

이 과정은 가비아에서 도메인을 구매와 기본 설정이 되어있는 상태에서 진행할 수 있다.

참고로 로드밸런서와 서브도메인의 연결은 레코드 생성의 별칭 - 대상으로 할 수 있다.

결과 확인

이후 서브도메인으로 각각의 서비스에 접근해보면 하나의 LB를 통해 접근이 가능한 것을 확인할 수 있다!!

route53에 정의한 후 시간이 걸리니 잘 안되는 경우엔 좀 더 기다려보자..!

회사에서 세운 가설을 증명하고, 이를 프로젝트에 활용한 좋은 경험이었다. 또한 AWS, GCP를 모두 비교하면서 사용할 수 있어서 좋았다.

[GCP] GCP 하나의 LB로 여러 서비스 운영하기

sebinChu — Mon, 13 May 2024 11:53:08 +0900

개요

로드 밸런서는 운영관리 입장에서 상당히 많은 편의성을 제공한다.

그래서 그런지 규모가 작은 프로젝트 즉, "부하 분산"이 필요없는 프로젝트임에도 불구하고 정말 많은 사람들이 로드 밸런서를 활용한다.

그런데 나의 경우, 작은 프로젝트에 LB를 쓰는게 그 기술의 취지에 맞지 않고, 그렇기에 많은 자원이 낭비가 된다는 생각에 쓰기가 싫었다. (뭔가 괜히 패배하는 기분이랄까..?)

여기서부터 도르마무 시작이었다!

이게 그 당시의 나를 설명하는 짤....

하나의 서버에 여러 포트를 두고, 이 각각의 포트에 SSL을 적용하는 테스크를 진행했는데, 사실 이건 로드 밸런서로 뚝딱뚝딱 1-2시간이면 할 수 있는 업무다.

그런데 위와 같은 이유로 로드밸런서를 사용하기 싫었고, 일일이 포트별 SSL 설치라는 수작업을 하기로 했다. ➡️ 심지어 이 수작업을 하는 기술들을 한국에서도 많이 사용하고 있었고(certbot) 의심없이 시작을 했지만, 결국 해내지 못했다!

그래서 패배를 인정하고 로드밸런서를 각각 서버마다 만들어서 쓰게되었다.

그렇게 서버를 운영하던 중... 운 좋게 회사에서 비슷한 솔루션(?)과 같은 업무가 주어져서 이 삽질에 대해 다시 생각해볼 기회가 생겼다.

솔루션은 로드밸런서 하나로 여러 서버를 운영해보는 것이었다. 처음엔 이 아키텍처가 위와 같은 이유로 이해가 안됐다.

로드 밸런서는 부하를 분산하는 것인데, 다른 여러 서비스(멀티 모듈)로 분산을 설정 해버리면 어떢함??? 기술에 맞지 않아! 이런 생각이 나를 지배했다.

그런데 이 아키텍처 설계의 의도를 생각해보면, 그냥 있는 기술을 나의 상황에 맞게 잘 설계한 것이다.

시중에 나온 기술을 어떻게 응용할 수 있냐에 따라 구축할 수 있는 건 무한했고, 기술을 잘 사용하기 위해서는 유연성과 응용력이 정말 필요한 소양이라는 깨달음을 얻었다. 정석대로 하는 것이 반드시 좋은 결과로 도출되는 건 아니다! 나의 꼼꼼함에 유연성을 첨가하자...

설계

여러 서브 도메인을 하나의 로드 밸런서 라우팅을 통해 이용한다. (로드밸런서가 주는 설정 편의가 크니까)
주의할 점
- 트래픽이 급격하게 많이 몰리면 당연히 이런 구조는 당연히 장애가 발생한다. (부하 분산을 하나의 서비스에 대해 하는 것이 아니니까) 따라서 테스트 서버 등과 같이 비용 절감이 필요하되, 로드 밸런서의 편의성이 필요한 곳에만 한정하여 사용한다.

크게 구조는 다음과 같다.

사용할 로드밸런서 생성

위 아키텍처처럼, default 서버를 제외하고는 라우팅을 해서 사용할 거기에 로드 밸런서 하나를 설정해준다.

서브 도메인 지정

사용하는 도메인 서비스에 A 레코드로 각각의 테스트 서버 A, B, C 서브 도메인을 생성한다. 이때, 각각에 로드밸런서 외부 IP를 등록해준다.

로드밸런서 설정

필자는 GCP 서비스로 이 테스크를 진행했다. (사이드 프로젝트는 AWS로 사용하고 있어서 주요 API 개발이 끝나면 AWS 클라우드에서도 POC를 해볼 예정이다. POC가 완성되면 과정을 추가하겠다. )

필요한 것들을 설정해준다.

ssl 인증서를 로드밸런서 없이 여러 서버에 한번에 적용해보면, 로드밸런서가 정말 편한 서비스임을 알 수 있다......

사용할 백엔드 버킷은 총 3개이므로, 3 개를 모두 추가한다. 이후 라우팅 규칙에서 이를 구분한다.

아래 호스트 및 경로 규칙 추가를 누르고, 라우팅할 각각의 서브 도메인과 서버를 연결해준다.

결과 확인

각각의 서브 도메인으로 접속이 잘 되는 것을 확인하였다.

개인적으로 어떤 가설을 세워서 검증하는 과정 자체가 재밌었고, 깨달음이 많은 작업이었다.

[BackEnd] API의 멱등성을 고려하여 개발하기

sebinChu — Fri, 26 Apr 2024 15:40:09 +0900

개요

신규로 도입한 어드민 기능에 문제가 발생했다. 아래 두 가지가 부족했기 때문이었다.

API의 멱등성
사용자 관점에서의 테스트

이 포스팅에서는 API의 멱등성에 대해 상세히 다루고, 앞으로 의식하여 적용할 수 있도록 해볼 것이다!

멱등성(Idempotency)

멱등성은 수학 용어로, 여러 번 연산을 적용해도 결과는 달라지지 않는 성질을 말한다.

한자도 덮을 멱, 무리 등인데 무리(swarm)의 효과를 덮어버린다! 라는 뜻이다.

멱등성의 대표적 예다.

절댓값 함수
1을 계속 곱하는 것

HTTP의 멱등성

기본적으로 HTTP 메소드의 GET, PUT, DELETE 와 같은 메서드는 멱등하다.

예를 들어, 여러 번 호출해도 GET 은 항상 같은 결과를 보여준다.
PUT 또한 여러 번의 요청에도, 매번 같은 리소스로 업데이트 한다.

반면, 서버의 데이터를 변경하는 POST, PATCH 와 같은 메서드는 호출을 할 때 마다 요청 데이터, 응답이 달라지기 때문에 멱등하지 않다. 이 HTTP Method의 API는 멱등성 보장을 위한 추가적 구현이 요구된다.

나의 경우 POST API였고, 멱등성을 보장하는 로직이 없어서 요청 시마다 값이 달라졌다. 결과적으로요구사항에 정확하게 맞지 않는 기능이 개발되었다.

API 멱등성 보장 방법

1) 멱등키 헤더

멱등키를 API 요청 헤더에 포함한다.

서버는 이 멱등키를 통해 같은 키가 2번 이상 요청되면 중복으로 판단한 뒤, 실제로 처리하지 않는 방식으로 동작한다.

IETF에서 표준으로 제안하는 요청 헤더의 멱등키 는 다음과 같다.

Idempotency-Key: {IDEMPOTENCY_KEY}

결제 취소 API의 멱등성을 구현한 토스 페이먼츠 예시 에서는 결제 취소와 같은 API에 이 멱등성을 제공한다.

toss payments에서 결제 서비스에 적용한 예시

결제취소는 POST 요청으로 진행되며, 취소 요청마다 헤더에 멱등키를 담아준다.

API 서버는 취소 요청마다 헤더에 멱등키가 있는지 확인한다. (이 확인을 통해 키의 중복을 판별하고, 멱등함을 구현하기 위해서다.)
멱등키 저장을 위한 DB가 있다. 만약 요청1의 헤더에서 DB에 저장된 멱등키가 발견된다면, 이에 대한 멱등성 보장을 위해 실제 요청을 진행하지 않고 저장된 응답 데이터를 돌려준다. 없으면 새로운 요청이니까 그대로 로직을 수행한다!

const idempotencyResponses = new Map();

let cancelReq = {
  orderId: req.body.orderId
  amount: req.body.amount,
};

let idempotencyKey = req.headers.idempotencyKey || null // 요청 헤더에서 멱등키를 가져옵니다.

// 멱등키가 있고 멱등 응답도 저장되어 있다면 실제 처리하지 않고 저장된 응답을 내보냅니다.
if (idempotencyKey != null && idempotencyResponses.has(idempotencyKey)) {
  const response = idempotencyResponses.get(idempotencyKey);
  return res.status(response.status).json(response);
};

const result = cancelProcessor.cancel(cancelReq); // 실제로 취소를 처리합니다.

// 멱등키가 있으면 멱등응답을 저장합니다.
if (idempotencyKey != null) {
  idempotencyResponses.set(idempotencyKey, result);
}

const responseBody = {
  message: `결제 취소 성공`,
};

return res.status(200).json(responseBody);

서버에서는 위와 같이 요청에 대해서 멱등키를 가져오고, DB에서 확인한 다음, 케이스 분기를 통해 응답을 한다.

2) Entity Tag

MDN에서 본 방법인데, 이도 키 헤더를 사용하는 방식과 거의 비슷하다. 특정 URL의 리소스가 변경되면 새로운 Etag를 생성하고, 이들의 비교를 통해 자원이 동일한지 여부를 확인한다.

요청

GET /users/123

응답

HTTP/1.1 200 OK
Etag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

{
"name": "cobinding",
"email": "cobinding@abc.com"
}

If-Match를 통한 Etag 확인

POST /users/123
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

{
"name": "cobinding123"
}

간단하게 구현해보기

Entity 정의

public class Resource {
    private Long id;
    private String title;
    private String content;
    private String etag;
    
    public String getEtag() {
        return DigestUtils.md5Hex(title + content + lastModified.getTime());
    }
}

DigestUtils: Apache Commons Codec 라이브러리에서 제공하는 MD5 해시 생성 유틸리티 메서드
- 문자열을 MD5 알고리즘으로 해싱해서 32자리 헥사 문자열로 변환한다.
- 보안성을 더 높이고 싶다면 SHA-256같은 해시를 사용
POST 수정 요청이 왔을 때 If-Match 헤더와 Etag 비교

@PostMapping("/resource")
public ResponseEntity<Resource> updateResource(@RequestBody Resource resource,@RequestHeader(value = "If-Match", required = false) String ifMatch,
HttpServletRequest request) {
   
   String currentEtag = "\"" + resource.getEtag() + "\"";
    if (ifMatch != null && !ifMatch.equals(currentEtag)) {
        return ResponseEntity.status(HttpStatus.PRECONDITION_FAILED).build();
    }
    
    Resource updatedResource = resourceService.updateResource(resource);
    String newEtag = "\"" + updatedResource.getEtag() + "\"";
    return ResponseEntity.ok()
                         .eTag(newEtag)
                         .body(updatedResource);
}

간단 회고

업무를 수행하며 새로운 개념에 대해 접할 수 있어서 재밌었다. 네트워크를 수강하고 HTTP를 따로 공부도 했지만, 직접적으로 개발하면서 배우는 지식은 훨씬 깊이있고 그 깨달음의 깊이도 다르다고 느껴진다. 앞으로도 개발 프로젝트에 도전하면서 더 깊이있는 학습과 그의 적용을 위해 노력해야겠다.

[Network] Transport Layer, Mux & Demux

sebinChu — Wed, 24 Apr 2024 15:04:28 +0900

개요

TCP Keywords

reliable data transfer
flow control
congestion control

Transport Layer가 하는 일

서로 다른 host의 프로세스 간 Logical communication 제공
프로토콜은 End System 즉, host에서 돌아간다.
- Network 계층의 라우터들을 거쳐서 데이터들이 전달되지만, Transport 계층은 이 거쳐가는 과정은 보이지 않고 두 엔드 시스템(프로세스) 사이의 Logical Communication에만 집중한다.
- Sender: App Layer의 메시지를 segment 단위로 메시지를 잘라서, Transport Layer의 헤더를 붙이고 Network Layer로 전송
- Receiver: 받은 segment를 합쳐서 메세지를 만들고 App Layer로 전달

⇒ App ↔ Transport가 메시지를 주고 받을 때 자르고/붙이고 함

⇒ Transport Layer의 핵심은 Multiplexing & Demultiplexing

Transport Layer vs. Network Layer

Network: host 간 logical 통신(우편 배달)

Transport: process 간 logical communication(배달이 된 우편들을 정확히 배분 ex. 12명 ↔ 12명 각각의 이름 매칭)

Transport - ① reliable ② unreliable

① reliable & in-order TCP

보낸 그대로, 순서대로 전달한다.

congestion control
flow control

커넥션을 맺어야 통신이 가능하다.

connection setup

② unreliable & unordered

중간에 날아갈 수 있고, 순서 상관없이 도달 ⇒ 그저 “전달만”!!

TCP, UDP가 모두 해줄 수 없는 것은

언제까지 도달하도록 보장할 순 없다.
속도 유지를 보장할 수 없다.
- 예를 들어, 스트리밍 중에 계속 몇 bps로 속도를 유지할 것인지는 보장 X

Multiplex & Demultiplex

멀티플렉스: 프로세스로부터 받은 패킷에 포트 번호를 넣어 헤더를 만들어서, 하나의 통로로 하위 계층에 보냄.

★ 디멀티: 그 반대, Transport 계층으로 오면 전송된 세그먼트의 헤더 정보를 확인해서 적절한 프로세스의 문(목적지)에 도달하게끔 함.

TCP와 UDP의 Demux

디멀티플렉스는 받은 소켓의 헤더 정보를 확인해서 적절한 프로세스와 연결해주는 것.

⇒ TCP와 UDP는 Demux하는 방식이 다르다. 각각 Connection-oriented, Connectionless

① Connectionless Demux

Datagram 소켓을 생성
desincation IP, Port로 전송
받는 호스트 측에서 UDP Segment를 확인해서, Destination Port가 같다면 OK

⇒ 즉 (src_ip, src_p, dst_ip, dst_pt) 중 dst_pt만 확인해서 같은 소켓으로 보낸다. 보내는 쪽의 주소와 포트 넘버가 달라도 Desination 정보가 같으면 같은 곳으로 보내짐!

② Connection-Oriented Demux

(src_ip, src_p, dst_ip, dst_pt) → 이 네 가지 값을 하나의 튜플로 묶어, 정보로 활용한다.

TCP에서는이 네가지 정보가 담긴 튜플을 활용해서 segment를 적절한 소켓으로 전달한다.

웹 서버는 TCP를 사용하는데, 클라이언트와 커넥션을 맺을 때마다 다른 소켓을 사용한다.→ non-persistent HTTP는 요청마다 새 커넥션을 하기 때문에 모두 다른 소켓을 사용한다.
- reliable data transfer
- flow control
- congestion control

[네트워크] DNS, DNS 쿼리, DNS recode 종류

sebinChu — Wed, 24 Apr 2024 14:59:31 +0900

개요

프로세스가 서로 통신할 때 알아야 하는 두 가지 정보 → IP, Port

IP: 프로세스가 돌고 있는 머신의 Network Interface Card에 부여된 Identity → IPv4, host name(domain name)
Port: 실행 중인 프로세스에 접근할 수 있는

DNS

IP 주소를 hostname으로 매핑(라우팅)해주는 역할

→ Network Layer에서 해야하는 일을 App-Layer에서 함

⇒ Network Layer는 빠르게 전송만 하면 돼서, 복잡한 연산을 App-Layer에서 처리하는 것

distributed database → not centralize
- 가용성, 중요한 서비스는 분산시킨다.
application layer protocol

DNS가 하는 일

host name-IP address
host aliasing - canonical & alias names
main server aliasing
load distribution

DNS 쿼리 과정(www.google.com)

어떤 host에 대한 IP 주소를 요청을 할 때,

INTERATED QUERY

Local DNS Server에 요청
root DNS Server에 요청 → (모르는 경우) TLD에 물어보라고 TLD 주소 알려줌
TLD DNS Server에 요청 → authorititative Server에 물어보라고 A Server 주소 알려줌
authorititative Server는 최종 권한을 가지고 있기에, 알려줌!

RECURSIVE QUERY

Local DNS Server에 요청하고, 답이 올 때까지 기다린다. Server 들이 직접 나서서 응답-요청 과정 겪음

실제로는 root DNS Server는 recursive 방식을 거부한다.

DNS Type 4가지

순서대로 권한 범위가 적다.

1) Local DNS Server(Default DNS Server)

Local DNS 서버는 hierarchy 구조에 포함되지 않으며, 클라이언트 가까이에 있는 캐시 서버다.
DNS 쿼리를 날릴 때 가장 먼저 요청되는 default name server

2) root DNS

전 세계 13개 기관에서 루트 서버 관리. IP 주소 찾기 위해서 항상 이 root에게 먼저 요청.
- root server가 local name server에게 return하는 방식으로 매핑
root부터 트리구조로 되어있으며 바로 아래 단계를 1단계 도메인이라고 한다. **최상위 도메인 TLD(Top Level Domain)**이다.
최상위 도메인은 국가최상위도메인과 일반최상위도메인으로 구분된다.

3) TLD(Top Level Domain)

com, org, net, edu..와 같은 탑레벨 도메인

4) Authoritative servers

기관에서 관장하는 서버

DNS record 종류

DNS Record는 DNS에 온 요청에 대해 어떻게 처리할 것인가를 나타낸 지침이다.

DNS 관리 서비스를 제공하는 cloudflare에 다양한 DNS 레코드 정보가 나와있다.

대표적인 4가지를 상세히 알아보도록 하자.

A record

도메인 주소와 서버의 IP 주소를 직접 매핑하는 방법이다.

예를 들어, cobinding.com이라는 도메인이 있고 EC2 등에서 설정한 서버의 IP 주소가 1.2.3이라고 가정하자.

가비아, cloudflare같은 서비스를 통해 cobinding.com-1.2.3을 직접 연동해주면, 사용자는 이 도메인 주소를 통해 서비스에 접근할 수 있다.

도메인 이름	IP 주소
cobinding.com	1.2.3

이 A record는 반드시 도메인과 IP가 1:1 매칭이 되는 것은 아니다.

관리자의 설정에 따라, 일대다 / 다대일도 될 수 있다.

도메인 이름	IP 주소
cobinding.com	1.2.3 1.2.4 1.2.6

CNAME record

Canonical Name의 약자로, 도메인 주소를 또 다른 도메인 주소로 매핑시키는 형태의 DNS record 타입이다.

아래 host aliasing을 통해 이 개념을 이해해보자.

host aliasing

DNS는 IP- hostname 매핑을 위해서 서버에 도메인 주소와 IP 주소를 쌍으로 저장해둔다.

naver.com 192.168.0.1

dev.naver.com	naver.com
google.com	172.17.0.1

사용자가 요청하면 이 테이블에서 정보 꺼내옴

하나의 행을 레코드(record)라고 하며, 저장되는 타입에 따라 A Record와 CNAME으로 구분한다.

A Record: 직결 매핑. 도메인 - IP 주소가 그대로 매핑됨
CNAME: 사용자가 dev.naver.com을 요청하면 서버는 naver.com을 리턴하고, 사용자는 다시 naver.com을 통해서 192.168.0.1을 응답한다.

A RECORD는 서버의 IP 주소를 한 번에 알 수 있지만, IP 주소가 자주 바뀌면 번거로울 수 있다.

CNAME은 IP 주소가 자주 변경되는 환경에서 유연하게 대응할 수 있지만, 실제 IP 주소를 얻기 위해 여러 번 요청해야 한다.

IP: 프로세스가 돌고 있는 머신의 Network Interface Card에 부여된 Identity → IPv4, host name(domain name)
Port: 실행 중인 프로세스에 접근할 수 있는 문

[네트워크] TCP/IP 5계층 | Application Layer

sebinChu — Wed, 24 Apr 2024 14:49:04 +0900

TCP/IP 5계층

Application
- FTP, HTTP, SMTP 등의 프로토콜
Transport
- TCP, UCP
Network
- IP, 스위치
Link
- 이더넷
Physical

여기서 7계층되면…

Application - Transport 계층 사이에 두 계층 추가
- Presentation 인코딩, 디코딩, 암호화/복호화
- Session: 애플리케이션 간 연결 지원(SSL, TLS 등)

계층 간 이동 ⇒ Encapsulation

각각의 계층을 이동하면서 프로토콜 헤더를 붙이게 된다.

캡슐화: 송신 측에서 응용계층부터 각 계층을 들리면서 헤더 추가, 물리 계층까지 가면 최종적으로 전기 신호로 변환되어 수신 측에 도착

Applciation Architecture(P2P와 Client-Server 구조)

Client-Server 구조

서버는 항상 호스팅되어야 하고, 영구 IP 주소를 가져야 한다.
클라이언트는 서버와 소통하며, 서로 직접 소통 X. 유동 IP 가진다.

P2P 구조

서버가 항상 호스팅되어야 하는 것은 아니다. → peer 끼리 소통하는 거고, 고정된 서버가 없다. 스스로가 서버가되고 클라이언트가 되는 구조다.
self scalability 특성: 새로운 peer가 생기면 계속 서비스 스케일이 늘어난다.
IP가 변동되기도 하는데, 전체적으로 관리가 어렵다.
대표적인 예) 비트토렌트

Process Communication

같은 호스트 안에서 두 개의 프로세스는 IPC(Inter-Process Communication)한다.
다른 호스트의 프로세스는 메시지 교환 → 소켓 통신
- 소켓은 프로세스의 문(door)과 같은 역할을 한다.

⇒ 소켓 통신은 다른 호스트에 존재하는 프로세스간 통신이다! 각각의 소켓은 서로 IP주소와 port 번호로 식별되고, 네트워크를 통해 서로 연결하고 데이터 송수신한다.

IP는 컴퓨터를 찾아가는 역할
PORT는 많은 프로세스 중 원하는 프로세스를 찾아가는 역할

*웹서버는 모두 80포트 사용. 네이버, 다음, 구글 등등 통일적으로 찾아가기 위해서!

App Layer Protocol RFC

Requests for comments: IETF에서 관리하는 기술 표준으로, 프로토콜 및 파일이 주요 주제이며 승인된 문서는 일련된 번호를 갖는다.

HTTP는 RFC-2068에서 시작되었다.

App Layer와 Transport Layer의 관계

Data Integrity: 데이터의 유실없이 도착
Timing: 예정된 시간 내에 도착
Throughput: 데이터의 처리율(용량)이 충분
Security: 안정성

⇒ Transport Layer가 제공하는 것은 1번 딱 하나. 나머지는 app 계층에서 처리.

App Layer 주요 프로토콜

Protocol Port Application underlying Transport Protocol

HTTP	80	web	TCP
SMTP	25	e-mail	TCP
Telnet	22	remote terminal 접근	TCP
FTP	21/20	파일 변환	TCP
RTP		스트리밍	TCP or UDP

SSL(Secure Socket Layer)

인터넷을 통해 전달되는 정보를 보호하기 위해 개발한 통신 규약 → HTTPS는 HTTP를 암호화하여 전송

[Algorithm] 이중 포문 조정 - 구간합

sebinChu — Wed, 17 Apr 2024 18:30:38 +0900

개요

시간복잡도 줄이는 법을 학습하면서 해본 정리

코드트리를 참고하였다!

어떤 배열에서 특정 합을 만족하며 가장 크기가 큰 구간의 크기를 찾기 위해 완전탐색을 하면 다음과 같다.

완전탐색 - O(N**3)

# 이 배열에서 특정 구간을 골라서, 
# 합이 10이 넘지 않아야 하고,
# 배열의 크기가 가장 커야 한다. 이때의 배열 크기는?

arr = [0,6,3,2,4,9,1]
n = len(arr)
target=10

# 무식하게 구해보기
for i in range(1, n+1):
    for j in range(i, n+1):
        total = 0
        for k in range(i, j+1):
            total += arr[k]
        
        if total <= target:
            ans = max(ans, j-i+1)

이 코드의 복잡도는 O(N**3)이다.

복잡도를 줄여보자.

구간 내 시작점과 끝 활용 - O(N**2)

# 일단 모든 구간 탐색
for i in range(1,n+1):
    total=0
    for j in range(i,n+1):
        total += arr[j]
    
    # 특정합이 타겟합을 넘었을 때
    if total > target : break

    ans = max(ans, j-i+1)

*이 경우, j는 i 값이 달라질 때마다 i에서 새로 시작하므로 후퇴하는 경우가 많이 발생하게 된다. ➡️ 시간복잡도는 O(N**2)

# while로 표현해보면
total=0
j=0

for i in range(1,n+1):
    while j+1 <= n and total + arr[j+1] <= target:
        total += arr[j+1]
        j += 1
    
    ans = max(ans, j-i+1)
    
    # 다음 구간으로 넘어가기 전에 arr[i]의 값은 해당 구간에서 제외한다.
    total -= arr[i]

투 포인터는 이렇게 i, j가 한 방향으로 전진하면서 연산을 수행하는 형태를 갖는다. ➡️ 시간복잡도는 O(N)

이 i, j 전진 테크닉은 실제로 이중 포문으로 작성되어 있지만, i와 j가 한 방향으로 진행되기 때문에 시간 복잡도는 두 for loop의 곱이 아니라 합으로 나타내진다.

구간 내 특정 합이 존재하고, 중복되는 값 Counting

같은 숫자가 3개 이상 있지 않은 경우 중, 가장 큰 구간의 크기

### 같은 숫자가 3개 이상 있지 않은 경우 중, 가장 큰 구간의 크기
n,s=map(int,input().split())
arr=[0] + list(map(int,input().split()))


# 각 숫자마다 몇 번씩 나왔는지 카운팅하는 배열을 추가적으로 만들어 관리한다.
## cnt_arr의 인덱스는 숫자 정보, value는 해당 숫자가 등장한 개수
cnt_arr=[0]*4


ans=0
j=0
for i in range(1,n+1):
    while j+1 <= n and cnt_arr[arr[j+1]] != 2:
        cnt_arr[arr[j+1]]+=1
        j+=1
    
    ans=max(ans,j-i+1)
    # 하나 제거
    cnt_arr[arr[i]] -= 1

[DB] DB스튜디오 과제 리뷰 2 | 데이터 모델링과 개념적 설계

sebinChu — Wed, 17 Apr 2024 13:27:22 +0900

개요

지난 1편에 이어서, 이번 과제도 배울 점이 많아 리뷰를 작성한다.

요구사항 1

지금까지 과제에서는 DATABASE 설계 명목 하에 개체와 속성이 뚜렷하게 보이는 식으로 요구사항이 정의되었다.

그런데 원래 요구사항은 대화하는 방식으로 주어진다. 이번 과제부터 자연어 요구사항이 주어졌고.. 이러한 경우는 "모호성 제거" 단계를 거쳐야 한다.

내 설계는 위와 같은데, 피드백을 받으면서 느낀 점은 다음과 같다.

요구사항이 빠졌는지에 대해 면밀히 검토하는 것은 좋다.
그런데 개체 간의 단순한 관계의 의미를 넘어서 응용 관점을 검토해보는 태도가 필요하다. 그러니까 위 설계같은 경우는 Customer와 Book 사이에 order라는 관계는 의미상으로는 완벽하다. 하지만 다음 질문에 답하기 어려운 설계다.
- Customer가 같은 책을 다른 날에 걸쳐 여러 번 주문하게 될 경우 어떻게 처리할 것인가?
- 참고) 관계가 식별키를 가질 수는 없다.

연하게 되어있는 관게는 첫 번째 단계까지만 수행하고 추후 보정을 못한 케이스다.(나의 케이스....)

요구사항 2

역시나 부족한 모호성 제거.... 교수 속성에서도 주제, 상태같은 모호한 것은 정의를 하고 반영하는게 맞다.

모호성 제거 단계를 통해 주소지에 관한 다양한 요구사항에 대해서 도시 개체를 만들어 한번에 해결한다.
날짜가 주는 추상화에서 오는 모호성을 제거하여 요일로 표현한다.

위처럼 크게 골격 스키마를 정리하고 나서 겹치는 부분은 다시 세분화하고, 여러 케이스를 따져서 구체화해준다.

사실 2번은 내가 설계한 것처럼 subentity를 표현하는 것이 문제 의도라고 생각하였는데, 풀이를 듣고보니 스키마 설게 단계 각각을 잘 이해하고 수행하고 있는지 확인하는 것이 의도였다. 어떤 식으로 표현을 하든 정통하는 설계 범주가 있으니, 단계 별로 해야할 일을 주의해서 설계하도록 하자.

스키마 설계 단계

모호성 제거
제거 후, 관련 있는 문장끼리 나누어 집합으로 정리한다. (집합으로 정리하는게 union이나 super-sub 관계를 나타내기도 좋은 것같다..! 앞으로 설계를 할 때 적극적으로 집합 정의를 해볼 생각이다.)
골격만 잡는 정도의(C-O-B 딱 이 수준의) 초기 설계 후, 여러 상황을 가정하며 세분화 진행; C-O-B에서 여러 주문은 어떻게하지? 이런식으로 의문을 잡아 나가는 것

모호성 제거

1. 용어에 대한 추상화의 적절한 단계를 선택한다.

여기서 용어라는 것은 추상적 용어와 구체적 용어 두 가지를 말한다.

예를 들어, 살았던 도시와 년수를 더 추상적인 용어로 변경하면 장소와 기간이 된다. 요구사항을 읽고 두 용어 간의 접점을 잘 잡아서 명명 및 설계해야한다.

2. 일반적인 개념대신 인스턴스의 사용 회피

필요 이상의 특정 용어들을 막 남발하면 이 용어 때문에 괜한 복잡한 설계를 하게 된다.

예를 들어서 컴퓨터에는 cpu, ram, 메인보드 등이 있는데 이 하나하나를 DB에 사용하면.... 의도치 않게 난잡해질 수 있다. 따라서, 이들을 포괄하는 부품(components)과 같이 포괄적인/일반적인 개념으로 표현하는 것이 좋다.

3. 완곡한 표현 회피

너무 완곡한 표현을 사용하는 것 또한 의도치않은 오류나 불편함을 초래한다. "매표창구에 앉아있는 사람"은 "매표원"으로 교체하는 등 명확한 개념과 용어를 사용하자.

4. 표준 문장 형식의 선택

다양한 문장 스타일 대신 단순한 문법 범주의 문장을 사용하자.

<주어><동사><서술부> 형식
<if><condition><then><action> 등 프로그래밍 언어 형태의 문장을 활용하는 것이 좋다. (애플리케이션 개발자와 계속 소통할테니 이 편이 확실히 좋다는 느낌을 받았다.)

5. 용어들 사이의 명백한 참조

참조할 개념들이 요구사항에 명백히 표현되게 해야 한다.

1번의 추상화 개념과 같이 고려하면 좋다. 예를 들어 이런 것이다. "날짜(day)"는 요일(day of the week)을 말하는 것인지, 날짜(day of month)를 말하는 것인지 명백하게 하는 것이 좋다.

6. 용어 해설집

사실 과제에서 하는 설계는 개체가 10개도 되지 않는 간단한 것들이기에 바로바로 설명이되지만 실무에서는 포괄적인 용어 해설집을 작성하여 스키마를 접하는 사람의 이해를 돕는다.

요구사항 2의 모호성을 제거한 예시다. 대체[모호한 개념]로 표기되어있다.

생각보다 사소하지만 배우지 않으면 할 수 없는 것들을 배워서 가끔 충격을 받곤한다

졸업하기 전에 제대로된 DB 설계 수업을 듣고싶어서 수강했는데, 잘 했다는 생각이 든다..

과제가 많고 개념을 하나하나 공부하기 시간이 필요하지만 성장했으면 좋겟다.

[AWS] public & private subnet 분리로 서버 운영하기

sebinChu — Sun, 7 Apr 2024 19:06:30 +0900

개요

AWS 서비스를 조금 더 보안성 있게 운영하고자 한다면, 한 VPC 내의 subnet을 분리하여 사용하는 방법이 있다.

이번 프로젝트는 앞으로 동아리에서 쭉 사용할 서비스이므로 처음부터 보안에 유의하여 설계를 해야겠다 다짐했다!!

그래서 이 포스팅을 통해 어떤 과정을 겪었는지 정리해보려 한다.

AWS에서 자체적으로 해주는 것이 많아서 생각보다 많이 간단했다.

VPC 만들기

AWS 계정을 생성하고 나면 기본 VPC는 존재한다. 별도의 퍼스널 서브넷 세팅을 위해 새로 VPC를 생성하자.

생성할 리소스 옵션 중 VPC만/VPC 등 두 가지가 있는데, private subnet에 RDS를 두려면 반드시 후자를 선택해야 한다. RDS 생성 시에도 RDS subnet을 세팅하게 되는데 이때 subnet은 두 개 이상의 리전에 대한 VPC에만 설정할 수 있기 때문이다.

가용영역 세팅하기

가용영역은 서비스를 호스팅할 지역의 2a, 2b로 설정한다.

서브넷 CIDR 블록은 private subnet은 RDS만 둘 예정이므로 25로 비교적 작은 값으로 세팅하였다.

이후, NAT 게이트웨이와 VPC 엔드포인트는 일단 없음으로 설정하고 다음 세팅으로 미루도록 한다.

생성 후 VPC 리소스맵을 통해 확인

세부정보 탭 옆 리소스맵

각각의 리전 가용영역에 public/private 서브넷이 세팅된 것을 확인할 수 있다.

특히 public 라우팅 테이블은 두 개의 public 서버와 한 번에 연결되어 있다.
또한 외부와의 통신을 위해 Igw(Internet gateway)와 잘 연동되어있음을 확인할 수 있다.
private 라우팅 테이블은 개별 서브넷에 할당되어 있으며 Igw와는 당연히 연결이 되어있지 않다.

인터넷 게이트웨이란?

VPC와 인터넷 간 통신을 가능하게 하는 통로다. 이 인터넷 게이트웨이를 VPC에 연결하여 퍼블릭 서브넷으로 연결해주면 해당 서브넷이 퍼블릭 역할을 할 수 있다.

위처럼 VPC 등 세팅을 한꺼번에 하게되면, AWS에서 자동으로 이를 생성하고, 등록해준다.

실제로 따로 Internet Gateway를 설정하고 등록하려면 아래와 같이 게이트웨이와 VPC를 연동해주면 된다.

해당 프로젝트에 사용되지 않는 별도의 IGW

보안그룹 세팅

보안 그룹은 특정 VPC에 대한 규칙이므로 처음에 반드시 보안 사항을 적용할 VPC를 선택해주어야 함을 유의하자.

인바운드 public 규칙

외부에서 VPC - public subnet 내부의 EC2로 접근 가능한 프로토콜을 세팅한다.

즉, 인바운드에 대한 규칙을 설정한다. public 서버에 대한 보안 그룹이므로, 모든 트래픽(Ipv4: 0.0.0.0/0, Ipv6: ::/0)을 허용한다.

유형만 선택하면 프로토콜과 포트를 결정해주어서 정말 편했다..

*아웃바운드는 apt-get 등 패키지 설치를 위해 http, https만 허용하였다.

인바운드 private 규칙

이번에는 내부망에서 관리자가 EC2를 통해 RDS로 접근할 수 있는 보안 규칙을 생성한다.

DB 접근 전용 SG이므로, 위와 같은 명명 규칙과 설명을 추가한다.

이때는 public 설정과 달리 트래픽 범위를 제한해야 한다.

일단 유형/프로토콜/포트범위는 사용할 MySQL로 제한하고, 소스 범위는 위에서 정의한 public SG로 할당한다!

이렇게 제한함으로써 private한 구축이 가능하게 되는 것이다.

세팅 완료

GCP를 쓰다가 AWS로 프로젝트에 도전해보았는데 훨씬 자동화도 잘 되어있고 편리하다는 것을 많이 느꼈다!

이번 과정을 통해 기반을 다져두었으니, 다음 포스팅에서는 RDS와 EC2 등 세팅을 진행해보도록 하자.

[백준/1063] 킹 | 구현 실수 방지를 위한 경우의 수 체크하기

sebinChu — Sun, 31 Mar 2024 14:40:53 +0900

킹

1063번: 킹

8*8크기의 체스판에 왕이 하나 있다. 킹의 현재 위치가 주어진다. 체스판에서 말의 위치는 다음과 같이 주어진다. 알파벳 하나와 숫자 하나로 이루어져 있는데, 알파벳은 열을 상징하고, 숫자는

www.acmicpc.net

알고리즘

킹이 움직인다. 이때 체크해야할 조건은 다음과 같다.

격자 안에서만 움직여야 한다.
돌이 있는 곳으로 움직일 경우, 돌과 함께 움직여야 한다.
이때 돌 또한 격자 안에서 움직여야 한다.
돌이 격자 밖으로 나가는 경우도 체크하되, 이때 킹이 격자 내에서 움직인다면 상관없이 움직인다

이를 코드로 나타내면 다음과 같다.

# 격자 내에서 해결해야한다.
if (0 <= king_row+r < 8 and 0 <= king_col+c < 8):
    # king이 rock이랑 같은 방향으로 갈 경우
    if (king_row+r == rock_row) and (king_col+c == rock_col):
        # 돌이 움직일 수 있다면 (격자 내라면 같이 이동)
        if (0 <= rock_row+r < 8 and 0 <= rock_col+c < 8):
            rock_row += r
            rock_col += c
            king_row += r
            king_col += c
        # 돌이 격자 밖으로 움직이는 경우
        else:
            continue
    else:
        king_row += r
        king_col += c

돌과 킹이 함께 움직이되 킹이 우선순위다. 이 케이스들을 if로 분기해주었다.

전체 코드

# 행: row, 열: col

row = {'8':0, '7':1, '6':2, '5':3, '4':4, '3':5, '2':6, '1':7}
col = {'A':0, 'B':1, 'C':2, 'D':3, 'E':4, 'F':5, 'G':6, 'H':7}
move = {'R':(0,1), 'L':(0,-1), 'B':(1,0), 'T':(-1,0), 'RT':(-1,1), 'LT':(-1,-1), 'RB':(1,1), 'LB':(1,-1)}


king, rock, n = input().split()
n=int(n)
graph = [[0 for _ in range(8)] for _ in range(8)] # 8*8 체스판


king_row, king_col = row[king[1]], col[king[0]]
rock_row, rock_col = row[rock[1]], col[rock[0]]
graph[rock_row][rock_col] = 1

for _ in range(n):
    command = input()
    r,c = move[command][0], move[command][1]
    
    # 격자 내에서 해결해야한다.
    if (0 <= king_row+r < 8 and 0 <= king_col+c < 8):
        # king이 rock이랑 같은 방향으로 갈 경우
        if (king_row+r == rock_row) and (king_col+c == rock_col):
            # 돌이 움직일 수 있다면 (격자 내라면 같이 이동)
            if (0 <= rock_row+r < 8 and 0 <= rock_col+c < 8):
                rock_row += r
                rock_col += c
                king_row += r
                king_col += c
            # 돌이 격자 밖으로 움직이는 경우
            else:
                continue
        else:
            king_row += r
            king_col += c
            
            
king_position=str()
for k,v in col.items():
    if v == king_col:
        king_position += k
            
for k,v in row.items():
    if v == king_row:
        king_position += k

print(king_position)

rock_position=str()
for k,v in col.items():
    if v == rock_col:
        rock_position += k
        
for k,v in row.items():
    if v == rock_row:
        rock_position += k
    
print(rock_position)

알게된 점

경우의 수를 모두 손으로 작성하고, 코드로 어떻게 분기할 것인지를 중점으로 구현하자.

[DB] DB스튜디오 과제 리뷰 | 데이터 모델링과 개념적 설계

sebinChu — Wed, 27 Mar 2024 14:51:58 +0900

개요

DB 스튜디오 과목에서 매주 요구사항에 맞게 데이터 모델링을 하고, 개념적 설계를 진행한다.

각각의 팀이 설계한 과제물에 대해 게시판을 통해 1차 토의하고, 강의시간에 교수님과 2차 토의를한다.

토의에서 나왔던 내용을 중심으로 과제에 대한 리뷰를 작성해보도록 한다.

요구사항

첫 설계의 요구사항은 다음과 같다.

하나는 UNIVERSITY DB로, 일반적으로 대학교에서 학생, 학부, 과목 등을 관리하는 요구사항이다.

두 번째는 MAIL_ORDER DB로, 쉽게 말해 구매 서비스다.

개체와 속성, 관계 추출

먼저 ERD를 그리기 전, 텍스트로 개체와 속성, 관계를 추출하는 과제를 수행하였다. 이때 composite, complex attribute 등의 속성 특징과 관계를 속성으로 나타내는 것을 활용하였다. 특히 속성의 종류는 설계에 있어서 중요하다고 생각이 들어 여기에 미리 정리해두었다.

이 단계에서 주의할 것은 다음과 같다.

개념 설계에서는 특정 DB를 전제하지 말자.

보통 DB를 RDBMS로 먼저 접하는 사람이 많아서 그런지, 개념 설계 단계에 RDBMS의 특징을 보이는 팀이 종종 있었다. 예를 들어, 다른 개체(Entity)의 식별값을 통해 관계를 정의하는 케이스가 가장 많았다.

개념 설계 단계에서는 요구사항을 명확히 파악하고 청사진같은 존재이므로, 특정 DB를 전제하에 설계하지 않도록 주의하자.
ER 모델에서 참조 관계는 속성이 아니라 관계로 표현된다.

개념과 표기법을 숙지하자.

composite, mutiple, complex 등 다양한 속성의 종류가 있다. 그런데 이 개념들을 헷갈려하는 팀들이 많았다. 또한, ERD에서 표기하는 것까지 착각한 팀도 있었다. 위 노션 페이지에 정리한 것을 토대로 각각의 개념과 표기법을 숙지하자.

STUDENT DB에 대한 개체, 속성, 관계 추출

주소와 휴대폰 번호를 연락처라는 complex attribute로 구조화 AddressPhone({Phone(current, permanent), Address(current, permanent(city, state, zip-code))}) 하였다.

Course와 Section, Grade가 많이 헷갈렸는데 사실 내 과제물에서는 특이 점이 없었다.
잘못 설계한 점은 Course Entity에 section_number라는 속성을 추가함으로써 외래키를 사용했다는 점이다.

MAIL_ORDER DB에 대한 개체, 속성, 관계 추출

여기서 좀 크리티컬한 실수를 했다.

나는 요구사항에서 하나의 Order는 Customer에 의해 생성되고, 또 Employee에 의해 관리된다는 점에 주목해서 각각의 Entity마다 해당 정보를 가질 수 있도록 작성하였다.

데이터가 중복된다는 단점이 있다. 하나의 Entiry에만 정보를 잘 담아두면 된다.
이때 어떤 개체에 정보를 담을 것이냐?를 유의해야 한다. (위 예시같은 경우는 EMPLOYEE에도 담을 수 있고, COUSTOMER에도 담을 수 있다.)

결론적으로 ORDER를 제외하고, 다른 Entity에 정의한 관계는 모두 제거하였다.

ORDER 개체가 part, customer, employee와 모두 직접적으로 연관되어있으므로 ORDER를 대표로 관계 속성을 정의하였다.

데이터 모델링, ERD

이 단계에서는 여러 표기법을 통해 그림으로 도식화한다.

DATA Refining

① Participation ② Cardinality를 고려한 Refining을 진행한다.

사실 이 DATA Refining이라는 것이 잘 이해가 안되었는데 GeekInterview에서 상세히 설명하고 있다. 좋은 자료라 첨부한다!

각각의 세부 단계에서는 다음과 같은 개념이 활용된다.

Relationship Type, Sets and Instances
Relational Model
Realationships as Attributes
Role Names and Recursive Relationships
Constraints on Relationship Types
Cardinality Ratios for Binary Relationships
Participations Constraints and Existenxe Dependencies
여러 개체 타입에 자주 등장하는 경우는 속성을 Entity로 승격하고, Entity로 두기에 애매한 것은 속성으로 강등한다.

=> 일단 과제 리뷰 포스팅이니 위와 같은 내용은 따로 DB 개념 등으로 포스팅할 것이다.

위 주의사항을 토대로 ERD를 그린 건 다음과 같다.

수정 전

피드백

[표기법] Composite 속성과 Multiple 속성의 표기를 혼동하였다. name, phone, address 속성은 multiple attribute를 의도하였으므로, 표기를 수정해주어야 한다.
[설계 관점]Grade Weak Entity의 문법상 의미는 맞다. 그러나 문맥상 의미는 좋아보이지 않는다. 차라리 Student의 속성으로 강등하는 것이 나을 수도 있다.
[설계 관점] 주전공/부전공을 나타내는 관계속성은 그 의미는 맞으나, 오해의 소지가 있다. (ex. (1,2) min-max를 설정하면 부전공이 2개로 들어갈 수 있는데 이걸 구별하는 값이 없다. 차라리 major_department와 minor_department 두 관계로 구분짓자.
[설계 관점] Section Entity는 개별적으로 구분이 안되며 종속적인 개체이기에 (1,n)은 맞지만 문맥상 완전 틀렸다. 학생이 수강하는 것은 Course가 아니라 Section이다. 따라서 Section의 Course의 Weak Entity이어야 하고, Section은 Studer와 연관관계 매핑이 된다.
[중복 데이터] Student와 Grade를 연관관계 매핑해놓고, partial key에 student, section을 주었다. 이는 중복 데이터다.
[표기법] Partial/Total Participation과 Chen 기법을 혼용하였다. 하나로 통일하는 것이 좋다.

수정 후

속성들은 생략하고 수정해보았다.

이 과정을 생략하고 바로 ERD 도식화에 들어가서 놓치는 부분이 많을 수밖에 없었다.

교수님께서도 이 과정을 통해 중복된 값을 제거하는 것이 중요하다고 강조하셨다.

배운 게 많은 만큼 다음 과제는 더 명확하게 해봐야겠다~~

[개발일지] 배포 삽질기 | 심볼릭 링크, 리눅스의 Capacities, ufw, netstat

sebinChu — Mon, 25 Mar 2024 13:04:25 +0900

개요

새로운 프로젝트 배포 테스트를 하는 과정에서 했던 삽질에 대해 기록한다.

하나의 도메인 내에서 여러 포트를 사용하고, 또 여러 웹서버를 사용하는데 제대로 서버/네트워크를 파악하지 못할 시 시도해볼만한 것들이다.

내가 진행한 서버의 개략적인 상황은 다음과 같다.

HTTP/HTTPS 요청
80, 8085, 8080 - Tomcat, Apache, java application
- 이 중에서 8080은 서버(platform) 역할을 한다.
8081 - Node.js(React), Nginx

일단 Ningx 웹서버 위에 React 프로젝트를 올리는 건 따로 포스팅할 예정이다. 여기서는 정말 내가 했던 삽질, 날 것을 다룬다...

까먹지 않으려고 기록하는 용이고 필요하다면 키워드를 통해 다른 사람도 활용할 수 있도록 정리해볼 것이다.

포트포워딩 관련 문제가 생겼다면 체크해볼 것

application 레벨에서 port 설정이 잘 되어있는가? 예를 들어, 자바 애플리케이션은 프로퍼티 파일에 server.port=80 이런식으로 설정할 수 있다.
방화벽이 잘 세팅되었는가? -> VPC나 ubuntu같은 경우는 ufw로 해결
클라우드 환경에 배포한다면, 사용할 포트에 대해 허용해줬는가? -> ufw 등 리눅스 명령어로 방화벽 관리
Nginx같은 웹서버라면, .conf 등의 세팅 파일 확인 -> 서버의 포트가 잘 설정되었는지 직접 파일을 열어 확인할 수있다.

다양한 Linux - Debian / RedHat

Linux는 UNIX 기반의 다중 작업을 지원하는 네트워크 OS다.

Linux는 오픈소스이기에, 다양한 많은 버전의 리눅스가 있다.

대표적인 Linux OOS

회사	대표적인 Linux	관리 패키지
RedHat	CentOS	yum
Debian	Ubuntu	apt / apt-get

이 둘 간의 차이를 명확하게 이해하지 못해서 약간의 시간 낭비를 했다.
RedHat 계열의 CentOS는 2021년부로 업그레이드를 하지 않으므로, 사용에 주의하도록 하자.

처음엔 비교적 더 저렴한 CentOS에서 node 프로젝트를 배포하는 작업을 했다.

그런데 GLIBC_2.27’ not found (required by node) 이런 에러가 발생하였다. 이는 해당 OS가 아래 목록의 라이브러리를 지원하지 못하는 케이스다.

해결하는 방법은 다음과 같다.

OS를 업그레이드한다.
OS를 바꾼다.

1번은 내가 정확하게 이해한 건지도 모르겠고 여러 개발 커뮤니티, 문서 등에서 2번을 추천했기에 과감히 2번으로 선택했다. 많이 귀찮아질 것을 예상했지만... 요구사항이 Node 버전은 18이상이었기에, 이를 맞추려면 불가피한 선택이었다. 나도 이 과정 때문에 알게된건데 CentOS는 더이상 업그레이드가 안되는 구버전의 linux다. 그냥 ubuntu 쓰자.

심볼릭 링크(symbolic link)

자바 애플리케이션을 배포하기 위해서 자바를 다운 받는다.

이후, which java 등의 명령어를 통해 자바 위치를 확인할 것이다. 이때 나오는 경로는 심볼릭 링크일 확률이 높다.

심볼릭 링크란

말 그대로 symbol. 실제 주소는 따로 있고 참조하는 링크다.

왜 심볼릭 링크를 쓰는가?

관리가 편하다, 공간 절약, 편의성 등등 .. 여러가지 이유가 있는데... 솔직히 잘 이해는 가지 않는다ㅠㅠ

이 부분에 대해서 심도있게 학습한 후 정리해야겠다.

진짜 링크 확인 방법

readlink -f [symbolic link]

애플리케이션 실행 시 심볼릭 링크를 사용해도 문제는 없다.

그러나 이 개념을 알고 있으면 애플리케이션 실행 및 배포에 문제가 생겼을 때 여러모로 활용할 수 있다.

Ubuntu 서버의 방화벽

GCP에서 방화벽을 관리하지만, ubuntu 자체에서 관리하는 방법도 있다.

바로 ufw라는 것인데, Uncomplicated Firewall의 약자로 방화벽 관리 프로그램이다. 명령어를 통해 간단하게 관리가 가능해서 편리하고 유용하다.

ufw 대표적인 사용 예제

# ufw 설지
apt-get install ufw

# ufw 활성화
sudo ufw enable

# 방화벽을 허용하는 명령어
ufw allow ${port_number}

# 허용된 방화벽 포트 확인
ufw status verbose

주의할 점

클라우드 컴퓨팅 서비스를 이용하고 ufw를 사용하고 싶다면, 일단 enable 한 뒤에 22번 포트부터 열어주자.

바보같이 22번 포트를 열지않고 직렬 콘솔로 해결하였다.

보통 서버에 ssh 키로 접속하여 작업을 하니까.. 명심@

Linux Capacities, well known 1024 이하 포트는 일반 계정으로 사용이 불가능하다.

리눅스 서버들은 루트와 일반 사용자의 권한을 철저히 분리한다. 이를 Capacity라는 시스템 하에 관리를 하는데, 보안상의 문제를 방지하기 위해서다. CAP_NET_BIND_SERVICE 가 대표적인 예다.

setcap 'cap_net_bind_service=+ep' [허용을 원하는 파일명의 주소]

이러한 특권은 리눅스에서 다양한 경우의 수를 따져 만든 보안 이슈일 것이다.

따라서 유의해서 사용해야 한다.

이러한 Linux Capacities 관련해서는 따로 깊게 공부를 할 필요가 있다고 느꼈다.

리눅스/네트워크 정보 관련 다양한 명령어

netstat

network statistic는 네트워크 연결, 라우팅 테이블, 포트 정보 등등 다양한 네트워크 관련 정보를 보여준다.

이 명령어는 사용하기 어렵지 않지만, 도커처럼 사용 옵션을 파악하는 것이 중요하다.

주요 옵션

옵션	설명
-a	--all과 같다. LISTEN, NOT LISTEN 소켓정보 모두 보여준다.
-n	--numeric과 같다. 10진수의 수치 정보로 결과를 출력한다.
-r	--route와 같다. 설정된 라우팅 정보를 출력한다.
-l	--listening과 같다. listen되고 있는 정보를 출력한다. netstat -anp \| grep LISTEN 이런식으로 직접 listen 패턴을 지정할 수도 있다.

lsof

List Open Files는 현재 열려있는 파일을 보여주는 명령어다. 이때 단순한 디스크 파일이 아니라 소켓, 파이프, 디바이스 등등 다양한 종류의 파일의 정보를 확인한다.

# 443 포트에 연결된 프로세스 넘버 확인
# -i 옵션은 대소문자 구별을 하지않는 값이다.
lsof -i :443

# TCP 연결 확인
lsof -i TCP

# 특정 프로세스에 의해 열린 파일
lsof -p ${PID}

# 지정 디렉토리와 하위 파일들 
lsof +D /home/cobinding

[AWS] AWS CLI 설정 및 활용하기

sebinChu — Sun, 24 Mar 2024 15:37:56 +0900

개요

GCP를 사용하면서 이 글 과 같이 google cloud SDK라는 걸 통해 콘솔에 접근하고 여러 클라우드 서비스를 이용하였다.

AWS도 이와 마찬가지로 SDK, CLI(명확하게 말하자면 SDK와 CLI는 다른 것이긴 하다.)를 통해 콘솔에 접근하는 서비스가 있다.

이걸 설정하고 AWS 서비스를 이용해보자!

우선 root 계정과 그로부터 admin 권한을 할당 받은 계정이 있다고 가정한다.

AWS CLI latest 다운

sudo curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"

해당 문서는 MacOS 사용자 기준으로 다운 방법을 제시하고 있다.

그냥 위 명령어를 iterm or terminal에 입력해주면 된다.

이후 aws --version을 통해 제대로 설치가 잘 되었는지 확인하자.

Access keys 발급

IAM의 user > Security credentials로 접근하자.

여기서 Create access key를 눌러 키를 발급해준다. 나는 이미 발급을 한 상태이다. csv 파일로 다운하는 것도 지원하니, 미리 다운해두자!

AWS Configure

aws configure

aws cli가 잘 다운되었으므로, 명령어를 통해 계정 접근 ID와 key를 설정해준다.

발급받은 ID와 key를 설정하고, 원하는 리전을 선태한다.

Default output format의 경우 설정할 것이 없어서 단순히 enter로 마무리 하였다.

확인 테스트

aws iam list-users

해당 명령어를 터미널에 입력하면, users에 대한 JSON값이 나온다. (AWS는 모든 IAM 설정을 JSON으로 통제할 수 있다.)

간단하게 User와 Id 등등 정보가 잘 출력되면 연동 성공이다!

편리하게 AWS를 활용하는 방법을 알아보았다.

GCP를 쓸 때도 가끔 CLI가 훨씬 편한 경우도 있었는데, AWS에도 있어서 다행이다.