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

지난번에는 State of DevOps Report 2023의 주요 결과에 대한 내용을 알아보는 시간을 가졌는데요.
이번에는 더 자세하게 알아보기 위해 주요 내용 중 사용자 중심에 대한 내용과 문서화에 대한 내용을 알아보는 시간을 가지겠습니다.

"Focusing on users predicts organizational performance"

"사용자 중심으로 조직 성과를 예측한다" 주제의 내용입니다.

사용자 중심이 강한 팀은 40% 더 높은 조직 성과를 낸다고 합니다.

여기서 사용자란 소프트웨어를 사용하기 위해 비용을 지불하는 고객 뿐만 아니라 소프트웨어에 관련된 개발팀, 운영팀, 배송팀, 리더 등 모든 사용자가 포함됩니다.

DORA팀에서는 사용자 중심의 세가지 중요한 특성을 조사했다고 하는데요.

• 팀이 사용자의 요구를 얼마나 잘 이해하는지.
• 사용자의 요구를 충족시키기 위해 팀이 얼마나 잘 준비되어 있는지.
• 작업의 우선순위를 정할 때 사용자 피드백을 사용하는 방법.

결과적으로 소프트웨어에 대한 사용자 중심 접근 방식을 발견했다고 하며, 사용자를 최우선으로 생각하면 아래와 같은 좋은 영향을 얻을 수 있다고 합니다.

이러한 결과는 아래 예시와 같이 조직 전체 및 다양한 팀에 영향을 미친다고 합니다.

• 개발팀
  • “ 사용자의 요구 사항을 명확하게 이해하고, 사용자 피드백을 기반으로 계획 조정”
• 운영팀
  • “ 사용자가 관심을 갖는 서비스 수준 지표를 식별하고 사용자의 만족도를 유지하는 것을 목표”
• 리더
  • “ 사용자에게 가치를 제공한 팀에 보상을 제공”

마지막으로 사용자에 집중하면 20% 더 높은 직업 만족도를 낸다고 합니다.

단순히 사용자 중심을 통해 얼마나 큰 영향이 있을까하는 생각이 있을 수 있지만,
사용자 중심을 통해 조직 성과와 직업 만족도 측면에서 높은 성과를 낸다는 것을 확인하실 수 있습니다.

"Documentation is foundational"

"문서화는 기본적이다" 주제의 내용입니다.

문서화는 기본이고, 기술 역량을 증폭시킨다고 합니다.
낮은 품질의 문서와 높은 품질의 문서에 따른 기술적 역량에 얼마나 영향을 미치는지 조사한 내용입니다.

높은 품질의 문서로 모든 측면에서 기술적 역량이 높아졌으며, 트렁크 기반 개발에서는 최대 12.8배의 차이가 있었습니다.

문서화는 이러한 기술적 역량뿐만 아니라 직원들의 행복과 조직의 성과에도 큰 영향을 미친다고 합니다.
번아웃 측면은 감소되었며, 직업 만족도와 생산성은 증가되어 모두 긍정적인 영향을 미쳤습니다.

팀 성과, 조직 성과, 운영 성과는 모두 증가되었습니다. 단 소프트웨어 제공 성능에는 영향이 없는 것을 확인하실 수 있습니다.

이러한 결과들 중에 예상치 못한 추세를 발견했다고 하는데요.

일부 사람들은 문서의 품질이 높아질 경우 번아웃 수치가 감소되는 것이 아니라 증가되는 부분도 있었습니다.

해당 결과를 통해 고품질의 문서를 창출하고 유지하기 위해서는 큰 노력이 필요하고, 일부 사람들은 이러한 기술적인 작업을 중요하거나 영향력이 있다고 인식하지 않을 경우가 있다고 합니다.
이러한 부분이 확인되면서 DORA팀은 문서화와 관련된 부분은 더 많은 연구가 필요할 것 같다고 합니다.

결과적으로는 문서화를 통해 기술적 역량뿐만 아니라 직원들의 행복과 조직의 성과에도 큰 영향을 미친다는 것을 확인하실 수 있습니다.

2023 State of DevOps Report의 주요 내용을 상세하게 확인해봤는데요.
3탄에서는 다른 주요 내용을 상세하게 확인해보는 시간을 가져보겠습니다....! 끝...!

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

[Reference]

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

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

지난 10월달에 "State of DevOps Report 2023" 이 나왔습니다!
State of DevOps Report란 Google에서 DevOps를 연구하는 DORA라는 팀에서 발표하는 자료인데요.
State of DevOps Report에는 어떤 내용이 있는지 한번 알아보는 시간을 가지겠습니다.

시작하기 전에...

DORA

매년 보고서를 발표하는 DORA 팀에 대해 간단히 알아보겠습니다.

Google의 DevOps Research and Assessment(DORA)팀은 소프트웨어 개발 및 배포 프로세스의 연구에 중점을 둔 팀으로, 가장 효율적인 DevOps 적용 사례, 효과, 기술 동향, 모범 사례 등을 연구하고 공유합니다.

