<h3>나는 왜 카프카를 공부하는가…</h3>지난 SSAFY 핀테크 특화 프로젝트를 진행하면서 처음으로 MSA를 통해 백엔드를 구축해볼 기회가 있었습니다. 그런데 사용자에게 알림 기능을 제공해야 하는 상황에서, 프론트엔드가 PWA를 사용한 모바일 웹앱 형태였기 때문에 문제가 발생했습니다.기존에는 웹소켓을 사용하여 커스텀 알림 형태를 제공했지만, PWA에서는 푸시 알림이 필요하다고 판단되어 FCM을 통해 푸시 알림 기능을 구현하게 되었습니다.<blockquote>FCM(Firebase Cloud Messaging)은 앱 개발자들이 서버나 클라이언트 애플리케이션에서 사용자의 안드로이드, iOS, 웹 애플리케이션 등으로 직접 메시지를 보낼 수 있게 해주는 구글의 크로스 플랫폼 메시징 솔루션입니다.알림 메시지 또는 데이터 메시지를 사용하여 앱이 활성화되지 않은 상태에서도 사용자에게 중요한 정보를 전달할 수 있습니다. 예를 들어, 새로운 이메일이나 소셜 미디어의 알림과 같은 정보를 실시간으로 사용자에게 알려줄 수 있습니다</blockquote>이 때, 알림용 서버를 별도로 구축했는데, 다른 서비스들에서 새롭게 생성된 알림 정보를 카프카를 통해 메시지를 발신하고, 알림 서버에서는 이 메시지들을 중앙집중적으로 수신하여 FCM을 통한 푸시 알림 전송 요청을 처리하는 형태로 구현하였습니다.해당 프로젝트를 통해 처음으로 Kafka를 학습하고 적용해볼 수 있었는데, 서버 설정부터 실제 기능 적용에 이르기까지, 예상외로 많은 어려움을… 🤣🤣🤣그럼에도 카프카의 활용도와 유용함을 실감하게 되어, 데이터 파이프라인을 구축할 때 Kafka는 필수적인 요소라는 것을 알게 되었고, 이로 인해 본격적으로 Kafka를 공부하기로 결심하게 되었습니다 !<img src="https://image.until.blog/thingk0/article/1718768163378" alt="until-561"><h2>카프카는 왜 생겼는가..</h2><ul class="tight" data-tight="true"><li>링크드인(LinkedIn) → 파편화된 데이터 수집 및 분배 아키텍처를 운영하는데 큰 어려움을 겪음.<ul class="tight" data-tight="true"><li>데이터 생성/적재하기 위해서는 데이터를 생성하는 소스 애플리케이션과 데이터가 적재되는 타깃 애플리케이션을 연결해야 함. 그리고 연결하는 소스/타깃 애플리케이션이 많아질수록 소스코드 및 버전 관리 이슈 발생. 추가로 타깃 애플리케이션에 장애가 발생할 경우 소스 애플리케이션에도 그대로 영향</li></ul>-&gt; 이러한 문제들을 해결하기 위해 ‘`아파치 카프카(Apache Kafka)`’ 가 탄생.</li></ul><h2>카프카 ?</h2><ul class="tight" data-tight="true"><li>각각의 애플리케이션끼리 연결하는 것이 아닌, 모든 데이터를 한 곳에 모아서 처리할 수 있도록 중앙집중화를 함.</li><li>여러 플랫폼에서의 데이터 스트림을 한 곳에서 실시관 관리가 가능해짐.</li><li>대용량 데이터를 수집하고, 사용자들이 실시간으로 데이터 스트림을 소비할 수 있게 만들어주는 일종의 ‘중추신경계’ 처럼 동작.</li><li>중앙에 배치된 카프카를 통해 소스/타깃 애플리케이션 사이의 의존도를 최소화하여 ‘결합도(Coupling)’ 를 완화함.</li></ul><blockquote>결합도(Coupling)는 소프트웨어 공학에서 매우 중요한 개념으로, 프로그램의 다양한 모듈 간에 상호 의존성의 정도를 나타냅니다.결합도가 높다는 것은 한 모듈이 다른 모듈과 강하게 연결되어 있어서, 하나의 모듈에 변경이 생길 때 다른 모듈에도 많은 영향을 미친다는 것을 의미&lt;/u&gt;합니다.반대로, 결합도가 낮다면 각 모듈은 독립적으로 기능하며, 변경사항이 다른 모듈에 미치는 영향이 적습니다.</blockquote>-&gt; 카프카를 통해 소스 애플리케이션은 타깃 애플리케이션을 고려하지 않고 그냥 데이터를 생산하면 됌.<ul class="tight" data-tight="true"><li>카프카는 내부에 데이터가 저장될 때, 선입선출(FIFO) 방식의 큐(Queue) 자료구조와 유사하게 저장이 됌.→ 큐에 데이터를 보내는 것이 프로듀서(Producer)이고 큐에서 데이터를 가져가는 것이 컨슈머(Consumer) 라고 함.</li></ul><img src="https://image.until.blog/thingk0/article/1718768378756" alt="until-562"><ul class="tight" data-tight="true"><li>카프카의 굉장히 큰 특장점으로, 카프카를 통해 전달할 수 있는 데이터의 포맷은 제한이 없다는 것. 직렬화/역직렬화를 통해 바이트 스트림 형태로 전달되기 때문에 Java 에서 선언 가능한 모든 객체를 지원하며, 카프카 클라이언트에서는 기본적으로 <code spellcheck="false">ByteArray</code>, <code spellcheck="false">ByteBuffer</code>, <code spellcheck="false">Double</code>, <code spellcheck="false">Long</code>, <code spellcheck="false">String</code> 타입 등에 대응한 직렬화/역직렬화 클래스가 제공됌.</li></ul><h2>카프카 브로커와 클러스터 ?</h2><blockquote>카프카 브로커(Kafka Broker)는 Apache Kafka의 기본 구성 요소 중 하나로, 메시지 또는 데이터 스트림의 관리와 전송을 담당하는 서버의 역할을 합니다.</blockquote>서버의 개념에 빗대어 설명하자면, 카프카 브로커는 레스토랑에서의 웨이터와 비슷합니다. 웨이터가 주문을 받아 주방에 전달하고, 준비된 음식을 손님에게 서빙하는 것처럼, 카프카 브로커는 데이터 생산자(Producer)로부터 메시지를 받아 저장하고, 필요할 때 소비자(Consumer)에게 해당 메시지를 전달합니다.<ul class="tight" data-tight="true"><li>실제 상용 환경에서 카프카는 최소 3대 이상의 브로커(=서버)를 카프카 클러스터 형태로 이루어서 분산 운영하여 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록함.<ul class="tight" data-tight="true"><li>클러스터에서 일부 브로커에 장애가 발생하더라도 데이터를 지속적으로 복제하여 관리하기 때문에 안전하게 운영이 될 수 있음. 그래서 최소 3대 이상의 브로커를 하나의 클러스터 형태로 운영해야 함.</li><li>또한, 데이터를 묶음 단위로 처리하는 배치 전송을 통해 낮은 지연과 높은 데이터 처리량이 카프카의 장점.</li></ul></li></ul><h2>카프카의 특장점 4가지</h2><ul class="tight" data-tight="true"><li>높은 처리량<ul class="tight" data-tight="true"><li>카프카는 프로듀서, 컨슈머 모두 브로커와 데이터를 주고받을 때 모두 묶어서 송수신함.</li><li>대용량의 데이터를 송수신할 때, 네트워크 연결 비용은 무시할 수 없는 규모이므로 동일한 양의 데이터를 보낼 때 네트워크 I/O 를 최소화시켜 동일 시간 내에 더 많은 데이터 송수신이 가능함.</li><li>대용량의 데이터를 배치 처리하여 빠르게 처리할 수 있기 때문에 실시간 로그데이터를 처리하는데 적합하며, 파티션이라는 개념을 통해 여러 파티션에 데이터를 분배하여 병렬 처리 또한 가능함.</li></ul></li></ul><ul class="tight" data-tight="true"><li>확장성<ul class="tight" data-tight="true"><li>데이터는 시간에 따라 양이 달라지기 때문에 항상 예측할 수 없음. 그러나, 카프카는 가변적인 환경에서 안정적으로 스케일 인(Scale-in), 스케일 아웃(Scale-out)이 가능함.</li></ul></li></ul><img src="https://image.until.blog/thingk0/article/1718768483787" alt="until-564"><ul class="tight" data-tight="true"><li>영속성<ul class="tight" data-tight="true"><li>카프카는 다른 메시징 플랫폼과 다르게 데이터를 메모리가 아닌 파일 시스템에 저장함. 그러나, 단순히 일반 파일 형태로만 저장하는 것이 아니라 운영체제에서 파일의 I/O 성능을 높이기 위한, 페이지 캐시(Page cache) 영역을 통해 데이터를 캐싱하는 형태이기 때문에 처리량이 높음.</li></ul></li></ul><img src="https://image.until.blog/thingk0/article/1718768518261" alt="until-565"><ul class="tight" data-tight="true"><li>고가용성<ul class="tight" data-tight="true"><li>이전에도 설명했듯이, 카프카 브로커(=서버)를 최소 3개 이상으로 클러스터를 운영하면 일부 서버에 장애가 발생하여도 무중단으로 안전하고 지속적으로 데이터 처리 가능. 그리고, 클러스터로 이루어진 브로커들끼리는 데이터가 복제되어 고가용성 특징을 가짐.</li></ul></li></ul><blockquote>💡 데이터 레이크(Data Lake): 데이터 레이크는 다양한 소스에서 수집한 데이터를 그 형식의 변화 없이 저장하는 저장 공간입니다. 이는 데이터 웨어하우스와 다른 점이며, 데이터 웨어하우스는 필터링되거나 구조화된 데이터만 저장합니다.데이터 레이크의 주요 특징은 운영되는 서비스로부터 수집 가능한 모든 데이터를 원본 형태로 모으는 것입니다. 이렇게 함으로써, 사용자는 필요에 따라 다양한 형태의 데이터를 분석하고 활용할 수 있습니다.</blockquote><hr><h3>정리</h3>카프카는 솔직히 처음 학습해보면 결코 쉬운 개념이 아닐 수 있지만, 그럼에도 불구하고 단점은 별로 보이지 않고 장점만 잔뜩 보이는, 너무 기특한 도구입니다. 그래서 백엔드 개발자라면 카프카를 반드시 알아야 한다는 생각이 강하게 들어, 책도 구매하고 강의도 구입했습니다. 카프카를 마스터한다면 굉장히 다양한 곳에 사용할 수 있는, 잠재력이 무궁무진하다고 생각하기 때문에 앞으로 꾸준히 카프카를 학습해보려고 합니다!<img src="https://image.until.blog/thingk0/article/1718793803772" alt="until-612">

