전체 글 47

[k8s] EKS IRSA, OIDC 이해

temporary security credential을 요청하기위해 AWS Security Token Service(STS)의 API 를 이용할 수 있다. temporary security credentials는 long-term access key credentials와 사실상 동일하게 동작한다. 하지만 만료시간이 존재하며, long-term AWS security credential 을 앱이나 웹에 직접 embed하는데 보안상 위험이 있기에 해당 방식을 사용해 AWS API를 이용하는것이 강력하게 권고되고 있다. temporary security credential을 받을 수 있는 방법은 OIDC provider를 생성하여 인증토큰을 받은 후 sts쪽에 AssumeRoleWithWebIdentity ..

카테고리 없음 2024.03.13

[k8s] 서비스를 통한 트래픽 전달 과정

서비스는 여러 파드들에 트래픽을 로드밸런싱해주는 역할을 한다. 부족하지만 이 과정에 대해 이해한 것들을 정리해 보려 한다 서비스의 IP,Port로 보낸 트래픽이 Pod의 Ip,Port 로 로드밸런싱 되는 상세 과정 k8s에서 서비스를 생성하고 pod를 매핑시키게 되면 서비스의 IP,Port가 생성된다. 이렇게 생성된 서비스의 IP와 Port로 향하는 트래픽은 패킷이 노드를 떠날때 노드마다 설치된 kube-proxy 에 의해서 매핑된 파드중 하나의 IP,Port로 랜덤하게 전달된다. 정확하게는 패킷이 노드를 떠날때 커널에서 kube-proxy에 의해 설정된 iptables 규칙을 참고하여 도착지의 Ip,Port 가 서비스의 Ip,Port쌍중에 하나인지를 확인한 후, 맞다면 그에 매핑된 파드의 Ip,Port..

tech/k8s 2024.03.02

좋은 서비스 운영환경을 만들기 위해서

현재 회사에 구축해 놓은 시스템들에 많은것들이 부족하다고 느낀다. 젠킨스에서 워커노드나 마스터노드간에 동일한 환경을 유지하는것이 잘 안되고 있다. k8s나 도커를 사용해 job실행시 이미지 기반으로 동일한 실행환경을 보장하는 것이 필요하고, 리소스를 동적으로 늘리는것에 대한 안정성에 대한 보장이 필요하다.트래픽이 안정적으로 인입되어 정상적으로 처리되지 않는 경우에 대한 알람, 자동복구 등에 대한 처리가 부족하다. 현재 트래픽이 서버에 도착한 이후에 Exception 이 발생했을때에 대한 알람은 sentry 로 존재하나, 트래픽이 서버에 제대로 도착하지 못 하는 모든 경우(서버가 죽어서) 는 서버의 헬스체크실패 알람 하나에 의존하고 있다.게임회사는 데이터가 생명이고 자주 변경/추가 가 이루어지는데, 이 처..

tech/생각 2024.03.01

[k8s] pod 의 상태에 관하여

Pod의 상태는 서비스 운영에서 중요한 모든 타이밍들과 깊이 연관되어있어, 상세한 이해가 중요하다. 예를 들어, 서비스에서 트래픽을 받게되는 시작타이밍은 Pod의 Readiness Probe가 통과되어 Pod의 Ready 컨디션이 True가 되는 순간이다. Pod에 이상이 감지되는 원리, 트러블슈팅시 진단하는 상황 등등 여러경우에서 Pod의 상태에 대한 이해가 요구된다. 우선, pod의 상태는 PodStatus 오브젝트에 기술되어 있고, PodStatus 오브젝트에는 상태와 관련된 여러 필드들이 존재한다. PodStatus 오브젝트 ### phase 필드 pod의 현재 라이프사이클을 나타내며, pending, running succeeded, failed, unknown 등의 상태가 존재한다. pendi..

카테고리 없음 2024.02.25

Aurora MySQL 성능테스트 과정기록

