[GitHub Action] workflow_call를 통한 다른 workflow 실행하기

GitHub Actions의 workflow는 소프트웨어 개발 과정에서 자동화된 작업을 정의합니다. 이를 통해 코드 푸시, 풀 요청 또는 다른 GitHub 이벤트에 반응하여 테스트, 빌드, 배포와 같은 CI/CD 작업을 실행할 수 있습니다.

 

GitHub Actions에는 CI/CD 작업을 위해 다양한 기능이 있으며 이번에 테스트할 기능은 workflow_call 기능입니다. workflow_call 기능은 다른 파일에 정의된 workflow를 실행할 수 있으며, 재사용이 가능합니다.

 

 


workflows_call 이벤트

workflow_call 이벤트를 사용하는 GitHub Actions workflow는 다른 workflow에서 재사용 가능한 구성 요소로 기능합니다. 이것은 코드 중복을 줄이고, 워크플로우의 유지 관리를 간소화하며, 프로젝트 전반에서 일관된 CI/CD 작업을 사용하는데 좋습니다.

 

  • 예시 코드
    on:
    workflow_call:
      inputs:
        environment:
          required: true
          type: string
  • on: workflow가 어떤 이벤트에 의해 활성화되는지 정의
  • workflow_call: 다른 workflow에 의해 호출될 수 있음을 정의
  • inputs: 호출하는 workflow에서 이 workflow로 전달할 수 있는 입력 파라미터 정의
  • environment: 입력 파라미터 값(이름)
  • required: true: 입력 파라미터 필수 제공 조건
  • type: string: 입력 파라미터 형식

 

workflow_call:를 통해 외부에서 호출될 수 있음을 정의하고,

inputs:를 통해 다양한 입력 파라미터를 전달 받을 수 있습니다.

 


workflows_call 코드

workflows_call 이벤트를 통해 다른 workflows에서 workflows 파일을 실행할 경우 uses 키워드를 사용합니다. 호출하는 workflows를 call workflows라고 명칭하며 호출되는 called workflows라고 명칭하여 사용하는 것 같습니다.

 

호출되는 called workflow 코드

> ./.github/workflows/workflow_call.yml

name: Workflows Names - called_workflow
run-name: Runs Names - called_workflow 🚀

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

jobs:
  Jobs-Names-called_workflow:
    runs-on: ubuntu-latest
    steps:
      - name: echo enviroment
        run: echo Setup for ${{ inputs.environment }}

간단히 workflow 호출 시 입력 파라미터 environment 값을 받고 출력하도록 설정하였습니다.

 

호출하는 call workflow 코드

> ./.github/workflows/workflow_call_demo.yml

name: Workflows Names - workflow_call_demo
run-name: Runs Names - workflow_call_demo 🚀
on: 
  push

jobs:
  Jobs-Names-workflow_call_demo:
    uses: ./.github/workflows/workflow_call.yml
    with:
      environment: production

 

uses 키워드를 통해 재사용 workflows 파일의 경로를 지정하고 브랜치명 설정은 옵션이며 필요에 따라 지정합니다.

with 섹션을 통해 필요한 파라미터 inputs 값을 제공합니다.

 


 workflows_call 실행

Push 이벤트 및 수동으로 해당 workflow를 실행해보겠습니다.

설정한 workflow가 실행되었습니다.



workflow_call_demo.yml 파일이 실행되었으며



workflow_call 설정을 통해 environment 파라미터를 전달하여 workflow_call.yml 파일을 실행하였습니다.
전달한 파라미터 값(`production`)을 정상적으로 출력하였습니다.

 

 



GitHub의 workflow_call 이벤트를 활용하면 하나의 workflow를 다른 여러 workflow에서 재사용할 수 있어, 공통된 작업이 필요한 다양한 프로젝트나 레포지토리 간에 코드 중복을 줄이고 유지보수를 용이하게 할 수 있습니다. 또한 대규모 소프트웨어 개발 프로젝트에서 특히 유용할 수 있습니다. 공통된 작업을 재사용 코드로 관리하여 사용해보시기 바랍니다.


지금까지 workflow_call를 통한 다른 workflow를 실행 해보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 



[Reference]
https://docs.github.com/en/actions/using-workflows/reusing-workflows

 

 

 

[DevOps] AWS vs Azure vs GCP vs NCP 사용, 인기도, 관심도 비교

Cloud 서비스들이 많이 등장하면서 인프라를 Cloud로 제공하는 IaaS(Infrastructure-as-a-Service)에 대한 관심도 높아지고 있습니다. 대표적인 해외 기업으로는 AWS, Azure, GCP가 있으며 국내 기업으로는 NCP가 있습니다.


다양한 Cloud IaaS(Infrastructure-as-a-Service) 서비스 업체인 AWS vs Azure vs GCP vs NCP 를 구글 트렌드를 통해 비교해보겠습니다. 구글 트렌드틑 통해 비교한 자료이므로 상세한 내용은 아닌 대락적인 사용, 인기도, 관심도를 확인해봤다 정도로만 생각해주시면 좋을 것 같습니다.

 

 


전세계 기준

전세계를 기준으로는 AWS가 가장 관심도가 높으며, 다른 IaaS 서비스로는 Azure가 두 번째로 관심도가 높습니다.
모든 IaaS 서비스의 관심도가 점차 높아지고 있으며 Azure가 가장 높은 관심도를 보이는 경우도 있네요.
전세계 기준이므로 국내 기업인 NCP의 관심도는 비교적 낮습니다.

 

