데이터 중심 애플리케이션 설계 1장 정리

정리

• 계산 중심 → 데이터 중심
  • 옛날처럼 계산을 막 알고리즘으로 쫘라라라락 하는거 아니고 이제는 애플리케이션은 데이터를 보여주는거에 집중하는 중이다.
• 요즘은 하나의 도구로는 개발이 힘들다. 여러 task를 애플리케이션 단에서 묶어서 처리하는거
• 신뢰성
  • 뭔가 잘못되더라도 지속적으로 올바르게 동작함
  • 결함 : 사양에서 벗어난 시스템의 한 구성 요소. 장애 : 사용자에게 필요한 서비스를 제공하지 못하고 서비스가 멈춤.
  • 하드웨어 결함
    • 카카오에서 불난거처럼 고장나는 경우가 많음
    • 이런거는 주로 이중화같은 방법으로 처리하는것 같음
      • 다중 시스템 구성하면 중단시간 없는 처리 가능
  • 소프트웨어 오류
    • 하드웨어는 하나 잘못되면 해결방법이 있는데 이거는 주로 상관관계가 얽혀있어서 좌르르르륵 망할수 있다.
    • 이거 문제가 뭔가 알수없게 특정 상황이 되면 나타난다
      • 트래픽이 막 많아지거나 응답이 느리거나 할 때처럼 예상치 못한 상황(갑작스러운)것에 대한 처리가 미흡하면 안되는 느낌
        • 근데 데드락은 소프트웨어 오류일까 아니면 인적오류일까 궁금하다.
          • 데드락은… 처리를 통해 해결할 수 있지만 특정 상황에서 나는데 뭐지
          • [api 관련해서 문제 → 앞단 proxy로 사용하는 오픈소스 소프트웨어에서 만져주지 않고 connection이나 소켓 수 등등을 제대로 넣어주지 않으면 default로 이상하게 되어있어서 이걸 쓰는 이유가 없다…(프록시가 게이트웨이??) ]
          • 사람의 문제가 없는데 프로그램이나 네트워크 자체가 오류가 있을 때에 → 이러면 오픈소스를 의심해 봐야하는데 → 이 오픈소스가 사람이 짠거인데 우리가 잘 만들어도 이거때문에 문제가 생기는거면 소프트웨어? 인적오류? 뭘까??
            • log4j같은거는…?
            • 그러면 이거는 소프트웨어 / 인적 문제?
              • TS는 유일하게 언어중에 튜링-완전(수학적으로 계산했을때 결과를 정확히 맞출 수 있는) 그런건데 소프트웨어는 잘못이 없는데 사람이 문제면…
              • java의 float 같은데서 문제가 있는건데 이거는 software 문제??
    • 해결방법은.. 각 소프트웨어간의 상호작용을 확인해보고 문제가 발생 안되게 봐야할듯
      • 근데 이거 은근 트래픽 관련 문제가 많은 것 같다. 잘 된다!! 했다가 안되는 그런느낌…?
      • 그리고 이게 쿠베처럼 죽은거를 살리는것도 은근 중요해보인다.
        • 막 트래픽은 감당 가능 숫자의 몇%를 넘으면 안된다 이런것도 있을듯
          • 파드 하나가 죽었으면 다른 파드들이 트래픽을 감당할 수 없으면 연쇄적으로 죽으니까
          • 디도스 받아보니까 쿠베의 중요성을 알겠다.
  • 인적 오류
    • 내가볼때 이게 개발자가 생각해야하는 오류인 것 같음
    • 어째 샌드박스 맨날 나오더니 이거였구만
    • 롤백 관련해서 나는 그동안 commit을 여러 기능을 붙였었는데, 그게 아니라 진짜 기능별 commit하는게 좋을듯!
    • 이거를 좀 열심히 봐야한다 에러 처리 로직도 봐야함…(NPE발생을 막아주는 Kotlin이 이래서 좋아보이기도 하고??) 근데 어차피 문제는 자주 발생하니 엣지테스트 등을 열심히 해야할것같기는 하다
