Category Archives: 아키텍쳐

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

마이크로 서비스 아키텍쳐(Micro Service Architecture)는 줄여서 MSA라고 부르며 서비스를 기능별로 작게 쪼개는 서버 아키텍쳐의 디자인 패턴으로, 기본 컨셉은 하나의 서비스는 한가지 일에 초점을 맞춘다는 것입니다. 또 다른 서비스와의 연계는 API로 구현합니다.

마이크로 서비스 아키텍쳐 구현 프로세스는 크게 4단계로 나눌 수 있는데, 구체적인 처리 절차는 다음과 같습니다.

STEP 1. 기능별로 서비스 어플리케이션 구분

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 2. 서비스 이미지 개발

– 이때 각각의 서비스 어플리케이션은 수샙, 수백여개의 서비스들로 구성되며, 각 서비스는 적절한 CPI, Memory, I/O리소스를 제공받아야 하고, 배포는 빠르고 효율적이어야 함. 참고로 배포 방법은 서버마다 전체 서비스를 적용하는 방법, 서비스를 VM위에 적용하는 방법, 서비스를 도커 콘테이너 위에 적용하는 방법 등이 있습니다.

– 서버별로 서비스를 적용하면 배포 및 서비스의 시작속도가 빠르다는 장점이 있습니다. 그러나 한 서비스 인스턴스가 CPU와 메모리를 모두 사용하는 문제점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 서비스를 VM에 적용하면 서비스별로 고정된 자원을 사용할 수 있고 클라우드 인프라 기능을 활용할 수 있다는 장점이 있습니다. 반면에 의도 해던 기능 외의 다른 VM의 기능은 낭비된다는 단점이 있고, 또 VM 자체를 관리해주어야 하는 오버해드를 가지고 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 마지막으로 서비스를 도커 콘테이너에 적용하는 방법이 있는데, 이는 VM의 장점을 거의 포함하면서 VM 보다는 가볍다는 잇점이 있습니다. 반면에 VM보다는 다소 기능이 떨어 질 수 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 3. 클라이언트에서 필요한 서비스 선택

– 실제 서비스 설계시 클라이언트에서 어떤 기능을 필요로 하는지 모델링을 할텐데, 이때 기능에 중복성을 없애면서 통신을 최소 하는 방향으로의 설계가 바람직합니다.

– 최적화 된 클라이언트의 구현 방법으로 API Gateway와 IPC(Inter-process Communiation)의 두가지 방법이 있습니다.

– API Gateway는 내부 시스템 아키텍쳐를 캡슐화 해서 클라이언트에 적합한 API를 제공하는 방식인데, 이는 주로 Netty, Vert.x, Node.js, Nginx와 같은 비동기, 논블로킹 I/O를 지원하는 플랫폼으로 개발됩니다. 또 통신 규격의 다양화로 이중 가장 효율적인 것을 선택할 수 있다는 장점이 있으며, Auto Scaling 및 IP 주소 변경에 유연하게 대응할 수 있다는 장점이 있습니다. 마지막으로 서비스 오류 핸들링을 용이하게 할 수 있다는 장점이 있는데, 넷플릭스의 Hystrix가 바로 그 예입니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– IPC(Inter-process Communication)은 서비스-클라이언트, 서비스-서비스간 통신 구현 방식인데, 구현 방법에 따라 동기적(request)/비동기적(message-based) 방식으로 나뉩니다. 주로 HTTP Rest나 Thrift 프로토콜을 많이 사용하며, 서비스 오류 핸들링이 용이하다는 장점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 4. 인스턴스 선택/관리

– 서비스가 가상화되먄 여러 인스턴스로 실행 시킬 수 있습니다. 이때 Auto Scaling 혹은 장애 등으로 IP 주소가 변화될 수 있습는데, 장애를 막기 위해 서비스 레지스트리에 자신의 상태를 전달합니다. 이때 상태 전달을 hearbeat이라고 호칭합니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

 

마이크로 서비스 아키텍쳐의 장점을 요약하면 다음과 같습니다.

  • 빠른 복구
  • Scaling
  • 서비스 확장 용이
  • 대규모 장애 확률 감소
  • 협업 용이

 

반면에 마이크로 서비스 아키텍쳐의 단점은 다음과 같습니다.

  • 복잡함
  • 트렌잭션 관리 어려움
  • 다중 테스트
  • 소규모 장애 확률 증가

 

 

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

인터넷 기반으로 서비스를 하는데 서버 없는 아키텍쳐가 있다고 하여 이를 올려 봅니다.

제목에 서버가 없다고 했지만, 서버가 아예 없는건 아닙니다. 정확한 표현은 최소화했다고 보는 것이 맞을 것 같습니다.

 

아래의 사례는 Amazon S3를 기반으로 하는 서비스 아키텍쳐 입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

Amazon CloudFront를 통해 콘텐츠르 배포하고, Amazon API Gateway를 이용하여 필요한 기능은 AWS Lamda를 이용한 사례입니다. AWS Lamda는 하나의 함수를 코드조각으로 구성하여 실행하는 실시간 대응형 서비스입니다.

 

아래의 사례는 모바일 앱의 사례인데, 기능이 좀더 복잡하여 Amazon API Gateway로 분기하여 AWS Lamda를 호출 한 사례입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

아래의 사례는 최소한의 기능만 가지고 서비스를 하는 마이크로 서비스의 사례입니다.

AWS 기반 서버 없는 아키텍쳐(Server-less back-end architecture)

