잉여개발자

개요초기 단계의 간단한 프로젝트의 경우에는 데이터베이스 구조가 자주 변하지 않거나, 작업자가 히스토리를 잘 아는 경우직접 SQL 쿼리를 실행하거나, ORM을 사용해 수작업으로 데이터베이스를 업데이트하는 방법으로 DB Migration을 관리 할 수 있다. 하지만 여러 명의 개발자가 동시에 작업하거나, 빈번한 스키마 변경(모델 자주 수정, 새로운 테이블 등 추가), 다양한 환경(개발, 스테이징, 프로덕션 등)에서 데이터베이스를 관리해야 하는 경우, DB Migration 히스토리를 관리하는 것은 DB 상태를 관리하는데 중요하다. 이를 잘 관리하기 위해 다양한 마이그레이션 도구가 존재한다. 마이그레이션 도구 사용시 장점1. 스키마(모델) 자동 관리- 테이블, 컬럼, 인덱스, 키 등의 추가, 수정, 삭제 같은..

이미지 리사이징 서비스 설명서비스 소개 및 설명은 아래에 나와있다. https://yubi5050.tistory.com/332 파일 관리 서비스 3 - S3 이미지 리사이징 서비스 만들기 (by. CloudFront, Lambda@Edge)개요웹 페이지 서비스에서 스토리지(S3)에 가지고, 사용하고 잇는 원본 이미지 크기가  720 x 360 라고 가정하자하지만 페이지에 따라 640x360, 1200x600 등등 출력할 화면이 있다고 가정할 때.. (추후 2:yubi5050.tistory.com 구현 순서 (1~2) 1. S3 이미지 만들고 & S3 캐싱하는 CloudFront 만들기2. Lambda (chalice) 코드 작성- chalice의 lambda function 사용하여 구현- edge 환경..

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

Schema 란 스키마(schema)는 데이터베이스 내에서 객체(테이블, 뷰, 함수, 인덱스 등)를 논리적으로 구분 한 컨테이너이다. 하나의 데이터베이스 안에 여러 스키마를 포함하며, 스키마를 활용해  여러 namespace 공간을 제공하고, 각각의 공간에서는 동일한 이름의 객체를 가질 수 있다. public과 service1이 다른 schema라는 가정하에 다음과 같이 정의 할 수 있다.ex) public.user_table / service1.user_table Mysql mysql 에서 스키마(Schema)는 Database와 동일한 의미로 사용된다.즉, MySQL의 스키마(Schema)는 데이터베이스(Database) 하나 자체를 지칭하며,필요시 다른 데이터베이스(Database)를 활용하여 논리..

Non-Tech 관련코드 리뷰코드 리뷰에 관한 생각 정리 : 코드 리뷰에 대한 가치관 및 좋은 견해 개발자, 커리어주니어/중니어/시니어의 역할 정리 : 주니어, 중니어  의 역할을 비교해보며 나는 어디쯤 속해있나 돌아보기 좋은 글.기타사용자 행동 로그 Tech 관련PythonPython과 FastAPI로 지속 성장 가능한 웹서비스 개발하기Fastapi 콜 한줄한줄 따라가기CPython 3.13버전에서 기대되는 기능(A Per-Interpreter GIL)Python @Dataclass 이해하기파이썬과 인터페이스: 프로토콜에서 ABC까지메타 프로그래밍이란? 설계 / 배포uvicorn 에 대한 이해로그 서비스 설계 및 이해 무중단 배포 (Blue/Green)gRPC vs Websocket 차이 이해해보기 L..

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

배경 복잡한 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..

Timeout 에러 timeout 에러 발생시, 다양한 이유에서 Timeout 504 에러가 발생 할 수 있다. ConnectTimeOut 연결 수립 과정(Connection TimeOut) 에서의 에러해당 서버로 아예 연결 수립 과정에서 막히는 경우timeout=0.0001 : 0.0001 초 안에 연결 수립 되어야 한다고 가정import requestsfrom requests.exceptions import ReadTimeout, ConnectTimeout############## Error - ConnectTimeout 에러! ##############url = "https://alden-kang.tistory.com/20"try: # 의도적으로 매우 짧은 타임아웃으로 연결 수립 조차 못하게 ..

개요웹 콘텐츠 캐싱은 이미지, 비디오, css, js 등과 같은 웹 콘텐츠를 사용자에게 더 빠르고 효율적으로 제공하기 위해 임시로 캐싱(저장)해두는 기술로 사용자의 원본 서버에 다시 접근하지 않고, 캐시에 저장된 데이터를 사용해 웹 페이지를 로드하는 방식 서버와 네트워크 부하를 줄여 응답 속도를 개선하고, 사용자 경험을 향상시킬 수 있는 장점이 있음 브라우저 캐시  vs 프록시 캐시 vs 서버 캐시주요 내용은 다음과 같다. 브라우저 캐시 (Client-Side)프록시 캐시 (Proxy or CDN)서버 캐시 (Server-side)목적동일 웹페이지 재방문시 빠른 로딩빠른 콘텐츠 전송 및 지연 시간 감소서버 부하 ↓ 응답 속도와 효율성 ↑대상정적 리소스 (CSS, JS, 이미지)정적(이미지) 및 동적(비디..

개요수치형 필드 설계시 효율적인 데이터 저장을 위해 나름의 현실에서 만들어 질 수 있는 필드들에 기준을 세워보았다.  수치형 필드 기준횟수(유한) / 일수 / 개수일반적인 (unsigned) Integer 필드DB 내부적으로 21억 이하의 정수 비즈니스 로직상으로 무한정 커질 수 없는 경우ex) 일 노출 횟수, 기간 일 수, 댓글 개수 금액 및 횟수 (무한)(unsigned) BigInteger 필드DB 내부적으로 63경 이하물론 꼭 Big 으로 필요는 없고 유연하게 하여도 됨)ex. 상품 단가, 최종 금액, 조회 수  Enum 값, 작은 단위의 값 (유한)TinyInteger, SmallInteger 필드 (일반적으로 256 또는 32767 이하) ex) 유저 타입, 상태값, 할인율 (0~100) 실..