기본 콘텐츠로 건너뛰기

컬럼: 전환기의 미들웨어

사보에 실었던 컬럼(2012년 4월호)을 블로그로 포스팅합니다.


한계가 컸던 웹서비스

지난 10여년간 컴퓨팅 패러다임을 바꿀 것으로 기대했던 흐름 중 하나는 웹서비스였다. 1998년 마이크로소프트 사에서 정의한 SOAP (Simple Object Access Protocol) 스펙에 기원을 둔 웹서비스는 마이크로소프트, IBM, BEA(지금은 Oracle에 인수됨) 3사의 엄청난 지원에 힘입어 국제 표준으로 자리잡았으며, 플랫폼과 프로그래밍 언어에 독립적인 XML의 장점과 원격 프로세스 호출(RPC) 아키텍처를 결합한 서비스 중심 아키텍처(SOA)라는 IT 패러다임을 만들었다.
하지만 웹서비스는 기대했던만큼 혁신적인 변화를 가져오지 못했다.
기업은 웹서비스 도입을 꺼려했고, 컨설팅 주도로 부풀려진 SOA 아키텍처는 기대했던 유연성과 확장성을 가져오지 못했다.
오히려 성능 저하, 처리 능력 저하, 하드웨어 비용 증가의 문제를 일으켰다.
웹서비스의 실패와 이에 따른 SOA 기피 현상은 기업 주도로 만들어진 인위적인 새로운 흐름의 문제점을 보여주었다.
가장 큰 문제는 CPU 과다 사용이었는데 XML 자체의 파싱 오버헤드도 있었지만 SOAP 규격이 정의한 Enveloping 오버헤드 문제, XML namespace 규격의 불필요한 prefix 오버헤드 문제 등 표준 규격 진행 과정에서 성능을 고려하지 않은 부분들이 스스로의 한계를 규정하고 말았다고 볼 수 있다.

클라우드 컴퓨팅

뜬구름 같은 이야기, 클라우드 컴퓨팅은 웹서비스의 한계를 여러 측면에서 반성하면서 탄성 있는 확장성과 관리 비용 절감 등을 내세우며 아마존, 구글과 같은 웹 중심 기술 기업에서 구현하여 제시하고 있는 새로운 컴퓨팅 스택이다.
클라우드 컴퓨팅은 컴퓨팅 리소스의 위치에 따라 public cloudprivate cloud로 구분할 수 있다. Public cloud의 영역에서는 주로 일반인 대상의 서비스들을 제공하는 기업들이 이미 많이 활용하고 있다. 특정 기업의 컴퓨팅 구현을 위해 기업 내부에 구축하는 클라우드인 private cloud는 아직 도입을 검토하는 단계로 적극적으로 도입하기에는 장점이 아직 뚜렷하지 않다.

미들웨어, 프레임웍, 언어

흔히 국내에서 WAS(Web Application Server)라고 부르는  Java EE 호환 애플리케이션 서버는 웹 서버, 원격 프로세스 호출, 메시징, 트랜잭션 서비스 등의 기능을 갖춘 미들웨어이다.
미들웨어는 복잡한 트랜잭션 기능이나 분산 환경 처리를 프로그램 개발자가 알 필요가 없도록 대신 처리를 해주며, 이에 따라 개발자는 미들웨어가 제공하는 프로그래밍 모델에 따라 비즈니스 로직에 집중하여 개발하면 된다. , 복잡도가 높은 부분을 별도 계층으로 분리하여 개발 비용을 낮추고 또 안정성을 높이는 솔루션이다.
개발자가 감당해야 할 프로그래밍 복잡도를 낮추기 위해서 복잡도가 높은 계층을 대신 수행해주는 미들웨어 외에도 모듈 구성 및 관리를 쉽게 해주고 개발 생산성을 향상시켜주는 역할을 하는 요소로 프레임웍과 프로그래밍 언어를 들 수 있다.
프레임웍은 미들웨어의 한 종류이면서 주로 프로그래밍 모델을 개선하고 미리 준비된 패턴을 제공함으로써 개발자가 비즈니스 로직 외의 부분들 즉, 데이터베이스나 컴퓨팅 리소스 처리 부분까지 감춰주는 기능을 제공한다.
프로그래밍 언어 역시 좀더 개발자가 의도하는 부분을 간결하게 표현할 수 있는 방향으로 발전하고 있으며, 여러 가지 함수형 언어(functional language)가 등장하여 10여년간 최고의 대중적인 언어 자리를 지켜왔던 자바를 위협하고 있으며, 자바도 언어의 간결성을 개선하고 함수형 언어나 스크립트 언어의 장점들을 받아들이는 방향으로 변화하고 있다.

확장성 (scalability)이 변화의 핵심 화두

