발자취

이번에 회사에서 terraform을 사용해서 간단히 정리해 보았다. Terraform이란 클라우드, 온프레미스 리소스들을 코드로 정의할 수 있는 도구이다. 컴퓨팅 리소스, 스토리지, 네트워킹 리소스, DNS, SaaS 등의 다양한 구성 용소를 코드로 정의할 수도 있다. 테라폼 API를 통해서 앞에서 말한 리소스들을 지정할 수 있다. 코드로 정의하기 때문에 기존의 코드를 작성하는 것처럼 협업이 가능하고 버전 관리가 용이하다. 테라폼의 워크플로에는 주로 3개의 단계가 있다. 먼저 코드를 작성하는 write 단계가 있다. 말 그대로 리소스를 코드로 작성한다. 두 번쨰는 plan이다. 기존에 있던 인프라를 기반으로 이후 변화될 계획을 구상한다. 구상하는 과정은 테라폼 자체적으로 알아서 순서를 정한다. 마지막으로..

실수로 postgres의 기본 db를 지워버렸다. 그 이후에 새 db를 만들려고 하니 자꾸 아래와 같은 오류가 나왔다. template database "template1" does not exist 알고보니 postgresql은 db를 수동으로 새로 만들때 템플릿이 있어야 하는 것 같았다. 그래서 기존의 template0, template1 db를 다시 살려야 하는 상황에 왔다. 구글에 검색하니 템플릿 데이터베이스를 따로 만들수 있다고 한다. 아래 명령어를 치니 템플릿이 새로 생성되었다. create database template0 TEMPLATE postgres; update pg_database set datistemplate=true where datname='template0'; 확인하니 기본..

현재 서버 배포 환경은 Jenkins를 사용해서 하고 있다. 처음에는 내가 직접 인스턴스를 만들어 상세히 커스텀을 할 수 있다는 점이 좋았는데, 이게 시간이 지날수록 서버를 직접 관리해야 한다는 점이 단점으로 크게 다가왔다. 그래서 자동 배포 관련한 기능을 찾아보니, 나의 목적에 잘 맞는 Github Action이라는 서비스가 있어서, Jenkins에 있는 배포 환경을 Github Action으로 이전하기로 했다. Github Action이란 간단히 말하면 테스트, 빌드, 배포 등의 활동들을 Github 내에서 자동으로 설정할 수 있는 도구이다. 그냥 CI/CD 도구 중 하나인데, Github와의 연동성이 매우 좋은 도구라 보면 된다. 거기에 다양한 플러그인 및 확장 프로그램까지 지원하여 꽤 괜찮은 도구..

