[90DaysOfDevOps] Day 84~89 - Engineering for Day 2 Ops

Main reference

• https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2023/

90DaysOfDevOps/2023/day84.md at main · MichaelCade/90DaysOfDevOps

 
 

Day 84

< API > 

 
What is API?
 
 = Application Programming Interface

• 프로그래밍 방식으로 애플리케이션을 제어하는 방법
• 웹사이트를 사용하면 데이터를 가져오거나, 애플리케이션에 데이터를 보내기 위해 인터페이스에서 수행하는 작업이 있음
• 사용자 인터페이스에서 실행되는 코드에 의해 백엔드에서 프로그래밍 방식이 수행됨. 

 
- 서비스간 통신을 위한 HTTP 기반 API 사용 방식
 
Design:
양방향으로 통신하는 2개의 프로그램, 매분마다 하나의 응용 프로그램이 다른 응용 프로그램에 임의의 문자열을 요청합니다.
문자열을 받으면 나중에 사용할 수 있도록 이 번호를 데이터베이스에 저장합니다.

Random Number generator:
요청 시 임의의 문자열을 생성하고 이를 데이터베이스에 저장합니다.
그런 다음 응용 프로그램은 첫 번째 프로그램에 문자열을 수신했는지 확인하도록 요청하고 이 정보를 데이터베이스의 문자열에 대해 저장합니다.
애플리케이션은 Generator requestor라고 부릅니다. 

이를 통해 프로덕션 환경에서 실행되는 서비스의 구축, 배포, 모니터링 및 소유와 관련된 다양한 작업을 빠르게 살펴볼 수 있습니다.
각 애플리케이션이 성공적으로 완료되려면 다른 애플리케이션이 필요하고 API 호출 속도와 같이 모니터링할 수 있는 항목이 있으므로 양방향 실패 모드가 있습니다.
-> 한 애플리케이션의 실행이 중지되는지 확인할 수 있습니다.

API 인터페이스의 모양을 결정해야 합니다.
여기서 통신하는 데 사용되는 2개의 API 호출이 있습니다.

• 첫째, requestor가 generator 호출해서 문자열을 요청합니다.
  • 이는 문자열을 요청하는 것 외에 추가 콘텐츠가 없는 API 호출이 될 가능성이 높습니다.
• 둘째, generator는 requestor에게 문자열을 수신하고 저장했다는 확인을 요청하기 시작합니다 .
  • 이 경우 우리가 알고 싶은 문자열이 될 매개변수를 requestor에 전달해야 합니다.

 
generator는 /new의 URL 경로를 사용하여 랜덤 문자열을 제공합니다.
requestor는 상태를 확인하기 위해 URL 경로를 사용하여 generator에서 문자열 정보를 수신하므로, string of interest이 어디에 있는지 generator에 대한 /strings/<STRING> URL을 설정합니다.

/strings/<STRING> 같은 엔드포인트로 API 접근한다~

 

Day 85

< Queue > 

https://dashbird.io/knowledge-base/well-architected/queue-and-asynchronous-processing/

Asynchronous Processing & Queue | Knowledge Base | Dashbird

 
 

 
 
Queue - 비동기식 접근 방식을 사용하는 사고 방식의 전환입니다. 
이는 애플리케이션 간에 응답이 즉각적일 필요가 없을 때 잘 작동할 수 있습니다. 
애플리케이션 간 요청에 약간의 지연을 추가해도 문제가 되지 않습니다.
 
위 그림에서 애플리케이션 사이에 큐를 추가하는 방법과 큐가 브리지를 통해 메시지의 의도를 저장하는 방법을 볼 수 있습니다. 
 
Consumer가 실패하고 메시지 반응을 중지하는 경우, Queue 소프트웨어에 충분한 저장 공간이 있으면, Producer에 관한 한 Consumer에게 보내는 메시지는 여전히 "성공"할 것입니다.

이는 시스템의 구성 요소를 서로 격리하고 폭발 실패 반경을 제한하는 강력한 패턴입니다. 
그러나 복잡성이 추가됩니다. Consumer와 Producer는 메시지의 형태에 대한 공통된 이해를 공유해야 합니다. 
그렇지 않으면 Consumer가 메시지에 따라 조치를 취할 수 없습니다.

데이터 흐름에서 두 애플리케이션 사이에 대기열을 구현할 예정입니다.
섹션이 끝나면 다음과 같은 데이터 흐름이 생깁니다.

