tioon's Devlog

이번 학기에 아파치 카프카에 대해서 스터디를 하게 되었는데 공부하면서 한번 정리를 해보려합니다! 혹시나 틀린 정보가 있다면 말씀해주세요! 현재 백엔드에서 빅데이터 처리시에 가장 많이 쓰이고 있는 플랫폼은 카프카인데요. 시작하기에 앞서, 우선 먼저 카프카를 한마디로 소개를 먼저 하자면 다음과 같습니다. 실시간 스트리밍 대용량, 대규모 데이터 처리에 특화된 프레임워크 이를 먼저 기억해주시고, 아래 글을 읽어주세요! 아파치 카프카(Kafka)의 시작 과거, 기존의 백엔드 서버에서 데이터를 수집하기위해 직접 데이터를 카테고리화 해서 저장을 하였습니다. 즉, 직접 1대1 매핑을 통해 데이터와 앱을 연결하여 카테고리처럼 저장하는 방식이였습니다. 초기에는 이러한 방식이 운영이 어렵지 않았고, 아키텍처도 복잡하지 않아..

이번 블로그에서는 터미널에서 SSH와 SCP를 직접 어떻게 사용하는지, 또한, 깃허브 액션에선 SSH와 SCP를 어떻게 사용하는지에 대해서 알아 보겠습니다. 사실 저희가 서버를 배포를 한다고 하면, SSH와 SCP 둘 다 사용할 일이 많잖아요?? 하지만 그럴때마다 까먹어서 구글링 하느라 시간 다쓴 적 있지않나요? 저도 서버 배포를 하면서 매번 SSH, SCP를 사용하는데 그때마다 까먹어서 자료 찾는게 귀찮아서 이번에 한번 제대로 공부하고, 까먹을 때마다 보려고 합니다 ㅎㅎ 우선 터미널 상에서 SSH와 SCP를 어떻게 사용하고, 옵션은 어떻게 활용하는지에 대해서 정리를 한 후, 추가적으로, 깃허브 액션에서는 어떻게 SSH와 SCP를 활용할 수 있는지에 대해서 정리를 해보도록 하겠습니다. SSH SSH 기본..

이번엔 제가 스프링으로 웹소켓을 구현하면서 겪었던 문제들을 해결하면서 고민했던것과 해결한 결과를 말씀 드리려 합니다. 예전에 웹소켓을 STOMP로 구현하면서 블로그 글을 올린 적이 있었는데, 그때엔 제대로 작동이 되었습니다. 하지만, 최근에 STOMP 테스트 하는 것이 어떤 이유에서인지 모르겠지만, 막혔더라구요...ㅜ 그래서 다양한 방법으로 해결을 하려 했지만, STOMP를 결국 활용을 못하고, 스프링 WebSocket으로 리팩토링하여 해결으 하였습니다. 우선 다음과 같은 단계로 설명을 드리려합니다. 현재 STOMP의 문제. STOMP 테스트 시스템 부재 STOMP 대체제인 스프링 WebSocket 직접 구현 스프링 WebSocket 테스트 현재 STOMP의 문제. 과거에 제가 STOMP를 이용해 웹소켓..

이번에 백엔드 팀원들끼리 깃허브를 활용해 협업을 진행하다가 불편한 점이 생겼고, 이를 서브모듈로 해결을 했습니다. 이 경험을 좀 더 기억하고싶고, 추후에도 사용할 기회가 있을 것 같아 기록을 남겨보려 합니다. 우선, 먼저 불편한 점이 다음과 같았습니다. 스프링 서버를 개발하면서, 중요한 key값들은 전부 application.yml파일에 저장을 하였습니다. 혼자 개발을 할땐 그냥 .gitignore 파일에 추가하여 git 추적을 하지 않으면 상관없었지만, 팀원들과 협업을 하며 개발할 때엔, 따로 application.yml파일을 주고 받아야 했기 때문에 위험하기도 했고, 귀찮기도 했습니다. 우선 저희가 처음에 했던 방식은 다음과 같습니다. 다른 스프링 코드들은 깃허브로 서로 공유를 하고 있었지만, app..

이번 블로그에서는 여러 EC2들을 대상으로 CI/CD를 구축하는 과정을 알아보도록 하겠습니다. 우선 CI/CD 도구는 깃허브 액션을 사용할것이고, 스프링 서버를 기반으로 배포를 진행할 것입니다. CI/CD를 구축할 서버 구조환경은 아래의 글에서 확인 하실 수 있습니다. https://tioon.tistory.com/184 EC2 도메인 연결 및 HTTPS 적용하기 이번엔 AWS에서 서버 배포를 할때, 도메인을 적용시키고, 추가적으로 HTTP가 아닌 HTTPS로 적용시켜 배포하는것을 알아보도록 하겠습니다. 우선, 이 과정을 진행하기 위해선 필요한것들은 다음과 tioon.tistory.com 즉, 아래가 저희가 CI/CD를 구축해야할 서버의 환경입니다. 로드밸런서와 RDS는 CI/CD를 구축할 필요가 없으므..

이번 글에서는 도커를 활용해 스프링서버를 배포하는 과정을 설명하겠습니다. 저희가 서버 1대를배포하거나, 서버의 환경설정이 간단하다면, 일반적으로 EC2에서 파일을받아 빌드하면되겠지만, 만약 여러대의 서버를 배포해야한다던가, 서버배포하기전에 환경설정작업이 매우 복잡하다면, 이렇게 일반적으로 빌드하게 될때 매우 복잡해집니다. 따라서, 도커는 가상환경의 장점을 통해 빠른 서버 배포와 환경설정이 가능하게 해줍니다. 배포 과정 먼저, 도커를 이용해 배포하는 과정을 간략하게 설명 드리겠습니다. Dockerfile 생성 Dockerfile 기반으로 도커이미지 생성 도커 이미지를 도커허브로 Push EC2에서 도커허브에서 도커 이미지 Pull 받기 도커이미지 기반으로 컨테이너 생성 후 실행 (도커 컴포즈로 대체가능) ..

이번 장에서는 로드밸런서를 활용한 Scale-Out 구현하겠습니다. Scale-Out을 구현하기에 앞서, Scale-Out의 개념과 이게 왜필요한지에 대해서 먼저 알아보도록 하겠습니다. Scale-Out(수평확장)이란?? Scale-Out이란 Scale-Up과 대비되는 말로, 서버의 처리능력을 증가시키기 위해 추가적은 노드(서버)를 시스템에 추가하는 것을 의미합니다. 즉, 서버의 성능을 높이기위해 단일 서버가 아닌 다수개의 서버를 이어붙여 트래픽을 분산시켜 서버 성능을 높이는 기법을 뜻합니다. 이해하기 쉽게 예시를 들어서 설명을 해보겠습니다. 위와 같은 상황의 서버가 있다고 가정을 하겠습니다. 현재 단일 서버로 서버 1대가 존재하고, 서버와 DB가 1대1로 매핑이 되어있는 서버라고 가정하겠습니다. 가장 ..