State of DevOps Report는 DORA 팀에서 매년 DevOps를 연구하고 발표한 자료입니다.

State of DevOps Report

"Accelerate: The State of DevOps Report"는 DevOps의 현황과 추세를 조사하고 분석하여 소프트웨어 개발 및 운영 프로세스의 효율성과 품질을 평가하는 보고서입니다. 이 보고서는 기업의 DevOps 도입 및 성공 사례, DevOps를 통한 비즈니스 성과, 다양한 조직의 DevOps 관련 실천 사례 등을 다루고 있으며 지난 9년 동안 전 세계 36,000명 이상의 전문가로부터 의견을 듣고 보고서가 작성되었습니다.

이 보고서를 통해 DevOps에 대한 이해를 높이고, 고성능 조직의 모범 사례를 제시하여 기업이 DevOps를 성공적으로 도입하고 활용할 수 있도록 지원하는 데 목적이 있습니다.

보고서 점수 측정

평균

• 평균 점수

IQR

• 사분위수 범위(IQR)의 경계 데이터
• 중간 50%가 위치하는 두 개의 숫자(25번째 및 75번째 백분위수)를 제공함으로써 응답의 퍼짐을 전달하는 데 도움이 됩니다.

중앙값

• 데이터 집합의 중간 값
• 평균과 크게 다른 경우 데이터가 왜곡되었음을 나타낼 수 있습니다.

Key outcomes (주요 성과)

주요 성과는 사람, 팀 또는 조직이 달성하기 위해 노력하고 있다고 믿는 목표 입니다.

• 팀 성과 점수는 평균이 가장 높은 값인 "7.6"으로 팀을 위해 가장 많은 노력을 하고 있다는 것을 확인하실 수 있습니다.
• 그 외에는 신뢰성 목표 항목이 조직 성과, 소프트웨어 제공 성능, 운영 성능보다 높다는 것을 확인하실 수 있습니다.

직원들의 번아웃(탈진), 생산력, 직업 만족도 측면 입니다.

• 개인적인 생각으로는 번아웃(탈진) 항목이 평균 5점 이상일 것이다라고 생각했지만 평균 "4.1"점으로 측정되었습니다.
• 또한 생산력 항목은 개인적인 생각보다는 높은 평균 "7.5"점 이었습니다.

Processes & technical capabilities (프로세스 및 기술 역량)

팀이나 조직에서 일하는 방식이나 활동, 상태에 대한 자료입니다.

• AI(Artificial Intelligence) 항목은 평균 "3.3"점으로 현재 AI가 업무에 주는 영향은 생각보다 낮다는 것을 확인하실 수 있습니다. ( ChatGPT나 Copilot을 많이 사용하는데 말이죠 ㅎㅎ )
• DevOps의 중요한 CI(Continuous Integration), CD(Continuous Delivery) 항목은 가장 높은 평균 점수 "6.9"점과 "7.0"점을 기록하였습니다.
• 그 다음으로는 유연한 아키텍처, 코드 검토 속도, 느슨한 결합 등의 항목이 차지했습니다.

Culture aspects (문화적인 측면)

DORA 팀에서는 문화를 정의하는 것은 쉽지 않지만 6가지 항목으로 분류하였습니다.
이러한 것들이 일반적인 규범(유연성 등), 일반적인 지향성(사용자 중심성 등), 그리고 직장의 분위기(조직 안정성 등)라고 말할 수 있다고 합니다.

• 이후에도 더 내용이 나오겠지만 사용자 중심주의 항목이 가장 높은 평균 점수인 "7.8"점을 기록하였습니다.
• 그 다음으로는 유연성, 조직 안정성, 웨스트럼 조직 문화 항목이 높은 점수를 기록하였습니다.
• 개인적인 생각으로는 지식 공유 항목이 높은 점수가 안나와서 의아했지만 조직마다 지식 공유 분위기가 많이 다르다보니 나올 수 있는 점수라고 생각되었습니다.

2023 State of DevOps Report의 요약된 주요 내용을 확인해봤는데요.
2탄에서는 각각의 주요 내용에 대해서 상세하게 확인해보는 시간을 가져보겠습니다....! 끝...!

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

[Reference]

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

[AWS] 리눅스 서버 CloudWatchAgent 설치하기

AWS에서 CloudWatch를 통해 서버의 메모리 및 디스크 사용량 등을 확인하기 위해서는 EC2 서버에 CloudWatchAgent를 설치해야 됩니다. 리눅스 서버의 서버의 메모리 및 디스크 사용량 등을 확인하기 위해 CloudWatchAgent를 설치하고, AWS를 설정하는 방법을 알아봅시다.

IAM Role 적용

EC2에서 CloudWatchAgent를 통해 EC2 인스턴스의 정보를 보낼 수 있도록 IAM 역할을 인스턴스에 연결해야 합니다.
허용이 필요한 정책은 CloudWatchAgentServerPolicy 이며, IAM 역할 추가를 통해 생성합니다.

IAM -> Roles 메뉴에서 신규로 Role을 생성합니다.

서비스는 EC2를 선택합니다.