뭐, 서버가 없다고 했지만, 이 모든것을 Lamda로 대체 가능하다고 주장하고 있습니다. 이를 위해서는 소프트웨어 구현 방법이 기존과는 달라져야 합니다.

넷플릭스 서비스 오토스케일링 아키텍쳐

글로벌 비디오 서비스 강자인 넷플릭스는 아마존 AWS를 운영환경으로 사용합니다.

그들이 온라인 비디오 시장에서 티격태격하면서 경쟁하고 있지만, 아이러니하게도 넷플릭스는 아마존과 끈끈한 관계를 유지하고 있습니다. 아마도 아마존은 넷플릭스덕분에 그들의 아마존 프라임 비디오 서비스를 위한 환경 구축을 북미 전역에 쉽게 얻었을 것이라는 생각을 하게 만듭니다. 

서비스 트래픽에 따라 서버 인스턴스를 늘렸다 줄였다 하는 오토스케일링(AWS Auto Scaling)을 기본으로 쓰고 있는데, 이는 다른 서비스 아키텍쳐와 다를 바가 없습니다.

다만, 트래픽이 증가한다고 무작정 오토스케일링을 하지 않고, 그들의 정책에 따라 EC2나 DynamoDB등의 키 컴포넌트를 스케일인, 스케일아웃을 한다는 것이 특징이라고 할 수 있습니다. 아래 그림에서는 Titus Control Plane이라 불리우는 넷플릭스 자체 시스템이 그러한 정책을 관리합니다.

넷플릭스 서비스 오토스케일링 아키텍쳐

또 하나 눈여겨 볼 것은 모바일/텔레비젼과의  통신은 Open API를 통해서 하지만, 자체구축하지 않고 Amazon API Gateway를 사용했습니다. 그럼으로 인해서 비용절감 및 보안(Security)을 해결하는 일타이피( ? ) 전략을 구사하고 있습니다.

참고로 위의 스핀네이커(Spinnaker)는 node.js 기반으로 동작하는 넷플릭스의 CDS(Continuous Delivery System)입니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 – InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

오라클 홈페이지에 가니 플러거블 스토리지 엔진 기반으로 동작하는 MySQL 아키텍쳐 그림을 볼 수 있었습니다. 플러거블(Pluggable)이라 함은 스토리지 방식을 선택할 수 있다는 것인데요. 이는 각각의 스토리지가 컴포넌트처럼 동작한다는 의미를 내포합니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 - InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

MySQL 5.5.5 이전 버젼에서는 MyISAM이 기본 스토리지 엔진이었습니다, 그런데 5.5.5부터는 InnoDB가 기본적으로 붙도록 바뀌었습니다. 쓰는 입장에서는 별 차이를 느낄 수 없을 것이라 생각됩니다만, 고도화 된 연산을 하는 부분에서는 성능차이가 발생 할 수 있을 것으로 생각됩니다. 즉, 개발된지 오래 된 MyISAM은 성능적으로 좀 느린 피드백을 줄 가능성이 높습니다. 그렇지만 256TB의 대용량을 지원 및 검색 기능은 무시 할 수 없을것 같군요.

MyISAM 스토리지의 기본피쳐는 아래와 같습니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 - InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

이와 비교할만한 DB로 InnoDB를 살펴봅시다.  보시는 바와 같이 스토리지는 64TB로 제한적이지만 주 메모리에 데이터와 인덱스(Index)를 상시 캐싱(Caching)하는 구조로 인한 퍼포먼스상의 잇점을 무시할 수 없을 것 같습니다. 즉, 인덱싱이 잘 되어져 있는 DB를 쓰시고 계신다면 설계시 감안했던 모든 잇점을 다 살리실 수 있을 것입니다.

플러거블 스토리지 엔진을 가진 MySQL 아키텍쳐 - InnoDB는 인메모리 캐싱을 하는 고성능 솔루션

좀더 자세한 기술적 자료는 아래 링크를 참조하세요.

https://docs.oracle.com/cd/E19957-01/mysql-refman-5.5/storage-engines.html

아틀라시안 뱀부(Atlassian Bamboo)를 활용한 CI(Continuous Integration) 환경 구축

아틀라시안 뱀부(Atlassian Bamboo)는 CI(Continuous Integration) Tool입니다. 여기서 CI는 어플리케이션 소스가 변경되면 이를 자동으로 빌드하고, 테스트하고 서버에 배포까지 완료해주는 일련의 프레스를 자동으로 수행하는 것을 가능하게 해주는 툴입니다.

일반적으로 개발자가 소스코드를 수정하여 소스코드 저장소에 올립니다. 이때 CI Tool이 저장소를 모니터링 하고 있다가, 뭔가 새로 변경된 것이 발견되면 소스코드를 다운로드하고 컴파일하여 자동실행 환경으로 배포까지 해 줍니다.

아틀라시안 뱀부(Atlassian Bamboo)를 활용한 CI(Continuous Integration) 환경 구축

뱀부(Bamboo)의 기본 기능은 아래와 같습니다.

  • 자동화(Automation)
  • BitBucket 소스코드 정합 및 Jira 트래킹
  • 모든 언어 지원
  • 병렬처리
  • 기존 자동화 툴(Hudson or Jenkins)로부터 소스코드 쉽게 이전 가능

유료라는 것이 함정이지만, 비용만큼의 가치가 있다는데 한표를 주고 싶습니다.

아키텍쳐 패턴이란 – 소프트웨어 디자인 패턴

