catpark's something new

slack을 쓰긴 쓰고 있지만....

사실 slack을 사용하고 있지만 협업툴로써 쓰기 보다는 메신저로 쓰고 있었다. 하지만 slack과 연동되는 많은 app의 기능은 단순 메신저로 사용하던 나를 slack API까지 보게 만들 정도로 매력이 넘친다. slack의 app directory를 가보면 category가 있는데 develop에 대한 app뿐만 아니라 finance, travel과 같은 app들과도 연동이 가능하다.

개발장이라 그런지 "project management"를 주목 하게 되었고 asana, trello, jira, gitlab등에 관심을 가지고 보게 되었다. 그 중에 MeisterTask는 유료긴 하지만 결제를 고민하게 될 정도로 괜찮아 보인다. 무료로도 사용 가능하지만 slack연동은 안되어서 일단 연동없이 무료로 써보고 포스팅도 할 계획이다.

왜 git과 slack을 연동하려고?

결론 부터 말하자면 처음 도입부에서 언급했던 것처럼 단순 메신저가 아닌 협업툴로 쓰기 위해서 첫단추를 "git연동"으로 잡았다. (그런데 쉽지 않는 주제를 잡아서 하고 나서 헥헥거리는 날 보게 됨...ㅠㅠ)

사실 github나 gitlab같은 서비스들은 연동이 쉽게 되긴한다. 서비스 자체에서 webhooks을 설정 해주는 것 같다. (물론 해보지 않고 블로그만 보고 얘기 하는 것임.) 하지만 불행하게도 git 형상관리 시스템은 다른 팀에서 관리 하고 있어서 gitlab을 설치 하는 그런 생각은 일찌감치 접었다. 대신 git의 hook를 써서 slack과 연동하기로 한다.

본격적인 slack 연동

먼저 slack page에서 자기의 workspace로 이동하면 위쪽에 Manage 탭을 클릭한다. 그럼 좌측에 Custom Integrations에 Incomming Webhooks가 보인다.

Incomming Webhooks를 클릭하면

Add Configuration을 클릭하면

특정 채널로 noti.하도록 설정하면

Configuration이 생긴다. edit버튼을 누르면

여러 내용들이 나오는데 제일 중요한것은 Webhook URL이다. 이 URL로 호출을 해줘야 해당 configuration이 동작하기 때문이다. 나머지 Setup Instructions나 Massage Attachments는 data structue와 richtext를 위한 내용이라고 보면 된다. 이러면 slack쪽 설정은 끝났다.

slack과 git 연동

지금까지는 slack에서 메세지를 받는 준비를 한 것이다. 이제 git에서 slack으로 메세지를 주도록 설정하면 된다. 그러기 위해서 나는 git push가 되었을 때를 기준으로 메세지를 보내려고 했다. 그래서 git hook을 사용하면 되는데 설명은 링크로 대체 한다. (GIT HOOK)

git hook은 크게 클라이언트 훅과 서버 훅으로 나뉘고 클라이언트 훅은 어떤 상황에서든 사용가능하나 서버 훅은 push의 전후로 사용된다는 특징이 있다. 당연하겠지만 서버 훅으로 설정되어야 어떤 push든 처리 가능하지 클라이언트 훅은 사용자별로 세팅되어야 전 인원이 적용되는 것이기 때문에 보통 서버 훅을 고려하지 않을까 생각 된다. server hook은 종류가 많지 않다. 그 중에 push후에 실행되는 post-receive를 사용했다.

먼저, remote git에 ssh로 접속해서 메세지를 보내고 싶은 repository의 hooks폴더로 이동한다. .sample로 끝나는 파일들은 git 설치하면 기본적으로 제공하는 sample들이다. 하지만 내가 쓰고자 하는 post-receive의 sample은 없었다... 지쟈스~ 결국 간단하지만 아래와 같이 shell을 만들었다!

#!/bin/bash

USER=$(whoami)
#GIT_LOG=$(git log --pretty=format:"commit:\t%H\nAuthor:\t%an\nDate:\t%ad\n%s" -1)
GIT_LOG=$(git log -1)
curl -X POST --data-urlencode "payload={\"channel\": \"#back-end\", \"username\": \"$USER\", \"icon_emoji\": \":bell:\", \
\"attachments\":[\
      {\
         \"fallback\":\"Please fix errors.\",\
         \"color\":\"good\",\
         \"fields\":[\
            {\
               \"title\":\"New Commit\",\
               \"value\":\"$GIT_LOG\",\
               \"short\":false\
            }\
         ]\
      }\
   ]}" https://hooks.slack.com/services/TAC434PG9/AAAAAAAA/BBBBBBBBBBBBBBBBBBBBBBBB

위치는 {remote git repository folder}/hooks/post-receive로 새로 만들었다. payload에 attachments는 richtext를 지원하는 slack api로 아래 갭쳐 처럼 보이게 한다.

