책 읽어주는 딥러닝

https://www.slideshare.net/carpedm20/deview-2017-80824162

  • Data
    1.  한국어 음성 데이터는 공개된 데이터가 없어서 직접 만들어야 한다.
    2. Google Speech API, Text Similarity를 통해 자동화

  • Model : Tacotron, Deep voice 2
    • Tacotron
      1. Encoder -
        1. Character Embeddings : 해당 텍스트를 가장 잘 나타내는 숫자를 생성
      2. Decoder -
        1. 음성을 생성 할 수 있는 스팩트로그램을 생성
        2. 스팩트로그램 : 음성이 되기 직전의 숫자
        3. Attention
      3. Vocoder - 스팩트로그램을 음성으로 변환
        1. Griffin-Lim : 스팩트로그램을 음성으로 만들어주는 알고리즘
      4. Attention -
          1. 텍스트의 어디에 집중할 것인가를 계산,
          2. 스팩트그램을 만드는 RNN에 Atteintion을 전달
          3. Attention의 중요성 :일반화
          4.  학습하지 않았던 문장도 얼마나 잘 말할 수 있는가?

Tacotron : Enbedding, Bidirectinal RNN

    • Deep Voice 2
    1. Multi Speaker Tacotron : 여러 목소리를 트레이닝 한다.
    2. Speaker Embedding
      1. 캐릭터 임베딩 뿐만 아니라 발화자를 잘 나타내는 숫자를 생성
    3. Multi Speaker Attention
      1. 어텐션을 임의의 어텐션으로 교체하여 커스터마이징 할 수 있다.

  • Code 



그런 REST API로 괜찮은가

http://slides.com/eungjun/rest#/

  • 2000년에 REST에 대해 논문을 발표한 Roy T. Fielding가 현재 대부분의 REST API는 제약 조건을 따르지 않는다고 한다.

  • REST API : REST 아키텍쳐 스타일을 따르는 API
    • REST를 구성하는 스타일 
      • client-server
      • stateless
      • cache
      • uniform interface
      • layered system
      • code-on-demand (optional)

  • REST API의 제약 조건은 현재 http를 통해서 대부분 만족한다. 다만 Uniform interface는 만족하지 못하는 경우가 많다.

  • uniform interface중에서 특히  Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
    • Self-descriptive - 메시지는 스스로에 대해 명세할 수 있어야한다. (헤더 / 미디터타입 등)
    • HATEOAS - 애플리케이션의 상태는 hyperlink에 의헤 명세되어야한다.

  • 독립적 진화
    • 서버와 클라이언트가 각각 독립적으로 진화한다
    • 서버의 기능이 변경되어도 클라이언트는 업데이트 할 필요가 없다.
    • 대표적인 예시 : 웹브라우저

  • 즉 REST API란 하이퍼텍스트를 포함한 self-descriptive한 메시지의 uniform interface를 통해 리소스에 접근하는 API.

  • Self-descriptive를 지키는 방법
    1. 미디어타입 정의
    2. Profile
  • HATEOAS
    1. data로 링크 등 다음 상태를 전달한다.
    2. HTTP 헤더를 통해 상태를 전달한다.

오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.

https://www.slideshare.net/deview/135-80845610

  • MySQL의 Replication을 통한 데이터 이중화 
    • Async Replication 
      • master의 데이터를 async로 slave에 replication한다. (mysql의 replication은 async로 동작한다.)
      • 비동기 replication 으로 master 장애시 데이터 유실 위험이 있다.

  • Lossless Replication 
    • slave 어딘가에 반드시 변경 이력이 남아있다.
    • Binary log를 전 slave에 전송, 단 하나의 slave에서라도 ack가 온다면 storage commit. 
    • slave중 최소 하나는 로그를 가지고있다
    • master 장애 시 slave중 어딘가에 있을 로그를 통해 데이터를 복구한다.

  • MHA (Master High Availability)
    • 30초 이내로 데이터 유실 없이 복구
    • 3초마다 DB 헬스체크, 3회 실패시 장애 인지후 페일오버.
    • Lossless Replication을 통한 relay log로 데이터 복구.
  • Domain Failover 
    • VIP failover가 아닌 Domain Failover를 채택.
    • 서비스 도메인(master) 장애시 slave로 DNS를 설정하여 장애 대응.
    • 서비스 도메인의 TTL은 0로 설정한다.
    • DNS는 캐싱하지 않는다.
    • 서비스는 커넥션풀로 동작한다.

  • Scale-out
    • 데이터 특성에 따라 파티셔닝.
    • static : 데이터 변경이 거의 없는 static 데이터는 캐시를 이용한다.
    • dynamic, historical : 변경이 잦은 사용자 데이터 혹은 로그 데이터는 DB를 통해 확장한다.
      • SERVICE : innoDB only, Range Partitoning한다.
      • ARCHIVE : 장기보관 데이터, tokuDB에  Range Partitoning한다.
    • tokuDB ? : http://gywn.net/2014/05/fractal-index-in-tokudb/
      • Fractal Index : 피벗에 버퍼를 두어 IOPS를 줄임.




+ Recent posts