지난 1년

  • 평균
    • AWS : 85
    • Azure : 71
    • GCP : 11
    • NCP : 4

 

지난 5년

  • 평균
    • AWS : 70
    • Azure : 58
    • GCP : 7
    • NCP : 3

 

 


한국 기준

한국을 기준으로는 AWS가 가장 관심도가 높으며, 다른 IaaS 서비스로는 Azure가 두 번째로 관심도가 높습니다.
전세계 기준과 비교해보면 AWS가 Azure보다 압도적으로 높은 관심도를 가지고 있다는 것을 확인하실 수 있습니다.
하지만 Azure의 관심도는 떨어지지 않고 계속 높아지고 있네요.

 

지난 1년

  • 평균
    • AWS : 87
    • Azure : 22
    • GCP : 9
    • NCP : 2

 

지난 5년

  • 평균
    • AWS : 87
    • Azure : 22
    • GCP : 9
    • NCP : 2

 

 


미국 기준

이번에는 미국 기준입니다.
미국 기준으로는 AWS가 가장 관심도가 높으며, 다른 IaaS 서비스로는 Azure가 두 번째로 관심도가 높습니다.
전세계 기준과 비교해보면 거의 비슷한 관심도를 가지고 있다는 것을 확인하실 수 있습니다.

 

지난 1년

  • 평균
    • AWS : 67
    • Azure : 52
    • GCP : 97
    • NCP : 1

 

지난 5년

  • 평균
    • AWS : 55
    • Azure : 40
    • GCP : 5
    • NCP : 1

 

 


인도 기준

이번에는 인도 기준입니다.
인도 기준으로는 AWS가 가장 관심도가 높으며, 다른 IaaS 서비스로는 Azure가 두 번째로 관심도가 높습니다. NCP의 경우에는 갑자기 관심도가 높아지는 것을 확인하실 수 있는데요. 인도에서의 NCP는 Nationalist Congress Party(민족주의 의회당)으로 인도의 주요 정당 중 하나로 같은 약어로 사용되면서 중간에 갑자기 관심도가 높아지는 부분이 있었습니다.

 

지난 1년

  • 평균
    • AWS : 78
    • Azure : 52
    • GCP : 10
    • NCP : 6

 

지난 5년

  • 평균
    • AWS : 60
    • Azure : 43
    • GCP : 7
    • NCP : 4

 

 


일본 기준

마지막으로는 일본 기준입니다.
일본 기준으로도 동일하게 AWS가 가장 관심도가 높으며, 다른 IaaS 서비스로는 Azure가 두 번째로 관심도가 높습니다.
지난 5년간의 데이터를 보면 전반적으로 IaaS 서비스에 대한 관심도가 다른 나라보다는 낮습니다. 또한 한국과 비슷하게 AWS가 Azure보다 압도적으로 높은 관심도를 가지고 있다는 것을 확인하실 수 있습니다.

 

지난 1년

  • 평균
    • AWS : 75
    • Azure : 32
    • GCP : 9
    • NCP : 1

지난 5년

  • 평균
    • AWS : 33
    • Azure : 13
    • GCP : 4
    • NCP : 0

 


 

구글 트렌드를 통해 여러가지 IaaS(Infrastructure-as-a-Service)의 사용, 인기도, 관심도를 비교해봤는데요.

 

IaaS(Infrastructure-as-a-Service) 중에서는 AWS가 가장 높은 관심도이며, 다음으로는 Azure가 차지하였습니다. 가장 큰 IaaS 서비스를 생각하면 AWS를 생각할 수 있지만 최근에는 Azure 또한 많이 따라오고 있는 추세입니다. 추가로 지난 5년간의 자료를 확인해보면 점점 IaaS에 대한 관심도가 점점 높아지고 있습니다.

 

다양한 IaaS 서비스가 있지만 반드시 하나만 사용해야 되는 것은 아닙니다. 상황과 비용에 따라서 각 IaaS 서비스의 다양한 상세 서비스들을 선택하여 사용할 수 있으므로 다양한 IaaS 서비스의 경험을 경험해보시기 바랍니다.

 

 

지금까지 구글 트렌드를 통해 여러가지 IaaS(Infrastructure-as-a-Service)의 사용, 인기도, 관심도를 비교해보는 시간이였습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[GitHub Actions] workflows 설정 및 기본 실행

GitHub Actions은 GitHub에서 호스팅되는 CI/CD 서비스로, 코드 이벤트에 반응하여 자동화된 워크플로우를 실행하여 빌드, 테스트, 배포 등의 작업을 자동으로 수행합니다. YAML 파일을 사용하여 간편하게 워크플로우를 정의하고 구성할 수 있습니다. YAML 파일을 통해 GitHub Actions의 workflows를 설정하여 push 이벤트 발생 시 자동으로 설정한 Pipeline이 동작되도록 기본적인 구성을 해보겠습니다.

 

 


workflows 기본 구조

workflows에 기본적인 구조를 알아봅시다.

 

GitHub Workflows 파일은 .github/workflows 디렉토리에 저장되며 YAML 형식을 사용하여 작성됩니다.
여기에는 기본적인 GitHub Workflows 파일의 구조가 있습니다.

### .github/workflows/github-actions-demo-01.yml