attachments는 slack API로 꽤 많은 기능이 제공된다. API링크를 보고 입맛에 맞게 payload를 수정하면 될 것 같다. 쉬운줄 알았는데 4시간을 허비하니까 힘들어서 attachment는 이 정도만 하고 "이 정도면 됐어!"하고 셀프 위안 중이다.ㅋ

후기

이로써 slack을 메신저에서 협업툴로 조금은 업그레이드 된 것 같다. slack은 채널이라는 개념이 있어서 프로젝트별로(개발장이라 프로젝트임. 원래는 그룹방 개념이라 프로젝트 말고 다른 이미로도 쓰일 수있다.) 채널을 만들어서 그 프로젝트에 관련된 알림을 주고 받는게 핵심이라고 생각한다. 현재는 git을 연동 했지만 나중에는 jira나 meister task같은 management tool도 연동하면 굉장히 나이스 할 것 같다.

이글은 Quora에 올라온 “What’s the difference between sharding and partition?“글의 질문과 모자이크 CTO가 답변한 내용을 번역한 글입니다.

샤딩(sharding)과 파티셔닝(partitioning)의 차이가 무엇인가? 분산 데이터베이스 시스템에서 샤딩과 파티셔닝이라는 단어를 종종 듣는다. 하지만 그들의 차이점을 잘 모르겠다. 그래서 이것들을 위키에서 검색해보았지만 여전히 혼란스럽다. 약간의 예제를 줄 수 있을까?

Tony Bako, Mosaic의 CTO의 답변 파티셔닝이란 퍼포먼스(performance), 가용성(availability) 또는 정비용이성(maintainability)를 목적으로 당신의 논리적인 데이터 엘리먼트들을 다수의 엔티티(table)로 쪼개는 행위를 뜻하는 일반적인 용어이다.

샤딩은 수평 파티셔닝(horizontal partitioning)과 동일하다. 데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리한다. 예를 들면, 나는 고객의 데이터베이스를 CustomerId를 샤드키로 사용하여 샤딩하기로 하였다. 0 ~ 10000 번 고객의 정보는 하나의 샤드에 저장하고 10001 ~ 20000 번 고객의 정보는 다른 샤드에 저장하기로 하였다. DBA는 데이터 엑세스 패턴과 저장 공간 이슈(로드의 적절한 분산 , 데이터의 균등한 저장)를 고려하여 적절한 샤드키를 결정하게 된다.

Horizontal Partitioning

수직 파티셔닝(vertical partitioning)은 하나의 엔티티에 저장된 데이터들을 다수의 엔티티들로 분리하는것을 말한다. (마찬가지로 공간이나 퍼포먼스의 이유로) 예를 들면, 한 고객은 하나의 청구 주소를 가지고 있을 수 있다. 그러나 나는 데이터의 유연성을 위해 다른 데이터베이스로 정보를 이동하거나 보안의 이슈등을 이유로 CustomerId를 참조하도록 하고 청구 주소 정보를 다른 테이블로 분리할 수 있다.

Vertical Partitioning

요약하면 파티셔닝은 퍼포먼스, 가용성, 정비용이성등의 목적을 위해 논리적인 엔티티들을 다른 물리적인 엔티티들로 나누는것을 의미하는 일반적인 용어이다. 수평 파티셔닝 또는 샤딩은 스키마 복제 후 샤드키를 기준으로 데이터를 나누는것을 말한다. 수직 파티셔닝은 스키마를 나누고 데이터가 따라 옮겨가는것을 말한다.

• 출처 : http://theeye.pe.kr/archives/1917

AWS kinesis를 보다가 partitioning에 대해서 이해가 부족했다. data용량이 커지면서 성능 문제가 생기게 되는데 이 문제를 해결하는 방법 중 하나로 파티셔닝이라는 용어가 나왔고 이는 database관련 용어였다. 그래서 MongoDB를 기준으로 파티셔닝에 대해 찾아보다가 복제와 수평/수직 파티셔닝 개념과 함께 샤딩 개념도 알게 되었다. 결론적으로 샤딩은 수평 파티셔닝이다.

결국 크게 나누어 아래 두가지를 하고 싶어서 OAuth2.0(RFC 6749)를 사용합니다.

• 인증 (Authentication)
• 인증은 지금 접속한 client가 누구인지에 대한 내용입니다. web browser, mobile app, 심지어 device가 될 수도 있습니다.
• 권한 부여 (Authorization)
• client가 이용하려고 하는 resource(web server, DB, storage 등등)에 대한 권한(user, admin, operator등등)을 부여합니다.

• protocol flow

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+
authorization server와 resource server는 같은 서버일 수도 있습니다.

Access Token과 Refresh Token, authorization grant type등의 내용은 다음 글에서 자세히 다룰 예정입니다.

※ 참고하면 좋을 문헌

• https://jungle.kim/2018/04/21/oauth/