애플사의 iPhone 등장 이후 폭발적으로 스마트폰이 보급되고 있으며, 점점 더 많은 기기들이 컴퓨팅 능력을 갖추면서 다양한 IT 서비스의 소비 기기가 되고 있다. 스마트폰 대중화 이전 시점과 비교하면 추후 5년 이내에 최소 열 배의 클라이언트들이 IT 서비스를 더 이용하게 될 것이라고 볼 수 있다.
휴대성이 좋은 기기들은 IT 서비스 접속 가능 시간도 기존의 데스크탑에 비해 훨씬 자주 접속할 수 있게 된다. 유통되는 정보의 양도 접속 시간과 접속 기기의 증가에 따라 훨씬 더 늘어나게 될 것이다.
현재에 비해 유통되는 정보의 양도 최소 열배 정도 늘어난다고 예측할 수 있다. , 제공해야 할 서비스가 열배 정도 늘어난다고 예측할 수 있다.
그렇다면 미들웨어가 감당해야 할 트랜잭션의 양은 접속점 10, 서비스 10배의 용량을 제공해야 하므로 같은 시간 내 약 100배 정도 늘어날 것이라고 어림잡을 수 있다.
CPU 등 하드웨어 기술의 발전으로 향후 5년 내에 약 5배 정도의 용량 개선을 기대할 수 있다고 보면 미들웨어가 지금 시점에서보다 최소 20배 정도의 용량을 더 처리할 수 있는 아키텍처를 제공해야 하는 셈이다.
다시 말하자면 지금 active/active 방식의 2대 서버로 제공하는 서비스들 중 일반 모바일 기기에까지 노출된 서비스들은 5년 후에는 하드웨어를 신규로 교체한다고 하더라도 최소한 20~30대의 서버군으로 증설하여 제공해야 한다는 단순 결론을 얻을 수 있다.

이러한 변화의 시대에서 확장성(scalability)이 화두가 되는 것은 어떻게 보면 당연하다. 클라우드 컴퓨팅을 기업 IT 환경에 적용하려고 하는 시도가 그다지 무리한 시도로 보이지 않는 것이다.

하지만, 현재의 클라우드 컴퓨팅 구현 방식은 기존의 프로그래밍 모델과 다른 모델을 요구하는 어려움을 안고 있다.
, 기존 프로그래밍 모델이 대화형 상태를 유지하는 상태유지형(stateful) 모델이었다며 클라우드 컴퓨팅은 상태독립형(stateless) 모델을 요구하는 경향이 있다.
좀더 효율적으로 대량의 증설을 실현하기 위한 프로그래밍 패러다임의 변화 요구인 셈인데 이것은 미들웨어가 감당해왔던 기반 아키텍처의 복잡성을 프로그래머에게 감추는 역할과 상충하는 측면이 있다. 이외에도 대량의 데이터를 분산 환경 하에서 효율적으로 처리하기 위해 RDBMS 보다는 컬럼 기반의 데이터베이스를 선호하는 경향이 있다.
이러한 프로그래밍 모델에 대한 변화 요구를 감춰주거나 완화시키는 것이 미들웨어 계층에서 해결해야 할 중요 과제로 보인다.

Java EE 미들웨어의 변화

자바 기반 미들웨어인 WAS는 표준화되고 대중적으로 개발자들을 폭넓게 확보하고 있는 미들웨어이다. WAS의 표준 스펙인 Java EE는 버전 7에서 클라우드 환경에서의 표준 미들웨어로 자리잡기 위한 기능 명세 정의를 시도하고 있다.

PaaS(Platform as a Service)라는 클라우드 컴퓨팅 미들웨어 스택에 적합한 표준으로 만들려는 시도부터 클러스터링과 배포 관리, 계측 기능 등을 클라우드 환경에 맞게 확장할 수 있도록 정의하고 있다. 또 자바 언어의 간결성을 강화하고 함수형 언어 기능을 포함하려는 시도를 계속하고 있다.

반면 클라우드의 기본 프로그래밍 모델인 stateless 패러다임이나 리소스 중심 아키텍처(ROA)를 보다 직접적으로 지원하기 위한 기능은 포함하고 있지 않으며, 기존의 Servlet, EJB, JMS 기능은 적어도 지금의 클라우드 컴퓨팅 모델과 매우 잘 맞지는 않는다.
현재는 이러한 부분을 Java EE가 아닌 별도의 프레임웍 솔루션들에서 제공하고 있다.

이외에도 자바는 가상 기계(Virtual Machine) 기반의 실행 모델을 갖고 있어서 대량의 메모리를 사용할 때 가비지 컬렉션의 오버헤드가 매우 커지는 기술적 문제를 가지고 있다. 실시간성으로 대량의 트랜잭션 처리가 필요한 금융권이나 제조업쪽으로 영역을 확장하기 위해 해결해야 할 과제를 안고 있는 셈이다. 이를 해결하기 위해 Java VM 차원에서 실시간성을 강화하는 노력을 몇몇 기업에서 시도하고 있다.

