Wekan 리뷰

1줄 요약 : wekan은 쓰지말자

소개

Wekan은 오픈소스이자 무료SW인 칸반보드(kanban board) 어플리케이션이다

wekan 샘플

발음은 kanban의 kan인 "we khan"(위칸)이라고 한다
쓰면서 누군 위칸, 위캔 등등 말이 많았는데 github에 보니 명확하게 누가 설명해줬다
github.com/wekan/wekan/issues/259

Pronunciation of new name · Issue #259 · wekan/wekan

 

칸반(kanban)이란?

칸반(kanban)은 소프트웨어 개발 프로세스 중 하나인데,
휴먼 시스템 전반에서 작업을 관리하고 개선하기 위한 간결한 방법론이다

접근방식은 수요와 사용 가능한 용량의 균형을 맞추고
시스템 수준 병목 현상 처리를 개선하여 작업을 관리하는 것을 목표로 한다

작업 항목은 참가자에게 일반적으로 보드(kanban board)를 통해
처음부터 끝까지 진행 상황과 프로세스를 볼 수 있도록 시각화되며,

작업을 프로세스로 바로 진행되지 않고 참가자의 용량이 호용하는대로 작업을 가져와서 처리하는 방식이다

자세한 설명은 칸반 위키를 참고 : en.wikipedia.org/wiki/Kanban

Kanban - Wikipedia

 

칸반보드의 모습

원래는 큰 칠판에 아래와 같이 업무 내용이 담긴 포스트잇을 붙혀서 일감을 만들고
본인 업무가 끝나면 다음 포스트잇을 찾아 떼가는 식으로 업무처리를 했던게 최초의 칸반 방식이다

가내수공업 칸반보드

좌에서 우로 전체적인 업무 흐름(진행 중 -> 완료)을 볼 수 있고
위에서 아래로 우선순위(위가 우선 순위가 가장 높음)를 조정할 수 있다는게 큰 틀이다

그래서 전체적인 보드에
좌에서 우로 리스트(진행중, 리뷰, 완료)가 존재하고
리스트 안에는 업무 카드(포스트잇)가 들어있는 형태이다.

요즘 칸반보드에서는 카드 안에 설명, 체크리스트, 댓글 기능이 있어서 더 세부적으로 업무 관리가 가능하다

 

유명한 칸반보드

wekan에 대해서 소개하는 글이지만 일단 유사한 다른 SW를 보면,
일단 칸반보드에서 가장 유명한게 트렐로(Trello)이다

트렐로 예제

최근엔 태스크월드(Taskworld)라는 유료 서비스도 있다

링크 : blog.naver.com/PostView.nhn?blogId=taskworld&logNo=221105043565

태스크월드 활용 백서 (2) 콘텐츠 팀 편

그리고 보통 회사에서 많이 쓰는 JIRA에도 칸반보드 기능이 들어있다

링크 : www.atlassian.com/blog/jira-software/kanban-with-portfolio-for-jira

Portfolio for Jira meets kanban - Work Life by Atlassian

 

wekan을 쓰게된 이유

결론적으론 "회사에서 써야되서" 인데 wekan까지 오게된 이유를 설명을 해보자면,

1. 초기에는 유명한 트렐로를 사용했다
2. 보안 이슈가 있었다
   - 대충, 트렐로에 중요한 정보들을 올려도 되냐. 자료유출 문제가 없냐. 다른 유저가 볼 수 있지 않냐 등등
3. 원하는 환경인 vpn이나 특정IP대역에서만 특정보드를 접근할 수 없을까하고 찾아봤지만
   트렐로는 public web service라서 불가능했다
4. 특정 유저만 제한을 하기 위해서 SAML SSO를 연동하려고 했지만,
   sso 특성상 별도의 개발이 필요했고 결론적으로 2, 3번 문제가 해결이 안됐다
5. 결국 원하는 방식은 내부 서버에 직접 설치하여 직접 네트워크(방화벽)을 관리하는 수 밖에 없는데
   트렐로는 그걸 지원하지 않았다
6. 은근 비용이 크다 (trello.com/pricing)
   엔터프라이즈 1달에 1명당 $17.5
   1년동안 100명이 사용하면 2.1만 달러 = 한화 2300만원쯤
