전체 글

💼 Microservicer의 분산 추적 ( 추적정보 Tracing ) MSA 환경에서 하나의 요청이 여러 개의 서비스를 호출 할 수 있다는 것을 알 수 있다. 그렇다면 우리가 문제가 발생했을때마다 일일히 모든 서비스를 찾아본다는게 쉽지 않다. 때문에 우리는 요청 정보의 실행 정보와 어떤 과정을 거쳐 어느 서비스로 이동되고 있는지 알아야할 필요성을 느꼈다. 그것이 분산 추적이다. 💼 Zipkin 우리가 분산 추적을 하여 추적을 하면 정보가 남는데 그것을 트레이싱이라고 한다 그렇다면 트레이싱을 어디에 저장을 할 수 있는 서비스가 필요하다 그때 사용하는 것이 바로 Zipkin이다. Twitter에서 사용하는 분산 환경의 Timing 데이터 수집, 추적 시스템 (오픈 소스) Google Drapper 에서 발..

🎩 장애 발생 UserService를 잘 사용하다가 OrderService나 CatalogService에서 장애가 발생하여 데이터를 전달 받지 못하게 된다면 그것은 해당 서비스의 문제가 된다. 하지만 중요한것은 반환값이다. 요청에 의한 응답엔 UserService가 문제가 발생했다고 얘기한다는 말이다. 그렇기 때문에 UserService 혹은 다른 서비스들도 그에 대한 대비가 되어있어야 한다. UserService에서 보이는 getOrders가 문제가 발생하면 다른 메소드를 호출해서 데이터를 처리하여 안정적으로 응답을 해야 한다는 말이다. 그러면 정상적인 응답이 전송될것이다. 하지만 문제가 발생한 Order쪽의 데이터는 정확하지 않게 되면서 우리는 Order서비스가 문제가 발생한 것을 알 수 있고 Use..

💥 구현의 어려움 기존에는 알고리즘을 이용해 문제를 풀기만 하면 되는 방식이였는데 이제 시뮬레이션과 구현문제가 주를 이뤘다 때문에 문제 하나하나의 시간이 굉장히 오래 걸리고 고민하는 시간도 굉장히 많이 길어졌다 💥 팀스터디 팀스터디의 방식이 조금 달라질것 같다 기존에는 문제를 다 풀고 만났는데 그렇게 하다보니 문제를 멍하니 보는 시간만 길어지는것 같다 그래서 방식을 조금 달리해서 문제의 이해와 풀이 방법을 조금 빠르게 생각해내려고 한다 1시간의 시간 제한을 두고 한문제를 풀고 다시 만나는 것이다. 그렇게 하면 코테를 대비하는 시간도 절약이 될 것 같고 좀 더 간단하고 빠르게 문제를 푸는 연습도 될 것 같다

이전에 배웠던 Kafka를 이용해 각각의 서비스의 데이터 변동에 의한 다른 서비스의 데이터베이스가 같이 변경되는 것을 확인해보자 🧶 Order ▶ Catalog orderservice에서 요청된 주문의 수량 정보를 Catalog service에 반영이 된다. orderservice에서 kafka topic으로 메세지를 전송하고 catalogservice에서 kafka topic으로 전송 된 메세지를 받는다 즉 order service 는 producer, catalog service는 consumer 가 되는 것이다. orderservice 가 자신의 테이블에 DB를 변동시키면 kafka에 topic을 통해 변동된 내용을 전달한다. 그럼 해당 topic을 구독하고 있는 catalog service또한 t..

💥 또다시 코테 주의 마지막 날인 화요일에 코테를 본다. 오늘도 역시 코테를 보았다 이번 주제는 저번주에 자주 다룬 내용으로 코테를 진행했고 이번에도 역시 결과는 뭐...비슷하닼ㅋㅋ 그래도 코테와는 별개로 문제를 푸는 습관을 많이 들여놓으니까 문제를 보는데 거부감이 훨씬 나아진것이 느껴진다 💥 DFS 와 이분탐색의 조합 오늘의 코테 중 4번이 가장 인상적이다. DFS와 이분탐색을 합친 문제라니 골드 2인 이유가 있다. 그러고보니 이제 그냥 문제를 주다보니까 티어를 많이 안보게되었다 예전에는 실버에서 계속 놀았기 때문에 골드는 꿈도 안꿨는데 이렇게 꼭 풀어야하는 문제로 줘버리니까 자연스럽게 많이 풀게되는거 같다 이건 좋은 현상인것 같아

