망 안에 없으면 제약이 반대가 된다

상태를 확인해 이상하면 메시지를 보내는 함수를 만들어 두고 기능을 넓히려던 참이었다. 이것이 내부망에 있는지 외부망에 있는지를 묻는 질문이 나왔다.

Open Table of contents

어느 망에도 붙어 있지 않았다

설정을 조회하니 망 식별자도 서브넷도 보안 그룹도 전부 비어 있었다. 내부인지 외부인지를 따지는 질문 자체가 성립하지 않는 상태였다.

이 함수는 서비스 제공자의 관리 환경에서 실행되고 우리 망과는 무관하게 돈다. 추측으로 답할 수 있는 질문처럼 보였지만 조회하기 전까지는 셋째 경우를 떠올리지 못했다.

이 상태의 제약은 명확했다. 인터넷 호출과 관리형 서비스 호출은 권한만 있으면 되고 우리 망 안의 데이터베이스에는 붙을 경로가 없다.

그래서 이 함수는 데이터베이스를 직접 읽지 못한다. 필요하면 조회용 인터페이스를 거쳐야 한다.

망 안에 넣었으면 어땠을지를 같이 따져 봤다. 데이터베이스에는 붙지만 사설 대역은 기본적으로 밖으로 못 나가므로 외부로 나가는 장치가 따로 필요하다.

알림을 외부 메신저로 보내야 하니 그 장치가 필수가 되고 비용이 붙는다. 어느 쪽이 맞느냐가 아니라 무엇을 포기하느냐의 문제였고 지금 구성은 그 복잡성 대신 직결을 포기한 것이다.

제약이 정해지니 어떤 기능을 어디에 둘지가 따라 정해졌다. 알림 발송과 이벤트 저장과 판정 로직은 외부 호출과 관리형 서비스만 쓰므로 이 함수 안에서 완결된다.

데이터베이스 조회가 필요한 것만 조회 인터페이스를 경유하게 뒀다. 배치를 감으로 정하지 않고 제약에서 도출하니 경계가 흔들리지 않았다.

이벤트를 저장소에 넣으면서 얼마나 보관할지를 정해야 했는데 처음에는 여섯 시간을 떠올렸다. 근거를 만들어 보니 이 저장소의 목적은 직전 실행이 언제였는지를 아는 것이었다.

그래야 한 번도 안 왔다와 아직 주기가 안 됐다를 구분할 수 있으므로 보존 기간의 하한은 가장 긴 스케줄 주기가 된다. 주기를 실측하니 대부분 십 분인데 하루에 한 번인 것도 있어서 그 채널까지 대상이면 하루를 넘겨야 했다.

설정과 주기를 둘 다 조회한 것이 이 설계를 갈랐다. 추측했으면 하나는 못 하는 것을 하려고 했을 것이고 다른 하나는 보존 기간이 모자랐을 것이다.