7. 그래서 오픈소스엔 이런게 없을까?로 접근하여 찾은게 wekan 이었다
   (물론 다른 오픈소스도 있다)

 

 

트렐로 가격

Sandstorm

일단 wekan을 설명하기 전에 sandstorm이란걸 알아야되는데,
sandstorm이란 self-hosting web app 오픈소스 플랫폼이다.

링크 : sandstorm.io/

Sandstorm

즉, 여러가지 기능을 하는 웹 어플리케이션 통합해주는 것이고
그 중 wekan을 지원해준다

sandstorm에서는 다음과 같은 어플리케이션을 제공해준다

• 채팅 : Rocket.Chat (rocket.chat)
• 파일 시스템 : Davros (github.com/mnutt/davros)
• Task & Project Management : Wekan
• Document Editing : etherpad-lite (github.com/ehter/etherpad-lite)

그래서 sandstorm을 사용한다면 4개의 시스템을 연동/통합시켜준다

 

물론 난 wekan만 필요해서 sandstorm을 쓰지 않았다

 

Wekan

그럼 wekan에 대해선 다시 파고들면,

개발프레임워크는
웹프레임워크는 meteor(nodejs) 사용했으며
DB는 mongo DB를 쓰고
프론트/백엔드 통신은 websocket을 사용한다

docker와 docker-compose를 지원해서 직접 빌드하지 않고 컨테이너로 쉽게 서비스가 가능하고

helm chart를 통해서 쉽게 kubernetes에서도 운영 가능하다
링크 : github.com/wekan/charts

wekan/charts

솔직히 여기까지보면 갓픈소스처럼 보인다
(트렐로 돈주고 쓰는 흑우 없지?)

하지만 여기서 사용하는 meteor프레임워크를 집고 넘어가자면...

 

Meteor

nodejs로 웹 개발했던 나도 meteor.js를 처음봤는데
생각보다 인기도가 높은 프레임워크라 놀랬다
(본인은 Express, Restify를 주로 사용했다)

전체 프레임워크 순위 링크 : hotframeworks.com/#rankings

Web framework rankings | HotFrameworks

13위에 meteor가 있다

(리액트는 이제 넘사벽이니 제외하고)

순위만 보면 Express와 Meteor가 거의 비슷한데 github의 별 갯수도 51.5k, 42.2k로 거의 비슷하다 

차이점은 Express는 웹프레임워크고 Meteor는 풀스택 프레임워크라는데

솔직히 MEAN(Mongo DB, Express JS, Angular, Node JS) 스택이 그렇게 유명했는데 Meteor가 비빌까 싶다

실제로 구글 트렌드도 비교해보면 엄청난 차이가 있다

링크 : trends.google.co.kr/trends/explore?q=%2Fm%2F0_v2szx,%2Fm%2F0t545zt

meteor의 발음이 미티어다

약간 아는 사람만 가는 맛집 같기도한데 궁금해서 더 찾아보니 

마침 두 프레임워크의 장단점을 비교해주는 사이트가 있었는데 매우 공감가는 내용을 볼 수 있었다

링크 : stackshare.io/stackups/expressjs-vs-meteor

wekan 글이니 meteor만 언급하자면 meteor 의 큰 단점이 바로 이 2개이다

• 매우매우 어려운 서버 디버깅
• CPU 사용량(무겁다)

솔직히 디버깅과 CPU 사용량에서 얼마나 차이가 크겠어?라고 생각했는데...

스포를 하자면 wekan을 못쓰는 이유 중 하나가 바로 저 2개 때문이다

규모있는 운영환경에서는 절대 사용할 수 없다!

 

Wekan의 문제점

솔직히 써봤던 오픈소스 중에 제일 최악이었는데 나열하면서 설정해보자면

 

1. 디버깅 & 로그 문제

위에서 언급된거처럼 뭔가 서버쪽에서 문제가 생기면 디버깅이 사실상 불가능하다

솔직하게 개발을 어떻게하는건지 모르겠는데,
웹서버가 시작됐다는 기본적인 로그만 있고
"카드가 생겼다", "유저가 가입했다"와 같은 로그는 아무것도 쌓이지가 않는다