name: Workflow 이름
run-name: Workflow 실행 이름
on:
  event:
    - trigger 이벤트 (예: push, pull_request, release 등)

jobs:
  job_이름:
    runs-on: runner 환경 (예: ubuntu-latest, windows-latest, macos-latest 등)

    steps:
      - name: 단계 1
        uses: 사용할 액션 또는 스크립트
        with:
          key1: value1
          key2: value2

      - name: 단계 2
        run: 실행할 명령어 또는 스크립트
  • name: 워크플로우 이름
  • run-name: 워크플로우 실행 이름
  • on: 어떤 이벤트에서 워크플로우가 실행될지 정의 / 예를 들어 push, pull_request, release 등이 있음
  • jobs: 여러 단계로 구성된 작업들의 그룹
    • jobs_name: 작업 이름
    • runs-on: 작업이 실행될 환경
    • steps: 작업을 수행하는 단계
      • name: 단계 이름
      • uses: 사용할 액션 또는 스크립트 지정
      • with: 액션에 전달할 매개변수
      • run: 실행할 명령어나 스크립트 직접 지정

 

이 외에 다양한 기능과 옵션을 제공하므로, 필요에 따라 추가하여 사용합니다.

 

 


workflows(yml) 설정 및 실행

Push 이벤트가 발생하면 간단히 echo 명령어로 실행하도록 설정을 추가해보겠습니다.

### .github/workflows/github-actions-demo-01.yml

name: Test GitHub Action Demo-01
run-name: Run GitHub Actions-01 🚀
on: [push]

jobs:
  Test-GitHub-Action:
    runs-on: ubuntu-latest
    steps:
      - name: echo-01
        run: |
          echo "TEST ECHO-01"

위와 같이 YAML 파일 생성 후 GitHub 프로젝트에 Push 해보도록 하겠습니다.

 

 

YAML에서 설정한 "Test GitHub Action Demo-01" 이름으로 workflows가 생성되었으며, 실행 이름은 "Run GitHub Actions-01" 으로 생성되었습니다.

 

 

이제 workflows "Run GitHub Actions-01"을 선택해보겠습니다.

YAML에서 설정한 "Test-GitHub-Action" 이름의 작업이 생성되어 있음을 확인하실 수 있습니다.

또한 상세한 Pipeline을 확인해보실 수 있으며, 성공 여부, 동작 시간 등을 확인하실 수 있습니다.

 

 

이제 작업 "Test-GitHub-Action"을 선택해보겠습니다.

설정한 run 필드의 echo "TEST ECHO-01" 명령어가 입력되고 정상적으로 실행됨을 확인하실 수 있습니다.

 

 

정상적으로 실행이 완료되면 Action 설정에서 녹색 표시를 확인하실 수 있습니다.

 

 


2개의 workflows(yml) 설정 및 실행

2개의 workflows(yml)를 생성한다면 어떻게 동작되는지 테스트해보겠습니다.

 

이전에 테스트한 내용과 비슷한 내용으로 YML 파일을 생성해보겠습니다.

### .github/workflows/github-actions-demo-02.yml

name: Test GitHub Action Demo-02
run-name: Run GitHub Actions-02 🚀
on: [push]

jobs:
  Test-GitHub-Action:
    runs-on: ubuntu-latest
    steps:
      - name: echo-02
        run: |
          echo "TEST ECHO-02"

위와 같이 YAML 파일 생성 후 GitHub 프로젝트에 Push 해보도록 하겠습니다.

 

 

workflows 2개가 생성되며 각각의 작업이 실행됨을 확인하실 수 있습니다.

 

 

여러 개의 YAML 파일을 사용하여 GitHub Actions을 구성하는 주요 이유는 모듈성과 재사용성을 높이기 위함입니다.

큰 규모의 프로젝트 또는 복잡한 워크플로우를 다룰 때, 단일 YAML 파일에 모든 것을 포함하는 것은 유지 보수가 어렵고 코드의 가독성을 떨어뜨릴 수 있습니다. 따라서 이를 해결하기 위해 여러 개의 YAML 파일을 사용하는 것이 일반적입니다.

 

예를 들어, build.yml, test.yml, deploy.yml과 같이 역할이나 기능에 따라 나누어진 YAML 파일을 만들고, 이를 메인 워크플로우 파일에서 jobs 섹션에서 불러와 사용할 수도 있습니다.

 

 


 

지금까지 workflows 설정 후 기본 실행을 해보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://docs.github.com/en/actions

 

 

 

[GitHub Actions] 한번 알아보자


GitHub Actions를 먼저 알아보기전 GitHub을 먼저 알아보자면, GitHub(깃허브)이란 소프트웨어 버전 관리와 협업을 위한 Git 플랫폼 입니다. 별도로 서버를 구성하지 않고도 GitHub 계정을 생성하여 소스 코드를 관리할 수 있습니다.

 

GitHub Actions이란 GitHub에서 공식적으로 제공하는 CI/CD 툴로써, 빌드, 테스트 및 배포 등의 파이프라인을 자동화할 수 있습니다. 또한 다양한 이벤트와 검색, 생성 및 공유 등 다양한 워크플로 및 사용자 정의된 워크플로를 사용할 수 있습니다. GitHub Actions의 특징 및 비용, 사용, 사례에 대한 기본적인 정보를 알아보겠습니다.

 

 


특징

