회사에서 사용 중인 H100*8ea 머신에서 pytorch로 llama3 80b 모델을 양자화하고 파인튜닝하는 내부 PoC 진행 중에 이쪽 세계에서 꽤 유명한(?) 오류를 지속적으로 만나게 됐다.

unhandled cuda error (run with NCCL_DEBUG=INFO for details), NCCL version 2.xx.x

진짜 불친절하게도 NCCL_DEBUG=INFO 를 주고 로그 레벨을 더 내리고 해봐도 로그상 별다른 문제(결국 답은 로그에 있었지만..)를 찾을수는 없었고, nccl 문제인건가 버전을 내렸다 올렸다. cuda 문제인가 버전을 내렸다 올렸다. 열심히 삽질 하던 중 pytorch github issue 이잡듯 뒤지다가 cuda12.4에서 pytorch를 소스 빌드해서 해결했다는 메세지를 보고 한번 시도해 볼까 해서 pytorch 소스 빌드를 진행해 보았다.

빌드를 진행해 보다 몇가지 이슈사항이 있었고 결국엔 항상 지나고 나면 별것 아닌 설정들... 거의 하루를 날려버리고 말았다.

그래서 다른이들의 삽질 방지를 위해서 이 또한 기록 해 둔다.

소스 빌드 시 주의사항

사실 소스로 부터 빌드 절차는 그렇게 어렵진 않다. 다큐먼트 순서데로 충실히 수행하면 된다.

GitHub - pytorch/pytorch: Tensors and Dynamic neural networks in Python with strong GPU acceleration

Tensors and Dynamic neural networks in Python with strong GPU acceleration - pytorch/pytorch

GitHubpytorch

제약 조건은 아래와 같고,

• Python 3.8 or later (for Linux, Python 3.8.1+ is needed)
• A compiler that fully supports C++17, such as clang or gcc (gcc 9.4.0 or newer is required)

나머지 의존성 설치는 conda 환경 기준으로 되어 있어서 나처럼 pip 만 사용할 수 있는 환경이면 약간 애로사항이 꽃 필 수 있다.

최종적으로는 컨테이너 기반에서 작업을 해야 하고 DDP(Distributed Data parallel) 나 OpenMPI 를 통한 분산 기능을 사용해야 해서 먼저 base 이미지는 ubuntu 22.04에 OpenMPI를 먼저 설치 했었다.

FROM nvidia/cuda:12.4.1-cudnn-devel-ubuntu22.04

# 기타 내가 필요한 라이브러리들 설치...

# Install Open MPI
RUN \
    echo "Install Open MPI 4.1.6" \
    && mkdir /tmp/openmpi \
    && cd /tmp/openmpi \
    && wget https://download.open-mpi.org/release/open-mpi/v4.1/openmpi-4.1.6.tar.gz \
    && tar zxf openmpi-4.1.6.tar.gz \
    && cd openmpi-4.1.6 \
    && ./configure --prefix=/usr  --enable-orterun-prefix-by-default  --with-cuda=$CUDA_HOME --with-cuda-libdir=$CUDA_HOME/lib64/stubs --with-slurm  > /dev/null \
    && make -j $(nproc) all \
    && make -s install \
    && ldconfig \
    && rm -rf /tmp/openmpi \
    && ompi_info | grep "MPI extensions"

그리고 pytorch 소스를 클론 받고 아래와 같은 스크립트를 통해 실제 빌드 작업을 진행했다.

python -m pip install mkl-include mkl-static ninja scikit-build
python -m pip install -r requirements.txt

export CMAKE_PREFIX_PATH="/usr/include/openmpi;/usr/lib/openmpi;/usr/lib"

USE_CUDA=1 \
USE_CUDNN=1 \
USE_MPI=1 \
USE_SYSTEM_NCCL=1 \
USE_ROCM=0 \
NCCL_INCLUDE_DIR=/usr/include \
python setup.py develop

여기서 주의 할점은 2가지 정도이고, 나머지는 빌드 옵션에 따라 약간 차이가 있다.

• CMAKE_PREFIX_PATH에서 openmpi 의 헤더 파일 위치와 공유라이브러리(so)파일 있는 위치를 정확하게 지정하지 않으면 MPI 가 활성화 되지 않은채 빌드된다.
• NCCL_INCLUDE_DIR 도 정확하게 지정해야 한다. NCCL 활성화 실패...

이 별거 아닌 설정 2개 찾느라 거의 하루를 날린 듯 하다.

정리

pytorch를 소스 빌드하는 순간이 얼마나 오겠냐만은... 비슷한 상황의 분들을 위해 정리해 본다.

여하간 오늘의 나의 교훈은

• 로그는 나의 생명줄, 보고 싶은 로그만 보고 넘기지 말자
• 급할수록 천천히 차근차근 하나씩 하나씩

시작은 2003년 이제 막 프로그래머로써 첫발을 내딛을 때부터 나는 프로그래밍 폰트에 대해서 관심이 많은 편이었다.

화면 붙잡고 매일 글자들과 씨름하는 직업이다보니 당연하게도 좀더 눈에 잘 보이고, 보기에 좀더 미려하고 조화스러운 폰트를 찾는 것이 어찌보면 약간 본능(?)적으로 관심을 가졌던게 아닌가 싶기도 하고 말이다.

최근까지도 이 주체할 수 없는 본능에 따라 마음에 드는 폰트를 찾아 유랑하는 탐험가의 마인드로 여기저기 들리는 폰트 소식들에 관심을 기울이다가 이번에 큰맘 먹고 유료 폰트(포스팅 마지막에 소개)를 구매하였다.

구매를 진행해보면서 내가 프로그래머 생활하면서 얼마나 많은 폰트를 거쳐왔었나 궁금해지기도 하고 한번 정리 해보는것도 재미있겠다 싶어 추억을 곱씹어 보니 생각보다 많은 폰트들이 내손을 거쳐갔구나 싶다.

이 폰트들이 나름 내 손으로 만들어낸 프로그램들에 생기를 불어 넣어준게 아닌가라는 감성적인 생각이 들기도 하고.. 서론이 길었고 여하간 지극히 개인적인 추억과 사용기로 내 프로그래밍 폰트 일대기를 한번 작성해 본다.

프로그래밍 폰트의 필수 조건

많이 알려져 있는 사실이지만 일반적으로 사용하는 폰트와 다르게 프로그래밍 폰트는 다음과 같은 조건들이 거의 필수적으로 요구되고 나도 그에 마찬가지로 동의하는 바이다.

내가 사용했던 폰트는 무조건 아래의 조건이 지켜져야 했다.

고정폭 폰트

내가 폰트 사용/프로그램 작성 시에 가장 중요하게 생각하는 것 눈에 잘 읽혀야 하는 가독성인데 공백이나 탭 등을 통해 들여쓰기 하거나 줄을 정렬하거나 할 때는 고정폭을 가진 폰트여야 이 가독성을 지키는 것이훨씬 더 유리하다.

문자간 명확한 구분

영문자 0O와 숫자 0, 영문자 iILl과 숫자 1 등 글리프(Glyph)가 약간 비슷한 놈들끼리 혼동되지 않고 구분되는 폰트여야 프로그램 작성 시에 오타 또는 혼동을 줄일 수 있기 때문에 이러한 조건들은 거의 필수적으로 지켜져야 마음의 평화를 유지 할 수 있다.

프로그래머 친구 엿먹일려면 세미콜론(;)을 그리스어 물음표(;)로 바꾸라는 이 생태계의 유명한 농담도 이러한 문자 구분에 대한 많은 프로그래머들의 신념에 대한 유쾌한(SQL 마지막에 그리스어 물음표라 생각하면 진짜 유쾌할까 😱) 유머 아닐까 싶다.

Ligature, Powerline Symbol, Icon [Optional]

Ligature는 서로 다른 글리프를 가진 문자들을 통합해서 보여주어서 화면상에 좀더 미려하게 표현하는 것을 얘기하며 또한 최근에는 zsh 사용자들이 많아 지면서 터미널에서 자주 사용하는 쉘프롬프트나 VIM 등의 상태바에 Powerline Symbol 등의 아이콘을 폰트에 합성(Nerd font)해서 많이들 사용하고 있다.

내가 사용해 왔던 폰트

정확하진 않지만 나의 사용 연대기 순으로 한번 정리해보았고 사용된 이미지 예제는 대체로 programmingfonts 에서 인용하였다.

재미로 간단한 사용기와 나름의 별점도 한번 매겨보았다.

Fixedsys, 1980

⭐⭐⭐

가장 먼저 언급을 안할 수가 없겠다.

추억보정용 폰트! 윈도우 노트패드인가 아마 기본 폰트였던걸로 기억하고 이게 아마 윈도우 1.0인가 부터 계속 있던 폰트로 알고는 있다.

DOS 코맨드라인 통해서 telnet 사용하던 시절 자주 애용하던 폰트였고, 최초로 고정폭 폰트가 이런거구나라는걸 알려준 폰트다.

최근 10년 내에는 윈도우를 거의 쓰지 않아서.. 요즘의 consolas 가 예전 fixedsys 정도 느낌이 되지 않을까 싶고, 초년생 때 외에는 거의 사용하진 않았던 추억의 폰트다.

Bitstream Vera Sans Mono, 2002

⭐⭐⭐⭐

쥬니어 프로그래머 시절 꽤나 오랜시간 나의 eclipse 에서 오랜시간 함께 했던 폰트다. 아마도 최근에 나온 많은 폰트 들에게 많은 영감을 준 폰트 아닐까 하고, 모든 구석에서 평균 이상의 평점이 나올 만한 폰트다.

아마도 많은 프로그래머 폰트 순위를 매기는 곳에도 항상 수위권을 지키지 않을까 싶은 폰트다.

Nanum Gothic Coding Font, 2009

⭐⭐⭐

D2Coding이 나오기 이전에 네이버에서 야심차게(?) 발표한 폰트 였고, Bitstream 보다는 글자폭이 약 90% 수준 정도여서 처음에는 좀더 가로로 길게 보기 편한 느낌이어서 사용을 좀 하다가 글자폭, 자간이 너무 좀 작은 편이이서 오랜 시간 사용할때는 약간 눈에 피로함이 있어서 길게 사용하진 않았던 폰트였다.

Envy Code R, 2008

⭐⭐⭐⭐

이때쯤 아마 Visual Studio로 법제처 프로젝트였었나 한글OCX로 법령안 편집기 Visual Basic 으로 밤패가며 코딩 하던 시기 였나 본데, 우연치 않게 찾아보던 VB관련 블로그에서 이 폰트를 추천 하길래 한 2~3년 정도 이것만 쭉 사용했던 기억이 있다.

1하고 l이 살짝 헷갈리긴 했지만 Bitstream 과는 약간 다른 둥글둥글한 맛에 꽤 오랫 동안 함께 했던 폰트다.

Anonymous Pro, 2009

⭐⭐⭐⭐

아마도 Adobe에서 무료로 풀렸던 Anonymous 기반으로 만들어진 폰트로 알고 있었고, 한참 개발자들 사에서 유행하길래 조금 써보았지만 내 타입은 아니었던 폰트였다.

그래도 아직 개발자들 사이에서는 인기 좋은 폰트 중 하나!

Source Code Pro, 2012

⭐⭐⭐⭐

그러고 보니 이 폰트도 Adobe에서 나왔던 폰트였나 그랬던거 같은데, 가로길이가 좀 긴 폰트였고 이 폰트도 아직 개발자들 사이에서는 많이 사용하는 폰트로 알고 있지만.. 이상하게 정이 안가는 폰트들중 하나..

D2Coding, 2016

⭐⭐⭐

역시나 네이버에서 배포한 개발자용 무료 폰트로 한글이 나눔고딕으로 머지되어 있어서 지금도 꽤 나 많은 팬층을 보유한 폰트이다.

역시나 자폭과 자간이 좀 짧은(네이버 스타일인가 보다)편의 폰트로 군더더기는 없지만.. 역시나 이상하게 정이 안가.. 많이 사용하진 않았다.

Fira Code, 2014

⭐⭐⭐⭐⭐

IDE를 주로 eclipse를 더 많이 사용하던 시절 3~4년은 이 폰트로 계속 사용 했던 기억이 있다. 내가 사용 했던 폰트 중에 제일 처음으로 ligature가 적용된 폰트였던거 같고 그 맛에라도 좀 더 길게 사용했던 폰트였다.

이 폰트도 아직 개발자들 사이에서 많이 사용 되고 상위권 폰트 느낌~

Menlo 2009, Monaco 2006

⭐⭐⭐⭐⭐

맥북을 본격적으로 사용하면서부터 터미널 기본 폰트 였나 그랬는데 생각보다 가독성도 꽤 좋고 터미널 사용 용도로 꽤나 오랫동안 애용 했고, 웹브라우저용 코드 표현이나 에디터에 consolas 와 같이 기본으로 사용하기 꽤나 좋은 폰트이다.

Menlo는 맥에서는 아무생각없이 그냥 기본 폰트로 사용하기에는 아주 훌륭한 폰트이다.

