SO DATA

Airflow

Apache Airflow는 초기 에어비엔비(Airfbnb) 엔지니어링 팀에서 개발한 워크플로우(workflow) 오픈 소스 플랫폼

프로그래밍 방식으로 워크플로우를 작성, 스케줄링 및 모니터링

https://airflow.apache.org/

Airflow 아키텍처

Airflow의 구성요소

Webserver

Airflow의 로그, Scheduler에 의해 생성된 DAG 목록, Task 상태 등을 시각화(UI)

Scheduler

할당된 work들을 스케줄링. 예약된 워크플로우들을 실행(트리거링)하기 위해 executor에게 task 제공 

Executor

실행중인 task 핸들링. default로는 scheduler에 할당된 모든 task 실행시키지만, production 수준에서는 실행할 task worker에 push

Workers

실제 task 실행하는 주체

Metadata Database

DAG, Task 등의 metadata 저장 및 관리

DAG Directory 

DAG 저장

Airflow 주요 개념

DAG(Directed Acyclic Graph)

• 비순환 그래프(사이클x)로써, 노드와 노드가 단방향으로 연결.
• Airflow에서는 DAG 이용해 워크플로우를 구성하고 어떤 순서로 task를 실행시킬 것인지, dependency를 어떻게 표현할지 결정 
• 순차적으로 task실행되며, 논리적 오류 발생 시 교착상태(deadlock) 발생

• 일반적으로 python 코드로 정의하며 $AIRFLOW_HOME/dags에 위치
  • dags 폴더의 .py 이름에 'airflow', 'dag' 단어 포함 시 Web UI에 표시
• $AIRFLOW_HOME/airflow.cfg 파일에서 변경

Operator

• DAG 동작 시 실제로 실행되는 task 결정(정의)
• Operator Type
  • Action Operator
    • 기능이나 명령 실행
    • 실제 연산 수행, 데이터 추출 및 프로세싱
    • 참고: https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/index.html
  • Transfer Operator
    • 하나의 시스템에서 다른 시스템으로 옮김(ex. 데이터를 Source에서 Destination으로 전송)
  • Sensor Operator
    • 조건 만족할 때까지 기다리다가 충족 시 다음 task 실행

Task & Task Instance

• Task: 데이터 파이프라인에 존재하는 Operator 의미
  • Operator 실행 시 task됨
• Task Instance: 데이터 파이프라인 trigger되어 실행 시 생성된 task
• task 실행 순서 정의
  • 각 task는 ">>", "<<", "[]" 이용해 task의 의존성 정의하며 dag 그림

Task와 Operator

• 사용자 관점에서 두 용어는 같은 의미지만 task는 작업의 올바른 실행을 보장하기 위한 manager
• 사용자는 operator 사용해서 수행할 작업에 집중하며, airflow는 task를 통해 작업 올바르게 실행
  • 사용자는 각 환경별 작업이 잘 이루어지는지 확인하기 위해 operator 내 코드 구성에 집중
  • airflow는 각 operator 내의 구성 요소들이 전부 잘 맞아야 작업이 이루어지는 형태

Airflow 기본 동작 원리

1. 유저가 DAG 작성
   • dags 폴더 아래에 py파일 배치
2. Webserver와 Scheduler가 DAG 읽어옴
3. Scheduler가 Metastore 이용해 DagRun 오브젝트 생성
   • DagRun은 사용자가 작성한 DAG인스턴스 (DagRun Status: Running)
4. Scheduler는 DagRun 오브젝트의 인스턴스인 Task Instance Object 스케줄링
5. 트리거의 조건이 맞으면 Scheduler가 Task Instance를 Executor로 보냄
6. Executor는 Task Instance 실행
7. 작업 완료 후 Metastore에 보고
   • 완료 Task Instance는 DagRun에 업데이트됨
   • Scheduler는 DAG 실행 완료 여부를 Metastore 통해 확인 후 DagRun 상태 바꿈(DagRun Status: Completed)
8. Metastore가 Webserver에 업데이트하여 사용자도 확인

DAG 코드 구조

Python 코드로 정의하는 DAG 구조

라이브러리 임포트

DAG와 워크플로우 구성에 필요한 라이브러리 선언

공통 변수 정의

DAG 구성에 사용하기 위해 공통으로 사용하는 변수 정의. 변경 자주 발생 시 Variable 기능 활용

DAG 공통 속성값 정의

DAG 정의 시 필요한 공통 속성 값 정의

DAG 정의

DAG 선언하고 공통 속성값 전달

Task 정의

DAG에 포함될 각 작업(task) 정의. Operator, Sensor, Hook 등 사용

Task 배열

각 작업(Task)들의 순서 나열. '<<', '>>' 같은 Shift 연산자 사용. set_upstream, set_downstream 함수도 사용 가능 

ex.

# dags/branch_without_trigger.py
import pendulum

from airflow.decorators import task
from airflow.models import DAG
from airflow.operators.empty import EmptyOperator

dag = DAG(
    dag_id="branch_without_trigger",
    schedule="@once",
    start_date=pendulum.datetime(2019, 2, 28, tz="UTC"),
)

run_this_first = EmptyOperator(task_id="run_this_first", dag=dag)


@task.branch(task_id="branching")
def do_branching():
    return "branch_a"


branching = do_branching()

branch_a = EmptyOperator(task_id="branch_a", dag=dag)
follow_branch_a = EmptyOperator(task_id="follow_branch_a", dag=dag)

branch_false = EmptyOperator(task_id="branch_false", dag=dag)

join = EmptyOperator(task_id="join", dag=dag)

run_this_first >> branching
branching >> branch_a >> follow_branch_a >> join
branching >> branch_false >> join

Airflow 장단점

장점

• Python 코드를 이용해 파이프라인 구현하므로 Python에서 구현할 수 있는 대부분의 방법 사용하여 복잡한 파이프라인 생성 가능
  • Python 기반으로 쉽게 확장 가능하며 다양한 시스템과 통합 가능 (다양한 유형의 DB, Cloud Service 통합 가능)
• 데이터 인프라 관리, 데이터 웨어하우스 구축, 머신러닝/분석/실험에 사용할 데이터 환경 구성에 유용
• 스케줄링 기능으로 DAG에 정의된 특정 시점에 트리거 가능하며 최종 시점과 다음 스케줄 주기 상세히 알려줌
• 백필 기능 사용하면 과거 데이터 손쉽게 재처리 가능하여 코드 변경 후 재생성 필요한 데이터 재처리 가능

단점

• Python에 익숙하지 않으면 DAG 구성 어려움
• 초기 설치는 간단해보여도 작은 환경 변화에 오류 발생하는 경우 있어 롤백 잦음

주의사항

• Data Streaming Solution 적용에 부적합
  • 초단위(그 이하) 데이터 처리 필요한 경우 사용에 부적합
  • airflow는 반복적이거나 배치 테스크를 실행하는 기능에 초점 맞춰져 있음
• Data Processing Framework (Flink, Spark, Hadoop 등) 로 사용 부적절
  • 데이터 프로세싱 작업에는 최적화 되어있지 않아 매우 느림
  • 경우에 따라 메모리 부족 발생
    • SparkSubmitOperator와 같은 operator 이용하여 데이터 프로세싱은 Spark와 같은 외부 Framework로 처리
• 파이프라인 규모 커질 시 Python코드 복잡해질 수 있음 -> 초기 사용 시점에 엄격한 관리 필요

ELK스택의 대표 수집 도구 Logstash(2012 출시)와 OpenSearch의 수집 도구 Data Prepper(2021 출시)의 비교

비교 항목

• High-level diagram
• Overview
• Components
• Usage 

High-level diagram

Logstash

Data Prepper

Overview

Logstash

Logstash는 다양한 소스에서 데이터를 수집하고 변환 후 원하는 '저장소'로 보내는 무료 개방형 서버 측 데이터 처리 파이프라인

