🥇소프트웨어 아키텍처 및 시스템 설계: 큰 그림 및 리소스 가이드

동료 여러분 안녕하세요.

오늘 우리는 현대 소프트웨어 시스템 설계 원칙을 상대적으로 적은 양으로 설명하는 Tugberk Ugurlu의 기사 번역을 제공합니다. 저자가 자신에 대해 요약하면 다음과 같습니다.

2019년 현재 건축 패턴+디자인 패턴이라는 거대한 주제를 하브로 기사에 다 담는 것은 절대 불가능하기 때문에, 우루글루 씨의 글 자체는 물론, 그 안에 친절하게 담아주신 수많은 링크도 추천해 드립니다. 마음에 드시면 분산 시스템 설계에 관해 더욱 전문적인 텍스트를 출판해 드리겠습니다.

스냅 샷 아이작 스미스 Unsplash에서

처음부터 소프트웨어 시스템을 설계하는 등의 과제에 직면한 적이 없다면 그러한 작업을 시작할 때 어디서부터 시작해야 할지조차 명확하지 않을 때가 있습니다. 나는 정확히 무엇을 디자인할 것인지에 대해 어느 정도 확신을 가질 수 있도록 먼저 경계를 그은 다음 소매를 걷어붙이고 그 경계 내에서 작업해야 한다고 믿습니다. 시작점으로 제품이나 서비스(이상적으로는 자신이 정말 좋아하는 것)를 선택하고 이를 구현하는 방법을 알아낼 수 있습니다. 이 제품이 얼마나 단순해 보이는지, 그리고 실제로는 얼마나 많은 복잡성이 포함되어 있는지 놀라실 것입니다. 잊지 마요: 단순 - 일반적으로 복잡, 괜찮아요.

시스템 설계를 시작하는 모든 사람에게 제가 드릴 수 있는 최고의 조언은 다음과 같습니다. 어떠한 가정도 하지 마십시오! 처음부터 이 시스템에 대해 알려진 사실과 이와 관련된 기대치를 지정해야 합니다. 디자인을 시작하는 데 도움이 되는 몇 가지 좋은 질문은 다음과 같습니다.

우리가 해결하려는 문제는 무엇입니까?
우리 시스템과 상호 작용할 최대 사용자 수는 몇 명입니까?
데이터 쓰기 및 읽기에 어떤 패턴을 사용할 것인가?
예상되는 실패 사례는 무엇이며, 이를 어떻게 처리할 것인가?
시스템 일관성과 가용성에 대한 기대치는 무엇입니까?
업무를 수행할 때 외부 검증 및 규제와 관련된 요구 사항을 고려해야 합니까?
어떤 유형의 민감한 데이터를 저장할 예정인가요?

이것은 나와 내가 수년간 전문적인 활동에 참여한 팀 모두에게 유용했던 몇 가지 질문입니다. 이러한 질문(및 작업해야 하는 상황과 관련된 다른 질문)에 대한 답을 알고 있다면 점차적으로 문제의 기술적 세부 사항을 조사할 수 있습니다.

초기 레벨 설정

여기서 "기준선"이란 무엇을 의미합니까? 실제로 우리 시대에는 소프트웨어 산업의 대부분의 문제가 기존 방법과 기술을 사용하여 "해결"될 수 있습니다. 따라서 이 환경을 탐색함으로써 다른 사람이 당신보다 먼저 해결해야 했던 문제에 직면했을 때 당신은 어느 정도 유리한 출발을 할 수 있습니다. 프로그램은 비즈니스와 사용자의 문제를 해결하기 위해 작성되었다는 점을 잊지 마십시오. 따라서 우리는 (사용자의 관점에서) 가장 간단하고 간단한 방법으로 문제를 해결하려고 노력합니다. 이것을 기억하는 것이 왜 중요합니까? 아마도 좌표계에서 모든 문제에 대한 고유한 솔루션을 찾고 싶을 수도 있습니다. "내가 모든 곳에서 패턴을 따른다면 나는 어떤 종류의 프로그래머인가?"라고 생각하기 때문입니다. 사실은, 여기서 예술은 어디서 무엇을 해야할지 결정하는 것입니다.. 물론, 우리 각자는 때때로 고유한 문제를 다루어야 하며, 이는 각각의 문제가 정말 어려운 일입니다. 그러나 초기 수준이 명확하게 정의되면 우리 앞에 놓인 문제를 해결하기 위해 기성 옵션을 찾거나 문제를 더 연구하고 더 깊이 이해하는 등 무엇에 에너지를 소비해야 하는지 알 수 있습니다.

