구글 프로토콜 버퍼 (Protocol Buffer)

 

개요

  1. <프토토콜 버퍼>는 랭귀지 중립적, 플랫폼 중립적인 데이터 시리얼라이즈 포맷

    • 서로 다른 종류의 머신, 서로 다른 종류의 플랫폼에서 동일한 의미를 갖도록 데이터의 포맷을 정의한다는 점에서 <프로토콜 버퍼>라는 이름은 (구글의 저질 작명 센스를 고려할 때, 의외로) 적절
      --> 프로토콜(통신)을 위한 버퍼(데이터)
  2. <프로토콜 버퍼>는 이제 구글의 데이터 공용어 (gRPC의 디폴트 데이터 포맷)

    • What is gRPC?
      . 구글이 정의한 RPC
      . 구글의 최신 API는 이제 REST API 뿐 아니라 gRPC API도 함께 제공함
      . gRPC는 <프로토콜 버퍼>를 기본 데이터 시리얼라이즈 포맷으로 사용
        (but, JSON 등 다른 포맷도 사용 가능)
      . 다양한 랭귀지 지원: C++, Java, Python, Go, Ruby, C#, Node.js, PHP, ...
  3. JSON을 <프로토콜 버퍼>로 <프로토콜 버퍼>를 JSON으로 변환 가능

  4. XML보다 작고, 빠르고, 간단

 

XML 대비 <프로토콜 버퍼>의 장단점

  1. XML 대비 장점

    • 더 간단함
    • 더 작음: 3배~10배
    • 더 빠름: 20~100배
    • 더 명료함
    • 컴파일러 등 도구를 제공함
  2. XML 대비 단점

    • 본질적으로 바이너리 포맷
      . HTML과의 호환성이 약함
      . human readable 특성이 약함
    • 데이터 포맷을 완전히 파악하려면 .proto 파일이 필요
      . XML은 어느 정도는 자기 완결성을 가짐

 

proto 파일

  1. <프로토콜 버퍼>의 데이터 포맷을 정의하는 소스파일

  2. proto 파일 고유의 문법 존재

  3. proto 파일 안에서 다른 proto 파일 참조 가능

  4. proto 파일을 컴파일하면 각 랭귀지별 라이브러리가 생성됨

    • 지원 랭귀지
      . proto2: C++, Java, Python, Go
      . proto3: C++, Java, Python, Go, Ruby, Objective-C, C#, JavaScript

 

Ref.


Posted by ingee

댓글을 달아 주세요

Dockerfile 베스트 프랙티스

https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices


* 컨테이너는 쉽게 죽고 살 수 있어야 한다 (Containers should be ephemeral )
  수시로 파괴되고 생성되어도 정상 동작해야 한다


* .dockerignore 파일을 활용하라 (Use a .dockerignore file)
  - docker build 디렉토리에 파일이 많아지면 안좋다
    . build 된 이미지가 커진다
    . biuld 작업이 느려진다
  - .dockerignore 파일로 관련 없는 파일들을 무시하게 하라


* 컨테이너의 목적을 (하나만) 분명히 하라 (Each container should have only one concern)
  - 하나의 어플리케이션을 여러개의 컨테이너로 나누는 편이
    <horizontal-scaling>과 <컨테이너-이미지 재활용> 측면에서 좋다


* layer 수를 줄여라 (Minimize the number of layers)
  - 이미지의 레이어 수를 줄이는 것이 좋다
  - RUN, COPY, ADD 명령이 레이어를 만든다


* Dockerfile 명령어 관련 조언
  - FROM
    . 항상 공식 이미지를 base 이미지로 사용하라


  - RUN
    . apt-get update와 apt-get install은 항상 한줄로 묶어 사용하라
    . apt-get install 시 패키지의 버전을 명시하면 잠재적인 오류를 줄일 수 있다
    . RUN 명령 모범 사례
      RUN apt-get update && apt-get install -y \
        aufs-tools \
        automake \
        build-essential \
        curl \
        dpkg-sig \
        libcap-dev \
        libsqlite3-dev \
        mercurial \
        reprepro \
        ruby1.9.1 \
        ruby1.9.1-dev \
        s3cmd=1.1.* \
        && rm -rf /var/lib/apt/lists/*


  - EXPOSE
    . 전통적인 포트 사용을 권한다
      예를 들어, 아파치 웹서버는 EXPOSE 80,
      MongoDB는 EXPOSE 27017


  - ADD or COPY
    . ADD 보다 COPY 를 권한다 (더 단순하다/직관적이다)
    . 여러 파일들을 한꺼번에 COPY 하는 것보다 파일별로 COPY 하는 것을 권한다
      그러면, 어떤 파일이 바뀌었을 때 캐시-이미지를 활용할 가능성이 커진다


(이상)

Posted by ingee
TAG docker

댓글을 달아 주세요

Mesos 101 (Mesos 첫걸음)

Ops 2017.07.04 18:24

Mesos 101 (Mesos 첫걸음)


개요

Mesos를 이용, 서버 클러스터를 운용해야 하는 상황이 되었다. Mesos 설치/운영 방법을 찾아야했는데, 정말 좋은 자료를 발견했다.

Mesos Advanced Course
https://open.mesosphere.com/advanced-course/
이름은 "Advanced Course" 이지만, Mesos 설치부터 운영까지 꼭 필요한 내용만 "쉽게" 설명한다. 동영상을 보며 따라 배우기도 좋고, 글로 요약된 내용을 뒤적이며 매뉴얼로 쓰기도 좋다.
열심히 집중하면 하루에 모든 진도를 끝내는 것도 가능할 것 같다.

특이했던 점

* ZooKeeper가 (의외로) 필수 컴포넌트
  . ZooKeeper는 HA 보장을 위한 optional 요소라고 생각했는데, 필수였다
  . ZooKeeper가 HA 보장 뿐 아니라 클러스터의 상태를 저장/관리 기능도 제공했다
  . 그래서 Mesos Master를 1개만 두는 구성에서도 ZooKeeper가 필요했다

* docker containerizer가 아닌 mesos containerizer가 디폴트
  . Mesos가 클러스터 위에서 실행시키는 모든 어플리케이션은 컨테이너다
  . 그런데 역사적으로 Mesos는 Docker보다 오래됐다
  . 그래서 Mesos의 디폴트 containerizer는 docker가 아니라 mesos containerizer 다
  . Mesos containerizer는 도커 이미지도(!) 실행시킬 수 있다


(이상)

Posted by ingee
TAG mesos

댓글을 달아 주세요