5월, 2021의 게시물 표시

전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것" (twitter.com/jasoncwarner)

 geeknews에서 가져온 내용. 원본 링크는 아래에 기재. https://news.hada.io/topic?id=7839 지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것 "Monolith > apps > services > microservices" 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음 둘째, 단계가 중요함 5-50인 회사라면 그냥 Monolith로 가세요 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면.. 먼저 정의(Definition) 부터 monolith - xyz.com apps - abc.xyz.com services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리) microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함 Why ? : 기본적으로 "Speed & Risk" 때문 #1 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움 #2 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움 #3 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함 #4 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함 이론적으로는 이게 맞고, 일이십개

curl 명령어 옵션

# 결과를 지정한 이름으로 파일에 저장 $ curl -o response.txt https://www.example.net # 결과를 파일이름으로 저장, index.html 이 저장됨  $ curl -O https://www.example.net/index.html # SSL증명서 에러 무시 $ curl -k https://www.example.net # 진척상황을 표시 하지 않기, 에러도 표시되지 않음 $ curl -s -o response.txt http://www.example.net # 에러메시지는 보고 싶을때 $ curl -sS -o response.txt http://www.example.net # progress bar로 진척상황표시 $ curl -# -O http://www.example.net/index.html # proxy이용시 $ curl -x <proxyip>:<port> --proxy-user <username>:<password> http://www.example.net $ curl -x <username>:<password>@<proxyip>:<port> http://www.example.net # 301/302등의 redirect를 자동인식 $ curl -L http://www.example.net # http의 메소드를 지정 $ curl -X [PUT|GET|POST] http://www.example.net # parameter를 POST로 송신 $ curl -w '\n' 'http://www.example.net/posturl' -X POST --data 'name=myname&mode=create' # status code만 출력 $ curl -sS -w '%{http_code}\n' http://www.example.net  # http의 response header를 확인

일본 취업에 대한 단상

일본취업이 결정되어 트렁크와 배낭만 달랑 들고 신오오쿠보로 들어온 날로부터 거의 20년이 다되어 간다. 어쩔 수 없이 룸쉐어를 해야 했던 밤마다 친구들 불러와 소란 떨던 그 싸가지 없던 유학생 놈들은 어떻게 되었을려나. 번듯한 회사에 계약사원으로 취업되어 실무보다는 벤더컨트롤을 더 많이 하던 업무가 싫어, 1년 반만에 그만두고 SES(System Engineering Service) 업계로 뛰어들어 그 말도 많고 탈도 많은 인력파견 업체에서 근무하게 되었다. 원하던대로 실무에서 각종 서버나 네트워크 기기 등을 접하게 되고, 이전보다 높은 급여를 받으며 그만 현실에 안주해 버린 그때가 후회 스럽다. 그때야 아무 것도 모르고 철도 덜 들었고, 실제로 사회생활도 해본 적이 없었으니 별 생각 없이 계속 SES업계에서 일을 했었는데, 결국 설계나 기획 같은 상위 공정은 갑회사에서 다 해먹고 을회사 직원들은 주어진 문서 대로만 단순 작업을 반복하는 업무가 반복 되었다.  상위공정을 위해서 SES업체에서는 그래도 능력을 인정받아 IBM, SonyBank, NEC, DOCOMO, HITACHI 등등 여러 곳에서 불러주었지만 항상 주어진 대로만 작업을 해야하는 업무에 점점 싫증을 느끼게 되었다. 초기에는 그렇지 않았지만 SES 제공업체가 점점 많아지며 그만큼 사건사고도 많아지고, 결국 SES 직원들의 가장 인정 받는 스킬은 '주어진 대로 그대로 똑같이 만들어 내가'가 되어 버렸다. 각종 설정 내용을 갑회사로부터 받아 얼마만큼 실수 없이 시스템을 구축해 내는가가 능력의 지표다. 아무 것도 생각할 필요없이, 사양서 그대로만 해야하는 업무가 계속 되니 결국 피로감을 느끼고 자사 서비스를 제공하는 업체로 이직을 하게 되었다. 거의 15년 가까이 주어진 업무만 하다 보니 새로운 환경에 적응을 못하고 거의 6개월을 버벅거리다 겨우 업무에 적응 하였다. 다행히 업무에 적응한 후로는 승급도 하고 여러모로 좋은 평가를 받았다. 여담이지만, 그때 팀 내에서는 채용실패한 경우가 아

Macbook M1에서 karabiner를 이용한 영어/한글/일본어 입력 변환

M1칩셋이 발표되기 이전부터 일본어 키보드에서 英数와 かな키를 이용한 한/영/일 전환을 이용하고 있었다. karabiner를 이용하여 英数는 영어전환, かな는 일어전환, かな를 두번 누르면 한글 전환으로 설정하고 있었다. 이전에 karabiner의 complex modificiations를 다운로드하여 사용하고 있었는데, 전제조건이 입력소스 배열로 한글 다음에 일어가 와야 한다는 것이었다. 그런데 이번에 사용하게 된 M1에서는 칩셋의 문제인지, OS의 문제인지 언어의 배열이 바뀌지가 않았다. 이전에는 새로이 언어를 추가하거나 삭제하는 방법으로 순서를 바꿀 수가 있었는데 새 M1에서는 순서가 변경되지 않는다. 더불어 BigSur의 문제로 OS를 종료할때 karabiner에서 Kernal Panic이 발생하는 문제가 있어서 거의 사용을 단념하고 있었다. 그럼 Complex modificiatons를 새로 만들면 어떨까 하는 생각이 들어 json 파일을 뒤적거려 보기로 했다. 확인해 본 결과 먼저 英数키를 눌러 영어로 입력소스를 변경한 후, 기본 입력소스 변경 단축키인 컨트롤+옵션+스페이스를 입력하면 반드시 한글로 변경되었다. json 파일을 다음과 같이 변경하여 ~/.config/karabiner/assets/complex_modifications 에 복사하는 걸로 해결 되었다. { "title" : "For Korean 일본어 맥OS에서 한글전환키 커스텀 지정 (rev.4)" , "rules" : [ { "description" : "[일본어(JIS) 키보드용] Kana키 더블클릭으로 한글전환" , "manipulators" : [ { "type" : "basic" , "from" : {