꿀벌개발일지

홈어시스턴스 이미지 생성 시 오류

ohgyun — Tue, 25 May 2021 00:39:32 +0900

발생일: 2021.05.25

키워드: 홈어시스턴트, Home Assistant, HA

문제:

홈어시스턴트 이미지를 SD 카드에 구워서 라즈베리 파이에서 구동하려고 한다.

가이드에 나온대로 SD 카드를 포맷하고 balenaEtcher 에서 타겟을 설정했는데, 아래와 같은 오류가 발생했다.

EBUSY: resource busy or locked, open '/dev/rdisk2 on Mac

해결책:

SD 카드를 Disk Utility 에서 포맷했는데, 이 때 APFS 로 포맷한 것이 문제였다.
Mac OS Extended (Journaled) 으로 포맷해야 한다.

APFS 로 포맷된 상태에서는 디스크 유틸리티에 다른 포맷 옵션이 나오지 않는다.
아래와 같이 커맨드라인에서 실행하면 된다.

$ sudo diskutil eraseDisk HFS+ NEWNAME /dev/disk2

DynamoDB: on-demand 모드의 오토 스케일링

ohgyun — Fri, 16 Apr 2021 10:58:22 +0900

발생일: 2021.04.21

키워드: 다이나모디비, 온디맨드, 오토 스케일링, auto scaling

문제:

다이나모디비를 온디맨드 모드로 쓰고 있다.

배치 작업으로 평소보다 많은 데이터를 PUT 했는데, 아래와 같은 에러가 나온다.

Throughput exceeds the current capacity for one or more global secondary indexes. DynamoDB is automatically scaling your index so please try again shortly.

온디맨드 모드는 스케일 제한이 없는 걸로 알았는데 왜 그런걸까?

해결책:

테이블 생성 후, 이전 트래픽 대비 많은 데이터를 넣어서 발생한 문제였다.

요약 먼저:
온디맨드도 내부적으론 오토스케일링으로 동작하는데, 스케일링 기준을 초과한 요청을 보내서 쓰로틀이 발생한 것이었다.

나중엔 스케일링 기준(이전 트래픽 피크치의 2배)를 임의로 필요한만큼 높여두면 쓰로틀링 이슈는 크게 걱정하지 않아도 되겠다.

온디맨드의 스케일링:
- 온디맨드는 트래픽 볼륨에 따라 자동으로 확장됨 (Auto Scaling)
- 테이블은 이전 최대 트래픽의 최대 2배 용량을 즉시 수용할 수 있음
- 예: 이전 트래픽의 최대값이 초당 5만 읽기였으면, 초당 10만 읽기까지 즉시 수용 가능
- 트래픽이 2배보다 더 커지는 경우 오토 스케일링 되면서 더 많은 용량을 할당함
- 단, 30분 이내에 이전 피크의 2배 이상을 초과할 경우 쓰로틀링이 걸릴 수 있음
- 테이블의 최대 피크치는 계속 지속됨
- 온디맨드 테이블의 최초 설정은
- 기존 테이블을 전환한 경우, 기존 테이블의 피크 트래픽의 2배
- 새로 생성한 경우: 최대 초당 4000 쓰기, 12000읽기

팁:
- 온디맨드 테이블의 최대 피크는 히스토리는 지속되므로 트래픽을 발생시켜서 pre-wraming 하는 요령도 있음
- 최대 2배 이상의 트래픽이 30분 이내에 오지 않는 경우라면 신경쓰지 않아도 될 듯

현재 상황:
- 현재 테이블은 기존 테이블을 온디맨드로 변경한 거라서 기본 설정인 초당 4000 쓰기보다 낮았음.
- 메트릭스를 보니 아마도 기존의 최대치는 초당 500 정도였는 듯.
- 테스트할 때 기존 피크의 2배 이상인 초당 1200 쓰기 정도를 호출해서 쓰로틀이 걸린 것이었음

결론:
- 기본 설정도 초당 12000 읽기 정도라 초반에는 큰 문제는 없을 듯
- 나중에 더 많은 트래픽이 예상될 땐, pre-warming 해둬서 최대 트래픽을 올려두면 문제 없을 듯

참고:

- https://theburningmonk.com/2019/03/understanding-the-scaling-behaviour-of-dynamodb-ondemand-tables/

- 온디맨드 읽기/용량 모드: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.InitialThroughput

DynamoDB: 고민했던 것들에 대한 정리

ohgyun — Sun, 14 Mar 2021 13:51:12 +0900

발생일: 2021.03.14

키워드: DynamoDB, 다이나모디비

문제:

다이나모디비를 써보면서 헷갈렸던 것들, 생각과 달랐거나 고민했던 내용, 중요하다고 생각되는 것들에 대한 정리

해결:

<비용>

핫파티션은 프로비저닝 모드에서만 해당됨

- 과금 체계는 프로비저닝 모드와 온디맨드 모드가 있고

- 프로비저닝 모드

- 프로비저닝 모드는 RCU와 WCU를 직접 설정하는데, '초당 처리량' 기준임

- 핫파티션 이슈는 프로비저닝 모드에서만 해당됨

- 초당 요청이 할당 받은 처리량을 초과하지 않게 하기 위해 설계해야 함

- 예약 요금은 프로비저닝 모드에서 쓸 RCU,WCU를 미리 사두는 개념

- 온디맨드 모드

- 사용한 RCU와 WCU 만큼 과금하는 모델

- 사용한 만큼 과금되기 때문에, 처리량의 한계와 핫파티션 이슈가 없음

- 더 비쌈. 비용 절감을 위해 서비스가 안정화되면 프로비저닝 모드로 전환하는 게 필요하다고 함

파티션 설계를 할 때 중요한 것은 '처리량'의 분산 (프로비저닝 모드만)

- 내가 설정한 처리량을 최대한 활용하는 것이 좋음

- '저장공간'이 아니라 '처리량'이 분산되도록 하는 것이 중요

- 물론, 프로비저닝 모드인 경우에 해당됨

- 설정한 RCU/WCU 는 파티션 별로 골고루 할당됨

- 예: 100RCU 에 파티션이 5개라면, 각 파티션에 20RCU 씩 분산됨

- 특정 파티션에 20RCU 요청를 초과하는 요청이 들어오면(핫파티션) 병목이 생기고 전체 테이블에 영향이 감

- 경우에 따라 다르겠지만, 상시 요청이 오는 서비스라면 (온디맨드로 시작하더라도) 결국 비용 절감을 위해 프로비저닝으로 변경해야 할 것 같음. 즉, 고민해두긴 해야 함

한 번 요청에 여러 RCU가 소진될 수 있음

- eventual consisten 기준으로 4K 당 0.5RCU 가 소진됨 (즉, 8K 당 1RCU)

- 스캔이나 쿼리로 한 번 읽어올 때 최대 1MB 까지 가능한데, 1MB를 읽어왔다면 1024 / 8 = 128RCU를 소진하는 셈

scan() 으로 테이블을 읽어오면 문제가 없을까? 과금 모델에 따라 다름

- 전체 테이블을 scan() 하면서 한 번에 1MB를 읽어왔다면, 128RCU 를 소진함

- 프로비저닝 모드라면,

- 초당 처리량이 문제가 될 수 있으므로, 적당히 나눠서 요청하는 것이 필요함

- 예: 100RCU 를 설정해뒀는데, 한 번에 1MB 씩 읽어오면 이미 테이블 처리량을 초과하게 됨.

- 이럴 땐, 1초에 10RCU(80K)만 쓰게 나누는 식으로 분산

- 온디맨드 모드라면, 걱정 없이 그냥 읽어오면 됨

- 병렬 스캔을 하면(TotalSegments, Segmant 파라미터), 빨리 가져올 수 있음

- 처리량이 크거나 온디맨드 모드라면(= 돈 걱정이 없다면),

- 테이블이 커도 세그먼트 수를 늘려서(예: 10만개) 수초 만에 가져올 수 있음

Projection 을 해도 비용은 동일함

- 쿼리나 스캔할 때, Projection 을 설정해 특정 속성만 가져오도록 하더라도 RCU 비용은 동일함

- 네트워크 비용이 줄어들지만 뭔가 속은 느낌-_-

LSI를 설정하지 않으면 파티션 사이즈를 고민하지 않아도 됨

- 파티션 최대 크기에 대한 문서가 조금 애매하긴 하지만, LSI를 설정하지 않으면 파티션 크기는 고민하지 않아도 되는 듯

- LSI를 설정한 경우, 파티션의 최대 크기가 10GB로 제한됨

- LSI는 대체로 잘 활용하지 않는 것 같음. 리인벤트 강의를 여러 개 들어봤는데, 아무도 LSI의 활용에 대해서는 언급하지 않았음 (GSI를 잘 설계하면 될 듯)

- LSI를 설정하지 않은 상태에서 10GB를 넘으면?

- 문제 없는 것으로 파악함

- 명시되어 있진 않은데 내부적으로 처리하지 않을까 예상해봄

- 파티션 1개의 크기에 한계가 있더라도 정렬키가 명확하니까 처리 자체가 복잡하지 않을 듯

<싱글 테이블 디자인>

싱글 테이블 디자인에서 테이블을 나누는 기준

- (아직 확신이 없지만, 적어도 지금까지는) 전부 싱글 테이블로 해도 괜찮을 것 같음

- 다만, MSA 로 서비스를 나눈다고 가정했을 때 완전 다른 도메인은 별도로 분리해도 좋을 듯

싱글 테이블 설계에서 데이터를 가져올 땐, "시간복잡도"를 줄이는 것이 중요

- 스케일이 커지더라도 시간 복잡도를 줄이는 것이 강점

- 복잡한 키 설계를 통해, 여러 타입의 데이터를 한 번에 가져올 수 있는 것이 장점

싱글 테이블인데 다른 엔터티를 함께 읽지 않으면 비효율

- 작업하다보니 싱글 테이블의 아이템을 조회할 때, 습관적으로 RDS에서 했던 것처럼 별개로 조회하고 있었음

- 여러 타입의 아이템을 한 번에 가져올 수 있게 GSI를 설계하는 것이 중요할 듯

자주 변경되지 않는 데이터는 중복하고 변경될 때 업데이트함

- 참조하는 아이템의 중복을 얼마나 허용해야 할까? (예: 유저 닉네임)

- 빈번하게 참조하는 대상도 중복해야 할까?

- 싱글 테이블의 베스트 프랙티스에서는 바뀌지 않거나(immutable) 자주 변경되지 않으면 중복해서 넣으라고 함

- 여기서 자주는 하루에 1~2번 정도. 발표자는 1천번까지도 괜찮다고 생각한다고 함

- 중복하더라도 스토리지를 조금 더 쓸 뿐이라고. 스토리지는 저렴함.

- 중복 데이터는 스트림과 람다를 활용해서 업데이트 하면 되고, 예전처럼 고통스럽지 않을 거라고 함

- 지금은 1980년대가 아니라면서...

- 참고: AWS re:Invent 2020: Amazon DynamoDB advanced design patterns

DynamoDB: Building NoSQL Database-Driven Applications 노트

ohgyun — Sun, 14 Mar 2021 12:57:26 +0900

발생일: 2021.02.16

키워드: DynamoDB, 다이나모디비

문제:

DynamoDB에 코세라 강좌가 있어 들으면서 정리했던 노트다.

https://www.coursera.org/learn/dynamodb-nosql-database-driven-apps

지금보면 너무 기초적인 것 같은데, 당시 흐릿하게 개념이 잡혔던 터라 전체 컨셉을 이해하기에 좋았다.

지금 보더라도 유심히 기억해야할 만한 특징인 볼드로 표시해뒀다.

내용:

Relational Databases and the Problem that Need Solving

- RDS(Relational Data System)의 특징
    - 정형 데이터를 분석하기 좋음
    - 스토리지를 많이 차지하고
    - 컴퓨팅 비용이 큼

- CAP 정리: 다음과 같은 세 가지 조건을 모두 만족하는 분산 컴퓨터 시스템이 존재하지 않음을 증명한 정리
    - 일관성(Consistency): 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다.
    - 가용성(Availability): 모든 요청이 성공 또는 실패 결과를 반환할 수 있다.
    - 분할내성(Partition tolerance): 메시지 전달이 실패하거나 시스템 일부가 망가져도 시스템이 계속 동작할 수 있다.

- Partiton Tolerance 는 시스템에서 보장해야 함. 그래서 C 와 A 중 둘 중 하나를 선택해야 함.

- NoSQL 이 유리하지 않은 경우
    - 피크를 예상할 수 있는 self-managed  환경. 수평 확장이 항상 옵션은 아님
    - 정형 데이터로만 구성된 경우
    - 여러 테이블의 조인이 필요한 경우. NoSQL은 cross-table 관계가 없음. 조인을 할 수가 없음

- NoSQL 디비 타입
    - Key-Value
        - key-value 기반으로 키 조합으로 데이터를 가져올 수 있음
        - DynamoDB
        - 예: 유저 세션 데이터 저장하기에 적합
    - Column-based
        - 많은 데이터를 빨리 가져오는데 유리함
        - Cassandra, HBase
    - Document-based
        - tagged elements로 저장
        - MongoDB

- DynamoDB
    - Managed System
    - read/write capacity units 을 조정해서 성능 레벨을 관리할 수 있음
    - 스트림, 트랜잭션, 액셀러레이터, 글로벌 테이블 등의 기능 제공
    - low latency, redundant storage, managed durability, fault tolerance
    - 1일 10조 콜, 초당 2000만 콜 처리 가능
    - TTL(Time To Live) 설정 가능

DynamoDB

- 테이블
    - primary key = partition key + (sort key)
    - primary key가 중복되면 안됨
    - attirbutes

- read request 의 consistent
- strongly: 무거움
- eventually

- 제한
    - 한 레코드는 400KB 제한
        - 더 큰 건 S3에 저장해야 함
    - key 길이
        - Partition Key: 1byte 이상, 2048 byte 이하
        - Sort key: 1byte ~ 1024byte

테이블 생성

- Partition Key와 Sort Key 조합이 Unique 하면 됨

- 테이블 목록
- $ aws dynamodb list-tables

- 아이템 추가
- $ aws dynamodb put-item --table-name Music --item file://song1.json

- 조회
    - $ aws dynamodb query --table-name Music --key-condition-expression "Artist = :v1 AND SongTiItle = :v2" --expression-attribute-values file://values1.json
    - v1, v2 = 변수
    - "S": "Rock" 의 의미 = 타입: 값
    - pk 와 sk 를 제외한 다른 속성은 쿼리(query)할 수 없음

- 삭제
- $ aws dynamodb delete-item --table-name Music --key file://key.json
- { "Artist": { "S": "David Bowie" }, "SongTitle": { "S": "Changes" } }

Query and Scan

- Query: PK 또는 PK + SK로 조회
- 정렬키만 있으면 조회

- Scan: 테이블의 전체 테이블 조회
- $ aws dynamodb scan --table-name Music

- 필터: 속성으로 조회해야 하는데, 키가 아니라서 쿼리를 할 수 없는 경우
- key-condition 과 동일하게 --filter-expression 을 쓰면 됨

- Scan + Filter 로 키가 아닌 걸 조회할 수 있으나,
    - scan 은 전체 테이블을 읽는 것이므로 주의해야 함

Secondary Index
- 다른 속성을 키로 갖는 테이블 복제본을 만드는 것
- Local secondary index: 다른 정렬키를 생성
- Global secondary index: 다른 파티션키와 정렬키를 생성

백업
- on-demand backup
    - 람다나,
    - AWS Backup 으로 스케쥴링 가능

- point-in-time recovery
    - 자동 백업
    - 35일 이내 복원 가능
    - 비동기, 성능 저하 없음

- 복원할 땐 read/write capacity가 동일해야 함
- 복원 시간은 상황에 따라 다름

- $ aws dynamodb create-backup --table-name Music --backup-name MusicBackup
- $ aws dynamodb describe-backup --backup-arn [BackupArn]
- $ aws dynamodb restore-table-from-backup --target-table-name MusicRestored --backup-arn [BackupArn]

스캔

- $ aws dynamodb scan --table-name Music --max-items 3
    - 최대 1MB 까지 가져옴
    - last process key 로 다음 배치를 가져올 수 있음
    - 페이지네이션처럼 동작함

