구축된 모니터링

• 성능 모니터링
  
• 로그 모니터링
  

메모리… 부족으로 ELK가 터졌다

eyestalk1:~/environment/aws $ kubectl get no
NAME                                             STATUS     ROLES    AGE     VERSION
ip-10-0-18-177.ap-northeast-2.compute.internal   Ready      <none>   3d23h   v1.23.13-eks-fb459a0
ip-10-0-22-140.ap-northeast-2.compute.internal   Ready      <none>   3d23h   v1.23.13-eks-fb459a0
ip-10-0-25-194.ap-northeast-2.compute.internal   Ready      <none>   3d23h   v1.23.13-eks-fb459a0
ip-10-0-28-81.ap-northeast-2.compute.internal    NotReady   <none>   3d23h   v1.23.13-eks-fb459a0

eyestalk1:~/environment/aws $ kubectl get po
NAME                           READY   STATUS        RESTARTS   AGE
back-deploy-6ff7fdc48f-bmdjn   1/1     Running       0          4h45m
front-deploy-7ff495c49-vnfkf   1/1     Running       0          15m
kibana-b4f699d9d-d2kz2         1/1     Terminating   0          42m
redis                          1/1     Running       0          5h9m
sig-deploy-869bb56644-drdq6    1/1     Running       0          4h51m
sig-deploy-869bb56644-jrqqg    0/1     Pending       0          15m

kubectl describe no ip-10-0-28-81.ap-northeast-2.compute.internal

⇒ 사용한 인스턴스 t3.small 이었다

EKS - AutoScaling을 사용하여 m5.large update 하기

이미 구축된 EKS에서 어떻게 인스턴스 용량을 업데이트할지 찾아보다가 AutoScaling에서 해당 노드를 죽이고 다시 살릴때 용량을 수정하면 된다는 정보를 보게되었다

전부 m5.large로 바꼈다!

어림도 없지 다시 EKS부터 구축...!

노드의 인스턴스 타입을 m5.large로 변경해도 노드그룹의 인스턴스 타입은 변경되지 않아 다시 용량부족이 되었다.
클러스터 설정을 가보면 노드 인스턴스는 m5.large이지만 노드그룹은 t3.small로 되어있는 것을 알 수 있다

다시 구축하고 난뒤 충분히 pod를 사용할 수 있었다

로그모니터링 구축

### 사용한 이미지 버전 
ELasticSearch: 7.10.1
Kibana: 7.10.1
Fluentd: fluent/fluentd-kubernetes-daemonset:v1.7.4-debian-elasticsearch7-2.2

참고자료
EFK Stack 구축을 통한 로그 수집

• Elasticsearch : 로그 저장소
• Fluentd: 로그를 수집하는 로그 수집기. 모든 노드마다 동일하게 배포되어야 함 (Daemonset)
• Kibana: ElasticSearch와 연동하여 로그 시각화

수집 대상 → (로그 스트림) → Fluentd (수집) → elasticsearch (저장) → kibana (시각화)

Elasticsearch

loadbalancer의 보안그룹 9200 포트를 열어서 외부를 통해 LB의 9200번 포트로 접근

LB 리스너 편집 → 9200번 포트로 들어온 트래픽을 인스턴스(워커노드)의 30920 포트로 전달

elasticsearch.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: elasticsearch
  labels:
    app: elasticsearch
spec:
  replicas: 3
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
      - name: elasticsearch
        image: elastic/elasticsearch:7.10.1
        env:
        - name: discovery.type
          value: "single-node"
        ports:
        - containerPort: 9200
        - containerPort: 9300
        
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: elasticsearch
  name: elasticsearch-svc
  namespace: default
spec:
  ports:
  - name: elasticsearch-rest
    nodePort: 30920
    port: 9200
    protocol: TCP
    targetPort: 9200
  - name: elasticsearch-nodecom
    nodePort: 30930
    port: 9300
    protocol: TCP
    targetPort: 9300
  selector:
    app: elasticsearch
  type: NodePort

확인

rapa0005:~/environment $ kubectl get pod,svc | grep elastic                                                     
pod/elasticsearch-6b79d9746d-6b2j8   1/1     Running   0          10h
pod/elasticsearch-6b79d9746d-g4v9h   1/1     Running   0          10h
pod/elasticsearch-6b79d9746d-vxlw4   1/1     Running   0          10h
service/elasticsearch-svc   NodePort    172.20.226.36    <none>        9200:30920/TCP,9300:30930/TCP   10h

lb의 리스너에 추가
리스너는 정의한 프로토콜과 포트를 사용해 연결 요청을 확인하는 프로세스.
라스너에 정의한 규칙에 따라 lb가 등록된 대상으로 요청을 라우팅하는 방법을 결정.

보안 그룹 인바운드 규칙 추가
[ EC2 → 로드밸런서 → 보안 → Security Group ID 클릭 → 인바운드 규칙 편집 ]

lb DNS에 9200번 포트를 붙여서 접속 확인

Kibana