외국인회사에 있다 보면 개발자 채용시 아키텍쳐 설계 부분도 이야기를 하게 됩니다. 그러면 어떤 어프로치로 소프트웨어를 설계해야 하느냐에 대한 논의를 하게 됩니다.

소프트웨어 개발/설계시 아키텍쳐링을 하다 보니 반복되는 패턴이 나오기 시작했고, 사람들은 이 패턴에 이름을 붙이기 시작했습니다. 즉, 아키텍쳐 패턴(Archiectural Patterns)이라 함은 소프트웨어 디자인 패턴이라고 할 수 있습니다. 참고로 패턴(Pattern)=유형,종류 라고 간주하셔도 될 것 같습니다.

 

아키텍쳐 패턴(Architectural Patterns)은 대략 다음의 10가지 종류가 있습니다.

1. Layered pattern

2. Client-server pattern

3. Master-slave pattern

4. Pipe-filter pattern

5. Broker pattern

6. Peer-to-peer pattern

7. Event-bus pattern

8. Model-view-controller pattern

9. Blackboard pattern

10. Interpreter pattern

 

여기에 하나 빠진것이 있다면 최근 떠오르는 MSA(Micro Service Architecture)가 있을텐데요… 이정도 길이면 학생들 가르킬때 21주짜리 프로그램이 하나 나올법도 하네요.

Interpreter pattern은 SQL 또는 통신프로토콜을 기술하는 언어 구현시 주로 이용되는 아키텍쳐

인터프리터 아키텍쳐 패턴(Interpreter Architectural pattern)은 프로그래밍 언어의 특정 구문을 해석/분석하는 컴포넌트 디자인에 많이 사용됩니다.

이 아키텍쳐의 기본 아이디어는 각각의 표현마다 클래스를 가지도록 하여 이를 조합하는 구조를 만드는 것입니다.

Interpreter pattern은 SQL 또는 통신프로토콜을 기술하는 언어 구현시 주로 이용되는 아키텍쳐
인터프리터 아키텍쳐 패턴(Interpreter Architectural pattern)은 SQL과 같은 Database Query Language 또는 특정 통신 프로토콜을 기술하기 위한 언어 등에 주로 응용되고 있습니다.

인터프리터 아키텍쳐 패턴(Interpreter Architectural pattern)의 장점이라 함은 동적인 설계가 가능하며, 최종 사용자가 프로그래밍하기 좋다. 즉, 인터프리터 프로그램을 쉽게 교체할 수 있기 때문에 유연성이 향상된다고 할 수 있습니다.

반면에 인터프리터 언어는 일반적으로 컴파일 언어보다 느리기 때문에 성능 문제가 발생할 수 있다는 단점이 있습니다.

Blackboard pattern은 오늘날 NLU(Natural Language Understanding)이나 차량인식 등에 응용되는 아키텍쳐

블랙보드 아키텍쳐 패턴(Blackboard Architectural pattern)은 Non-deterministic algorithm(비결정성 알고리즘)을 구현하는데 널리 이용되고 있습니다.

Non-deterministic algorithm(비결정성 알고리즘)은 그 다음 단계의 결과가 실행할때마다 다르게 나올 수 있는 알고리즘을 의미합니다. 참고로 Deterministic algorithm(결정성 알고리즘)은 결과가 유니크(Unique)합니다. 즉, 특정 값으로 떨어집니다.

Non-deterministic algorithm(비결정성 알고리즘)의 예는 “오늘 날씨 어떻지?”라는 함수를 호출했을때, 아침에는 “맑음”이었는데, 같은 함수를 오후에 호출하면 “흐림”으로 나오는 것이 그 예라고 할 수 있습니다.

블랙보드 아키텍쳐 패턴은 크게 3개의 컴포넌트로 이루어져 있습니다.

  • 블랙보드(blackboard) – 솔루션(solution space)에서 가져온 객체(object)를 가지고 있는 구조화된 전역 메모리 (structured global memory)
  • 지식소스(knowledge source) – 각각의 표현을 기술한 모듈
  • 컨트롤 컴포넌트(control component) – 상황에 맞게 모듈을 선택/설정/실행 합니다

모든 컴포넌트는 블랙보드를 통해 제어되며, 각각의 컴포넌트들은 백보드의 데이터 객체(data object)로 생성되어, 각각의 패턴에 맞는 지식소스로부터 패턴이 일치하게 되면 정해진 프로세스를 수행하게 됩니다.

Blackboard pattern은 오늘날 NLU(Natural Language Understanding)이나 차량인식 등에 응용되는 아키텍쳐

블랙보드 아키텍쳐 패턴(Blackboard Architectural pattern)은 구문인식(Speech recognition), 차량인식 및 추적(Vehicle identification and tracking), 시그널프로세싱, 단백질 구조 분석(Protein structure identification) 등에 응용되고 있습니다.

마지막으로 블랙보드 아키텍쳐 패턴(Blackboard Architectural pattern)의 장단점을 언급하면, 새로운 애플리케이션을 쉽게 추가할 수 있다는 장점이 있습니다만, 데이터 공간의 구조를 변경은 모든 애플리케이션이 영향을 받기 때문에 하기가 어렵다는 단점이 있어 동기화 및 접근 제어가 필요할 수 있습니다.

MVC(Model-view-controller) pattern은 Django, Rails와 같은 웹 어플리케이션 개발에 주로 응용되는 아키텍쳐

