목록Architecture (31)
ecsimsw
Mysql DB Multi source replication 지난 글에선 데이터 백업, 쿼리 분산을 위한 Mysql replication 을 소개했다. DB 서버 하나에 데이터를 넣어두는 것이 위험하다고 생각해 복제용 DB를 만들어 데이터를 백업했고, 이를 읽기 전용 서버로 생각하여 백업과 부하 분산 두 가지를 잡을 수 있었다. 이번엔 새로운 니즈가 생겼다. 지금 프로젝트 배포를 개인 홈 서버에 하고 있는데 물리적인 문제가 생겨 데이터가 날아가면 어쩌지 하는 생각이다. (혹시 불이라도 나거나 SSD가 고장나면 어째..) 원하는 구조는 아래와 같다. Api 서버별로 다른 DB 서버로부터 Cloud server 에 하나의 Mysql DB 를 띄워 단순 복제하는 것이다. 여러 소스로부터 복제한다고 해서 이를 ..
0. 메시지 큐 사용 이유와 전략, 재앙 시나리오 소개 Picup 프로젝트에선 메시지 큐로 RabbitMQ 를 사용한다. 이 글에서는 Message queue 를 사용하게 된 이유부터 Rabbit mq의 주요 설정 옵션들 그리고 프로젝트 내에서 MQ 사용 시나리오를 소개하려 한다. 1. Message queue 도입 배경 2. Rabbit MQ 의 주요 옵션, Dead letter 3. 프로젝트에서의 사용 시나리오 / 재앙 시나리오 1. Message queue 도입 배경 Picup 에서는 사진 파일을 한 번에 많은 양 삭제할 수 있어야 한다. 사용자가 앨범 삭제를 요청하면 서버에선 앨범 내에 들어있는 관련 사진들을 삭제해야 한다. 이때 사용자가 그 파일들이 실제로 삭제 처리 될 때까지 그 시간을 기다릴..
Mysql db replication PicUp 프로젝트에서 DB를 백업하기 위해서 replication 을 사용한다. 당장은 백업을 위함이 가장 컸지만 replication 도입으로 쿼리 부하 분산, 지역화의 이점도 얻을 수 있을 것이다. 이 글에선 아래 네가지 키워드를 다룬다. - Mysql이 제공하는 Replication 방식과 각 장단점 - 이 프로젝트에서 비동기 복제 방식을 사용한 이유와 정합성 문제 고민 - Mysql 에서 비동기 Statement Based Replication 설정 방법 - Spring 에서 여러 DB source를 정의하고 transaction readOnly 옵션으로 target source 를 분기할 수 있는 설정 Replication 종류 Mysql 의 복제 방식은 ..
Rabbit MQ 재시도 정책과 Dead letter queue 설정 방법 Pic up 에서 서버간 비동기 통신을 위해 그리고 두 서버의 직접 통신을 피하기 위해 Message queue 로 Rabbit MQ 를 사용하고 있다. Message consumer 가 메시지를 처리하는 도중에 처리 실패하는 경우 큐에서 메시지는 제거되지만 실제 메시지는 처리가 안되는 문제를 해결하기 위한 정책을 고민한다. 재시도 정책 Consumer 가 메시지 처리 도중 예외가 발생하는 경우 정책에 따라 Message queue 에 다시 해당 메시지를 추가하도록 한다. RabbitListenerContainerFactory 를 재정의하고 Rabbit listener 가 이를 사용하는 것으로 RetryInterceptorBuil..
Diagram EKS는 2가지 VPC로 구성되어 있다. Kubernetes control plane를 AWS에서 관리하는 AWS VPC, 그리고 사용자가 직접 관리하는 Customer VPC가 있다. 사용자는 K8S의 control plane를 직접 관리하지 않고, 실질적으로 사용해야 하는 서비스들을 AWS EC2를 Worker node로 하는 Customer VPC에 집중하도록 한다. Cluster endpoint access 이때 이 cluster의 Endpoint, 즉 AWS VPC의 kubernetes api server의 접근 가능 VPC를 설정할 수 있다. public은 요청자의 VPC에 상관없이 endpoint에 접속할 수 있고, 반대로 private 은 cluster 내 VPC 또는 그와 ..
EKS 모니터링하기 / Cloudwatch 세팅부터 Metric slack 알람까지 1. EKS의 Metric 정보를 fluentbit와 cloudwatch agent를 이용하여 Cloudwatch로 모니터링한다. 2. Cloudwatch의 알람을 Slack으로 전송한다. docs : https://catalog.us-east-1.prod.workshops.aws/workshops/9c0aa9ab-90a9-44a6-abe1-8dff360ae428/ko-KR/90-monitoring/100-build-insight CWagent 설치와 Fluentbit 를 Daemonset 으로 선언 cwagent-fluent-bit-quickstar.yaml 다운 받는다. wget https://raw.githubuse..
NO_PUBKEY B53DC80D13EDEF05 Google cloud에서 반환하는 gpg key 포맷이 'OpenPGP ASCII armor'로 변경되면서 기존 kubernetes docs에서 소개하는 Installing kubeadm 방식을 사용하는 경우 gpg key이 올바르지 않는 문제가 발생한다. 혹시 Kubeadmin, Kubelet, Kubectl 을 설치하는 과정에서 apt repository를 등록하고 apt update로 package 업데이트 시 아래와 같은 key 에러(NO_PUBKEY B53DC80D13EDEF05)를 만났다면 이전 방식으로 설치를 진행하진 않았는지 점검한다. Err:2 https://packages.cloud.google.com/apt kubernetes-xeni..
Dynamic secret 정적인 Secret은 위험하다. 사용자가 모두 같은 키 공유하기 때문에 하나의 키만 탈취당해도 모든 권한을 갖는다. 마찬가지로 하나의 키를 공유하여 여러 서비스가 사용하고 있기에 퇴사자가 생기거나 탈취 상황에서 키를 만료시키기 쉽지 않다. 극단적인 예로 하나의 AWS 키를 모든 개발자와 CI/CD agent가 사용하다가 퇴사자가 나쁜 마음을 먹고 키를 사용한다고 가정해 보자. 키를 revoke -> renew 하는 사이 시간 동안 모든 개발 작업, CI/CD 동작들이 멈출 것이다. Dynamic secret은 미리 정의한 사용자 허가 범위에 따라 임시 키를 만들어 사용자에게 반환한다. 그 임시 키는 사용자마다 공통되지 않고, 만료 기간이 정의되어 있어 기간 외엔 사용할 수 없는..