logo
logo
데이터베이스
PostgreSQL
StackOverflow 질문 수: 179916
Github Stars : ★ 17197
사용 기업
직장
교육
패션
이커머스
소셜/컨텐츠
모빌리티
금융/보험
부동산/인테리어
여행
푸드테크
종합
헬스케어
기타
인공지능
블록체인
techstack-logo
토스랩
techstack-logo
뤼이드
techstack-logo
딜리셔스
techstack-logo
숨고
techstack-logo
스푼
techstack-logo
바로고
techstack-logo
디셈버앤컴퍼니
techstack-logo
직방
techstack-logo
마이리얼트립
techstack-logo
와디즈
techstack-logo
마켓컬리
techstack-logo
쏘카
techstack-logo
매스프레소
techstack-logo
채널코퍼레이션
techstack-logo
카카오페이
techstack-logo
차이코퍼레이션
techstack-logo
42dot
techstack-logo
카카오엔터테인먼트
더 보기
기술 블로그 글
스푼
Serverless Postgres Neon으로 Next.js 환경에서 Short-URL 구현하기
Photo by Steve Johnson on Unsplash안녕하세요. 스푼랩스 비글루 Client Team에서 프론트엔드 개발을 담당하고 있는 Drew(이서용)입니다. 비글루는 글로벌 숏폼 드라마 서비스로 다양한 콘텐츠를 쉽고 빠르게 즐길 수 있도록 iOS / Android 앱과 웹사이트에서 스트리밍 서비스를 제공하고 있습니다. 이번 글에서는 더 많은 사람들이 손쉽게 비글루 콘텐츠에 접근할 수 있도록 프론트엔드에서 서버리스 DB Neon을 이용해 간단한 커스텀 Short-URL을 구현하는 과정에 대해 다루었습니다.Short-URL 도입 계기기존 비글루 웹 서비스 콘텐츠 페이지 URL은 다음처럼 불필요하게 많은 정보를 노출하는 구조로 되어있어 가독성 및 보안 측면에서 적절하지 않았습니다.// 콘텐츠 URLex) www.video.com/ko/content/10001?season=10001&episode=1이에 비해 타 서비스 웹 URL의 경우 UUID 형태로 정보를 숨기거나 마케팅 용도로 읽을 수 있도록 만드는 등, 유연하게 여러 가지 형태의 URL을 사용하고 있었습니다.// UUID 형태의 타 서비스 콘텐츠 URLex) www.video.com/content/1523cb9c-f1ad-41f1-81bc-2be08c92d381// Semantic한 형태의 타 서비스 콘텐츠 URLex) www.play.com/ko/ep/41000110515_escape-with-boss-baby이를 보완하기 위해서는 실제 정보를 가진 원본 URL과 외부에 노출되는 URL의 구분이 필요하다는 사실을 알게 되었고, 자체적인 커스텀 Short-URL 도입을 검토하게 되었습니다.// 짧아진 Short-URLex) www.video.com/content/1fja491일반적으로 Short-URL은 다음 과정을 통해 구현됩니다.1. URL 단축먼저 원본 URL을 대체할 단축된 Short-URL을 생성합니다. Short-URL은 서로 충돌이 발생하지 않도록 crypto나 nanoid와 같은 난수 생성 패키지를 이용해 생성합니다. 생성된 URL은 이후 조회를 위해 서버 저장이 필요합니다.2. URL 조회이제 단축된 URL을 조회하여 실제 URL을 찾을 수 있도록 서버 요청을 구현합니다. 실제 URL로 단순히 Redirect 시킬 수도 있지만, Short-URL을 유지하면서 원본 URL 정보만 가져오고 싶다면 이를 API 요청을 통해 조회하도록 설정할 수도 있습니다.3. 추적 및 통계추가로 Short-URL 변환 시점에 클릭 수 등의 데이터를 수집하도록 설정할 수도 있습니다. 이는 기존 이벤트 트래킹 툴과 연동하면 보조적인 데이터로 활용이 가능합니다.이제 구체적인 구현 방법에 대해 살펴보겠습니다.Vercel Storage와 Neon가장 먼저 찾아보았던 것은 Short-URL을 저장하고 불러올 수 있는 DB 서버에 대한 구현 방법이었습니다. 현재 비글루 웹 서비스는 서버사이드 렌더링을 지원하는 React 프레임워크 Next.js를 이용해 개발되었고, Vercel을 통해 배포
nextjs
postgresql
카카오페이
AWS re:Invent 2024 Recap: Database, Storage
greg.ss 클라우드에 관심 있지만 시간이 없어 AWS re:Invent 2024를 살펴보지 못하셨나요? 그렇다면 직접 미국까지 다녀온 제이코와 아리가 보고 듣고 정리한 이 글을 추천드려요!shine.by 클라우드 컴퓨팅에 관심 있는 누구나 놓칠 수 없는 AWS re:Invent 2024의 최신 기술들을 쉽고 명확하게 접할 수 있는 글입니다. 앞으로의 개발 방향성에 대한 영감을 얻고 싶다면, 이 글을 통해 최신 기술 트렌드를 확인해 보세요!안녕하세요. 카카오페이 크레딧클랜에서 대출 플랫폼을 개발하는 제이코, 마케팅테크팀에서 프로모션 플랫폼을 개발하는 아리입니다. 저희는 카카오페이 기술 직군을 대표하여, 2024년 12월 2일부터 6일까지 미국 라스베이거스에서 열린 AWS re:Invent 2024에 다녀왔습니다.이번 행사에서는 생성형 AI 서비스인 Amazon Q, 맞춤형 AI 모델 구축을 지원하는 Amazon Bedrock, 분산형 데이터베이스인 Amazon Aurora DSQL, 대규모 데이터 분석을 위한 Amazon S3 Tables 등 다양한 기술이 소개되었습니다. 이 중에서, 제이코는 Amazon Aurora DSQL을 다룹니다. Amazon Aurora DSQL은 Multi-Region 및 Active-Active 기능을 지원하며 무제한 확장성과 높은 가용성을 제공하는 서버리스 분산형 SQL 데이터베이스입니다. 아리는 Amazon S3 Tables를 다룹니다. Amazon S3 Tables는 테이블 버킷을 이용한 새로운 데이터 관리 솔루션으로, 표 형식 데이터에 최적화된 Apache Iceberg 기반의 완전 관리형 테이블 형식 스토리지를 제공합니다.AWS re:Invent는 매년 클라우드 기술의 최신 트렌드를 한눈에 살펴볼 수 있는 중요한 행사입니다. 이번 글에서는 특히 Amazon Aurora DSQL과 Amaon S3 Tables와 같은 혁신적인 데이터베이스 기술을 다루는 만큼, 데이터베이스 관리와 데이터 분석에 관심 있는 분들에게 유익한 정보가 되길 바랍니다. 먼저, Amazon Aurora DSQL에 대해 살펴보겠습니다.안녕하세요, 카카오페이 크레딧클랜의 제이코입니다. 이번 AWS re:Invent 2024에서는 Amazon Aurora DSQL이 새롭게 소개되었습니다. Amazon Aurora DSQL은 사실상 무제한의 확장성과 높은 가용성을 제공하며 인프라 관리가 필요 없는 서버리스 분산 SQL 데이터베이스입니다. 이제부터, Amazon Aurora DSQL이 등장한 배경과 핵심 특징, 구성 요소 및 활용 방법에 대해 자세히 살펴보겠습니다.Amazon Aurora DSQL의 주요 특징을 살펴보기 전에, 먼저 이 기술이 등장하게 된 배경부터 살펴보겠습니다.AWS는 2014년에 Amazon Aurora를 출시했습니다. Amazon Aurora는 MySQL 및 PostgreSQL과 완벽하게 호환되면서 MySQL보다 5배, PostgreSQL보다 3배 높은 처리량을 제공합니다. 또한, 기존 상용 데이터베이스 대비 1/1
awsauroradb
nodejs
postgresql
여기어때컴퍼니
[DevOps] GitLab 버전 업그레이드는 계속 된다.
안녕하세요. 여기어때컴퍼니 DevOps팀 루카스입니다. 저희 팀은 여기어때컴퍼니 Tech 조직내 개발자들의 업무 몰입을 위한 개발 환경과 체계를 만들어가는 조직으로 조직별로 상이한 개발 환경을 통합하고 운영하고 있습니다.Photo by Pankaj Patel on Unsplash이번에 다룰 주제는 팀에 합류하고 나서 첫 번째 작업이었던 GitLab 버전 업그레이드 과정입니다. GitLab은 소프트웨어 개발자에게 강력한 기능을 제공하는 형상 관리 플랫폼입니다. 하지만 최신 기능을 활용하고 보안 업데이트를 적용하기 위해서는 정기적으로 업그레이드를 해야 합니다. 우리 조직내 개발자들이 더욱 안전한 환경에서 신규 기능을 활용 할 수 있도록 저희팀은 GitLab을 업그레이드 하기로 결정하였습니다.1. 사전 준비1–1. Upgrade Path 확인GitLab의 현재 설치된 버전과 호환성을 확인합니다. 이런 경우에는 GitLab의 공식 문서에서 지원되는 업그레이드 경로를 확인하는 것이 좋습니다. https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/ 이 URL에서 현재 사용 버전, OS, 업그레이드 대상 버전 등을 선택하면 어떤 버전의 순서로 업그레이드를 해야하는지 알려 줍니다. 버전 변경에 대한 큰 변동사항에 대해서도 미리 경고해 줍니다.여기어때에서는 GitLab 15.1.6을 사용하고 있었으며, 16.9.4 버전으로 업그레이드를 진행하였습니다.15.1.6에서 16.9.4로 Upgrade Path는 다음과 같습니다.15.1.6 → 15.4.6 → 15.11.13 → 16.1.6 → 16.3.7 → 16.7.7 → 16.9.1Upgrade Path의 경고 마지막 부분에 Expiring Access Token 부분이 있었습니다. Gitlab PAT 관련 문서를 통해 추가로 확인해 보았습니다. https://docs.gitlab.com/ee/user/profile/personal_access_tokens.htmlNever Expire로 발급된 Personal Access Token은 모두 GitLab 16.0으로 업그레이드한 날짜로부터 1년 후에 만료 되도록 강제로 변경 됩니다. CI/CD Pipeline 자동화를 위해서 사용되는 토큰인 경우, 만료시 장애를 일으킬 수 있는 원인이 되기 때문에 사전 작업을 진행합니다.1) 기존 버전의 Personal Access Token의 만료일이 Never인 Token을 리스트업합니다.$ curl -s --header "PRIVATE-TOKEN: ${your_access_token}" "https://${gitlab url}/api/v4/personal_access_tokens" | jq '.[] | {id, expires_at}'결과 샘플은 다음과 같습니다.{ "id": 154, "name": "GITLAB-PAT", "expires_at": "2025-06-25"}your_access_token 은 admin 권한을 갖는 계정의 Personal Access
docker
gitlab
postgresql
redis
현대자동차그룹
PostgreSQL을 Kubernetes에서 운영하기
저희 팀에서는 메타데이터성의 경량의 PostgreSQL을 쿠버네티스 클러스터 위에 배포하여 운영하고 있습니다. 기존의 VM과 같은 고정된 인프라 위에서 RDB를 운영하는 전통적인 방식과 달리 컨테이너 형태로 데이터베이스를 운영하는 방식에는 장단점이 있습니다. 이번 포스팅에서는 제가 PostgreSQL을 쿠버네티스로 배포 및 운영하면서 겪은 해당 방식의 장단점에 대해서 말씀드리려고 합니다.DB를 Kubernetes Pod로 관리하게된 계기저희 팀에서 데이터베이스를 구축해야하기 전에 충족해야하는 요구조건이 몇가지 있었습니다. 설치 및 배포가 용이하고 검증되어있어야 했으며, 구축할 데이터베이스의 스키마가 복잡하지는 않으나 HA를 충족시켜야 했습니다. 또한 메타데이터성의 데이터였기 때문에 읽고 쓰는 양 자체가 많지 않지만 차후 확장성을 고려하여 스케일링 방식이 유연해야 했습니다.  이러한 요구사항을 기반으로 컨테이너 방식으로 데이터베이스를 구축하자는 의견이 나왔습니다. 저희 팀 구성원들은 VM 인프라에서만 데이터베이스 운영 경험이 있었기 때문에 처음에는 걱정이 된것도 사실이었지만 결국은 매우 효율적으로 PostgreSQL을 운영할 수 있었습니다.컨테이너 형태의 PostgreSQL운영의 장단점결론부터 말씀드리면 상황에 따라서 장단점이 다르게 적용되는 것 같습니다. 제가 운영을 하면서 느꼈던 장점과 단점을 아래 표에 정리해보았습니다.장점단점설치 및 버전 업그레이드가 쉽다직접적인 운영이 어렵다초기 구축이 쉽다client 접속이 번거롭다환경 설정이 쉽다트러블슈팅이 어렵다구축과 업그레이드가 손쉽게 된다는 것은 컨테이너화된 데이터베이스의 가장 큰 장점이라고 할 수 있을 것 같습니다. 제한된 시간 안에 고가용성 postgres를 구축해야 한다면 쿠버네티스 위에서 운영하는 것이 더 적절할 것입니다. 반면에 컨테이너화 되어 있다보니 접속하는 CLI가 사용자 친화적이지 않고 환경 설정에 대한 볼륨도 직접적으로 하기 번거로워서 세부적인 운영에 어려움이 있었습니다. 실제로 VM 보다 장애가 발생했을 때 트러블슈팅 하는데에 시간과 노력이 더 많이 필요했던 것 같습니다. 또한 호스트 운영체제를 공유하는 컨테이너 기반의 데이터베이스 형식이다보니 VM에 직접 서비스를 운영할 때보다 성능적인 측면에서 이슈가 있을 수 있을 것 같습니다. 따라서 저희 팀의 요구조건처럼 데이터 쓰기 양이 많지 않고 비용과 자원이 제약되어 있는 상황에서는 컨테이너 방식의 데이터베이스 운영이 장점일 수 있으나 대규모 서비스를 운영 한다거나 성능에 중요한 이슈가 있는 환경에서는 적절하지 않을 수 있을 것 같습니다.설치 과정저희가 선택한 방식은 bitnami에서 제공한 postgres-ha helm 차트를 이용한 배포 방식이었습니다. bitnami helm 차트는 공식 차트에 비해 좀 더 사용자 친화적이고 간편한 설치 방법을 제공합니다. 설정 또한 유연하게 조정할 수 있어서 원하는 요구사항에 맞춘 배포가 가능하다는 장점이 있습니다. postgres-ha는 postgresql 클러스터에서 replicat
helm
kubernetes
postgresql
연관 기술 스택
techstack-logo
AWS AuroraDB
techstack-logo
AWS MariaDB
techstack-logo
MySQL
Copyright © 2025. Codenary All Rights Reserved.