Skip to main content

3 posts tagged with "DevOps"

View All Tags

· 11 min read

이전 포스팅에서 EKS 클러스터와 어플리케이션 배포 및 테스트를 간단하게 해봤다. 이번에는 AWS ECS 또는 AWS Batch Application을 CircleCI를 통해 배포 및 업데이트 하는 것을 알아본다.

Application 요구사항

기본적으로 현재 업무 중에 IBM클라우드에서 AWS로 데이터를 가져와야 하는 업무가 생겨서 시작되었고 정기적으로 매일 새벽에 크롤링(Pull)방식으로 데이터를 복제해야하는 Use-Case를 구현해야 했다.
CI/CD Pipeline구성이 주 목적으로 Application구현은 포스팅 내용에서 제외하였다.

기본 요구사항

  • Github Account
  • CircleCI Account (Github Auth)
  • AWS ECR(Elastic Container Registry)
  • AWS Batch(ECS)

CI/CD 구성안

실제 프로젝트에 적용할 구성안이다.
기본적으로 모든 구성은 최대한 비용이 들지 않고 AWS 종속성을 제거한 방법으로 구성하였다.

  • Code Repository : Github
  • CI : CircleCI
  • Registry : AWS ECR
  • CD : CircleCI
  • Target : AWS Batch(ECS)
  • Notification : Slack

이번 데모에서는 다음과 같은 시나리오로 진행하려고 한다.

  1. Terraform으로 AWS Batch 생성
  2. Github에 수정된 Batch Code(Shell Script) Commit & Triggering CircleCI
  3. Docker Build & AWS ECR로 Push
  4. S3로 myjob shell 파일 복사
  5. AWS Batch(ECS) Job Definition 변경(Change Image)

AWS Batch

기본적으로 Batch 컴퓨팅을 목적으로 하는 서비스로 컴퓨팅 타입을 Fargate 또는 EC2 중 하나를 선택하여 동적으로 프로비저닝하는 서비스이다.
초기 설정이 번거롭긴 하지만 한번 구성하고 나면 별도 관리가 필요없고 Batch작업이 발생하는것과 컨테이너 이미지 보관비용 이외에는 추가 비용이 발생하지 않기 때문에 비용측면에서 장점이 있는 서비스이다.
위에서 이야기한 정기적으로 새벽마다 크롤링(Pull)방식으로 데이터를 복제해야하는 Use-Case를 구현하는것이 적당한 워크로드 구현방법이라 생각했기 때문에 AWS Batch 서비스를 사용하게 되었다.

간단한 Batch demo는 https://github.com/awslabs/aws-batch-helpers/에서 확인이 가능하며 CircleCI연동을 위해 Fork후 진행하였다.

Demo Repository : https://github.com/ddiiwoong/aws-batch-helpers/

CircleCI

모든 Pipeline은 CircleCI기반으로 작성하였다. 혹자는 AWS Code Commit, Pipeline을 사용하지 않느냐고 문의하시는 분들도 있는데 다음과 같은 이유로 CircleCI를 선택하였다.

  • Fully Managed (Serverless)
  • AWS 종속성 최소화
  • Git, Registry, CD영역의 확장성 고려
  • AWS Console 접속 최소화
  • 쉽고 단순하게 빌드 환경구성
  • 소규모 프로젝트 빠르게 시작 가능

Amazon Elastic Container Registry (ECR)

개인적으로 Registry는 구축형보다는 Managed서비스를 사용하는것이 좋다고 보기 때문에 Webhook을 Native하게 지원하는 DockerHub도 대체 가능하다고 생각한다.

  • Fully Managed
  • Security (IAM) 연동
  • CircleCI Orbs 제공
  • EKS, ECS 연동 용이

Terraform

https://www.terraform.io/docs/providers/aws/index.html

선언적 인프라스트럭처 관리 도구로 많이 사용하고 있는 도구이며 Docs와 블로그 자료가 많은 관계로 따로 설명하지 않겠다.
이번 포스트에서는 AWS Batch를 생성하는 영역을 Terraform이 담당한다.

CircleCI Config 작성

