기록하는 습관 "기습"

컨테이너 이미지 사이즈가 다르다?

의문 발생2025.07.29 - [Container & Orchestration/Docker] - Docker, 보안, 그리고 이미지 최적화 Docker, 보안, 그리고 이미지 최적화배경프로젝트 진행 중에 컨테이너 이미지 보안에 관련해서 지적을 받았기에 조치를 진행하고 있었다. 문득 이보다 더 효율적으로 만들 수 있지 않나 싶었다. 이미지 크기를 줄이고 캐시까지 적aitidev.tistory.com 이전 프로젝트에서 한 가지 실험을 위해 윈도우 컴퓨터에서 컨테이너 이미지를 빌드하였다.그런데 Mac(arm64)에서는 빌드 이후 이미지 사이즈가 445MB였는데 윈도우(amd64)에서 진행하니 289MB다..! 무시하기에는 너무 큰 차이기 때문에 어떤 게 실제 크기의 이미지인지, 왜 이런 일이 발생한 것인지 ..

참고 - ArgoCD + HPA Metric이 필요하다No Metric API왜인지 HPA가 동작하기 않기에 kubectl get hpa 명령어로 확인해보았다. 그런데 unknown으로 잡히는 것 아닌가? 뭔가 문제인지 알아보니 HPA에서 Metric를 수집할 수 없기 때문에 동작하지 않는 것이었다. 지금껏 promethus로 필요한 메트릭을 수집하고 있다보니 metrics-server를 없다는 것을 이제 알았다.prometheus와 연동하게 할 수 있지만 시간이 없는 관계로 이를 생략하고 일단 metrics-server를 설치하였다.# 리포 추가/업데이트helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/helm r..

배경EKS를 켜기 위해 Terraform에서 plan 명령어를 실행하였다. 처음 시도했을 때 내가 모르는 variables를 입력하라고 해서 강제로 종료하였다. 나중에 알고보니 AWS Secret manager에서 필요한 값이다. 팀원 분이 적용해주셨는데 바쁜 나머지 정보 공유가 되지 않은 것 같다.어쨌든 정체를 파악하고 2번째로 Terraform plan 명령어를 시도하니 다음과 같은 에러가 발생하였다.│ Error: Error acquiring the state lock│ │ Error message: operation error DynamoDB: PutItem, https response error StatusCode: 400, RequestID: PI3UVPVOJ9HUK4QKERQ1L9U7NFVV..

의문의 시작점2025.07.29 - [Container & Orchestration/Docker] - Docker, 보안, 그리고 이미지 최적화 Docker, 보안, 그리고 이미지 최적화배경프로젝트 진행 중에 컨테이너 이미지 보안에 관련해서 지적을 받았기에 조치를 진행하고 있었다. 문득 이보다 더 효율적으로 만들 수 있지 않나 싶었다. 이미지 크기를 줄이고 캐시까지 적aitidev.tistory.com이전에 작성한 글에서 언급하지 않았었다. Docker에 빌드 과정이나 캐싱에 대해 알아보는데(캐싱은 더 공부가 필요하다..) 점점 Docker의 동작 원리에 관심이 가기 시작했다. 문득 Docker가 어떻게 호스트와 격리된 공간, 컨테이너를 만드는지 궁금했다.호스트 OS 커널을 빌려 사용한다는 건 알겠는데 ..

Base64란 무엇인가Base64는 이진 데이터를 64개의 ASCII 문자로 변환하는 인코딩 방식이다. 이 방식은 8비트 이진 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 문자로 바꾸어, HTTP나 이메일 등의 텍스트 기반 시스템에서 안전하게 전송할 수 있게 한다. 주로 이메일 첨부나 HTML에 이미지를 포함할 때 사용되며, 데이터 크기가 약 33% 증가하지만 플랫폼 간 호환성을 보장한다.Base64는 바이너리 데이터의 손실을 막기 위해 개발되었다. ASCII는 7비트 인코딩인데, 시스템마다 나머지 1비트를 다르게 처리하거나 제어 문자 코드가 달라 문제가 발생할 수 있다. Base64는 안전한 64개 문자(A-Z, a-z, 0-9, +, /)만 사용해 이러한 문제를 해결한다. 예를 들어, AP..