MVC(Model-view-controller) 아키텍쳐 패턴(Architectural pattern)은 웹 어플리케이션 개발에 주로 이용되는 아키텍쳐 패턴입니다.

MVC는 다음의  3개 파트로 구성되어져 있습니다.

  • 모델(model) – 기본 함수와 데이터를 포함합니다
  • 뷰(view) – 정보를 사용자에게 보여줍니다. 웹페이지 그 자체를 생각하시면 될 것 같습니다
  • 컨트롤러(controller) – 사용자로부터의 입력을 처리합니다

이 패턴의 기본 아이디어는 UI/연산(모델)/제어를 각각 분리하여 효율화를 하겠다는 것입니다. 실제 서비스 구축시에는 각각의 파트가 서버 인스턴스로 구성되어 퍼포먼스에 따른 서버 리소스 할당을 하여 효율화를 하기도 합니다.

MVC(Model-view-controller) pattern은 Django, Rails와 같은 웹 어플리케이션 개발에 주로 응용되는 아키텍쳐

MVC 아키텍쳐 패턴은 Java, Python, PHP와 같은 주요 프로그래밍 언어로 웹 어플리케이션 아키텍쳐 디자인시 주로 사용되고 있으며, Django나 Rails와 같은 웹 프레임웍(Web frameworks)에서도 사용되고 있습니다.

MVC 아키텍쳐 패턴은 동일한 모델에 대해 여러개의 뷰를 만들 수 있으며, 런타임에 동적으로 연결 및 해제를 할 수 있다는 장점이 있습니다. 그러나 이것이 오히려 복잡성을 증가시키며, 사용자의 행동에 대한 불필요한 업데이트가 많이 발생할 수 있다는 단점 또한 가지고 있습니다.

최근에는 RESTful API (Open API) 기반의 서비스/소프트웨어 개발이  널리 이용되면서 점차 MSA(마이크로 서비스 아키텍쳐; Micro Service Architecture)로 이동하는 추세를 보이고 있습니다.

Event-bus pattern은 Push Notification Service, 안드로이드 앱 개발에 주로 응용되는 아키텍쳐

이벤트-버스 아키텍쳐 패턴(Event-bus Architectural pattern)은 4개의 주요 컴포넌트로 구성되어져 있는데, 이들 컴포넌트는 이름에서 예상되듯 이벤트를 다루는 컴포넌트 입니다.

  • 이벤트 소스(event source)
  • 이벤트 리스너(event listener)
  • 채널(channel)
  • 이벤트 버스(event bus)

아래의 그림에서 특정 채널을 통해 메시지가 메시지 버스를 통해 전달 되면, 리스너(listener)는 등록(subscribe)한 특정 채널에 해당하는 메시지를 이벤트로 받는 구조입니다. 이 이벤트를 받는 것을 영어로 Event Notification이라고도 합니다.

Event-bus pattern은 Push Notification Service, 안드로이드 앱 개발에 주로 응용되는 아키텍쳐

안드로이드(Android)/아이폰 앱 개발이 이 아키텍쳐 패턴(Architectural pattern)에 해당하며, Push Notification Service도 이벤트-버스(Event-bus) 아키텍쳐 패턴(Architectural pattern)에 해당된다고 할 수 있습니다.

이벤트-버스 아키텍쳐 패턴(Event-bus Architectural pattern)은 고도로 분산화된 애플리케이션에 효과적이라고 할 수 있습니다. 반면, 모든 메시지가 동일한 이벤트 버스를 통해 전달되기 때문에 확장성 문제가 발생할 수 있다는 단점이 있습니다.

Peer-to-peer pattern은 BitTorrent와 같이 파일공유 솔루션이나 P2PTV, PDTP와 같은 멀티미디어 프로토콜에 주로 이용

P2P는 Peer-to-Peer의 줄임말입니다.

P2P 아키텍쳐 패턴(Architectural pattern)에서 개개의 각각의 독립적인 컴포넌트를 피어(peer)라고 부릅니다. 각각의 피어는 클라이언트로서 다른 피어에게 서비스를 요청하면서 한편으로는 서버로서 요청받은 서비스를 동적으로 처리해주는 기능을 가집니다.

Peer-to-peer pattern은 BitTorrent와 같이 파일공유 솔루션이나 P2PTV, PDTP와 같은 멀티미디어 프로토콜에 주로 이용

2000년대 초반에 많이 쓰이던 당나귀(eDonkey), 냅스터(Napster), 소리바다와 같은 소프트웨어가 P2P 아키텍쳐 패턴에 해당하며, P2PTV나 PDTP같은 멀티미디어 프로토콜이 및 비트코인이나 이더리움 등의 최근 크립토 커런시(Crypto Currency) 등이 아키텍쳐 패턴에 해당합니다.

P2P 아키텍쳐 패턴(Architectural pattern)은 탈중앙화된 컴퓨팅을 지원하며, 특정 노드 장애에 매우 강하고, 리소스 및 컴퓨팅 성능면에서 확장성이 뛰어나다는 장점이 있습니다. 
반면에 노드들이 자발적으로 참여하기 때문에 서비스 품질에 대한 보장이 어려우며 보안에 대한 보장이 어렵고, 노드의 갯수에 따라 성능이 좌우된다는 것은 단점이라고 할 수 있습니다.

Broker pattern은 Apache ActiveMQ, Apache Kafka, RabbitMQ 등 메시지 미들웨어 같은 아키텍쳐에 주로 이용

