JH-Labs

병렬성(parallelism)의 문제  1) CPU마다 갖는 캐시를 서로 다르기 때문에 동기화가 어렵다는 문제가 있음(서로 로컬 캐시 이기 때문)2) L3 캐시를 사용하더라도 사로 다른 코어가 동시에 접근할 수 없음(lock)    - 보통의 경우 먼저 선점한 코어가 빠져나오기까지 block 됨.    - 이럴 거면 멀티 코어를 쓰는 의미가 없어짐 위와 같이 비동기(순서가 서로 다른), 병렬성에 따른 문제가 있었고 이를 해결하기 위해 프로그래밍 언어 레벨에서 해결하려는 노력들(RxJava, 콜백)이 있었다. 이러한 노력에도 단점들이 있는데, 콜백을 사용할 경우 콜백 정의부가 메소드 내부 인자로 들어감에 따라 코드 depth가 커지고 가독성이 나빠질 수 있으며 RxJava를 사용할 때엔 항상 스트림을 사용..

컨셉  - JetBrains 사에서 만든 언어- JVM 기반 언어    - .java에서 컴파일된 .class 파일을 동일하게 코틀린에서도 사용    - 자바에서 소스파일을 .java로 사용하듯 코틀린에서 같은 레벨에 .kt 파일로 정의됨- 코틀린이 자바와 100% 호환될 수 있는 이유: 코틀린도 .class 파일로 컴파일되기 때문. 따라서 import를 통해 코틀린 소스코드 내에서 자바 라이브러리, 스프링 등을 참조할 수 있음(import 시 이미 컴파일된 class를 참조하기 때문)- 2016년 코틀린 1.0 릴리즈, 스프링 프레임워크 5.0부터 코틀린 공식 지원, gradle의 경우 Groovy에 더해 Kotlin DSL 지원- JetBrains 사에서 코틀린 기반의 백엔드 애플리케이션 프레임워크 ..

controlplane을 구성하는 Pod IP 확인 현재 클러스터의 Pod CIDR은 10.244.0.0/16로 설정되어 있으며 호스트 CIDR은 172.31.50.113/20로 설정되어 있는 상태이다. 하지만 controlplane을 구성하는 Pod IP를 확인한 결과 kube api server를 비롯한 각종 Pod는 CNI 망에 속하지 않는 것을 볼 수 있다. cf. Pod CIDR 확인하기 k describe po -n kube-system | grep -i ip API server, kube-proxy와 같은 Master Node의 컴포넌트들은 CNI 망에 속하지 않고 호스트 네트워크 영역을 따른다.(모든 Master Node 컴포넌트가 그러한 것은 아님) 즉, 컨테이너(Pod)로 띄워지더라도 ..

1. 이슈 설명 ArgoCD 설치 후 github 레포와 ssh 연결을 설정하는 과정이 실패하는 문제. 2. 원인 분석 1) 방화벽 문제 - AWS EC2의 아웃바운드 및 인바운드 규칙을 확인한 결과 아웃바운드 룰은 모두 허용이었고 인바운드 룰에 github server와 22번 포트를 열어준 상태에서도 문제는 해결되지 않음. - 사실 아웃바운드 요청을 먼저 보내서 커넥션을 여는 상황을 의미하기 때문에 인바운드룰에 대한 설정은 현재 이슈와 상관이 없을것이라고 판단됨. 2) DNS 문제 - argocd-repo-server 로그 중 "dial tcp: lookup github.com on 10.96.0.10:53"가 있는 것으로보아, coredns 서버에 lookup을 했으나 실패한 것으로 확인됨. - c..

Horizontal Pod Autoscaler(HPA) 및 Vertical Pod Autoscaler(VPA) [Horizontal Pod Autoscaler (HPA)] HPA는 Kubernetes에서 가장 일반적으로 사용되는 오토 스케일링 기술로 애플리케이션의 수평적인 replicas 수를 동적으로 조정하여 애플리케이션의 부하에 따라 자동으로 조정하는 기능을 제공한다. HPA는 CPU 사용률, 메모리 사용률 또는 사용자 정의 지표를 기반으로 Pod의 replicas 수를 조정한다. [Vertical Pod Autoscaler (VPA)] HPA는 Pod의 replicas 수를 조정하여 가용 자원의 사용을 최적화하지만, VPA는 개별 Pod의 resources, request을 조정하여 수직 스케일링을..

시험 준비 - 패스트캠퍼스 Kubernetes 자격증 마스터 클래스 CKA/CKAD/CKS, https://fastcampus.co.kr/dev_online_kubemaster 문제에서 다룬 주제 1. ETCD 백업 / 복원 2. 클러스터 업그레이드 3. sidecar 컨테이너 - emptyDir 타입의 공유 볼륨 활용 4. Multicontainer-Pod 관련 5. Ingress Resouece - Ingress Controller는 이미 구성된 상태에서 룰만 구성 6. 노드 NotReady 트러블슈팅 - 컨테이너 런타임, kubelet이 정상적으로 실행 중인지 확인 7. 디플로이먼트 scale out 관련 8. ServiceAccount 구성 및 RBAC 할당(ClusterRole, 바인딩) 9. ..

이번 포스팅에서는 반응형(Reactive) 모델이 최근 떠오르고 있는 이유와 이에 대한 장단점, 반응형 프로그래밍을 표준화하기 위한 과정들, Spring에서 기존 서블릿을 대체하는 반응형 네트워크 엔진 등에 대해 알아본다. Blocking I/O와 Non-Blocking I/O의 동작 원리 반응형(Reactive) 프로그래밍을 이해하기 위해선 Non-Blocking I/O의 동작 원리와 Blocking I/O와 비교했을 때 어떤 장단점이 있는지를 명확하게 이해해야 한다. 위 그림과 같이 Non-Blokcing I/O 모델은 I/O가 발생하더라도 block되지 않기 때문에 다른 요청을 처리할 수 있게 된다. 따라서 더 적은 양의 쓰레드와 CPU로 다수의 요청을 동시에(Parallel의 의미가 아니라 Con..

Netty에서 제공되는 I/O는 모두 Non-Blocking 기반이다. 예를 들어, Bootstrap에 대한 connect, bind 또는 writeAndFlush 등의 I/O 메소드는 모두 Non-blocking I/O 기반으로 동작한다. Non-Blocking I/O Non-Blocking I/O는 쓰레드가 실행 중에 I/O 연산을 마주했을 때 system call을 하고 바로 빠져나와(Non-Blocking I/O) 다음 작업을 처리하는 방식이다. 따라서 Non-blocking I/O기반의 작업은 I/O가 완료되기 전까지 다른 작업을 수행할 수 있다는 게 핵심이다. 이러한 개념에 비추어 봤을 때, I/O 시간이 오래걸리는 것에 대해서 Non-blocking을 기반으로 하는 것이 좋다. I/O 시간이..