[ACC 해커톤] 1주차 회고록

서론

팀 주제는 이메일 대량 발송 시스템 설계가 나왔다. 

첫 주차 과제인 아키텍처 초안 구상, 유저 시나리오 작성을 수행하기 위해 3회의 온라인 모임과 1회의 오프라인 모임을 가졌다. 오프라인 모임은 사당 스터디룸에서 진행됐고, 뱅크샐러드에 재직 중인 멘토님께 피드백을 받으면서 진행했다.

 

---

배운 것들

• 아키텍처 초안은 개괄적으로 구성하자. 
  자세한 로직은 실제로 서비스를 사용한다는 생각으로 살을 붙여 나가는 것이 좋다. 처음부터 구체적으로 진행하다보니 자꾸 결과가 산으로 가게 되었다. 동작하는 것이 먼저이고, 최적화는 나중에 처리하도록 하자.
• 유저는 람다의 트리거가 될 수 없다.
  유저와 람다 사이에 API Gateway를 배치해야 한다.
• 특정 시간에 람다를 실행시키고 싶다면 EventBridge를 사용하자.
  EventBridge는 람다의 트리거가 될 수 있다.
• 람다에 할당할 수 있는 최대 메모리를 인지해야 한다.
  최대 10GB의 메모리를 할당할 수 있다. 이메일 발송 대상이 1,000만명인 경우, 람다가 터질 수도 있다. 람다는 기본적으로 scaling을 지원하지만, 최대 메모리를 초과하는 경우라면 여러 개의 람다에 로드 밸런서를 연결하는 구조가 필요하다.
• 람다와 컨테이너는 사용성의 차이가 있다.
  람다와 ecs의 가용성은 거의 동일하다. ecs를 사용하면 관리가 어려워서 유지 보수 비용이 비싸다는 단점이 있다. 람다는 관리가 간단하여 유지 보수 비용이 저렴하지만, 코드가 람다 형식이라 코드 관리 측면에서 어려울 수 있다.
• SES의 사후 처리 로그 감지는 SNS를 사용하는 것이 공식 권고 사항이다.
  구독자에게 뿌리는 것은 개발자가 커스텀할 수 있다.
• SQS는 말 그대로 Queue의 역할만 한다.
  SQS로부터 메시지를 전달 받으면 메시지를 가공하는 로직은 람다가 처리해야 한다.
• SQS는 이미지를 전송할 수 없다.
  S3와 같은 저장소에 이미지를 업로드한 후, url을 전송하는 방식으로 해결할 수 있다.
• SQS의 용량 제한은 256kb이다.
  용량은 크지만 어떤 정적인 요소를 보내야 한다면 key-value 구조를 사용할 수 있다. 어떤 정적인 요소 value를 db(혹은 s3)에 미리 담고 SQS는 key값만 보내는 방식으로 처리할 수 있다.
• 람다 체이닝은 지양하자.
  트랜잭션이 보장되지 않아서 실패 확률이 상승하고, 그로 인해 가용성이 떨어진다.
• 서버리스 아키텍처는 호출 시 요금이 발생한다.
  한 번 보낸 요청을 제대로 성공하는 것도 중요하지만. 쓸 데 없는 요청을 날리지 않는 것도 중요하다.
• 유연한 구조를 만들고 싶다면 레이어를 추가하자.
  이해도가 부족해서 아직 이 말은 이해하지 못했다. 남은 2주동안 실제로 설계하면서 이해하도록 하자.
• 동적인 구조를 만들고 싶다면 유저에게 동적인 구조를 제공하는 것도 방법이다.
  아키텍처만으로 동적인 구조를 만들기 힘들다면 유저에게 위임할 수도 있다. 그러나 유저의 사용성이 떨어지면 안 되므로 유저의 편의에 맞게 front-end를 구성해야 한다.
• 에러가 발생한 경우에 어디서 에러가 발생했는지 파악할 수 있는 정도를 가시성(Observility)이라고 한다.
  가시성을 높이기 위해 모니터링(cloud watch) 등의 방식을 사용한다. 가시성을 높이고 싶다면 모든 람다마다 cloud watch를 붙여도 되겠지만, 비용+번거로움과 trade-off 관계이다. 사실 전체 아키텍처에 하나의 cloud watch를 달아 놓기도 한다.
• 요금을 계산할 때는 프리 티어도 고려 대상이다.
  놀랍게도 그렇다고 한다.
• 저장소에서 데이터를 가져올 때 캐시를 사용하면 성능을 향상시킬 수도 있다.
  마지막 최적화 단계에서 고려해볼 만한 사항이다.

결과물

아키텍처 초안

---

결론

얻는 것도 많아야 하지만, 우선 열심히 해서 1인분은 해야 한다. 이번주의 기여도는 딱히 만족스럽지 못했다.

SAA 준비를 빨리 해야겠다.