• 수많은 파이프라인 패턴을 구축할 수 있도록 해주는 수많은 전투 테스트를 거친 수집 프레임워크. 한 파이프라인의 출력을 다른 파이프라인으로 연결할 수 있는 옵션과 함께 많은 입력, 필터, 출력을 허용
• HTTP/TCP/CSV에서 GCS/AWS S3/Elasticsearch에 이르기까지 다양한 데이터 소스에서 읽고 쓸 수 있는 방대한 입력 및 출력 플러그인 카탈로그 존재
• 내구성 측면에서 Logstash는 전송할 수 없는 요청을 일시적으로 버퍼링하는 영구 큐(Persistent Queue)와 수집에 실패한 문서를 처리하기 위한 데드 레터 큐(Dead Letter Queue) 제공

Data Prepper

Data Prepper는 다운스트림 분석 및 시각화를 위해 데이터를 필터링, 보강, 변환, 정규화 및 집계할 수 있는 서버 측 데이터 수집기

• OpenSearch의 공식 수집 도구로써 소스, 버퍼, 프로세서, 싱크와 같은 유사한 개념을 사용하여 하나의 소스에서 읽고 여러 데이터 싱크 가능하게 함
•  소스/프로세서/버퍼 카탈로그는 Logstash에 비해 제한적이지만 Logstash configuration 파일의 실행을 지원하며(실행 가능한 구성 제한적) 로그 및 트레이스를 위한 OpenTelemetry와의 통합 지원
• OpenTelemetry 수집기를 활용하는 OpenSearch 분산 추적(distributed tracing)지원 제공 (Logstash는 미지원)

Components

Logstash

Input plugins (총 56개)

다양한 소스로부터 문서를 수집할 수 있게 해주는 데이터 input entrypoint

Filter plugins (총 47개)

선택 사항이며, 필드 제거와 같은 간단한 작업부터 사용자 정의 루비 코드 허용에 이르기까지 Logstash가 데이터 처리를 할 수 있게 해줌

Output plugins (57개)

파이프라인의 끝. 하나 또는 여러 개 정의 필요

Persistent Queue (PQ)

Logstash가 데이터 손실을 방지하고 이벤트를 디스크에 저장하여 재시작 후 복구 가능하며 출력에서 처리할 수 없는 메시지 버스트 흡수 가능.

이벤트가 메모리에서 처리되기 때문에 기본적으로 비활성화 되어있는 기능으로, 활성화 시 수집 속도 느려짐

Dead Letter Queue (DLQ)

코드 400 또는 404로 수집에 실패한 문서에 특정 파이프라인(입력-필터-출력)을 설정하여 문제를 해결한 다음 다시 수집 시도 가능.

데이터 손실 없이 문서의 오류를 수정할 수 있기 때문에 매우 편리하지만 기본적으로 비활성화 되어있으며 Elasticsearch output에서만 지원

Data Prepper

Source (5개)

Logstash에 비해 사용 가능한 소스가 훨씬 적으며, Logstash의 Kafka, JDBC, Syslog 및 FIlebeat 입력 소스 사용 불가.

Fluentd와 같은 대체 로그 수집기로 s3, http_source 소스와 함께 사용 가능 

Buffer

이벤트를 누적하며 사용자 지정 버퍼를 만들기로 결정한 경우 메모리 또는 디스크 사용 가능하지만 현재 in-memory bounded blocking buffer만 사용 가능. s3 버킷을 통해 로그를 소비 시 Data Prepper 내부에서 버퍼링 안할 수 있음

Processor

Logstash 필터와 동일한 목적을 수행하며 이벤트 데이터를 필터링, 변환, 보강하는 기능 제공

사용 가능 filter/processor 비교

일반적으로 Logstash의 기능이 더 강하지만, Data Prepper에는 OpenTelemetry 및 이상 징후 탐색 프로세서(anomaly detection processors) 사용 가능. 이벤트가 사용해야 하는 싱크를 결정하는 조건을 정의하는 데 사용할 수 있는 "routes" 프로세서도 존재.

SInk (4개)

Data Prepper가 데이터를 쓰는 위치를 정의

Dead Letter Queue (DLQ)

실패한 문서를 특수 형식의 JSON 배열로 s3 버킷에 저장 가능

dlq-v${version}-${pipelineName}-${pluginId}-${timestampIso8601}-${uniqueId}

현재 s3 소스에서만 사용 가능

Usage

아래 로그 파일을 읽을 때 Logstash와 Data Prepper usage 비교

[2023-05-15 08:22:35][INFO][192.168.1.10] – User ‘gustavo llermaly’ successfully logged in.
[2023-05-15 08:23:05][INFO][192.168.1.10] – User ‘gustavo llermaly’ visited ‘/my-account’.
[2023-05-15 08:24:30][ERROR][192.168.1.10] – System crashed while user ‘gustavo llermaly’ was active.

Logstash

일반적으로 호스트에 FileBeat 설치해 로그 파일을 읽은 다음 Logstash로 전송 (file input 플러그인 사용해 직접 읽기 가능)

Data Prepper

Logstash Flow와 유사하지만 데이터 수집기로 Filebeat를 사용하는 대신, HTTP 소스를 사용해 로그를 Data Prepper로 전송하는 FluentBit 사용

Conclusion

• Logstash가 더 많은 플러그인과 다중 필터 입출력을 수행할 수 있는 기능으로 더 많은 유연성 제공
• Logstash는 더 강력한 dead letter queue와 persistent queue 시스템 갖춤
• Data Prepper는 로그와 트레이싱을 위한 도구를 제공에 초점을 맞춤
• Data Prepper는 이상 징후 탐색 프로세서(anomaly detection processor)와 OpenTelemetry 통합을 위한 APM 지원
• Data Prepper는 부분적으로 Logstash 파일 사용 지원
• OpenSearch 사용 시 Data Prepper는 Apache 2.0 오픈 소스 라이선스에 따라 계속 개발되고 있어 OpenSearch와의 호환 보장되지만 Logstash의 경우 7.16.2 이상의 버전 사용 불가 

이미 Logstash 사용중인 사용자들은 전환 전 Data Prepper에 더 많은 Logstash기능이 나타날 때 까지 기다리는게 좋으나, 새로 시작하는 사용자는 Data Prepper가 OpenSearch와 장기적으로 호환이 가능하니 고려 필요

출처: https://opster.com/guides/elasticsearch/data-architecture/data-prepper-vs-logstash/

Jenkins에서 제공하는 helm chart를 이용하여 kubernetes 환경에서 Jenkins 및 agent 구축 및 운영

참고: https://github.com/jenkinsci/helm-charts/tree/main/charts/jenkins

1. Helm repository 추가 및 업데이트

helm repo add jenkins https://charts.jenkins.io
helm repo update

2. values.yaml 이용하여 jenkins 환경 설정

helm chart에서 제공하는 value 옵션을 참고하여 values.yaml 파일을 생성해 필요한 설정을 적용한다

value 옵션 참고: https://github.com/jenkinsci/helm-charts/blob/main/charts/jenkins/VALUES_SUMMARY.md

주요 설정 옵션

kubernetes 클러스터 관련

# For FQDN resolving of the controller service. Change this value to match your existing configuration.
# ref: https://github.com/kubernetes/dns/blob/master/docs/specification.md
clusterZone: "cluster.local"

# The URL of the Kubernetes API server
kubernetesURL: "https://kubernetes.default"

설치할 kubernetes의 클러스터의 도메인 및 API 서버 정보 적용

KST timezone 설정

controllers:
  containerEnv:
    - name: TZ
      value: "Asia/Seoul"
  initScripts: 
    - |
      System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'Asia/Seoul')
      System.setProperty('user.timezone', 'Asia/Seoul')

jenkins의 default timezone이 UTC이기 때문에, KST 기준으로 변경하기 위해 위의 설정 필요

• initScripts로 jenkins에 jvm 옵션을 적용하여 시스템 전체의 timezone을 Asia/Seoul(KST) 로 변경
• 시스템 설정을 변경하더라도 job 생성 시 주기적 실행을 위해 Build periodically - Schedule에 crontab으로 정의 시 UTC 기준으로 동작하므로, KST 기준으로 동작하게 하려면 TZ=Asia/Seoul 추가 필요

• containerEnv로 controller 환경변수에 TZ="Asia/Seoul"을 설정해줄 경우 Schedule crontab이 KST기준으로 동작하여 별도의 timezone 설정 필요 없음

agent 설정

