cloudwithbass

[DNS] DNS 구성 요소와 이름 풀이 과정, 레코드 타입

cwb111 — Mon, 4 May 2026 18:17:57 +0900

1. DNS구성 요소

DNS에선 아래와 같이 세 종류의 구성 요소가 있습니다.

스터브 리졸버
- 풀 리졸버에게 이름 풀이를 요청합니다.
- 주로 OS에 내장되어 있습니다.
풀 리졸버
- 실제로 이름 풀이를 수행합니다.
- 인터넷 상의 서버에 질의하기 때문에 공인 IP를 할당하는 것이 일반적입니다.
- 대표적으로 구글이나 클라우드 플레어의 8.8.8.8, 1.1.1.1 같은 오픈 리졸버가 있습니다.
권한이 있는 서버(네임 서버)

실제론 스터브 리졸버와 풀 리졸버에 '포워더'라는 구성 요소도 존재합니다.

포워더는 스터브 리졸버와 풀 리졸버 간 질의와 응답을 중계합니다.

Forwarder와 Conditional Forwarding 차이 (출처: https://blog.naver.com/mschoi72/221996559578)

Conditional Forwards
: DNS서버가 가지고 있지 않은 외부 레코드에 대해 쿼리가 들어오게 되면 DNS 서비스는 Root Hits 라는 DNS 루트 서버 리스트를 이용하여 외부 DNS로 쿼리를 하게 됩니다. 만약 이 Root Hits 가 없다면 외부 DNS 레코드에 대해서는 어디로 쿼리를 해야 할지 모르기 때문에 쿼리가 실패하게 됩니다. 그런데 문제는 Root Hits 를 사용하게 되면 어디 루트 DNS 서버를 통해서 외부 쿼리가 되는지 정확히 알 수 없고 신뢰할 수 있는 DNS 서버로 부터 값을 가지고 오는 것이지 등 등을 알 수 없는 상황이 될 수 있기 때문에 만약 어떤 특정 도메인에 대해서는 특정 외부 DNS를 설정할 수 있습니다. 이렇게 설정한 DNS서버를 Conditional Forwards 라고 표현합니다. 그렇다면 Conditional Forwards 가 있으면 일반 Forward 도 있지 않을 까요? 맞습니다. 어떤 조건이 필요없이 모든 외부 DNS에 대해 무조건적으로 Forwarding 하는 DNS 서버는 그냥 Forwarder 라고 표현합니다

[이름 풀이 과정]

아래는 test.kr 도메인에 대해 처음으로 이름 풀이를 하는 예시 과정입니다.

1. 스터브 리졸버 호출

클라이언트가 이름 풀이가 필요하면 스터브 리졸버를 호출합니다.

Windows OS에선 DNSClient라는 서비스가 스터브 리졸버 역할을 담당합니다.

[캐시와 네거티브 캐시]

DNS 처리 효율을 높이기 위해 캐시와 네거티브 캐시를 사용합니다.

캐싱한 내용이 있으면 이제 같은 질의에 대해선 이름 풀이를 수행하지 않고 바로 응답할 수 있습니다.

네거티브 캐시란, '존재하지 않는다'라는 결과도 캐싱하는 동작입니다.

이 결과를 캐싱하지 않으면 존재하지 않는 결과에 대해 반복적으로 이름 풀이하는 경우가 발생합니다.

[네임 서버의 가용성]

네임 서버가 여러 개일 경우, zone의 데이터를 각 네임 서버에 복사해야 합니다.

이를 존 전송(zone transfer)이라고 합니다.

이 때 데이터를 전송하는 서버를 primary server, 데이터를 받는 서버를 secondary server라고 합니다.

네임 서버가 여러개면 풀 리졸버는 RTT(Round Trip Time)값으로 질의할 네임 서버를 선택합니다.

RTT는 질의 후 응답이 돌아오기까지의 시간입니다.

[풀 리졸버의 가용성]

스터브 리졸버는 질의 대상으로 여러 풀 리졸버를 지정할 수 있습니다.

이 경우 설정한 순서대로 질의를 요청합니다.

Windows OS에선 네트워크 연결 -> IPv4 설정에서 지정할 수 있습니다.

2. 네임 서버가 응답하는 정보

도메인 이름, TTL, 클래스, 레코드 타입, 데이터를 응답합니다.

TTL과 클래스는 생략할 수 있습니다.

레코드 타입	내용
SOA	zone 관리에 관한 기본적인 정보
NS	zone 위임에 관한 정보
A	도메인 이름에 대한 IPv4 주소
AAAA	도메인 이름에 대한 IPv6 주소
MX	메일 전송에 관한 정보
CNAME	도메인 이름에 대한 정식 이름
TXT	임의 문자열
PTR	IP 주소에 대한 도메인 이름

[SOA 레코드]

Start of Authority, 즉 위임받은 존을 관리할 때 필요한 정보를 설정합니다.

dig naver.com soa

도메인 이름, TTL, 클래스 타입, 레코드, MNAME, RNAME, SERIAL NUMBER, REFRESH, RETRY, EXPIRE, MINIMUM 순서입니다.

클래스 타입: 현재는 IN(internet)만 사용됩니다.
MANME: 이 zone의 primary server host name입니다.
RNAME: zone 관리자의 메일입니다. RNAME의 메일 주소는 '@'를 '.'으로 변경해 설정합니다.
SERIAL NUMBER: secondary server는 자신의 번호보다 큰 번호를 갖는 zone이 있다면 존 전송을 요구해서 최신화합니다.
REFRESH: 이 시간이 지나면 자발적으로 존 데이터를 갱신합니다.
RETRY: 존 데이터 갱신 실패 시 이 시간이 지나서 다시 시도합니다.
EXPIRE: 이 시간까지 존 데이터 갱신에 실패하면 존 데이터 만료로 처리합니다.
MINIMUM: 네거티브 캐시를 보유해도 되는 시간입니다.

[NS 레코드]

위임에 관한 정보를 NS 레코드로 설정합니다.

dig naver.com ns

도메인 이름, TTL, IN, NS, 네임 서버의 호스트 이름 순서입니다.

즉, naver.com 도메인은 ns1~3.naver.com 네임 서버들에서 관리합니다.

[A 레코드]

도메인 이름에 해당하는 IP 주소 정보를 설정합니다.

dig naver.com a

[MX 레코드]

메일 주소를 사용하기 위해선 우선 순위와 함께 MX 레코드로 네임 서버에 설정해야 합니다.

dig naver.com mx

도메인 이름, TTL, IN, MX, 우선 순위, 네임 서버의 호스트 이름 순서입니다.

우선 순위 값이 낮은 메일 서버부터 순서대로 메일 전송을 시도합니다.

[CNAME 레코드]

CNAME을 사용하면 외부 서비스를 다른 이름으로 이용할 수 있습니다.

예를 들어 aws alb의 도메인인 my-alb-123456.ap-northeast-2.elb.amazonaws.com를 alb.example.com으로 사용할 수 있게 합니다.

CNAME 레코드를 확인하면, 진짜 이름인 my-alb-123456.ap-northeast-2.elb.amazonaws.com에 대해 다시 한번 이름 풀이를 합니다.

[TXT 레코드]

도메인 이름 외 임의의 텍스트를 문자 정보로 추가할 수 있습니다.

dig naver.com txt

외부 서비스와 연동할 때, 이 도메인을 컨트롤할 수 있다는 것을 인증하기 위해 특정 값을 TXT 레코드로 설정하는 용도로도 사용됩니다. 사진에 있는 naver.com의 TXT 레코드도 그런 용도로 보입니다.

[PTR 레코드]

IP 주소에 대응하는 도메인 이름을 알아낼 수 있습니다.

DNS는 역순으로 조회하기 때문에 풀 리졸버가 IP 주소 표기를 역순으로 표기한 뒤, 마지막에 '.in-addr-arpa.'를 붙입니다.

ex) 192.0.2.3 -> 3.2.0.192.in-addr-arpa.

활용 예시

스팸 메일 필터
- 메일 서버가 메일 발송 서버의 IP를 이용하여 도메인을 조회(PTR)
- 다시 그 도메인의 IP를 조회해서 일치하지 않으면 수신 측에 보내지 않음

[DNS] DNS의 등장 배경과 관리 체계

cwb111 — Mon, 4 May 2026 12:55:35 +0900

DNS 책을 읽게 되어 정리합니다.

1. DNS 등장 배경

[인터넷 초기의 DNS]

인터넷 초기에는 SRI-NIC이라는 네트워크 정보 센터에서 HOSTS 파일을 관리했다.

HOSTS.txt 파일에선 도메인 이름과 IP를 관리한다.

따라서 인터넷 접속을 등록하는 과정은 아래와 같다.

1. 클라이언트는 SRI-NIC에 인터넷 접속 신청을 함

2. SRI-NIC에서는 승인 후 신청자의 IP를 HOSTS 파일에 등록

3. HOSTS 파일을 인터넷에 게시하여 다운 받아 이용할 수 있도록 함

