'분류 전체보기'에 해당되는 글 82건

(개인적으로 학습의 목적으로 정리한 글로 틀린 내용이 있을 수 있습니다)

Attention이 생긴이유

1) 연속된 정보(Sequence data)들관의 상관관계를 처리하기 위해 RNN(Recurrent Neural Network)이 처음으로 고안되었다.

2) 하지만 RNN은 vanishing gradient의 문제점 때문에 데이터가 길어지면 길어질수록 결과가 부정확해졌고, LSTM(Long Short Term Memory)는 이를 보완하기 위해 구조를 개선하여 나왔다.

3) Seq2Seq 모델은 내부적으로 encoder와 decoder라는 2개의 LSTM/RNN 모델 계층들을 사용하여 sequence를 입력값으로 받고 결과값도 sequence로 반환하여준다.

4) 하지만 Seq2Seq 모델또한 Vanishing Gradient문제가 남아있고, 하나의 고정된 벡터에 모든 정보를 압축하려고 하니까 정보 손실이 발생한다. 이를 보완하기 위해 Attention Mechanism이 사용되고 있다.

Seq2Seq 모델을 간단하게 짚고 넘어가기!

Seq2Seq 모델은 encoder과 decoder로 이루어지는데, encoder와 decoder는 하나 혹은 여러개의 RNN/LSTM의 계층을 가집니다. Encoder는 입력값을 압축해서 context vector로 변환합니다. 그리고 decoder는 이 context vector를 기반으로 각각의 timestamp마다 결과값을 추론하며, 얻어진 결과값을 다음 timestamp의 입력값으로 사용합니다. decoder는 이 작업을 <sos>부터 시작하여 <eos>까지 반복합니다. 추론의 결과값이 <eos>가 나오면 작업을 끝냅니다.

Attention의 기본적인 아이디어

Attention의 기본 아이디어는 decoder에서 출력단어를 예측하는 매 timestamp마다 encoder에서 전체 입력문장을 다시 참고하는 것이다. 이 때 모든 입력값들을 동일한 비중으로 참고하는 것이아니라, decoder에서 현재 timestamp를 넘겨주면 encoder에서 softmax함수를 사용하여 decoder의 추론에 도움이 되는 정도를 수치화하여 전달하여 주고 이 정보를 decoder는 사용하게 됩니다. 결과적으로 deocder는 출력단어를 더 정확하게 예측할 확률이 높아집니다.

Hard vs Soft Attention

Attention은 크게 Hard와 Soft로 나누어지는데 가장 큰 차이점은 hidden state의 weight를 계산하는 function이 differentiable한가이다. Encoder의 hidden state를 differentiate하여 cost를 구하고 이를 사용하여 모델을 학습시키는 Soft Attention과 달리 Hard Attention은 randomness가 포함되어있기때문에 differentiable하지 않다. 따라서 주로 Reinforced Learning을 사용하여 모델을 학습시킨다.

Global vs Local Attention

만약 decoder에서 추론을 할때 모든 input을 보고 결정한다면 Global Attention이다.

반대로 deocder에서 추론을 할때 input의 특정 부분만을 보고 결정한다면 Local Attention이다

Self Attention

Self Attention은 decoder의 state를 신경쓰지않고 input들 사이에서 각 timestamp때 어떤 input들에 더 높은 비중을 줘야될지를 결정한다. decoder없이 오로지 input들만으로 attention score를 계산하기때문에 구현이 쉽고 계산이 빠르며 decoder의 이전 state가 필요하지 않기때문에 한번에 다 계산해버릴 수 있다.

Reference:

Attention: https://wikidocs.net/22893

Seq2Seq: https://wikidocs.net/24996

Soft vs Hard Attention: https://stackoverflow.com/questions/35549588/soft-attention-vs-hard-attention

Self Attention: https://towardsdatascience.com/illustrated-self-attention-2d627e33b20a

Veraport와 같은 은행, 정부 홈페이지들을 들어가면 설치해야되는프로그램들을 찾아서 삭제해주는 프로그램입니다.

원본: https://teus.me/653

What is Entropy:

Entropy is the measure of impurity, disorder and uncertainty

In machine Learning: Average number of yes/no questions we need to guess the target class

How does entropy play?

Entropy controls how a Decision Tree decides to split the data. It actually effects how a decision tree draws its boundaries.

What is Information Gain:

Information Gain(IG) measures how much "information" a feature gives us about the class

Decision Tree Algorithm tries to split by attributes with highest Information Gain

https://www.youtube.com/watch?v=9r7FIXEAGvs

참고: https://medium.com/coinmonks/what-is-entropy-and-why-information-gain-is-matter-4e85d46d2f01

