'XML'에 해당되는 글 2건

  1. 2008.05.11 SOA의 허상 (14)

SOA의 허상

컨설팅이야기 2008.05.11 15:03 Posted by 5throck
일본 애니메이션 공각기동대를 보다 보면 주인공인 “모토코”가 정보처리를 위해 다른 시스템을 연결해서 사용하는 것이 나옵니다. 대규모 연산을 위해서 자신의 컴퓨터에서 처리하는 것이 아니라 다른 컴퓨터에서 연산을 돌려서 그 결과를 받는 병렬/분산처리를 하는 것이죠. 실제로 이런 장면은 애니메이션에서만 나오는 것은 아니고 미드인 "24시"에서도 대규모 연산을 위해 다른 시스템의 사용허가를 받고 그 자원을 이용해서 연산을 처리하는 장면들이 나옵니다.

이것이 요즘 IT업계에서 회자되고 있는 SOA 개념과 상당히 유사한 점이 많은데, 실제로 SOA의 개념을 이용해서 시스템을 구현해 보시면 아시겠지만, 이를 실제 업무에 적용하기에는 상당한 어려움이 존재합니다. 드라마나 애니메이션에서 대규모 데이터가 병렬/분산으로 쉽게 처리되는 것과 다르게 특수한 환경이 아닌 경우를 제외하고는 이런 처리를 하기 위해서는 상당한 노력이 동반되기 때문입니다.

대규모 연산의 경우는 그래도 좀 분리하기가 쉬울 수 있겠지만, 다량의 데이터를 처리해야 하는 경우에는 상당한 량의 데이터를 각 서버에 보내야 하고, 이들 서버에서 처리되는 것을 받아서 통합 처리해야 하는 엄청난 일을 해야 합니다. 또한, 이런 일들을 자신의 모바일 장비에서 간단한 조작으로 가능하기 위해서는 대규모 데이터를 저장하고 있는 서버와 이를 처리를 위한 미들웨어 그리고 데이터들을 자연스럽게 흘릴 수 있는 데이터 통신 표준 및 코딩방식 등이 정해져 있어야 한다는 것입니다.

EDI vs. XML - 최신의 기술만이 항상 최고는 아니다

하지만, SOA 기반의 미들웨어는 XML 기반으로 데이터를 처리하는 관계로 기존의 Structure 형태를 띠고 있는 EDI에 비해 현저한 성능저하가 발생합니다. 따라서, 벤더들은 이러한 문제를 해결하기 위해 Parsing을 전문적으로 하는 서버의 설치를 권하기도 하는데, 이는 근본적인 문제를 해결하는 것이기보다는 문제를 악화시킬 가능성이 더 높습니다. (댓글에서 Tuna님이 말씀하신 것처럼 저도 대규모 데이터 처리 시에는 XML보다는 CSV 방식으로 저장된 데이터를 이용하여 처리하는 것이 바람직하다고 생각하고 있으며, 이러한 처리는 SOA 기반 미들웨어에서도 가능합니다.)

게다가 한국은 전문을 트랜잭션 단위로 처리하기보다는 배치성으로 처리하는 경우가 많기 때문에 SOA 기반 미들웨어들이 대규모 데이터를 처리해주어야 하지만, 이를 SOA 미들웨어에 보낼 경우 한번에 처리할 수 있는 데이터의 양이 보잘 것 없어서 처리하기 힘들 때가 많은 것 같습니다. 게다가 한번에 보내는 전체 전문의 양이 2MB를 넘는 경우 서버에서 처리를 못하고 문제가 생기는 경우도 많이 봐왔고, 이런 문제가 발생할 경우 “울며 겨자 먹기” 식으로 한번에 보내는 데이터의 양을 조절해야 하는 황당한 경우가 발생하는 경우도 있는 것 같습니다.

SOA 개념은 정말 좋지만 그걸 하기 위해서 얼마나 많은 인터페이스와 시스템을 바꾸어야 하는지 한번쯤 고민을 하시고, 그렇게 해도 문제가 없다는 생각이 드신다면 그 때 SOA 선택을 해서 도입을 하셔도 늦지 않을 것이라고 생각합니다.
신고

'컨설팅이야기' 카테고리의 다른 글

지진피해와 중국 포털  (2) 2008.05.20
Daum UI Devday 행사  (4) 2008.05.18
SOA의 허상  (14) 2008.05.11
RSS 번역 서비스  (4) 2008.05.11
총잡이와 농부  (0) 2008.05.10
IT와 구조조정  (6) 2008.05.05