• 확장성
  • 데이터 처리를 늘리기 위해서 하는거
  • 이거는 된다/안된다 보다는 어떻게 커지는거를 어떻게 대처할까? 자원을 어떻게 투입할까?? 같은걸로 생각하면 됨
    • 부하 기술하기
      • 부하 매개변수
        • 초당 요청수, DB R/W, 캐시 히트수 등등…
        • 이 매개변수의 경우는 평균이나 극단적경우 모두 판단해야한다(병목현상의 원인 가능성)
    • 성능 기술하기
      • 부하 매개변수가 바뀔 때에 성능이 얼마나 영향을 받는지?
      • 그리고 그 성능 유지를 위한 자원 요청수 등등..
      • 이게 중요한거는 산술평균이 아니라 중앙값을 쓴다는게 인상깊었다.
        • 그 이유는 사용자 요청의 절반은 중앙값보다 오래걸리기 떄문…
          • 그리고 AWS는 상위 백분위 응답시간(tail latency)를 99.9로 쓴다함
            • 이게 굳이? 싶었는데 진짜 생각해보면 이런 서비스 회사에서 시간이 오래걸린다 → 그 서비스에 가져올 데이터가 많다 → VIP임 이런 흐름이 있어서 되게 중요하다는걸 느꼈음…
          • 어떤 느린 요청때문에 후속 처리가 느려질수도 있다 → 선두 차단 (하나의 서비스에서 시간이 오래걸려서 전체가 느려질수도 있는거지)
      • 부하 대응 접근 방식
        • 이제 그래서 Scale up / out 을 고려해야함
          • 일단 지금까지는 단일노드에서 Scale up하다가 고가용성 요구가 들어어면 Scale out하는 식이 보통임
            • 다만 요즘은 분산 시스템을 위한 도구나 추상화가 좋아져서 바뀌고 있다고는 한다.
• 유지보수성
  • 운용성
    • 모니터링이나 자동화 통합 등등… 여기서 말하는 운영팀은 서비스 운영자가 아니라 SM쪽을 말하는것 같음.
    • 이거는 테스트 모니터링 등이나 위키, GIt PR을 잘 보관하는 등으로 가능한 것 같다.
      • 나도 처음에 진짜 하나도 몰랐는데 그래도 여기 팀에서 wiki를 엄청 잘 작성해주고 주요 사항을 팀 agit에 보관해서 많은 도움이 되었음
  • 단순성
    • 지금 회사에서도 자주 쓰이거나 공통적인 내용을 공통 Util로 관리한다. 이렇게 하면 구현도 편해지고 사람마다 다르게 하는게 적어져서 좋은듯!
      • 다만 이 경우 이해를 못하거나 필요사항이 많을 때에 문제가 발생할 여지가 있긴함… 예를 들어 이번에 진행한 응원하기 프로젝트에서 완전 새로운 요청사항들이 있어서 그에 맞춘 내용을 추가해 넣었다.
        • 요구사항의 변경 / 요청 추가 / 트래픽 증가 등에서 이게 생각보다 문제가 될 여지가 있었던 기억이 있다!!
    • 고수준 프로그래밍을 쓰는것도 이것의 일종이라 한다
  • 발전성
    • 위의 그 요구사항의 변화도 이거랑 비슷한 느낌이지 싶다.
    • TDD처럼 미리 테스트를 정의하고 하는 방식도 요구사항 변화에 맞춰서 하는 것이라고 한다….
      • 근데 개인적으로 궁금한점은 TDD는 오히려 생산성에 악영향을 끼치는것 같고 요구사항이 자주 변경되는 경우 테스트의 deprecate같은 경우나 내부 구현이 확확 바껴서 문제가 생기는 경우가 많은 느낌이었다.
      • 이거에 대해 팀원들이랑 이야기했을 때에도 TDD의 장점은 확실하지만 단점도 너무 큰 것 같다!! 는 느낌이었는데… 이게 발전성에서 말하는 ‘변화를 쉽게 만들기’ 랑 무슨 관련이 있을까??
      • 테스트 케이스 단계에서(아직 구현은 없음) 일 때에 변경사항이 있으면 바로 반영이나 사양에 따른 확정이 가능할 듯 싶기는 하다.

