조대협의 블로그

쿠버네티스를 위한 CD 툴, Skaffold #2조대협 (http://bcho.tistory.com)Skaffold 설정 파일의 구조Skaffold의 개념과 기본적인 사용법을 이해하였으면, 다음으로 Skaffold 설정 파일에 대해서 알아보도록 하자.Skaffold의 설정 파일은 아래와 같이 크게 두가지가 있다. Pipeline config 우리가 앞에서 살펴본 skaffold.yaml 파일이 파이프라인 설정 파일에 해당한다. 컨테이너 빌드 및 레지트리 등록, 테스트 및 컨테이너 배포 일련의 파이프라인에 대한 행동을 정의한다. Global config ~/.skaffold/config 파일에 저장되어 있는 정보로 skaffold의 기본 설정 정보를 정의한다. 예를 들어 디폴트 도커 레지스트리 경로등을 정..

쿠버네티스용 Continuous Deployment 툴인 Skaffold조대협 (http://bcho.tistory.com)What is skaffold?쿠버네티스 기반에서 개발을 하고 테스트를 하려면 일반적으로 다음과 같은 절차를 거쳐야 한다.소스 코드를 수정한 후, 수정한 코드를 컴파일 한 다음에컴파일한 소스 코드를 포함해서 Dockerfile을 이용해서 컨테이너로 패키징 한후에컨테이너를 레파지토리 새로운 버전 태그를 붙여서 업로드 하고쿠버네티스의 기존 Deployment나 Pod의 yaml 파일에 image 명을 바꾼후kubectl -f apply 를 이용해서 변경된 파일을 반영하고,다음 public IP가 있는 서비스의 경우에는 public IP로 접속하고, 아닌 경우에는 SSH 터널링을 이용해서..

쿠버네티스 패키지 매니저 Helm#2-5 Helm Chart 배포조대협 (http://bcho.tistory.com) Helm 차트를 작성했으면, 다른 사용자들이 사용하기 쉽게 차트를 차트 리포지토리 (Chart repository)에 배포할 수 있다. Helm 파일 패키징파일을 배포하기 위해서는 먼저 차트 파일들을 *.tgz 파일 형태로 패키징해야 하는데, helm package 명령을 사용하면 된다. %helm package [차트 디렉토리] 형태로 사용하면 된다. 앞의 예제인 helloworld 차트를 패키징 하려면 아래와 같은 명령을 사용하면 된다.%helm package ./helloworldSuccessfully packaged chart and saved it to: /home/terrych..

쿠버네티스 패키지 매니저 Helm #2-4 Helm Chart Hook 조대협 (http://bcho.tistory.com) Hook은 차트 설치나, 삭제와 같이 차트의 라이프 사이클 중에, 차크 개발자가 동작을 추가해줄 수 있도록 해주는 기능이다. mySQL을 차트로 설치한 후에, mySQL에 테이블을 생성하고 데이타를 로딩하거나, 차트로 Pod를 설치하기전에 Configmap이나 Secret 의 값을 세팅해놓는 것과 같은 작업을 예를 들 수 있다. 등을 들 수 있다. Hook 으로 실행되는 리소스는 따로 있는 것이 아니라, 기존의 쿠버네티스 리소스 (Job, Cron Job 등)에 metadata.annotations.”helm.sh/hook” 으로 태그를 달아주면, 이 리소스들은 Hook으로 정의되..

쿠버네티스 패키지 매니저 Helm #2-3. Charts (디렉토리 구조)조대협 (http://bcho.tistory.com)디렉토리 구조Helm 차트의 디렉토리 구조는 다음과 같다. 직접 아래와 같은 디렉토리 구조에 파일을 각각 생성해도 되지만, 기본 템플릿을 helm create [차트명] 으로 생성할 수 있다.아래는 %helm create mychart 명령으로 생성한 디렉토리의 구조이다. mychart/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A hum..

쿠버네티스 패키지 매니저 HELM #2-2. Chart 버전과 릴리즈 조대협 (http://bcho.tistory.com)업그레이드와 롤백Chart로 의해서 설치된 리소스들을 쿠버네티스에서 릴리즈라고 한다.예를 들어 같은 차트로 MySQL을 쿠버네티스 클러스터 내에 여러번 설치 할 수 있다. 각각 설치된 MySQL들을 릴리즈라고 하고, 릴리즈에 설정이 변경된 경우에, 차트를 수정해서 변경을 반영할 수 있다. 변경이 반영될때 마다 새로운 버전이 생성된다. 처음 helm install로 설치를 할때 --name 옵션으로 저장한 설치 이름이 릴리즈 명이 되고, 이 릴리즈를 업데이트 하고 싶으면 helm upgrade {Helm 릴리즈명} {차트 디렉토리} 를 실행하면, 해당 릴리즈를 업데이트하고, 새로운 버전..

쿠버네티스 패키지 매니저 HELM#2-1 .Chart조대협 http://bcho.tistory.comHelm Chart차트는 helm의 패키지 포맷으로, 하나의 애플리케이션을 설치하기 위한 파일들로 구성되어 있다. 예를 들어 tomcat을 설치하기 위한 쿠버네티스의 pod,service,deployment를 위한 YAML 파일등을 포함한다.템플릿과 밸류Helm 은 기본적으로 템플릿의 개념을 사용한다. 템플릿 파일을 만들어놓은 후에, 밸류 값을 채워 넣어서 쿠버네티스 리소스를 정의한 YAML 파일을 생성한다. 예제를 살펴보자Helm 은 기본적으로 템플릿의 개념을 사용한다. 템플릿 파일을 만들어놓은 후에, 밸류 값을 채워 넣어서 쿠버네티스 리소스를 정의한 YAML 파일을 생성한다. 예제를 살펴보자. 먼저 t..

2019년 6월 2일 700만 돌파 (6개월)2018년12월 10일 600만 돌파 (7개월)2018년 5월 10일 500만 돌파 (10개월)2017년 7월17일 405만 돌파 2016년10월20일300만 돌파2015년12월16일200만 돌파

쿠버네티스 패키지 매니저 HELMHelm의 일반적인 개념Helm은 리눅스의 apt 툴이나, node.js의 npm과 같은 쿠버네티스용 패키지 매니지먼트 도구 이다. 일반적으로 하나의 소프트웨어를 쿠버네티스에 배포하려면, 간단하게 컨테이너만을 배포해서는 사용하기 어려운 경우가 많다. 외부로 IP를 노출 시키기 위해서 쿠버네티스 서비스를 배포해야 하고,쿠버네티스 pod를 관리할 deployment가 필요하며, 디스크 볼륨과 기타 정책등 부가 적인 부분을 추가로 배포해야 한다. 이미 네트워크나 디스크 설정이 완료된 상태에서 애플리케이션을 업데이트 하는 경우에는 쿠버네티스 deployment나 다른 배포 도구를 이용해도 되지만, 처음부터 모든 것을 설치해야 하는 반복적인 작업이 있는 경우에는 배포 도구로 불가능..

참고 문서 : 구글 머신러닝 크래쉬 코스 피처 엔지니어링 #1 - 피처 크로스 조대협 (http://bcho.tistory.com) 일반적인 선형 모델의 경우에 선을 그어서 문제를 해결할 수 있다. 아래 그림과 같은 데이타 분포의 경우에는 파란선과 붉은선 사이에 선을 그으면 문제가 해결된다. 그러나 아래와 같은 데이타 모델의 경우에는 선을 하나 그어서 해결할 수 가 없다. (선형 모델의 경우에) 세로축을 x1, 가로축을 x2라고 할때, y = w1x1 + w2x2 + w3(x1x2) +b 로 세번째 피쳐를 앞의 두 피쳐를 곱한 값을 이용하게 되면, 문제를 해결할 수 있다. 즉 x1이 양수이고 x2가 양수이면 양수가 되고 , x2가 음수이면 x1*x2는 양수가 된다. 즉 파란색 점이 위치한 부분은 모두 양..

SRE #6-운영에서 반복적인 노가다 Toil조대협 (http://bcho.tistory.com)ToilToil의 사전적인 뜻은 “노역"이라는 뜻을 가지고 있는데, 비속어를 사용해서 표현하자면 운영 업무에서의 “노가다" 정도로 이해하면 된다. Toil 에 대한 정의를 잘 이해해야 하는데, Toil은 일종의 반복적인 쓸모없는 작업 정도로 정의할 수 있다.경비 처리나, 회의, 주간 업무 보고서 작성과 같은 어드민 작업은 Toil에 해당하지 않는다. Toil은 운영상에 발생하는 반복적인 메뉴얼 작업인데, 다음과 같은 몇가지 특징으로 정의할 수 있다.메뉴얼 작업이고 반복적이어야함Toil의 가장 큰 특징은 사람이 직접 수행하는 메뉴얼 작업이라는 것이다. 그리고 어쩌다 한번이 아니라 지속적으로 발생하는 반복적인 작..

SRE #5 - Error budget 조대협 (http://bcho.tistory.com) SLI와 SLO에 대한 개념을 이해 했으면 다음은 Error budget에 대한 개념을 이해해야 한다.Error budget은 단순하게 생각하면Error budget = [100% - availability target] 와 같다. 예를 들어 설명하면, 한달에 SLO가 99.999%를 목표치로 설정했다면, 한달간 SLO는 0.001%의 다운 타임을 허용하게되고, 이 0.001%가 Error budget이된다. 위의 표는 가용성에 따라서, 허용되는 장애 시간을 정리해놓은 표이다.앞의 예제에서 99.999% 가용률을 목표로 봤을 때 허용되는 장애시간은, 0.001%로 다운 타임은 한달에 25.9 초만 허용된다. 그러..

Azure Devops 조대협 (http://bcho.tistory.com) 페이스북 타임라인을 보다가. “Azure Devop가 나왔는데. JIRA 따위는 꺼져버려.." 라는 말이 있어서 몬가 궁금해서 살펴봤는데 이거 정말 물건이다. MS가 요즘 많이 변하하고 있다고 들었는데, 정말 잘 만든 제품인듯 Devops라고 해서 Monitoring,Logging쪽 제품으로 생각했는데, Task management, 부하 테스트, git repo & 빌드, 빌드 파이프라인, 웹테스트 툴 등이 들어있는데, 전반적으로 정말 좋은듯. 예전 IBM의 Jazz 플랫폼과 컨셉은 비슷한데, UI나 기능이나 반응 속도나 압권이고 거기다가 일부 플랜은 무료다!! 나 같은 개인 개발자(집에서는)에게는 딱이 아닐까 싶다. 대충 후..

2019년 샌프란시스코 구글 NEXT 2019에서 발표한 로깅 시스템에 대한 강의 입니다.구글 스택 드라이버 로깅에 대한 소개와, 삼성전자가 어떻게 스택 드라이버 툴을 이용해서 Devops로 적응했는지에 대한 사례입니다.영어 컨텐츠 입니다.

SRE #4-예제로 살펴보는 SLI/SLO 정의 방법조대협 (http://bcho.tistory.com) 앞에서 SRE의 주요 지표인 SLO/SLI의 개념에 대해서 설명하였는데, 그러면 실제 서비스에서는 어떻게 SLO/SLI를 정의하는지에 대해서 알아본다.SLI는 사용자 스토리당 3~5개 정도가 적당하다. 사용자 스토리는 로그인, 검색, 상품 상세 정보와 같이 하나의 기능을 의미한다고 보면된다. 아래 그림과 같은 간단한 게임 서비스가 있다고 가정하자. 이 서비스는 웹사이트를 가지고 있고, 그리고 앱을 통해서 접근이 가능한데, 내부적으로 API 서비스를 통해서 서비스가 된다. 내부 서비스에는 사용자 랭킹(Rank ), 사용자 프로파일 (User profiles) 등의 서비스가 있다. 이 서비스에서 "사용자..

SRE #3-SRE 주요 지표 (SLI/SLO)조대협 (http://bcho.tistory.com) 이글은 앞글 (https://bcho.tistory.com/1327)과 연결 됩니다.앞에 까지 SRE가 무엇이고, SRE가 하는일은 무엇이며, 어떻게 그 일을 수행 하는지에 대해서 알아보았다. SRE 프랙티스 에서는 의사 결정을 데이터에(data based decision) 따라 하기 때문에, 데이타 즉 지표를 정의하는 것이 중요하다. 그러면 SRE 에서는 어떻게 지표를 정의하고 활용하는지에 대해서 알아본다. SLI (Service Level Indicator)SLI는 서비스에 대한 수준을 측정하여, 정량적으로 정의한 지표이다. "REST API의 응답시간 = 300ms"와 같이 절대 값을 사용하기도 하지..

SRE는 어떻게 일하는가? 조대협 (http://bcho.tistory.com) 이글은 앞의 글 "SRE/DEOPS의 개념과 SRE는 무엇을 하는가?" (https://bcho.tistory.com/1325) 와 연결된 글입니다.How SRE does Devops?그럼 SRE들은 이런한 일들을 어떤 방법으로 수행할까? 앞에서 SRE가 해야 하는 일에 대해서 설명하면서 각각에 대해서 일부를 언급했지만, 다시 SRE가 해야하는 일을 하기 위해서는 어떻게(How) 해야 하는지에 대해서 다시 정리해보자.SRE는 앞에서 언급한 다섯가지 일을 하기 위해서 아래와 같이 다섯 가지 방법을 사용한다. (참고 : 구글 NEXT 발표자료 https://drive.google.com/file/d/1iOMaYIwlUBiGoG2..

AutoEncoder vs Variant AutoEncoder 조대협 (http://bcho.tistory.com) AbnormalAutoEncoder는 입력값을 기반으로 여기서 특징을 뽑아내고, 뽑아낸 특징으로 다시 원본을 재생하는 네트워크이다. 이미지 합성이나 압축, Abnormal Detection 등 여러 유스케이스에 사용이 될 수 있지만, 특히 추출된 특징 (latent coding)은 데이타의 특징을 이해하는데도 유용하게 사용될 수 있다. 이 글에서는 AutoEncoder와 요금 각광 받는 VAE (Variant Auto Encoder) 의 차이를 알아보고 특히 latent coding의 값이 어떻게 다르게 표현되며, 어떤 의미를 가지는지에 대해서 이해한다. 일반 오토 인코더의 모양은 다음과 ..

Site Reliability Engineering(SRE)#1 SRE/DEVOPS의 개념조대협 (http://bcho.tistory.com)배경Devops는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다. 이 Devops라는 컨셉이 소개된지는 오래되었지만, Devops의 개념 자체는 명확하지만 이 Devops를 어떻게 실전에 적용할것인 가는 여전히 어려운 문제였다.(예전에 정리한 Devops에 대한 개념들 1 , 2) 예전 직장들에 있을때 Devops의 개념이 소개되었고 좋은 개념이라는 것은 이해하고 있었지만, 여전히 운영팀은 필요하였고, 그 역할이 크게 바뀌지 않았다. 심지어 Devops를 하는 기업들도 보면 기존 개발팀/운영팀이 있는데, ..

SRE는 구글의 Devops의 프랙티스 로 구글의 서비스에 대한 배경과 철학을 읽을 수 있다.SRE의 기본 사상중의 하나는 서비스의 안정성이 완벽할 수 없으며, (아니 완벽하지 않게 만들며) 장애를 허용하는 모델이다.고 가용/고 성능 시스템을 만들기 위해서는 그만큼 많은 개발에 대한 노력이 소요되는데, 이로 인해서 기능 개발에 대한 속도가 느려지기 때문에, 사용자가 납득할만한 수준의 가용성을 제공하되 개발의 속도를 유지하는 철학이다.배경을 살펴보면 구글은 모바일을 기반으로 한 B2C 서비스를 주력으로 하기 때문에, 서비스가 99.999%의 가용성을 제공하더라도, 스마트폰과 통신망 자체가 그정도의 안정성을 제공하지 않기 때문에, 백앤드 서비스가 높은 가용성을 제공하더라도 사용자가 느끼는 가용성은 그 정도 ..

Serveless를 위한 오픈소스 KNative #2 Eventing 조대협 (http://bcho.tistory.com) knative의 다른 모듈로써는 비동기 메세지 처리를 위한 eventing 이라는 모듈이 있다. 카프카나, 구글 클라우드 Pub/Sub, AWS SQS와 같은 큐에서 메시지를 받거나 또는 Cron과 같은 타이머에서 이벤트가 발생하면 이를 받아서 처리할 수 있는 비동기 메커니즘을 제공하는 모듈이라고 보면 된다. 메시지 큐나 cron 과 같이 이벤트를 발생 시키는 자원들은 knative에 event source 라는 Custom Resource로 등록이 되고, 등록된 event source는 이벤트가 발생되면 지정된 knative 서비스로 이벤트 메시지를 HTTP로 전송한다. 이때 이벤..

Serveless를 위한 오픈소스 KNative조대협(http://bcho.tistory.com)배경근래에 들어서 컨테이너를 사용한 워크로드 관리는 쿠버네티스 de-facto 표준이 되어가고 있는데, 쿠버네티스 자체가 안정되어가고 있지만, 이를 현업에 적용하기 위해서는 아직까지 여러가지 챌린지가 있다.컨테이너 기반의 쿠버네티스 서비스가 지향하는 바는, 셀프서비스 기반의 데브옵스 모델로 인프라와 이를 자동화하는 플랫폼을 인프라엔지니어가 개발하여 개발팀에 제공하고, 개발팀은 개발과 배포/운영을 스스로 하는 모델이다.그런데 예를 들어 간단한 무상태(stateless) 웹서비스를 하나 구축한다 하더라도 Deployment,Ingress,Service 등의 쿠버네티스 리소스를 정의해서 배포해야 하고, 여기에 오토..

스택 드라이버 로그로 로그 백앤드 구축하기조대협 (http://bcho.tistory.com) 앞의 글에서까지 로그를 남기는 방법에 대해서 알아보았다. 이번 글에서는 로컬에 남긴 로그를 중앙으로 수집하여 모니터링할 수 있는 도구에 대해서 알아보고자 한다.보통 로그 시스템은 오픈소스 기반의 ELK (Elastic search + Logstash + Kibana)를 많이 사용한다. 좋은 시스템이기는 하지만 러닝 커브가 있고, 구축과 운영에 노력이 들어간다. 대안으로는 클라우드 기반의 매니지드 서비스를 사용하는 방안이 있는데, 구글 클라우드의 스택드라이버 로깅이 사용이 편리하기 때문에 스택드라이버를 소개하고자 한다.구글 클라우드의 스택드라이버는 로깅뿐만 아니라 모니터링, 에러 리포팅등 다양한 기능을 제공하는 ..

티스토리가 근래에 오랜만에 개편이 되고, 에디터도 대폭 개선이된데다가 마크다운 에디터까지 지원하는 것은 좋은데, 사용자 경험을 그전 호환성을 유지해야 하는데, 이번에는 좀 문제가 있지 않나 싶다. 티스토리 에디터가 너무 불편해서 글쓰기가 어려워서 그간 여러 방법을 고민하다가 내린 결론이 구글닥스를 이용해서 글을 다 쓴 후에, 복붙으로 붙이는 방식을 사용했는데, 잘되다가 얼마전 부터, 글을 써 붙이니 포맷이 모조리 깨져 버린다. 코드블록도 프로그램언어는 있지만 XML이나 JSON,YAML 은 왜 없는지도 싶고.. https://bcho.tistory.com/1319 로깅 시스템 #6-Spring Boot에서 Zipkin을 이용한 분산 시스템 로깅 Spring Boot + slf4j + MDC + Zipki..

Spring Boot + slf4j + MDC + Zipkin 조대협 (http://bcho.tistory.com) 아래 예제는 MDC를 이용해서 여러 메서드간의 컨텍스트를 연결하는 것을 확장해서, 서로 다른 프로세스와 서버간에 로그를 연결하는 방법이다. 서로 다른 프로세스 또는 서버간에 컨텍스트를 전달하려면 HTTP 헤더등을 통해러 리모트로 컨텍스트를 전달해야 하는데, 이를 가능하게 하는 오픈소스로 Zipkin이 있다. (자세한 설명은 이글을 참고하기 바란다. ) Zipkin은 원래 분산 로그 추적용으로 개발된 오픈소스가 아니라 원래 목적은 분산 시스템에서 각 구간별 레이턴시(지연시간)을 측정해서 구간별 소요 시간을 측정하는 트레이스용도로 개발이 되었지만, 구간별 소요 시간을 측정하기 위해서는 각 개별..

스택드라이버 로깅을 테스트 하고자 로컬 환경에서 로그를 올리기 위해서 fluentd를 설치했는데 일단 설치는 서비스 어카운트를 다운 받아서 하면 되긴 하는데, 실행을 하고 로그를 전송하려면 아래와 같은 이유가 난다. 2019-04-02 01:20:36 +0900 [error]: #0 Failed to access metadata service: error_class=Errno::EHOSTUNREACH error="Failed to open TCP connection to 169.254.169.254:80 (No route to host - connect(2) for \"169.254.169.254\" port 80)" 2019-04-02 01:20:36 +0900 [info]: #0 Unable to d..

로깅 시스템 #5 - Spring boot에서 JSON 포맷 로깅과 MDC 사용하기조대협 (http://bcho.tistory.com) 실제로 백앤드 애플리케이션을 자바로 개발할때는 스프링 부트를 사용하는 경우가 대부분이기 때문에 앞에서 적용한 JSON 로그 포맷과 MDC 로깅을 스프링 부트에 적용해보자스프링 부트라고 해도, 일반 자바 애플리케이션에 대비해서 로그 설정 부분에 다른점은 없다.아래와 같이 pom.xml에 logback과 json 의존성을 추가한다. ch.qos.logbacklogback-classic1.2.3 ch.qos.logback.contriblogback-json-classic0.1.5 ch.qos.logback.contriblogback-jackson0.1.5 com.fasterx..

로깅 시스템 #4 - Correlation id & MDC조대협(http://bcho.tistory.com)Correlation id하나의 프로그램은 여러개의 메서드들로 조합이 된다. 하나의 요청을 처리하기 위해서는 여러개의 메서드들이 순차적으로 실행이 되는데, 멀티 쓰레드 프로그램에서 여러개의 쓰레드 동시에 각각의 요청을 처리할때, 각 메서드에 로그를 남기게 되면, 멀티 쓰레드 프로그램에서는 쓰레드들이 서로 컨택스트를 바꿔가며 실행이 되기 때문에, 로그 메시지가 섞이게 된다아래 그림을 보자. 요청 A와 B가 호출되어 각각 다른 쓰레드에서 실행이 되었을때, 위의 그림과 같이 로그 메시지가 섞이게 된다. 이런 경우 요청 A에 대한 처리 내용을 확인하기 위해서 요청 A에 대한 로그만을 보고 싶을때 로그가 섞..

로그 시스템 #3 - JSON 로그에 필드 추가하기 조대협 (http://bcho.tistory.com)JSON 로그에 필드 추가앞에 예제에서 로그를 Json 포맷으로 출력하였다. 그런데, 실제로 출력된 로그 메세지는 log.info(“문자열") 로 출력한 문자열 하나만 json log의 message 필드로 출력된것을 확인 할 수 있다. 그렇지만, 단순한 디버깅 용도의 로그가 아니라 데이터를 수집하는 용도등의 로깅의 message라는 하나의 필드만으로는 부족하다. 여러개의 필드를 추가하고자 할때는 어떻게 할까? Json Object를 log.info(jsonObject) 식으로 데이터 객체를 넘기면 좋겠지만 불행하게도 slf4j에서 logging에 남길 수 있는 인자는 String 타입만을 지원하고, ..

로그 시스템 #2- 자바 로그 & JSON 로그 포맷조대협 (http://bcho.tistory.com) 앞 글에서 간단하게 자바 로깅 프레임워크에 대해서 알아보았다. 그러면 앞에서 추천한 slf4j와 log4j2로 실제 로깅을 구현해보자SLF4J + log4j2메이븐 프로젝트를 열고 dependencies 부분에 아래 의존성을 추가한다. 버전은 최신 버전을 확인하도록 한다. artifactid가 log4j-slf4j-impl 이지만, log4j가 아니라 log4j2가 사용된다. org.apache.logging.log4jlog4j-slf4j-impl2.11.2 다음 log4j2의 설정 정보 파일인 log4j2.properties 파일을 src/main/resources 디렉토리 아래에 다음과 같이 생성..