내가 만드는 모든 서비스는 죽는다
Source: Dev.to
그게 바로 핵심입니다. 저는 급여에서 직접 청구서를 결제할 수 있게 하는 핀테크 스타트업 Ontime Payments에서 시니어 소프트웨어 엔지니어로 일하고 있습니다. 우리는 의도적으로 모듈식이며 이벤트‑드리븐 서버리스 아키텍처를 구축했으며, 그 안의 모든 서비스는 결국 교체될 것으로 예상됩니다. 일부는 교체되지 않을 수도 있지만, 우리는 마치 교체될 것처럼 설계하고, 이것이 모든 것을 형성합니다.
Source: …
Serverless Architecture
Serverless는 잘 알려진 이점이 있습니다: 관리할 서버가 없고, 적용할 패치가 없으며, 자동으로 확장되는 컴퓨팅. 실제 변화는 관리형 인프라뿐만 아니라, 작은 집중형 함수들을 이벤트‑드리븐 통신과 “필요할 때 언제든지 구성 요소를 종료하고 교체할 수 있다”는 철학과 결합했을 때 일어납니다.
기본에 익숙하지 않다면: 사용자가 API Gateway에 요청을 보내면 Lambda 함수가 트리거됩니다. 그 함수는 자신의 작업(예: 결제 처리)을 수행하고, 사용자에게 응답을 반환하며, EventBridge에 이벤트를 발생시킵니다.
EventBridge는 중간에 위치해 정의한 규칙에 따라 이벤트를 라우팅합니다. 결제 함수는 창고 운영이나 이메일 영수증에 대해 아무것도 알지 못합니다. 단지 자신이 수행한 일을 알리고, 다른 서비스들이 이를 듣고 적절히 행동합니다. 생산자는 몇 명의 소비자가 듣고 있는지, 혹은 그들이 누구인지 전혀 모릅니다. 각 함수는 한 가지 일만 수행합니다. 이러한 작은 구성 요소와 느슨한 결합이 다른 모든 것을 가능하게 만드는 핵심입니다.
서비스 교체
우리는 모니터링 서비스를 처음에는 간단하게 시작했지만 시스템이 확장되면서 조건부 로직이 얽히게 되었습니다. 새로운 기능이 추가될 때마다 더 많은 엣지 케이스, 더 많은 설정 요구사항, 더 큰 취약성이 생겼습니다. 그래서 우리는 v2 를 처음부터 다시 만들었습니다.
이는 일반적인 조언(“절대 재작성하지 말고 항상 반복하라”)과는 반대되는 접근입니다. 원래 서비스가 작고 집중돼 있었기 때문에, 계속해서 패치를 적용하는 것보다 새로 시작하는 것이 실제로 더 적은 작업이었습니다. 범위도 관리 가능했습니다.
두 버전은 strangler fig 패턴과 유사하게 나란히 실행되었습니다.1 두 서비스는 EventBridge 로부터 동일한 이벤트를 소비했습니다. 이벤트를 발생시키는 서비스는 아무것도 바꿀 필요가 없었으며, 하나의 소비자든 두 개(또는 열 개)든 듣고 있다는 사실을 알 필요가 없었습니다. 우리는 v2 가 정상적으로 동작하는 것을 검증한 뒤 v1 을 종료했습니다. 나머지 시스템은 아무 변화도 감지하지 못했습니다.
이것은 특별한 이야기가 아닙니다. 우리는 모듈을 병합하고, 분리하고, 전체 서비스를 교체해 왔습니다. 초기 이메일 전송 서비스는 Slack, 웹훅, 이메일을 함께 처리하는 더 넓은 알림 모듈에 흡수되었습니다. 오래된 서비스는 단순히 꺼졌을 뿐입니다. 이것이 우리가 평소에 하는 방식이며, 영웅적인 마이그레이션 작업이 아닙니다. 이점은 단 한 번의 순간이 아니라, 항상 모든 것이 더 쉬워진다는 점입니다.
사고방식과 유연성
많은 개발자들이 처음부터 모든 가능한 미래 요구사항을 예측하여 구축하려고 합니다. 그것은 유연성이 아니라, 경직성의 범위를 넓히는 것에 불과합니다.
우리가 발견한 유연성은 사전 계획에서 오는 것이 아니라 아키텍처 자체에서 나옵니다. Lambda는 작고 집중된 컴포넌트를 장려합니다. 이벤트‑드리븐 설계는 이들 컴포넌트를 서로 격리시킵니다. 각 조각은 이해하기에 충분히 작고, 교체하기에 충분히 집중되어 있으며, 교체해도 외부에 파급 효과가 없을 정도로 격리되어 있습니다.
아키텍처 수준에서 진지하게 적용되는 keep‑it‑simple‑stupid 철학2은 모든 가능한 미래가 아니라 오늘의 요구사항에 맞춰 구축한다는 의미입니다. 이는 정신적 에너지를 절약하고 배포 속도를 높이며, 결코 도래하지 않을 시나리오에 대비해 복잡하게 만드는 일을 방지합니다. 서비스가 더 이상 요구사항에 맞지 않을 때 우리는 그 서비스를 종료하고 요구사항에 맞는 새로운 서비스로 교체합니다. 우리가 구축한 방식 덕분에 그 교체는 다른 경우보다 훨씬 쉬워집니다.
결론
모든 서비스는 결국 사라집니다. 그것이 시스템을 살아 있게 하는 이유입니다.
Human written, AI assisted.
AWS Lambda와 EventBridge를 활용한 이벤트‑드리븐 서버리스 아키텍처에 대해 더 알아보려면, AWS의 이벤트‑드리븐 아키텍처 문서를 참고하십시오.