version: 2.1
orbs:
aws-ecr: circleci/aws-ecr@6.1.0
aws-ecs: circleci/aws-ecs@0.0.8
aws-s3: circleci/aws-s3@1.0.11
aws-cli: circleci/aws-cli@0.1.13
jobs:
sh-s3-upload:
docker:
- image: 'circleci/python:2.7'
steps:
- checkout
- aws-s3/copy:
from: ./myjob.sh
to: 's3://batch-ecr-test/myjob.sh'
deploy-batch:
executor: aws-cli/default
steps:
- checkout
- aws-cli/install
- run:
name: Update AWS Batch Job
command: |
aws batch register-job-definition --job-definition-name fetch_and_run --type container --container-properties '{ "image": "823928750534.dkr.ecr.ap-northeast-2.amazonaws.com/fetch_and_run:v20190623", "vcpus": 1, "memory": 512}'
workflows:
build-and-deploy:
jobs:
- aws-ecr/build-and-push-image:
repo: $AWS_RESOURCE_NAME_PREFIX
tag: v20190623
- sh-s3-upload:
name: sh-s3-upload
requires:
- aws-ecr/build-and-push-image
- deploy-batch:
name: deploy-batch
requires:
- sh-s3-upload

단계별 설명을 위해 부분적으로 설명하도록 하겠다.

  1. Terraform으로 Batch 배포

    resource "aws_batch_compute_environment" "default"{ 
    compute_environment_name = "env_fetch_and_run"
    compute_resources {
    instance_role = "arn:aws:iam::823928750534:instance-profile/ecsInstanceRole"
    instance_type = [
    "optimal",
    ]
    desired_vcpus = 1
    max_vcpus = 1
    min_vcpus = 0
    security_group_ids = [
    "sg-0632cf81b5c4dff17"
    ]
    subnets = [
    "subnet-0c4f8135b536e8fab",
    "subnet-0a261950d894cf27e"
    ]
    type = "EC2"
    }
    service_role = "arn:aws:iam::823928750534:role/service-role/AWSBatchServiceRole"
    type ="MANAGED"
    }

    Batch Computing 환경을 구성하게 되는데 "aws_batch_compute_environment"를 사용한다.

    • compute_environment_name : (필수) 컴퓨팅 환경 이름
    • compute_resources.instance_role : (필수) EC2에 적용되는 Role
    • compute_resources.instance_type : (필수) 사용 가능한 instance 유형
    • compute_resources.desired_vcpus : (옵션) 원하는 CPU수
    • compute_resources.max_vcpus : (필수) 최대 CPU수
    • compute_resources.min_vcpus : (필수) 최소 CPU수
    • compute_resources.security_group_ids : (필수) EC2에 적용되는 Security Group
    • compute_resources.subnets : (필수) Subnets 목록
    • compute_resources.type : (필수) EC2를 기반으로 생성, SPOT instance 사용가능
    • service_role : (필수) AWS Batch가 다른 AWS 서비스를 호출 할수있게 해주는 IAM Role(ARN)
    • type : (필수) MANAGED나 UNMANAGED를 선택할 수 있고, MANAGED의 경우 compute_resources에 세부 사항을 설정할 수 있다.
    resource "aws_batch_job_definition" "default" {
    name = "fetch_and_run"
    type = "container"

    container_properties = <<CONTAINER_PROPERTIES
    {
    "command": [],
    "image": "823928750534.dkr.ecr.ap-northeast-2.amazonaws.com/fetch_and_run:v20190623",
    "vcpus": 1,
    "memory": 512,
    "volumes": [],
    "environment": [],
    "mountPoints": [],
    "ulimits": []
    }
    CONTAINER_PROPERTIES
    }

    Job Definition 정의("aws_batch_job_definition")에서는 Resource spec 및 Command(Docker RUN), Container IMAGE 등을 선언하게 된다.

    • name : (필수) Job Definition 이름
    • type : (필수) Job Definition 유형, ECS로 처리하기 위해 container로 선택
    • container_properties : (선택) JSON 형태로 작성하는 container 속성정보 (Image, Resources, Command, MountPoint 등)
  2. .circleci/config.yml에 CircleCI 버전 명시 및 관련 orb(ecr,ecs,s3,cli) 추가
    기본적으로 2.1로 설정을 해야 ecs, eks orb 사용이 가능하다.

    version: 2.1
    orbs:
    aws-ecr: circleci/aws-ecr@6.1.0
    aws-ecs: circleci/aws-ecs@0.0.8
    aws-s3: circleci/aws-s3@1.0.11
    aws-cli: circleci/aws-cli@0.1.13
  3. workflow 구성

    build-and-push-image -> sh-s3-upload -> deploy-batch 순으로 순차적으로 pipeline구성을 하였다.

    workflows:
    build-and-deploy:
    jobs:
    - aws-ecr/build-and-push-image:
    repo: $AWS_RESOURCE_NAME_PREFIX # data-crawler-test
    tag: v20190623
    # create-repo: true
    # dockerfile: Dockerfile
    - sh-s3-upload:
    name: sh-s3-upload
    requires:
    - aws-ecr/build-and-push-image
    - deploy-batch:
    name: deploy-batch
    requires:
    - sh-s3-upload

    기본적으로 CircleCI에서는 orb job을 [orb name]/[predefined-job] 형식으로 선언한다.

    I. 첫번째 step에서는 container image를 build하고 push하는 Job을 수행하므로 aws-ecr/build-and-push-image을 선언한다.
    자세한 내용은 https://circleci.com/orbs/registry/orb/circleci/aws-ecr를 확인하자.

    II. 두번째 step에서는 S3에 배치스크립트를 올리는 Custom Job을 수행한다. Job은 Step의 모음으로 선행되어야할 Job은 상위에 requires: 에서 선언하면 된다.

    III. 세번째 step에서는 AWS Batch job definition의 container image를 교체(revision 변경)하는 Custom Job을 수행한다.

  4. custom job 구성 Workflow에서 선언한 Custom Job의 상세 definition을 기재한다.

    jobs:
    sh-s3-upload:
    docker:
    - image: 'circleci/python:2.7'
    steps:
    - checkout
    - aws-s3/copy:
    from: ./myjob.sh
    to: 's3://batch-ecr-test/myjob.sh'
    deploy-batch:
    executor: aws-cli/default
    steps:
    - aws-cli/install
    - run:
    name: Update AWS Batch Job
    command: |
    aws batch register-job-definition --job-definition-name fetch_and_run --type container --container-properties '{ "image": "823928750534.dkr.ecr.ap-northeast-2.amazonaws.com/fetch_and_run:v20190623", "vcpus": 1, "memory": 512}'

    I. sh-s3-upload 에서는 aws-s3/copy 를 사용하여 원하는 S3버킷에 사용할 스크립트를 업로드 한다. checkout에서는 현재 상태의 git repo를 clone하게 된다.

    II. deploy-batch 에서는 aws-cli/install 를 사용하여 기존에 작성한 Batch Job definition을 awscli로 원하는 새로운 image로 업데이트 하게 된다.