RDS에 있는 데이터를 가져와야 하는데, 여러가지 제한 사항 때문에 시간이 많이 걸리는 쿼리를 10억회 이상 날릴 일이 생겼다. 그래서 쿼리 속도 향상을 위해 DB 전체를 로컬로 가져와서, localhost로 쿼리를 날리는 방법을 선택했다. 이를 위해 RDS에 있는 데이터를 로컬에서 처리하기 위한 방법을 기록해 볼려고 한다. 여기서는 pg_dump 명령어를 사용할 것이다. 덤프란? 덤프는 .sql 형식의 파일이며, 데이터베이스의 데이터를 sql 구문으로 출력된 파일을 덤프라고 한다. 이걸 이용해서 데이터를 백업하거나 파일로 저장, 복구할 수 있다. Mac 환경 기준, brew install postgresql 명령어를 통해 psql을 미리 설치해두자. 데이터 가져오기 pg_dump -h [주소] -p [..

최근에 이벤트 관련 데이터 파이프라인을 분리하는 작업을 시작했다. 기존에는 서비스를 운영하면서 나오는 모든 이벤트들을 DB에 저장하는 것을 보고, 언젠가는 꼭 해결한다고 했는데 그걸 이제야 시작한다. 해당 로직을 구상하기 위해서 여러 방법들을 구상한 결과, 기존 AWS 도큐먼트에 있는 시스템을 이용해 보는 것이 좋겠다고 생각했다. 구상하기 현재 시스템은 특정 이벤트에 대한 내용을 클라이언트에서 4곳의 서버 (사용자 분석 툴)로 데이터를 보내주고 있다. 이 중 하나는 DB로 이벤트를 보내게 되는데, 이 시스템 자체가 상당히 비효율적이라는 생각이 들었다. DB는 주로 사용자의 데이터 및 프로덕트의 가변 정보들을 저장하는 곳인데, 이벤트에 대한 데이터를 DB에 저장하기에는 목적에도 맞지 않고 DB 및 WAS에..

현재 아키텍쳐는 Elastic Beanstalk에서 서버 이상 상태에 대한 이벤트를 받아서 Lambda 함수에서 슬랙으로 메시지를 전송한다. 하지만 여기서 Lambda 함수에 대한 코드를 사용자가 직접 관리해야 하기 때문에, 이 기능을 AWS Chatbot으로 이전해서 코드에 대한 관리까지 없애보려고 한다. 기존의 플로우에서 람다 -> chatbot으로 전환하는 내용이다. 아래 링크는 기존의 플로우 https://tre2man.tistory.com/303 서버 상태 Lambda와 Slack으로 실시간 확인하기 현재 운영중인 서버는 Elastic Beanstalk으로 관리를 하고 있다. 덕분에 오토 스케일링, 블루그린 배포 등등 서버와 관련된 설정들을 간편하게 관리하는 중이다. 명령어 몇 줄이면 자동으로 ..

최근 사용자 관련 이벤트를 수집하는 로직에서 문제가 보여서 해당 로직을 개선하기 위해서 방법을 찾아보니 Kinesis를 이용하는 것이 제일 좋아 보였다. 하지만 Kinesis에 관해서 잘 모르기 때문에 한번 정리해 보았다. Kinesis 란? 실시간으로 데이터 스트림을 수집 및 처리할 수 있는 시스템이다. Kinesis에는 총 4가지의 기능이 있다. Video Stream, Data stream, Data Firehose, Data Analytics 가 있다. Data stream 데이터를 실시간 스트림으로 받아서 수집 및 저장을 할 수 있는 서비스. Kinesis Data Analytics, spark, ec2, lambda 등의 서비스로 전송할 수 있다. Data Firehose 데이터를 실시간 스트..

개요 이번에 SMS 및 카카오톡 알림톡을 보내는 로직을 커스텀해서 프론트에 API를 제공하는 작업을 하게 되었다. 이 때 '알리고' 라는 서비스를 사용하게 되었는데, 여기서 아이피주소 화이트리스트 (특정한 IP 주소에서 보낸 요청에만 응답하는 것) 를 기본적으로 적용하고 있고, 현재 API 서버와 결합해야 하지만 outbound를 고정하기 힘들고 범용성을 가져야 하는 특정 때문에 Lambda로 제작하기로 했다. 목표 lambda를 사용해서 '알리고'의 API를 사용해 메시지를 보내자. 단, outbound IP 주소는 항상 고정이여야 한다. 구상 글 맨 밑의 참고자료에서 사진을 가져왔다. 간단히 아키텍쳐에 대한 정리를 해 볼려고 한다. 정리 전에 간단한 용어 정리부터 하려고 한다. VPC: 가상 사설 네..

현재 운영중인 서버는 Elastic Beanstalk으로 관리를 하고 있다. 덕분에 오토 스케일링, 블루그린 배포 등등 서버와 관련된 설정들을 간편하게 관리하는 중이다. 명령어 몇 줄이면 자동으로 배포가 가능한 편리한 기능이다. 최근에 서버 운영 중 서버가 죽는 일이 있었다. 이 때 서버 운영 문제를 바로 알았더라면 대응이 조금 더 빨리 되었을 것 같은데, 바로 알아차리지 못해서 대처가 조금 늦었다. 그래서 서버에 문제가 생기거나 상태 변화가 있을 때 바로 슬랙으로 서버 상태를 보내주는 로직이 필요할 것 같아서, 바로 서비스를 구축해보기로 했다. 구상하기 구조는 간단하다. Elastic Beanstalk은 상태 변화와 관련된 이벤트를 EventBridge로 보내주게 된다. 이 이벤트를 잡아서 슬랙으로 이..

아마존 요금 현황을 확인하니, 잘 사용하지 않는 react 사이트가 ec2 위에 올려져서 계속 돈을 먹는 것을 보았다. 서비스 운영에 필요한 사이트이나 자주 쓰는 사이트는 아니지만 꼭 필요한 사이트이기 때문에 배포 방식을 바꿀 필요가 있었다. 그래서 이것저것 찾아보던 중, 나의 요구사항에 잘 맞는 AWS Amplify라는 서비스를 알게 되었다. (배포 방식의 간편화, 사이트 이용량이 많지 않은 사이트) 그래서 Amplify를 이용해서 react app을 배포할려고 한다. AWS Ampliy 먼저 Amplify부터 알아보고 가자. Amplify는 AWS에서 출시한 모바일 앱 개발에 대하여 다양한 기능을 제공하는 프레임워크이다. 말만 들으면 뭐가 뭔지 모르겠다. 예시를 들어 보자. 1. 여러가지 플랫폼 및 ..