Issuefy 아키텍처Issuefy는 AWS의 오토 스케일링 그룹과 ECS를 활용하여 트래픽 변화에 유연하게 대응할 수 있는 아키텍처를 채택했습니다. CPU 사용량이 70%를 초과하면 자동으로 스케일 아웃되어 추가 트래픽을 처리하고, 3분 동안 30% 이하로 유지되면 불필요한 리소스 낭비를 방지하기 위해 스케일 인됩니다. 최대 3개의 인스턴스까지 확장 가능하도록 설정하여 급격한 트래픽 증가에도 대비하고 있습니다.  성능 측정과 트래픽 처리그러던 중 하나의 의문이 생겼습니다. 우리 서버는 과연 초당 몇 개의 요청(TPS)을 감당할 수 있을까? 처음에는 정확한 데이터 없이 CPU 사용량이 70%를 넘으면 스케일 아웃이 트리거되도록 설정했지만, 실제로 몇 개의 요청이 발생해야 이 조건을 충족하는지는 명확하지 ..

Issuefy 목표Issuefy는 GitHub 오픈소스 생태계에 기여하고자 하는 주니어 개발자들을 위해 기획된 프로젝트입니다.주니어 개발자들은 오픈소스 프로젝트에 기여하고 싶지만, 적절한 이슈를 찾는 데 어려움을 겪거나, 'Good First Issue' 레이블을 가진 이슈가 다른 개발자에 의해 빠르게 선점되어 기회를 놓치는 경우가 많습니다. Issuefy는 이러한 문제를 해결하여 더 많은 주니어 개발자들이 오픈소스 커뮤니티에 쉽게 참여할 수 있도록 돕는 것이 목표입니다. 관심 있는 오픈소스 프로젝트들을 한곳에서 모아볼 수 있게 하고, 해당 프로젝트들에 새로운 이슈가 등록되면 알림을 통해 빠르게 참여할 수 있도록 설계했습니다. 프로젝트의 핵심 기능중 하나는 실시간 알림이었고, 이를 구현하기 위해 Serv..

대시보드의 필요성Issuefy 프로젝트를 진행하면서 기존 홈 화면을 개선할 필요가 있다고 느꼈습니다. 기존 홈 화면은 즐겨찾기 한 리포지토리와 이슈만을 표시하고 있어, 사용자에게 제공하는 정보가 제한적이었습니다. 또한 홈 화면에 필요한 핵심적인 구성요소가 부족하다고 판단했습니다. 이러한 문제를 해결하고 사용자 경험을 향상하기 위해 사용자 맞춤 대시보드를 추가하기로 결정했습니다. 접근 및 구현계획대시보드 구현을 위해 두 가지 접근 방식을 검토했습니다. RDB 직접 쿼리 방식이 방식은 데이터베이스에서 필요한 정보를 직접 추출하여 대시보드를 구성합니다.SELECT u.id, COUNT(DISTINCT l.login_date) as visit_count, COUNT(r.id) as repo_add_cou..

Issuefy 프로젝트에 통합 모니터링을 도입한 이후 하루에 한 번 이상은 특별한 이슈가 없어도 로그를 보고 있습니다. Issuefy의 API 서버는 Spring 프레임워크를 기반으로 구축되었으며, GitHub OAuth를 통해서만 로그인할 수 있습니다. 또한, JWT 기반의 인증 체계를 사용하고 있어 유효하지 않은 JWT 토큰을 포함한 요청은 인증 필터에서 거부됩니다. 의심스러운 로그 탐지그런데 로그를 모니터링하던 중 이상한 점을 발견하게 되었습니다. 인증 필터에서 지속적으로 차단하고 있는 요청들이 있었던 것입니다. 아직 개발이 완료되지 않은 상황이라 팀원들은 모두 로컬 서버에서 작업하고 있었고, 배포 서버로 요청을 보낼 만한 사람이 없었기에 이는 매우 의심스러운 상황이었습니다. 원인 파악원인을 파악하..

통합 모니터링의 필요성Issuefy 프로젝트를 진행하면서 중점을 둔 부분은 바로 모니터링 시스템의 구축이었습니다. 이전 프로젝트들에서 경험했던 문제점들을 토대로, 이번 프로젝트에서는 보다 효과적이고 안정적인 모니터링 체계를 갖추고자 했습니다. 지속적인 모니터링의 부재과거 프로젝트에서는 주로 인프라 구성과 CI/CD 파이프라인 구축에 초점을 맞추다 보니, 서비스 운영 과정에서의 지속적인 모니터링이 소홀해지는 경향이 있었습니다. 배포 자동화에만 집중한 나머지 배포 이후의 서비스 상태 모니터링은 상대적으로 간과되었고, 이로 인해 인프라나 애플리케이션에 문제가 발생해도 개발팀이 신속하게 인지하지 못하는 상황이 종종 발생했습니다. 통합된 로깅 전략 및 로그 분석 도구의 필요성서비스 운영 중 이슈가 발생하여 로그를..