- BatchWriteItem
    - 한 번에 여러 테이블에 여러 레코드를 쓸 수 있음
    - 추가하거나 삭제할 수 있음. 업데이트는 안됨
    - 요청 중에 하나가 실패하더라도 나머지 항목은 실행됨
    - 실패된 아이템은 unprocessed items 응답으로 내려옴
    - { 테이블명: [ { 커맨드: { ... }, 커맨드: { ... }] }
    - $ aws dynamodb batch-write-item --request-items file://batch.json

- BatchGetItem
    - 한 번에 여러 테이블에서 여러 레코드를 가져올 수 있음
    - 기본적으로 eventually consistent 임
    - 필요하다면 strongly consistent 를 테이블 단위로 설정할 수 있음
    - $ aws dynamodb batch-get-items --request-items file://...
    - { 테이블명: { Keys: [ ... ] } }
    - 특정 테이블이 실패했다면 unprocessed keys 응답에 있음

- BatchWriteItem 과 BatchGetItem 실패 시,
- unprocessed 응답을 보고 retry 하면 됨

- scan 시 주의
    - 전체 데이터를 훑음
    - 1메가 단위로 끊어서 읽음. LastEvalueatedKey 로 나머지 이어서 가져올 수 있음
    - 필터가 적용되어 있으면, 읽어온 데이터에 값이 없을 수도 있음 (마지막이 아니더라도)

- 옵션
    - ExpressionAttributeNames
        - 속성 키가 예약어와 겹치는 등의 이유로 다른 이름으로 매핑하려는 경우
        - # 캐릭터를 씀
        - "#family": "family"
    - ProjectionExpression
        - 필요한 속성만 가져오려는 경우
        - 예: "dragon_name, #family, protection, damage, description"
    - Segment 나 TotalSegments 로 병렬 처리 가능 (가이드)

모니터링
- CloudTrail
    - 테이블 액션, role, service 모니터링
    - 이벤트 로그를 볼 수 있음

- CloudWatch Logs
- 알람 설정 가능
- API에 따라 처리할 수 있음

- X-Ray
- 바틀넥이나 에러 처리할 때 쓸 수 있음

- CloudWatch Metric
    - 각종 지표
    - RCU, WCU 볼 수 있음
    - 1 RCU = 1 strongly consistent read = 2 eventually consistent read (4KB 이내, 초당 처리 기준)
    - 1 WCU = 1 write (1KB 이내, 초당 처리 기준)
    - dynamodb provisioned capacity 테이블을 보면 정보가 있음
    - 메트릭스 상세: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html

- RCU, WCU 도 파티션에 따라 분산됨
    - 예: 5000RCU 가 있고 파티션이 5개이면, 한 파티션에 1000RCU 씩 분산됨

RCU, WCU가 적절한 것 같은데도 퍼포먼스가 제대로 안나올 땐? (프로비전인 경우)
- CloudWatch에서 capacity 관련 메트릭스 확인
    - 테이블에서 시간당 쓰인 RCU, WCU를 볼 수 있음 (글로벌 인덱스나 세컨더리 인덱스도)
    - 메트릭스에서 설정한 것보다 더 많이 쓰였다면 올려줘야 함
    - 알람 맞춰두면 좋음

- RCU와 WCU도 오토스케일링 정책을 적용해서 처리할 수 있음

- 그래도 병목이 있으면?
- 키 스키마 관련 이슈일 수 있음 (파티션 키 최적화가 필요함)
- large scan 하지 않게 쿼리 최적화가 필요함

파티션키와 최적화
- 테이블을 생성하면 데이터는 파티션에 저장됨
- 파티션은 스토리지 단위이고 물리적 공간(SSD)에 저장됨
- 멀티 리전에 자동으로 복제됨
- 테이블 생성하면 처리량(RCU와 WCU)에 맞춰 적당한 개수의 파티션을 생성함
- 테이블이 커지면 파티션이 추가됨

파티션키
- 모든 테이블은 파티션키가 있음

- 파티션키만 있으면
- 파티션키에 해시함수를 적용한 값으로 파티션 구분

- 정렬키가 같이 있으면,
- 파티션키에 해시함수를 적용한 값으로 파티션을 구분하고
- 여기에서 sort key 로 데이터를 정렬함

- 키 스키마 디자인할 때
- 파티션키가 저장 위치를 결정함
- 모든 파티션에 골고루 분산되게 파티션키를 디자인해야 함

- RCU, WCU를 직접 설정한 경우 (on-demand 는 해당 안됨)
    - 400RCU가 있고 파티션이 4개라면, 각 파티션은 100RCU를 가짐
    - 200RCU 만큼의 요청이 들어왔을 때, 파티션키가 골고루 분산되어 있다면 각 파티션은 50RCU 씩 처리함
    - 만약 한 파티션에 200RCU만큼의 요청이 몰린다면(hot-partition), 처리량을 넘어서게 됨 (provision throughput exceeded exception 발생)
    - 즉, 전체 RCU를 초과하지 않았는데도 에러가 발생하게 됨
    - 핫파티션이 생기지 않게 파티션키를 디자인해야 함

- adaptive capacity 기능
- 핫파티션이 생겼을 때, 사용되지 않은 쓰루풋을 핫파티션이 사용하게 하는 옵션
- 기본 적용되어 있음 (아마도 2019년부터?)

- burst capacity 기능
    - 5분 동안 사용하지 않는 용량을 남겨두었다가 초과분에 사용함

베스트 프랙티스. 파티션 키 디자인
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-uniform-load.html
- 골고루 분산되는 속성을 파티션키로 설정해야 함
- 좋은 예
    - 사용자가 많은 경우, 사용자 아이디
    - 디바이스가 비슷한 빈도로 접속하는 경우, 디바이스 아이디
- 나쁜 예
    - HTTP 상태 코드: 200이 대부분을 차지하기 때문
    - 날짜 단위의 아이템 생성 날짜: 요청이 한 곳에 몰림
- 예를 들어, 파티션키를 생성 날짜, 정렬키를 아이템 아이디로 만들면,
    - 오늘 온 요청(파티션키 = '2021-02-18')은 한 파티션(물리적 공간)에 몰리게 됨
- 마찬가지로, 파티션키 종류가 적은 경우엔 분산되는 속성을 파티션키로 하는 게 나음

다른 우회 방법
- 날짜를 꼭 파티션키로 써야하는 경우, 날짜 뒤에 랜덤한 값을 붙여서 골고루 분산되게 할 수 있음
    - 2021-02-18.123 처럼, 0~200 사이의 값을 넣는 것
    - 근데 이렇게 하면 쿼리로 해당 날짜의 데이터를 조회할 수 없음
    - 0~200까지 조합해서 다 합해야 함
- 조회할 때, 날짜 + 주문 아이디 조합 같은 경우라면, 주문 아이디 기반의 난수를 생성해서 골고루 분산되게 하는 방법도 있음
    - 2021-02-18 에 주문번호 10423번이면, 10 % 100 을 적용해서, 2021-02-18.423 처럼 하는 방법
- 시계열 처리가 필요한 경우,
    - 하루에 한 개의 테이블을 생성하고, 해당 테이블의 RCU/WCU을 고정함
    - 파티션키는 날짜, 정렬키를 시간으로 함
    - 하루에 한 테이블에만 처리가 몰리도록 해서 초과되지 않게 관리함

보안
- 암호화가 필요한 데이터(개인정보)
- 기본적으로 암호화됨
- 암호화 키로 별도로 암호화할 수 있음 (암호화 적용해도 성능 영향 거의 없음)
- EncryptionClient
    - 아이템별로 보안 적용할 수 있음 (사이닝)
- 예: 정부의 개인정보에 맞추기 위해
    - 전화번호 같은 것들이 암호화돼서 저장됨
    - client 수준의 암호화도 있음

TTL
- 성능에 영향 없음
- Manage TTL 에서 켜주면 됨
- 아이템에서 TTL 대상 속성을 정해주면 됨
- 세션 구현 예제
    - { PK: username, SK: sessionId, TTL: expireTime }
- TTL 적용 권한에 IAM을 설정할 수 있음
- 백업할 때에도 적용됨
- 만료된 아이템은 48시간 이내에 삭제됨
    - 만료되었는데 삭제되지 않은 경우, 쿼리, 스캔 결과에 나올 수 있음?

글로벌 테이블
- 여러 리전 간 리플리케이션 제공
- 다이나모디비 스트림으로 리얼 타임으로 전달
- 각 리전 간 동일한 스킴의 테이블을 만들고, 글로벌 테이블로 묶으면 됨
- eventually consistent 로 동기화됨

스트림
- time-ordered sequence
- 24시간 동안 저장됨
- 스트림 이벤트를 받아서 처리할 수 있음
    - 스트림 데이터는 별도로 저장됨
    - 다이나모디비 스트림에 액세스가 필요함
- 프라이머리키 정보가 전달됨
- ES 인덱스 갱신 예

Optimistic Locking
- 동시 업데이트 이슈
- 다이나모디비는 락킹을 지원하지 않음

- Optimistic Locking
- 작업 중인 항목이 마지막으로 읽은 이후 덮어씌워지지 않은지 확인하는 전략

- conditional write 로 구현
    - PutItem, UpdateItem, DeleteItem 메서드의 옵션으로  지원
    - ConditionExpression 파라미터
    - 예:
        - 키가 없을 때에만 허용
        - 속성이 특정 값인 경우에만 허용

- 버전 넘버로 관리하는 예
    - 아이템에 버전을 명시하는 속성을 별도로 둠
    - 업데이트 전에 아이템의 버전을 가져옴
    - 업데이트할 때, 동일한 버전일 때만 업데이트
    - 버전이 바뀌었다면 실패. 성공할 때까지 다시 수행

LSI
- 파티션 내에서 새로운 인덱스를 만듬
- LSI는 파티션에 대해서 고유할 필요가 없음
- consistent 를 선택해서 조회할 수 있음
- 테이블 생성할 때만 추가됨

GSI
- 파티션 키로 새로 정렬해야 할 때 사용
- 비동기로 업데이트됨 (eventually consistent)
- GSI 를 위한 RCU/WCU를 설정해야 함

보조키
- 사용하되 최소로 유지할 것
- 인덱스 사이즈를 최대한 작게 유지할 것
    - project item
- 자주 사용되는 쿼리인 경우, 모든 속성을 project 할 것
    - LSI의 projected attribute 에 없는 경우, 다이나모디비가 전체 테이블을 스캔함

싱글 테이블
- 연관된 데이터를 하나의 테이블에 넣는 것을 추천
- 단, 싱글테이블로 만들 땐, 테이블을 만들기 전에 쿼리를 설계해야 함
- 특히, LSI 는 테이블 생성할 때만 할 수 있기 때문이기도 함
- 먼저 관계 모델을 생성한 후에 싱글 테이블로 설계
- 성능과 쿼리를 위한 것임
- 쿼리를 먼저 생성

음원 테이블 설계 예:
- 작가, 노래, 앨범 관계 모델을 설계

- 쿼리를 설계
    - 아티스트별 곡 찾기
    - 장르별 앨범 찾기
    - 연도별 아티스트의 앨범 찾기
    - 노래 이름으로 찾기

- 쿼리를 설계
    - 아티스트별 곡 찾기: 'PK = 아티스트'로 조회
    - 장르별 앨범 찾기: 장르를 GSI로 만들어서 조회
    - 연도별 아티스트의 앨범 찾기: LSI로 출시연도를 설정해서 조회
    - 노래 이름으로 찾기: 노래 이름을 GSI로 만들어서 조회

- 아티스트 이름을 변경하려고 한다면?
    - 데이터가 여러 번 중복되게 됨. 데이터를 비정규화하기 때문.
    - 한 번에 업데이트하기 위해선 트랜잭션이 필요함
    - 한 번의 오퍼레이션으로 처리할 수 있음

시계열 데이터
- 한 시간 단위에 하나의 테이블을 두는 게 나음
- 스캐닝이 자주 필요한 경우가 특히 그럼 (예: 분기별 집계)
- 아니면 AWS TimeStream 을 써도 됨

싱글 테이블을 만들려고 너무 무리하진 말 것
- 드래곤 카드 게임 서비스라면, 아래 두 테이블은 분리하는 것이 좋음
    - 드래곤 정보 테이블
    - 게임 정보 테이블

DAX
- 한자리수 밀리세컨드
- 마이크로세컨드로 원하는 경우. in-memory 캐시
- DAX 액셀러레이터
- 인메모리 캐시임
- API 호환됨
    - 테이블 대신 클러스터만 보면 됨
- 쓰기보다 리드가 훨씬 큰 경우 유리함
- 작은 아이템이 다른 아이템보다 많이 조회되는 경우
    - 예: 쇼핑몰의 오늘의 인기 아이템
- 별도 비용 있음

논의:

이후에 다이나모디비를 적용하면서 헷갈렸던 개념들을 정리해둠

ohgyun.tistory.com/808

구글 앱스 스크립트에서 비동기 작업 추가하기

ohgyun — Wed, 10 Mar 2021 01:34:15 +0900

발생일: 2021.03.10

키워드: 구글 앱스 스크립트, 구글 앱 스크립트, Google Apps Script, gas, background, setTimeout

문제:

구글 스프레드시트와 슬랙, 구글 앱스 스크립트로 간단한 자동화 태스크를 구축해뒀다.

슬랙을 API 창구로, 구글 앱스 스크립트를 앱 서버로, 스프레드시트를 디비로 사용하고 있다.

예를 들면 이런 작업이다.

1. 슬랙에서 /find_stock_price 같은 슬래시 명령을 치면

2. 구글 앱스 스크립트에서 요청을 받아서

3. 스프레드시트의 값을 수정하거나 조회한 후에 슬랙으로 응답해주는 것이다.

태스크가 조금 복잡해지면서 작업의 응답 시간이 길어지게 됐다.

문제는 슬랙 커맨드의 타임아웃이 3초라는 것...

슬랙 요청에 대해 짧은 응답을 먼저 주고,

긴 작업을 수행한 후에 파라미터로 받은 response_url 로 다시 메시지를 주면 간단한 일이지만,

안타깝게도 구글 앱스 스크립트는 모든 스크립트가 동기로 동작한다.

setTimeout()을 지원하지 않는다.

즉, 일반적인 자바스크립트처럼 비동기로 백그라운드 작업을 실행하고 응답을 먼저 줄 수가 없다.

V8 런타임이 추가되면서 Promise 나 async 함수가 추가됐지만,

내부적인 동작일 뿐 함수 자체는 동기로 동작한다.

어떻게 하면 될까?

해결책:

ClockTrigger 를 사용하는 방법으로 우회했다.

요청이 들어오면 바로 직후에 실행되는 타임 트리거를 생성하고 먼저 응답한다.

슬랙 메시지에 응답하기 위한 URL은 스프레드시트에 저장해두는 방법.

... 장황하지만 동작은 잘 된다.

아래는 코드 스니핏.

function doPost(e) {

const command = e.parameter.command;

const responseUrl = e.parameter.response_url;

let outputText = '';

if (command === '/long_task') {

runAsyncTask('longTask', responseUrl);

outputText = '작업 중...';

} ... 중략

const output = {
text: outputText
};
return ContentService.createTextOutput(JSON.stringify(output))

.setMimeType(ContentService.MimeType.JSON);

}

function runAsyncTask(funcName, responseUrl) {
const spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
const sheet = spreadsheet.getSheetByName('sample');

// responseUrl 을 스프레드시트에 기록해둔다
    sheet.getRange('A1').setValue(responseUrl);

    ScriptApp.newTrigger(funcName)
        .timeBased()
        .after(10)
        .create();
}

function longTask() {

// 오래 걸리는 작업

doSomethingLongTask();

// responseUrl 을 가져온다.

const spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
const sheet = spreadsheet.getSheetByName('sample');

const responseUrl = sheet.getRange('A1').getValue();

// 슬랙으로 다시 전달

UrlFetchApp.fetch(responseUrl, {

method: 'post',

contentType: 'application/json',

payload: JSON.stringify({ text: '작업 완료' })

});

}

참고:
- Slack Message Interaction: api.slack.com/legacy/interactive-messages

- ClockTrigger API: developers.google.com/apps-script/reference/script/clock-trigger-builder#after(Integer)

DynamoDB: 파티션키와 정렬키의 이해

ohgyun — Tue, 9 Mar 2021 00:42:26 +0900

발생일: 2021.03.09

키워드: DynamoDB, 다이나모디비, Partition Key, Sort Key, 파티션키, 정렬키, PK, SK, GSI

문제:

동료들이 다이나모디비의 파티션키(Partition Key)와 정렬키(Sort Key)의 관계를 헷갈려한다.

해결책:

처음엔 개념이 잘 잡히진 않았는데, 알고보니 간단하고 명확한 개념이었다.

다이나모디비로 설계하면서 자꾸 복잡하다고 느끼는 건,

설계 시점부터 스케일 아웃을 고려하고 있기 때문인 것 같다.

RDS에선 스케일을 고려했다기보단, 이름 그대로 관계(relation)에 집중해 설계했던 것 같다.

사용할 땐 쿼리를 조합하면 되니, 설계 시점엔 확장이나 호출 샘플보단 관계를 고민했다.

(다른 디비를 설계할 때에도 지금처럼 스케일을 고려해 설계했다면 어땠을까 싶다...)

여튼, 다이나모디비는 스케일 아웃에 중점을 둔 디비라는 걸 염두해두면 파티션키와 정렬키의 관계를 이해하기 쉽다.

파티션키는 물리적 공간인 파티션을 특정하는 키다.

- 스케일이 아무리 커져도 주소를 알고 있어서 빠르게 가져올 수 있다.

- 파티션키로는 일치하는 값만 가져올 수 있고, 조건문으로 작성할 수 없는 이유이기도 하다.

정렬키는 파티션 내에서 정렬하는 기준 값이다. (검색을 위한 최소의 조건이다)

- Number, Binary, String 타입을 지원한다. String 이라면 utf-8 기준으로 정렬된다.

- 단순한 (문자열) 인덱스라고 생각하면 될 듯 하다.

- 단순정렬이기 때문에 파티션의 사이즈가 커도 빠르게 가져올 수 있다. (eq, lt, gt 등의 비교 조건과 between, begin_with 만 지원한다)

이런 구조의 디비라면 빠르게 가져올 수 밖에 없을 것 같다.

대신, 제약 사항이 크고 유연하게 원하는 아이템을 조회하기 어렵다.

기본적인 조회 방법은 일치하는 파티션키를 주고, 정렬키로 특정 범위를 조회하는 것이다.

테이블에 보조 인덱스인 GSI(Global Secondary Index)를 만들면,

아이템을 조회하기 위한 또 다른 PK와 SK를 추가할 수 있다.

GSI를 만들면서 파티션키와 정렬키를 정할 수 있는데,

저장할 아이템의 속성 중 하나를 파티션키로, 다른 하나를 정렬키로 정하면 된다.

GSI을 추가하면 원본 테이블을 복제해 새로운 테이블을 만드는 방식이다.

복제한 원본 테이블의 아이템을

- GSI의 파티션키로 새로운 물리 공간을 할당해 저장하고,

- GSI의 정렬키로 정렬해 저장해둔다.

- 원본 테이블이 변경되면 GSI의 테이블도 동기화하는 구조다.

원본 테이블과 마찬가지로,

GSI도 파티션키와 정렬키로 특정 공간에 정렬돼 저장되어 있기 때문에,

원본 테이블과 동일한 성능 수준으로 조회할 수 있다.

물론, 빠른 확장과 안정적인 성능을 위해 다양한 제약이 있다.

- 아이템 하나의 크기는 400KB

- 한 번 조회할 때 최대 크기는 1MB

- 배치로 가져올 때에도, 최대 100개, 16MB까지

- 배치로 쓸 때에도, 최대 25개, 16MB까지

위 내용과 관련해 좀 더 자세한 내용은 아래 키워드로 검색해보면 된다.

- DynamoDB Stream

- GSI Sparse Index

- Eventual, Strong Consistent

- Hot Partition

제약 사항이 많아서 설계 과정이 어렵긴 하지만,

구조를 알고 나니 스케일 확장에도 성능은 걱정되지 않는다. :D

npm registry 를 찾지 못하는 이슈

ohgyun — Tue, 9 Mar 2021 00:04:30 +0900

발생일: 2021.02.22

키워드: yarn config, npm config, registry, npmrc, private registry

문제:

갑자기 전체 태스크가 실패했고, 건너자리 A가 코드 원복까지 했는데도 계속 지속됐다.

에러 문구를 보니 특정 npm 모듈의 리파지터리를 찾지 못하는 문제다.

node_modules 디렉토리를 날리고 새로 설치해도 동일한 문제가 발생했다고 한다.

이번에 npm registry 를 변경하는 작업을 준비하고 있었는데,

새로 설치된 모듈이 아직 준비되지 않은 새 레지스트리를 바라본 것이 문제였다.

왜 그런걸까?

해결책:

이번에 옮기려던 레지스트리는 도메인과 권한이 기존과 모두 달랐다.

예를 들어, https://old_registry.example.com 에서 https://new_registry.example.com 으로 옮기는 셈이다.

개발자들이 레지스트리 설정을 깜빡하는 경우가 있어서,

아래처럼 package.json 의 preinstall 스크립트로 config 를 설정하는 걸 미리 넣어뒀었다.

[package.json]

{

...

"preinstall": "yarn config set registry https://old_registry.example.com"

...

}

스크립트가 있어서 문제될 게 없다고 생각했는데,

문제는 테스트하던 개발자가 로컬 디바이스에서 CLI로 레지스트리를 설정했기 때문이었다.

$ npm config set registry https://new_registry.example.com

npm 의 설정이 yarn 의 설정에 우선한 것이 문제였다.

다른 포스트를 찾아보니, config 에 대한 우선순위가 아래처럼 된다고 한다.

local npmrc > global npmrc > local yarnrc

여튼, 우리는 아래처럼 정리했다.

- preinstall 에서 처리하던 설정은 모두 제거

- 레지스트리는 .npmrc 파일에 정의

- 각 개발자들의 로컬 npm config 는 정리

.npmrc 파일에 레지스트리를 추가하려면, 파일을 생성해서 아래 내용을 넣어주면 된다.

registry=https://npm.bar.com

논의:

참고로 우리는 버다씨오(verdaccio) 를 사용해서 레지스트리를 구축해뒀었다.

헌데, 버다씨오에서 해주던 프라이빗 리파지터리 기능을 이제는 깃헙에서도 할 수 있다!

우리 팀의 레지스트리도 깃헙으로 다 옮겼다!

- 깃헙 패키지: github.com/features/packages

참고:

yarnrc, npmrc 우선순위: qkrdudwls99.medium.com/priority-of-yarnrc-npmrc-a47dc01797e6

효과적인 DynamoDB 디자인 및 활용

ohgyun — Thu, 18 Feb 2021 15:55:18 +0900

발생일: 2020.02.18

키워드: nosql, dynamodb, 다이나모디비

문제:

이번엔 디비를 NoSQL로 AWS의 DynamoDB를 사용해서 구성해보려고 한다.

아키텍처 디자인을 어떻게 해야할까 고민하던 차에, A가 리인벤트 동영상을 추천해줬는데 내용이 좋다.

youtu.be/8rEsuvdL17s

아래는 보면서 정리해둔 내용.

해결책:

- 한 애플리케이션에 한 개의 테이블

- 파티션 키는 데이터를 골고루 분산하는 용도로 (데이터 분배 결정)
- 고유 값이 많은 속성(카디널리티가 높은 속성)
- 균일한 비율로 무작위로 요청되는 속성

- 정렬 키는 기존 RDS에서 인덱스를 사용하는 느낌으로 (쿼리, 다양화)
    - 1:n, m:n 관계 모델링에 활용
    - 효율적/선택적 조회
    - 범위 조회

- GSI (Global Secondary Index)
    - 별도의 속성으로 파티션과 정렬키 설정 가능
    - 인덱스 크기 제한 없고, 기존 테이블 대상으로 추가/삭제 가능
    - Eventual consistent read 만 가능
    - 테이블 당 5개까지 가능
    - 테이블과 별도의 읽기/쓰기 용량(RCU/WCU) 할당
    - 즉, 테이블 capacity는 충분한데 GSI capacity 가 부족하면 병목 발생

- LSI (Local Secondary Index)
    - 테이블과 동일한 파티션키. 파티션 내에서 정렬
    - 인덱스는 10기가 단위로 데이터와 함께 저장
    - 테이블을 생성할 때만 설정할 수 있음 (추가/삭제 불가)
    - 테이블에 할당된 RCU/WCU 사용
    - Eventual + Strong consistent 선택 가능
    - 테이블 당 5개까지 가능

- 읽기 용량 단위
    - 1 RCU = 초당 4KB 처리 단위
        - Eventual consistent = 2회
        - Strong consistent = 1회
    - 4KB로 올림 처리
        - 예: item 크기가 7KB 면 8KB로 올림
    - 즉, 가능하면 한 번에 많이 읽어와야 함

- 쓰기 용량 단위
    - 1 WCU = 초당 1KB 처리
    - 1KB 단위로 올림 처리
        - 예: 100B 를 써도 1KB로 처리
    - 즉, 가능하면 한 번에 많이 써야 함

- 조회 (Get, Query)
    - eventual, strong consistent 선택 가능
    - 1MB 단위로 응답
        - 결과량이 1MB를 넘을 땐 LastEvaluatedKey 를 ExclusiveStartKey 로 활용
    - PK 조회 (동일한 값 조회)
        - 예: PK = 1
    - SK 조회 (범위 값 조회)
        - 예: SK in 10~20, SK beginwith 'foo.'
    - LSI 조회 (테이블 용량 소진)
        - 예: PK = 1, LSI_SK = foo@bar
    - GSI 조회 (별도 용량)
        - GSI_PK: name = 'foo', GSI_SK: age > 20

- 조회 (Scan)
- 전체 테이블 필터 적용해서 선택적 조회
- 병렬 스캔 가능하지만 RCU 유의해야 함

- 모델링 (집계 처리의 예)

- 예를 들어, 음원의 상세 정보와 월별 다운로드 수를 함께 집계한다면,
    - 음원 정보 아이템
        - { PK: 'song-129', SK: 'Details', Title, Artist, ... }
    - 음원 집계 아이템
        - { PK: 'song-129', SK: 'Month-2020-02', Month: '2020-02', Downloads: 482320 }
    - 여기서 가장 많이 다운로드 된 음원을 찾으려고 한다면, GSI 설정
        - GSI_PK: Month = '2020-02', ScanIndexForwarded = False, Limit = 1 로 조회

- 모델링 (키를 다양하게 조합하고 싶은 경우)
    - PK = 아이디, SK = 집계를 원하는 공통 이름으로 설정 (타입), 속성은 타입에 따라 다름
    - 예:
        - { PK: 'emp-100', SK: 'master', 이름, 기타 기본 정보}
        - { PK: 'emp-100', SK: 'state:CA', 이름, 캘리포니아 근속 정보 }
        - { PK: 'emp-100, SK: 'state:NY', 이름, 뉴욕 근속 정보 }
        - { PK: 'emp-100', SK: 'prevtitle:A', 이름, 이전 타이틀 }
        - { PK: 'emp-100', SK: currtitle:B, 이름, 현재 타이틀 }
        - SK + 이름 조합을 GSI로 설정

- 모델링 (결합 정렬키)
- 계층 관계를 적용해서 조회하고 싶다면, 정렬키 이름을 계층으로 설정
- 예: SK: 'foo#bar#baz'

- 쓰기 샤딩
    - 예를 들어, 한 디바이스에 요청이 몰릴 때
    - 디바이스가 쓸 때, 샤드 개수를 서픽스로 붙여서 PK로 할당
    - 디바이스 - 샤드 개수를 기록

- 비용
    - 쓰기가 가장 비싼 작업
    - TTL 을 활용한 삭제와 테이블 삭제는 무료
    - 모든 데이터를 보관하려고 하지 말고, 장기간 보관이나 큰 데이터는 S3를 활용
    - eventually consistent read 는 50% 저렴. 앱 단에서 잘 설계해서 활용하면 좋음
    - 프리티어의 유효기간이 없음
        - 25GB 스토리지 + 25 WCU, 25 RCU
        - 월 2억 건 정도의 요청량임
    - 규모가 커졌을 땐 예약 용량을 활용해서 절약하는 방법 있음

- 필요한 데이터만 읽기
- GSI는 Sparse Index 임 (즉, 데이터가 있는 것만 인덱스를 만듦)
- 아이템에 타입에 따라 필요한 정보를 넣은 후, GSI를 활용

- 한 번에 최대한 많이 쓰고, 필요한 것만 읽는 것이 좋음

- 필요에 따라 auto scaling 쓰면 절약할 수 있음

논의:

한 애플리케이션에 한 개의 테이블을 추천하다고 하는데, 적합한 애플리케이션의 단위는 뭘까?

발표에서는 음원 사이트를 예로 들었는데, 이 테이블에 유저 정보도 포함된 걸까?

글쎄... 지금 생각으론, 주요 서비스 단위로 생각해보면 어떨까 싶다.

예를 들어, 음원서비스라면 이런 식으로 테이블을 나눠야 하지 않을까....?

- 유저: 사용자 기본 정보, 즐겨찾기, 아티스트

- 음원

- 아티스트

- 플레이리스트

음원과 아티스트는 한 테이블에 넣는 게 좋을까... 애매하다.

2020.02.20 추가

이후에 좀 더 리서치를 해봤다.

- 발표에서 의미했던 건, 도메인 또는 MSA 당 한 개의 테이블이라고 이해하면 좋을 것 같다.

- 즉, 위에서 언급했던, 유저, 음원, 아티스트, 플레이리스트는 한 개의 테이블로 구성해도 좋겠다.

다이나모디비와 싱글 테이블 디자인에 대한 건 나중에 정리.

JWT 개념 이해하기

ohgyun — Thu, 11 Feb 2021 11:34:37 +0900

발생일: 2021.02.09

키워드: JWT, JSON Web Token, 세션 기반, stateless, Access Token, Refresh Token, 액세스 토큰, 리프레시 토큰

문제:

이번엔 인증 과정에 JWT를 사용해보기로 했다.
건너자리 B가 코드를 다 짜왔고, 자세한 설명까지 보태서 이해가 쏙 되게 공유해줬다.

(좋은 내용을 쉽게 이해하고 왔으니^^)
레거시만 운영해왔던 J에게도 JWT를 이용한 인증 관리를 설명해주려고 한다.

기존 환경과 비교해서 이해하기 쉽게 정리해봤다.

해결책:

JWT(JSON Web Token)는 인증 토큰을 정의하는 방법에 대한 표준(RFC 7519)이다.

(여러 서버 간에) 안전하게 인증 정보를 주고 받을 수 있도록, 인증 토큰을 생성하고 해석하는 방법을 규정한다.
토큰은 JSON 포맷의 정보와 이 정보의 위변조를 막기 위해 서명한 값으로 구성돼있다.

처음이라면 익숙하지 않아서 JWT를 사용하는 용도가 헷갈릴 수 있는데,
기존 세션 기반의 인증 관리 방법과 비교해보면 이해하기 쉽다.

구현 방식은 다양할 수 있지만, 이해를 위해 대략 설명해보면 아래와 같은 차이가 있다.

세션 기반 인증

클라이언트가 로그인에 성공하면,
- 임의의 토큰을 생성한 후, 토큰을 키로 인증 정보(사용자 아이디 등)를 값으로 세션에 저장
- 클라이언트에 해당 토큰을 응답

클라이언트가 토큰과 함께 요청을 보내면,
- 서버는 세션에서 해당 토큰으로 저장된 인증 정보가 있는지 확인
- 유효하다면 인증된 요청이라고 판단

구체적인 구현 방식은 다양할 것이다.
- 인증 서버를 서비스와 별도로 뒀을 수도 있고, 한 서버에서 모두 처리할 수도 있다.
- 자체 인증 서버라면 토큰을 임의로 생성했을 테고,

- OAuth를 사용해 인증 받았다면, 발급받은 액세스 토큰으로 직접 관리하거나 또는 인증 후에 별도로 관리했을 수도 있다.
- 세션에 저장하는 정보도 서비스마다 다를 테고,
- 별도의 세션 스토리지(예: 레디스)에 저장했을 수 있고, 서버의 메모리에 저장했거나 분산해서 클러스터링으로 관리했을 수도 있다.
- 클라이언트에 응답할 때엔, 쿠키로 내려줬을 수도 있고 별도의 형태로 응답했을 수도 있다.
- 클라이언트가 요청할 땐, 쿠키에 포함해서 보낼 수도 있고 헤더에 넣어서 보냈을 수도 있다.

중요한 건, 세션에 상태(토큰과 인증 정보)를 저장하고 있었다는 것이다.

JWT 기반 인증

클라이언트가 로그인에 성공하면
- 인증 정보(사용자 아이디 등)와 이 정보가 유효한지를 검증하는 값을 포함한 토큰을 생성 (예: 인증정보+유효함)
- 검증키는 서버에 별도로 저장한 비밀키로 생성
- 생성한 토큰을 (서버에는 저장하지 않고) 클라이언트에 응답

클라이언트가 토큰과 함께 요청을 보내면,
- 서버의 비밀키로 유효한 토큰인지 확인
- 토큰이 유효하다면, 토큰에 저장된 인증 정보로 처리

큰 차이점은, 세션에 상태를 저장하지 않고 토큰만 활용해 인증을 처리하는 것이다.

역시 구현 방식은 다양할 수 있으며, 중요한 특징은 다음과 같다.
- 토큰에 인증 정보가 포함되어 있고, 공개되어 있다.
- 서버에서는 비밀키로 유효성만 확인한다.
- 인증 서버를 포함한 다른 서버는 동일한 비밀키를 소유하고 있어야 한다.

주로 여러 서비스가 하나의 인증 서버를 사용하는 환경에서 사용되고,
각 서비스에서 인증을 위해 매번 인증 서버에 요청하지 않아도 되는 장점이 있다.

위에서 설명했듯이, JWT 는 이 토큰을 정의하는 방법에 대한 표준이고,
토큰을 생성하는 방법은 홈페이지에 잘 설명되어 있다.

간단하게 설명하면, 토큰은 아래처럼 정의한다.
- A.B.C 의 형태 (각 값을 dot 으로 구분)
- A = Base64Url(header). 헤더는 JSON 포맷으로, 타입과 검증 알고리즘 정보가 있음
- B = Base64Url(payload). 페이로드는 JSON 포맷으로, 인증 정보를 포함
- C = HMAC(A.B, 비밀키). 서명값
- Base64Url 은 Base64에서 +, / 를 각각 -,_ 로 대체한 것

서버에서 요청을 받으면, 토큰을 생성하는 것과 같은 방법으로 검증한다.
- A.B.C 의 토큰을 받으면,
- HMAC(A.B, 비밀키) = C 와 동일한지 확인

더불어, 토큰의 추가적인 관리를 위해 일반적으로 payload 에는 발급자, 발급시간, 만료시간 정보를 포함한다.

JWT에 대한 자료는 워낙 많아서,
개념과 용도를 파악했다면 다른 자료를 검색해서 보면 상세히 이해될 것 같다.

논의:

발급한 토큰의 보안과 관련해 몇 가지 선택적으로 관리해야 할 사항이 있다.

이건 다음 포스트에...

참고:

- JWT 홈페이지의 토큰 구성 예제: jwt.io/#debugger-io

Salted Hashes vs. HMAC

ohgyun — Tue, 9 Feb 2021 00:49:13 +0900

발생일: 2020.05.25

키워드: HMAC, salted hash

문제:

HMAC 과 hash 에 salt 를 적용한 게 어떤 차이가 있을까?

실제로 쓰다보면 큰 차이가 없는 것 같은데...

해결책:

잘 정리된 글이 있다.

security.stackexchange.com/questions/29951/salted-hashes-vs-hmac

요약하면,

- 해시 함수는 기본적으로 길이에 제한이 있는 취약점(length extension)이 있음

(예: 모든 해시값에 대한 사전을 만들어두고 역으로 조회)

- 이런 사전형 복호화를 방어하기 위해 salt를 적용하는데, (예: hash(원본 + salt))

이렇게 해도 사전으로 복호화하면 몇 가지 패턴으로 원본과 salt를 구별해낼 수 있음

- 원래 HMAC(메시지 인증 코드, hash-based message authentication code)의 목적은 비밀번호의 단방향 해시를 생성하는 것과는 다름.

HMAC은 메시지가 공개되어 있고, key가 비밀임. 메시지의 무결성과 송신자 여부를 확인하기 위한 것임. 그래서 salt 대신 key라는 용어를 씀. 예) hmac(message, key)

- hmac은 중첩적으로 수십~수만번 hash 처리함(물론 salt를 써야함). 사전으로 복호화하더라도 많은 비용이 듬.

결론: hmac 이 단순히 hash + salt 하는 것보단 약칸 느리지만 안전하겠음

lock=none, algorithm=inplace 으로 테이블 변경하기

ohgyun — Tue, 9 Feb 2021 00:39:58 +0900

발생일: 2020.07.30

키워드: mysql, aurora, DB 컬럼 추가, DB 인덱스 추가, add index without lock, add column

문제:

크기가 큰 MySQL (Aurora) 테이블에 컬럼이나 인덱스를 추가하려고 한다.

테이블 크기가 큰 경우, 락 타임이 길어져서 운영 중일 땐 문제가 발생할 수 있다.

어떻게 하면 될까?

해결책:

algorithm 절과 lock 절을 이용하면, 락을 걸지 않고 컬럼이나 인덱스를 추가 또는 삭제할 수 있다.

컬럼 추가

규모가 큰 larget_table 에 new_date 란 이름으로 DATETIME 형식의 컬럼을 추가한다고 가정하면, 아래와 같이 하면 된다.

ALTER TABLE large_table
ADD new_date DATETIME null, ALGORITH = INPLACE, LOCK = NONE;

인덱스 추가

large_table 의 new_date 컬럼에 new_date_index 를 추가한다고 가정하면, 아래와 같이 하면 된다.

ALTER TABLE large_table
ADD INDEX new_date_index (new_date), ALGORITH = INPLACE, LOCK = NONE;

시간이 조금 걸리더라도 인내를 갖고(?) 기다리면 된다.

운영 중인 5천만 행 정도 되는 테이블을 수정했는데, 3분 정도 후에 특별한 문제 없이 적용됐다.

논의:

추가하려는 컬럼이나 인덱스가 여러 개라면, 한 번에 하나씩 하는 게 안전하다.

ALTER TABLE 명령에서 여러 태스크를 실행하면 복잡도가 높아지면서 INPLACE 대신 COPY 로 전환될 수 있나보다.

참고:

- 자세한 설명: http://www.gurubee.net/lecture/4184

- 여러 컬럼은 나눠서 하는 게 좋음: https://stackoverflow.com/questions/46970401/mysql-add-multiple-column-to-large-table-in-optimised-way

DeepLearning.AI TensorFlow Developer 노트

ohgyun — Tue, 9 Feb 2021 00:25:41 +0900

발생일: 2020.11.25

키워드: tensorflow, coursera, 코세라

내용:

코세라의 TensorFlow Developer 강좌 노트

www.coursera.org/professional-certificates/tensorflow-in-practice

(간단하게 기억을 더듬는 용도로 적어둔 노트임)

CNN
- DNN (Densed Neural Network), CNN (Convolutional Neural Network)
- loss functions: binary_crossentropy, categorical_corssentropy
- activation functions: relu, softmax, sigmoid
- optimizer: sgd, rmsprops, adam, ...
- callbacks
    - on_epoch_end
- Convolution (Conv2D), Max Pooling
- History: history = model.fit()
- Transfer Learning: Pre Trained Model, In
    - x = keras.layers.Flatten(last_output)
    - Model(pre_trained_model.input, x)
    - lock train: model.trainable = False
- Drop Out
- ImageDataGenerator
    - rescale (normalize image size)
    - flow_from_directory
    - Image Augmentation (shear, zoom, flip, fill_mode, ..)
    - class_mode: binary, categorical

NLP
- Token, Corpus
- Dictionary (=word_index)
- Text (= Sentences) -> Sequences
- oov_token = out of vocabulary
- Padding: pad_sequences
- Word Embedding
    - 단어를 숫자로 표현하는 다른 방식 중의 하나
    - label 에 따라 비슷한 의미지를 가진 단어를 시맨틱하게 벡터 공간에 표시
    - corpus 에서 특징 추출
- Embedding Weights = (vocab_size, embedding_dimension)
- GlobalPooling1D = 단어 수에 관계없이 pooling
- https://projector.tensorflow.org
    - 벡터(vecs.tsv), 메타데이터(meta.tsv) 를 저장해서 시각화할 수 있음
    - 강의 깃헙
- Sub-words: 단어를 n-gram 으로 토크나이징해주는 기능
    - 단어의 순서가 존재만큼 중요하다
    - oov가 없다
    - 설명링크
- RNN (Recurrent Neural Network)
- Sequence Model: RNN 같은 걸 시퀀스 모델이라고 함
- LSTM (= Long Short - Term Memory)
    - RNN의 한 종류
    - 이전 결과를 유지하면서 학습
- GRU (= Gated Recurrent Units)
    - RNN의 한 종류
- CNN을 사용해서 분류할 수도 있음
- Bidirectional(LSTM())

Sequences
- Time Series data
    - 정해진 시간 단위의 데이터
    - Univarite, Multivarite 해당 시간에 값이 1개, 여러 개
    - 이동 경로 같은 것도 해당(예: 자동차의 시간에 따른 위경도 위치)
    - 데이터 특징, Trend, Seasonaliy, Autocorellation, Noise
- 시계열 데이터의 데이터 분리
    - 시즈널한 특징을 갖는 경우, 연도나 월 단위로 쪼개는 것이 유리
    - 과거 1을 학습 데이터, 과거 2를 검증 데이터, 가장 최근을 테스트 데이터로
    - 1 + 2 를 학습데이터로, 최근을 검증데이터로 한 번 더 학습 가능
- Fixed partitioning vs. Roll-forward partitioning
    - 롤포워드는 기간을 잘게 쪼개서, 하루, 주간 단위로 테스트
    - 짧은 기간부터 시작해 늘려가면서 테스트하는 방식
- 에러 종류
    - mse = mean square error, 에러 총합이 마이너스가 되는 것 방지. 에러가 큰 경우 제곱으로 가중치가 적용됨.
    - rmse = root mse,  루트를 적용해 스케일을 원래 오류와 동일하게 할 목적
    - mae = mean absolute error, 절대값 오류의 합을 평균. 큰 에러나 작은 에러의 편차가 중요하지 않은 경우
    - mape = mean absolute percentage error, 오류의 퍼센트의 절대값으로 평균
- naive forecast
    - 단순히 이전 값으로 예측
    - 이 값을 기준값으로 설정할 수 있음
- Moving Average (이동평균)
    - 단순하지만 노이즈를 줄일 수 있는 방법
    - 트렌드나 주기를 예측하진 않음
    - naive forecast 보다 정확도 낮음
- Moving Average of Differencing (기간 차의 이동평균을 활용)
    - 예를 들어, 1년 전의 값의 차이를 계산하고, Vdiff = (Vt - V(t-365))
    - Vdiff 의 이동평균을 계산 (Vt_diff_average)
    - 이전 날짜에 Vdiff를 이동평균한 값을 더해 다음 값을 예측: V(t-365) + Vt_diff_average
    - Forecasts = moving averaged differenced series + series(t - 365)
    - 이래도 노이즈는 남아있는데, 이럴 때 V(t-365) 대신 과거값을 이동평균한 값으로 사용하면 부드러워짐
    - 즉, forecasts = Vmoving_agerage(t-365) + Vt_diff_average
    - Forecasts = trailing moving average of differenced series + centered moving average of past series(t-365)
    - 과거 값에 centered 이동 평균을 사용했고 (예: 시간 + 5와, 시간 - 5 사이의 평균) 이게 더 정확함. 현재값에 적용할 땐 trailing 이동 평균을 적용했는데, 이건 미래의 값을 알 수 없기 때문
- Deep Learning for Time Series
    - 특정 윈도우 사이즈에 해당하는 시간  x 의 y 값이 input, 다음 시간의 y 값이 label
    - tf.data.Dataset: range, flat_map, map, batch, shuffle...
    - Sequence bias: 시퀀스에서의 순서 편향이 있을 수 있다. 예를 들어, 첫 번째 나온 게 더 익숙하게 느껴질 수 있다. 훈련 데이터는 섞어서(shuffle) 쓰는 게 좋다.
    - callbacks.LearningRateScheduler 를 콜백으로 해서, 적합한 러닝 레이트를 찾을 수 있다.
        - 근데 그냥 adam 으로 설정한 게 더 나은 것 같다?
    - numpy array를 새로 생성할 때: np_array[np.newaxis] 로 생성할 수 있음
- RNN for Time Series
    - RNN에서 텐서플로우의 기본 유닛 개수는 3개 (해서, 배치사이즈 x 유닛 개수의 행렬이 셀의 아웃풋이 됨)
    - 셀의 중간 아웃풋을 생략하고 최종만 가져가는 걸 sequence to vector RNN 이라고 하는데, 이게 기본 동작임
        - 전체 시쿼스를 전달하려면 (sequence to sequence RNN), return_sequences = True 옵션을 쓰면 됨
    - RNN의 input 은 3 dimension
        - batch_size: 정해지지 않은 경우 None 으로 설정하면 됨
        - number_of_timestamp: None 으로 설정하면 길이에 무관하게 처리할 수 있음
        - 변수 개수: univariable 인 경우 1, 여러 개인 경우 숫자만큼
    - RNN의 기본 activation function 은 tan H 임
        - -1 ~ 1 값임
        - 예제에선 실제 학습 데이터가 0~100 사이라서, 람다 레이어에서 결과 값은 100배 해서 스케일을 비슷하게 맞췄음
- Lambda Layer
    - keras.layers.Lambda: 전처리/후처리를 한 플로우 안에서 처리할 수 있음
- Humber loss function
    - 아웃라이어에 덜 민감한 로스 함수
    - MAE 보다는 민감하고, MSE 보다는 덜 민감한 듯
- SimpleRNN vs LSTM
    - SimpleRNN 은 상태값이 다음 셀에만 적용이 돼서 시간이 지날수록(다음 단계로 갈수록) 처음 값의 영향이 작아짐
    - LSTM 은 셀의 상태(Cell State)를 정해진 기간동안 유지할 수 있고, 양방향으로도 처리할 수 있음. 즉 처음 값의 영향이 시간이 지나도 유지됨
- 실습 과제
    - Conv1D + 2 LSTM + 3 Dense layer 로 예측

강연: 호갱노노 이렇게 만듭니다

ohgyun — Mon, 8 Feb 2021 23:50:09 +0900

발생일: 2020.11.26

키워드: 호갱노노, 삼성전자

내용:

삼성전자 R&D 센터에 초청받아 강연하고 왔다.

R&D 센터는 이번이 두 번째 방문이다.

한 때 나름 인기가 많았던ㅎㅎ 코드리뷰 경험을 주제로 강연을 부탁받아서 다녀왔었다.

벌써 4년 전 일인데, 당시 환대해주셔서 특히 기억에 남는다.

올해는 개발 문화를 주제로 하는 전사 사내 컨퍼런스라고 소개받았다.

최근에 시간적인 여유도 조금 생겼고, 마음 편하게 다녀왔던 생각에 큰 부담을 갖지 않고 수락했다.

양재라서 가깝고 주차도 편했던 건 덤^^

막상 수락하고 보니 어떤 내용을 공유할까 고민이 많았다.

삼성전자와 호갱노노는 규모나 업종, 프로세스나 성향까지 크게 달라서, 개발 문화가 의미있을까 싶기도 했다.

고민 끝에, 호갱노노에서 개발자들이 직접 기획해서 개발하고, 운영까지 담당한 과정을 주제로 골랐다.

뜯어보면 특별할 것도 없고, 삼전에서는 직접 적용해보기도 어려운 내용이다.

하지만, 이런 방식은 스타트업 같이 작은 규모에서만 가능할 것 같아서, 간접 경험을 제공한다는 생각으로 정리해봤다.

아래는 강연 슬라이드. (영상 녹화본은 외부 공개를 하지 않기로 했다.)

호갱노노 이렇게 만듭니다 from Ohgyun Ahn

후기:

전사 컨퍼런스인데 코로나 때문에 온라인으로 진행한다고 해서, 당일엔 소수 인원으로 녹방으로 진행했다.

작은 강의실에서 부담 없이 편한 마음으로 녹화했는데, 컨퍼런스 당일엔 1200명 정도 시청했다고 해서 놀랐다.

컨퍼런스 후에 온라인으로 피드백 받은 걸 보내주셔서 받았는데, 생각했던 것보다 좋게 봐주셔서 너무 좋았다.^^

클럽하우스와 음성 데이터

ohgyun — Thu, 4 Feb 2021 13:39:10 +0900

발생일: 2020.02.03

키워드: 클럽하우스, clubhouse, voice data, voice recognition, 음성 인식

내용:

요새 클럽하우스가 인기인가보다.

음성 기반의 SNS 서비스이다.

초대 받아 들어가서 잠깐 체험만 해보았는데, 음성 데이터의 가치가 엄청날 것 같아 보인다.

얼마 전에 1조 가치로 투자 받았다는데, 이런 특징들이 클럽하우스의 내재 가치를 올려주었던 게 아닐까 생각해봤다.

- 화자가 명확한 음성 데이터를 수집할 수 있다는 것
- 다자간 음성 대화를 주제별로 분류할 수 있는 것

음성 인식 시장에 대해 잠깐 검색해봤는데, 생각보다 훨씬 규모가 크고 다양하게 활용되고 있는 것 같다.

음성 인식 시장의 가치
- 음성 인식 시스템, 음성 지원 가상 비서, 소매, 은행, 커넥티드 장치, 스마트 홈, 의료 및 자동차 분야에 적용 가능
- 2020년 108억 달러(12조), 2026년 27000억 달러(2970조 원) 예상
- 특히, BFSI 산업에서 수요 증가
    - BFSI: Banking, Financial services, Insurance
    - 중국 생체 인식 기술 수요는 2021년까지 340억 위안(5조원) 예상
    - 온라인 거래에서 음성으로 인식하는 쪽으로 사용하는 듯
    - 예를 들어, 고객이 전화 문의하는 동안 고객의 신원이 확인됨
- 미국 분석회사 ComScore는 검색 트래픽의 50%가 음성으로 검색될 거라 예상
- 구글에 따르면, 구글 모바일 앱 쿼리의 20%는 음석 검색임

클럽하우스와 음성 데이터의 머신러닝 활용에 대해서 검색해보니, AI 커뮤니티에서는 이런 식으로 활용될 거라고 예상하는 것 같다.
- 개인의 신원 증명
- 음성 대화로 감정 분석에 활용
- (예: 대화를 듣고 이 사람이 슬픈지 기쁜지 알 수 있다는 것인 듯)
- 다국어 다자간 대화의 음성 인식
- (클럽하우스 이전에는 동일한 주제에 대해 다양한 언어로 대화하는 소스가 많지 않았을 것 같다)

참고:

- 클럽하우스: www.joinclubhouse.com/

- 클럽하우스 1조 가치로 투자 받음: www.theinformation.com/articles/clubhouse-gets-investment-interest-at-1-billion-valuation

- 음성 인식 시장의 가치: www.mordorintelligence.com/industry-reports/voice-recognition-market

- 클럽하우스와 보이스 AI: voicebot.ai/2021/01/31/clubhouse-social-audio-network-1b-valuation-3m-users-and-the-intersection-with-voice-ai/

뉴스: GPT-Neo 를 개발하고 있다는 소식

ohgyun — Thu, 4 Feb 2021 11:58:05 +0900

발생일: 2020.02.04

키워드: GTP-3, GTP-Neo, NLP

내용:

화제가 됐던 NLP 모델인 GTP-3의 무료 복제본인 GPT-Neo 를 개발하고 있다는 소식

GPT-Neo
- GTP-3 의 복제 버전을 무료 공개용으로 제작할 목적
- GTP-3는 현재 마이크로소프트가 독점 라이선스를 가지고 있음
- 올해 8월 초까지 완성할 계획으로 목표는 GTP-3와 동일한 수준으로 구현하는 것
- 파라미터 1750억개의 버전이 목표이고, 현재 파라미터 1000억개까지는 완료함
- 사회적 편견을 없애는데 주의를 기울이고 있음
- CoreWeave 라는 클라우드 서비스가 인프라를 무료로 제공해주기로 함
- 학습 데이터는 825GB
- 텍스트 데이터셋, IRC 챗로그, 유튜브 자막, 의학 연구 보고서 등
- 성별, 종교, 인종 편견에 데이터를 평가하기 위해 감정 분석을 사용함
- 너무 심한 수준의 편향 데이터는 학습 데이터에서 제거함

파라미터는 뉴럴 네트워크 내 뉴런의 개수라고 이해하면 될 것 같다.

여러 사례를 보면, NLP에서는 다양한 측면에서 감정 분석을 활용하고 있는 것 같다.

문장의 의미 뿐 아니라 분위기를 이해하는 것이 모두에게 도전적이고 중요한 일인 것 같다.

얼마 전에 본 포스트에선 GTP-3를 학습하려고 쿠버네티스로 GPU 인스턴스를 동시에 7500대를 띄워서 작업했다는 내용도 있더라.
위 소식의 파라미터 수도 그렇고, 인스턴스 수도 그렇고, 놀라울 따름이다.

물론, 기존 모델을 활용해서 적은 데이터로 의미있는 결과를 냈다는 뉴스도 많으니... ㅎㅎ

참고:

GTP-Neo: https://www.eleuther.ai/projects/gpt-neo

GTP-3 쿠버네티스: openai.com/blog/scaling-kubernetes-to-7500-nodes/

AWS: ElasticSearch 사이즈 최적화

ohgyun — Wed, 3 Feb 2021 23:56:13 +0900

발생일: 2020.07.28

키워드: aws, elasticsearch size, 사이즈, node size, 노드 사이즈

문제:

AWS 엘라스틱서치에 몇 가지 검색을 추가해 넣으려고 한다.

예전에 몇 번 다운됐던 적이 있어서, 미리 적합한 사이즈를 알아보려고 한다.

어느 정도가 적합한 걸까?

해결책:

사이즈 찾는 가이드 문서가 있다.

https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/sizing-domains.html

적합한 스토리지 사이즈
- 클러스터 > 노드 > 샤드
    - 물리 서버에 여러 노드를 생성할 수 있지만, AWS ES에서는 한 인스턴스의 한 개의 노드만 있는 듯
- 마스터 전용 노드(Dedicated Master Node)는 홀수로 3개 이상 권장
    - Split Brain 이슈: https://esbook.kimjmin.net/03-cluster/3.3-master-and-data-nodes
- 각 노드의 복제본(리플리카) 개수는 1개 이상 권장 (기본값: 1)
- 인덱스 사이즈는 보통 데이터 전체 사이즈보다 10% 정도 더 커짐
    - 예: 대상 데이터 100메가 -> 인덱스 포함 110메가, 여기에 리플리카 1개 하면 220메가
- 리눅스 OS는 기본적으로 5% 정도의 공간을 주요 프로세스에 할당함
- Amazon ES 시스템은 인스턴스 별로 20% 정도의 공간(최대 20GB)를 예약 점유함
    - 인스턴스 당 최대 20기가이기 때문에, 노드 개수에 따라 달라짐
    - 예: 노드가 10개면 200기가가 예약 공간으로 잡힘
- 간단 계산 방식: 원본 데이터 크기 * (1 + 리플리카 개수) * 1.45 = 최소 필요 공간
    - 자세히: 원본 데이터 크기 * (1 + 리플리카) * (1 + 인덱스 크기) / ( 1 - OS 점유 비율) / ( 1 - AWS ES 비중) = 최소 필요 공간
- 예: 원본이 100기가, 리플리카 1 이면,
    - 100GB * (1 + 1) * 1.45 = 290GB가 필요
    - 현재: 1.3기가 = 1.3 * 2 * 1.45 = 3.7기가 (현재 스토리지 = 10기가)

노드 모니터링
- GET _cat/indices?v 로 볼 수 있음
    - health - 인덱스 헬스 상태 (green, yellow, red)
    - status - 인덱스 open 상태 (open, close)
    - pri - 프라이머리 샤드 갯수
    - rep - 리플리카 샤드 갯수
    - docs.count - 도큐멘트 갯수
    - docs.deleted - 삭제된 도큐멘트 갯수
    - store.size - 리플리카를 포함한 실제 저장된 사이즈
    - pri.store.size - 프라이머리 실제 저장된 사이즈
- GET /_cat/allocation?v
    - shards - 샤드 갯수
    - disk.indices - 인덱스가 사용하고 있는 디스크 용량
    - disk.used - 실제 시스템에서 사용된 디스크 용량
    - disk.avail - 실제 시스템에서 사용 가능한 디스크 용량
    - disk.total - 실제 시스템에서 전체 디스크 용량
    - disk.percent - 실제 시스템의 디스크 용량 사용률

샤드 개수 정하기
- 프라이머리 샤드는 인덱스 생성 후 변경하기 어렵움
- 샤드 개수를 설정하는 목적은 클러스터의 모든 노드에 인덱스를 고르게 분산시키는 것
- 샤드 개수가 너무 많거나, 한 개의 샤드 사이즈가 너무 크면 안됨
    - 용량이 너무 크면 실패 복구에 비용이 많이 듬
    - 샤드 운영에 CPU와 메모리가 소모되므로, 작은 샤드가 너무 많은 경우라면 비효율적임
- 대략 10~50기가 정도의 크기인 것이 좋음
- 간단 계산법: 인덱스 크기 / 원하는 샤드 사이즈
    - 예: 데이터 사이즈가 60기가고, 샤드 하나의 크기를 30기가로 생각한다면,
    - (60 * 1.1) / 30 = 2개 (1.1을 곱하는 건 인덱스 크기가 10% 정도 크기 때문)
- 내년에 용량이 4배로 증가할 것 같다고 미리 샤드를 여러 개 만들어두는 것보다는, 적당한 개수로 설정해서 사용하다가 인덱스를 새로 생성하는 것이 효율적임
- 엘라스틱서치 7버전은 노드 당 샤드 개수를 1000개로 제한하고 있음
    - 수정이 필요한 경우, cluster.max_shards_per_node 설정을 변경하면 됨
- 또한, 1개의 노드에서 자바 힙 사이즈 기준으로 기가 당 샤드의 개수는 20개 이하여야 함
    - 예를 들어, m5.large.elasticsearch 인스턴스는 4기가 힙을 가지고 있음
    - 이 노드의 샤드의 개수는 4 * 20 = 80개 이하여야 함
    - 이 계산에 따르면 샤드 사이즈가 5기가가 되는 거라 권장 사이즈보다 작게 됨
    - 보통 샤드의 권장 사이즈(10~50기가)를 따르면 이 문제는 발생하지 않을 것임

인스턴스 타입 정하기
- https://aws.amazon.com/ko/elasticsearch-service/pricing/
- 샤드가 많거나, 집계를 많이 하거나, 도큐먼트를 자주 업데이트하거나, 쿼리가 많거나 하는 경우엔 더 좋은 인스턴스가 필요함
- 스토리지 100기가 당, 적어도 2 vCPU + 8GiB 메모리로 시작하는 것을 권장함
    - 예: 데이터가 200기가면 4 vCPU + 16GiB
- 2개의 데이터 노드와 3개의 마스터 노드로 시작하는 것을 권장함 (Split brain 이슈 등을 피하기 위함)
- 예: 전체 데이터가 184기가이고 노드가 3개라면,
    - 노드 당 184 / 3 = 61기가가 필요함
    - 이 정도면, m5.large.elasticsearch (2 vCPU, 8GiB)인스턴스가 적당함 (90GiB ESB 스토리지를 쓰는데, 늘어나는 것 고려하면 충분)
    - 그럼 총 6 vCPU, 24GiB를 쓰는 셈
- 실제 데이터를 넣고 테스트했을 때, CPUUtilization 이나 JVMMemoryPressure 수치가 높다면 더 좋은 인스턴스를 사용해야 함
- 시스템이 다운되는 것보다는 오버파워되는 게 나으니까, 좋은 걸로 시작했다가 점차 줄이는 것을 추천함

참고:
- https://github.com/itmare/es

엘라스틱서치 시작하기 노트

ohgyun — Wed, 3 Feb 2021 23:50:10 +0900

발생일: 2020.07.25

키워드: 엘라스틱서치, elastic search

문제:

엘라스틱서치로 검색을 구현하려고 한다.

시작하기 문서를 찾아서 봤는데, 너무 이해하기 쉽게 잘 설명해준다.

아래는 노트해둔 것.

해결책:

엘라스틱 서비스
- Kibana 시각화 도구
- Elastic Search 검색 도구
- Beats, Logstash 수집 도구
- 이거 합해서 엘라스틱 스택

기타 기능
- 엘라스틱 사이트 서치: 사이트 URL 넣으면 색인 모두 만들어줌. 자동완성과 검색 제공하는 자바스크립트 모듈만 넣으면 된다고 함
- 엘라스틱서치 사이트에서 support matrix 라고 검색하면 지원환경 알 수 있음
- 엘라스틱서치 7버전부터 JDK를 같이 포함하고 있어서 자바 설치 안해도 됨

디렉토리 설명
- 다운로드: https://www.elastic.co/kr/downloads/elasticsearch (MacOS 용 다운로드 받음)
- config 내 elasticsearch.yml (야믈 파일)이 가장 중요한 설정

elasticsearch.yml
- network.host: 파일에 호스트를 설정해야 프로덕션으로 가능함
- http.port: 기본적으로 REST API로 통신함. 기본 포트는 9200

용어
- 도큐먼트: 단일 데이터
- 인덱스: 도큐먼트 집합. 저장 단위인 인덱스는 indicies 라고 표현하기도 함
- 색인: 저장 행위
- 샤드: 인덱스는 기본적으로 샤드(shard)라는 단위로 분리되고, 각 노드에 분산되어 저장됨

실행 및 테스트
- 실행할 땐 ` bin/elasticsearch` 으로 하면 됨. 노드 이름으로 실행됨
- 9300번 포트로 다른 서비스와 통신, 9200번 포트로 클라이언트와 통신
- $ curl localhost:9200

데모
- https://github.com/kimjmin/elastic-demo/tree/master/demos/get-started
- 색인 생성 데모
    - https://github.com/kimjmin/elastic-demo/blob/master/demos/get-started/elasticsearch-7x.md
- PUT/GET
    - 구조는 localhost:9200/[인덱스명]/_doc/[도규먼트ID]
    - 7.0부터는 타입 개념이 없어져서 _doc 으로 붙으면 됨
    - PUT으로 REST API로 넣을 수 있음
    - 넣고 나서는 같은 이름으로 GET으로 가져올 수 있음
    - 엘라스틱서치는 한 URL이 한 도큐먼트를 가리키고 있음 (같은 URL로 넣으면 덮어써짐)
- POST
    - POST는 도큐먼트 ID를 자동으로 생성함
- DELETE
    - DELETE 로 삭제하면 되고, 도큐먼트 또는 인덱스 단위로 모두 삭제할 수 있음

키바나 데모
- config/kinana.yml 이 주요 설정 파일
- 로컬 호스트가 아니라 엘라스틱서치와 다른 서버로 실행하고 싶다면, elastic_server 설정 변경하면 됨
- bin/kinana 로 실행. 5601번 포트가 기본 포트
- 메뉴 > Dev Tools 에 가면 여러 가지 테스트해볼 수 있음

Bulk API
- 대용량인 경우, 기본가 bulk는 10배 이상 차이남
- POST /_bulk
- index, create, update, delete 동작 가능
- delete를 제외하고, 명령문과 데이터문을 한 줄씩 순서대로 입력
    - 또한, 명령문과 데이터문은 반드시 한 줄 안에 입력되어 있어야 함 (줄바꿈을 허용하지 않음)
- 모든 명령이 동일 인덱스에서 수행되는 경우엔, 인덱스명/_bulk API 로 호출할 수 있음
- 엘라스틱서치는 커밋이나 롤백 등 트랜잭션 개념이 없음
    - _bulk 작업 중 연결이 끊기거나 시스템 다운 등으로 동작이 중단된 경우, 어디서 중단됐는지 확인 불가함
    - 이럴 땐 인덱스를 삭제하고 처음부터 다시 하는 것이 안전함

Search API
- GET 인덱스/_search 로 요청
    - q 파라미터로 검색어를 전달할 수 있음. /_search?q=value
    - q="a and b" 나, q=field:value 같은 패턴으로 검색 가능
- 데이터 본문으로 검색: query 옵션으로 검색 조건을 씀
    - match: 필드 + 검색어로 설정함
        - 검색어는 term 이라고 함. 공백으로 구분하면 기본적으로 OR 조건. 예) dog fox
        - AND를 하려면 "operator": "and" 조건을 주면 됨
    - match_all: 인덱스의 모든 것을 가져옴
    - match_phrase: 검색어를 하나의 구문으로 검색함
        - slop: 1 옵션을 주면, '스키 장갑' 같은 검색 시, '스키 벙어리 장갑', '스키 보드 장갑'도 검색 가능