CircleCI 실행

빌드 및 배포과정을 간단하게 설명하면 코드가 업데이트되면 CircleCI는 해당 저장소의 .circleci/config.yml 을 기준으로 빌드 및 배포를 시작하게 된다.

README.md에 Build Status Badge 달기

https://circleci.com/docs/2.0/status-badges/

badge 위 링크와 설정을 참고하여 아래 그림과 같이 Build Statud Badge를 달 수 있다.

badge

정리

이번에는 CircleCI를 가지고 AWS Batch job을 구성하는 데모를 진행하였다.

얼마전인가에도 어형부형님께서도 언급하신 선언적인 구성 기반에 최대한 serverless 환경에서의 배포를 추구하게 되다 보니 아래와 같은 CI/CD Pipeline 시나리오를 구상하게 되었다.

cicd

새로운 기능의 브랜치(New Feature)가 Git에 push되면 빌드와 테스트가 트리거되어 자동으로 진행되고 동시에 개발자가 PR을 작성하면 동료 및 담당 상급자에게 코드 리뷰를 받게 된다.

리뷰가 통과되고 CircleCI에서 빌드가 성공했다면 승인단계를 통해 Merge를 하고 CircleCI 가 한 번 더 빌드를 시작하고 배포까지 수행하게 된다.

ECS나 Batch로 배포는 CircleCI를 통해 직접 배포를 하고 EC2나 EKS로의 배포는 Terraform 및 ArgoCD를 통해 배포를 진행하는 방식이다.

다음번 포스팅에는 위 그림 기반으로 CircleCI와 ArgoCD를 활용하여 EKS기반 배포과정을 정리할 예정이다.

ko-fi

· 11 min read

CI/CD는 개발단계에서 지속적인 통합, 배포를 통해 효율성을 높여주는 도구라고 말할수 있다. 특히 GitOps가 중요시 되는 최근 트렌드에서 Public Git서비스와 통합은 필수적인 요소이다.

GitHub MarketPlace에서 CI 라고 검색하면 다음과 같은 결과를 얻을수 있다.

github-ci

CircleCI, Travis CI, Google Cloud Build 등 최근 트렌드한 도구들을 확인할 수 있다.

이번 포스팅에서는 CircleCIGitHub과 연동해서 AWS ECR Push 및 EKS로 배포하는 간단한 Pipeline을 구성하는 방법을 적어보고자 한다.

CircleCI - GitHub Accout 연동

circleci.com에 접속하여 Sign Up을 진행하면 GitHub과 BitBucket 계정을 연동할 수 있는데 일반적인 GitHub 3rd Party OAuth연동 진행을 하게된다.

init

