Notice
Recent Posts
Recent Comments
«   2024/07   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
Archives
Today
Total
관리 메뉴

채록채록

[CloudComputing] Review_The Antifragile Organization:Embracing Failure to Improve Resilience and Maximize Availabilit 본문

Cloud Computing

[CloudComputing] Review_The Antifragile Organization:Embracing Failure to Improve Resilience and Maximize Availabilit

김책은 2024. 4. 10. 01:11

불가피하고 예측할 수 없는 실패에 직면했을 때,
사용자가 의존할 수 있는 높은 수준의 가용성을 제공하는 서비스를 어떻게 구축할 수 있을까? 

라는 질문을 내 인생에 대해서도 던져보고 싶다...ㅎ

불가피하고 예측할 수 없는 실패에 직면했을 때,
내가 의존할 수 있는 높은 수준의 삶을 제공하는 습관을 어떻게 구축할 수 있을까?

뭔소리임

Reference : https://queue.acm.org/detail.cfm?id=2499552

 

 

The Antifragile Organization - ACM Queue

June 27, 2013Volume 11, issue 6   PDF The Antifragile Organization Embracing Failure to Improve Resilience and Maximize Availability Ariel Tseitlin Failure is inevitable. Disks fail. Software bugs lie dormant waiting for just the right conditions to bite.