정책은 CloudWatchAgentServerPolicy를 검색 후 해당 정책을 선택합니다.

IAM Role 이름을 설정 후 생성합니다.

생성된 IAM Role을 확인하실 수 있습니다.

이제 EC2 -> Instances 메뉴에서 역할을 적용할 EC2를 우클릭 후 Security -> Modify IAM role을 클릭합니다.

생성한 IAM role을 선택 후 업데이트하면 IAM Role 적용이 완료됩니다.

CloudWatchAgent 설치 및 설정 파일 적용

CloudWatchAgent를 설치할 리눅스 서버에 접속 후 설치 파일을 통해 패키지를 설치하고, 설정 파일을 적용해보겠습니다.
테스트한 EC2 서버의 OS는 Rocky Linux 9.2를 사용하였습니다.

설치 파일을 다운로드 하기 위해 wget 명령어를 사용합니다.
wget 명령어가 없을 경우 yum 명령어로 설치합니다.

• 실행 명령어

yum install -y wget

• 결과

*** 생략 ***
Running transaction
  Preparing        :                                                                1/1
  Installing       : wget-1.21.1-7.el9.x86_64                                       1/1
  Running scriptlet: wget-1.21.1-7.el9.x86_64                                       1/1
  Verifying        : wget-1.21.1-7.el9.x86_64                                       1/1

Installed:
  wget-1.21.1-7.el9.x86_64

Complete!

wget 명령어로 설치 파일을 다운로드 합니다.

• 실행 명령어

wget -P /tmp/ https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm

• 결과

--2023-12-07 07:06:04--  https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm
Resolving amazoncloudwatch-agent.s3.amazonaws.com (amazoncloudwatch-agent.s3.amazonaws.com)... 52.217.175.113, 52.216.52.153, 52.217.225.49, ...
Connecting to amazoncloudwatch-agent.s3.amazonaws.com (amazoncloudwatch-agent.s3.amazonaws.com)|52.217.175.113|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 100700416 (96M) [application/octet-stream]
Saving to: ‘/tmp/amazon-cloudwatch-agent.rpm’

amazon-cloudwatch-age 100%[=========================>]  96.04M  7.69MB/s    in 14s

2023-12-07 07:06:19 (6.89 MB/s) - ‘/tmp/amazon-cloudwatch-agent.rpm’ saved [100700416/100700416]

rpm 명령어로 설치 패키지를 설치합니다.

• 실행 명령어

rpm -U /tmp/amazon-cloudwatch-agent.rpm

• 결과

create group cwagent, result: 0
create user cwagent, result: 0

아래 내용으로 config.json 파일을 /tmp/ 경로에 생성합니다.

• 실행 명령어 및 결과

cat << EOF > /tmp/config.json
{
    "agent":{
        "metrics_collection_interval":60,
        "debug":false
    },
    "metrics": {
        "namespace": "CloudWatch/TestMetrics",
        "metrics_collected":{
            "disk":{
                "measurement":[{"name" : "disk_used_percent", "rename" : "DISK_USED" } ],
                "metrics_collection_interval":30,
                "resources":["/"]
            },
            "mem":{
                "measurement":[ {"name" : "mem_used_percent", "rename" : "MEMORY_USED"} ],
                "metrics_collection_interval":10
            }
        },
        "append_dimensions":{
            "InstanceId":"\${aws:InstanceId}"
        }
    }
}
EOF

아래 명령어를 통해 추가한 config.json 파일 내용으로 AmazonCloudWatchAgent를 실행합니다.

• 실행 명령어

amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/tmp/config.json

• 결과

****** processing amazon-cloudwatch-agent ******
I! Trying to detect region from ec2 D! [EC2] Found active network interface I! imds retry client will retry 1 timesSuccessfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp
Start configuration validation...
2023/12/07 07:27:51 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp ...
2023/12/07 07:27:51 I! Valid Json input schema.
2023/12/07 07:27:51 D! ec2tagger processor required because append_dimensions is set
2023/12/07 07:27:51 D! metric decorator required because measurement fields are set
2023/12/07 07:27:51 D! pipeline hostDeltaMetrics has no receivers
2023/12/07 07:27:51 Configuration validation first phase succeeded
I! Detecting run_as_user...
I! Trying to detect region from ec2
D! [EC2] Found active network interface
I! imds retry client will retry 1 times
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded

아래 명령어를 통해 정상적으로 AmazonCloudWatchAgent가 실행되었는지 확인합니다.

• 실행 명령어

amazon-cloudwatch-agent-ctl -m ec2 -a status

• 결과

{
  "status": "running",
  "starttime": "2023-12-07T07:27:51+00:00",
  "configstatus": "configured",
  "version": "1.300031.0b313"
}

• 실행 명령어

systemctl status amazon-cloudwatch-agent

• 결과

