Jinhyeok's Portfolio

서버리스 아키텍처 선정 배경

11 min read

이 프로젝트에서는 AWS Lambda를 사용한 서버리스 아키텍처를 선정했습니다.

🎯 AWS Lambda 사용 이유

TIL 챌린지 2주차에 프로젝트를 시작했습니다. 당시, 12주차 동안 평균 8~9명의 멤버가 참여했으며, 각 멤버는 약 11~12개의 좋아요를 받았습니다. 이를 바탕으로 주간 약 100번의 요청이 발생할 것으로 예상하였고, 챌린지에 참여하는 23명의 멤버가 모두 활발히 활동한다면, 주간 요청 수는 약 500번에 이를 것으로 예상했습니다. 또한, 참여 패턴을 살펴보면, 대부분의 활동이 목요일부터 일요일 사이에 집중되었고, 월요일부터 수요일 사이에는 참여가 저조했습니다. 이러한 상황을 종합적으로 고려한 결과, AWS Lambda를 활용하는 것이 적합하다고 판단했습니다.

1️⃣ 빠른 배포와 서버 관리 불필요

이미 챌린지가 시작된 상황이였고, 무엇보다 빠르게 기능을 구현해서 해당 챌린지를 지원하고 싶었습니다. 만약 EC2를 사용해 배포를 진행했다면, 서버 프레임워크를 설정하고, 코드를 작성한 후, 배포 과정까지 모두 직접 처리해야 했기 때문에 많은 시간이 소요될 것이라고 생각하였습니다. Lambda를 사용하면 오직 기능구현에 집중할 수 있고, 테스트도 바로바로 가능했으며 배포 또한 빠르게 진행할 수 있을 것 같아 람다를 선택했습니다.

2️⃣ 사용한 만큼만 비용 부과

주간 100~500번의 요청은 서버를 항상 켜둘 만큼의 트래픽은 아니라고 판단했습니다. 특히, 멤버들이 주로 목요일부터 일요일 사이에 참여가 집중된다는 점을 고려했을 때, 요청이 없는 시간에도 서버를 계속 운영하는 것은 비용적으로 비효율적일 수 있습니다. AWS Lambda는 요청이 발생한 만큼만 비용이 청구되므로, 트래픽이 없는 시간에는 비용이 발생하지 않습니다. 이러한 이유로, 비용 효율성을 높이기 위해 Lambda를 선택했습니다.

🎯 S3 vs 데이터베이스

좋아요 집계를 위해서는 참여 멤버별로 좋아요 개수를 유지할 저장소가 필요했습니다. 또한, 몇 주차에 어떤 멤버가 참여했으며, 각각 몇 개의 좋아요를 받았는지도 데이터로 기록해야 했습니다. 하지만, 참여 멤버가 23명에 불과했기 때문에, 복잡한 데이터베이스를 구축할 필요가 없다고 판단했습니다. 소규모 데이터를 관리하기 위해 S3에 간단한 JSON 파일로 데이터를 저장하고 관리하면, 멤버별 좋아요 수와 참여 기록을 쉽게 유지할 수 있다고 생각해 S3를 선택했습니다.

1️⃣ 간단한 데이터 구조

이 프로젝트의 데이터는 구조가 복잡하지 않으며, 단일 JSON 파일로 충분히 관리할 수 있었습니다. 따라서, 복잡한 데이터베이스보다 S3에 JSON 파일을 저장하고 필요할 때 불러오는 것이 더 적합하다고 판단하였습니다. 또한, 집계된 좋아요 개수를 웹사이트에서 표시해주어야하는데 단일 JSON 파일로 불러와서 적절히 파싱한 후 출력해주는 것이 좋을 거 같다고 생각해서 아래와 같이 데이터를 정의해주었습니다.

📖 사용한 데이터
{
  "U07AU7TQGF3": {
    "name": "OO 님",
    "reaction_count": 0,
    "join_week": {
      "1721629662.494939": {},
      "1722213544.304319": {},
      "1722922114.756999": {}
    }
  },
  "U07AHSXC3U4": {
    "name": "OO 님",
    "reaction_count": 14,
    "join_week": {
      "1721629662.494939": {
        "1722170346.383569": {
          "total": 8,
          "has_link": true,
          "like": {
            "U079ZDDD8TV": 1,
            "U07AU339WF3": 1,
            "U07A0RSEZ7H": 1,
            "U07B46KC21W": 1,
            "U07AHSY9UDA": 1,
            "U07A8PR8B0E": 1,
            "U07AFHRPDH8": 1,
            "U07B472R196": 1
          }
        }
      },
      "1722213544.304319": {
        "1722661142.562769": {
          "total": 6,
          "has_link": true,
          "like": {
            "U07AHSY9UDA": 1,
            "U07B46KC21W": 1,
            "U07AU339WF3": 1,
            "U07AFCTFRNE": 1,
            "U07ACG5UQ6R": 1,
            "U079ZDDD8TV": 1
          }
        }
      },
      "1722922114.756999": {}
    }
  },
  ...
  ......
}

