Infra & Cloud

[Spring] kafka 파헤치기현재 캡스톤 프로젝트에는 사용자 개인의 마인드맵 CRUD 과정이 이루어지는 기능이 들어간다. 간단히 말하자면,1. 사용자가 마인드맵을 생성 (마인드맵의 Root Node 생성)2. 사용자가 마인드맵을 수sksmsfbrjs51.tistory.com  이전 포스트에서는, Kafka의 필요성과 Kafka가 어떤 구조로 이루어져있는지 분석해보았다. Kafka를 활용하여 지속적으로 마인드맵 데이터를 Producer에게 전송하여 이를 DB 및 Client에게 전송해줘야 하는 구조임을 알게 되었다. 하지만 여기서 걸리는 것이, 그럼 결국 Publisher에게 호출한 토픽이 같은 경우, 가장 마지막에 요청된 Topic으로 DB에 저장, 수정되거나 사용자에게 반환해줘야 하는게 아닌가? ..

현재 캡스톤 프로젝트에는 사용자 개인의 마인드맵 CRUD 과정이 이루어지는 기능이 들어간다. 간단히 말하자면,1. 사용자가 마인드맵을 생성 (마인드맵의 Root Node 생성)2. 사용자가 마인드맵을 수정 (마인드맵에서 노드를 생성하고 가지를 뻗어나가는 과정)  이때, 사용자의 지속적인 마인드맵 수정 작업이 이루어지는 로직을 기획하고 있었다.[x, y 좌표 배치 및 노드 데이터 변경] 현재는 데이터베이스에 직접 end-to-end 방식으로 API를 호출하는 방식으로 아키텍쳐를 구상한 상황이지만, 크게 4가지의 잠재적인 문제점을 내포했다.  1. 시스템 복잡도의 증가중앙화된 데이터 전송 영역이 없어, 데이터의 흐름을 파악하기 어렵고, 시스템 관리가 복잡함.시스템의 일부분에 문제가 발생하면, 연결된 모든 애..

프로젝트를 진행하는 당시 백엔드에서 모델 서버에 여러 번 Sagemaker Endpoint로 요청을 호출했을 때, 갑자기 EC2에서 해당 로그를 뜯어봤을 때 다음과 같은 에러가 발생했다. Caused by: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30001ms (total=10, active=10, idle=0, waiting=0) at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:686) ~[HikariCP-5.1.0.jar!/:na] a..

해당 게시글은 국민대학교 이경용 교수님의수업 내용을 바탕으로 작성하였습니다.  구동중인 서버에 문제 발생 시 해결 방안 자원의 시작, 종료, 설정 자동화! -> 시스템의 안정성, 일관성, 효율성을 높임. DevOpsDevelopment + Operation 클라우드 서비스의 등장 및 웹 서비스의 보편화에 따라 개발 및 운용의 경계 모호웹서비스의 빠른 개선 주기로 인한 간단한 릴리즈 사이클 필요 (자동으로 처리할 수 있는 배포 환경 필요)코드를 활용한 서비스 배포 보편화 (사용자로 인한 에러 감소) Infrastructure as Code (IaC)코드를 이용한 자원 관리소프트웨어 개발 프로세스를 적용 가능 (재사용, 유지보수, 확장성)JSON 또는 YAML을 활용하여 자원 상태 서술장점속도 및 안정성 :..

해당 게시글은 국민대학교 이경용 교수님의클라우드 컴퓨팅 수업 내용을바탕으로 작성하였습니다.  고가용성 (High Availability) 이란?서비스를 운용하는 사람이 관리를 하지 않아도 서비스가 동작하지 않은 시간 최소화하여 사용자에게 예측된 성능을 제공해줄 수 있는 척도구축 시 추가 cost 발생구현 요소들Fault tolerance : 실패 내성 (문제가 발생해도 사용자에게 영향을 전파하지 않는 능력)Scalability : 확장성 (시스템 설계를 바꾸지 않고도 증가하는 요청을 처리할 수 있는 능력) 사용자 보유 데이터 센터와 클라우드에서의 고가용성 & 여러 Region들사용자 보유 데이터 센터많은 경비 소요 (하드웨어 구매, 서버룸 구축 등)중요한 일부 서비스에 대해서만 고가용성 확보클라우드여러 ..

해당 게시글은 국민대학교 이경용 교수님의수업 내용을 바탕으로 작성하였습니다.  Decoupling Modules전체 시스템을 독립적인 컴포넌트로 디자인 하는 것.  시스템이 loose coupled 될수록 시스템의 확장성을 보장하는 것이 쉬움.Web Server -> Nginx 또는 Apache Tomcat (proxy가 각 엔드포인트에 대해 요청을 뿌려줌) 장점각 컴포넌트 간의 종속성 최소화. (casecading failure 방지)tightly coupled : 한 응용 서버의 문제가 모든 웹서버에 전파됨loosely coupled : 로드밸런서가 응용서버의 실패를 가려줌 (health check) 모듈을 Decoupling 하는 방법서버를 구축해서 모든 서비스를 만드는 시도는 좋지 않음.서버를 만..

해당 게시글은 국민대학교 이경용 교수님의수업 내용을 바탕으로 작성하였습니다. Monolithic Application  vs  Microservice Application  Monolithic Application하나의 서버에 다른 목적을 가지는 여러 프로세스가 동작함.Scale-up이 적당한 경우가 많음Scale-out이 불가능한 경우가 많음 Microservice Application독립적으로 배포 가능해야 하며, static한 외부 API 제공배포 가능한 컴포넌트로 분리 후 배포여러 컴포넌트 간 통신 프로토콜 정의 필요장점고가용성 시스템 구성확장이 필요한 서비스만 확장 가능필요에 따라 특정 서비스만 여러 서버에 복제하여 안정성을 높일 수 있음.여러 서비스간 소프트웨어 종속 문제 해결 가능다수 소프트..

문제 상황2024년 2학기 AI를 활용한 회의 지원 솔루션 플랫폼 "Clerker" 프로젝트를 개발할 때 EC2에서 Port forwarding을 위해 nginx를 사용했다. Nginx를 Reverse proxy로 사용할 때, 다음과 같은 에러가 발생했다.413 Request Entity Too Large 413 Request Entity Too Large 에러는 클라이언트가 서버로 전송한 요청의 크기가 서버에서 허용한 크기보다 클 때 발생한다. 이 문제는 특히 파일 업로드 또는 POST 요청 데이터가 많을 때 자주 나타난다.발생 원인1. Nginx 설정의 제한 Nginx는 너무 큰 사이즈의 request를 서버에 전송하지 못하게 제한을 걸 수 있다.request의 Content-Length 헤더값이 여..