프로젝트 경험기 17

파일 관리 서비스 3 - S3 이미지 리사이징 서비스 만들기 (by. CloudFront, Lambda@Edge)

개요웹 페이지 서비스에서 스토리지(S3)에 가지고, 사용하고 잇는 원본 이미지 크기가  720 x 360 라고 가정하자하지만 페이지에 따라 640x360, 1200x600 등등 출력할 화면이 있다고 가정할 때.. (추후 2:1 비율의 다양한 이미지 사이즈가 추가 될 수 있음) 어떻게 효율적으로 관리 할 수 있을까? 접근 및 방법1. 그냥 720x360 이미지를 활용하자니-> 더 작은 이미지(320x160)를 호출하는 곳에서는 더 큰 이미지(720x360)를 불필요한 호출 리소스가 사용된다.  2. 각 사이즈의 이미지를 만들어 올려놓자니-> 크기가 바뀔 때마다 매번 관리(업로드) 해야 하고, 스토리지(S3)에 저장하는 것도 부담일 수 있음 관리 비용도 적게 들고, 스토리지도 효율적으로 사용하면서, 확장에도..

[시스템 장애] Cron 작업 과부하에 따른 서버 장애 발생

상황서버 CPU나 메모리가 일정 임계선을 넘어 서, 서비스에 장애가 생기는 경우 복구를 위해 서비스 재부팅 + 알림 메일이 오게 설정해두었는데, 3일 연속 자정에 서버가 임계선을 넘어가 재부팅 되었다는 알림 경보 메일을 받게 되어, 3일차에 문제 해결에 들어가게 되었다.(처음 1일 때는 일시적인 현상으로 지켜보면서 모니터링 만 하다가, 2~3일 때 반복적인 발생하는 이슈로 보았음) 문제 파악다른 시간대에는 문제가 없고, 자정에만 문제가 생기는 것으로 보아, 자정에 실행되는 이벤트 들에 문제가 있다고 생각하여 해당 크론들을 파악하게 되었다.(아래 AWS 지표를 볼 때, AWS는 기본 5분 단위로 평균을 집계(옵션 및 추가 비용을 내면 1분마다 집계 가능) 하여 그래프로 나타내준다. 23시 55분 ~ 00시..

[리팩토링] (3) early-return 적용하기

배경 복잡한 if-else  중첩 구조에 대한 수정  과정👉 리팩토링 전 - api.py 의 함수에 다음과 같은 조건문이 적혀있었고, 유지보수와 이해(가독성)에 매우 어려움이 존재# 리팩 전if a: if b: if c: return '성공' else: raise ApiError(에러c) else: raise ApiError(에러b)else: raise ApiError(에러a) 👉 리팩토링 후- 부정 문으로 상위 조건인 경우 return(raise)를 진행함 . early-return 을 통해 가독성 개선# 리팩 후if not a: raise ApiError(에러a)if not b: raise ApiError(에러b)if n..

파일 관리 서비스 2 - S3 폴더 구조 설계

S3(스토리지) 폴더 구조 설계하기스토리지에 파일을 저장할 때 다양한 기준으로 폴더 구조를 설계 하여 저장 할 수 있다.S3는 내부적으로 데이터를 파티셔닝하여 분산 저장하는데, 우리가 할 수 있는 폴더 구조, prefix 등을 잘 활용하여 설계 할 수록 성능적인 이점 뿐만 아니라 관리 자체를 효율적으로 할 수 있다. 설계 방법에 대한 규칙의 특징이 대해 알아본다. 날짜 기반 구조 (Date-Based Structure)예시2024/08/18/files/...2024/08/17/files/......2022/05/19/files/...특징백업, 로그 파일, 일별/월별 데이터 저장 관리시 적절날짜 기준 데이터 조회시 폴더 구조가 명확해져 검색 성능 개선단 files/ 아래에 파일들이 많을 때는 추가 규칙 p..

파일 관리 서비스 1 - 업로드 (Presigned URL)

개요많은 서비스가 사용자로 부터 파일을 받아, 이를 스토리지 등에 저장 해 두고 관리한다. 업로드 간 올바른 데이터가 잘 업로드 되도록 검증하거나, 유출되면 안되는 중요한 정보도 있기 때문에 이를 잘 관리하는 것 또한 중요하고, 스토리지가 유저에 의해 오남용 되는 경우도 주의해야 한다. 해당 글에서는 다음 정보에 대해 알아본다.파일 업로드 간 올바른 데이터(무결성) 관리를 위한 검증 목록파일 업로드 시 스토리지 접근 주체 (BE vs FE)파일 업로드 Presigned URL 방법 파일 업로드 간 올바른 데이터(무결성) 관리를 위한 검증 목록파일  간 꼭 모든 사항을 필수적으로 검증해야 하는 것은 아니고, 서비스에 맞게 하면됨.대분류소분류내용1. 파일 형식 검증확장자 검증file 이름에서 확장자 검증  ..

[기타] 슬랙 커스텀 앱 봇 만들기

셋팅 방법1. 슬랙 워크 스페이스의 앱에 대한 기본 Key 및 옵션 설정다음 링크 참조 2. 최종 Key 획득다음 key들은 프로젝트 내 환경변수로 관리SIGNING SECRET : ... hashSLACK_BOT_TOKEN : xoxb- ... SLACK_APP_TOKEN(=Socket Token) : xapp-... 3. 로컬 프로젝트 생성슬랙 API 에서 공식 지원하는 - Bolt Python 으로 작성 [링크]슬랙 API 사용 중 필요 권한은 1. 에서 계속 추가 설정코드 배포 4. 슬랙 채널에 앱 추가만든 커스텀 앱을 채널에 등록한다. 5. 트러블 슈팅설치할 봇 사용자가 없습니다. : 앱 명을 자꾸 바꾸다가 발생하였었음 추가슬랙에는 Custom 앱 을 만드는 방법 외에, 주어진 extension..

[기타] 임시 저장 서비스 경험기

임시 저장 서비스사내에서 임시 저장 서비스를 구현하면서, 어떻게 할 것인가.. 어떤 방법이 좋은가에 대해 고민했던 부분을 공유해보려고 한다. 결과적으로, 설계 당시에 선택한 방법이 가져올 문제점 등에 대해 충분히 고려하지 못해 나중에 수고스러워 지는 부분도 있었던 것도 같고, 다음에 구현하게 될 때 좀더 빠르고 정확하게 할 수 있도록 기록을 남겨 보려 한다. 임시 저장 서비스 기능 요구 사항상태 : 임시 저장, 생성 완료 (발행)임시 저장 데이터 : 생성, 수정, 삭제, 조회 가능완성 데이터 : 생성, 수정, 삭제, 조회 가능데이터 목록 : 임시 저장, 완성 데이터는 같이 조회가능 해야 함중요 : 완성 데이터가 있어도 임시 저장 데이터가 유효 해야 함중요 : 사용자는 하나의 객체에 대해서만 생서/수정 한..

[기타] 에러 핸들링 (Error Handling) 처리 경험기

에러 핸들링 구현기 프로젝트를 진행하며 초기 셋팅시, 에러에 대한 핸들링 처리를 통해 서버에 대한 신뢰도와 안정성을 높이는 작업을 진행하였고, 해당 과정에서 최종 정의한 에러 범위에 대한 정의, 정의 간 고려사항, 처리 방법 등에 대해 정리 해보았다. 에러 핸들링 처리는 목적은 다 똑같지만.. 범위나 방법 등에 대해서는 기업마다 팀마다 다를 것이라고 생각한다. 에러 핸들링 이란? 런타임 과정, 혹은 특정 예외 상황에서 발생하는 에러/비정상적인 상황들 (ValidationError, AuthError, ServiceLogicError 등)에 대해 직접 의도된 동작으로 처리 하는 기술 에러 핸들링의 주요 목표는 다음과 같다. - SW의 비정상적인 종료들로 인한 사용자 경험 저해 방지 - 프로그램에 대한 안정..

[리팩토링] 가독성 높이기 - 함수명 개선

배경몇달간의 프로젝트를 진행 후에,서로 다른 코드 스타일, 모듈들의 역할에 대해 상이하게 생각한 부분 등의 문제점들이 발견되었고,2주 간의 리팩토링을 진행하는 시간을 가지게 되었다. 다음 글에서는 리팩토링을 진행 하면서, '가독성 높이기 - 함수명 개선' 에 대한 경험을 공유 하려 한다. 가장 큰 목적은 여럿이서 작성한 다양한 함수명 틀을, 조금이나마 비슷하게 맞춰 가독성을 높이는데 중점을 두었다. 함수명 개선 간 나름 정한 규칙은 다음과 같다- Service Class 명도 해당 함수에 같이 의미 해석 된다.- check, validate, in 등의 비슷한 결의 함수명을 가지게 함 사례 1 - 함수명 개선 하기👉 변경 전 코드## 변경 전 코드# main.pyUserService.update_use..

[리팩토링] 공통 코드 줄이기

배경몇달간의 프로젝트를 진행 후에,서로 다른 코드 스타일, 모듈들의 역할에 대해 상이하게 생각한 부분 등의 문제점들이 발견되었고,2주 간의 리팩토링을 진행하는 시간을 가지게 되었다. 다음 글에서는 리팩토링을 진행 하면서, '공통 코드를 줄이는 것' 에 대한 경험을 공유 하려 한다. 과정👉 리팩토링 전 프로젝트 구조router/ : api 및 service/ return 값에 따른 error handling 수행service/ : 비즈니스 로직 작성 및 결과에 따른 return 성공 여부 반환즉 router에서 service 로직을 호출하여 수행하다가, 성공 여부를 router로 반환해, 핸들링 된 에러로 유저에게 응답하는 방식초기에 이렇게 작성했던 이유는 api 별로 error 흐름을 파악하기 쉽다. ..