아래와 같이 redo log flush 가 굉장히 높은 load를 차지하며 TPS 한계지점을 확인할 수 있었다. aurora mysql 구조를 참고하면(https://plaid.com/blog/exploring-performance-differences-between-amazon-aurora-and-vanilla-mysql/ ) Master 인스턴스는 redo log 를 storage layer 와 replica 들에 계속해서 보낸다. 리더노드는 어떠한 page도 disk 에 보내는 행위를 하지 않는다. aurora는 마스터, 리더 모두 storage layer를 공유한다는 특이사항이 있다. undo 로그또한 storage layer에 존재한다. mysql 과 aurora의 구조이다 mysql 에선 pr..

카테고리 없음 2024.02.11

[k8s] pv 생성시의 avz 배치 설정에 관하여

AWS CSI 인터페이스에 대한 이해 쿠버네티스에서는 스토리지 연계를 위해 CSI 인터페이스를 제공. 쿠버네티스 CSI 인터페이스에 맞춰 개발된 AWS CSI를 CSI드라이버라고 한다. EKS에서 EBS,EFS등 AWS스토리지를 다룰 수 있게되는 것. 간단하게 헬름으로 설치할 수 있다. AWS CSI 드라이버는 크게 2가지 구성요소가 있다. AWS API를 호출하면서 aws 스토리지를 실제로 생성하는 csi-controller kubelet 과 상호작용하면서 aws 스토리지를 pod에 마운트하는 csi-node EBS 사용시 주의할점은 아래 3가지 설정. 1. accessMode: 몇개의 파드에서 연결할지 등 설정. 기본적으로 readwriteonce로 설정 2. volumeBindingMode: pv동..

카테고리 없음 2024.01.04

[k8s] 쿠버네티스 파드의 노드배치(Node Affinity, Taint, Toleration)

쿠버네티스는 pod 를 node에 배치할때 3가지 필터 절차를 갖는다 1. 볼륨 필터: pod에 필요한 디스크 볼륨이 노드에서 지원되는지 확인(마운트 충돌) 2. 리소스 필터: 충분한 리소스 있는지 확인 3. 토폴로지 필터: affinity, taint, toerance 등 확인 이중 affinity, taint, tolerance 에 대하여 간략하게 정리한다. node affinity pod 에서 특정 노드에 배치되도록 지정하는 정책. matchExpression을 통하여 라벨 조건을 지정해 노드를 지정할 수 있다. 스케줄링중에 적용되는 것이므로 이미 배치된 후에는 조건이 변경되었다해서 축출되거나 하지는 않는다. 아래 2가지 옵션을 각각 작성가능하다 requiredDuringSchedulingIgnor..

카테고리 없음 2024.01.03

[k8s] 무중단 배포를 위한 설정들

deployment 를 통한 배포시 타이밍적으로 "API 요청을 받을 수 없는 상태의 pod에 API 요청이 가는" 상황이 일시적으로 발생하는것으로 확인되었다. 원인은 "서비스에서 pod를 제외한 후 pod를 terminating 시키는 것이 아니라, pod를 죽인 후 service에서 제외시키는" 것 때문이다. 이 문제를 k8s의 의도한 바를 토대로 해결하기 위해서는, 어플리케이션에서 graceful shutdown 구현이 필요하다. 사실 정확하게는 graceful shutdown 을 구현한다해도 무조건적으로 service가 어플리케이션 트래픽을 끊는 시간보다 늦게 종료처리될것이라는 보장을 어떻게 하는지에 대해선 정확한 이해를 하지 못했다. 쉽게 해결하는 방법은 pod 를 terminating 시키는 ..

tech/k8s 2024.01.02

websocket 내부 동작 정리 & signalr

websocket 연결 과정 1. websocket handshake TCP 소켓 리스닝을하며, HTTP 프로토콜의 GET request 에 응답한다 클라이언트는 websocket handshake process를 거친다. HTTP request가 시작이며 아래와 같은 HTTP header 를 보낸다 GET /chat HTTP/1.1 Host: example.com:8000 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 이과정에서 어떤 header라도 부정확한 값을 갖거나 서버가 해석하지 못하는경우 서버는 400(bad request)를 응답하게 된다. we..

tech/network 2023.10.26

apache lucene 내부구조

개요 아파치 루신은 open-source, high-performance, scalable DB 엔진이다. elasticsearch, solr등의 오픈소스 프로젝트들이 루신을 엔진으로 사용하고있다. 특징 1. inverted index 데이터구조를 사용한 인덱싱 구조 사용 2. 데이터 저장 구조가 log-structured 이다. 즉, disk의 도큐먼트 정보 혹은 인덱스 정보가 inplace로 수정되지 않는다. 인덱스를 예로 들면, 인덱스는 여러 세그먼트(immutable, append only)로 구성되고 새로운 segment들이 계속적으로 생성되고 과거의 segment들은 merge를 통해 합쳐져서(compaction이라고 함) 전체 segment 갯수가 일정이하로 유지되는 식의 구조이다 위 1번의..

tech/database 2023.10.22