2-3년 전에 회사에 얼마 입사되지 않은 어떤 친구가 조심스럽게 나에게 물었다. 


Q : 왜 번역하시는 거에요? 돈 되는 거에요? 




나는 그 친구에 웃으면서 말했다.


A: 돈이 안되더라구요. 




그러자 그 친구는 정말 궁금한 얼굴로 나에게 해맑게 물었다.


Q : 그럼, 왜 번역하시는 거에요?




나는 답이 있었지만, 머리 속을 다시 정리하며 말하고 싶었다.


A: (잠깐의 침묵)





#--------- 생각 중-----




처음 내가 번역한 이유는 먼가 내가 먼가를 했다는 느낌(상패) 나 자존감을 세우기 위함이 있었다. 


40살에 큰 컨퍼런스에서 발표하고 번역을 시작했다. (번역하는데 머뭇거리던 출판사 실무자를 설득하기엔 컨퍼런스 발표가 효과적이었다)


영어 번역이 얼마나 재미있던지, 일년에 4권을 번역하기도 했다. 그렇게 몇 년동안 회사에서 일하고 밤에는 번역했다. 


번역서가 10권이 넘어가자 처음의 느낌은 온데 간데 없이 사라지고 말았다. 




가끔 나는 왜 나는 번역하고 있나 생각이 종종 들었다.


한 장에 얼마하는 그 공에 비해 좀 힘들다는 생각도 들기도 하고 1500페이지 번역하다 A형 독감에 걸리기도 했다. 간수치도 높아져서 병원도 가보기도 했다.


그래도 반드시 해낼 때 오는 기쁨이 오기도 하고, 왠지 영어보다 한글을 조금 더 사랑하게 되는 느낌이 생겼다.


때로는 어떤 번역자가 잠수 타는 바람에 내가 대신 번역을 진행하기도 했다.





10권의 번역서를 넘어가니 책 번역이 '노동'으로 많이 느껴지기 시작했는데, 어떤 기사를 보면서  마음이 달라지기 시작했다.


예전에 어떤 신문 기사를 본 적이 있었다. 


수도권이 아닌 지방에 사는 어떤 대학생이 인터뷰하면서 나온 말이었는데, IT 정보를 얻는 데 쉽지 않다고 했다. 인터넷이 있지만 정말 실무자의 환경이나 정보 같은  살아있는 정보를 원한다고 했다.


그 뉴스를 보면서 나에게 번역은 '사명' 같다는 생각이 들었다.  





나는 세상의 어떤 끝내주는 개발자가 알려주는 '기밀 정보'를 '전달'해 주는 사람이기에 먼가 생색내지 않아도 되고. 자연스럽게 정보를 주는 사람이 되는 것 같은 "새로움 느낌"을 받았다.







#--------- 생각 끝-----



나는 생각의 흐름을 멈추고 그 친구에게 얘기했다.



A: 내가 번역한 책은 누군가에게 희망이 될 수 있기에 번역하고 있어요..





아주 짧게 얘기했지만 그 친구는 알아 들은 듯, 못 알아 들은 듯 살짝 애매한 표정으로 나를 쳐다보았다.


나는 누군가에 필요한 책을 번역하고 있다는 생각 때문에 '노동'이 '아름다울 수 있는 무언가'가 되고 있다는 생각에 잘 참아낼 수 있는 것 같아.




====== 이 책을 출간하며 




드디어 도커 인 프랙티스가 나왔다. 출간 안 될 줄 알았는데, 출판사에서 많이 신경 써주신 것 같다.







도커 인 프랙티스 2/e 출간







http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9791161754734&orderClick=LAG&Kc=





이 책을 번역할 때는 아마존 평가는 1~2개 밖에 없었는데, 오늘 보니 20개나 있다. 


처음에는 내가 이상한 책을 추천했나 싶었지만 내(실무자) 관점에서 본 이 책은 확실히 좋은 책이었다.  (물론 다 좋을 순 없을 것이다)








