반응형

개요

  • 수많은 삽질을 맞치며...
  • TOBE Architecture
  • Atlantis에 Terragrunt 구성하기
  • Terragrunt 설정하기

수많은 삽질을 마치며...

해당 구성을 완료하기 위해 3일정도 매달렸던 것 같다.

막상 완료해보니 문제는 아래와 같았다.

  • Kubernetes 예제는 많으나, ECS Fargate 예제는 많지 않음
  • Ataltnstis가 구동할때 Terragrunt 옵션을 대신 사용하기
  • CPU Architecture 문제

어떻게 트러블 슈팅을 했는지는... 따로 기재하진 않겠지만 

내가한 삽질만큼 다른사람들이 하지 않길 바라며...

 


TOBE Architecture

Architecture

설정 단계는 아래와 같다.

  1. Git Webhook 설정하기
  2. Atlantis ECS Fargate 구성하기
  3. 잘 설정되었는지 확인하기...

 

Atlantis 에 Terragrunt 구성하기

Git Webhook 설정하기

이건 사실 별거없다.

기존 많은 블로그들의 글을 참조해도 상관없다.

내가 기재한 Github에 README.md를 참조하자 

여기서 중요한건 Secret은 사용해야 하기때문에 꼭 기억 / 저장해두도록...

https://github.com/zkfmapf123/atlantis-fargate

 

Atlantis ECS Fargate 구성하기

Atlantis는 ECS Fargate Module을 제공한다.

https://registry.terraform.io/modules/terraform-aws-modules/atlantis/aws/2.5.0

 

하지만 이미 나는 ALB도 이미있고, Route53도 구축된상태라 

몇몇부분 수정하였다.

  • 기존과 특이점
    • Cluster는 이미 존재했음 (코드 참조)
    • ALB도 이미 존재했음 (코드 참조)
    • environments.ATLANTIS_REPO_CONFIG_JSON (하단 설명)
    • secrets.AWS_ACCESS_KEY_ID (하단 설명)
    • secrets.AWS_SECRET_ACCESS_KEY (하단 설명)
variable "atlantis_attr" {
  default = {
    devops_prefix   = "devops"
    security_prefix = "security"
    name            = "atlantis"
    port            = "4141"
    host_header     = ["HOST_HEADER"]
  }
}

#################################################### Listner Target Group ####################################################
resource "aws_lb_target_group" "atlantis_ecs_tg" {
  name        = "${var.atlantis_attr.devops_prefix}-${var.atlantis_attr.name}-tg"
  port        = var.atlantis_attr.port
  protocol    = "HTTP"
  target_type = "ip"
  vpc_id      = var.vpc_id

  health_check {
    path                = "/"
    port                = var.atlantis_attr.port
    protocol            = "HTTP"
    healthy_threshold   = 3
    unhealthy_threshold = 3
    matcher             = "200-301"
    timeout             = 30
    interval            = 40
  }

  deregistration_delay = 60
}

resource "aws_lb_listener_rule" "atlantis_443_rule" {
  listener_arn = local.alb.security_alb.listener_443_arn
  priority     = "100"

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.atlantis_ecs_tg.arn
  }

  condition {
    host_header {
      values = var.atlantis_attr.host_header
    }
  }
}


#################################################### Atlantis ####################################################
module "atlantis" {
  source = "terraform-aws-modules/atlantis/aws"

  name = "${var.atlantis_attr.devops_prefix}-${var.atlantis_attr.name}"

  # ECS Container Definition
  atlantis = {
    environment = [
      {
        name  = "ATLANTIS_GH_USER"
        value = "[리뷰 사용자 이메일]"
      },
      {
        name  = "ATLANTIS_REPO_ALLOWLIST"
        value = "[Atlantis Webhook 설정한 GIT 주소]"
      },
      {
        name : "ATLANTIS_REPO_CONFIG_JSON", ## 이건 왜 필요한지 이따 설명
        value : jsonencode(yamldecode(file("${path.module}/server-atlantis.yaml"))),
      }
    ]
    secrets = [
      {
        name      = "ATLANTIS_GH_TOKEN"
        valueFrom = "[Github Access Token]"
      },
      {
        name      = "ATLANTIS_GH_WEBHOOK_SECRET"
        valueFrom = "[Webhook 때 지정한 SecretKey]"
      },
      {
        name      = "AWS_ACCESS_KEY_ID"
        valueFrom = "[이건 왜 필요한지 이따 설명]"
      },
      {
        name      = "AWS_SECRET_ACCESS_KEY"
        valueFrom = "[이건 왜 필요한지 이따 설명]"
      },
    ]
  }