만약에 특정 코드에서 어떤 문제가 발생하는지를 보고 싶다면, 해당 코드 부분에서 직접 로그를 찍는 코드를 넣어야된다

그리고 컨테이너 환경에서는 더욱 답이 없는게 로그 찍으려고 코드를 찾아갔는데 소스코드가 없었다
그래서 dockerfile를 보니 마지막에 코드 자체를 삭제해버린다

링크 : github.com/wekan/wekan/blob/master/Dockerfile

왜...? 왜 다 지워버리는거야???

물론 내가 직접 로컬에서 띄워서 개발툴에서 브레이크포인트 걸어서 해도 되긴하지만
문제는 meteor 자체가 cpu를 너무 과도하게 잡아먹어서
내 맥북 프로도 멈춰버릴 정도의 부하가 발생한다...

처음엔 내가 뭘 잘못 세팅해서 그런줄 알았는데 그냥 프레임워크 자체의 고질적인 문제였다

2. 소스코드 문제

이건 내가 Meteor를 잘 몰라서 그런걸 수도 있긴한데 코드를 보다보면 뜬금없는 클래스, 객체 등이 나타난다

내가 클라이언트 단에서 체크리스트를 추가할때 로그를 찍어보고 싶어서 클라이언트쪽 코드를 봤는데
뜬금없이 BlazeComponent가 나온다

BlazeComponent 이건 어디서 선언된거지??

이렇게 쓰는 프레임워크도 처음이고
이름을 보니 아마 리액트처럼 저게 컴포넌트이고 저 안에서 어떤 렌더링이 일어나는 것일텐데
그래서~! BlazeComponent는 어디서 나타난 거냐고요...
import가 안되있는데 클래스나 변수를 가져와서 쓴다

문제는 이런게 여기저기서 등장해서 진짜 툴 도움 없으면 코드를 따라가는게 불가능하다
아래는 보드에서 카드를 로딩하는 부분의 코드이다

링크 : github.com/wekan/wekan/blob/master/client/components/boards/boardBody.js

Cards를 어디서 가져오는거야...

그러다보니 발견한건데, 얼마나 관리가 안되면 find.sh란 스크립트로 파일을 찾는다

설명도 아래처럼 검색할때 다른 폴더를 무시하고 찾는 스크립트란다

Add find.sh bash script that ignores extra directories when searching.

링크 : github.com/wekan/wekan/blob/master/find.sh

 

3. 컨테이너가 아닌 직접 설치하는 방식

이것도 되게 특이했는데, 옛날에 cpp로 개발하던 느낌이라고 해야되나

npm을 쓴다고 되있는데 당연히 npm install && npm start하면 도는줄 알았는데

2번처럼 스크립트가 있다. 그것도 무려 sh/bat 파일 2가지로 말이다...

npm은 뭐에 쓰세요...?

눈치껏 rebuild-wekan -> start-wekan 으로 써야된다

근데 서버 종료 스크립트는 좀 무섭다

#!/bin/sh
pkill -f "node main.js"

재밌는건 여기서 쓰는 main.js 는 github에 없다

오르지 rebuild-wekan을 실행시켜야 쓸 수 있는 파일이다

난 여기까지보고 절대 meteor를 쓰지 말아야지란 삶의 목표가 생겼다

아니 뭔 이딴 프레임워크가 다 있어

 

4. 프론트 렌더링 이슈

위에서 언급했듯 이게 회사에서 쓰려고 했던거 였는데
약 1달간 wekan을 사용하다가 이 4번 이슈로 인해서 다른 플랫폼으로 넘어갔다

문제가 뭐냐면 보드 내에 카드&체크리스트가 많아지면 클라이언트도 멈추고
서버 단에서도 DB, 웹서버가 상시로 죽는다

그 중에 프론트 렌더링 이슈가 뭐냐면
카드별로 체크리스트를 아래 이미지처럼 보여주는데

전체 8개 체크리스트 중 3개를 했다는 것을 좌측 카드에서 3/8로 보여준다

