02 A Few Concrete Examples
(몇 가지 구체적인 예제)

Deep Learning은 입력값과 출력값을 맵핑한다. Deep Learning은 상관 관계를 찾는다. 그것은 "Universal Approximator"(보편적인 근사)라고 알려져 있다. 왜냐하면 입력값 x와 출력값 y가 상관 관계나 인과 관계가 있다고 가정할 때, 함수 f(x)=y의 근사치를 계산하는 것을 배울 수 있기 때문이다. 학습 과정에서, 신경망은 f(x)=3x+12인지 f(x)=9x-0.1인지에 상관없이 올바른 f를 찾거나 정확한 방식으로 x를 y로 변환한다. Deep Learning이 무엇을 할 수 있는지 여기 몇가지 예제가 있다.

1. Classification
(분류)

모든 분류 작업은 라벨이 붙여진 데이터셋에 달려 있다. 그것은 곧 사람은 신경망이 라벨과 데이터 사이의 상관 관계를 배우도록 지식을 데이터셋으로 변환해야 한다는 것을 의미한다. 이것을 Supervised Learning(감독 학습)이라고 한다.

  - 얼굴을 감지하고, 이미지에서 사람들을 식별하고, 얼굴 표정을 인식한다. (화가 났는지, 즐거운지)
  - 비디오에서 행동 인식한다.
  - 음성을 감지하고, 화자를 식별하고, 음성을 텍스트로 바꾸고, 음성에서 감정을 인식한다.
  - 텍스트를 스팸(이메일에서)이나 사기(보험 청구에서)로 분류하고 텍스트에서 감정을 인식한다. (고객 피드백)

사람이 만들 수 있는 어떤 라벨이나 관심을 가지고 있는 어떠한 결과, 데이터와 상관 관계가 있는 어떤 라벨이라도 신경망 훈련에 사용할 수 있다.

2. Clustering
(클러스터링)

클러스터링이나 그룹핑은 유사성을 감지한다. Deep Learning은 유사성을 감지하기 위해 라벨을 붙이도록 요구하지 않는다. 라벨을 붙이지 않은 Learning은 "Unsupervised Learning"(감독되지 않는 학습)이라고 한다. 라벨이 붙어 있지 않은 데이터는 전 세계 대부분의 데이터이다. 머신 러닝의 한가지 원칙은 더 많은 데이터로 알고리즘이 학습할수록, 더 정확해질 것이라는 것이다. 그러므로, unsupervised learning은 굉장히 정확한 모델을 생성할 수 있는 잠재력이 있다.

  - 검색 : 유사한 아이템을 나타내기 위하여 문서나 이미지, 사운드를 비교한다.
  - 이상 탐지 : 유사성 탐지와는 반대로 이상 현상이나 비정상적인 행위를 탐지하는 것이다. 많은 경우에, 비정상적인 행위는 사기와 같이 탐지하고 방지하기 원하는 것과 높은 상관 관계가 있다.

3. Predictive Analytics
(예측 분석)

말하자면, 분류를 통해서 deep learning은 이미지의 픽셀과 사람의 이름 사이의 상관 관계를 설정할 수 있다. 이것을 정적 예측이라고 부를 수 있다. 동일한 토큰으로, 충분한 올바른 데이터에 노출된다면 deep learning은 현재 이벤트와 미래 이벤트 사이의 상관 관계를 설정할 수 있다. 미래 이벤트는 감각에 라벨을 붙이는 것과 같다. Deep learning은 시간이나 어떤 일이 아직 발생하지 않았다는 사실을 반드시 고려하지는 않는다. 주어진 일련의 시간 동안, deep learning은 숫자열을 읽고, 다음에 발생할 것 같은 최적의 숫자를 예측한다.

  - 하드웨어 고장 : 데이터 센터, 제조, 운송
  - 건강 이상 : 뇌졸중, 생체 통계와 웨어러블 데이터 기반 심장 마비
  - 고객 변동(churn:서비스 제공자를 바꾸는 고객) : 웹 활동이나 메타데이터에 근거한 고객이 떠날 가능성 예측
  - 직원 이직율 : 위와 동일하지만, 직원용으로

