다음을 통해 공유

솔루션 설계자의 기본 사항

  • 아티클

모든 워크로드는 구성 요소 및 토폴로지 디자인 프로세스를 통과합니다. 이 프로세스는 워크로드 시작 시 가장 심합니다. 여기에는 초기 요구 사항 설계 및 워크로드의 장기적인 성공이 포함됩니다. 아키텍처는 시간이 지남에 따라 워크로드가 변경되고 조직이 기능을 추가, 변경 또는 제거할 때도 설계되었습니다.

구성 요소 및 토폴로지 디자인은 설계자의 주요 기능입니다. 클라우드 기반 및 하이브리드 솔루션에 집중하는 설계자를 클라우드 솔루션 설계자라고도 합니다. 일부 조직에서는 클라우드 솔루션 설계자가 엔터프라이즈 아키텍처 그룹 내의 중앙 집중식 용량에 존재합니다. 또한 특정 워크로드에 집중할 수 있습니다.

전용 역할은 설계자의 기능을 제공할 수 있습니다. 경우에 따라 신뢰할 수 있는 기술 전문가(예: 워크로드 엔지니어링 리더)가 설계자의 기능을 제공할 수 있습니다. 또는 조직에서 워크로드와 연결된 소규모 선임 엔지니어 그룹에 이 기능을 배포할 수 있습니다.

설계자는 일반적으로 시스템 디자인 이외의 역할에 대한 경험을 가지고 있습니다. 다음이 있을 수 있습니다.

  • 개발자 및 운영 팀 구성원입니다.
  • 고객 지원 팀과 협력했습니다.
  • 품질 보증 및 사용자 동의를 위해 시스템을 테스트하는 방법에 대한 이해를 개발했습니다.
  • 재해 복구 훈련 또는 인시던트 대응을 거쳤습니다.
  • 워크로드의 증분 및 대규모 기능 변경 내용 모두에 노출되었습니다.
  • 해석된 사양 및 사용자 동의 조건입니다.

앞의 목록은 완전하지는 않지만, 이러한 관점은 건축가가 설계 의무에 가져다 주는 중요한 측면입니다. Azure Well-Architected Framework는 이러한 사례가 지침을 가장 효과적으로 사용하기 위해 마련되었다고 가정합니다.

다음 섹션에서는 설계자가 해당 기능에 효과적이기 위해 따라야 하는 지침 원칙을 강조합니다.

의사 결정 프레임워크 사용

디자인의 주요 측면은 일관된 프로세스를 사용하여 결정을 내리는 것입니다. 설계자는 초기 디자인과 증분 설계 모두에 엄격하게 접근해야 합니다.

예상된 결정을 식별합니다. 학습된 환경을 사용하여 의사 결정 식별에 도움을 줍니다. 만들려는 모든 결정을 기록합니다.

정보에 입각한 결정을 내립니다. 제한 사항, 제약 조건, 절충, 노력, 가역성 및 위험을 고려합니다. 기술 설명서 및 지침과 함께 개념 증명의 지원 증거를 포함합니다.

ADR(아키텍처 의사 결정 레코드)의 의사 결정을 문서화합니다. 각 결정과 함께 근거를 문서화합니다.

구현에 대한 후속 작업입니다. 모든 의사 결정을 전달하고 구현합니다. 구현에서 향후 의사 결정을 안내하는 데 도움이 되는 방법을 알아봅니다. 의사 결정을 식별하지 못해 위험이 발생한 영역을 찾습니다.

클라우드 디자인 패턴 파악

클라우드 디자인 패턴은 아키텍처의 기본 구성 요소입니다. 클라우드 기반 아키텍처 및 애플리케이션 디자인은 종종 패턴 인식의 연습입니다.

워크로드의 기능 및 비기능적 요구 사항을 평가하여 패턴을 인식합니다. 표준화된 패턴을 통해 사례를 사용하도록 디자인을 매핑할 기회를 찾습니다.

미래 지향적 사고

현재 요구 사항을 달성하기 위한 설계는 필수이지만 설계자가 워크로드의 진화를 예측하는 것이 중요합니다. 구현된 시스템의 변경 내용을 통합하는 것은 구현 전에 디자인을 변경하는 것보다 비용이 더 많이 듭니다.

계획된 수명이 끝날 때까지 지속되는 시스템을 설계하려면 아키텍처 유연성을 염두에 두고 워크로드를 디자인해야 합니다. 식별할 수 있는 경우 디자인 절벽을 피하십시오.