댓글을 달아 주세요

  1. Favicon of http://calmglow.egloos.com BlogIcon calmglow  수정/삭제  댓글쓰기

    안녕하세요. 음. 옳으신 말씀입니다. 그런데 SOA라기 보다는 그림에서도 지적하셨지만 잘못된 ESB(SOA기반 미들웨어)사용으로 인한 폐해가 주제가 아닐런지요?

    2008.05.11 01:01 신고
    • Favicon of http://mbastory.tistory.com BlogIcon 5throck  수정/삭제

      지적하신 부분이 맞습니다. SOA는 이론적인 이야기이지요. 다만, 그걸 엉뚱하게 팔고다니는 벤더들의 이야기들을 하려다보니 제 이야기가 좀 와전이 된 부분이 있긴 한 것 같습니다.

      2008.05.11 01:09 신고
  2. Favicon of http://xacdo.net BlogIcon xacdo  수정/삭제  댓글쓰기

    1. XML 파싱을 하면 그냥 소켓통신 하는 것보다 10배는 느려지죠.
    2. 대신에 미들웨어를 사용하면 개발속도가 빨라집니다. 2년 걸릴 프로젝트를 6개월에 끝낸다던가.
    3. 매년 컴퓨터의 성능이 2배씩 증가한다면, 2^3 < 10 < 2^4 니까 3~4년 안에 속도문제는 해결되겠죠.

    2008.05.11 07:47 신고
    • Favicon of http://mbastory.tistory.com BlogIcon 5throck  수정/삭제

      말씀하신대로 미들웨어를 사용하면 개발속도는 빨라질 수 있을 것 같습니다. 다만, 그걸 해결하기 위해서는 엄청난 서버 자원이 필요한데, 결국에는 개발자 단가와 서버비용간의 Break-Even Point가 되는 시점이 바로 SOA가 활성화되는 시점이 될 것 같습니다.

      2008.05.11 10:16 신고
  3. Favicon of http://blog.empas.com/seachicken/ BlogIcon Tuna  수정/삭제  댓글쓰기

    제 생각엔, 위의 글은 병렬처리 내지는 분산컴퓨팅에 대한 얘기이지 SOA에 대한 얘기가 아닙니다. 죄송하지만 위의 글만으로는 5throck님이 SOA에 대해 저와는 틀린 이해를 하고 계신듯 합니다.

    5throck님의 표현대로 SOA를 사용하고자 한다면 필요한 계산을 수행하기 전에 먼저 여러곳에 분산되어 있는 컴퓨터에 특정한 서비스를 배치(인스톨? 디플로이? 로딩? 뭐가 되든..)해야 합니다만 그건 SOA에서 말하는 One place one function이란 개념의 서비스와는 틀린, 단지 부하분산, 복수의 시스템 자원의 보다 유효한 활용을 위한 분산컴퓨팅의 얘기이지 SOA와는 아무런 상관이 없습니다. 필요한 계산기능이 너무나도 범용적인 기능이라 대부분의 시스템에 디폴트로 인스톨되어 있는 서비스라면 또 다른 얘기겠습니다만...

    그 후에 말씀하신 대량의 데이터 처리에 있어서의 비효율성은 XML이란 데이터포맷의 문제이지 SOA의 문제가 아닙니다. 아마도 'SOA의 도입 = XML의 사용'이라는 전제하에 글을 진행하고 계신 듯 하지만, (그리고 그게 일반적인 사례이기도 하지만,) 그건 SOA의 본질을 이해하지 못한 대중의 오해라고 생각하고 있습니다.(아직 역사가 짧은 SOA이고, 실체가 아닌 컨셉의 문제이기에 어쩔 수 없는 일이라고는 생각합니다만.. )
    실제로 제가 참가한 SOA 프로젝트에서는 서비스를 이용하되 일부 서비스의 데이터포맷은 CSV 내지는 바이너리를 사용하는 경우도 있습니다. 제 말은, SOA라는 '시스템 구축에 있어서의 개념(컨셉)'은 XML이란 데이터포맷과는 비의존적인 얘기라는 것입니다.

    XML은 범용성과 호환성, 가시성을 중시한 데이터포맷이지, 데이터처리의 효율성을 중시한 데이터포맷이 아님을 이미 잘 아실 것입니다. (그리고 그건 위 본문에서 링크해 주신 다른 글에서 이미 잘 설명을 하고 계시구요.) 즉, 태생부터 비교대상이 아닌 것을 비교하고 계신 듯 합니다. (물론 이 차이를 이해하지 못하는 사람들에게 잘 이해하고 적용하라..는 말씀으로 이해했습니다. ^^)

    또하나, 배치작업에 대해 말씀하셨는데, 기존의 시스템에서의 배치작업들이란 비지니스적인 요건에 의해서가 아니라 시스템의 제약에 의해 배치작업화된 것들이 많습니다. 즉 기존의 모습이 지켜내야 할 '선'이 아니라 고쳐가야 할 '악'일 수도 있다는 얘기입니다. 기존의 모습에 맞지 않는다고 무조건 부정하는 것은 옳지 않다고 생각합니다.

    SOA는 기본적으로 실시간성을 중요시하고 있습니다. 따라서 SOA를 검토하실 때는 그런 배치작업을 그대로 서비스화 할 것을 검토하는 것이 아니라 그 배치작업이 정말 배치작업이어야 하는 것인가 하는 당위성부터 검토해야 할 것으로 보입니다. (기존의 처리방식을 그대로 두고 서비스라는 가면만 덧씌울 것이라면 쓸데없이 SOA 따위 도입할 필요도 없습니다. 저같이 벤더에 있는 넘 배 불리려는 목적이 아니라면... ^^;;)

    기존의 배치작업이 비지니스적인 요건에 의한 것이라면 당연히 그에 걸맞는 대응-그냥 배치로 두거나, EDA형식을 적용해 리팩토링을 하거나-을 해야 하겠지만 그것이 과거의 시스템적인 제약에 의해 그리 된 것이라면, 그래서 비지니스의 발목을 잡고 있다면, 당연히 실시간형 서비스로 이행할 것을 검토해야겠지요. 그리고 그 순간 그것은 더이상 배치처리가 아니게 됩니다. (즉, 대용량 데이터의 문제는 없어지게 될 확률이 높습니다.) 무언가 새로운 개념을 도입한다는 것은 문제의 개선을 위한 것이지 기존의 것을 지키기 위함이 아니죠.

    물론 기존의 인터페이스와 처리방식을 한순간에 바꾸는 것은 현실적으로 어려운 일이므로 그에 대한 로드맵을 작성해서 순차적으로 이행해 가야 할 것이며 그게 바로 SOA를 도입하는 아키택트나 컨설턴트들이 해야 할 일이겠지요.

    위에서 산발적으로 적은 난문을 정리하자면,
    - 병렬처리 내지는 분산처리와 SOA는 개념이 틀린 것이라는 것
    - 대용량 데이터의 처리에 적합하지 않은 것은 엄밀하게는 SOA가 아니라 XML이라는 것
    - 배치작업의 처리능력이 떨어지는 것을 SOA의 문제로 치부할 것이 아니라, SOA의 적용방법 내지는 적용하려는 장소가 잘못되지 않았는가를 먼저 생각해 볼 것.(즉, 정말 배치작업으로 처리해야 할 것이라면 무조건적으로 SOA를 들이댈 게 아니라 다른 컨셉(예를 들면 EDA?)을 검토할 것. SOA도 만능의 칼은 아니므로.)

    ... 정도가 되겠네요. 제 얘기에 오류가 없다면, 적어도 5throck님의 글 제목인 'SOA의 허상'은 본문 내용과는 조금 안 맞는 타이틀이라고 보입니다.

    PS: 참고로, 위 본문에 포함된 카툰은, SOA라고 적인 거대한(?) 박스의 이름을 ERP 내지는 IT업계의 다른 무엇의 이름으로 바꾸어 적어도 그대로 의미전달이 되겠지요. 즉 위 카툰은 IT업계의 거품과 잘못된 관행을 꼬집는 것은 될 수 있어도 SOA에 국한된 얘기는 아닐 수도 있다는 생각입니다.
    PS2: 혹시나 하는 마음에 미리 말씀드리자면, 전 SOA에 관련된 일을 하지만 SOA빠는 아니라고 밝히고 싶습니다. 그냥 있는 그대로 보자...는 주의입니다.오히려 최근엔 여러가지 회의감을 가지고 있다는...

    2008.05.11 08:31 신고
    • Favicon of http://mbastory.tistory.com BlogIcon 5throck  수정/삭제

      제가 밤 늦게 정신 없는 상태에서 포스팅을 하다 보니 개념을 혼동한 부분이 있는 것 같습니다. 지적하신 대로 병렬을 병렬/분산으로 수정하는 것 맞는 것 같아 수정을 하도록 하겠습니다.

      다만, 일반적으로 SOA 기반 미들웨어들이 표준 데이터 포맷을 XML로 정하고 다른 포맷들을 부가적으로 지원하는 형태로 구성이 되어있기 때문에 XML이 대용량 데이터 처리에 부적절하다는 것은 모순이 있다고 생각합니다. 또한 그것이 사실이라면 벤더들이 주장하는 SOA 기반의 미들웨어에서 대용량 데이터 처리가 가능하다는 표현은 삭제가 되는 것이 마땅하겠지요. 그런데, 어떤 벤더도 그런 이야기를 고객들에게 진솔하게 하지 않더군요. 그런 관점에서 제 이야기를 봐주시면 좋을 것 같습니다.

      또한, 말씀하신 대로 XML이 가지고 있는 가장 큰 장점이 유연성인데 대규모 데이터 처리를 위해서 그것을 포기한다면 굳이 SOA를 사용할 이유는 없을 듯 합니다. 그럴 바에는 차라리 기존의 EDI형태의 인터페이스를 그대로 유지하는 편이 유지보수 측면이나 투자 측면에서 더 좋을 것 같다는 생각이 듭니다.

      장문의 댓글과 좋은 지적에 감사 드리며, 좋은 연휴 되시길 바라겠습니다. =;-)

      추신: 제 글의 제목을 풀어서 쓴다면 "벤더들이 주장하는 SOA의 허상" 정도가 될 것 같고, 제목을 정할 때 너무 긴 것 같아 앞부분을 생략한 것이라고 봐주시면 될 것 같습니다. ^^

      2008.05.11 15:01 신고
  4. Favicon of http://blog.naver.com/mycogito BlogIcon MyCogito  수정/삭제  댓글쓰기

    TUNA님과 5throck님의 의견이 모두 좋은 생각들이라 많은 도움이 된 것 같습니다. 특히 제가 최근 고민하고 있는 서비스가 분산처리를 통한 서비스 제공이라서 이런저런 참고가 된 것 같습니다.

    짧은 지식으로는 SOA는 서비스를 제공하는 것을 중심으로 아키텍쳐를 구성하는 것이기 때문에 굳이 SOA가 대규모 데이터 처리를 위해서 존재하는 것은 아니라고 생각됩니다. 오히려 지금 5throck님이 말씀하시는 것은 SOA라기 보다는 EAI 툴들에 대한 이야기가 아닌가 하는 생각이 듭니다.(SAP의 XI같은...)

    SOA의 가장 쉬운 예로 드는 것들이 SOAP을 기반으로 해서 각 영화 사이트에서 영화예매 정보를 가져와서 보여주는 것들이 아닌가 합니다. 이런 것은 굳이 대용량 데이터일 필요도 없겠지요. 하지만 SOA기반으로 설계의 개념이 들어가야 한다고 봅니다.

    TUNA님이 지적하신대로 대용량의 데이터를 처리하는 서비스가 있다면 이야기는 다르겠지만 그 문제가 굳이 SOA를 쓰느냐 마느냐의 문제는 아니라고 봅니다.

    그리고 유연성이야기를 듣고 보니 떠오르는 생각은 서버의 비용 증가만 고려할 것이 아니라 유연성이 생김으로서 얻는 유지보수 비용의 절감도 생각해야할 것 같습니다. 현장에서 일하다 보면 오래전 만들어진 EDI 등에서 문서화 등의 부재라는 문제가 있긴 하지만 담당자가 바뀌거나 없어지면 프로그램을 처음 부터 다시 다 보고 수정해야 하거나 재개발 하는 경우도 많고 데이터 구조만 바꾸면 해결될 것도 읽는 위치나 데이터 타입 등이 변함으로해서 추가적인 프로그램 변경도 많이 일어나기 때문에 유연성에서 오는 적지만 유의미한 비용 절감도 고려할 필요는 있다고 생각됩니다 ^^

    2008.05.14 13:34 신고
    • Favicon of http://mbastory.tistory.com BlogIcon 5throck  수정/삭제

      잘 지내시죠. ^^ 일반적으로 대용량이라고 말을 할 때는 2가지 의미가 내포되어 있는 것 같습니다. 하나는 개별 데이터의 양이 많은 경우와 다른 하나는 트랙잭션의 건수가 많은 것을 말합니다.

      SOA의 경우는 후자의 경우를 대상으로 만들어졌고 EAI는 전자의 경우를 대상으로 만들어졌다고 생각하시는 것 같은데, 실제 SOA에는 2가지 경우 모두를 포함하게 되어 있다고 생각합니다.

      예를 들어 어떤 서비스에서 파일 등과 같은 문서 첨부를 허용해야 한다면 대용량이 될 것이고, 예를 드신 영화예매와 같은 경우는 많은 트랜잭션 처리를 의미하는 것 같습니다. 따라서, SOA가 2M이상의 대용량(?) 데이터를 처리하지 못한다면 원래의 서비스 개념에 충실하지 못한 부분이 있다고 생각합니다.

      또한, 문서화의 부재는 SOA로 해결될 문제라기보다는 IT에 대한 관리개선의 문제라고 생각하기 때문에 SOA를 도입한다고 해서 쉬워질 것이라고는 생각하지 않습니다.

      2008.05.14 23:59 신고
  5. mycogito  수정/삭제  댓글쓰기

    많이 바빠졌지만 잘 지내는 편인 것 같습니다 ^^

    SOA에 대해서 지적하신 점 고민해 보아야 할 것 같습니다 ^^ 좀 더 깊은 통찰의 기회를 가지게 된 것 같습니다. ㅎㅎ

    문서문제도 지적하신 것처럼 SOA를 한다고 해결되진 않겠지요. 관리의 수준이 좋아져야 할 것 같습니다.

    2008.05.14 21:55 신고
  6. Favicon of http://yuzi.egloos.com BlogIcon YUZI  수정/삭제  댓글쓰기

    여하간에... 하단의 카툰은 정말 재미있군요.!!!

    2008.05.15 10:13 신고
  7. Favicon of http://benelog.egloos.com BlogIcon benelog  수정/삭제  댓글쓰기

    안녕하세요.
    XML웹서비스를 쓰는 경우라도 잘 구현하면 일정한 메모리양으로 무한정한 용량처리가 이론적으로는 가능할 것입니다. 아마 문제를 일으킨 모듈은 파싱한 객체를 메모리에 한꺼번에 쌓는 방식일 것으로 예상됩니다.

    예를 들어 XML웹서비스라도 결국은 Http연결이고 이것은 InputStream으로 바꿀수 있으니 SAX나 StAX방식의 처리라면 XML조각을 읽을 때마다 DB에 바로 넣어줄 수 있을 것 같습니다. 아니면 일단 받은 내용을 파일로 쓴 다음에 그것을 Stream으로 읽어서 파싱할 수도 있을 것입니다. 아랫단에서 제공되어진 모듈에 이렇게 구현된 것이 없다면 손이 더 가는 작업이기는 하겠습니다.

    아뭏든 CSV에 비해 더 많은 메모리 소모량, 더 늦은 속도이겠지만 XML처리라고해서 파일용량에 비례해서 더 많은 메모리가 있어야하는 용량제한이 있는 아닌데, 혹시나 오해가 될까봐 사족을 덛붙였습니다~

    그래서 XML은 대용량 처리에 적합하지 않다는 말보다는 대용량 고속처리에 적합하지 않다는 표현이 더 적절하다고 생각됩니다.

    2008.05.22 11:13 신고
    • Favicon of http://mbastory.tistory.com BlogIcon 5throck  수정/삭제

      안녕하세요... ^^ 잘 지내시죠?

      말씀하신대로 처리를 하면 이론적으로는 일정한 메모리 양으로 무한정한 용량처리가 가능할 듯 합니다. 다만, 그렇게 했을 경우에는 DB처리를 위해서 상당기간 기다려야 해서 속도의 저하가 많이 발생할 것 같고, 아마도 그런 이유 때문에 SOA 기반 미들웨어 패키지 개발업체에서 고려하지 않았던 것 같습니다.

      또한, XML 파일의 경우에는 스트럭처를 이용한 데이터 처리방식과 다르게 소스에 대한 파싱이 필요해서 스택 메모리를 사용해야 함으로 메모리를 좀 더 사용할 것 같습니다. ^^ 게다가 XML 구조가 복잡할 경우에는 스택 메모리를 더 사용할 것 같구요...

      너무 오랫동안 프로그래밍을 안한 관계로 기억이 좀 가물가물한데 제 생각이 맞나요? ㅎㅎ

      2008.05.22 23:19 신고

카테고리

나누어보기 (617)
스타트업 & 벤처 (15)
컨설팅이야기 (239)
MBA이야기 (39)
CC Korea 이야기 (36)
문화 이야기 (92)
세상사는 이야기 (188)
IT 이야기 (8)
Statistics Graph
BLOG main image
세상을 보는 또 다른 시선
때로는 '사실'보다 '희망'이 더 절박할 때가 있습니다. 적절한 희망이야말로 사람을 움직이는 원동력이 되고, 사람이 움직이면 희망은 곧 사실로 바뀌게 됩니다.
by 5throck

세상을 보는 또 다른 시선

5throck's Blog is powered by Tattertools / Supported by TNM Media
Copyright by 5throck [ http://mbastory.tistory.com/ ]. All rights reserved.

Tattertools TNM Media DesignMyself!