위 그림처럼 모든 Repository가 확인되고 Follow할 Repository를 선택하면 초기 구성이 완료된다.

error

첫 연동이 되면 Build를 진행하게 되는데 위 그림과 같이 error를 보게 되는데 이는 기본적으로 circleci가 필요로 하는 기본 설정값(.circleci/config.yaml)이 없어서 발생하는 오류이다.

#!/bin/sh -eo pipefail
# No configuration was found in your project. Please refer to https://circleci.com/docs/2.0/ to get started with your configuration.
#
# -------
# Warning: This configuration was auto-generated to show you the message above.
# Don't rerun this job. Rerunning will have no effect.
false

위에서 보이는것 처럼 config를 체크하는것도 하나의 가상머신(컨테이너)이 진행하는데 CircleCI콘솔에서 Spin up Environment 로그를 보면 Docker(18.09.6)로 aws Linux기반으로 환경구성을 하는 것을 알 수 있다.

Build-agent version 1.0.11727-b0960fc9 (2019-05-23T02:12:54+0000)
Docker Engine Version: 18.09.6
Kernel Version: Linux 9a20a41aeae4 4.15.0-1035-aws #37-Ubuntu SMP Mon Mar 18 16:15:14 UTC 2019 x86_64 Linux
Starting container bash:4.4.19
using image bash@sha256:9f0a4aa3c9931bd5fdda51b1b2b74a0398a8eabeaf9519d807e010b9d9d41993
...

CircleCI Grossary

아래 링크는 CircleCI에서 자주 사용하는 용어들을 따로 정리한 페이지이다. 주로 컨테이너 기반으로 동작하기 때문에 용어들은 Docker에서 사용하는 용어과 겹치는 부분이 많다.

https://circleci.com/docs/2.0/glossary/

위 링크 내용을 확인하면 Orbs라는 용어가 나오는데 이는 공유가능한 패키지로 Jenkins의 Plugin과 유사한 개념이라고 보면 된다. CircleCI에서 제공하는 자체 패키지 뿐만 아니라 3rd Party orbs를 제공하고 있다.

MacOS에서는 brew를 통해 cli를 설치하고 orb 리스트를 확인하거나 https://circleci.com/orbs/registry/에서 확인할 수 있다.

$ brew install circleci
$ circleci orb list
Orbs found: 43. Showing only certified orbs.
Add --uncertified for a list of all orbs.

circleci/android (0.1.0)
circleci/artifactory (1.0.0)
circleci/aws-cli (0.1.13)
circleci/aws-code-deploy (0.0.9)
circleci/aws-ecr (6.1.0)
circleci/aws-ecs (0.0.8)
circleci/aws-eks (0.1.0)
circleci/aws-s3 (1.0.11)
...
circleci/jira (1.0.5)
circleci/jq (1.9.0)
circleci/kubernetes (0.3.0)
circleci/lein-nvd (0.0.2)
circleci/maven (0.0.8)
circleci/node (1.0.1)
...
circleci/slack (3.2.0)
circleci/twilio (0.0.1)
circleci/welcome-orb (0.3.1)

In order to see more details about each orb, type: `circleci orb info orb-namespace/orb-name`

Search, filter, and view sources for all Orbs online at https://circleci.com/orbs/registry/

Circle Architecture

circle-arch

GitHub 또는 Bitbucket에서 관리하는 Repository가 CircleCI 프로젝트로 승인되면 최초에는 컨테이너나 가상머신환경(2core 4GB)이 프로비저닝 되고 자동으로 테스트가 진행된다.

테스트가 완료된 후 성공 또는 실패에 대한 Alert설정(Email, Slack)이 가능하고 각 단계(job, workflow)에 대한 결과는 각 단계별 세부 정보 페이지에서 확인할 수 있다.

또한 배포는 AWS CodeDeploy, AWS ECS, AWS S3, AWS EKS, Google Kubernetes Engine (GKE) 및 Heroku 등 다양한 환경에 코드를 배포하도록 구성 할 수 있다. 이외의 클라우드 서비스 배포는 SSH를 통해 직접 사용하거나 terraform과 같은 도구를 가지고 해당 클라우드 서비스의 API통해 자동화가 가능한 구조로 되어있다.

CircelCI AWS EKS

https://github.com/CircleCI-Public/circleci-demo-aws-eks

위 demo는 CircleCI를 이용하여 다음과 같은 workflow (상세내용 아래 config.yaml 참고)를 수행한다.

version: 2.1

orbs:
aws-eks: circleci/aws-eks@0.1.0
aws-ecr: circleci/aws-ecr@3.1.0
kubernetes: circleci/kubernetes@0.3.0