IBM Plex Mono, 2017

⭐⭐⭐⭐

말그대로 IBM에서 오픈소스로 배포된 폰트인데 얘도 잠깐 사용하다가 말았던 폰트이긴 한데 아직도 이 폰트를 사랑하는 개발자는 꽤나 있는걸로 알고 있고 지금 우리 팀원중 한명도 이 폰트를 애용하고 있다.

Cascadia Code, 2019

⭐⭐⭐⭐

이 폰트는 Microsoft에서 오픈소스로 배포한 폰트인데 처음에는 그렇지는 않았던거 같은데 이제는 기본 윈도우 터미널과 비쥬얼 스튜디오 기본 폰트로 지정된거 같다.

약간 느낌이 Fira Code와 비슷한 느낌이 있었고 이탤릭체가 다른 폰트와 다른게 약간 재미진 느낌이 있다.

근데 이 다음에 소개할 폰트 때문에 그리 오래 사용하진 않았던 기억이 있다.

JetBrains Mono 2020

⭐⭐⭐⭐⭐

JetBrain에서 처음 출시 할때 부터 최근 몇년간 주력으로 사용하던 폰트이다.

자간이 그렇게 넒은편은 아니고 IntelliJ를 계속 사용하다보니 거부감 없이 그냥 계속 사용했던거 같다.

x-height가 되게 적절히 설정되어 있어서 코드를 계속 보고 수정할 때 편안함을 느꼈던거 같다. 비교적 최신에 나온 폰트여서 ligature도 잘 적용 되어 있고 최애 폰트 중 하나이다.

Meslo LG 2013

⭐⭐⭐⭐⭐

Jetbrains Mono와 함께 가장 많이 사용했던 폰트이다. 주로 맥 터미널용 폰트로 많이 썼었는데 얘는 다른 폰트와 다르게 줄간격이 폰트에 포함된 폰트가 함께 나왔었다.

Menlo Regular 기반으로 커스텀을 약간 한 폰트로 다른 폰트와는 다르게 LineGap이라고 하는 속성을 가지고 있다. 줄간격이 더 넓게 고정된 세트를 같이 배포한다고 보면 되는데 IDE나 터미널에서 줄간격 옵션이 없는 경우에 유용하게 사용 가능해서 주로 터미널에서 주력으로 계속 사용했었다.

Monolisa, 2022

⭐⭐⭐⭐⭐

서두에 얘기 했듯이 유료로 구매한 폰트가 바로 이 폰트이다.

우연치 않게 서핑 중에 추천하는 글을 발견했고 Playground 페이지에서 이것저것 내 입맛에 맞게 커스텀이 가능하고 이탤릭 글자 표현도 너무 맘에 들어서... 결국 pro 버전을 구매했다.

지금 거의 모든 IDE와 터미널 등 키보드로 칠 수 있는 거의 모든 곳에 이 폰트를 사용하고 있다. 왜냐하면... 돈 주고 샀기 때문에 일단 뽕을 뽑아야 해서 😅😅😅

내 인생 처음으로 돈을 주고 산 폰트이기도 하지만 그 이전에 내가 원했던 글리프의 미묘한 모양 변화도 가능해서 일단 몇년 간은 폰트 걱정없이 잘 사용할 것 같다.

나만의 Best 5

사용했던 폰트들 중에서 사용기간 등을 고려한 나름의 순위를 굳이 한번 매겨보자면 다음과 같다.

1. Monolisa - 이건 돈주고 샀기 때문에 어쩔 수 없다 ㅋㅋㅋ
2. Jetbrains Mono
3. Meslo LGMDZ nerd font mono
4. Fira code
5. Cascadia Code

마무리

프로그래밍 폰트 탐험자들을 위해 약간의 도움이 됐으면 좋겠고, 아직 내 여정(?)도 엔딩이 아니기 때문에 여정이 멈추는 순간까지 마음에 드는 폰트가 있다면 계속 추가해보겠다.

다음은 그 동안 거쳐간 키보드도 한번 리뷰 해볼까 ㅋㅋ

Happy Coding~!

몇 년 전인지는 기억나진 않지만 Rate Limit 적용은 항상 애플리케이션 쪽에서 처리하는 것이 당연하다는 것이 주된 의견이었다. 그래서 그때 당시 Bucket4J 를 통해서 Spring 쪽에서 처리하고 했던 기억이 있다.

이제는 당연하게도 Istio와 같은 Service Mesh쪽에서 처리하는 것이 응당 맞다고 생각되는 것이 개발 세상이 이제 점점 더 클라우드향으로 이동된다는 느낌이다.

강력한 오픈 소스 서비스 메시인 Istio는 마이크로서비스 아키텍처를 운영/관리 하기 위한 굉장히 다양한 기능을 제공한다. 하지만 너무 많은 기능을 담은 탓 일까.. 기능이 너무 많고 설정하기 너무 어렵고 너무 불편하다 😂

만들고 있는 서비스에서 Rate Limit을 적용하려 했고, 다양한 경우의 수에 의해서 하나의 인스턴스에서 특별한 Path를 가진 놈만 제한을 가하려 하니, 공식 문서 참조 만으로는 해결이 잘 안되었고 몇일은 고생한 기억이 있어서 Istio 및 Envoy에 대한 간략한 정리와 삽질기를 한번 풀어 써볼까 한다.

Rate Limit이란

Rate Limit란 서비스 혹은 API를 운영함에 있어서 특정 시간 동안 허용되는 최대 요청 횟수를 제한하는 기능이고, 대부분 안정적인 서비스 운영을 위해 특정 시스템의 과부하 등을 조절하거나 제어하기 위해 사용한다.

한국말로 하자면 요청 제한 혹은 호출 제한, 속도 제한 등으로 불리우기는 하는데 어느 것 하나 표현이 제대로 안되는 것 같아서 앞으로도 그냥 Rate Limit으로 기술한다.

이러한 제한 형태 서비스를 구현하기 위한 알고리즘은 아래와 같은 것들이 많이 사용되고, Istio에서는 Token Bucket 을 사용한다. 간단한 알고리즘 설명은 위키 페이지를 참조하면 좋겠다.

• Token Bucket Algorithm #envoy에선 이 알고리즘 사용
• Leaky Bucket Algorithm
• Fixed Window Counter
• Sliding Window Log

Istio의 Rate Limit

앞서 얘기했지만 Istio를 통해 들어오는 트래픽을 동적으로 제어하고 관리하는 기능은 굉장히 종류가 많다. 트래픽에 대한 관리, 보안, 정책, 관측 등의 모든 처리는 Envoy Proxy를 통해 동적으로 설정 되고 관리된다.

그래서 먼저 Rate Limit 설정을 서술하기전에 Envoy가 어떤식으로 트래픽을 관리하는지 알아볼 필요성이 있어서 리서치 해본 김에 살펴보고 넘어가야할 일부 중요한 처리 과정을 아래와 같이 정리해보았다.

트래픽이 Istio를 통해 유입이 되면 Sidecar를 통해 배포된 Envoy Proxy는 요약하자면 다음과 같은 동작을 수행한다. 전체 요청에 대한 라이프사이클 문서에 상세한 설명은 담겨 있으니 디테일한 부분이 궁금하신 분들은 참조하시면 좋겠다.

• Listener Filter는 리스너에 구성된 주소와 포트에 상응하는 요청이 들어오면, 리스너 내부적으로 리스너 필터로 전달하여 커넥션 메타데이터를 조작하고 네트워크 필터로 전달
• Network Filter를 순회하면서 트래픽 특성에 따른 적합한 Filter를 찾고 해당 Filter가 요청을 처리. 제공되는 빌트인 필터 종류가 어마무시하고 자세한 필터 정보는 레퍼런스를 참조
• HTTP 요청인 경우 HTTP Connection Filter를 통해 트래픽을 처리
• 마지막 Route 를 통해 Upstream endpoint로 연결
• 전체 요청에 대한 상세한 설명은 공식 문서(Life of a request) 잘 설명되어 있으므로 상세한 설명이 필요한 경우 참조

여기서 Rate Limit 처리를 담당 하는 부분은 Network Filter 중에 하나이며, 뜯어보면 아래와 같은 프로세스로 처리된다고 볼 수 있다.

Network Filer, HTTP Filter 2가지에서 모두 Rate Limit 설정을 진행할 수 있고, 원하는 구현 방식에 따라 해당 Filter에 설정을 하면 된다.

Envoy는 Global과 Local의 두 가지 Rate Limit을 지원하고, 각각의 네트워크 필터 혹은 HTTP 필터를 통해 Rate Limit을 설정하고 관리 할 수 있다. 각각의 형식에 따라 구성해야할 추가적인 외부 서비스 등이 있으므로 간략히 설명해 본다.

Global Rate Limit

Global Rate Limit은 전체 메시의 Limiting를 제공하기 위해 Global gRPC Rate Limit Service를 사용한다. Istio 외부에서 Rate Limit을 처리하기 위해 Redis를 기반으로 한 Go로 짜여진 서비스이고 해당 설정을 사용하려면 Redis와 함께 외부 Rate Limiter를 설치해야 한다.

Local 방식과의 차이점은 각각 인스턴스의 Envoy Proxy를 사용하는 것이 아니라 Ingress Gateway의 Envoy를 통해 전역으로 설정하는 것이 가장 큰 차이점이라 볼 수 있다. 나머지 이슈나 차이점 정리해보자면 다음과 같다.

• 별도의 Global Rate Limit Service를 구현 해야함
  • 샘플은 제공됨, sample
  • 설치 자체는 어렵진 않는데 샘플 자체는 2022년 08월 16일 구현체로 설치하는데 수정된지 꽤 되어 보이긴 하니 참조
  • redis backend가 필요
• Local Rate Limit과 병행하여 사용 가능
• Istio Ingress Gateway의 Envoy에서 전역으로 설정된 Rate Limit을 처리

이번 포스팅의 주제는 Local Rate Limit 쪽이므로 Global 관련된건 다음에 시간이 나면 별도의 포스팅으로 다뤄 볼 생각이다.

Local Rate Limit

Envoy 자체적으로 트래픽 요청(L4, HTTP)의 Local Rate Limit을 지원다. 이를 통해 다른 외부 서비스를 호출하지 않고도 프록시 자체 인스턴스 수준에서 Rate Limit을 적용할 수 있다.

내가 Local로 선택한 이유도 Redis 등의 별도의 백엔드 데이터베이스를 구성하고 따로 운영해야하는 부담이 있어서 Istio/Envoy 만으로 구성할 수 있기를 선호해서 나는 Local 방식을 선택했지만 어떻게 구성하여 운영할 지는 주어진 환경에 따라 선택하면 될 것 같다.

구성을 위한 사전 정보는 살펴봤으므로 이제 본격적으로 Local Rate Limit을 설정해 보자.

All you need is "EnvoyFilter"

사실 설정할 것은 많지 않다. Envoy Filter 를 적정한 포맷으로 작성하면 된다. 근데 이 예제가 정말 거지 같다. 공식 문서 샘플도 정말 정말 거지 같다. 도저히 그것만 보고는 따라 만들 수 없을 정도로 거지 같다.

그래도 뭐 차근차근 일단 전체 서비스를 걸려면 공식 문서에 나와 있는 것처럼 HTTP_FILTER 전에 RATE_LIMIT 필터를 추가해야 한다.

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: filter-local-ratelimit-svc
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: productpage
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: http_local_rate_limiter
              token_bucket:
                max_tokens: 4
                tokens_per_fill: 4
                fill_interval: 60s
              filter_enabled:
                runtime_key: local_rate_limit_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              filter_enforced:
                runtime_key: local_rate_limit_enforced
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              response_headers_to_add:
                - append: false
                  header:
                    key: x-local-rate-limit
                    value: 'true'
EOF

여기서 중요하게 봐야할 설정 값은 아래와 같다.

• stat_prefix
  • promethus 를 통해서 관련된 메트릭을 수집할 수 있는데 그때 사용되는 prefix 정보다.
• token_bucket
  • 이 예제는 1분에 총 4개의 요청만 받고 나머지는 제한 하는 설정으로
  • max_tokens: 4 는 버킷에 담을 수 있는 최대 토큰 수이고, 버킷에 초기 설정에 포함되는 토큰의 수이기도 하다.
  • tokens_per_fill: 4 는 각 토큰 채움 간격 동안 버킷에 추가되는 토큰 수다. 지정하지 않으면 기본값은 max_tokens 값이다.
  • fill_interval: 60s 는 토큰이 버킷에 추가되는 채움 간격이다. 각 채움 간격 동안 버킷에 토큰이 추가될 때마다 tokens_per_fill 개수가 추가된다. 이 경우 1분이 지나면 4개의 토큰이 다시 채워지는 경우이다. 버킷에는 최대 토큰 수보다 많은 토큰이 포함되지 않는다. 예를 들어 기간 동안 2개가 남았다고 해서 2+4가 아니라 4개가 다시 지정되는 방식이다.