  # ECS Service
  service = {
    task_exec_secret_arns = [
      "SSM ARNS",
 
    ]
    # Provide Atlantis permission necessary to create/destroy resources
    tasks_iam_role_policies = {
      AdministratorAccess = "arn:aws:iam::aws:policy/AdministratorAccess"
    }
  }
  service_subnets = local.was_subnet_ids
  vpc_id          = var.vpc_id

  # Cluster -> 이미 나는 Clustr가 존재햇음
  create_cluster = false
  cluster_arn = local.alb.security_alb.ecs_cluster_arn

  # ALB -> 이미 나는 ALB가 존재했음
  create_alb            = false
  alb_target_group_arn  = aws_lb_target_group.atlantis_ecs_tg.arn
  alb_security_group_id = local.alb.alb_sg_id

  tags = {
    Environment = "prd"
    Terraform   = "true"
    System      = "ecs"
  }
}

output test {
  value = "atlantis"
}

 

environments.ATLANTIS_REPO_CONFIG_JSON

이건 아틀란티스 서버자체에 Config 파일이다.

해당 Config 파일에서는 여러가지 옵션을 수정할 수 있지만 우리가 지금 당장 필요한건 Action 을 Custom으로 수정하도록 하는 옵션을 설정해야 한다. (Terragrunt를 실행하기 위해)

// server.atlantis.yaml
repos:
  - id: /.*/
    allow_custom_workflows: true ## 이걸 true로 해줘야함
    allowed_overrides:
      - apply_requirements
      - workflow
    apply_requirements:
      - approved
    workflow: default

 

만약, allow_custom_workflows 값을 true로 하지 않는다면

뭔가 계속 설정해도 terraform 으로만 실행하게 된다 (이걸로 하루정도 날렸던 것 같음)

 

secrets.AWS_ACCESS_KEY_ID / secrets.AWS_SECRET_ACCESS_KEY (Optional)

이건 무슨 옵션이지 하는 사람도 있을텐데,

Atlantis에 꼭 넣어야 하는 환경변수는 아니지만 현재 우리회사는 Multi Account로 관리되고 있기때문에

Terraform 사용자 계정을 AssumeRole을 통해서 접근하는 방안을 채택하였다.

 

자세한내용은 아래 블로그참조

https://zkfmapf999.tistory.com/31

 

Terragrunt 설정하기

자 위 방법대로 구성하면 아주 멋있는 Atlantis 가 생성된다.

그럼 저 이미지에서 Terragrunt를 구성하려면 어떻게 해야될까?

 

Terragrunt를 구동할 수 있는 이미지 만들기

Atlantis 공식문서 Terragrunt를 사용하기 방법을 읽다보면 아래 문구가 나온다.

응, Atlantis에는 Terragrunt 없어 니가 만들어서 써

 

그럼... 만들어야지

잘 읽어보면 terragrunt 파일을 만들어서 /usr/local/bin 파일에 넣은것 뿐이지만...

진짜 서치 여러군데 해봤는데 아무것도 없어서 만들었음

## 2025.2.14 dobby.lee
FROM ghcr.io/runatlantis/atlantis:latest