공통적으로 orb를 3가지를 추가하였기 때문에 각단계마다 관련 orb를 추가하는 단계를 거치게 된다.

  1. 환경설정 및 Docker Build 및 ECR로 Push
    workflows:
    deployment:
    jobs:
    - aws-ecr/build_and_push_image:
    name: build-and-push-image
    account-url: AWS_ECR_URL
    region: AWS_DEFAULT_REGION
    repo: eks_orb_demo_app
    dockerfile: ~/project/demo_app/Dockerfile
    path: ~/project/demo_app
    tag: ${CIRCLE_SHA1}
    # repository가 없을 경우 생성하는 옵션
    # create-repo: true
  • environment variables 설정
    • Project - BUILD SETTINGS - Environment Variables 에서 Key-Value형태로 입력
      • AWS_DEFAULT_REGION : us-west-2
      • AWS_ECR_URL : 219547004475.dkr.ecr.us-west-2.amazonaws.com/eks_orb_demo_app
  • github 연동 (ssh-key 연동 및 repo clone)
  • aws cli 설치 및 AWS Access, Secret Key설정
  • ECR Login
  • Image Build (https://github.com/ddiiwoong/circleci-demo-aws-eks/blob/master/demo_app/Dockerfile)
  • Push Image to ECR
  1. EKS클러스터 생성 (No Scripts)
    workflows:
    deployment:
    jobs:
    - aws-eks/create-cluster:
    cluster-name: eks-orb-demo-app-deployment
    aws-region: $AWS_DEFAULT_REGION
    requires:
    - build-and-push-image
  • kops, kubectl, aws iam authenticator, aws cli 설치
  • kubectl config 설정 (aws iam authenticator)
  • eksctl 설치
  • eksctl로 클러스터 생성 및 검증 (Cloudformation)
    • variables 사전 설정가능 ($AWS_DEFAULT_REGION)
  1. Demo Application 배포
    jobs:
    deploy-application:
    executor: aws-eks/python3
    parameters:
    ...
    steps:
    - checkout
    - run:
    name: Create deployment manifest
    command: |
    BUILD_DATE=$(date '+%Y%m%d%H%M%S')
    cat deployment/demo-app-deployment.yaml.template |\
    sed "s|DOCKER_IMAGE_NAME|<< parameters.docker-image-name >>|\
    g;s|BUILD_DATE_VALUE|$BUILD_DATE|g;s|VERSION_INFO_VALUE|\
    << parameters.version-info >>|g" > deployment/demo-app-deployment.yaml
    - aws-eks/update-kubeconfig-with-authenticator:
    cluster-name: << parameters.cluster-name >>
    install-kubectl: true
    aws-region: << parameters.aws-region >>
    - kubernetes/create-or-update-resource:
    resource-file-path: "deployment/demo-app-deployment.yaml"
    get-rollout-status: true
    resource-name: deployment/demoapp
    - kubernetes/create-or-update-resource:
    resource-file-path: "deployment/demo-app-service.yaml"
    ...
    workflows:
    deployment:
    jobs:
    - deploy-application:
    cluster-name: eks-orb-demo-app-deployment
    aws-region: $AWS_DEFAULT_REGION
    docker-image-name: "${AWS_ECR_URL}/eks_orb_demo_app:${CIRCLE_SHA1}"
    version-info: "${CIRCLE_SHA1}"
    requires:
    - aws-eks/create-cluster
    ...
  • deployment manifest생성 (deployment template)
  • kops, kubectl, aws iam authenticator, aws cli 설치 (orb설정: aws-eks,kubernetes)
  • kubectl config 설정 (aws iam authenticator)
  • resource(deployment, service) 배포 (orb설정: aws-eks,kubernetes)
  • rollout 수행 (0->3)
  1. application test
    workflows:
    deployment:
    jobs:
    - test-application:
    name: test-application
    cluster-name: eks-orb-demo-app-deployment
    aws-region: $AWS_DEFAULT_REGION
    expected-version-info: "${CIRCLE_SHA1}"
    requires:
    - deploy-application
    jobs:
    test-application:
    executor: aws-eks/python3
    parameters:
    ...
    steps:
    - aws-eks/update-kubeconfig-with-authenticator:
    cluster-name: << parameters.cluster-name >>
    install-kubectl: true
    aws-region: << parameters.aws-region >>
    - run:
    name: Wait for service to be ready
    command: |
    kubectl get pods
    kubectl get services
    sleep 30
    for attempt in {1..20}; do
    EXTERNAL_IP=$(kubectl get service demoapp | awk '{print $4}' | tail -n1)
    echo "Checking external IP: ${EXTERNAL_IP}"
    if [ -n "${EXTERNAL_IP}" ] && [ -z $(echo "${EXTERNAL_IP}" | grep "pending") ]; then
    break
    fi
    echo "Waiting for external IP to be ready: ${EXTERNAL_IP}"
    sleep 10
    done
    sleep 180
    curl -s --retry 10 "http://$EXTERNAL_IP" | grep "<< parameters.expected-version-info >>"
  • kops, kubectl, aws iam authenticator, aws cli 설치 (orb설정: aws-eks,kubernetes)
  • kubectl config 설정 (aws iam authenticator)
  • External IP 체크 및 curl 테스트
  1. Demo Application 삭제
    jobs:  
    undeploy-application:
    executor: aws-eks/python3
    parameters:
    ...
    steps:
    - aws-eks/update-kubeconfig-with-authenticator:
    cluster-name: << parameters.cluster-name >>
    install-kubectl: true
    aws-region: << parameters.aws-region >>
    - kubernetes/delete-resource:
    resource-types: "deployment,service"
    label-selector: "app=demo"
    wait: true
    - run:
    name: Check on pod status
    command: |
    kubectl get pods
    workflows:
    deployment:
    jobs:
    - undeploy-application:
    cluster-name: eks-orb-demo-app-deployment
    aws-region: $AWS_DEFAULT_REGION
    requires:
    - test-application
  • kops, kubectl, aws iam authenticator, aws cli 설치 (orb설정: aws-eks,kubernetes)
  • kubectl config 설정 (aws iam authenticator)
  • deployment 삭제 및 상태 체크
  1. EKS클러스터 삭제 (No Scripts)
    workflows:
    deployment:
    jobs:
    - aws-eks/delete-cluster:
    cluster-name: eks-orb-demo-app-deployment
    aws-region: $AWS_DEFAULT_REGION
    wait: true
    requires:
    - undeploy-application
  • kops, kubectl, aws iam authenticator, aws cli 설치 (orb설정: aws-eks,kubernetes)
  • kubectl config 설정 (aws iam authenticator)
  • eksctl 설치
  • eksctl로 클러스터 삭제 및 검증 (Cloudformation)

상세 config는 다음 링크에서 확인할 수 있다.
https://github.com/ddiiwoong/circleci-demo-aws-eks/blob/master/.circleci/config.yml

pipeline 수행

위 Workflow를 수행하게 되면 마지막에 어플리케이션과 클러스터를 삭제하기 때문에 해당 workflow는 제외하고 수행한다. 해당 config를 commit하면 바로 해당 CI가 트리거 되어 시작되게 된다.

      # - undeploy-application:
# cluster-name: eks-orb-demo-app-deployment
# aws-region: $AWS_DEFAULT_REGION
# requires:
# - test-application
# - aws-eks/delete-cluster:
# cluster-name: eks-orb-demo-app-deployment
# aws-region: $AWS_DEFAULT_REGION
# wait: true
# requires:
# - undeploy-application

result

클러스터 구성포함해서 총 20분정도 소요되었다. 실제 eksctl로 프로비저닝하게 되면 CloudFormation으로 수행되기 때문에 약 15-20분 정도 소요되니 간단한 빌드,배포,테스트는 5분정도 소요된것을 알 수 있다.

삭제는 역순으로 진행하거나 위에 주석 처리된 영역만 수행하면 된다.

정리

간단하게 CircleCI를 가지고 GitOps와 CI/CD를 구성하는 데모를 진행하였다.

CircleCI는 Jenkins와 유사하지만 Public서비스이고 Slave관리에 대해서 의존적이지 않기 때문에 기존에 Jenkins를 사용한 경험이 있다면 아주 쉽게 구성할 수 있다.

https://circleci.com/docs/2.0/migrating-from-jenkins를 참고하면 Jenkins와 차이점을 알 수 있는데 가장 큰 장점은 병렬로 테스트나 Job을 수행할수 있다는 점과 Lambda와 같은 서버리스 앱을 배포할때 정말 서버리스 환경으로 구성할수 있다는 점이다.

이는 Git Repository를 연동할때도 Java Plugin을 설치해야하는 번거로움을 덜 수 있다. 가장 중요한건 SaaS라는 장점도 무시할수 없다. Travis 무료 플랜과 비교해도 작은 프로젝트의 경우 별도의 Docker environment(2core, 4GB)를 제공받기 때문에 지연없이 바로 빌드가 가능하다는 점이다.

다음번 포스팅에는 terraform을 통해 ECR과 ECS로 배포하는 workflow를 살펴보려고 한다.

· 13 min read

그동안 DevOps 담당자라고 부르짖던 사람들의 Role이 인프라 담당자인지 플랫폼 담당자인지 아니면 개발하는 운영자인지 헷갈릴때가 많았다.

갑자기 국내에서도 SRE 채용 공고가 많아지는것을 보면서 내 자신도 한번 정리를 하고 가야할것 같은 생각이 들었다.

https://docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/

개념정리 측면에서 위 MS Azure의 온라인 교육내용을 정리해봤다.

SRE

SRE(사이트 안정성 엔지니어링)란 조직이 해당 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 달성하도록 지원하는 엔지니어링 분야이다.

출처 : https://landing.google.com/sre/sre-book/chapters/introduction/

기본적으로 운영경험이 있는 sysadmin, IT전문가, DevOps실행 담당자 등이 대상이 될 수 있다.

적절한 수준의 안정성

가장 핵심이 되는 단어는 안정성이다. 조직에서 만든 애플리케이션이 안정성이 부족하여 작동하지 않거나 불안정한 경우 실제 비즈니스에 피해를 줄 수 있다는건 누구나 알고 있는 당연한 이야기이지만 100%의 안정적인 시스템은 존재하지 않으므로 적절한 수준(정량적으로 측정하긴 어렵지만 이해관계자들이 납들할만한 수준)의 안정성을 달성하기 위한 일련의 작업들을 수행하는 것이 SRE의 기본 속성이라고 볼수 있다.

SRE는 Google에서 2003년부터 7명의 소프트웨어 엔지니어로 구성된 팀에서 시작된 이후 (자세한 내용은 위 링크 ebook 참조) Google 사내에 널리 확산되고 내부적인 문화로 조성되는 중에 밖에서는 DevOps라고 하는 문화가 동시에 확산되었다 한다. 결국 동일한 문제를 해결하기 위한 측면에서 두개의 방법론은 다르다고 봐야한다.

차이점

  • SRE - 안정성을 위한 엔지니어링, DevOps - 개발과 운영조직 각각의 사일로를 해체하기 위한 문화적인 움직임
  • SRE - 저는 SRE 입니다, DevOps - 저는 DevOps를 하는 운영자 또는 개발자 입니다.
  • SRE - 규범으로 인식, DevOps - 문화로 인식

공통점

  • 모니터링/식별 가능, 자동화

주요 SRE원칙 : 선순환

새로운 서비스의 상태의 지표는 어떻게 정의할까? 보통은 무엇을 SLI(서비스 수준 지표)로 사용할지를 정하는것으로 본다. 일반적으로 성공 및 실패 측정값(200 OK,500 Error), 응답시간(ms), 처리량 등의 조합으로 결정될 수 있다. 보통 카나리아 분석을 통해 Scoring을 한 SLI를 200 OK와 500 또는 에러코드의 비율로 결정하는 방법을 사용하는 경우가 많다.

서비스 상태를 식별하는 지표를 정하고 나면 고객이나 우리가 원하는 안정성 수준을 결정해야 한다. 개발팀과 운영팀이 같이 만든 원하는 안전성 수준을 SLO(서비스 수준 목표)라고 말하면 된다.

SLO는 Prometheus나 Datadog과 같은 모니터링 시스템을 활용하여 정확하게 측정하고 표시해야 한다. 서비스의 안정성에 대해서 명확하게 이해할수 있는 목표이기도 하다. 반드시 SLO를 만족하는지 못하는지 명확한 측정값으로 데이터가 존재해야 하고 SLO를 충족하지 못하면 문제가 있는것으로 판단하고 문제를 해결해야 한다.

오류 예산

오류 예산이라는 말을 명확히 이해하려면 흔히 고객과 체결하는 계약서 상의 명시된 서비스 가동율(SLA)을 생각하면 될 것 같다. 보통 99.9% 의 SLO를 정한다고 한다면 1년에 8시간 45분 57초의 서비스 다운타임을 허용하는 것이다. 오류 예산은 서비스의 완벽한 안정성과 원하는 안정성의 차이(100%-99.9%=0.01%)를 말한다. 0.01%로 즉 8시간정도의 오류 예산을 가지는 것은 그 시간을 모두 사용할 때까지 추가 릴리스나 패치를 진행할 수 있다는 이야기와 같다. 어떤 팀은 해당 예산을 신규 기능을 릴리스하는데 사용하기도 하고 장애가 발생했을때 문제의 원인을 발견하고 개선하는데 사용하기도 한다.

일반적으로 서비스에 대한 오류 예산이 모두 사용되면 서비스가 원하는 안정성 수준으로 돌아갈때 까지 해당 서비스의 추가적인 릴리스를 보류하는게 일반적이긴 하지만 특정기간(월 또는 분기 또는 연간) 기준으로 계산되기 때문에 서비스 안정성이 정상 상태라면 오류 예산은 다시 주어지게 되므로 선순환 구조를 가진다고 볼 수 있다.

비난 없는 장애 회고

일반적으로 비즈니스에 크리티컬한 장애가 발생했을때 사후 분석(회고)을 하게 되는데 이때는 비난 없는 분석을 해야한다. 오래전 기억이지만 예전 직장 특정팀에서는 장애가 발생하면 유관자들이 모두 엔지니어 책상 뒤에 서서 모든 화살과 눈총을 주기 때문에 도저히 일을 할 수 없게 만든 경우가 많았었다.

특정 운영자의 작업 실수로 인해 장애가 발생했다 하더라도 해당 이벤트가 발생하게 된 프로세스나 기술기반에 실패 원인을 파악하는데 중점을 두어야 할것이다.

시스템의 안정성을 저하시키고 서비스를 중단시킨 작업(릴리스, 패치 등)을 사유로 개인에게 페널티를 주거나 고과에 반영하는 방법은 장애로 부터 교훈을 얻을수가 없고 해당 담당자의 충성도나 생산성 저하를 유발하는 안좋은 장치가 될 수 있다. 내 경험이기도 하지만 한동안 두려워서 아무 변경도 하지 못하는 경우가 종종 있었다.

회사나 조직, 팀은 시스템 중단으로부터 교훈을 얻고 지속적으로 시스템을 개선할수 있다. 적절한 분석을 통해 후속조치를 수행함으로써 실패를 수용하는 것이 SRE의 핵심 원칙이다. 이러한 내용을 모두에게 공유하고 타 조직이나 팀에게 인사이트를 제공하는 선순환 구조를 만드는것 또한 SRE의 기본 원칙이라고 볼 수 있다.

주요 SRE원칙 : 사람측면

Toil(수고스런 일, 번거로운 작업)

항상 SRE에서는 Toil에 초점을 맞춰야 한다. Toil은 사람이 수행하는 운영 작업 중 특정한 패턴이나 특성이 있는 작업을 말한다. 종종 반복적이고 자동화 될 수 있는 작업일지라도 대부분 수동작업으로 처리를 한다. 서비스의 규모가 커지거나 고객이 많아지게 되면 보통 우리가 이야기 하는 티켓(또는 SR)의 수가 많아지고 공수가 많이 필요하게 된다.

배포때마다 Config를 적용하거나 계정 등록, 볼륨이나 디스크 프로비저닝 등 수동으로 처리해야하는 모든 작업이 운영자에게는 부하로 다가올수 있다. 이러한 반복적인 작업을 티켓시스템을 통해 처리를 하게 되면 티켓 생성, 작업계획서 작성, 검토, 승인 단계를 그때 마다 해야하는 아주 번거로운 작업(Toil)을 해야한다.

SRE는 최대한 이러한 반복적이고 번거로운 작업을 제거하기 위해 노력해야하고 자동화와 Self-Service로 개발자가 편하게 직접 사용할수 있도록 환경을 제공해 주어야 한다. 이러한 요청이나 티켓을 자동으로 처리할 수 있으면 조금 더 생산적인 일을 수행할수 있다.

위에서 이야기한 적절한 안정성과 비슷한 맥락으로 생각하면 될 것 같다. 번거로운 작업을 없애는것이 다른 중요한 작업보다 우선순위가 떨어지기도 하지만 서비스 상에서 Toil을 제거하는것도 SRE의 주된 업무이다.

운영작업의 비율

Toil을 제거하거나 서비스/시스템 안정성을 개선하기 위해 SRE는 장애를 해결하고 티켓을 처리하는 시간 비중을 50%를 넘겨서는 안된다. 티켓이 필요하지 않도록 개발자 Self-Service를 구성/제공하고 효율성을 증대시키기 위해서 IaC등(Shell, Ansible, Terraform)과 같이 자동화를 위한 코드를 만드는데에도 집중을 해야한다.

정리

지금까지 SRE에 대해서 간단하게 소개하고 이해하는 측면에서 정리해 봤다.

Service Reliability Hierarchy

hierarchy

그림과 같이 서비스 안정성 계층 구조에서는 기본적으로 모든 서비스를 모니터링 하는 시스템을 갖추어야 한다고 말한다. 모니터링 시스템이 준비가 되면 서비스에 대한 SLI, SLO를 만들고 모니터링 시스템에서 구현하는것이 첫번째 SRE를 적용하는 방법이라고 할 수 있을 것이다.

참고 서적