
AI를 활용한 텍스트 기반 그림생성 프로젝트를 기획했다.일기를 작성하고 해당 일기를 바탕으로 사용자의 감정 분석, 오늘의 기분, 일기 분석한 그림 일기를 제작해주는 서비스이다.이번 프로젝트에서는 인프라 담당으로 인프라를 설계하고 구축했다.이후 백엔드 기능중 스프링 배치
이전에 Soyu 프로젝트를 구축할 당시에는 급하게 배포하느라 전반적인 지식이 부족했다. AWS의 EC2의 이해와 리눅스의 전반적인 명령어와 학습을 먼저 진행했다. 아래는 기본적인 리눅스와 네트워크, 프로토컬, 클라우드, Dev/ops 에 대한 정리입니다. SHE
인프라를 구축하고 여러가지의 프로세스를 구축해야 한다. 추후에 각 인스턴스를 가변적으로 생성/삭제시 컨테이너 로드밸런싱을 진행해야 한다. 각 프로세스 즉 서버들을 독립적으로 구성한다면 보안성 결합도 측면에서도 유리하다. 배포되는 서비스의 Version 을 관리하고
기본적인 리눅스와 Docker에 대한 학습을 진행했고 이제 직접 환경을 구축하고자 합니다. 사용하는 AWS의 EC2는 다음과 같습니다. Ubuntu 20.04.6 LTS 사용하는 Ram은 16GB 입니다. 사용하는 ubuntu와 Debian 서버와의 최신 싱크를
위 방법은 모든 자바 파일들과 상태를 그대로 옮겨놔야 한다 ! 왜냐? 위 방법은 파이프라인에서 빌드를 하는 경우이기 때문이다 ! 이미지 빌드시에 그냥 → jar 파일을 만들어서 둔다면 굳이 다른 파일들을 가져갈 필요가 없는거다 ! ! ! ! ! 멀티 스
이번 그림 일기 프로젝트에서는 프론트 팀원들이 리액트 네이티브를 사용해서 앱을 만들기 때문에 React Native를 사용해서 개발한다. 실제로 개발후 APK를 도출해서 앱에 출시하는 개념이라 프론트 코드를 빌드할 필요가 없었다. 하지만 웹서버인 Nginx 와 프
다음은 SSL 적용을 위한 증명서 발급과 자동으로 증명서를 재발급해주는 Certbot을 구축해보려고 합니다. 원스토어에 앱을 등록하려면 SSL 설정은 필수라고 합니다. 가장 먼저 docker compose 통해서 서트봇 엔진엑스를 띄워놔야 한다 ! 서트봇을 통
SSL 적용을 완료하고, 서버에 리버스 프록시를 적용하려고 한다. 위 그림처럼 서버단의 프록시 서버가 모든 요청을 받아서 처리해준다. 내가 생각하는 큰 장점으로는 호스트의 포트를 노출시키지 않아도 된다. 모든 요청에 공통적으로 SSL 적용이 가능하다. 그러면 이제
git 을 통해서 올리는 환경은 local 개발 환경이므로 앞서 네트워크에서 학습한대로 http://locahost 가 아닌 http://[컨테이너이름] 이 되야한다. 따라서 yml 파일을 Dev 환경과 prod 환경으로 분리해서 실행되는 환경에 맞는 파일을 마운트하
다음으로는 해당 프로젝트를 진행하며 가장 많이 고민하고 또 헷갈렸던 부분이다. 도커 네트워크를 제대로 이해하고 내부 네트워크를 통한 처리를 구현하려고 한다... 그 전에 사설, 공인 IP에 대한 개념을 먼저 학습했다 ! 🌐 IP 기초 (사설IP / 공인IP / N
프론트에서 서버 API를 사용하던 도중 502 에러가 나왔다는 이야기를 들었다. 확인해보니 이런 경우는 2가지가 존재했다. spring 이미지 제작후 컨테이너를 최신 버전으로 띄울때 기존 컨테이너가 내려갔고 새로운 버전의 API를 로드할때 서버의 API는 사용할 수
이제 앞에 학습한 내용을 직접 적용해보고자 합니다. 포트 public 으로 여는것을 막고자 expose로 처리하고 싶다 ! 따라서 컨테이너 이름으로 포워딩을 만들기 위해 springblue, springgreen 으로 각 컨테이너를 띄운다. 이후 블루 그린을 스
정적으로 띄워지는 컨테이너중 MySQL 의 PW를 파일이 아닌 EC2 리눅스 환경에 직접 지정하여 사용해보려고 한다. 해당 컴포즈에서는 하나의 네트워크에 expose로 설정해놨기 때문에 외부에서 접근이 불가하다 ! 하지만 root의 비밀번호가 git에 노출된다면 이
인프라를 다 구축한 뒤 잘 돌아가던 서버에서 백엔드 빌드 과정에서 10분이 넘어가는 문제가 발생했다. 그리고 정확히 13시간 뒤 서버가 뻗은 후 다시 켜졌다가 뻗기를 반복했다... 같은 경우가 있는지 찾아봤고 보통 프리티어(ram1GB) EC2에서 많이 발생하는 현
Blue/Green 배포를 적용하고 외부 포트를 개방하지 않고 사용하려고 하니 문제가 존재했다. 헬스 체크시 젠킨스 내부에서 동일 네트워크내 Spring 컨테이너로 Health check 시에 해당 DNS 이름을 인식하지 못하는 문제였다. health 체크를 젠킨스

인프라 구축 완성 후 백엔드 업무에 참여했다.알림 도메인과 일괄 알림 처리를 구현하기로 하고 방법을 고민했다.FCM이 구축되어 있는 상황에서, 다음과 같은 엔티티를 설계했다.기본 알림을 구축하는데는 어려움이 없었지만, 하루중 특정 시간에 사용자들에게 일괄 알림을 보내야

앞 포스팅에서 학습한 spring Batch를 프로젝트에 적용해보고자 한다.라이브러리 등록 implementation 'org.springframework.boot:spring-boot-starter-batch'배치 5.0이론 5.0 이후 @EnableBatchPr

현재 소켓 통신망을 구축해 그림 생성을 요청받은 Spring 서버와 FastApi 서버의 통신을 사용하고 있다. 하나의 서버의 version이 바뀌거나 하나의 서버라도 down 된다면 해당 소켓 통신을 유실되고 밀려있던 모든 일기의 내용이 유실되는 문제점이 존재했다.
프로젝트에 Kafka를 도입하기 이전에 먼저 Spring Server 2개를 가지고 테스트를 해보려 한다. 가장 먼저 EC2 환경에 쉽게 이식할수 있도록 로컬에서도 도커를 활용해 띄우려고 한다. 해당 docker-compose를 통해서 도커를 활용해 kafka를 띄
이제 기존의 Server(Spring) To Server(FastAPI) 소켓 통신을 Kafka 통신으로 변경하려고 한다. 기존 Socket 통신 Socker 을 활용한 Server To Server를 구성할때는 한쪽이 서버 한쪽이 클라이언트로 구성되어 연동을 시도