랭킹 시스템 도입, AWS ELB 로드 밸런서 적용기 - 항해99 11주차 회고

싱클베어·2022년 3월 27일
0

항해99 회고록

목록 보기
11/13

그동안의 이야기

열한번째 회고록을 작성하게 되었다. 퍼포먼스 마케팅 특강을 통해, 12주에 진행하게될 실제 마케팅을 어떻게 진행할 지에 대한 고민을 가져가고, 백엔드 서버를 좀 더 튼튼하게 가져가고 고객을 맞이할 준비를 진행했던 한 주였다. 다소 심심했던 기능들을 조금 더 채워넣는 시간도 가졌다. 이번주는 좀 쉬어가며 할 수 있지 않을까 싶었는데, 역시나 늘 순탄치 않았다. 그 과정을 적어보려 한다.

  • 이번 주 개발 진행 상황
  • 기존 서버 환경에서 이전하기
  • AWS 네트워크에 대한 이해와 AWS ELB
  • 느낀 점
  • 내게 아쉬웠던 것

이번 주 개발 진행 상황

랭킹 시스템 적용

캐릭터를 조금 더 활용해보자는 취지에서, 랭킹 시스템에 다른 사람들의 캐릭터를 볼 수 있는 페이지를 만들었다.

실 사용자들이 들어와, 각자 개성있게 꾸민 캐릭터들이 랭킹 페이지를 장식하고 있는 것도 꽤 재밌는 아이디어가 될 것이라고 생각이 들었다. 다만 백엔드 개발 입장에서 성능상의 이슈가 있다.

현재는 실시간 랭킹을 구현하기 위해 그저 모든 사용자의-캐릭터 데이터를 모두 불러와 계속해서 쿼리를 보내고 있는 상태인데, 단위가 커서 문제가 생길 것이라고 보고있다. 두 가지 해결책이 제시되는 것 같다.

  1. redis를 사용해, 자주 데이터를 조회하게 되도 부하를 줄여 실시간 랭킹 구현
  2. 정해진 시간에(예: 매일 오전 05:00시 업데이트) 랭킹 데이터를 업데이트 하도록 하여 그 날 동안은 모두가 같은 데이터를 보게 함.

실시간 랭킹에 대해 검색해봤을 때 1을 좀 더 자주 쓰는 것으로 보였는데, 어떤 해결책을 적용해 볼 수 있을 지 차주에 업데이트를 해볼 것으로 예상된다.

매 3일째 주는 포인트는 랜덤 지급

현재 진행중인 실전 프로젝트에 재밌는 기능을 넣었다. 챌린지에 대해 인증 할 때, 1,2일차에는 인증 시 포인트를 100점을 주고, 3일차는 300~3000포인트를 주는데, 이 3일차 지급 포인트에 확률을 적용 시켜보기로 했다.
Math.random() 을 사용해 일정 확률로 구간을 나누어 각각 300, 500, 1000, 2000, 3000점을 주게 설정하였다. 로직 자체는 떠오른거에 비해 굉장히 금방 나왔는데, 재미 요소가 될 수 있을지 좀 고민이다.

프론트엔드 팀원분들이 "어 이거 좋은데요, 룰렛이라도 하나 만들어 볼까요?" 해서... 일단 진정하시고 프로젝트 완성도를 높이고 추가 기능으로 생각해보자고 했다. 당장은, 포인트를 얼마 받았다만 표기하도록 적용되었다.

아키텍처 변경

아마도 백엔드 쪽에서의 가장 큰 화두는, 기존에 서비스 아키텍처로 구상했던 것을 제대로 사용하여 구현하는 것이었다. 그러기 위해서는 AWS 서비스 중 ELB란 것이 어떻게 사용되는지 제대로 들여다 볼 필요가 있었다. 금방 구현하겠지 했는데 들어가야할 개념이 정말 많았기에 순탄치 않았다. 이는 별도의 블로그 글로 정리해서 작성해보려고 한다.

보안 적용