즉, 이 시기에는 DNS가 중앙 관리형 시스템이였다.

[DNS 분산 관리 체계]

인터넷 접속 신청이 늘어나자 HOSTS 파일 반영 시간이 지연되기 시작했다.

따라서 '계층화'와 '위임'을 통해 분산 관리 시스템으로 구조가 바뀌었다.

즉, 관리할 범위를 분할(계층화)하고, 책임을 위임하여 분산한다.

이 때, 위임에 의해 관리하는 범위를 zone이라고 한다.

위임한 네임 서버를 위임자(부모), 위임된 네임 서버를 위임처(자식)라고 한다.

각 zone의 관리자는 네임 서버를 통해 아래 정보들을 관리한다.

zone 내에 존재하는 호스트의 도메인 이름과 IP 주소
위임처(자식)의 네임 서버

위 정보들을 저장하므로 흔히 말하는 TLD부터 질의하는 DNS 재귀적 쿼리를 이해할 수 있다.

예를 들어 'example.com.'이라는 도메인의 IP를 알아내는 과정이 아래 사진과 같다.

위 이름 풀이 과정의 세부 내용은 다음 포스팅에서 다루겠습니다.

2. DNS 관리 체계

각 zone의 관리자를 '레지스트리'라고 한다.

도메인 사용을 위해선 사용할 zone의 레지스트리에 등록을 신청해야 한다.

.kr이나 .com 등의 중요한 TLD는 레지스트리·레지스트라 모델을 채택한다.

레지스트리: 각 zone의 관리자
레지스트라: 도메인 이름 신청자와 레지스트리를 중개 (예를 들어 가비아 같은 회사가 해당함)

[레지스트리의 역할]

1. 네임 서버를 운용한다.

2. 레지스트리 DB를 관리한다. 이 DB에는 도메인 이름을 등록하기 위해 필요한 이름, 조직명, 연락처 등이 저장된다.

3. Whois 서비스를 제공한다.

예를 들어 .kr 도메인의 Whois 서비스에 naver.co.kr을 조회해보면 아래 사진과 같이 도메인 등록 정보를 알 수 있습니다.

[레지스트라의 역할]

1. 도메인 등록 신청자에게 신청을 접수 받고, 레지스트리 DB에 도메인 등록을 접수한다.

2. 등록자 정보를 관리한다.

3. Whois 서비스를 제공한다.

옛날에 가비아에서 도메인을 신청한 적이 있었는데요, 신청할 때 네임 서버를 등록하는 과정이 있었습니다.

저는 네임서버를 등록하는 이유도 모르고 구글링 내용에 나온대로 AWS Route53에서 제공한 네임서버를 등록했었습니다.

그 과정이 필요한 이유를 이제야 깨달았네요 ㄷㄷ

참고로 aws 같은 클라우드 서비스를 사용하지 않을 경우엔 dns 소프트웨어를 이용하여 직접 네임 서버를 구축해야 합니다.

다음 포스팅에선 더 자세한 이름 풀이 과정과 구성 요소를 알아보겠습니다.

[서평단] SQL, 이렇게 하면 된다

cwb111 — Mon, 13 Apr 2026 21:48:58 +0900

제이펍 출판사에게 책을 제공받아 작성하는 리뷰입니다.

제가 회사에서 하는 일 중 하나는 개발자가 작성한 쿼리를 튜닝하는 것입니다.

그렇다보니 쿼리를 인덱스에 태우는 방법에만 몰두하느라 이 책의 내용들이 생소했습니다.

이 책의 대부분에선 SQL이라는 언어의 특성과 그 특성을 활용하는 방법에 대해 소개하기 때문입니다.

(물론 쿼리 튜닝에 대한 내용도 11장에 짤막하게 있습니다.)

따라서 이 책을 아래와 같은 분들에게 추천합니다. (저입니다.)

SQL 기본 문법과 인덱스 정도만 아는 사람
그 수준에서 다음 단계로 나아가고 싶은 사람

'집합론' 관점에서의 SQL

처음 SQL을 접했을 때, 프로그래밍 언어만 다루다가 SQL을 사용하니 아주 답답했습니다. 뭔지 모를 이질감이 느껴졌었는데요, 이 책을 읽고서야 그 이유를 깨달았습니다. SQL의 기초 이론 중 하나는 집합론이며, '집합 지향'으로 설계된 언어이기 때문입니다.

SQL의 토대가 되는 이론 중 하나가 집합론이기 때문에 프로그래밍 언어와는 차이점이 있었습니다.

집합 지향 언어를 절차 지향 언어처럼 다루려 했으니 당연히 이질감이 들었을 것입니다. 이 책에서는 SQL 설계 의도에 맞춰 SQL을 강력하게 다루는 방법을 설명합니다. 하지만 이런 사고 방식에 미숙해서인지.. 아직은 집합 지향적으로 다루는 게 어렵습니다. 익숙해질 때까지 반복 학습해보려 합니다.

따라서 SQL 도서이지만, 의외로 '집합과 명제'에 관한 내용이 자주 등장합니다.

SQL의 역사

IT의 세계에선 역사를 아는 것이 중요하다고 생각합니다.

이 책의 파트 2에선 RDB의 역사를 배울 수 있습니다.

SQL이 어떠한 목적으로 설계되었는지, 어떤 과정을 거쳐 현재의 SQL이 되었는지 등을 알 수 있습니다.

이런 지식들은 당장엔 도움되지 않겠지만, SQL을 보는 시야를 넓혀줄 것이라고 생각합니다.

그 외 인상 깊은 내용들

이진 논리(True, False)만 지원하는 프로그래밍 언어들과 달리, SQL에서는 unknown이라는 세 번째 진리값을 갖는다는 점

따라서 NULL을 다룰 땐 결과가 직관적이지 않다는 점

그럼에도 엔지니어라면 이런 내용을 확실히 이해해야 한다는 점

그리고 WinMagic => 윈도 함수는 서브 쿼리를 대부분 대체할 수 있다는 점

SQL을 집합처럼 다루는 방법과 윈도 함수를 더 공부해야겠습니다.

2025년 신입 SE의 회고

cwb111 — Sun, 22 Feb 2026 16:16:46 +0900

인생의 큰 체크포인트 중 하나였던 2025년을 기록하기 위해 글을 작성합니다. (곧 3월인데 이제서야????)

1. 무엇을 했나

2025년에는 인턴으로 직장 생활을 시작해서 정규직으로 전환됐다.

입사 시 나의 포지션은 SE(시스템 엔지니어)였고, 주 업무는 아래와 같다.

Kubernetes 환경 구축, 운영
CI/CD (ArgoCD, Gitlab Pipeline)
IaC (Terraform, Ansible)
Monitoring & Logging (Prometheus, Filebeat, Grafana)

뭔가 거창하게 많이 한 것 같지만..

Kubernetes는 나의 역량이 부족해서 작업의 완성도가 떨어졌다.

IaC는 팀의 필요에 맞게 커스텀한 일부를 제외하곤, 다른 팀에서 제공한 블루 프린트를 그대로 썼다.

그래서 사실 정말로 내가 한 작업은 간단한 CI/CD와 모니터링, 로깅 구성밖엔 없다고 생각한다 ~~..

2. 실무에 대해

학습과 운영의 차이

나의 쿠버네티스 역량이라곤 그래봤자 학생 때 Cluster에 워크로드 이것저것 배포해 본 게 전부다.

학생 땐 단지 배포하고, 잘 동작하는 것을 확인하기만 하면 충분하다고 생각했다.

하지만 그저 배포해 본 것과 실제로 운영하는 것에는 너무 많은 차이가 있었다.

현업에선 워크로드가 반드시 항상 살아 있어야 한다.

전제 조건이 딱 하나 생겼을 뿐인데, 이것을 위해 고려해야 할 점이 아주아주 많아진다.

워크로드가 스케줄링되는 과정을 알아야 무중단으로 배포할 수 있다.
부하 테스트를 통해 워크로드의 스케일 인/아웃 정책과 cpu/메모리 사용량의 적절값을 조정해야 한다.
위 사항들을 잘 제어해도 pod의 이미지 자체에서 메모리 누수가 생길 수 있다.

이것 외에도 학생 땐 프로메테우스, 그라파나를 배포해봤지만, cpu/memory 외엔 모니터링 해보지 않았다.

역시 배포만으론 부족하다. 실제로 클러스터를 운영할 땐 주요 모니터링 지표를 알아야 한다. 그래야 특정 장애 발생 시에 어떤 지표를 봐야 하는 지 알 수 있기 때문이다. 그리고 이것을 알기 위해선 그 지표를 봐야 하는 이유까지도 알아야 한다.

운영의 무게

팀에서 쿠버네티스 환경을 처음 사용하다보니, 쿠버네티스 전문가분이 없어서 쿠버네티스 운영에 너무 많은 부담과 책임을 많이 느꼈었다.

그런데 지금 돌이켜 보면 팀장님과 팀원분들도 고작 신입 사원에게 거창한 무언가를 바라진 않았을 듯 싶다.

