연주 로그

Repository > Repository Settings > Ignored Files 추가 

대규모 마이크로 서비스의 대응 패턴 

장애는 어디서든 발생할 수 있다는 가정을 명심하는 거은 문제 해결 방법을 다르게 생각하도록 만든다.

얼마나 많은 장애를 감내할 수 있는지와 얼마나 빠른 시스템이 되야 하는지 아는 것은 시스템 사용자에 의해 좌우 된다.

부하와 장애를 더 잘 처리하기 위해 다음과 같은 시스템 확장을 고려할 수 있다.

- 응답시간/지연시간 ex) 웹사이트가 초당 200개의 동시 접속수를 처리할 때 응답시간의 90%가 2초 미만을 유지할 것으로 예상된다

- 가용성, 데이터의 내구성 

기능분해의 중요성 

회복력 있는 시스템 구축을 위해서는 안전하게 기능을 분해할 수 있는것이 중요하다. 다수의 마이크로서비스를 사용하는 모든 고객을 향한 인터페이스나 다수의 하위 협업자 서비스에 의존하는 마이크로서비스가 다운되면 어떤 일이 벌어질지 자문하고 무엇을 해야 할지 알아야 한다. 교차 기능 요구 사항의 고나점에서 개별 기능의 심각도를 생각함으로써 우리가 무엇을 할 수 있는지 훨씬 더 잘 알게 될 것이다. 

안티프래질 조직 : 실패와 무질서로부터 얻을 수 있는 혜택

실제로 장애를 조작하여 궁극의 장애 테스트를 할 수도 있다. 분산된 아키텍처에서 발생할 수 있는 이런 장애를 대응하기 위한 준비

- 타임아웃 : 모든 프로세스 경계 외부의 호출에 타임아웃을 넣고 항상 기본 타임아웃 시간을 설정해야 하는데 발생 시간을 로깅하고 어떤 일이 발생했는지 살펴보며 타임아웃 시간을 적절히 변경해 주어야 한다.

- 회로 차단기 : 호출 타임아웃 또는 오류가 발생하기 시작했을떄 임계치를 초과하면 커텍션을 중단키셔 요청이 실속히 실패하도록 한다. 그다움 서브 시스템이 복수 여부를 간헐적으로 확인하고 정상 임계치에 도달하면 커텍션을 리켓한다. 

- 격벽 : 각각의 하위 커넥션 마다 각각의 다른 커텍션 풀을 사용

- 격리 : 하위 서버를 오프라인 상태로 만들 수 있는 통합 기술을 사용하여 하나의 서비스가 다른 서비스에 의존하지 않도록 한다.

확장

- 더 크게 만들기 : 더 큰 머신에 더 빠른 CPU와 더 좋은 I/O를 탑재 한다고 해서 모든 문제가 해결되는 것은 아니지만 이는 빠르고 좋은 해결 방안이다. 

- 작업부하 나누기 : 중요성의 크기에 따라 서비스를 잘 분리한다. 

- 부하 분산 : 부하분산기는 유입된 호출을 주어진 알고리즘에 따라 하나 이상의 인스턴스에 분배하고 인스턴스가 정상 동작하지 않거나 복구되었을 때 제거하거나 추가한다. 일부 부하분산기는 SSL termination 기능을 제공한다. 분산기로 유입되는 HTTPS 커넥션을 HTTP커넥션으로 변환해서 인스턴스에 전달한다. 보안강화를 위해 VLAN안에 모든 마이크로 인스턴스를 둔다. VLAN은 가상의 지역 네트워크로 외부와 격리되어 있어 외부 요청은 라우터로만 유입되는데 이 경우에는 라우터가 SSL을 종단하는 부하분산기가 된다. VLAN외부의 통신은 HTTPS지만 내부에서는 모두 HTTP를 사용한다. AWS는 HTTPS terminal 기능이 있는 부하분산기를 elastic load balancer ELB 형태로 형태로 제공하고 VLAN을 구현하기 위해 AWS보안 그룹이나 가상 사설 클라우드 를 사용한다. 아니면 모드 프록시와 같은 소프트웨어가 소프트웨어 부하 분산기의 역할을 할 수 있다. 

데이터베이스 확장

- 서비스의 가용성과 데이터의 내구성 : 둘의 개념은 분리하여 다른 해결책을 찾아야 한다. 대기 모델도 주 DB를 백업으로 바꾸거나 할 수 없다면 가용성을 얻을 수 없다. 

- 읽기용 확장 : 읽기만을 위한 복제도 있다.  

- 쓰기용 확장 : 샤딩 - 노드 

- 공유 데이터베이스 인프라스트럭처, CQRS

캐싱

