본문 바로가기
Storify

STORIFY (0117) - 기술적 챌린지

by Peter.JH 2024. 1. 17.
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/

 

클라우드 서비스 이해하기 IaaS, PaaS, SaaS | 와탭 블로그

클라우드 컴퓨팅, IaaS, PaaS, SaaS이란?

www.whatap.io

 

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