- 엘라스틱서치의 Query 구문은 모두 JSON 형식으로 입력함
    - 베이직 이상 라이렌스에서는 표준 SQL문을 사용해 검색 가능하지만, 기능에 제한이 있으므로 JSON 형식을 쓸 것을 권장함

멀티테넌시 (Multitenancy)
- 엘라스틱서치는 여러 인덱스를 한꺼번에 묶어 검색할 수 있는 멀티테넌시를 지원
- logs-2020, logs-2019 같은 인덱스가 있다면, logs-*/_search 명령으로 한꺼번에 검색 가능
- 인덱스는 쉼표(,)나 와일드카드(*)로 묶을 수 있음
- GET logs-2020,logs-2019/_search
- GET logs-*/_search

복합 쿼리
- 복합 쿼리. query에서 "bool" 옵션으로 서브쿼리를 조합할 수 있음
    - must: 쿼리가 참인 도큐먼트들을 검색
    - must_not: 쿼리가 거짓인 도큐먼트들을 검색
    - should: 검색 결과 중 이 쿼리에 해당하는 도큐먼트의 점수를 높임
    - filter: 쿼리가 참인 도큐먼트를 검색하지만 스코어를 계산하지 않음. must 보다 검색 속도가 빠르고 캐싱됨.
- 각 항목에 서브쿼리를 배열로 전달할 수 있음
- 예를 들어, 특정 아파트의 리뷰만 검색하려고 한다면,
    - must 에는 키워드를,
    - filter 에 아파트 아이디를 넣는 방법 (스코어에 영향을 주지 않고 더 빠르니까)