USER root
RUN apk update && apk add --no-cache curl jq \
    && TERRAGRUNT_VERSION=$(curl -sL https://api.github.com/repos/gruntwork-io/terragrunt/releases/latest | jq -r .tag_name) \
    && curl -L -o /usr/local/bin/terragrunt https://github.com/gruntwork-io/terragrunt/releases/download/${TERRAGRUNT_VERSION}/terragrunt_linux_amd64 \
    && chmod +x /usr/local/bin/terragrunt

# 환경 변수 설정
ENV ATLANTIS_GH_USER=test
ENV ATLANTIS_REPO_ALLOWLIST=test
ENV ATLANTIS_GH_TOKEN=test
ENV ATLANTIS_GH_WEBHOOK_SECRET=test
ENV AWS_ACCESS_KEY_ID=test
ENV AWS_SECRET_ACCESS_KEY=test

RUN mkdir -p /home/atlantis/.atlantis/bin \
    && chown -R atlantis:atlantis /home/atlantis/.atlantis

RUN chown -R atlantis:atlantis /home/atlantis/.atlantis

USER atlantis

ENTRYPOINT ["atlantis", "server"]

 

혹시... amd64로 변환해야한다면 buildx를 쓰거나 위 download 파일을 바꾸시길

 

Repository 설정 수정하기

자 여기까지 했으면 다했음

뭐만 남았냐...

 

이제 Atlantis가 구동될 Repository에 명령어만 Terragrunt로 변환시켜 주면된다.

Repository 기준 root path에 위치시키자

version: 3
projects:
- dir: [terragrunt.hcl이 존재하는 path]
  workflow: terragrunt

workflows:
  terragrunt:
    plan:
      steps:
      - env:
          name: TERRAGRUNT_TFPATH
          command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"'
      - env:
          name: TF_IN_AUTOMATION
          value: 'true'
      - run:
          command: terragrunt plan -input=false -out=$PLANFILE
          output: strip_refreshing
    apply:
      steps:
      - env:
          name: TERRAGRUNT_TFPATH
          command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"'
      - env:
          name: TF_IN_AUTOMATION
          value: 'true'
      - run: terragrunt apply $PLANFILE

 

결과화면

관련 Git Repository

반응형
반응형

 

개요

  • AIOps의 비전
  • AWS에서의 활용
  • Monitoring With AIOps 

 

AIOps의 비전

  • AIOps를 활용하여, 반복적인 작업 , 지루한 작업같은 수동적인 작업을 줄이는것이 목적

 

AWS에서의 활용

  • 적절한 규모를 정의 -> AWS Compute Optimizer 
  • AWS내에서 여러가지 질의를 통해 Insight를 얻을 수 있음 -> CloudTrail Lake
    • 한달동안 AWS 진입한 사람들 수
    • S3 download 횟수
  • CodeReview -> AWS CodeGuru
  • Integration Amazon Q
    • System Manager
    • CloudFormation

Monitoring with AIOps

AIOps
CloudWatch anomaly detection

  • 기계 학습을 통해서 CloudWatch 내에서 이상탐지
  • 기계학습을 통한, 임계값과 정상치를 자체적으로 구현
    • 자동으로 임계값 설정
    • 메트릭 시각화
    • 알림 발생 (AWS Chatbot)

 

반응형
반응형

개요

  • Micro FrontEnd가 무엇인가?
  • 예시) Formula 1.com의 예전 Architecture
  • 예시) CMS 활용 (ContentFul)
  • 예시) ECS 구성 활용
  • 예시) 최종 형태

 


Micro Frontend가 무엇인가?

  • 프론트 애플리케이션을 독립적으로 배포 및 개발할 수 있는 작은 단위로 분할
  • 팀 간 병렬작업과 코드베이스의 유비보수를 용이하게 하는 방법론
  • 애플리케이션 자체가 점점 커지면서 확장 가능한 아키텍처가 필요함
  • 결국 Front도 서버처럼 MicroService 형태로 발전하는 걸로 보임

예시) Formula 1.com의 예전 Architecture

  • 전통적인 3 tier architecture
  • 정해진 수로만 확장가능 ( Auto Scaling )
  • 릴리스 (배포) 시 사소한 변경사항에 대해 전체 테스트를 진행해야 함( 모놀리식 )

CMS 활용 (ContentFul)

  • 기존 모놀리식 형태는 유지
  • Content는 ContentFul 을 활용
    • ContentFul은, CMS (Headless Content Management System)으로 콘텐츠를 구조화하고 API를 통해 다양한 플랫폼을 지원
    • 콘텐츠 자체를 따로 구성 가능

내가 잘 이해가 안되서... CMS를 사용하면 좋은점

  • CMS 사용 전 구성
    • 주로 백엔드에서 데이터를 관리 (Database) (API 통신)
    • Frontend -> Backend -> Database 의 전통적인 통신방식
    • Frontend에서 API 호출과 렌더링을 담당
    • 콘텐츠 수정의 경우
      • 새로운 페이지 추가 및 블로그 수정 시 백엔드 및 프론트 개발자가 직접 코드를 수정
      • 배포과정이 필요하고 그에따라 서버가 잠시 다운될 수 있음
  • CMS를 사용한다면
    • 관리자가 Contentful 웹사이트에 직접 글, 이미지, 동영상을 추가 및 수정 가능
    • 프론트엔드에서 API를 통해서 데이터를 가져올 수 있다. (백엔드 없어도... API 통신을 통해서)
    • CMS 내용만 바꾼다면 배포가 없어도 프론트에서 자동반영된다 -> 비개발자가 프론트까지 직접 관리할 수 있음

 


ECS 구성 활용