초반에 팀장님께서 내게 '신입이 책임질 수 있다고 말하는 건 조금 강하게 말해 건방진 거다'라고 말씀하신 적이 있는데 이 말이 딱 맞다. 이 시기에 그냥 책임감을 갖지 말고 mz답게 이것저것 질문해 볼 걸 후회가 된다.

만약 그랬더라면.. 팀에 쿠버네티스 전문가가 없으니 문제가 직접 해결되진 않았겠지만, 이걸 표현함으로써 팀장님께서 다른 팀의 전문가에게 도움을 요청하는 등 어떤 조치를 취해주셨을 듯 싶다.

이걸 이제서야 느끼다니 ㄱ-

아 그런데 아쉽기도 하다

내가 진짜 더 열심히 했다면 쿠버네티스에 대해 A to Z 모든 것을 경험해 볼 수 있는 기회이기도 했는데.. 난 왜 더 열심히 하지 않았을까

내가 나태해진 듯

일하는 방법을 터득함

이제 어떻게 일해야 하는 지 알았다.

협업할 때: 가이드를 문서화하고 전달할 내용을 간소화하자. 혼자 생각해도 이해 안되면 물어봐서 빠르게 처리하자.

혼자 일할 때: 그 일을 효율적으로 처리하기 위해 거쳐야 할 단계를 메모하고, 각 단계를 행하자.

난 아직 일이 몸에 배지 않았으니 메모를 보고 머리를 거친 후에 일해야 한다.

3. 1년 동안 달라진 점

첫째, 서버에 대한 시야

팀에서 업무 외에 공부할 시간을 굉장히 많이 지원해 주셔서 1년 새 서버에 대한 시야가 넓어진 것이 느껴진다.

예를 들어 2024년엔 유튜브를 통해 진행한 이벤트를, 2025년엔 회사의 서버를 이용하려 하던 일이 있었다.

팀장님은 이런 상황에서 어떤 점을 고려해야 하는지 물어보셨는데.. 난 아무런 대답도 하지 못했었다.

이때가 아마 2025년 3월 쯤이였다.

2026년의 나는 이제 대답할 수 있다.

유튜브 서버로 들어오던 트래픽이 우리 서버로 들어오게 된다.

이에 따라 트래픽 관리, 인프라 구성, 서버 모니터링과 장애 조치가 우리의 부담이 된다.

인프라 구성이라는 업무 내에서도 스케일링, 부하 분산, 서버 이중화, 부하 테스트 등 다양한 작업들이 필요할 것이다.

고연차분이 이걸 보신다면 '엥? 너무 겉핥기 식인데?' 라고 말하시겠지만.. 당장 내 수준은 이 정도인 것 같다. 앞으로 더 발전해야지 뭐

둘째, 데이터베이스 (SQL Server)

운이 좋게도 팀에서 DB 서버를 다루게 되어서 나도 데이터베이스를 배울 기회가 생겼다.

데이터베이스를 다룬 경험이 거의 없다시피해서 걱정도 됐었는데 다행히 작년 4분기부터 현재까지도 디비를 잘 배우고 있다. 좀 많이 맞긴 했지만 ㅋㅋㅋㅋ

작년엔 책을 통해 인덱스, 물리 조인, 백업과 복원, 복구 모델 같은 이론적인 공부를 했고, 올해는 1월부터 DB팀 자리로 이동해서 실무를 배우고 있다. 글을 쓰는 현재는 내가 오픈 예정인 서비스에 투입됐다. (물론 나는 부 담당자고 시니어분과 함께 참여한다.)

DB 서버와 웹 서버가 무관할 것 같은데 은근 비슷한 점이 많아서 신기했다. 원래 팀에서 Windows 서버를 주로 다루는데, SQL Server를 배우면서 WSFC나 사용자 권한 관리, AD 같이 Windows 서버에 대한 지식들도 겸사겸사 배우고 있다.

올해는 시니어분의 도움 없이 나 혼자 일을 쳐낼 수 있도록 발전하고 싶다.

4. AI에 대해

AI에 대한 나의 생각을 적어보려 한다.

내 생각에 AI는 컴퓨터 조작 방법을 추상화한 계층이라고 생각한다.

예를 들어서 기계어를 추상화한 프로그래밍 언어를 통하여 하드웨어를 조작하는 것처럼
프로그래밍 언어를 추상화하여 자연어로 컴퓨터를 조작할 수 있게 하는 것이 AI 같다.

요새 바이브 코딩이랍시고 CS의 중요성을 과소평가하며 AI의 도움만으로 무엇이든 할 수 있을 거라는 글이 인터넷에 너무 많다.

AI라는 추상화 계층을 사용하더라도, 프로그래밍 언어를 사용할 때처럼 여전히 컴퓨터에 대한 이해가 필요하다.
만약 컴퓨터에 대한 이해가 없다면 프로그래밍 언어는 명확한 에러를 발생시키지만, AI는 그럴듯한 답변을 내서 환각을 일으키기 때문이다.

최근에 너무 많은 ai 관련 tool들이 생기고 있고, 당연히 그만큼 도태되는 ai tool들도 많다.

내가 현재 핫한 ai tool의 사용법을 공부하는 경우를 가정하자.

그 툴이 도태된다면?
- 내가 공부한 내용은 무용지물이 되어 버린다.
그 툴이 도태되지 않고 global winner가 된다면?
- CS 지식 없이 그것을 100% 활용할 수는 없을 거라고 생각한다.

어느 경우던 나에게 불리하다. 이게 지금 당장 CS를 공부해야 하는 이유다. 지금 공부해둔 CS 지식을 바탕으로 몇 년 뒤에 global winner가 될 ai tool을 사용하여 업무에 사용하면 해결될 문제다. ai가 너무 발전해 버렸을 때 컴퓨터 지식을 공부하려면 늦는다.

컴공 교수 버튜버 제이미님

CSE Fundamental은 영원하다

5. 되고 싶은 것

Freak

나는 괴짜가 되고 싶다

DB라는 주제만으로도 하루종일 떠들 수 있을 것 같은 DB팀의 어느 분처럼

컴퓨터와 서버에 대한 내용이라면 뭐든 알고 있을 것 같은 우리 팀장님처럼..

그리고 나도 이 편이 더 재미있다.

서버를 공부해도 어떤 기능을 동작하게 하는 커널이 궁금하고

DBMS를 공부해도 쿼리의 내용보단 데이터를 가져오는 그 내부 동작이 궁금하다.

당연히 내부 동작은 너무 복잡해서 공부해도 며칠 뒤면 다 까먹지만 ㅋㅋ 그런데도 알고싶다..

그래서 올해의 목표 중 하나는 소박하지만 Windows Internal Vol1과 Windows Server 2022 책을 다 읽는 것이다.

작년에 나는 나태했지만 올해는 회사 근처로 이사를 가기 때문에 퇴근 후에도 시간이 남을 것이다.

그래서 이룰 수 있을 목표라고 생각한다.

아 역시 글을 써야 머릿속의 중구난방으로 있던 생각들이 정리된다.

올해는 다시 블로그를 활성화하자.

올해도 파이팅 ~~

[SQL] 집계 함수는 WHERE 절에 사용할 수 없다.

cwb111 — Sun, 12 Oct 2025 13:33:00 +0900

요약: 만약 WHERE 절에서 집계 함수를 사용한다면, 집계 이후 필터링이 실행되므로 이것은 쿼리의 의도와 맞지 않게 됨

에러 예시

사원 정보가 저장된 Employee 테이블이 있습니다.

가장 최근에 입사한 사원의 정보를 예를 들어 아래처럼 쿼리합니다.

SELECT *
FROM Employee
WHERE HireDate = MAX(Hiredate)

발생하는 에러 메시지

집계가 HAVING 절이나 SELECT 목록에 포함된 하위 쿼리 내에 없으면 WHERE 절에 나타날 수 없습니다. 또한 집계 중인 열은 외부 참조입니다.

에러메시지 그대로 WHERE 절에 집계 함수를 사용했기 때문에 발생한 에러입니다.

에러 발생 원인

사실 곰곰이 생각해보면 SQL 문서까지 읽을 필요도 없었네요

WHERE 절에선 조건에 맞는 행들을 필터링합니다.
만약 WHERE 절에서 집계 함수를 사용한다면, 집계 이후 필터링이 실행되므로 이것은 쿼리의 의도와 맞지 않게 됩니다.

그래도 찾은 내용이 아까우니 함께 첨부합니다

SELECT 문이 처리되는 순서

FROM
ON
JOIN
WHERE
GROUP BY
WITH CUBE or WITH ROLLUP
HAVING
SELECT
DISTINCT
ORDER BY
TOP

What are the SQL database functions?

즉, 집계 함수는 여러 결과를 계산하여 단일 값을 반환하고, 집계 함수는 SELECT 목록에서 사용해야 합니다.

Aggregate functions perform a calculation on a set of values and return a single value. They're allowed in the select list or the HAVING clause of a SELECT statement. You can use an aggregation in combination with the GROUP BY clause to calculate the aggregation on categories of rows. ...(생략)