더 잘 예측할수록, 더 잘 예방하고 미연에 방지할 수 있다. 보는 것과 같이, 신경망을 가지고 우리는 더 적은 놀라움의 세상을 향해 움직일 수 있다. Zero가 아닌 단지 미미하게 더 적은 놀라움의 세상으로.

Deep Learning Use Case에 대한 간략한 Overview를 통해서, 신경망이 무엇으로 이루어져 있는지를 살펴보자.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/787


more..



01. Neural Network Definition
(신경망의 정의)

신경망은 패턴을 인식하도록 디자인된 사람의 뇌를 본떠 느슨하게 모델링된 일련의 알고리즘이다. 신경망은 기계 인식, 원시 입력값을 라벨링하거나 클러스터링하는 것을 통해 감각 데이터를 해석한다. 신경망이 인식한 패턴들은 모든 실제 세상의 데이터-이미지, 사운드, 텍스트, 시간 계열-가 번역되어 벡터에 포함된 수치들이다.

신경망은 클러스터링하고 분류하는데 도움을 준다. 신경망은 저장하고 관리하는 데이터 위에서 클러스터링하고 분류하는 계층으로 생각할 수 있다. 신경망은 예제로 입력하는 값들 사이의 유사성에 따라 라벨이 붙어 있지 않은 데이터를 그룹하는데 도움을 준다. 그리고, 라벨이 붙여진 데이터를 가지고 있다면 분류하여 훈련할 수 있다. (더 정확하게 이야기하면, 신경망은 클러스터링하고 분류하기 위해 다른 알고리즘에 있는 기능들을 추출한다. 따라서 심층 신경망(Deep Neural Networks)은 강화 학습, 분류 및 회귀 알고리즘을 포함한 더 커다란 머신러닝 어플리케이션의 컴포넌트로 생각할 수 있다.)

Deep Learning(심화 학습)으로 풀 수 있는 문제들은 무엇이 있으며, 더 중요한 것은 Deep Learning으로 여러분의 어떤 문제들을 해결할 수 있는가? 그에 대한 답을 알기 위해서는 스스로에게 몇 가지 질문을 해볼 필요가 있다. 내가 관심을 가지고 있는 결과는 무엇인가? 그런 결과들은 데이터로 적용될 수 있는 라벨들이다. 예를 들면, 이메일 필터의 스팸인지 아닌지, 사기 탐지의 좋은 사람인지 나쁜 사람인지, 고객 관계 관리(CRM)상에서의 화난 고객인지, 행복한 고객인지. 그런 다음 물어보라. 이 라벨에 동반되는 데이터를 가지고 있는가? 곧, 라벨이 붙여진 데이터를 찾을 수 있는가? 또는 라벨과 입력값 사이의 상관 관계를 알고리즘에 가르쳐 주기 위해 스팸이라는 라벨이 붙여진 스팸과 같이 라벨이 붙여진 데이터들(Mechanical Turk이나 Crowdflower와 같은 서비스를 사용하여)을 만들 수 있는가?

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/786


Summary
(요약)

기존 어플리케이션을 마이크로서비스로 마이그레이션하는 과정은 어플리케이션 현대화의 한 형태이다. 어플리케이션을 처음부터 다시 작성하여 마이크로서비스로 옮기면 안 된다. 대신에, 어플리케이션을 일련의 마이크로서비스로 점차적으로 리팩토링해야 한다. 여기에 사용할 수 있는 3가지 전략이 있다. 새로운 기능을 마이크로서비스로 구현한다. 비즈니스 컴포넌트와 데이터 액세스 컴포넌트에서 프리젠테이션 컴포넌트를 분리한다. 기존의 모듈을 monolith에서 마이크로서비스로 변환한다. 시간이 지날수록 마이크로서비스의 수는 증가하고, 개발팀의 민첩함과 속도는 증가할 것이다.

more..


받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/785


Strategy 3 – Extract Services
(세번째 전략 : 서비스 추출)

세번째 리팩토링 전략은 monolith 내 기존 모듈들을 독립형 마이크로서비스로 변환하는 것이다. 모듈을 추출하여 서비스로 변환할 때마다, monolith는 작아진다. 일단 충분히 모듈로 변환하고 나면, monolith는 문제가 되지 않을 것이다. Monolith는 완전히 사라지거나 또다른 서비스가 될 만큼 충분히 작아지게 된다.

