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

인프런 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의를 들으며 학습하고 정리한 내용을 자유롭게 쓰고자 합니다. kubernetes 기본 동작 방식쿠버네티스의 기본 동작 방식은 다음과 같은 흐름으로 이루어진다.pod 요청 -> kube API -> kubelet -> 컨테이너 런타임 -> 커널 레벨 격리(chroot), 리소스 분배(cgroup), 프로세스 격리(namespace)이 과정에서 각 컴포넌트는 중요한 역할을 수행하게 된다.사용자나 시스템이 pod 생성을 요청하면, 쿠버네티스 API 서버가 이를 처리하고 kubelet에게 지시를 내린다.kubelet은 이 요청을 받아 컨테이너 런타임에게 실제 컨테이너 생성을 요청하고, 컨테이너 런타임은 Linux 커널의 기능들을 활용하여 컨테..

프로그래머스에 새로운 문제가 올라왔길래 오랜만에 풀어보았다.최초에는 완전탐색으로 접근하면 시간초과가 나는걸 알면서도 다른 로직이 안떠올라서 일단 완전탐색으로 구현하고이진탐색으로 수정해서 풀이에 성공했다. 로직배열의 크기가 300,000 이므로 완전 탐색으로 접근하면 100% 시간 초과가 난다.여기서 이진 탐색을 떠올려야 하는데, level의 최댓값이 diffs 요소중 가장 큰 값이라는걸 캐치해서 풀어야 한다.그러므로 1 level의 최솟값 이진탐색으로 level의 값들을 cal 함수에 넣어주면서 탐색하면 최종적으로 level의 최솟값이 나오게 된다. cal 함수에서는 제한시간을 넘으면 탐색을 중지하고 False를 반환하고, 제한시간안에 모든 탐색을 끝냈다면 True를 반환한다. cal 함수의 반환 결과에..

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 파이프라인 구축에 초점을 맞추다 보니, 서비스 운영 과정에서의 지속적인 모니터링이 소홀해지는 경향이 있었습니다. 배포 자동화에만 집중한 나머지 배포 이후의 서비스 상태 모니터링은 상대적으로 간과되었고, 이로 인해 인프라나 애플리케이션에 문제가 발생해도 개발팀이 신속하게 인지하지 못하는 상황이 종종 발생했습니다. 통합된 로깅 전략 및 로그 분석 도구의 필요성서비스 운영 중 이슈가 발생하여 로그를..

2024년 5월 16~17일에 열렸던 AWS Summit Seoul 2024에 다녀왔다.작년부터 꼭 가고 싶던 컨퍼런스여서 신청이 열리자마자 신청했고, 기대를 많이 했다. 이번에는 Hana와 Frod와 함께 가게 되었는데, 작년 우아콘 경험을 토대로 시작시간에 맞춰가지 않으면 입장까지 한참 걸린다는 것을 알아서 입장 시간에 맞춰 들어가기로 했었다. 그러나... 코엑스가 꽉 찰 정도로 많은 개발자분들이 오셨고, 입장까지 30분을 넘게 줄을 서서 들어가게 되었다.기조연설은 직접 듣고 싶었는데 도저히 자리가 나지 않아 중계 홀에서 듣게 되었다.이번 컨퍼런스는 코엑스 4개의 층을 사용했는데 생각보다 각 층과 홀을 이동하는데 시간이 많이 소요돼서 쉬는 시간마다 바쁘게 움직였다.요즘 가장 화두인 AI에 대한 이야기..

30분이면 풀 수 있을 줄 알았지만 몇 시간을 고민한 문제이다. 각 열을 돌면서 매번 bfs를 탐색해도 시간초과에 안 걸릴 것 같았는데, 효율성 테스트에서 전부 시간 초과가 나서 bfs 탐색이 끝나면 각 열에 오일 개수를 추가하는 로직으로 풀이에 성공했다. 로직 일반적인 bfs와 다른점은 bfs 탐색이 끝나면 석유가 있는 열 set을 따로 만들어서 set을 순회하며 원래 oil 리스트에 인접 영역의 석유의 양인 cnt을 더해주는 것이다. 이렇게 하면 bfs 탐색은 한 번만 실행하고 석유가 있는 인접영역을 모두 열에 추가하여 답을 구할 수 있다. 최종 코드 from collections import deque def solution(land): answer = 0 n, m = len(land), len(l..