LB의 보안그룹 5601번 포트를 열어서 외부를 통해 LB의 5601 포트로 접근

LB의 리스너 편집 → 5601 포트로 들어온 트래픽을 인스턴스(워커노드)의 30561 포트로 전달

kibana.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana
  labels:
    app: kibana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kibana
  template:
    metadata:
      labels:
        app: kibana
    spec:
      containers:
      - name: kibana
        image: elastic/kibana:7.10.1
        env:
        - name: SERVER_NAME
          value: "kibana.kubenetes.example.com"
        - name: ELASTICSEARCH_HOSTS
          value: "http://elasticsearch-svc.default.svc.cluster.local:9200"
        ports:
        - containerPort: 5601

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: kibana
  name: kibana-svc
  namespace: default
spec:
  ports:
  - nodePort: 30561
    port: 5601
    protocol: TCP
    targetPort: 5601
  selector:
    app: kibana
  type: NodePort

확인

rapa0005:~/environment $ kubectl get service,po | grep kibana
service/kibana-svc          NodePort    172.20.240.80    <none>        5601:30561/TCP                  11h
pod/kibana-b4f699d9d-5rsqs           1/1     Running   0          11h

로드밸런서에 리스너 추가

보안그룹에서 인바운드 규칙 추가

lb DNS:5601

fluentd.yaml

→ Daemonset으로 배포 (모든 워커노드에 존재)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd
  namespace: kube-system

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: fluentd
  namespace: kube-system
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - namespaces
  verbs:
  - get
  - list
  - watch

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: fluentd
roleRef:
  kind: ClusterRole
  name: fluentd
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: fluentd
  namespace: kube-system

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
    version: v1
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-logging
      version: v1
  template:
    metadata:
      labels:
        k8s-app: fluentd-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccount: fluentd
      serviceAccountName: fluentd
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.7.4-debian-elasticsearch7-2.2
        env:
          - name:  FLUENT_ELASTICSEARCH_HOST
            value: "elasticsearch-svc.default.svc.cluster.local"
          - name:  FLUENT_ELASTICSEARCH_PORT
            value: "9200"
          - name: FLUENT_ELASTICSEARCH_SCHEME
            value: "http"
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

확인

rapa0005:~/environment $ kubectl get pod -n kube-system | grep fluentd
fluentd-hd2xq                                   1/1     Running   0          11h
fluentd-p5b8m                                   1/1     Running   0          11h
fluentd-pptws                                   1/1     Running   0          11h
fluentd-sqc9q                                   1/1     Running   0          11h

로그 (pod, 컨테이너 관련)

webrtc_room index pattern 생성
→ python 로그를 수집하기 위해 python에 logger관련 코드 추가

Elasticsearch 접속 오류 개선

---

• fluentd 1 개로 변경 / elasticsearch1 / kibana:daemonset
  
• 200, 200, 200 맞춤
  

☀️ 모니터링 최종 정리

성능 모니터링 : CloudWatch

---

• EKS성능을 확인 할 수 있는 모니터링을 CloudWatch에 구축함
• helm으로 Promethus, Dashboard를 설치하였으나 CloudWatch가 이를 대신하고 있기 때문에 발표에서는 제외시키기로함.
• Distro를 설치하여 CloudWatch에서 Container Insight로 배포된 애플리케이션을 모니터링이 가능하다
• 비용 절감을 위해서 CPU사용 일정 수준이 넘어가면 메일이 오도록 했다

Container Insight

Cloud Watch 대시보드

CloudWatch 경보 알람 메일 확인

로그 모니터링 : ELK

---

• 원하는 로그가 발생되고 있는 python 코드에 수집하고 싶은 로그를 저장한 후 인덱스를 만들어서 elasticSearch에 저장
• 수집한 로그를 시각화하기 위해 elasticSearch와 kibana를 연동해 로그 대시보드를 커스텀하여 모니터링한다

수집한 로그

로그	설명
des	수집한 로그에 대한 설명 (create room, New member joined, user-disconnect,chatting)
user_nickname	사용자가 방에 입장할 때 설정한 닉네임
chatting message	사용자가 보낸 채팅 메시지 (RSA 암호화 처리됨)
room_id	방 생성 시 설정된 방 이름
@timestamp	로그가 발생한 시간

Kibana 대시보드 구성

대시보드	설명
24H 방 생성 사용량	24시간동안 어느 시간대에 방이 많이 생성되는 지를 확인할 수 있다.
Today 방 생성 수	하루동안 방이 얼마나 생성되는 지를 확인할 수 있다.
room 별 채팅 개수	방에서 채팅의 수가 어느정도 되는지 확인할 수 있다.
room 별 채팅 내역	RSA 암호화 됨
Today 서비스 접속 인원	하루동안 해당 서비스에 몇명의 사람이 접속하는지 확인할 수 있다.

방이 생성되고 채팅을 하면 방 생수, 접속자 수, 방 이름과 채팅이 Kibana에서 볼 수 있도록 구성했다