- should 는 match_phrase 와 함께 쓰면 유용함
    - 예를 들면, 검색 결과 중 입력한 검색어 전체 문장이 정확히 일치하는 결과를 맨 상위에 위치시킬 수 있음
    - 나머지 결과는 누락하지 않은 채 볼 수 있음
- 복합쿼리 안의 배열은 AND 조건임
    - 예: must: [ { queryA }, { queryB } ] -> queryA AND queryB 를 의미
    - OR는 검색어를 공백으로 구분해 적용할 수 있음

Relevancy (정확도)
- https://esbook.kimjmin.net/05-search/5.3-relevancy
- 검색 결과의 스코어는 BM25 알고리즘을 사용함
    - BM25 계산식은 TF, IDF, Field Length를 사용함
    - TF: Term Frequency. 도큐먼트 내에 검색된 텀(Term)의 개수가 많을수록 점수가 높음. BM25에서는 최대 25까지 증가함
    - IDF: Inverse Document Frequency. 검색한 텀을 포함하고 있는 전체 도큐먼트의 개수가 많을수록, 해당 텀의 점수가 감소함
    - Field Length: 텀을 포함하고 있는 필드의 길이가 짧을수록 점수가 높음.

Exact value query (정확값 쿼리)
- 풀 텍스트는 정확도를 측정해서 스코어로 정렬함
- exact value 쿼리는 참/거짓 여부만 판별해서 결과를 가져옴
- term, range 같은 쿼리가 이 대상임
- 문자열 데이터는 keyword 형식으로 저장하면 정확값 검색이 가능함
- 예: message 필드가 있다면, message.keyword 필드를 검색 대상으로 잡으면 됨
- 스코어를 계산하지 않기 때문에 보통 bool 쿼리의 filter 내부에서 사용함
- filter 안에 넣은 검색 조건들은 스코어를 계산하지 않지만 캐싱이 되기 때문에 쿼리가 더 가볍고 빠르게 실행됨
- 스코어 계산이 필요하지 않은 쿼리들은 모두 filter 안에 넣어서 실행하는 것이 좋음

Range 쿼리
- range 쿼리
    - gte (Greater-than or equal to): 이상 (같거나 큼)
    - gt (Greater-than): 초과 (큼)
    - lte (Less-than or equal to): 이하 (같거나 작음)
    - lt (Less-than): 미만 (작음)
- format 속성을 정의할 수 있음
    - y, M, d, H, m, s 로 입력 가능
    - 예: "format": "yyyy-MM-dd"
    - 예: "format": "yyyy-MM-dd||yyyy" (|| 로 OR 패턴을 넣을 수 있음)
- 날짜인 경우 키워드로 조회할 수 있음
    - 예: "gt": "now-2y": 오늘부터 2년 전 이후보다 큰 값
    - 예: "gt": "2020-01-01||+6M" -> 2020년 1월 1일에 6개월을 더한 값보다 큰 것
- range 또한 스코어가 없어서 filter 조건으로 넣는 것이 좋음
    - range 에 따른 스코어를 주고 싶을 땐 function_score 쿼리를 사용해서 조정이 가능함

텍스트 분석
- 엘라스틱서치에 색인될 때 검색에 필요한 형태로 분리됨
- API _analyze 로 애널라이저(analizer) 정보를 볼 수 있음
    - 애널라이즈 만들기 전에 미리 분석해보면 좋을 듯
- 애널라이저(analizer)는 토크나이저(tokenizer)와 여러 개의 필터(filter)로 구성됨
    - Tokenizer 을 통해 문장을 검색어 텀(term)으로 쪼갬
    - Filter(토큰필터) 를 통해 쪼개진 텀들을 가공
        - 필터 예: lowercase, unqiue, stop(불용어 제거)
- T: standard, F: lowercase -> 스탠다드 토크나이저 + lowercase 필터

역인덱스 (Invereted Index)
- https://esbook.kimjmin.net/06-text-analysis
- 데이터를 저장할 때 검색 가능한 term (검색어 토큰) 으로 색인을 생성함
    - 예: doc1 = 'lazy dog' -> lazy: doc1, dog: dog1 과 같이

- 엘라스틱서치에 저장되는 도큐먼트의 모든 문자열(text) 필드의 역 인덱스를 생성함
- 애널라이저(Analyzer)
    - 텍스트 분석 (Text Analysis) 과정: 문자열 필드가 저장될 때, 데이터에서 검색어 토큰을 추출하는 여러 과정
    - 텍스트 분석을 처리하는 기능 = 애널라이저
- 애널라이저
    - 0~3개의 캐릭터 필터, 1개의 토크나이저, 0~n개의 토큰 필터로 이루어짐

    - 캐릭터 필터(Character Filter)
        - 전체 문장에서 특정 문자를 대치하거나 제거
        - 예: 특수문자 제거, 특정 키워드 치환
        - 7.0 기준으로 strip, mapping, pattern replace 3개가 있음
        - char_filter 항목에 배열로 입력 가능
    - 토크나이저(Tokenizer)
        - 문장에 속한 단어들을 텀 단위로 하나씩 분리
        - 토크나이저는 반드시 1개만 적용이 가능함
        - 예: whitespace 토크나이저: 공백을 기준으로 텀 들을 분리
    - 토큰 필터(Token Filter)
        - 분리된 텀을 가공
        - 예: lowercase 토큰 필터: Lazy, lazy 를 같은 텀으로 병합
        - 예: stop 토큰 필터: 검색 가치가 없는 단어를 불용어(stopword)로 간주해 토큰에서 제외
        - 예: snowball 토큰 필터: 문법상 변형된 단어를 기본 형태로 변환, jumps -> jump, jumping -> jump
        - 예: synonym 토큰 필터: 동의어를 텀으로 추가. quick -> fast 를, aws -> amazon 을 추가
    - 애널라이저를 정의해서 바로 할당할 수 있음
    - 검색 시 검색어도 애널라이저를 거쳐 term 으로 변형돼, 색인된 값을 검색함
        - 한국어 형태소 분석기를 쓴다면, '수영장' -> '수영' + '장'으로 분리되어 검색되는 것임
    - 검색할 때 애널라이저를 적용하지 않으려면 "term" 쿼리를 사용하면 됨
        - 예: "query": { "term": { "message": "jump" } }

사용자 정의 애널라이저
- https://esbook.kimjmin.net/06-text-analysis/6.3-analyzer-1/6.4-custom-analyzer
- 인덱스에 적용할 땐 사용자 정의 애널라이저를 만들어 적용하는 것이 편함
- PUT 인덱스명/_analyze 로 추가
    - settings 프로퍼티로 커스텀 애널라이저와 커스텀 필터를 먼저 설정하고,
    - 이 값을 데이터에 적용할 땐, mappings 프로퍼티로 대상 필드에 넣어주면 됨
- 도큐먼트 토큰은 _termvectors API로 확인 가능
    - GET 인덱스/_termvectors/[id]?fields=foo,bar

한글 형태소 분석기
- 별도 플러그인을 설치해야 함
- bin/elasticsearch-plugin install analysis-nori
- T: nori_tokenizer 로 분석해보면 다른 결과를 볼 수 있음
- 한국어 사전 기반으로 분석됨

사용자 정의 애널라이저
- 인덱스는 도큐먼트의 모음
- settings 와 mapping 로 구분됨
    - settings: 애널라이저, 샤드개수, 리프레시 기준 등
    - mapping: 필드의 명세, 텍스트라면 어떤 애널라이저를 쓸 것인지 등
- 한 번 만든 인덱스의 설정 대부분은 변경 불가능함
    - 리프레시 타임이나 리플리카 샤드 개수 등은 수정할 수 있으나, 대부분 변경 불가
- 토큰 필터: https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-tokenfilters.html

집계
- 검색이 아니라 집계
- metrics 와 bucket이 있음
    - metrics: min, max, sum, avg 등의 계산
    - bucket: 특정 기준으로 도큐먼트들을 그룹화

메트릭스 집계
- 검색할 땐 query 대신 "aggs" 속성을 줌
- "size": 0 을 주지 않으면, hits 결과가 함께 나오니 집계만 할 거면 적용하는 게 좋음
- 집계를 query 와 같이 하면, 결과의 합계만 집계함

버킷 집계
- 날짜별 히스토그램 (date_histogram)
- 예: date_histogram으로 date 필드를 1개월 간격으로 구분하는 bucket aggregation
- 기본적으로 문서 개수를 리턴(doc_count)
- keyword 타입 = 분석하지 않고 통으로 저장함
- 메트릭스 집계를 같이 사용할 수 있음

위치 정보
- geo_point : { "lat": 41.12, "lon": -71.34 } 같은 형식으로 입력
- geo_bounding_box : 두 점을 기준으로 하는 네모 안에 있는 도큐먼트들을 가져옴
- geo_distance : 한 점을 기준으로 반경 안에 있는 도큐먼트들을 가져옴

노드: 엘라스틱서치 인스턴스
- https://esbook.kimjmin.net/03-cluster/3.3-master-and-data-nodes
- 노드에 여러 인덱스를 생성할 수 있음
- 한 노드는 9200번 포트로 클라이언트와 통신, 9300번 포트로 다른 노드와 통신
- 여러 노드를 하나의 클러스터로 묶을 수 있음
    - 클러스터 > 노드 > 샤드
- 노드 하나는 동시에 여러 역할을 할 수 있음
    - master: 마스터 후보
    - data: 데이터 저장
    - ingest: 데이터 색인 전처리 작업 수행
    - ml: 머신러닝 작업 수행
    - 아무 것도 설정 안하면 클라이언트와 통신만 하는 역할
- 마스터 노드와 데이터 노드를 분리하면,
    - 마스터 노드는 클러스터 관리만 하면 되고, 데이터노드는 데이터 처리에 집중할 수 있어 효율적임
    - 마스터 전용 노드를 Dedicated master node 라고 함
- Split Brain 이슈
    - 마스터 노드가 1개면 마스터 노드가 유실되었을 때 클러스터 전체가 작동하지 않을 위험이 있음
    - 짝수 개라면 네트워크가 끊겼을 때 정합성 이슈가 생길 수 있음
    - 마스터 노드는 3개 이상의 홀수 개를 놓은 것을 권장, 마스터 후보 노드가 최소 2개 이상 존재하도록 하는 것이 좋음

샤드
- 샤드: 인덱스는 기본적으로 샤드(shard)라는 단위로 분리되고, 각 노드에 분산되어 저장됨
    - 클러스터에 노드를 추가하면, 샤드들이 각 노드들로 분산됨
    - 기본적으로 1개의 복제본을 생성함
    - 처음 생성된 샤드를 프라이머리 샤드(Primary Shard), 복제본은 리플리카(Replica)라고 함

    - 최소 3개의 노드로 구성할 것을 권장함
    - 샤드는 반드시 서로 다른 노드에 저장되며, 노드가 유실되면 남아있던 샤드가 프라이머리로 승격되고 다른 노드로 복제본을 생성함
        - https://esbook.kimjmin.net/03-cluster/3.2-index-and-shards
- 샤드는 인덱스 단위로 생성할 수 있고, 샤드의 개수는 인덱스를 처음 생성할 때 지정할 수 있음
    - 프라이머리 샤드의 개수는 인덱스 재색인 전에는 변경할 수 없음
    - number_of_shards: 프라이머리 샤드 개수
    - number_of_replicas: 리플리카 개수
    - 예: 프라이머리 5개, 리플리카 1개 = 5 * (1 + 1) = 총 10개의 샤드
- 유실되지 않으려면, 노드 개수 * 2 * 2 정도의 샤드는 있어야 할 듯?

인덱스 설정
- 인덱스는 두 개의 정보를 가지고 있음. settings & mappings
- https://esbook.kimjmin.net/07-settings-and-mappings/7.1-settings
- settings
    - 프라이머리 샤드 수는 인덱스를 생성할 때 한 번 설정하면 바꾸기 어려움
    - 7.x부터 기본 샤드 수는 1개, 6버전 이하는 5개였다고 함
- mappings
    - properties
        - 생략하면 값을 보고 직접 설정함
        - 매핑 필드를 한 번 설정하면 변경할 수 없음 (인덱스를 새로 만들어야 함)
        - type
    - 타입
        - 문자열
            - text
                - https://esbook.kimjmin.net/07-settings-and-mappings/7.2-mappings/7.2.1
                - 문자열 역인덱스를 생성함
                - analizer, search_analizer를 설정할 수 있음
            - keyword:
                - 입력된 문자열을 하나의 토큰으로 저장
                - 집계나 정렬할 때 사용하는 경우 자주 사용함
                - normalizer 적용이 가능 (노멀라이저는 캐릭터 필터와 토큰 필터만 적용 가능)
        - 숫자
            - long, integer, short, byte, double, float, hal_float, scaled_float
            - coerce 옵션이 있음. 자동으로 형변환 됨
            - ignore_malformed 를 true 로 설정하면, 값이 오류가 있어도 저장함. 소스에는 저장이 되나 검색 대상에서는 제외됨 (기본값 false)
        - date
            - ISO8601 포맷면 됨
            - format 으로 별도 포맷을 설정할 수 있음
                - epoch_mills, epoch_second 도 사용 가능
                - 예: "format": "yyyy-MM-dd HH:mm:ss||yyyy/MM/dd||epoch_millis"
        - boolean
            - true 또는 문자열 "true"
        - object
            - 객체 형태로 넣을 수 있음
            - 다만, 검색할 때 query 내에 "nested" 쿼리를 사용해야 함
        - geo
            - 위도(latitude)와 경도(logitude)를 넣음
            - https://esbook.kimjmin.net/07-settings-and-mappings/7.2-mappings/7.2.6-geo
            - geo_point와 geo_shape 형식으로 저장 및 검색 가능
                - geo_shape: point, multipoint, linestring, mutilinearstring, polygon, mutlipolygon, envelope (직사각형 영역)
                - 폴리곤과 멀티폴리곤의 한 폴리곤의 시작점과 끝점은 동일해야 함
            - 포인트 쿼리
                - geo_bounding_box: 박스 내 좌표 검색
                - geo_distance: 특정 포인트부터 원형으로 영역 내 좌표 검색
            - geo_shape  쿼리
                - relation 으로 검색
                    - intersects: 기본값^ 일부만 겹치면 됨
                    - disjoint: 겹치지 않는 도큐먼트
                    - within: 완전이 포함되어 있는 도큐먼트
            - 이 외에 geo_polygon으로 검색할 수도 있음
    - 참고로, 전처리된 데이터가 아니면 항상 _source 의 값은 변경되지 않음

참고:
- 시작하기 영상: https://www.elastic.co/kr/webinars/getting-started-elasticsearch
- 가이드북: https://esbook.kimjmin.net/01-overview/1.1-elastic-stack

파일을 바이너리로 보기

ohgyun — Wed, 3 Feb 2021 23:10:44 +0900

발생일: 2020.12.23

키워드: byte, binary, 바이너리, 바이트, hex, hexdump, xdd, od

문제:

머신러닝 예제를 돌려보고 있는데, 1바이트에 1개의 레이블이 있고 10개씩 묶으로 가져와 처리하는 예제였다.

파일을 특정 바이트 단위로 묶어서 바이너리 형태로 보고 싶은데 어떻게 하면 될까?

해결책:

xxd 툴로 바이너리로 읽어볼 수 있다.

기억을 더듬느라 좀 헷갈렸는데,

1byte

= 8bit

= 0~255 까지 256을 표현

= 2진수(binary)로 8자리 (00000000 ~ 11111111)

= 2진수는 4자리 씩 끊어 보여주면 16진수 (0000 0000 ~ 1111 1111)

= 16진수(hexadecimal)로 2자리 (00 ~ ff)

xxd 나 hexdump 명령으로 바이너리 파일을 hex 로 볼 수 있음

xxd 는 출력 그룹을 지정할 수 있고, 컬럼 개수도 보여줄 수 있어 편하다

아래 명령은 1byte 씩 구분해서 보여주고(-g 1), 한 컬러에 10개(-c 10) 즉 10 바이트씩 보여주겠단 얘기

AI For Everyone 노트

ohgyun — Wed, 3 Feb 2021 22:39:04 +0900

발생일: 2020.12.07

키워드: Coursera, Andrew Ng, Deep Learning, AI

문제:

코세라의 AI For Everyone 강의를 보고 정리한 노트 (강의 링크)

해결책:

- AI > 머신러닝 > 딥러닝 = Neural Network
- 딥러닝은 뉴런에서 영감을 받았지만, 사람의 뇌의 동작 방식은 알 수 없음

- 머신러닝의 대부분은 지도 학습(Supervised Learning)
- Input A 로 B를 매핑하는 것 (A to B mapping)
- 사람이 1초 안에 판단할 수 있는 것이라면 지도 학습으로 구현 가능

- AI 팀과 DS 팀은 다름
    - AI 팀은 머신러닝을 활용한 자동화에 중점
    - DS 팀은 데이터를 분석해서 인사이트를 얻는 것에 중점 (의사 결정, 프리젠테이션 등)
    - 머그컵 판매 사업이라면,
        - DS팀: 데이터를 분석해서 어떤 지역에서 판매가 잘 되는지 분석하고 전략에 도움
        - AI팀: 머그컵 사진을 보고 불량품 파악 자동화

- 직업을 대체하는 것보다는 작업을 대체하는 것이 효율적임

- 비지니스 가치를 올릴 수 있는 곳에 AI를 적용하면 더 가치 있음
- 즉, 먼저 비즈니스에서 중요한 걸 파악하란 뜻

- 수용가능한 기준을 세워야 함
- 예: 성능 기준 95%

- 기술을 사는 게 나을까? 팀을 꾸리는 게 나을까?
    - 일반적인 산업에서 필요한 기술(산업 표준)이라면 사는 게 나음
    - 기차 앞에서 뛰지 마라: 산업 표준의 발전 속도가 더 빠르므로
    - 우리 사업에 특화된 것이라면 팀을 꾸리는 게 나음

- AI는 구조적으로 100% 정확도를 달성하기 어렵다
- 비즈니스에서 의미있는 정확도를 설정해도 큰 도움이 됨

- 스마트 스피커 구현 예
    - "헤이 구글, 10시에 알람 맞춰줘"
        1. 호출 단어 인식: 오디오에서 '헤이 구글'이 있는지 없는지
        2. 음성 인식: '10시에 알람 맞춰줘'를 텍스트로 변환
        3. 의도 인식: 알람, 10시
        4. 명령 실행
    - 명령 만큼의 의도 인식 분류가 필요함
    - 대부분 supervised learning