이제 특정한 포트라던가 path 설정을 추가하려면 HTTP_ROUTE 과 함께 설정을 해야 한다. 아래 예제는 공식문서에 나와있는 9080 으로 들어오는 모든 요청에 대해서 Rate Limit을 거는 예제이다.

metadata:
  name: filter-local-ratelimit-svc
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: productpage
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: http_local_rate_limiter
    - applyTo: HTTP_ROUTE
      match:
        context: SIDECAR_INBOUND
        routeConfiguration:
          vhost:
            name: "inbound|http|9080"
            route:
              action: ANY
      patch:
        operation: MERGE
        value:
          typed_per_filter_config:
            envoy.filters.http.local_ratelimit:
              "@type": type.googleapis.com/udpa.type.v1.TypedStruct
              type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
              value:
                stat_prefix: http_local_rate_limiter
                token_bucket:
                  max_tokens: 4
                  tokens_per_fill: 4
                  fill_interval: 60s
                filter_enabled:
                  runtime_key: local_rate_limit_enabled
                  default_value:
                    numerator: 100
                    denominator: HUNDRED
                filter_enforced:
                  runtime_key: local_rate_limit_enforced
                  default_value:
                    numerator: 100
                    denominator: HUNDRED
                response_headers_to_add:
                  - append: false
                    header:
                      key: x-local-rate-limit
                      value: 'true'
EOF

이제 이렇게 설정하면 9080으로 들어오는 모든 요청에 대해서 limit이 걸리게 된다.

사실 path 기준으로 limit을 설정하려고 했던 이유는 서비스의 health check url은 15초에 한번 probe를 체크하는데 계속 사용되는데 이게 계속 token 갯수에 잡히다 보니 특정 인스턴스에서 해당 url을 제외하고 내가 원하는 url만 걸고 싶어서 찾기 시작했던 설정이었다.

근데 나머지 설정을 어떤식으로 MERGE, INSERT 해야하는지 친절하게 설명된 문서는 거의 전무 했고 Envoy 문서를 위주로 해당 정보를 찾았다.

일단 Envoy Filter를 설정하는 방법은 아래에 나와 있긴 하다. 근데 큰 도움은 되지 않는다.

Envoy Filter

Customizing Envoy configuration generated by Istio.

Istio18 minute read

여기서 HTTP_ROUTE 설정에 몇가 설정만 추가하면 되는것이었는데 사실 찾기 쉽진 않았다. 부디 다른 분들은 해당정보를 찾아 헤매는 시간이 많이 줄길 바라며..

주요한 설정은 HTTP_ROUTE 의 route 설정에 다음과 같은 액션을 아래와 같이 추가하고

route:
  rate_limits:
    - actions:
      - header_value_match:
          descriptor_value: "infer"
          expect_match: true
          headers:
            - name: :path
              string_match:
                safe_regex:
                  google_re2: {}
                  regex: "^/v2/models/[a-zA-Z0-9-_]+/versions/[0-9]+/infer"

이 예제는 정규표현식으로 특정 URL만 descriptor로 분류 해서 header에 infer 라는 값을 넣기 위함이다.

그리고 HTTP_ROUTE 의 local_ratelimit 설정에 해당 descriptor 설정을 추가하면 된다!

envoy.filters.http.local_ratelimit:
  '@type': type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
  stat_prefix: [[${param.statPrefix}]]
  token_bucket:
    max_tokens: 2147483647
    tokens_per_fill: 2147483647
    fill_interval: 60s
  filter_enabled:
    runtime_key: test_enabled
    default_value:
      numerator: 100
      denominator: HUNDRED
  filter_enforced:
    runtime_key: test_enabled
    default_value:
      numerator: 100
      denominator: HUNDRED
  response_headers_to_add:
    - append: false
      header:
        key: x-local-rate-limit
        value: "true"
  descriptors:
    - entries:
        - key: header_match
          value: infer
      token_bucket:
        max_tokens: [[${param.maxTokens}]]
        tokens_per_fill: [[${param.tokensPerFill}]]
        fill_interval: [[${param.fillInterval}]]

여기서는 기본으로 설정될 값을 지정하고 descriptors 설정에 header_match 가 infer 인 경우 특별한 설정을 할 수 있게 지정하면 된다.

전체 설정은 아래와 같다.

kind: EnvoyFilter
metadata:
  name: filter-local-ratelimit-svc
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: productpage
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            '@type': type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: [[${param.statPrefix}]]_all
    - applyTo: HTTP_ROUTE
      match:
        context: SIDECAR_INBOUND
        routeConfiguration:
          vhost:
            name: "inbound|http|8000"
            route:
              action: ANY
      patch:
        operation: MERGE
        value:
          route:
            rate_limits:
              - actions:
                  - header_value_match:
                      descriptor_value: "infer"
                      expect_match: true
                      headers:
                        - name: :path
                          string_match:
                            safe_regex:
                              google_re2: {}
                              regex: "^/v2/models/[a-zA-Z0-9-_]+/versions/[0-9]+/infer"
          typed_per_filter_config:
            envoy.filters.http.local_ratelimit:
              '@type': type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
              stat_prefix: [[${param.statPrefix}]]
              token_bucket:
                max_tokens: 2147483647
                tokens_per_fill: 2147483647
                fill_interval: 60s
              filter_enabled:
                runtime_key: test_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              filter_enforced:
                runtime_key: test_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              response_headers_to_add:
                - append: false
                  header:
                    key: x-local-rate-limit
                    value: "true"
              descriptors:
                - entries:
                    - key: header_match
                      value: infer
                  token_bucket:
                    max_tokens: [[${param.maxTokens}]]
                    tokens_per_fill: [[${param.tokensPerFill}]]
                    fill_interval: [[${param.fillInterval}]]

그러면 이제 내가 원하는 특정 API만 설정이 가능하다. 만세~!

프로메테우스를 통한 모니터링

stat_prefix 설명을 통해 간단히 얘기했지만 Filter 걸린 요청 정보는 아래와 같은 metric으로 조회가 가능하다.

모든 통계값은 Prometheus의 경우 Counter 형식으로 저장된다.

이렇게 [stat_prefix]_http_local_rate_limit_ok 조회 가능하다.

Summary

지금까지 Istio Envoy Proxy의 Local Rate Limit 설정 기능 중에 Path 기반으로 설정하는 방법에 대해 주저리 주저리 설명을 해보았다.

부디 같은 고민을 하는 분들의 삽질 시간을 많이 줄여 주길~

포스팅 글과 관련하여 질문이나 피드백 등은 자유롭게 링크드인 프로필에 연락주세요~

LinkedIn https://www.linkedin.com/in/hkwon77

현재 개발하고 있는 일부 컨테이너 기반의 서비스들을 Istio를 통해 서비스들을 구성하고 트래픽을 관리하고 있다.

이때 컨테이너 서비스가 같은 규격이 여러개가 같은 url과 port를 할당 받아서 사용해야는 애로 사항이 있어 Istio에서 header 기반으로 특별한 헤더가 있는 경우에만 라우팅이 될 수 있도록 구성하고 테스트를 진행했었다.

Istio Request Routing 예제와 같이 header 에 model-api-key 값에 따라 정확하게 매치된 요청만 지정한 서비스로 라우팅 되도록 설정하였다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  generation: 1
  labels:
    cheetah.xxx: xxx
  name: ...
  namespace: cheetah
spec:
  gateways:
  - model-deployment-gateway
  hosts:
  - '*'
  http:
  - match:
    - headers:
        model-api-key:
          exact: "xyz"
    route:
    - destination:
        host: model-deploy-01j46dj4ah5abd1zz8pc21vkg9
        port:
          number: 8000

curl 이나 기타 다른 도구들로 테스트 시에는 큰 문제가 되진 않았는데, 브라우저에서 해당 API를 호출해서 뭔가 메타데이터를 얻어오는 경우가 있었는데, 당연하게도 서비스되는 도메인이 같지 않고 IP 기반으로 서비스를 하다보니 CORS(교차 출처 리소스 공유) 이슈가 발생했었다.

브라우저에서는 CORS를 검증하기 위한 pre-flight(사전 검증 요청) 요청을 특별한 헤더(Options)와 함께 던져서 유효한 요청인지 검증 받고 실제 API를 요청하는데 이 과정에서 아래와 같이 오류가 발생했다.

Access to XMLHttpRequest at ‘https://myapi.com/Form’ from origin ‘https://myui.net’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: Redirect is not allowed for a preflight request.

CORS Preflight 와 관련된 절차와 자세한 내용은 아래의 문서들이 진짜 정리(진리의MDN)가 잘되어 있다. 한번 훑어 보시길 권장한다.

Fetch Standard

WHATWG

Cross-Origin Resource Sharing (CORS) - HTTP | MDN

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

MDN Web Docs

어찌됐든 일반적인 CORS 관련된 설정이거니 해서 공식 Istio 문서에서 Cors Policy 를 보고 아래와 같이 수정해서 테스트를 다시 진행했다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  generation: 1
  labels:
    cheetah.xxx: xxx
  name: ...
  namespace: cheetah
spec:
  gateways:
  - model-deployment-gateway
  hosts:
  - '*'
  http:
  - corsPolicy:
      allowCredentials: true
      allowHeaders:
      - authorization
      - content-type
      - accept
      - origin
      - user-agent
      - model-api-key
      allowMethods:
      - POST
      - GET
      - PUT
      - DELETE
      - OPTIONS
      allowOrigins:
      - exact: '*'
      maxAge: 24h
    match:
    - headers:
        model-api-key:
          exact: "xyz"
    route:
    - destination:
        host: model-deploy-01j46dj4ah5abd1zz8pc21vkg9
        port:
          number: 8000

corsPolicy에 allowHeader와 allowMethds에 허용할 값들을 위처럼 잘 설정하고 다시 테스트 해보는데 이번엔 뜬금없이 404 not found가 나고 있다.

다시 한번 절차데로 제대로 되고 있는지 이것저것 로그를 확인해 보았다.

위 그림 처럼 가장 첫번째 Preflight 요청을 날리는 시점이 문제였다. 해당 부분은 axios나 fetch 같은 라이브러리를 사용하여 날리는 요청이 아니라 브라우저 에서 CORS 확인을 위해 준비되는 절차인데, 특별한 헤더를 사용한 요청 즉 model-api-key라는 헤더를 통해 istio로 라우팅 한 경우가 문제가 되고 있었다.

브라우저에서 Options 메소드로 Preflight 검증 요청 시에는 custom header를 지원하지 않는 것이었다.

당연히 커스텀 헤더가 없어서 라우팅할 서버가 없기 때문에 404 오류가 발생되었다.

Istio의 설정으로 뭔가 가능하지 않을까 싶었지만 결국엔 방법을 찾진 못했고 결국엔 같은 url와 port로 떠 있는 preflight 검증용 dummy 서버를 만들어서 띄워두고 preflight 검증 시에는 dummy 서버로 요청하고 실 요청은 헤더를 기반으로 요청하게끔 기능은 변경 하였다.

정리

• CORS 처리 절차에 대해서 숙지 필요
• Istio와 상관 없이 브라우저에서 Preflight 요청에서는 사용자 정의 header가 포함되진 않는다.
• Istio가 아니더라도 custom header를 반드시 사용해야 하는 경우라면 dummy 서비스를 하나 띄워두고 preflight와 본 요청을 분리하여 사용한다.

최근에 nvidia a100 gpu를 mig로 나눠서 사용 하는 노드에서 cadvisor가 gpu metric을 수집을 잘 못해서 kubulet에서 계속 오류가 떨어져서 트러블슈팅을 진행했었다.

dcgm-exporter로 prometheus로 metric을 수집하고 있어서 굳이 cadvisor에서 nvidia accelerator meric을 수집할 이유가 없어져서 이것저것 자료를 찾아보니 1.19 버전부터는 DisableAcceleratorUsageMetrics feature gates로 해당 수집 옵션을 비활성화 시킬 수 있는 것으로 보여서 적용했다.

적용하는 중에 생각보다 kubernetes cluster 운영 중에 feature gates를 수정할 일이 많아서 매번 까먹고(왜 맨날 할때 마다 새롭지??) 찾기 귀찮아서 정리를 한번 해본다.

Feature Gates란

Feature gates는 kubernetes에서 제공되는 기능 설정에 대한 키-값 세트이다. -feature-gates 커맨드 라인 플랙이나 kubulet, api server 설정 파일을 통해 Alpha, Beta Feature에 대해서 기능을 활성/비활성 시킬 수 있다.

아래의 문서에서 버전 별로 설정할 수 있는 feature에 대해서 확인 할 수 있다.

https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/

1. Kubelet에서 Feature gate 활성화

첫번째로는 모든 클러스터에서 kubelet service의 feature gate를 활성화를 진행한다.

systemd로 kubelet이 설정 되어 있다면 환경변수 파일을 확인한다.

hkwon@a100-cheetah-1:/etc/systemd/system/kubelet.service.d# cat 10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --node-ip=183.111.96.75

EnvironmentFile은 user overrides 하는 설정은 /etc/default/kubelet 파일을 사용하라고 되어 있으니 해당 파일을 편집하여 $KUBELET_EXTRA_ARGS 변수를 설정한다.