성능 최적화의 방법으로 연산의 이전 결과를 저장하여 연속된 요청일 경우 재연산을 위한 시간과 자원 소비 없이 저장되 있는 값을 사용할 수 있게한다. 

- 클라이언트 측, 프록시, 그리고 서버측 캐싱 : 클라이언트 측 캐싱은 클라이언트가 캐싱된 결과를 저장하는 것으로 클라이언트가 새로운 복사본을 가져올 싲머과 여부를 결정한다. 이상적으로는 하위 서비스가 힌트를 제공하며 클라이언트는 그 응답을 통해 해야 할 것을 이해하고 새로운 요청의 시점과 여부를 알 수 있다. 프록시 캐싱은 클라이언트와 서비 사이에 프록시를 배치하는 것이다. 가장 좋은 예는 리버스 프록시나 콘텐츠 전송 네트워크를 사용할 경우다. 서버 측 캐싱은 서버가 캐싱의 책임을 지고 레디스나 멤캐시드 또는 단순한 인메모리 캐시 같은 시스템을 활용한다. 어떤걸 쓸지는 최적화 하려는 대상에 좌우된다. 1번은 네트워크 호출을 대폭 줄이고 서버의 하위 서비스에 대한 부하를 줄일 수 있는 가장 빠른 방법이며 2번은 클라이언트와 서버에 독립적이다. 프록시가 일반적인 트래픽을 캐시하도록 설계되었다면 하나 이상의 서비스도 캐싱할 수 있다. 흔한 예는 스퀴드나 바니시 처럼 모든 HTTP 트래픽을 캐시하는 리버스 프록시다. 3번은 클라이언트에 독립적이다. 서비스 경계 내부 또는 근처에 캐시를 배치하면 데이터의 무효화 또는 캐시 적중률 추적과 최적화 같은 것을 추적하기 쉽다. 

동적 서비스 레지스트리

- 칸슬 : 환경 구성 관리 + 서비스 발견. 서비스 발견을 위한 HTTP 인터페이스 제공. 실제 DNS 서버 기능 제공.

- 주키퍼, 유레카, 직접만들기 

문서화 서비스

- 스웨거 : API 문서 웹으로 

- HAL과 HAL브라우저, 자기 기술 시스템

인증과 권한부여

인증과 권한부여에 대한 일반적인 접근 방식 : 싱글사인온 (SSO) - SAML, OpenID Connect (권한주체 - 신원 제공자 - 서비스 제공자 )

싱글사인온 게이트웨이 : 서비스와 외부 사이에서 프록시 처럼 동작하는 게이트웨이를 사용할 수 있다. 

서비스 대 서비스 인증과 권한부여

HTTP(S) 기본 인증 

SAML, OpenID Connect 

클라이언트 인증서 :  클라이언트 인증서 형태의 전송 계층 보안(TLS) 기능 

HTTP 기반의 HMAC : 해시 기반 메시징 코드. HMAC에서 요청 메세지 바디는 비밀 키를 사용하여 해새되고, 결과는 요청과 함꼐 전송 된다. 

API 키 : API호출자를 인식하고 호출자의 능력에 제한을 둔다. 단순하고 직관적이다. 

보관 중인 데이터 보호 

독자적인 암호화 알고리즘을 구현하는 것이 아닌 잘 알려진 구현체를 선택하라. 

키 관리를 잘해야 하고 암호화 대상을 정해야 한다. 데이터의 요청이 있을 때 복호화 하고 백업 암호화를 해야한다. 

심층방어

방화벽 : 특정 포트에 대해 특정 종류의 트래픽 접근을 제한하는 것 

로깅 : 로그를 통해 정보가 누출되지 않도록 해야한다

침입 탐지 시스템(IDS), 네트워크 분리(망 분리), 운영 체제 

개인을 식별할 수 있는 정보를 가능한 한 많이 제거하여 최소한의 저장만을 사용하자

보안 탑재, 외부 검증

콘웨이의 법칙과 시스템 설계 

느슨한 조직과 강력히 결합된 조직

보통 더 느슨히 결합된 조직일수록 모듈화가 더 잘되어 있으며 결합도가 낮은 시스템을 만들어낸 반면 더 강력히 결함된 조직의 소프트웨어는 모듈화가 덜 되었다. 

의사소통 경로 적응

서비스 내부의 변경 속도가 서비스 간 변경 속도보다 훨씬 높아 지도록 서비스를 분해하는 것을 목표로 하는데 세분화된 의사소통 능력을 갖춘 단일 팀은 서비스 내부의 코드 통신 경로와 잘 부합된다.  서비스가 분해되어야 할 떄 시스템 개발에 연관된 사람들의 지리적인 경계가 필요하다.

서비스 소유권 