● amazon-cloudwatch-agent.service - Amazon CloudWatch Agent
     Loaded: loaded (/etc/systemd/system/amazon-cloudwatch-agent.service; enabled; preset: disabled)
     Active: active (running) since Thu 2023-12-07 07:26:19 UTC; 23s ago
   Main PID: 11484 (amazon-cloudwat)
      Tasks: 7 (limit: 22602)
     Memory: 19.7M
        CPU: 170ms
     CGroup: /system.slice/amazon-cloudwatch-agent.service
             └─11484 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -config /opt/aws/amazon-cloudwatch-agent/etc/amazon>

Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: 2023/12/07 07:26:19 Reading json config file path: /opt/aws/amazon-cloudwa>
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: 2023/12/07 07:26:19 I! Valid Json input schema.
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: I! Detecting run_as_user...
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: I! Trying to detect region from ec2
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: 2023/12/07 07:26:19 D! ec2tagger processor required because append_dimensi>
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: 2023/12/07 07:26:19 D! metric decorator required because measurement field>
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: 2023/12/07 07:26:19 D! pipeline hostDeltaMetrics has no receivers
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11489]: 2023/12/07 07:26:19 Configuration validation first phase succeeded
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11484]: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json does not>
Dec 07 07:26:19 TEST start-amazon-cloudwatch-agent[11484]: I! Detecting run_as_user...

인스턴스 메트릭 정보 확인

이제 CloudWatch에서 정상적으로 인스턴스의 메트릭 정보가 저장되고 있는지 확인합니다.

CloudWatch -> Metrics -> All metrics 메뉴를 통해 "CloudWatch/TestMetrics" 이름의 네임스페이스가 생성되었는지 확인합니다.

config.json 파일에서 정의한 DISK_USED, MEMORY_USED 정보를 검색하여 메트릭 정보를 확인하실 수 있습니다.

• DISK_USED

• MEMORY_USED

이제 AWS 리눅스 EC2 서버의 메모리 및 디스크 사용량 등의 인스턴스 정보를 CloudWatch를 통해서 확인하시길 바랍니다. 지금까지 CloudWatchAgent를 설치하고, AWS를 설정하는 작업을 알아보는 시간이었습니다....! 끝...!

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

[Reference]

• https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html
• https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html

[AWS] 윈도우 서버 CloudWatchAgent 설치하기

AWS에서 CloudWatch를 통해 서버의 메모리 및 디스크 사용량 등을 확인하기 위해서는 EC2 서버에 CloudWatchAgent를 설치해야 됩니다. 윈도우 서버의 메모리 및 디스크 사용량 등을 확인하기 위해 CloudWatchAgent를 설치하고, AWS를 설정하는 방법을 알아봅시다.

IAM Role 적용

EC2에서 CloudWatchAgent를 통해 EC2 인스턴스의 정보를 보낼 수 있도록 IAM 역할을 인스턴스에 연결해야 합니다.
허용이 필요한 정책은 CloudWatchAgentServerPolicy 이며, IAM 역할 추가를 통해 생성합니다.

IAM -> Roles 메뉴에서 신규로 Role을 생성합니다.

서비스는 EC2를 선택합니다.

정책은 CloudWatchAgentServerPolicy를 검색 후 해당 정책을 선택합니다.

IAM Role 이름을 설정 후 생성합니다.

생성된 IAM Role을 확인하실 수 있습니다.

이제 EC2 -> Instances 메뉴에서 역할을 적용할 EC2를 우클릭 후 Security -> Modify IAM role을 클릭합니다.

생성한 IAM role을 선택 후 업데이트하면 IAM Role 적용이 완료됩니다.

CloudWatchAgent 설치 및 설정 파일 적용

CloudWatchAgent를 설치할 윈도우 서버에 접속 후 설치 파일을 통해 패키지를 설치하고, 설정 파일을 적용해보겠습니다.
테스트한 EC2 서버의 OS는 Windows Server 2022를 사용하였습니다.

설치 파일을 다운로드 합니다.

https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi

설치 파일을 실행하여 패키지를 설치합니다.

CloudWatchAgent 실행 시 사용할 메트릭 정보를 정의하기 위해 아래 내용으로 config.json 파일을 생성 후 윈도우 서버 "C:\Program Files\Amazon\AmazonCloudWatchAgent" 경로에 추가합니다.

설정한 namespace 값으로 CloudWatch의 Metrics 정보를 구분하여 확인하실 수 있습니다.

{
    "agent":{
        "metrics_collection_interval":60
    },

    "metrics": {
        "namespace": "CloudWatch/TestMetrics",
        "metrics_collected": {
            "statsd": {},
            "Processor": {
                "measurement": [
                    {"name": "% Idle Time", "rename": "CPU_IDLE", "unit": "Percent"}
                ],
                "resources": [ 
                    "*"
                ]
            },
            "LogicalDisk": {
                "measurement": [
                    {"name":"% Free Space", "rename" : "DISK_FREE"}
                ],
                "resources": [
                    "*"
                ]
            },
            "Memory": {
                "metrics_collection_interval": 10,
                "measurement": [
                    {"name":"% Committed Bytes In Use", "rename" : "MEMORY_USED", "unit":"Percent"}]
            }
        },
        "append_dimensions":{
            "InstanceId":"${aws:InstanceId}"
        }
    }
}

