altair의 프로젝트 일기

이번에 드디어 취업에 성공했다! 그리고 그것보다 더 멋진 건 바로 네이버에 입사하게 되었다는 것이다! 입사일까지 며칠 시간이 남길래 이 참에 어떤 과정을 거쳐 합격하게 되었는지, 그리고 무엇보다 그 동안의 구직 활동에 대해 회고하는 글을 써보려 한다. 한 여름 밤의 꿈, 그리고 한겨울 밤의 현실 작년 한 해 동안 소프트웨어 마에스트로 활동에 최선을 다했다. 어찌나 열심히 했는지 대기업 신입 모집 몇 개 빼면 별로 지원하지 않았다. 지금와서 생각해보면 취업 시도를 거의 하지 않았던 것 같다. 가능성이 낮다고 생각한 일보다, 다시 돌아오지 않을 현재 프로젝트에 최선을 다해 많은 것을 얻어가는 것이 더 낫다고 생각했다. 그게 옳았는지는 둘째치고 원했던대로 정말 많은 것을 얻었던 시간이었다. 하지만 한 ..

서론 저번 글에서 JMeter를 사용한 부하테스트와 그 결과, 그리고 문제를 해결하기 위한 시도였던 기초적인 쿠버네티스 배포까지 다루었다. 그러나 결국 시스템의 병목은 스프링 백엔드 서버보다는 DB였던 것으로 나타났다. 심지어 백엔드 서버 인스턴스의 다중화보다 DB 커넥션풀(HikariCP)을 크게 늘리는 것이 더 효과적이었다. 쿠버네티스와 Helm 배포를 구축하려 했는데 아무래도 더 쉽게 느껴지는 DB 다중화부터 진행하기로 했다. 그래서 이에 이번 글에서는 MySQL DB를 Master - Slave로 레플리케이션한 뒤 같은 부하테스트를 해본 결과를 다루어보려한다. MySQL 복제 MySQL의 Master-Slave 토폴로지는 다른 다중 DBMS 토폴로지에 비해 굉장히 간단한 편이다. 근래에 읽은 ..

발단 저번에 면접을 보면서 면접관이 이런 말을 했다. "그래도 혹시 모르잖아요. 트래픽이 갑자기 몰릴 경우는 생각해보지 않으셨나요?" 소프트웨어 마에스트로 경험에 관한 질문이었다. 그때 우리는 각각 단일 인스턴스에 MySQL과 MongoDB를 올려 운영 서버에 사용하고 있었다. 당시에는 활성 사용자는 고사하고 가입자 수만 해도 손에 꼽을 만큼 적었기 때문에 싱글 인스턴스 DB가 아무런 문제가 없었다. 오히려 아무도 쓰지 않을 DB를 RDS 같은 곳에 올려두는 비용이 더 아까웠다. 우리라고 트래픽이 몰릴 걱정을 하지 않은 것은 아니었다. 다만 서비스 개발 자체가 훨씬 급한 업무였고 이에 트래픽 대비는 뒷전으로 밀렸을 뿐이었다. 심지어 초기 계획에는 서버에 대한 부하 테스트도 포함되어 있었다. 팀원 중 하..

서론 서비스를 개발하다보면 DB의 스키마를 변경해야 할 일이 생긴다. 특히 프로젝트 초기일수록 더 그렇다. 많은 가이드에서 프로젝트를 시작할 때 RDB보다 MongoDB 같은 NoSQL을 추천하는 이유는 스키마 변경에 있다고 생각한다. 데이터 정합성보다 쉬운 스키마 변경이 더 중요하다면 애플리케이션 단에서 데이터 어노멀리를 처리할 수 있는 NoSQL이 더 효율적일 것이다. 아이러니하게도 나 같이 RDB에 더 익숙한 초보 개발자는 NoSQL보다 RDB로 시작하는게 더 생산성이 올라가곤 한다. 대부분의 데이터는 정형화된 데이터로 나타낼 수 있고, 높은 부하의 요청은 들어오지도 않고, 작은 서버에서 처리하지도 못하기 때문이다. 스키마 변경과 불일치 문제 Spring Boot에서 RDB를 쓰는 경우 중요한 ..

회고 취준과 공부, 개발을 동시에 하려니 생각보다 셋 다 속도가 나지 않았다. 그래도 이제는 프로젝트의 개발의 패턴이 어느 정도 자리잡아 간다고 느낀다. 기술 스택과 CI/CD 파이프라인 등이 정해지니 이제 비로소 개발 본질에 집중하게 된 듯하다. 이번 글에서는 지금까지 어떤 진전이 있었고 어떤 문제와 해결이 있었는지 적어보려한다.  프론트엔드 - 디자인 반영 가장 눈에 띄는 변화는 드디어 프론트엔드 디자인의 대부분이 반영되었다는 점이다. 다음은 디자인 가이드와 실제 웹 페이지다.  몇몇 수정 외에는 거의 디자인 가이드를 따라가보았다. 사실 보고 그대로 만들기만 하면 되는 건데 뭐가 대단하냐 할 지 모르겠다. 그렇지만 이전까지 바닐라JS만 겨우 끄적대봤던 나이기에 NextJS를 통해서긴 하지만 처음으로 ..

CI/CD를 해야하는 이유 내 서버에 올라가는 서비스를 개발할 때, 나는 제일 먼저 CI/CD 파이프라인부터 구축한다. 자동화된 테스트와 통합, 배포 과정은 개발이 진행될수록 점점 그 구축 비용이 증가하는 경향이 있다. 테스트는 라이브러리와 프레임워크 의존성에 큰 영향을 받고, 통합은 VCS의 브랜치 전략 등에, 배포는 Docker, LXC 등의 서버 인프라와 Dockerfile 등의 빌드 과정에 크게 좌지우지 된다. 만약 CI/CD를 미리 구축하지 않고 개발하기 시작하면 우선 로컬에서만 테스트할 것이고, 손수 SFTP 등으로 배포하게 될 것이다. 개발이 진행됨에 따라 테스트 및 배포 비용이 부담되어 그때 가서 CI/CD 파이프라인을 구축한다면 여러 문제가 발생한다. 다음은 내가 경험한 문제들이다. 기존..