개요 - 쿠버네티스 리소스를 직접 다룰 때의 불편함운영 중인 쿠버네티스 클러스터 안에는 수많은 리소스가 존재한다. Pod와 이를 관리하는 Deployment, 클러스터 내/외부와의 통신을 위한 Service, 변수 관리를 위한 Configmap 등이 이에 해당한다.이러한 쿠버네티스 리소스들은 보통 리소스별로 별도의 yaml 파일에 명시하고 관리하게 되며, 아래와 같은 명령어를 통해 클러스터에 배포한다.kubectl apply -f {resource name}언뜻 보면 그렇게 복잡한 작업이 아니어보일 수 있지만, 매번 동일한 클러스터를 구성하기 위해 수십 개의 리소스에 대해 이 명령을 실행하는 것은 꽤나 귀찮은 일이 될 수 있다.또한, 리소스의 변경 주기가 개별적으로 동작하니 변경 관리를 하기 어렵다. 언..
개요 - 민감 정보를 클러스터에 저장하려면?애플리케이션을 운영하다 보면 데이터베이스 접속 정보, API 키, 인증서 등과 같은 민감 정보를 안전하게 관리해야 한다. Kubernetes에서는 ConfigMap, Secret과 같은 환경변수 관리 목적의 리소스를 제공하지만, 이러한 방법들을 통해 민감 정보를 다루는 것은 보안적인 측면에서 명백히 한계를 갖고 있다.본 글에서는 아래와 같이 민감 정보가 전달되는 과정에서 어떻게 민감 정보를 다루는 것이 더 좋을지 각 단계별 데이터의 형태를 기준으로 살펴보고자 한다.Local Machine - 개발자가 작업하는 로컬 머신External Storage - 작업물이 올라가는 저장소. GitHub과 같은 서비스Kubernetes Cluster - 애플리케이션(Pod)이..
개요대부분의 백엔드 개발자들이 처음 데이터를 영속화할 DBMS를 선택할 때 MySQL을 선택한다.그리고 JDBC를 이용해 MySQL에 연결하고자 하는 Spring 백엔드 개발자라면, 애플리케이션 서버와 MySQL을 연결하다가 아래와 같은 오류를 마주하게 될 수 있다.“Public key retrieval is not allowed”어? 이게 뭐지? 구글에 검색해보니, 아래와 같은 옵션을 붙이면 문제를 해결할 수 있다고 한다.useSSL=false&allowPublicKeyRetrieval=trueDB 연결 세팅에 위 옵션을 더하니 정말로 연결이 잘 된다.이제 문제를 해결했으니 내 애플리케이션을 구동하면 되겠다. 그런데…저 오류는 정말 문제일까? 위 옵션을 더하는 것은 문제의 해결이라고 볼 수 있을까?이 ..
k6란?k6는 그라파나 랩스(Grafana Labs)에서 개발 및 운영 중인 오픈 소스 도구로, 개발자 친화적으로 부하 테스트를 수행할 수 있도록 돕는 도구이다.k6는 내부적으로 Go언어의 gorutine(go의 경량화된 가상 스레드)을 기반으로 동작하는데, 이러한 점 덕분에 싱글 스레드 내에서 비동기로 가상 유저의 동시 요청을 수행하여 다른 멀티 스레드 기반 도구들에 비해 시스템 리소스를 효율적으로 사용할 수 있다는 특징이 있다.또한, 자바스크립트 문법으로 작성되는 스크립트를 기반으로 동작하여, 개발자는 k6 문법과 사용법에 대한 러닝커브만 감당하면 별도 언어를 학습할 필요가 없다는 장점도 있다.이번 글에서는 이 k6의 실행 조건을 구성하는 설정값인 option에 어떤 정보들이 들어갈 수 있는지 알아보..
요구사항 - 크레딧 서버 개발어느 날, 물건 판매 개발이 포함된 서비스의 개발자인 나에게 사용자의 크레딧을 관리할 수 있는 크레딧 서버의 개발 및 요청이 들어왔다.이 크레딧은 매일 자정에 30으로 초기화되며, 사용자들은 매일 이 30개의 크레딧을 통해 물건을 구매할 수 있다. 구현 편의성을 위해 이 서버는 물건 당 크레딧, 사용자 세부 정보 등의 정보는 다루지는 않는다고 가정한다.그리하여 이 크레딧 서버가 제공해야 하는 API는 2개이다.크레딧 차감사용자 아이디, 크레딧 사용량을 입력으로 받아 해당 사용자의 크레딧을 차감크레딧 조회사용자 아이디를 입력으로 받아 해당 사용자의 당일 잔여 크레딧을 반환지금부터 2가지 방식의 설계 하에 2가지 기능을 구현하고, 2개 설계의 성능을 비교해보고자 한다. 설계버전..
어느 날, 개발자 A가 실수로 개발자 B의 PR에 해당 PR의 커밋을 반영하지 않은 브랜치로 force push를 올려 원래 PR의 작업물 일부가 날아가버리는 사고가 발생했다.개발자 B는 자신의 로컬 브랜치를 찾아 다시 변경 사항을 반영하려 했으나, 로컬 브랜치를 이미 지워버린 뒤였다는 사실을 깨달았다…개발자 A와 B는 절망에 빠졌지만, git의 놀라운 기능들을 이용하면 이 작업물을 복구할 수 있다고 한다.지금부터 이 작업물을 복구하는 방법을 알아보자! 이 글의 예상 독자hard reset, 브랜치 삭제 등에 의해 커밋을 잃어버린 사람들 잃어버린 커밋을 되찾는 방법 3가지잃어버린 커밋을 되찾는 방법은 3가지가 있다.커밋 해시로 복구 브랜치 생성git reflog 명령을 이용git fsck 명령을 이용1..