GitHub Actions은 GitHub 저장소와 긴밀하게 통합되어 있어, 저장소 내에서 워크플로우를 설정하고 관리할 수 있습니다.
또한 코드, 이슈, 워크플로우 등 GitHub의 다양한 기능과 함께 통합되어 효과적인 협업과 개발이 가능합니다. 저장소 내에서 워크플로우를 설정하고 관리할 수 있다는 점이 큰 특징입니다.

 

GitHub에서 제공하는 Runner를 통해 별도의 서버(Runner)를 구성하지 않고 CI/CD Job을 실행할 수 있습니다.
Runner는 Windows, MacOS, Linux와 같은 다양한 운영체제에서 동작하며, 다양한 환경에서 실행할 수 있습니다.

 

병렬로 여러 워크플로우 작업을 처리할 수 있어, 대규모 프로젝트에서도 효율적으로 사용할 수 있습니다.

 

 


비용


기본적으로 한 달에 Job 실행에 대한 시간을 3,000분을 무료로 제공해줍니다.


운영 체제 및 CPU에 따른 분당 요금은 다르며 가장 기본적인 요금은 분당 $0.008 입니다.
대략적으로 하루에 1분이 소요되는 Job을 100번 실행한다면 한 달 요금이 $24정도 발생됩니다.


Job 실행 시간이 길거나 많은 수를 실행한다면 생각보다 높은 비용이 발생될 수 있습니다.

GitHub 비용 상세 정보 링크

 

 


사용

 

워크플로 파일을 GitHub 프로젝트의 ".github\workflows" 경로에 YAML 파일로 작성하면 됩니다.

작성 완료 후 속성을 부여하여 프로젝트에 푸쉬한다면 설정한 YAML 파일이 자동으로 동작합니다. 별도로 Runner를 설정하거나, GitHub 프로젝트의 옵션을 설정할 필요 없이 경로에 맞춰 파일을 생성하면 바로 동작합니다.

 

 


사례

다양한 기업에서 DevOps CI/CD 도구로 GitHub Action을 사용하고 계십니다.
몇 곳의 사레를 링크로 적어봤으며 참고하시기 바랍니다.

 

[뱅크 샐러드]
https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/

 

[다나와]
https://danawalab.github.io/common/2021/12/28/Github-Actions-%EC%82%AC%EC%9A%A9%EB%B2%95.html

 

[카카오엔터프라이즈]
https://tech.kakaoenterprise.com/180

 

 


 

GitHub Action과 다른 CI/CD 툴을 비교해봐도 큰 틀에서는 CI/CD 코드에 대한 형식과 기능은 비슷하지만 상세하게는 조금씩 다른 것 같습니다. 자신이 구성하고자 하는 환경과 효율, 비용 등을 고려하여 맞는 CI/CD 도구를 사용하시기 바랍니다.

 

 

 

지금까지 GitHub Action을 한번 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://docs.github.com/en/actions

[DevOps] 여러가지 CI/CD 툴 사용, 인기도, 관심도 비교

구글 트렌드를 통해 여러가지 CI/CD 툴의 사용, 인기도, 관심도를 비교해보겠습니다.


기준으로는 총 5가지의 CI/CD 툴인 Jenkins, GitHub Action, GitLab CI/CD, TeamCity, Atlassian Bamboo를 비교해봤습니다. 구글 트렌드틑 통해 비교한 자료이므로 상세한 내용은 아닌 대락적인 사용, 인기도, 관심도를 확인해봤다 정도로만 생각해주시면 좋을 것 같습니다.

 

 


한국 기준

한국을 기준으로는 Jenkins를 가장 많이 사용하고 있으며, 다른 CI/CD 툴 중에서는 GitHub Action 또한 두 번째로 많이 사용하고 있습니다. IT 기업의 기술 블로그를 확인해봐도 Jenkins 및 GitHub Action을 CI/CD 툴로 많이 사용하고 있음을 확인하실 수 있습니다.

 

지난 1년

  • 평균
    • Jenkins : 74
    • GitHub Action : 22
    • GitLab CI/CD : 1
    • TeamCity : 2
    • Atlassian Bamboo : 0

 

지난 5년

  • 평균
    • Jenkins : 58
    • GitHub Action : 9
    • GitLab CI/CD : 1
    • TeamCity : 1
    • Atlassian Bamboo : 0

 

 


전세계 기준

전세계를 기준으로는 Jenkins를 가장 많이 사용하고 있으며, 다른 CI/CD 툴 중에서는 GitHub Action 또한 두 번째로 많이 사용하고 있습니다. 한국과 비교해봤을 때에는 Jenkins의 비중이 더 높고, GitHub Action의 비중이 더 낮습니다.

 

지난 1년

  • 평균
    • Jenkins : 85
    • GitHub Action : 7
    • GitLab CI/CD : 1
    • TeamCity : 2
    • Atlassian Bamboo : 0

 

지난 5년

  • 평균
    • Jenkins : 62
    • GitHub Action : 2
    • GitLab CI/CD : 0
    • TeamCity : 1
    • Atlassian Bamboo : 0

 

 


미국 기준

이번에는 미국 기준입니다.
미국 기준으로도 동일하게 Jenkins를 가장 많이 사용하고 있으며, 다른 CI/CD 툴 중에서는 GitHub Action 또한 두 번째로 많이 사용하고 있습니다. 한국 및 전세계 자료와도 비교해봤을 때 Jenkins의 비중이 더 높고, GitHub Action의 비중이 더 낮습니다.

 

