[TIL]180219-0225

2 / 24 (토) (Korea Community Day 2018)

1. 차곡차곡 쉽게 알아가는 ElasticSearch와 Node.JS (관련 SlideShare)

ElasticSearch란, 분산형 RESTful 검색 및 분석 엔진으로, 정형/비정형/위치정보/메트릭 등 원하는 방법으로 다양한 유형의 검색을 수행하고 결합이 가능하며, 초당 엄청난 양의 이벤트를 처리할 수 있도록 수평적 확장이 가능한 서비스이다.(JAVA 8 이상, 메모리 4G 이상)

ElasticSearch 색인과정은, Tokenizer가 문자열을 단어 단위로 잘라서 토큰을 만든 후 TokenFilter가 이를 변형(대문자-> 소문자화, a/the 등 삭제)하고, 토큰과 토큰에 관한 정보를 가지고 있는 자료구조로 저장하는 절차(역색인)를 거친다.

ElasticSearch 검색과정은, 사용자 질의를 분석하고 사용자 질의와 일치하거나 유사한 문서를 검색하여 결과를 변환하는 절차를 거친다. 한국어 분석기로는 주로 한나눔, 꼬꼬마, komoran, Mecab, Twitter, 아리랑 등이 있으며, 발표자는 Mecab을 사용하였다고 한다. (근거데이터는 영화관 입장권 통합전산망 오픈 api을 활용)

구체적으로 indices API를 사용하여 인덱싱을 하고 조회하는 과정들은 직접해봐야 알 것 같다. 발표자 분께 따로 물어보니 러닝커브는 낮았다고 한다.(그 전에 apache lucene을 따로 학습한 적이 있긴하지만, 요새 자료도 많고 해서 본인이 생각하기에 금일 시연한 정도는 elasticsearch만 3개월정도면(물론 풀타임은 아니고..) 가능할꺼 같다고..) 차주에 자바카페 모임관련 공지가 나온다고 하니 한번 봐봐야겠다.

2. IntelliJ IDEA만으로 개발하기

아, 정말 기대없이 이동욱님만 보러갔다가 "오오~"하다가 나왔다 ㅋㅋ

IDE == 통합개발환경.. 발표자분이 지적한대로 통합개발환경에 대해 그동안 잘못 이해하고 있었고 각 툴들을 text editor 수준으로만 쓰고 있던 것 맞다. 그리고 IntelliJ의 생산성에 놀랄 수 밖에 없었다. 그리고 깨알같은 jojoldu translator.. ㅎㅎ 

IntelliJ는 회사 지원을 받을때까지는 아무래도 비용문제로 사용하기는 힘들거 같지만.. 흠..

3. What's new in MYSQL 8.0 (관련 SlideShare)

역시, 별 기대없이 들어갔다가 많이 놀랐던 시간이었다.(솔직히 거의 이해 못했다 ㅠ.ㅠ)

우선 Mobility friendly.. GIS에 대한 지원이 강화되었고 unicode를 default character set으로(utf8mb4)하여, 퍼포먼스가 더 증가하였다고 한다. 인상적인 부분은 기존 5.7 에 있었던 st_distance()를 이용한 거리 계산이 더 개선이 되었다고 하는 부분이었는데, st_distance도 이 날 처음 알았던지라..(지번 조회 검색기능시에 해당 기능을 어떻게 구현할지 고민했었는데, 역시 이미 기능이 있었다.)

두번째로, Developer First + Data Driven + Scalable Stable.. JSON 데이터 타입 및 JSON 함수 사용이 가능해졌고 flexible schema 등등.. 데이터 엔지니어 분은 spark 등 덕분에 이런 형태의 쿼리가 익숙하다고는 하다던데.. 흠..