Requestor (임의의 문자열을 요청) → Queue → Generator (메시지를 가져와서 문자열을 생성하고 이를 다른 큐의 Requestor에게 다시 전달) → Requestor (문자열을 다시 큐에 가져와 저장한 다음 큐에게 수신했다는 메시지를 전송) → Queue → Generator (메시지가 수신되었음을 표시)

마지막 섹션에는 Generator가 요청자가 메시지를 받았는지 확인해야 합니다.
여기서는 실제 프로세스를 단순화한 것으로, 애플리케이션이 강화된 데이터 레코드나 일부 추가 정보를 다시 전달할 수 있지만 간단한 양방향 통신을 수행할 수 있습니다.

 

NATSio  - queue technology

 

Day 86

< Designing for Resilience, Redundancy and Reliability >

 
; CSP에서 안정적인 제공을 위한 복원/중복/안정 추구 방법
 
Failure Zones

• 애플리케이션을 구축하고 모든 것을 단일 VM 또는 서버에 배포한다면 이 서버에 장애가 발생하면 어떻게 되나요?
• 애플리케이션이 오프라인 상태가 되면 고객은 만족하지 못할 것입니다!
• 이에 대한 해결책: 여러 장애 지점에 걸쳐 워크로드를 분산하기
• 애플리케이션 인스턴스에만 적용되는 것이 아니라 시스템의 모든 측면에 대해 여러 개의 중복 지점을 구축할 수 있습니다.

cloud provider는 여러 AZ를 제공 → increase our redundancy and resilience over factors such as a fire in one of these facilities

 
Replication

• 많은 데이터 스토리지 도구에는 여러 오류 영역에 걸쳐 복제하도록 구성할 수 있는 기능이 함께 제공됩니다.
• 이전에 사용한 NATS.io는 하나 이상의 영역에서 장애가 발생하더라도 여러 인스턴스에 걸쳐 메시지를 복제하도록 구성할 수 있습니다. Postgresql 데이터베이스는 모든 트랜잭션의 순서대로 기록을 저장하는 WAL(Write Ahead Log)을 다른 곳에서 실행되는 대기 인스턴스로 스트리밍하도록 구성할 수 있습니다.
• 기본 오류가 발생하면 가장 큰 손실은 복제본으로 전송되지 않은 WAL의 데이터 양입니다. 복제가 없는 경우보다 데이터 손실이 훨씬 적습니다.

 
Contract Testing

• 시스템에 오류가 발생할 가능성이 가장 높은 시간은 배포 중이라는 사실
• 새로운 코드가 우리 시스템에 들어오고 프로덕션 환경에서 철저하게 테스트되지 않은 경우 정의되지 않은 동작이 발생할 수 있습니다.
• 개발 및 빌드 시 애플리케이션 간의 인터페이스를 테스트할 수 있는 계약 테스트라는 개념이 있다.
• 이를 통해 진행 상황에 대한 피드백(DevOps의 핵심 원칙)을 빠르게 얻을 수 있습니다.

개발 및 빌드 시 애플리케이션 간의 인터페이스를 테스트

 
 
Async programming and queues

• 시스템 없이 종속성을 깨면 안정성이 향상됨
• 변경 사항이 작아지고 애플리케이션의 다른 영역에 영향을 미칠 가능성이 줄어들며 롤백도 쉬워진다~

 
Logging and Tracing 

• 추적은 시스템의 요청에 대한 고유 식별자를 공격한 다음 해당 요청 여정 전반에 걸쳐 채워지고 기록될 수 있다는 개념
• HTTP 요청이 LoadBalancer에 도달하는 것을 볼 수 있고 상관 ID를 얻은 다음 해당 상관 ID를 확인하려고 합니다.
• 요청 작업이 시스템을 통해 침투함에 따라 로그 라인에 기록됩니다.

Log Level(TRACE, DEBUG, INFO, WARN, ERROR) 고려해서 너무 많이 남기지 말기 

 

Day 87

무중단배포 = 클라이언트 입장에서 서비스가 끊어지지 않으면서(Zero-downtime) 새로운 버전을 업데이트
Downtime = 시스템, 네트워크, 애플리케이션 또는 서비스가 예정되지 않은 방식으로 작동을 멈추거나 접근할 수 없게 되는 시간

- Rolling Deployments
하나씩 배포 버전을 차례로 바꿈
ex. 1번 서버 다운 + 버전업 → 버전업 끝나면 2번 서버 다운 + 버전업
쿠버네티스의 배포 방식