문제2025-08-12T15:59:30.088Z WARN 1 --- [ main] o.m.jdbc.message.server.ErrorPacket : Error: 1698-28000: Access denied for user 'root'@'192.xxx.x.xxx' 쿠버네티스 클러스터 내에서 ArgoCD로 배포를 진행하는 와중에 특정 서비스에서 저런 에러 로그가 발생했다.말 그대로 DB 연결이 안된다는 의미다. 처음에는 "뭐지? 환경 변수가 잘못됐나?" 싶어서 Base64로 인코딩된 변수들을 직접 디코딩해보았다. 문제가 없었다! 값은 잘 있다.그래서 다음엔 DB 계정의 아이디, 비밀번호, 권한 순으로 찾아보았다. 이 또한 잘못된 것은 없었다.Deployment yaml 파일이 잘못 작성되었나 싶었다. 물..

배경프로젝트 진행 중에 컨테이너 이미지 보안에 관련해서 지적을 받았기에 조치를 진행하고 있었다. 문득 이보다 더 효율적으로 만들 수 있지 않나 싶었다. 이미지 크기를 줄이고 캐시까지 적용하면 CI 빌드 시간을 생각보다 단축할 수도 있을 것 같았다. 따라서 이미지 최적화를 진행하고자 했다.이 글을 볼 사람들에게 미리 알려주자면 Github actions를 사용해 컨테이너 빌드를 진행한다. SpringDockerGithub actions 이미지 최적화진행 중인 프로젝트에서 Dockerfile의 변화가 어떻게 진행됐는지 보면서 설명하겠다.첫 번째 버전은 다음과 같다. FROM gradle:8.14.2-jdk21 AS buildWORKDIR /appCOPY gradlew .COPY gradle ./gradleC..

가상 스레드(Virtual Thread)?최근에 진행중인 프로젝트에서 맡은 거래 엔진 자원의 효용성을 높이기 위해 이것저것 공부하고 있다. 그러던 중 한 1년에 알게 된 Virtual Thread를 다시 공부하게 됐다. 이번엔 이를 다뤄보고 적용할 수 있지 없을지 판단해보겠다.자바 전통의 플랫폼 스레드(OS 스레드)는 생성·전환 비용이 높고, 스택이 고정(1MB ±)이라 메모리도 많이 소모한다. I/O-blocking 중심의 웹 서버처럼 “대기 시간이 긴 짧은 작업”이 수천 ~ 수만 개 쌓이면 플랫폼 스레드 방식은 금세 한계에 부딪힌다.이를 해결하기 위해 JDK 21부터 가상 스레드가 정식 도입되었다. 가상 스레드는 JVM 안에서 스케줄링되는 초경량 스레드로, 필요한 순간에만 소수의 캐리어(플랫폼) 스레..

지난 반 년 간내가 작성한 2024년 회고에 2025년에는 무엇을 하겠다고 했는지 다시 보았다.올해는 새롭게 무언가를 시작하고, 성장하고 발전하여 어엿한 사회구성원이 되는 게 목표다.사실상 목표는 3가지였다.새로운 활동엔지니어로써 성장취업이 중 1개는 달성했다고 생각한다. 1개는 달성 중이다. 1개는 아직이다.뭐가 됐든, 반 년 간 열심히 달려왔다. 벌써 반 년이다. 이 정도나 달려왔다는 게 되돌아보면 신기하다. 조금씩 스스로 발전하고 있다는 것도 알 수 있다.이번에는 지금까지 무엇을 했고, 앞으로 무엇을 할 건지 내 생각과 함께 정리해보고자 한다. 취미에 집중하자재작년부터 블로그에 개발 외적인 것을 담으려고 하진 않았는데 취미가 내 발전에 많은 도움이 됐기에 담아보자고 생각했다. 벌크업을 목표로 원..

가상 메모리 관리 기법현대 컴퓨터 시스템이 여러 프로그램(프로세스)을 동시에 매끄럽게 실행할 수 있는 비결은 무엇일까? 그 중심에는 한정된 물리 메모리(RAM)를 수많은 프로세스들이 나눠 쓸 수 있도록 하는 메모리 관리 기술이 있다. 그중에서도 페이징(Paging)은 가장 핵심적인 가상 메모리 관리 기법으로, 메모리 공간을 낭비하는 외부 단편화 문제를 근본적으로 해결하고, 각 프로세스가 마치 자신만의 거대한 메모리를 독차지한 것처럼 느끼게 해주는 안정적인 환경을 제공한다.페이징의 기본 원리: 페이지와 프레임페이징의 핵심 아이디어는 물리 메모리를 조각내어 프로세스에 비연속적으로 할당하는 것이다. 마치 책의 내용을 여러 페이지에 나누어 담고, 이 페이지들을 책장 여기저기에 꽂아두지만 목차를 통해 순서대로 찾..