발자취

요즘 lambda가 재밌어 보여서 계속 알아보는 중이다. 람다 (서버리스) 애플리케이션에 대한 설명은 다음 사이트에 잘 나와있다. https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless 서버리스란? 서버리스(serverless)란 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델입니다. www.redhat.com 간단히 말하면 서버를 관리할 필요가 없는 환경을 말하는데, BaaS (Backend As A Service)환경에서 작동되는 것을 말한다. 즉, 우리는 실행하는 함수만 작성해서 Lambda에 넘겨주면 람다는 구동환경을 알아서 최적화하여 서비스해준다. 여튼 Typescr..

aws를 사용하면서, 하나의 계정이 아닌 여러개의 계정을 사용할 일이 많아졌다. 거의 모든 작업을 콘솔에서 할 수도 있지만, 익숙하다면 cli 환경이 좀 더 나은 것 같다. 여튼 다중 계정 설정을 cli에서 사용해보자. 다중 계정 설정하기 m1 mackbook에서 진행한다. 컴퓨터에 미리 aws cli를 설치해두자. 기존의 aws configure 명령어를 이용하면 IAM 엑세스 키를 입력하여 사용자를 인증할 수 있다. 여기서 --profile 옵션을 붙여 프로필을 나눌 수 있다. 1 aws configure --profile newProfile cs 이후 .aws 폴더 안에 있는 파일들을 확인하자. config와 credentials란 파일이 있는데, config는 사용자에 대한 정보, credenti..

현재 ec2 인스턴스에서 jenkins를 이용하여 docker image를 빌드하는 작업을 계속 진행하고 있다. 이 때 갑자기 경고창이 떴다. 용량이 부족하다고 징징댄다. EBS에 16GB나 할당해주었는데... 바로 ssh 접속후 df 명령어로 인스턴스의 남은 용량을 확인해 보았다. 결과는 약간 충격적이였다. Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 1000672 0 1000672 0% /dev tmpfs 1009664 0 1009664 0% /dev/shm tmpfs 1009664 432 1009232 1% /run tmpfs 1009664 0 1009664 0% /sys/fs/cgroup /dev/xvda1 16764908 15732..

이전 게시물에서는 elastic beanstalk에 배포하는 플로우까지 제작해 보았다. 하지만 배포가 끝났을 때 알려주는 로직이 있으면 조금 더 확실히 배포에 대해서 인지할 수 있지 않을까? 라는 생각이 들었다. 배포가 정상적으로 이루어지면 좋은거고, 만약 배포에 예상치 못한 원인으로 실패했을 때도 알람을 주면 좋겠다는 아이디어가 있어 찾아보니, jenkins에는 slack과 연동해서 slack에 message를 보낼 수 있었다. 이를 이용해서 배포 결과를 slack으로 보내 보겠다. 참고로 모든 슬랙 메시지와 채널의 이름은 영어로 하는 게 좋다. slack 설정 먼저 기존에 이용중인 슬랙이 있어야 한다. 슬랙에 메시지를 전송받을 채널을 만든 후, 좌측 하단의 앱 -> 앱 추가 버튼을 눌러야 한다. 추가..

NestJS의 ORM으로 Prisma를 사용 중이다. 여기서 특정 연산을 수행했을 떄 Can't reach database server at `db` ... 이라는 문구가 뜨면서 DB connection이 끊기는 현상이 발생했다. 다른 연산은 모두 정상적으로 작동하는데 특정한 연산에 대해서만 이러한 문제가 발생했다. 여기서 Prisma의 동작 원리를 알아봐야 하는데, Prisma는 개발자의 생산성 및 Migration을 쉽게 하기 위함에 초점을 맞춘 ORM이다. PrismaClient에 json 파일을 입력한다. 이 json 파일은 Prisma 자체적으로 sql 쿼리로 변환한다. Prisma가 sql 쿼리로 변환하는 과정에서 문제가 생기는 것이다. 예를 들어 (raw query 기준) "publi 스키마..