이 체크리스트를 클라이언트(브라우저)에서 하나하나 세고 있어서
js 특성상 CPU연산을 계속하면 다른 처리가 안되고 이 CPU연산을 기다려야된다

난 이 연산이 DB나 백엔드에서 이뤄져서 느릴거라 생각했는데
wekan은 이런 자잘한 연산을 모두 프론트에서 처리하고 있다

그래서 이 카드 이미지를 그려주고 저 체크리스트를 갱신하면 모르겠는데
처음에 저 체크리스트를 모두 카운트하고 그 다음에 UI를 렌더링하다보니
유저 입장에서는 사이트가 멈춘걸로 보이고 서버에서는 이상이 없는걸로 보여지는 것이다

이때 1개 카드에 많으면 40~50개 체크리스트가 있고 보드 하나엔 카드가 20~30개 있어서 생각보다 부하가 컸었고
그렇다고 카드수가 적다고 로딩이 빠른것도 아니었다

더 열받는건 이 카드 렌더링을 끝내고 나서 해당 보드&카드에 유저가 누가 있는지, 내 정보는 어떤지를 나중에 가져오기 때문에 열심히 기다려서 카드가 보이지만 댓글, 카드 정보 수정을 할 수가 없는 상태가 된다

그리고 웃긴건 아카이브된 데이터도 로딩하고 카운트해서 더 고통받는다
이 내용은 github 이슈에도 존재한다
github.com/wekan/wekan/issues/2338

Performance optimization: Archived data loading · Issue #2338 · wekan/wekan

count와 관련된 로직은 여기 있다
이 코드를 프론트에서도 쓰기 때문에 map&reduce가 거의 상시로 일어난다
왜 상시로 일어나느냐... 그건 카드가 추가되거나 체크리스트에 변경이 생기면 무조건 이 함수가 실행되기 때문이다

관련 코드 링크 : github.com/wekan/wekan/blob/4396d7cfd5f4bceee807e5112d2a14c39dd077c1/models/cards.js#L595

wekan/wekan

더 슬픈건 전체 체크리스트 수를 세는것과 완료된 체크리스트를 세는게 분리되어 있다보니
카드별로 for문이 굳이 2번 돈다

알고리즘에서 빅오로 2n이 n이라고 하지만 엔지니어 입장에선 어쨌든 2개나 연산이 늘어난 셈이다

사실 Meteor 때문에 어디서든지 CPU가 100%문제가 발생하는데
어느 이슈를 가든 CPU 부하 관련된 이슈에서는 구체적으로 어디가 문제인지 알 수 없기 때문에
서버 문제에서도 이 내용이 언급된다
링크 : github.com/wekan/wekan/issues/3203

Abnormal CPU usage - wekan not responding · Issue #3203 · wekan/wekan

 

5. DB 관련

일단 wekan은 mongo DB를 쓴다

문제는 mongo DB는 잘못이 없는데 모델링이 nosql이 아닌 RDB처럼 설계가 되어있다

nosql의 장점은 하나의 테이블에 json으로 모두 때려박아서 쓸 수 있다는 장점이 있는데
wekan은 json으로 때려박고도 별도로 테이블을 관리한다

일단 모델을 그대로 보면 아래와 같이 카드, 유저, 체크리스트 등 개념별로 테이블을 다 나눠놨다

구체적인 문제점을 보기 위해 먼저 wekan의 계층 구조를 보면
board - swimlane - list - card - comment 순으로 계층 구조가 구성되어 있다
(하나의 board를 여러개 쪼개는 쓰는걸 swimlane이라고 한다)

default / test 2개로 swimlane을 구성한 모습

이제 cards 테이블에 document를 예제를 하나 보면 swimlaneId = ""으로 되어 있다
실제로는 위에처럼 board에 2개의 swimlane을 생성하고 카드를 생성한건데
cards의 document를 보면 값이 없다는 것이다

그럼 어떻게 해야되느냐? swimlanes 테이블에 가서 그 카드에 맞는 board/card id값으로 swimlane 값을 찾아야된다

이렇게 되다보니 mongo DB에 접근을 많이 해야되고
백엔드도 그에 따라서 연산량이 많아져서 결국 CPU 부하가 늘어난다