성장 모델. 시간이 지남에 따라 워크로드의 사용량이 증가하거나 축소되는 방식을 예측합니다.

규정 준수 변경. 워크로드가 향후 규정 준수 요구 사항을 충족할 것으로 예상되는 경우 사전 조치를 취합니다. 이 방법은 다음 규정 준수가 요구 사항이 될 때 재작업을 줄일 수 있습니다.

지역 확장. 향후 워크로드를 여러 지역으로 확장하는 것이 좋습니다. 단일 지역으로 제한되는 디자인은 다중 지역 배포를 위해 크게 리팩터링되어야 하며 비용이 많이 들 수 있습니다. 워크로드 디자인이 서로 다른 규정 준수 요구 사항을 가진 여러 지역에 수용해야 하는 경우 더욱 복잡합니다. 지역 확장에 대한 합리적인 예측에서 디자인 요소가 있는지 확인합니다.

제품 로드맵. 디자인에서는 사용 중단 경로에 있는 구성 요소를 포함하지 마세요. 마찬가지로 현재 미리 보기 상태인 기능을 디자인에 포함할 때는 주의해야 합니다. 릴리스될 수도 있지만 취소될 수도 있습니다. 미리 보기 기능을 사용하여 곡선보다 앞서는 것이 매우 유리할 수 있습니다. 기능이 릴리스된 직후 워크로드가 프로덕션으로 이동하도록 준비됩니다. 그러나 신중한 위험 분석을 수행한 후에만 디자인에 미리 보기 기능을 포함합니다. 허용된 위험 프로필이 있는 기능만 제공합니다.

클라우드 디자인 패턴에 대한 자세한 내용은 다음을 참조하세요.

지원 가능성을 위한 디자인

세 가지 주요 지원 관점으로 워크로드를 디자인합니다.

클라우드 공급자 지원. 워크로드는 플랫폼 지원 채널을 사용하는 경우 중단을 방지하기 위해 클라우드 공급자의 지원되는 구성 내에서 작동해야 합니다.

운영 가시성. 디자인은 인시던트 대응 중에 혼동을 방지하기 위해 워크로드 운영 팀에 대한 실행 가시성을 제공해야 합니다.

고객 지원 기능. 디자인은 사용자 요구를 충족할 뿐만 아니라 고객 지원 기능을 용이하게 해야 합니다. 지원 팀이 고객을 조사하거나 지원하는 능력을 저해하는 디자인은 부적절합니다.

기술 유지 관리 및 향상

건축가의 전문 지식은 종종 실용적인 경험에 뿌리를 두고 있습니다. 진화하는 클라우드 에코시스템을 따라잡기 위해 기술 집합을 확장하는 데 투자하는 것이 중요합니다.

교육 기술 공급자가 설계자에게 제공하는 교육 및 인증 기회를 모색합니다.

커뮤니티 참여. 온라인 및 지역 아키텍처 커뮤니티를 통해 동료와 소통합니다.

예비 연습. 조직에서 후원하는 해커톤 또는 유사한 이벤트에 참여하여 익숙하지 않은 영역에서 기술을 개발합니다.

성공을 위한 공동 작업

설계자는 클라우드 공급자 또는 구현 파트너의 전문 지식을 활용해야 합니다. 대부분의 공급자는 워크로드가 플랫폼에서 성공하기를 원하며, 종종 클라우드 솔루션 설계자와 아키텍처 디자인 검토 세션 또는 컨설팅 세션과 같은 서비스를 제공합니다. 공급업체 관계 내에서 검토 및 지원을 위한 기회를 모색합니다.

디자인 접근 방식에서 체계적이어야 합니다.

아키텍처 프레임워크는 워크로드 관점과 방법론적 접근 방식을 제공하여 설계자를 지원합니다. 잘 설계된 프레임워크는 포괄적인 워크로드 관점을 제공합니다. 설계자는 TOGAF(Open Group Architecture Framework)와 같은 다른 아키텍처 프레임워크와 잘 설계된 프레임워크를 결합할 수 있습니다.

아키텍처 프레임워크의 원칙, 검사 목록, 평가 및 참조 자료를 사용하여 워크로드에 맞는 프로세스를 설정합니다. 마인드 매핑과 같은 개인 기술과 프레임워크를 결합합니다.

아키텍처는 최종 제품에 관한 것만큼이나 통신에 관한 것입니다. 설정된 프로세스에서 의도적인 의사 결정, 절충 승인 및 명확한 통신을 최적화하고 있는지 확인합니다.

다음 단계

설계자의 검사 목록