아래 명령어를 통해 추가한 config.json 파일 내용으로 AmazonCloudWatchAgent를 실행합니다.

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\config.json"

****** processing amazon-cloudwatch-agent ******
I! Trying to detect region from ec2
D! [EC2] Found active network interface
I! imds retry client will retry 1 timesSuccessfully fetched the config and saved in C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\file_config.json.tmp
Start configuration validation...
2023/12/06 09:21:38 Reading json config file path: C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\file_config.json.tmp ...
2023/12/06 09:21:38 I! Valid Json input schema.
I! Trying to detect region from ec2
D! [EC2] Found active network interface
I! imds retry client will retry 1 times2023/12/06 09:21:38 D! ec2tagger processor required because append_dimensions is set
2023/12/06 09:21:38 D! metric decorator required because measurement fields are set
2023/12/06 09:21:38 D! pipeline hostDeltaMetrics has no receivers
2023/12/06 09:21:38 Configuration validation first phase succeeded
Configuration validation second phase succeeded
Configuration validation succeeded
AmazonCloudWatchAgent has been stopped
AmazonCloudWatchAgent has been started

아래 명령어를 통해 정상적으로 AmazonCloudWatchAgent가 실행되었는지 확인합니다.

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -m ec2 status

{
  "status": "running",
  "starttime": "2023-12-06T09:21:40",
  "configstatus": "configured",
  "version": "1.300031.0b313"
}

인스턴스 메트릭 정보 확인

이제 CloudWatch에서 정상적으로 인스턴스의 메트릭 정보가 저장되고 있는지 확인합니다.

CloudWatch -> Metrics -> All metrics 메뉴를 통해 "CloudWatch/TestMetrics" 이름의 네임스페이스가 생성되었는지 확인합니다.

config.json 파일에서 정의한 CPU_IDLE, DISK_FREE, MEMORY_USED 정보를 검색하여 메트릭 정보를 확인하실 수 있습니다.

• CPU_IDLE

• DISK_FREE

• MEMORY_USED

이제 AWS 윈도우 EC2 서버의 메모리 및 디스크 사용량 등의 인스턴스 정보를 CloudWatch를 통해서 확인하시길 바랍니다. 지금까지 CloudWatchAgent를 설치하고, AWS를 설정하는 작업을 알아보는 시간이었습니다....! 끝...!

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

[Reference]

• https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html
• https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html

[AWS] S3 다른 계정 버킷에 있는 객체 복사하기

AWS 콘솔을 접속하여 S3 버킷의 COPY 기능을 통해 같은 계정에서 동일한 리전의 S3 버킷과 또는 다른 리전의 S3 버킷에 객체를 복사할 수 있습니다.

하지만 AWS 콘솔에서 S3 버킷의 COPY 기능을 통해 다른 계정의 버킷으로는 객체를 복사할 수 없습니다.
IAM 정책 및 버킷 정책을 통해 권한을 허용하여 다른 계정의 S3 버킷에 있는 객체를 복사하는 방법을 알아봅시다.

기본 설정

B 계정에서 AWS CLI를 통해 A 계정의 S3 버킷에 있는 객체를 B 계정의 S3 버킷으로 복사할 수 있도록 작업을 진행해보겠습니다.

우선 각각의 계정에 S3 버킷을 생성합니다.

• A 계정 S3 버킷

• B 계정 S3 버킷

A 계정의 S3 버킷에는 복사하고자 하는 txt 파일을 생성하였습니다.

IAM 정책 추가 및 적용

B 계정의 IAM 정책을 추가하여 A 계정의 S3 버킷을 조회하거나 가져올 수 있도록 허용하고,

자신의 S3 버킷에 업로드할 수 있도록 정책을 허용합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::{SOURCE-S3-BUCKET}",
                "arn:aws:s3:::{SOURCE-S3-BUCKET}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::{TARGET-S3-BUCKET}",
                "arn:aws:s3:::{TARGET-S3-BUCKET}/*"
            ]
        }
    ]
}

정책은 이름 설정 후 생성합니다.

B 계정에서 생성한 IAM 정책은 사용하고자하는 AWS CLI 계정의 정책에 추가합니다.

B 계정에서의 정책 설정을 완료하였습니다.

버킷 정책 추가