최종형태 

  • Front 서버앞단은 ALB 통해서 제공
  • Routing은 CloudFront을 사용해서 구성

 

참고

 

반응형
반응형

개요

  • Terraform을 잘 사용하고 있는가?
  • 수정된 IaC 구성 방안
  • 보안을 강화하기 위한 방안
  • + Github Action (OIDC)
  • 정리

Terraform 을 잘 사용하고 있는가?

현재 우리회사에서 사용하고 있는 테라폼 구성은 아래와 같다.

ASIS

2024년 8~9월 부터 Terraform을 적용을 시작하면서,

기존 Git Repository + S3 를 시작으로 Terraform Cloud를 사용하기 시작하였다.

Terraform Cloud를 사용하면서, 정말 좋은기능도 많고 추후 여러부분에서 활용할만하다고 생각했지만...

몇몇 아쉬운 부분이 발생하였다.

 

리소스 증감에 따른 비용추가

Terraform Cloud는 총 4가지 plan이 제공된다.

주로 FreePlan으로도 많은 것을 할 수 있으나, Resource 500 부터는 Standard Plan을 사용해야 했다.

일단... 나는 IaC를 최소비용으로 구성하고 싶은 마음이 있었다. Resource 는 아래 사유로 계속 증가하였다.

  • 기존 리소스 IaC 구성 (Terraforming)
  • 새로운 서비스 증가

위 2개 업무를 틈날때 마다하니... 이건 뭐 달마다 300~400$ 넘어갔다.

물론 테라폼을 비용을 지불하면서 까지 잘 사용한다면 좋지만... 내 생각에는 효율대비 비싼 것 같다.

 

IaC Provisioning 속도

 

이 부분은 솔직히 조금 불편하였다.

terraform plan 을 진행하면, 기존 S3를 State 로 사용하는것보다 2~3배 느렸다.

뭐 당연한 부분이라고 생각하지만 ( Terraform -> Terraform Cloud -> Computing -> Plan ... )

뭔가 빠르게 IaC 를 구성하는 관점에서는 조금 답답한 부분인것 같다.

 

의외로 너무 복잡

Terraform Cloud는 제공하는 기능이 정말 많다.

Drift, RBAC, 팀 / 조직별 권한 제어, Infra Catalog 등등 너무 많다.

하지만 현재 우리조직의 단계는 위 항목들을 적용하는 것 보단, 빠르게 인프라를 구성하고 리뷰하고 적용하는 부분이다.

굳이 저 기능까지는 필요가 없다고 생각했다.

 


효과적인 IaC 구성방안

그래서 우리는 Terraform Cloud를 대체할만한 제품을 찾기 시작하였다.

Attlantis 도입

Attlantis 가 정답이라고 할 순 없지만, 현재 상황에서는 Terraform Cloud 보다는 더 낫다고 생각하였다.

 

그렇게 생각한 이유...

  1. 비용 절감 포인트
  2. GitOps 관점에서 더 쉬움

비용 절감 포인트

이건 뭐... 그냥 무료니까 (공짜가 좋음)

그리고 ECS Fargate Terraform module도 제공하니...

 

GitOps 관점에서 더 좋음

Terraform Cloud와 Attlantis 모두 여러 VCS와 통합이 가능하나, 동작 구성의 차이가 존재한다.

Terraform Cloud의 경우, 코드변경을 Push (Branch, Tag) 에 의해 동작이 결정된다 (Plan -> Apply)

Atlantis의 경우, PR (Pull Request) 기반의 작업 흐름을 만든다. PR을 기준으로 Plan을 실행하고 결과를 PR 댓글로 남긴다.

그 과정에서 변경사항이 Git 에 기록되면서 관리가 된다.

 

물론 TC (Terraform Cloud) 가 더 좋을 수는 있지만, 우리 팀에서는 Atlantis 형태가 더 조직에 성향에 맞다고 생각하였다.

 


 보안을 강화하기 위한 방안

Terraform을 사용하다보면, 아래 처럼 Provider를 구성하기 마련이다.

### use Credentials 
provider "aws" {
  access_key = ....
  secret_key = ....
  region = "ap-northeast-2"
}

### use Profile
provider "aws" {
  profile = ...
  region = "ap-northeast-2"
}

 

근데 위 방법은 어째선지... 좀 위험할 수도 있다고 생각스...

좀더 효과적인 방안이 없을까...

 

IAM Role을 사용한 접근 방법

 

IAM Role을 사용해서 대신 Provider를 구성할 수 있다.