Decision Tree Learning은 데이터들의 모음으로부터 패턴을 추출하여 같은 규칙들 안에 들어가는 데이터들끼리 묶어 Decision Tree를 만들고, 이를 활용하여 새로운 데이터가 들어왔을때 데이터가 어떤 집합에 속하게 되는지를 판별함으로써 target을 예측하는 방법입니다.

위에 도표를 예시로 들자면,  가장 아래의 Leaf node를 먼저 살펴보겠습니다. Humidity <= 70의 노드에는 Play 2 Don't Play 0로 되어있는데, 이는 sunny한 날에 Humidity가 70이하인 경우에는 2번의 경기가 열렸는데 모두 Play를 했다는 뜻입니다. 이를 확장한다면 위 도표의 Decision Tree는 총 10개의 경기를 Decision Tree로 분류한 것이며 1차적으로 (sunny, overcast, rain)으로 분류를 하고, sunny는 (humidity <= 70, humidity > 70)으로, rain은 (Windy TRUE, Windy False)로 분류하였습니다. 이렇게 Decision Tree를 원래가지고 있는 dataset(10개)로 생성해놓으면 새로운 경기 데이터를 예측할 때, sunny, overcast, rain 중 어디에 속하는지를 판단하고, 그 뒤에 Humidity 혹은 Windy로 판별을 한다면 새로운 경기가 Play할지 Don't Play할지를 예측할 수 있게 되는 것입니다.

정리하자면, Decision Tree Learning은 기존의 dataset을 가지고, 분류가능한 특징을 가지고 classification tree를 생성하여 Decision Tree를 만들고, 이 tree를 사용하여 예측하는 것을 뜻합니다.

참고1 : https://en.wikipedia.org/wiki/Decision_tree_learning

참고2 : https://ratsgo.github.io/machine%20learning/2017/03/26/tree/

Object Detection이란, 여러 개의 사물이 포함되어 있는 이미지 안에서 각각의 물체의 종류를 판별하는 Image Classification과, 각각의 사물의 범위를 예측하는 Object Localization이 합쳐진 작업입니다.

Deep learning 이전의 기법들:

Sliding Window: 

여러가지 사이즈의 frame들을 움직이며 각각의 위치의 score를 계산하는 방법입니다. 계산의 횟수가 많아 속도 측면에서 비효율적입니다.

Selective Search:

영상의 계층적인 구조를 활용하여 탐색하고 그룹화하는 과정을 반복합니다.

Deep learning을 사용한 Object Detection

R-CNN:

Object Detection에 CNN을 적용한 첫 논문이며 selective search와 CNN을 결합한 방법론입니다. input image를 Selective Search를 사용하여 여러개의 영역으로 나누고, 각각의 영역들에 CNN을 적용하여 Classification을 수행하는 방법입니다.

1-Stage Object Detector(Fast R-CNN, Faster R-CNN):

Object Localization과 Image Classification이 동시에 진행되는 방법론. 속도가 빠르지만 정확도가 낮다.

2-Stage Object Detector(SSD, YOLO):

Object Localization과 Image Classification을 순차적으로 진행하는 방법론. 속도가 느리지만 정확도가 높다.

참고: https://hoya012.github.io/blog/Tutorials-of-Object-Detection-Using-Deep-Learning-what-is-object-detection/

Apache Beam

Apache Beam은 data processing pipeline을 정의할 수 있는 오픈소스 프로그래밍 모델이다. Apache Beam은 배치 프로세싱과 스트리밍 프로세싱을 모두 지원한다. Beam에서 pipeline을 정의한 후, Beam이 지원하는 Runner들(Spark, Apex, Flink, Google Dataflow) 중 하나를 사용하여 데이터를 처리하는 방식으로 각각의 Runner들을 사용하는 방법을 몰라도 Beam만을 사용해서 데이터를 처리할 수 있다.

Apache Beam은 Dataflow model paper를 따라 개발되었다. 여기서 Dataflow Model이란, 제한이없고 정렬되지않은 데이터셋들을 처리하기 위한 데이터의 관리 및 처리 프레임워크이다. 최근에는 끝이 없는 데이터들이 실시간으로 쏟아져들어오기때문에 이를 효율적으로 처리할 방법이 필요해졌다. 많은 어플리케이션들이 순서대로 들어온 정보를 처리후에는 순서가 뒤엉킨채로 내보낸다. 이를 앞에서 소개한 Dataflow model paper는 해결하기 위한 방법을 제시하였다.

Apache Airflow ( Google Cloud Composer )

머신러닝의 경우 데이터 전처리 > 학습 > 배포 > 예측의 단계를 통해 진행된다. 이 경우, 이전의 output이 다음의 input이 되는데, 이를 효율적으로 관리하기 위한 툴이 Apache Airflow이다. Apache Airflow는 파이썬 기반으로 만들어졌기때문에 데이터분석을 하는 분들도 쉽게 코드를 사용할 수 있다.