이 내용들을 응용해서, 부서 별 가장 최근에 입사한 사원 정보를 쿼리하려면 쿼리문을 이렇게 작성할 수 있습니다.

SELECT *
FROM Employee AS e1
WHERE e1.HireDate =  (SELECT MAX(Hiredate) From Employee AS e2 WHERE e1.DeptID = e2.DeptID)

[Network] MAC, ARP, VLAN에 대해 알아보자

cwb111 — Sun, 9 Feb 2025 20:15:02 +0900

최근에 네트워크를 이해하는 것이 중요함을 느끼고 있습니다.
low level network라고 하면 내용이 방대하지만, 기초부터 차근차근 알아가보려 합니다.
그 시작은 이번 포스팅에서 다룰 MAC, ARP, VLAN입니다.

MAC은 OSI 2계층에서 사용되고, IP는 OSI 3계층에서 사용한다는 말을 들어봤을 것입니다.
이 말은 즉 IP는 네트워크 대역을 찾는 데 사용되며, MAC 주소는 그 네트워크 대역 내의 정확한 위치를 식별하는 데 사용된다는 의미입니다.

우선 이런 느낌으로 이해하면 됩니다.
이 그림에 대한 내용은 이 포스팅에서 점차 설명하겠습니다.

1. Mac address

MAC address는 Layer 2에서 통신하기 위한 네트워크 인터페이스의 고유 식별자입니다.
- 주로 NIC에 할당되며, 가상 네트워크의 경우 소프트웨어에 할당되기도 합니다.
- MAC address는 XX:XX:XX:XX:XX:XX 꼴의 16진수로 표현됩니다.
- (참고: IP 또한 NIC에 할당됩니다.)
L2 스위치는 동일한 네트워크(LAN) 내에서 MAC 주소를 기반으로 프레임을 전달합니다.
- 위 그림의 경우, 10.0.1.0/24와 10.0.2.0/24가 LAN에 해당합니다.
따라서, L2에서 정확한 위치로 데이터를 전송하기 위해 MAC 주소가 필요합니다.
- OSI 7 Layer 모델에서는 통신 시 데이터 캡슐화와 역캡슐화 과정을 거칩니다.
- 따라서 대부분의 네트워크 환경에서 L2 통신이 필요합니다.

위 내용을 통해 데이터 통신을 위해 MAC 주소가 필요하다는 사실을 확인했습니다.
그러면 목적지의 MAC 주소는 어떻게 알아낼 수 있을까요?

2. ARP

MAC 주소를 알아내기 위해서 ARP 프로토콜을 사용합니다
ARP 프로토콜을 사용하면 IP를 기반으로 MAC 주소를 알아낼 수 있습니다.
ARP는, LAN 내의 모든 호스트에게 브로드캐스트 요청을 보냅니다.
- 목적지 IP를 이미 알고 있으므로, 이 IP를 가진 호스트만이 MAC 주소를 응답합니다.

예를 들어 아래 그림을 다시 보겠습니다.
10.0.1.0/24의 PC 1이 10.0.2.0/24의 PC2로 데이터를 전송하는 상황입니다.

PC 1은, 목적지 IP가 자신의 네트워크 대역과 다름을 인지합니다.
(참고로, DNS 질의 등을 통해 PC2의 IP를 알아냅니다.)
따라서 PC 1은 자신의 LAN인 10.0.1.0/24에 브로드캐스트로 Router의 MAC 주소를 반환 받습니다. (ARP)
Router는 이제 10.0.2.0/24 대역에 브로드캐스트 요청을 통해 PC2의 Mac 주소를 반환 받습니다. (ARP)
이제 Router는 목적지의 IP와 Mac을 알았습니다. 이 내용이 담긴 데이터를 해당 대역의 케이블로 데이터를 내보냅니다.
이 케이블은 Switch로 이어지며, Switch는 MAC을 기반으로 PC2에 데이터를 포워딩합니다.

굳이 Switch를 거치는 이유는 라우터의 부하 분산과 포트 확장의 목적 때문입니다.

여기서 궁금증이 생깁니다.

게이트웨이(라우터)는 서로 다른 네트워크들의 인터페이스이기 때문에 아주 많은 네트워크 장치가 연결되어 있을 것입니다.
그렇다면 이 게이트웨이에서 브로드캐스트 요청을 실행 시 당연히 과부하가 오겠죠. 이 문제를 어떻게 해결할까요?
ARP Cache 등의 많은 대비책들이 있지만, 그중 하나는 VLAN입니다.

3. VLAN (Virtual LAN)

이름에서 유추할 수 있듯, VLAN은 가상의 LAN을 형성하는 기술입니다.
위키 백과에서는 VLAN을 이렇게 설명합니다.

컴퓨터 네트워크에서 여러 개의 구별되는 브로드캐스트 도메인을 만들기 위해 단일 2계층 네트워크를 분할할 수 있는데, ...

여기서 브로드캐스트 도메인이란 브로드캐스트가 닿는 범위를 말합니다.
즉, VLAN을 사용해 브로드캐스트를 요청할 수 있는 범위를 제한할 수 있습니다.
따라서 게이트웨이(라우터 or L3 스위치)의 과부하 문제가 해결됩니다.
라우터에 PC만 연결되는 것은 아니지만.. 아래 그림과 같은 느낌입니다.
평소라면 라우터가 브로드캐스트 요청 시 6개의 요청을 보내야 하지만, 아래 그림과 같이 구성할 경우, 각 VLAN 별로 2개의 요청만 보내도 됩니다.

VLAN의 원리

저는 이 VLAN을 보고 두 가지 궁금증이 생겼습니다.

1. VLAN을 어떻게 구현할까요?

저는 실제로 서버 스위치를 본 적도, 다뤄본 적도 없어서 확실치 않지만
Cisco의 문서들을 참고하면 다음과 같은 순서로 구현할 수 있다고 설명합니다.

CLI 액세스 공식 문서 문서에 따라 케이블을 이용하여 스위치와 pc를 연결 후 PUTTY로 CLI 접근
VLAN 포트 구성 문서 문서에 따라 VLAN 구성

2. 물리 장비는 VLAN을 어떻게 구분하는 걸까요?

저보다 훨씬 설명을 잘해주신 블로그를 참조했습니다.

이 질문을 해결하기 위해서 Trunk Port를 이해해야 합니다.

Trunk 포트란

여러 VLAN들의 트래픽을 하나의 포트를 통해 이동시킬 수 있는 포트입니다.
(참고: 만약 하나의 VLAN만을 사용하는 경우 Access Port라고 합니다.)
아래 사진처럼 Trunk 포트 적용 이전에는 VLAN의 개수만큼 포트가 추가로 필요했지만, Trunk 포트 사용 시 하나의 포트만으로도 여러 VLAN의 트래픽을 전송할 수 있습니다.

Trunk Port 사용 전/후

만약 Trunk Port를 사용할 경우, 하나의 포트만으로 여러 VLAN을 구분해야 합니다.
또한 OSI Layer 2에선 IP를 확인할 수 없으므로, 프레임 수준에서 VLAN을 구분해야 합니다.
이 때 IEEE 802.1Q 표준을 사용합니다.

IEEE 802.1Q는 하나의 이더넷 네트워크에서 가상 랜(VLAN)을 지원하는 네트워크 표준입니다.

출처 https://ko.wikipedia.org/wiki/IEEE_802.1Q

사진을 보면 이더넷 프레임(상단)에 802.1Q Header라는 헤더를 삽입합니다(하단).
이 중 12비트의 VID 필드를 통해 VLAN을 구분할 수 있습니다.
Access Port의 경우 대부분 802.1Q Header를 사용하지 않지만, 항상 그런 것은 아닙니다.

많은 자료를 찾아가며 정리한 내용이지만 혹시 잘못된 내용이 있을 경우 댓글로 지적 부탁드립니다.
감사합니다!

비사이드 프로젝트 후기와 실패 회고

cwb111 — Tue, 31 Dec 2024 21:27:16 +0900

최근 비사이드 포텐데이 412에 참여하여 프로젝트를 진행했습니다.
결론부터 말씀드리면 저는 프로젝트에 실패했습니다.
이 포스팅에선 비사이드 포텐데이에 대해 소개하고, 제가 실패한 이유를 돌아볼 것입니다.

1. 비사이드 포텐데이란?

참여자들이 팀을 구성해서 10일 동안 서비스를 만드는 온라인 해커톤입니다.
참여 분야는 기획, 디자인, 개발 세 종류이며, 자발적으로 팀을 구성합니다. 팀이 구성되지 않으면 비사이드에서 임의로 팀을 구성해 줍니다.
저는 DevOps 개발자로 참여했습니다.
참여비는 10만 원입니다. (얼리버드 신청 시 30% 할인)

2. 왜 비사이드에 참여했나?