그외로 기억나는 것들은 window 함수(통계, 랭킹 등), 그리고 recursive CTE..(전에 직접 재귀쿼리를 짰었는데 ㅠ.ㅠ) 그리고 invisible indexes라고 옵티마이저로부터 인덱스를 숨겨서 인덱스에 대한 임시삭제 혹은 단계별 추가가 가능해졌다고 하는데, 인덱스 무효처리와는 달리 옵티마이저로부터만 숨기고 인덱스 유지관리에는 영향을 주지 않는다고 한다. set session variables라고 쿼리 실행중에 세션 레벨의 변수를 변경할 수 있도록 hint 문에 옵션 SET_VAR를 추가한다던가 / set persistence 세팅으로 글로벌 변수 변경시 리스타트없이 적용이 가능해졌던 부분 / Performance schema indexes(퍼포먼스 성능지표 수집이 가능)이 물리적 인덱스를 내부에서 유지관리하지 않아 부하가 감소되었고 더 효율적인 실행 플랜 선택이 자동으로 가능해졌다는 부분 / ERROR 통계 테이블(By Account, Thread 등등) / Histogram (latency 통계) / Transactional Data dictionary(innodb로 메타데이터를 관리하여 파일시스템에 의존하지 않아 OS 호환성이 향상됨) / MySQL Role (set of ACLS !!) / MySQL innodb cluster architecture 등등등.. 뭔가 Oracle이나 MSSQL의 기능들이 넘어오는 듯한 인상을 받았다. 

그리고 요새는 DevOps 등 이것저것 다하는 사람들 수요가 증대되지만 갈수록 이런 부분들은 다시 시스템으로 대체되고 각 부문에 깊게 아는 사람들과 핵심 비즈니스 로직을 개발하는 fullstack developer들만 남게되지 않을까 하는 생각이 든다. 채찍.. 채찍이 필요하다 ..

2 / 23 (금)

1. 네이버 오픈소스 세미나

왜 오픈소스에 시간을 소비하는가?

재미? 보람? 

일단 공통적인 인상은, 스펙을 위해 시작했다기보다는 개발을 하다보니 자연스럽게 오픈소스 에 참여하게 되었다는 것이었다. (부자들이, 자신의 길을 걷다보니 돈은 자연스럽게 따라온다고 하는 맥락과 비슷한..ㅡㅡ?)

요인이야 어쨋든, 발표자들이 오픈소스 생태계에서 얻었다고 생각하는 부분은,

(회사처럼 일정이 짜여지고 자주 모이는 것이 아닌 느슨한 협업관계가 이루어지다보니)커뮤니케이션의 방법, 협업의 방법과 중요성, 테스트코드의 중요성(누가 수정할지 모르니 정말 중요하다고 한다. 테스트가 없으면 아에 받지도 않는다고..), 지속적 통합 및 배포, 코드 품질관리(lint, convention) 등이라고 한다.

그렇다면 무엇을 어떻게 해야하는가?

오픈소스참여라는 것이 뭔가 특별하고 거창한 것은 아니다.

소프트웨어 사용, 홍보(기술블로그 등), 번역, 리포팅(오탈자 및 버그 등), 문서화, 코드제출 순으로 참여도가 나뉠텐데, 발표자들도 다들 오탈자 리포팅, 버그 리포팅, 사용중에 필요한 기능 개발 후 PR 순으로 참여해왔던것 같다.

github 프로젝트들의 commit수를 보면 알 수 있듯, 생각보다 메인테이너 몇명에 의존성이 큰 경우들이 많아(bus factor), 이슈를 리포팅하는 것 또한 소스코드 기여 못지않게 중요한 기여가 될 수 있다. 이슈보고를 할 때는 재현 가능한 예제와 상황을 제공해야 하며, 자신의 이슈를 빨리 처리해달라고 요청하지는..(메인테이너들이 지치지 않도록.. 다들 상상이상으로 바쁘다고 한다. 유명 프로젝트의 경우 하루에 100개 이상의 이슈를 받는데, 보통 오픈소스 참여는 부업으로 하는 사람들이 많으므로..)

그리고 문서번역의 규칙을 숙지하고, 이미 진행중인지에 대한 여부도 이슈를 통해 확인하는 것이 좋다.

추가적으로, 기억나는 부분은 egjs 오픈소스화하는 과정에서, 가이드 문서의 중요성(없으면 이슈트래킹도 안될 뿐더러, 요새 오픈소스 경쟁도 심해 사용 자체도 안한다는..)과 Pull Request 단위 줄이기(리뷰를 의미있게 하기 위한 조건으로, 되도록이면 1이슈 1PR이 좋다고 함.)이다.

행사를 진행하셨던 분께서 조언하신대로, 이날 끝나고 집에와서 egjs를 fork해서 보다 README의 Link 중 안맞는 부분이 있어서 수정해서 pr을 보내보았다.(merge가 될런지는 모르겠지만..)