간단한 작업의 경우 cron을 사용하여 수행할 수 있지만, 디버깅이 어렵고 만약 에러가 발생했을때 재실행시킨다던지 하는 작업이 힘든데, apache airflow는 그런 작업들을 쉽게 UI를 사용하여 처리할 수 있게 해준다.

Airflow는 스케쥴링, 매니징 역할을 할뿐 실제로 데이터를 처리하지는 못한다.

          Cons:

            - Additional DB/Redis/Rabbitmq for Celery

            - Not dependent on data. just task dependency

Apache Atlas

Apache Atlas는 open metadata management와 governance 기능을 제공하여 사용자가 data assets들을 분류하고 카탈로그를 만들수있게 도와준다. 주로 Atlas는 Hadoop과 함께 사용되며 메타데이터를 효과적으로 교환할 수 있도록 도와준다. data가 순차적으로 처리될때도 classification이 유지된다. Atlas를 사용하면 업계 표준 요구사항을 유지하는 데 큰 도움이된다.

Classify된 metadat를 검색하기 위해 Solr를 사용한다.

Apache Beam vs Apache Airflow

두 프레임워크는 모두 작업이 순차적으로 진행하도록 보장해준다. 하지만 세부적으로 보면 큰 차이점이 있다.

- Airflow는 task management system으로 Directed Acyclic Graph(DAG)의 노드들이 순차적으로 실행되도록한다. 만약 A > B > C 로 이어진 DAG가 있다면, Airflow는 A가 작업을 마친 후에 B를 실행시키고, B의 작업이 모두 끝난 뒤에 C를 실행시킨다. 하지만 Beam은 dataflow engine으로써 A, B, C 노드를 모두 동시에 실행시키고 A의 결과물이 B로, B의 결과물이 C로 들어가도록 해준다.

- Airflow는 각각의 노드(task)들이 어떤작업을 하는지 전혀 신경을 쓰지않는다. Airflow는 단지 이 작업이 끝났는지, 혹은 실패했는지만을 본다. 따라서 만약 다음 노드로 현재 노드의 작업물을 전달해주어야한다면, 프로그래머가 직접 local file system에 저장하던지, 외부 서비스를 사용하던지해서 저장 및 로드를 처리해주어야 한다. 하지만, Beam의 각각의 task는 엔진에서 지원하는 프로그래밍 언어를 사용하여 Beam process안에서 수행할 작업을 정의해주어야한다. Beam process외부에서 데이터를 처리하는 것은 매우 어렵거나 불가능하다(Beam을 사용하는 이유에 맞지않다). Beam은 데이터를 처리하는 엔진이므로 데이터를 어떻게 처리할지만 정의하고나면, 각각의 step(task)들 간의 데이터 전달은 신경써주지않아도 framwork가 전부 처리해준다.

- Airflow는 그 자체로서 framwork이지만 Beam은 abstraction layer이다. Beam의 pipeline은 지원하는 runner들에게서 수행된다. Beam의 목표자체가 Beam만 배워서 여러가지의 backend들에서 실행할 수 있게하는 것이다.

- 가장 큰 차이점 중 하나는 Airflow는 하나의 단계가 끝난 후 다음 단계를 수행하는 방식이므로 data stream은 처리할 수 없다. stream은 끝나지 않기때문이다. Airflow의 공식 홈페이지에도 "Airflow는 data stream을 처리하기 위한 솔루션"이 아니다라고 명시되어있다.