내가 활성화할 feature gates는 DisableAcceleratorUsageMetrics 이므로 해당 feature를 true로 설정한다.

$ sudo vi /etc/default/kubelet
KUBELET_EXTRA_ARGS=--feature-gates=DisableAcceleratorUsageMetrics=true

새로 설정한 내용을 적용하려면 kubelet 서비스를 재시작해야 한다. 노드가 ready status로 다시 가기 위해 5분 정도는 구동중인 pod에는 영향을 미치지 않으니 설정에 별(?) 이상이 없다면 노드들의 kubelet 을 재시작한다.

물론 중요한 시스템인 경우 node drain 후에 재시작을 권고한다.

$ sudo systemctl restart kubelet

설정이 성공적으로 적용 되었는지 확인 할 수 있다.

$ ps aux | grep kubelet | grep feature-gates

$ journalctl --no-pager -u kubelet -x -e -f

2. Kube api server에서 Feature gate 활성화

이제 kubenetes 컴포넌트(kube-apiserver, kube-controller-manager and kube-scheduler)들에서 feature gates를 활성화 한다.

kube component들에 feature gate 추가

기본component들의 manifets는 아래에 위치하고 해당 설정을 추가하여 저장한다.

$ sudo vi cd /etc/kubernetes/manifests/kube-apiserver.yaml

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=183.111.68.73
    ...
    - --feature-gates=VolumeSnapshotDataSource=true, DisableAcceleratorUsageMetrics=true

$ sudo vi cd /etc/kubernetes/manifests/kube-controller-manager.yaml.yaml

...
spec:
  containers:
  - command:
    - kube-controller-manager
    ...
    - --feature-gates=VolumeSnapshotDataSource=true, DisableAcceleratorUsageMetrics=true

$ sudo vi cd /etc/kubernetes/manifests/kube-scheduler.yaml

...
spec:
  containers:
  - command:
    - kube-scheduler
    ...
    - --feature-gates=RemoveSelfLink=false, VolumeSnapshotDataSource=true, DisableAcceleratorUsageMetrics=true

해당 파일들이 수정되면 자동으로 component pod들은 재시작된다. 아래와 같이 제대로 적용 되었는지 확인한다.

$ ps aux | grep apiserver | grep feature-gates
root      765532 13.4  4.0 1375592 641716 ?      Ssl  06:37   0:41 kube-apiserver --advertise-address=183.111.68.73 ... 
--feature-gates=VolumeSnapshotDataSource=true, DisableAcceleratorUsageMetrics=true

잘 적용 되었는지 다시 gpu node의 kubelet 로그를 확인해 본다.

정리

feature-gates를 적용하는 분들의 시간을 줄일 수 있기를~!

더 좋은 방법이 있다면 댓글 고고~!

Mac에서 갑자기 Docker desktop이 무한 리스타트가 되면서 맛탱이가 가는 상황이 발생됐다.

좀 오래 걸리는 Docker build를 돌려 놓고 퇴근 했는데 Desktop이 전원이 나갔나 중간에 리부팅 되면서 Docker desktop이 정상 동작되지 않는다..

최신버전 받아서 재설치도 해보고 여전히 해결이 안되서 싹 지우고 다시 설치하니 정상 작동 한다.

아래는 문제 해결해보면서 했던 일들 정리

Docker - Troubleshoot 메뉴를 통해 해결을 시작해 본다.

먼저 Clean/Purge data 를 통해 data 쪽에 꼬인 부분이 있다면 clean 해준다.

이걸로 해결이 안된다면 아예 Reset to factory defaults 로 초기화 해본다.

이것도 해결이 안된다면 Uninstall 후에 아래의 cache 및 디렉토리를 싹 정리해준다.

• ~/Library/Application Support/Docker Desktop
• ~/Library/Caches/com.docker.docker
• ~/Library/Cookies/com.docker.docker.binarycookies
• ~/Library/Group Containers/group.com.docker
• ~/Library/Logs/Docker Desktop
• ~/Library/Preferences/com.docker.docker.plist
• ~/Library/Preferences/com.electron.docker-frontend.plist
• ~/Library/Saved Application State/com.electron.docker-frontend.savedState
• ~/.docker

나 같은 경우에는 아예 clean 으로 싹 지우고 재설치 하니 정상 동작~

Docker desktop도 이제 반쯤 유료화 되고, mac에서 뭔가 지원이 영 시원찮은 느낌, 대체제를 좀 알아봐야겠다.

Ubuntu는 한 3년전부터인가 CentOS보단 개인적으로 더 주력으로 많이 사용했던거 같다.

16.04 LTS 나올때부터 꾸준히 쓰긴 했었는데 어느샌가 벌써 18.04가 LTS 버전으로 나왔다.

16.04로 바꿔서 쓸때도 systemctl 때문에 한동안 매우 힘들었는데 18.04 올라가고 벌써부터 바뀐 것들이 너무 많다. 뭐 이리 배울게 많아 ㅠㅠ

어찌됐든 또 잊어버리기 전에 다음에 헤매지 않게 기억해본다.

Static IP 설정

첫번째 난관은 네트워크 인터페이스 설정이다.

17.10부터 네트워크 인터페이스 설정이 NetPlan이라는 새로운 네트워크 설정 시스템으로 변경된 것 같다.

확실히 기존의 인터페이스 설정(/etc/network/interfaces)보다는 더 간결하고 쉽게 YAML을 사용하여 관리가 가능하다.

/etc/netplan/*.yaml

해당 위치에 인터페이스 설정이 가능하고 NetworkManager와 networkd 두개의 렌더러를 사용할 수 있다.

NetworkManger 렌더러를 사용하는 경우에는 X Window 환경에서만 사용하고 나머지 경우는 networkd 렌더러를 사용하면 된다.

네트워크 인터페이스 확인

우선 ifconfig -a 를 통해 설정할 네트워크 인터페이스를 확인한다.

hkwon@canary-test-server:~$ ifconfig -a
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::a00:27ff:fe57:92b1  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:57:92:b1  txqueuelen 1000  (Ethernet)
        RX packets 375  bytes 314494 (314.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 178  bytes 18901 (18.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 08:00:27:22:8f:0b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 28  bytes 2208 (2.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28  bytes 2208 (2.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8 인터페이스를 NetPlan을 통해 설정해보자.

netPlan을 통한 Static IP 설정

아마 디폴트로 세팅했다면 아래와 같이 기본 인터페이스 설정이 존재한다.

/etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp0s3:
            addresses: []
            dhcp4: true
            optional: true
    version: 2

dhcp로 설정된 enp0s3 인터페이스가 보일 것이다.

새로운 인터페이스인 enp0s8번을 설정해보자

$ sudo vi /etc/netplan/01-netcfg.yaml

나는 virtualbox 호스트네트워크를 사용한 인터페이스를 추가해서 ethernets 섹션의 ip를 192.168.56.100/24로 설정하고 기타 아래와 같이 gateway와 dns 정보를 입력한다.

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
 version: 2
 renderer: networkd
 ethernets:
   enp0s8:
     dhcp4: no
     dhcp6: no
     addresses: [192.168.56.100/24]
     gateway4: 192.168.56.1
     nameservers:
       addresses: [8.8.8.8,8.8.4.4]

다른 섹션은 볼 필요 없고 ethernets 섹션만 정확하게 설정하고 저장한다.

• dhcp4 : IPv4 dhcp 설정
• dhcp6 : IPv6 dhcp 설정
• addresses : ,로 구분한 IP 멀티로 가능
• gateway4 : IPv4 gateway 설정
• nameservers : dns 설정 ,로 구분 멀티로 설정 가능 [생략 가능]

설정 재적용

새 설정을 적용하려면 아래의 명령어를 실행한다.

$ sudo netplan apply

다시 ifconfig -a 해서 네트워크 인터페이스 정보를 확인한다.

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::a00:27ff:fe57:92b1  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:57:92:b1  txqueuelen 1000  (Ethernet)
        RX packets 1566  bytes 400006 (400.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 980  bytes 153691 (153.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.56.100  netmask 255.255.255.0  broadcast 192.168.56.255
        inet6 fe80::a00:27ff:fe22:8f0b  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:22:8f:0b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 386 (386.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 40  bytes 3108 (3.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 3108 (3.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

정상적으로 변경된 것을 확인 할 수 있다.

MacBook-Pro:~ hkwon$ ssh hkwon@192.168.56.100
The authenticity of host '192.168.56.100 (192.168.56.100)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.56.100' (ECDSA) to the list of known hosts.
hkwon@192.168.56.100's password:
Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-22-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
...

외부에서도 정상적으로 세팅된 IP로 접속 가능한 것을 볼 수 있다.

최근에 진행하고 있는 사이드 프로젝트 중 하나에 전국/시/군/구/읍/면/동 별 맵차트를 그려야 할일이 생겼었다.

특정 지역의 분포도라던지 히트맵 정도를 지도에 보여줘야 하는 요구사항이었는데(네이버 부동산처럼)

그간 GIS쪽이나 이런쪽은 SI사업을 주로 하다보니 솔루션 베이스로 다뤄봤지만 직접 구현해본적은 없어서 이리저리 자료 조사를 해보니 그럭저럭 오픈소스를 활용해서도 원했던 요구사항 정도는 충분히 커버 할 것 같아서 진행해보았다.

언제나처럼 뭐 이런저런 삽질은 했지만 작업하고 나니 꽤나 간단하게 구현이 가능하다.

준비물

시/군/구/읍/면/동 별 맵 차트를 그리기 위해 가장 중요한건 사실 지도 데이터이다.

우선 원천데이터는 SHP File(Shape file 이하 SHP)이 필요하다.

SHP 포맷은 GIS(지리정보시스템) 에서 가장 유명한 지리정보를 표현하기 위한 벡터 데이터 포맷이다.

ESRI라는 곳에서 개발되었고 최근엔 거의 GIS 소프트위에 제품쪽에서는 de facto로 광범위하게 사용되고 있는 것 같다.

매우 고맙게도 아래 블로그나 포털에서 다운로드 받을 수 있다.

• 공간정보시스템 연구소
• 국가공간정보포털

특히나 공간정보시스템 연구소에서 제공해주는 SHP 파일은 꽤나 유용해서 해당 파일로 작업을 진행했다.
(시간과 노력이 분명 들어가는 일일텐데 매번 업데이트도 마다하지 않고 매우 감사하다)

웹에서 어떻게 표현하지?

브라우저에서 SHP 파일을 직접 핸들링하기에는 힘들고 맵을 표현하기 위해서는 GeoJSON이라는 지리 정보 표시를 위한 표준 Json포맷으로 변환해야 한다.

GeoJSON의 포맷은 다양한 지리 데이터 구조를 인코딩하고 표현하기 위한 형식으로 RFC 표준(RFC 7946)으로 정해져 있고 해당 형식으로 변환을 하면 된다.

SHP to GeoJSON에는 여러가지 방법들이 있겠지만 나는 GDAL이라는 지리데이터 변환 라이브러리에서 제공하는 ogr2ogr 이라는 tool을 사용했다.

변환에 앞서 최적화가 필요하다

앞서 얘기했듯이 SHP에 표현되는 벡터 정보는 폴리곤들이 꽤 디테일하게 그려져 있기 때문에 사이즈가 크기도 하고 좀더 심플하게 표현할 필요가 있다.

여러가지 변환툴을 찾다보니 Mapshaper라는 SHP 에디팅 툴을 많이 사용하는 것 같고 javascript로 만들어져 있기 때문에 node.js만 설치하면 쉽게 사용할 수 있고 GUI 툴도 같이 제공해준다.

Simplify 작업을 수행하기 전에 node.js가 먼저 설치되어 있어야 한다.

# mapshaper 설치
$ npm install -g mapshaper

이제 Mapshaper CLI를 사용할 수 있고 공간정보시스템 연구소에서 제공하는 시군구 SHP 파일을 Simplify해보자

$ mapshaper -i TL_SCCO_SIG.shp \
            encoding=euc-kr  \
            -simplify weighted 0.5% \
            -o format=shapefile \
            TL_SCCO_SIG_convert.shp

hkwon@DESKTOP-HDB86IE:/mnt/c/Temp/map/SIG_201703$ ls -al
합계 11551133
drwxrwxrwx 0 root root      512  8월 22 09:05 .
drwxrwxrwx 0 root root      512  8월 22 08:50 ..
-rwxrwxrwx 1 root root    21629  5월  3 12:37 TL_SCCO_SIG.dbf
-rwxrwxrwx 1 root root      406  1월 15  2014 TL_SCCO_SIG.prj
-rwxrwxrwx 1 root root 21438444  5월  3 12:37 TL_SCCO_SIG.shp
-rwxrwxrwx 1 root root     2100  5월  3 12:37 TL_SCCO_SIG.shx
-rwxrwxrwx 1 root root    21629  8월 22 09:05 TL_SCCO_SIG_convert.dbf
-rwxrwxrwx 1 root root      406  8월 22 09:05 TL_SCCO_SIG_convert.prj
-rwxrwxrwx 1 root root  1597344  8월 22 09:05 TL_SCCO_SIG_convert.shp
-rwxrwxrwx 1 root root     2100  8월 22 09:05 TL_SCCO_SIG_convert.shx

변환된 결과를 Mapshaper GUI에서 확인해 보면

사이즈가 21M에서 1.5M 정도로 줄어들고 디테일하던 섬들 line이 간결화된걸 볼 수 있다. 더 다양한 변환 옵션은 해당 라이브러리 github에서 찾아보면 되고 개인적인 기준에서는 0.5% 정도가 제일 적당하게 단순화 되는 것 같다.

GeoJSON 으로 변환

SHP 파일이 준비 됐으니 이제 GeoJSON으로 변환을 하면 데이터 준비는 완료된다.

앞서 얘기했듯이 SHP to GeoJSON은 GDAL 패키지의 ogr2ogr를 사용해서 변환할 수 있다.

윈도우나 리눅스 머신 둘다 설치 패키지는 제공해주고 있으니 상황에 맞게 GDAL 패키지를 설치한다.

# ubuntu에서 설치
$ sudo add-apt-repository ppa:ubuntugis/ppa && sudo apt-get update
$ sudo apt-get install gdal-bin

이제 ogr2ogr을 사용할 준비가 됐고 기본 옵션은 아래와 같다.

$ ogr2ogr
Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update]
               [-select field_list] [-where restricted_where|@filename]
               [-progress] [-sql <sql statement>|@filename] [-dialect dialect]
               [-preserve_fid] [-fid FID]
               [-spat xmin ymin xmax ymax] [-spat_srs srs_def] [-geomfield field]
               [-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def]
               [-f format_name] [-overwrite] [[-dsco NAME=VALUE] ...]
               dst_datasource_name src_datasource_name
               [-lco NAME=VALUE] [-nln name]
               [-nlt type|PROMOTE_TO_MULTI|CONVERT_TO_LINEAR]
               [-dim 2|3|layer_dim] [layer [layer ...]]
.....
Note: ogr2ogr --long-usage for full help.

사용할 옵션중 COORDINATE_PRECISION은 좌표 표현값이 너무 커서 정밀한 작업은 하지 않을 것이기 때문에 소수점 3자리로 줄여서 변환하는 옵션을 줬다. 물론 그만큼 GeoJSON의 사이즈도 작아진다.

아래의 명령어로 변환이 가능하다.

$ ogr2ogr -f GeoJSON -lco COORDINATE_PRECISION=3 \
          "sig.json" \
          "TL_SCCO_SIG_convert"

전국 맵은 시도 SHP 파일로 쉽게 변환할 수 있고 시군구, 읍면동은 전체가 이어진 하나의 맵으로 되어 있으니 요놈을 시군구, 읍면동 별로 잘라내서 저장해야 서울특별시.json, 서울특별시_강남구.json 과 같은 분리된 파일을 얻을 수 있다.

다행히 국가공간정보포털에서 제공해주는 파일에는 행정구역코드가 함께 포함되어 있어 쉽게 구분해 낼 수 있을 것으로 보였고 간단하게 gulp 태스크를 만들어 변환작업을 연결시켰다.

행정구역코드에 관련된 내용은 [통계청>통계분류포털>특수/일반/국제/행정구역분류>행정구역분류>자료실] 을 참조하면 된다.

var fs = require("fs");

var gulp  = require('gulp'),
    gutil = require('gulp-util'),
    clean = require('gulp-clean'),
    exec  = require('child_process').exec,
    _     = require('lodash'),
    iconv = require('iconv-lite');

var shpPath = {
    ctprvn : {
        source : 'src/CTPRVN_201703/TL_SCCO_CTPRVN.shp',
        convert : 'src/CTPRVN_201703/TL_SCCO_CTPRVN_CONVERT.shp',
        json : 'dist/ctprvn.json'
    },
    sig : {
        source : 'src/SIG_201703/TL_SCCO_SIG.shp',
        convert : 'src/SIG_201703/TL_SCCO_SIG_CONVERT.shp',
        json : 'dist/sig.json'
    },
    emd : {
        source : 'src/EMD_201703/TL_SCCO_EMD.shp',
        convert : 'src/EMD_201703/TL_SCCO_EMD_CONVERT.shp',
        json : 'dist/emd.json'
    }
}

gulp.task('default', ['convert']);

gulp.task('clean-shp', function() {
    return gulp.src(['dist/*.json', 'src/**/*_CONVERT.*'])
        .pipe(clean());
});