정리

• 계산 중심 → 데이터 중심
  • 옛날처럼 계산을 막 알고리즘으로 쫘라라라락 하는거 아니고 이제는 애플리케이션은 데이터를 보여주는거에 집중하는 중이다.
• 요즘은 하나의 도구로는 개발이 힘들다. 여러 task를 애플리케이션 단에서 묶어서 처리하는거
• 신뢰성
  • 뭔가 잘못되더라도 지속적으로 올바르게 동작함
  • 결함 : 사양에서 벗어난 시스템의 한 구성 요소. 장애 : 사용자에게 필요한 서비스를 제공하지 못하고 서비스가 멈춤.
  • 하드웨어 결함
    • 카카오에서 불난거처럼 고장나는 경우가 많음
    • 이런거는 주로 이중화같은 방법으로 처리하는것 같음
      • 다중 시스템 구성하면 중단시간 없는 처리 가능
  • 소프트웨어 오류
    • 하드웨어는 하나 잘못되면 해결방법이 있는데 이거는 주로 상관관계가 얽혀있어서 좌르르르륵 망할수 있다.
    • 이거 문제가 뭔가 알수없게 특정 상황이 되면 나타난다
      • 트래픽이 막 많아지거나 응답이 느리거나 할 때처럼 예상치 못한 상황(갑작스러운)것에 대한 처리가 미흡하면 안되는 느낌
        • 근데 데드락은 소프트웨어 오류일까 아니면 인적오류일까 궁금하다.
          • 데드락은… 처리를 통해 해결할 수 있지만 특정 상황에서 나는데 뭐지
          • [api 관련해서 문제 → 앞단 proxy로 사용하는 오픈소스 소프트웨어에서 만져주지 않고 connection이나 소켓 수 등등을 제대로 넣어주지 않으면 default로 이상하게 되어있어서 이걸 쓰는 이유가 없다…(프록시가 게이트웨이??) ]
          • 사람의 문제가 없는데 프로그램이나 네트워크 자체가 오류가 있을 때에 → 이러면 오픈소스를 의심해 봐야하는데 → 이 오픈소스가 사람이 짠거인데 우리가 잘 만들어도 이거때문에 문제가 생기는거면 소프트웨어? 인적오류? 뭘까??
            • 소연 : 이거는 오픈소스 에러 아님?
            • log4j같은거는…?
            • 그러면 이거는 소프트웨어 / 인적 문제?
              • TS는 유일하게 언어중에 튜링-완전(수학적으로 계산했을때 결과를 정확히 맞출 수 있는) 그런건데 소프트웨어는 잘못이 없는데 사람이 문제면…
              • java의 float 같은데서 문제가 있는건데 이거는 software 문제??
    • 해결방법은.. 각 소프트웨어간의 상호작용을 확인해보고 문제가 발생 안되게 봐야할듯
      • 근데 이거 은근 트래픽 관련 문제가 많은 것 같다. 잘 된다!! 했다가 안되는 그런느낌…?
      • 그리고 이게 쿠베처럼 죽은거를 살리는것도 은근 중요해보인다.
        • 막 트래픽은 감당 가능 숫자의 몇%를 넘으면 안된다 이런것도 있을듯
          • 파드 하나가 죽었으면 다른 파드들이 트래픽을 감당할 수 없으면 연쇄적으로 죽으니까
  • 인적 오류
    • 내가볼때 이게 개발자가 생각해야하는 오류인 것 같음
    • 어째 샌드박스 맨날 나오더니 이거였구만
    • 롤백 관련해서 나는 그동안 commit을 여러 기능을 붙였었는데, 그게 아니라 진짜 기능별 commit하는게 좋을듯!
    • 이거를 좀 열심히 봐야한다 에러 처리 로직도 봐야함…(NPE발생을 막아주는 Kotlin이 이래서 좋아보이기도 하고??) 근데 어차피 문제는 자주 발생하니 엣지테스트 등을 열심히 해야할것같기는 하다
