BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
2012.07.21 12:41

 

아키텍처는 고객의 기능/비기능 요구사항과 직접적으로 관련된 중요한 의사결정입니다. 의사결정을 한다는 것은 어떤 문제에 대한 해결책으로 선택할 수 있는 대안들이 여럿 있다는 것을 의미합니다. 여러개의 대안들 중에 하나를 선택하는 것이기 때문에 거기에는 그렇게 결정한 근거가 있어야 합니다.

아키텍처를 간접 경험한다는 것은 이러한 의사결정 과정을 간접 경험하는 것입니다. 어떤 문제에 대해 어떤 대안들이 있고 그 대안들에서 어떤 것을 왜 선택했는지를 연습하는 것입니다.

이 책은 실제적으로 사용되고 있는 다양한 오픈소스들을 대상으로 하고 있고, 책 제목에 아키텍처를 포함하고 있기 때문에 관심을 갖는 사람들이 많이 있습니다. 그래서 많은 기대를 가지고 시작했습니다. 하지만 책의 시작에 해당하는 1장의 내용은 실망이었습니다. 전체 내용을 이미 읽거나 세밀하게 검토하지 않고, 많은 사람들이 관심을 갖고 있는 책이라는 이유로 너무 성급하게 선택한 것이 아닌가하는 생각도 해봤습니다.

사실 1장의 Asterisk는 도메인도 관심 대상이 아니고, 이 장을 통해 무엇을 배울 수 있는가를 물었을 때 사실 뭘 배울 수 있는지 모르겠습니다. 해당 도메인에 관심을 가지고 이러한 시스템을 개발해야 하는 사람에게는 도움이 될 수 있을지는 모르지만, 책의 의도한 바와 같이 아키텍처에 대한 간접 경험을 얻기에는 많이 부족해 보입니다.

이러한 이유로 책의 내용을 정리하는 방식으로 진행하는 것은 좋지 않다고 생각이 듭니다. 조금이라도 뭔가를 배울 수 있으려면 적극적으로 '어떻게 해당 시스템에 대한 아키텍처를 구축할 수 있을까?'라는 관점으로 접근해야 할 것 같습니다.

 

온라인 세미나 진행은 참여자가 아키텍트가 되어 '해당 시스템을 어떻게 아키텍처링할 것인가'라는 관점을 가지고 접근할 것입니다. 아키텍처링을 하지만 그 결과는 책의 내용이 기준이 됩니다. 불필요한 세부사항은 생략함으로 세미나 진행자나 참여자들의 부담을 줄이도록 하겠습니다.

 

Asterisk is an open source telephony applications platform distributed under the GPLv2. In short, it is a server application for making, receiving, and performing custom processing of phone calls.

'Asterisk ' - 이 이름으로 부터 시스템이 무엇을 하는지 알기 어렵습니다. 대부분의 오픈소스들의 이름이 이렇게 지어지는 것 같습니다. 시스템 이름은 시스템의 존재목적이 반영되도록 하는 것이 좋습니다.

 

이 시스템을 만들어야 한다면 어떻게 해야 할까요?

구조에 대한 접근은 기능요구와 비기능요구를 분리해서 접근하는 것이 이러한 구분 없이 접근하는 것보다 쉽습니다. 기능요구에 의해 결정되는 구조는 도메인의 핵심구조가 됩니다.

Asterisk 사용자는 전화를 통해서 음성메일이나 전화통화를 할 수 있습니다. 음성메일이나 전화통화에는 어느정도 시간이 요구될 것이기 때문에 전화와 Asterisk 시스템 사이에 연결을 유지할 필요가 있다. 연결을 유지해주는 부분을 채널(Channel)이라고 합시다. 음성메일은 하나의 전화와만 연결되니 하나의 채널이 만들어지면 됩니다. 

전화통화는 두 개의 채널이 만들어져야 합니다. 전화통화를 위해서는 어떤 채널과 어떤 채널이 연결된 것인지를 알아야 하고, 그들 사이의 음성 전달이 요구됩니다. 이 역할을 하는 것을 채널을 연결한다는 의미로 채널브릿지(Channel Bridge)라 합시다.

고객은 전화들 사이에 음성 뿐만 아니라 비디오나 텍스트 또한 전달하기를 원한다고 합니다. 음성이나 비디오나 텍스트를 전달하는 기술은 어떤 전화를 사용하느냐에 따라 다양하다고 합니다. 이 요구사항을 만족시키기 위해서는 채널이 다양한 기술을 지원할 수 있어야 합니다.  즉, 전화 사용자들이  어떤 채널 기술을 사용하던지 상관없이 두 채널을 연결할 수 있어야 합니다.

다양한 채널 기술들에 상관 없이 브릿지할 수 있으려면 다양한 고려가 있어야 하고 이를 반영해야 하기 때문에 성능이 떨어질 수 있습니다. 만약 같은 기술의 채널들을 연결하는 경우라면, 불필요한 고려를 할 필요가 없습니다. 성능과 유연성을 모두 만족시키기 위해서 두 종류의 브릿지를 둡니다. 채널 기술에 상관 없이 브릿지하는 것을 generic bridge라고 하고 채널 기술에 종속되어 브릿지하는 것을 native bridge라고 합시다.

 

여기까지 진행하면 우리는 도메인의 핵심구조인 Channel, Channel Bridge를 식별할 수 있습니다.

 

고객은 Asterisk가 프레임워크가 되기를 원합니다. 따라서 프레임워크를 확장해서 만들어지는 애플리케이션들에서 쉽게 사용될 수 있도록 해야 합니다. 

애플리케이션에서는 특별한 채널 기술들에 대해서 알 필요가 없습니다.  따라서 Asterisk는 특별한 기술을 추상화한 수준에서의 인터페이스와 구체적인 기술이 반영된 클래스가 구분되도록 합니다(인터페이스와 구현의 분리). 이 구분에 따라 Abstract Channel Layer, Channel Technology Layer라는 두 개의 레이어를 둡니다.

채널은 공통의 인터페이스에 대한 다양한 구현이 존재할 수 있기 때문에 구체적인 채널의 생성을 위해 팩토리를 둡니다(팩토리 메소드 패턴).

 

중요한 비기능 요구사항은 성능에 대한 것으로 병행처리에 대한 고려만을 하라고 합니다. 멀티쓰레드로 병행처리를 다루기로 합니다. 다수의 사용자들에 의해 연결이 요청될 수 있기 때문에 네트워크 모니터링 하는 것과 채널 처리에 대해서 쓰레드를 둡니다.

저작자 표시 비영리 변경 금지
신고
Mickey | 2012.07.26 23:44 신고 | PERMALINK | EDIT/DEL | REPLY
"해당 시스템을 어떻게 아키텍처링 할 것인가?" 라...조금 고민도 되고 부담도 되는 것 같네요..^^;
Justine | 2012.08.02 11:18 신고 | PERMALINK | EDIT/DEL
꼭 그렇게 할 필요는 없습니다. 1장과 2장은 정리된 내용에 밝힌 것 같이 그럴 만한 이유가 있어서 그렇게 한 것입니다. 내용을 잘 전달하고, 그 내용을 통해 무엇인가 배울 것이 있도록 하는 것이 목표입니다. 그 목표를 가장 잘 달성할 수 있는 방법이면 됩니다.
Name
Password
Homepage
Secret

티스토리 툴바