Cloud SW 아키텍처 패턴:Deployment and Production Testing Patterns

• Cloud SW 아키텍처 패턴:Deployment and Production Testing Patterns
  • Deployment and Production Testing Patterns
  • Rolling
  • Blue-Green
  • Canary A/B
  • Chaos Engineering Pattern
    • Chaos Engineering - Motivation
  • 학습 회고
    • 1.시스템 레벨의 이해에 도움이 많이 되는 강의 였다.
    • 2.메시지 브로커 (카프카)가 정말 다양한 패턴에 쓰인다.
    • 3.경험의 중요성을 알게되었다.
    • 4.FE개발에도 큰 도움이 된다.

Deployment and Production Testing Patterns

5.배포 및 프로덕션 테스트 아키텍처 패턴 - Deployment and Production Testing Patterns

배포에 관련된 사항은 k8s 에서 더 자세하게 다루는게 좋을 것 같다.

• k8s 컴포넌트 개념과 함께 여러 배포 전략들을 이어서 학습.

Rolling

• Rolling Deployment benefits:

  • No downtime
  • No additional cost for hardware
  • We can rollback quickly if something goes wrong

• Downsides:

  • Potential for Cascading Failures
  • 2 versions in production at the same time

Blue-Green

Canary A/B

Both Canary Release and A/B Deployment Patterns allow us

• to dedicate a small portion of servers for a different version of software

During a Canary Release:

• We monitor for:
  • Performance
  • Functionality
• Limit to internal users or beta testers

Chaos Engineering Pattern

Chaos Engineering - Motivation

• We won't know about those issues until they actually happen • When they do happen it may be too late
• Those issues are very rare
• The results of those issue can be catastrophic
• Solution of Chaos Engineering : Embracing the inherent chaos in a cloud-based Distributed System

Chaos Monkey (2011) by Netflix
• Responsible for randomly terminating cloud servers in production

• Chaos Engineering Pattern:

  • Increases confidence
  • Protects production against critical failures

• Allows finding:

  • Single Points of Failure
  • Scalability issues
  • Performance bottlenecks

• Ensures that real failures are dealt with gracefully

학습 회고

1.시스템 레벨의 이해에 도움이 많이 되는 강의 였다.

사내 시스템에 다양한 아키텍처들이 존재한다.
시스템 아키텍처들을 보면 매번 새롭고 좋아보였다.

아키텍처 패턴을 이해하고 보니, 사실상 모든 시스템들이 Best Practice는 아닌 경우가 보인다.

오버엔지니어링을 한 경우, 일정에 쫒겨서 더 좋은 구조로 갈 수 있으나 타협한 경우 등등

• 이벤트 아키텍처로, 메시지 브로커를 도입할 만큼 중요한 기능임에도
• Time Based Sync로 컴포넌트간 데이터 동기화 플로우로 채워가는 경우도 있었다.
• 그러면 비록 짧은 시간일지라도 '일관성'이 깨질 수 있다.

예를 들어 YouTube처럼 광고 영상을 올리는 기능이다.

• 광고 정책에 이슈가 있는 콘텐츠는 사전에 체크해야 한다.
• 하지만 우선 광고 영상이 공개되고, 그 이후 Audit 하는 로직이 돌아간다.
• 최대 30분정도 잠재적 위험이 있는 광고 영상이 공개되는 것이다.

사내 시스템에 대해서 스터디를 하자.!

2.메시지 브로커 (카프카)가 정말 다양한 패턴에 쓰인다.

• 로드밸런싱, 코레오그래피, CQRS 패턴 등
• 시스템에서 비동기라는 작업은 정말 많고, 그래서 카프카가 중요하구나.

카프카에 대해서 얇팍하게 알아보자.!

3.경험의 중요성을 알게되었다.

사실상 지금까지 배운 아키텍처 패턴은 이론에 불과하다.

• 실제 비즈니스 로직을 담고 돈으로 벌어봐야 그 복장성과 현실 타협점들을 알게 된다.
• 기본 베이스 지식들을 알고, 현실에서 마주할 수 있는 수많은 에러들을 핸들링 하며
• 큰 규모의 시스템을 성공적으로 이끄는 경험이 소중할 것 같다.
• 개발씬 은퇴까지 2~3개의 대규모 시스템을 구축해보는 것도 어려울 수 있다는 생각.
• 초기 스타트업, 신사업부 같은 경우라면 기회가 더 많을지도?

사이드프로젝트 혹은 기회가 되면 시스템 설계를 하자.!

4.FE개발에도 큰 도움이 된다.

아키텍처 패턴 강의를 들으면서 FE개발 관련된 부분은 하나의 파트밖에 없었다.

• BFF 패턴밖에서 없어서 아쉬웠다.
• 마이크로 프론트 엔드 등 아키텍처를 고려할 부분들이 있긴 하다.
• 그럼에도 FE지식과 지금까지 배운 패턴들을 조합해서 시스템을 구축해볼 수 있을 것 같다.

예) Static Site Generator + CQRS Pattern.

SSR 기능이 탑재된 Next.js, Nuxt.js 에는 정적사이트를 생성할 수 있는 기능들이 있다.
사용자들의 포스팅, 뉴스기사 등을 발행을 한다.
사용자들이 만들어둔 콘텐츠를 바탕으로 미리미리 정적사이트들을 생성해야 한다.
여러 가지 방법이 있다.

• 주기적으로 정적사이트를 만드는 방법
• 사용자의 요청이 들어올 때 정적사이트를 만들어 주고 캐싱하는 방법
• CQRS 패턴을 이용하면, 사용자가 콘텐츠를 업데이트 할 때 이를 구독하고 정적사이트를 만들어볼 수 있다. !

FE에 적용시키면 좋을 시스템 설계를 공부하자.!