지난 1년

  • 평균
    • Jenkins : 83
    • GitHub Action : 4
    • GitLab CI/CD : 0
    • TeamCity : 1
    • Atlassian Bamboo : 0

 

지난 5년

  • 평균
    • Jenkins : 48
    • GitHub Action : 1
    • GitLab CI/CD : 0
    • TeamCity : 1
    • Atlassian Bamboo : 0

 

 


인도 기준

이번에는 인도 기준입니다.
인도 기준으로도 동일하게 Jenkins를 가장 많이 사용하고 있으며, 다른 CI/CD 툴 중에서는 GitHub Action 또한 두 번째로 많이 사용하고 있습니다. 전세계 자료와 거의 비슷한 비중을 보이고 있습니다.

 

지난 1년

  • 평균
    • Jenkins : 78
    • GitHub Action : 5
    • GitLab CI/CD : 1
    • TeamCity : 2
    • Atlassian Bamboo : 0

 

지난 5년

  • 평균
    • Jenkins : 70
    • GitHub Action : 2
    • GitLab CI/CD : 0
    • TeamCity : 2
    • Atlassian Bamboo : 0

 

 


일본 기준

마지막으로는 일본 기준입니다.
일본 기준으로도 동일하게 Jenkins를 가장 많이 사용하고 있으며, 다른 CI/CD 툴 중에서는 GitHub Action 또한 두 번째로 많이 사용하고 있습니다. 한국과 비슷하게 GitHub Action 사용 빈도가 전세계 기준보다는 조금 높은 비중을 보이고 있습니다.

 

지난 1년

  • 평균
    • Jenkins : 74
    • GitHub Action : 15
    • GitLab CI/CD : 1
    • TeamCity : 1
    • Atlassian Bamboo : 0

 

지난 5년

  • 평균
    • Jenkins : 50
    • GitHub Action : 4
    • GitLab CI/CD : 0
    • TeamCity : 1
    • Atlassian Bamboo : 0

 

 


구글 트렌드를 통해 여러가지 CI/CD 툴의 사용, 인기도, 관심도를 비교해봤는데요.


CI/CD 툴 중에서는 Jenkins를 가장 높은 비중을 차지하고 있고, 다음으로는 GitHub Action이 차지하였습니다.

지난 5년간의 자료를 확인해보면 점점 Jenkins의 비중은 낮아지고, GitHub Action의 비중은 높아지고 있는데요.

다양한 CI/CD 툴이 생겨나가면서 Jenkins의 비중이 점점 낮아지는 것은 아닐까라는 개인적인 견해를 가지고 있습니다.


여러가지의 CI/CD 툴 중에서 많이 사용하고 있다는 것은 그만큼 검증된 툴이며 작업을 하기 위해 다양한 자료가 있다는 것으로 생각할 수 있습니다. 따라서 CI/CD 툴을 어떤 것을 사용할지 고민이시라면 Jenkins 또는 GitHub Action을 추천드립니다.

 

 

 

지금까지 구글 트렌드를 통해 여러가지 CI/CD 툴의 사용, 인기도, 관심도를 비교해보는 시간이였습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[DevOps] AWS vs NCP 주요 서비스 기능 및 비용 비교

AWS는 세계적으로 널리 사용되는 클라우드 서비스 플랫폼이며, NCP(네이버 클라우드 플랫폼)는 주로 한국에서 이용되는 클라우드 서비스 플랫폼입니다. AWS는 글로벌 기업들에게 다양한 서비스를 제공하며, NCP는 주로 한국 기업 및 사용자를 대상으로 한 클라우드 서비스를 제공하는데요.


AWS와 NCP의 주요 서비스의 비용을 비교해보도록 하겠습니다.

 


주요 서비스

[ 공통 조건 ]

환율 : $1 = 1350원

월 기준 : 730시간

 

서버

AWS - EC2 NCP - Server


- [Linux] / CPU(2) / Mem(8) / SSD(50G)
- Type : t3a.large
- 비용 : $72.89 / 98,401원 (월 기준)

- [Window] / CPU(2) / Mem(8) / SSD(100G)
- Type : t3a.large
- 비용 : $97.60 / 131,760원 (월 기준)

- [Linux] / CPU(16) / Mem(32) / SSD(50G)
- Type : c5a.4xlarge
- 비용 : 506.80 / 684,180원 (월 기준)

- [Linux] / CPU(8) / Mem(64) / SSD(50G)
- Type : r5a.2xlarge
- 비용 : $401.68 / 542,268원 (월 기준)

- [Linux] / CPU(4) / Memory(20) / SSD(50G)
- Type : g4dn.xlarge / GPU T4 (1ea)
- 비용 : $476.87 /  643,774원 (월 기준)




- [Linux] / CPU(2) / Mem(8) / SSD(50G)
- Type : Standard
- 비용 : 88,000원 (월 기준)

- [Window] / CPU(2) / Mem(8) / SSD(100G)
- Type : Standard
- 비용 : 113,760원 (월 기준)

- [Linux] / CPU(16) / Mem(32) / SSD(50G)
- Type : High CPU
- 비용 : 576,000원 (월 기준)

- [Linux] / CPU(8) / Mem(64) / SSD(50G)
- Type : High Memory
- 비용 : 480,000원 (월 기준)

