저번에 인프라를 주제로 한 인프런 퇴근길 밋업 포스팅을 올렸었는데이번에는 "테스트코드"라는 너무 좋은 주제로 진행된다는 소식을 듣고 바로 신청을 했습니다 ㅎㅎ총 60명을 추첨하여 밋업을 진행하는데 신청 당시만 해도 300명이 넘는 분들이 신청을 하셨어서이번에는 좀 어려울 수도 있겠다... 싶었는데 운이 좋게도 60명 내에 선정됐다는 문자를 받았습니다!( 최종 신청 인원은 480명이었다고 합니다...ㄷㄷ ) 저는 평소 테스트코드의 중요성은 알고 있었지만 테스트코드를 작성 문화를 가진 팀에서 일한 경험이 없었고항상 어느 범위까지 테스트코드를 짜야하고 의미있는 테스트를 하려면 어떻게 해야 하는지에 대한 갈증이 있었습니다.이런 갈증들을 해소하고자 밋업에 신청하게 되었고 많은 인사이트를 얻어와서 이번에도 후기를 ..
UUID는 중복을 방지하고 예측할 수 없는 값이기 때문에 Primary Key의 값으로 좋은 선택지입니다.하지만 UUID로 인해 성능 이슈가 발생할 수 있는 여지가 있고 이를 개발자 수준에서 고려하고 적절히 대처해야 합니다.이번 포스팅에서는 PostgreSQL 기준으로 UUID 사용 시 발생할 수 있는 성능 이슈에 대해 정리하려 합니다. UUID 저장 시 UUID 전용 데이터 타입에 저장하기흔히 UUID를 저장하기 위한 데이터 타입으로 Text 타입 혹은 String 타입을 사용합니다.uuid는 128 비트 길이의 값을 생성하기 때문에 메모리 상에서 16바이트의 공간을 차지합니다.( 1byte = 8bit, 128bit / 8bit = 16byte ) 이런 uuid 값의 길이는 항상 고정적이기 때문에 P..
평소 주변 동료분들 중에 Go 언어를 좋아하시는 Gopher 분들이 계셔서 Go 언어에 대한 장점들을 익히 들어왔는데최근 관심이 생긴 회사에서 Go를 사용하고 있어 이번에 Go 언어는 무엇인지에 대해 알아보고자 합니다.( 온전히 기술적인 측면에서 Go를 탐구하고 배경이나 역사 같은 건 넘어가도록 하겠습니다 ) 1. Go는 무엇이 좋은가?1-1. 단순성(Simple)Go는 문법이 간결하고 명확하여 러닝커브가 낮습니다.Go의 예약어는 25개로 Python이 36개, Java가 53개의 예약어가 있는 것을 고려하면 굉장히 적은 것을 알 수 있습니다.이처럼 Go는 불필요한 복잡성을 최대한 제거하고 코드 가독성을 높이도록 위해 설계되었습니다. 1-2. 병행성(Concurrency)Go는 고루틴(goroutine)..
PostgreSQL은 동시성 이슈를 해결하고 데이터 무결성을 보장하기 위해 다양한 Lock을 제공합니다.( 동시성 이슈가 무엇인지 모르겠다면 해당 포스팅을 참고해 주세요. )이번 포스팅은 PostgreSQL이 제공하는 강력한 기능 중 하나인 Lock에 대해 기술해보려 합니다. 1. Lock 이란?Lock은 특정 리소스에 대한 접근을 제한하는 메커니즘입니다.PostgreSQL은 트랜잭션의 동시성을 제어하고 데이터 손상을 방지하기 위해 여러 수준의 잠금을 제공합니다. 2. PostgreSQL Lock의 종류2-1. 테이블 수준 Lock테이블 수준 Lock은 테이블 전체에 다른 트랜잭션이 접근하지 못하도록 Lock을 거는 작업입니다.해당 Lock이 걸려있다면 해제되기 전까지 권한이 충돌하는 다른 Lock은 해..
동시성 이슈는 여러 스레드나 프로세스가 동시에 동일한 데이터에 접근하거나 수정하려고 할 때 발생하는 문제입니다. 이러한 문제는 데이터 일관성을 해치고, 예상치 못한 결과를 초래할 수 있습니다. 동시성 이슈에 대한 이해를 돕기 위해 아래 사진처럼 5명이 버튼을 동시에 누르려하는 예제를 들어보겠습니다.버튼을 누르면 Value 값이 1씩 오른다고 했을 때 Value 값은 무엇이 될까요? 우리는 당연히 5라고 생각합니다.하지만 컴퓨터 세계에서의 답은 알 수 없다 입니다.이유가 무엇일까요?? Value 값이 오르는 과정을 살펴보면 그 이유를 알 수 있습니다.Value 값에 1을 더하기 위해서는 아래 2가지 작업이 필요합니다 1. 현재 Value 값을 가져온다.2. 가져온 Value 값에 1을 더한다. 문제는 여기..
저는 평소 1인 개발을 통해 수익화를 경험해보고 싶은 목표가 있었고 이번에 그 첫걸음을 내디뎠습니다.개발과 앱 검수 기간을 포함해 이번 3월 한 달 동안 프로젝트를 진행해 앱 하나를 만들어 출시하게 되었습니다. 앱 이름은 캠퍼스클럽으로 언제 어디서든 학교 학생이라면 자신의 학교에 모든 동아리를 살펴볼 수 있고만약 동아리 관리자라면 캠퍼스클럽에서 모집공고를 게시하고 지원자들을 관리할 수 있는 기능을 가진 애플리케이션입니다.캠퍼스 클럽을 만들게 된 계기 대학교 커뮤니티 사이트인 에브리타임을 둘러보던 도중 동아리 존재 유무에 대한 질문과 현재 모집하는 동아리가 있는지에 대한 질문들이 자주 올라오는 것을 발견하였습니다.이런 글이 올라오는 이유를 파악해 보니 대학교 동아리들은 모집 기간에만 모집 공고를 올리기 때..
문제 상황 및 원인저번 포스팅에서 VM에 들어오는 해킹 시도를 방어하는 포스팅을 올렸었는데이런저런 작업을 하다가 오늘 또 CPU 100%를 찍는 이슈를 마주쳤습니다.이제 해킹 시도로 인한 무작위 요청을 막아서 API에서 발생하는 이슈는 아닌 것 같았고무엇이 문제일까 분석하다 해결 방법을 기록하고 공유할 겸 포스팅을 작성하게 되었습니다. 일단 CPU가 100%를 찍게 된 원인부터 분석해 보면EC2 인스턴스를 종료 및 재시작하여 ssh에 접근하고 NGINX 액세스 로그부터 살펴봤습니다.하지만 역시 API 로그는 깔끔했고 이건 메모리 문제일 가능성이 크다고 판단해 메모리를 파보기 시작했습니다. 저는 free tier를 사용 중이었기에 ec2 스펙이 t2.micro로 Memory 1GB 정도의 작은 서버였고to..
해킹 시도를 받다 프로젝트를 완성하고 VM 하나를 빌려 내 API 서버를 배포하였습니다. 근데 어느 날인가부터 아래 사진과 같이 누가 봐도 이상한 API 요청이 들어오기 시작했습니다. 아직 데이터도 많지 않은 서버라 안일하게 특별한 보안 장치를 두지 않아 이런 일이 발생했고 일단 개발이 급했기에 그냥 놔뒀는데 어느날 vm에 ssh 연결이 안 되는 이슈가 있었습니다. 정확히는 ssh 접근 시도를 하면 아무런 에러도 뜨지 않은채 계속 연결 시도 대기 상태에 멈춰있었습니다 뭔가 느낌이 쌔해서 aws 콘솔에 가서 네트워크 모니터링 로그를 보니 CPU 100%가 되어 있네요.. ㅎㅎ 무작위 요청을 하던 그놈 짓이구나 라는 걸 바로 알 수 있었고 일단 vm은 접속해야 하니 vm을 중단 후 재시작하여 연결하였습니다...