gulp.task('clean-split', function() {
    if (!fs.existsSync('dist/sig')){
        fs.mkdirSync('dist/sig');
    }

    if (!fs.existsSync('dist/emd')){
        fs.mkdirSync('dist/emd');
    }

    return gulp.src(['dist/sig/*.json', 'dist/emd/*.json'])
        .pipe(clean());
});

gulp.task('convert', ['clean-shp'], function() {
    for (var key in shpPath) {
        console.log('==========');

        mapshaper(key, shpPath[key].source);
    }
});

gulp.task('split', ['clean-split'], function() {
    // 시군구 geojson 생성
    splitGeojson('sig');

    // 동 geojson 생성
    splitGeojson('emd');
});

function mapshaper(key) {
    var command = 'mapshaper -i '
                + shpPath[key].source
                + ' encoding=euc-kr -simplify weighted 0.5% -o format=shapefile '
                + shpPath[key].convert;

    console.log(command);

    exec(command, function (error, stdout, stderr) {
        if (error) {
            console.error(`exec error: ${error}`);
            return;
        }

        console.log(stdout);
        console.log(stderr);

        console.log('=> convert size')
        console.log('%s : %d bytes', shpPath[key].source,  fs.statSync(shpPath[key].source).size);
        console.log('%s : %d bytes', shpPath[key].convert, fs.statSync(shpPath[key].convert).size);
        console.log('=>')

        ogr2ogr(key);
    });
}

function ogr2ogr(key) {
    var command = 'ogr2ogr -f GeoJSON -lco COORDINATE_PRECISION=3 "'
                + shpPath[key].json
                +'" "' + shpPath[key].convert + '"';

    console.log(command);

    exec(command, function (error, stdout, stderr) {
        if (error) {
            console.error(`exec error: ${error}`);
            return;
        }

        console.log(stdout);
        console.log(stderr);

        console.log('=> convert json size')
        console.log('%s : %d bytes', shpPath[key].json, fs.statSync(shpPath[key].json).size);
        console.log('=>')
    });
}

function splitGeojson(type) {
    console.log("\n *Split geoJSON START* \n");
    console.log(type);

    var fileName = shpPath[type].json;
    //var exception = [ "47940" ];
    var exception = [];

    // 시군구 데이터 sido 별로 자르기
    var contents = fs.readFileSync(fileName);
    var features ={};
    contents = iconv.decode(contents, 'utf-8');

    var jsonContent = JSON.parse(contents);

    for (var key in jsonContent.features) {
        var feature = jsonContent.features[key];
        var subKey, cd, name;

        if (type == 'sig') {
            cd = feature.properties.SIG_CD;
            name = feature.properties.SIG_KOR_NM;
            subKey = feature.properties.SIG_CD.substr(0, 2);
        } else if (type == 'emd') {
            cd = feature.properties.EMD_CD;
            name = feature.properties.EMD_KOR_NM;
            subKey = feature.properties.EMD_CD.substr(0, 5);
        }

        console.log(`feature.properties.cd: ${cd}, feature.properties.name: ${name}`);

        if (features.hasOwnProperty(subKey)) {
            if (!_.has(exception, cd)) {
                features[subKey].push(feature);
            }
        } else {
            features[subKey] = [];

            if (!_.has(exception, cd)) {
                features[subKey].push(feature);
            }
        }
    }

    for (var key in features) {
        var featuresCollection = _.template('{"type": "FeatureCollection", "features": [ \
                <% _.forEach(iterator, function(val, index, list) { %> \
                \n  <%= JSON.stringify(val) %><% \
                if (index < list.length - 1) { \
                %>, <% \
                } \
                }); %> \
            \n]}');

        var jsonStr = featuresCollection({
            'iterator': features[key]
        });

        // split json파일 생성
        fs.writeFileSync("dist/" + type + "/" + key + ".json", jsonStr);
    }

    console.log("\n *EXIT* \n");
}

사용했던 라이브러리는 참조 바란다.

  "devDependencies": {
    "gulp": "^3.9.1",
    "gulp-clean": "^0.3.2",
    "gulp-exec": "^2.1.3",
    "gulp-util": "^3.0.8",
    "iconv-lite": "^0.4.17",
    "lodash": "^4.17.4"
  }

행정구역 코드 별로 파일을 다 분리해내면 이제 원하는 맵을 그릴 준비가 된다.

# 이렇게 최종적으로 행정구역 코드 별로 쭉 생성하면 된다.
$ tree
├── ctprvn
├── ctprvn.json
├── emd
│   ├── 11110.json
│   ├── 11140.json
│   ├── 11170.json
...생략
│   ├── 48870.json
│   ├── 48880.json
│   ├── 48890.json
│   ├── 50110.json
│   └── 50130.json
├── emd.json
├── sig
│   ├── 11.json
│   ├── 26.json
│   ├── 27.json
│   ├── 28.json
│   ├── 29.json
│   ├── 30.json
│   ├── 31.json
│   ├── 36.json
│   ├── 41.json
│   ├── 42.json
│   ├── 43.json
│   ├── 44.json
│   ├── 45.json
│   ├── 46.json
│   ├── 47.json
│   ├── 48.json
│   └── 50.json
└── sig.json

3 directories, 270 files

이제 실제 맵을 그려보자

GeoJSON 파일이 준비됐으니 이제 맵차트를 그리면 된다. ㅎㅎ

많은 상용/오픈소스 차트 라이브러리들은 Custom GeoJSON 파일을 읽어서 맵차트를 그릴 수 있다. 작업 할때 리서치를 잠깐 했었는데 대표적으로는 아래의 차트 라이브러리들이 가능하다.

• 상용
  • AMCHARTS - using-geojson-maps-amcharts
  • highcharts - Custom GeoJSON maps
  • AnyChart - Custom GeoJSON Maps
• 오픈소스
  • ECharts - Population Density of HongKong(2011) 예제
  • D3, Leaflet

돈만 있다면야 상용 라이브러리 사용도 충분하겠지만 오픈소스로도 구현은 가능하다.

지금이야 D3 공부가 어느 정도 되서 D3가 편하겠지만 만들 당시에는 익숙하지 않아서 바이두에서 만든 ECharts 로 작업을 진행했었다.

얘도 참 물건인 것 같고 잘 만들었다. 제공해 주는 예제도 엄청 많아서 쉽게 적용 가능하다.

간단하게 갭수익율로 히트맵을 시도/시군구/읍면동 단위로 그릴 수 있고 GeoJSON이 있으니 쉽게 네이버맵 위에도 레이어를 그릴 수 있다.

위처럼 원하는 방향데로 히트맵 그리는데는 ECharts 정도로 충분했다.

ECharts를 사용하는 방법은 별도의 설명이 필요 없을 정도로 위에 적어놓은 예제에 자세히 나와있어서 따로 모듈 사용법을 설명할 필요는 없을 것 같고 사용했던 모듈은 참고로 올려둔다.

<script type="text/javascript" src="/static/echarts/echarts.js"></script>
<script type="text/javascript" src="/static/echarts/chart/line.js"></script>
<script type="text/javascript" src="/static/echarts/chart/map.js"></script>
<script type="text/javascript" src="/static/js/region.min.js"></script>

...
<div class="mapview">
  <div id="mapChart" class="feature-box light-gray-bg bordered text-center" style="height:350px;">
  </div>
</div>
...

...
MapChart.drawMapChart('mapChart');
...

---

/**
 * **** 맵 차트 모듈
 * Created by hkwon on 2017-05-12.
 */