queue.acm.org

 

  1. 불가피하고 예측할 수 없는 실패에 직면했을 때, 사용자가 의존할 수 있는 높은 수준의 가용성을 제공하는 서비스를 어떻게 구축할 수 있을까? 라는 질문으로 본문이 시작된다.
  2. 엄격한 분석을 통해 시스템의 정확성을 증명하려고 시도할 수 있다. 다양한 유형의 오류를 모두 모델링하고 simulation/emulation하거나, 분석용 프레임워크를 사용해 시스템의 올바른 작동을 추론하는 것이 가장 이상적이겠으나… 현실적으로 아직은 불가능하다.
    1. 모든 실패 상황을 시뮬레이션 하기위한 test suites를 만들어서 개별적인 테스트 환경에서 실행한다. 그리고 각 test suite에서 각 구성요소가 실패할 때 개별 구성요소의 올바른 작동과 전체 시스템의 기능을 유지하게 한다.
      1. 그러나, 대규모 분산 시스템에서 resilience(탄력성)을 유지하기엔 충분하지 않다.
      2. 대규모 분산 시스템에서는 데이터 일관성, 병행성 제어, 네트워크 지연 등의 문제가 발생할 수 있기 때문이다.
      3. 많은 컴포넌트와 서비스가 상호작용하는 대규모 분산 시스템의 특성상 이를 모두 포함하는 완전한 테스트 환경을 구축하다보면 배보다 배꼽이 더 커질수도 있다.
    2. 시스템이 실제 환경에서 실패를 유발하여 경험적으로 resilience를 시연하고 의도한 동작을 검증한다.
      1. 테스트 환경에서 잡히지 않고 실제 운영환경에서만 발생할 수 있는 잠재적인 버그를 발견하고 더 큰 문제를 예방한다.
      2. 데이터 정보 흐름 및 배포 아키텍처 변경을 모델링할 필요가 없다.
  3. 그래서 시스템의 resilience를 높이는 방법이 무엇이냐?
    1. Build your application with redundancy(중복성) and fault tolerance(장애허용시스템)
      1. service-oriented architecture : 서비스라는 소프트웨어 구성요소 (업무상의 일 처리에 해당)를 사용해 비즈니스 애플리케이션을 생성하는 소프트웨어 개발 방식. 각 서비스는 네트워크상에 연동되어 서로 통신한다.
      2. 시스템을 구성하는 부품의 일부에서 fault/failure가 발생하여도 정상적/부분적으로 기능을 수행할 수 있는 시스템을 구성
    2. 정기적으로 실패를 유도한다.
  4. GameDays → The Simian Army
    1. Chaos Monkey
      1. 깨어나서 주사위를 굴려 AWS API를 사용하여 영향을 받는 개별 서버 instance를 종료한다.
      2. 시스템이 서버가 다운될 때 또는 예기치 않은 상황에서도 계속해서 동작할 수 있는지를 테스트
    2. Chaos Gorilla
      1. 클라우드 환경에서 전체 데이터 센터가 실패하는 상황같은 대규모의 장애를 시뮬레이션 한다.
      2. Network partition : 해당 zone 내의 instance는 여전히 실행 중이며 서로 통신할 수 있지만, 해당 zone 외부의 서비스와 통신할 수 없는 상황을 시뮬레이션한다.
      3. Total zone failure: : 해당 zone의 모든 instance가 종료된다.
    3. Chaos Kong
      1. 특정 region에 있는 모든 인프라 자원과 서비스와 인스턴스가 다운되는 상황을 모의한다.
        1. region : made up of multiple data centers(availiability zones)
          1. 아 그래서 ACC 동아리에서 regional captain이라고 한거였구나... 싶었다ㅋㅋ
      2. 시스템이 여러 지역에 중복 배포되면 지역 오류를 테스트해야한다.
        1. 강력한 deployment(배포) 아키텍처는 AZ 중복성이 있다.
    4. Latency Monkey
      1. 서비스가 성공적으로 응답할 수 있지만 대기 시간이 증가하여 시간 초과가 발생할 수도 있다.
        1. 클라우드 환경에서는 네트워크 지연, 데이터베이스 응답 지연 등 다양한 원인으로 인해 시스템의 레이턴시가 발생하기 때문이다.
      2. RESTful 클라이언트-서버 통신 계층에서 인위적인 지연을 유도하여 서비스 저하를 시뮬레이션하고 upstream 서비스가 적절하게 응답하는지 측정한다.
        1. 서비스 간 통신에 인위적인 지연을 주어 네트워크 지연의 영향을 확인하거나, 데이터베이스 쿼리의 응답 시간을 인위적으로 늘려서 데이터베이스 지연에 대한 시스템의 반응을 테스트
        2. 풀스택서비스 네트워킹에서 교수님께서 RESTful 클라이언트-서버 통신 계층에 대해서 다음시간에 설명하신다고 했던게 생각났다. 내가 알던 RESTful api는 그냥 웹사이트 만들때 규칙정도라서 오잉 이게 어떻게 풀스택서비스네트워킹이랑 관련이 있지 싶었는데 여기서 또 등장한다. 다음 수업 시간을 기대와 기쁨으로 기다릴 수 있을 것 같다.
      3. instance나 서비스를 물리적으로 중단하지 않고 매우 큰 지연을 사용하여 노드/전체 서비스 가동 중지를 시뮬레이션 할 수 있다.
  5. Netflix는 Simian을 도입할 때 다음 단계를 수행한다.
    1. 엔지니어는 테스트 환경에서 새로운 원숭이를 사용하여 사용자 경험을 관찰한다. 고객에게 미미한 영향만을 미칠 때까지 반복한다.
    2. 프로덕션 환경에서 새 원숭이를 활성화 시킨다. 처음에는 새 원숭이가 opt-in mode에서 실행된다.
      1. opt-in mode : 사용자가 원숭이를 수동으로 활성화하는 모드. 시스템이 새로운 원숭이를 자동으로 모든 서비스에 적용하지 않도록 하는 것.
    3. 많은 서비스가 opt-in 된 후 새로운 원숭이는 opt-out mode로 전환된다. 즉, 모든 서비스가 새로운 원숭이의 잠재적인 대상이 된다.
      1. 자동화, ai가 일자리를 대체하지 못하는, 결국 어딘가에는 사람이 해야하는 업무가 존재한다. 그런 업무를 맡는 사람이 되고 싶다. 
    4. opt-out list : 각 원숭이에 대해 정기적으로 검토되어 원숭이는 해당 서비스를 회피한다.
  6. <세이노의 가르침>, <나는 4시간만 일한다>에서 최근에 읽었던 내용도 이와 비슷한 내용이 있던 게 생각났다.
    1. <세이노의 가르침>에서는 야무지고 원대한 꿈을 실현시키는 아주 작은 단계들은 하찮게 여기고 무시하지 말라고 한다. 그래서 소박하고 구체적으로 실행 가능한 목표를 세우라고 한다.
    2. <나는 4시간만 일한다>에서는 우리의 적은 지루함이지 어떤 추상적 개념의 ‘실패’가 아니다라는 말이 나온다.
      1. 본문에서 인상깊었던 말은, 각각의 실패는 “어떻게 실패를 더 빨리 감지할 수 있었습니까?" "이러한 유형의 오류에 대해 시스템의 복원력을 어떻게 높일 수 있습니까?" "어떻게 이런 실패가 정기적으로 유도될 수 있습니까?”의 질문을 생성하는 학습 기회라는 말이다.
      2. 시스템은 실패하는 횟수와 방식이 많아질수록 더 좋아진다.
        1. 어쩌면 나도? ㅋ 
    3. 이래서 0101로 이루어진 컴퓨터공학 학문에서도 ‘철학’이 존재하고 ‘방법론’이 존재하는걸까 하는 재밌는 상상을 해보게 되는 이런 순간이 내가 이 전공에 발붙이는 낙이 되어준다.
  7. TED '할일을 미루는 사람의 심리'에서도 머릿속을 어지럽히는 존재로 원숭이가 나오는데 외국에서는 원숭이가 이런역할을 맡는게 흔한 일인가보다ㅎㅎ 소소하게 재밌는 포인트였다. 
    https://www.ted.com/talks/tim_urban_inside_the_mind_of_a_master_procrastinator?language=ko
 

할 일을 미루는 사람의 심리

팀 어번은 할 일을 미루는 것이 말이 안 된다는 걸 알면서도 마지막까지 할 일을 미루는 습관을 버릴 수가 없습니다. 이 재미있고도 통찰력 있는 강연에서 어번은 유튜브 몰아보기, 위키피디아

www.ted.com