2024-05-24 체인저의 API 명세서와 협업
[10분 테코톡] 체인저의 API 명세서와 협업 (youtube.com)
프론트와 백엔드 개발자는 API 명세서와 여러가지 의사소통을 통해서 협업을 한다.
API 명세서란?
=> API의 기능, 동작, 사용법 등을 나타낸 문서
API 명세서 구성
- 이름 및 설명 : API 이름과 설명
- 기본 정보 : Host 주소, EndPoint, HTTP Method
- Request : Header, Parameter, Body
- Response : Header, Body
여기서 추가적으로 API 호출의 예시와 여러 응답의 예시가 추가된다면 더욱 좋음
" API 명세서만 보고도 사용할 수 있는가? " 를 기준으로 잡고 API 명세서를 작성하면 좋음
프론트와 백엔드 협업 효율적으로 하는 4가지 방법
1. 구현 전에 API 설계를 꼭 진행하자
2. API 설계할 때 소통을 하자
3. API 업데이트를 사전에 공유하자
4. 상대방 입장에서 설명하자
2024-05-25 최소 신장 트리와 최단 경로 알고리즘
[10분 테코톡] 썬샷의 최소 신장 트리와 최단 경로 알고리즘 (youtube.com)
그래프의 최소 신장 트리 알고리즘
- 간선들 중 가장 낮은 가중치를 선택하여 트리에 순차적으로 추가한다.
- 사이클을 생성하는 간선은 트리에 추가하지 않고 제외한다.
- 이 과정을 통해 최소 신장 트리가 구성되며, 남은 간선은 고려 대상에서 제외된다.
프림 알고리즘
- 프림 알고리즘에서는 시작 정점 하나를 트리에 추가하고, 최소 가중치의 간선을 찾아서 트리 집합에 포함시킴.
- N-1번까지 간선을 선택하고 인접한 정점을 트리에 추가하여 알고리즘을 완료.
- 시작 정점 선택이 임의적이며, 간선 선택 후 인접 정점 추가 과정을 반복하여 마침.
- 이를 통해 프림 알고리즘은 끝나게 됨.
다익스트라, A* 알고리즘 (최단 경로 알고리즘)
- 최단 경로 알고리즘은 두 정점을 연결하는 간선을 최소 비용으로 찾는 문제이다.
- 다익스트라 알고리즘과 A* 알고리즘이 나온 과정을 설명하며, 다익스트라의 과정은 cost와 visit를 활용하여 정점 간 비용을 계산한다.
- cost는 충분히 큰 값으로 초기화하고, visit에 정점을 추가하며, 반복하여 최소 비용의 정점을 선택하고 비용을 갱신한다.
- visit에 남아있는 정점이 없을 때까지 반복하면 알고리즘이 완료된다.
2024-05-26 오도의 정렬 알고리즘
[10분 테코톡] 오도의 정렬 알고리즘 (youtube.com)
삽입 및 퀵 정렬 알고리즘
- 삽입 정렬은 안정 정렬로, 추가적인 메모리를 필요로하지 않고 제자리 정렬이다.
- 최선의 경우 시간복잡도는 O(N), 정렬된 배열에서는 N제곱의 시간 복잡도를 갖는다.
- 퀵정렬은 pivot을 기준으로, 불안정 정렬로 좌측은 작고 우측은 큰 값을 정렬한다.
- 퀵정렬의 각 단계에서 포인트 위치가 겹치면 두 요소 위치를 바꾸며, 정렬을 수행한다.
팀정렬, 병합 정렬 알고리즘
- 병합정렬은 하나의 리스트를 두 개의 균등한 크기의 부분 리스트로 분할하고 정렬한 후 병합하는 알고리즘.
- 병합 과정에서 작은 값들을 찾아서 정렬하고, 안정 정렬로서 최악의 경우에도 항상 NlogN을 유지함.
- 메모리 사용량이 많은 단점을 가진 `팀정렬` 소개.
- `팀정렬`은 합병 정렬과 삽입 정렬이 혼합된 하이브리드 알고리즘인데, 현실 데이터 정렬에 적합.
- 각 정렬 알고리즘은 장단점을 보완하여 발전해왔는데, `팀정렬`은 병합 정렬의 느림과 메모리 소모량을 개선하여 개발되었다.
- 특히 데이터 비교 비용이 많은 현실 데이터에 적합한 안정 정렬이며, 병합 정렬에 비해 성능을 보장하는 장점이 있다.
메모리 사용량을 줄이는 팀정렬과 시간 복잡도
- 병합 과정 중에 정렬이 필요한 부분만 병합하여 메모리 사용량을 최소화하는 기법 활용.
- 팀정렬은 안정정렬이며, 최선 시간 복잡도는 O(N), 최악 시간 복잡도는 NlogN.
- 이진 탐색을 통해 13보다 작은 값과 17보다 큰 값을 찾아낸 후 정렬이 필요한 부분만 병합함.
- 기존의 2배씩 뛰어넘어가며 구간을 탐색하는 방식을 활용하여 팀정렬 알고리즘 실행.
2024-05-27 연어의 DB Partitioning
[10분 테코톡] 연어의 DB Partitioning (youtube.com)
파티셔닝이란 간단하게 이렇게 하나의 논리적인 테이블을 여러 개의 물리적인 테이블로 나누는 것
MySql에서의 파티션 처리
- 파티셔닝을 하려면 기준이 필요하며, 파티션 표현식은 기준으로 사용된다.
- 업데이트 시, 파티션 키 이외의 컬럼이 변경될 때는 파티션이 물리적 위치와 함께 변경되지 않으며, 저장된 위치에서 수정이 이루어진다.
- 파티션 키 컬럼이 변경될 때는 물리적으로 저장된 위치를 찾아 기존 데이터를 삭제하고 업데이트 후 새로운 파티션에 저장한다.
SQL 쿼리 최적화를 위한 파티션 활용 방법
- 파티션 설정 시 WHERE 절을 활용하고, 효율적으로 인덱스를 사용할 수 있는지 중요하다.
- 예를 들어, 출생년도를 기준으로 파티션을 구분하고, SELECT 쿼리를 통해 파티션 접근을 최적화하여 실행 계획 설정이 가능하다.
- 커버링 인덱스와 인덱스 레인지 스캔을 통해 파티션을 최적화하여 가장 효율적인 쿼리로 만들 수 있다.
쿼리 최적화와 파티션 역할
- 첫 번째 쿼리는 인덱스 레인지 스캔을 통해 효율적인 결과를 도출한다.
- 두 번째 쿼리는 WHERE 절이 없어 모든 파티션을 접근하며 머지 작업이 필요하다.
- 세 번째와 네 번째 쿼리는 피해야 하는 것이 좋으며, 풀테이블 스캔이 들어가 느린 쿼리를 유발한다.
- 파티셔닝의 목적 중 하나는 작업 범위를 좁히기 위함이며 PK와 UK 테이블은 파티션 키 컬럼을 포함해야 한다.
MySQL 파티션 종류: 레인지, 리스트, 해시, 키
파티션 설계 방법과 주의사항
- 파티션된 데이터에서 일부 파티션만 접근하는 예시로, 옵티마이저가 접근할 필요가 없어서 좋은 예시이다.
- 데이터를 균등하게 접근하면 오버헤드로 평가 시간이 증가하고 데이터 머지로 인한 작업이 발생해 효율성이 감소한다.
- 이런 경우, MySQL 대신 물리적 10개의 샤딩을 사용하는 것이 효율적이다.
- 파티션 전에 가능한 많은 상황을 고려하여 설계해야 한다.
2024-05-28 키아라의 스프링 트랜잭션 전파
[10분 테코톡] 키아라의 스프링 트랜잭션 전파 (youtube.com)
트랜잭션 타입: Required와 Requires_New
- 트랜잭션 타입에는 Required와 Requires_New가 있다.
- Required는 기존의 트랜잭션이 있을 경우에는 해당 트랜잭션에 참여하고, 없을 경우에는 새로운 트랜잭션을 생성한다.
- Requires_New는 기존의 트랜잭션이 있든 없든 항상 새로운 트랜잭션을 생성한다.
- 나머지 타입들은 이 두 가지를 충분히 이해하면 적용할 수 있다.
물리 트랜잭션의 커밋, 롤백은 신규 트랜잭션에서만 가능
- 신규 트랜잭션만이 물리 트랜잭션을 커밋이나 롤백 할 수 있음.
- 영화 서비스 예매와 이력 저장을 하나의 트랜잭션으로 묶는다.
- 트랜잭션은 다른 곳에서도 사용되므로 각각은 별도의 트랜잭션을 가짐.
- 이때 신규 트랜잭션이 생성되며, 트랜잭션은 커밋, 롤백하는 방식으로 종료됨.
트랜잭션 묶는 과정을 그림으로 확인해보고, 각 트랜잭션이 새로운 트랜잭션인지 확인해 원하는 대로 묶어서 실행해보는 과정을 확인
트랜잭션 분리를 위해 requires_new 전파 타입 사용
- requires_new는 물리 트랜잭션을 완전히 분리하는 타입이다.
- 각각의 커밋과 롤백은 서로에게 영향을 미치지 않기 때문에 트랜잭션 분리에 적합하다.
- 트랜잭션 AOP가 롤백을 요청할 경우, 먼저 requires_new 속성에서 생성된 신규 트랜잭션의 로직이 먼저 처리되고, 다시 넘어오면서 롤백이 되는데, 이 때 물리 롤백이 진행된다.
- requires_new을 사용하면 트랜잭션의 수가 늘어나므로, 웹 요청 수만큼 DB 커넥션을 사용하므로 성능 고려가 필요하다.
사용자가 실망하지 않도록, 로그 저장 실패에도 예매는 유지되어야 한다.
2024-05-29 망고의 DeadLock
[10분 테코톡] 망고의 DeadLock (youtube.com)
데드락 == 교착상태
교착상태라는 건 서로 다른 둘 이상의 프로세서들이 상대 프로세서가 차지하고 있는 자원을 기다리는 무한 대기 상태
프로세스 스케쥴링 조건들
- '상호 배제'는 한 프로세스만 자원을 사용할 수 있어야 함
- '비선점' 조건은 다른 자원을 빼앗을 수 없는 조건
- '순환 대기' 는 프로세스들이 자원을 순환 대기해야 한다는 조건
데드락 현상과 MySQL에서의 처리 방법
2024-05-30 루카의 CI/CD
[10분 테코톡] 루카의 CI/CD (youtube.com)
혼자 개발 할 때가 아닌 팀 개발을 할 때에 main branch에서 각각의 개발자들이 개발할 기능을 pull해서 가져옴,
그 다음 구현이 되면 Merge 혹은 PR을 올리는데 이때 충돌이 발생할 수 있음
이러한 문제를 해결하기 위해 CI가 필요함
CI = 지속적 통합
-> 동일한 프로젝트를 진행하는 모든 사람이 정기적으로 코드 베이스의 변경사항을 중앙 저장소에 병합하는 방식
CD = 지속적 통합에 이어 프로덕션 배포까지 자동화
CI/CD 파이프 라인
개발 -> 빌드 -> 테스트 -> 릴리즈 -> 배포
그 외에 Jenkins와 gitAction에 관한 설명들
CI/CD의 기초적인 개념에 대한 발표
2024-05-31 로지의 AWS 사용팁
[10분 테코톡] 로지의 AWS 사용팁 (youtube.com)
1. 비효율을 감지하자
= 특정 업무가 주어질 때 현재 하고 있는 방안이 최선인지, 비효율적이지는 않은지 항상 고민하고 생각하기
-> QWS는 솔루션으로 돈을 벌기 때문에 기술 발전이 매우 빠름 -> 싸고 좋은 기술이 묻혀있을 수 있음 잘 찾아보기
2. 구글링 할 때 마법의 단어인 "solution을 붙히면 좀 더 거시적인 관점 (클라우드 관점)으로 검색이 가능
= 코드를 작성하지 않고서도 문제를 해결할 수 있는 방법이 있을 수 있음
3. 일단 재미로 보고 듣기
= AWS를책보고 강의보며 기초를 다지기엔 시간이 너무 부족할 뿐더러 제공되는 solution이 너무 많음
따라서 가볍게 볼 수 있는 20분 정도 되는 유튜브 영상들을 재밌게 볼 수 있고, 정말 잘 되어 있음
이러한 가벼운 영상들을 재미로 보면서 학습하면, 비교적 내가 신경쓰지 못했던 것과 앞으로 내가 적용해볼 것들을 얻을 수 있음
2024-06-01 주디의 Spring Bean
[10분 테코톡] 주디의 Spring Bean (youtube.com)
스프링 빈과 IoC 컨테이너에 대해 다룸. 빈이란 스프링 IoC 컨테이너가 관리하는 객체이며, 의존성 주입을 통해 객체 생성과 의존성 관리를 자동화함. 싱글톤 패턴의 단점을 극복하고 객체 라이프사이클을 관리하는 방식을 설명. 또한 @Primary, @Qualifier 어노테이션을 사용하여 의존성 주입 시 우선순위를 지정하는 방법을 소개
- 의존성 자동 주입의 필요성
객체를 빈으로 등록하지 않고 의존성을 직접 주입하면 의존 관계를 모두 파악해야 하는 번거로움이 생기고, 많은 객체가 중복 생성될 수 있다, 따라서 의존성 주입이 필요한 객체를 빈으로 등록하여 스프링 IoC 컨테이너가 객체 생성과 의존성 주입을 관리하도록 해야 한다.
- 싱글톤 패턴의 단점
스프링이 아닌 개발자가 직접 싱글톤 패턴을 적용하면 다형성을 이용할 수 없고, 단위 테스트가 어려워짐. 하지만 스프링 IoC 컨테이너는 싱글톤 레지스트리를 통해 동일한 객체를 반환하므로 이러한 단점을 해결함.
- 스프링 IoC 컨테이너의 빈 관리 방식
스프링 IoC 컨테이너는 Bean Definition 정보를 이용하여 빈을 생성하고, 싱글톤 레지스트리에 빈의 이름을 키로, 객체를 값으로 저장. 의존성 자동 주입을 통해 의존 관계를 설정하고, 필요한 객체를 초기화한 후 빈을 사용할 수 있음. 컨테이너 종료 시 싱글톤 빈도 함께 소멸.
- 빈 설정 시 주의사항
싱글톤 스코프의 빈이 상태를 가지면 스레드 안전성 문제가 발생할 수 있으므로 상태를 가지면 안된다. 상태가 필요한 경우 프로토타입 스코프를 사용해야 함. 또한 의존성 주입 시 구현체가 여러 개라면 @Primary나 @Qualifier 어노테이션을 사용하여 우선순위를 지정해야 함.
2024-06-02 베베, 허브의 성능 테스트
[10분 테코톡] 베베, 허브의 성능 테스트 (youtube.com)
성능 테스트의 중요성과 지표
- 성능 테스트는 서버 동작 상황을 확인하며, 가용성 향상과 목표치 달성을 위한 필수 과정이다.
- 주요 지표로 처리량(RPS)과 응답시간을 확인하며, 병목 구간을 개선해야 전체 성능 향상에 성공할 수 있다.
- 성능 향상 시 병목 구간 이동에 주의해야하며, 올바른 부분 개선이 전체 성능 향상에 중요하다.
- 예를 들어, MySQL 처리량 100 rps에서 300 rps로 향상될 경우 톰캣으로 병목 구간이 이동하여 전체 시스템 처리량이 영향을 받는다.
시스템 응답 시간과 성능 개선 전략
- 응답 시간은 요청을 받아 처리하는 시간을 포함하며, 시스템 성능 평가의 중요한 지표이다.
- 시스템 A가 100ms 안에, 시스템 B가 200ms 안에 응답하면 성능 차이로 볼 수 있다.
- 응답 시간 개선은 전체 시스템 성능 향상에 영향을 미치며, 서브시스템 중 가장 긴 부분부터 개선하는 것이 효과적이다.
- 처리량 개선은 응답시간 단축으로 연결되며, 응답시간 단축은 처리량 향상과 연결된다.
다양한 성능테스트 유형 및 테스트 도구
- 성능 테스트에는 스모크, 스파이크, 부하, 스트레스, 내구, 중단점 테스트가 있으며, 각각 시스템의 다양한 측면을 확인한다.
- 스모크는 시스템의 최소 부하 확인, 스파이크는 급증 상황 테스트, 부하는 일반 부하 대비 기능 확인, 스트레스는 최대치 시스템 동작 확인, 내구는 장기 부하 확인, 중단점은 한계 지점 파악하는 테스트이다.
- 테스트 도구로는 JMeter, K6, nGrinder 등 대표적 성능테스트 툴을 활용한다.
- API 호출로 정상 부하 확인하며, 이어지는 실습에서 테스트 도구 활용 가능하다.
nGrinder: 한국 개발자들에게 유용한 오픈소스 부하 테스트 툴
서비스 사용자 증가에 따른 테스트 결과 파악
- 서비스의 사용자 증가 시기를 파악할 때, 출퇴근 시간의 대중교통 서비스나 페어매칭 시간의 LMS 등 사용자가 많은 시기 고려.
- 테스트 수행 시 200 명의 사용자 측정 및 테스트 서버와 데이터베이스의 사용자 수 고려하여 테스트 진행.
- 응답 시간은 300ms 이하여야 함을 전제로 200명의 동시 사용자를 고려한 nGrinder 테스트 계획.
- 사용자의 테스트 스크립트 작성 시, think time을 1초로 설정하여 유저가 1초에 한 번의 요청만 가능하도록 가정.
2024-06-03 민트의 DI
[10분 테코톡] 민트의 DI (youtube.com)
이 요약은 영상의 코드와 함께 봐야 이해가 잘
푸드 파이터 객체 생성과 사용의 책임 분리
- KoreanChef 구현체 생성 책임에서 클라이언트에게 객체 결정과 생성 책임 전가.
- 푸드 파이터는 셰프 인터페이스를 구현한 객체만 받아들이며, 먹는 것에 집중.
- 개방 폐쇄 원칙 준수하여 변경에 닫혀 있으면서도 확장에 열려 있음.
- 셰프 구현 변경시 푸드파이터 코드 변경 없음. 폐쇄성과 확장성 유지.
셰프 생성 책임을 팩토리 클래스에 위임하여 객체 생성과 DI,IoC 개념
- 푸드 파이터에게서 셰프 생성 관심사를 떼어냈고, 클라이언트에게 책임을 부여하던 중, 객체 생성을 위한 팩토리 클래스 도입.
- 팩토리 클래스에서는 chef 메서드로 셰프의 구현체를 생성하고 반환, 푸드 파이터는 해당 셰프 객체를 주입 받음.
- 이로 인해 클라이언트 코드가 받은 객체를 사용하는데 집중하고, 객체 생성 방법은 팩토리 클래스만이 담당함.
- IoC는 제어의 역전으로 설명되며, 푸드 파이터가 제어권을 가진 기존 구조에서 벗어나 객체 생성 방식을 위임하는 개념을 소개함
IoC와 DI를 적용하여 유지보수 용이한 결합 의존 관계 확립
- 팩토리 클래스와 IoC를 도입한 결과, 푸드 파이터는 팩토리가 생성한 셰프를 사용하며 팩토리가 제어권을 가지게 됐다.
- 이어서 DI(의존 관계 주입)을 통해 푸드 파이터에게 셰프를 생성자로 외부에서 주입하여 의존성 관계 설정이 가능해졌다.
- 이는 생성과 사용의 책임을 분리하며 느슨한 결합의존 관계를 구축함으로써 유지보수가 용이해진다.
- 결론적으로, 의존성 주입과 IoC(Inversion of Control)를 통해 탄력적인 의존 관계를 형성하여 시스템의 유지보수를 용이하게 한다.
스프링의 DI와 IoC의 관계, 스프링 컨테이너의 역할
- 스프링은 DI를 편리하게 사용하게 해주는데, IoC를 제공하며 애플리케이션 오브젝트를 관리한다.
- 스프링은 스프링 컨테이너를 통해 DI를 수행하며, IoC를 적용한 컨테이너로 기능을 한다.
- 스프링 컨테이너, IoC 컨테이너, DI 컨테이너 용어가 혼용되지만 핵심은 스프링은 IoC를 적용한 컨테이너를 사용한다.
- 스프링은 팩토리 클래스를 직접 구현하지 않고도 IoC 개념을 활용할 수 있는 프레임워크 기능을 제공한다.
스프링 프레임워크의 IoC, DI, 객체지향 철학의 중요성
- 스프링은 IoC, DI, 객체지향을 기반으로 하는 편의 제공 도구임.
- 프레임워크 사용뿐 아니라, 해당 철학과 핵심을 파악하는 게 중요.
- IoC와 DI는 객체지향 설계를 충실히 적용한 코드의 특징.
- 개발자에게 스프링의 철학 이해가 중요함을 강조.
2024-06-04 주드의 Server Sent Events
[10분 테코톡] 주드의 Server Sent Events (youtube.com)