• 확장성
  • 데이터 처리를 늘리기 위해서 하는거
  • 이거는 된다/안된다 보다는 어떻게 커지는거를 어떻게 대처할까? 자원을 어떻게 투입할까?? 같은걸로 생각하면 됨
    • 부하 기술하기
      • 부하 매개변수
        • 초당 요청수, DB R/W, 캐시 히트수 등등…
        • 이 매개변수의 경우는 평균이나 극단적경우 모두 판단해야한다(병목현상의 원인 가능성)
    • 성능 기술하기
      • 부하 매개변수가 바뀔 때에 성능이 얼마나 영향을 받는지?
      • 그리고 그 성능 유지를 위한 자원 요청수 등등..
      • 이게 중요한거는 산술평균이 아니라 중앙값을 쓴다는게 인상깊었다.
        • 그 이유는 사용자 요청의 절반은 중앙값보다 오래걸리기 떄문…
          • 그리고 AWS는 상위 백분위 응답시간(tail latency)를 99.9로 쓴다함
            • 이게 굳이? 싶었는데 진짜 생각해보면 이런 서비스 회사에서 시간이 오래걸린다 → 그 서비스에 가져올 데이터가 많다 → VIP임 이런 흐름이 있어서 되게 중요하다는걸 느꼈음…
          • 어떤 느린 요청때문에 후속 처리가 느려질수도 있다 → 선두 차단 (하나의 서비스에서 시간이 오래걸려서 전체가 느려질수도 있는거지)
      • 부하 대응 접근 방식
        • 이제 그래서 Scale up / out 을 고려해야함
          • 일단 지금까지는 단일노드에서 Scale up하다가 고가용성 요구가 들어어면 Scale out하는 식이 보통임
            • 다만 요즘은 분산 시스템을 위한 도구나 추상화가 좋아져서 바뀌고 있다고는 한다.
• 유지보수성
  • 운용성
    • 모니터링이나 자동화 통합 등등… 여기서 말하는 운영팀은 서비스 운영자가 아니라 SM쪽을 말하는것 같음.
    • 이거는 테스트 모니터링 등이나 위키, GIt PR을 잘 보관하는 등으로 가능한 것 같다.
      • 나도 처음에 진짜 하나도 몰랐는데 그래도 여기 팀에서 wiki를 엄청 잘 작성해주고 주요 사항을 팀 agit에 보관해서 많은 도움이 되었음
  • 단순성
    • 지금 회사에서도 자주 쓰이거나 공통적인 내용을 공통 Util로 관리한다. 이렇게 하면 구현도 편해지고 사람마다 다르게 하는게 적어져서 좋은듯!
      • 다만 이 경우 이해를 못하거나 필요사항이 많을 때에 문제가 발생할 여지가 있긴함… 예를 들어 이번에 진행한 응원하기 프로젝트에서 완전 새로운 요청사항들이 있어서 그에 맞춘 내용을 추가해 넣었다.
        • 요구사항의 변경 / 요청 추가 / 트래픽 증가 등에서 이게 생각보다 문제가 될 여지가 있었던 기억이 있다!!
    • 고수준 프로그래밍을 쓰는것도 이것의 일종이라 한다
  • 발전성
    • 위의 그 요구사항의 변화도 이거랑 비슷한 느낌이지 싶다.
    • TDD처럼 미리 테스트를 정의하고 하는 방식도 요구사항 변화에 맞춰서 하는 것이라고 한다….
      • 근데 개인적으로 궁금한점은 TDD는 오히려 생산성에 악영향을 끼치는것 같고 요구사항이 자주 변경되는 경우 테스트의 deprecate같은 경우나 내부 구현이 확확 바껴서 문제가 생기는 경우가 많은 느낌이었다.
      • 이거에 대해 팀원들이랑 이야기했을 때에도 TDD의 장점은 확실하지만 단점도 너무 큰 것 같다!! 는 느낌이었는데… 이게 발전성에서 말하는 ‘변화를 쉽게 만들기’ 랑 무슨 관련이 있을까??
      • 테스트 케이스 단계에서(아직 구현은 없음) 일 때에 변경사항이 있으면 바로 반영이나 사양에 따른 확정이 가능할 듯 싶기는 하다.