브로커아키텍쳐 패턴(Broker Architectural pattern)은 클라이언트-서버(Client-Server) / 마스터-슬레이브(Master-Slave) 처럼 역할이 분리된 컴포넌트(decoupled components)를 구조화하는데 주로 응용되는 패턴입니다.

여기서 브로커 컴포넌트는 컴포넌트간 통신(communication)을 조율(coordination) 하는 역할을 담당합니다.

클라이언트가 어떤 요청사항을 전달하면, 브로커가 중간에 받아서 이를 처리할 기능이 있는 서버로 명령을 요청하게 되고, 서버가 이에 따른 결과를 처리하는 방식입니다.

Broker pattern은 Apache ActiveMQ, Apache Kafka, RabbitMQ 등 메시지 미들웨어 같은 아키텍쳐에 주로 이용

Apache ActiveMQ, Apache Kafka, RabbitMQ and JBoss Messaging과 같은 소프트웨어가 브로커(Broker) 아키텍쳐 패턴(Architectural pattern)에 해당합니다.

브로커아키텍쳐 패턴(Broker Architectural pattern)은 객체의 동적인 변경, 추가, 삭제 및 재할당이 가능하며 개발자에게 배포를 투명하게 할 수 있다는 장점이 있습니다.

또한 배포를 투명하게 하려면 서비스 표현에 대한 문서화 등의 표준화가 필요합니다.

Pipe-filter pattern은 컴파일러와 같이 통해 연속되는 필터링 기법을 통한 분석을 하는 아키텍쳐에 주로 이용

파이프-필터 아키텍쳐 패턴(Architectural pattern)은 웹로그와 같은 텍스트 기반의 데이터 또는 프로그램 소스 코드 등과 같은 데이터 스트림을 처리하는데 적합합니다.

각각의 프로세스는 필터 컴포넌트 내에서 처리되며, 데이터는 파이프를 통해 전달되어 처리되어집니다. 이러한 파이프는 버퍼링을 하거나 동기화 하는 목적으로 사용됩니다.

Pipe-filter pattern은 컴파일러와 같이 통해 연속되는 필터링 기법을 통한 분석을 하는 아키텍쳐에 주로 이용

컴파일러, DNA정보 분석 소프트웨어가 파이프-필터 아키텍쳐 패턴(Architectural pattern)기반이라고 할 수 있습니다.

파이프-필터 아키텍쳐 패턴(Architectural pattern)은 다음과 같은 장점이 있습니다.

  • 필터 추가가 쉬움
  • 시스템 확장성이 좋음
  • 필터 재사용 가능
  • 주어진 필터들을 재구성하여 또 다른 파이프라인을 구축할 수 있음

반면에 단점이라 하면, 특정 필터 연산의 성능이 전체 효율에 영향을 미칠 수 있다는 것입니다.

Master-slave pattern은 장애 대응을 위한 Database 복제 등 병렬처리 및 Disaster Recovery 대응 로직에 주로 이용

마스터-슬레이브 아키텍쳐 패턴(Master-Slave Architectural pattern)은 마스터(master)와 슬레이브(slave)로 구성되어져 있는데, 마스터는 일을 분배하는 역할을 가지고 있으며, 슬레이브는 전달된 기능을 수행합니다.

즉, 마스터(주인)이 업무를 지시하면, 슬레이브(하녀)는 그 일을 완료하여 결과물을 전달 하는 것입니다.

Master-slave pattern은 장애 대응을 위한 Database 복제 등 병렬처리 및 Disaster Recovery 대응 로직에 주로 이용

마스터-슬레이브 아키텍쳐 패턴(Master-Slave Architectural pattern)의 예로는 데이터베이스 복제(replication)를 들 수 있습니다. 즉, 마스터 DB는 원본데이터를 가지고 있고, 슬레이브는 그 복제본을 동기화하여 가지고 있습니다.

참고로 replication이라 함은 사전적으로 “복제”라는 의미를 가지고 있습니다.

다른 예로는 USB 허브를 예로 들수 있는데, USB 허브를 통해 마스터 포트에서 사용하던 기능을 그대로 사용할 수 있습니다.

마스터-슬레이브 아키텍쳐 패턴(Master-Slave Architectural pattern)의 장점은 정확성에 있습니다. 즉, 서비스의 실행은 각기 다른 구현체를 가진 슬레이브들에게 전파되어 설계된 로직대로 동작합니다.

반면에, 슬레이브가 독립적이므로 공유되는 상태가 없으므로 실시간 시스템에서는 마스터-슬레이브간 레이턴시 문제가 발생할 수 있습니다. 이 패턴은 분리 가능한 문제에만 적용할 수 있다.

Client-server pattern은 TCP/IP를 통해 데이터를 주고 받는 이메일, 웹하드 등이 주로 이용하는 아키텍쳐

클라이언트-서브 아키텍쳐 패턴(Client-Server Architectural pattern)은 서버와 다수의 클라이언트로 구성된 2-Tier Architecture입니다.

서버는 다수의 클라이언트 컴포넌트에게 서비스를 제공하고, 클라이언트는 서버로부터 서로 약속한 서비스를 받는 구조입니다. 따라서, 이 구조에서는 서버가 클라이언트로부터 지속적으로 요청을 받아 처리하도록 설계되어져 있습니다.

 

Client-server pattern은 TCP/IP를 통해 데이터를 주고 받는 이메일, 웹하드 등이 주로 이용하는 아키텍쳐

응용분야로는 TCP/IP를 기반으로하는 Client-Server 소프트웨어로 이메일, 문서 공유 웹하드, 홈뱅킹 등이 있습니다.

