기준으로는 총 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 툴의 사용, 인기도, 관심도를 비교해보는 시간이였습니다....! 끝...!
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원 (월 기준)
[AWS] Certified Solutions Architect - Associate 취득 후기
이번에 AWS 자격증인 Solutions Architect - Associate (SAA)을 취득하였습니다!! 단순 자격증만을 취득하기 목적이 아닌 AWS 각각의 서비스들을 공부하면서 진행했기 때문에 총 2달의 시간이 소요되었습니다. 어떤 방법으로 공부했는지와 취득 시 꿀팁 등을 공유해드리도록 하겠습니다.
시험 공부
시험 공부는 크게 3단계로 공부하였으며 하나씩 공유해드립니다.
1. Udemy 강의
Solutions Architect - Associate 자격증에서 가장 유명한 Stephane 선생님의 Udemy 강의입니다.
examtopics 사이트의 장점은 Discussion을 통해 각 항목에 대한 상세한 설명을 각 유저들이 남긴 댓글을 통해 확인할 수 있어 문제를 이해하는데 큰 도움이 되었습니다. (사이트에서 틀린 정답이 있어 투표에 따른 정답을 확인하시면 됩니다. 덤프 파일 또한 실제 정답과 다른 정답이 있다고 합니다.)
추가로 빠르게 합격하고 싶으신 분은 덤프 파일을 구매하시는 것을 추천해드립니다!
시험 진행
시험 신청
AWS Training 센터를 통해 시험을 예약하였으며, 온라인 시험(OnVUE)으로 신청하였습니다.
시험 신청 시점은 시험 공부 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 취득 후기였습니다....! 끝...!
지난번 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의 주요 결과 및 주요 내용에는 이런 것들이 있구나라고 느끼셨으면 좋겠습니다....! 끝...!
지난번에는 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탄에서는 다른 주요 내용을 상세하게 확인해보는 시간을 가져보겠습니다....! 끝...!
지난 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탄에서는 각각의 주요 내용에 대해서 상세하게 확인해보는 시간을 가져보겠습니다....! 끝...!
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 명령어로 설치합니다.
아래 명령어를 통해 추가한 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.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를 설정하는 작업을 알아보는 시간이었습니다....! 끝...!
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를 사용하였습니다.
아래 명령어를 통해 추가한 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가 실행되었는지 확인합니다.