이 책을 보고 도커에 대한 좋은 영감을 받으면 좋겠다.








교보문고의 출판사 서평이다.




★ 이 책에서 다루는 내용 ★

■ 지속적 통합과 배포
■ 쿠버네티스 오케스트레이션 툴
■ 클라우드 작업 흐름 간소화
■ 도커 스웜 모드
■ 최근에 소개된 모범 사례와 기술

★ 이 책의 대상 독자 ★

구조화된 코드를 개발하는 기능, 소프트웨어 개발 및 배포 프로세스 인식과 같은 기본적인 개발 기술과 개념을 이해하고 있다고 가정한다. 또한 핵심 소스 제어 저장소의 기본 지식과 TCP/IP, HTTP, 포트와 같은 네트워크 기본 사항도 알고 있다는 전제하에 설명했다.

★ 이 책의 구성 ★

16개 장이 5개의 부로 나뉘어 있다.
1부, ‘도커의 기초’에서는 먼저 도커를 소개하고 기본 도커 커맨드를 실행할 수 있도록 도커 이해의 토대를 마련한다. 그리고 2장에서 도커의 클라이언트-서버 아키텍처와 디버깅 방법을 설명한다. 디버깅은 도커 설정 문제를 식별할 때 유용하다.

2부, ‘도커와 개발’은 독자들이 도커에 익숙하도록 돕고 머신에서 도커를 최대한 활용하는 데 중점을 둔다. 3장에서는 도커를 쉽게 시작할 수 있도록 익숙한 가상 머신의 개념과 유사한 방식으로 도커의 기초를 설명한다. 4장, 5장, 6장에서는 도커 이미지를 빌드 및 실행하고, 도커를 관리하기 위해 매일 사용하는 도커 기술을 자세히 설명한다. 7장에서는 설정 관리 기술을 살펴보면서 도커 이미지를 심층적으로 빌드하는 주제를 살펴본다.

3부, ‘도커와 데브옵스’는 소프트웨어 빌드 및 테스트의 자동화에 도커를 사용하는 것부터 구축된 소프트웨어를 여러 장소로 배포하는 것까지 데브옵스 문맥에서 도커를 사용하는 부분을 다룬다. 3부에서 도커 컴포즈를 소개하고 네트워크 시뮬레이션 및 도커 네트워크 플러그인과 같은 고급 네트워크 주제를 다루는 도커 가상 네트워크를 설명하며 마무리한다.

4부, ‘단일 머신에서 클라우드까지의 오케스트레이션’에서는 컨테이너 오케스트레이션 주제를 다룬다. 단일 호스트에서 단일 컨테이너를 실행하는 방법부터 ‘운영체제로서의 데이터 센터’에서 실행하는 도커 기반 플랫폼에서 컨테이너를 실행하는 방법까지 설명한다. 13장은 도커 기반 플랫폼을 선택할 때 고려해야 할 부분을 추가로 다룬다. 도커 기반 플랫폼을 구현할 때 엔터프라이즈 아키텍트가 무엇을 생각하는 것인가의 관점을 안내한다.

5부, ‘상용 환경의 도커’는 상용 환경에서 도커를 효과적으로 사용할 수 있는 여러 주제를 다룬다. 14장에서는 컨테이너 내부에서 실행 중인 프로세스를 보호하는 방법과 외부에 노출된 도커 데몬에 접근을 제한하는 방법을 설명하는 중요한 보안 주제를 설명한다. 15장, 16장에서 상용 환경에서 도커를 실행하기 위한 실용적인 정보를 자세히 알려준다. 15장에서는 로그 저장부터 자원 제한에 이르기까지 컨테이너 문맥에서 기존 시스템 관리자 지식을 적용하는 방법을 설명한다. 16장에서는 만날 수 있는 도커 문제를 살펴보고 도커 디버깅 및 해결할 수 있는 단계를 제공한다.

부록에서는 가상 머신 내부와 윈도우 OS를 포함해 다양한 방법으로 도커 설치, 사용 설정의 세부 사항을 포함한다.