클라이언트-서브 아키텍쳐 패턴(Client-Server Architectural pattern)은 클라이언트가 요청할 수 있는 일련의 서비스를 모델링 할 수 있다는 장점이 있습니다. 또한 이 아키텍쳐는 일반적으로 서버에서 별도의 스레드로 구현되며, 프로세스간 통신의 프로토콜이 달라 오버헤드가 발생할 수 있다는 단점이 있습니다.

Layered pattern은 PC App, 쇼핑몰(이커머스) 웹사이트 등이 주로 쓰는 아키텍쳐 패턴

레이어드 아키텍쳐 패턴(Layered architectural pattern)은 특정 수준의 추상화 된 레벨의 서브 펑션으로 구성된 스트럭쳐드 프로그램(Structure programs)에 널리 이용되고 있습니다.

각각의 레이어는 차상위 레벨의 레이어에게 서비스를 구성하도록 설계되어져 있는데, 통상 다음과 같이 4단계의 레이어를 이용하여 일반적인 정보 시스템을 구성하고는 합니다.

  • Presentation layer (UI layer라고도 부름)
  • Application layer (service layer라고도 부름)
  • Business logic layer (domain layer라고도 부름)
  • Data access layer (persistence layer라고도 부름)

 

Layered pattern은 PC App, 쇼핑몰(이커머스) 웹사이트 등이 주로 쓰는 아키텍쳐 패턴

 

레이어드 아키텍쳐 패턴의 사례로는 일반적인 데스크톱 어플리케이션 (General desktop applications)이나 아마존닷컴이나 알리익스프레스 같은 이커머스 웹 어플리케이션 (E commerce web applications)을 들 수 있습니다.

이 아키텍쳐의 장점이라 하면 하위 레이어는 다른 상위 레이어에 의해 사용이 되며, 레이어 표준화가 쉬우며 레이어 수준을 정의하기가 수월하다는 것입니다. 또한 레이어를 변경해도 다른 레이어에는 영향을 끼치지 않습니다.

반면에 단점이라 하면 광범위한 적용이 어렵다는 것인데, 특정 상황에서는 특정 레이어가 불필요할 수도 있습니다.

Machine Learning Tool의 종류와 용도

Machine Learning Tool의 종류는 어떤 것이 있고, 그 용도는 어떤 것으로 설계되었는지 살펴봅니다.

1. Tensorflow
Google Brain Team에서 개발했고, Neural Network 및 Machine Learning에 대한 연구에 사용되고 있습니다.
Gmail, 음성 인식, Google 포토 및 Google 검색과 같이 일상적으로 사용하는 인기있는 Google 서비스에는 Tensorflow가 탑재되어 있다고 합니다.
Tensorflow는 Data Flow Graph를 사용하여 복잡한 수치 작업을 수행하는데, 수학적 계산은 엣지와 노드가 포함된 그래프를 사용하여 정교화됩니다. 이 노드는 조작을 구현하는 데 사용되며 데이터가 공급되는 엔드 포인트로 작동 할 수도 있습니다. 엣지는 또한 다른 노드 간의 입/출력 연관을 나타냅니다.

2. Caffe
Machine Learning Framework로 CNN (Convolutional Neural Networks)을 활용하여 컴퓨터 비전/이미지 분류용으로 개발되었습니다.
텍스트, 사운드 또는 시계열 데이터가있는 응용 프로그램을 다루는 경우 Caffe는 컴퓨터 비전 이외의 용도로 사용되지 않습니다.
그러나 여러 호스트에서 동적으로 실행될 수 있으며 단일 플래그를 사용하여 CPU와 GPU간에 전환하는 작업을 잘 수행합니다.

3. Amazon Machine Learning
Amazon은 AML이라는 자체 머신러닝 서비스를 개발했습니다. AML을 사용하면 사용하기 쉬운 API를 통해 응용 프로그램에 필요한 예측을 파생시킬 수 있습니다. AML은 Amazon S3, RDS 또는 Redshift에 저장된 데이터에 연결하여 바이너리 분류, 회귀 또는 다중 클래스 분류와 같은 작업을 수행하여 새 모델을 생성 할 수 있습니다.

4. Apache Singa
Apache Singa는 주로 모델 파티셔닝을 사용하여 분산된 딥러닝과 학습 프로세스의 병렬화에 중점을 두는데 주로 이미지 인식 및 자연어 처리(NLP)를 하는데 사용됩니다.
Singa의 기술 스택은 IO, Model 및 Core라는 세가지 중요한 구성 요소로 이루어져 있는데, IO 구성 요소에는 네트워크 및 디스크에 데이터를 읽거나 쓰는 데 사용되는 클래스가 들어 있으며, Core에서는 텐서 연산과 메모리 관리 함수를 처리하고, Model은 기머신러닝 모델에 사용되는 알고리즘 및 데이터 구조를 포함합니다.

5. Microsoft CNTK
CNTK (Cognitive Toolkit)는 Microsoft의 오픈소스 Machine Learning Framework입니다. CNTK는 음성인식 영역에서 더 많이 사용되지만 텍스트 및 이미지 Training에도 사용할 수 있습니다.
AS CNN, LSTM, RNN, Sequence-to-Sequence 및 Feed Forward와 같은 다양한 머신러닝 알고리즘을 지원하며, 다양한 CPU 및 GPU를 포함한 여러 하드웨어 유형을 지원합니다.
CNTK에서 C ++ 및 Python과 같은 언어로 작업하고 내장된 교육 모델을 사용하거나 직접 빌드 할 수 있습니다.

