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