구성된 IAM Role은 AssumeRole 을 활용하여 관련계정에 접근하고 (Trust Relation Ship), 

해당 계정은 PassRole을 사용하여 필요한 권한을 부여한다

 

관련 Git Repository 참조


 + Github Action (OIDC)

관련 Git Repository 참조

 

 

정리

위 구성을 Draw.io로 그려보면... (그리는거 쉽지 않네...)

 

반응형
반응형

개요

  • terragrunt destroy 이슈
  • 한번 살짝 뜯어보자...
  • 해결책

terragrunt destroy 이슈

최근 테라폼을 사용하면서, Dry 한 코드를 구성하기 위해 terragrunt를 사용하였다.

폴더 구조는 아래와 같다.

|- dev 
  |- __shared__.hcl 			                ## 공통 구성
  |- vpc						## vpc
    |- terragrunt.hcl
    |- main.tf
  |- ec2						## ec2
    |- terragrunt.hcl
    |- main.tf
  |- ecs						## ecs
    |- terragrunt.hcl
    |- main.tf

 

Terragrunt에 대해서 어느정도 가이드 문서를 써볼 의향은 있으나.. 지금은 아님

하다보니 문제가 생겼다.

 

destory가 안됨

이러고 계속 유지... 나중엔 Stack Overflow 가 발생

 

아니.. 미칠노릇

apply, plan, state, output... 여러 명령어들은 되는데 destory만 안된다

문제가 뭘까


한번 살짝 뜯어보자...

tracing 용 command

terragrunt [명령어] --terragrunt-log-level debug

terragrunt plan

terragrunt plan -> terraform plan

 

terragrunt destroy

terragrunt destroy ->git rev-parse --show-toplevel

 

왜? terragrunt destory 를 하면, git rev-parse --show toplevel을 하지...

terragrunt는 작업 Dir 에서 -> Git 최상위 Dir 까지 확인하기 위해 실행한다.

 

그럼 결국 terragrunt destroy는 Git 최상위까지 모든 디렉토리 구조를 검색하기에 시간이 걸릴 수 있다.

현재 내가 사용하고 있는 Repositoy는 꽤 커서 Stack Overflow가 난거였다.


해결책

간단하게 프로젝트를 하나파서 했을때도 저 이슈는 계속 발생했었다.

terragrunt 0.72.2 (2025년 1월 19일 기준 latest) 을 update 했음에도 계속 이슈가 발생하였다.

그래서 여러 해결책을 알아본 결과... 아래 명령어를 사용하여 Destroy를 진행하면 쉽게 지워질 수 있었다.

 

terragrunt destroy --terragrunt-no-destroy-dependencies-check

 

아래 명령어는 의존성 관계 체크를 건너뛰게 된다.

일단 destory가 안된다는건 Critical 하기에 위 명령어를 사용할 계획이다.

의존성이 문제가 된다면, __shared__.hcl에 의존관계를 명확히 하면 해결될수도...

반응형
반응형

개요

  • python 앱 빌드할때 시간이 너무 오래걸린다
  • 빌드 시간 단축하는 방법
  • 결과
  • 추후 고민해야 할 부분

 


python 앱 빌드할때 시간이 너무 오래걸린다

최근 회사내에서 AI 서비스를 운영하면서,

Build 하는시간이 너무 오래걸렸다. (평균 20분)

 

 

이건 뭐... 배포하는데 20분씩 걸리는건 조금... 아주 많이 비효율적이었다.

배포만 20분이지 중간에 실패하면 30~40분씩 걸린다 (... CloudFormation 때문인것도 있음)

 


문제인식

해당 앱의 전체적인 문제점을 파악해보았다.

  • Docker Container Image 용량이 2GB 육박함 (Multi Staging임에도 불구하고)
  • Build 하는 과정에서 python package 버전이 명시되지 않아서 설치하는 과정에서 굉장히 오래걸림
  • docker cache가 제대로 되고 있지 않음

먼저 해결할 수 있는 부분 선택하기

  • Docker Container Image 용량이 2GB 육박함 (Multi Staging임에도 불구하고)
    • 이부분은 dive 를 사용해서 파악해볼 수는 있지만 시간이 꽤 오래걸릴것같아 pass
    • 추후에는 고쳐져야 할 문제, 결국 2GB 데이터의 Data Transfer 비용도 상당할것으로 예상됨
    • https://github.com/wagoodman/dive 
  • Build 하는 과정에서 python package 버전이 명시되지 않아서 설치하는 과정에서 굉장히 오래걸림 (선택됨)
    • package 버전을 명시한다면 빌드시간을 단축할 수 있을 것 같음
  • docker cache가 제대로 되고 있지 않음 (선택됨)
    • docker cache 가 제대로 이뤄지게끔 Docker 명령어를 수정하기로 함

 