- [Linux] / CPU(4) / Mem(20) / SSD(50G)
- Type : GPU / Tesla T4 (1ea)
- 비용 : 480,000원 (월 기준)


  • 동일한 사양에서 OS에 따른 비용 비교
  • CPU, Memory, GPU 등 Type별 비용 비교

 

객체 스토리지

AWS - S3 NCP - Object Storage


- 사용 :10TB (월 기준) 
- 비용 : $256 / 345,600원 

- PUT, COPY, POST, LIST 요청 
- 비용 : 1000만건 $45 / 60,750원 

- GET, SELECT 및 기타 모든 요청 
- 비용 :  1000만건 $3.5 / 4,725원

- 아웃바운드 데이터 전송(인터넷)
- 비용 :  1TB  $129.02 / 174,177원


- 사용 :10TB (월 기준) 
- 비용 :  286,720원 

- PUT, COPY, POST, LIST 요청
- 비용 : 1000만건 45,000원 

- GET, SELECT 및 기타 모든 요청 
- 비용 : 1000만건 4,000원 

- 아웃바운드 데이터 전송(인터넷) 
- 비용 : 1TB 102,400원
  • 사용량 기준 비용 비교
  • 요청에 따른 비용 비교

 

 

블록 스토리지

AWS - EBS(Elastic Block Store) NCP - Block Storage


- SDD / 1024GB / 16,000 IOPS / 1,000MiB/s
- 비용 : $149.08 / 201,258원 (월 기준)

- HDD / 1024GB / 500 IOPS / 500MiB/s
- 비용 : $107.91 / 145,678원 (월 기준)



- SDD / 1024GB / 16,000 IOPS / 250MiB/s
- 비용 : 118,656원 (월 기준)

- HDD / 1024GB / 500 IOPS / 500MiB/s
- 비용 : 59,328원 (월 기준)
  • Storage Type(SSD, HDD)에 따른 비용 비교

 

 

네트워크 스토리지

AWS - EFS(Elastic File System) NCP - NAS


- 용량 : 1030GB
- 비용 : $89.86 / 121,311원 (월 기준)


- 용량 : 1030GB
- 비용 : 79,200원 (월 기준)

 

 

Functions

AWS - Lambda NCP - Cloud Functions


- 요청 수 : 1억건
- 요청 기간(ms) : 1000
- 메모리 : 128MB
- 비용 : $221.47 / 298,984원


- 요청 수 : 1억건
- 요청 기간(ms) : 1000
- 메모리 : 128MB
- 비용 : 225,500원

 

 


기타 서비스

Auto Scaling

AWS - Auto Scaling NCP - Auto Scaling


- 장점: 다양한 서비스 지원 유연한 메트릭 및 정책 설정 생명주기 훅을 통한 사용자 정의 제어 가능

- 단점: 설정 및 구성이 복잡할 수 있음 일부 사용자에게는 과도할 수 있는 기능이 제공됨


- 장점: 간편한 설정 및 관리 HTTP 기반 트래픽에 특화 컨테이너 인프라 지원 

- 단점: 일부 AWS 서비스에 비해 특정한 서비스의 확장성이 떨어질 수 있음 고급 설정이나 사용자 정의가 부족할 수 있음

 

 

API Gateway

AWS - API Gateway NCP - API Gateway



- Rest API / 요청 1억건
- 비용 : $350 / 472,500원

- 캐시 사용량 : 1.6GB / 6.1GB
- 비용 : 27.74, 37,449원 / $146, 197,100원

+@ HTTP API, WebSocket API 지원


- Rest API / 요청 1억건
- 비용 : 396,000원

- 캐시 사용량 : 1.6GB / 6.1GB
- 비용 : 59,040원 / 225,000원




Queue

AWS - SQS(Simple Queue Service) NCP - RabbitMQ


- 표준 대기열 요청 : 1억건
- 비용 : $39.6 / 53,460원

- 아웃바운드 데이터 전송(인터넷)
- 비용 : 1TB $129.02 / 174,177원


- RabbitMQ를 "단독 VM(Virtual Machine)"에 설치하여 메시지 시스템을 구성할 수 있음

- RabbitMQ 프로세스는 Supervisor에 의해서 관리되며, 의도치 않게 종료됐을 경우에는 프로세스를 재기동시켜 서비스 중단을 최소화 할 수 있음

 

 


 

전체 서비스에 대한 기능 및 비용을 비교한 것은 아니지만 일부 서비스들을 비교해봤습니다.


전체적으로 AWS 비용이 조금 비싸지만 환율에 따라 많이 달라질 소지가 있습니다. 또한 스토리지 부분에서는 NCP가 비교적 많이 저렴하기 때문에 스토리지 관련 서비스를 많이 사용할 경우에는 NCP가 더 비용적으로 효율적입니다.

 

위 정보 이외에 사용하실 서비스들의 기능 및 비용을 비교하여 Cloud를 선택 후 사용하시기 바랍니다.

 

지금까지 AWS와 NCP의 주요 서비스 기능 및 비용 비교 확인해봤습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[AWS] Certified Solutions Architect - Associate 취득 후기

이번에 AWS 자격증인 Solutions Architect - Associate (SAA)을 취득하였습니다!!
단순 자격증만을 취득하기 목적이 아닌 AWS 각각의 서비스들을 공부하면서 진행했기 때문에 총 2달의 시간이 소요되었습니다. 어떤 방법으로 공부했는지와 취득 시 꿀팁 등을 공유해드리도록 하겠습니다.

 

 