// 지역중심 맵 차트 모듈
(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    define(["jquery", "lodash"], factory);
  } else if (typeof module === 'object' && module.exports) {
    module.exports = factory(require("jquery"), require("lodash"));
  } else {
    root.MapChart = factory(root.$, root._);
  }
}(this, function ($, _) {
  var MapChart = {};

  var version = '1.0';

  //-----
  //--variables
  var type, code;
  var seriesData = [];
  var geo;
  var myChart;
  var ecConfig;

  // ECharts global toolbox option
  var toolboxOption = {
    show: true,
    orient: 'vertical',
    x: 'right',
    y: 'center',
    feature: {
      mark: {
        show: true,
        title: {
          mark: '마킹',
          markUndo: '마킹 원복',
          markClear: '마킹 제거'
        }
      },
      dataView: {
        show: true,
        readOnly: false,
        title: '데이터 보기',
        lang: ['a', 'b', 'c']
      },
      dataZoom: {
        show: false,
        title: {
          dataZoom: '확대',
          dataZoomReset: '줌 취소'
        }
      },
      magicType: {
        show: false,
        title: {
          line: 'line',
          bar: 'bar',
          stack: 'statck',
          tiled: 'tiled',
          force: 'force',
          chord: 'chord',
          pie: 'pie',
          funnel: 'funnel'
        },
        option: {
          // line: {...},
          // bar: {...},
          // stack: {...},
          // tiled: {...},
          // force: {...},
          // chord: {...},
          // pie: {...},
          // funnel: {...}
        },
        type: []
      },
      restore: {
        show: true,
        title: '새로고침'
      },
      saveAsImage: {
        show: true,
        type: 'png',
        title: '이미지로 저장',
        lang: ['저장']
      }
    }
  };

  // ECharts global data range option
  var dataRangeOption = {
    min: 1,
    max: 3,
    text: ['높음', '낮음'],
    realtime: false,
    precision: 1,
    padding: 10,
    calculable: true,
    color: ['#EA1583','#EC3A88','#F16785','#F48F80','#F8AA6F','#FCCF50', '#FCF135']
  };

  // ECharts global data range option
  var tooltipOption = {
    trigger: 'item',
    showDelay: 0,
    transitionDuration: 0.2,
    formatter: function (params) {
      console.log('tooltip ' + params.seriesName);
      var seriesName = params.seriesName ? params.seriesName : '단지 없음';
      return seriesName + '<br/>' + params.name + ' : ' + params.value;
    }
  };

  //-----
  //--utilities function

  var findCodeByName = function (name) {
    var code;

    for (key in geo.features) {
      if (geo.features.hasOwnProperty(key)) {
        if (geo.features[key].properties.name === name) {
          if (type === 'ctprvn') {
            code = geo.features[key].properties.CTPRVN_CD;
          } else if (type === 'sig') {
            code = geo.features[key].properties.SIG_CD;
          } else if (type === 'emd') {
            code = geo.features[key].properties.EMD_CD;
          }
        }
      }
    }

    return (code + "0000000000").slice(0, 10);
  };

  //-----
  //--dom handler

  //-----
  //--event handler
  var addEventHandler = function () {
    // Event 등록
    myChart.on('click', function (params) {
      var name = params.name;

      window.location = '/region/' + findCodeByName(name);
    });
  };

  //-----
  //--private methods
  var loadAndDrawMapChart = function(id) {
    var dataArr = [];

    if (regionJsonDatas) {
      for (var k in regionJsonDatas) {
        var dataObj = {};

        dataObj['name'] = regionJsonDatas[k].lowest_area_nm;
        dataObj['value'] = (regionJsonDatas[k].roi === '-') ? 0 : parseFloat(regionJsonDatas[k].roi);

        dataArr.push(dataObj);
      }

      // data range max,min 계산
      dataRangeOption.max = parseFloat(_.maxBy(dataArr, 'value').value);
      dataRangeOption.min = parseFloat(_.minBy(dataArr, 'value').value);

      console.log('max' + dataRangeOption.max);
      console.log('min' + dataRangeOption.min);
    } else {
      console.log('데이터가 존재하지 않습니다.');

      return false;
    }

    seriesData[0] = {
      name: '****',
      type: 'map',
      roam: true,
      mapType: 'CUSTOM_MAP',
      itemStyle: {
        normal: {label: {show: false}},
        emphasis: {label: {show: true}}
      },
      data: dataArr,
      nameMap: {}
    };

    configureECharts();
    drawEChartsMap(id);
    addEventHandler();
  };

  // Configure ECharts for module loader
  var configureECharts = function () {
    console.log('initializeChart');

    require.config({
      paths: {
        echarts: '/static/echarts'
      }
    });
  };

  // Draw ECharts map
  var drawEChartsMap = function(id) {
    require(
      [
        'echarts',
        'echarts/chart/map',
      ],
      function (ec, theme) {
        // Initialize after dom ready
        myChart = ec.init(document.getElementById(id));

        // code 별 map data load
        require('echarts/util/mapData/params').params.CUSTOM_MAP = {
          getGeoJson: function (callback) {
            $.getJSON('/static/geojson/' + type + '/' + code + '.json', callback)
              .done(function (data) {
                geo = data;
              });
          }
        }

        var option = {
          title : {
              text : '****'
          },
          tooltip : tooltipOption,
          toolbox: toolboxOption,
          dataRange: dataRangeOption,
          series : seriesData
        };

        // Load data into the ECharts instance
        myChart.setOption(option);

        ecConfig = require('echarts/config');
      }
    );
  };

  // uri에 표현된 행정동 code에 따른 type 판별
  // geojson에 기재된 코드 체계로 변환
  var setType = function() {
    var matchType;
    var uri = $(location).attr('pathname');

    var re = new RegExp("\/region\/(.*)");
    var match = uri.match(re);

    if (match[1]) {
      if (match[1].substring(2, 10) === '00000000') {
        code = match[1].substring(0, 2);
        type = 'sig';
      } else if (match[1].substring(5, 10) === '00000') {
        code = match[1].substring(0, 5);
        type = 'emd';
      } else if (match[1].substring(9,10) === '00') {
        type = 'apt';
      }
    } else {
      code = 'ctprvn';
      type = 'ctprvn';
    }
  };

  //-----
  //--public methods

  // 차트 그리기
  MapChart.drawMapChart = function(id) {
    setType();
    loadAndDrawMapChart(id);
  };

  // 맵차트 반환
  MapChart.getChart = function() {
    return myChart;
  }

  return MapChart;
}));

비슷한 기능이 필요하다면 ECharts로도 충분히 원하는 방향으로 그려볼 수 있을 것 같다.

개인적으로 D3에 요새 심취해 있어서 시간이 된다면 D3로 된 예제도 만들어 볼까하는데.. 과연.. 귀차니즘과 시간이 되려나 싶긴하다.

그래도 화이팅~

XenServer 구성 시 설치할 os의 iso 이미지 attach 하는 가장 기본적인 방법은 cifs 를 사용해서

윈도우 머신의 공유 폴더를 attach하여 사용하는 방법이 있다.

근데 요상하게 cifs가 잘 안잡히거나 하는 경우에는 xenserver host에 local iso library를 만들어 사용하면 된다.

큰 파일의 ISO Library 만들기

Xenserver 호스트의 루트 파티션은 기본이 아마 4G로 되어 있으므로 sr-mount 되어 있는 파티션에 xenserver storage를 만들면 된다.

[root@localhost ~]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              4127440   2012800   1904976  52% /
none                    954268       112    954156   1% /dev/shm
/opt/xensource/packages/iso/XenCenter.iso
                         57216     57216         0 100% /var/xen/xc-install
/dev/mapper/XSLocalEXT--bb2de5e6--d46d--c812--a949--dd0934750a62-bb2de5e6--d46d--c812--a949--dd0934750a62
                     3829180512 866521236 2768148020  24% /var/run/sr-mount/bb2de5e6-d46d-c812-a949-dd0934750a62 <-- 여기에 만들면 된다.

스토리지 location을 아래와 같이 생성하고

$ mkdir /var/run/sr-mount/bb2de5e6-d46d-c812-a949-dd0934750a62/iso_storage

다음과 같이 스토리지를 생성하면 된다.

xe sr-create name-label=ISO_Storage type=iso device-config:location=/var/run/sr-mount/bb2de5e6-d46d-c812-a949-dd0934750a62/iso_storage device-config:legacy_mode=true content-type=iso

요렇게 xencenter에서 보면 새로운 iso library가 생성된것이 보인다.

인터넷이 되는 환경이라면 wget으로 파일을 직접 받음 되고 ftp로 해당 location에 이미지를 넣고 storage 옵션에서 rescan을 하면 iso 이미지가 보이게 된다.

이제 VM 생성 시 해당 iso 이미지를 선택해서 guest os 설치하면 된다.

DVD도 없고 큰 파일의 iso(everything 버전 등)들을 설치하기 힘든 환경인 경우 위처럼 ISO Library를 생성하고 사용하면 좋을 듯 하다.

최근에 몇몇 프로젝트를 Thymeleaf를 템플릿 엔진으로 선정해서 진행을 하고 있다.

일단 기존의 개발자들이 JSP & JSTL을 사용하는 것에 너무 익숙하다보니 도입을 하는게 쉽진 않았으나 Spring Framework와 궁합도 잘 맞아보이고 개인 프로젝트를 몇개 해보니 확실히 도입하는 것이 낫다 싶어서 최근 프로젝트는 일단 Thymeleaf로 진행을 하고 있다.

몇가지 살짝 아쉬운 기능들

Link URL Expressions을 사용한 th:href attribute를 사용함에 있어서 request에 넘어온 query string을 그대로 다음 링크로 넘겨야되는 경우가 발생하고는 하는데 전체 query string을 받아오는 기본 기능은 존재하지 않는다.

몇가지 방법이 존재하긴 하지만 다 맘에 들진 않는다.

<div th:with="currentUrl=(${#request.getRequestURI() + '?' +
    #strings.defaultString(#request.getQueryString(), '')})">
  <a th:href="@{${currentUrl}(myparam=test)}">click here</a>
</div>

javax.servlet.http.HttpServletRequest를 직접 액세스할 수 있는 #request 표현을 사용하면 대충 원하는 기능을 만들어 볼순 있다.

하지만 파라미터가 중복인 경우에는 중복해서 계속 추가되고 무엇보다 저걸 매번 링크마다 써주는 아주 맘에 안드는 상황이 발생한다.

<div th:with="currentUrl=(${@currentUrlWithoutParam.apply('myparam')})">
  <a th:href="@{${currentUrl}(myparam=test)}">click here</a>
</div>

@Bean
public Function<String, String> currentUrlWithoutParam() {
    return param -> ServletUriComponentsBuilder.fromCurrentRequest()
            .replaceQueryParam(param).toUriString();
}

혹은 Function을 만들어서 간단하게 처리할 수도 있지만 역시나 이 방법도 그리 탐탁치 않다.

<span th:with="urlBuilder=${T(org.springframework.web.servlet.support.ServletUriComponentsBuilder).fromCurrentRequest()}"
      th:text="${urlBuilder.replaceQueryParam('p2', '32').toUriString()}">
</span>

org.springframework.web.servlet.support.ServletUriComponentsBuilder를 직접 불러와서 사용하는 방법도 찾아서 시도해보았지만 어느하나 th:with 를 써야하고 매번 링크를 만들때마다 매우 불편한 상황이 발생해서 자주쓰는 기능이다보니..

Thymeleaf 확장 기능을 통해 th:link 라는 새로운 attribute를 만들어서 처리해보기로 했다.

th:link attribute 추가를 위해 Thymeleaf를 확장해보자

관련 레퍼런스(Tutorial: Extending Thymeleaf)와 기존의 확장기능들 소스를 둘러보니 그리 어렵지 않게 기능을 확장할 수 있다.

Dialects and Processors

Thymeleaf Dialects란 새롭게 만들 템플릿의 기능 집합이라고 보면 될 것 같다. Dialect는 다수의 Processors와 Expression을 가질 수 있다.

여기서 얘기하는 Processor는 만들려고 하는 Attribute나 Tag의 기능을 실제 처리하는 로직이고, Expression은 #request처럼 ThymeLeaf의 기본 표현식을 확장하는 것을 얘기한다.

레퍼런스에는 org.thymeleaf.dialect.IDialect를 구현해서 사용하면 된다라고 나와 있고 아래와 같은 sub interface들을 몇가지 제공한다.

• IProcessorDialect for dialects that provide processors.
• IPreProcessorDialect for dialects that provide pre-processors.
• IPostProcessorDialect for dialects that provide post-processors.
• IExpressionObjectDialect for dialects that provide expression objects.
• IExecutionAttributeDialect for dialects that provide execution attributes.

만드려는 확장의 기능에 맞게 적절한 인터페이스를 선택하면 된다.

Processors는 Dialect와 마찬가지로 org.thymeleaf.processor.IProcessor 인터페이스를 구현해서 사용하면 되고

• Template start/end
• Element Tags
• Texts
• Comments
• CDATA Sections
• DOCTYPE Clauses
• XML Declarations
• Processing Instructions

위의 타입에 맞게 알맞은 sub interface를 구현하면 된다.

ExtraLinkDialect 생성

ExtraLinkDialect라는 Dialect를 이제 실제로 만들어보자.

고맙게도 AbstractProcessorDialect라는 IProcessorDialect를 구현한 클래스를 제공해 주고 있다.

package me.hkwon.thymeleaf.dialect;

import java.util.LinkedHashSet;
import java.util.Set;
import me.hkwon.thymeleaf.dialect.processor.LinkAttrProcessor;
import org.thymeleaf.dialect.AbstractProcessorDialect;
import org.thymeleaf.processor.IProcessor;
import org.thymeleaf.templatemode.TemplateMode;

public class ExtraLinkDialect extends AbstractProcessorDialect {
    public static final String NAME = "ExtraLink";
    public static final String DEFAULT_PREFIX = "th";
    public static final int PROCESSOR_PRECEDENCE = 800;
    private String charset;

    public ExtraLinkDialect(String charset) {
        super("ExtraLink", "th", 800);
        this.charset = charset;
    }