빌드 시간 단축하는 방법


Build 하는 과정에서 python package 버전이 명시되지 않아서 설치하는 과정에서 굉장히 오래걸림

사실 난 파이썬 잘 모른다.

그래서 package 버전을 명시하려니... 와... 에러가 너무 많이남

python 자체가 이렇게 버전별로 dependency가 있는지 처음알았음

 

그래서 꼼수를 하나썼음...

"아니... 지금 운영상에 올라가있는 서비스 package 버전을 알면 되잖아" -> correct

 

2가지 방법이 존재한다.

  • 현재 구동중인 서비스는 ECS로 운영중이고, ssm exec 명령어를 사용하여 확인
aws ecs execute-command --profile PROFLE_NAME --region REGION_NAME\
  --cluster CLUSTER_NAME \
  --task TASK_ID \
  --container CONTAINER_NAME \
  --command "/bin/sh" \
  --interactive
  • docker image 를 다운 받아서, exec로 버전 파악하기 (이걸로 함)
## 기존 이미지 다운로드
docker pull [ecr에 올라가있는 image url]:latest

## sleep infinity로 run
docker run [image-url] sleep infinity

## exec로 접근
docker exec -it [container-id] /bin/sh

## package 버전확인
pip show [package]

 

 

나는 2번째 방법을 사용해서, 

전체 package에 대한 버전을 확인하고 명시하였다.

 


docker cache가 제대로 되고 있지 않음

Docker 이미지 구성하는 과정에서 Cache가 잘 되고 있지 않았다. 

물론 Layer Cache가 구성되어있지만, 하루에한번 Action에 잔존되어있는 이미지를 삭제하게된다면

Cache 없이 Image를 Build하였다.

 

그래서 build 명령어에 cache-from 추가하였다.

docker build -t sena -f Dockerfile.sena --cache-from [ecr iamge url] .

 

결과

일단 Build가 5분안에 끝났다. (원래는 10분 ~ 13분 가량 소요되었음)

배포까지 하면 8분안에 끝날듯하다 ... 현재는 다른이슈로 결과창을.... (추후에)

 

추후 고민해야 할 부분

현재 Docker Image가 2GB 정도된다. 

Image 경량화작업을 진행해야 할듯하다... 언제나 작업할건 참 많은것 같다.

반응형
반응형

개요

  • AWS Cloud 내 Dump 하는 방법
  • MYSQL Dump 방법
  • PostgreSQL Dump 방법
  • PostgreSQL Vector DB Dump 방법

최근 아래와 같은 요청이 많이 들어온다.

"A 테이블에 있는 데이터 스테이징환경에 Dump 해주세요"

"A RDS에 인덱스 테스트 해야되니까 test DB 하나 만들어주세요"

...

 

해야지... 이슈 없다면 해야ㅈ....

 

 


AWS Cloud 내 Dump 하는 방법

사실 이건 굉장히 쉽다. 

그냥 Snapshot 하면된다.


RDS Snapshot 을 활용하여 Database 복원하기

1. 스냅샷 생성

 

2. 생성된 스냅샷 복원



3. 복원 시 알맞은 Config 값 수정하기


교차계정 내 RDS Snpshot 공유하기

1. 완성된 스냅샷을 공유

 

2. 스냅샷 공유하기 위해 계정 ID 추가
3. 나와 공유됨에서 공유된 스냅샷 확인


다른 리전으로 보내야 한다면?

1. 스냅샷 복사

 

2. 복사할 리전을 선택한 후 진행

만약, 다른 계정에 다른 리전에 해당 스냅샷이 존재해야 한다면?

스냅샷 공유 -> 스냅샷 복사를 하면된다. 좀 귀찮긴 하지만 스냅샷이 가장 편함스


KMS가 AWS Managed Key로 되어있다면?

이 경우가 은근 화나는 경우인데,

AWS KMS 키로 암호화가 되어있는 경우, KMS 정책을 수정할 수 없기에 ( 타계정 Access )

다른 KMS로 스냅샷을 복사 한 후 스냅샷을 공유 해야 한다. -> KMS로 다시 암호화를 하는것이니 시간이 오래걸림...

 