전문가가 훌륭한 소프트웨어 시스템의 아키텍처 구성 요소가 무엇인지 자신있게 이해한다면 이 지식은 아키텍처 기술을 숙달하고 이 분야에서 탄탄한 기반을 개발하는 데 필수적일 것이라고 확신할 수 있었다고 생각합니다.

좋아요, 그럼 어디서부터 시작할까요? 유 도나 마르티나 GitHub에는 다음과 같은 저장소가 있습니다. 시스템 설계 입문서에서 대규모 시스템을 설계하는 방법을 배우고 이 주제에 대한 인터뷰를 준비할 수 있습니다. 저장소에는 예제가 포함된 섹션이 있습니다. 실제 아키텍처, 특히 시스템 설계에 접근하는 방법이 고려됩니다. 일부 잘 알려진 회사예: 트위터, 우버 등

하지만 이 자료로 넘어가기 전에 우리가 실제로 직면하는 가장 중요한 아키텍처 문제를 자세히 살펴보겠습니다. 이는 완고하고 다면적인 문제의 많은 측면을 지정하고 주어진 시스템에서 시행되는 규정의 틀 내에서 문제를 해결해야 하기 때문에 중요합니다. 잭슨 개버드전 페이스북 직원이었던 는 다음과 같이 썼습니다. 시스템 설계 인터뷰에 관한 50분짜리 비디오, 그는 수백 명의 지원자를 심사한 자신의 경험을 공유했습니다. 비디오는 대규모 시스템 설계와 해당 직위에 대한 후보자를 찾을 때 중요한 성공 기준에 중점을 두고 있지만 시스템을 설계할 때 가장 중요한 것이 무엇인지에 대한 포괄적인 리소스 역할을 합니다. 나는 또한 제안한다 요약 이 비디오.

데이터 저장 및 검색에 대한 지식 구축

일반적으로 장기적으로 데이터를 저장하고 검색하는 방법에 대한 결정은 시스템 성능에 중요한 영향을 미칩니다. 따라서 먼저 시스템의 예상되는 쓰기 및 읽기 특성을 이해해야 합니다. 그런 다음 이러한 지표를 평가하고 평가에 따라 선택할 수 있어야 합니다. 하지만 기존 데이터 저장 패턴을 이해해야만 이 작업에 효과적으로 대처할 수 있습니다. 원칙적으로 이는 다음과 관련된 확실한 지식을 의미합니다. 데이터베이스 선택.

데이터베이스는 확장성과 내구성이 매우 뛰어난 데이터 구조로 생각할 수 있습니다. 따라서 특정 데이터베이스를 선택할 때 데이터 구조에 대한 지식은 매우 유용합니다. 예를 들어, Redis 다양한 유형의 값을 지원하는 데이터 구조 서버입니다. 이를 통해 목록 및 집합과 같은 데이터 구조로 작업하고 잘 알려진 알고리즘을 사용하여 데이터를 읽을 수 있습니다. LRU, 내구성이 뛰어나고 접근성이 높은 스타일로 이러한 작업을 구성합니다.

스냅 샷 사무엘 젤러 Unsplash에서

다양한 데이터 저장 패턴을 충분히 이해한 후에는 데이터 일관성 및 가용성 연구로 넘어갑니다. 우선 이해를 하셔야 합니다 CAP 정리 적어도 일반적인 용어로는 확립된 패턴을 자세히 살펴봄으로써 이 지식을 다듬습니다. 일관성 и 유효성. 이렇게 하면 해당 분야에 대한 이해가 깊어지고 데이터 읽기와 쓰기가 실제로 두 가지 매우 다른 문제이며 각각 고유한 과제가 있다는 것을 이해하게 됩니다. 몇 가지 일관성 및 가용성 패턴으로 무장하면 시스템 성능을 크게 향상시키는 동시에 애플리케이션에 대한 원활한 데이터 흐름을 보장할 수 있습니다.

