네른

약간 번외 느낌인데, Elasticsearch를 사용하다가 쌓인 데이터를 어떻게 처리할까? 에 대해 고민하다가 찾아봤다. 디스크가 터질 것 같았기 때문. ILM(Index Lifecycle Management)인데, 말그대로 elasticsearch index들의 수명을 어떻게 처리할지이다. 주로 Hot, warm, cold, delete 페이즈를 지정해서 일정 기간이 지나도록 접근이 없거나 접근 횟수가 낮으면 중요도를 점점 낮추다가 삭제하는 방식. - 기본적으로 hot-warm-cold 방식을 기반으로 동작 - 자주 접근되는 인덱스는 hot, 일정 기간 이상 접근되지 않으면 warm -> cold 순으로 내려감 - cold 상태에서도 일정 기간 이상 접근되지 않으면(데이터 조회나 추가가 없으면) del..

지난번에 작성한 Fluentd 내용을 토대로, 실제 EFK 스택을 kube에 올릴 때 사용한 yaml을 정리하고자 한다. 해당 yaml들은 helm chart를 기반으로 작성되어있어 일부 변수가 포함되어있다. 실제로는 해당 부분을 직접 채워넣어 사용해도 되니까 우선은 helm chart 내용을 토대로 정리한다! 우선, 각 애플리케이션별 구성은 크게 다음과 같다. Fluentd - Deployment (HTTP 로그 수집용 / Side-car 형태의 로그 수집용) - ConfigMap - Service (HTTP 로그 수집용 Pod를 위한 서비스) - Ingress Elasticsearch - Deployment - Service - Ingress Kibana - Deployment - Service - ..

보통 로깅을 위한 아키텍쳐라고 하면 ELK(Elasticsearch, Logstash, Kibana)의 구조를 생각하게 된다. 가장 유명한? 널리 알려진? 로깅/분석 스택이기 때문이다. Kubernetes 환경에서도, Kubernetes 자체의 로그 뿐 아니라 내부의 애플리케이션에 대한 로깅과 매니징이 필요하다. 그래서 사내에서 동작중인 앱에 대해 ELK 스택을 적용하고자 하였으나, CNCF stack을 찾아보니 Logstash보다는 Fluentd를 권장하고 있어 이를 사용하게 되었다. Fluentd에 대해 간단히 설명하자면 다음과 같다 - 오픈소스 기반의 로그 수집기 - HTTP, TCP, File 등 다양한 데이터 소스로부터 로그를 수집해 원하는 곳으로 전달(elasticseardch, s3)할 수 ..

본 글에서 알아볼 내용은, 쿠버네티스에서 환경변수, conf 파일 등을 어떻게하면 효율적으로, 편하게 사용하는지에 대한 내용. 실제 kubernetes를 이용하게 되면, 만약 conf 파일이 Pod 내에 있는 경우 이를 수정할 방법이 마땅치 않거나 매우 복잡. 그래서, 이를 조금 더 쉽게 하는 대표적인 두 리소스가 configMap과 secret. - 환경변수 혹은 설정파일을 일종의 변수로 두고 Pod가 생성될 때(배포될 때) 반영할 수 있도록! - 방법은 크게 두 가지로, 환경변수(env) 혹은 disk mount의 방법 ConfigMap - Key-Value 형태로 데이터를 저장할 수 있음 kind: ConfigMap apiVersion: v1 metadata: name: common-config n..

기존의 서비스들은 가용성을 유지하면서 애플리케이션을 업데이트하기 위해 블루-그린 업데이트 등의 방식을 사용해왔음. kubernetes에서는 이러한 업데이트를 '롤링 업데이트' 방식으로 처리함. - ReplicaSet 단위로 진행되며, 기존 ReplicaSet의 replica 수를 줄임과 동시에 새 ReplicaSet의 replica 수를 늘려서 유지되도록 이러한 과정을 추상화해두고, 이용하기 쉽게 해둔것이 바로 Deployment. 앞서 말했던것과 같이, deployment는 ReplicaSet의 추상화된 개념임을 유의 실제 deployment를 배포한 후, 다음과 같은 명령어로 기존 replicaset을 업데이트 할 수 있다. $ kubectl set image deployment DEPLOYMENT이..