[추천사]
“도커를 사용할 때 매우 유용한 팁이 있다. 현장에서 유용하고 실용적이어서 실제 도커 이슈를 해결할 수 있다.”
- 아마존 고객

“읽기 쉽고 따라 하기 쉽다. 이 책을 읽으면 도커의 내부 동작 방식을 훨씬 잘 이해할 수 있다.”
- 아마존 고객

★ 지은이의 말 ★

2013년 9월, 해커 뉴스(Hacker News)를 탐색하다 ‘도커’라는 새로운 기술을 소개한 와이어드(Wired) 기사(http://www.wired.com/2013/09/docker/)를 우연히 발견했다. 기사를 읽고 도커의 혁신적인 잠재력을 깨닫게 되면서 점점 더 흥분했다.
10년 넘게 근무한 회사에서 소프트웨어를 빨리 제공할 수 있는 방법을 고민하던 차였다. 배포 환경은 비용이 많이 들고 시간이 오래 걸리며 수동적인 데다가 매력이라고는 찾아볼 수 없는 작업이었다. 지속적 통합(Continuous Integration)은 거의 없었고 개발 환경을 설정할 때는 인내심으로 버텼다. 내 직책에 ‘데브옵스 관리자(DevOps Manager)’라는 단어가 들어 있어 배포 문제를 해결해야 하는 특별한 동기도 있었다.
회사 메일링 목록에 열정으로 가득 찬 동료(동료 중 하나가 공동 저자가 됐다)를 모집했고 함께 스컹크 웍스(skunkworks) 팀을 만들었다. 베타 툴을 비즈니스 이점으로 전환해 VM 비용을 낮추고 소프트웨어 구축과 배포에 관해 새로운 사고방식으로 접근했다. 조직의 요구에 맞게 자동화 툴(ShutIt)을 구축하고 오픈소스로 공개했다.

도커는 효과적으로 해결할 수 없었던 많은 문제를 해결하기 위해 패키징됨과 동시에 유지 관리되는 툴이 됐다. 도커는 최고의 오픈소스로서 여가 시간을 활용하고 기술 부채를 극복하며 매일 학습하도록 도전 의식을 불러 일으켰다. 도커뿐 아니라 지속적 통합, 지속적 배포, 패키징, 자동화, 사람들이 빠르고 파괴적인 기술 변화에 대응하는 방법을 알게 됐다.
도커는 매우 광범위하게 사용할 수 있는 툴이다. 리눅스를 사용해 소프트웨어를 실행하는 곳마다 도커가 영향을 줄 수 있다. 도커의 범위가 소프트웨어만큼 넓기 때문에 도커라는 주제로 책을 집필하는 것은 어렵다. 도커 생태계는 소프트웨어 산업에서 근본적인 변화에서 발생하는 요구를 충족시키는 솔루션을 생산하는 데 정말 놀라운 속도로 진행된다. 그런 면에서 작업이 더욱 부담스럽게 느껴질 때도 있다. 시간이 지나면서 문제 및 해결책의 형태가 점차 친숙해져 우리의 경험을 책으로 전달하려 많이 노력했다. 내용을 이해하면 특정 기술과 비즈니스 제약 조건의 해결책을 파악할 수 있을 것이다.

개발자 모임에서 소통하면서 도커를 기꺼이 수용하려는 조직은 상당히 빠르게 효과를 봤음을 알게 됐다. 이 책은 데스크톱, 데브옵스 파이프라인을 거쳐 도커를 사용해 상용 환경에 배포하는 방법을 다룬다. 완전히 정통이라고 보기는 어렵지만 엔지니어로서 실용성을 담아야 한다고 생각하며 글을 썼다. 물론 돈을 절약할 때도 매우 실용적이어야 한다. 책에 실린 모든 내용은 실무 현장에서 얻은 실제 교훈을 기반으로 쓴 것이니 좋은 정보를 많이 얻길 기대한다.

이 책은 저마다 다른 상황에서 다양한 기술을 사용해 실제 도커 사용 예시를 보여준다. 다른 기술에 관한 지식 없이 이 책의 기술을 설명하려고 최대한 노력했다.
1부, 2부에서 도커의 기초 설명으로 시작해 단일 머신에서 도커를 개발하는 데 중점을 둔다. 3부에서는 데브옵스 파이프라인에서 도커를 사용해 지속적 통합, 지속적 배포, 테스트를 다룬다. 4부에서는 오케스트레이션을 통해 도커 컨테이너를 확장 가능한 방법을 살펴본다. 마지막 16장에서는 상용 환경에 도커를 실행하는 환경을 다루며 표준 상용 환경 작업, 무엇이 잘못될 수 있고 어떻게 대처해야 할지에 중점을 둔다.
도커는 광범위하고 유연하며 역동적인 툴이다. 도커 생태계에서 미래에 사용할 수 있는 툴과 기술을 확실하게 평가할 수 있는 능력을 제공하기 위해 실제 애플리케이션과 예시를 통해 중요한 개념을 전달하려고 노력했다.
도커가 우리의 삶을 더 편안하게 하고 심지어 재미있게 해주는 여러 방법을 담아 즐거운 여행으로 느낄 수 있도록 글을 썼다. 도커에 몰입해 전체 소프트웨어 생명 주기 동안 흥미로운 많은 소프트웨어 기술로 독자에게 자극을 주는 방법을 담았다. 이 책을 통해 도커 핵심 기술을 독자가 공유할 수 있기를 바란다

★ 옮긴이의 말 ★

요즘은 도커를 사용해 서비스로 활용하는 것뿐 아니라 툴, 테스팅, POC로 사용하는 경우가 많아졌습니다. 그만큼 도커는 점점 대중화되고 있습니다. 도커는 효과적으로 해결할 수 없었던 많은 문제를 해결하기 위해 패키징돼 유지 관리하는 툴로 사용되고 있습니다. 도커는 최고의 오픈 소스로서 여가 시간을 활용하고 기술 부채를 극복하며 매일 학습하도록 도전하게 만듭니다.


하지만 우리는 도커의 내부 구조를 얼마나 이해하고 있을까요? 저는 도커로 파이썬, 스칼라/자바 애플리케이션을 쿠버네티스 클러스터에 배포하고 운영한 적이 있습니다. 당시 “도커를 깊이 알지 않아도 다 돌아가는구나.”라고 생각했던 적도 있습니다. 하지만 결국 도커에 대한 얕은 지식으로 문제가 발생해 ‘삽질’할 때가 많았습니다. 단순히 커맨드만 안다고 도커를 이해했다고 말하기는 어려웠습니다.


이 책을 보고 나서 도커를 상대하는 것과 더불어 쿠버네티스도 이해되기 시작했습니다. 도커의 단점을 파악하니 도커의 보안 이슈를 이해할 수 있었습니다. 또한 마라톤/메소스 및 쿠버네티스와 같은 오케스트레이션 툴도 제대로 보이기 시작해 앞으로 더 잘 사용하고 싶어졌습니다.


저는 도커가 개발자와 데브옵스에게 평생 친구가 될 것이라고 장담합니다. 점차 도커는 대중화될 것이고 곳곳에서 사용될 것입니다. 이 책으로 도커를 깊이 알아가는 기회가 되면 좋겠습니다.
이 책은 VM에서 전환하기, 시스템을 마이크로 서비스로 나누기, 영속성 볼륨, 고급 이미지 구축 기술, 지속적 통합, 셀레늄 테스트, etcd와 confd, 네트워크 시뮬레이션, 보안, 모니터링, 성능 및 디버깅 등과 같은 컨테이너와 관련된 실무 이슈를 해결하는 내용을 담고 있습니다.


상용 환경에서 도커를 다루기 위해 중요한 설정 관리 및 오케스트레이션 툴을 설명합니다. make와 같은 전통적인 유닉스 툴, 도커 컴포즈, 헬리오스(Helios), 도커 웜 및 쿠버네티스와 같은 도커 기본 툴을 사용해 도커 파일(Dockerfile)을 관리하는 상세한 작업 예시를 소개합니다.


마지막으로 도커와 관련된 툴에 관한 버그와 단점을 실제로 작업을 수행할 수 있도록 실용적인 조언과 팁을 전합니다. 이 책은 도커 생태계에서 미래에 사용할 수 있는 툴과 기술을 확실하게 평가할 수 있는 능력을 제공하기 위해 실제 애플리케이션과 예시로 독자를 이해시키고자 합니다. 여러분도 도커에 몰입해 전체 소프트웨어 생명 주기 동안 흥미로운 소프트웨어 기술에 자극받길 바랍니다. 


Posted by 김용환 '김용환'

댓글을 달아 주세요

  1. Favicon of https://anisos.tistory.com BlogIcon 공학코드 2021.04.06 01:33 신고  댓글주소  수정/삭제  댓글쓰기

    종종 작성하신 글들을 참고할 때가 있습니다. 노고에 감사드립니다.

  2. Favicon of https://devkyu.tistory.com BlogIcon 개발자큐 2021.09.16 09:46 신고  댓글주소  수정/삭제  댓글쓰기

    소설 작가 중에 베르나르 베르베르의 책을 모두 읽다보니 그 사람은 생각을 어떻게 할지 예상이 되고 새로운 작품을 만나도 친근한 느낌이 있었습니다.
    번역자 김용환 님의 책들도 천천히 다독해보겠습니다ㅎㅎ


(이젠 업무에 바빠서 책 번역 외에는 블로그 할 시간이 점차 사라지고 있다)


교보문고 홈 페이지의  IT 전문서 올해의 IP 책 - 마이크로 서비스 클라우드 분야를 봤더니,

내가 번역한 실무자 관점에서 다룬 마이크로 서비스 아키텍처 (2판)이 4위를 차지했다.

고생한 것 만큼 정당한 대우를 독자들에게서 받아서 너무 좋다. 

(이제서야 글을 봤고 어떤 사람에게도 부탁이 한적이 없다. 그만큼 의미가 있다!! )


1판 번역을 완료한 후 2판 번역까지 완료하고

거의 내 혼자 힘으로 (최종 편집까지) 꼼꼼하게 본 책이라 많은 기억이 남는 책이다. 


http://www.kyobobook.co.kr/eventRenewal/eventViewByPid.laf?eventId=84458



지금 번역 중인 Docker in Practice (2nd), Seeking SRE 책도 예쁘게 번역하리라..



Posted by 김용환 '김용환'

댓글을 달아 주세요



내가 번역한 책 

"빅데이터 분석을 위한 스칼라와 스파크 대용량 빅데이터 분석과 머신 러닝까지 활용하는." 책이 대한민국학술원에서 선정한 2019 우수학술도서가 되었다. 


http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9791161752402&orderClick=LAG&Kc=







http://www.nas.go.kr/info/notice/view.jsp?NP_Code=10000043&NP_DataCode=20000014&NGB_Code=10002646&searchKey=NGB_SUBJECT&searchVal=&pg=2







출판사에서 도와주신 것 같다.



Posted by 김용환 '김용환'

댓글을 달아 주세요


Spark Streaming Job(Kafka-Consumer)의 성능을 높일 수 있다.


* Kafka topic의 파티션 개수 * 설정 파일의 spark.streaming.kafka.maxRatePerPartition 이다.


* 파티션 개수가 10개 * spark.streaming.kafka.maxRatePerPartition이 5 개이면 => 50 event /duration 성능이 나온다.


그러나 maxRatePerPartition이 너무 크면 OOM이 발생하거나 스트리밍 시스템(sink)에 영향을 줄 수 있다.




스트리밍이 제대로 동작되는지 확인하려면 2가지를 확인할 수 있다.


1) 52 completed batches, 653 records (동작안되면 0 completed batches 라고 뜬다)


