웹 서비스에서 흔히 발생하는 일이 있습니다. 하나의 API 결과 뿐만 아니라 n개의 API 결과를 받아보고 싶습니다. 흔히 우리가 SPA를 가지고 웹 애플리케이션을 만들다보면 여러 API를 호출하는 일이 있는데, 이와 비슷한 이야기입니다. Reactive Programming이 나오기 이전, 우리가 생각하는 대규모 애플리케이션은 그냥 수십대 서버를 가지고 GB 정도의 데이터, 몇 초 걸리는 응답 시간, 유지보수는 몇 시간 걸리는 정도가 당연하다. 라고 보고 운영을 해왔습니다. 하지만 지금은 어떨까요? 다양한 서비스가 있고, 특히 한국에서는 인터넷 속도가 굉장히 빠르기 때문에 페이지 로딩 시간이 수 초라도 걸리면 그냥 닫아버리는 게 관습이 되어버렸죠. 이렇게 변화가 된 이유는 무엇일까요? 늘어난 데이터 시..
이벤트 소싱을 처음 접하게 된 것은 2017 SpringCamp에서였습니다. 당시에는 MSA라는 개념에 대해 잘 알지도 못했고, MSA는 대기업에서나 쓸 수 있고, 적용가능한 엄청나게 큰 아키텍처였다. 라고만 인식하고 무작정 배웠을 때였습니다. 그런데, 최근 제가 다니고 있는 회사에서 이벤트 소싱과 CQRS라는 주제로 이야기를 했었는데요. 다시금 CQRS를 보려고 하니, 그 개념이 잘 기억나지 않고, 어떤 특징을 가지고 있었는지를 파악하기가 어려워서 이렇게 정리하게 되었습니다. 그럼 MSA의 트랜잭션 이야기 3번째 이벤트 소싱과 CQRS 시작하도록 하겠습니다. 전통적인 CRUD 가끔은 이런 생각이 들 때가 있습니다. 전통적인 CRUD를 사용함으로써 백엔드 엔지니어가 데이터베이스를 사용할 때 트랜잭션 로직..
지난 포스트에서 Kubernetes와 Container Deployment에 대해 알아보며 컨테이너로 서비스 배포하기까지의 과정과 Docker Swarm 등의 다른 오케스트레이션 툴과 어떤 점이 다른지 살펴봤습니다. 이러한 점을 확인하고, 우리가 운영하는 서비스가 쿠버네티스에 적합한지, 차후 미래 운영 대책으로 사용할만한지를 정확하게 고려 대상으로 선정하셨다면 이 글을 계속 읽으며 Kubernetes를 직접 공부해보고, 사용해보시는 것이 좋을 것 같네요. Kubernetes의 기본 구조 이제 본격적으로 Kubernetes가 어떻게 이루어졌는지 알아보겠습니다. 기존의 Docker에서는 컨테이너를 관리할 때 중앙의 Docker Engine이 자리잡고 있어, 이 엔진이 애플리케이션 이미지를 관리하고, 생성하는..
저에게 있어 쿠버네티스는 Docker Swarm을 지나 이전부터 사용하고 있었던 컨테이너 오케스트레이션 툴이었습니다. 최근에 이직을 한 회사에서 쿠버네티스를 이용하여 시스템을 구성하고 서비스를 운영하게 되어 주 오케스트레이션 툴로 쿠버네티스를 사용하게 되었고, 이 때부터 Docker Swarm 보다는 Kubernetes로 시스템을 구성하는 일이 자주 생겨났습니다. 이 글은 Docker를 자주 사용하지만 Kubernetes에 대해서는 잘 모르고, 그리고 사용을 고려해보고 싶은 분들에게 드리는 글의 시작입니다. Container Deployment으로 거슬러 올라오기까지.. Kubernetes는 Go 언어를 기반으로 Google에서 개발하여 2014년에 공개된 Container Orchestration to..
이전 글에 이어서 MSA 내에서 트랜잭션을 원활히 하는 방법 2가지를 소개해드리고자 합니다. 관계형 데이터베이스와 더불어 모놀리틱 아키텍처를 도입한 서버 애플리케이션은 DB 서버에서 제공하는 Commit과 Rollback을 이용하여 데이터를 일관성 있게 제어할 수 있었습니다. 그러나 MSA에서는 각 서비스별로 DB 인스턴스와 애플리케이션이 분리됨에 따라 관계형으로 맺어진 Entity들은 서로가 다른 인스턴스로 운영되고, 그들 리소스를 받기 때문에 데이터의 일관성이 무너지게 됩니다. 이를 위해 우리는 분산 트랜잭션 기술을 이용하여 이들 일관성을 지킬 수 있는 방법이 있습니다. 1. Two-Phase Commit Two-Phase Commit이란, 2단계에 거쳐서 영속하는 작업을 말합니다. 이렇게 말하면 아..
MSA에 대해서 우리는 각 API 서버를 분리하여 용도별로 인스턴스를 나누고, 앞단에서 Gateway를 사용해 클라이언트가 원하는 서비스를 주고, 로드 밸런싱 등의 작업이 들어갈 경우, Service Discovery를 통하여 원하는 서비스를 동적으로 찾아주는 방법까지 알았습니다. 그런데, 이렇게 서비스를 분리함으로써 한 인스턴스가 모든 서비스를 감당하는 부분이 완화되는 등의 장점이 생겼지만, 만약 서비스에 장애가 발생한다면 그 장애는 어떻게 처리할 수 있을까요? 서비스가 분리되어 있는 상태에서 클라이언트의 잘못된 입력 값 등으로 생기는 오류는 논리적인 오류입니다. 따라서 이런 오류는 Exception 등의 처리를 통해서 클라이언트에게 오류를 알려주고, 이를 처리하는 방식으로 진행할 수 있습니다. 하지만..
안녕하세요. 다들 구정 연휴 잘 보내고 계신가요? 구정 언휴긴 하지만, 저에게는 길게 느껴지는 연휴인지라, 오늘도 이렇게 끄적여 봅니다. 오늘은 Service Discovery에 대한 이야기를 다뤄보도록 할게요. 서비스 디스커버리는 지난 API Gateway에서도 잠시 다뤘던 내용이지만 서비스가 분리되어 있는 MSA에서 각 서비스가 다음에 불러야할 서비스가 어디에 있는지를 찾아주는 검색 기능입니다. What is Service Discovery ? 쉬운 설명을 위해 Wi-Fi를 예로 들어보겠습니다. 우리는 스마트폰이나 태블릿 PC, 노트북에서 인터넷을 사용하기 위해 Wi-Fi에 연결해야 합니다. 원래라면, 직접 SSID를 입력해야만 하죠. 하지만 AP 검색 기능을 제공하기 때문에 우리는 이렇게 디바이스에..
안녕하세요. 이번 글은 MSA에 대한 글을 이어서 API Gateway에 대한 이야기를 하고자 합니다. 지난 MSA 글에서는 MSA를 왜 써야하는지, 어떨 때 필요하고, 무슨 장단점이 있는지를 간략하게 설명해보는 아주 쉬운 이야기를 다뤄봤습니다. 사실 MSA의 깊이는 그것보다 깊기 때문에 제대로 이야기를 하고자 한다면, 많은 이야기가 될 것 같아 짧게 필요한 부분을 설명드린 것이구요. 타 글에서 좀 더 심층적으로 다뤄볼까 합니다. Spring Cloud를 사용해서 간단히 API를 구성하는 방법도 알았고, 이와 비슷하게 Python의 Django, Flask 등 타 언어, 타 프레임워크에서도 어떻게 구성할 수 있는지 감이 잡혔을 것이라 생각합니다. 오늘은 이들 API를 그룹화 시켜주는 API Gateway..
지난 포스트에서는 Configuration Server를 설정하는 두 가지 방법을 알아봤습니다. 첫 번째 방법은 로컬의 저장되어 있는 설정 파일을 가져오는 방법이었고, 두 번쨰 방법은 Github 등의 레포지터리에 있는 파일을 가져오는 방법이었습니다. 우리는 이러한 서버가 제대로 구축되어 있는지 확인하기 위해서 REST API를 직접 호출하여 해당 값을 반환하는 방법으로 테스트를 했었는데요. 하지만 이러한 결과를 보고, 어떻게 API 서버가 이러한 값을 받는지에 대해서는 아마 궁금해 하셨을 것이라 생각합니다. 그래서 이번 포스트에서는 직접 비즈니스 로직을 만들고, 해당 서버에 맞는 설정값을 만들어, 가져오는 방법을 알아보도록 하겠습니다. 먼저 API 서버를 만들어보도록 하죠. 새로운 Spring Boot..
안녕하세요. 지난 시간에는 Spring Cloud의 Configuration Server를 로컬 환경의 설정 파일을 통하서 구성하는 방법에 대해 알아봤습니다. 로컬 내에 있는 설정 파일을 직접 작성하여 이를 Pull 방식으로 이용할 수 있도록 별도의 구성 서버를 작성하는 것은 매우 효율적으로 서버의 구성 설정을 변경하고 새로이 작성하는 데 용이합니다. 그런데, 여기에 Git을 추가한다면 어떨까요? 기존의 설정에서 새로운 설정으로 변경한 뒤, 어떠한 문제점이 생겼다거나 이슈가 발생된다면 롤백을 하여야 합니다. 하지만 파일 시스템에서 롤백을 할 수 있는 것은 Volume Shadow Copy 정도나 혹은 RAID 레벨에서 제공하는 Snapshot, BRTFS에서 제공하는 Snapshot일 것입니다. 하지만 ..
안녕하세요. 오늘은 Micro Service Architecture에 대해 이야기 해보고자 합니다. 한동안 MSA가 굉장히 화두였는데, 요즘은 분위기가 식어지는 듯하여 오늘 블로그에 이 글을 적게 되었습니다. 우리는 백엔드 개발을 위해서 Spring, Django 등 다양한 프레임워크를 사용하여 개발을 하게 됩니다. 보통 이들 프레임워크를 이용해서 특정 기능을 수행하는 API를 설계하고 개발하여 서비스하는 것이 기본 형태이죠. 이렇게 UI, 비즈니스 로직, 데이터 레이어까지 모든 것을 한 통 속에서 운영하는 방식을 모놀리틱 아키텍처라고 이야기 합니다. 흔히 학부에서 운영체제 과목을 수강해보신 분들이라면, 모놀리틱 커널이라는 단어를 들어보셨을텐데, 거기에서 나오는 모놀리틱과 동일한 단어입니다. 그런데, 이..
E-mail: contact@neonkid.xyz
Comments
Comments (3)
Comments (2)
Comments