    public Set<IProcessor> getProcessors(String dialectPrefix) {
        LinkedHashSet processors = new LinkedHashSet();
        processors.add(new LinkAttrProcessor(TemplateMode.HTML, 
            dialectPrefix, this.charset));
        return processors;
    }
}

간단하다. 새로운 템플릿의 prefix는 th를 사용했지만 원하는 걸로 변경하면 되고 실제 기능들을 담당할 Processors를 추가시켜 주면 된다.

LinkAttrProcessor 생성

아래는 Link 처리를 위해 실제 구현한 LinkAttrProcessor 클래스다. 신규 Attribute를 처리 하기 위해서 AbstractAttributeTagProcessor를 사용했다.

/**
 * Thymeleaf Extra Link Processor
 *
 * @author hkwon
 */
@Slf4j
public class LinkAttrProcessor extends AbstractAttributeTagProcessor {
    public static final int ATTR_PRECEDENCE = 1300;
    public static final String ATTR_NAME = "link";
    private static final char PARAMS_START_CHAR = '(';
    private static final char PARAMS_END_CHAR = ')';
    private static final char EXPRESSION_END_CHAR = '}';
    private static final char PARAMS_DELIMITER = ',';
    private String charset;

    // 생성자
    ...

        @Override
    protected void doProcess(ITemplateContext context,
                             IProcessableElementTag tag, AttributeName attributeName,
                             String attributeValue, IElementTagStructureHandler structureHandler) {
        final RequestContext requestContext = (RequestContext)context.getVariable(SpringContextVariableNames.SPRING_REQUEST_CONTEXT);
        final LinkExpression linkExpression;
        final Object expressionResult;

        if (StringUtils.isEmptyOrWhitespace(attributeValue)) {
            expressionResult = null;
        } else {
            // Get Attribute expression
            linkExpression = (LinkExpression) StandardExpressions.getExpressionParser(context.getConfiguration()).parseExpression(context, attributeValue);

            if (linkExpression == null) {
                expressionResult = null;
            } else {
                if (requestContext.getQueryString() == null) {
                    expressionResult = linkExpression.execute(context);
                } else {
                    // Append whole request parameters to attributeValue
                    URI uri = null;
                    List<NameValuePair> nvp = null;

                    try {
                        uri = new URI(requestContext.getRequestUri() + "?" + requestContext.getQueryString());
                        nvp = URLEncodedUtils.parse(uri, Charset.forName(charset));
                    } catch (URISyntaxException e) {
                        log.error("Passed URI has not valid syntax : " + uri, e);
                    }

                    // Exclude duplication query string
                    AssignationSequence assignationSequence = linkExpression.getParameters();

                    if (assignationSequence != null) {
                        for (Assignation assignation : assignationSequence) {
                            nvp.removeIf(e -> assignation.getLeft().getStringRepresentation().equals(e.getName()));
                        }
                    }

                    final String parameters = nvp.stream()
                            .map(nv -> nv.getName() + "=${'" + nv.getValue() + "'}")
                            .collect(Collectors.joining(","));

                    final StringBuilder sb = new StringBuilder();

                    if (linkExpression.hasParameters()) {
                        // Manipulate expression string with request parameters
                        final int lastIndex = attributeValue.lastIndexOf(PARAMS_END_CHAR);

                        sb.append(attributeValue.substring(0, lastIndex))
                                .append(PARAMS_DELIMITER)
                                .append(parameters)
                                .append(attributeValue.substring(lastIndex, attributeValue.length()));

                    } else {
                        sb.append(attributeValue.substring(0, attributeValue.lastIndexOf(EXPRESSION_END_CHAR)))
                                .append(PARAMS_START_CHAR)
                                .append(parameters)
                                .append(PARAMS_END_CHAR)
                                .append(EXPRESSION_END_CHAR);
                    }

                    attributeValue = sb.toString();

                    expressionResult = EngineEventUtils.computeAttributeExpression(context, tag, attributeName, attributeValue).execute(context);
                }
            }
        }

        structureHandler.setAttribute("href", HtmlEscape.escapeHtml4Xml(expressionResult == null ? null : expressionResult.toString()));
    }
}

특별한 설명은 필요 없을 것 같고 처리는 아래의 순서로 진행했다.

• request에서 query string 얻어오기
• LinkExpression 검증
• LinkExpression에 파라미터 추가
• Expression 재생성
• attribute 설정

좀 해멨던 부분이 ITemplateContext context에서 Request 객체를 얻어오기가 쉽지 않았는데 여기저기 뒤져보니

final RequestContext requestContext = (RequestContext)context.getVariable(SpringContextVariableNames.SPRING_REQUEST_CONTEXT);

처럼 Request 객체를 얻어와서 list에 넣어두고 신규로 들오어는 parameter가 있다면 대체하여 링크를 만들어 내는 로직을 추가했다.

별도의 expression을 만드는 것은 오바하는 것 같고 LinkExpression을 기본적으로 사용하는 것이 맞아 보여서 그렇게 구현을 했고,

표현식 자체가 멀티 파라미터를 @{link(param=1)(param=2)} 처럼 제공해주진 않기 때문에 ) 여부만 파악하면 되므로 위와 같이 처리해보았다.

Dialect Engine에 등록

Spring boot 를 사용한다면 IProcessorDialect 클래스를 구현한 놈은 자동으로 등록해주기 때문에 별다른 설정 없어 Bean을 추가해주면 된다.

@Configuration
public class ThymeleafConfig {
	@Bean
	public ExtraLinkDialect extraLinkDialect() {
		return new ExtraLinkDialect("UTF-8");
	}
}

혹은 SpringTemplateEngine 생성 시 addDialect로 추가해 주면된다.

@Bean
public SpringTemplateEngine templateEngine() {
    SpringTemplateEngine templateEngine = new SpringTemplateEngine();

    templateEngine.setEnableSpringELCompiler(true);
    templateEngine.setTemplateResolver(templateResolver());
    templateEngine.setMessageSource(messageSource);
    templateEngine.addDialect(new LayoutDialect());
    templateEngine.addDialect(new SpringDataDialect());
    templateEngine.addDialect(new ExtraLinkDialect("UTF-8"));

    return templateEngine;
}

사용방법

사용 방법은 아래와 같다.

http://localhost:8080/users?pageNum=2&query=검색어&test=1%26encoding

게시판 목록조회 url을 이렇게 호출한 경우 상세조회 화면으로 가는 링크는

<a th:link="@{/users/__${user.userId}__}" th:text="${user.userId}">아이디</a>

처럼 th:link를 사용했다. 그럼 실제 생성되는 link는

<a href="/users/hkwon?pageNum=2&amp;query=%EA%B2%80%EC%83%89%EC%96%B4&amp;test=1%26encoding">권혁</a>

처럼 생성이 된다. 상세조회 왔다가 다시 목록으로 오는 경우에 검색어 등 계속 끌고 다닐 파라미터가 있는 경우 사용하면 좋다.

페이징 처리시에도 pageNum 파라미터를 추가로 넘기면

<div th:fragment="pagination(page)">
  <nav aria-label="Page navigation">
    <ul class="pagination justify-content-center">
      <li class="page-item" th:class="${page.getPrePage() == 0} ? 'disabled'">
        <a class="page-link" th:link="@{''(pageNum=${page.getPrePage()})}" tabindex="-1" th:if="${page.getPrePage() > 0}">Previous</a>
      </li>
      <li class="page-item" th:each="i : ${#numbers.sequence(1, page.getPages())}" th:class="${page.getPageNum() == i} ? 'active'">
        <a class="page-link" th:link="@{''(pageNum=${i})}" th:text="${i}">1</a>
      </li>
      <li class="page-item" th:class="!${page.isHasNextPage()} ? 'disabled'">
        <a class="page-link" th:link="@{''(pageNum=${page.getNextPage()})}" th:if="${page.getNextPage() > 0}">Next</a>
      </li>
    </ul>
  </nav>
</div>

중복되는 파라미터는 th:link="@{''(pageNum=${i})}" 표현식에 넣은 것 처럼 기존 것은 제외하고 생성되는걸 볼 수 있다.

<nav aria-label="Page navigation">
  <ul class="pagination justify-content-center">
    <li>
      <a class="page-link" href="?pageNum=1" tabindex="-1" )>Previous</a>
    </li>
    <li>
      <a class="page-link" href="?pageNum=1&amp;query=%EA%B2%80%EC%83%89%EC%96%B4&amp;test=1%26encoding">1</a>
    </li>
    <li class="active">
      <a class="page-link" href="?pageNum=2&amp;query=%EA%B2%80%EC%83%89%EC%96%B4&amp;test=1%26encoding">2</a>
    </li>
    <li>
      <a class="page-link" href="?pageNum=3&amp;query=%EA%B2%80%EC%83%89%EC%96%B4&amp;test=1%26encoding">3</a>
    </li>
    <li>
      <a class="page-link" href="?pageNum=4&amp;query=%EA%B2%80%EC%83%89%EC%96%B4&amp;test=1%26encoding">4</a>
    </li>
    <li>
      <a class="page-link" href="?pageNum=3" )>Next</a>
    </li>
  </ul>
</nav>

확장에 굉장히 열려있는 엔진이기 때문에 필요한 기능들은 그때그때 만들어서 써도 무방할 것 같은 느낌이다.

전체 사용된 소스는 아래에서 확인할 수 있다.

https://github.com/hkwon77/thymeleaf-extra-link

참조

• http://www.thymeleaf.org/doc/tutorials/3.0/extendingthymeleaf.html#processors
• http://www.thymeleaf.org/doc/articles/sayhelloextendingthymeleaf5minutes.html

장장 네시간(?)의 삽질 후에 혹시나 다른 누군가가 비슷한 곤란한 상황에 빠졌을 때 도움이 되길 바라면서 포스트를 써본다.

사내에서 솔루션 관련 내부 프로젝트 구성 중에 간단하게 배포해야하는 서비스 구조가 있어서 그 동안 눈으로만 훑어봤던 Spring Boot를 사용하기로 맘 먹고 레퍼런스 보면서 하나씩 붙여나가는 도중에 예기치 않게 i18n 구성 중에 메시지 파일을 계속 못 불러오는 불상사가 일어났다.

결론부터 말하자면..

결론적으로 말하자면 messages 파일의 이름에 . 이 들어가면 로딩이 안된다.

비극의 시작

레퍼런스를 보면서 차근히 하라는 데로 시작했다.

spring:
  messages:
    always-use-message-format: false
    cache-seconds: -1
    basename: i18n/message, i18n/error.message # 이 부분
    encoding: UTF-8

레퍼런스에 따르면 Spring Boot의 MessageSourceAutoConfiguration을 사용한 INTERNATIONALIZATION 설정은 아래와 같이 진행할 수 있다.

# INTERNATIONALIZATION (MessageSourceAutoConfiguration)
spring.messages.always-use-message-format=false # Set whether to always apply the MessageFormat rules, parsing even messages without arguments.
spring.messages.basename=messages # Comma-separated list of basenames, each following the ResourceBundle convention.
spring.messages.cache-seconds=-1 # Loaded resource bundle files cache expiration, in seconds. When set to -1, bundles are cached forever.
spring.messages.encoding=UTF-8 # Message bundles encoding.
spring.messages.fallback-to-system-locale=true # Set whether to fall back to the system Locale if no files for a specific Locale have been found.

message 파일을 하나로 가져가지 않고 여러개 사용할 경우 comma로 구분해서 다수의 basename을 설정하여 사용할 수 있다.

해서 위 yaml 설정 처럼 당당하게 i18n/error.message을 추가하였다.

    basename: i18n/message, i18n/error.message

죽어도 파일 로딩을 못하는 것이다. --debug 설정을 걸어도 항상 맨 앞에 있는 basename만 읽어오는 것 처럼 보인다.

   MessageSourceAutoConfiguration matched:
      - ResourceBundle found bundle URL [file:/C:/app/workspace/xstream-portal/src/main/resources/i18n/message.properties] (MessageSourceAutoConfiguration.ResourceBundleCondition)
      - @ConditionalOnMissingBean (types: org.springframework.context.MessageSource; SearchStrategy: current) did not find any beans (OnBeanCondition)

WebMvcConfigurerAdapter 으로 설정이 추가되면 혹여나 MessageSourceAutoConfiguration이 무시되고 문제가 되는 것인가?

혹시나 해서 AutoConfiguration 문제인가 해서 MessageSourceAutoConfiguration을 exclude하고 직접 아래처럼 설정해봐도

@EnableAutoConfiguration(exclude = {MessageSourceAutoConfiguration.class})
...
@Value("${spring.messages.basename}")
String messagesBasename = null
...
@Bean
public ReloadableResourceBundleMessageSource messageSource(){
   ReloadableResourceBundleMessageSource messageSource = new ReloadableResourceBundleMessageSource();
   messageSource.setBasenames(messagesBasename.split(","));
   messageSource.setDefaultEncoding(messagesEncoding);
   messageSource.setCacheSeconds(messagesCacheSeconds);

   return messageSource;
}

여전히 못불러오고 basename의 convention 문제인가 해서 아래처럼 다 해봐도..