저는 2024년 8월에 대학교를 졸업한 이후 Udemy의 강의와 여러 서적들을 통해 이론적 지식들을 공부했습니다.
그래서 저에겐 실무와 프로젝트 경험이 부족합니다.
당연히 이론과 실무에는 차이가 존재할 것이라고 생각했고, 이 생각이 제가 프로젝트를 시작한 계기가 되었습니다.

팀 프로젝트를 찾기 위해 구글링 해보니 렛플, 홀라, 인프런 등 많은 프로젝트 구인 플랫폼들이 있었습니다.
저는 이 모든 플랫폼들의 게시글을 확인했고, 프로젝트의 대부분이 클라우드 엔지니어나 데브옵스 포지션을 원하지 않았습니다.

주업무가 개발보단 운영이 더 가까운 저의 포지션은 사이드 프로젝트에서 환영받지 못 했습니다.

아마 사이드 프로젝트의 목적은 서비스 운영이 아닌, 서비스 개발이기 때문인 듯싶습니다.

그래서 저는 비사이드에 참여하게 됩니다. 그 이유는 두 가지입니다.

다른 구인 플랫폼들에서는 원하지 않는 DevOps 포지션으로 프로젝트에 참여할 수 있기 때문입니다.
디자이너, 기획자, 개발자들의 협업 경험을 얻을 수 있기 때문입니다.

참가비가 10만 원이지만, 이 두 가지 이유로 10만 원을 사용할 가치가 있다고 생각했습니다.

3. 프로젝트 진행 과정

2024.12.02(월) 13시 ~ 2024.12.05(목) 09시 : 자체 팀 빌딩 (빌딩 실패 시 비사이드에서 팀 임의 배정)
2024.12.06(금) ~ 2024.12.15(일) 15시: 프로젝트 진행
2024.12.15(일) 15시: 프로젝트 마감

3-1 팀 빌딩하기

참여자들은 Slack 채널에 초대되고, 이곳에서 자기 소개를 합니다.
각자의 소개를 확인하고 마음에 드는 사람들과 팀을 구성합니다.

이런 식입니다. (저의 소개)

자기 소개 글을 게시했고 2시간 정도 기다려봤지만 아무런 연락도 오지 않았습니다.
아마 다들 저처럼 먼저 연락하지 않고 기다리기만 한 듯싶습니다.
그래서 저는 제가 직접 나서서 사람들에게 연락을 보내서 팀을 구성하기로 합니다. 그 이유는 두 가지입니다.

프로젝트를 주도해보고 싶은 욕심: 이전 프로젝트에서 너무 팀장을 따라가기만 했기 때문에 이번엔 제가 주도해보고 싶었습니다. 상반된 두 경험을 겪으며 뭔가 얻을 게 있을 것이라고 생각했습니다.
팀을 구성할 수 없을 것 같다는 불안감: DevOps는 개발 자체를 담당하진 않기 때문에 팀이 구성되지 않을 위험이 있다고 생각했습니다.

그렇게 첫 날의 밤 12시까지 총 열 한분께 메시지를 드렸고, 6인의 팀을 구성하는 데 성공합니다.
팀 구성은 이렇습니다: 기획자 1, 디자이너 2, 백엔드1, 프론트엔드 1, DevOps(본인) 1

제가 팀원을 모집한 유일한 기준은 다음과 같습니다.

'당장의 실력이 없더라도 프로젝트에 참여할 시간이 많을 것'

실력이 부족해도 열정과 시간만 있다면 충분히 서비스를 만들 수 있을 것이라고 생각했습니다.
그래서 저희 팀원은 모두 취준생으로 구성했으며, 모든 인원이 선약을 제외하고 10일 간 모든 시간을 프로젝트에 사용할 수 있었습니다.
하지만 돌이켜 보면 이것이 실패 원인 중 하나가 됐습니다. 이에 대한 내용은 '4. 실패 원인'에서 계속됩니다.

프로젝트 정식 시작 기간은 2024.12.06(금)부터지만 저희 팀은 팀을 빠르게 구성했기 때문에 2024.12.04(수)부터 회의를 시작할 수 있었습니다.

3-2. 아이디어 내기

어떤 서비스를 만들 지 회의하는 데 이틀이 걸렸습니다.
첫 날엔 여러 아이디어를 냈고, 기술적 실현 가능성과 경쟁력 등을 고려해서 아이디어를 간추렸습니다.
저희 서비스에선 Azure의 Computer vision(이미지 분석)을 이용하려고 했기 때문에 둘째 날엔 Azure를 공부했고 Computer vision의 성능을 테스트했습니다.

3-3 프로젝트 진행

저는 AWS, 쿠버네티스와 gitOps, 모니터링 환경 구축, CI/CD 파이프라인 구축을 목적으로 프로젝트에 참여했습니다.
하지만 AWS 작업 외 목적을 달성하지 못하고, 대부분의 시간을 백엔드 트러블 슈팅에 사용하게 됩니다. 이 이유는 '4. 실패 원인'에서 계속됩니다.

프로젝트 마감일 당일에는 밤을 새우며 23시간 동안 백엔드 api가 정상 동작하는 지 확인하고, 에러가 발생하면 그 에러를 해결했습니다.
하지만 마감 시간 이전에 모든 에러를 해결하진 못 했습니다.
백엔드 뿐만 아니라 프론트엔드도 완성되지 않았습니다.

4. 실패 원인

프로젝트 마감에 실패한 이유를 생각해봤습니다.

4-1. 일정 변동

저는 원래 계획에선 프로젝트 기간 동안 10일 모두 프로젝트에 사용하려고 했습니다.
하지만 예상에 없던 면접 일정으로 인해 이틀을 허비했습니다.

A 기업의 면접은 원래 프로젝트 기간 이전에 예정되어 있었습니다. 하지만 하필 면접일에 계엄령으로 인해 전사 재택 근무가 시행되어서 면접일이 프로젝트 기간 중으로 밀렸습니다.
B 기업에선 서류 합격 발표와 동시에 4일 뒤에 갑자기 면접을 보러 오라고 해서 갑작스럽게 또 하루를 면접 준비에 사용하게 됐습니다.

결국 저는 면접과 프로젝트 두 마리 토끼를 모두 잡으려다 모두 놓치게 됐습니다. (운이 좋게도 A 기업엔 최종 합격해서 1월에 입사가 예정되어 있습니다!)

4-2. 잘못된 팀원 선택 기준

제가 팀원을 고르는 기준으로 열정만을 확인했던 것이 패착입니다.
비사이드 포텐데이는 10일이라는 짧은 기간에 기획, 디자인, 개발을 모두 해야 합니다.
기획이 돼야 백엔드와 디자인을 할 수 있고, 디자인이 돼야 프론트를 개발할 수 있습니다. 따라서 실제 개발할 수 있는 기간은 10일 보다 훨씬 짧습니다. 따라서 기본적인 개발 실력이 뒷받침되어 있어야 합니다. 제가 이 사실을 간과했습니다.

저희 팀의 프론트엔드, 백엔드 개발자분들은 실력이 썩 좋아 보이진 않았습니다. (git과 대화 수준을 미루어 보아 짐작)
두 분은 공통적으로 디버깅을 할 줄 몰랐습니다. 그래서 저의 도움 없이는 해결 할 수 없던 에러들이 꽤 있었습니다.

남탓만 백날 해봐야.. 문제를 해결할 수 없죠

제가 직접 디버깅에 참여하기 위해서 저희 프로젝트의 백엔드 프레임워크인 Django의 기초를 공부했습니다.

파이썬을 쓸 줄 아니까 Django의 url, view, model, serializer 정도의 핵심 개념들만요.

이렇게 해서 드디어 디버깅할 수 있는 환경이 갖춰졌습니다. 하지만 저는 장고를 모르고, 백엔드 개발자님은 파이썬을 모르니 디버깅 과정이 다음과 같이 비효율적이여서 시간이 굉장히 오래 걸렸습니다.

백엔드가 장고 코드를 실행
에러 발생 시 결과를 저에게 전송
제가 그 내용을 토대로 디버깅
코드 수정 사항을 백엔드에게 전송
백엔드가 코드를 수정, 이후 1번부터 반복

프론트 엔드 개발자분 또한 의사소통이 힘들었습니다. 프론트에서 에러가 발생하면 '어떤 에러가 발생했다'만 알려주고, 상세 에러 내용과 에러 발생 위치를 알려주지 않아서 디버깅을 하기 위해 세부 내용을 되묻는 과정이 필요했습니다. 카카오톡을 통해 소통했기 때문에 이 과정에는 많은 시간이 소요됐습니다.

AWS 오픈 채팅방의 비슷한 상황

예를 들어서 CORS 에러 발생 시 그 원인은 오리진이 될 수도 있고, 헤더나 메소드가 될 수도 있고, 프론트의 코드가 될 수도 있고, 이번 프로젝트의 경우엔 'redirect is not allowed'라는 에러 메시지도 있었습니다. CORS의 원인이 이렇게 다양할 수 있는데 CORS라고만 얘기하면 디버깅을 할 수가 없습니다.