서비스를 소유한 팀이 해당 서비스의 변경을 책임지는 것을 말한다. 요구사항 발굴에서 부터 빌드, 배포, 유지보수에 이르는 모든 측ㅁ녀까지 확장 된다. 팀에 더 많은 권한과 자율성을 부여하지만 업무의 책임도 부여하면서 최선의 녁ㄹ정을 할 수 있는 사람이 결정하게 만든다. 

공유 서비스의 추진

제품 특징 팀은 작은 팀이 하나의 제품 특징의 모든 기능을 구현하면서 그 제품 특징 셋의 개발을 주도하는 것이다. 마이크로서비스에서 특정 서비스를 소유한 팀이 비지니스 도메인과 유사하게 정렬된다면 그 팀은 고객에게 집중할 가능성이 훨씬더 높고 제품 특징의 개발을 더잘 파악할 수 있다. 

콘웨이의 역법칙

조직이 어떻게 시스템 설계에 영향을 주는지가 아닌 반대로 시스템 설계가 조직을 변경하는 일화 소개

콘웨이의 역법칙은 시스템을 조직 구조와 다르게 설계할 때의 위험을 강조한다. 서비스의 소유권을 동일 위치의 팀과 나란히 정렬시킬 수 있도록 해주고 그 팀은 스스로 조직의 경계와 동일한 경계가 있는 콘텍스트 위주로 정렬 된다. 

마이크로서비스는 많은 혜택이 있지만 모니터링 부분에서는 이에 따른 더 복잡한 문제가 발생할 수 있다. 장애 발생시 우리는 서버와 로크파일, 네트워크 등 많은 부분을 체크해야 하는데 마이크로서비스에서는 이를 해결하기 위해 작은 것들을 모니터링하고 전체 상황을 볼 수 있도록 취합해야 한다. 시작은 가장 단순한 시스템인 단일 노트에서 부터다.

단일 서비스, 단일 서버

무엇을 관찰해야 할까? 먼저 호스트 자체를 모니터링 한다. CPU와 메모리의 정상 범위를 알고 해당 범위를 벗어날 때 경보를 보낼 수 있다. 자체 모니터링 소프트웨어나 호스팅 서비스를 이용할 수 있다. 두번째는 서버에 직접 접근하여 명령어로 에러 로그를 찾는다. 세번째로는 어플리케이션 자체의 최소한 응답시간을 모니터링 할 수 있다. 

단일 서비스, 다수 서버

하나의 호스트가 아닌 분리된 여러 호스트 상에 실행되는 서비스에도 마찬가지로 호스트 레벨의 측정이 필요하다. 개별 호스트 문제인지 전체 호스트 문제인지 세부 분석을 할 수 있어야 한다. 마찬가지로 서버에 로그를 확인해야 하는데 여러 호스트에 동일한 명령 실행이 가능한 ssh멀티플렉서를 이용하면 조금 더 간편하게 찾을 수 있다. 세번째 응답시간 추적은 부하 분산기에서 쉽게 추적할 수 있다. 그러나 부하 부난기 또한 추적의 대상이 되어야 한다

다수 서비스, 다수 서버

다수의 호스트에 분선되어 협업하는 다수의 서비스의 경우 로그부터 어플리케이션 측정 지표까지 가능한 한 많은 수집과 집중식 취합이 필요하다. 호스트의 수가 많아지면 SSH멀티플렉싱으로도 어렵다. 대신 로그를 수집하고 중앙에서 접근하기 위해 전문적인 서브시스템인 로그스태쉬를 사용할 수 있다. 많은 로그 파일 포맷을 파싱하고 추가 분석을 위해 하부 시스템에 전송할 수 있다. 

다수 서비스 간의 측정지표 추적

다수 서비스 간의 로그를 살펴보는 것은 어렵기 때문에 오랜 기간에 거쳐 명확한 패턴이 드러나도록 시스템의 행동 방식에 대한 측정 치표를 수집해야 한다. 전체 시스테메 대해 집계된 특정 측정지표 뿐만 아니라 특정 서비스에 대한 모든 인스턴스타 개발 인스턴스에 대한 측정지표까지도 집계할 수 있어야 하는데 이는 이러한 구조를 추론할 수 있도록 메타데이터와 측정지표를 연결할 수 있어야 한다는 것을 의미한다. 그래파이트라는 이러한 서비스를 제공해주는 시스템이 있다. 측정지표를 이해하는 다른 혜택은 용량 게획이다. 사용패턴을 이해햐아 필요한 인프라스트럭처를 보유해 효율성을 높힐 수 있다.

서비스 측정 지표

웹서비스는 최소한 응답시간과 에러율 같은 측정지표를 노출해야 한다. 더 나아가서는 소프트웨어의 기능이 얼마나 활용되고 있는지 알아야 어떻게 개선해야 할지 대응할 수 있도 어떤 데이터가 유용한지 까지 알 수 있다.

