지갑 노드와 API 서버 상태를 확인해 이상하면 텔레그램으로 메시지를 보내는 서버리스 함수 health-alert 를 만들어 두고 기능을 넓히려던 참이었다. 이것이 내부망에 있는지 외부망에 있는지를 묻는 질문이 나왔다.
Table of contents
Open Table of contents
검증 — 어느 망에도 붙어 있지 않았다
함수 설정을 조회하니 VPC 식별자도 서브넷도 ACG 도 전부 비어 있었다. 내부인지 외부인지를 따지는 질문 자체가 성립하지 않는 상태였다.
이 함수는 클라우드 제공자의 관리 환경에서 실행되고 우리 VPC 와는 무관하게 돈다. 추측으로 답할 수 있는 질문처럼 보였지만 조회하기 전까지는 셋째 경우를 떠올리지 못했다.
할 수 있는 것과 못 하는 것
이 상태의 제약은 명확했다. 인터넷 호출과 Object Storage 같은 관리형 서비스 호출은 권한만 있으면 되고 우리 VPC 안의 MariaDB 에는 붙을 경로가 없다.
그래서 이 함수는 데이터베이스를 직접 읽지 못한다. 필요하면 API 서버의 GET /internal/health 조회 인터페이스를 거쳐야 한다.
판단 기준 — 반대 구성이 지는 대가
두 가지 방법이 있었다. 함수를 VPC 안에 넣는 것과, 지금처럼 밖에 두는 것이다. 안에 넣으면 MariaDB 에는 붙지만 사설 대역은 기본적으로 밖으로 못 나가므로 NAT Gateway 가 따로 필요하다. 알림을 외부 메신저로 보내야 하니 그 장치가 필수가 되어 월 비용이 붙는다.
밖에 두는 쪽을 골랐다. 이유는 이 함수가 하는 일이 상태 확인과 알림 발송이라 DB 직결이 꼭 필요하지 않아서다. 대신 DB 를 봐야 하는 판정은 조회 인터페이스를 거쳐야 하는 것을 감수했다. 어느 쪽이 맞느냐가 아니라 무엇을 포기하느냐의 문제였고 지금 구성은 그 복잡성 대신 직결을 포기한 것이다.
조치 — 제약이 정한 기능 배치
제약이 정해지니 어떤 기능을 어디에 둘지가 따라 정해졌다. 텔레그램 발송과 Object Storage 이벤트 저장과 판정 로직은 외부 호출과 관리형 서비스만 쓰므로 이 함수 안에서 완결된다.
MariaDB 조회가 필요한 것만 GET /internal/health 를 경유하게 뒀다. 배치를 감으로 정하지 않고 제약에서 도출하니 경계가 흔들리지 않았다.
보존 기간의 하한
이벤트를 Object Storage 에 넣으면서 얼마나 보관할지를 정해야 했는데 처음에는 여섯 시간을 떠올렸다. 근거를 만들어 보니 이 저장소의 목적은 직전 실행이 언제였는지를 아는 것이었다.
그래야 한 번도 안 왔다와 아직 주기가 안 됐다를 구분할 수 있으므로 보존 기간의 하한은 가장 긴 cron 주기가 된다. 주기를 실측하니 대부분 십 분인데 일정산처럼 하루에 한 번인 것도 있어서 그 대상까지면 하루를 넘겨야 했다.
설정과 주기를 둘 다 조회한 것이 이 설계를 갈랐다. 추측했으면 하나는 못 하는 것을 하려고 했을 것이고 다른 하나는 보존 기간이 모자랐을 것이다.
정리
- 내부인가 외부인가를 묻기 전에
VPC에 붙어 있는지를 확인한다 - 망 밖이면 외부 호출은 자유롭고
MariaDB같은 내부 리소스에는 못 붙는다 - 제약이 반대이므로 어느 쪽이 맞는 것이 아니라 무엇을 포기하느냐다
- 제약을 알면 기능 배치가 따라 정해진다
- 내부 접근이 필요한 것만
GET /internal/health를 경유한다 - 보존 기간의 하한은 가장 긴
cron주기다 - 대상 범위가 그 하한을 정하므로 감으로 정할 것이 아니다
- 설정과 주기를 추측하지 않고 조회하면 예상과 다른 값이 나온다