멤버 별로 위와 같이 정의 되어 있으며 각 멤버 아이디를 키값으로 구분되어 있습니다.

  • name: 웹 페이지에 보여주거나 메세지를 보낼때 보여줄 멤버 이름입니다.
  • reaction_count: 멤버별 받은 전체 좋아요 개수 입니다.
  • join_week: 멤버별 참여한 주차를 저장합니다.
    • 해당 객체는 TIL 게시글의 고유한 타임스템프 값을 키값으로 하는 객체를 가지고 있습니다.
    • 멤버가 해당 TIL 게시글에 답글을 달면 답글의 고유한 타임스탬프 값을 키값으로 가지는 객체가 저장됩니다.
      • total: 해당 답글의 좋아요 개수 입니다.
      • has_link: 블로그 글 링크가 게시되었는지 여부를 표시합니다. 링크를 게시하지 않으면(false) 참여하지 않은 것입니다.
      • like: 좋아요를 누른 멤버 ID를 저장합니다.
{
  "timestamps": {
    "7": {
      "1721629662.494939": "TIL 7월 4주차",
      "1722213544.304319": "TIL 7월 5주차"
    },
    "8": {
      "1722922114.756999": "TIL 8월 1주차"
    },
    "this_month": "8"
  }
}

TIL 챌린지 게시글(답글X)의 타임스탬프 값을 월별로 저장해주었습니다. 사용자가 답글을 달았을 때 요청 데이터에 부모 타임스탬프 값(답글을 단 메세지의 타임스탬프)도 포함됩니다. 이 값을 위의 데이터와 비교하여 TIL 챌린지 글에 단 답글인지 확인합니다. 월별로 데이터를 유지한 것은 매 달 챌린저를 뽑을 때 활용하기 위해서입니다.

2️⃣ 비용 및 성능

앞서 말했듯이 해당 프로젝트는 멤버 28명의 데이터만 유지합니다. 즉 소량의 데이터를 다룹니다. 이러한 이유로 저장한 데이터의 양에 따라 비용이 부과되는 S3를 사용해도 문제가 없을 것 같다고 판단했습니다. 물론 현재 프리티어를 사용하고 있기 때문에 이정도의 데이터로는 DynamoDB를 사용하든 S3를 사용하든 비용은 나가지 않습니다. 또한, 성능적인 측면에서는 데이터베이스가 복잡한 쿼리 처리와 실시간 데이터 검색에 유리합니다. 그러나 이 프로젝트에서는 그런 고성능 기능이 필요하지 않기 때문에, S3를 통해 데이터를 간단히 저장하고 관리하는 방식이 성능적으로도 충분히 쓸 만하다고 판단하였습니다.

3️⃣ 정적 웹사이트 호스팅

S3는 정적으로 웹사이트를 호스팅 할 수 있습니다. 이 부분이 제가 S3를 선택한 가장 큰 이유였습니다. 제가 만들려고하는 사이트는 사용자와 동적으로 상호작용할 필요 없이 집계된 좋아요 데이터를 시각적으로 표시하는 간단한 웹사이트를 구현할 생각이었기에 별도의 웹 서버를 운영할 필요 없이, S3에 HTML, CSS 파일을 업로드함으로써 간단히 웹사이트를 배포할 수 있었습니다. 저는 리액트로 페이지를 만들고 해당 리액트 프로젝트를 빌드하여 빌드한 파일들을 S3에 올려주었습니다.

사실, 이 프로젝트를 구현하는 데 꼭 서버리스를 선택해야 하는 것은 아니었습니다. 다른 방법들도 충분히 고려할 수 있었고, 다양한 기술적 접근이 가능했습니다. 구현하면서도 DB가 더 나았을까? 람다 대신 직접 서버 환경을 구축하는 것이 더 나았을까? 라는 궁금증이 들기도 했습니다. 그러나 모든 방법을 충분히 비교할 만큼의 경험이 부족했고, 이번 기회를 통해 서버리스를 직접 경험하며, 람다와 S3를 비롯한 다양한 AWS 인스턴스를 활용하여 경험을 더 쌓고 싶다는 생각도 이 결정을 내린 중요한 이유 중 하나였습니다.

Graph View

Backlinks