전파

시스템 간의 통합 지점을 모니터링 하는것이 중요하다. 각 서비스 인스턴스는 데이터베이스부터 협업하는 다른 서비스에 이르기까지 하위 의존성 상태를 추적하고 노출해야 한다. 이러한 정리된 현황을 알 수 있도록 수집된 정보들을 취합해야 한다. 

표준화

모니터링은 표준화가 중요하다. 많은 인터페이스를 이용하는 사용자에게 기능을 제공하기 위해 다양한 방식으로 협업하는 서비스들이 있다면 총체적인 방식으로 시스템을 바라볼 수 있어야 한다. 

서비스 

- 최소한의 필수 사항으로 응답시간을 추적하고 에러유을 추적하라 그리고 어플리케이션레빌 측정치표에 대해 작업해라.

- 모든 하위 응답 상태 추적. 최소한 하위 호출의 응답시간을 포함하고 에러율도 추적

- 측정지표가 수집될 방식과 저장소를 표준화

- 가능하면 표준 저장소와 포맷으로 로깅하라

- 불량 프로세스를 추적하고 용량 계획을 수행할 수 있도록 하부 운영 체제를 모니터링 하라

시스템

- 어플리케이션 레벨 측정 지표와 cpu처럼 호스트 레블 칙정지표도 취합해라

- 측정지표 저자소 도국가 스스템 또는 서비스 레벨로 집계할 수 있는지 확인하고 개별 호스트 레벨까지 탐색해서 보여줘라

- 시스템의 추이를 이해할 정도로 오랜 기간 데이터를 유지할 수 있는지 확인

- 로그를 취합하고 저장하는데 질의 가능한 단 하나의 도구를 ㅏ용하라

- 상관관계 ID를 사용하는 데 있어 표준화를 고려하라

- 대응 행동 요청이 필요한 것이 무엇인지 이해하고 주의 경보와 대시보드를 적절히 구조화 하라

- 수로나 리만 같은 도구가 적합한지 검토하고 모든 다양한 측정지표를 취합하는 방식을 통합할 수 있는지 조사해라

마이크로서비스에 테스트 자동화를 적용하는 것에 대해 알아보자. 수행 가능한 테스트의 종류를 이해하는 것이 중요하다 

테스트의 종류

기술중심(개발자) - 단위 테스트, 성능 테스트

비지니스중심 - 인수 테스트, 탐색 테스트 

각 테스트를 얼마나 많이 수행할 것인지는 시스템의 특성에 달려 있지만. 핵심은 시스템을 테스트하는 방법의 측면에서 여러 선택을 해야 한다는 것.

테스트의 범위 

단위테스트 : 단일 함수 또는 메서드 (기능의 정상 동작 유무에 대한 빠른 피드백) 

서비스테스트 : UI를 우회해서 서비스들을 직접 테스트

엔드 투 엔드 테스트 : 시스템 전체 (이 부분이 마이크로서비스 환경에서 까다롭다) 

서비스 테스트

단위테스트와 다르게 서비스 테스트는 테스트하려는 서비스와 다른 서비스를 격리 시키는게 관건이다. 이를 위해 다른 협업자를 모두 스텁화 한다. 서비스테스트집합은 하위 협업자를 위한 스텁 서비스를 실행시켜야 하고 스텁 서비스들과 연결되는 환경에 고객 서비스를 구성한 다음 실 환경 서비스를 모방해 응답을 보내도록 스텁을 구성해야 한다. 

엔드 투 엔드 테스트

엔트 투 엔트 테스트를 구현하기 위해선 다수의 서비스를 함께 배포해야 하고, 그 후 모든 서비스에 대한 테스트를 수행해야 한다. 따라서 더 넓은 범위를 다루긴 하지만 더 느리며 실패를 분석하기 어렵다.

- 변경되는 범위가 증가함에 따라 신뢰할 수 없는 케이스가 늘어난다. 

- 다수의 팀이 연계되어 있을 확률이 높기 떄문에 누가 주도해야 할지에 대한 문제가 생긴다.

- 시간 소요가 상당하다. 피드백 주기가 길어 적체가 일어난다.

최선의 방법은 전체 시스템을 테스트 하는 소수의 핵심 여정에 집중하는 것.

소비자 주도 테스트

- 

출시 후 테스팅

배포 전 테스팅을 통해서는 장애의 가능성을 완전히 없앨 수는 없다

- 배포를 릴리즈와 분리하기 : 스모크 테스트, 청색/녹색 배포 

- 카날리아 릴리즈

교차기능 테스트 

- 비 기능적 요구사항 : 일반적인 기능과 같이 단순히 구현될 수 없는 시스템의 특징을

성능 테스트

단