전 포스팅에서 k6로 300 VUs 부하테스트를 돌렸더니 평균 응답시간이 4초가 넘게 나왔다. 원인을 찾아보니 application-prod.yaml에 Hikari 설정 자체가 없어서 기본값인 10으로 돌아가고 있었다. 문제 300명이 동시에 주문하면 DB 연결이

현재 부트캠프에서 뽀시래기라는 프로젝트를 진행하고 있다.도메인은 https://pposiraegi.cloud/login 인데, 타임딜 서비스이기 때문에 순간적인 트래픽이 폭증하는 상황도 연출하고 그걸 버티는 상황인지 테스트를 해야하기 때문에 k6를 통해 테스트

GitHub Actions도 고치고, 부트스트랩도 정상 실행됐는데 이번엔 ArgoCD가 CD(배포) 과정에서 문제가 생겼다. ArgoCD는 Git 저장소를 바라보며 Kubernetes 클러스터에 자동으로 배포해주는 도구인데, 이 단계에서 또 막혔다.위처럼 OutOfSy

Terraform apply와 GitHub Actions CI/CD까지 성공한 후, 이제 EKS 클러스터에 플랫폼 컴포넌트를 설치할 차례였다. 팀원이 만들어준 bootstrap-platform.sh 스크립트를 실행하면 ArgoCD, Karpenter, Istio 등을

저번 포스팅에서 프론트엔드 CI 쪽은 수정했지만, 백엔드 4개 서비스는 해결하지 못했다. 이번 포스팅에서는 백엔드 쪽 오류를 수정한 과정을 정리해보려 한다.이 에러는 production 네임스페이스가 존재하지 않아 발생하는 오류다.원인을 파악해보니, terraform

처음에 깃허브 argocd가 안되어서 왜 그런가 봤더니조직 레벨에서 외부 액션 사용이 막혀있어서 pnpm/action-setup@v3 같은 액션을 못 쓰는 문제가 생겼다.이거를 프로젝트 레포에서 보니 변경이 막혀있어서조직 Settings에서 "Allow all acti

argocd 연결까지 완벽하게 끝냈는데 production pod를 연결하는 과정에서 crashloopback 오류가 떴다. 이를 해결하기 위해 시스템로그(/var/log/messages에 있는 로그)를 보고 그럼에도 안되면 dmesg 커널 메세지를 따보기로 하려 한

이번 포스팅은 ArgoCD Sync를 시도하다가 연속으로 두 가지 문제를 맞닥뜨린 트러블슈팅 기록이다.결론부터 말하면 레포 이름 오타 → 폴더 경로 오류 → RDS 보안 그룹 차단 순서로 문제가 터졌고, 아직 완전히 해결 전 단계다.Sync 전에 RDS, ElastiC

이번 포스팅에서는 AWS EKS 클러스터에 ArgoCD를 설치하고, GitHub 레포지토리와 연동해서 자동 배포까지 설정하는 과정을 정리했다.

팀원이 tfstate s3 버킷을 지정하면서 오류가 생겨서 이거때문에 terraform apply가 안되는 오류가 발생했다.팀원이 보내준 사유는 다음과 같다현재 pposiraegi-ecommerce repo에서 Terraform/EKS 접근 문제가 있습니다.중요:파일

본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.이전 게시물에서 프로젝트를 시작했을 때 포스팅을 남겨놓았다.그때는 기획 수준이었는데, 지금은 그때와는 다른 고민들을 하기 시작했다.CI/CD 파이프라인 구성이라든지, 자동 배포 전략은

팀 프로젝트에서 kafka를 사용하기로 결정했고, 이에 대한 얕은 지식만 갖고 있었다. 그러다 멘토님께서 kafka가 뭔지 설명하라고 하셨고, 이를 사용하는 이유 등 기초적인 질문을 던지셨는데 제대로 답변하지 못하는 나의 모습을 보고제대로 알고 써야겠다는 생각에 다시

본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.3개월의 이론 기간이 끝나고 드디어 프로젝트를 시작하게 되었다.그런데 중간에 설 연휴도 끼어 있어서 실질적으로는 약 1주일 정도 진행을 하지 못했다.설 연휴 전에 프로젝트명과 도메인을

본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.오늘은 구름의 딥다이브 과정을 반 정도 지나온 시점에서, 약 3개월 동안 느낀 점을 정리해보려고 한다.또한 과정이 어떻게 진행되는지 간략하게 소개하고, 그중에서도 가장 마음에 들었던

쿠키와 세션에 대해 공부하고 있는데, 실제 쿠키가 어떻게 동작하는지 이해가 잘 안 가서 실습을 진행해보기로 결정했다.클라이언트(브라우저)가 페이지를 요청한다.ex)사용자가 사이트에 접속웹서버는 쿠키를 생성한다.ex) 로그인 세션 ID 만들기서버는 응답(Response)

그동안은 쿠버네티스 환경을 구성할 때 강사님께서 주시는 vagrantfile을 그저 받아서 vagrant up을 하여 설치환경을 구성하였는데, 이제는 단순한 실습 환경을 넘어서,인프라 관리자의 관점에서 쿠버네티스를 어떻게 설치해야 하는지를공식 문서를 기준으로 하나씩 확

컨테이너가 등장하기 전의 배포 방식은 비교적 단순한 구조였다.애플리케이션을 빌드해서 나온 실행 파일을 서버에 복사하고 실행하는 방식이다.개발자는 IntelliJ 같은 IDE를 사용해 코드를 작성한다.개발이 완료되면 Gradle 같은 빌드 도구를 통해 빌드를 수행한다.빌

리눅스는 크게 Debian 계열과 Red Hat 계열로 나눌 수 있다.이 구분은 무료/유료의 문제가 아니라, 패키지 관리 방식과 배포 정책의 계열 차이이다.Debian 계열은 apt, dpkg 기반의 패키지 관리 방식을 사용한다.Red Hat 계열은 rpm, dnf(y

이번 게시물에서는 Grafana 대시보드에서 Dashboard > New panel을 통해 Histogram 시각화를 직접 만들어보는 과정을 정리해본다.목표는 Kubernetes API Server 요청 처리 시간의 분포를 히스토그램으로 확인하는 것이다.우선, 데이터가

이번 게시물에서는 그라파나 대시보드에서 apiserver 요청에 대한 응답시간 (시간 흐름)을 heatmap을 만들어보려고 한다.우선 를 쿼리하여 데이터가 나오는지 확인해본다.이제 여기에 sum을하고 1m에 대해 less then equal로 group by하여 쿼리한