하지만 개발자 두 분 모두 열정적으로 참여하고 협조해주신 점은 감사하게 생각하고 있습니다.

10만 원을 지불하고 프로젝트에 참여하는 사람들이라서 프로젝트 마감 기한은 12/15지만, 글을 작성하고 있는 12/31까지도 꾸준히 개발하고 있습니다.

5. 어떻게 해야 했을까?

저는 제가 프로젝트에서 사용하고 싶던 kubernetes, gitOps, fluentbit를 포기하고 운영보단 프로젝트 개발에 기여했습니다.

또한 면접으로 인해 프로젝트에 사용하지 못 한 시간은 잠을 줄여 프로젝트에 사용했습니다.

그래서 저는 제가 처한 상황에서 최선의 행동을 했다고 생각합니다.

그럼에도 후회스러운 일이 하나 있는데, 회의를 진행하지 않은 것입니다.
프로젝트 시작 당일에 저는 '하루나 이틀에 한 번씩은 디스코드에서 회의를 통해 서로의 진행 상황을 공유하자'고 했지만 팀원들은 번거로울 것 같다며 노션을 통해서만 공유하자고 했습니다.

다수결이니 어쩔 수 없이 그 의견에 따랐지만, 저는 회의를 하자고 설득했어야 했습니다.

텍스트를 통해 전달할 수 있는 메시지는 한정적입니다.

예를 들어서 개발자들은 디자이너분들이 노션에 적은 작업들 중 하나인 '핸드오프'가 무엇인지, 또 기간이 얼마나 걸리는 작업인지 알 수 없습니다.

이것은 디자이너분들 입장에서도 개발 작업을 확인할 때 마찬가지일 것입니다.

만약 회의를 진행하며 서로의 진행 상황을 즉각적으로 공유했다면 서로가 얼마나 서둘러야 했을 지 알게 될 것이고, 다른 팀원의 부족한 점을 어떻게 도울 수 있을 지 생각할 수 있었을 것입니다.

6. 이 경험에서 알게 된 점

6-1. 의사 소통은 정말 중요하다

현업자분들의 인터뷰를 보면 같이 일하고 싶은 동료로 항상 '의사소통이 잘 되는 동료'를 꼽았습니다.

그리고 전 이번 경험에서 그 이유를 깨달았습니다.

기획자님과는 의사소통이 정말 잘 됐습니다.

저와 기획자님 모두 조금이라도 이해가 안 된 내용이 있다면 서로 즉각 물어봄으로써 명확하게 서로의 이해도를 공유했습니다.

이로 인해 할 일이 명확해졌으니 저도 빠르게 저의 일을 처리할 수 있었고, 기획자님도 의도한 대로 일을 맡길 수 있었습니다.

이해가 안 되는 점이 있다면 이해가 될 때까지 물어보는 행동이, 번거로워 보여도 오히려 가장 효율적으로 목표를 달성할 수 있는 방법임을 알았습니다.

반대로 상술했듯 개발자분들과는 의사소통이 힘들었습니다.

특히 한 분은 부모님 핑계를 대며 디스코드에 참여하지 않았습니다.

그래서 그분은 채팅을 통해 소통했고, 함께 디버깅을 할 땐 저의 시선을 채팅창에 고정해야 했기 때문에 터미널 보랴, 채팅창 보랴 고생이 많았습니다.

6-2. 절대 도구에 의존하지 말자

백엔드 개발자분을 보며 느꼈습니다.

그분은 ssh, scp 명령 대신 mobaxterm을 사용했고, curl 명령 대신 postman을 사용하는 등 GUI 도구에 의존했습니다.

따라서 그분은 mobaxterm을 통해 자신이 ssh 연결 동작을 수행하고 있음을 알지 못합니다.

GUI 도구는 분명히 편리한 점이 있습니다.

하지만 그것을 사용할 땐 적어도 자신이 어떤 동작을 하고 있는지는 알아야 한다고 생각합니다.

마치 생성형 AI의 코드를 그대로 사용하지 않고, 그 코드가 어떤 동작을 하는지 알아야 하는 것처럼요.

이것으로 2024년의 마지막 포스팅을 마칩니다.

내년에는 더 발전한 제가 되길 기대합니다.

다들 새해 복 많이 받으세요!!

[AWS] Cloud Watch: Amazon SNS + Lambda vs Lambda 단독 호출 비교

cwb111 — Tue, 24 Dec 2024 18:50:21 +0900

1. 서론

저는 현재 Cloud Watch를 이용해 AWS 리소스 모니터링 환경을 구성하고 있습니다.

아래 그림은 제가 구성하려는 모니터링 아키텍처입니다.

AWS의 리소스들을 CloudWatch로 모니터링하고, 임계치가 넘으면 Cloud Watch 알람을 생성하며 이는 Amazon SNS에 게시됩니다. SNS에 주제가 게시되면 이를 구독하는 Lambda가 트리거되고, Lambda는 Slack을 통해 개발자에게 알림을 주는 구조입니다.

이렇게 구성한 이유는 이전에 AWS SAA 시험과 Cloud Watch 워크숍을 진행하며 Cloud Watch → Amazon SNS → Lambda 구조를 당연하게 생각했기 때문입니다.

이 아키텍처를 구성하던 중 CloudWatch 설정에서 아래 내용을 발견했습니다.

알림 메뉴에선 SNS에 Cloud Watch 경보를 게시할 Amazon SNS 주제를 선택할 수 있고, Lambda에선 Cloud Watch 경보 발생 시 호출할 Lambda 함수를 선택할 수 있습니다.

즉 제가 구상한 아키텍처에선 Cloud Watch → SNS → Lambda 순서지만, 굳이 SNS를 끼지 않아도 Cloud Watch → Lambda로 아키텍처를 간소화할 수 있습니다.

이번 포스팅에선 이 두 가지 경우를 비교해 보겠습니다: Cloud Watch → SNS → Lambda, Cloud Watch → Lambda

2. Amazon SNS features and capabilities

Amazon SNS를 사용하지 않는 경우의 장점은 당연히 아키텍처와 운영 복잡도를 간소화할 수 있다는 점일 것입니다.

그렇다면 Amazon SNS를 사용하는 경우, 장점이 무엇일까요? 이를 알아보기 위해 우선 Amazon SNS의 특징과 capabilities를 알아보겠습니다.