1. KMS 변경

{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::[기존계정]:root",
          "arn:aws:iam::[공유될 계정]:root"
        ]
      },
      "Action": "kms:*",
      "Resource": "*"
    },
   	....

 


MYSQL Dump 방법

근데, 스냅샷을 사용할 수 있다면 아주 양반이다.

최근 특정 Table 만 Dump 해달라....

OnPremise에 있는 데이터를 떠달라... 

 


MYSQL Dump 명령어

mysqldump -h [DB_HOST_NAME] \
-u [USER] -p \
--databases [DATABASE] \
--set-gtid-purged=OFF \
--single-transaction \
--routines \
--triggers \
--events \
--compress \
--add-drop-database \
--quick \
--hex-blob > output.sql

 

  • --single-transaction
    • InnoDB 테이블의 대한 일관성 보장, 읽기잠금 최소화 -> 대용량 DB Dump 할때 필요
  • --routines
    • Stored Procedure 함수 포함
  • --triggers
    • 테이블내 트리거 포함
  • --events
    • 이벤트 스케쥴러 포함
  • --compress
    • 전송 압축 (필요)
  • --add-drop-database
    • 데이터 복구전에 기존 DB 삭제
  • --quick
    • 메모리 사용량 줄이고 성능향상
  • --hex-blob
    • 바이너리 데티러를 16진수로 덤프 -> 이미지 및 BLOB 데이터 복구 시 필요
  • --set-gtid-purged=OFF
    • 안하면 Restore 할때, Access Denied 에러가 발생한다.

MYSQL Restore 명령어

mysql -h [DB_HOST_NAME] -u [USER] -p [DATABASE] < output.sql

mysql -h [DB_HOST_NAME] -u [USER] -p --force [DATABASE] < output.sql > /dev/null

PostgreSQL Dump 방법


PostgreSQL Dump 명령어

pg_dump -h 호스트네임 -U 유저네임 -p 포트번호 -d 데이터베이스 -f ./test.dump

pg_dump -h 호스트네임 \
-U 유저네임 \
-p 포트번호 -d 데이터베이스 -F c -b -v -f ./test.dump

 

첫번째 방법은 기본적인 Text 형식 (SQL Script)로 덤프된다. (다른 옵션 존재하지않음)

두번째 방법은 아래와 같은 옵션을 사용한다.

  • -F c 
    • 백업파일을 커스텀 형식으로 구성
    • pg_restore를 활용하여 복원
    • 바이너리 형식으로 저장
  • -b
    • large objects의 데이터를 포함하여 백업
    • 대규모 객체가 있는 경우 사용
  • -v
    • verbose 모드로 백업상태를 출력
    • 디버깅 용

PostgreSQL 복구 명령어

psql -h 호스트이름 -U 유저이름 -p 포트번호 -d 데이터베이스 -f test.dump

pg_restore -h 호스트네임 \
-U 유저네임 -p 포트번호 -d 데이터베이스 \
-F c -v ./test.dump

 

psql은 위의 기본옵션으로 데이터를 Dump 하였을때 사용한다.

pg_restore은 커스텀형식으로 Dump 했을 경우 사용한다.

 


PostgreSQL Vector DB Dump 방법

사실 이게 문제다.

회사 내에서 AI 프로젝트를 AWS로 내재화하는 작업에서 

기존 OnPremise 로 구성된 PG를 RDS로 마이그레션 해야했다.

 

결국 pgVector 문제였다.

pgVector의 버전을 동일하게 했을때 문제는 없었다.

 

vector extension 설치

 

vector 0.7.0 설치 (pg 16.3)

 

데이터도 너무 커서 테이블 단위로 Dump / Restore 하였다.

## dump
pg_dump -h 호스트네임 -U 유저네임 -p 포트번호 -d 데이터베이스 -t public.테이블이름 -f ./test.dump

## restore
psql -h 호스트네임 -U 유저네임 -p 포트번호 -d 데이터베이스 -f test.dump

 

반응형
반응형

개요

  • 개발인생 회고
  • 열심히 살았는가?
  • 놀기만 했는가?
  • 앞으로는 어떻게 살아야 하는가?

개발인생 회고

2024년 굉장히 나에게는 다사다난했다.

굵직한 것들만 한번 간단하게만 기재를 한번 해보자...

 

  1. 2023년 11월에 게임회사 퇴직 -> 본부가 날라감 (엔XX)
  2. 2024년 2월에 새로운 회사 입사 -> 건강문제로 인한 퇴사 (팀XXX)
  3. 2024년 3월에 새로운 회사 입사 (지XXXXXX)
  4. 2024년 5월에 팀장으로 승진
  5. 2024년 12월에 갑상선 수술 
  6. 현재... 체력이 없음

