728x90
반응형
### 기술적 챌린지로 생각할 만한 것들
성능/최적화
- 느림 -> 빠르게
- 많음 -> 적게
- 비용 많음 -> 비용 적게
- 과부하 개선 (연산량/메모리)아키텍쳐 개선
- 부하분산 -> 개선
- 연산량/대상 줄이기
- lazy loading (속도/용량 - 한꺼번에 처리가 어려우니, 쓸때 실행)
- eviction전략 (한정된 자원을 어떻게 효과적으로 사용할지…)
- 빈번한 접근 (캐싱)
- 서버다운/크래시 (메모리누수/메모리 부족) -> 스왑크기 조절
- 응답속도 느림 -> ... -> 빠르게
- 끊어지는 화면렌더링 -> 개선 -> 부드러운 화면렌더링
- 매우 많은 이벤트발생 -> 전부 처리하면 느려짐 -> 이벤트의 변화는 수집주기 조절 (throttling, debouncing)
알고리즘 적용
- 서비스의 특정 기능을 1-4주차 알고리즘을 적용해서 풀었다
- 로직개선 (상황에 맞는 알고리즘으로 성능을 올렸다)
좋은 구조/컴포넌트화 (확장성, low coupling, high cohesion)
- 컴포넌트 간의 의존도가 높음 -> 의존도 줄여서 확장성 높임
- (내 심장이라는 컴포넌트를, 옆사람이 볼 수 있고, 움켜쥘 수 있으면 -> 좀 이상한데 -> 커플링 심함)
동시성/동기화
- 레이스컨디션 (한정된 자원을 동시에 접근하려면 경합 -> 어떻게 처리)
- 클라이언트 간 시간 동기화
- 병렬 vs 순차 조절 구간
- 트랜잭션 처리
- 스레드를 또는 락을 쓴다가 아니라, 그런 메커니즘을 모사해서 만들어 봤다…
사용성
1. 디자인 개선 (어눌/불편 UX -> 합리/상식적 UX)
2. 조작성 개선
3. 여러 단계가 있었는데, 단계를 줄여서, 작업시간을 줄였다 -> 생산성
4. 우리가 만든 것을 극단적으로 줄여서 1 클릭에 되게 했다 -> 데모가 너무 빨리 끝났음 ㅠㅠ
(3, 4는 상황에 맞게 조절해야겠음)
가용성/안정성/확장성
- 이중화를 통해서 장애대응
- 장애조치 후 다시 master로 복구
- 이를 통한 무중단 서비스
- 트래픽/부하 증가 시 -> 스케일아웃(서버개수를 늘리기) vs 스케일업(서버사양을 올리기)
신뢰성
- 작업처리 대상 간 성능/시간차로 요청 유실이 안되게/방지 전략 (async, queuing)
- 24시간 7일 365일 죽지 않고 돌거나, 예외에 대해서 버틸 수 있어야… (error recovery, fail over, fail back)
기술적용력/파고듦
- hot한 기술을 빠른 시간에 익혀서 적용
- 만들어 보니 문제가 발생함 -> 문제의 이유를 깊이 있게 파고들어서 -> 바닥을 들여다 봄 -> 해결했다
### 오늘 작업
1. users, auth관련 refactoring작업 후 FE 작업을 위한 배포완료.
( Paas인 fly.io를 사용함, 빠른 배포를 통해 FE작업이 수월하게 이뤄질 수 있도록)
참고 블로그: https://www.whatap.io/ko/blog/9/
2.
stories
- 일기 관련 모듈
books
- 동화 관련 모듈
(books의 create는 ai service 호출(글, 그림, 목소리)하여 생성, DB저장, result 출력)
작업 순서:
1. Schema 수정: Mongoose 스키마를 정의하거나 수정합니다. 이 단계에서는 데이터베이스의 데이터 모델을 설계하며, 필요한 필드와 자료형, 제약 조건 등을 명시합니다.
2. DTO(Domain Transfer Object) 수정: 클라이언트와 서버 간에 데이터를 전송할 때 사용하는 객체를 정의하거나 수정합니다. 이 단계에서는 API 요청이나 응답에서 사용되는 데이터의 형태를 명시합니다.
3. Repository: 데이터베이스와의 상호작용을 위한 메서드를 정의합니다. 이 단계에서는 데이터베이스 CRUD(Create, Read, Update, Delete) 연산을 수행하는 로직을 구현합니다.
4. Service: 비즈니스 로직을 구현합니다. 이 단계에서는 애플리케이션의 핵심 기능을 구현하며, 일반적으로 Repository를 사용하여 데이터베이스와 상호작용합니다.
5. Controller: 사용자의 요청을 받아 적절한 서비스 메소드를 호출하고, 그 결과를 사용자에게 반환합니다. 이 단계에서는 HTTP 요청과 응답을 처리하는 로직을 구현합니다.
6. Module: 관련된 컨트롤러, 서비스, 프로바이더 등을 그룹화합니다. 이 단계에서는 애플리케이션의 구조를 정의하며, 각 모듈 간의 의존성을 관리합니다.
3.
stories
- schema, dto 추가, 위의 작업순서에 따라 crud 구현
books
- schema, dto 추가
- books의 create, update는 ai 모듈의 틀이 나와야 작성가능하기에 read, delete 구현
4. s3 연결작업
aws s3 설정:- 모든 퍼블릭 액세스 접근
728x90
반응형
'Storify' 카테고리의 다른 글
STORIFY (0123) - 단일 책임 원칙 (0) | 2024.01.24 |
---|---|
STORIFY (0122) - 종속성 순환 문제, 페이지네이션 (0) | 2024.01.23 |
STORIFY (0119) - API 구조 변경 (0) | 2024.01.19 |
STORIFY (0118) - s3 연결 (0) | 2024.01.18 |
STORIFY (0116) - DB Schema 설계 (0) | 2024.01.16 |