(참고: https://stackoverflow.com/questions/50249759/apache-airflow-or-apache-beam-for-data-processing-and-job-scheduling)

Apache와 Nginx와 Tomcat 모두 유명한 Webserver framework들이다.

이 세가지 framework들을 간단하게 비교해보겠다. 비교는 Apache를 기준으로 하겠다.

Apache는 가장 오래된 Webserver framework들 중 하나로서, 모듈을 기반으로하는 구조를 가지고 있기때문에 커스터마이징이 자유롭다. 관리자들은 모듈들을 사용하여 새로운 기능들을 쉽게 도입할 수 있다. 또 .htaccess 파일을 편집하여 쉽게 설정을 바꿀 수 있다.

Apache Tomcat은 이름에서 알 수 있다시피, Apache를 개발한 개발사에서 만든 webserver이다. Tomcat의 가장 큰 차별점은 JAVA 어플리케이션을 위해서 만들어졌다는 점이다. Tomcat은 JVM이나 다른 JAVA 관련 라이브러리를 미리 로드해준다. 따라서 본인이 JAVA 어플리케이션을 호스팅하는 것이 아니라면 general-purpose HTTP server인 nginx나 apache를 사용하는 것이 더 적합하다.

Nginx는 2004년에 소개되었는데 이는 c10k problem을 해결하기위해 소개되었다. c10k problem이란 thread를 사용하여 user request를 처리하는 web server는 한번에 10000개 이상의 request를 처리할 수 없다는 문제이다. 이 문제를 해결하기 위해 nginx는 single thread로 master process가 여러개의 worker process들에게 request를 효율적으로 배분하는 방식으로 작동한다. 트래픽이 심한 웹사이트들은 nginx를 사용하는 것이 더 좋지만 그렇지 않은 경우에는 모듈을 임포트하여 쉽게 개발이 가능한 apache를 사용하는 것이 더 편리할 수 있다.

사이트에 ssl을 적용하지 않으면 안되는 상황이 많아지면서 nginx에서 요청을 받아 ssl을 풀고 실제로 요청을 처리하는 docker container로 전달하는 경우가 많아졌습니다. 작업을 하다가 이와 같은 경우에 어떻게 해야되는지를 정리해보았습니다

아래는 docker container들을 관리해주는 docker-compose.yml입니다.ㄷ

//docker-compose.yml
version: '2'

services:
  janus-gateway:
    image: janus-gateway
    environment:
      - DOCKER_IP=${DOCKER_IP}
  nginx:
    image: nginx:1.14.2
    container_name: nginx
    ports:
      - "8088:8088"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - /path/to/ssl:/ssl

    depends_on:
      - janus-gateway

실제로 요청을 처리하는 컨테이너는 janus-gateway이고, nginx는 단순히 ssl을 해제하여 맞는 포트로 포워딩만 시켜줍니다.

nginx가 외부에서 접근하는 8088포트를 바인딩하여 자신의 컨테이너의 8088포트로 보내줍니다.

//nginx.conf
http {
  server {
    listen              8088;
    ssl on;
    server_name         YOUR_DOMAIN;
    ssl_certificate     /path/to/certificate;
    ssl_certificate_key /path/to/key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
      proxy_redirect     off;
      proxy_set_header   Host $host;
      proxy_set_header   X-Real-IP $remote_addr;
      proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

      proxy_pass http://janus-gateway:8088;
    }
  }
}

그 후 nginx에서 nginx.conf에서 nginx가 docker-compose.yml에서 설정하였듯 외부포트의 8088로 접근하는 요청을 내부 8088포트로 돌려줬기때문에 `listen 8088`을 사용하여 내부포트 8088에 바인딩해줍니다.

ssl을 해제한 이후 http://<docker 컨테이너 이름>:<실제 포트>로 전달하여줍니다.

여기까지는 간단한데, 헷갈렸던 점이 위의 docker-compose.yml같이 janus-gateway 컨테이너에 아무 port가 명시되어있지 않으면 외부로부터 요청을 받지 못하는 줄 알았는데, 내부포트는 전부 열려있고, 단지 자체적으로 외부 포트로의 바인딩이 되어있지 않은점입니다. 따라서 외부포트로부터의 요청을 하나도 받지 못하지만 위처럼 nginx가 내부의 8088번 포트로 포워딩해주는 요청들은 전부 받을 수 있습니다.

또, 처음에는 이 사실을 몰랐기에:

//docker-compose.yml
version: '2'

services:
  janus-gateway:
    image: janus-gateway
    ports:
      - "9088:8088"
    environment:
      - DOCKER_IP=${DOCKER_IP}
  nginx:
    image: nginx:1.14.2
    container_name: nginx
    ports:
      - "8088:8088"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - /path/to/ssl:/ssl

    depends_on:
      - janus-gateway

//nginx.conf
http {
  server {
    listen              8088;
    ssl on;
    server_name         YOUR_DOMAIN;
    ssl_certificate     /path/to/certificate;
    ssl_certificate_key /path/to/key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
      proxy_redirect     off;
      proxy_set_header   Host $host;
      proxy_set_header   X-Real-IP $remote_addr;
      proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

      proxy_pass http://janus-gateway:9088;
    }
  }
}

위와 같이 docker-compose.yml에서 janus-gateway를 9088번 포트에서 요청을 받아서 실제로 요청을 처리하는 8088번 포트로 포워딩해주고(왜냐하면 8088번으로부터 외부에서 들어오는 요청에는 ssl이 적용되어있어 nginx에서 ssl을 해제하여 포워딩해주어야합니다), 외부에서 8088번포트로 들어오는 요청은 nginx에서 받아서 janus-gateway 컨테이너의 9088번 포트로 포워딩해주었습니다.

해보니 당연히 작동이 되지않았습니다. janus-gateway에서 바인딩한 9088번포트는 해당 컨테이너가 돌아가고있는 물리적인 머신의 9088번 포트로 들어오는 요청을 컨테이너의 8088번포트로 연결해주는 것이었기때문에, nginx에서 컨테이너의 9088번포트로 보내주어도, 요청을 받지 못합니다.