[Econo-Recruit] 1년간 서버 운영을 마치며 (끝이라는 이야기는 아님)

BlackBean99·2024년 4월 5일
3

회고

목록 보기
6/8
post-thumbnail

Econo-Recruit가 뭔가요??

에코노베이션 동아리 신입모집 플랫폼 매 신입기수 채용시 필요한 다양한 서비스들을 통합 관리하는 플랫폼입니다!
협업을 위한 칸반보드식 업무 프로세스 지원 서비스, 지원서 작성 및 제출, TF 선정 및 전체 프로세스 관리자 페이지, 현 지원자 통계 페이지, 신입 회원 메일링, Slack Notification, 관리 모니터링 서비스를 모두 제공하고 있습니다.

약 1년간 운영하면서 있었던 많은 이슈들. 추가된 여러 장애와 기능들을 대응하면서 있었던 이야기들을 적어볼까 합니다.

이정도의 트래픽을 실제로 경험할 수 있었고, 너무너무 불안한 인프라 환경 (대학교 온프로미스 서버 대여)에서 구축했기 때문에 보안적 제약사항도 많았습니다.

👉 Econo-Recruit 바로가기

오늘의 회고는 1인 서버 개발자로서 무엇이 부족했었는지 어떤 마인드로 개발을 해나가야 하는지, 어떤점을 미리 준비했어야 했는지 이런 관점으로 작성해보도록 하겠습니다.

흑흑 너무 힘들었지만 여러 도전도 많이 해봤던 프로젝트였기 때문에 뿌듯한 마음뿐이랍니다.

먼저 간단하게 기능 소개를 해볼까요.

기능소개

📷 Main ( 신청을 제외한 페이지는 전부 인증된 회원대상으로 한 로그인을 해야만 열람할 수 있습니다)

😀 칸반보드 서비스 ( 칸반보드형 지원자 관리 플랫폼 )
각 칸반을 생성, 이동, 지원자 등록시 자동 카드 생성, 삭제, 네비게이션 관리, 좋아요, 댓글 기능 포함 ( 지원서 제출시 자동으로 칸반 보드 생성 ) 신입모집 칸반보드

📱 세부 카드 관리
지원서 폼 내용 열람 및 평가, 댓글, 댓글 좋아요(일반 좋아요와 구분)를 통해 면접관들과 지원자들에 대해 소통할 수 있습니다. 카드내용 (개인정보들이 있어서 몇개는 블러처리 했습니다 ㅎ)

관리자 페이지
신입모집 TF 선정 , 통계 열람 신입모집 관리자 페이지 신입모집 관리자 페이지통계 관리자 페이지


📱 지원서 신청
Json 파일 구조에 따라 자동으로 UI 생성 및 관리되게 세팅되었습니다. 신청

기능을 모두 소개할 수 없어서 간단하게 이정도만 하고 넘어가겠습니다. ㅎㅎ 궁금하시면 지원하셔서 확인하시길 ㅎ

시작하기 전부터 중간에 있던 억까들 (제한사항)

  1. 서버가 그냥 꺼집니다. CPU파워가 문제인지, 대기전력 부족인지 , Ram 부족인지 다 추적을 해봤지만 결론은? 그냥 전기가 나가더라구요.. (UPS설치해서 그나마 대응할 수는 있었지만 건물 전체 새벽에 정전나는건 진짜 너무한거 아니냐..)
  2. 학교 서버를 대여해서 쓰니 포트 제한이 걸려있습니다.
  • 처음에는 80포트가 열려있었습니다. 다른 포트도 열려있었구요. 그런데 어느 날 443 포트를 제외한 모든 포트가 다 막혀버렸습니다. 이게 뭐가 문제냐구요? 아웃바운드 포트도 막혀서 AWS SES, SMTP, 모니터링 솔루션 이런거 전부 사용이 불가했습니다. (나중에 이거 극복한 이야기도 있습니다)
  • 이걸로 처음에는 SSL 적용을 안해두다가 80번이 막히고 나서 SSL 적용을 하는게 진짜 억까였습니다. Akamai Challenge 하느라 정말 힘들었습니다. 클라우드를 쓰지 않으면 외부 80번이 막히고 SSL 인증하는 난이도는 정말 어렵습니다. (제기준)
  1. 대여서버 CPU나 RAM같은 스펙자체가 좋지는 않았습니다.
  • 자세히 적기는 조금 그래서,, ㅎ 아무튼 한번은 램이 꽉차서 터진적도 있구,, 카프카 몰래 도입하다가 터져버린적도 있구,, 그래서 최대한 저스펙으로 운영해야했습니다.