시험 공부

시험 공부는 크게 3단계로 공부하였으며 하나씩 공유해드립니다.

 

1. Udemy 강의

Solutions Architect - Associate 자격증에서 가장 유명한 Stephane 선생님의 Udemy 강의입니다.

https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c03/

 

시험에 나오는 전체적인 AWS 서비스에 대한 내용을 다루고 있습니다. AWS를 이해하는 것에도 큰 도움이 되었으며, 총 2 번을 들었습니다. 처음에는 서비스들의 종류가 있다 정도의 내용으로 한번 듣고, 두 번째로는 상세한 내용을 이해하는 수준으로 들었습니다.

 

2. Udemy 강의 시험

처음에 말씀드린 강의 중 마지막에 테스트 시험 항목이 있습니다.

 

시험과 동일하게 65문제를 푸는 테스트이며, 테스트 완료 후 각 항목에 대한 상세한 설명을 확인할 수 있어 도움이 많이 되었습니다. 틀린 문제에 대해서는 AWS 공식 사이트에서 추가적인 정보를 통해 서비스를 이해할 수 있도록 하였습니다.

 

3. 기출문제 풀이

덤프 파일을 구매해서 시험 보는 분들이 많았지만, 저는 AWS를 공부하는 목적도 있기 때문에 별도의 덤프 파일은 구매하

지 않았는데요. 그래도 시험에 좀 더 편하게 합격하기 위해서 온라인에서 무료로 제공하는 덤프 파일을 풀었습니다.

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/view/

 

examtopics 사이트의 장점은 Discussion을 통해 각 항목에 대한 상세한 설명을 각 유저들이 남긴 댓글을 통해 확인할 수 있어 문제를 이해하는데 큰 도움이 되었습니다. (사이트에서 틀린 정답이 있어 투표에 따른 정답을 확인하시면 됩니다. 덤프 파일 또한 실제 정답과 다른 정답이 있다고 합니다.)

 

추가로 빠르게 합격하고 싶으신 분은 덤프 파일을 구매하시는 것을 추천해드립니다!

 

 


시험 진행

시험 신청

AWS Training 센터를 통해 시험을 예약하였으며, 온라인 시험(OnVUE)으로 신청하였습니다.

https://www.aws.training/certification

 

시험 신청 시점은 시험 공부 1, 2번을 완료하고 기출 문제를 풀기 시작할 때쯤 2주 뒤로 신청했습니다.
온라인 시험이기 때문에 독립된 공간에서 혼자 진행해야되며, 마이크와 캠이 지원되는 환경에서 진행해야 됩니다.

 

 


온라인 시험 진행

온라인 시험을 진행하기 이전에 테스트 시험을 진행하였습니다. 마이크와 캠이 잘 연결되는지 확인하고, 정상적으로 테스트 프로그램이 실행되는지를 1~2일 전에 확인하였습니다.

 

시험 시작 30분 전에 온라인으로 체크인을 진행하였습니다. 온라인 체크인을 위한 사이트를 QR코드로 접속하여 얼굴과 신분증 사진 찍고 시험 장소(독립된 공간)의 4면을 사진 찍어 업로드하여 온라인 체크인을 완료합니다.

 

온라인 체크인을 완료하면 시험 감독관과 1대1로 영어로 음성 및 채팅으로 소통하면서 시험 공간에 대한 확인을 진행합니다. 책상 위에는 노트나 연필, 기타 시험에 불필요한 물건들이 없어야하며 시험 장소 전체와 책상 아래 등을 상세하게 확인합니다. 손목에 시계, 책상 위에 스피커 등 모든 항목을 시험 감독관의 지시에 따라서 이행하면 완료됩니다.

 

완료 이후 시험을 진행할 수 있습니다. 시험은 선택한 언어로 표시되며 영어 버튼을 클릭하면 영문으로된 문제를 바로 확인하실 수 있습니다. 한국식 표현이 조금 애매한 문제가 조금 있어 영문을 통해 문제를 몇가지 확인하였습니다. 총 시험 시간은 170분(편의 사항 요청으로 30분 추가) 중에서 70분 정도 사용하여 65문제를 풀고 결과를 제출하였습니다. 완료 후 시험에 대한 설문조사를 끝으로 마무리됩니다.

 

 


시험 결과


시험 결과는 다른 후기를 확인했을 때 보통 2~3일만에 나온다고 했지만 저는 단 3시간만에 결과를 받았습니다!! (너무 일찍 결과가 나와 사실 하루 뒤에 알았습니다 ㅎㅎ)
시험 신청 비용(17만원)이 큰 비용이었기 때문에 한번에 붙기를 기원했는데 다행이네요.

 

 


 

시험을 지원하셨거나 지원 예정이신 분들은 위 내용을 참고하셔서 꼭 한번에 합격하시길 바랍니다!!
예상 필요 기간은 AWS를 접해보시지 않은 분들이라면 2~3달 정도, 처음 접해보시는 분들이라면 1~2달의 시간을 투자하시면 반드시 합격하실 수 있을 겁니다!

 

 

지금까지 AWS 자격증인 Solutions Architect - Associate 취득 후기였습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[DevOps] 2023 State of DevOps Report 알아보기 3탄