Prioritizing Which Modules to Convert into Services
(서비스 변환 대상 모듈 우선 순위화)

크고 복잡한 monolithic 어플리케이션은 수십, 수백개의 모듈들로 이루어져 있다. 그리고 그 모듈들은 모두 추출 대상이다. 우선 변환할 모듈을 알아내는 것은 도전적인 일이다. 좋은 접근 방법은 쉽게 추출할 수 있는 몇 가지 모듈로 시작하는 것이다. 이것은 일반적으로 마이크로서비스와 특히 추출 프로세스에 대한 경험을 제공해 준다. 그 이후에, 가장 큰 이익을 주는 모듈들을 추출해야 한다.

모듈을 서비스로 변환하는 것은 일반적으로 시간이 많이 걸린다. 여러분은 얻을 수 있는 이익을 기반으로 모듈에 대한 순위를 매기기를 원한다. 일반적으로는 자주 변경되는 모듈을 추출하는 것이 유익하다. 한번 모듈을 서비스로 변환하고 나면, monolith와는 독립적으로 개발하고 배포할 수 있기 때문에 개발을 가속화하게 될 것이다.

Monolith의 나머지와 크게 다른 리소스 요구사항을 가지는 모듈을 추출하는 것도 유익하다. 예를 들면, 인메모리 데이터베이스를 가진 모듈을 서비스로 변환하고, 대용량 메모리를 가진 호스트에 배포할 수 있다. 이와 유사하게, 계산하기에는 비싼 알고리즘을 구현하는 모듈을 추출하는 것은 많은 CPU를 가진 호스트에 배포할 수 있기 때문에 가치가 있다. 특정 리소스 요구사항을 가진 모듈을 서비스로 변환함으로써, 어플리케이션을 훨씬 쉽게 확장할 수 있다.

어느 모듈을 추출할지를 알고 나면, 이미 존재하는 대략적인 경계(이음새로 알려진)를 찾는 것이 유용하다. 모듈을 서비스로 더 쉽고 값싸게 한다. 그러한 경계의 한 예로는 비동기 메시지를 통해 나머지 어플리케이션과 커뮤니케이션하는 모듈을 들 수 있다. 상대적으로 싸고 쉽게 모듈을 마이크로서비스로 변환할 수 있다.

How to Extract a Module
(어떻게 모듈을 추출하는가)

모듈을 추출하는 첫번째 단계는 모듈과 monolith 사이에 대략적인 인터페이스를 정의하는 것이다. Monolith는 서비스가 소유한 데이터를 필요로 하고, 그 반대의 경우도 마찬가지이기 때문에 대부분 양방향 API일 것이다. 모듈과 나머지 어플리케이션들 사이의 얽혀 있는 의존성과 잘 정리되어 있는 상호작용 패턴 때문에 양방향 API를 구현하는 것은 종종 어려운 일이다. Domain Model 패턴을 사용하여 구현된 비즈니스 로직은 도메인 모델 클래스 간의 수많은 연관성 때문에 리팩토링하기에 특히 어렵다. 이러한 의존성을 깨기 위하여 종종 중요한 코드를 변경해야만 할 필요가 있다. 다음 다이어그램은 리팩토링에 대해서 보여준다.

대략적인 인터페이스를 일단 구현하고 나면, 모듈을 독립적인 서비스로 변환할 수 있다. 이렇게 하기 위해서, monolith와 서비스가 Inter-Process Communication(IPC : 프로세스간 통신) 메커니즘을 사용하는 API를 통해 서로 통신할 수 있는 코드를 작성해야만 한다. 다음 다이어그램은 리팩토링 전, 도중, 후의 아키텍처를 보여준다.


사용자 삽입 이미지



이 예제에서, 모듈 Z는 추출할 후보 모듈이다. 그 구성요소들은 모듈 X에서 사용되고, 모듈 Y를 사용한다. (즉, X 모듈에서는 Z 모듈의 구성요소를 사용하고, Z 모듈의 구성요소들은 Y 모듈을 사용한다.) 첫번째 리팩토링 단계는 대략적인 API 쌍을 정의하는 것이다. 첫번째 인터페이스는 모듈 Z를 호출하기 위해서 모듈 X에서 사용하는 인바운드 인터페이스이다. 두번째는 모듈 Y를 호출하기 위해 모듈 Z에서 사용하는 아웃바운드 인터페이스이다. (인바운드 : 모듈 Z의 입장에서 요청이 들어오는 방향, 아웃바운드 : 모듈 Z의 입장에서 요청이 나가는 방향)