(참고 문서: https://docs.aws.amazon.com/sns/latest/dg/welcome-features.html)

Amazon SNS offers a comprehensive set of features designed to enhance messaging between applications and users. These features enable seamless communication, secure message delivery, and robust message management, ensuring high availability, durability, and flexibility for a wide range of messaging use cases.

위 AWS 문서의 설명을 참고했을 때, SNS는 여러 엔드포인트에 대해 고가용성, 내구성, 유연함을 보장하며 application과 user 간 매끄럽고 안전한 통신을 가능하게 합니다.

저는 '여러 엔드포인트'와 '고가용성'에 집중했습니다.

왜냐하면 이 기능들은 Amazon SNS를 거치지 않는 Cloud Watch → Lambda 구조에서는 취할 수 없는 Amazon SNS만의 장점이기 때문입니다.

Amazon SNS endpoints

여기서 엔트포인트란 다음과 같습니다.

애플리케이션 간 메시징
- Amazon Data Firehose, Lambda Functions, Amazon SQS 등
애플리케이션 - 사람 간 알림
- 모바일 휴대폰 전화번호, 모바일 애플리케이션, 이메일 주소 등

따라서 Amazon SNS를 사용하면 Lambda 외 많은 앤드포인트들과 아키텍처를 통합할 수 있습니다.

Amazon SNS delivery retry policy

메시지의 고가용성은 'delivery retry policy'를 통해 보장합니다.

(참고 문서: https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html)

Amazon SNS defines a delivery policy for each delivery protocol. The delivery policy defines how Amazon SNS retries the delivery of messages when server-side errors occur (when the system that hosts the subscribed endpoint becomes unavailable).

위 문서를 확인하면 Delivery policy stage가 있습니다.

Amazon SNS가 메시지 전송을 실패했을 때 어떤 단계로 메시지 재전송을 처리할 지 나타냅니다.

https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html

1단계: Immediate Retry Phase (No Delay) – 전송 시도 이후 즉시 발생합니다. 재시도 간 딜레이가 없습니다.

2단계: Pre-Backoff Phase – 1단계 이후 발생합니다. SNS는 이 단계를 backoff function을 적용하기 전에 시도하는 일련의 재시도(set of retries)로 사용합니다. 재시도할 횟수와 재시도 간의 딜레이를 설정합니다.

3단계: Backoff Phase – 이 단계에선 retry-backoff function을 사용해서 재시도 간 딜레이를 제어합니다. 최소 지연, 최대 지연, 그리고 지연이 최소 지연에서 최대 지연으로 얼마나 빠르게 증가하는지를 정의하는 retry-backoff function을. 설정합니다. 이 함수는 산수(arithmetic) 함수, 지수(exponential) 함수, 기하(geomtetric) 함수, 또는 선형(linear) 함수일 수 있습니다.

4단계: Post-Backoff Phase – 3단계 이후 발생합니다. 재시도 횟수와 재시도 간 딜레이를 설정합니다. 4단계가 마지막 단계입니다.

각 단계에 대해 재시도를 어떻게 시도할 지는 위 문서의 표에 자세히 기술되어 있습니다.

https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html

표를 확인해 보면 Lamba와 같은 AWS 관리형 서비스는 총 100,015번의 재시도를 요청합니다.

특히 Post-backoff phase에서 20초 딜레이로 100,000만 번의 전송을 요청하기 때문에 재전송은 최대 23일 동안 유지됩니다.

AWS 관리 엔드포인트, Customer 관리 엔드포인트와 다르게 HTTP 엔드포인트의 경우 JSON을 각 단계의 재시도 횟수, 딜레이 등을 직접 지정할 수 있습니다. 이 문서를 참고해주세요.

CloudWatch와 Lambda를 바로 통합하면 Lambda를 한 번만 트리거합니다. 따라서 만약 트리거에 실패할 경우

3. 최종 선택

Amazon SNS를 사용할 경우 장점과 단점은 다음과 같습니다.

장점: 여러 엔드포인트 사용 가능, 고가용성의 알람 전송
단점: (SNS를 사용하지 않는 경우보다) 관리할 게 하나 늘어남

저는 최종적으로 Amazon SNS를 사용하여 Cloud Watch → Amazon SNS → Lambda 구조를 채택했습니다.

그 이유는 다음과 같습니다.

당장은 Lambda만 사용하므로 여러 엔드포인트를 사용하진 않지만, 아키텍처는 요구사항 에따라 언제든 바뀔 수 있습니다. 따라서 확장성이 좋은 SNS를 사용하는 것이 유리합니다.
고가용성의 알람 전송: Amazon SNS를 사용하면 23일 동안 10만 번의 재시도를 합니다. SNS를 사용하지 않을 경우 재시도는 두 번만 발생하는 것을 고려했을 때 가용성의 차이는 아주 큽니다.
(참고 문서: "Lambda retries function errors twice.", https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
큰 장점에 비해 아주 작은 단점: Amazon SNS를 사용할 경우 위의 확장성과 고가용성을 확보할 수 있습니다. Amazon SNS는 완전 관리형 서비스이기 때문에 관리가 거의 필요하지 않으며, 요금도 요청 100만 건 당 0.5 달러로, 아주 저렴합니다.

[AWS] NAT Instance로 AWS 요금을 줄여보자

cwb111 — Thu, 19 Dec 2024 22:51:20 +0900

이 포스팅에선 최근 진행한 프로젝트에 NAT Instance를 도입한 과정을 작성했습니다.

1. NAT Instance 도입 배경

최근 프로젝트를 진행하며 AWS에 서비스를 배포했습니다.

프로젝트에서 알게 된 사실 중 하나는 NAT Gateway의 사용료가 꽤 비싸다는 점입니다.

NAT Gateway의 사용료는 시간 당 $0.059이기 때문에 한 달 내내 사용 시 약 $42.5가 부과됩니다. (+ 트래픽에 따른 비용 청구)

이는 1달러 당 1451원인 현재 환율로 약 61,600원이기 때문에 꽤 부담되는 금액입니다.

저 또한 과거에 테라폼을 공부하며 필요할 때만 사용했는데도 NAT에 30달러를 지불한 경험이 있습니다..

서비스는 중단되어선 안 되며, 보안을 위해 Private subnet을 반드시 사용해야 합니다. 따라서 Piravte subnet에서 인터넷으로 트래픽을 전달할 수단 또한 반드시 필요합니다.

저는 NAT Gateway의 비용 최적화 방안을 찾아봤고, 그 결과 저희 서비스에 NAT Instance를 사용할 수 있겠다고 생각했습니다.

2. NAT Gateway vs NAT Instance

이 내용은 아래 AWS 문서에 굉장히 자세히 정리되어 있습니다. 따라서 주요 차이점만을 작성하겠습니다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-comparison.html

NAT 게이트웨이 및 NAT 인스턴스 비교 - Amazon Virtual Private Cloud

NAT 게이트웨이 및 NAT 인스턴스 비교 NAT 인스턴스와 NAT 게이트웨이의 차이점을 세부적으로 요약하면 다음과 같습니다. NAT 게이트웨이는 더 나은 가용성과 대역폭을 제공하고 관리에 소요되는 작

docs.aws.amazon.com

주요 차이점

NAT Gateway: 고가용성이며, AWS 관리형 인스턴스입니다. 최대 100Gbps 대역폭까지 확장합니다.

NAT Instance: 스크립트로 장애를 조치해야 하며, 사용자가 유지관리해야 합니다. EC2로 구현하기 때문에 EC2 인스턴스의 사용료를 지불합니다. 또한 bastion으로 사용이 가능합니다.

AWS에선 NAT Gateway 사용을 권장하므로 2023년 12월 31일에 NAT AMI 유지관리 지원을 종료했습니다. (관련 문서)

따라서 NAT Instance를 사용하기 위해선 자체 관리형의 NAT AMI가 필요합니다. 제 경우 NAT Instance가 하나만 필요해서 AMI까지 만들진 않았습니다.

저의 프로젝트의 경우 적은 수의 사용자가 예상되므로 높은 수준의 가용성과 대역폭은 필요하지 않습니다. 오히려 트러블 슈팅 경험을 위해 서버가 다운되길 바랍니다.

또한 가난한 취업 준비생 6명이서 진행한 프로젝트이기 때문에 비용을 최우선으로 고려해서 아키텍처를 설계해야 합니다.

그래서 NAT Gateway보단 NAT Instance가 적합하다고 생각했습니다.

3. NAT Instance 구성하기

3-1. EC2 인스턴스 생성

먼저 NAT Instaance로서 동작할 ec2 인스턴스를 생성합니다.

인터넷으로 패킷을 전달해야 하니 당연히 Public Subnet에 생성해야 하며, Private subnet에서 들어오는 트래픽을 허용해야 합니다.

3-2. 패킷 포워딩 활성화

NAT Instance Flow Chart (https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_NAT_Instance.html)

위 사진처럼 NAT Instance는 Private subnet의 패킷을 Internet Gateway로 전달하는 역할을 합니다. 이러한 동작을 패킷 포워딩이라고 합니다. 패킷 포워딩 기능은 기본적으로 비활성화 되어 있으므로 이를 활성화해야 합니다.

/proc/sys/net/ipv4/ip_forward 파일을 확인하면 0으로 설정되어 있을 것입니다.

이 파일의 내용이 0이면 패킷 포워딩을 비활성화, 1이면 활성화합니다.

/etc/sysctl.conf 파일에서아래 net.ipv4.ip_forward=1 부분을 주석 해제합니다.

/etc/sysctl.conf 파일은 리눅스에서 커널 관련 설정을 정의한 파일입니다.

그리고 sudo sysctl -p 명령을 실행합니다.

이 명령은 /etc/sysctl.conf의 내용을 영구적으로 저장합니다.

3-3. 마스커레이드 활성화

마스커레이드는 네트워크 내부의 IP들을 네트워크 외부의 공인 IP로 변환하는 기술입니다. 즉, NAT Gateway와 같은 역할을 합니다.

우선 ip link show 명령으로 인스턴스의 네트워크 인터페이스를 확인합니다.

제 경우 lo와 enX0을 응답합니다.

1: lo는 루프백을 의미하며, 자기 자신과 통신하기 위한 네트워크 인터페이스입니다. 대표적으로 로컬호스트의 ip인 127.0.0.1이 루프백 인터페이스의 ip 주소입니다.

2: enX0은 외부 네트워크와 통신하기 위한 네트워크 인터페이스입니다.

사실 저도 구글링을 해서 알아낸 내용이고, 이 응답 내용만 보고 어떤 역할을 하는 지 구분하는 건 아직 어렵네요..

아무튼, 네트워크 인터페이스를 확인했으니 iptables 명령으로 이 인터페이스에 대한 마스커레이드 규칙을 추가합니다.

sudo iptables -t nat -A POSTROUTING -o enX0 -j MASQUERADE

-t nat: NAT 라우팅 테이블에 적용합니다. (nat 외 mangle, filter 등의 테이블도 있습니다.)

-A POSTROUTING: post routing 체인에 새 규칙을 추가합니다. post routinig 체인은 네트워크 인터페이스를 나간 직후에 적용됩니다. 네트워크 내부의 IP를 인터페이스를 거친 후 외부 IP로 변환해야 하기 때문입니다.

-o enX0: 이 규칙을 어떤 인터페이스에서 나가는 패킷에 적용할 지 지정합니다. 외부 네트워크로 나가는 인터페이스는 enX0임을 확인했으니 이 인터페이스를 지정합니다.

-j MASQUERADE: 마스커레이드 동작을 수행하라고 지정합니다.

이제 sudo iptables -t nat -L 명령을 통해 테이블 내용을 리스트로 출력합니다.

POSTROUTING에 마스커레이드 규칙이 추가된 것을 확인했다면 iptables-save 명령으로 저장합니다.

4. 소스/대상 확인 비활성화

각각의 EC2 인스턴스는 기본적으로 원본/대상 확인을 수행합니다. 즉, 인스턴스 자기 자신으로부터 나가거나(원본) 자기 자신에게 온(대상) 패킷만을 처리합니다.

하지만 NAT 인스턴스는 자신의 대상이 아니므로 이런 동작을 비활성화해야 합니다.

참고 문서: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/work-with-nat-instances.html#EIP_Disable_SrcDestCheck

AWS 콘솔에서 NAT 인스턴스를 선택 후 작업 -> 네트워킹 -> 소스/대상 확인 변경을 클릭합니다.

중지를 누른 후 저장합니다.

이제 NAT Instance의 설정을 마쳤습니다.

마지막으로 Private subnet의 라우팅 테이블에서 기존 NAT Gateway를 향하던 라우팅 규칙을 NAT Instance로 향하게 해줍시다.

Piravte subnet 내 인스턴스에서 성공적으로 인터넷에 ping 명령이 가능합니다.

혹시 public과 private 간 ping이 안 된다면 보안 그룹의 인바운드에서 ICMP를 허용했는지, 서로의 서브넷에서 온 트래픽을 허용했는지 점검해 보시길 바랍니다.

저는 현재 프리 티어 계정을 사용 중이고, NAT Instance로 t2.micro 유형의 인스턴스를 사용했으니 nat instance의 유지비는 없습니다.

제가 매달 저희 팀의 61,000원을 아껴주었습니다 ㅎㅎ 기분이 좋네요

AWS SAA 시험을 공부할 때 NAT Instance는 depreacted 되었기 때문에 무작정 안 좋다고만 나와서 저도 부정적으로 생각했는데 NAT Instance가 더 좋은 경우도 있군요.

역시 이론과 실무는 다른 듯싶습니다.

참고 블로그: 마스커레이드 설정 시 네트워크 인터페이스로 eth0을 사용한다는 점 외에 저의 내용과 같습니다.

https://coding-groot.tistory.com/169

[AWS] VPC의 NAT 비용을 줄여보자 :: Ubuntu로 NAT 인스턴스 만들기

두 배가 되어버린 AWS 비용.. 1달 전에는 테스트용으로 그냥 Public IP로 다 통신하도록 하고 최저 사양으로 다 올렸었다. 하지만 보안이나 비용적인 측면, 나중에 할 부하 테스트를 생각해서 Amazon EC

coding-groot.tistory.com

첫 기술 면접의 회고록

cwb111 — Wed, 11 Dec 2024 22:59:01 +0900

안녕하세요!! 거의 2주일 만에 포스팅을 작성합니다.

당연히 공부를 쉰 건 아니고요 최근 한 대기업의 채용 연계형 인턴 면접을 다녀왔습니다.
생애 첫 면접을 다녀오고 느낀 점과 기록해야 할 일들을 작성하겠습니다.
(기업 명이나 면접 질문 목록에 대해선 작성하지 않았습니다. 이 내용을 찾기 위해 블로그에 오셨다면 도움이 되지 않을 거에요.)

왜 26살 먹도록 면접 한 번 보지 않았나?

저도!!!!! 면접을 보고 싶었습니다.

저는 올해 8월에 대학교를 졸업했습니다.
졸업한 이후 중소 기업, 중견 기업 가리지 않고 총 20여 군데에 서류를 지원했었는데요.. 단 한 군데도 붙지 못 했습니다.
심지어 한 곳을 제외한 나머지 기업들에선 탈락했다는 연락 조차 주지 않았었죠.

그래서 저는 '몇 년 동안 그렇게 공부를 열심히 했는데 나를 원하는 곳은 없구나' 생각하며 자존감이 무너졌고..
이 영향이 있었는지 8월 중순 쯤에 번아웃이 왔습니다.

텅텅 비어있는 8월의 깃 잔디

번아웃을 극복한 이후에는 '올해에는 공부에만 집중하고 내년부터 본격적으로 구직 활동을 하자.' 라는 생각과 함께 편의점 아르바이트를 구했습니다.

그렇게 공부를 하던 중, 제가 정말 가고 싶던 대기업에 인턴 공고가 떴습니다.

저는 올해엔 어차피 공부만 하기로 마음 먹었기 때문에 '붙으면 좋고 떨어지면 말고~'라는 생각을 하며 처음으로 중소, 중견이 아닌 대기업에 서류를 지원했습니다.

그리고 아르바이트를 하던 어느날, 이 기업의 서류 전형에 합격했다는 메일을 받게 됩니다.

이 기업은 서류 합격자를 대상으로 과제 전형을 진행했습니다.
저는 이 과제 전형을 밤낮으로 준비하며 안구 건조증까지 생겼지만 다행히.. 과제 전형까지도 합격했습니다.

면접 후기

면접은 저를 겸손해지도록 만들었습니다.

저는 면접관님들의 절반 이상 대답하지 못했습니다.
알고 있다고 대답한 질문들에 대해서도 제가 모른다고 대답할 때까지 깊숙하게 물어보셨습니다.

면접관님들께선 주로 기술의 근본적인 부분에 대해 물어보셨고, 저도 제가 이렇게나 모르고 있는 줄 몰랐습니다.
저는 멍청하게도 근본도 모르는 이 기술들을 잘 알고 있다는 듯이 면접관님들 앞에서 떠들고 있었죠.. 너무 부끄럽네요.
면접관님들이 저를 어떻게 보셨을까요??

저는 현재 팀 프로젝트를 하고 있습니다.
실력 보단 참여율 위주로 팀원들을 선택해서 제가 주도적으로 팀을 구성했습니다.

이 사진은 면접 다음날 새벽에 저희 팀의 백엔드, 프론트엔드 개발자 두 분이서 나눈 대화입니다.
백엔드 개발자분이 베이스 url을 127.0.0.1이라고 알려주고, 프론트엔드 개발자분은 아무런 의심 없이 127.0.0.1로 api 요청을 보내시네요.

저는 아침에 일어나서 이 대화를 봤을 때 깨달았습니다.
'면접관님들도 나를 이런 시선으로 보셨겠구나..'

절대 이분들을 낮잡기 위해 올린 사진이 아닙니다. 오히려 2~3시까지 공부하는 열정이 대단하다고 생각합니다.. 저는 잠이 많아서 저렇게까진 못 하거든요.

단지 127.0.0.1이 뭘 의미하는지도 모르면서 프레임워크를 사용하고 있는 모습과 기술의 근본도 모르고 다 안다는 듯이 면접관님들 앞에서 떠들어댔던 저의 모습이 겹쳐 보여서.. 동질감을 느꼈습니다.

저는 이 짧은 대화만으로 저의 팀원 두 분이 많은 내용을 모른다는 사실을 한 눈에 알 수 있었습니다.
예를 들면 '클라이언트가 api 요청을 보내면 어떤 과정을 거쳐 서버로 어떻게 전송되는지', '127.0.0.1이 뭘 의미하는지' 등이요..
아마 면접관님들도 저를 보며 똑같은 생각을 했겠죠.

그리고 저는 질문에 답변도 잘 못 했는데, 면접 태도까지 건방졌습니다.
아는 게 나와서 면접관님의 말을 끊은 적도 있고, '진짜요?'라고 대답하려다가 말을 절어서 '진짜?'까지만 말하기도 했고, 저는 집중하면 주먹을 쥐고 턱에 주먹을 올리는 습관이 있는데, 면접관님이 말하실 때 집중하느라 주먹을 턱에에 갖다 대고 면접을 봤습니다.
ㅋㅋㅋㅋ.. 원래 이렇게 mz스럽지 않은데 .... 평소엔 정말 깍듯한데 ..........

면접을 마치고 집 가는 길에 '내가 대체 왜 그랬을까 '곰곰이 생각해봤는데요
면접 자리가 너무 편했던 것 같습니다.

왜냐면.. 저는 컴퓨터 공학을 복수 전공해서 컴공 친구가 거의 없습니다.
그래서 이렇게 컴퓨터 관련 주제로 깊게 대화하는 것이 처음이였고, 저는 면접을 보는 내내 너무 신났습니다..
면접실 들어가기 직전까진 너무 떨려서 심장이 쿵쾅대는게 느껴졌는데, 제가 떨렸었다는 사실을 잊었을 정도로요.
면접이 시작되고 나서는 전혀 떨리지 않았어요.

제가 가장 시간을 많이 들이는 분야에 대해, 그 분야의 전문가분들과 말할 기회를 주시다니 아주 값진 경험이였습니다..
당연히 면접 결과는 불합격이겠지만 배울 점이 아주 많았고, 특히 앞으로의 공부 방향을 잡아주신 점이 정말 감사했습니다.

화려한 기술보단 그 기술의 보이지 않는 근본적인 부분을 공부하고, 항상 겸손해야겠습니다.