Kube는 Pod의 health check를 이용해서 컨테이너를 자동으로 재시작할 수 있음 - 크게 Liveness / Readiness/ Startup Probe라는 세 방식이 있음 - 세 Probe 모두 다음과 같은 방법을 이용할 수 있음 1) Command Probe - 쉘 명령어를 수행하고, 결과값이 0이면 정상 livenessProbe: exec: command: ls -al 2) HTTP Probe - HTTP Get 메소드를 이용해 응답이 200대 혹은 300대인경우 정상 livenessProbe: httpGet: path: /test port: 8080 3) TCP Probe - 지정된 컨테이너에 TCP 연결을 수행해서 성공한경우 정상 livenessProbe: tcpSocket: port..

저번 포스트에서는 기본 오브젝트들에 대해 정리함. 이번에는 컨트롤러 - Replication Controller(ReplicaSet), Deployment, StatefulSet, DaemonSet, Job Controller 에 대해 정리하고자 함. Controller? - 쿠버네티스의 오브젝트를 관리해주는 것 Replication Controller (ReplicaSet) - 구 버전의 Replication Controller와 ReplicaSet은 동일. - Kube의 Pod 수를 일정하게 유지되도록 생성하고 관리하는 것이 주 역할. - Kube는 가용성 확보를 위해 동일한 Pod를 여러개 띄우게 되는데, 이를 replica로 묶어서 관리하게 됨 : 즉, 어떤 ReplicaSet의 replica 수..

쿠버네티스는 매번 할때마다 새롭기때문에, 간단하게라도 정리해두고자 함. 매우 간단하게 정리할 예정임! Kubernetest의 구조 - 크게 Master node와 Worker node로 구성되어있음 Master - API 서버 : KUBE의 기능을 API 형태로 제공하는 서버 - etcd : Key-Value 구조의 DB로, 설정값, 클러스터의 정보 등을 저장하는 DB - Scheduler : Pod, 서비스 등을 워커노드에 적절하게 할당하는 역할을 담당 - Controller Manager : Replica, Service, Volume, Node Controller 등 다양한 컨트롤러를 생성하고 관리하는 역할 - DNS : KUBE는 리소스의 endpoint를 DNS로 관리함. 각 리소스의 IP는 동..

앞서 실행한 두 테스트 이후에, 우선적으로 이미지를 생성하는 작업을 진행하였다. 이유는 뒤이어 실행할 두 테스트 (SiteSpeed.io / JMeter)가 실제 동작중인 백엔드 서버가 필요하기 때문. 그래서 우선 이미지를 만들어 push하고 push한 이미지를 구동한 후에 테스트를 이어서 진행하고자 하였다. 해당 단계를 설명하기 전에, 구성하였던 CI/CD의 전반적인 과정은 다음과 같다. 1. JUnit 테스트 2. Jacoco 테스트 3. 테스트용 Docker image 생성 -> 이후 pipeline 일시정지 4. 사용자는 생성된 docker image로 서버를 구동(스크립트 등을 이용해) 5. 테스트 이어서 진행(Gitlab에는 pipeline 일시정지 기능이 있다!) 6. SiteSpeed 테스..

이번엔 Jacoco. Jacoco또한 Java 테스팅 툴로, 앞서 작성한 JUnit의 테스트 코드를 그대로 사용하게 됨 해당 코드를 이용해서 전체 프로그램, 클래스의 커버리지(Coverage) 테스트를 진행할 수 있음 JUnit과 마찬가지로, Gradle 셋팅부터 시작 plugins { id 'java' id 'application' id 'jacoco' // 해당 내용 추가 } jacoco { toolVersion = 'Jacoco의 버전' } jacocoTestReport { reports { // xml.enabled = true // 설정에 따라 xml 혹은 csv로 레포트를 받을 수 있음 csv.enabled // 여기서는 csv로 결과를 받기로 함. 추후 있을 gitlab-ci를 위해 // x..