반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
AI 인공지능
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
APM Solution
애플리케이션 관리
URL 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
카프카를 통한 로그 관리 방법
메모리 누수 위험있는 FinalReference 참조 분석하기
김진광
2023.10.12
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] 브레인즈컴퍼니 ‘가을문화행사 2023’
Java에서 가장 많이 접하는 문제는 무엇이라 생각하시나요? 바로 리소스 부족 특히 ‘JVM(Java Virtual Machine) 메모리 부족 오류’가 아닐까 생각해요.
메모리 부족 원인에는 우리가 일반적으로 자주 접하는 누수, 긴 생명주기, 다량의 데이터 처리 등 몇 가지 패턴들이 있는데요. 오늘은 좀 일반적이지 않은(?) 유형에 대해 이야기해 볼게요!
Java 객체 참조 시스템은 강력한 참조 외에도 4가지 참조를 구현해요. 바로 성능과 확장성 기타 고려사항에 대한 SoftReference, WeakReference, PhantomReference, FinalReference이죠. 이번 포스팅은
FinalReference를 대표적인 사례
로 다루어 볼게요.
PART1. 분석툴을 활용해 메모리 누수 발생 원인 파악하기
메모리 분석 도구를 통해 힙 덤프(Heap Dump)를 분석할 때, java.lang.ref.Finalizer 객체가 많은 메모리를 점유하는 경우가 있어요. 이 클래스는 FinalReference와 불가분의 관계에요. 나눌 수 없는 관계라는 의미죠.
아래 그림 사례는 힙 메모리(Heap Memory)의 지속적인 증가 후 최대 Heap에 근접 도달 시, 서비스 무응답 현상에 빠지는 분석 사례인데요. 이를 통해 FinalReference 참조가 메모리 누수를 발생시킬 수 있는 조건을 살펴볼게요!
Heap Analyzer 분석툴을 활용하여, 힙 덤프 전체 메모리 요약 현황을 볼게요. java.lang.ref.Finalizer의 점유율이 메모리의 대부분을 점유하고 있죠. 여기서 Finalizer는, 앞에서 언급된 FinalReference를 확장하여 구현한 클래스에요.
JVM은 GC(Garbage Collection) 실행 시 해제 대상 객체(Object)를 수집하기 전, Finalize를 처리해야 해요.
Java Object 클래스에는 아래 그림과 같이 Finalize 메서드(Method)가 존재하는데요. 모든 객체가 Finalize 대상은 아니에요.
JVM은 클래스 로드 시, Finalize 메서드가 재정의(Override)된 객체를 식별해요. 객체 생성 시에는 Finalizer.register() 메서드를 통해, 해당 객체를 참조하는 Finalizer 객체를 생성하죠.
그다음은 Unfinalized 체인(Chain)에 등록해요. 이러한 객체는 GC 발생 시 즉시 Heap에서 수집되진 않아요. Finalizer의 대기 큐(Queue)에 들어가 객체에 재정의된 Finalize 처리를 위해 대기(Pending) 상태에 놓여있죠.
위 그림과 같이 참조 트리(Tree)를 확인해 보면, 많은 Finalizer 객체가 체인처럼 연결되어 있어요. 그럼 Finalizer 객체가 실제 참조하고 있는 객체는 무엇인지 바로 살펴볼까요?
그림에 나온 바와 같이 PostgreSql JDBC Driver의 org.postgresql.jdbc3g.Jdbc3gPreparedStatement인 점을 확인할 수 있어요. 해당 시스템은 PostgreSql DB를 사용하고 있었네요.
이처럼 Finalizer 참조 객체 대부분은 Jdbc3gPreparedStatement 객체임을 알 수 있어요. 여기서 Statement 객체는, DB에 SQL Query를 실행하기 위한 객체에요.
그렇다면, 아직 Finalize 처리되지 않은 Statement 객체가 증가하는 이유는 무엇일까요?
먼저 해당 Statement 객체는 실제로 어디서 참조하는지 살펴볼게요. 해당 객체는 TimerThread가 참조하는 TaskQueue에 들어가 있어요. 해당 Timer는 Postgresql Driver의 CancelTimer이죠.
해당 Timer의 작업 큐를 확인해 보면 PostgreSql Statement 객체와 관련된 Task 객체도 알 수도 있어요.
그럼 org.postgresql.jdbc3g.Jdbc3gPreparedStatement 클래스가 어떻게 동작하는지 자세히 알아볼까요?
org.postgresql.jdbc3g.Jdbc3gPreparedStatement는 org.postgresql.jdbc2.AbstractJdbc2Statement의 상속 클래스이며 finalize() 메서드를 재정의한 클래스에요. Finalize 처리를 위해 객체 생성 시, JVM에 의해 Finalizer 체인으로 등록되죠.
위와 같은 코드로 보아 CancelTimer는, Query 실행 후 일정 시간이 지나면 자동으로 TimeOut 취소 처리를 위한 Timer에요.
정해진 시간 내에 정상적으로 Query가 수행되고 객체를 종료(Close) 시, Timer를 취소하도록 되어 있어요. 이때 취소된 Task는 상태 값만 변경되고, 실제로는 Timer의 큐에서 아직 사라지진 않아요.
Timer에 등록된 작업은, TimerThread에 의해 순차적으로 처리돼요. Task는 TimerThread에서 처리를 해야 비로소 큐에서 제거되거든요.
이때 가져온 Task는 취소 상태가 아니며, 처리 시간에 아직 도달하지 않은 경우 해당 Task의 실행 예정 시간까지 대기해야 돼요.
여기서 문제점이 발생해요.
이 대기 시간이 길어지면 TimerThread의 처리가 지연되기 때문이죠. 이후 대기 Task들은 상태 여부에 상관없이, 큐에 지속적으로 남아있게 돼요.
만약 오랜 시간 동안 처리가 진행되지 않는다면, 여러 번의 Minor GC 발생 후 참조 객체들은 영구 영역(Old Gen)으로 이동될 수 있어요.
영구 영역으로 이동된 객체는, 메모리에 즉시 제거되지 못하고 오랜 기간 남게 되죠. 이는 Old(Full) GC를 발생시켜 시스템 부하를 유발하게 해요. 실제로 시스템에 설정된 TimeOut 값은 3,000초(50분)에요.
Finalizer 참조 객체는 GC 발생 시, 즉시 메모리에서 수집되지 않고 Finalize 처리를 위한 대기 큐에 들어가요. 그다음 FinalizerThread에 의해 Finalize 처리 후 GC 발생 시 비로소 제거되죠. 때문에 리소스의 수집 처리가 지연될 수 있어요.
또한 FinalizerThread 스레드는 우선순위가 낮아요. Finalize 처리 객체가 많은 경우, CPU 리소스가 상대적으로 부족해지면 개체의 Finalize 메서드 실행을 지연하게 만들어요. 처리되지 못한 객체는 누적되게 만들죠.
요약한다면 FinalReference 참조 객체의 잘못된 관리는
1) 객체의 재 참조를 유발 2) 불필요한 객체의 누적을 유발 3) Finalize 처리 지연으로 인한 리소스 누적을 유발
하게 해요.
PART2.
제니우스 APM을 통해 Finalize 객체를 모니터링하는 방법
Zenius APM에서는 JVM 메모리를 모니터링하고 분석하기 위한, 다양한 데이터를 수집하고 있어요. 상단에서 보았던
FinalReference 참조 객체의 현황에 대한 항목도 확인
할 수 있죠.
APM 모니터링을 통해 Finalize 처리에 대한 문제 발생 가능성도
‘사전’
에 확인
할 수 있답니다!
위에 있는 그림은 Finalize 처리 대기(Pending)중인 객체의 개수를 확인 가능한 컴포넌트에요.
이외에도 영역별 메모리 현황 정보와 GC 처리 현황에 대해서도 다양한 정보를 확인 할 수 있어요!
이상으로 Finalize 처리 객체에 의한 리소스 문제 발생 가능성을, 사례를 통해 살펴봤어요. 서비스에 리소스 문제가 발생하고 있다면, 꼭 도움이 되었길 바라요!
------------------------------------------------------------
©참고 자료
◾ uxys, http://www.uxys.com/html/JavaKfjs/20200117/101590.html
◾ Peter Lawrey, 「is memory leak? why java.lang.ref.Finalizer eat so much memory」, stackoverflow, https://stackoverflow.com/questions/8355064/is-memory-leak-why-java-lang-ref-finalizer-eat-so-much-memory
◾ Florian Weimer, 「Performance issues with Java finalizersenyo」, enyo,
https://www.enyo.de/fw/notes/java-gc-finalizers.html
------------------------------------------------------------
#APM
#Finalize
#제니우스
#메모리 누수
#Zenius
#FinalReference
#제니우스 APM
김진광
APM팀(개발3그룹)
개발3그룹 APM팀에서 제품 개발과 기술 지원을 담당하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
옵저버빌리티 향상을 위한 제니우스 대표 기능들
옵저버빌리티 향상을 위한 제니우스 대표 기능들
이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-EMS)에서는 옵저버빌리티 향상을 위해서 어떤 제품들을 제공하고 있는 지 살펴보겠습니다. 옵저버빌리티 구현을 위해 널리 활용되는 대표적인 오픈소스로는 아래 네 가지 정도를 들 수 있습니다. l Prometheus: 메트릭 수집 및 저장을 전문으로 하는 도구입니다. Prometheus는 강력한 쿼리 기능을 가지고 있으며, 다양한 기본 메트릭을 제공하며 데이터 시각화를 위해 Grafana와 같은 도구와 통합될 수 있습니다. 또한 이메일, Slack 및 PagerDuty와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. l OpenTelemetry: 에이전트 추가 없이 원격으로 클라우드 기반의 애플리케이션이나 인프라에서 측정한 데이터, 트레이스와 로그를 백엔드에 전달하는 기술을 제공합니다. Java, Go, Python 및 .NET을 포함한 다양한 언어를 지원하며 추적 및 로그에 대한 통합 API를 제공합니다. l Jaeger: 분산 서비스 환경에서는 한번의 요청으로 서로 다른 마이크로서비스가 실행될 수 있습니다. Jaeger는 서비스 간 트랜잭션을 추적하는 기능을 가지고 있는 오픈 소스 소프트웨어입니다. 이 기능을 통해 애플리케이션 속도를 저해하는 병목지점을 찾을 수 있으며 동작에 문제가 있는 애플리케이션에서 문제의 시작점을 찾는데 유용합니다. l Grafana: 시계열 메트릭 데이터를 시각화 하는데 필요한 도구를 제공하는 툴킷입니다. 다양한 DB를 연결하여 데이터를 가져와 시각화 할 수 있으며, 그래프를 그릴 수도 있습니다. 시각화한 그래프에서 특정 수치 이상일 때 알람 기능을 제공하며 다양한 플러그인으로 기능확장이 가능합니다. ------------------------------------------------- 오픈 기술을 이용해 Do It Yourself 방식으로 옵저버빌리티를 구현한다면 어떨까요? 직접 옵저버빌리티를 구현하기 위해서는 먼저 필요한 데이터를 수집해야 합니다. 필요한 데이터가 무엇인지, 어떤 방식으로 수집할지 결정하고 Prometheus, OpenTelemetry 같은 도구들을 이용해 설치 및 설정합니다. 이 단계는 시간이 가장 오래 걸리고, 나중에 잘못된 구성이나 누락이 발견되기도 합니다. 다음 단계는 데이터 저장입니다. 이 단계에서 주의할 점은 예전처럼 여러 소스에서 수집한 데이터를 단순하게 저장하는 것이 아니라, 전체적인 관점에서 어떤 이벤트가 일어나는지를 추적이 가능하도록 데이터 간의 연결과 선후 관계를 설정하는 것입니다. 어려운 점은 새로운 클라우드 기술을 도입하거나 기존의 인프라나 애플리케이션에서 변경이 발생할 때마다 데이터를 계속해서 정리를 해야 하는데, 이를 위해 플랫폼을 지속적으로 수정하고 구성을 추가해야 한다는 것입니다. 마지막으로 부정확한 경고들은 제거해야 합니다. 비즈니스 상황과 데이터는 계속해서 변화하기 때문에 이에 맞게 베이스 라인을 지속적으로 확인하고, 임계치를 조정해서 불필요한 알람이나 노이즈 데이터가 생기는 것을 방지해야 합니다. 결론적으로 직접 옵저버빌리티를 구현하는 것은 처음에는 쉬워 보여도 고급 인력과 많은 시간을 확보해야 하며, 별개로 시간이 지남에 따라서 효율성과 확장성이 떨어진다는 점을 감안하면 대부분의 기업은 감당하기 어렵다고 할 수 있습니다. 그렇다면, Zenius(제니우스) EMS는 옵저버빌리티를 어떻게 확보하고 있을까요? 옵저버빌리티 향상을 위한 가장 기본적인 기능은 토폴로지맵 또는 대시보드입니다. 다양한 인프라의 물리적 논리적 연결구조들을 한 눈에 시각적으로 파악할 수 있도록 해야 합니다. Zenius는 각 인프라별 상황을 한 눈에 볼 수 있는 오버뷰와 시스템 전체를 조망할 수 있는 토폴로지맵, 그리고 서비스 별 상황들을 감시할 수 있는 대시보드 등 크게 세가지의 뷰어(Viewer)를 제공합니다. 인프라의 구성 상황에 따라 다층적으로 구성되어 고객들이 인프라에서 일어나는 상황을 즉각 알 수 있도록 해 줍니다. 이러한 뷰어들은 기존 ‘모니터링’의 개념에서 ‘옵저버빌리티’ 개념으로 진화화면서 좀 더 다층적, 다양화되는 형태로 진화하고 있습니다. 또한, Zenius는 기존의 각 인프라별로 단순히 감시를 설정하는 방식이 아닌 다양한 인프라로부터의 로그와 메트릭 정보를 이용해 어떤 상관관계가 있는지 분석하는 ‘복합감시’라는 서비스가 기본적으로 탑재돼 있습니다. 복합감시를 대표 기능에는 ERMS(Event Relation Management System), 스냅샷 그리고 조치 자동화 등을 들 수 있습니다. l ERMS 기능은 로깅, 메트릭 정보와 장비의 상태를 이용해 새로운 감시 기준을 만들어, 의미있는 이벤트를 생성해 사용자에게 개별 장비 수준이 아닌 서비스 관점에서 정확한 상황 정 보를 제공합니다. l 스냅샷은 서비스 동작에서 이벤트가 발생했을 때, 당시 상황을 Rawdata 기반으로 그대로 재현하는 기능으로 SMS, DBMS, APM, NMS 등 모든 인프라를 동시에 볼 수 있습니다. l 조치 자동화는 ERMS를 자동운영시스템과 연동해, 특정 상황에서 자동으로 스크립트를 실행해 제어하는 기능입니다. 트레이싱 기능은 APM에서 제공하는 기능으로, WAS(Web Application Server)에 인입되고 처리되는 모든 트랜잭션들을 실시간으로 모니터링하고 지연되고 있는 상황을 토폴로지 뷰를 통해 가시적으로 분석할 수 있습니다. 사용자는 토폴로지 뷰를 통해 수행 중인 액티브 트랜잭션의 상세정보와 WAS와 연결된 DB, 네트워크 등 여러 노드들 간의 응답속도 및 시간들을 직관적으로 파악할 수 있습니다. 제니우스의 또 다른 옵저버빌리티는 인공지능 기반의 미래 예측 기능으로 미래 상황을 시각적으로 보여줍니다. 인프라 종류에 상관없이 인공신경망 등 다양한 알고리즘을 통해 미래 데이터를 생성하고, 장애발생 가능성을 빠르게 파악해 서비스 다운타임이 없도록 도와줍니다. 또한 이상 탐지 기능은 보안 침해 또는 기타 비정상적인 활동을 나타낼 수 있는 시스템 로그, 메트릭 및 네트워크 트래픽의 비정상적인 패턴을 식별할 수 있습니다. 이상탐지 알고리즘은 시간이 지남에 따라 시스템 동작의 변화에 적응하고 새로운 유형의 위협을 식별하는 방법을 학습할 수 있습니다. 이상과 같이 Zenius(제니우스) EMS는 최고의 옵저버빌리티를 제공하기 위해서 연구개발에 매진하고 있습니다. 옵저버빌리티 향상을 위한 다양한 기능/제품들은 고객의 시스템과 조직 상황에 맞게 선별적으로 사용될 수 있습니다.
2023.04.19
클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치
클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치
최근 디지털 트랜스포매이션(Digital Transformation)이 IT 트렌드로 자리 잡았습니다. 기업과 조직은 빠르게 변화하는 환경에 대응하고 경쟁에서 앞서기 위해 '클라우드 네이티브 컴퓨팅' 기술을 채택하고 있는데요. 여기서 클라우드 네이티브 컴퓨팅 기술을 연구 및 발전시키고, 생태계를 촉진하는데 중추적인 역할을 하는 커뮤니티가 바로 'CNCF(Cloud Native Computing Foundation)'입니다. 현재 CNCF에서는 Google, Intel, Azure 등 700여 곳 이상의 회원사들이 활동에 참가하고 있습니다. 이번 시간에는 CNCF가 정확히 무엇이고, 추구하는 핵심가치와 주요 프로젝트에 대해 자세히 알아보겠습니다. 。。。。。。。。。。。。 CNCF(Cloud Native Computing Foundation)란 CNCF는 2015년 12월에 리눅스 재단에 의해서 출범된 비영리 단체로, 네이티브 컴퓨팅 기술의 채택을 촉진하는 오픈소스 소프트웨어 재단입니다. CNCF는 클라우드 네이티브 컴퓨팅 플랫폼에서 사용하며, 확장 가능한 애플리케이션을 개발하는데요. 이와 관련된 기술인 컨테이너, 마이크로서비스, 서비스 메쉬 등의 발전을 촉진하여 이러한 기술 패턴을 누구나 이해하고 활용할 수 있도록 하는 것이 목표입니다. ▲총 24개의 CNCF Platinum Members 이러한 클라우드 네이티브 컴퓨팅 환경을 대중화하기 위해 Google Cloud, AWS, MS Azure, Cisco, IBM, Apple, Oracle, Red Hat, VMware, SAP 등 유수의 기업들이 플래티넘 회원사로 참여하여 뜻을 같이 하고 있습니다. CNCF의 세 가지 핵심 가치 CNCF의 핵심가치는 1) 클라우드 네이티브 기술의 촉진 2) 오픈소스 프로젝트 생태계 육성 3) 기술의 표준화 수립으로 정리할 수 있습니다. 이 세 가지 핵심 가치를 더 자세하게 살펴볼까요? CNCF 핵심가치1 : 클라우드 네이티브 기술의 촉진 CNCF는 현대적이고 미래 지향적인 '클라우드 네이티브 기술의 촉진'을 중요한 핵심 가치로 규정하고 있는데요. 이는 CNCF가 오늘날의 IT 생태계의 중심에 서서, 클라우드 네이티브 기술을 지속적으로 연구 및 개발하여 새로운 디지털 전환의 시대를 선도하고자 하는 의지가 담겨 있다고 볼 수 있습니다. CNCF는 기존 온 프레미스(On-Premise) 환경, 그리고 모놀리식(Monolithic)한 개발 환경에서 탈피한 컨테이너, 마이크로서비스, 서비스 메시, 서버리스 등. 보다 혁신적이고 미래지향적인 기술 영역을 보급하고 대중화하기 위한 노력과 지원을 아끼지 않습니다. ▲기존 모놀리식 아키텍처와 마이크로서비스 아키텍처 비교 또한 디지털 트랜스포메이션 과정에서 클라우드 환경으로의 전환이 더욱 효율적으로 이루어질 수 있도록, 클라우드 네이티브 기술과 기업들의 서비스 모델을 재구성하기 위한 방법들을 안내하고 있습니다. 이렇게 새로운 서비스 모델 구축을 통해 민첩성과 효율성을 강화하여, 빠르게 변화하는 IT서비스의 수요에 기민하게 대응하고 고객 요구에 부응할 수 있도록 지원합니다. 여기서 계속 언급되고 있는 '클라우드 네이티브'는 정확히 무엇을 뜻할까요? CNCF의 활동에 대한 이해도를 높이기 위해, 클라우드 네이티브의 의미를 짚어보겠습니다! 📑클라우드 네이티브(Cloud Native)란? 클라우드 네이티브는, 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축·배포·관리할 때의 소프트웨어 접근 방식입니다. 기업과 조직은 고객의 요구를 충족하기 위해 신속하게 업데이트할 수 있는 확장성과 유연성, 그리고 복원력이 뛰어난 애플리케이션을 구축하고자 합니다. 이를 위해 클라우드 네이티브에서 사용되는 기술들은, IT 서비스에 영향을 미치지 않고 애플리케이션을 신속하게 변경합니다. 또한 리소스를 효율적으로 활용하여 빠르게 변화에 대응할 수 있도록 지원하고 있습니다. 위의 개념을 '클라우드 컴퓨팅'과 비교한다면 보다 더 쉽게 이해할 수 있는데요. 클라우드 컴퓨팅은, 클라우드 서비스 제공 업체가 단순히 리소스와 인프라를 클라우드 형태로 제공하는 방식입니다. 여기서 서비스 제공 방식은 기존 '모놀리식' 방식과 크게 다르지 않습니다. ▲클라우드 네이티브의 핵심요소 ⓒPivotal 클라우드 네이티브는 마이크로서비스 아키텍처(MSA)와 컨테이너를 기반으로, IT 서비스의 확장·변경 등에 대응이 용이한 환경입니다. 예를 들어 Ex1) 서비스 수요가 폭증하거나 장애가 생겼을 경우 Ex2) 자동적으로 애플리케이션을 확장하거나 장애가 발생했을 경우에는 대체 가능한 모델을 바로 적용하여 Fail-Over가 손쉽게 이루어질 수 있도록 합니다. CNCF에서는 위 그림과 같이 클라우드 네이티브의 핵심 요소를 마이크로서비스, 컨테이너, 애플리케이션의 개발·통합·배포의 의미를 내포하는 DevOps, CI/CD의 개발 방법론을 포함하여 설명하고 있습니다. CNCF 핵심가치2 : 오픈소스 프로젝트 생태계 육성 CNCF는 다양하고 혁신적인 '오픈소스 프로젝트'를 개발·공급·대중화하여, 클라우드 네이티브 생태계를 활성화하는데 큰 기여를 하고 있습니다. 또한 클라우드 네이티브 컴퓨팅 환경을 구성하고 효율적으로 운영하기 위해, 다양한 오픈소스를 개발하고 있는데요. 누구나 이와 같은 기술들을 이용할 수 있도록 지원합니다. 가장 성공적인 프로젝트는 2018년 8월에 컨테이너 오케스레이션 플랫폼인 'Kubernetes' 프로젝트이며, 컨테이너 생성·실행·종료 등의 역할을 하는 'Containerd', 시스템 모니터링 및 경고 역할을 하는 'Prometheus' 그리고 여러 시스템의 트래픽을 균등하게 분배하여 로드밸런싱을 제공하는 'Envoy' 등이 있습니다. 이처럼 클라우드 네이티브 생태계 활성화를 위한 다양한 프로젝트를 실행하며 배포하고 있습니다. ▲CNCF 개발 완료된 프로젝트 이외에도 클라우드 네이티브 커뮤니티인 이벤트·웨비나·워크샵 등을 활성화하여, 온오프라인 영역에서 개발자들 간의 교류를 원활하게 합니다. 개발자들이 오픈소스 프로젝트를 효과적으로 활용할 수 있도록, 사용법에 대한 교육과 튜토리얼을 제공하기도 합니다. 이를 통해 많은 기업과 이용자들이 클라우드 네이티브 환경에 손쉽게 접근할 수 있도록 지원하고 있습니다. CNCF 핵심가치3 : 기술의 표준화 수립 CNCF는 클라우드 네이티브 관련 기술의 무분별한 확장과 사용으로 인한 혼란을 방지하고자, 기술의 표준화를 촉진하고 정책의 일관성을 확보하는 노력 또한 지속하고 있는데요. 기술의 안정성과 품질 확보를 위해 재단 자체적으로 테스트와 벤치마킹 등을 수행하고, Best Practice를 공유하여, 기술의 표준화와 성숙도를 유지합니다. 이 외에도 CNCF는 새로운 기술의 적용 가능성과 성숙도를 평가하고, 클라우드 관련 기술을 보유한 회원사 및 파트너와의 협력을 촉진합니다. 이처럼 다양한 형태로 클라우드 네이티브 생태계의 지속적인 발전을 지원하고 있습니다. 。。。。。。。。。。。。 이번 시간에는 CNCF의 정의와 핵심가치를 알아보았는데요. CNCF는 앞에서 소개해 드린 내용처럼, 클라우드 네이티브 생태계 활성화를 위해 다양한 노력을 기울이고 있습니다. 브레인즈컴퍼니 역시 클라우드 네이티브 모니터링을 위한 다양한 제품과 기능들을 속속 출시하고 있으니, 많은 관심 부탁드립니다. 다음 시간에는 [CNCF의 핵심 프로젝트] 주제로 돌아오겠습니다!
2023.12.27
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
지난 포스팅을 통해 정리한 것처럼 CNCF는 클라우드 네이티브 생태계의 활성화를 위해, 다양한 오픈소스 프로젝트를 개발하고 공급하고 있습니다. 또한 프로젝트 채택 단계부터 사용 빈도까지의 성숙도를 관리하기 위한, 프로세스 체계를 보유하고 있는데요. 이번 시간에는 CNCF의 주요 프로세스인 쿠버네티스(K8s), Helm 등과 CNCF 프로세스에 대해서 알아보고자 합니다. 。。。。。。。。。。。。 CNCF 프로젝트 프로세스 2023년 10월 기준으로 약 170여 개의 CNCF 프로젝트가 진행 중인데요. 이들 프로젝트는 성숙도에 따라서 샌드박스(Sandbox), 인큐베이팅(Incubating), 졸업(Graduated)으로 나뉩니다. 성숙도 수준에 대한 평가는 CNCF 위원회 멤버들에 의해서 결정되며, 졸업(Graduated) 단계의 프로젝트로 인정받기 위해서는 3분의 2 이상의 찬성 표가 필요합니다. ▲프로젝트 성숙도 단계 Step1. 샌드박스(Sandbox) CNCF의 새로운 프로젝트가 채택되면 Sandbox 단계에서 시작합니다. 이 단계에서는 프로젝트가 CNCF의 가이드라인과 정책에 부합되는지를 확인하는 절차를 주로 거칩니다. Step2. 인큐베이팅(Incubating) Sandbox를 통과한 프로젝트는 Incubating 단계로 집입하며, 이 단계에서는 프로젝트의 커뮤니티와 기술적 성숙도를 더욱 강화하도록 합니다. 해당 프로젝트의 커뮤니티의 규모와 다양성을 평가하고 기능들의 안정성을 검증합니다. Step3. 졸업(Graduated) Incubating 단계를 성공적으로 통과한 프로젝트는 Graduated 단계로 올라갑니다. 높은 수준의 품질과 안정성이 보장되어야 이 단계에 올라갈 수 있는 거죠. 커뮤니티가 활발하게 유지되고 관련자의 참여가 적극적으로 이루어져야 하며, 실제 사용 사례에서 성공한 경험들이 존재해야 합니다. Step4. 사용 사례 검증 Graduated 프로젝트 중 실제로 다양한 산업에서 사용되고, 기업과 조직이 해당 프로젝트를 많이 채택하는지를 평가하여, 지속적인 성장 가능성과 성숙도를 평가합니다. CNCF에서 관리하는 프로젝트 영역은 꽤 넓고 다양한데요. 애플리케이션 개발을 위한 도구부터 컨테이너 오케스트레이션, 서비스 프로비저닝, 모니터링 도구 등 소프트웨어 개발부터 운영까지를 위한 도구들이 존재합니다. 이제부터는 가장 성공적인 프로젝트인 쿠버네티스를 포함하여, Incubating 단계 이상의 프로젝트를 알아보고자 합니다. CNCF의 주요 프로젝트 쿠버네티스(kubernetes) 쿠버네티스는 CNCF에서 최초로 Graduated 단계에 진입한 프로젝트입니다. 컨테이너 오케스트레이션 기능을 통해, 애플리케이션 컨테이너 기반으로 자동화하고 확장할 수 있는 플랫폼을 제공합니다. A. 컨테이너 오케스트레이션 기능 컨테이너화된 애플리케이션을 자동으로 배포·확장하고 관리하는 기능을 제공합니다. 애플리케이션의 변경이 필요할 경우, 개발자가 애플리케이션을 빠르게 수정 및 배포하고 운영할 수 있게 합니다. B. 스케일링 기능 리소스 사용량이나 사용자 트래픽 증가에 따라 자동으로 애플리케이션을 확장·축소하는 오토 스케일링 기능을 제공합니다. C. 롤백 기능 문제가 발생된 애플리케이션의 경우, 롤백 기능을 제공하여 서비스 장애에 신속히 대응합니다. Helm Helm은 쿠버네티스 환경에서 애플리케이션을 관리하기 위한 도구로 사용됩니다. Helm은 차트라고 불리는 패키지로 애플리케이션을 패키징 하는데요. 이 차트에는 애플리케이션의 설치부터 관리에 필요한 모든 것을 포함합니다. 쉽게 말하면 이 차트라는 기능을 통해 애플리케이션을 탬플릿화하고, 배포하며, 롤백 및 공유하는 역할을 하는 프로젝트입니다. Envoy ▲Envoy를 사용하는 주요 업체 리스트 ⓒenvoyproxy.io Envoy는 클라우드 네이티브 환경에서 애플리케이션의 네트워크 트래픽을 관리하고, 제어하기 위한 프로젝트입니다. 프록시 기능을 수행하고, 클라이언트 서버 간의 통신을 관리하며, 애플리케이션 간의 통신의 보안 향상시킵니다. 여러 애플리케이션 사이에서 부하 분산을 자동화하여 가용성과 성능을 향상시킬 수 있도록 합니다. 부하 분산을 함에도 불구하고 특정 시스템에 부하가 생겨 장애 발생이 생길 경우, 트래픽을 가중치에 따라 다른 시스템으로 분산시키는 역할을 합니다. Containerd Containerd는 쿠버네티스 환경에서 컨테이너를 만들고 실행하는 데 도움을 주는 프로젝트입니다. 개발자가 컨테이너를 만들고 실행시키는 역할을 하며, 필요할 때는 중지하거나 삭제하는 작업을 지원합니다. 컨테이너 실행에 필요한 파일과 설정을 모아 놓은 이미지를 다운로드하고, 저장하며, 불러오는 역할과 같은 이미지 관리 기능도 제공하고 있습니다. Prometheus Prometheus는 시스템이나 애플리케이션의 동작을 실시간으로 모니터링하고, 이상 상황이 발생할 경우 알림을 줄 수 있는 도구입니다. 다양한 데이터를 수집하고 기록하여 차후 분석 용도로 활용할 수 있습니다. 또한 핵심 지표들을 유형 및 종류별로 제공하여, 다각적인 관점에서의 관찰을 지원합니다. 시스템의 리소스부터 애플리케이션의 동작 및 응답 상태를 적시에 확인하게 해줍니다. Fluentd ▲Fluentd 개념 설명 ⓒfluentd.org Fluentd는 다양한 시스템에서 발생되는 로그 데이터를 수집·처리·전송하는 데이터 수집 도구로서, 스플렁크(SPLUNK)와 유사한 역할을 수행하는 프로젝트입니다. 다양한 소스에서 발생되는 로그를 수집할 수 있을 뿐만 아니라, 원하는 목적지의 저장소까지 전송하는 역할을 수행합니다. 예를 들어 Syslog 등을 실시간 수집하고, 이를 Elasticsearch나 Amazon S3 등의 원하는 저장소로 목적지를 설정할 수 있게 합니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼, CNCF에서 클라우드 네이티브 생태계 활성화를 위해 다양한 프로젝트를 진행하고 있는데요. 브레인즈컴퍼니 역시 클라우드 네이티브 모니터링을 위한 다양한 제품과 기능 등을 속속 출시하고 있습니다. 대표 제품인 제니우스(Zenius)를 통해 클라우드 네이티브의 핵심요소인 컨테이너(Docker)의 상태와 리소를 실시간으로 모니터링할 수 있습니다. MSA 환경을 만들기 위한 필수 도구인 쿠버네티스(K8s)의 Cluster·Node·Pod 등의 구성과 변화를 관찰하며, 이상 상황 알림을 통해 선제적 장애 대응 또한 가능합니다. Zenius에 대해 더 자세히 알고 싶으시다면, 바로 아래 링크를 클릭해 주세요! 🔍더보기 Zenius로 클라우드 네이티브 모니터링하기 CNCF 세 가지 핵심가치(1탄)도 있어요
2024.01.03
테라폼(Terraform)의 모든 것, 그리고 AWS EC2 생성하기
테라폼(Terraform)의 모든 것, 그리고 AWS EC2 생성하기
클라우드 환경이 도래하면서 CSP(Cloud Service Provider)에서는 콘솔을 통해 클라우드 자원에 쉽게 접근할 수 있게 되었습니다. 하지만 서비스를 운영하며 발생하는 다양한 이슈를 콘솔에서 전부 관리하기에는 무리가 있습니다. 반복적인 작업과 휴먼에러가 발생하기 때문이죠. 이러한 문제를 한 번에 해결할 수 있는 방법이 바로 IaC(Infrastructure as Code)입니다. 인프라를 코드로 관리하는 컨셉으로, 효율적인 데브옵스와 클라우드 자동화 구축을 위해 ‘꼭’ 필요한 기술로 각광받고 있죠. 그중에서도 ‘테라폼(Terraform)’은 가장 강력한 IaC 도구로 꼽힙니다. “테라폼(Terraform)이란?” 테라폼은 하시코프(Hashicorp) 사에서 Go 언어로 개발한 오픈소스 IaC 도구입니다. 테라폼에서는 HCL(Hashicorp Configuration Language, 하시코프 설정 언어)을 사용해 클라우드 리소스를 선언합니다. *쉽게 설명한다면 코드로서 클라우드 인프라 서버를 더 효율적으로 구축하고, 운영할 수 있는 오픈소스 소프트웨어죠. 따라서 이번 시간에는 테라폼의 기본동작방식, 특장점, 명령어의 종류, 구체적인 활용 예시에 대해서 살펴보겠습니다. 。。。。。。。。。。。。 테라폼의 기본동작방식 테라폼은 Write, Plan, Apply 기본동작방식으로 이루어져 있는데요. Write 단계에서는 HCL 언어로 필요한 리소스를 선언하고, Plan 단계에서는 앞에서 선언된 리소스들이 생성 가능한지 테스트 및 예측 실행을 수행하며, Apply 단계에서는 선언된 리소스들을 CSP에 적용하는 과정을 거칩니다. *쉽게 설명한다면 Write 단계는 코드 기반으로 선언하고, Plan 단계는 코드 기반으로 검토하며, Apply 단계는 코드 기반으로 리소스를 생성하는 것이죠. 테라폼의 기본개념 테라폼의 주요 기본개념이자 구성요소입니다. 전부 필수적인 내용이지만 특히 Resource, Provider, State는 많이 쓰이는 중요 개념이며 하단 예시에도 나오니 꼭 기억해 두세요! 테라폼의 장점 테라폼은 다양한 장점들이 있는데요. 그중 가장 큰 장점은 자동화를 통해 코드 기반으로 서버 운영 및 관리가 가능한 점입니다. 초보자도 쉬운 코드 재사용을 통해, 효율적인 협업이 가능하고 생산성도 향상시킬 수 있죠. 또한 테라폼은 AWS, GCP(구글), Azure(MS), Naver Cloud(네이버클라우드) 등 다양한 환경에서 지원이 가능한데요. 즉 테라폼만으로도 멀티 클라우드 리소스들을 선언하고 코드로 관리할 수 있습니다. 테라폼의 명령어 테라폼에서 자주 쓰이는 명령어입니다. 그중에서도 코드를 통해 실행될 내용을 미리 확인하는 Plan, 코드 기반으로 리소스를 생성하는 Apply, 그리고 상태를 확인하는 State가 핵심 명령어로 많이 사용되고 있습니다. 테라폼의 활용예시 테라폼을 통해 많은 것을 할 수 있지만, 이번 시간에는 테라폼을 이용하여 AWS에 가장 중심이 되는 서비스인 EC2(AWS에서 제공하는 서버)를 생성해 보겠습니다. 또한 제니우스(Zenius) 모니터링까지 살펴봅시다! 우선 앞서 [테라폼의 기본동작방식]에서 설명했던 것처럼 테라폼은 Write, Plan, Apply 단계를 거치게 되는데요. 테라폼 명령어가 어떤 방식으로 쓰이고 반응하는지, 예시를 통해 확인해 볼까요? > Write 단계: Provider 및 Resource 선언하기 Writer 단계에서는 [테라폼의 기본개념]으로 언급된 *Provider, Resource를 코드 기반으로 선언한 부분을 확인할 수 있습니다. > Plan 단계: Terraform plan Plan 단계에서는 *Terraform plan을 통해 검증을 하게 되는데요. 위 사진 하단에 나와있듯 1개가 추가되고, 0개가 변하고 0개가 없어진다는 의미입니다. 이처럼 +을 통해 추가되는 인프라의 상세정보를 확인할 수 있습니다. > Apply 단계: Terraform apply Apply 단계에서는 앞서 구축 계획에 문제가 없다면 *Terraform apply를 통해 검증된 결과를 바탕으로 실제 인프라에 적용하는 단계입니다. apply 명령을 이용하여 리소스를 생성·수정·삭제하는 것이죠. > State로 확인해 보기 State list 명령어를 통해서도 확인해 보니, 1개의 인스턴스(instance, 클래스의 현재 생성된 오브젝트)가 확인 되네요. 앞서 State list 명령어를 통해 생성된 ‘부분’만 확인했다면, 이번에는 State show 명령어를 통해 어떻게 생성이 됐는지 ‘상세’하게 확인해 봅시다. State 명령어뿐만 아니라 State는 terraform.tfstate 파일로도 확인 가능해 인스턴스 Name 또한 비교해 보았습니다. 테라폼을 이용해 최종 목표였던 AWS에 EC2 인스턴스가 잘 생성이 되었는지 확인해 봐야겠죠? *빨간색 네모 박스에 표기되어 있는 것처럼 잘 생성 되었습니다. 여기서 다시 주목할 점은 AWS의 인스턴스를 생성하기 위해선, 여러 가지 절차를 거쳐야 하는데요. 테라폼을 이용하면 ‘코드’ 하나로 바로 생성이 가능하다는 점입니다. 코드 기반으로 서버운영 및 관리의 자동화라는 특장점 또한 다시 한번 상기해 볼 수 있겠죠? 이처럼 인프라 서버를 효율적으로 구축하는 테라폼을 이용하여, AWS에 EC2를 생성해 보았습니다. 하지만 ‘생성’만 중요한 게 아닌, 효율적인 클라우드 인프라 관리를 극대화하기 위해 ‘모니터링’하는 점도 매우 중요한데요. 테라폼처럼 매우 쉽고 효율적인 방법을 소개하겠습니다. 바로 AWS EC2 모니터링이 가능한 클라우드 서비스 모니터링 시스템인 제니우스-CMS(Zenius-CMS) 예시를 통해, 다양한 환경에서 인프라 모니터링을 어떻게 하고 있는지 살펴보겠습니다! Zenius에서 AWS 모니터링하기 Zenius-CMS는 API를 통해 AWS 계정 기반으로 자동 모니터링을 제공하고 있는데요. 테라폼을 통해 AWS에서 EC2가 코드 기반으로 쉽게 생성했던 것처럼, CMS도 간편한 AWS 모니터링 실행이 가능합니다. 위 사진처럼 EC2 클라우드 서버에 대한 성능도 모니터링이 가능하죠. 여기서 새로운 인스턴스를 추가하면, 이 또한 자동으로 모니터링이 됩니다. Zenius-CMS는 EC2뿐만 아니라 RDS, VPC 등 과금 현황까지 통합 모니터링할 수 있는데요. AWS 콘솔에 접속하지 않고도, AWS 주요 성능 지표에 대한 모니터링 추이도 확인할 수 있습니다. 。。。。。。。。。。。。 이번 시간에는 인프라 서버를 효율적으로 구축하는 테라폼에 대해 학습하고, AWS에 EC2를 생성해 보며 활용 예시까지 살펴보았습니다. 또한 제니우스-CMS(Zenius-CMS) 예시를 통해, AWS EC2 모니터링뿐만 아니라 다양한 환경에서 인프라 모니터링 방법을 알 수 있었는데요. 앞으로도 클라우드 환경에서의 인프라 관리뿐만 아니라, 다양한 환경에서의 모니터링이 가능한 제니우스 제품에 많은 관심 부탁드릴게요! 📚참고 자료 모두의 Terraform(테라폼) PART1 - 개념(230313) Terraform(테라폼)이란? 간단 사용기(220711) 테라폼(Terraform) 기초 튜토리얼(200314)
2024.01.11
다음 슬라이드 보기