반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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팀에서 제품 개발과 기술 지원을 담당하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
2022 상반기 New Brainzer 인터뷰 | (1) 개발자 편
2022 상반기 New Brainzer 인터뷰 | (1) 개발자 편
2022년, 브레인즈컴퍼니에는 새로운 브레인저들이 많이 입사했습니다. 특히, 사업을 확장하며 개발자들이 대거 들어왔는데요. 그 중, 상반기에 입사해 6개월 이상 재직 중인 개발자들을 모아 브레인즈를 선택한 이유, 입사 후 느끼는 브레인즈의 매력 등에 대한 이야기를 나눴습니다. 브레인즈컴퍼니에 입사하길 원하는 개발자분들, 주목해주세요! Question List 1. 자기소개 2. 업무소개 3. 브레인즈컴퍼니를 선택한 이유 4. 브레인즈의 매력 5. 성장을 느꼈던 순간 6. 브레인즈에서 이루고 싶은 목표 7. 예비 브레인저에게 한 마디 1. 안녕하세요, 브레인즈컴퍼니 개발 3그룹 위성조입니다. 저는 대학에서 컴퓨터공학을 전공했고 졸업 전에 4개월 정도 다른 곳에서 인턴 생활 후, 입사한지 10개월 정도 됐습니다. 2. 저는 현재 회사의 주력 제품인 제니우스의 차세대를 만드는 팀에서 백엔드 개발자로 일하고 있습니다. 처음 입사 당시에는 프론트엔드 개발자로 입사해 동료들과 함께 페이지의 여러 컴포넌트 및 데이터 처리 로직을 제작했었는데, 우연히 기회가 닿아서 백엔드 개발자로 직무전환 할 수 있었습니다. 백엔드 개발자로서 프론트엔드 개발자 동료들과 협력해, 기존 제니우스에서 지원하던 기능 혹은 새로운 기능들을 추가하거나 기존에 작성됐던 코드들을 개선하는 작업들을 하고 있어요. 3. 인턴 생활 당시에 대시보드에 관해 접할 기회가 있었는데, 꽤나 마음에 들어서 관련 분야에서 일해 보고 싶다는 생각을 했었습니다. 마침 취업을 준비하는 기간에 모니터링 솔루션 국내 1위 업체(브레인즈컴퍼니)에서 올린 채용 공고를 보게 됐고, 관련 업무를 할 수 있을 것 같아 지원했어요. 면접 당시 면접관님이 지금 부서의 부서장님이셨는데, 질의를 주고받는 과정에서 합이 잘 맞았던 것 같아 이 회사에 들어오고 싶다고 생각했었는데, 다행히 합격할 수 있었습니다. 4. 조식과 전자동 에스프레소 머신 포함 각종 음료가 무제한 제공되는 복지가 있고, 업무적으로 수평적인 분위기에서 자유로운 의견 교환이 가능하다는 장점이 있습니다. 제가 있는 개발 3그룹은 최근 저를 포함한 신입분들을 대규모로 신규 채용해, 같은 나이대의 동료들이 매우 많고 운 좋게도 다들 주변과 잘 어울리는 성격이라 부서 분위기가 매우 좋아요. 5. 제가 올린 Pull Request가 머지됐을 때, 제 의견이 맞다고 인정받았을 때, 새로 배운 기술•기능•기법 등을 사용해 이전엔 어려웠던 구현을 간단하게 혹은 효율적으로 완성했을 때, 직무 전환 후 새로운 업무에 적응한 내 모습을 볼 때 등이 있습니다. 6. 우선적으로 제가 제작에 참여한 차세대 제니우스가 시장에 나가서 활약하는 모습을 보고 싶고, 차세대 제니우스가 완성될 즈음에는 제가 사용한 기술 스택 중 한 가지라도 익숙해져서 ‘전문가’ 라는 타이틀이 어색하지 않은 개발자가 되고 싶습니다. 7. 화려한 기술도 좋지만 왜 이 기술을 선택했는지, "이렇게 하면 되더라" 보다 이게 어떻게 되는지 등 기본적이고 본질적인 내용에 충실하시면 좋은 결과 있으실 거라고 생각합니다. 1. 개발 3그룹에 소속돼 있으며, 소프트웨어를 전공한 1년차 개발자 김현수입니다. 대학교 졸업 후 1년 정도 취업 준비를 하다가 브레인즈컴퍼니에 입사하게 됐어요. 2. 저는 현재 서비스되고 있는 제니우스의 차세대 버전인 제니우스 뉴 제너레이션(이하 ZNG)의 프론트엔드를 개발하고 있습니다. 프로그램의 뼈대가 되는 화면 설계, 기능 개발 등을 하고 있습니다. 사용자가 직접 만지고 경험하는 화면을 개발한다는 점에서 사용자와 가장 직접적으로 소통하는 개발자라고 할 수 있겠습니다. 3. 새로운 프로젝트인 ZNG에 초기부터 투입돼 개발을 많이 할 수 있고, 이를 통해 실력적으로 높은 성장을 할 수 있을 것이라고 기대했습니다. 주변 개발자 친구들에게 물어봤을 때 일반적으로 유지보수나 버그 리포트를 하는 경우가 많은데 그에 비해서 '절대적으로 개발하는 시간'이 압도적으로 많아요. 4. 회사가 임직원에게 해줄 수 있는 가장 큰 복지는 '좋은 동료'라고 생각합니다. 실력적으로나, 인성적으로나 말입니다. 그런 측면에서 브레인즈컴퍼니는 높은 수준의 복지를 제공하고 있습니다. 코드리뷰를 하거나 얘기를 나눌 때마다 동료들로부터 배울게 많다고 항상 느껴요. 5. 가끔 코드가 마음에 들지 않아 고치려고 보면 과거에 제가 짰던 코드였던 적이 종종 있습니다. 아마 지금 짜는 코드도 몇 년 후에는 같은 생각으로 고치고 있겠죠?ㅎㅎ 6. ZNG 개발을 무사히 완료해 실제 서비스되는 ZNG를 보고 싶습니다. 그리고 꾸준히 유지보수를 해야겠죠?ㅎㅎ 7. 개인적으로 브레인즈컴퍼니의 개발 문화에 대해서 굉장히 만족하고 있습니다. 코드 리뷰를 통해 개발자 관점에서 높은 수준의 코딩을 하기 위해 노력하고 있습니다. 직급에 상관없이 자기 의견을 내는데 자유로운 분위기가 형성돼 있으며 '논리, 설득력'을 중요시합니다. 만약 개발자로서 성장하기 위한 '진짜 개발 문화'를 느끼고 싶다면, 저는 자신 있게 브레인즈컴퍼니를 추천합니다! 1. 안녕하세요. 현재 개발 3그룹에서 일하고 있는 권오민이라고 합니다. 2. 차세대 개발에서 프론트엔드 부분을 담당하고 있습니다. 특정 화면이나 기능을 구현하고 버그를 고치거나 코드를 개선하는 등의 일을 합니다. 3. 입사 전에 경험했던 간단한 팀 프로젝트가 모니터링에 대한 것이었는데, 이를 계기로 모니터링 쪽에 관심을 갖게 됐고 운 좋게 브레인즈컴퍼니에 입사할 수 있었어요. 4. 같은 팀에 속한 분들이 성격도 좋으시고 그 덕분에 팀 분위기 자체가 밝은 것 같습니다. 또 하나의 프로젝트를 초기 단계부터 시작해 배울 점도, 성장할 수 있는 가능성도 높다고 생각합니다. 5. 제가 이전에 짰던 코드를 보고 의문을 가지거나 마음에 들지 않는다고 생각할 때입니다. 6. 과거의 저보다 나아지는 걸 목표로 합니다. 성장한 면을 억지로 찾는 게 아니라, 스스로가 자연스레 성장했다고 느낄 정도로 성장하고 싶어요. 7. 입사 후 처음에는 업무가 이해하기가 쉽지 않고 어렵게 느껴질 수도 있습니다. 하지만, 그렇기 때문에 배울 점이 많고 더 성장하며 앞으로 나아갈 수 있다고 생각합니다. 1. 안녕하세요, 긍정적인 사고로 도전하기를 좋아하는 이윤지입니다. 컴퓨터 공학부 졸업 후 교육회사에서 개발 업무를 5개월 가량했습니다. 새로운 도전을 하기 위해 브레인즈컴퍼니로 이직하게 됐습니다. 2. 브레인즈컴퍼니에서 APM을 개발하는 팀에서 근무하고 있습니다. APM은 어플리케이션의 성능을 관리하고 통제하는 모니터링 도구입니다. 초단위의 실시간 모니터링을 통해 정밀한 성능 감시 및 분석을 지원합니다. 웹서버 및 매니저와의 통신을 통해 web UI 모니터링 기능을 개발하는 업무를 하고 있어요. 3. 기사를 통해 회사에서 직원들을 진심으로 아끼고 존중하는 문화와 복지를 볼 수 있었습니다. 브레인즈와 같이 성장하며 회사를 즐겁게 다닐 수 있을 거 같아 지원했습니다. 4. 브레인즈컴퍼니는 수평적인 업무환경을 가지고 있습니다. 직원들이 자유롭게 의견을 개진하고 업무에 적극적으로 반영하는 분위기를 갖고 있어요. 5. 일을 하면서 스스로 만족스러운 코드를 작성했을 때 성장했다고 느꼈습니다. 6. 제니우스가 국내를 넘어 세계1위 모니터링 솔루션 회사가 될 수 있도록 노력하겠습니다. 7. 브레인즈컴퍼니에 지원하시는 모든 분들을 진심으로 응원합니다! 1. 안녕하세요, 소프트웨어학을 전공하고 웹개발 부트캠프 및 인턴과정을 거쳐 브레인즈컴퍼니 개발4그룹에서 근무하고 있는 김영욱입니다. 2. 브레인즈컴퍼니 로그매니저의 기능개발 및 유지보수 작업을 맡았습니다. 개발은 프론트엔드와 백엔드를 모두 진행했으며, 다양한 기술스택들을 배우며 로그매니저의 기능 개선 및 CC인증을 위한 사전점검 작업들도 진행했던 한 해였습니다. 이후에는 Zenius AI의 빅데이터 및 AI 개발을 하게 될 예정입니다. 3. 풀스택 기술뿐만 아니라, 빅데이터 및 AI 기술을 활용해 차세대 기술을 개발하는 브레인즈컴퍼니의 채용공고를 접했습니다. 이 회사에서라면 많은 것을 배워 역량을 키우고 성장하며 일할 수 있겠다는 생각에 지원했고, 면접 끝에 첫 직장에 취업하게 됐습니다. 4. 모든 그룹원분들께서 잘 다독여주시고, 좋은 피드백을 줘서 지속적으로 배워가고 성장할 수 있는 회사 및 부서라고 생각합니다. 그룹의 상래님, 신후님, 천웅님, 태민님 모두 제게 좋은 피드백과 도움을 주고 계세요. 개선돼야 할 점과 공부해야 할 부분, 그리고 개발을 하면서 고쳐야할 습관들을 알려주셔서 점차 앞으로 나아갈 수 있어요. 5. 최근 카프카, ELK 등을 통한 로그 분산처리 작업을 하면서 배우는 점이 많았는데, 시행착오를 겪으면서 성장하고 있다고 느꼈고 매우 뿌듯한 시기를 보냈습니다. 6. 백엔드 작업에서 아직 배울 점들이 많고 이러한 것들을 모두 제 것으로 만들어 어느 부분에서 문제가 생기더라도 그것을 해결할 수 있을 정도의 실력있고 도움이 되는 개발자가 되는 것을 목표로 하고 있습니다. 7. 점점 발전하고 있으며, 배우고 성장함에 있어서 무궁무진한 가능성을 주는 회사라고 생각합니다. 본인이 성장을 하고 싶고, 실력을 발휘하고 싶다면 주저없이 입사 지원을 해보는것을 추천드려요! 1. 안녕하세요 개발 2그룹 인프라웹팀에서 근무하고 있는 김청룡입니다. 대학에서는 경영학을 전공했고, 브레인즈컴퍼니가 첫 직장입니다. 2. 인프라웹팀 안에서도 여러가지 업무가 있지만 신입인 저는 주로 고객사에서 요청하는 커스터마이징 보고서를 개발하는 업무를 하고 있습니다. 커스터마이징 보고서 개발업무에 대해서 간략히 말씀드리면, Zenius는 여러 인프라 장비 혹은 서버의 데이터를 수집하고, 사용자가 수집된 데이터를 보고서 형태로 볼 수 있도록 기본 보고서 기능을 제공을 해주고 있어요. 그 외에도 사용자가 원하는 양식(요구사항)으로 수집된 데이터를 볼 수 있도록 보고서를 개발합니다. 3. 국비지원 학원에서 여러 기업에서 나와 소개를 해줄 때 가장 인상깊었어요. 다른 기업들과 다르게 기업에서 어떤 사업을 진행하는지, 채용 과정은 어떻게 되는지 등 상세하게 알려줘서 이 회사에 입사를 하고 싶다면 알아야할 것들을 전달 받은 느낌이 있었어요. 또, 업무적으로 대용량 데이터베이스를 빠르게 처리하기 위해 어떻게 노력하고 있는지 궁금해 지원하게 됐어요. 4. 브레인즈컴퍼니는 무엇보다 사람이 좋은 것 같습니다. 모두 각자의 역할에서 책임을 다하고 최선을 다하는 모습, 그리고 질문을 할 때도 최대한 도움을 주려고 하는 모습에서 느껴졌습니다. 5. 코드를 작성하면서 여러가지 경우를 생각할 때입니다. 처음 코드를 작성할 때는 절차식처럼 그저 생각나는 대로 작성했는데, 입사 후 작성된 코드를 보고 어떻게 잘 나눠야 하는지, 성능을 고려하면서 작성했는지 등 다양한 고민을 하고 있는 제 자신을 볼 때 성장하고 있다고 느꼈습니다. 6. 다방면으로 역량이 있는 개발자를 목표하고 있습니다. 7. 사람 좋은 기업을 찾는다면 브레인즈컴퍼니입니다!
2022.12.09
클라우드 송환(Cloud Repatriation): 클라우드에서 다시 온프레미스로
클라우드 송환(Cloud Repatriation): 클라우드에서 다시 온프레미스로
다시 온프레미스로 복귀하려는 움직임 2022년 발표된 IDC 조사 결과에 의하면, 미국 기업의 71%가 향후 2년내에 ‘클라우드 송환’ 계획이 있다고 합니다. 실제 일부 애플리케이션을 클라우드에서 빼내 자체 데이터센터로 다시 가지고 오는 기업이 늘고 있습니다. 우리나라의 경우 ‘클라우드 전환’이 업계의 화두가 되고 있지만, 클라우드 전환을 10년 넘게 경험하고 있는 미국의 경우에는 이제 ‘클라우드 송환’이 또 다른 화두가 되고 있습니다. 클라우드 송환(Cloud repatriation)은 기업이 클라우드 환경에서 운영하던 애플리케이션, 데이터, 서비스 등을 온프레미스 환경으로 되돌리는 것을 말합니다. 이는 퍼블릭 클라우드가 비즈니스 민첩성을 향상시킬 수 있지만, 특정한 상황에서 온프레미스보다 퍼블릭 클라우드의 지출 비용이 더 크다는 사실을 기업이 깨달으면서 해당 애플리케이션 등을 온프레미스로 복귀시키려는 IT 전략입니다. 클라우드 송환 현상은 IT 비용과 성능을 비롯한 여러 측면에서 클라우드가 항상 최선의 해결책은 아니라는 인식을 바탕으로 확대되는 추세이며 이제 기업이 비용, 성능, 보안의 극대화를 위해 기존 환경과 새로운 환경 사이에서 자연스러운 워크로드 분산을 시작했다는 의미이기도 합니다. 미처 몰랐던 클라우드 서비스의 문제점 클라우드를 채택한 기업이 클라우드 송환을 선택하는 이유는 다음과 같은 문제가 있기 때문입니다. 첫째, 클라우드 비용 문제입니다. 2022년 클라우드 현황(Flexera 2022 State of the Cloud Report) 보고서에 따르면, 클라우드 비용의 30% 정도가 낭비되고 있습니다. 클라우드 서비스가 표면적으로 내세우는 클라우드의 가장 큰 장점이 비용 절감임에도 불구하고, 클라우드 전환 OPEX(operational expenses)가 기존 CAPEX(capital expenses) 대비 더 낫다고 단정하기 어렵습니다. 초기에는 클라우드의 비용이 저렴하게 느껴지지만, 가상머신(VM)과 컨테이너 인스턴스에서 처리하는 작업이 늘어날수록 비용도 더해지기 때문입니다. 워크로드가 증가하는 스타트업은 클라우드를 통해 유연성을 확보하는 것이 비용면에서 유리하겠지만, 예측 가능한 수준의 워크플로우를 갖고 있는 기업이라면 얘기가 달라집니다. 특히, 클라우드에서는 인터넷 대역폭 및 스토리지 요금 등 추가적인 비용이 발생할 수 있습니다. 둘째, 보안 문제입니다. 기업은 클라우드 제공자가 제공하는 기본적인 보안 기능 외에도 보안 문제에 대한 책임을 직접 지게 됩니다. 또, 기업은 자체 보안 정책을 준수해야 하며, 이를 클라우드 환경에 적용하는 것이 쉽지 않습니다. 특히 복잡한 멀티클라우드 환경에서는 견고하게 클라우드 보안 아키텍처를 구축하기 어렵고 외주 처리에 따라 많은 비용이 듭니다. 셋째, 성능 문제입니다. 클라우드에서는 다른 기업과 리소스를 공유하기 때문에 성능 문제가 발생할 수 있습니다. 또, 클라우드 환경에서 애플리케이션 및 데이터를 조작하는 데 필요한 대역폭이 충분하지 않을 경우 성능 문제가 발생할 수 있습니다. 따라서 기업은 성능 문제로 인해 클라우드 송환을 선택할 수 있습니다. 넷째, 제어 문제입니다. 클라우드에서는 기본적으로 클라우드 제공자가 인프라 관리와 보안을 담당합니다. 이는 기업이 클라우드 환경에서는 많은 경우 애플리케이션, 데이터, 서비스 등을 직접 제어할 수 없다는 것을 의미합니다. 따라서, 기업이 직접 컨트롤하지 못해서 문제가 발생한다고 느낄 때에는 클라우드 송환을 선택할 수 있습니다. 클라우드 송환의 이점 클라우드 송환(Cloud repatriation)은 기업에게 여러 가지 이점을 제공합니다. 첫째, 기업은 애플리케이션, 데이터, 서비스 등을 직접 관리할 수 있습니다. 이는 기업이 보안 및 규정 준수와 같은 중요한 문제를 직접 다룰 수 있도록 해주며, 제어력을 높임으로써 IT 부서가 잠재적 문제에 대비해 인사이트와 더 나은 계획을 수립할 수 있게 해줍니다. 클라우드에서는 기본적으로 클라우드 제공 업체가 인프라 관리와 보안을 담당하기 때문에, 이를 직접 제어할 수 없습니다. 클라우드 송환에 적합한 케이스는 정적인 기능을 제공하며 사용량이 많은 애플리케이션입니다. 비용이 고정되고 예측 가능한 애플리케이션은 온프레미스 환경에서 관리하는 편이 더 효과적입니다. 둘째, 기업은 클라우드 비용을 절감할 수 있습니다. 한때 퍼블릭 클라우드가 모든 문제의 해답이라고 생각했다가 퍼블릭 클라우드의 비용 특성과 이점이 기업의 상황과는 맞지 않는다는 사실을 깨닫게 됩니다. 2~3년에 걸쳐 추가되는 비용을 감안하면 퍼블릭 클라우드를 계속 사용할 만한 매력은 시간이 갈수록 희석됩니다. 기업은 반복적으로 발생하는 클라우드 운영 비용을 줄이거나 없애는 방법으로 많은 비용을 절감할 수 있습니다. 예를 들어, 어떤 기업의 데이터가 여러 사이트에서 발생하고 그 양이 많다면 클라우드 환경에서 데이터를 보관하고 이동시키는 데 많은 비용이 발생할 수 있습니다. 또 다른 예로 영상을 불러오고 저장하는 작업이 빈번한 영상 제작 기업의 경우, 클라우드 서버에서 병목현상이 발생할 수 있고 내부 LAN처럼 10Gbps 속도로 데이터를 옮기려면 그 비용이 저렴하지 않을 수 있습니다. 비용 외에도 데이터 이동에 많은 시간이 소모되며 이로 인해 데이터를 필터링해 최소한의 데이터만 저장해야 하는 불편함이 있습니다. 한편, 메모리와 디스크 리소스 비용이 계속 하락하면서 기업의 온프레미스 투자가 유리해지고 있습니다. 더불어 클래스 메모리 및 SDN(소프트웨어 정의 네트워크)과 같은 비용에 도움을 주는 솔루션을 활용하면, 한때 퍼블릭 클라우드의 큰 매력이었던 유연성, 확장성, 중복성의 간극이 상당부분 사라집니다. 셋째, 기업은 데이터 보호와 백업을 더욱 쉽게 할 수 있습니다. 클라우드 업체도 데이터 프라이버시에 대해 엄격하지만 온프레미스 환경에서 데이터를 저장하고 백업 받고 복구하는 것보다 더 안전할 수 없습니다. 물론 민감한 정보를 로컬 환경에 저장하는 것 역시 문제 제기가 있겠지만 최소한 고객 데이터가 사라졌을 때 무엇을 어떻게 해야 하는지 알 수 있습니다. 규정 준수 측면에서도 각 국마다 개인정보보호 규정이 달라 우발적인 규정 위반 가능성이 있습니다. 이러한 우려를 줄이는 방법은 애플리케이션을 특정 위치의 온프레미스 환경에서 실행하는 것입니다. 넷째, 대역폭 문제에서 자유로운 장점이 있습니다. 클라우드 환경에서 빅데이터 시스템을 활용하는 기업은 빅데이터 시스템에서 생성되는 데이터가 높은 대역폭을 요구하면서 자사 데이터 센터보다 훨씬 더 많은 운용 비용을 지불합니다. 컴퓨팅은 온디맨드이므로 탄력적인 클라우드가 유리할 수 있지만 스토리지는 매일 매초 비용이 계속 증가하고 있는 사실을 알아야 합니다. 클라우드냐 온프레미스냐 고려할 점 클라우드 송환은 비용면에서 매력적이지만 매우 도전적인 과제입니다. 클라우드 서비스 공급자는 일반적으로 클라우드에서 빠져나오기 상당히 어렵게 계약하고, 해체됐거나 아예 존재하지 않던 온프레미스 환경을 준비하기 위해 기업의 재무와 조직 운영에 큰 영향을 미치기 때문입니다. 게다가 애플리케이션을 온프레미스 데이터센터로 마이그레이션하는 경우 기업은 클라우드의 확장성, 유연성, 가용성, 탄력성을 유지하기 힘들고 자체 데이터센터가 클라우드에 비해 더 안전하다는 보장을 하기도 어렵습니다. 따라서 이런 경우에는 애플리케이션에서 실행 중인 환경에 대한 종속성이 있는 부분과 단순히 데이터를 관리하는 부분을 분리하면 혼란을 최소화할 수 있습니다. 처음부터 클라우드 환경을 고려해 서비스를 설계했다면, 워크로드를 다시 데이터센터로 되돌리기 위해서는 어느 정도의 재설계가 필요하며 빅데이터에 의존하는 기업은 상당한 마이그레이션 작업을 각오해야 합니다. 이처럼 클라우드 송환은 매우 어려운 과제입니다. 따라서 처음부터 워크로드를 퍼블릭 클라우드로 이전하는데 매우 신중한 입장을 취하는 것이 가장 중요합니다. 그래서 최근에는 기업들이 클라우드 환경을 고수하는 것보다는 필요한 경우 클라우드와 온프레미스 환경을 융합하는 하이브리드 클라우드 전략을 선택하는 경향이 있습니다. 모든 서비스를 클라우드로 전환하는 것이 아니라, 단기간에 트래픽이나 사용자가 급속히 늘어날 가능성이 있거나, 클라우드 서비스를 활용해 서비스를 빠르게 런칭해야 하는 경우로 한정하는 것이 필요합니다. 우리나라에서도 많은 기업들이 이미 클라우드가 갖고 있는 단점들을 경험하고 온프레미스로 전환하고 있습니다만, ‘클라우드 전환’이라는 큰 물결 아래 ‘클라우드 송환(Cloud Repatriation)’에 대한 논의는 제한적입니다. 우리나라의 클라우드 전환율이 세계시장과 비교해 볼 때 현저히 낮지만, 오히려 클라우드 환경의 문제를 이미 경험한 나라들의 교훈을 미리 받아들인다면 학습비용을 줄일 수 있을 것으로 기대합니다. Zenius-EMS는 고객들이 레거시 시스템에서부터 클라우드 네이티브 시스템에 이르기까지 다양한 관점의 서버모니터링을 할 수 있도록 지원합니다. 대규모 인프라가 존재하는 데이터센터 및 클라우드 환경에서 대용량 데이터 처리에 대한 높은 성능을 확인할 수 있습니다. 고유의 특허 기술을 통해 수천대의 장비에서 발생되는 데이터들을 안정적으로 수집하고 빠르게 처리할 수 있습니다. [출처] John Edwards, "클라우드의 온프레미스 송환이 타당한 5가지 경우", IT WORLD, 2019.04.16 Steven J. Vaughan-Nichols, "모두가 '클라우드' 외칠 때 '로컬 서버' 선택해야 하는 이유, IT WORLD, 2022.07.27 Andy Patrizio, "기업 71%, 2년 이내 클라우드에서 온프레미스로 복귀할 것", IT WORLD, 2022.06.29 Clint Boulton, "'전진 위한 후퇴'··· 클라우드서 온프레미스로 송환하는 기업들", CIO Korea, 2020.03.30 Brian Adler, "Cloud Computing Trends: Flexera 2022 State of the Cloud Report", flexera, 2022.03.21
2023.04.07
다음 슬라이드 보기