Cloud

AWS RDS는 관계형 데이터베이스(RDBMS)를 쉽게 설정, 운영하게 하는 관리형 데이터베이스 서비스이다.RDS는 MySQL, PostgreSQL, Oracle 등의 다양한 DB엔진을 지원하고, 자동 백업, Auto-Scaling, Cloudwatchf를 통한 모니터링 등을 지원해 DB 관리에 드는 노력과 부담을 줄여준다. 이러한 RDS의 기능 중 Multi-AZ와 Read Replica는 DB의 가용성, 성능, 확장성을 크게 향상시킬 수 있는 요소이다.  이번에는 이러한 Multi-AZ와 Read Replica를 알아보고 직접 구성해보도록 한다. Multi-AZ2개 이상의 AZ(가용영역, Availability Zone)에 걸쳐 DB를 구축하는 아키텍쳐, DB의 가용성을 높인 구조로 볼 수 있다.Mu..

AWS VPC CNIAWS 환경에서 동작하는 Kubernetes 클러스터에 제공하는 CNI(Container Network Interface)로, node에 배치되는 pod들에도 VPC IP를 할당해 pod 간 통신을 구현하는 방법node와 pod가 동일한 네트워크 대역을 사용한다는 특징이 존재한다.  기존의 다른 kubernetes CNI들이 네트워크 오버레이와 같은 기술을 사용해 pod에 IP를 할당했다면, AWS VPC CNI는 node 내부의 pod 간 통신은 네트워크 브릿지를 통해서 이루어지고, node를 넘어서는 pod 간 통신은 오버레이 기술이 아닌 일반 VPC 통신이 이루어진다. (VPC Native) EKS는 기본적으로 VPC CNI를 사용하고, kOps로 클러스터를 만드는 경우 clus..

클라이언트로 하여금 파일을 업로드받거나, 그 파일을 워크로드를 거친 후 결과물을 다운로드받게 하고자 하는 경우 보통 S3 버킷을 하나 생성해서 파일을 관리한다. 그리고 그 버킷을 Public하게 오픈시켜 클라이언트들이 접근하게 만든다. 하지만 이렇게 단순히 Public하게 오픈시켜 모든 클라이언트로 하여금 파일을 업/다운로드하게 하는 것은 과연 안전한 방법일까?그리고 클라이언트의 파일을 우리의 백엔드 API를 통해서 S3로 업로드하면, 우리의 백엔드에도 파일을 받고 전송하는데에 대한 부하가 발생하게 된다. 이러한 문제를 위해 S3에서는 Presigned-URL이라는 기능을 지원한다.  Presigned-URL버킷에 대한 접근 권한이 있는 사용자를 통해 버킷의 특정 객체에 대한 접근을 허용하는 단기간성 U..

서버를 운영하게 되면 로그는 자연스럽게 발생한다. 이러한 로그들은 양도 많을 뿐더러 관리하는 서버의 수가 많아지면 그 내용들을 일일히 직접 확인하기란 어려울 따름이다. 그래서 로그 수집과 가시화 시스템을 구축하여 로그들을 모니터링하게 된다.  이번에는 Loki와 Promtail, Grafana를 이용해 로그를 모니터링하는 아키텍쳐를 구축해보도록 한다. Loki & PromtailLike Prometheus, but for logs  Loki는 오픈소스 타입의 로그 모니터링 도구로, 로그를 Label을 통해 그룹화해 처리한다. Prometheus가 Metric을 수집하는데에 목적을 두었다면, Loki는 로그를 수집하는데에 목적을 둔 도구로 볼 수 있다.로그 라인의 메타데이터(Label)를 인덱싱해, 그 L..

Terraform을 통해 aws_instance를 만들면 기본 AMI값을 지정해주어야한다. 이 ami 값은 외우기도 좀 그렇고 자주 바뀌는 터라, 동적으로 가져와서 지정해줄 필요가 있다. Terraform의 'data' Block을 사용해 특정한 AMI 값을 AMI Marketplace에서 검색해 가져올 수 있다.예시로 ubuntu-22.04의 AMI 값을 가져와 본다.data "aws_ami" "ubuntu" { most_recent = true owners = ["099720109477"] # Canonical(Ubuntu 배포사)의 AWS 계정 ID filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-jammy..

지난 3-tier VPC 구축에 이어서, 이번에는 Application단(EC2, ALB 등)을 설계해보도록 한다. 아키텍쳐 구성도 Terraform 코드 작성 Application 단에서 생성할 리소스는 크게 다음과 같다. 인스턴스 4개 보안그룹 키 페어 ALB 2개 (외부, 내부) 대상그룹 2개 (외부, 내부) 먼저 Application 모듈의 변수들을 구성한다. Application 단에서 사용될 외부 변수들에는 주로 vpc 관련의 것이 있다. 인스턴스를 생성할 때 사용될 vpc_id나 배치될 서브넷의 id 값이 여기에 해당된다. 이외에도 ami의 id값이나 미리 생성해둔 security group의 id 같은 리소스도 변수로 불러와서 사용할 수도 있을 것이다. variable "vpc_id" {}..

Prometheus 공식 문서에 따르면 Prometheus에서 Alert는 크게 2가지 컴포넌트로 구성되어있다.Alert Rule : PromQL을 기반으로 정의하는 알람이 발생할 규칙AlertManager : 수신받은 Alert를 다양한 서비스에 notify를 수행오늘은 Prometheus의 Alert 아키텍쳐를 알아보도록 한다. Alerting RulePrometheus 쿼리문(PromQL)을 바탕으로 정의하는 알람 조건, 조건에 맞아 알람이 발생하면 연결된 외부 서비스로 알람을 전달하게 된다.Prometheus에서 Alert Rule을 선언하는 방법으로 Prometheus 웹 GUI 상에서 선언해주는 방법과 설정파일을 작성하는 방법이 존재한다.groups:- name: example rules: ..

도메인을 리다이렉트해달라는 내용을 요청받았다. 자세히 이야기하자면, www.before.com과 같은 도메인으로 들어온 요청을 www.after.com과 같은 다른 도메인으로 리다이렉트하도록 설정을 해달라는 내용이였다. 이러한 예시는 실제로 종종 볼 수 있다. 예를 들어 어떤 서비스의 도메인이 완전히 바뀌어서, 이전 도메인으로 접속하는 트래픽을 신규 도메인으로 리다이렉션해주는 상황이 있을 수 있다. 이외에도 회사의 브랜드나 서비스 등을 사칭하는 사례의 방지를 위해 관련된 도메인들을 구매하고 정식 서비스로 리다이렉트 시켜버리는 등의 예시도 생각 할 수는 있다. (도메인 사칭방지와 관련된 LG전자의 실제 예시에서 이같은 방법을 고려해볼 수 있을 것이다. 다만, 도메인을 모오두 사들이는 돈은 있어야겠지만.....