저번 글에서는 Jenkins와 Github를 연결해 보았다. 연결하는 순간 Github에 Jenkins 파일이 생성될 것이다. 젠킨스 파일을 이용해서 파이프라인을 구성하면 배포 과정을 비교적 쉽게 알아챌 수 있다. 3번부터 6번까지의 과정은 Jenkins파일 안에서 스크립트로 진행될 예정인데, 이를 작성하기 위해서는 3번부터 6번까지의 과정을 cli 명령어로 구성할 줄 알아야한다. Docker Image 빌드하기 도커 이미지를 로컬에서 빌드해야 한다. 먼저 다음 설명서를 읽고 도커를 설치하자. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html Docker basics for Amazon ECS - Amazon El..

현재 우리 회사의 배포환경은 절반은 자동, 절반은 수동으로 배포를 하는 중이다. 대략적인 플로우는 github에 push를 하게 되면 dockerhub에서 자동으로 빌드가 되고, 이 이미지를 수동으로 elastic beanstalk에 배포하는 방식이다. 테스트 환경은 상관없는데 프로덕션 환경에서는 상당히 거추장스럽다는 생각이 들게 되었다. 그래서 자동 배포 툴을 찾아보다가 Jenkins 라는 CI/CD 툴을 발견하게 되었다. 내가 사용하는 환경에서 상당히 적합하다는 느낌을 많이 받아서 Jenkins를 사용하기로 했다. 구상하기 구상한 환경은 다음과 같다. 내가 대강 구상한 플로우는 번호 순서대로 따라가면 된다. 1. 로컬에서 코드 작성 후 Github에 push한다. 2. webhook을 통해서 코드 저..

우리 회사에서 예전부터 유저들의 동향을 그래프로 표시하고 싶다는 욕심이 있긴 했다. 그럴 때마다 Firebase 쓰세요~ 라고 했지만 뭔가 자세한 로그가 보고 싶다고 한다. 그래서 이것저것 알아봤더니 모니터링 프로그램은 Grafana가 제일 좋아 보여서 Grafana를 쓰기로 했다. 하지만 data source는 뭐로 쓸까 고민을 했다. 찾아 보니 prometeus라는 프로그램이랑 grafana와 궁합이 제일 잘 맞아 보였다. 서버에서 생긴 로그들을 다 prometeus로 몰아넣고 grafana에서 가져와 쓰면 되는 듯 했다. 하지만 우리 서버는 예전에 있던 로그들도 사용해야 해서 고민하다가 결국 기존에 사용중인 graphql을 grafana에서 사용해 보기로 했다. 구상과 제작 기본적인 구상은 다음과 ..

Postgresql db를 사용하면서 다수의 row를 가진 데이터들을 다룰 때 양이 많아질수록 쿼리 시간이 길어지는 것이 보였다. 이를 개선하기 위해 여러가지 기법을 찾던 중, db의 인덱싱 알고리즘에 따라서 특정한 데이터들은 성능이 빨라진다는 것을 알게 되었다. 이에 대한 지식이 부족한 것 같아 간단히 정리했다. 알고리즘 종류의 필요성 현재 사용되는 db 서비스들은 대부분 기본값으로 b-tree 인덱싱을 사용하고 있다. 보편적으로 많이 사용되고 성능 또한 어느정도 검증이 되어 있어 이를 기반으로 구조가 이루어져 있다. 하지만 이것이 만능 인덱싱 알고리즘은 아닐 뿐더러 항상 특수한 경우가 생기기 마련이다. 이를 위해서 postgres 에서는 21년 현재 6개(사실상 5개)의 알고리즘을 지원하고 있다. 지..

배포 자동화는 계속 발전하고 있다. 개발자들이 개발에 집중할 수 있게 함으로서 생산성을 올리게 되는 선순환으로 이어지게 된다. 내가 현재 사용하는 개발환경은 nodejs 환경이며, 도커 컨테이너에 담아서 쉽게 deploy 할 수 있게 하고 있다. 최근에 도커에 대한 공부를 하면서 기존의 배포 환경을 한번 더 정리하는 식으로 정리해 둘려고 한다. 참고로 내가 하는 방법은 현재 "유료" 이다. (1년에 60달러를 결제하면 Pro 계정 사용이 가능하다.) DockerHub 에서 Github 코드 depoly 하기 먼저 dockerhub 사이트에서 github 계정이랑 연동한다. 나의 경우에는 Github 계정과 연동을 시켜 두었다. 그 다음으로는 Repository를 만들고 간단한 설정을 한다. 1. 도커 허..