지난번 2탄에 이어서 3탄에도 State of DevOps Report 2023의 주요 내용을 상세하게 알아보는 시간을 가져보겠습니다.
이번에는 인프라스트럭처와 문화에 대한 내용을 알아보는 시간을 가지겠습니다.

 


"Flexible infrastructure is key to success"

"유연한 인프라스트럭처가 성공의 열쇠다" 주제의 내용입니다.

 

유연한 인프라스트럭처는 30% 더 높은 조직 성과를 낸다고 합니다.

 

 

인프라를 구축하기 위해서는 크게 온프레미스와 클라우드를 선택할 수 있으며 각각의 인프라 사용에 따른 비율은 지표로 확인할 수 있습니다.

 

 

클라우드를 많이 사용하고 있으며 그 중 Public 클라우드가 주도하고 있습니다.
이러한 클라우드를 "단순히" 사용하여 인프라를 구축할 경우의 성과 결과를 확인해봅시다.

Private 클라우드는 팀 성과와 운영 성능은 향상되지만 조직 성과와 소프트웨어 배포 속도에는 효과가 없음을 확인할 수 있으며, Public, Hybrid, Multi 클라우드는 조직 성과와 팀 성과는 향상되지만 소프트웨어 배포 속도와 운영 성능은 감소되는 것을 확인하실 수 있습니다.

 


이러한 문제는 클라우드를 "단순히" 사용하면서 발생되는 부정적인 영향이라고 합니다.

하지만 클라우드 인프라는 유연성을 제공합니다.
퍼블릭 클라우드를 사용하면 비용이 22% 증가하지만 유연한 인프라를 사용했을 경우 모든 결과는 달라집니다.

 


유연한 인프라를 통해 모든 성과 및 성능 측면이 긍정적으로 향상되었습니다.

또한 모든 클라우드에서도 긍정적인 영향을 미친다는 것을 확인하실 수 있습니다.

 

 

클라우드가 결합된 유연한 인프라를 사용하는 것과 유연성이 없는 클라우드를 비교했을 경우 큰 차이가 있음을 알 수 있습니다.

 

 

추가로 직원들의 행복 측면에서도 효과를 얻을 수 있습니다.

 

 

결과적으로 "단순히" 클라우드를 사용하면 부정적인 영향이 있으며, 유연한 인프라를 통해 퍼블릭 클라우드를 사용하면 모든 성과 및 성능 측면과 직원들의 행복 측면에서도 모두 긍정적인 효과를 얻을 수 있다는 것을 확인하실 수 있습니다.

 


"None of this works without investing in culture"

마지막으로 "문화에 투자하지 않고서는 이 중 어떤 것도 효과가 없다" 주제의 내용입니다.

 

문화를 정의하기는 어렵지만 DORA팀은 아래 7가지 측면으로 정의하였습니다.

 

 

DORA팀은 문화에 대한 측면을 강조하였으며, 문화는 직원들의 행복과 조직의 성과를 좌우하는 핵심 요소라고 합니다.
문화 중 생성 문화가 있는 팀은 그렇지 않은 팀보다 조직 성과가 30% 더 높다고 합니다.

 

 

문화는 팀 성과, 조직 성과, 소프트웨어 제공 성능, 운영 성능 등 대부분의 성능에 긍정적인 영향을 미칩니다.

업무 분배 측면은 소프트웨어 제공 성능이 감소되는 영향이 있었으며, 업무를 다양하고 많은 사람들을 통해 분배하면 실제 소프트웨어를 제공하는 시간이 늦어질 수 있다는 내용으로 확인됩니다.

 

 

기술적인 역량을 향상 시키기 위한 부분도 문화가 큰 영향을 미칩니다.

 

 

직원들의 행복 측면에서도 문화는 큰 영향을 미칩니다.

 

문화와 관련된 여러가지 지표를 확인해 봤는데요.
이 중에 웨스트럼 조직 문화가 모든 측면에서 가장 긍정적인 영향을 미치고 있습니다.


웨스트럼 조직 문화를 간단하게 설명하자면 Pathological(병적인), Bureaucratic(관료적인), Generative(생성적인) 부분으로 크게 3가지를 구분하고 있습니다. 여기서 Generative 생성 문화는 성과 중심으로 조직이 임무에 집중하고 모든 것은 팀이 좋은 성과를 내기 위해 해야 할 일이다는 주제를 가지고 있는 조직 문화입니다. 간단히 알아봤지만 이후에 웨스트럼 조직 문화에 대한 상세한 내용을 확인해보는 시간을 가져보겠습니다.

 

결과적으로 문화는 건강한 문화, 생성적 문화를 통해 모든 성과 및 성능 측면과 기술적 역량, 직원들의 행복 측면에서도 모두 긍정적인 효과를 얻을 수 있다는 것을 확인하실 수 있으며 DORA 팀에서도 강조한 것과 같이 문화에 대한 중요성을 항상 가지면서 조직 문화와 업무를 가져봐야할 것 같습니다.

 


 

2023 State of DevOps Report의 주요 내용을 상세하게 확인해봤는데요.
지금까지 작성한 1,2,3탄을 통해 2023 State of DevOps Report의 주요 결과 및 주요 내용에는 이런 것들이 있구나라고 느끼셨으면 좋겠습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]

https://cloud.google.com/devops/state-of-devops
https://semaphoreci.com/blog/state-of-devops-2023

 

 

 

+ Recent posts