[NHN FORWARD 22] 분산 시스템에서 데이터를 전달하는 효율적인 방법

แชร์
ฝัง
  • เผยแพร่เมื่อ 27 พ.ย. 2024

ความคิดเห็น • 55

  • @exsylee
    @exsylee หลายเดือนก่อน

    MSA구조로 가야한다면 정말 중요한 내용.!!
    강의 감사합니다.

  • @kwo2002
    @kwo2002 8 หลายเดือนก่อน

    잘봤습니다. 감사합니다

  • @xeropise
    @xeropise ปีที่แล้ว +3

    좀더 내용이 길었으면 할 정도로 내용이 좋은 강의네요 감사합니다

  • @호빵맨주인-j3j
    @호빵맨주인-j3j 8 หลายเดือนก่อน

    msa에서 kafka를 쓰는 이유가 이거군요 쉽게 설명해주셔서 고맙습니당

  • @acanisijin
    @acanisijin ปีที่แล้ว

    전문적인 용어들을 이해하기 쉽게 설명해주셔서 정말 좋았어요 무엇보다 중요한 데이터를 정확하게 전달할 수 있는 팀에 대해 배울 수 있어서 유용한 시간이었습니다 좋은 정보 감사합니다

  • @JY-Dev
    @JY-Dev ปีที่แล้ว +1

    진짜 좋은 강의에요!

  • @김태현-w9q8q
    @김태현-w9q8q ปีที่แล้ว

    최근에 카프카 관심이 있었는데, 초심자에게 이해갈 수 있도록 설명해주셔서 감사합니다.

  • @kimta3314
    @kimta3314 ปีที่แล้ว +1

    엄청난 발표...

  • @배성재-p4e
    @배성재-p4e ปีที่แล้ว

    감사합니다

  • @kibumkim8687
    @kibumkim8687 5 หลายเดือนก่อน

    제 짧은 생각에는 컴퍼넌트 간의 파이프라인 역할을 하는 큐를 외부 별도 프레임 워크에 의존하는 것보다는 각 컴퍼넌트가 자신의 큐를 관리하는 방식이 더 효과적이고 관리 측면에서 용이하지 않을까?라는 의문이 생깁니다. (물론 구현의 난이도는 올라가겠지만)

  • @김선우-g1k9s
    @김선우-g1k9s ปีที่แล้ว

    처음에는 방법을 이야기 하시면서 데이터를 전달하는 효율적인 방법에 대한 근거와 과정을 설명하셨는데.
    후반부로 갈수록 코드에 대한 설명이 길어지면서 이론적인 방법보다 코드 작성 방법에 대해서만 말씀하시는 듯합니다.
    RDB 를 이용한 방법은 비교적 자세하게 나와있으나 ( 설명 )
    Rabbit MQ / Kafka 는 ACK , NACK 에 대해 설명을 하다가 코드로 넘어가서 코드 설명만 들었네요
    이렇다는건 RDB 는 위험성이 꽤나 높은 방법이고 ( 단점도 리스크가 높음 )
    Rabbit MQ / Kafka 와 같이 AMQP 기반들은 ACK / NACK 를 통해서 메세지 송/수신에 안정적이기 때문에 특별한 상황을 고려할 필요없고
    코드 작성에 대해서만 알려준게 아닐까 싶습니다.
    다 들어봤을때 이렇다는거지 다른 분 생각은 어떨지 궁금합니다

  • @핵자전거
    @핵자전거 ปีที่แล้ว +3

    이런걸 볼때마다 참. 이게 뭐하는 짓인가 싶은 생각도 듭니다.
    저런 처리 c++에 native coding으로 서로 주고 받게 하면코드도 성능도 앞도적으로 좋고 코드도 짧고 이런 거 신경안써도 되고 훨씬 좋을텐데 왜 이런 비효율적인 짓을 하는지 이해가 안 가네요.
    앗사리 성능은 그냥 신경을 쓰지 말든지 그것도 아니고 참...
    kafka도 웹 request에 비해 빠른 거지 c++ native coding으로 송수신하느 것에 비하면 성능 압도적으로 떨어지고 응답시간은 더더욱 떨어집니다.
    이렇게 고생해서 더 덜떨어지는 걸 만드는 이유가 도대체 뭘까요.

    • @wqeqweew3278
      @wqeqweew3278 ปีที่แล้ว +4

      단순히 성능만을 따지면 당연히 그러할듯 합니다. 다만 kafka를 사용하는 장점은 전송 속도의 문제보다 스트림을 안전하고 확장성 있게 처리하는 관점에서 이점이 있어서 사용하는 것 같습니다. replication, checkpoint 등의 존재일 테고 partition, broker clustering 과 같은 대규모 데이터에서 확장성을 고려할 수 있는 이점이 있죠

    • @핵자전거
      @핵자전거 ปีที่แล้ว

      ​@@wqeqweew3278 어차피 tcp인데 kafka라고 무슨 용 빼는 전송 방법이 있는 건가요?
      더군다나 kafka는 전송 성능을 늘리기 위해서 delay를 줘서 gathering 하는 걸로 알고 있는데?
      kafka 전송이 특별히 더 안전한 이유 있나요?
      그냥 제가 보기에는 웹기술쪽이 너무 기형적이 된 듯합니다.
      해외 웹서비스 개발을 할 때 c++많이 씁니다. google은 말할 필요도 없고 facebook은 서비스 주유 코드 대부분이 c++로 되어 있다는 것은 유명하죠.
      서비스에 맞게 native code로 다양한 tool이나 뭐 라이브러리들을 만들고 그걸 기반으로 서비스를 개발해서 생산성과 효율을 모두 챙기는 것이 일반적이죠.
      kafka도 링크드인이 자기들 서비스 개발하기 위해 만든 것 아닌가요?
      웹서비스 개발에 쓰이는 수많은 툴들이 이런 과정에서 개발된 것이죠.
      근데 대한민국에서는 최고의 인터넷 서비스 개발사들에게는 이런 절대 만들지 않습니다.
      native code로 직접 만들어야 한다는 개념 자체가 없을 뿐만 아니라 구식이고 잘못된 것이라고 생각하는 수준이에요. 왜 그런 걸 만드냐? 뭐 이런 마인드냐.
      그냥 서비스를 어떻게든 해외에서 나온 툴들 가져다가 이리 저리 짜집기해서 개발하는 것에만 몰두 하고 있다는 것입니다.
      비유를 하자면
      어느 나무꾼이 나무를 자르는 툴로 톱을 개발해서 나무 자르는데 짱이라며 세상에 공개를 했는데...
      대한민국은 그걸 가져다가 톱으로 못 박는법!! 톱으로 못을 뽑는 법!! 톱으로 페인트 칠하는 법!! 톱으로 밥 짓는법 이러고 있다는 겁니다.
      게다가 이런 잘해봐야 사용 스킬 쯤에 해당하는 것들이 마치 대단한 기술처럼 발표되고 있다는 것이 문제란 것이죠.
      이런 툴 사용법 기술로는 기술력 누적이 안돼요. 결국 세계적인 기업들에 무슨 AI니 뭐니 이런 그럴싸한 기술에 밀려서 망하는 게 아니라
      결국 효율성에 밀려서 경쟁력을 잃을 겁니다.
      성능이 절실한 서비스면 kafka로 어떻게든 꼼수 쓰면서 성능 올리려 할 것이 아니라!!
      그 서비스에 맞는 native 툴이나 라이브러리를 직접 만들어서 세상에 공개할 생각을 하라는 겁니다.
      kafka 성능 죽을 쓰고 용을 써서 올려도 해당 서비스에 맞춰서 c++에 native code로 만들어진 서버 성능 1/10도 안 된다는 거 장담합니다.
      물론 모든 걸 다 만들어야 된다는 것은 아닌데 전부 짜집기에 몰빵 되어 있는 것이 문제란 겁니다.
      거대한 인터넷 서비스 사는 있는데 뭐하나 세상에 널리 알려진 작은 툴 하나 없지 않습니까?
      안 그래도 대한민국 소프트웨어는 인터넷 서비스에 몰빵 되어 있는데 그 조차도 이 지경이니 문제란 거죠.
      나름 국내 최대 개발사라는 곳 조차 이러니 대한민국 IT가 세계적인 경쟁력을 가질 수가 있을까요?
      시간은 걸리겠지만 결국 점점 고사될 겁니다.
      서비스에 native로 맞게 직접 개발하는 건 회사에서 앗사리 배제하고 주구장창 남이 만든 툴들 가져다가 짜집기해서 서비스 개발하는 회사가 경쟁이 될까요?
      인프라 서비스는 결국은 효율의 싸움이고 비용의 전쟁인데...
      그런 인프라 서비스 조차 JAVA같은 vm에서 동작하는 비효유적인 플랫폼으로 도배를 하고 있으니 과연 진짜... 경쟁이 될까 모르겠네요.
      세계적으로 JAVA에 점유율도 절반 안되던 C++이 점점 늘어나더니 올해 JAVA를 4위로 제치고 3위 에 올라섰습니다. 1,2위는 C와 Python이죠.
      의미 하는 것이 뭘까요?
      근데도 우물안 개구리처럼 대한민국은 여전히 JAVA와 spring 공화국이 더욱 공고화만 되어가고 있죠.
      네이버와 다음이 인터넷 검색 절대 과점이었다가 이미 구글에 거의 다 뺏겼는데 나머지 서비스들은 과연 무사할까요?
      계속 이 수준이면 힘들다고 봅니다.

    • @zesrt444
      @zesrt444 ปีที่แล้ว +10

      이 사람은 진짜 아무것도 모르면서 떠드는 사람이구나

    • @핵자전거
      @핵자전거 ปีที่แล้ว

      @@zesrt444뭘 모른다는 것이죠? 제가 이 발표하시는 분보다 못하지는 않을텐데요?

    • @Gooya6609
      @Gooya6609 11 หลายเดือนก่อน +7

      발표의 주제와 내용 자체가 '성능'이 아니라 '데이터의 정확성'에 포커싱 되어 있습니다. 수억건의 대용량 데이터를 처리할때 단순히 성능이 중요한 도메인도 있지만, 성능보다는 데이터의 정합성이 훨씬 중요한 도메인도 있지요. 그런 측면에서 보면 말씀하신대로 처리하는게 적합한 도메인도 있고, 그렇지 않은 도메인도 있는듯 합니다 ^^
      그래서 발표의 내용이 비효율적인게 아니라, 도메인에 따라 더 적합한 개발방식이라 볼 수 있지 않을까요?