이런 수많은 제한사항들이 있었지만 꾸역꾸역 극복했습니다. 이를 통해 저는 제한속에서 극복해나가는 과정들이 또 개발자 스럽다고 생각합니다. 어딜가든 마찬가지로 이런 억까가 있을테니까요.

’그럼에도 불구하고’ 해내는 것이 우리 개발자 아니겠습니까.

기획자의 부재

우리 개발팀(FE 1, BE 1, De 1) 이렇게 3명이서 진행해서 디자이너가 그려준 화면에서 추측성?으로 기획을 진행했었습니다.

정책 수립 담당자의 부재

저 화면에서 저걸 누르면 활성화가 되지 않을까? 저건 움직여야 하지 않을까? 공란으로도 보낼 수 있지 않을까?
하지만 화면에서는 드러나지 않는 제한사항들은 백엔드인 제가 정책을 세워야 했습니다.
처음부터 제가 정책을 모두 세우고 진행했었다면 조금 나중에 변동에 유연했겠지만 그렇지 못했다보니 나중에 수정파티가 일어났습니다.

ex) DTO에 필드를 화면단위로 맞추었더니 나중에 화면 바뀌면 파라미터를 바꿔달라 하더라구요. 도메인이 4,5개가 연결된 DTO인 경우 정말 수정하기 어려운 점도 있었습니다.
DTO Less하거나 엄청 유연한 반환방법을 좀 더 고민해봐야겠습니다.

TF팀의 요구사항

메일링 템플릿의 수정사항이나 메일링 예약 시간의 수정, 좋아요를 누르면 하이라이트를 해준다거나 등등 첫 기획에는 부족한 점이 많아서 TF팀과 함께 만들어갈 수 있어서 점점 퀄리티가 좋아졌습니다.

가끔은 반영하기 정말 어려운 요구사항들도 있었습니다. 하지만 ‘그럼에도 불구하고’ 라는 마인드로 어떻게든 구현해준다는 생각으로 임해서 힘들긴 했지만 모두 수용할 수 있도록 개발했습니다.

Release 3.0까지 오면서 있었던 변화들

각 버전별로 큰 변화에 대해서 간략하게 적어볼게요
백엔드 분들은 이런 변화를 겪으며

Release 1.0

메인 화면 기획 구현에 포커스를 두었습니다.

댓글, 좋아요, 지원서, 평가 칸반보드, 인프라 구축 등등

Release 2.0

  • https 적용
  • docker-compose 적용
  • 멀티모듈 적용
  • Swagger 커스텀 문서화 적용
  • Nginx Reverse proxy로 동아리 여러 서버에 도메인 라우팅 (prefix기반으로 라우팅 구현)
  • 하이라이트(내가 찜해둔 지원자들 화면 하이라이트 표시)
  • 영상 임베딩(면접 영상)
  • 관리자 권한 수정
  • XSS 공격 방지
  • BlackList 및 자체 IDS
  • EDA ( 모든 연관관계를 다 끊었습니다 - 수정이 확실히 용이했습니다. )
  • 칸반보드 최적화
    • Before : 기존에는 (3,3) → (4,5) 이렇게 좌표 기반으로 움직였는데 이러다 보니 아래 깔린 칸반 전체를 수정해야해서 update를 너무 많이 해야했어요.
    • After : prev, next 링크드 기반으로 이전 칸반과 이후 칸반, 이전 칼럼 이후 칼럼 이렇게 구성해서 알고리즘을 전체 변경했습니다.

