발자취

현재 프로젝트에서 docker image안에 azure cil을 설치하고, 해당 프로그램에 인자로 key값을 받는 작업을 수행했다. azure는 aws와 다르게 cli로 로그인 하기 위해서는 거의 무조건 web으로 연결해야 하는 로직이 있었다. oauth2를 사용해서 보안 강화에 초점을 맞춘 것 같다. 여하튼 해당 플로우를 구현하기 위해서 방법을 찾아봤는데, aws와 다른점이 있어서 방법을 찾을때 약간 고생좀 했다. 구현하기 기존의 로그인 플로우를 확인하면 다음과 같다. az login 실행 (--use-device-code 도 비슷한 플로우) 웹사이트 오픈 로그인 인증 후 cli로 전환 로그인 완료 여기서 웹사이트를 오픈하는 과정 자체가 보안에는 좋을지 몰라도 사용성에서는 상당히 별로인 것 같아 보였다..

현재 AKS에 NestJS 파드를 올려야 하는 상황이다. 분명히 네트워크 엔드포인트 잘 맞추고, 서비스 잘 올렸는데 자꾸 백엔드에서 DB에 접속을 하지 못하는 이슈가 있었다. 현재 이 상황에서 내가 해본 것들은 다음과 같다. Service 포트 확인하기 Deployment, Service 라벨 확인하기 Pod에 접속해서 curl 날려서 DB 연결 확인하기 Azure 가상 머신에 접속하여 이미지 빌드 후 푸시하기 원격 저장소에 있는 이전 이미지 배포하기(이건 잘됨) 클러스터 처음부터 다시 만들기 CNI 설정 처음부터 다시하기 이정도의 엄청난 삽질을 하고 있었다...그런데 CRI에 대해서 한번 확인해 보라고 주변 분께서 제안해 보셨다. 그래서 CRI에 대해서 잠깐 알아본 이후 바로 확인해 보았다. CRI C..

쿠버네티스는 컨테이너 애플리케이션을 제어할 수 있는 컨테이너 오케스트레이션 프로그램 중 하나이다. 현재 컨테이너 오케스트레이션 도구 중에서 독보적인 위치를 지니고 있으며, MSA를 사용하는 기업들은 거의 다 쿠버네티스를 사용하고 있다. 쿠버네티스는 각 컨테이너를 다루는 도구이므로, 당연히 그와 관련된 네트워크 설정들이 있을 것이다. 쿠버네티스에서 기본적으로 제공하는 네트워크에 대해서 간단히 알아보자. 쿠버네티스의 기본 네트워크 쿠버네티스의 구조에 대해서 간단히 알아보자. 쿠버네티스의 가장 작은 단위는 파드이다. 한 개의 도커 컨테이너라고 보면 된다. 파드들을 관리하는 상위 단위는 노드이다. 노드는 한 대의 pc라고 생각하면 된다. 이러한 노드들을 관리하는 것이 쿠버네티스 클러스터이다. 그림으로 보면 다음..

이번에 회사에서 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 데이터를 실시간 스트..