서론이 글은 Golang 어플리케이션을 Serverless framework 를 이용해 AWS Lambda 에 배포하는 과정을 다룬다.현재 운영중인 사이드 프로젝트(🔗 테크 블로그 모아보기) 는 Go 언어를 기반으로 AWS Lambda(이하 람다)에 배포되어 있다. 처음 람다를 배울 땐 AWS Console 에서 일일이 API Gateway 를 설정하고 Lambda 함수의 코드를 직접 작성한 기억이 나는데, 당시만 해도 간단한 파이썬 함수를 호출하는 정도라 AWS Console 에 코드를 복붙하는 정도로 람다를 맛보기 했다. 하지만 실제로 운영할 애플리케이션 코드는 단순 복사 붙여넣기로 람다에 배포할 수 없었다. 파일 수도 많을 뿐더러 매번 배포할 때 마다 그런 번거로운 일을 할수도 없기 때문이다. ..

서론글또 4년 차면 글을 쓰는 것뿐만 아니라 좋은 글을 찾아 읽는 것도 즐기게 된다. 여러 회사의 테크 블로그를 자주 챙겨 읽는데 매번 업데이트가 되는지, 안되는지 알 수 없으니 직접 페이지를 방문하는 수밖에 없었다. 카카오페이 같은 경우는 감사하게도 새로운 글이 올라올 때마다 링크드인에 노티를 주지만 그렇다고 모든 회사를 팔로우 할 순 없는 노릇이었다.해결해야 할 문제가 얼마나 고통스러운지, 이걸 해결하면 얼마나 많은 사람들이 편안해지는 지에 따라 문제의 중요성을 파악하곤 하는데, 냉정하게 말해서 직접 블로그를 방문하여 새로운 글을 확인하는 게 그리 고통스러운 일은 아니다. 단지 조금 귀찮았을 뿐.. 그래서 나도 아주 약간의 노력만 들여 이 문제를 조금 편하게 만들어보자는 마음에 🔗 테크 블로그 모아..

목차- 서론- 동기식 호출- 비동기 호출 : Goroutine 활용- 비동기 호출 개선 : Channel 활용- 결론  서론여러 테크 기업의 기술 블로그를 읽기 좋아합니다. 다만 매번 여러 블로그 홈페이지를 방문하다 보니 자주 가는 블로그는 따로 모아서 읽고 싶은 생각이 들더라고요. 이를 위해 Go를 활용한 테크 블로그 스크래퍼를 개발하기로 했습니다. 이미 그런 서비스는 많지 않냐고요? 맞습니다. 그래도 한번 직접 해보고 싶었습니다🙃.기업의 블로그들은 다양한 플랫폼을 활용합니다. Medium 부터 자체 블로그를 운영하는 곳까지, 다양한 방식의 기술 블로그를 제공합니다. 각기 다른 형태의 플랫폼을 사용하기 때문에 그에 맞는 스크래핑 방식을 사용해야 합니다. 저는 블로그 플랫폼에 맞는 스크래핑 구현체를 만..