Release 3.0

  • 온프로미스 환경 CI/CD 파이프라인 구축 ( 내부 서버의 보안 정책으로 제한사항이 많아서 많이 해맸습니다,, )
  • 배포 속도 최적화 (JIB 적용해서 컨테이너 빌드 속도를 최적화했습니다.
  • 지원자 질문과 응답이 계속 변해서 RDB에 지원자 하나당 33개정도의 로우가 있어서 관리하기가 너무 힘들어서 자체 몽고디비 클러스터를 구성했습니다.
    • 이거 하나로 대부분의 로직을 전부 수정했습니다. DB에 의존한 코드는 좋지 않습니다.. 최대한 인프라와 분리된 코드를 짜야하더군요,,
  • 지원자 서류합격, 면접 합격 메일링
  • 질문 자체 ID 구성 및 DB가 아닌 JSON파일로 질문 데이터 관리 (수정의 용이)
  • 메일링 발송 실패(SMTP 커넥션 문제)를 해결하기 위한 Outbox 패턴 적용해서 메일링 발송률 100프로 보장
  • 첨부파일(포트폴리오) 메일링 기능 추가
  • 지원자 검색 기능 추가(검색 기준이 이름이 아니라 관련된 모든 정보 기반(대답, 개인정보 등등등등…으로 검색)
  • 지원자 조회 페이지 정렬 기준 추가 ( 이름, 등록 시간, 평가 점수 등등 )
  • 지원서 유실 장애 해결(자체 메시지 큐 구성) - 지원 성공률 100프로 보장 / Fault-Tolerance System 구축
  • 지원서 스냅샷 백업 기능 추가
  • VAVR을 적용해 코드스타일을 FP으로 변경

이렇게 작성해오니 생각보다 기술적으로 많은 변화가 있었네요

아쉬운 점

  • 처음부터 보안 사항을 전부 해결할 방법을 알고 시작했으면 더 많고 다채로운 도전을 할 수 있지 않았을까 싶습니다.
  • 서비스는 점차 발전하는데 인수인계를 받을 사람의 수준을 저 내용을 모두 이해할만한 수준으로 끌어올릴 온보딩 절차가 미흡했습니다.
  • 기능을 설계할 때 정책, 제한사항, 사이드 이펙트를 더 깊게 고민할 시간이 있었으면 더 좋은 설계가 나오지 않을까 아쉽네요. 많이 개선되긴 했지만 업무를 착수할 때 더 면밀히 관련된 도메인과 관련된 데이터의 사이드 이펙트는 없을지 더 깊이 고민하려구요,,

기술수준이 높아지면서 온보딩하는 사람이 감당할만한 수준과 타협은 어려운 것 같습니다. 개인의 성장과 집단의 성장을 타협을 해야하는 상황이지만 전적으로 개발을 담당했던 제 성장에 포커스를 하다보니 신입들이 위 Release3.0 까지 오는 것이…

혼자 서버를 하느라 힘들었던 점은 없었나요?

  • 혼자 한다는게 제일 문제인건 많은 기능을 혼자 다 담당하다 보니 개발 속도가 저 혼자에 달려있다는 게 적절하지 못했습니다. 제가 어떤 일이 있을 때 문제가 생기면 아무도 대응해줄 수 없다는게 아쉽긴 했습니다.
  • 힘든건 제 능력으로 어떻게 다 해결할 수 있었지만, 미래를 그리기에는 조금 어렵습니다. 동아리원들이 이 기술 스택을 전부 이해하고 코드를 자유롭게 수정하는데 온보딩을 해야하는데 제공하려 많은 노력을 했지만, 온보딩 받다 졸업하고 취준한다고 해서 이탈하는 사람도 있어서

좋은 온보딩을 저에게는 좋은 오프보딩을 할 수가 없었습니다. 계속 이어서 내가 해야하나,,

  • 코드리뷰를 받거나 개선할 여지가 저의 판단에 의존된다는게 아쉽습니다. 충분히 좋은 챌린지들을 많이 해서 많이 성장은 했지만 함께 고민할 사람이 없다는게 아쉽습니다.

그럼 서버 혼자 하면서 좋았던 점은 있어?

  • 도전하고 싶은 기술은 근거를 가진다면 적극적으로 실험해볼 수 있다는 것이 좋았습니다. ( 물론 기준 스펙 높은 스택은 쓸 수는 없지만,, )
  • 개발 속도는 체감상 빨랐다고 생각합니다. 공동 목표 및 스프린트 관리, 팀원 관리에 들어가는 커뮤니케이션 비용이 없었기 때문에 속도는 빨랐습니다.
  • 서비스의 전체 설계부터 운영까지 모두 다 경험할 수가 있어서 서비스와 비즈니스 자체에 대한 이해도가 많이 높아졌다고 생각합니다. 정말 귀한 경험이었죠.
  • 이런 서비스가 MAU 3000명을 달성하기까지 정말 힘들었지만 뿌듯합니다. 제 자식같다고 할까요..?
  • 같이 하는 프론트 친구와 전우가 됩니다. 서로 데이터 처리를 자기가 하겠다고 ㅋㅋㅋㅋ
    스스로 나서서 하려고 했던 자세를 가진 서로가 있었기 때문에 여기까지 오지 않았나 싶습니다.
    (야 정렬 내가 해서 줄게, 아니? 그냥 프론트에서 이렇게 뚝딱하면 되는데? 어,,, 그래도 내가 하는게 맞지 않냐? ㅋㅋㅋ 내가 해서줄게~ )

도전해보고 싶은 게 남아있어?

물론이죠 사실 4.0을 준비하고 있습니다.

  • sentry나 ELK를 적용해서 로그나 예외를 프론트분들도 확인할 수 있는 환경
  • 마이페이지 ( 따로 조회 )
    • 내 북마크(좋아요 라벨 기준으로 지원자 조회)
  • 램 관리 (TTL)
    • RAM을 70% 이하로 유지할 수 있도록 하고 싶어요. 서버 스펙이 안좋다 보니 배포할때마다 너무 뛰더라구요.
    • 서버에 부하가 정말 적은 무중단 배포 환경을 개선 ( 가상 서버 하나를 더 할당 받아서.. )
  • ApiGateWay 구축하고 쿠버네티스를 적용해서 동아리원들에게 AWS처럼 서버를 할당해서 관리하는 플랫폼을 더해준다면 더 좋지 않을까 싶네요
  • 캐시를 더 잘 써서 Stempede 문제도 해결하고 반응 속도를 좀 더 빠르게 해주고 싶네요
  • 지원자의 면접시간 배정 및 면접시간(카카오톡 오픈채팅방에 들어온 면접시간 수정 요청) 기능을 추가하고 싶어요. → 지금은 면접시간 요청은 받아서 사람들이 수작업으로 시간을 할당했지만 이것도 잘하면 자동화 할 수 있을 것 같습니다.
  • 지원서 요청 위치를 추적해서 위치기반 요청 패턴 예측 및 모니터링 반영 ( 어디 사는 사람들이 지원 비율이 많더라 이런 통계 처리를 좀 더 해보고 싶습니다. )
  • 자동 로그인 기능 추가 ( 이종간 보안 추가 )
  • 하드웨이 데이터 이용
  • IDP 회원관리 서버 통합 및 Microservice로 분할
  • Stanby 서버 구성
  • 외부 서버를 좀 더 구성해서 Hystrix 같은 솔루션을 적용해서 Circuit Breaker 적용해 다중 서버 상태 관리
  • 모바일 푸시알림

정리해둔건 이정도가 있습니다.

작성해둔걸 보니 그냥 계속 발전시키고 싶나 보군요.

한 서버를 여기까지 혼자 달려오면서 정말 행복했습니다. 취업이 되고 나서도 시간될때마다 조금씩 손보려구요 ㅎㅎ

Econovation을 지원하려는 서버 개발자들에게 or 위 프로젝트를 합류하고자 하는 서버 개발자들에게

사람들에게 많은 관심을 받기도 했습니다. 분명 프로젝트를 진행하면서 기획적으로 많은 요구사항도, 잦은 수정사항도 받게 될겁니다.

저 혼자서도 이렇게 많은 도전들을 해왔습니다.

HR 플랫폼에 대한 도메인도 익히고, 자신만의 새로운 기획을 추가하기에도 매우 자유로운 이 프로젝트에 합류하신다면 분명 많은 도전을 할 수있으리라 확신합니다. 하지만 그런 도전을 할 준비와 자세가 있는 사람이여야만 이런 값진 경험을 얻어갈 수 있다 생각해요.

제가 언제 취업이 될지는 알 수 없지만 추 후에 인수인계를 받게될 제자들에게 한마디 하자면,
가벼운 마음이 아니라 진심으로 서비스에 애착이 있고 스스로 도전을 찾는 사람이 될 준비가 됐다면 환영합니다.
저도 정진하겠습니다.

profile
like_learning

0개의 댓글