요즘 백엔드는 카프카가 필수인 이유

우리가 카프카를 공부해야 하는 이유 - 브로커와 클러스터 그리고 특징 4가지

팀 프로젝트를 진행할 때마다 팀원들이 각자 생각하는 API 설계 규칙이 달라서, 매번 새로운 회의를 하고 규칙을 작성하는 것이 번거롭고 시간 낭비가 되었습니다.이런 답답한 상황에서 팀원 모두를 설득할 수 있을 만큼 완벽한 RESTful API 설계 규칙을 만들기 위해 많은 노력을 기울였습니다!!!덕분에 팀원들을 설득하여 프로젝트를 빠르게 진행할 수 있었습니다. 원래 노션에 작성해두었던 이 문서를 다른 사람들에게도 도움이 될까 하여 블로그에 올려보게 되었습니다 :)<h2>1. 자원(리소스) 기반 URI</h2><ul class="tight" data-tight="true"><li>일관된 URI 구조: 모든 자원은 고유한 URI를 가짐. 자원은 간결하고 명확하게 식별되어야 합니다.</li></ul><h3>URL 설계 규칙</h3><ul class="tight" data-tight="true"><li>마지막에 / 포함하지 않기:<ul class="tight" data-tight="true"><li>예: <code spellcheck="false">http://api.test.com/users</code></li></ul></li><li>_(underbar) 대신 -(dash) 사용:<ul class="tight" data-tight="true"><li>예: <code spellcheck="false">http://api.test.com/users/post-comments</code></li></ul></li><li>소문자 사용:<ul class="tight" data-tight="true"><li>예: <code spellcheck="false">http://api.test.com/users/post-comments</code></li></ul></li><li>URL에 행위(method) 포함하지 않기:<ul class="tight" data-tight="true"><li>예: DELETE <code spellcheck="false">http://api.test.com/users/1/posts/1</code></li></ul></li><li>컨트롤 자원을 의미하는 URL에는 동사 허용:<ul class="tight" data-tight="true"><li>예: <code spellcheck="false">http://api.test.com/posts/duplicate</code></li></ul></li></ul><hr><h2>Restful API 설계 모범 사례</h2><img src="https://image.until.blog/thingk0/article/1718791191412" alt="until-599"><img src="https://image.until.blog/thingk0/article/1718791228436" alt="until-600"><img src="https://image.until.blog/thingk0/article/1718791344586" alt="until-601"><img src="https://image.until.blog/thingk0/article/1718791581052" alt="until-602"><img src="https://image.until.blog/thingk0/article/1718791600715" alt="until-603"><img src="https://image.until.blog/thingk0/article/1718791633327" alt="until-604"><img src="https://image.until.blog/thingk0/article/1718791656507" alt="until-605"><img src="https://image.until.blog/thingk0/article/1718791687549" alt="until-606"><h3>추가적인 PathVariable 및 QueryString 사용 예시</h3><img src="https://image.until.blog/thingk0/article/1718791707307" alt="until-607"><h3>PathVariable과 QueryString</h3><hr><h3>PathVariable</h3><ul class="tight" data-tight="true"><li>정의: <code spellcheck="false">PathVariable</code>은 URL의 경로에 포함되는 변수를 의미합니다. 일반적으로 리소스의 식별자나 주요 속성을 나타내는 데 사용됩니다.</li><li>적합한 상황:<ul class="tight" data-tight="true"><li>특정 리소스 식별: 특정 리소스에 직접 접근할 때 사용합니다. 예를 들어, <code spellcheck="false">/users/{id}</code>에서 <code spellcheck="false">{id}</code>는 특정 사용자의 고유 식별자</li></ul></li></ul>입니다.<ul class="tight" data-tight="true"><li>리소스 계층 표현: 부모-자식 관계나 계층적 구조를 표현할 때 유용합니다. 예: <code spellcheck="false">/users/{id}/posts</code>는 특정 사용자의 모든 포스트를 나타냅니다.</li><li>장점:<ul class="tight" data-tight="true"><li>URL 경로의 일부로서 직관적이고 명확하게 특정 리소스를 지목합니다.</li><li>계층적이고 구조적인 URL을 만들 수 있어 API의 가독성이 향상됩니다.</li></ul></li></ul><h3>QueryString</h3><ul class="tight" data-tight="true"><li>정의: <code spellcheck="false">QueryString</code>은 URL의 <code spellcheck="false">?</code> 뒤에 오는 키-값 쌍의 집합입니다. 주로 옵션, 필터링, 정렬 또는 검색 조건 등을 지정하는 데 사용됩니다.</li><li>적합한 상황:<ul class="tight" data-tight="true"><li>데이터 필터링: 특정 기준에 따라 데이터를 필터링할 때 사용합니다. 예: <code spellcheck="false">/products?category=books&amp;price_below=20</code></li><li>정보 정렬: 데이터를 특정 순서로 정렬해야 할 때 사용합니다. 예: <code spellcheck="false">/posts?sort_by=date&amp;order=asc</code></li><li>검색 조건 적용: 키워드나 다양한 파라미터로 데이터를 검색할 때 유용합니다. 예: <code spellcheck="false">/users?name=John</code></li></ul></li><li>장점:<ul class="tight" data-tight="true"><li>URL 경로가 아닌 파라미터를 통해 유연한 데이터 조작과 검색을 할 수 있습니다.</li><li>다양한 파라미터 조합을 통해 복잡한 쿼리와 데이터 요청을 간편하게 처리할 수 있습니다.</li></ul></li></ul><hr><h2>2. HTTP 동사 활용</h2>HTTP 프로토콜은 다양한 동사(메서드)를 제공합니다. RESTful API 설계에서는 이러한 동사를 적절하게 활용하여 API의 의도를 명확하게 전달해야 합니다.<ul class="tight" data-tight="true"><li><code spellcheck="false">GET</code>: 리소스의 정보를 조회하기 위해 사용합니다.</li><li><code spellcheck="false">POST</code>: 리소스를 생성하기 위해 사용합니다.</li><li><code spellcheck="false">PUT</code>: 리소스의 정보를 업데이트하기 위해 사용합니다.</li><li><code spellcheck="false">DELETE</code>: 리소스를 삭제하기 위해 사용합니다.</li><li><code spellcheck="false">PATCH</code>: 리소스의 일부분을 업데이트하기 위해 사용합니다.</li></ul><hr><h2>3. 적절한 상태 코드 반환</h2>HTTP 상태 코드는 API의 응답에 포함되어 클라이언트에게 작업 결과를 알려줍니다. RESTful API 설계에서는 적절한 상태 코드를 반환하여 클라이언트가 요청에 대해 올바르게 대응할 수 있도록 해야 합니다. 일반적으로 사용되는 몇 가지 상태 코드는 다음과 같습니다:<ul class="tight" data-tight="true"><li>200 OK: 성공적인 GET, PUT, PATCH 요청.</li><li>201 Created: 성공적인 POST 요청.</li><li>204 No Content: 성공적인 DELETE 요청.</li><li>400 Bad Request: 잘못된 요청 형식.</li><li>401 Unauthorized: 인증되지 않은 접근.</li><li>403 Forbidden: 권한 없는 접근.</li><li>404 Not Found: 요청한 리소스가 없음.</li><li>500 Internal Server Error: 서버 내부 오류.</li></ul><hr><h2>4. 적절한 데이터 포맷</h2>모든 요청과 응답은 JSON 형태로 주고받습니다.<ul class="tight" data-tight="true"><li>예시 요청/응답 데이터 포맷:<ul class="tight" data-tight="true"><li>요청: <code spellcheck="false">{ "title": "The Great Gatsby" }</code></li><li>응답: <code spellcheck="false">{ "id": 3, "title": "The Great Gatsby" }</code></li></ul></li></ul><hr><h2>5. 적절한 인증과 권한 부여</h2>인증 방식은 API 키, OAuth, JWT 등을 활용합니다.<ul class="tight" data-tight="true"><li>모든 API 요청은 적절한 인증 토큰과 함께 전송되어야 합니다.</li></ul><hr><h3>참고문헌</h3><ul class="tight" data-tight="true"><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://velog.io/@tiger/API-RESTful-API">https://velog.io/@tiger/API-RESTful-API</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://library.gabia.com/contents/8339/">https://library.gabia.com/contents/8339/</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://medium.com/tech-pentasecurity/restful-api-%EB%84%A4%EC%9D%B4%EB%B0%8D-7c81bdb9da63">https://medium.com/tech-pentasecurity/restful-api-네이밍-7c81bdb9da63</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://velog.io/@gun_123/RESTful-API-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99%EA%B3%BC-%EC%98%88%EC%8B%9C">https://velog.io/@gun_123/RESTful-API-설계-원칙과-예시</a></li></ul><img src="https://image.until.blog/thingk0/article/1718793846972" alt="until-613">

원래 혼자서만 몰래 보려고 만든 문서였지만, 다른 사람들에게도 도움이 되고자 그동안 제가 나름대로 정리해서 만든 RESTful API 설계 규칙입니다!!