A 계정의 S3 버킷에 정책을 추가하여, B 계정에서 A 계정의 S3 버킷 객체를 가져갈 수 있도록 허용합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DelegateS3Access",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{B Account ID}:user/{B Account IAM UserName}"
            },
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::copy-test-src-s3/*",
                "arn:aws:s3:::copy-test-src-s3"
            ]
        }
    ]
}

• AWS 예시
  • arn:aws:iam::123412341234:user/TestUser

A 계정의 S3 버킷 설정을 완료하였습니다.

객체 복사

AWS CLI에 B 계정의 Access Keys를 등록합니다.

B 계정의 S3 버킷을 조회합니다.

# aws s3 ls
2023-10-17 09:18:32 copy-test-target-s3

A 계정의 S3 버킷을 조회할 수 있습니다. 사전에 정책을 추가해줬기 때문에 가능합니다.

# aws s3 ls s3://copy-test-src-s3
2023-10-17 09:21:40       1218 TextFile.txt

이제 A 계정의 S3 버킷에 있는 객체를 B 계정의 S3 버킷에 복사해보겠습니다.

# aws s3 sync s3://copy-test-src-s3 s3://copy-test-target-s3
copy: s3://copy-test-src-s3/TextFile.txt to s3://copy-test-target-s3/TextFile.txt

복사가 완료되었으며 AWS 콘솔을 통해서도 확인하실 수 있습니다.

IAM 정책 및 S3 버킷 정책을 추가하여 다른 계정 버킷에 있는 객체 복사하여 사용해보시기 바랍니다.
지금까지 S3 다른 계정 버킷에 있는 객체 복사하는 방법을 알아보는 시간이었습니다....! 끝...!

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

[Reference]

• https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/copy-data-from-an-s3-bucket-to-another-account-and-region-by-using-the-aws-cli.html
• https://velog.io/@unihit/%EA%B3%84%EC%A0%95%EA%B0%84-S3-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%9D%B4%EC%A0%84-%EB%B0%A9%EB%B2%95

VMware OVF to OVA 변환 ovftool

VMware 도구인 ovftool은 VMware 제품 간에 OVF 패키지를 가져오고 내보내는데 도움을 주는 유틸리티 입니다.
ovftool을 사용하여 OVF 파일을 OVA 파일로 변환하는 작업을 진행해보도록 하겠습니다.

OVF 파일, OVA 파일 차이점

OVF(Open Virtualization Format) 파일과 OVA(Open Virtual Appliance) 파일은 가상 머신 및 가상화 환경에서 가상 머신 이미지를 배포, 공유 및 관리하는 데 사용되는 포맷입니다.

두 파일 형식 사이의 차이점을 요약하자면 OVF 파일은 가상 머신의 구성 정보를 포함하고, OVA 파일은 OVF 파일과 가상 머신 이미지를 함께 포함하는 패키지입니다

상세한 차이점은 다음과 같습니다.

1. 파일 형식

• OVF 파일: OVF는 가상 머신 이미지와 구성 설정을 설명하는 여러 XML 파일과 관련 파일로 구성된 디렉토리 구조를 나타냅니다. OVF 파일은 주로 가상 머신 이미지와 관련 설정 정보를 설명하는 메타데이터를 포함합니다.
• OVA 파일: OVA는 OVF 파일을 하나의 아카이브로 패키징한 파일입니다. OVA 파일은 OVF 파일 및 해당 가상 머신 이미지와 관련 파일을 하나의 아카이브 파일로 묶어 더 쉽게 배포 및 공유할 수 있도록 합니다.

2. 포함 내용

• OVF 파일: OVF 파일은 가상 머신의 구성, 가상 하드웨어 설정, 네트워크 구성 등과 관련된 메타데이터를 포함합니다. 실제 가상 머신 디스크 이미지는 포함하지 않습니다.
• OVA 파일: OVA 파일은 OVF 파일뿐만 아니라 가상 머신 디스크 이미지와 관련 파일도 포함합니다. 이렇게 하면 가상 머신을 완전한 형태로 패키징하여 배포 및 공유할 수 있습니다.

3. 배포 및 공유

• OVF 파일: OVF 파일은 주로 가상 머신의 구성 정보를 공유하고, 실제 가상 머신 이미지는 따로 제공해야 합니다. 이로 인해 가상 머신 이미지와 구성 설정을 별도로 관리해야 할 수 있습니다.
• OVA 파일: OVA 파일은 가상 머신 이미지와 구성 설정을 하나로 묶어 배포 및 공유할 수 있기 때문에 편리하게 사용할 수 있습니다.

4. 휴대성

• OVF 파일: OVF 파일을 다른 환경으로 이동하려면 OVF 파일과 관련 파일을 함께 복사해야 합니다.
• OVA 파일: OVA 파일은 하나의 아카이브 파일로, 이를 이동하거나 다른 VMware 호스트에서 가져오는 데 더 용이합니다.

OVF to OVA 변환

ovftool을 사용하여 OVF 파일을 OVA 파일로 변환해보도록 하겠습니다.

ovftool 다운로드 링크를 통해 ovftool을 다운로드 받으실 수 있습니다.

OVF 파일 구성

OVF는 여러 파일을 패키지로 포함하며 .ovf, .mf, .vmdk, .nvram 파일 등으로 구성되어 있습니다.

• 해당 파일들은 같은 디렉토리에 위치해야 하며, OVF 파일 생성 시 이름을 사용해야 됩니다.
• .vmdk 파일과 같은 경우 이름 변경 시 ovftool을 사용하여 OVA 파일로 변환 시 에러가 발생합니다.

ovftool 변환

ovftool을 사용하여 OVF 파일을 OVA 파일로 변환합니다.

# ovftool.exe {{OVF 파일 이름}} {{OVA 파일 이름}}
> .\ovftool.exe .\VM\relay\DEV-RELAY-CentOS6.7.ovf .\VM\relay\DEV-RELAY-CentOS6.7.ova

완료 시 아래와 같이 Completed successfully을 확인하실 수 있습니다.

해당 경로에 .ova 파일 또한 확인하실 수 있습니다.

이제 OVA 파일을 사용하여 보다 쉽게 가상 머신 이미지를 배포 및 공유하여 사용하시길 바랍니다.

지금까지 ovftool을 사용하여 OVF 파일을 OVA 파일로 변환하는 작업을 알아보는 시간이었습니다....! 끝...!

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

[AWS] Route 53 도메인 신규 등록하기

Amazon Route 53은 가용성과 확장성이 뛰어난 도메인 네임 시스템(DNS) 웹 서비스 입니다.
도메인 연결을 관리할 뿐만 아니라 신규로 도메인을 등록하여 사용할 수 있습니다.
Route 53을 이용하여 도메인을 신규로 등록하는 방법을 알아봅시다.

도메인 신규 등록하기

Route 53 메인 화면에서 신규 도메인 등록을 위한 Domains -> Registered domains 메뉴를 클릭합니다.

Register domains 버튼을 클릭하여 신규 도메인을 등록하는 절차를 진행합니다.

우선 사용하고자하는 도메인 정보를 검색합니다.
사용 가능한 도메인인지 검색 후 사용 가능하다면 Select 후 다음 절차를 진행합니다.

도메인 가격 정보를 확인합니다.
기본적으로 1년 단위로 결제되며, Auto-renew 활성화 시 자동으로 1년마다 갱신됩니다.

도메인 발급에 필요한 상세 정보를 입력합니다.
국가, 이름, 이메일, 전화번호 등의 정보가 필요합니다.

설정을 완료하였으며 Review and submit을 통해 설정한 값을 한번씩 확인합니다.

Terms and conditions(이용약관) 확인 후 Submit을 통해 도메인 발급을 신청합니다.

이제 메인 화면에서 Domains -> Requests 메뉴를 클릭하면 발급 진행 중인 도메인을 확인하실 수 있습니다.

일정 시간이 지나면 아래와 같이 도메인 발급이 완료됩니다.

이제 발급이 완료된 신규 도메인을 자유롭게 사용하시면 됩니다.

지금까지 Amazon Route 53 서비스를 통해 도메인을 신규로 등록하는 방법을 알아보는 시간이었습니다....! 끝...!

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

[AWS] Amazon Kinesis 알아보기

운영중인 서비스가 점차 커진다면 대용량의 실시간 데이터를 수집, 처리 및 분석할 수 있도록 구성해야됩니다. 별도의 데이터 처리 서버를 구성할 수 있겠지만 확장성 및 실시간 모니터링 등 데이터 처리에 필요한 기능을 구현해야 하므로 어려움이 많습니다. AWS에서는 클라우드 기반 데이터 스트리밍 플랫폼인 Amazon Kinesis를 사용하여 대용량의 실시간 데이터를 수집, 처리 및 분석할 수 있습니다.

주요 기능

Amazon Kinesis의 주요 기능은 크게 4가지로 구성되어 있습니다.

• Kinesis Video Streams
  • 비디오 스트림 캡처, 처리 및 저장
• Kinesis Data Streams
  • 데이터 스트림 캡처, 처리 및 저장
• Kinesis Data Firehose
  • 데이터 스트림 AWS 데이터 스토어로 로드
• Kinesis Data Analytics
  • SQL 또는 Apache Flink로 데이터 스트림 분석

Kinesis Video Streams

Kinesis Video Streams는 동영상 스트림을 쉽게 처리하고 저장하기 위한 기능입니다.
IoT 디바이스나 카메라에서 생성되는 동영상 스트림을 실시간으로 수집하고 처리할 수 있습니다. 또한 동영상 데이터를 압축하고 인코딩하며, 실시간으로 스트리밍하거나 저장할 수 있는 인프라를 제공합니다.

Kinesis Data Streams

Kinesis Data Streams은 대량의 실시간 데이터 스트림을 처리하고 분석하기 위한 기능입니다.
데이터 스트림은 하나 이상의 샤드로 구성되며, 각 샤드는 데이터의 순서를 보장하고 병렬 처리가 가능합니다. 데이터를 수집한 후 필요한 처리를 수행하거나 다른 AWS 서비스와 연동하여 사용할 수 있습니다.

Kinesis Data Firehose

Kinesis Data Firehose는 스트림 데이터를 처리하여 다양한 대상으로 전달하는 역할을 합니다.
데이터를 Amazon S3, Amazon Redshift, Amazon Elasticsearch 등과 같은 저장소나 분석 도구로 전달할 수 있습니다. 또한 데이터 전달 과정을 자동으로 관리하므로 개발자는 데이터 전달 파이프라인을 구축하고 관리하는데 시간을 절약할 수 있습니다.

Kinesis Data Analytics

Kinesis Data Analytics는 SQL 쿼리를 사용하여 스트림 데이터를 실시간으로 분석하는 데 사용됩니다.
데이터 스트림에서 생성된 실시간 데이터를 실시간으로 데이터를 가공하고, 패턴을 발견하며, 실시간 대시보드를 생성할 수 있습니다. 또한 SQL 쿼리를 통해 분석하면서 시각화 및 모니터링에 활용할 수 있습니다.

장단점

Amazon Kinesis는 강력한 실시간 데이터 스트리밍 및 처리 플랫폼이지만, 사용 시 고려해야 할 장점과 단점이 있습니다.

장점

1. 실시간 데이터 처리: 대량의 실시간 데이터를 처리하고 분석하는데 탁월한 성능을 제공합니다.
2. 확장성: 데이터 스트림을 여러 샤드로 나누어 처리할 수 있으며, 필요에 따라 확장하여 데이터 처리의 확장성을 보장하면서도 성능을 유지할 수 있습니다.
3. 다양한 데이터 유형 처리: 웹사이트 로그, 센서 데이터, 애플리케이션 로그 등 다양한 소스의 데이터 유형을 처리할 수 있습니다.
4. 간편한 데이터 파이프라인 구축: 간편하게 데이터 파이프라인을 쉽게 구축하고, 데이터 변환과 전달을 자동으로 관리하므로 개발자는 데이터 이동에만 집중하면 됩니다.
5. 실시간 분석 및 모니터링: 실시간으로 데이터를 분석하고 모니터링할 수 있습니다.
6. 다양한 대상으로의 전달: 데이터를 다양한 AWS 서비스 및 저장소로 전달할 수 있습니다.

단점

1. 복잡성: 대규모 애플리케이션에서는 설정 및 구성 과정이 다소 복잡해질 수 있습니다.
2. 비용: 데이터 처리량 및 스트림의 크기에 따라 과금되므로, 대규모 데이터 처리 시 비용이 증가할 수 있습니다.
3. 모니터링 및 디버깅: 대용량 데이터 처리 시 모니터링 및 디버깅이 복잡해질 수 있습니다.
4. 서비스 의존성: AWS 서비스에 의존성이 높아지므로, AWS 서비스가 불안정한 경우 영향을 받을 수 있습니다.

비용

Amazon Kinesis의 비용은 사용되는 리소스와 데이터 처리량에 따라 다를 수 있습니다

Kinesis Data Streams

데이터 샤드 수: 가장 큰 비용 요소는 데이터 샤드 수입니다. 데이터 샤드 수가 많을수록 비용이 증가합니다.
데이터 샤드 시간당 비용: 각 데이터 샤드당 시간당 비용이 부과됩니다.

Kinesis Data Firehose

전송량: 전송된 데이터 양에 따라 비용이 부과됩니다. 데이터 전송량이 많을수록 비용이 증가합니다.
전송 시간당 비용: 데이터 전송 시간당 비용이 부과됩니다.

Kinesis Data Analytics

처리량: 처리되는 데이터 양에 따라 비용이 부과됩니다. 처리량이 많을수록 비용이 증가합니다.
처리 시간당 비용: 처리된 시간당 비용이 부과됩니다.

활용

웹 사이트 모니터링 및 분석

모바일 서비스 발전에 따라 모바일에서 어플이나 웹 사이트를 통해 다양한 서비스를 이용하고 있습니다.
어플이나 웹 사이트에서 생성되는 로그 데이터를 수집하고 분석하여 성능, 사용자 동작, 에러 등을 실시간으로 모니터링 및 분석할 수 있습니다. 실시간 대시보드 및 경고 시스템을 구축하여 웹사이트의 상태를 실시간으로 파악하고 개선할 수 있습니다.

금융 거래 감지 및 분석

결제, 입출금, 주식 거래 등 실시간으로 많은 수의 금융 거래가 실시간으로 계속 발생되고 있습니다.
금융 거래 데이터를 실시간으로 처리하여 부정 거래나 신용카드 사기 등을 감지할 수 있습니다.
또한 금융 거래의 이상 패턴을 실시간으로 분석하여 신속하게 대응할 수 있습니다.

게임 분석

온라인 게임에서는 실시간으로 다른 플레이어들과 상호작용을 하면서 다양한 게임 플레이를 진행합니다.
온라인 게임에서 생성되는 사용자 데이터를 실시간으로 분석하여 게임 플레이, 플레이어 상호작용, 성과 등을 추적하고 게임 개선에 활용할 수 있습니다.

Amazon Kinesis를 통해 대용량의 실시간 데이터를 유연하게 처리해보시기 바랍니다.
지금까지 Amazon Kinesis를 알아보는 시간이었습니다....! 끝...!

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

[Reference]

• https://aws.amazon.com/ko/kinesis/
• https://aws.amazon.com/ko/kinesis/data-streams/?nc=sn&loc=0
• https://aws.amazon.com/ko/kinesis/data-firehose/?nc=sn&loc=0
• https://aws.amazon.com/ko/kinesis/data-analytics/?nc=sn&loc=0