배경Go 애플리케이션을 종료할 때 특정 로직을 수행하고자 했습니다.사용자가 수동으로 (로컬) 서버를 종료하면 syscall.SIGINT 값이 channel 에 할당되면서 goroutine 내부가 실행되어로직 수행 후 애플리케이션이 종료(os.Exit(1)) 됩니다.실제로 로컬에서 서버를 실행하고 ctrl + C 명령어로 서버를 종료하면 goroutine 내부 로직이 잘 실행됐습니다.func (s *Server) StartServer() error { s.setServerInfo() channel := make(chan os.Signal, 1) signal.Notify(channel, syscall.SIGINT) // (1) 단순 종료 시그널 go func() { 도커 컨테이너화 후에도 잘..

SELECT ~ FOR UPDATE  란일반적인 SELECT 구문은 락을 사용하지 않습니다. 락을 획득하지 않아도 데이터를 조회할 수 있죠.하지만 간혹 조회 시점에도 락이 필요한 경우가 있습니다. 예를 들어 정산 시점을 생각해보면, 정산시간 동안은 해당 조회 트랜잭션에서 read 중인 데이터를 다른곳에서 수정하면 안됩니다. 이럴 경우엔 SELECT FOR UPDATE 구문을 사용해 조회 중 수정을 방지할 수 있습니다.쉽게 말해 '내가 데이터를 조회하는 동안은 이 데이터를 수정하지마!' 라고 표현할 수 있고,기술적으로 표현하면 동시성 제어를 위해 특정 Row 에 배타적 LOCK 을 거는 것이라 할 수 있습니다.  실습  server_info 테이블 대상으로 Select for update 쿼리를 실험해보겠..

에러 발생CardSection 컴포넌트로 posts props 를 넘기는 과정에서 발생한 문제.CardSection 역시 동일한 타입의 props 를 선언했지만 아래와 같은 에러가 발생했다.  MainBlog.tsx (부모 컴포넌트)posts 변수를 CardSection 컴포넌트의 props 로 전달한다.해당 변수의 타입은 CardInterface[] 배열이다.export interface CardInterface { name: string; role: string;}const MainBlog = () => { const posts: CardInterface[] = [ {name: 'Post1', role: 'CEO BALENCIAGA'}, {name: 'Post2', role: 'CEO..

개요fiber 프레임워크를 사용하여 웹소켓 채팅 서버를 개발 중 http 에서 websocket 으로 프로토콜을 업그레이드 하는 과정에서 발생한 문제. 에러 발생주석에 달아놓은 것 처럼 websocket handler 내부에서 fiber.Ctx 에 접근하자마자 에러가 발생했다.유효하지 않은 메모리 주소이거나 nil pointer 에러가 발생했다는데, ServeHttp() 메서드 진입시점에서 c 를 로그로 확인했을 땐 정상 값이 출력됐다.즉 websocker 핸들러 내부에서 fiber.Ctx 를 접근하지 못하는 것이 원인이라 생각했다.func (r *Room) ServeHTTP(c *fiber.Ctx) error { if r == nil { return fiber.NewError(fiber.St..

📌 서론 룰렛 게임을 한 번쯤 해본 적이 있을 것이다. 빙글빙글 돌아가는 원판에는 구역별로 상품이 걸려있고 돌아가는 원판이 속도를 잃을 때쯤 멈추는 곳의 당첨 막대가 가리키는 상품을 얻게 된다.이런 룰렛 게임을 코드로 구현하려면 어떻게 해야할까? 필자는 백엔드 개발자이기에 UI를 그리는 것보단 어떤 원리에 의해 상품이 당첨되는지 초점을 두게 됐다. 만약 원판이 여섯 개의 구역으로 나뉘어 있다면 각각 1/6의 당첨확률을 가진다고 생각할 수 있다. 하지만 세상일이 원래 생각대로 되던가요? 좋은 상품은 항상 빗나가고 상대적으로 값어치가 떨어지는 상품만 자주 걸리는 게 차가운 자본주의의 현실이다 like 윤루카스. 프로그램으로 구현된 룰렛 게임은 각 구역의 당첨확률을 세팅할 수 있기에 값어치가 높은 상품보단 ..

서론최근 해커톤을 나가면서 배포 자동화 프로세스를 고민하게 됐다. 필자는 백엔드 개발자이기 때문에 프론트엔드 개발자가 빠르게 서버와 통신할 수 있도록 먼저 EC2 인스턴스를 배포했다. 기존 배포 프로세스는 아래와 같다.1. 로컬에서 스프링부트 도커 이미지를 빌드하여 도커 허브로 push2. EC2 인스턴스에 SSH 접속하여 도커 허브의 이미지 pull3. pull 받은 이미지를 빌드하여 EC2 내부에서 서버 실행- EC2 내부에 shell script 를 작성하여 image pull 과 container run 은 한번에 진행할 수 있다. 위 방법은 3가지 스텝으로 구분 돼 비교적 간단해보이지만, 코드에 변경이 있을 때마다 EC2 내부에서 새로운 도커 이미지를 pull 받는 과정을 반복해야 했다. 매번 ..