2024년에서 가장 굵직한 사건은 크게 2개 였던 것 같다.

  • 팀장으로 승진
  • 갑상선 수술 - 이건... 쓰기 싫음

팀장으로 승진

우습지만... 회사에서 이름이 Dobby 임 (이름 잘 지었음)

이야... 내가? 처음에는 감이 잘 안왔다.

뭐 그냥된건 아니고 몇가지 이유가 있긴 하다

4~5월달에 미친듯한 퍼포먼스를 보여주기도 했고, 없던 정책을 적용하기도 했고, ... 기존 팀장님이 퇴사하시도 했고

 

사실 기존 팀장님이 나간것에 대해서는 크게 분노하였다 -> 왜냐하면 거의 취업사기...

하지만 어쩔수 없지 이미 이렇게 된거 열심히 하겠다고 했다.

지금 생각해보면 조금 오글거리지만, 인사팀에서 팀장된 기념으로 하고싶은말 없냐니까.. 이렇게 말했다.

 

앞으로 남겨진 업무 최대한 완료하고 문제생기면 원복한 후 책임질 사안에대해서는 책임지고 퇴사하겠다.

 

크... 이때의 간지란 낭만이 넘쳤던 시절이다. 물론 7개월 전이지만...

 

문제가 난다.. 난 아무것도 모른다

 

이게 참 과학인게...

기존 있던 분이 나가면 항상 문제가 나더라

여기저기 팡팡 터지면서, 정말 내가 모르는 문제들을 계속해서 겪었었다..

 

여기서 멘탈이 1차로 나갔던것같다.

다시한번 마음속에 새기기로 했다. 

퇴사자는 모든지 알고있다는것을 어디서 터질지, 어디가 문제였다는것을, 언제쯤 문제가 될것까지도...

 

근데, 아직까지도 이렇게 티스토리에 글 끄적이는거보면, 잘 이겨낸 걸지도 모르겠다.

 


열심히 살았는가?

점수로 표현하자면... 60점인 것 같다.

2024년에는 솔직히 목표가 많았다. 욕심이었지만

 

  • Elastic Search 공부하기
  • Kafka 공부하기 [완료]
  • Kubernetes 공부하기
  • Golang 공부하기 [완료]
  • Event Driven의 대해서 더 공부해보기 [완료]

5개중에 3개만 했네... 그리고 자격증도 따고싶었는데 게을러서 미뤘던 것 같다.

뭐 핑계를 좀 대자면

 

연애도 하고

탁구도 좀 치고

친구랑 회사끝나면 KFC도 가고

잠도 좀 자고

... 

 


놀기만 했는가?

핑계를 적으니... 좀 많이 놀았던 것 같다.

내 나이 32살... 94년생... 만 3년차.. 아직은 놀때가 아니거늘

 

더 열심히 살아야하는데... 무성했던 Github에 잔디도 없다가 최근에서야 다시 하기 시작했다. (열심히 살자...)

 

 


앞으로는 어떻게 살아야 하는가?

내가 Devops Engineer로 전향하게 된 계기는 어쩌면 단순했던 것 같다.

CI/CD 라는 분야의 대해서 깊이 고민하고 구성해보고 싶어서 공부하다가 눈 뜨니까 여기까지 온 것 같다 (아직 저년차지만...)

 

근데 솔직히 이제 CICD는 좀 질렸달까? 

아니.. 질렸다라기 보다는 그외 분야를 더 공부해보고 싶다라는 생각을 자주 한다.

 

물론 Kubernets, AWS 공부는 꾸준히 할 생각이지만...

SRE 위주의 공부를 좀 해보고 싶다. 

 

이제는 구성하고, 구현하고 하는것은 좀 뒤로 미루고 

구현된것들을 고도화 하는 방안에 대해서 공부를 많이 해보고 싶다.

 

앞으로 2025년은 SRE 관련된 글을 조금씩 써보지 않을까?

1년후에 나는 어떻게 바뀌어있을지 궁금하다. 

뭐 궁금하진 않다. 어차피 크게 안뀌어있을 것 같음

반응형

'개발인생_회고 > 개발3년차_devops_2024년' 카테고리의 다른 글

초보팀장 (1)  (0) 2024.10.27

+ Recent posts