- 자율 주행 구현 예
    - 역시 supervised learning
    - 예:
        1. 이미지/라이다/레이더 + GPS/MAP
        2. 자동차 인식, 보행자 인식 (이후 방향 예측), 경로 인식, 신호등 인식, 장애물 인식 등...
        3. 모션 플래닝 (가속, 핸들 등)

- Edge Deployment
    - 유저 디바이스에 직접 배포하는 것
    - 네트워크 비용 없이 빨리 응답
    - 예: 자율주행 차량에 탑재, 스마트 스피커에 탑재

- AI 논문 사이트: Arxiv

- 규모가 있는 AI 팀의 구성
    - Software Engineer
    - Machine Learning Engineer
    - Machine Learning Resercher
    - Data Scientist: 데이터로 의사 결정에 도움
    - Data Engineer: 데이터 구성, 접근 관리 등
    - AI Product Manager: 어떻게 빌드할 건지, 구현 가능한지, 가치가 있는지 결정

- AI Transformation Playbook: 훌륭한 AI 회사를 만드는 법
    1. 추친력을 얻기 위해 파일럿 프로젝트 진행
        - 가치보단 성공 가능성에 집중해서 시작
        - 일단 성공을 해서 한 팀에서 지지를 얻는 것이 중요
        - 구글 브레인에서는 음성 인식 팀에 처음으로 딥러닝을 적용함(음성인식은 광고나 검색만큼 가치가 있진 않음)
        - 여기서 성공한 후, 구글 맵 팀 등으로 연결됨. 이후에 온라인 광고까지 적용
        - 파일럿 프로젝트는 단기(6-12개월)에 결과를 보여줘야 함
        - 자체 팀도 좋지만, 처음엔 결과를 빨리 얻고 전문가의 경험을 얻을 수 있으니 외주여도 괜찮음
    2. 자체 AI 팀 구성
        - AI를 company-wide platform 으로 구축할 수 있게 CEO 직속(내지는 비즈니스 유닛과 평행하게) 구성하는 것이 좋음
        - CEO, CTO, CIO 직속일 수도 있고, CAIO 직속일 수도 있음
        - 비즈니스 펀딩을 위해 AI팀을 조직하는 것 아니라, AI 조직을 위해 펀딩을 받은 경우 더 성과가 좋았음
    3. AI 이해를 위한 학습 전파 (Provide broad AI training)
        - 임원 레벨은 4시간 이상, 리더는 12시간 이상 AI에 대해 학습하도록 하는 게 좋음
        - AI 개발자를 채용하는 대신 내부에서 기르는 것도 좋은 방법 (100시간 학습)
        - The smart CLO knows they should curate rather than create (CLO = learning)
    4. AI 전략 수립 (Develop an AI strategy)
        - 전략을 세우는 것이 첫 번째가 아닌 이유는, 먼저 AI를 우리 회사의 비즈니스에 적합하게 적용하는 것을 이해해야 하기 때문
        - AI 선순환 구조를 만드는 것이 중요 (좋은 제품 > 많은 사용자 > 많은 데이터 > 좋은 제품)
        - 검색 같은 것은 기존 업체와 경쟁하기 어렵지만, 스타트업이 새로운 분야에 진입할 때 큰 장점이 됨
            - 양배추와 잡초를 구분하는 트랙터 사업 예
            - 이렇게 하면 defensible company 를 만들 수 있음 (신규 사업자가 진입하기 어려운 구글 같은 회사)
        - AI는 대부분 해당 사업군에 특화된 경우가 많기 때문에, 대형 기술 회사의 AI 기술과 견주어서 지레 겁먹을 필요가 없음
        - 데이터 수집 전략를 세우는 것을 고려
            - 데이터 수집 전략: 무료 에메일, 사진 서비스가 무료로 (광고도 없이) 서비스를 제공하는 이유
            - 통합된 데이터 웨어하우스
        - 네트워크 효과와 플랫폼의 장점을 고려
            - 승자독식 구조의 산업에서는 AI가 큰 도움이 될 수 있음
    5. 커뮤니케이션 (Develop an internal and external communications)
        - AI는 회사와 제품에 변화를 줄 수 있음
        - 투자자: AI 회사로서의 가치를 적합하게 평가할 수 있게
        - 정부: 공익에 도움이 됨 (규제가 많았던 헬스케어, 자율주행 분야...)
        - 소비자/사용자에게 교육해서 인식을 바꿔주는 것도 중요
        - AI 성공 사례는 드물어서, 커뮤니케이션하면 채용에 도움이 됨
        - 내부 커뮤니케이션도 중요: 직원들이 걱정하는 경우도 있어서 안심을 주는 것이 도움이 됨

