들어가며평소에도 그렇고 일을 하면서도 그렇고, 프로젝트에서도 배포쪽으로 다양하게 서포트하는 쪽이라 nginx를 굉장히 많이 사용하는 편이다. 특히 학교에서 일하게 되면서 네트워크 정책이 전산을 관리하는 곳에서 통제하기 때문에 제한된 구조로 특정 포트밖에 이용할 수 없게 된다. 이 때 nginx를 극한으로 사용하는 방법에 대해서 알아보기 시작하였다. nginx를 리버스 프록시 및 로드 밸런싱과 같이 다양한 방법으로 사용하다가 Nginx Proxy Manager라는 것을 알게 되었다. 굉장히 신세계였는데, 매번 nginx.conf를 직접 설정하고 nginx -t로 문법 체크하고, reload하는 것과는 다르게, 손쉽게 SSL을 통한 https 접속 및 서브 도메인 로드 밸런싱을 지원하는 점이 좋았다. 더 말..
최근 AWS 기반으로 CI/CD 파이프라인이 구축되어 있던 것을 온프레미즈로 옮기고 있기도 하고, 현재 일하는 곳에서 젠킨스를 이용한 CI/CD 파이프라인을 구축해야할 일이 있었다.젠킨스에 대해서 자세하게 다뤄본 적은 없었으나, 컨테이너를 통하여 젠킨스를 띄우고 젠킨스에서 다른 컨테이너를 컨트롤 하는 상황일 때, 꽤나 잔 에러가 많이 난다고 듣기만 하고서 선뜻 다뤄보지 못했다. 이번 포스팅에서는 docker를 통해 젠킨스를 띄우는 방법에 대해서 다룰 예정이며, dood 방식으로 진행한다. 파이프라인 구성에 대한 자세한 부분은 담지 않는다. 본론DinD? DooD? DinD ( Docker in Docker )먼저 DinD는 말 그대로 Docker를 컨테이너 안에 설치하여 실행하는 방법이다. 즉, 하나의 ..
앞서 포스팅에서 프론트엔드 배포에 대한 설정은 끝났다. 이제 백엔드 배포와 함께 해당 프로젝트의 전반적인 CI/CD 구성을 끝낼 예정이다. 전반적인 아키텍처는 아래와 같이 구성될 예정이다. 이번에도 Github actions를 통해 IAM으로 접근하는 방법이다. 백엔드 개발자가 github actions 설정을 통해서 코드를 푸시하는 순간 바로 ECS를 통해 배포되도록 구성했다. 백엔드 배포는 프론트엔드와 같이 완전한 Serverless를 이루도록 설정해 두었다. 즉, 스케일 아웃이 설정에 따라 알아서 진행되는 아키텍처로 설계하였다. 먼저 프로젝트를 진행하기 전에 앞서 알아두어야할 것들이 몇 가지 있다. 첫 번째로는 서버리스 아키텍처를 위해 ECS의 Fargate를 사용하는데, 이 경우에는 메모리와 CP..
최근 피우다 프로젝트라는 공모전에 다섯 명으로 팀을 꾸려 참가하였다. 개발 경력이 가장 길었기에 PM이자 팀장 포지션으로 다른 개발자들을 서포트하는 포지션으로 프로젝트에 임하게 되었다. AWS를 통해 프론트엔드와 백엔드를 배포하는 CI/CD를 전체적으로 구성하였는데, 전체적인 아키텍처는 위와 같았다. freetier를 사용하는 수준에서 처리할 수 있었고, 수많은 AWS의 서비스를 사용함으로써 AWS 아키텍처의 기본기를 제대로 다뤄보았다고 생각했다. 이번 포스팅은 프론트엔드편과 백엔드편으로 나뉘어 배포하는 과정을 나타낸다. 해당 과정에 대해서 다시 한번 블로그에 복기함으로써 어떤 식으로 아키텍처를 구성했는지 리마인드함과 동시에 다른 개발자들도 참고할 수 있게 글을 작성한다. 이번 포스팅에서 다룰 전반적인..
먼저, 간단한 프리뷰를 하자면 준비 기간은 약 5주 정도였던 것 같다. 퇴근하고 나서 공부할 때도 있었지만, 학부연구생을 하고 있어서 온전히 퇴근한 시간을 쓸 수 없었기 때문에 5주 정도였다. 퇴근하고 나서 온전히 시험에 투자할 수 있다면 3~4주, 아니면 일을 하고 있지 않아서 정말 하루 종일 공부할 수 있다면 2주 정도로 합격할 수 있을 것 같다. ( 사람에 따라 다름 ) 시험을 보게 된 계기는 그동안 너무 AWS를 오래 사용했지만 자세히 알지 못하고 쓰는 감이 있어서 AWS에 대한 자세한 이해가 하고 싶었고, 평소에 자격증 공부를 하는 취미가 있어서 공부하게 되었다. 자격증을 준비하면서 생각보다 강의 내용도 알찼고, 시험에 합격하고 나서는 정말 모든 아키텍처들에 대해서 어떻게 어떻게 구성해야 될지 ..
슈퍼컴퓨터 관리자로 일하기 시작한 지 약 세 달째가 되었다. 대략적으로 하고 있는 일들은 익숙해졌다. 가장 중요한 일 중 하나는 비정상(abnormal)으로 작동하고 있는 노드들을 고치는 것이다. 주로 소프트웨어적인 측면에서 발생하는 문제는 HPC(High Performance Computer)를 클러스터링 할 때, Slurm이라는 툴을 사용하는데, Slurm에서 node의 상태가 drain으로 찍히는 경우이다. 이러한 경우에는 먼저 ssh로 접속하여 htop같은 명령어를 통해 리소스 사용량을 조회하고, slurm의 로그 파일을 읽어 어떤 문제가 있는지 확인하고, reboot 명령어를 통해 서버를 재실행하는 방법으로 해결하곤 한다. 소프트웨어적인 측면이 아니라 하드웨어적인 측면에서도 비정상(abnorma..
이번 포스팅에서는 웹소켓을 통해서 채팅 서버를 구현하는 방법에 대해서 알아볼 예정이다. 먼저 채팅 서버의 가장 중요한 특징은 무엇일까? 그것은 바로 실시간이라는 것이다. 일반적으로 요청(Request)와 응답(Response)으로 이루어진 HTTP API와는 다르게 실시간으로 통신하는 것이 중요한 채팅 서버에서는 웹소켓(Websocket)이라는 프로토콜을 사용한다. 따라서 이번에는 웹소켓이라는 프로토콜을 사용할 예정이다. 위와 같은 채팅 서버를 구현하기에 앞서 우리는 AWS를 이용할 예정이다. 우리가 사용할 서비스는 IAM, Amazon Lambda, API Gateway, DynamoDB를 사용할 예정이다. 간단하게 프리뷰를 하자면 다음의 포스팅을 참고하였다. 해당 포스팅에서는 CloudFormatio..
최근 인공지능 기술이 크게 발전함에 따라 인공지능을 뒷받침하는 다양한 기술들이 연구되고 있다. 그 중 GPT와 같은 프로덕트를 구현하는 데 사용되는 LLM(Large Language Model)과 이를 위한 데이터베이스인 VDB(Vector Database)도 활발한 연구가 이루어지고 있다. 이러한 벡터 데이터베이스(VDB)는 벡터값을 저장하기 위해 특화된 데이터베이스인데, 주로 embedding과 함께 쓰이게 된다. embedding은 모든 데이터들을 고차원의 벡터값으로 변환한 것이다. 다양한 데이터에 맞는 embedding model을 사용하여 어떠한 데이터든 임베딩으로 나타낼 수 있다. ( text embedding model, image embedding model, etc ... ) 이러한 LL..