Decisions
4개 의사결정 기록
외부 API 화이트리스트 제약을 Lambda + NAT로 해결한 이유 외부 API 호출을 요청 경로에서 분리하려 했지만, 대상 서비스는 IP 화이트리스트 기반 접근 제어를 요구하고 있었다. 비동기 실행 구조를 유지하면서도 고정 IP 조건을 만족시킬 방법이 필요했다. Read decision 외부 연동 작업의 실행 경로를 SQS + Lambda로 정리한 이유 데이터 수집과 외부 연동 작업이 서버 중심으로 실행되면서 확장성과 운영 제어가 모두 제한되고 있었다. 실행 위치가 서버에 묶여 있었고, 같은 요청이 반복 유입될 때 중복 작업을 제어할 기준도 필요했다. Read decision 레거시 모니터링에서 Custom Exporter로 시작한 이유 레거시 운영 서버에는 이미 중요한 서비스가 올라가 있었고, CPU, 메모리, 디스크, MySQL 연결 수 같은 기본 지표와 서비스 이벤트를 빠르게 수집할 필요가 있었다. 동시에 운영 서버에는 HTTP endpoint 기반 scraping 구조와 IP whitelist를 적용해 안전하게 메트릭을 노출해야 했다. Read decision 레거시 개선에서 구조 변경보다 관측 가능성 확보를 먼저 본 이유 서버 단위로 애플리케이션, DB, 스토리지가 결합된 레거시 시스템은 장애가 나도 원인과 영향 범위를 설명하기 어려웠다. 확장과 복구 제약도 컸지만, 무엇이 실제 병목인지 측정할 수 없는 상태에서는 구조 개선 우선순위를 정하기도 어려웠다. Read decision