- AI 팀을 만들려고 할 때 일반적인 위험 (Don't / Do)
    - Don't: AI로 모든 걸 해결하려는 것
        - AI의 한계를 인정하고~
    - Don't: 머신러닝 개발자를 단독으로 2-3명 고용하는 것
        - 비즈니스 전문가와 개발자 한 명의 쌍이 더 나음 (구현 가능 여부와 비즈니스 가치를 모두 고려할 수 있음)
    - Don't: 첫 번째 시도로 AI 프로젝트가 동작할 거라고 기대
        - 한 번에 되는 경우는 잘 없음. 반복된 시도로 성공할 수 있음
    - Don't: 전통적인 방법으로 계획
        - 타임라인과 마일스톤, KPI를 세울 때 AI 팀과 함께 논의
    - Don't: 시작 전 AI 슈퍼스타가 필요할 지 고려
        - 팀을 만들어서 시도해보는 게 좋음

- AI 팀 시작하기
    - 스터디할 팀을 구성하고
    - 브레인스토밍 프로젝트를 시작 (No project is too small)
    - 도움이 필요하다면 ML/DS 엔지니어를 고용
    - AI Leader (VP AI, CAIO, ...)를 고용하거나 임명. 최근엔 CAIO 라는 직급이 많이 생겼다고 함
    - CEO와 AI 전환에 대해 논의 (Key Question: AI를 적용하면 회사의 가치가 높아지거나 효율적이 될까?)

- AI의 한계
    - 성능 이슈 (많은 데이터가 필요함)
    - 과정을 설명하기 어려움
        - 가능한 경우도 있으나 대체로 판단한 과정을 설명하기 어려움
        - 판단의 과정을 표현하는 것도 주요 연구 대상 중의 하나로 진행 중임
        - 사람도 잘 설명하지 못함. (머그컵이 왜 머그컵인지 설명하는 것이 쉽지 않은 것처럼)
    - 편향: 편향된 정보(인종 등)로 학습된 AI
    - AI 시스템에 대한 공격: 일부러 공격하는 경우가 있음

- 편향이 중요한 이유
    - 고용 도구에서 여성이 차별됨
    - 얼굴 인식 도구는 흑인보다 백인을 더 잘 구별함
    - 은행 대출 승인
    - 고정관념에 의한 중독 효과가 발생함 (예: 검색 결과에서 CEO 결과는 항상 백인 남성)

- 편향을 피하는 방법
    - 기술적인 방법
        - 잘 사용되지 않는 단어는 0으로 처리 (이런 단어에서 주로 편향이 발생했음)
        - 데이터가 편향되지 않게 (예: 성별/인종별로 비슷한 비중의 데이터를 사용)
    - 검증 과정을 투명하게. 편향을 이 단계에서 제거할 수 있게
    - 다양한 인종과 성별을 가진 직원으로 팀을 구성

- AI 시스템에 대한 공격
    - 이미지 인식을 방해하는 방법
        - 예: 토끼 이미지 픽셀을 몇 개 변경하면, 책상으로 분류됨
        - 예: 바나나 이미지에 특정 스티커를 보여주면 토스터로 변경됨
    - 사기 감지, 스팸 필터 같은 시스템에서는 특히 중요함

----

Supervised Learning 구현 기술 예

Computer Vision
- Image Classification/Object Recognition
    - 이미지가 고양이 사진인지
    - Face recognition, 사람 사진인지, 같은 사람의 사진인지 등
- Object Detection
    - 사진에서 차량이나 보행자가 어디에 있는지(영역)
- Image Segmentation
    - 차량과 보행자의 픽셀 단위까지 파악
    - X-ray 사진에서 각 부위 파악
- Tracking
    - 마라톤 비디오에서 사용자의 이동 위치 파악
    - 동영상에서 새의 위치를 파악

Natural Language Processing
- Text classification
    - 이메일 카테고리 분류 (스팸 or 정상)
    - 제품 설명으로 카테고리 분류 (당근마켓 글 등)
    - 감정(Sentiment) 분류 (레스토랑 리뷰를 별점으로 환산)
        - Food was good -> 별점 4점
        - Service was horrible -> 별점 1점
- Information retrieval (정보 반환)
    - 검색 결과에 연관 문서 반환
- Name entity recognition (이름 인식)
    - 문장에서 인물의 이름을 파악
    - 회사 이름, 전화 번호, 지명 등등
- Machine translation
    - 번역
- 자연어 처리의 다른 부분
    - part-of-speech tagging (품사 태깅)
    - parsing
        - 파싱 예: 구문을 의미 단위로 연결
        - [the cat] [on the mat]

Speech
- Speech recognition (speech-to-text)
    - 시간에 따른 음파 분석
    - 최근의 음성 인식 발전은 대부분 딥러닝 덕분
- Trigger word/wakeword detection
    - 헤이 구글
- Speaker ID
    - 화자가 누군지 분석
- Speech synthesis (text-to-speech, TTS)
    - The quick brown fox jumps over the lazy dogs.
        - 알파벳 26자가 다 있는 문장ㅎㅎ

Robotics
- Perception
    - 주변 물체를 인지 (자율 주행차)
- Motion planning
    - 이동할 경로를 찾음
- Control

General machine learning
- Unstructured data (Image, Video, Audio, ...)
- Structured data

---

Supervised Learning 외 구현 기술 예

Unsupervised learning
- Clustering
    - 식료품점에서 감자를 사는 사용자군을 클러스터링
        - 예: 낮은 가격의 칩을 많이 사는 사람들, 비싼 가격의 칩을 적게 사는 사람들
    - 구글 팀에서는 유튜브 데이터로 비지도 학습을 시켰더니, 고양이 동영상이 많다는 결과를 냈다고 함
- 지도 학습의 단점은 데이터 라벨링
    - 머그컵을 학습시키려고 아이들한테 머그컵 1,000개를 학습시키지 않으니까...
    - 사람의 뇌가 동작하는 방식은 아직 알지 못하지만, 비지도 학습이 도움이 될 수도 있을 듯
    - 현재는 지도 학습에 비해 경제적인 가치가 낮은 편

Transfer learning
- 이미 학습한 모델로 다른 분야를 학습
- 대규모 데이터로 학습한 자동차 인식 모델로 소규모 데이터가 있는 골프카트 인식 모델 학습
- 컴퓨터 비전 쪽에서 특히 많이 사용함

Reinforcement learning
- 행동에 보상을 주는 방식으로 학습
- 아주 많은 데이터가 필요함
- 미디어의 주목을 많이 받긴 했지만, 경제적 가치는 지도학습에 비해 미미함

GANs (Generative Adversarial Network)
- 이미지를 생성하는데 효과적임
- 예: 연예인 이미지를 학습해, 연예인처럼 생긴 이미지를 생성

Knowledge Graph
- 구글 검색 우측에 나오는 인물 정보 (자동으로 생성되는 거였다니..)
- 데이터로 인물 정보를 생성함
    - 출생, 사망, 이력 등
- 영화, 연예인, 호텔, 공항 등의 정보 생성에 사용되고 있음
- 경제적 가치가 높은데 의외로 많이 연구되지 않고 있음

스케치의 컬러와 크롬의 컬러가 다른 이슈

ohgyun — Fri, 17 Apr 2020 11:45:58 +0900

발생일: 2020.04.09

키워드: 스케치, sketch, 컬러 스페이스

문제:

디자이너가 스케치에서 작업해준 컬러를 크롬에 적용했는데, 컬러 코드가 동일한데도 색상이 눈에 띄게 다르다.

왜 그런 걸까?

해결책:

프로그램마다 사용하는 컬러 스페이스가 다르기 때문이었다.
(좀 찾아보니 컬러 스페이스는 색 공간, 색 영역, 컬러 프로필, 컬러 프로파일, 디스플레이 프로필 같은 용어로 쓰인다. 여기선 통일해서 컬러 스페이스라고 표기했다)

크롬을 포한한 브라우저의 컬러 스페이스는 일반적으로 sRGB 이고,
스케치는 기본적으로 모니터의 컬러 스페이스를 사용한다.

우린 iMac을 사용하고 있는데, 디스플레이 속성 메뉴에 가보면 어떤 컬러 스페이스가 적용되어 있는지 알 수 있다.

디자이는 기본적으로 iMac 컬러 스페이스를 사용하고 있었고,
스케치에서 컬러를 헥스 코드로 추출할 때에도 해당 컬러 스페이스를 따르기 때문에 크롬에서 다르게 보였던 것이었다.

스케치도 포토샵처럼 개별 컬러 스페이스를 적용할 수 있고,
File > Change Color Profile 메뉴에서 컬러 스페이스를 변경할 수 있다.

참고로, 맥에 Digital Color Meter 라는 기본 앱을 사용하면,
모니터에 표시된 컬러를 여러 컬러 스페이스의 코드로 확인할 수 있다.

동일한 컬러지만, 컬러 스페이스에 따라 코드가 다르다.

우리는 스케치의 컬러 스페이스를 크롬과 맞춰서 sRGB로 변경하는 걸로 해결했다.

참고:
* https://www.reddit.com/r/sketchapp/comments/71ntgh/sketch_giving_me_the_wrong_color_hex_codes_looks/
* https://carrotdesign.tistory.com/35

Array.sort() 정렬 기준은 문자열의 유니코드 포인트

ohgyun — Fri, 31 May 2019 16:52:20 +0900

발생일: 2019.05.31

키워드: Array.sort, sort, 정렬

문제:

아래와 같이 sort() 함수로 정렬했는데,

[1, 5, 10, 20].sort();

결과가 아래와 같이 기대했던 것처럼 나오지 않는다.

[1, 10, 20, 5]

으잉?

해결책:

나만 몰랐나...

Array.sort() 의 기본 정렬 기준은 문자열의 유니코드 포인트였다.

숫자로 정렬하려면 아래와 같이 compareFunction 을 넘겨주면 된다.

[1, 5, 10, 20].sort((a, b) => a - b);

기존에 비슷한 코드도 확인해봐야겠다...

논의:

우린 유틸리티 모듈로 언더스코어(underscore.js)를 쓰고 있는데, 언더스코어의 _.sortBy 는 의도대로 숫자로 정렬된다.

코드를 확인해보니, 기본 compareFunction 에서 각 값을 비교하는 과정에서 암묵적으로 형변환되었기 때문이다.

  _.sortBy = function(obj, iteratee, context) {
    var index = 0;
    iteratee = cb(iteratee, context);
    return _.pluck(_.map(obj, function(value, key, list) {
      return {
        value: value,
        index: index++,
        criteria: iteratee(value, key, list)
      };
    }).sort(function(left, right) {
      var a = left.criteria;
      var b = right.criteria;
      if (a !== b) {
        if (a > b || a === void 0) return 1;
        if (a < b || b === void 0) return -1;
      }
      return left.index - right.index;
    }), 'value');
  };

우리 코드는 _.sortBy()를 쓰는 것으로 처리했다.

참고:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort

MySQL: 테이블 이름 변경에 view 활용하기

ohgyun — Mon, 20 May 2019 17:33:27 +0900

발생일: 2019.04.22

키워드: mysql, view, 뷰

문제:

기존 변수를 모두 변경하면서 관련된 테이블의 이름도 함께 변경하려고 한다.

테이블 앨리어스가 있다면 가장 쉽게 운영 중인 서비스에도 문제 없이 적용할 수 있을 것 같다.

가만, view 가 업데이트도 가능했던가?

해결책:

단일 테이블로 생성한 뷰는 업데이트나 인서트도 가능하다.

- view 조건에 해당되지 않는 경우에도 업데이트나 인서트가 가능하다.

CREATE VIEW emp_view AS

SELECT * FROM emp WHERE age > 10

INSERT INTO emp_view (iage) VALUES (5);

- 뷰 생성 시 컬럼 앨리어스를 사용한 경우에도 인서트나 업데이트 된다.

CREATE VIEW emp_view AS

SELECT id, age AS age2 FROM emp

- 1:1 매핑이 되지 않는 경우엔 업데이트 가능하지 않다.

CREATE VIEW emp_view AS

SELECT id, age, age AS age2 FROM emp

CREATE VIEW emp_view AS

SELECT id, age, 10 AS age2 FROM emp

참고로,

- 뷰의 정의는 생성 시점에 정해진다. 뷰가 생성된 이후에 테이블의 컬럼이 추가된 경우, 뷰에 적용되진 않는다.

- 뷰를 생성한 후에 테이블을 삭제해도, 뷰는 삭제되지 않는다. 참조만 없음

논의:

# 운영 중인 foo 테이블의 이름을 bar 로 변경

스킴을 변경해도 운영 중인 테이블이나 변경 타이밍이 다른 코드 등에서 동일하게 사용할 수 있어야 하니,

기존 테이블의 이름을 변경하고 바로 기존 이름의 뷰를 생성해두는 게 안전하다.

(rename 하는 동안, 테이블을 찾지 못해 오류가 발생할 수 있음)

RENAME TABLE foo TO bar;

CREATE VIEW foo AS SELECT * FROM bar;

# 변경할 테이블의 컬럼명을 바꾸려고 하는 경우

foo_id 컬럼이 있는 foo_sub 테이블을,

bar_id 컬럼을 갖는 bar_sub 테이블로 변경하려는 경우임.

RENAME TABLE foo_sub TO bar_sub;

ALTER TABLE bar_sub CHANGE foo_id bar_id INT(10) unsigned;

CREATE VIEW foo AS

SELECT id, bar_id AS foo_id, ...

FROM bar;

LetsEncrypt 로 개발용 인증서 만들기

ohgyun — Mon, 20 May 2019 17:23:15 +0900

발생일: 2019.05.13

키워드: 인증서, https, ssl, letsencrypt, cordova, phonegap, 코르도바, 폰갭, certbot, 자가 서명 인증서, self-signed certificate

문제:

로컬 환경에서 https 를 구성하기 위해 자가 서명 인증서를 만들어 적용했다. (자가 서명 인증서는 https://ohgyun.com/429 참고)

브라우저에서는 잘 테스트했는데, 시뮬레이터에서는 동작하지 않는다.

왜 그럴까?

해결책:

우리 서비스는 코르도바 기반의 하이브리드 앱으로 구현되어 있다.

코르도바 보안 가이드에 따르면, 자체 서명된 인증서는 보안에 취약하기 때문에 기본적으로는 허용하지 않는다고 한다.

디버깅 옵션을 주면 된다고 하는데, 실제 환경과 비슷하게 테스트할 수 있게 신뢰할 수 있는 인증 기간의 인증서를 사용하는 쪽으로 해결했다.

LetsEncrypt 에서 무료로 인증서를 제공하며, OS에 따라 certbot 모듈을 이용해 생성하면 된다.

certbot으로 각 서버에 자동으로 인증서 설정을 할 수 있지만, 우린 기존 환경을 미리 구성해둬서 인증서만 생성하면 되는 상황이었다.

아래 명령으로 수동으로 인증서를 생성했다. -d 옵션에 할당한 dev.example.com을 본인의 도메인에 맞게 넣어주면 된다.

$ sudo certbot -d dev.example.com --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns certonly

위 명령어를 실행하면, 아래와 같이 DNS TXT를 설정하라고 한다.

Please deploy a DNS TXT record under the name

_acme-challenge.dev.example.com with the following value:

m61ycxBWXXKIt8ws2LJEelAYSt5wITUCyHxzHw9Slys

해당 도메인의 소유 여부를 확인하려는 목적이다.

도메인 제공 서비스에서 _acme-challenge.dev.example.com 의 레코드 셋을 만들고, 타입을 TXT로 Value 에 출력된 값을 넣어주면 된다.

우리는 AWS의 Route53을 사용하고 있어서, 아래와 같이 추가해줬다.

다음 단계로 진행하면, OS 환경에 따라 특정 경로에 인증서가 생성된다.

인증서는 3개월마다 갱신해줘야 한다.

`sudo certbot renew` 커맨드로 실행하면 되고, 젠킨스에 배치로 걸어둘 예정이다.

논의:

# API 호출 제한

테스트로 계속 호출했더니, API 호출 제한에 걸렸다.

테스트 목적으로는 --dry-run 플래그로 API 스테이징 서버를 호출하면 된다.

$ sudo certbot -d dev.example.com --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns certonly --dry-run

# AWS Linux에서의 설치

AWS Linux 에서 certbot이 yum 으로 설치되지 않는다.

가이드가 있어서 따라해봤는데, 여전히 안된다.

certbot-auto 파일을 별도로 받아 설정하는 방식으로 해결했다.

https://certbot.eff.org/lets-encrypt/pip-other

$ sudo /usr/local/bin/certbot-auto -d dev.example.com --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns certonly

# 관련 모듈을 찾을 수 없다는 오류

아래와 같이 관련 파이썬 모듈을 찾을 수 없다고 나오는 경우:

[ec2-user@admin ~]$ /usr/local/bin/certbot-auto renew
Requesting to rerun /usr/local/bin/certbot-auto with root privileges...
Error: couldn't get currently installed version for /opt/eff.org/certbot/venv/bin/letsencrypt:
  Traceback (most recent call last):
    File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 7, in
        from certbot.main import main
  ... 중략
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 8, in
      from OpenSSL import crypto, SSL
  ... 중략
  ImportError: No module named cryptography

sitecustomize.py 파일을 생성한 후에, 아래와 같이 패스를 추가해주면 된다.

$ sudo vi /opt/eff.org/certbot/venv/lib64/python2.7/site-packages/sitecustomize.py

import site

site.addsitedir('/opt/eff.org/certbot/venv/lib64/python2.7/dist-packages')

# TXT record 가 제대로 업데이트 되었는지 확인하고 싶을 땐, txt type으로 nslookup 하면 된다,

$ nslookup -type=txt _acme-challenge.dev.example.com

참고:

Certbot:

https://certbot.eff.org/

Guide: Using Let's Encrypt SSL Certificates for a local or network server

https://r.je/ adguide-lets-encrypt-certificate-for-local-development#vjecerts

LetsEncrypt Staging Environment

https://letsencrypt.org/docs/staging-environment/

Amazon Linux AMI 에서 letencrypt certbot 으로 SSL 인증서 발급 에러

https://www.lesstif.com/pages/viewpage.action?pageId=54952117

Error: pg_config executable not found

ohgyun — Sat, 13 Apr 2019 21:55:35 +0900

발생일: 2019.04.05

키워드: psycopg2, pg_config

문제:

얼마 전, 파이썬 배치 작업들이 모두 실패했다.

오류 문구는 아래와 같다.

Collecting psycopg2
  Using cached https://files.pythonhosted.org/packages/c7/ca/75236b17f1b951950ffc55d657c5aa408d3d0327a1b6c4c0f7cb16ef7e7b/psycopg2-2.8.tar.gz
    Complete output from command python setup.py egg_info:
    running egg_info
    creating pip-egg-info/psycopg2.egg-info
    writing pip-egg-info/psycopg2.egg-info/PKG-INFO
    writing dependency_links to pip-egg-info/psycopg2.egg-info/dependency_links.txt
    writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
    writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'

    Error: pg_config executable not found.

    pg_config is required to build psycopg2 from source.  Please add the directory
    containing pg_config to the $PATH or specify the full executable path with the
    option:

        python setup.py build_ext --pg-config /path/to/pg_config build ...

    or with the pg_config option in 'setup.cfg'.

    If you prefer to avoid building psycopg2 from source, please install the PyPI
    'psycopg2-binary' package instead.

    For further information please check the 'doc/src/install.rst' file (also at
    <http://initd.org/psycopg/docs/install.html>).

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/7m/gd92t9wx0nl_t8yw70ymhl0c0000gn/T/pip-install-t4927zna/psycopg2/

왜 그럴까?

해결책:

psycopg2 관련 모듈이 업데이트 되면서 postgresql 바이너리를 찾지 못하는 문제인 것 같다.

postgresql 관련 모듈을 다시 설치하는 것으로 해결했다.

맥에서는,

$ brew install postgresql

CentOS에서는,

$ sudo yum install postgresql postgresql-devel python-devel

참고:

https://stackoverflow.com/questions/11618898/pg-config-executable-not-found

nginx: 허용하지 않은 도메인에서 접속이 되는 경우

ohgyun — Sat, 13 Apr 2019 21:45:35 +0900

발생일: 2017.12.06

키워드: nginx, default_server, 기본 server

문제:

엥?? 도메인이 다른 전혀 관련 없는 웹페이지가 우리 서비스를 프록시로 걸어 제공하고 있었다.

어처구니가 없는 행동이지만, 그 전에 왜 nginx는 도메인이 다른 접근에 응답하고 있었던 걸까?

nginx 설정의 서버 블럭에는 아래와 같이 server_name 이 명시되어 있었다.

server {

server_name ohgyun.com;

...

}

해결책:

nginx의 "첫 번째" 서버 블럭은 server_name 이 매칭되지 않았을 때 동작하는 기본 서버 블럭이다.

서버 블럭을 하나만 정의했었기 때문에, 도메인이 매칭되지 않았을 때에도 동일하게 첫 번째 블럭이 실행된 것이 문제였다.

아래와 같이 기본 서버 블럭을 정의하고, 404를 리턴하게 한 것으로 해결했다.

# Default server

server {

return 404;

}

server {

server_name ohgyun.com;

...

}

논의:

응답으로 444를 리턴하면, 404보다는 네트워크 데이터를 좀 더 절약할 수 있다고 한다.

우린 AWS ELB를 쓰고 있었는데, 444로 리턴했더니 502 Bad Gateway로 응답한다.

확인해보니, 444는 nginx 확장 코드라 아직 ELB에서 지원하지 않는다고 한다.

404로 리턴하도록 했다.

참고:

https://stackoverflow.com/a/43128186/954292

nginx: 로그 때문에 서버 용량이 찼을 때 처리 방법

ohgyun — Tue, 26 Mar 2019 11:48:52 +0900

발생일: 2017.07.31

키워드: nginx, 용량, 로그 용량, copytruncate, logrotate, 로그 로테이트

문제:

서버 용량이 가득 차서 리스타트에 실패하는 문제가 발생했다.

nginx 로그 때문으로 추측되는데, 실제로 로그 디렉토리 내의 로그 파일의 용량은 문제가 될 만큼 크지 않다.

뭐가 문제일까?

해결책:

nginx 로그는 로테이트해 S3로 업로드한 후에 삭제한다.

확인해보니, 원인은 로그가 제대로 로테이트되지 않고 프로세스가 삭제된 기존 파일을 계속 물고 있었기 때문이다.

로그 로테이트 옵션에 copytruncate 을 추가하는 것으로 해결했다.

아래는 작업과 관련된 스크립트:

# 현재 머신의 용량을 확인해본다

df -h

# 어떤 디렉토리에서 가장 많이 차지하는지 확인한다

sudo du -hs * | sort -hr | head -n 10

# nginx 프로세스가 삭제된 파일을 물고 있는지 확인한다 (이게 원인이었음)

lsof / | grep deleted

# nginx 리로드해서 삭제된 물고 있는 파일을 정리한다

sudo /etc/init.d/nginx reload

# nginx 로그로테이트 설정 파일 보기

sudo cat /etc/logrotate.d/nginx

# nginx 로그로테이트 설정 파일에 copytruncate을 추가했다

sudo vi /etc/logrotate.d/nginx

# 디버깅 모드로 로그로테이트 실행하기

sudo logrotate -d /etc/logrotate.d/nginx

# 강제로 로그로테이트 실행하기

sudo logrotate -f /etc/logrotate.d/nginx

논의:

du + sort 로 읽기 편한 사이즈로 표시하면서 정렬하는 방법

https://serverfault.com/questions/62411/how-can-i-sort-du-h-output-by-size

로그 용량이 기가 단위로 큰 경우엔 copytruncate 동작 중 I/O 블로킹으로 인한 타임아웃이 발생할 수 있다고 한다.

https://brunch.co.kr/@alden/27

clasp: 구글 앱스 스크립트 로컬에서 개발하기

ohgyun — Sat, 2 Mar 2019 03:53:48 +0900

발생일: 2019.03.02

키워드: Google Apps Script, 구글 앱스 스크립트, clasp

문제:

구글 앱스 스크립트를 로컬에서 개발하고 싶다.

기존엔 파일이 크지 않아 온라인에서 수정하거나, 수정 사항이 좀 있을 땐 에디터에 복사해서 수정하고 붙여넣곤 했다.

규모가 조금 커지다보니 더 이상 귀찮아서 못하겠다.

뭔가 도구가 있을 테다.

해결책:

유후. 로컬에서 개발하고 배포할 수 있는 clasp 라는 도구가 있다. 진작에 찾아볼 걸.

https://github.com/google/clasp

npm 으로 바로 설치할 수 있다.

$ sudo npm i @google/clasp -g

구글 계정에서 Apps API 권한을 허용해준 다음,

https://script.google.com/home/usersettings

터미널에서 바로 로그인하면 된다.

$ clasp login

난 이미 프로젝트가 있어서, 로컬에 디렉토리를 만들어 클론했다.

$ clasp clone [스크립트 ID]

한 번 클론한 이후에 원격의 수정 사항을 가져오려면 pull만 하면 된다.

$ clasp pull

로컬에서 파일을 수정한 후에, push 하면 된다.

push 후 온라인 스크립트 에디터에서 확인해보려면 새로고침 한 번 해야한다.ㅎㅎ

$ clasp push

수정 사항으로 새 버전을 따거나 바로 배포할 수도 있다.

간단하게 deploy만 하면, 신규 버전이 따지면서 배포도 된다.

$ clasp deploy

와. 정말 편하다.

온라인 스크립트 에디터를 바로 열 수 있기도 하고!

$ clasp open

논의:

버전 관리는 별도로 git 으로 하면 된다.

clone 한 스크립트 아이디는 .clasp.json 파일에 있다.

로컬 파일이 변경될 때마다 자동으로 push 하고 싶다면, -w (--watch) 옵션을 쓰면 된다. 편하다.

$ clasp -w

로컬에서 함수를 실행할 땐, run 명령을 쓰면 된다.

$ clasp run [함수명]

git 과 비슷하게 status 명령이 있지만 의미는 다르다.

이 명령은 서버에 푸시할 때 포함되는 파일의 목록을 출력해준다.

$ clasp status

deploy 한다고 변경 내용이 서버에 push 되는 건 아니니 주의한다.

수정 전에 push -w 을 걸어두는 게 편하겠다.

또한, deploy 한다고 웹앱이 신규로 퍼블리싱 되는 것도 아니다.

기대한 대로라면 잘 되어야 할 것 같고, 깃헙 이슈에서 논의도 되었지만 아직 해결되지 않은 듯 싶다.

좀 번거롭긴 한데, deploy 후에 퍼블리싱 과정을 챙겨줘야겠다.

npm 설치 오류: code EBADKEY

ohgyun — Sat, 2 Mar 2019 03:53:16 +0900

발생일: 2019.03.01

키워드: node, npm

문제:

code EBADKEY

invalid config key requested: config

npm install 할 때, 위 문구가 나오면서 설치되지 않는다.

해결책:

검색해서 몇 가지 방법을 시도해봤는데, 잘 되지 않았다.

노드 관련 파일을 모두 제거 후에 다시 설치했다.

- 루트 node_modules 제거

npm 루트 경로는 아래 명령으로 찾으면 된다

$ npm root -g # npm

- node 제거

노드 파일은 아래 명령으로 찾으면 된다

$ type node

- n 으로 노드 신규 설치

$ curl -L https://git.io/n-install | bash

오랜만에 깨끗해졌다~ ㅎㅎ

Node: String 크기 제한에 의한 RangeError

ohgyun — Tue, 30 Oct 2018 14:44:10 +0900

발생일: 2018.10.22

키워드: JSON.stringify, RangeError, Invalid string length, max-old-space-size, 메모리 부족, RangeError

문제:

배치 작업 과정 중에 아래와 같은 오류가 발생하면서 프로세스가 종료됐다.

RangeError: Invalid string length

at JSON.stringify (<anonymous>)

메모리 이슈인 것 같아 노드의 max-old-space-size 파라미터로 힙 사이즈를 필요한 만큼 지정해 실행했는데도 동일하게 발생한다.

왜 그런 걸까?

해결책:

확인해보니, V8은 구조적 문제로 객체의 크기를 1.9기가로 제한하고 있다고 한다.

사이즈가 큰 객체를 stringify 하는 과정에서 문자열의 크기가 지나치게 커진 것이 문제였다.

아래 코드를 실행하면, 위 오류를 재현할 수 있다.

let str = 'a';

for (let i = 0; i < 30; i++) {

str += str;

}

위 예제에서는 단순히 문자열을 더한 것이지만,

JSON.stringify(bigObject);

와 같이 사이즈가 큰 객체를 변경 시 JSON Syntax를 포함한 변환된 문자열의 크기가 허용치를 넘어서면서 발생할 수도 있다.

해결하려면,

- 객체를 작은 사이즈로 나누거나

- 스트림으로 직렬화하는 방법으로 우회할 수 있다.

논의:

# JSON을 스트림으로 처리

JSON을 스트림으로 처리하는 용도로 JSONStream 모듈이 있다.

https://www.npmjs.com/package/JSONStream

아래와 같은 식으로 사용하면 된다.

const parser = JSONStream.stringifyObject();

parser.pipe(fs.createWriteStream('output'));

parser.write(['key1', 'value1']);

parser.write(['key2', 'value2']);

parser.end();

스트림의 종료 이벤트는 좀 헷갈리는데,

Readable 은 end 이벤트를, Writable 은 finish 이벤트를 사용하면 된다.

아래는 읽고 쓰는 샘플 예제이다.

(유틸리티 모듈로 undescore 를, 프라미스 모듈로 Q를 썼다.)

const fs = require('fs');

const JSONStream = require('JSONStream');

const dumpJson = function (obj, outputFile) {

const deferred = Q.defer();

const parser = JSONStream.stringifyObject();

const output = fs.createWriteStream(outputFile);

parser.pipe(output);

_.each(obj, (value, key) => {

parser.write([key, value]);

});

parser.end();

output.on('finish', () => {

deferred.resolve(output);

});

return deferred.promise;

};

const restoreJson = function (inputFile) {

const deferred = Q.defer();

const input = fs.createReadStream(inputFile);

const parser = JSONStream.parse('$*');

const obj = {};

input.pipe(parser);

parser.on('data', (data) => {

obj[data.key] = data.value;

});

parser.on('end', () => {

deferred.resolve(obj);

});

return deferred.promise;

};

const obj = {

foo: '1',

bar: '2',

baz: [1, 2, 3]

};

return dumpJson(obj, 'output.json').then(() => {

return restoreJson('output.json').then((restored) => {

console.log(_.isEqual(obj, restored));

});

위 문제에서처럼 사이즈가 큰 객체를 메모리를 늘리지 않고 처리하거나,

event loop을 방해하지 않으면서 처리하고 싶을 때 사용하면 좋다.

다만, 기본 파싱보다 느린 것이 단점이다. (대략 10배 정도 느림)

우린 서버에서도 사용하고 있는데, 큰 사이즈의 데이터를 캐시에 넣고 뺄 때 다른 요청에 방해되지 않게 하는 용도로 사용하고 있다.

JSON은 사이즈가 커질수록 파싱하는데 시간이 크게 늘어나니, 이런 종류의 데이터를 만들지 않는 것이 가장 좋은 방법일 것 같다.

----

# 메모리가 부족한 경우

이 외에 단순히 메모리가 부족한 경우엔 아래와 같은 오류가 출력된다.

Allocation failed — process out of memory

또는,

FATAL ERROR: JS Allocation failed - process out of memory

또는,

<--- Last few GCs --->

[54774:0x103000000] 95 ms: Mark-sweep 6.2 (15.7) -> 5.6 (15.7) MB, 4.9 / 0.0 ms (average mu = 0.205, current mu = 0.152) allocation failure GC in old space requested

[54774:0x103000000] 100 ms: Mark-sweep 5.6 (15.7) -> 5.6 (16.2) MB, 4.8 / 0.0 ms (average mu = 0.110, current mu = 0.004) allocation failure GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

0: ExitFrame [pc: 0x16c79d5dc01d]

Security context: 0x1bc5a131e681 <JSObject>

이런 경우엔 노드 스크립트를 실행할 때, V8의 옵션인 max-old-space-size 파라미터로 힙 사이즈를 필요한만큼 지정해주면 된다.

$ node --max-old-space-size=10240 task.js

단위는 MB이다. 즉, 위 코드의 10240은 10GB를 의미한다.

https://nodejs.org/api/v8.html#v8_v8_getheapspacestatistics

----

# 메모리가 부족한 경우 (Grunt)

우린 태스크 러너로 그런트를 사용하고 있는데, 이럴 땐 노드 옵션을 주고 그런트를 이어서 실행하면 된다.

$ node --max-old-space-size=10240 /usr/bin/local/grunt task.js

----

# 힙 사이즈 확인

힙 사이즈를 확인하려면 v8 모듈을 사용하면 된다.

const v8 = require('v8');

v8.getHeapStatistics();

[

...,

{

"space_name": "old_space",

"space_size": 3090560,

"space_used_size": 2493792,

"space_available_size": 0,

"physical_space_size": 3090560

...

]

참고:

- 스택오버플로우: https://stackoverflow.com/questions/24153996/is-there-a-limit-on-the-size-of-a-string-in-json-with-node-js

- 크로미엄 이슈: https://bugs.chromium.org/p/v8/issues/detail?id=847

V8의 헤더 파일

https://v8docs.nodesource.com/node-10.6/d8/dcd/classv8_1_1_resource_constraints.html#a62577457df1cfedc707856d865529b53

쉬운 예:

https://medium.com/@vuongtran/how-to-solve-process-out-of-memory-in-node-js-5f0de8f8464c

Python: 정규식으로 문자열을 자를 때, 그룹이 포함되어 있는 경우

ohgyun — Tue, 30 Oct 2018 14:20:24 +0900

발생일: 2017.08.18

키워드: re, 정규식, lookbehind, 그룹, group, regular expression, regex, split

문제:

문자열을 정규식으로 split 할 때, 정규식 구문에 그룹이 포함되어 있었더니 원하는 결과가 나오지 않는다.

왜 그런 걸까?

해결책:

split()으로 전달하는 패턴에 그룹이 있으면, 분할한 결과 뒤에 그룹 매칭값이 붙는다.

아래 예제를 보면 쉽게 이해할 수 있다.

re.split('-', 'aaa-bbb')

-> ['aaa', 'bbb']

re.split('(-)', 'aaa-bbb') # 그룹으로 묶음

-> ['aaa', '-', 'bbb'] # split 결과에 그룹이 포함된다

re.split('(-)', 'aaa-bbb-ccc') # 여러 번 잘라질 때도 동일

-> ['aaa', '-', 'bbb', '-', 'ccc']

re.split('(-)(x)', 'aaa-xbbb-xccc') # 그룹이 여러 개인 경우

-> ['aaa', '-', 'x', 'bbb', '-', 'x', 'ccc']

그룹에 포함되지 않게 하려면 ?: 를 넣어주면 된다.

re.split('(?:-)', 'aaa-bbb')

논의:

# 자바스크립트에서도 동일

자바스크립트에서도 동일하다.

'aaa-bbb'.split(/-/); //-> ['aaa', 'bbb']

'aaa-bbb'.split(/(-)/); //-> ['aaa', '-', 'bbb']

그룹이 포함된 정규식 구문으로 split 하는 경우에 원하는 결과가 나오지 않는다.

# 글을 문장 단위로 자르기

사실 이 문제는 글을 문장 단위로 자르는 코드를 작성하면서 발생했다.

예를 들어,

"오늘 아마존의 주가는 4.2% 증가했다. 구글은 3.4% 증가했다."

와 같은 문장을 첫 문장과 두 번째 문장으로 구분하려고 했다.

아래와 같이 단순히 마침표로만 자를 수도 있는데,

re.split('\.', text)

이렇게 하면, 자르는 기준에 4.2%, 3.4%와 같은 소수점도 포함되기 때문에 lookbehind 옵션으로 마치표 앞의 문자는 숫자가 아닌 것만으로 제한했다.

re.split('(?<=[^0-9])\.', text)

이때까지 잘 동작했는데, 개행 문자를 정규식 구문에 추가하기 위해 그룹으로 묶었다.

re.split('((?<=[^0-9])\.|\n)', text)

이랬더니, 결과에 마침표가 포함된 거였다.

아래처럼 그룹에 포함되지 않게 변경하는 것으로 수정했다.

re.split('(?:(?<=[^0-9])\.|\n)', text)

그치만 정리하다 보니, 그룹 없이 그냥 캐릭터를 쓰는 게 훨씬 간결하겠네...

re.split('(?<=[^0-9])[\.|\n]', text)

CLI로 젠킨스 설정 업데이트하기

ohgyun — Mon, 29 Oct 2018 21:18:20 +0900

발생일: 2018.10.29

키워드: jenkins, 젠킨스, manage jenkins, reload configuration in command line, 설정 업데이트

문제:

젠킨스의 설정 파일인 config.xml 을 직접 변경하고 나면,

Manager Jenkin (Jenkins 관리) 메뉴에 들어가서 Reload Configuration from Disk 버튼을 눌러야 실행 중인 젠킨스에 반영된다.

CLI로 바로 업데이트 할 수 없을까?

해결책:

터미널에서 아래와 같이 호출하면 된다.

$ java -jar jenkins-cli.jar -s [JENKINS_URL] -auth [ID:PW] reload-configuration

난 젠킨스가 실행되고 있는 환경에서 바로 실행해서 아래와 같이 localhost 로 호출했다.

$ java -jar jenkins-cli.jar -s http://localhost:8080 -auth ${id}:${password} reload-configuration

jenkins-cli.jar 파일은 젠킨스 URL에서 다음 주소로 다운로드 받을 수 있다.

/jnlpJars/jenkins-cli.jar

젠킨스가 실행되어 있는 서버의 터미널이라면, 아래처럼 호출하면 된다.

$ curl -O http://localhost:8080//jnlpJars/jenkins-cli.jar

논의:

# REST API에는 없는 듯

우린 node-jenkins 클라이언트 모듈을 사용하고 있었는데, 이 라이브러리는 REST API를 호출하는 것 같더라.

내가 못 찾은 걸 수도 있는데, REST API에 설정 업데이트는 지원하지 않는 것 같다.

잡(job)이나 빌드 설정은 클라이언트 라이브러리를 활용하는 것이 편하다.

# 권한 필요

설정 업데이트는 젠킨스의 어드민 권한이 있어야 가능하다.

혹시 권한 문제로 실행되지 않는다면, Jenkins 관리 > Manage and Assign Role > Assign Roles 에서 설정해주면 된다.

참고:

https://jenkins.io/doc/book/managing/cli/#downloading-the-client

https://stackoverflow.com/questions/34791525/how-to-reload-the-configuration-jenkins-from-the-command-line

AWS Security Group 중첩 이슈 및 정리 팁

ohgyun — Tue, 23 Oct 2018 18:32:45 +0900

발생일: 2018.04.08

키워드: AWS Security Group, 보안 그룹, 시큐리티 그룹, nested security group

문제:

AWS 보안 그룹에 다른 보안 그룹을 추가했는데, 하위 보안 그룹의 룰셋이 상위 보안 그룹에 추가되는 것 같지 않다.

왜 그런 걸까?

해결책:

보안 그룹 내에 다른 보안 그룹을 추가하는 경우,

- 하위 보안 그룹의 룰셋이 상위 보안 그룹의 룰셋에 추가되는 것이 아니라,

- 하위 보안 그룹을 가진 인스턴스들이 상위 보안 그룹에 액세스할 수 있게 된다.

오해하기 쉬워 보인다. @_@

참고:

https://stackoverflow.com/questions/42871841/can-you-configure-aws-security-groups-to-have-sub-groups-or-nested-groups

https://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html

AWS: 10 Things You're Probably Doing Wrong as ans Architect

https://labs.eleks.com/2013/11/aws-10-things-youre-probably-doing.html

논의:

종종 보안 설정이 헷갈렸던 이유는, 보안 그룹을 룰셋으로 설정할 때도 있고, 대상 인스턴스의 IP 목록으로 설정하는 경우도 있었기 때문이다.

아래처럼 정리하면 편리할 것 같다.

- VPC를 대표하는 default 그룹을 생성. default 그룹은 모든 인스턴스가 갖도록 한다.

- 각 인스턴스의 그룹은 그룹을 대표할 수 있는 이름(예: app, rds, redshift, redis, jenkins-slave 등)을 보안 그룹으로 갖게 한다.

- 즉, 이 보안 그룹은 룰셋인 동시에 해당 인스턴스의 목록이 된다.

- 해당 보안 그룹의 Inbound 룰에 AWS 인스턴스로부터의 접근 권한을 지정한다.

- 예) 특정 인스턴스의 접근만 허용할 거라면, 해당 보안 그룹을 추가하는 방식으로 넣어준다.

- 예) 모든 인스턴스의 접근을 허용할 거라면 default 그룹을 추가한다.

- VPC 외부의 IP를 명시하는 보안 그룹은 별도로 만들고, (보안 그룹이 아니라) 인스턴스에 지정한다.

- 이 보안 그룹은 외부 IP에 대한 룰셋이므로 별도의 접두사를 둔다.

예) ext_office: 사무실 IP 룰 목록

- 예를 들어, app 인스턴스엔 default, app, ext_office 보안 그룹이 할당되어 있다.

Python으로 Alfred Workflow 만들기

ohgyun — Sat, 20 Oct 2018 01:37:35 +0900

발생일: 2018.10.20

키워드: alfred workflow, 알프레드 워크플로우

문제:

파이썬으로 알프레드 워크플로우 만들기 :)

해결책:

파이썬으로 워크플로우를 쉽게 만들 수 있게 부트스트랩 라이브러리를 만들어둔 저장소가 있다.

https://github.com/deanishe/alfred-workflow

아래는 간단 튜토리얼.

http://www.deanishe.net/alfred-workflow/tutorial_1.html

논의:

# 부트스트랩 라이브러리 설치

알프레드 워크플로우를 생성한 후에, 해당 디렉토리에서 아래처럼 설치할 수 있다. (설치 가이드 참고)

$ pip install --target ./workflow Alfred-Workflow

----

# 한글 이슈

알프레드는 맥의 기본 버전인 파이썬 2.7 버전을 사용하기 때문에, 고질적인 유니코드 문제가 있다.

unicodedata 모듈로 아래와 같이 노멀라이징하면 스크립트 필터에서 전달하는 한글 이슈를 해결할 수 있다.

import sys

import unicodedata

reload(sys)

sys.setdefaultencoding("utf-8")

query = unicodedata.normalize('NFC', query)

위에서 언급한 workflow 모듈의 인스턴스의 args 변수에 실행 스크립트로 전달한 인자가 저장되며,

이미 유니코드로 노멀라이즈 되어 있어서 바로 사용해도 된다.

query = wf.args[0]

다만, 디버깅 용도로 print()로 한글을 출력하려면 기본 인코딩을 지정해줘야 한다.

import sys

reload(sys)

sys.setdefaultencoding("utf-8")

query = wf.args[0]

----

# 서드파티 라이브러리 추가 (third-party library)

먼저, pip로 별도 라이브러리에 서드파티 라이브러리를 설치한다.

예를 들어, lib 디렉토리에 click 이란 패키지를 설치하려면 아래와 같이 실행하면 된다.

$ pip install --target=./lib click

스크립트에서 직접 가져오려면 __init__.py 를 만들어줘야 한다.

$ touch ./lib/__init__.py

from lib import click

wf 인스턴스에서 바로 가져오는 방법도 있다.

def main(wf):

import requests

...

if __name__ == '__main__':

wf = Workflow3(libraries=['./lib'])

sys.exit(wf.run(main))

----

# 꿀벌개발일지 검색용 워크플로우

아래와 같이 검색하는 간단한 워크플로우이다.

코드는 아래 gist에서 확인하면 된다.

https://gist.github.com/ohgyun/0f728f80ff14fd64e5bea476be2cf695

다운로드해 참고해보면 쉽게 다른 워크플로우를 만들 수 있을 것이다. :D

꿀벌개발일지_1.0.alfredworkflow

MySql: LOAD DATA INFILE 로 대용량 데이터 인서트하기

ohgyun — Fri, 19 Oct 2018 19:14:08 +0900

발생일: 2017.11.17

키워드: MySQL, LOAD DATA INFILE, insert large amount of dataset into mysql database, 대용량 데이터 추가

문제:

대용량 데이터를 MySQL 디비에 인서트하려고 한다. 가장 효율적인 방법이 뭘까?

해결책:

텍스트 파일을 읽어 테이블에 인서트하는 LOAD DATA INFILE 구문이 있다.

기본 INSERT 구문을 쓰는 것보다 20배 정도 빠르다고 한다.

대략 아래와 같은 포맷으로 실행할 수 있다.

LOAD DATA LOCAL INFILE '{file_name}'

INTO TABLE {table_name}

CHARACTER SET utf8

FIELDS

TERMINATED BY '{field_terminator}' # 각 필드 구분 문자 (예: CSV라면 컴마)

OPTIONALLY ENCLOSED BY '"' # 필요할 경우, 따옴표(")로 구분

LINE TERMINATED BY '\n'

IGNORE 1 LINES # 제목이 포함된 첫 번째 줄은 생략

(col1, col2, ... ) # 컬럼명

논의:

# 권한 이슈

LOAD DATA를 사용하려면 별도의 권한이 있어야 한다. DB에 접속할 때, load_infile=1 파라미터를 넘기면 된다.

----

# 인덱스와 인서트 성능

MyISAM 테이블에서는 인덱스를 끄면 성능이 향상된다고 한다.

ALTER TABLE ... DISABLE KEYS;

InnoDB 테이블에서는 인덱스를 끄지 않아도 된다.

----

2018.03.09 추가

# 유니코드 캐릭터 인코딩 이슈

유니코드 형식의 데이터의 백슬래시가 사라지고 코드 자체가 인서트되는 경우가 있다.

예를 들어, 데이터에 '경기도'라는 문자가 있다면, 유니코드로 변환돼 "\uacbd\uae30\ub3c4"가 인서트되어야 하는데,

백슬래시가 생략되어 "uacbduae30ub3c4"와 같이 인서트된다.

CSV로 저장할 때 이스케이프 캐릭터였던 백슬래시를 문자열로 변경했는데,

MySQL에서 파일을 로드할 때 백슬래시를 다시 이스케이프 캐릭터로 인식한 것이 문제였다.

CSV로 저장할 때 이미 문자열된 상태이기 때문에 MySQL에서 로드할 땐 이스케이프 캐릭터를 무시하는 것으로 해결했다.

LOAD DATA LOCAL INFILE '{file_name}'

INTO TABLE {table_name}

CHARACTER SET utf8

FIELDS

TERMINATED BY '{field_terminator}'

OPTIONALLY ENCLOSED BY '"'

ESCAPED BY '' # 문자열 그대로 인서트될 수 있게 이스케이프 캐릭터를 빈 값으로 처리

LINES TERMINATED BY '\n'

IGNORE 1 LINES

({column_str})

----

2018.10.19 추가

# 빈 값 이슈

CSV 파일 내 빈 데이터가 NULL로 인서트 되지 않고, 컬럼 타입에 따라 empty string ('') 또는 0으로 들어간다.

기본값인 NULL로 넣고 싶다.

예) 1,2,3,,5

MySQL 문서에 따르면, LOAD DATA의 타겟 파일의 빈 필드에 \N 을 넣으면 NULL로 인서트된다고 한다.

NULL를 넣어도 될 때가 있는데, 환경에 따라 다르다고 하니 \N을 넣는 게 좋겠다.

예) 1,2,3,\N,5