마지막으로 데이터 저장 문제에 대한 대화를 마무리하면서 캐싱에 대해서도 언급해야 합니다. 클라이언트와 서버에서 동시에 실행해야 합니까? 캐시에는 어떤 데이터가 저장되나요? 그리고 왜? 캐시 무효화를 어떻게 구성합니까? 일정한 간격으로 정기적으로 수행됩니까? 그렇다면, 얼마나 자주? 나는이 주제를 공부하기 시작하는 것이 좋습니다 다음 섹션 앞서 언급한 시스템 설계 입문서.

의사소통 패턴

시스템은 다양한 구성 요소로 구성됩니다. 이는 동일한 물리적 노드 내에서 실행되는 다른 프로세스이거나 네트워크의 다른 부분에서 실행되는 다른 시스템일 수 있습니다. 네트워크 내의 이러한 리소스 중 일부는 비공개일 수 있지만 다른 리소스는 공개되어야 하며 외부에서 액세스하는 소비자에게 공개되어야 합니다.

이러한 리소스 간의 통신은 물론 전체 시스템과 외부 세계 간의 정보 교환도 보장해야 합니다. 시스템 설계의 맥락에서 우리는 다시 한 번 새롭고 독특한 과제에 직면하게 됩니다. 어떻게 유용할 수 있는지 살펴보겠습니다. 비동기 작업 흐름, 그리고 무슨 p다양한 의사소통 패턴을 사용할 수 있습니다..

스냅 샷 토니 스토다드 Unsplash에서

외부 세계와의 의사소통을 조직할 때 항상 매우 중요합니다. 보안, 이에 대한 조항도 진지하게 받아들이고 적극적으로 추진해야 합니다.

연결 배포

이 주제를 별도의 섹션으로 나누는 것이 모든 사람에게 타당해 보일지 확신할 수 없습니다. 그럼에도 불구하고 나는 이 개념을 여기서 자세히 제시할 것이며, 이 섹션의 내용은 "연결 분포"라는 용어가 가장 정확하게 설명된다고 생각합니다.

시스템은 많은 구성 요소를 적절하게 연결하여 구성되며, 이들 간의 통신은 TCP, UDP 등 확립된 프로토콜을 기반으로 구성되는 경우가 많습니다. 그러나 이러한 프로토콜은 종종 고부하에서 작동하고 사용자 요구에 크게 의존하는 현대 시스템의 모든 요구를 충족시키기에는 충분하지 않습니다. 시스템의 높은 부하에 대처하기 위해 연결을 분산시키는 방법을 찾아야 하는 경우가 많습니다.

이 분포는 잘 알려진 것을 기반으로 합니다. 도메인 명 시스템 (DNS). 이러한 시스템에서는 가중치가 부여된 라운드 로빈 및 대기 시간 기반 방법과 같은 도메인 이름 변환을 통해 로드를 분산하는 데 도움이 됩니다.

부하 분산 근본적으로 중요하며 오늘날 우리가 다루는 거의 모든 대규모 인터넷 시스템은 하나 이상의 로드 밸런서 뒤에 있습니다. 로드 밸런서는 사용 가능한 여러 인스턴스에 클라이언트 요청을 분산시키는 데 도움이 됩니다. 로드 밸런서는 하드웨어와 소프트웨어 모두로 제공되지만 실제로는 소프트웨어를 처리해야 하는 경우가 더 많습니다. HAProxy и ELB. 역방향 프록시 첫 번째와 두 번째 사이에는 범위가 있지만 개념적으로는 로드 밸런서와 매우 유사합니다. 뚜렷한 차이점. 요구 사항에 따라 시스템을 설계할 때 이러한 차이점을 고려해야 합니다.

당신은 또한 알아야합니다 콘텐츠 전달 네트워크 (CDN). CDN은 지리적으로 특정 사용자에게 더 가까운 노드에서 정보를 전달하는 프록시 서버의 글로벌 분산 네트워크입니다. JavaScript, CSS 및 HTML로 작성된 정적 파일로 작업하는 경우 CDN을 사용하는 것이 좋습니다. 또한 트래픽 관리자를 제공하는 클라우드 서비스는 오늘날 일반적입니다. 예를 들면 다음과 같습니다. Azure 트래픽 관리자, 동적 콘텐츠 작업 시 글로벌 배포 및 대기 시간 단축을 제공합니다. 그러나 이러한 서비스는 일반적으로 상태 비저장 웹 서비스로 작업해야 하는 경우에 유용합니다.