2 / 21 (수)

1. Spinnaker

평소에 SNS상으로만 자주 접했던 분들을 뵐 수 있었던 시간이었다. (주니어는 나밖에 없는듯한 ㅡㅡ??)

관련 내용 정리는 주말에 해야겠다. 하는김에 애매한 개념, 툴 분류 작업도 같이해서 포스팅하는게 나을거라 판단했다.

spinnaker은 Netflix에서 개발한 OpenSource로, multi-cloud 환경을 대상으로 CD를 도와주는 도구이다.

한 눈에 들어오는..

간단하게 spinnaker 장/단점만 소개하자면 우선 장점은,

1. 배포 현황 파악이 쉽고 UI visualization이 좋다. 

    아, 좋다. 정말 좋다. 

    인프라 구축 및 learning curve가 어느정도일지는 모르겠으나, 

    한번 구축해놓고 나면 이후 배포작업은 클릭 몇번이면 되고 진행상황도 직관적이다. 

    (발표자의 회사도 현재 실 배포작업은 Dev팀에서 직접하고 있다고 한다.)

2. 자동화 (각 종 CM tool / CI tool 활용하기 편리하여 Continuous Delivery 구축이 가능)

3. OpenSource여서 Multi-Cloud(AWS든 GCP든간에) 환경에서 VM을 spinnaker로 중앙제어가 가능하다.

4. 무엇보다 큰 장점은 Deploy & Rollback이 매우 쉽고 빠르다(물론 AMI 생성하는데 드는 시간 자체는..)

단점은, 

1. 복잡한 설정 적용(최신버전들은 hal command line tool을 이용해 쉬워진 편이라고 하니, 이건 직접해봐야 알듯.)

2. learning curve가 높음(CM tool / CI tool / public cloud 모르면.. ㅡ.ㅡ)

3. 작은 규모의 서비스에서 쓰기 적합하지 않음 (발표자의 회사는 r4.xlarge(vCPU: 4, Mem(GiB): 30.5)를 사용중이라 한다.)

    시연을 봐도 VM 10개정도 규모에서는 굳이 쓸 필요가 없어보이긴했다.

    (따라서, 모두의학원 서비스에는 당분간 적용할 일은 없어보이고, 내가 DevOps로 취업하게 된다면 도입하게 될수도 있겠다.)

보기엔 복잡해보이나 시연을 보니 실제 운영시에 사람이 해야할 부분은 별로 없다

2 / 19 (월) ~ 20 (화)

1. Docker 복습

Docker Container에 소스코드 배포부터 LB(nginx) - WEB(node) 연동, docker-compose 까지 복습하였다.(git repo)

지난번엔 EC2(linux)에서 실습했었지만, 이번엔 로컬 PC에 docker-toolbox로 설치하고 작업을 진행했다.

kitematic으로 보니 github과 생태계가 비슷하다는 말을 새삼 느꼈다.

추후 blue-green 배포방식 적용 후 ansible, kubernetes, spinnaker 등을 학습해볼 계획이다.

docker lifecycle에 대한 좋은 그림이 있어 공유해본다.

2. 피닉스패턴의 VM 이미지 타입

OS Image는 정말 OS만 이미지로 생성하고, Configuration Management tool를 이용하여 Software 설치 및 Application 구축을 하므로, 그 과정에서 외부 시스템 장애에 대한 의존성이 크다.

Foundation Image는 기본 환경구축(각 종 Software 설치까지)을 의미하며, Immutable Image는 Application까지 전부 배포하므로 최신 업데이트를 유지하기 좋지만, 빌드시간이 오래걸림, 차라리 Docker를 쓰는게 나을수도 있다.

Snowflakes Server vs Phoenix Server 

Phoenix Server는 변경시 OS 부터 재설치(그래서 피닉스인듯.. 기존 이미지를 재사용하지 않음)

Phoenix Server의 경우 스크립트에 모든 설정 정보가 유지되며, 이 스크립트 코드를 git과 같은 소스관리 시스템을 이용해서 관리하게 되면, 어떤 부분을 누가 어떻게 수정했는지도 추적이 가능해진다.

추가적으로, 몇가지 혼동되는 개념들(Provisioning vs Configuration Management vs Orchestration)에 대해서 정리를 다시 해보고, 각 툴들 장단점을 정리해봐야겠다.