6. Torch
2002년 NYU에서 개발된 Torch는 Twitter 및 Facebook과 같은 글로벌 서비스 업체에서 주로 쓰며, Torch는 루아(Lua)라는 언어로 코딩되어 있는 것이 특징입니다. Torch의 장점은 역시 참고문헌(?)이 많다는 것입니다.

7. Accord.NET
.NET을 기반으로하는 오픈소스 시스템 학습 Framework이며, 패턴 인식, 인공 신경망, 통계 데이터 처리, 선형 대수, 이미지 처리 등과 같은 응용 프로그램에 사용할 수있는 다양한 라이브러리로 구성됩니다.
Framework는 설치 프로그램, NuGet 패키지 및 소스 코드로 사용할 수 있는 라이브러리로 구성됩니다.
Accord.NET에는 코드 재사용과 점진적인 알고리즘 변경을 용이하게하는 매트릭스 라이브러리가 있습니다.

8. Apache Mahout
Apache Software Foundation의 무료 오픈소스 프로젝트인 Apache Mahout은 클러스터링, 분류 및 협업 필터링과 같은 애플리케이션을 위해 무료 분산 또는 확장 가능한 ML 프레임 워크를 개발하려는 목표로 구축되었습니다. Apache Mahout은 MapReduce 패러다임을 사용하여 Hadoop 위에 배포되는데, Hadoop에 저장된 Big Data 가 연결되면 Mahout은 의미있는 패턴을 찾는 데 도움을 줄 수 있습니다.

9. Theano
Theano는 2007 년 몬트리올 대학에서 개발한 것으로 저가형 머신러닝 프레임워크로 알려졌습니다.  Theano는 API 래퍼를 보낼 하이엔드 추상화 시스템을 위한 기본 플랫폼으로 주로 사용되고 있는데,  몇가지 인기있는 라이브러리의 예로는 Lasagne, Blocks 및 Keras가 있습니다. Theano를 사용하는 한가지 단점은 다중 GPU를 지원하기 위해 몇 가지 해결 방법을 모색해야한다는 것입니다.

10. Brainstorm
Python으로 작성된 Brainstorm은 여러 백엔드 시스템에서 원활하게 실행되도록 제작되었습니다. Brainstorm은 Python을 사용하여 두개의 Data API를 제공합니다. 하나는 Numpy 라이브러리의 CPU 용이고 다른 하나는 CUDA를 사용하여 GPU를 활용하는 것입니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 – 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

자연어 처리의 역사는 1950년대로 거슬러 올라가야 합니다. 당시 지금과 같은 컴퓨터 기술이 없었을때도 로봇이 사람의 말을 알아들을 수 있을까에 대한 의구심이 있었습니다. 또한 어떻게 하면 로봇이 사람의 말을 인지할 수 있을까에 대한 궁금증 또한 있었습니다.

인공지능의 가장 큰 도전과제는 어떻게 지식을 이해하고 표현할 것인가일 것입니다. 이해하는 것과 표현하는 것은 다를 것 같지만, 결국 그 둘의 공통분모는 이를 어떻게 정보화 할 것이냐에 대한 결과로 도출이 됩니다.

자연어처리라는 학문은 NLU라고 부르며 Natural Language Understanding의 줄임말입니다. 즉, 자연어에 대한 이해…

우리가 사용하는 언어는 일련의 규칙을 가지고 있으며, 여러가지 상황이 얽혀 있습니다. 소프트웨어 측면에서는 Multiple Query의 조합(Combination)이라고 할 수 있으며, 이는 어떠한 상황(State)에 대한 정보도 포함합니다.

이를 흐름도로 도식화 하면 다음과 같이 나타 낼 수 있습니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

우리가 어떠한 사실이나 개체를 인지할때는 대화를 통해서 알게 됩니다. 이것이 축적되면 굳이 대화를 나누지 않아도 우리 머리속에 그러한 상황정보가 남게 되고, 굳이 여러 대화를 나누지 않아도 한방에 알 수 있게 되는 것입니다.

결국 우리가 자연어처리 시스템을 구축한다고 하면 결국 “대화형 시스템”을 구축한다라고… 말해야 하는 것이 맞습니다. 대화형 시스템의 3단계 레이어를 도식화 하면 다음과 같이 나타 낼 수 있습니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

위의 그림에서 Dialogue Manager에서 핵심적인 기능은 있는 정보를 오케스트레이션(잘 버무리는 것; Dialog Orchestration)입니다. 이를 가능하게 하려면 양질의 메타데이터와 그에 따른 빅데이터가 있어야 가능할 것입니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

대화 시 상황정보를 받아들이는 계층을 도식화 하면 다음과 같이 표현 할 수 있습니다. 소프트웨어적 측면에서는 다음의 4단계로 나눌 수 있습니다.

  1. 명령(Command)
  2. 질문(Question)
  3. 할 일(Task)
  4. 잡담(Chat)

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

지금까지 구현된 대화형 솔루션은 3번까지입니다. 4번의 경우 일부 업체들이 그러한 기술을 구현했고, 계속 발전하고 있는 상태입니다.

대화형 솔루션의 궁극의 목표는 누가 말했느냐… 까지 구현하는 것일 것입니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

이러한 정보를 효과적으로 오케스트레이션하는 방법론으로는 다음과 같은 접근이 가능할 것입니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

