사내에서 AWS를 활용하고 있어 Best Practice 적용 및 적절한 기술을 도입하기 위해 공부를 따로 해야겠다는 생각이 들었다. 자격증을 목표로 잡으면 동기부여도 되고, 강제로 공부를 하게 되기 때문에 AWS Solution Architect Associate 자

사내에서 사용 중인 Internal application의 경우 회사 내 ip에서만 접근할 수 있도록 보안 정책을 설정해야 한다. 기존 internal application 은 aws ec2 + ALB 로 구성되어 있었으며 ALB 의 Security rule을 통해 회

EKS 환경으로 마이그레이션 하면서 클러스터에 여러 애플리케이션을 배포하다보니 로드 밸런서 개수가 늘어나는 문제가 생겼다. 가령 같은 서브도메인에서도 path에 따라서 여러 서비스를 나누어 배포하고 싶은 경우도 있었고, 다른 서브도메인이라도 하나의 로드밸런서만 사용하여

Intro 기존 모놀리식 아키텍처인 소프트웨어를 마이크로 서비스 아키텍처로 마이그레이션 하는 작업을 수행하면서 인프라 환경도 기존 ECS가 아닌 EKS로 넘어가게 되었다. EKS 에서 애플리케이션 컨테이너들의 로그들을 수집하기 위해서는 로그 수집을 수행하는 로그 수

서론 사내 인프라 환경을 기존 모놀리식 + ECS 환경에서 MSA + AWS EKS 로 전환하면서 Terraform 도입도 같이 진행하게 되었다. Terraform 도입 이후 효율적인 tfstate 관리 방법과, CI/CD 상 terraform 변경 사항에 대한 검증

서비스를 운영하다가 Production 환경에서 Celery worker 및 백엔드 서버에서 RabbitMQ Connection Refused 문제가 발생했다. 처음에는 오류 개수가 많지 않아서 일시적인 오류라 생각했으나, 꽤 많은 건수의 보고가 잡혀서 원인을 파악하고

회사에서 여러 데이터들을 취합하는 통계 기능을 구현할 일이 있었는데, 그 과정에서 SQL의 윈도우 함수를 알게 되어 정리하고자 한다. 윈도우 함수는 행과 행 간의 관계를 정의하거나 비교, 연산을 수행할 수 있는 함수이다. 윈도우 함수를 통해 여러 서브 쿼리를 이용해서

개발해야할 이슈가 많아질 수록 프로젝트를 체계적으로 관리하는 것은 정말 중요하다. 그렇지 않으면, 우리가 집중해야할 것이 무엇인지 놓칠 수 있고 또 꼭 해결해야할 이슈를 놓칠 수 있기 때문이다. 오늘은 우리 회사에서 asana로 제품 개발 프로젝트를 관리하는 방법을 소

오랜만의 데이터베이스 관련 포스팅이다. 친한 개발자와 인덱스에 관련된 토론을 하다가 결합 인덱스에 대해서 정확히 정리가 안된 것 같아서 정리해보고자 한다. 인덱스를 생성할 때 두 개 이상의 컬럼을 결합해서 인덱스를 만드는 것을 결합 인덱스라고 한다. 하나의 컬럼만으로는

기존의 모놀리식 아키텍처 여러 개의 독립된 DB를 가진 서비스로 분해시킨 마이크로 서비스 아키텍처 에서는 데이터를 효율적으로 쿼리하기 위한 고민이 필요하다. 모놀리식 아키텍처 에서는 DB가 하나 뿐이기 때문에 개발자는 데이터를 쿼리하기 위해 적절한 인덱스를 설정하고 S

개요 마이크로 서비스 아키텍처에서는 독립된 서비스 간 호출을 통해 전체 서비스를 제공한다. 그러다 보니 특정 서비스가 느려지거나 장애가 나게되면 다른 서비스들로 장애가 전파될 수 있다. 예를 들어 독립된 서비스 A, B 가 있을 때 B가 급격한 트래픽 증가로 응답속

마이크로 서비스 아키텍처에서는 여러 서비스들이 서로 다른 네트워크 엔드 포인트들을 가지고 있다. 또 각 서비스들은 여러 노드들로 구성되기 때문에 이 모든 서비스들에 대한 네트워크 정보를 저장하고 관리해야 한다. 클라우드 컴퓨팅 환경의 도입에 따라 각 서비스들은 동적으

배경 클라우드 플랫폼은 우리가 데이터센터를 구축하지 않아도 앉아서 1분 안에 컴퓨팅 노드를 생성, 네트워크 설정 등 여러가지 다양한 기능을 제공해준다. 그러나 주의해서 서비스를 설계하지 않으면 많은 비용이 발생한다. 내가 운영하고 있는 ML 기반 서비스의 경우 워

사내에서 Rest API 개발 프레임워크로 Django Rest Framework(DRF)를 사용 중이다. DRF에서 APIView는 Class Based View의 일종으로 클래스 안에 serializer나 permission, throttle 클래스를 명시해주면 알

사내 Celery 도입을 위해서 GKE(Google Kubernetes Engine)에 RabbitMQ를 설치해야 했다. GKE에 RabbitMQ RabbitMQ를 설치하는 도중 Pod이 계속 Pending State에 머물러있길래 왜 그런지 살펴보던 중 Persist

신규 프로젝트에서 Celery를 활용하기 위해 브로커에 쓰일 RabbitMQ를 구축해야 했다. 이미 우린 GKE를 활용해서 백엔드 애플리케이션 및 Celery Worker를 올리려고 하였기 때문에 RabbitMQ도 GKE에 구축해야 했다. (물론 클라우드 기반해서 제공

기존에 운영하던 애플리케이션은 개발환경 dev, staging, production 마다 별도의 GCP(Google Cloud Platform) 프로젝트로 분리되어 있었으며, 각 환경마다 별도의 GKE 클러스터를 쓰고 있었다. 환경 별로 프로젝트를 분리하면 어떤 자원을

프로덕트를 안정적으로 운영하기 위해서는 테스트 방법을 잘 설계하는 것이 필수이다. 사내에는 Browser Stack을 활용한 E2E 테스트가 존재하였고 master 브랜치의 CD Flow에 해당 테스트가 포함되어 있었다. 그러나 운영했던 E2E 테스트는 실제 우리 프로

비동기 처리를 위해 Celery를 도입하려는데 메시지 브로커로 RabbitMQ, Redis를 사용할 수 있다고 한다. 둘 중 하나를 선택하기 위해 분석해서 표로 정리해보았다. | RabbitMQ | Redis | | --- | -- | | 메시지 브로커 용도로 개

DDD Start라는 책을 읽다가, 웹 애플리케이션에서 여러 스레드가 특정 모델(애그리거트)에 동시 접근할 때 발생하는 문제와 해결법이 나오는데 실무에서 꼭 알아두어야할 내용인 것 같아서 정리하려고 한다. 멀티 스레드 환경에서 어떤 문제가 발생할 수 있을까? 온라인