하나의 시스템은 독립적인 프로그램들로 구성됩니다.

우리는 프로그램들과 이들 프로그램들과의 관계를 정리하는 것을 아키텍쳐라고 부릅니다.

이들 시스템들의 다이어그램을 그릴 때, 종종 개개의 프로그램들과 서버들을 간략하고 조그만 사각형들로, 연결 관계들을 화살표들로 표현합니다.

“HTTP를 통신하는 SOAP-XML을 사용한 동기화/비동기 요청/응답”을 의미하는 하나의 화살표가 있습니다. 단 하나의 그림 문자가 표현하기에는 너무나 많은 정보를 가지고 있습니다. 이러한 모든 것을 표현하기에는 충분한 공간이 없습니다.

그래서 우리는 화살표 위에 내부적인 관점으로는 “XML over HTTP (HTTP 기반의 XML)”,  외부적인 관점으로는 “SKU[1] Lookup”[2] (재고 검색)라고 이름을 붙입니다.

프로그램들을 연결하는 화살표는 직접적으로 프로그램들과 통신하는 것 같아 보이지만, 사실은 그렇지 않습니다. 박스들 사이에 하얀 공백들은 하드웨어와 소프트웨어 컴포넌트들로 가득 채워져 있습니다.

이 회로와 같은 박스는 아래와 같은 것들을 포함할 수 있습니다.

  • 네트워크 인터페이스 카드
  • Landing Zone 테이블
  • 네트워크 스위치
  • 도시 권역 SoNET Ring(Metro-area SoNET Rings)
  • 방화벽
  • MPLS 게이트웨이
  • 칩임 탐지 시스템과 침입탐지와 실시간 방어가 가능한 솔루션 (IDS와 IPS)
  • 중계 회선 (Trunk lines )
  • 메세지 큐와 브로커들
  • Oceans (대양)
  • 케이블을 찾는 배들(Cable-finding fishing trawlers)
  • XML 변환 엔진들
  • FTP 서버들

프로그램 A와 B사이에는 항상 4개 또는 5개의 컴퓨터들이 있습니다. 이들 컴퓨터는 패킷 스위칭을 하는 소프트웨어와 , 트래픽 분석, 위험 분석 등을 위한 소프트웨어가 동작하고 있습니다. 아키텍트로써, 이러한 프로그램들을 연결 시키기 위해서는, 당신은 이러한 요소들을 고려해야 됩니다.

저는 “만족시킴(fulfillment)”이라고 표기해 놓은 화살표를 본적이 있습니다. 하지만 이 간단한 화살표의 내부는 그리 간단하지 않습니다. 서버 한대는 고객의 회사에 있었고, 또 다른 서버는 다른 곳에 있었습니다. 고객을 만족시키기 위해서 매우 중요한 이 화살표는 복잡하게 엮여있는 (인테페이스 한개 이상의 쥐덫(Moustetrap) 게임을 닯은 ) 이벤트들의 체인을 나눕니다. (unpack, unmarshaing) 메세지는 메세지 브로커에게 전달 되어지고 브로커는 이 메시지 들을 파일형태로 저장합니다.  그후 주기적인 FTP 처리를 통해 이 파일들을 수집해 간 후 또 여러 가지 일을 합니다. 단지 하나의 인터페이스가 20개의 이상의 절차를 가지고 있습니다.

화살표가 전달하는 정적이거나 동적인 메세지(loads)를 이해하는 것은 필수적입니다. 단지 “HTTP 기반의 SOAP-XML”이라고 표현하는 것 대신에, 작은 화살표는 “HTTP 요청 당 하나의 쿼리를 날리고, HTTP응답(reply)당 하나의 응답(response)이 돌아오는 것을 예측합니다. 그리고 최대 초당 100 개 이상의 요청과 250 밀리 초 (milliseconds) 이하의 시간 동안 99.999 %의 응답을 제공합니다.” 라고 표현해야 합니다.