비즈니스 로직에 대해 이야기해 봅시다. 비즈니스 로직, 작업 흐름 및 구성 요소 구조화

그래서 우리는 시스템의 다양한 인프라 측면을 논의했습니다. 아마도 사용자는 시스템의 이러한 모든 요소에 대해 생각조차 하지 않으며 솔직히 전혀 신경 쓰지 않을 것입니다. 사용자는 시스템과 상호 작용하는 것이 어떤 것인지, 이를 통해 무엇을 얻을 수 있는지, 시스템이 사용자 명령을 실행하는 방법, 사용자 데이터로 무엇을 어떻게 수행하는지에 관심이 있습니다.

이 글의 제목에서 알 수 있듯이 저는 소프트웨어 아키텍처와 시스템 디자인에 관해 이야기하려고 했습니다. 따라서 소프트웨어 구성 요소가 생성되는 방식을 설명하는 소프트웨어 디자인 패턴을 다룰 계획은 없었습니다. 그러나 생각하면 할수록 소프트웨어 디자인 패턴과 아키텍처 패턴 사이의 경계가 매우 모호하고 두 개념이 밀접하게 연관되어 있다는 생각이 듭니다. 예를 들어보자 이벤트 등록 (이벤트 소싱). 이 아키텍처 패턴을 채택하면 시스템의 거의 모든 측면(데이터의 장기 저장, 시스템에 채택된 일관성 수준, 시스템 구성 요소의 모양 등)에 영향을 미칩니다. 따라서 나는 비즈니스 로직과 직접적으로 관련된 몇 가지 아키텍처 패턴을 언급하기로 결정했습니다. 이 기사는 간단한 목록으로 제한되어야 하지만 이 기사를 숙지하고 이러한 패턴과 관련된 아이디어에 대해 생각해 보시기 바랍니다. 여기 있어요:

협업적 접근 방식

당신이 프로젝트에서 시스템 설계 과정을 전적으로 책임지는 참가자로 참여하는 경우는 거의 없습니다. 오히려 업무 안팎에서 일하는 동료들과 상호 작용해야 할 가능성이 높습니다. 이 경우 동료와 함께 선택한 기술 솔루션을 평가하고, 비즈니스 요구 사항을 파악하고, 작업을 병렬화하는 최선의 방법을 이해해야 할 수도 있습니다.

스냅 샷 칼레이디코 Unsplash에서

첫 번째 단계는 달성하려는 비즈니스 목표가 무엇인지, 처리해야 할 움직이는 부분이 무엇인지에 대한 정확하고 공유된 이해를 개발하는 것입니다. 특히 그룹 모델링 기술 폭풍우 사건 (이벤트 스토밍)은 이 프로세스의 속도를 크게 높이고 성공 가능성을 높이는 데 도움이 됩니다. 이 작업은 개요를 작성하기 전이나 후에 수행할 수 있습니다. 서비스의 경계, 제품이 성숙해짐에 따라 심화됩니다. 여기에서 달성할 일관성 수준에 따라 다음을 공식화할 수도 있습니다. 공통 언어 당신이 일하는 제한된 상황에서. 시스템의 아키텍처에 대해 이야기해야 할 때 유용할 수 있습니다. 모델 C4, 제안 사이먼 브라운, 특히 문제의 세부 사항을 얼마나 자세히 설명하고 전달하려는 내용을 시각화해야 하는지 이해해야 할 때 더욱 그렇습니다.

아마도 이 주제에 대해 도메인 중심 설계만큼 유용하고 또 다른 성숙한 기술이 있을 것입니다. 그러나 우리는 어떻게 든 주제 영역에 대한 이해로 돌아가므로 해당 분야의 지식과 경험이 있습니다. 도메인 중심 설계 당신에게 유용할 것입니다.

출처 : habr.com

소프트웨어 아키텍처 및 시스템 설계: 큰 그림 및 리소스 가이드

코멘트를 추가 답장을 취소