전체 글

1. AWS S31.1 S3 스토리지 클래스 유형Amazon S3는 데이터의 접근 빈도와 보관 목적에 따라 다양한 스토리지 클래스를 제공한다. 이를 통해 데이터 특성에 맞는 클래스를 선택하여 비용을 절감하면서 필요한 성능을 유지할 수 있다.대표적인 스토리지 클래스는 다음과 같다.1) StandardS3의 기본 스토리지 클래스이며 자주 접근하는 데이터를 저장할 때 사용된다. 높은 가용성과 내구성을 제공하며 대부분의 서비스 데이터가 이 클래스를 사용한다.사용 예시웹 애플리케이션 데이터정적 콘텐츠 파일로그 데이터2) Intelligent-Tiering객체의 접근 패턴을 자동으로 분석하여 스토리지 계층을 이동하는 방식이다.접근 빈도가 높은 데이터는 상위 계층에 유지하고, 일정 기간 접근하지 않은 데이터는 자동으..

AWS S3 핵심 키워드 정리1️⃣ 스토리지 클래스 (Storage Class)Standard → 자주 접근 (Frequent Access)Intelligent-Tiering → 접근 패턴 분석 후 자동 계층 이동Standard-IA (Infrequent Access) → 거의 접근 안함 / 즉시 조회One Zone-IA → 단일 AZ 저장 / 비용 ↓Glacier Instant Retrieval → 아카이브 / 즉시 조회Glacier Flexible Retrieval → 조회 최대 1시간Glacier Deep Archive → 장기 보관 / 조회 최대 12시간2️⃣ 버전 관리 (Versioning)객체 이전 버전 유지파일 덮어쓰기 방지데이터 복구 가능3️⃣ 객체 잠금 (Object Lock)객체 수정 ..

CentOS 에서 Rocky linux로 전환할때, 팀원들 편하게 하라고 메뉴얼을 작성한적이 있었는데꼼꼼히 작성했어서 그런지 다른팀에서도 종종 사용해주는걸 보고 기분이 좋아서 .. 내 블로그에도 기록을 남기려고 한다. 💻 Rocky Linux 세팅 가이드 (Hyper-V 기준)1️⃣ Hyper-V 활성화1. Windows에서 “프로그램 및 기능 → Windows 기능 켜기/끄기”를 연다. 2. Hyper-V를 체크해서 활성화한다. 3. 변경 사항을 적용하고 컴퓨터를 재부팅한다.2️⃣ 가상 컴퓨터 생성 및 환경 설정https://rockylinux.org/ko-KR/download버전은 Rocky Linux 9을 추천한다.Rocky Linux ISO 다운로드 1. Hyper-V 관리자 실행 ..

최근 OS 전환 이후, 여러 환경 설정이 미묘하게 바뀌면서 예상치 못한 트러블들이 이어졌다.그중 하나가 바로 Atomikos의 “Error during recover – retry later” 로그였다.오늘은 그 문제의 원인으로 이어진 MaxIdleTime 설정에 대해 정리해보려 한다.🧠 MaxIdleTime 이란?MaxIdleTime은 커넥션 풀에서 특정 시간 동안 사용되지 않은(DB와 통신하지 않은) 연결을 제거할 수 있게 해주는 설정값이다.즉, 일정 시간 동안 유휴 상태(idle)로 남아있는 연결을 정리하여 리소스를 효율적으로 관리하게 해주는 기능이다.⚠️ 문제의 시작운영 중인 애플리케이션의 로그 파일을 확인하던 중아래와 같은 에러 로그가 일정 주기로 반복 출력되는 것을 발견했다. atomikos..

컨테이너를 사용하는 프로젝트를 구성할때 가장 먼저 고려해야할 데이터 관리에 대해 기술하고자한다. 컨테이너는 기본적으로 휘발성이라, 컨테이너가 삭제되면 그 안에 있던 데이터도 함께 삭제된다. 그래서 데이터를 날리지 않기 위해 스토리지 전략이 필요하다 컨테이너 스토리지 (Container Storage) 란 ? -> 컨테이너가 데이터를 저장하고 접근하는 방식즉, 컨테이너가 어디에, 어떻게 데이터를 저장하느냐를 관리하는 구조라고 생각하면 쉽다. 대표적으로 3가지의 구조를 가지는데 1. 임시 스토리지 ( Ephemeral Storage)컨테이너 안의 파일시스템을 그대로 사용하는 형태.컨테이너가 죽거나 재시작되면 데이터도 모두 사라짐.예: /tmp 같은 임시 파일 저장용.주로 캐시나 세션, 로그 버퍼 등에 ..

내가 운영하는 서비스의 성능 테스트를 위한것이 아닌, 컨테이너를 조금 더 이해하고, 잘 다루고자 연습하기 위한 수단으로 부하테스트 및 관리에 대한 포스팅을 하고자 한다. 겸사겸사 컨테이너를 사용하고 안하고의 성능 차이도 직접적으로 확인하고, 한발 더 나아가 성능개선, 튜닝까지를 목표로 잡고 있다. 이 기록은 나를 위한 기록이기도 하지만 나와 같이 컨테이너를 더 잘 이해하고, 도커를 조금 더 잘 다루고 싶은 사람들에게 도움이 되었으면 좋겠다. 정확한 방법을 기술하기보다, 전체적인 방향과 흐름을 남기고자한다. 전체적인 흐름을 이해하면, 어떤 프레임워크를 사용하던 어떤 기술과 툴을 사용하던 활용할 수 있기 때문에.. '컨테이너 활용'을 위한 부하테스트 이기 때문에 서비스 자체는 가장 빠르게 만들 수 있는 스..

늭시 공부 정리할거 setDescriptionKey(e.target.value)} /> 대신에 onChange에 이벤트를 바로 걸어버리면 리액트는 비동기식 렌더링으로 처리하기 떄문에 타점을 정확히 지정해줄 수 없음 그래서 하단에처럼 onChange 이벤트를 밖으로 빼줘서 const onChangeModalInput = useCallback((e: React.ChangeEvent) => { const {value} = e.target; console.log(value) setDescriptionKey(value); }, [setDescriptionKey]) 이렇게 따로 관리해줘야함 또한 마지막 , []) 여기에 , 컴포넌트 밖에서 가져온 것들을 넣어줘야함 이게 바로 의존성 배열 { console.log(d..

리사이징을 어느 시점에서 할지 고민을 많이 해 본 결과 , aws s3에 올라가기전에 리사이징을 해주는것이 현 프로젝트에서 서는 더 좋은 방향이라 결론이 났다. 우선적으로 서버비용을 아낄 수 있고 , 기존에 있던 에러도 해결할 수 있으며, 현 프로젝트의 데이터 전송량이 적기 때문이다. 프론트단에서 리사이징을 하는 것은 데이터 전송량이 많아지면서 프로토콜 응답이 느려질 수도 있다고 한다. 보통은 백단에서 처리하는 경우가 많은 것 같다. 당근 마켓도 그렇게 하고 있다고 한다. 기존 s3 미들웨어 upload 코드에서 조금만 수정해주면 리사이징을 할 수 있을것 같아 multer-s3-transform 으로 sharp 패키지를 사용하기로 했다. Lamda라고 함수코드를 만들어서 리사이징 하는 방법이 있긴 한데 ..