마지막으로 자연어 처리는 Rule-based DM(Dialog Management) 또는 Data-based DM(Dialog Management)를 기반으로 동작하게 될 것입니다.

자연어처리(NLU)를 하기 위한 소프트웨어 아키텍쳐 - 걸음마단계부터 인간 수준으로 진화하는 방향에 대해 알아본다

현실적으로 자연어처리 소프트웨어를 만든다면  “자연어 처리로 무엇을 할 것이냐”에 대한 답을 가지고 있어야 가능 할 것입니다.

예를 들면 다음과 같은 목표가 있어야 합니다.

  1. IPTV 서비스를 위한 콘텐츠 추천
  2. 홈표핑을 위한 제품 추천
  3. 제품 고장 처리를 위한 문제점 확인

아마도 가까운 미래에는 위와 같은 DM Engine이 많이 만들어져 있을 것이고, 이것을 다시 오케스트레이션 하는 통합 엔진이 나올 것입니다. 그러면 정말 인간과 가까와지는 천재 로봇이 나올지도 모르겠군요.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning – TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

2015년 11월, 구글은 머신러닝(Machine Learning)이라는 기술을 공개했습니다.

사실 머신러닝은 구글이 최초로 만든 기술은 아닙니다, 구글이 그들의 소프트웨어를 공개하면서, 그들의 제품 이름이 아닌 대중이 알아듣기 좋은 적절한 이름으로 이미 업계에서 통용되고 있는 단어(머신러닝;Machine Learning)를 사용했습니다.

구글 머신러닝은 텐서플로(TensorFlow)라는 이름으로 오픈소스로 공개되었습니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

구글의 머신러닝은 공부한 시간을 데이터로 인풋(input)하면 컴퓨터는 성적이라는 결과를 아웃풋(output)으로 도출하게 되는데, 이 과정의 상관관계를 학습시키는 것이라고 합니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

구글은 머신러닝을 쉽게 이해시키기 위해 로켓도 동원했는데, “머신러닝은 로켓엔진과 비슷하다”면서 “로켓엔진의 중간 부분이 머신러닝이며 로켓의 연료가 데이터, 뿜어져 나오는 연기는 그 결과물”이라고 설명했는데, 아래의 로켓 엔진은 위에 그려진 머신 러닝 컨셉 다이어그램과 유사합니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

또한 구글은 인공지능 소프트웨어 시스템인 ‘텐서플로(TensorFlow)’를 무상으로 공개한다고 발표했는데, “이를 통해 개발자들은 CPU, GPU, 모바일 등 실제 제품에 접목할 수 있다”면서 “머신러닝의 표준화를 통해 미래제품 출시에도 도움이 된다”고 강조하면서 머신러닝의 보급에 최우선 순위를 두고 있다는 뜻을 내비쳤습니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

이 머신러닝 적용 사례로는 구글검색, 구글포토, 구글번역, 지메일(Gmail) 등 자사 제품이 있습니다. 구글앱을 통해 음성검색을 이용하면 그 음성을 인식한 뒤 분석한 내용을 바탕으로 검색어를 생성한다고 합니다. 또 구글 포토를 이용하면 스마트폰으로 찍은 사진을 인물, 장소, 사물별로 분류해 저장하고, 클라우드에 보관된 위치 정보가 없는 사진도 촬영 장소의 특징을 분석해 그 위치를 찾아낸다고 합니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

슈미트 회장은 “내가 볼 때 구글은 이 분야(머신러닝)에서 월드 리더다”라고 강조하면서 “구글은 머신러닝을 통해 더욱 스마트해질 것”이라고 언급했다고 합니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

텐서플로(TensorFlow)는 오픈소스로 공개되어졌으며, 다음의 URL에서 관련 정보를 얻으실 수 있습니다.

http://tensorflow.org/

 

참고로 텐서플로(TensorFlow) 외에도 아파치 머하웃(Apache Mahout)이라는 Scalable Machine Learning기술이 예전부터 공개되어져 있었고, 이 기술은 글로벌한 소프트웨어/서비스 기업에서 사용 중인데요, 관련정보는 http://mahout.apache.org/ 에서 얻으실 수 있습니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

 

마지막으로 머신러닝의 응용 사례에 대해 언급해보고자 합니다.

1) 넷플릭스는 머신러닝을 활용하여 개인화된 페이지를 구성하였습니다. (출처: 넷플릭스 블로그)

이를 통해 고객의 선호를 만족시키고 동시에 다양한 콘텐츠를 구매할 수 있도록 유도하는 전략을 펼쳤습니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

참고로 CF 알고리즘이 적용되었습니다.

 

2) 페이스북은 머신러닝을 활용하여 이미지 분석 진행

98%의 정확성을 가지고 있고, 8억건의 사진을 5초 이내에 확인할 수 있었다고 합니다.

구글 머신러닝 솔루션 텐서플로(Google Machine Learning - TensorFlow) 오픈소스 공개에 따른 현재와 미래의 비젼

참고로 구글포토에서도 비슷한 기술이 적용되어져 있다고 합니다.

 

3) 구글은 스팸메일 필터시 메일의 패턴을 학습시켜 스팸메일을 거르는 확률을 높였다고.

 

이제 서비스를 전제로 하는 소프트웨어는 보다 많은 빅 데이터를 쌓아 이를 응용하여 미래를 예측하는 기술을 전보다 더 많이 활용하게 될 것으로 보입니다. 보다 편리하고 살기 좋은 미래… 어떻게 다가 올지 궁금합니다.