2) Processing Time과 Total Delay 처리 Avg 시간을 확인한다. -로 나온다면 처리하는 것이 아니다. 




Posted by 김용환 '김용환'

댓글을 달아 주세요

td-agent 모니터링

Tool 2019. 10. 28. 18:29


td-agent가 잘동작하는지 확인하려면 시스템 레벨에서 td-agent가 잘 동작하는지를 확인할 수 있을 것이다.


이외 td-agent에 기본적으로 설치된 24220 포트를 활성화하고 해당 서버의 포트를 체크한다.

<source>
@type monitor_agent
bind 0.0.0.0
port 24220
</source>




대략 (파이썬을 사용해 ) ansible의 host 파일을 읽어 아래와 같이 모니터링할 수 있다. 

failed_servers = []

for ansible_server in ansible_server_list:

url = f"http://{ansible_server}:24220/api/plugins.json"

try:

r = requests.get(url)

r.raise_for_status()

except (requests.exceptions.ConnectionError, requests.exceptions.Timeout, requests.exceptions.HTTPError):

failed_servers.append(ansible_server)



'Tool' 카테고리의 다른 글

td-agent 모니터링  (0) 2019.10.28
java.lang.NoSuchMethodError: No such DSL method 'withMaven' found among steps 에러  (0) 2019.03.11
맥OS 에서 숨은 파일 찾기  (0) 2019.01.09
tmux 사용 방법  (0) 2018.12.19
[git] no kex alg 이슈  (0) 2018.06.20
[intellij] 2018.1 lombok 설정  (0) 2018.06.19
Posted by 김용환 '김용환'