JEUS, t-Cloud

Java EE 버전 6를 만족하는 JEUS 7은 클라우드 환경을 준비하는 첫번째 JEUS 버전이 될 것이다. 동적인 클러스터링 증설부터 더 많은 수의 클러스터 노드를 효율적으로 지원하기 위한 도메인 아키텍처를 채택하는 큰 변화가 있으며, 그외에도 여러 가지 개발 편의와 효율 개선을 위한 기능들이 추가되었다.
앞으로도 JEUS는 현재 미들웨어의 한계를 극복하고 미래를 준비하는 새로운 기술들을 적극 개발하여 제품에 반영할 것이다.
JEUS 외에도 대용량 트랜잭션의 시대를 능동적으로 이끌어가기 위한 t-Cloud 전략을 수립하고 정련하여 제품 포트폴리오에 반영하는 일들을 진행중에 있다. 대량 증설의 복잡성을 미들웨어와 프레임웍을 통하여 감추고, SOA 프로그래밍 패러다임을 받아들이는 과정에서 웹서비스란 프로토콜 한계에 집착하지 않았던 독창적 혜안을 변화하는 패러다임에 엄격하고 창의적으로 적용하고 있다.

댓글

이 블로그의 인기 게시물

[Java] Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다.

일단 생소하기 때문에 어렵다.

그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다.

먼저 G1GC를 이해하는 데 유용한 사이트이다.

Garbage-First CollectorGetting Started with the G1 Garbage CollectorUnderstanding G1 GC LogsTuning Garbage Collection for Mission-Critical Java ApplicationsControlling GC pauses with the GarbageFirst CollectorG1: One Garbage Collector To Rule Them AllGarbage First (G1) Garbage Collection Optionscompare JVM options for public메일 : G1 GC clean up time is too long
JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다.
(새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.)

지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다.
즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다.
앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다.

둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한 처리는 아직 최적화되지 않았다. 보통 한 region의 50% …

[Java] Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class…

맥북프로 13인치 2010년 버전의 하드웨어 업그레이드 산전수전 경험기

혼돈의 시작
2010년에 구입한 맥북프로 13인치.

메모리 4GB,  하드디스크 256GB

2013년에 맥북프로 레티나 13인치를 사면서 아내와 딸이 함께 구형 맥북프로를 사용했다.

2016년에 또다시 맥북프로 레티나 13인치를 딸에게 사주면서 버려질 위기에 처한 맥북프로를 아내가 논문 작성용으로 쓰고 싶다고 해서 고민하다가 하드웨어 업그레이드를 결심.
메모리를 좀 늘리고 HDD를 SSD로 바꾸면 충분히 빨라질 것이라고 당연한 판단.

먼저 여기저기 뒤져서 애플에서는 공식 지원하지 않는 맥북프로 업그레이드 방법을 찾아냈다.
기종을 정확하게 아는 게 핵심.
우리 집 맥북프로의 공식 버전명은 MacBooPro 7.1 혹은 MacBook Pro Mid 2010 이었다.

먼저 메모리를 찾아봤다. 16GB까지 업그레이드 가능하다는 주장도 있었으나 주장들이 좀 엇갈려서 안정적으로 4GB 두 개 즉, 8GB로 업그레이드하기로 했다.

8.0GB OWC Memory Upgrade Kit - 2x 4.0GB PC8500 1066MHz 204 Pin (gmarket에서 9만 2천원. 배송비 포함)

다음은 HDD를 대체할 SSD.
이것도 여기저기 찾아봐서 호환이 확실히 되는 걸 찾았다.

MICRON Crucial MX300 275GB SSD (gmarket에서 9만 7천 2백원. 배송비 포함)

한국에서 구매하는 방법은 G-Market 뿐이었던듯.
아마존은 대부분 한국에서는 구매할 수 없는 곳 뿐이었다.

그리고, 마지막으로 맥북을 분해 조립하기 위한 드라이버들.
메모리와 HDD 교체에 필요한 드라이버는 작은 십자 드라이버 하나였다.
(하지만, 종류별로 다 구매했다는 ㅠ_ㅠ 나중에 나오지만 배터리를 교체하려면 Y자 드라이버도 필요하다. 드라이버는 한 개당 gmarket에서 1800원 정도.)

2016년 8월 10일
자, 이제 20만원 가까운 금액을 gmarket에 입금!

2016년 8월 24일
주문한 부품들이 도착한 것은 2주 후

분해와 조립, 무한 반복...
이제 이 맥북도 곧 날라다니겠…