게다가 meteor도 CPU를 많이 먹는데 위에 렌더링 이슈로 인해 클라이언트도 CPU가 바쁘다

여기저기 문제가 많고 어디서 고쳐야될지도 감이 안온다

실제로 풀리퀘된 코드를 보면 다들 자신이 필요한 일부분만 고치고
다른 곳에 영향이 갈법한 사이드이펙트는 고려하지 않는 경우가 많다

그건 니 생각 아니야? 라고 한다면 다음 6번을 보자

 

6. 이슈 관리(+성능관련)

나는 이게 결정적이라고 본다

일단 현재 이슈 수를 보면 590개로 오픈소스치고 이슈가 많다
(고정된 이슈를 보면 현재 CPU관련된 성능이슈가 아직 남아있다)

wekan issue

사용하고 있는 프레임워크인 meteor랑 비교해보면 이슈만 5배 차이난다
closed된 수도 거의 4배정도 차이가 있다

meteor issue

난 위에서 언급한 4, 5번을 해결하기 위해서 이슈를 많이 찾아봤는데 
해결된 이슈 중에서 이런걸 볼 수 있었다

링크 : github.com/wekan/wekan/issues/1600

Client-side page loads freeze-up browsers · Issue #1600 · wekan/wekan

어떤 사람이 클라이언트에서 프리징 현상이 있다고 이슈를 올렸다
그것도 매우 디테일하게, 엄청 고사양 장비에서 테스트한 결과를 보여줬다

12코어 24기가 장비라니...

하지만 이 이슈는 18년 4월 20일에 생성되었고 19년 7월 25일에 되서야 해결됐는데
어떻게 해결했느냐...

허... 참....

마스터 브랜치에 새로 올라온 docker-compose로 해보신분 있나요?
여전히 이슈가 발생하면 댓글이나 다시 오픈해주세요
-끝-

찾아보면 이런식으로 닫힌 이슈가 매우 많은걸 볼 수 있다

정말 몰라서 저렇게 닫았을거라곤 생각이 들지가 않는게
아직도 같은 문제가 발생하고 같이 문제로 이슈가 생기고 있는데
이슈들은 closed되고 있다

단순히 perfomance로 검색했을때 나오는 이슈만 54개고 46개는 의미 없이 닫혔다

풀리퀘로 처리된게 아니고 임의로 closed되었다

이거에 대해서 더 이상 언급할 필요가 없는듯하다...

 

AWS에도...?

그리고 AWS marketplace에도 wekan이 올라와 있다

링크 : aws.amazon.com/marketplace/pp/Intuz-Wekan-Powered-by-Intuz/B075GVTJGK

AWS Marketplace: Wekan Powered by Intuz

대충 EC2에 wekan를 설치한 이미지(AMI)를 쓸 수 있게 해주고 EC2 비용 + 라이센스 비용을 받아가는거다

인스턴스 타입마다 다르긴 한데 시간당 $0.02가 라이센스 비용으로 추가된다

한번 써봤는데 HA구성이 되는 것도 아니고 EC2 하나에 DB와 웹서버가 모두 돌아가기 때문에
컴퓨팅 리소스 분리가 전혀 안된다

 

결론

여기까지가 내가 wekan을 도입하면서 겪게된 지옥이었다...

겉으로 좋아보이네하고 무작정 도입했다가 피를 본 케이스인데

겨우 200명도 못버티는 오픈소스일지는 상상도 못했다...

심지어 이때 사용했던 장비는 rancher로 구축된 kubernetes 였는데
웹서버만 4코어 32기가짜리 pod을 20개를 띄웠는데도 버티지 못했다

96코어에 128기가짜리 베어메탈 장비도 비슷한 상황이었고
찾다보니 DB, 백엔드, 프론트가 다 난리인걸 알 수 있었다

역시 트렐로나 JIRA가 괜히 비싼게 아니란걸 알 수 있었다

물론 wekan을 대체하기 위한 다른걸 도입했는데 그건 나중에 천천히 리뷰하는걸로... ㅎㅎ

 

Wekan 관련 링크

• 공식홈 : wekan.github.io
• 소스코드 : github.com/wekan/wekan

Wekan — Open-Source kanban