본문 바로가기

생각정리/항해99

(65)
알고리즘 1주차 알고리즘 문제를 풀 때 해당 사용해야 하는 알고리즘이 정해저 있는 부분들이 있었는데 이 부분을 해당 알고리즘을 사용하면 쉽고 빠르게 풀 수 있는 방법인 것이고 다른 방식을 찾아서 풀 수 있어 코딩 테스트에서 기발한 방식으로 풀면 좋다고 생각을 했었는데, 멘토님과 이야기를 해보니 코딩 테스트에서 문제를 냈을 때 문제를 보고 문제가 어떤 유형의 문제인지 파악을 하고 적합한 알고리즘을 떠올려 문제를 푸는 것이 중요하다고 말씀을 주셔서 알고리즘을 대처하는 방법을 조금 다르게 생각을 해야겠다. 또한, 코딩 테스트에서 문제를 풀 수 있는지만 보는게 아니라 코드를 어떻게 구성하는지 변수명은 어떻게 사용하는지 등의 코드를 작성하는 습관이나 좋은 코드로 작성을 하는지도 확인을 하는 부분이라고 말씀을 주셔서 코드를 작성하..
커리어톤 부스팅클럽 - 알고리즘 1일차 문제풀이를 매일 혼자서 하고 있었는데, 커리어톤 부스팅클럽을 하면서 다른 사람들과 팀으로 되어 문제를 풀고 문제에 대한 이야기를 하니깐 확실히 더 좋은 느낌이 있었다. 혼자 풀었을 때는 나의 생각만 알고 추가적으로 생각해 볼 수 있는 것도 다른 사람의 코드만 보고 유추하는 정도로 다른 방향을 생각해 보는 게 다이지만 같이 토론 처럼하면서 어떤 부분에서 어떤 생각을 통해서 코드를 작성했는지를 세세하게 의견을 나눌 수 있어 기존의 코드의 부족한 점을 찾을 수 있고 개선할 수 있어 좋았다.
[실전 프로젝트] 6주차 - 1 발표 준비 https://fate-twine-132.notion.site/Flash-Frenzy-eCommerce-1000-ccd72041961b4b64a49ca29c50fd3225?pvs=4 [Flash Frenzy] eCommerce 플랫폼에서 1000만 개 상품의 주문 및 조회 서비스를 제공 🌱 01 - 프로젝트 소개 fate-twine-132.notion.site 발표 준비를 하면서 여러 가지 적용했던 기술들을 다시 한번 노션에 정리하면서 새롭게 내용들을 확인을 할 수 있었고, 진행하면서는 바쁘게 하다 보니 놓쳤던 부분들 혹은 여기저기에 따로 정리했던 내용들을 합치면서 생각을 정리를 할 수 있었다. 진행하면서 틈틈이 내용들을 정리했다고 생각했는데, 필요한 자료들을 찾으려고 하니 했는데, 없는 내용..
[실전 프로젝트] 5주차 - 1 부하 테스트 서버의 Thread Pool 늘리기 동시에 10000개의 요청을 보냈을 때, 8000개 부근에서 계속해서 에러가 발생 -> 확인을 해보니 스프링 기본 max-connections가 8192개 여서 8192개 이상의 스레드가 생성되지 못해서 오류가 발생하는 것으로 예상해서 max-connections를 수정해서 테스트를 진행을 해보기로 함 max-connections를10000으로 늘리고 테스트 진행 -> 오히려 스레드 간의 콘텍스트 스위칭이 발생하여 오버헤드가 발생해 더 느려짐 스레드 문제가 아닌 것 같아 좀 더 다양한 정보를 보기 위해 모니터링 프로그램 사용을 고려해보았습니다. 프로메테우스 애플리케이션에서 발생한 메트릭을 그 순간만 확인하는 것이 아니라 과거 이력까지 함께 확인하려면 메트릭..
[실전 프로젝트] 4주차 - 2 부하 테스트 이제 기본적인 기능들은 다 추가하고 해당 기능들을 부하 테스트를 하면서 성능이 어느정도 나오는지 확인 후 병목구간이나 문제가 되는 지점들을 수정하면서 성능에 대한 기록들을 하기 시작을 했다. 주로 나눈 구간은 가장 중요하다고 생각하는 주문API를 중심으로 테스트를 하고 이후에 검색 및 조회 API들을 테스트 할 예정이다. 확인하는 방법은 먼저 로컬에서 부하 테스트를 진행해보고 너무 느리지 않으면 서버에 올려서 테스트를 진행하였는데, 생각보다 로컬과 서버간의 차이가 많이 났고, 특히 로컬 DB일 때와 AWS RDS를 사용할 때의 차이가 많이 나서 당황스러웠다. 따로 RDS를 설정해주는 부분이 있는건지 아니면 사용하고 있는 인스턴스의 성능이 문제인건지는 테스트를 좀 더 진행을 해보면서 확인을 해..
[실전 프로젝트] 4주차 - 1 Kafka 적용 Kafka 주문 결과를 우선적으로 반환 후 재고 업데이트, 주문 결과 저장 등 이후에 수행 되어도 사용자에게 큰 상관이 없는 로직들을 비동기 처리함으로 주문로직에 대한 성능을 개선했습니다. 주문 로직을 따로 데이터 스트림 구조로 만들어 성능의 저하 없이 동시에 지속적인 생산과 소비를 할 수 있습니다. 주문 API 단계 장바구니 조회 → 장바구니 구매 (담은 모든 상품) → 이벤트 상품 확인 → 주문 생성 → 상품 재고 관리 → 주문 결과 확정 Kafka 적용 카프카를 사용하지 않으면 모든 단계를 거친 후 사용자에게 응답을 해주는데, 카프카를 사용하면서 사용자들이 주문 후, 주문이 생성되고 주문 결과가 “주문 중” 으로 넘어가고 상품 재고 관리, 주문 결과 확정 과정을 비동기적으로 처리하여..
[실전 프로젝트] 3주차 - 2 Kafka 학습 및 적용 고려해보기 카프카란? 분산 이벤트 스트리밍 플랫폼, 고성능 강조 TCP 네트워크 프로토콜을 통해 통신하는 서버와 클라이언트로 구성된 분산 시스템 이벤트 스프리밍이란 ? 데이터베이스, 센서, 모바일 장치, 클라우드 서비스 및 소프트웨어 애플리케이션과 같은 이벤트 소스에서 이벤트 스트림 형태로 실시간으로 데이터를 캡처하는 방식으로 나중에 검색할 수 있도록 이러한 이벤트 스트림을 영구적으로 저장한다. 상시 접속 세상을 위한 기술 이벤트 스트리밍 사용 분야 증권거래소, 은행, 보험 등 결제 및 금융거래를 실시간으로 처리하기 위해. 물류 및 자동차 산업 등에서 자동차, 트럭, 차량 및 배송을 실시간으로 추적하고 모니터링합니다. 공장, 풍력 단지 등 IoT 장치나 기타 장비에서 센서 데이터..
[실전 프로젝트] 3주차 - 1 Jmeter 테스트 Apache JMeter는 서버가 제공하는 성능 및 부하를 측정할 수 있는 테스트 도구 JMeter는 순수 Java 애플리케이션 오픈소스이며 서버나 네트워크 또는 개체에 대해 과부하를 시뮬레이션하여 강도를 테스트하거나 다양한 부하 유형에서 전체 성능을 분석하는 데 사용할 수 있습니다. Stepping Thread Group [ this group will start ] 총 몇 개의 Thread를 발생할 것인가? [ Next, add ] 몇 개씩 더해질 것인가 ? [ threads every ] 몇 초 후에 더해질 것인가? [ using ramp-up ] Next add되는 데 걸리는 시간 [ Then hold load for ] 몇 초 동안 최대 Thread를 유지할 것인가? [ Fi..