우린 pandas의 데이터프레임을 CSV로 만들어 인서트하고 있는데, pandas에 빈 값을 할당하는 인자가 있어 아래와 같이 처리했다.

df.to_csv(filename, na_rep='\\N')

참고: https://stackoverflow.com/questions/2675323/mysql-load-null-values-from-csv-data

Pandas: 그룹 내에서 상위 n개 가져오기

ohgyun — Fri, 19 Oct 2018 16:57:19 +0900

발생일: 2018.10.19

키워드: pands, 판다스, groupby, nlargest, nsmallest, sort_values, get n largest value in group

문제:

그룹 내에서 값이 큰 순으로 상위 n개만 가져오려고 한다.

해결책:

이 용도의 nlargest 와 nsmallest API를 제공하고 있다.

하지만, 가장 빠른 방법은 데이터프레임을 원하는 값으로 정렬한 후에 groupby 하고, head 로 가져오는 것이다.

id, name, total 로 구성된 데이터프레임이 있고, 각 name의 값을 total 로 정렬해 상위 3개만 가져오고 싶다면 아래와 같이 처리하는 것이 빠르다.

df.sort_values(by='total', ascending=False).groupby('name').head(3)

DataFrame.groupby 문서에 의하면,

sort : boolean, default True

Sort group keys. Get better performance by turning this off.

Note this does not influence the order of observations within each group.

groupby preserves the order of rows within each group.

그룹 내 행의 순서가 유지되기 때문에 안전하다.

그룹 자체의 정렬이 필요하지 않다면, sort 옵션을 끄면 좀 더 빠르다.

df.sort_values(by='total', ascending=False).groupby('name', sort=False).head(3)

논의:

nlargest 를 사용해 동일하게 아래와 같이 처리해도 된다.

df.groupby('name').apply(lambda x: x.nlargest(3, 'total'))

하지만, 약 150만개 행으로 테스트했을 때, 첫 번째 방법은 200ms 근처로 실행됐지만, 두 번째 방법은 40초 이상 걸렸다.

참고:

https://stackoverflow.com/a/36074520/954292

ML: Matchbox Recommender 추천 모델 적용 실패 사례

ohgyun — Fri, 19 Oct 2018 12:15:02 +0900

발생일: 2017.01.14

키워드: Matchbox recommender

문제:

지금도 잘 모르지만, 지금보다 더 잘 몰랐을 때의 메모 ㅎㅎ.

MS 의 Mathbox recommender 모델을 사용해 추천을 적용하려고 했다가 실패했다.

점수를 내는 기준을 제대로 잡지 못했기 때문이다.

지금 보면 워낙 기초가 없던 때라 그런 거였는데, 나중에 같은 실수를 하지 않게 기록해둔다.

해결책:

매치박스 레코멘더 모듈은 각 아이템 간에 점수(rating)를 부여하고 이를 조합해 추천하는 방식이다.

우린 아파트 정보 서비스여서,

- 사용자에게 아파트를 추천

- 아파트와 비슷한 아파트 추천

하는 것을 목표로 했다.

점수는 조회수와 알림 구독 여부, 우리집 선택 여부로 아래와 같이 조합했다.

- rating이 0부터 시작해서,

- 조회수 4건 이상이면 +1

- 조회수 7건 이상이면 +2

- 구독하면 +2

- 우리집으로 선택하면 +2

rating의 최대값은 10으로 조정했다.

평가값이 0~최대값 사이이기 때문에, 이상치에 의해 최대값이 영향을 받을 것 같았기 때문이다.

여러 조건으로 실험해본 결과는 정확도는 0.75~0.8사이에 있었고, 평가값이 좋아지는 쪽으로 수치를 조절했다.

사용자에게 아파트를 추천하는 작업은 학습 시간이 오래 소요돼서, 아파트와 비슷한 아파트 추천 결과를 실제로 돌려봤다.

헐... 근데 결과가 정말 엉망이었다. 이렇게 안 맞을 수 있다니.... -0-

혹시나 해서 조회수만 기준으로 해서, rating 값이 0, 1, 2만 나오도록 실험했더니 0.87이 나오더라.

나아가, 구독 여부로 rating이 0, 1만 나오도록 했더니, 정확도가 0.96까지 올라갔다.

비슷한 아파트 추천 결과도 만족스러웠다.

왜 그랬던 걸까?

논문을 살펴봤다.

Matchbox: Large Scale Online Bayesian Recommendations 논문: http://www.herbrich.me/papers/www09.pdf

In addition it is desirable that a recommender system can

be applied flexibly in a wide variety of scenarios. Frequently,

data on user preferences is in the form of ratings on an ordinal

scale (for example Netflix [1]) where each user’s interpretation

of this scale may be different. In other cases we

may only have data showing which items were clicked on

by a user, where we assume that a user clicking on an item

provides implicit evidence that it is interesting to them

사용자는 흔히 넷플릭스의 영화 평점처럼 1~5점의 순서를 가진 값으로 선호도를 평가할 수 있다.

이렇게 평가할 경우, 같은 점수를 주더라도 사용자마다 평가하는 기준은 다를 수 있다.

(예: A가 준 4점과, B가 준 4점은, 점수를 주는 그의 성향에 따라 의미가 다를 수 있다)

반면, 좋다/싫다와 같이 평가할 수도 있다.

구글의 뉴스 추천 시스템은 단순히 기사 클릭 여부를 가지고 추천한다고 한다.

논문에서 제시하는 추천 시스템 아래 3가지 대안을 가지고 rating을 평가한다.

The model for user feedback is flexible. We present

three alternatives: direct observation of an absolute

rating each user gives to some items, observation of a

binary preference (like/ don’t like) and observation of

a set of ordinal ratings on a user-specific scale

- rating의 절대값

- rating의 바이너리값

- 사용자가 평가한 값의 범위 내에서의 순위

생각해보니, 우리가 잘못 적용한 점이 있었다.

먼저, rating의 후보 값은 같은 맥락에 있어야 한다는 것이다.

영화 평점이 1~5점이었던 것에 반해, 우리가 처음에 적용했던 척도와는 좀 달랐다.

- A가 평점을 3, 4, 5 범위 내에서만 했다면, A에게 4점은 보통일 것이다.

- B가 평점을 1, 3, 5 범위 내에서만 했다면, B에게 4점은 좋은 축에 속할 것이다.

같은 맥락이 아니라면 사용자 범위 내로 순위를 매길 때 의미가 없어질 것 같다.

완전히 조회수 기준이라면,

- A의 아파트 선호도가 1, 10, 30이라면, A에게 10번 조회는 나쁜 축에 속할 것이다.

- B의 아파트 선호도가 1, 3, 10이라면, B에게 10번 조회는 좋은 축에 속할 것이다.

(이런 이유 때문에 n번 이상 평가한 사용자를 변수로 설정할 수 있게 한 모양이다)

우리가 처음에 했던 것처럼, 조회수(+1씩)와 구독 여부(+10)의 조건을 합해 점수를 냈다면,

- A의 아파트 선호도가 1, 10(a, 구독), 30(조회+)이라면, A는 구독한 아파트 a는 추천 대상이 아닐 것이다.

- 반면, B의 아파트 선호도가 1, 3, 10(b, 구독)이라면, B가 구독한 아파트 b는 추천 대상이다.

처음부터 rating의 변수를 설정했던 방법이 우리 의도를 벗어난 것이었다.

이런 경우라면, 바이너리 결과 값으로 rating을 평가하는 것이 더 나은 결정일 것 같다.

conda 환경에서 pip 패키지도 동시에 업데이트 하기

ohgyun — Fri, 19 Oct 2018 11:35:34 +0900

발생일: 2018.10.18

키워드: conda env update, pip install --upgrade, environment.yml, 콘다 환경, 아나콘다, 미니콘다, anaconda, miniconda

문제:

서비스에서는 conda 패키지를 envrionment.yml 파일로 관리하고 있다.

이런 식이다.

[environment.yml]

name: foo

channels:

- conda-forge

- defaults

dependencies:

- python=3.7

- ipython

- jupyter

- pandas

- numpy

- pip:

- konlpy

- ...

헌데, conda env update 를 실행해도, 환경 파일에 정의해둔 pip 패키지는 업데이트되지 않는다.

어떻게 해야할까?

---

conda 4.6.13 부터 해결되었다고 한다.

https://github.com/conda/conda/issues/7774

해결책:

conda environment 내에 정의한 pip 내의 패키지는 환경을 생성(conda create)할 땐 설치되지만, conda env update 명령으로 업데이트되진 않는다.

패키지가 별도로 관리되기 때문이다.

conda list 의 결과 내에 pip 패키지도 포함되어 있기 때문에, 이 목록으로 별도로 업데이트하게 처리했다.

conda list | grep "<pip>" | cut -d " " -f 1 | xargs pip install --upgrade

https://stackoverflow.com/questions/44265533/does-conda-update-packages-from-pypi-installed-using-pip-install

논의:

# 환경 파일에서 채널은 뭔가?

- 채널을 정의하면 conda install 로 패키지를 설치할 때, 해당 채널의 패키지를 설치한다.

- conda-forge 채널의 패키지를 설치하는 것이 안정성 측면에서 높다고 한다.

- 설치하려는 패키지가 정의한 여러 채널에 중복으로 있는 경우, 선호도가 높은 채널(정의한 순서대로)의 것을 먼저 사용한다.

- 참고: https://veranostech.github.io/docs-korean-conda-docs/docs/build/html/user-guide/tasks/manage-channels_ko.html#id3

# 환경 파일에서 pip 정의해야 하나?

- pip는 기본으로 설치된다.

- environment.yml 에서 pip 는 생략해도 된다.

# 환경 파일을 자동으로 관리할 수 없을까? lock 을 한다거나.

- conda env export 명령으로 enviroment.yml 파일을 생성할 수 있지만, OS 간 호환성이 보장되지 않는다.

- 패키지에 따라 OS 별로 버전이 다른 경우가 있기 때문이다.

- 따라서, OS 간 호환이 필요하다면, conda 의 environment.yml 파일은 수동으로 관리해주는 게 좋다.

- 참고: https://stackoverflow.com/questions/39280638/how-to-share-conda-environments-across-platforms

나중엔 운영과 동일하게 docker 로 환경을 구성하고, 필요한 시점에 conda env export 로 lock 파일을 만들어 관리해야겠다.

node.js: euc-kr 페이지에 보낼 요청 파라미터 인코딩

ohgyun — Sat, 29 Sep 2018 22:37:57 +0900

발생일: 2018.09.03

키워드: euc-kr, euckr, node.js, iconv, 인코딩, encoding, escape, encodeURIComponent

문제:

노드에서 euc-kr 로 인코딩 된 페이지로 GET 요청을 보내려고 한다.

한글이 포함된 값을 파라미터로 전송하려고 하는데, 어떻게 인코딩하면 될까?

해결책:

iconv 라이브러리를 활용하면 된다.

const buffer = iconv.encode('한글이 포함된 파라미터', 'euckr'); // 파라미터를 euc-kr 로 인코딩 해 버퍼에 담은 후,

const param = encode(buffer.toString('binary')); // 바이너리로 변환해 이스케이프하면 된다.

논의:

encodeURI() 와 encodeURIComponent() 는 UTF8 인코딩된 문자열을 대상으로 한다.

UTF8로 인코딩되지 않은 문자열을 URL 인코딩(퍼센트 인코딩)하고자 할 땐, 바이너리로 변환 후 escape() 함수를 사용하면 된다.

참고:

노드에서 euc-kr 로 인코딩된 문서나 페이지를 읽어올 땐 아래 포스트를 참고

http://ohgyun.com/665

클라이언트에서 euc-kr로 submit을 보낼 땐 아래 포스트를 참고

http://ohgyun.com/314

Jupyter notebook HTML output에 템플릿 적용하기

ohgyun — Sat, 29 Sep 2018 02:03:48 +0900

발생일: 2018.09.29

키워드: Jupyter notebook, nbconvert to HTML

문제:

작성한 주피터 노트북을 팀내에 공유하거나 배치로 메일 등으로 발송하게 하려고 한다.

nbconvert 모듈로 HTML이나 PDF 포맷으로 export 할 수 있다는 건 알고 있다.

$ jupyter nbconvert --to html sample.ipynb --output output.html

이렇게 처리했는데, 생성된 HTML이 정말 못생겼다.

좀 예쁘게 바꾸고 싶은데, 어떻게 하면 될까?

해결책:

nbconvert 모듈로 export 할 때, --template 옵션으로 별도의 템플릿을 적용해 출력 형태를 바꿀 수 있다.

$ jupyter nbconvert --to html sample.ipynb --template=basic.tpl --output output.html

템플릿을 적용해 변환하는 것에 대한 설명은 아래 포스트에 쉽게 잘 정리되어 있다.

https://www.datacamp.com/community/tutorials/jinja2-custom-export-templates-jupyter

기본적인 방법은 위 포스트 뿐 아니라 구글링 결과도 많다.

여기엔 상세하게 스타일을 설정하려고 할 때 참고할 만한 자료에 대해 정리해뒀다.

템플릿 엔진

먼저, nbconvert 모듈은 파이썬의 주요 템플릿 엔진인 Jinja 템플릿을 쓴다.

스타일을 변경하거나 원하는 템플릿만 출력하는 정도만 활용하면 되며, 아래 링크의 템플릿 문법만 알아두면 된다.

http://jinja.pocoo.org/docs/2.10/templates/

템플릿 구조

주피터 노트북을 컨버팅할 때, 템플릿의 구조를 알아야 상세하게 설정할 수 있겠더라.

템플릿의 구조는 아래 문서를 확인하면 된다.

https://nbconvert.readthedocs.io/en/latest/customizing.html#Template-structure

부모 템플릿

하위 템플릿에서 상속한 상위 템플릿의 상세 구조를 알아야 하는 경우가 있었다.

내가 사용하기엔 기본 제공되는 basic.tpl 은 너무 간소했고, full.tpl 은 너무 과했다.

이럴 땐 basic.tpl 의 일부만 따서, 원하는 템플릿을 만들면 된다.

상위 템플릿 파일은 아래 링크에서 확인할 수 있다.

basic.tpl 파일

https://github.com/jupyter/nbconvert/blob/4.x/nbconvert/templates/html/basic.tpl

full.tpl 파일

https://github.com/jupyter/nbconvert/blob/4.x/nbconvert/templates/html/full.tpl

테마 모음

주피터 노트북 테마가 없을 리가 없다.ㅎㅎ

주피터 노트북의 테마까지 변경할 수 있고, 어떤 모듈은 프로필까지 적용해준다.

그 중 괜찮아 보이는 모듈을 찾았다.

https://github.com/dunovank/jupyter-themes

난 일단 목적에 충실하기 위해 스타일만 가져다 적용해봤다. HTML 아웃풋도 예쁘게 잘 나온다.

https://github.com/dunovank/jupyter-themes/blob/master/jupyterthemes/styles/compiled/chesterish.css

그렇지만, 난 깃헙 스타일이 제일 좋더라!

A Github Flavored Theme for Ipython or Jupyter Notebook

https://gist.github.com/aahoo/e8ed425759711ead1ef7e7a3332dcd2d

스크립트 적용

full.tpl 은 기본적으로 jQuery를 임베딩하고 있다.

난 스태틱한 페이지를 만들기 위해 스크립트를 제거했는데, 필요에 따라 활용하는 것도 좋다.

아래는 output이 토글되게 적용한 샘플이다.

https://gist.github.com/gabraganca/7097067

TemplateExporter

템플릿 파일에서 셀의 출력 방식을 변경하거나 원하지 않은 경우 빈 값으로 렌더링할 수 있다.

하지만, nbconvert 명령에서 TemplateExporter 옵션으로도 제거할 수 있다.

난 input 영역과 output 의 숫자 출력 부분을 제거하고 싶어 아래와 같이 실행했다.

$ jupyter nbconvert --to html .ipynb --template=sample.tpl --TemplateExporter.exclude_input=True --TemplateExporter.exclude_output_prompt=True --output output.html

TemplateExporter 로 제거할 수 있는 항목은 아래 문서를 참고하면 된다.

https://nbconvert.readthedocs.io/en/latest/config_options.html?highlight=TemplateExporter

추가로, 용어가 좀 헷갈려서 설명 이미지를 만들었다.

노트북을 새로 실행하면서 변환

노트북을 새로 실행하면서 생성하려면 --execute 옵션을 주면 된다.

$ jupyter nbconvert --to html .ipynb --execute --output output.html

최종

아래 이미지는 기본 컨버팅 결과와 템플릿을 다듬어서 출력한 결과를 비교해둔 것이다.

손본 게 확실히 예뿌다.ㅎㅎㅎ

수정한 템플릿 파일은 아래 gist를 참고하면 된다.

https://gist.github.com/ohgyun/986a5c1718e49f8d6da6d0cb5e79438e

컨버팅할 때 실행한 명령은 다음과 같다.

$ jupyter nbconvert --to html .ipynb --template=sample.tpl --TemplateExporter.exclude_input=True --TemplateExporter.exclude_output_prompt=True --output output.html

Node.js: npm asyncWrite 오류 발생할 때

ohgyun — Thu, 27 Sep 2018 12:59:58 +0900

발생일: 2019.09.27

키워드: node, npm install, n, asyncWrite

문제:

npm install 로 모듈을 설치할 때 아래와 같은 오류가 발생한다.

npm ERR! asyncWrite is not a function

npm ERR! pna.nextTick is not a function

해결책:

npm 을 재설치하는 방법으로 해결했다.

$ curl -0 -L https://npmjs.com/install.sh | sudo sh

논의:

npm 모듈의 캐시도 날려보고

$ sudo npm cache clean -f

node 관리 모듈인 n을 재설치하기도 하고, node 를 stable 버전으로 새로 갱신하기도 했는데 해결되지 않았다.

다른 사람들은 이런 방법으로도 해결된 것 같으니 혹시 npm 재설치로 해결되지 않는다면 시도해보는 것도 좋겠다.

참고:

https://stackoverflow.com/questions/50597159/npm-err-asyncwrite-is-not-a-function/52529039#52529039

DataGrip 팁 모음

ohgyun — Sun, 23 Sep 2018 18:28:17 +0900

발생일: 2018.09.01

키워드: JetBrains DataGrip, 단축키, shortcut

문제:

얼마 전부터 데이터베이스 IDE로 젯브레인의 데이터 그립을 사용하고 있다.

1년 결제 시 연간 $199, 3년 결제 시 연간 $119로 매우 비싸지만...

여러 디비를 한 번에 쓸 수 있다는 장점이 있어 바꿨다.

사용해보고 몇 가지 자주 사용하는 팁을 기록해둔다.

해결책:

* 팁 내에서 RMB는 오른쪽 마우스(Right Mouse Button)를 의미

특정 테이블 하나를 빠르게 조회하기

- Cmd + O -> 테이블명 입력 -> <Filter Criteria> 에 where 절 검색

- 기본 필터 단축키가 복잡하다. 난, Cmd + Shift + F 로 변경해두고 사용하고 있는데 편하다!

Row/Column 전환하기

- 테이블에 여러 컬럼이 있을 때에 유용하다.

- 테이블 조회 후, RMB -> Transpose 하면 된다.

- 난 단축키로 Cmd + Shift + T 를 할당해놓고 사용하고 있다.

특정 인덱스나 컬럼을 포함한 테이블 조회하기

- Cmd + Option + O 로 특정 컬럼이나 인덱스 명으로 테이블을 조회할 수 있다.

Explain 빠르게 하기

- 콘솔에서 쿼리 선택 후, RMB -> Explain

- 명령어에 Explain을 붙이지 않아도 편리하다.

템플릿으로 빠르게 쿼리 작성하기

- 자주 사용하는 쿼리를 설정 > Live Templates 에 넣어두면 편하다.

- 예: sel 입력하면 select 완성

Matplotlib: 폰트 기본 경로를 찾을 수 없을 때

ohgyun — Sun, 23 Sep 2018 12:27:49 +0900

발생일: 2018.09.22

키워드: Jupyter Notebook, 주피터 노트북, 한글 폰트, 한글 깨질 때, font_manager, fontManager, seaborn, custom font, 나눔고딕, Nanum Gothic, AppleGothic, Mac OS X, set matplotlib font directory

문제:

주피터 노트북에서 Matplotlib 이나 Seaborn 으로 차트를 그릴 때 한글이 깨지는 문제가 있다.

이상한 건, 기존엔 잘 그려지다가 갑자기 안된다는 것이다.

폰트 설정도 하고, rcParam도 설정하고, 캐시도 날려보고, 무려 재부팅도 했는데 안된다...

왜 그럴까?

해결책:

Matplotlib 모듈이 내 맥의 폰트 디렉토리를 제대로 찾지 못하는 것 같다.

정확한 원인은 모르겠지만, 커널이 실행된 후에 모듈을 업데이트하는 과정에서 뭔가 문제가 생겼나보다.

여튼, 아래와 같이 명시적으로 폰트 디렉토리를 설정해주는 방법으로 해결했다.

from matplotlib import font_manager

# 폰트 경로가 인식되지 않는 문제가 있다

font_dirs = ['/Library/Fonts']

font_files = font_manager.findSystemFonts(fontpaths=font_dirs)

font_list = font_manager.createFontList(font_files)

font_manager.fontManager.ttflist.extend(font_list)

font_dirs 변수 내에 있는 /Library/Fonts 는 맥의 기본 폰트 디렉토리이다.

별도로 설치한 폰트나 다른 디렉토리에 있는 폰트를 차트를 그리는데 사용하고 싶다면,

동일하게 font_dirs 디렉토리에 넣어두면 된다.

프로젝트 내에서 공통으로 사용하는 폰트라면, 폰트 ttf 파일을 리파지터리에 넣어두고 상대 경로로 지정해도 괜찮을 것 같다.

font_dirs 가 유효하지 않아도 워닝이가 경고가 발생하지 않는다.

스크립트가 여러 환경에서 실행된다면, 대상 OS의 유효한 폰트 디렉토리를 넣어둬도 괜찮을 것 같다.

난 주로 Seaborn 을 사용하고 있어서, 폰트는 아래와 같이 적용했다.

import seaborn as sns

...

sns.set(font='AppleGothic')

논의:

일반적으로 한글이 깨지는 건 기본으로 설정된 폰트에 한글이 없기 때문이다.

대부분 차트의 폰트를 바꾸는 방법으로 해결 가능하다.

----

내게 발생한 문제는 아니었는데, 주피터 노트북의 캐시가 문제가 되는 경우가 있다고 한다.

이 땐 주피터 노트북의 캐시를 삭제하고, 노트북을 다시 실행하면 해결된다고 한다.

캐시 디렉토리는 get_cachedir() 명령으로 확인할 수 있다.

import matplotlib as mpl

print(mpl.get_cachedir()) #--> '/Users/ohgyun/.matplotlib'

디렉토리엔 font 관련 JSON 파일 등이 있는데, 그냥 다 지우면 된다.ㅎㅎ