리팩토링의 두번째 단계는 모듈을 독립적인 서비스로 변환하는 것이다. 인바운드, 아웃바운드 인터페이스는 IPC 메커니즘을 사용하는 코드로 구현된다. 서비스 검색과 같은 Cross-Cutting Concern(AOP에서 여러 비즈니스 로직에 공통으로 필요하여 별도 모듈로 쉽게 분리할 수 없는 요구사항. 예:보안, 로깅, 트랜잭션, 등)을 다루는 Microservice Chassis framework와 모듈 Z를 결합하여 서비스를 빌드할 필요가 있다.

일단 모듈을 추출하고 나면, monolith와 다른 서비스들과는 별도로 개발, 배포, 확장하 ㄹ수 있는 또다른 서비스를 가지게 된다. 서비스를 처음부터 재작성하게 될 수도 있다. 이 경우에는, 서비스와 monolith를 통합하는 API 코드가 2개의 도메인 모델 사이를 변환하는 Anti-Corruption Layer(반부패 계층)이 된다. 서비스를 추출하는 경우마다 마이크로서비스의 방향으로 또 한 걸음 나아가는 것이다. 시간이 지날수록 monolith는 작아지고, 마이크로서비스는 늘어날 것이다.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/784


Strategy 2 – Split Frontend and Backend
(두번째 전략 - Frontend와 Backend의 분리)

Monilithic Application을 축소시키는 전략은 비즈니스 로직과 데이터 액세스 레이어에서 프리젠테이션 레이어를 분리하는 것이다.

일반적으로 엔터프라이즈 어플리케이션은 최소한 3가지 다른 유형의 컴포넌트들로 이루어져 있다.

프리젠테이션 레이어 - HTTP 요청을 처리하고, (REST) API나 HTML 기반 Web UI를 구현하는 구성 요소. 정교한 사용자 인터페이스를 가지고 있는 어플리케이션에서 프리젠테이션 계층은 종종 상당한 코드로 구성되어 있다.
비즈니스 레이어 - 어플리케이션의 핵심 영역이며, 비즈니스 규칙을 구현하는 구성 요소.
데이터 액세스 레이어 - 데이터베이스나 메시지 브로커와 같은 인프라 구성 요소들에 액세스하는 구성 요소

일반적으로 프리젠테이션 로직 영역과 비즈니스, 데이터 액세스 로직 사이는 분명하게 분리되어 있다. 비즈니스 계층은 비즈니스 로직 컴포넌트들을 캡슐화하는 하나 이상의 facade(진입점 역할을 하는 인터페이스)로 이루어진 대단위 API를 가지고 있다. 이 API는 monolith를 2개의 더 작은 어플리케이션으로 나눌 수 있는 자연적인 솔기이다. 한 개의 어플리케이션은 프리젠테이션 레이어를 가지고 있다. 다른 어플리케이션은 비즈니스와 데이터 액세스 로직이 포함되어 있다. 이렇게 분리한 후, 프리젠테이션 로직 어플리케이션은 비즈니스 로직 어플리케이션을 원격으로 호출하게 된다. 다음 다이어그램은 리팩토링 전후의 아키텍처를 보여주고 있다.

사용자 삽입 이미지



이 방법으로 monolith를 분할하는 것은 2가지 주요 장점이 있다. 서로간에 독립적으로 2개의 어플리케이션을 개발, 배포, 확장할 수 있다. 특히, 프리젠테이션 레이어 개발자는 사용자 인터페이스를 빠르게 반복하여 개발할 수 있다. 그리고 예를 들면, 쉽게 A|B 테스트를 수행할 수 있다. 이 접근방법의 또다른 장점은 개발한 마이크로서비스에서 호출할 수 있는 원격 API를 제공한다는 것이다.

그러나, 이 전략은 단지 부분적인 해결책일 뿐이다. 한 두개의 관리할 수 없는 monolith 어플리케이션에 대한 해결책일 공산이 크다. 나머지 monolith를 제거하기 위해서는 3번째 전략을 사용하는 것이 필요하다.
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/783