agent:
  enabled: true
  defaultsProviderTemplate: ""
  # URL for connecting to the Jenkins controller
  jenkinsUrl:
  # connect to the specified host and port, instead of connecting directly to the Jenkins controller
  jenkinsTunnel:
  ...

agent 옵션의 enabled 설정을 true로 적용할 경우, job 실행 시 지정 옵션대로 agent pod이 동적으로 생성되어 해당 pod에서 job 실행

※ agent pod를 별도로 띄워놓고 동작시키고 싶을 경우 별도의 pod(deployment) 생성해 controller와 연결 가능 (아래 별도 설명)

3. helm 배포로 jenkins 구축

helm install jenkins jenkins/jenkins . -f values.yaml -n jenkins
 
 
NAME: jenkins
LAST DEPLOYED: Sat Nov  11 12:00:57 2023
NAMESPACE: jenkins
STATUS: deployed
REVISION: 1
NOTES:
1. Get your 'admin' user password by running:
  kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/additional/chart-admin-password && echo
2. Get the Jenkins URL to visit by running these commands in the same shell:
  echo http://127.0.0.1:8080
  kubectl --namespace jenkins port-forward svc/jenkins 8080:8080

3. Login with the password from step 1 and the username: admin
4. Configure security realm and authorization strategy
5. Use Jenkins Configuration as Code by specifying configScripts in your values.yaml file, see documentation: http:///configuration-as-code and examples: https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos

For more information on running Jenkins on Kubernetes, visit:
https://cloud.google.com/solutions/jenkins-on-container-engine

For more information about Jenkins Configuration as Code, visit:
https://jenkins.io/projects/jcasc/


NOTE: Consider using a custom image with pre-installed plugins

NOTES 대로 kubectl 명령어를 실행해주면 jenkins 접속 시 admin의 password 확인할 수 있으며, 임의의 password를 지정하고 싶으면 values.yaml에  adminPassword를 지정해주면 됨

jenkins UI 접속도 마찬가지로 아래 명령어를 통해 port-forward해 http://127.0.0.1:8080 으로 접속 가능하며, values.yaml의 serviceType 옵션을 변경하거나, ingress를 enabled: true 로 활성화 및 옵션 지정하여 url설정 및 접속 가능하게 함  

4. agent pod 생성 및 controller 연결

1. Jenkins 관리 > Nodes > New Node에서 노드명, type 지정해 신규 노드 설정 생성

노드 설정 예시

• 노드명: default-agent
• Type: Permanent Agent
• Remote root directory: /home/jenkins
• Labels: default-agent
• Usage: Use this node as much as possible 
• Launch method: Launch agent by connecting it to the controller

2. 생성된 노드늘 눌러 상세 화면으로 들어간 후 agent의 command 라인의 secret 옵션값 복사

3. agent pod생성 후 controller와 연결해 job을 실행하기 위한 deployment yaml (default-agent.yaml) 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "jenkins-inbound-default-agent"
  labels:
    name: "jenkins-inbound-default-agent"
  namespace: "jenkins"
spec:
  replicas: 1
  selector:
    matchLabels:
      name: "jenkins-inbound-default-agent"
  template:
    metadata:
      labels:
        name: "jenkins-inbound-default-agent"
    spec:
      containers:
      - name: inbound-default-agent
        env:
        - name: "JENKINS_SECRET"
          value: "5d9a52efc22d85f3ed27c81c99c8434dfe05445bd38f0801fc545f3a1564e30d"
        - name: "JENKINS_TUNNEL"
          value: "jenkins-agent.jenkins.svc.cluster.local:50000"
        - name: "JENKINS_AGENT_NAME"
          value: "default-agent"
        - name: "JENKINS_NAME"
          value: "default-agent"
        - name: "JENKINS_AGENT_WORKDIR"
          value: "/home/jenkins/agent"
        - name: "JENKINS_URL"
          value: "http://jenkins.jenkins.svc.cluster.local:8080/"
        image: "jenkins/inbound-agent"
        imagePullPolicy: "Always"
        resources:
          limits:
            memory: "1Gi"
            cpu: "1024m"
          requests:
            memory: "1Gi"
            cpu: "1024m"

• 위에서 복사한 secret 값을 JENKINS_SECRET 환경변수 값으로 적용

4. kubectl 명령어로 default-agent.yaml apply해 pod 생성

kubectl apply -f default-agent.yaml -n jenkins

5. 노드 생성 및 연결 확인

6. job 생성 시 label에 해당 노드의 label 적용해 지정 노드에서 job 실행 가능

OpenSearch란? 

2021년 1월 21일, Elastic에서 Elasticsearch와 Kibana의 Apache 2.0 라이선스 소스 코드를 Elastic License 및 SSPL 1.0에 따라 이중 라이선스로 전환(7.11 릴리즈부터 적용)

해당 라이선스는 오픈 소스가 아니며 사용자에게 동일한 자유를 제공하지 않음

 

https://www.elastic.co/kr/pricing/faq/licensing 

 

기존의 오픈소스 코드를 기본으로 Open Distro for Elasticsearch 플러그인을 개발하여 고급 보안, 이벤트 모니터링 및 알람 등의 기능을 지원하던 AWS는 Elasticsearch 및 Kibana의 마지막 OpenSource 버전(7.10)을 포크하여 OpenSearch라는 이름으로 Apache 2.0 라이선스로 Github에 오픈.

 

 

OpenSearch는 Apache 2.0 라이선스 하에 제공되는 분산형 커뮤니티 기반 100% 오픈 소스 검색 및 분석 제품군으로, 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사례에 사용.

 OpenSearch는 데이터 탐색을 쉽게 해주는 통합 시각화 도구 OpenSearch 대시보드와 함께 대량 데이터 볼륨에 빠르게 액세스하고 응답하며 뛰어난 확장성을 지닌 시스템을 제공.

Apache Lucene 검색 라이브러리로 구동되며 k-nearest neighbors(KNN) 검색, SQL, Anomaly Detection, Machine Learning Commons, Trace Analytics, 전체 텍스트 검색 등 다수의 검색 및 분석 기능을 지원하며, 원하는 방식으로 사용, 수정, 확장, 수익화, 재판매가 가능한 100% 오픈 소스 제품

K8S OpenSearch 클러스터 구축 

Helm은 Kubernetes 클러스터에서 애플리케이션을 손쉽게 배포하기 위해 사용되는 패키징툴이며, OpenSearch 또한 OpenSearch Project Helm-Charts를 이용하여 쉬운 설치와 관리 가능

https://github.com/opensearch-project/helm-charts

1. Helm repository 추가 및 업데이트

helm repo add opensearch https://opensearch-project.github.io/helm-charts/
helm repo update

2. nodetype 별 yaml 파일 작성

helm install 시 반영할 nodetype(master, coordinator, data)별로 custom yaml 파일을 작성하여 Release 구분

https://opensearch.org/blog/setup-multinode-cluster-kubernetes/ 

master.yaml

clusterName: "opensearch-cluster"

 nodeGroup: "master"

 masterService: "opensearch-cluster-master"

 roles:
   master: "true"
   ingest: "false"
   data: "false"
   remote_cluster_client: "false"

 replicas: 1

data.yaml

clusterName: "opensearch-cluster"

 nodeGroup: "data"

 masterService: "opensearch-cluster-master"

 roles:
   master: "false"
   ingest: "true"
   data: "true"
   remote_cluster_client: "false"

 replicas: 1

client.yaml (coordinator)

 clusterName: "opensearch-cluster"

 nodeGroup: "client"

 masterService: "opensearch-cluster-master"

 roles:
   master: "false"
   ingest: "false"
   data: "false"
   remote_cluster_client: "false"

 replicas: 1

3. yaml 파일 이용해 helm 배포

helm install opensearch-master opensearch/opensearch -f  usr/data/master.yaml
helm install opensearch-data opensearch/opensearch -f  usr/data/data.yaml
helm install opensearch-client opensearch/opensearch -f  usr/data/client.yaml

※ 구축 시 발생 가능 이슈

- vm.max_map_count 관련 에러