우리는 화살표에 대해 알아야 할 것들이 더 있습니다.

  • 호출자가 너무 자주 호출한다면? 응답자는 한계에 도달했을 때 요청을 무시(drop) 할지, 공손히 거절해야 할지, 요청을 처리할 수 있게 최선을 다해야 할까요?
  • 호출자가 250 밀리 초 (milliseconds) 이후에 응답을 받게 된다면? 재호출 해야 할까요? 좀더 기다려야 할까요? 또는 응답자가 죽었다고 가정하고, 요청에 대한 기능을 수행하지 않고 넘어가야 할까요?”
  • 호출자가 프로토콜 (통신 규약) 1.0으로 요청을 보냈는데, 1.1 버젼 형태로 응답이 왔다면 어떠한 일이 발생할까요? 받은 데이터 중 일부분이 XML 대신 HTML 형태로 왔다면? 또는 XML 대신에 MP3 File이 왔다면?
  • 잠시 동안 인터페이스의 한 끝 부분이 사라졌다면 어떻게 될까요?

이러한 물음들에 대해 답변하는 것이 다이어그램을 그리는(백지를 채우는) 작업의 핵심입니다.

Written By Michael Nygard

이 자료는 Creative Commons Attribution 3 라이센스를 준수합니다.

원본 자료 – http://97-things.near-time.net/wiki/Engineer%20in%20the%20white%20spaces

(실제 서적을 번역한 것이므로, 위 Wiki 원본과는 번역 내용이 상이할 수도 있습니다.)


[1]Stock Keeping Unit – 문자와 숫자 등 기호로 표기하며 개별적인 생산물(제품,단품)에 대해 재고관리 목적으로 추적(History) 관리가 용이하도록 식별하기 위해 사용되는 논리적 관리코드이다

[2] SKU Lookup – 재고의 관리 단위 ( XML HTTP로 통신하지만, 실제 재고 내용을 파악하기 위한 메시지 였음을 의미한다.)

Join the conversation! 4 Comments

  1. 좋은 글 잘읽었습니다.

    프린트해서 자주 보려고 하네요 ^^

    여기 오면 항상 공부하고 가서 좋아요

    응답
    • 🙂 저 역시 연륜이 느껴지는 글이라, 좋아라 합니다.

      97 Architects 에 서적은 참으로 많은 것에 대해 가르침을 주지요.
      조만간 출간되면, 보너스로 한권 제가 특별히 드리겠습니다.

      감사합니다.

      응답
  2. 경험이 쌓일수록- 하고 싶은 말과 글로 남기고픈 경험이 많아진다지만
    쓰기, 읽기 그리고 말하기를 잘 못해 그러한 재산들을 정리 못하는 엔지니어인 덕분에-
    저분들의 ‘정리와 기록과 표현’방법이 나무만 보던 나에게도 숲을 보게끔 하는구나 싶다.

    확실히, 나는 요즘 이슈가 되고 있는 ‘인문학’이랑 먼데서 살고 있었고, 그래서 저분들의 표현이 ‘네 자신을 알라’ 하시는 철학자분들의 얘기를 듣는 느낌이랄까?
    즉, 다- 맞는 말인데, 현실에서 바르게 바뀌고, 더 나아지기 위해서는 얼마나 더 가야 하는 걸까의 문제의 느낌으로 또 끝날것만 같은… .
    원천적인 문제를 짚어본다면, 글에서 말한것 처럼, 내가 표현하기에 편한게 아니라, 상대방이 이해하기 편하게끔 ‘주.어.진.시.간.안.에.’ 표현하는 방법을 알고, 이후- 쓰고, 말하고, 실천해야 한다는 것인데… .
    그 능력치가 UP! 되는 방법은?
    그만한 의욕이나 열정을 북돋을 방법은?

    책? 실경험? 대화? 야근? 이란 것들은 해도해도 끝이 없을것 같고… .T^T

    다시말해, 저분 역시 다양한 경험에서 하는 얘기일테고, 소위 ‘아키텍트’라는 제다이 마스터 같은 아우라를 뿜어내는 것은, 우리와 다른 ‘정리/기록’ 능력 덕분이 아닐까 하는데… .

    혹시 그게 맞거나, 일부라 해도… ‘글’과 ‘문서’ 작업은 왜이리 하기 싫을까아….
    그래서 나는 ‘아키텍트’? 까지 한참 멀었나 보다… ㅎㅎ

    응답
    • 많이 써보고, 다양한 사람들과 만나 그들의 시선을 배우고,
      다양한 경험을 쌓는게 중요하다고 생각해요.🙂
      자극도 받고🙂

      정리/기록 이게 부족하죠. 정말 우리는 거기다 공유하는 것도 인색하구요🙂

      응답

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

카테고리

Articles, My Activity, Software Architecture, Software Engineering, Study

태그

,