- Surge Deployments
start a large number of new tasks before cutting over traffic to those tasks and then draining traffic from our old tasks.
→ Rolling이 Surge 차용함

- Blue/Green
새로운 그린을 구성해서 가동 테스트 후 로드밸런서가 블루 → 그린으로 트래픽을 변경

- Canary
Rolling Deployment + Blue/Green Deployment +새로운 버전에 대한 오류를 조기에 감지 (A/B테스트)
블루/그린 구성 → 조금씩 블루→그린으로 트래픽 변경 → 성능/오류 모니터링하며 배포를 지속할지 결정

 
 
1. 롤링 배포: 기존 배포를 천천히 새로운 작업으로 교체하면서 안정성을 유지하고, 작은 일부 작업만 변경됩니다. Kubernetes의 기본 배포 전략이며 가용성을 높이면서 업데이트를 수행할 수 있습니다.

2. 급증 배포: 새로운 작업을 빠르게 많이 시작하여 트래픽을 분산하고, 이전 작업에서 트래픽을 제거하기 전에 새로운 작업이 안정화될 때까지 기다립니다. 대용량 트래픽을 다루는 애플리케이션에 적합합니다.

3. 블루/그린 배포: 새로운 스택(또는 애플리케이션)을 가동하여 테스트한 후에만 전체 트래픽을 전환합니다. 롤백 및 복구에 빠르게 대응할 수 있는 경우에 사용됩니다.

4. 카나리아 배포: 소수의 새로운 애플리케이션을 배포하고 트래픽의 작은 부분을 새 서비스로 전송하여 안정성을 확인한 후 전체 배포를 진행합니다. 문제가 발생하면 자동으로 롤백할 수 있습니다.

애플리케이션 수명주기의 다양한 단계에서 사용될 수 있으며, 각각의 상황에 따라 적합한 전략을 선택해야 한다~
애플리케이션의 안정성과 가용성을 최대화하면서 업데이트를 수행할 수 있는 최적의 방법을 고려하는 것이 중요
 
 

Day 88

< 시스템 관리자 또는 운영팀이 장애 상황에서 대응하기 위한 도구와 프로세스 >

1. 대기실 업무: 시스템이 "대기 중"에 있을 때는 장애 대응과 문제 해결에 책임이 있습니다. 이는 경고 및 모니터링 시스템을 통해 감지되며, 적절한 조치를 취하여 시스템의 안정성을 유지합니다.

2. 경고: 경고는 시스템의 상태 또는 성능에 대한 알림을 제공합니다. 이는 오류, 시간 초과, 트래픽 급증 등의 이벤트에 의해 트리거될 수 있으며, 문제를 신속하게 감지하고 대응할 수 있도록 도와줍니다. 그러나 너무 많은 허위 경보를 방지하기 위해 경고 설정을 신중하게 관리해야 합니다.

3. 통화 비용: 시스템에 대한 대응 시간은 시스템의 특성에 따라 다를 수 있습니다. 일부 시스템은 대기 중에 문제를 처리하는 데 여유가 있지만, 다른 시스템은 즉각적인 대응이 필요할 수 있습니다. 이에 대비하여 대기 중인 사람들이 빠르게 대응할 수 있도록 프로세스를 마련해야 합니다.

시스템 관리에 있어서는 대기 및 사고 대응에 대한 적절한 도구와 프로세스가 필수다~
 
 

Day 89

< 실수와 문제 대응에 대한 조직 문화 >

 
1. 비난 없는 문화: 실수는 불가피한 것이며, 이를 통해 발전할 수 있는 문화를 구축해야 합니다. 비난 없는 문화는 팀원들이 실험하고 변화하며 자유롭게 의견을 나눌 수 있는 환경을 제공합니다.

2. 심리적 안전: 심리적으로 안전한 직장 환경은 팀원들이 자유롭게 의견을 나누고 실패를 공유할 수 있는 환경을 의미합니다. 이를 통해 팀의 협력과 문제 해결 능력이 향상될 수 있습니다.

3. Post mortems: 문제가 발생한 후에는 팀이 함께 앉아서 원인을 파악하고 해결책을 모색하는 것이 중요합니다. 이는 비슷한 문제의 재발을 예방하고 조직의 성장을 위해 필요한 절차입니다.

조직은 실수를 인정하고 발전하는 문화를 구축해야 한다~
비난 없는 환경과 심리적 안전을 통해 팀은 문제를 공유하고 협력하여 해결할 수 있다~
사고 후에는 원인 분석과 개선을 위한 솔직하고 개방적인 대화가 필요하다~~