전체 글101 [메모 - EKS/VPC] EKS에서 다른 VPC 내에 있는 인스턴스에 접근하기 왓아원 EKS에서 다른 VPC 내에 있는 인스턴스에 띄워진 DB에 접근하고 싶다. 해결방법 1. vpc를 원하는 인스턴스가 있는 피어링을 연결한다. 2. 원하는 라우팅 테이블에 라우팅 연결 메뉴를 통해 vpc 피어링 (pcx-xxxxxxx)를 추가한다. 3. 보안그룹의 인바운드 및 아웃바운드를 수정해준다. 접속 확인! 여기서 주의점! 라우팅이 연결되어야 한다는 생각에 새로운 라우팅 테이블을 연결하고 subnet 연결을 편집했는데, 이렇게 되면 기존 eks의 네트워크에 영향을 주게 되기 때문에 새로 라우팅 테이블을 생성하는 것이 아닌 기존 라우팅 연결을 편집하는 것이 맞다. 참고자료 [AWS] 가장쉽게 VPC 개념잡기 가장쉽게 VPC 알아보기 medium.com 2023. 6. 29. [디버깅]NodeCreationFailure: Instances failed to join the kubernetes cluster => 왕짱삽질 인트로 image pull이 잘 되던것이 어느 시점부터 갑자기 되지 않기 시작했다. 처음부터 구성하자고 마음을 먹어 노드 그룹부터 생성을 시작했는데, 아래와 같은 에러가 떴다. 하우투 디벅? NodeCreationFailure: Instances failed to join the kubernetes cluster 해결해보아요~ 일단 ecr에서 imgpullback의 경우 i/o timeout 을 제외하고 별다른 로그를 볼 수 없었기에, 노드 생성에서 나타나는 오류부터 추적해보았다. aws에서는 아래와 같이 말하고 있다. 그런데 내경우는 이게 안먹혔다!!! ㅠㅠㅠ 기존에 잘 되던 것이 안되기 때문 알고보니 vpc 연결이 문제였다. 다른 vpc 내의 인스턴스에 띄워진 db에 접근하려고 vpc 라우팅을 수정하.. 2023. 6. 28. [디버깅기] airflow postgresql sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "postgres" (), port 5432 failed: FATAL: sorry, too many clients already 인트로 sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "postgres" (172.19.0.2), port 5432 failed: FATAL: sorry, too many clients already 서칭한 해결방안 재시작 하면 기존에 셋팅해두었던 airflow connection 값들이 모두 사라지기 때문에, postgres docker로 cp 를 진행하였다. Airflow psycopg2.OperationalError: FATAL: sorry, too many clients already I have a four node clustered Airflow environment that's been .. 2023. 6. 27. [디버깅기] eks Error from server (Forbidden): error when creating "manifest_aws.yml": deployments.apps "" is forbidden: unable to create new content in namespace because it is being terminated 인트로 namespace 를 삭제하고 새로 생성하려는데, namespaces 가 계속 Terminating 상태로만 남아있었다. cc@ksadlq001:~$ kubectl get namespaces NAME STATUS AGE cert-manager Active 29h default Active 2d10h kube-node-lease Active 2d10h kube-public Active 2d10h kube-system Active 2d10h -dashboard Terminating 2d10h 현상진단부터! 일단 띄워진 namespace 의 리소스 삭제 순서가 꼬인 것이니 현황을 파악한다. resource 내의 삭제 순서가 꼬이면 finalizers에 의해 삭제가 막힌다고 한다. 그러니까 finaliz.. 2023. 6. 26. pycharm파이참 에서 github auto copilot 사용하기 1. plugin을 설치한다. 2. Tools - Github copilot 을 통해 github계정과 연동한다. 이제 잘 사용하면 된다! tab을 누르면 자동완성! 2023. 6. 26. [디버깅기] eks 로 띄운 서비스 curl: (52) Empty reply from server/* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection [L4/L7, LoadBalancer, ingress, service, kubectl, aws eks] 요약: eks 에서 ingress를 생성해주어야 한다! 인트로 - 해결법을 찾아가기 azure 에서 k8s를 통해 서비스를 띄운뒤, 같은 내용의 manifest file을 eks 에도 띄우려고 하였다. 애저에서 잘 되던거니 어련히 알아서 잘 되겠거니 했는데, 서비스를 띄우는 것까진 성공했지만 막상 웹앱에 접근하려고 하니 serivce에서 제공하는 external ip 로 접근할 수 없었다. 그렇다면 내가 만든게 뭔가 잘못된 것! 아래는 내가 처음에 azure에서 띄운 서비스의 manifest 파일이다. kind: Namespace metadata: creationTimestamp: null name: my-name spec: {} status: {} --- apiVersion: apps/v1 kind: .. 2023. 6. 25. 데이터 품질의 비밀 - 데이터 품질에 주목해야 하는 이유 ch1 데이터 다운타임: data downtime 데이터가 수집되지 않아 누락되거나 부정확하게 측정되는 등의 데이터 손실로 인해 소프트웨어 또는 서비스의 가동이 중지되는 상황을 의미한다. 신뢰할 수 없는 데이터가 너무 많을 때 일어난다. 자체만으로 기업의 수익성이 크게 나빠지는 것은 아니다. 데이터 조직이 데이터 품질문제를 처리하기 위해 전체 업무 시간의 40% 이상을 소모한다고 한다. 데이터 다운타임의 근본적인 원인? Db 스키마 변경으로 인한 데이터 파이프라인 중단 주요 행 또는 열 중복 현상 대시보드 내 오류값 발생 등등… 프로덕션 데이터 소스시스템의 데이터 다운타임: 가동중지, 업타임: 정상 수행시간 다운타임은 소프트웨어 엔지니어링, 개발 및 운영과 모두 관련있어서 보통 업타임을 기준으로 성능을 측정한다.. 2023. 5. 3. 데이터 중심 애플리케이션 설계 - 분산시스템의 골칫거리 분산 시스템의 골칫거리 잘못될 가능성이 있다면 잘못된다 ㅠㅠ 결함과 부분 장애 우리는 소프트 웨어를 결정적으로 설계한다. 하지만 네트워크로 연결된 여러 컴퓨터에서 실행되는 소프트웨어는 오류가 날 수 있다. 부분 장애: 어떤 부분은 잘 동작하지만 어떤 부분은 예측할 수 없는 방향으로 고장 비결정적이다. 클라우드 컴퓨팅과 슈퍼컴퓨팅 대규모 컴퓨팅 구축 방법에 관한 철학 한쪽 끝에 고성능 컴퓨팅이 있다(high-performance computing, HPC) 다른 극단에는 클라우드 컴퓨팅이 있다. 사용ㅇ컴퓨터, 신축적, 주문식 자원할당(elastic, on-demand), 계량결제 전통적인 기업형 데이터센터는 이 두 극단의 중간지점에 있다. 철학에 따라 결함 처리 방법도 다르다. 슈퍼컴퓨터: 단일 노드처럼 .. 2023. 4. 28. 데이터 중심 애플리케이션 설계 - 트랜잭션 트랜잭션 트랜잭션은 수십년동안 여러 내결함성 결여로 인해 발생되는 문제를 해결하는 메커니즘으로 채택되어 왔다. 데이터베이스에 접속하는 애플리케이션에서 프로그래밍모델을 단순화 하려는 목적으로 만든 것이다. 안전성보장: safety guarantee: db에서 트랜잭션 사용을 통해 어플의 잠재적 오류와 동시성 문제를 무시할 수 있다. 항상 트랜잭션이 필요한 것은 아니다.‘ 이번장의 중요 질문: 트랜잭션이 필요한지 아닌지 어떻게 알 수 있을까? 애매모호한 트랜잭션의 개념 관계형 데이터베이스는 거의 모두 트랜잭션을 채택하는 경우가 많고, 비관계형 베이스는 채택하는 경우도, 아닌 경우도 있다. ⇒ 이 과정에서 트랜잭션의 의미가 약화되었다. ACID의 의미 원자성(atomicity), 일관성 (consistency.. 2023. 4. 26. 데이터 중심 애플리케이션 설계 - 파티셔닝 파티셔닝 샤딩 : 데이터를 파티션으로 쪼갤 필요가 있다. 파티션 : region, tablet, vnode, vbucket 처럼 서비스마다 쓰이는 용어가 다양하다. 데이터 단위가 하나의 파티션에 속한다. 파티셔닝을 원하는 주된 이유는 확장성이다. ⇒ 분산하여 질의 부하를 감소시킴 트랜잭션 기반인지, 분석 기반인지에 따라 시스템을 튜닝하는 방법은 다르지만, 기본적으로 둘ㄷ ㅏ파티셔닝의 원칙이 적용된다. 파티셔닝과 복제 보통 복제와 파티셔닝을 함께 적용해 각 파티션의 복사본을 여러노드에 적용한다. 한 노드에 여러 파티션을 저장할 수도 있다. 각 파티션마다 리더파티션이 있는 구조 키-값 데이터 파티셔닝 파티셔닝의 목적은 질의부하를 노드사이에 고르게 분산시키는 것이다. Skewed: 파티셔닝이 고르게 이루어지지.. 2023. 4. 24. 데이터 중심 애플리케이션 설계 - 복제 - 다중 리더 복제 다중 리더 복제 리더에 대한 의존성이 높다. 리더가 여러개: 다중리더설정, 마스터미스터 액티브/액티브 복제 다중 리더 복제의 사용사례 다중 데이터센터 운영 데이터 센터마다 리더를 두고 복제를 진행 오프라인 작업을 하는 클라이언트 인터넷이 끊어진 동안 앱이 계속 동작해야하는 경우 이 경우 로컬 데이터베이스가 있다. 아키텍처 관점에서 보면 근본적으로 다중 리더복제와 동일하다.(구글 캘린더?) 협업 편집 실시간 협업 편집 애플리케이션: ex 구글독스 오프라인 사용 사례와 공통점이 많다. 로컬에 적용하고 이후 비동기방식으로 타 사용자의 db와 연동한다. 충돌이 없으려면 편집전 문서의 lock을 얻어야한다. [펌] 파일락(File Lock) 쓰기 충돌 다루기 동기 대 비동기 충돌감지 단일 리더: 들어온 순서대로 .. 2023. 4. 21. 데이터 중심 애플리케이션 설계 - 복제 - 복제 지연 문제- 복제 지연 문제 리더기반 복제 : read-scaling 아키텍처 쓰기는 하나의 노드에서(리더기반) 나머지 복제된 노드는 읽기 처리만 진행하면 됨 쓰기비율이 낮고 읽기 비율이 높은 경우 유용하다. 실제로는 비동기식 복제에서만 동작한다. 동기식으로 처리시 네트워크 중단 등으로 시스템 불안정 초래 또한 비동기 처리 후 과거 데이터를 보여줄 수 있음.(불일치 발생=일시적인 효과 ⇒ 최종적 일관성) 자신이 쓴 내용읽기 일반적으로 사용자는 사용자가 제출한 데이터를 읽을 수 있음. 이때 종종 새로운 데이터는 리더에게 전송하지만 팔로워에서 읽을 수 있도록 함 ⇒ 데이터가 팔로워에 반영되지 않을 경우 유실된 것처럼 보이기도 함. 이 경우 입력은 보장하나 읽기는 보장할 수 없다 ⇒ 쓰기 후 읽기 일관성의 필요성 수정 시.. 2023. 4. 20. 이전 1 2 3 4 5 6 ··· 9 다음