댓글을 달아 주세요

sbt 동작 이상

scala 2019. 10. 21. 15:21


아무리 수정해도 sbt가 잘 동작하지 않으면, sbt의 로컬 디렉토리인  ~/.sbt 을 다시 지우고 시작하자!!


Posted by 김용환 '김용환'

댓글을 달아 주세요


sbt 사용할 때 Exception이 fully하게 보여주지 않으니 답답한데..

-oD를 사용하니  기니 Exception이 fully 로 나온다. 속이 시원하다.


http://www.scalatest.org/user_guide/using_scalatest_with_sbt

Specifying ScalaTest Arguments

You can pass arguments to ScalaTest by using testOptions and Tests.Argument in your sbt build file:

testOptions in Test += Tests.Argument(TestFrameworks.ScalaTest, "-oD")

The -oD argument above will be pass to ScalaTest for all test runs, you can also pass arguments for individual runs by using test-only and placing them after --, like this:

> test-only org.acme.RedSuite -- -oD


Posted by 김용환 '김용환'

댓글을 달아 주세요


sbt 에서 컴파일 속도가 나지 않는다고 계속 아래 커맨드를 사용하라고 로그가 나와서 

[warn] Getting the hostname Alvins-MacBook-Pro.local was slow (5003.850955 ms).
This is likely because the computer's hostname is not set.
You can set the hostname with the command:
  scutil --set HostName $(scutil --get LocalHostName).

아래 커맨드를 사용하니 잘 동작한다. 

$ scutil —set HostName $(scutil —get LocalHostName)




참고할 내용


실제 코드 

https://github.com/sbt/sbt/pull/3766/files


질문 & 답

https://apple.stackexchange.com/questions/175320/why-is-my-hostname-resolution-taking-so-long


\

Posted by 김용환 '김용환'

댓글을 달아 주세요

kudu 공부 링크

scribbling 2019. 10. 21. 15:16



kudu 번역

https://blog.cloudera.com/apache-kudu-read-write-paths/


https://blog.cloudera.com/?s=kudu


spark을 이용하면 read, write, update가 가능하다.. 


Posted by 김용환 '김용환'

댓글을 달아 주세요


Open JDK를 테스트하는데 일주일 걸리고, 한 번 테스트하는데 만불(1200만원) 걸린다고 한다.


=> 역시 구글은 테스트를 중요하게 생각한다.


Posted by 김용환 '김용환'

댓글을 달아 주세요