spring:
  messages:
    basename: i18n/message, i18n/error.message
    basename: classpath:i18n/message, classpath:i18n/error.message
    basename: classpath:/i18n/message, classpath:/i18n/error.message
    basename: classpath*:i18n/message, classpath*:i18n/error.message
    basename: classpath*:/i18n/message, classpath*:/i18n/error.message

여전히 못불러오는 것이다 ㅎㅎㅎㅎㅎㅎㅎㅎ 이쯤되면 정신이 혼란해지고 구글은 더 이상 조력자가 되지 않는 상황이 발생한다.

아예 처음부터 다시 시작해봐도. 잘되어 있는 sample 프로젝트르 받아서 변경해봐도.. 안된다..

마음을 다시 한번 가다듬고.. 근데.. 설마.. 혹시나 해서 관련된 소스를 까보기 시작하니..

final String resourceName = toResourceName(bundleName, "properties");

ResourceBundleMessageSource에서 Bundle 파일 생성 시 toResourceName 메소드가 호출된다. 따라가보니...

public final String toResourceName(String arg0, String arg1) {
    StringBuilder arg2 = new StringBuilder(arg0.length() + 1 + arg1.length());
    arg2.append(arg0.replace('.', '/')).append('.').append(arg1);
    return arg2.toString();
}

쉣!! .을 path 구분자로 변환한다 ㅠㅠㅠㅠㅠㅠ

마음을 가다 듬고 .이 들어가지 않는 basename으로 변경하니 잘 안다. 아주 잘 읽어온다.

spring:
  messages:
    basename: i18n/message, i18n/error, # 열받아서 삼십개 정도 더 붙여봤는데 잘 된다 ㅋㅋㅋ

└── resources
    ├── application.yml
    ├── banner.txt
    ├── i18n
    │   ├── error.properties
    │   ├── error_ko_KR.properties
    │   ├── message.properties
    │   └── message_ko_KR.properties
    ├── logback-spring.xml
    ....

i18n 설정 시 주의사항

• basename의 resource 이름에는 .를 넣지 않는다. 앞으로 다른 파일 만들때도 안 넣을 것 같다. ㅜㅜ
• Spring과 Spring Boot의 basename Convention은 약간 상이하다. classpath prefix가 붙지 않는다.
• 위처럼 아무 내용이 없더라고 basename.properties 파일을 생성한다.
• --debug 옵션의 autoconfiguration report는 모든 정보가 다 나오지 않는다.
• 삽질하지 말고 안될때는 기본부터 천천히..

거의 1년을 달려온 프로젝트가 저번주 금요일을 기점으로 오픈하면서 안정화 단계에 접어들고 있다.

덕분에 요 몇달간 블로그며 스터디며 개인생활이건 또 뒷전이 되버리는 상황이 벌어지고 말았다.

SI생활을 15년 가까이 해오면서 프로젝트 규모가 커지면 커질수록 오픈이 가까와지면 가까와 질수록 야근도 많아지고 , 먹는 욕도 많아지고.. 운동은 열심히 한다고는 하는데 체력도 예전 같지 않은지 몸도 마음도 더욱더 지쳐 만 간다.

해를 더해 갈수록 왜 오픈은 더 힘들어 만 지는걸까.. 개선의 여지는 진짜 없는것인가?

프로젝트 막바지 도대체 왜 이렇게 힘든걸까

그간 내가 직접 수행하거나 지켜봐왔던 프로젝트를 돌이켜보면, 정말 막판에 개발자들끼리 아름다운 Double욕이 오고가는 비참한 프로젝트부터 목표 했던 고지는 한라산인데 달나라까지 가야하는 수 없이 실패되거나, 맥빠지는 프로젝트들, 모두 광인이 되어 마치 영화 매드맥스의 광활한 사막에서 서로 죽고 죽이기를 반복하며 누가 악이며 누가 선인지는 중요하지 않는 네버 엔딩의 미친 프로젝트 들까지 수 없이 많은 프로젝트를 지켜봐 왔지만.. (물론 내가 수행한 프로젝트는 이정도 급은 아니었다 ^^;)

이러한 실패된 프로젝트 들의 대표적인 실패 요인을 개인적으로 분석해 보면 다음과 같다고 생각 된다.

• 처음부터 잘못된 만남(계약)
• 요구사항의 끊임 없는 변경
• 개발방법론 선정의 문제
• 내부 갈등, 리더쉽의 부재
• 제대로된 아키텍처, 개발스킬의 부재
• 고객과의 관계(정치)
• 외부요인 (법이나 제약, 규제 등의 변경)
• ...

여기에 무엇보다 이 여러가지 문제점 들에서 공통적으로 엮여 있는 가장 큰 문제점은 바로 ==제대로된 커뮤니케이션의 부재==가 아닐까 한다.

처음부터 잘못된 만남(계약), 요구사항의 끊임 없는 변경

그렇다! 난 너와 만나지 말아야 했어... 망하는 프로젝트의 전형은 아마 시작부터 잘못된 프로젝트 일 것이다.

공공SI사업의 경우에는 FP(Function Point, 기능점수)를 기반으로하는 나름 명확한 요구사항을 RFP에 담고 시작한다.

FP가 정답은 아닐지언정 어느 정도는 프로젝트 비용 산정에는 무리는 없을 수도 있다. 하지만 문제는 RFP 작성 당시 그 매우 짧은 시간에 50~100억 규모의 프로젝트의 전체 기능을 산정하기도 힘들 뿐더러 발주까지 한달 안에 그 규모를 파악하기도 매우 힘겨운건 명백한 사실이다.

발주 이후 사업자야 RFP 내용만 믿고 시작했지만, 고객의 한마디 한마디에 광인이 되어 가는 것이다.

사실 이건 내가 생각한 기능이 아냐 - 최모 고객

요구사항을 내는 부서가 IT를 잘 몰라서 그랬어 - 권모 고객

위에서 그건 아니래 - 김모 고객

다음 사업 하기 싫어? - Double욕 나오는 고객

내일이 오픈이니까 이건 해줘야지 - 와.. x발..

요구사항은 변경 될 수 있는 것이 당연하다. 하지만 문제는 변경의 규모는 책정된 비용 안에서 소화할 수 있느냐 없느냐가 판단되어야 한다.

요구사항 변경은 적절한 절차와 승인을 거쳐 변경 관리 되야 하는 것은 누구나 아는 사실이지만, 현실을 그렇지 않은 경우가 허다하다.

고객 입장에서는 "책임"의 소지가 있기 때문에 매우 애매모호한(이건 해야되는건지 안해야되는건지 판단 불가) 요구사항을 내기 일쑤고, 오픈이 내일인데 자기 입지를 위해 무리한 요구사항을 남발한다거나, IT를 진짜 잘 몰라서 구글이나 네이버 같은 사이트를 만들어내라는 요구사항을 아주 쉽게 던지는 경우도 많다.

회사 입장에서는 신규 고객 사이트의 발굴을 위해 무리한 입찰과 함께 다음 사업의 발판을 위한 프로세일즈랍시고 과도한 요구사항 변경과 추가 요구사항에도 도덕경에서 말하는 대원경지(大圓境智)를 이루어 모든 것을 다 받아 들이는 자비심을 무한히 베푸는 경우도 비일비재하다.

프로젝트 관리 방법론!?

SI현장에서는 아직도 수많은 프로젝트들이 전통적 폭포수 방법론을 기반으로한 변형된 방법론을 사용하고 있다. 최근에는 애자일 프로세스를 도입한 프로젝트들도 나오긴 하는 것 같긴한데 여전히 규모가 큰 프로젝트들은 폭포수 방법론을 기반으로 하는 방법론을 대부분을 사용하고 있다.

폭포수 방법론의 가장 큰 단점은 프로젝트 초기에 모든 요구사항과 일정, 자원에 대한 정의가 이루어지기 때문에 단계가 끝나고 다음 단계로 이전될 때 변경사항에 대해 능동적으로 대처하기 매우 힘들다는 것이다.

내가 생각하는 폭포수 방법론의 가장 큰 단점은 바로

개발에 들어가기 시작한다면 모든 변경사항은 위협이 되버리고 만다.

거기에 개발이 끝나갈 무렵에 요구사항 변경은 생각만 해도 왕짜증이 밀려올 정도로 스트레스가 되는 것이 현실이다.

제대로된 아키텍처, 개발스킬의 부재

뼈대가 훌륭하게 이루어져 있는 항공모함은 비바람이 몰아 쳐도 먼바다에서 묵묵히 임무를 수행해낸다. 프로젝트도 마찬가지 프로젝트 초기부터 견고한 아키텍처 설계에 힘쓰고, 변경에 능동적으로 대처해야 한다.

하지만 SI프로젝트의 현실은 그렇지 않다. 대규모 레거시 시스템의 유지/보수 사업이라던지 전사업의 남기고간 찌꺼기들 때문에 영롱하고 견고한 새로운 아키텍처를 설계하고 유지하기란 정말 쉽지 않다.

만들어내는 서비스나 프러덕트가 제대로 동작하는 것에는 관심 밖인 사업의 PM이나 관리자의 입장에서는 무엇보다 안전하게 프로젝트를 마치는 것이 지상 최대의 과제이기 때문에 더더욱 아키텍처의 변경은 힘들다.

머릿수 채우기에 급급한 외주 개발자들의 투입과 투입 된 개발자들 또한 이전 세대의 기술로만 계속 개발해 와서 새로운 개발 패러다임의 변화에 적응하지 못하고 갖혀 있는 경우가 허다하고, 계속되는 야근에 "더 이상 이 길이 나의 길인가" 혹은 "이 생활이 원래 이렇지"라는 고민만 깊어져 가는 것이다.

그래서 결국 사람..사람..그리고 사람..

프로젝트가 산으로 가는 이유에 대해서 주저리 주저리 말이 많았지만, 결국엔

프로젝트도 결국은 사람이 만드는 것이다.

우리 모두 슈퍼히어로는 아니기 때문에 아니 설령 아이언맨이나 캡틴 아메리카도 외계인의 침공엔 혼자서는 역부족이지 않을까.

요구사항 협상 실패, 고객에게 맥 없이 끌려다니기, 개발자들의 원성, 프로젝트 관리 실패...

이 모든 문제는 결국 커뮤니케이션 의 부재라고 생각된다.

어떻게 하면 문제를 해결 할 수 있을까? 치열하게 고민하고 또 고민하고 솔루션을 만들어 내는 고통스러운 작업들이 결국 프로젝트의 성공을 이끌어 내지 않나 싶다.

제대로된 RFP의 작성, 요구사항의 관리, 고객과의 협상, 견고한 아키텍처 설계, 내부 갈등 기타 등등 모든 문제는 상황에 맞는 적절한 대화로 해결이 가능하다고 생각되고, 그 대화라는 것에 집중하고 나가야할 목표에 프로젝트 구성원 모두가 같은 그림을 그릴 수 있는 리더쉽.. 그것이야 말로 프로젝트를 산으로 보내지 않는 키가 아닐까 생각한다.

그렇다면 개선의 여지는 없나?

AA팀 팀장을 하기 이전에는 개발자부터 개발PL까지 십수년간 프로젝트를 계속 해오고 겪어왔지만 한사람 개인의 힘으로는 어려운 상황을 이겨내기 쉽지 않는 것이 사실이다.

그래서 필요한 것이 개발 프로세스고 개발 문화라고 생각한다.

적절한 방법론의 선택

한번 성공한 프로젝트의 방법론이 다음 프로젝트의 성공을 100% 이끌어내진 못한다. 프로젝트마다 고유한 성격을 가지고 있기 때문에 그 프로젝트에 맞는 방법론을 고민해야봐야 한다.

애자일 방법론이 만병 통치약은 아니지만 적극적으로 Best Practice들을 도입해보고 실행해 보는 것도 방법이 될 수도 있을 것 같다.

개발 문화의 정착

효율적인 개발 문화라는건 사실 회사가 만들어 주는건 아니다. 구성원들 스스로가 자각하고 협심하여 만들어내는 것이다.

그러한 행동들을 발현할 수 있도록 만들어주는 장치들을 고민해야 한다.

사실 요새 스타트업들이 이런 무기(개발 문화)로 개발자들 많이 끌어모으고 있는 것 같은데 좋은 아이디어는 살짝 채용 해 보는 것도 방법일 것 같다.

무엇보다 공통의 목표로 이끌 수 있는 리더쉽

위에서 말한 그 무엇보다 프로젝트 구성원을 하나의 목표로 이끌 수 있는 리더쉽 능력 향상이 가장 필요할 것 같다.

나는 사이먼 시넥의 TED 강연(위대한 리더들이 행동을 이끌어 내는 법)을 예전에 보면서 깊은 감명까진 아니지만, 나부터 변화가 필요하다고 느꼈고, 그런 느낌을 주위에 전파하는 것에 주력했던 것 같다.

마무리

주저리 주저리 말이 많았지만 결론은 SI는 이제 그만둬야 하나??? 그럼 난 뭐 먹고 살 수 있을까?? ㅎㅎㅎㅎㅎㅎ

저 좀 데려가주실 분 없으신가요?