일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- backend
- docker
- 개발
- redis
- aws
- react
- git-hooks
- yarn-berry
- 백엔드
- 캐시
- 리액트
- 배포자동화
- 롱 폴링
- styled-components
- 스타일 컴포넌트
- 예제
- 배포
- 소켓IO
- deployment
- 쿠버네티스
- 디렉토리이동
- 인프라
- Infra
- methodreference
- Atomic Design
- Kubernetes
- 자동화
- GHCR
- Atomic Design 패턴으로 페이지 만들기
- 도커
- Today
- Total
목록백엔드 (6)
SLASH 기술 블로그
1. How to containerize your app - 앱을 컨테이너화하는 방법에 대해 알아보자. 2. Running on Kubernetes Cluster - 쿠버네티스 클러스터에서 이미지 실행하기 3. Exposing the service - 서비스를 외부에 공개하기 4. Simplifying deployment process - 배포 과정 단순화하기 이전 글에서 포트포워드와 NodePort 서비스를 통해 서비스를 외부에서 접근할 수 있도록 설정하는 방법을 알아봤다. 그러나 실제로 서비스를 할 때는 여러 서버가 있을 때 파드 간의 부하를 분산하거나 한 파드에 장애가 발생한 경우 이를 감지해서 다른 파드로 라우팅시키는 로드 밸런싱이 필요하기도 하고, 하나의 도메인에서 path에 따라 서로 다른 서..
요즘 백엔드 개발을 한다면 피해갈 수 없는 주제가 바로 도커와 쿠버네티스일 것이다. 보통 어떤 기술에는 장점과 단점이 혼재하기 마련인데, 도커와 쿠버네티스가 제공하는 강력한 기능들은 그 단점이 무색해질 정도로 좋아서, 서버 개발의 패러다임을 완전히 바꿔버렸다. 내가 처음 일을 시작한 2017년만 해도, 회사에서 도커에 대해 아시는 분들이 적었고, 쿠버네티스는 당연히 모르는 분위기였는데, 몇 년 사이 도커를 쓰지 않고 배포하는 경우를 찾아보기 힘들 정도로 널리 퍼지고 대중화가 되었다. (물론 내가 일을 시작한 회사가 새로운 기술에 둔감했던 것도 한 몫 했던 것 같다) 이번 글에서는 쿠버네티스가 다루는 컨테이너에 대한 이해를 위해 도커를 간단히 살펴보고, 쿠버네티스의 기본적인 요소들 - Pod, Replic..
AWS EC2에서는 다양한 인스턴스 타입을 제공한다. 가장 기본적인 t로 시작하는 범용 인스턴스부터, R로 시작하는 메모리 최적화 인스턴스, 컴퓨팅에 최적화된 C로 시작하는 인스턴스들까지, 처음 인스턴스를 띄울 때는 이렇게 다양한 타입 중에 어떤 것을 선택해야 하는지도 꽤나 고민이 될 것이다. 처음 서비스를 만들고 인프라를 만지면서 했던 실수 중 하나는 인스턴스의 특성을 제대로 고려하지 않고 vCPU, 메모리만 보고 인스턴스를 골랐던 것. 같은 스펙을 가지고 있더라도, 인스턴스의 특성에 따라서 특화된 기능이나 비용은 천차만별이다. 오늘은 다양한 인스턴스 타입을 파헤쳐보고, 상황에 따라 어떤 인스턴스를 선택하는 게 좋을지 알아보도록 하자. 뭘 해야할지 모르겠을 때는? 범용 인스턴스 처음 인스턴스를 만들 때..
이전 글에서는 Redis의 키 관리나 자료 구조의 선택을 어떻게 할 것인지에 대해 간단한 생각을 이야기했다. 오늘은 실제로 BSER.FUN 사이트를 구현하면서, 유저가 전적 갱신을 요청했을 때 이를 처리하기 위해 Redis를 적극적으로 활용했던 경험이 있어, 이를 공유하고자 한다. Redis가 캐시로 많이 쓰이기는 하지만, 꼭 캐시로만 써야하는 것도 아니다. 그동안 캐시로만 Redis를 사용했던 분들이라면 Redis를 활용하는 새로운 방법에 대한 힌트를 얻어갈 수 있지 않을까 싶다. 데이터 갱신을 위한 Queue - List 활용 게임 전적 사이트에서는 유저마다 전적을 보여주고 동시에 다양한 통계를 보여주기 위해서 유저가 플레이한 게임 데이터를 갱신하는 로직이 반드시 필요하다. 어떤 방식을 취하든, 기본..
동일한 입력에 대해 동일한 출력을 뱉는 API라면 매 번 요청이 들어올 때마다 연산을 할 필요가 없다. 이처럼 적절한 곳에 적절한 형태의 캐싱을 사용하면, 연산량이 많은 작업이나 DB Hit을 줄일 수 있어 서버 부하를 덜고 API의 반응 속도를 올릴 수 있다. 현재 서비스하고 있는 BSER.FUN 사이트에서도 캐싱을 사용했는데, 얼마 전까지는 Redis가 아닌 단순 로컬 캐시로만 처리를 했다. (서버 로컬 메모리) 당시 Redis의 존재 자체는 알았지만, 막연하게 느껴지는 심리적인 장벽과 기능 개발에 집중해야하는 스탠스로 인해서 쉽사리 적용해볼 생각을 못했는데, 이후 Redis를 도입하게 되면서 캐싱뿐만 아니라 앱 전반에서 다양한 이득을 보아 그 사례를 공유하고자 한다. 한 편, 여러 개의 노드가 동일..