보안에 대한 부분을 많이 들여다봤는데, 실제로 적용된 건 많이 없었다. 테스트를 도대체 어떻게 해야할 지 감이 안와서 진행하는 도중에 막힌 것들이 정말 많았다. XSS, CSRF, SQL Injection, HTTP 헤더 보호, DoS 공격 등 적용해볼만 한 것은 많았는데 쉽지 않았다.

관련 내용을 기술 멘토링 멘토님에게 물어보니, 취약점 분석을 해주는 사이트에 우리 서비스의 도메인을 넣고 검사하는 것을 이용해 문제가 있다는 부분을 하나씩 조치 해나가는 것도 하나의 방식이 될 수 있다고 알려주셨다. 서비스가 올라가고 난 뒤, 해당 내용들을 적용시켜 방어하는 것도 방법이라 한다.


기존 서버 환경에서 이전하기

기존 구성도는 EC2에 기본 VPC고, 새로 구성하려는 구성도는 새 로드 밸런서용 VPC를 별도로 파고, 새 서브넷, 라우팅 테이블, 보안 그룹, 로드 밸런서-타겟 그룹을 꾸려놓았다.

기존 EC2를 다른 VPC에 그대로 옮기는 방법을 찾아봤는데 그것은 AWS에서 정책적으로 막아둔 상태이기 때문에, AMI (Amazon Machine Image)를 사용해 기존 EC2를 이미지로 백업해둔 후, 다른 EC2를 생성 후 거기에 부어넣는 방식으로 진행했다.
이를 응용해, 다른 로드 밸런서에 부하를 받아줄 EC2는 별도로 새 EC2를 생성 후, shell 스크립트를 통해 미리 작성해두어 필요한 파일과 설정을 미리 다 입혀둔 이미지를 AMI로 만들었다. 마치 과거에 윈도우 고스트를 작성하듯 하는 기분이었는데, 올바르게 이해한 지는 조금 더 공부가 필요할 듯 하다.

AWS 네트워크에 대한 이해와 AWS ELB

VPC, 퍼블릭/프라이빗 서브넷, 라우팅 테이블, 인터넷 게이트웨이, 타겟 그룹 등 정말 생소한 용어들이 줄줄이 튀어나왔다. 정확하게 이해한 후 만들고 싶어서 며칠에 걸쳐 테스트 계정을 가지고 씨름을 했다. 관련된 내용을, 별도 블로그 글로 게시하였다. 아래에서 확인할 수 있다.

실전프로젝트 돌아보기 - Amazon EC2 ELB 적용하기

느낀 것

예쁜 디자인이 입혀진 것이 이것저것 살이 붙으며 실제 서비스 하는 것 처럼 굉장히 깔끔하게 입혀지고 있다. 보는 내내 기분이 좋은 동시에, 한 편으로는 유저들이 들어왔을 때 우리가 원하는 플로우대로 써줄까? 는 여전히 미지의 세계였다. 온보딩 페이지를 만들어 가이드를 하긴 하지만, 내부에 숨겨진 기능이 많아 잘 전달이 될지는 솔직히 걱정이다.

하지만, 그럼에도 불구하고 뭔가 이런 서비스가 완성되어 가는 것을 구경하는 것은 역시 기분이 좋다. 마무리를 잘 하고, 팀원 모두의 포트폴리오로도 가치있게 사용되었으면 하는 바램이다.

내게 아쉬웠던 것

팀원분들. 이번주는 잠 좀 잡시다.

저번 주에도 비슷한 얘길 한거같은데, 이번주도 잘 챙겨드리진 못한거 같다. 얼굴이 많이 상해있다거나 말의 텐션이 가라앉은 분들이 많아 좀 걱정이 된다. 내 개인적으로는 텐션을 올리는 쪽보단, 차분하거나 진지하게 정리하는 것 위주로 하는 편이라 쉽지는 않다... 그래도, 정말 이제 2주밖에 남지 않았다. 남은 2주를 다시 알차게 보내보겠다.


참고 URL

profile
안녕하세요.

0개의 댓글