!rm -r {mpl.get_cachedir()}/*

참고로, 캐시를 지우지 않고도 폰트 매니저의 내부 메서드로 빌드할 수도 있다.

mpl.font_manager._rebuild()

참고:

커스텀 폰트 디렉토리 설정하기

https://stackoverflow.com/questions/35668219/how-to-set-up-a-custom-font-with-custom-path-to-matplotlib-global-font

폰트 설정에 대해 전반적으로 잘 설명해주는 강의

https://programmers.co.kr/learn/courses/21/lessons/950

Pandas: 한 셀의 데이터를 여러 행으로 나누기

ohgyun — Sat, 22 Sep 2018 12:00:36 +0900

발생일: 2018.09.22

키워드: pandas, stack, unstack, split array to multiple rows

문제:

df = pd.DataFrame({'foo': ['a,b,c,d,e', 'd,e,f', 'h,i']})

위와 같이 한 셀에 들어있는 문자열을 컴마로 구분해서 한 글자씩 여러 행으로 나누고 싶다.

해결책:

문자열을 split 해 각 행을 여러 컬럼으로 나눈 후 병합하는 방법으로 구현할 수 있다.

먼저, 각 foo 컬럼의 문자열을 배열로 나눈다.

split = df.foo.str.split(',')

split

각 배열이 Series를 리턴하게 apply를 적용하면, Series -> DataFrame으로 변환할 수 있다.

split = split.apply(lambda x: pd.Series(x))

split

stack() 으로 컬럼을 행으로 변환할 수 있다.

split.stack()

stack()을 실행하면, 위와 같이 멀티 인덱스를 가진 Series가 된다.

알파벳 낱자만 가져오기 위해 인덱스를 초기화하고, 기준이 된 인덱스도 제거해보자.

split.stack().reset_index(level=1, drop=True)

이 결과는 Series이기 때문에, DataFrame으로 변환해보자.

to_frame()이 파라미터로 컬럼명을 지정할 수 있다.

split = split.stack().reset_index(level=1, drop=True).to_frame('foo_single')

split

필요에 따라, 원본 프레임에 left join으로 머지하면 아래와 같이 의도했던 결과를 얻을 수 있다.

df.merge(split, left_index=True, right_index=True, how='left')

MySQL: max_execution_time 설정하기

ohgyun — Fri, 21 Sep 2018 01:14:16 +0900

발생일: 2018.08.28

키워드: max_execution_time, slow query, cpu 100% of database

문제:

실수로 실행 시간이 아주 긴 쿼리가 운영 중인 서비스에서 실행됐다.

서버에서 맺은 커넥션은 타임아웃이 걸려있어서 문제 없이 끊겼는데, MySQL 서버의 CPU는 여전히 100%다.

디비 서버의 모든 커넥션을 끊은 후에도 한동안 CPU가 100%로 유지되더라.

문제가 뭘까.

해결책:

문제의 쿼리는 SELECT 구문으로 무려 80초나 걸리는 것이었는데, 커넥션이 끊긴 이후에도 해당 쿼리는 계속 실행된 게 원인으로 보인다.

동일 쿼리가 여러 번 실행됐을 거고, 이런 이유로 CPU가 계속 100%가 되었던 것으로 추측된다.

커넥션 타임아웃(connet_timeout)을 설정해둬서 이런 경우에도 문제 없을 거라고 생각했고,

언뜻 커넥션이 끊겼으니 문제의 쿼리도 종료됐을 거라 생각했는데 아니었다.

커넥션 타임아웃을 설정하는 것과 쿼리의 실행 시간을 제한하는 것은 별개의 문제다.

또한, 운영 중인 디비 서버에서 실행 시간이 지나치게 긴 쿼리는 제한 시간 내에 종료되어야 하는 게 정상이다.

MySQL에선 max_execution_time 을 설정해 SELECT 구문의 실행 시간을 제한할 수 있다.

서비스 뿐만 아니라, 배치 작업 등 여러 환경에서 디비 서버를 사용하고 있기 때문에 글로벌로 설정하는 대신 세션 단위로 설정하기로 했다.

커넥션 풀에서 커넥션을 맺을 때 아래 쿼리를 실행해 시간을 제한했다. 단위는 밀리세컨드이다.

SET SESSION max_execution_time = 5000 -- SELECT 구문을 5초로 제한

세션이 아니라 쿼리에서 직접 설정할 수도 있는데, 이땐 아래와 같이 /*+ 로 시작하는 힌트 구문을 적용하면 된다.

SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM employee -- 실행시간을 1초로 제한

참고로, 시스템 변수를 0으로 설정하면 무제한이지만, 힌트에서 0으로 설정할 경우엔 무제한이 아니라 시스템 변수를 따른다고 한다.

SELECT /*+ MAX_EXECUTION_TIME(0) */ * FROM employee -- 시스템 변수를 따름

논의:

꽤 오래 전부터 종종 디비 서버의 CPU가 100%가 되면서 힘들어하곤 했다.

여러 원인이 있었고, 해결하기 위해 여러 방법(쿼리 수정, 실행 시간 제한, 리드 리플리케이션 등등)을 적용했고, 지금은 안정화된 것 같아 보인다.

글쎄- 원인도 복합적이고 해결책도 그랬겠지만, 실행 시간을 제한하기로 한 건 좋은 선택이었던 것 같다.

참고:

https://stackoverflow.com/questions/415905/how-to-set-a-maximum-execution-time-for-a-mysql-query

MySQL: FULLTEXT 인덱스와 일반 인덱스 성능 차이

ohgyun — Fri, 21 Sep 2018 01:13:50 +0900

발생일: 2018.07.26

키워드: fulltext index, use index, match against

문제:

FULLTEXT 인덱스를 적용해 둔 테이블에서 날짜와 주소로 조회하려고 한다.

테이블 크기는 약 1800만 행 정도이고, 컬럼과 인덱스 정보는 아래와 같다.

employee: 약 1800만 행

- address: 주소

- join_date: 입사일

인덱스:

- address: FULLTEXT index

- join_date: index

주소와 날짜로 검색하기 위해 아래와 같이 조회했는데,.. 엄~청 느리다.

SELECT *

FROM employee

WHERE

MATCH(address) AGAINST('+서울' IN BOOLEAN MODE) -- (A)

AND join_date >= '${fromDate}' -- (B)

AND join_date <= '${now}'

왜 그런 걸까?

해결책:

풀텍스트 인덱스(A 조건)가 날짜 인덱스(B 조건)보다 먼저 적용됐기 때문이다.

FULLTEXT 인덱스는 전체 테이블을 대상으로 스캔하고, 매칭 결과도 많아 오래 걸린 것이었다.

이번 건의 경우, 날짜 조건이 더 좁았기 때문에 USE INDEX로 입사일 인덱스를 사용하게 변경했다.

SELECT *

FROM employee USE INDEX (join_date)

WHERE

address LIKE '%서울%'

AND join_date >= '${fromDate}'

AND join_date <= '${now}'

참고로, FULLTEXT 인덱스는 다른 인덱스와 함께 사용할 수 없다.

MATCH AGAINST 구문을 인덱스 설정 없이 사용하면 아래와 같은 오류가 발생한다.

[HY000][1191] Can't find FULLTEXT index matching the column list

참고:

http://jojoldu.tistory.com/243

http://blog.acronym.co.kr/270

iOS/macOS 사파리 12에서 Array.prototype.reverse() 버그

ohgyun — Thu, 20 Sep 2018 15:06:42 +0900

발생일: 2018.09.20

키워드: reverse, array, iOS, macOS, safari, javascript array bug

문제:

옆자리 C가 사파리 12버전에서 Array.prototype.reverse() 버그가 발견됐다며 클리앙의 포스트를 공유해줬다.

https://www.clien.net/service/board/news/12614248?po=0&od=T31&sk=&sv=&category=&groupCd=&articlePeriod=default&pt=0

배열을 선언하고 reverse()를 호출한 후에, 페이지를 새로고침 했을 때 해당 변수의 배열이 reverse() 된 체 남아있는 버그다.

에이 설마. 이런 빅버그가...

해결책:

오잉잉. 버그가 맞다.

클리앙 글에 참조되어 있는 스택오버플로우 글에서 폴리필 코드도 제시해주고 있다.

https://stackoverflow.com/questions/52390368/array-state-will-be-cached-in-ios-12-safari-is-it-a-bug-or-feature/52392901#52392901

서비스에도 적용해야 할까 해서 좀 더 살펴봤다.

- 아래 테스트 URL에서 '문제 있음'이 뜨면 버그가 발생하는 것이다.

- 테스트 URL (A) : http://output.jsbin.com/yecixixuma/1

- iOS 크롬이나 인앱 브라우저에서도 모두 발생한다.

- iOS12 사파리 버전에서 배열 reverse() 시 복사본을 생성하지 않는 게 원인인 것 같은데... 정확한 원인은 모르겠다.

C와 얘기하면서 아무래도 사파리의 최적화와 관계가 있지 않을까 생각했다.

- 다만, 배열을 선언한 후 동적으로 배열을 변경하는 경우엔 발생하지 않는 문제다.

- 문제가 발생했던 환경에서도 아래 URL은 정상적으로 동작할 것이다.

- 테스트 URL (B): http://output.jsbin.com/linefufuse/1

- 우리 서비스에서는 모든 케이스에서 배열을 동적으로 할당하기 때문에 적용하지 않기로 했다.

논의:

버그 여부를 확인하는 (A)와 (B)의 테스트 코드는 각각 아래와 같다.

(A)

window.addEventListener('load', function () {

function buggy() {

var a = [1, 2];

return String(a) === String(a.reverse());

}

alert(buggy() ? '문제 있음' : '괜찮음');

});

(B)

window.addEventListener('load', function () {

function buggy() {

var a = [];

a.push(1);

a.push(2);

return String(a) === String(a.reverse());

}

alert(buggy() ? '문제 있음' : '괜찮음');

});

객체에 프로퍼티 설정 시 성능 이슈

ohgyun — Thu, 20 Sep 2018 15:06:21 +0900

발생일: 2018.09.19

키워드: json, object, Map

문제:

배치 작업에서 약 천만 행의 데이터를 로드에 객체의 프로퍼티로 할당하는 작업을 진행하고 있었다.

대략 다음과 같이 DB에서 데이터를 읽어와 메모리에 할당하는 간단한 작업이다.

readFromDatabase().then((result) => {

const map = {};

const list = [];

result.forEach((item) => {

map[item.id] = item.value; // (A)

list.push(item); // (B)

});

헌데, 특정 시점(문제가 발생했던 데이터의 경우 약 700만 라인 즈음)부터 (A) 부분의 작업이 1초 이상 걸린다.

하지만 배열에 추가하는 (B) 코드는 아무 문제가 없었다.

단순히 맵에 할당하는 건데... 왜 이렇게 느려지는 걸까?

해결책:

건너자리 J에게 이 문제에 대해 얘기했더니, 네이티브 Map 객체를 쓰면 어떠냐고 한다.

V8에선 객체의 형태가 달라질 때 최적화 작업을 하는데, 이 비용이 꽤 크다고 알고 있다고 한다.

문제가 됐던 코드는 아래와 같이 변경했다.

readFromDatabase().then((result) => {

const map = new Map();

const list = [];

result.forEach((item) => {

map.set(item.id, item.value);

list.push(item);

});

만세! 잘 된다! ㅎㅎㅎ

논의:

위 문제를 재현하고 싶다면 아래 코드를 실행하면 된다. (테스트 환경의 node는 10.10 버전)

const map = {};

let i = 0;

for (; i < 10000000; i++) {

const key = 'key_' + i; // (A)

map[key] = i;

if (i > 8388600) {

console.log(key, process.memoryUsage().heapTotal);

}

if (i === 8388610) {

break;

}

결과는 다음과 같다.

내 맥에선 8,388,605번째부터 느리게 할당됐고, 실제로 이 시점부터 프로퍼티를 한 번 설정할 때마다 메모리가 크게 (무려 64MB 씩) 늘어났다.

참고로, (A) 부분의 key 값을 숫자인 i로 할당하면 전혀 느리지 않고, 메모리가 크게 증가하는 현상도 없다.

정확한 원인이 뭘까 찾아봤는데, 아래 포스팅에서 언급한 내용과 관련이 있지 않을까 싶다.

https://v8project.blogspot.com/2017/08/fast-properties.html

살짝 정리해보면 다음과 같다. (편의 상 영어는 발음되는 대로 표기했다)

자바스크립트 객체는 메모리 내에서 아래 그림과 같이 표현된다.

배열이나 키가 숫자인 객체는 엘리먼트(Elements)로, 키가 문자열인 객체는 네임드 프로퍼티(Named Properties)로 저장된다.

엘리먼트는 엘리먼트 스토어(elements store)에, 네임드 프로퍼티는 프로퍼티 스토어(properties store)에 저장된다.

V8의 모든 자바스크립트 객체는 객체의 형태에 대한 정보가 있는 히든 클래스(HiddenClass)를 갖고 있다.

히든 클래스에는, 프로퍼티의 이름과 인덱스에 대한 정보, 프로퍼티의 개수, 객체 프로토타입의 참조 등이 있다.

자바스크립트와 같은 프토토타입 기반의 언어는 객체의 타입을 미리 알 수 없기 때문에, V8은 객체가 업데이트 될 때마다 히든 클래스의 정보를 업데이트한다.

히든 클래스는 객체의 형태에 대한 식별자 역할을 하고, 인라인 캐시나 컴파일러 최적화에 아주 중요한 요소로 사용된다.

V8은 객체에 새 프로퍼티가 생성될 때마다 히든 클래스를 생성한다.

프로퍼티의 구조와 추가된 순서가 같다면, 객체의 히든 클래스도 동일하다. V8에서도 동일한 구조일 땐 객체간 히든 클래스를 공유한다.

동일한 구조이더라도 순서가 다를 땐, 별도의 히든 클래스가 새로 생성된다.

참고로, { a: 1, b: 2 } 같이 네임트 프로퍼티를 가진 객체는, 외부에서 보기엔 딕셔너리 같지만 V8에선 인라인 캐시나 최적화를 위해 딕셔너리처럼 사용하지 않는다.

네임드 프로퍼티에는 3가지 타입이 있다.

In-object, Fast, Slow/dictionary

- In-object 타입은 V8에서 사용할 수 있는 가장 빠른 프로퍼티로, 미리 지정된 개수만큼 객체에 '직접' 할당된다.

허용된 개수보다 더 많은 프로퍼티가 저장되면, 별도의 프로퍼티 스토어에 저장된다.

프로퍼티 스토어는 한 단계 간접 참조가 있지만, 개별적으로 확장될 수 있다.

- Fast 타입은 프로퍼티 스토어에 있고, 모든 메타 정보가 히든 클래스의 디스크립터 배열(discriptor array)에 저장된다.

일반적으로 선형 프로퍼티 스토어(linear properties store)에 저장된 프로퍼티를 빠르다고 정의한다.

Fast 프로퍼티는 프로퍼티 저장소의 인덱스를 사용해 간단히 액세스할 수 있다. 프로퍼티 이름으로 프로퍼티 저장소의 실제 위치로 이동하려면 히든 클래스의 디스크립터 배열을 참조해야 한다.

- Slow 타입은 히든 클래스 외부의 자체(self-contained) 프로퍼티 사전을 갖는다. 메타 정보는 더이상 히든 클래스에 저장되지 않는다.

만약 객체에 많은 프로퍼티가 추가되거나 삭제되면, 디스크립터 배열과 히든 클래스를 유지하기 위해 많은 시간과 메모리가 필요하다. V8이 slow 프로퍼티를 지원하는 이유이다.

Slow 프로퍼티는 개별적으로 메타 정보를 저장하는 사전을 갖지 때문에, 객체를 추가하거나 삭제할 때 히든 클래스가 업데이트 되지 않으며 인라인 캐시에서도 일반적으로 빠른 프로퍼티보다 느리다.

즉, slow 프로퍼티는 객체의 추가/삭제는 빠르지만 다른 프로퍼티에 비해 접근이 느리다.

----

https://stackoverflow.com/questions/43594092/slow-delete-of-object-properties-in-js-in-v8

위 문제랑 좀 다르긴 한데, 비슷하게 객체 삭제가 특정 시점부터 느려진다는 글도 있다.

V8 개발자의 답변으로는 flat array 형태로 되어 있던 메타 정보를 사전 형태로 바꿀지 여부를 확인하는 과정에서 발생하는 known issue란다.

위 문제랑은 조금 다른 문제이긴 하다.

----

글쎄... 정확한 원인이 뭔진 잘 모르겠다.

어쨌든, 느려지는 이유는 메모리의 급격한 상승 때문인 것 같다.

첫 번째 블로그 글을 읽고, Fast 프로퍼티가 Slow 프로퍼티로 전환되는 과정에서 그런 걸까하고 생각했는데, 느려도 너무 느려서..ㅠㅠ

여튼, 이런 케이스엔 Map()을 사용하자.

Charlse Proxy iOS의 프록시 자동 옵션으로 연결하기

ohgyun — Fri, 27 Jul 2018 14:54:25 +0900

발생일: 2018.07.27

키워드: Chalse Proxy, iOS, proxy, 찰스 프록시, iOS proxy auto configuration

문제:

맥에서 HTTP 프록싱 도구로 찰스 프록시를 사용하고 있다.

패킷 디버깅이 필요할 때마다 와이파이 설정에서 프록시를 수동으로 연결하고 있는데 귀찮고 번거롭다.

자동으로 연결할 수 없을까?

해결책:

iOS는 프록시 설정에 자동 옵션이 있다.

프록시를 설정할 때 수동으로 설정해서 IP와 포트를 지정하는 대신, 자동 옵션을 선택한다.

설정 > Wi-Fi > 프록시 구성 > 자동

URL을 입력칸에 아래와 같은 형태의 주소를 넣는다.

https://chls.pro/X.X.X.X:XXXX.pac

X.X.X.X:XXXX 는 본인 아이피:포트이다. (예: 192.168.1.92:55555)

이렇게 설정해두면, 찰스가 켜져있을 땐 프록시로 동작하고 꺼진 경우엔 기본으로 동작한다.

편하다!

논의:

프록시 설정에서 SOCKS 모드를 설정해두고 SOCKS 모드로 연결하면, 프록시가 연결된 상태에서도 HTTP2 스펙으로 연결할 수 있다.

Proxy Setting 메뉴에서 아래와 같이 SOCKS 모드를 켜고,

iOS의 프록시 > 자동 > https://chls.pro/X.X.X.X:XXXX.socks.pac 으로 연결하면 된다.

# 2019.07.18 추가

iOS 앱에서 SSL 접속이 안되는 문제

iOS에서 찰스 인증서를 설치해도 브라우저에서는 SSL 접속이 되는데 앱에서는 안된다면, 인증서가 루트 권한에 적용되어 있는지 확인해보면 된다.

아이폰 설정 > 일반 > 정보 > 인증서 신뢰 설정 메뉴에서 찰스 인증서의 루트 인증서 전체 신뢰 활성화를 켜주면 된다.

참고:

https://www.charlesproxy.com/documentation/configuration/proxy-settings/

Node.js: 스트림의 'drain' 이벤트

ohgyun — Sat, 5 Aug 2017 12:57:32 +0900

발생일: 2017.01.09

키워드: Readline, WriteStream, ReadStream, highWaterMark

문제:

한 행에 JSON 포맷의 데이터를 포함한 파일을 CSV 파일로 변환하려고 한다.

파일 사이즈가 커서 readline을 사용해 스트림으로 읽어 변환 후 다시 스트림으로 쓸 생각이다.

WriteStream에 'drain' 이벤트가 있던데, 정확히 어떤 이벤트일까?

해결책:

highWaterMark(내부 버퍼에 저장할 최대 바이트)에 지정한 값보다 큰 버퍼를 쓰려고 할 땐, write()가 false를 리턴한다.

스트림이 빠져나가는 동안 write()를 호출하면, 청크가 버퍼링되고 false가 리턴된다.

현재 버퍼링된 모든 청크가 빠져나가면 'drain' 이벤트가 발생한다.

write()가 false를 리턴했을 땐, drain 이벤트가 발생하기 전까지 write()를 호출하지 않는 것이 좋다.

스트림이 빠져나가지 않은 상태에서 write()가 계속 발생되면, node.js는 최대 메모리 에러가 발생할 때까지 쓰려는 데이터를 모두 버퍼링하기 때문이다.

이렇게 되면 불필요하게 GC가 동작할 수 있고, 심지어 메모리가 다시 반환되지 않는 문제가 발생할 가능성도 있다고 한다.

아래는 변환하는 코드의 일부이다.

function convertToCsvFile(options) {

const deferred = Q.defer();

const inputFilePath = options.inputFilePath;

const outputFilePath = options.outputFilePath || (inputFilePath + '.csv');

const headers = options.headers;

const keyNames = options.keyNames || [];

const filter = options.filter;

const transform = options.transform;

if (!inputFilePath) {

return Q.rejecct('inputFilePath는 필수 값입니다');

}

const ws = fs.createWriteStream(outputFilePath, {

flags: 'w',

defaultEncoding: 'utf8'

});

ws.on('open', () => {

if (headers) {

ws.write(headers.join(',') + '\n');

}

const rl = readline.createInterface({

input: fs.createReadStream(inputFilePath)

});

rl.on('line', (line) => {

let data = JSON.parse(line);

if (!_.isFunction(filter) || filter(data)) { // 필터가 정의되어 있다면 사용한다.

if (_.isFunction(transform)) {

data = transform(data);

}

_writeToStream(ws, data, keyNames);

}

});

rl.on('close', () => {

ws.end();

});

ws.on('finish', () => {

ws.close();

});

ws.on('close', () => {

deferred.resolve(outputFilePath);

});

return deferred.promise;

}

function _writeToStream(ws, data, keyNames) {

const values = [];

let shouldDrain = false;

_.each(keyNames, (keyName) => {

let value;

try {

value = _getValueByKeyName(data, keyName);

} catch (e) {

console.error('값을 가져오는데 실패했습니다');

console.log('Data:', data);

console.log('Key Name:', keyName);

throw e;

}

values.push(value);

});

shouldDrain = ws.write(values.join(',') + '\n') === false;

if (shouldDrain) {

ws.once('drain', () => {

_writeToStream(ws, data, keyNames);

});

}

참고:

http://stackoverflow.com/questions/35532332/how-does-readline-rl-write-work

ML: MS의 Matchbox Recommender 이해하기

ohgyun — Fri, 28 Jul 2017 09:58:27 +0900

발생일: 2017.01.07

키워드: Microsoft Matchbox Recommender, Matchbox Recommendation, Recommendation system, 마이크로소프트 매치박스, Azure Machine Learning Studio, 애저 머신러닝 스튜디오, 매치박스 알고리즘, 추천 알고리즘

문제:

Matchbox Recommender는 MS Azure의 머신러닝 스튜디오에서 제공하는 추천 시스템이다.

이번에 MS의 제품을 활용해 추천 시스템을 구축하기 전에 정리한 내용이다.

해결책:

추천 시스템은 한 개 이상의 아이템이나 유저를 추천해주는 시스템.

두 가지 접근 방식이 있다.

하나는 content-based, 다른 하나는 collaborative filtering

content-based:

- 유저와 아이템의 피처를 기반으로 추천한다

collaborative filtering:

- 모든 유저와 아이템의 점수를 매트릭스로 만든 데이터를 기반으로 한다

Matchbox recommender는 두 가지 방식을 모두 사용하는 하이브리드 리커멘더이다.

신규 사용자처럼 히스토리가 없는 경우, 아이템과 유저의 피처에 기반에 추천하는 방식으로 콜드 스타트 이슈를 해결할 수 있다.

시간이 지나 히스토리가 쌓이면 content-based 에서 collaborative filtering 방식으로 자연스럽게 전환할 수 있는 알고리즘이다.

Predict Ratings

- user features 와 item features를 옵션으로 추가할 수 있다.

- 하지만, 이미 평가했던 사용자나, 이미 평가되었던 아이템의 피처들은 스코어를 매길 때는 사용되지 않는다. 이 피처들은 콜드 스타트 사용자와 아이템을 위한 것이기 때문이다.

- user-item-rating 데이터를 응답한다

Recommend Items

- 사용자에게 1개 이상의 아이템을 추천한다.

- Recommend item selection

- From rated items: 개발 단계에서 모델 평가용으로 사용한다. 평가할 때 이미 평가가 됐던 아이템들을 대상으로 추천한다

- From all items: 웹 서비스나 프로덕션에서 사용할 때 선택한다.

- Dataset to score

- From all items 라면 컬럼 한 개만 넣어야 한다. 사용자 아이디다.

- From rated items 라면, user-item 페어 데이터를 전달한다.

- 유저와 사용자의 피처 데이터는 동일한 방법으로 사용된다.

- Maxium number of items to recommend to a user: 추천할 아이템의 최대 개수

- Minimum size of the recommendation pool per user: 평가 단계에서, 최소 몇 개 이상 평가했던 사용자들 대상으로 할 것인지 여부

- user, item1, item2, ..., itemn 컬럼을 응답한다

- item1이 가장 연관성이 높은 데이터이다.

Find Related User

- 비슷한 사용자를 추천하는 모듈이다. "people like you"에 대한 추천이다.

- Recommender prediction kind 를 Related users 로 선택

- From all users, from users that rated items 는 동일한 방법으로 동작

- 인풋으로는 user 아이디 하나만 받는다. 평가용이라면 user-item 페어 데이터를 받는다.

- 비슷한 사용자 아이디를 응답한다.

Predict related items

- 아이템 아이디를 받아 연관된 아이템을 추천한다.

- 인풋으로 item 아이디를 넘긴다. 평가용이라면 user-item 페어를 넘긴다.

- 연관된 아이템 아이디를 반환한다.

신규 유저에 대한 추천

- 아이디가 없을 수도 있고, 평가 히스토리도 없을 것이다.

- 이 때엔 사용자 피처로 추천한다.

- 인풋은 트레이닝에 사용되지 않았던 아이디를 넘긴다. 단, 사용자 피처 데이터가 있어야 한다.

- 만약 협업 필터링을 위한 데이터가 없다면(유저 피처), classification 이나 regression 알고리즘을 사용하는 것이 낫다.

사용자가 이미 봤던 것을 제외하고 싶다면, 요청을 여러 번 보낸 후에 직접 필터링해서 사용하면 된다.

현재는 온라인 업데이트는 제공하지 않는다.

증가분을 추가로 트레이닝하는 건 불가능하다. 전체를 다시 트레이닝 해야한다.

참고:

Documentation: https://msdn.microsoft.com/en-us/library/azure/dn905970.aspx

Matchbox Recommender 논문: http://www2009.eprints.org/12/1/p111.pdf