💥 너비 우선 탐색과 깊이 우선 탐색 오늘은 DFS 와 BFS를 좀 더 본격적으로 풀어본 느낌이 났다. 기존에 관련 문제를 풀지 않아서 걱정을 많이 했던 만큼 역시 문제는 많이 어려웠다. 우선 이해도가 굉장히 낮은게 매우 아쉬웠다. 그래서 좀 더 문제의 속도보다 알고리즘의 이해도를 더 중요시하기 위해 문제를 몇 번이나 풀어보고 또 나아가 BFS가 아닌 다른 방법으로 푸는 방법을 생각해보기도 하면서 좀 더 이해도를 올렸다 💥 팀스터디 인접 행렬과 인접 리스트 평소에 문제를 풀떄는 배열을 사용해서 문제를 풀기 떄문에 인접 리스트가 너무 어색했다. 행렬은 눈으로 바로 보이는데 반해 인접리스트로 연결된 노드를 표현할때는 머릿속으로 그림을 그려놔야 하는 느낌이기 때문이다 그래도 시간복잡도의 차이가 어마어마해서 알..

🍀 kafka 의 개요 Scalar 언어로 된 오픈 소스 메세지 브로커 프로젝트이다 실시간 데이터 피드를 관리하기 위해 통일된 높은 처리량과 낮은 지연 시간을 지닌 플랫폼을 제공하고 있다. ♪ kafka 를 사용하는 이유 위 사진의 방식의 단점 End - to - End 연결 방식의 아키텍처이다 데이터 연동의 복잡성이 증가한다 (HW, 운영체제, 장애 등) 서로 다른 DB를 사용하면 다른 종류의 DB에 데이터를 전달하는 것은 쉽지 않다. 때문에 확장이 어렵다는 단점이 존재한다. 때문에 모든 시스템으로 데이터를 실시간으로 전송하여 처리하는게 필요했고 또 데이터가 많아지더라도 확장이 용이한 시스템이 필요졌고 그로 인해 Kafka라는 시스템이 도입되었다 Kafka의 등장으로 각각의 DB는 더이상 어떠한 시스템..

🐟 시작하기에 앞서.. 설치에 앞서 굉장히 실패를 많이 하게 되어 다른 사람들은 그렇게 되지 않았으면 하는 마음에 굉장히 꼼꼼히 작성할것이다. 필자는 이미 한 번 진행을 하게 되어 파일이 모두 있다...하지만 최대한 알 수 있도록 노력하여 작성해본다. 환경은 윈도우이며 폴더는 C드라이브에 만들어진 kafka폴더를 이용해서 진행할 예정이다 윈도우의 환경으로 인해 bin/windows 의 경로에서 진행할 것이다. 🐟 Zookeeper 와 Kafka server 우선 connect 설치를 하기 앞서 알아두어야 하는 것은 주키퍼와 카프카서버는 열려있어야 한다는 조건이 있다. 주키퍼와 카프카를 정상적으로 설치했다면 kafka_버전으로 적힌 폴더가 있을 것이다. ※ c/kafka/kafka_버전/bin/window..

💥 이분 탐색 ▶ 어제도 했던 이분 탐색 코테를 풀 때는 어떤 알고리즘을 사용해서 문제를 풀게 할지 정해서 내는 것이 아니기에 주제를 보지 않고 바로 문제를 봤다. 결과는 역시 처참...뭘 원하는지 몰라 이것저것 생각을 하게 만들었다 이분 탐색이라는 생각은 바로 드는게 아니라 한참을 고민하고 다른 코드도 적어보고 했다가 든 생각이였다. 또한 이분탐색의 주제를 가지고 낸 문제에서 정작 이분 탐색을 이용해 문제를 푼 것은 한문제 뿐이였다. 분발해야지 💥 팀스터디 ▶ 정말 다양한 풀이 방법 나는 전혀 생각하지 못한 방법으로 문제를 푸는 사람들을 보면 너무 신기하다. 또한 코드를 짧게 작성할 수 있다는 사실도 굉장히 흥미로웠다. 이번 사각형의 넓이를 구하는 문제만 해도 이분법을 생각하여 왼쪽에서 가운데로 오른쪽..

💥 이분탐색 ▶ 문제 풀이 이분탐색을 하는 문제가 정확히 떠오르는 것은 쉽지 않다. 자료구조를 사용하게 하는 문제는 중복을 없앤다던가 순서를 중요시 한다던가 하는 규칙이 존재하는데 이분탐색의 경우는 이분탐색이 아닌 방식으로도 풀수 있다는 것이다. 또한 코딩테스트의 특징 상 수학적 능력을 중요시 하게 되는데 아직 이러한 경우의 수를 바로바로 떠오르는 것이 쉽지 않다. 💥 팀스터디 ▶ 시간복잡도 계산 백준을 기반으로 진행하는 코테이기 때문에 시간복잡도를 계산해도 어떤것이 나은지 확실히 할 수 없었지만 매니저님이 좀더 직접적으로 계산하는 방법을 알려주셨다. 그래서 백준에서 빠르게 계산을 마쳤다 하더라도 해당 코드 자체의 시간복잡도가 우수하다 라고 할 수는 없었다 짧은 데이터에는 빠를지 몰라도 데이터의 양이 커..