ERROR: [1] bootstrap checks failed [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

• yaml파일에 아래 옵션 적용 후 install

sysctl:
  enabled: true

sysctlVmMaxMapCount: 262144

- 클러스터 생성 후 바로 접속 시 unauthorized 메세지 발생하며 접속 불가할 경우

• master 노드 접속해 /usr/share/opensearch/plugins/opensearch-security/tools 경로 아래의 securityadmin.sh 실행해 security index 생성 후 접속 가능

cd /usr/share/opensearch/plugins/opensearch-security/tools
./securityadmin.sh -cd ../securityconfig/  -icl -nhnv \
   -cacert ../../../config/root-ca.pem \
   -cert ../../../config/kirk.pem \
   -key ../../../config/kirk-key.pem

4. opensearch dashboard 배포 및 클러스터 UI 접속

helm install dashboards opensearch/opensearch-dashboards

Elasticsearch Enrich processor

Elasticsearch 7.5부터 이미 인덱싱되어 있는 인덱스들의 데이터를 새로 인덱싱되는 데이터에 원하는대로 추가하는 Enrich 작업 가능

주요 활용 사례

• IP address를 통해서 연관된 디바이스나 서비스 정보들 추가
• 상품 주문 데이터의 Product ID를 통해서 상세 제품 정보 데이터 추가
• 이메일 주소를 통해서 상세 컨택 포인트 정보 추가
• GPS의 정보를 통해서 우편 번호 정보 추가

주의 사항

• Enrich processor가 여러 작업을 수행하며 수집 파이프라인의 속도에 영향을 줄 수 있으므로, 프로덕션 환경에 배포하기 전 테스트 실행해 벤치마킹할 것을 권장
• 실시간 데이터를 추가하는 데는 수집 프로세서를 사용하지 않는 것이 좋으며, 수집 프로세서는 자주 변경되지 않는 참조 데이터에서 가장 잘 동작

Ingest node

elasticsearch에 데이터를 인덱싱하기 전에 다양한 전처리를 할 수 있는 메커니즘을 제공하는 노드 타입으로써

Enrich processor 설정 시 해당 노드 타입에서 프로세스 실행

모든 노드 타입의 default가 ingest 가능으로 설정되어 있으며, elasticsearch.yml 파일에서 disable 가능

node.ingest: false

Ingest Pipeline

다양한 프로세서(Processors)로 파이프라인(Ingest Pipline)을 구성해서 순차적으로 데이터를 처리한 후 es에 인덱싱

• 데이터의 전처리 위해 전처리 processor가 지정된 pipeline 정의
• elasticsearch 7.8부터 ingest data를 쉽게 관리하기 위해 kibana의 management에 Ingest Node Pipelines 추가됨
  • 모든 데이터 파이프라인을 하나의 테이블에서 볼 수 있음
  • JSON 에디터를 이용해 파이프라인 생성, 삭제, 편집 가능

How the enrich processor works

Ingest pipeline이 인덱싱 전의 데이터 변환

• Ingest pipeline의 정의된 processor들의 인덱싱 되는 데이터들을 대상으로한 변환 작업이 끝나면 target 인덱스에 해당 document 추가됨
• 대부분 processor들 해당 문서의 변환 작업만 수행하지만, enrich processor는 들어오는 문서들에 새로운 데이터를 추가하는 작업 수행 

Enrich Pipeline 구성

1. prerequisites 확인

security 사용 시 권한/롤 설정 필요

1. read index privileges for any indices used
2. The enrich_user built-in roleAdd enrich data

2. Source Index 생성

source index의 document는 incoming 문서에 추가하려는 enrich data가 포함되어야 하며, 
문서 및 인덱스 API를 사용해 source index 관리 가능 (일반 인덱스와 동일)

3. Enrich Policy 생성

source 인덱스를 대상으로 Enrich Policy 정의 및 생성

PUT /_enrich/policy/my-policy
{
  "match": {
    "indices": "users",
    "match_field": "email",
    "enrich_fields": ["first_name", "last_name", "city", "zip", "state"]
  }
}

• policy type : enrich policy 정의
  • geo_match: geo_shape_query를 기반 (지리 정보 관련된 incoming 문서에 적용 시 사용)
  • match: term 쿼리 기반
  • rangeMatch: range 쿼리 기반 (숫자, 날짜, IP주소 관련 incoming 문서 매치 시 사용)
• indices: 같은 match_field를 공유하는 source index 여러개 정의 가능
• match_field: incoming 문서에 사용될 source 인덱스의 필드
• enrich_field: incoming 문서에 추가될 필드 정의. source 인덱스에 반드시 존재해야 함
• query (optional): enrich index에서 매칭 시 필터링 쿼리 정의 (default: match_all

주의사항

생성된 enrich policy는 업데이트나 변경 불가하므로, 변경 필요 시 아래 작업 수행

1. 신규 enrich policy 생성 및 실행
2. 사용 중인 enrich processor의 기존 enrich policy를 신규 policy로 대체 
3. delete api 사용해 기존 enrich policy 삭제

4. Enrich Policy 실행

enrich policy를 execute API로 실행해 enrich 인덱스 생성

PUT /_enrich/policy/my-policy/_execute

enrich 인덱스에는 source 인덱스에 있는 문서가 포함되며, enrich 인덱스는 항상 .enrich-*로 시작하고 읽기 전용이며 강제 병합(force merge) 됨

5. enrich processor 정의 및 ingest pipeline에 추가

PUT _ingest/pipeline/my_pipeline_id
{
  "description" : "describe pipeline",
  "processors" : [
    {
      "enrich" : {
        "policy_name": "enrich-policy",
        "field" : "enrich_field",
        "target_field": "enrich_target_field",
        "max_matches": "1"
      }
    }
  ]
}

• enrich processor
  • policy_name: 위에서 정의한 enrich policy
  • field: 새로 인덱싱되는 data에서 매칭될 필드 정의
  • target_field: enrich data가 포함될 필드 이름 정의. 해당 필드에 enrich data가 json array 형식으로 추가
  • max_matches: target_field에 추가될 json array 길이 제한 

6. Ingest and enrich documents.

Index template에 위에서 생성한 pipeline 추가해 적용

PUT _template/index_template
{
  "settings" : {
    "index": {
      "default_pipeline": "my_pipeline_id",
       ...
    }
  }
}

참고 문서 : https://www.elastic.co/guide/en/elasticsearch/reference/7.x/enrich-setup.html#create-enrich-source-index

Apache 라이센스 버전의 기능 배포판인 Elasticsearch OSS 버전과 Opensearch 비교

여유 자금이 있다면 ElasticSearch를 사용하는 것이 더 쉬운 접근 방식이 될 수 있으나, 예산 절약이 목적이라면 OpenSearch

참고 문서: https://dattell.com/data-architecture-blog/opensearch-vs-elasticsearch/

• 검색 시 동의어가 사용되는 이유 및 방법
• 아파치 루씬
• 순방향 신경망의 기초
• word2vec 알고리즘 사용
• word2vec 사용해 동의어 생성

동의어(synonyms): 정보 검색 시 쿼리에 따른 관련 결과 개수 늘리는데 사용하는 일반적인 기법

2.1 동의어 확장

동의어 확장(synonym expansion): 같은 정보 여러 가지 방법으로 표현할 수 있도록 하는 기술

2.1.1 왜 동의어인가?

동의어(synonyms): 철자와 발음은 다르지만 의미가 같거나 아주 비슷한 단어 (ex. aircraft(항공기)와 airplane(비행기)는 모두 'plane'이라는 단어의 동의어)

• 적절한 쿼리가 일치할 확률을 높임 -> 너무 적거나 아무런 결과도 나오지 않게 하는 쿼리 수 줄어듦
• 재현율 개선(recall) - 관련성 높음
• 색인화 시 동의어 확장하면 색인화 속도가 느려지고 색인디 더 커지지만 검색 속도는 빨라짐
  • 크기와 부하가 증가함에 따라 시스템의 성능에 현저한 영향 미침

2.1.2 어휘 기반 동의어 일치

ex. music is my aeroplane

1. 토크나이저가 토큰 생성(화이트 스페이스 기준) ('music', 'is', 'my', 'aeroplane')
2. 토큰 필터 사용해 수신된 각 토큰의 동의어 어휘를 살펴보고 키워드 있는지 확인

   • 용어	문서(위치)
     aeroplane	1(12, 17)
     aircraft	1(12, 17)
     airplane	1(12, 17)
     is	1(6, 8)
     music	1(0. 5)
     my	1(9, 11)
     plane	1(12, 17)

     • 특정 문서에서 해당 용어가 출현하는 위치에 대한 정보 기록
     • 'plane', 'airplane', 'aircraft'용어가 원래 용어인 'aeroplane'에 첨부된 정보와 동일한 위치로 색인 추가됨
     • 용어의 위치(position)를 역색인에 기록  - music is my aeroplane/aircraft/airplane/plane
       • music is my aeroplane
       • music is my aircraft
       • music is my airplane
       • music is my plane
         • 네 가지 다른 형태(form). 이 중 하나라도 일치하면 오직 하나의 문서만을 검색 엔진이 반환

아파치 루씬: 자바로 작성된 오픈 소스 검색 라이브러리

•  Document(문서): 색인화하고 검색할 수 있는 주요 실체. 사용 사례에 따라 페이지, 책, 단락 이미지 등
  • 다른 부분을 파악하는 데 사용할 수 있는 다수의 Field들로 구성(페이지 제목, 페이지 내용 등)
    • 필드별 텍스트 분석 파이프라인 구성 가능
    • 용어 위치 또는 각 용어가 참조하는 원본 텍스트의 값을 게시 목록에 저장할지 등의 색인화 옵션 구성 가능
•  Directory 통해 접근- 역색인이 유지되는 파일 목록 (역색인 저장)
• IndexReader: 검색 엔진의 대상 경로에서 디렉토리 열기
• IndexSearcher: 검색 및 결과 수집
• Analyzer: 텍스트 분석 작업 수행하는 API. Tokenizer 및 TokenFilter 컴포넌트로 구성 가능
• IndexWriter: IndexWriterConfig에 따라 역색인을 디렉토리의 디스크에 기록

동의어 확장을 통해 루씬 색인 설정

1. 색인 시간 및 찾기 시간에 텍스트 분석에 사용할 알고리즘 정의
   • 모두 동일한 토크나이저 사용하는 것이 대체로 더 좋으므로 텍스트는 동일한 알고리즘에 따라 분할
2. 설정
   • 화이트스페이스 토크나이저(whitespace tokenizer, 화이트스페이스 문자 마주쳤을 때 토큰 분할) 토크나이저 사용하는 찾기 시간 Analyzer
   • 화이트스페이스 토크나이저 및 동의어 필터를 사용하는 색인 시간 Analyzer
     • 쿼리 시간과 색인 시간 모두에 동의어 확장이 필요하지 않음

검색 엔진에서 대부분의 경우 가벼운 문서 구조를 유지하는 것이 좋음

• 각 속성(author, title, year, album, text)에 대한 필드 정의 가능
• 서로 다른 부분에 다른 Analyzer 사용해 보고, 데이터의 말뭉치에 대한 최적의 조합 찾기 전 여러번 변경이 일반적
• 시간이 지남에 따라 조정 필요

동의어 파일 작성 - 파일 변경되어도 코드 변경할 필요 없이 그대로 유지 가능 및 언제든 필요할 때 파일 갱신 가능

• WordNet프로젝트: 프린스턴 대학교의 영어 어휘 데이터페이스. 대규모 동의어 어휘집 이용 가능
  • 모든 언어에 사용 불가
  • 외연(denotation, 즉 외적 형식 또는 겉으로 드러난 의미)을 기반으로 하였기 때문에 단어가 문맥에 따라 정의되는 내포(connotation, 즉 내적 의미 및 함축된 의미)가 고려되지 않음 -> word2Vec 유용

2.2 맥락의 중요성

동의어 매핑(mapping, 즉 대응)의 한계: 정적이며, 색인화된 데이터에 구속되지 않음

• 단어 자체와 동시에 출현하는 인접 단어의 패턴 분석해 최근접 이웃(nearest neighbor) 추출
  • 문법적 관점에서 동의어가 아니더라도 동의어로 간주
• 분포 가설(distributional hypothesis): 같은 맥락에서 사용되고 발생하는 단어들이 유사한 의미를 갖는 경향이 있다는 생각이며, 텍스트 표현을 위한 많은 딥러닝 알고리즘의 기초가 됨
  • ex. 도시 이름은 'in' 이라는 단어 근처나 'live', 'visit' 등과 같은 동사에서 멀리 떨어지지 않고 사용됨
  • 데이터로부터 동의어 생성 가능

2.3 순방향 신경망

순방향 신경망(feed-forward neural network, 또는 전방전달 신경망, 피드 포워드 신경망)

• 정보가 입력 계층에서 은닉 계층으로 전달, 마지막으로 출력 계층으로 전달되며 루프 구조가 없어 뉴런 간에 순환 고리 형성되지 않음

뉴런: 망의 근분적인 구성 요소

• 어떤 계층에 속함
• 들어오는 가중치에 맞춰 입력 처리
• 활성 함수에 따라 출력 전파

• 두 번째 층의 뉴런으로 들어오는 모든 가중치를 0.3으로 설정하고 첫 번째 계층으로부터 0.4, 0.5, 0.6 입력치 받는다고 가정
• 각 가중치에 그 입력을 곱함 -> 0.3 * 0.4 + 0.3 * 0.5 + 0.3 * 0.6 = 0.45
• 활성 함수는 이 중간 결과에 적용된 후 뉴런의 나가는 연결선에 전파. 일반적으로 쓰이는 활성함수로 탄젠트(tanh), 시그모이드(sigmoid) 및 정류 선형 장치(ReLU)가 있음
• tanh함수 사용할 경우 tanh(0.45) = 0.4218990053 이므로, 세 번째 계츠의 뉴런은 유일한 수신 연결선을 통해 이 숫자를 수신해 자신의 입력치로 사용하여 똑같은 단계 수행

역전파: 신호가 신경망 내에서 순방향으로 전달된 뒤 다시 출력 계층에서 입력 계층으로 역방향으로 흐르게 함

• 입력치가 순방향 방식으로 출력 계층에 전달되면 출력 계층에서는 이 값을 활성 함수를 거치며 변형하는데, 이렇게 변형된 최종 출력치는 기대 출력치와 비교됨
• 비용 함수(cost function): 특정 사례에서 망이 얼마 잘못되었는지 나타내는 측도(measure)
• 오차는 출력 뉴런으로 들어오는 연결선을 통해 은닉 계층의 해당 유닛에 역방향으로 전달
• 유닛은 갱신 알고리즘(update algorithm)에 따라 가중치를 갱신하며, 이 가중치의 역방향 갱신은 입력 계층에 연결된 연결선이 나타내는 가중치까지 조정되어야 끝남
  • 각 가중치는 오차가 생기게 하는 원인 중 하나이므로, 역전파라는 과정을 통해 가중치 조정 시 입력과 출력으로 이뤄진 상이 만들어내는 오차 줄일 수 있음

2.4 word2vec 사용

word2vec: 텍스트의 한 부분을 가져다가 텍스트의 각 단어를 하나씩 일련의 벡터로 출력

• 출력 벡터가 2차원 그래프에 표시될 때, 서로 의미가 매우 유사한 단어 벡터가 매우 가깝게 놓이게 됨
• 단어의 동의어 찾기 가능

word2vec 같은 알고리즘에 의해 생성된 단어 벡터는 정적이고(static) 이산적이며(discrete), 고차원적인(high dimensional) 단어 표현을 차원이 더 낮으면서도 미분 가능한(연속적인) 벡터 공간에 사상(mapping)하기 때문에 단어 매장(word embedding)이라고 하는 경우가 많음

ex. i like pleasure spiked with pain and music is my aeroplane

• 텍스트를 word2vec에 입력할 시 각 단어에 대한 벡터 생성(주성분 분석, t-SNE와 같은 차원성 축소 알고리즘 사용해 2차원 출력)
• 각 벡터 사이의 거리 측정하기 위해 코사인 유도 사용 시 결과 중 일부는 좋고, 일부는 좋지 않음
  • music -> song, view
  • looking -> view, better
  • in -> the, like
  • sitting -> turning, could
    
    • 생성된 단어 벡터의 차원(2개 차원) 수가 너무 낮은 것으로 보임
    • 더 많은 예문 필요
• 더 많은 데이터셋 사용해 word2vec 모델 다시 만들 시
  • music -> song, sing
  • view -> visions, gaze
  • sitting -> hanging, lying
  • in -> with, into
  • looking -> lookin, lustin

검색 엔진이 자신이 취급하는 데이터에서 동의어를 생성하는 방법을 학습할 수 있기 때문에 최신 정보를 유지하기 위한 사전이나 어휘가 필요하지 않을 수 있음

word2vec의 단어 표현 학습 - 연속 단어 주머니(CBOW)와 연속 스킵그램(continuous skip-gram) 사용

• 신경망에 일정한 크기의 조각으로 쪼개지는 텍스트 한 조각이 주어지며, 모든 단편은 표적 단어(target word 또는 대상어, 목표 단어)와 문맥(context)로 구성된 쌍으로 망에 공급
  • 훈련 중 각 조각의 일부를 표적 단어로 사용하며, 나머지는 문맥으로 사용
  • 연속 단어 주머니 모델에서는 표적 단어를 망의 출력물로, 텍스트 조각(문맥)의 나머지 단어를 입력으로 사용
  • 연속 스킵그램 모델에서는 표적 단어는 입력으로, 문맥 단어는 출력으로 사용
  • 스킵그램이 자주 사용하지 않는 단어에서 약간 더 잘 작동하는 경우가 흔하므로 더 선호됨
  • ex. she keeps moet et chandon in her pretty cabinet let them eat cake she says (창: 5)
    • | she | keeps | moet | et | chandon | 5개의 텍스트 조각 표본
    • 입력: | she | keeps | et | chandon |
    • 출력: moet
• 망의 은닉 계층에는 각 단어에 대한 일련의 가중치가 들어가며, 이 벡터들은 학습이 끝날 때 단어 표현으로 사용됨
• 훈련 단계가 끝날 때 은닉 계층의 내부 상태 추출해 각 단어를 정확히 하나의 벡터 표현으로 산출
• 각 단어를 원핫인코딩 벡터로 표현
• 단어 주머니 모델
  • 
    • 입력 계층은 CxV의 차원성을 가지며, 여기서 C는 문맥의 길이(window 파라미터 1에 대응), V는 어휘의 크기
    • 은닉 계층에는 사용자가 정의한 N의 차원성 존재
    • 출력 계층은 V와 같은 차원성 가짐
  • 입력 단어의 원핫인코딩 벡터를 먼저 입력-은닉 사이에 있는 가중치들에 곱해 망을 통해 전파
  • 출력은 은닉-출력 가중치와 결합(다중)되어 출력 생성되며, 이 출력은 소프트맥스 함수 통과
  • 소프트맥스는 임의의 실제 값 k차원 벡터(출력 벡터)를 1까지 더하는 범위(0,1)의 k차원 벡터에 '스쿼시(squash)'하여 확률 분포 나타낼 수 있도록 함
  • 문맥(망 입력) 감안해 각 출력 단어가 선택될 확률 알려줌
  • 이 신경망의 가장 중요한 부분은 맥락에서 주어진 단어들을 예측하는 것이 아닌, 두 단어가 의미적으로 비슷한 경우를 결정할 수 있도록 은닉 계층의 가중치가 조정됨
• 스킵그램 모델
  • 
    
    • 입력 벡터는 원핫인코딩(각 단어마다 하나씩)되어 있으므로 입력 계층에는 입력 텍스트의 단어 수와 같은 수의 뉴런 존재
    • 은닉 계층은 원하는 결과 단어 벡터의 차원성을 가짐
    • 출력 계층은 window - 1에 단어 수를 곱한 숫자의 뉴런 가지고 있음
    • ex. she keeps moet et chandon in her pretty cabinet let htem eat cake she says
      • 입력: moet
      • 출력: | she | keeps | et | chandon |

2.4.1 Deeplearning4j에 word2vec 끼워쓰기

DL4J(Deeplearning4j): 자바 가상 머신을 위한 딥러닝 라이브러리

• 스킵그램 모델을 기반으로 word2vec 바로 구현 가능

2.4.2 Word2vec 기반 동의어 확장

WordNet 사용 시 제한된 동의어 집합을 가지고 있기 때문에 색인 부풀리기 불가

word2vec을 책임감 있게 사용하기 위한 전략

• 최근접 단어를 얻기 위해 투입할 단어의 종류 제한 (ex. PoS(품사)가 NC(보통명사) 또는 VERB(동사)인 단어에 대해서만 사용)
• 문서가 얼마나 유익한지 살펴보는 것 (ex. 긴 문서보다 짧은 문서들에 초점을 맞추면서 이 문서들의 동의어를 확장)
• 용어 가중치를 보고 낮은 가중치를 생략
• 유사도가 좋은 경우에만 word2vec 결과 사용

• word2vec을 기반 동의어 확장 과정
• 학습된 word2vec 모델을 사용해 필터링 중 용어 동의어를 예측할 수 있는 동의어 필터 생성 가능

2.5 평가 및 비교

쿼리 확장의 도입 전후에 정밀도, 재현율, 결과 0의 쿼리 등을 포함한 계량(metrics) 포착 가능하며, 신경망의 모든 파라미터를 최선의 구성 집합이 되게 정하는 것도 좋은 방법

교차 검증(cross validation): 머신러닝 모델이 훈련용 데이터와 훈련용이 아닌 데이터를 구분함으로써 훈련을 아주 잘 하게 하는 동시에 파라미터를 최적화 하는 방법

• 훈련 집합: 모델 훈련하는 데 쓸 데이터의 출처로 사용
• 교차 검증 집합: 가장 성능이 좋은 파라미터를 가진 모델을 선택하는데 사용
• 테스트 집합: 교차 검증 집합과 동일한 방식으로 사용되나, 교차 검증 집합에서 테스트를 통해 선택된 모델에서만 사용되는 것 제외

2.6 프로덕션 시스템에 대해 고려할 사항

대부분의 기존 프로덕션 시스템은 이미 많은 색인화된 문서를 포함하고 있으며, 그러한 경우 색인화되기 전 존재했던 원래의 데이터에 접근하는 것이 때때로 불가능

시간이 지나 데이터셋이 변할 경우 별도의 저장소에 이전 사본을 보관하지 않으면 나중에 모든 색인된 문서에 대해 word2vec 모델 작성 불가능

-> 검색 엔진을 주요 데이터 소스로 사용해 해결

2.6.1 동의어 대 반의어

보통 텍스트에 'hate', 'love'가 비슷한 맥락에서 나타나지만, 적절한 동의어가 아니라는 것을 말해 줄 충분한 정보가 있음

단어 벡터 간의 유사도는 충분히 비슷하지 않은 최근접 이웃을 배제하는데 도움

• 유사도의 절대값(ex. 0.6)을 기준으로 필터링

요약

• 동의어 확장 시 재현율이 개선되므로 검색 엔진 사용자를 더 행복하게 하는 기법이 될 수 있음
• 일반적인 동의어 확장 기법 적용 시 사용되는 데이터와 별 관계없는 정적인 사전이나 어휘집을 사용하게되고, 이로 인해 이러한 사전이나 어휘집을 일일이 수작업으로 정비 필요
• 순방향 신경망은 많은 신경망 아키텍처의 기초. 정보는 입력 계층에서 출력 계층으로 흐르며, 이 두 계층 사이에 하나 이상의 은닉 계층 있을 수 있음
• word2vec은 유사한 의미의 단어를 찾거나 유사한 문맥에 나타나는 단어를 찾기 위해 사용할 수 있는 단어들에 대한 벡터 표현을 학습하는 순방향 신경망 기반 알고리즘. 따라서 이 단어를 동의어 확장에도 사용하는 것이 합리적

• 검색에 관한 기초 내용
• 검색 시에 당면할 수 있는 중요 문제
• 신경망이 검색 엔진에 더 효과적일 수 있는 이유

이 책은 딥러닝(deep learning, DL)이라는 머신러닝의 하위 분야 기법을 이용해 검색 엔진의 동작에 영향을 줄 수 있는 모델과 알고리즘을 더 효과적으로 구축하는 데 필요한 내용을 담고 있다.

딥러닝 알고리즘이 로비가 하는 일을 담당하게 하면 검색 엔진은 더 나은 검색 엔진을 제공할 수 있을 테고, 따라서 최종 사용자에게 더 정확한 답을 제공할 수 있을 것이다.

인공지능 > 머신러닝 > 딥러닝

1.1 신경망과 딥러닝

딥러닝이란 머신러닝의 한 분야이며, 심층 신경망을 이용해 컴퓨터가 사물을 점진적으로 표현하고 인식할 수 있도록 머신이 학습할 수 있는 분야.

인공신경망(artificial neural network): 뇌의 신경세포가 그래프 꼴로 조직되는 방식에서 영감을 얻어 만든 연산 패러다임

• 입력 계층(input layer, 또는 입력층): 입력 내용을 받아들이는 첫번째 계층
• 은닉 계층(hidden layer, 또는 은닉층): 입력 - 출력 사이의 계층
• 출력 계층(output layer, 또는 출력층): 마지막 계층으로서 신경망의 결과 출력

1.2 머신러닝이란?

이전까지 쌓아온 경험(이전에 관측한 내용과, 이러한 관측치로부터 알고리즘이 추정해야 할 내용이 서로 쌍을 이룬 형태)을 바탕으로 최적해를 학습해 낼 수 있는 알고리즘을 기반으로 문제를 해결하는 자동화된 접근법

딥러닝은 머신러닝을 수행하는 방법 중 한 가지에 불과하며, 심층 신경망을 사용한다는 점이 여타 머신러닝 알고리즘과 다름

머신 러닝

지도학습(supervised learning, 또는 감독학습): 각 입력에 따른 적합한 출력을 지정

• 훈련 단계(training phase) 동안 머신러닝 알고리즘은 훈련 집합을 쪽쪽 씹으며 입력 텍스트를 출력 범주에 대응(map)시키는 일과 같은 방식을 배움
• 훈련 단계를 마치면 머신러닝 모델(machine learning model, 또는 기계학습 모델)을 사용해 일을 마무리하며, 출력 예측 시 활용

비지도학습(unsupervised learning, 또는 자율학습)

• 예상되는 출력에 대한 정보가 없는 데이터를 가지고도 학습 단계(learning phase)에서 패턴과 데이터 표현을 추출

1.3 검색 시에 딥러닝으로 할 수 있는 일

딥러닝 알고리즘을 적용한 검색엔진의 이점

• 최종 사용자에게 연관도가 더 높은 결과 제공
• 텍스트를 검색할 때와 같은 방법으로 이진 형식으로 된 내용 검색 가능(이미지 검색)
• 검색 내용에 쓰인 언어와 다른 언어를 사용하는 사용자에게도 내용 제공
• 데이터를 더 정교하게 처리

1.5 유용한 정보 꺼내기

검색 엔진이란?

• 사람들이 정보를 끄집어 내는 데 사용할 수 있는 시스템. '데이터'를 '정보'로 만들어 제공하는 역할
• 수직 검색 엔진(vertical search engine): 특정한 문서 형식이나 특정 주제에 특화 (ex. 구글 스칼라)

검색 엔진의 역할

• 색인화(indexing): 데이터를 효율적으로 수집하고 저장해 둠으로써 빠르게 검색
• 쿼리 처리(querying, 즉 질의처리): 최종 사용자가 정보를 찾아볼 수 있게 검색 기능 제공
• 순위지정(ranking): 사용자의 정보 요구를 가장 잘 충족하기 위해 특정 지표에 맞춰 순위 지정해 결과 표시

1.5.1 텍스트, 토큰, 용어, 검색에 관한 기초 지식

텍스트 분석(text analysis): 용어(term)라고 부르는 텍스트 조각을 추출하고 저장 (텍스트를 그 구성 요소인 단어별로 분해)

용어(terms): 텍스트 분석 알고리즘에 의해 생성된 최종 단위(단어 외 문장 그룹이나 단어의 일부일 수 있음). 검색 엔진이 데이터를 저장해 결과적으로 데이터를 검색하기 위해 사용하는 기본 단위

키워드 검색(keyword search): 사용자가 단어 세트를 입력하면 검색 엔진이 단어의 일부 또는 모든 용어를 포함하는 문서 모두 반환

쿼리(query, 질의 또는 질의어): 사용자가 무언가를 검색하기 위해 입력하는 텍스트

검색 단계를 빨리 계산할 수 있는 방법?

역색인(inverted indexes, 또는 역인덱스): 용어가 원래 들어 있던 텍스트에 용어를 매핑하는 데이터 구조 (책의 뒤편에 나오는 색인 구조와 같음)

텍스트 분석 파이프라인 구성의 두가지 유형 빌딩 블록

• 토크나이저(tokenizer, 즉 토큰화기 또는 토큰 생성 함수): 텍스트의 스트림을 단어나 구 또는 기호나 토큰(token)이라고 부르는 그 밖의 단위에 맞춰 분할하는 컴포넌트
  • ex. 화이트스페이스(whitespace) 문자를 만날 때마다 토큰 분할
• 토큰 필터(token filter): 토큰 스트림을 받아들여 새 토큰으로 수정, 삭제하거나 추가할 수 있는 컴포넌트
  • ex. 불용어 목록(stopword list, '정지어 목록', '사용하지 않을 블룩)이라는 일종의 블랙리스트에 일치하는 토큰 제거

색인화(indexing, 인덱싱): 텍스트의 스트림을 분석한 결과로 나온 용어들을 검색 엔진에 저장하는 전체 과정

문서(document): 색인화할 텍스트 조각

색인화 예제

• 'the brown fox jumped over the lazy dog' (문서 1)
• 'a quick brown fox jumps over the lazy dog' (문서 2)
• 역색인 표

  • 용어	문서 식별부호
    brown	1, 2
    fox	1, 2
    jumped	1
    over	1, 2
    lazy	1, 2
    dog	1, 2
    quick	2
    jumps	1

    • 불용어 기반의 토큰 필터로 인해 'the' 용어 항목 없음
    • 첫번째 열의 용어 사전과 각 행의 각 용어와 관련된 게시 목록(posting list), 즉 문서 식별자 집합 찾기 가능
    • 역색인을 사용해 특정 용어가 포함된 문서 아주 빠르게 검색 가능
      • ex. 'quick' 용어 검색 시 'quick'이라는 용어에 해당하는 게시 목록 살펴서 문서 2 반환
    • 실무에서는 문서의 서로 다른 부분들에 대한 색인들을 동일한 검색 엔진에서 모두 처리할 수 있게 역색인을 중복해서 갖춰둠

검색(retrieval)

쿼리 파서(query parser, 쿼리 구문분석기): 사용자가 입력한 검색 쿼리 텍스트를 검색 엔진이 찾아야 할 용어와 역색인에서 일치 항목을 찾을 때 사용하는 방법을 나타내는 일련의 절(clause)로 변환

• ex. 'deep + learning for search' 쿼리 예제에서 기호 +와 '를 이해하는 역할 (deep, learning 반드시 포함)
• 지능형 쿼리 파서의 경우 단어의 의미를 반영하는 절들 생성 가능

색인 시간 텍스트 분석(index-time text analysis): 색인화 하는 동안 텍스트 분석 파이프라인은 입력 텍스트를 색인에 저장할 용어로 분할

찾기 시간 텍스트 분석(search0time text analysis): 쿼리가 검색을 하는 동안 쿼리 문자열을 용어별로 분리하기 위해 텍스트 분석 적용

역색인

• 시스템이 텍스트 분석(토큰화 및 필터링)을 통해 사용자가 쿼리 시간에 입력할 것으로 예상되는 용어에 맞춰 텍스트를 분류함으로써 역색인이라고 부르는 데이터 구조에 배치하는 기술
• 저장 공간 측면 - 효율적으로 색인 작업 가능
• 검색 소요 시간 측면 -효율적으로 검색 가능

1.5.2 연관도 우선

연관도: 문서가 특정 검색 쿼리와 관련해 얼마나 중요한지 측정하는 기준

• 검색 모델(retrieval model)은 연관도의 개념을 가능한 한 정확하게 포착해야 함
• 연관도가 높은 결과일수록 검색 결과의 순위지정(rank) 점수 높음

1.5.3 고전적인 검색 모델

벡터 공간 모델(vector space mode., VSM)

• 각 문서와 쿼리는 벡터로 표현되며 문서 벡터와 쿼리 벡터가 가까울 수록 유사
• 가중치(weights): 검색 엔진의 나머지 문서와 관련해 해당 용어가 문서/쿼리에서 얼마나 중요한지를 나타내는 실제 수
• 용어빈도-역문서빈도(term frequency-inverse document frequency, TF-IDF, 또는 용어빈도/역문헌빈도)
  • 단일 문서에 용어가 자주 나타날수록(TF 클수록) 중요
  • 모든 문서에 걸쳐 어떤 용어가 흔하게 나타날수록(IDF 클수록) 중요성 떨어짐

Okapid BM25: 확률론적 모델. 문서가 특정 쿼리와 연관될 확률을 추정해 검색 결과 순위로 매김

1.5.4 정밀도와 재현율

정밀도(precision): 검색된 문서들 중 연관성이 있는 문서들의 비율을 분수로 나타냄

• 정밀도 높을수록 사용자는 검색 결과 목록의 맨 위에서 원하는 결과 대부분 찾을 수 있음

재현율(recall): 연관성이 있는 문서들 중 검색된 문서들의 비율을 분수로 나타낸 것

• 재현율 높을수록 검색 결과에서 모든 관련 결과 찾을 수 있지만, 관련 결과라고 해서 다 상위 차지는 못할 수 있음(랭킹 낮을 수 있음)

검색 엔진의 효과 측정 옵션: 공개된 데이터셋 사용

1.6 미해결 문제들

 필요한 모든 정보를 다 얻으려면 몇 번에 걸쳐 묻고 응답하는 과정이 반복될 수 있음

• 심층 신경망을 사용해 더 쉽게 사용 가능하고 더 발전한 검색 엔진을 만들고자 할 때 이러한 문제들 인식 필요

1.7 검색 엔진 블랙박스 열기

효과적인 검색 쿼리를 만들 때 중요한 문제 - 어떤 쿼리 언어를 사용하는가.

쿼리 언어에 따라 검색 결과가 많이 달라질 수 있으며, 실무에서 검색 결과의 순위를 수동으로 조정하는 것은 거의 불가능

• 딥러닝으로 그러한 문제를 해결하거나 최소한 완화시키는데 어떻게 도움이 될 수 있을까

1.8 구조의 손길을 펼치는 딥러닝

딥러닝: 심층 신경망을 사용해 일반적으로 텍스트나 이미지 또는 데이터의 깊은 표현을 배우는 데 초점을 맞춘, 머신 러닝의 하위 영역

• 적어도 두 개의 은닉 계층을 가지고 있을 때 심층(deep) 신경망으로 간주
• 심층 신경망은 특히 고도로 합성된 데이터(작지만 비슷한 성분들이 큰 물체 형성 시)에 사용할 때 큰 도움이 되며, 이미지와 텍스트가 이 경우에 해당

텍스트 문서 집함 내에서 단어 표현을 학습하기 위해 신경망 알고리즘 사용 시, 밀접하게 관련된 단어들은 벡터 공간에서 서로 인접

• word2vec신경망 알고리즘 사용해 단어 벡터(word vector) 학습

단어 매장(word embedding, 단어 임베딩)으로도 불리는 단어 벡터나 문서 매장(document embedding, 문서 임베딩)으로도 불리는 문서 벡터에 의존하는 검색 모델이 있으면 좋을 것이므로 이를 위해 최근접 이웃(nearest neighbor) 보며 문서 유사도나 단어 유사도를 효율적으로 계산하고 사용

단어나 문장이나 문서가 나타내는 맥락을 사용해 가장 적절한 표현을 추론함으로써 텍스트에 숨어 있는 의미를 잘 표현 가능하고, 검색엔진의 연관도 높일 수 있음

딥러닝 vs 심층 신경망

딥러닝은 주로 심층 신경망을 이용해 단어, 텍스트, 문서, 이미지의 표현을 배우는 일

심층 신경망: 더 넓게 응용. (ex. 언어 모델링, 기계 번역 등)

1.9 색인아, 뉴런을 만나 주지 않을래?

신경망과 검색 엔진을 통합하는 몇가지 방법

• 훈련 후 색인(train-then-index):
  1. 문서 모음(텍스트, 이미지)을 가지고 망을 훈련
  2. 훈련에 쓴 데이터와 동일한 데이터를 가지고 검색 엔진에서 색인
  3. 검색 시 검색 엔진과 신경망 사용
• 색인 후 훈련(index-then-train): 
  1. 검색 엔진에서 문서 모음 색인화
  2. 색인화된 데이터로 신경망을 훈련(때때로 데이터 변경 시 다시 훈련)
  3. 검색 시 검색 엔진과 신경망 함께 사용
• 훈련으로 색인 추출(train-extact-index):
  1. 문서 모음을 가지고 망을 훈련
  2. 훈련된 망을 사용해 데이터와 색인화될 유용한 자원 함께 생성
  3. 검색 엔진만 있으면 검색 가능

1.10 신경망 훈련

신경망 학습 알고리즘은 기대 출력과 실제 출력간의 차이를 취해 이를 바탕으로 각 계층의 가중치를 조정함으로써 다음 차례에 나올 출력 오차를 줄임

데이터가 충분할 시 오차율을 크게 줄일 수 있으며, 활성 함수는 예측을 수행하는 신경망의 능력과 학습 속도에 영향 미침

역전파 알고리즘: 기대 출력과 실제 출력이 주어지면 알고리즘은 각 뉴런의 오차(error)를 역전파하고 결과적으로 출력에서 입력까지 한 번에 한 계층씩 각 뉴런의 연결부에 대한 내부 상태 조정

정적모델(static model, 또는 정태모형)의 경우 훈련 집합을 갱신하려면 전체 과정을 순서대로 반복해야 하는데, 끊임없이 흘러 들어오는 신규 데이터를 처리해야 하는 검색 엔진과 같은 시스템에는 적절하지 않음

• 신경망에 재훈련이 필요하지 않은 온라인 학습(online learning) 도입?

1.11 신경 검색의 약속들

신경 검색 활용

• 의미를 깊이 파악하는 딥러닝의 능력을 통해 기초 데이터에 잘 적응하는 관련 모델과 순위지정 함수 얻을 수 있음
• 이미지 검색에서 좋은 결과를 주는 이미지 표현 학습 가능
• 의미적으로 유사한 단어나 문장 또는 단락등을 파악하기 위해 딥러닝이 생성한 데이터 표현에 적용 가능
• 텍스트 생성, 번역, 검색 엔진 최적화 등..

검색 시스템에 신경망 활용

• 색인화 시 역색인에 진입하기 전 데이터 보강 위한 신경망 사용
• 검색 쿼리 범위 확대하거나 지정해 더 많은 수의 결과나 정환한 결과 제공하는 일에 신경망 사용
• 사용자가 검색 쿼리를 입력할 수 있도록 돕거나, 검색 쿼리를 번역하는 일에 신경망 사용

한계

• 훈련 비용
• 모델 업그레이드 등..

요약

• 정보 검색에 대한 일반적인 접근 방식에는 한계점과 단점이 있음
• 텍스트 분석은 색인화와 검색 단계에서 모두 중요한 작업
• 연관도는 검색 엔진이 사용자의 정보 요구에 얼마나 잘 대응하는지 보여주는 기초 측도며, 사용자마다 맥락과 의견이 크게 다를 수 있으므로 연관도 측정 시 검색 엔지니어에게 지속적으로 초점 맞춰야 함
• 딥러닝은 심층 신경망을 이용해 의미적으로 목적에 적합한 유사성 측도를 포착할 수 있는 내용의 표현을 학습하는 머신러닝 분야
• 신경 검색은 딥러닝을 사용해 검색과 관련된 다양한 작업을 개선하는 것을 목표로함