EtoC
Architecture(아키텍처) 본문
면접공부를하다 '아키텍처가 뭘까?'라는 생각이 들었다.
청사진이라는 생각이 먼저들었고 레이어드패턴, 카프카, 마이크로 아키텍처, 모놀리틱 아키텍처가 떠올랐다.
근데 명확하게 뭐다라는 생각이 떠오르지 않는데..음 ..아키텍처가 정확히 뭐고 왜 중요한거지?
1 . Architecture
아키텍처는 건축물 또는 건축양식을 의미한다.
컴퓨터 공학에서는 컴퓨터 아키텍쳐(Computer architecture)라고 한다.
1. Computer architecture
컴퓨터 아키텍처는 시스템의 근간이되는 운영구조이다.
하드웨어와 소프트웨어간의 상호 작용 및 컴퓨터가 데이터를 처리하는 방식을 다루며, 다양한 수준의 추상화로 이루어져 있다.
요약하면 하나의 컴퓨터가 어떻게 동작하는지 원리를 나타낸것이다.
2. Software Architecture
Software Architecture Guide
Software Architecture is the important aspects of a software system's internal design, usually its major components and aspects that are hard to change.
martinfowler.com
Software Architecture Guide의 저자 Martin Fowler의 글을 요약하면 아래와 같다.
"Architecture is about the important stuff. Whatever that is"
"good architecture is something that supports its own evolution, and is deeply intertwined with programming. "
"High internal quality leads to faster delivery of new features"
martin fowler는 아키텍처를 중요한 무언가라고한다.
개발자들은 대부분의 시간을 코드 수정하고 추가하는데 보내는데 좋은 아키텍처일수록 기능을 추가하고 빠르게 제공할 수 있기때문에
초기에 좋은 아키텍처를 만들어야한다.
아키텍처는 프로젝트 초기에 결정해야하는 디자인으로 어떤 결정을 내리는지에따라 개발자가 생각해야할 규모가 달라진다.
일반적으로 떠올리는 어플리케이션의 규모를 어플리케이션 아키텍처라고한다.
3. Application Architecture
martin fowler는 "어플리케이션 아키텍처가 일반적으로 사용되는 아키텍쳐인데도 불구하고 정확한 정의가 없으며,
그런 어플리케이션 아키텍처를 사회적으로 구성된 아키텍처"로 본다고 한다.
개발자에겐 하나의 단위로 보는 코드 집합체, 비즈니스 고객에게는 하나의 기능적 단위, 사업자에게는 하나의 예산으로 간주된다.
이런 관점들이 연결되어 어플리케이션의 잠재적인 크기를 설정한다고 한다.
엔터프라이즈 아키텍처와의 차이점은 사회적 구조를 중심으로 상당한 정도의 통합된 목적이있는 점이다.
application architecture
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these
martinfowler.com
위의 사이트의 내용을 정리하기에는 내용이 정말 많아서 직접 들어가서 읽어보는게 좋을거같다.
아래는 다양한 사이트들에서 읽어보고 정리해보았다.
애플리케이션 아키텍처는 애플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술을 설명합니다.
아키텍처는 애플리케이션을 구축할 때 따라야 할 로드맵과 모범 사례를 제공하여 체계적으로 구성된 애플리케이션을 완성할 수 있게 해줍니다.
소프트웨어 설계 패턴은 애플리케이션을 구축할 때 도움이 됩니다.
패턴을 서로 연결해 보다 일반적인 애플리케이션 아키텍처를 만들 수 있습니다.
애플리케이션 아키텍처에는 프런트엔드와 백엔드 서비스가 모두 있습니다.
출처: https://www.redhat.com/ko/topics/cloud-native-apps/what-is-an-application-architecture
요약하면 어플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술을 설명하고 클라이언트와 서버간에 어떻게 연결되어있는지 설명해주는 설계도의 의미로 사용되는것같다.
Application Architecture에는 Monolithic , Layered, Microservices, Event-Driven, Service-Oriented 등이 있다.
Monolithic Architecture
비즈니스 로직, DB, UI 같은 소프트웨어 컴포넌트가 하나의 어플리케이션에 통합하여 빌드하고 배포하는 아키텍처이다.
전통적인 방식으로 모든기능이 하나의 코드베이스에 포함되어 개발이 단순하고 배포하기 쉽다.(처음 학원가면 하는것)
단점으로는 프레임워크와 언어의 제한, 확장성과 유지보수의 어려움, 부분적 장애가 서비스 전체의 장애가 될 수 있다.
Microservice Architecture(MSA)
요즘 많이 사용하는 아키텍처로 하나의 큰 어플리케이션을 작은 단위의 독립적인 서비스로 나누는 아키텍처이다.
각 서비스는 자체적으로 배포되고 운영되며 API를 통해 통신한다.
독립적으로 개발과 배포가 가능하여 빠른 배포가 가능하며 확장성이 용이하다.
단점으로는 각각의 서비스가 독립된 저장소를 가지고 있어 공유자원에 접근하기 어려우며 배포와 실행과정이 복잡하게 얽혀있다.
그래서 배포와 데이터 관리가 어려우며 서비스간의 의존성이 높아 리소스가 과도하게 사용되어 비용의 증가로 이어질 수 있다.
추가공부: CI/CD와 배포자동화
Event-Driven Architecture(EDA)
분산된 어플리케이션 서비스(MSA)가 이벤트(상태변화,업데이트)를 기반으로 통신하고 응답하는 아키텍처 패턴이다.
시스템의 개별 구성 요소에 대해 확장, 업데이트, 독립적인 배포가 쉽고, 이벤트메시지를 통해 비동기적으로 통신하기때문에 이벤트를 확인하는데 드는 폴링 비용을 없앨수있다.
단점으로는 개발자가 이벤트를 기억하고 게시해야하는점과 디버깅, 추적이 어렵다.
추가공부: pub(게시)/sub(구독)
Layered Architecture
소프트웨어 시스템을 여러 계층으로 나누어 계층별로 특별한 역할을 수행하도록 하는 아키텍처 패턴이다.
사용자와의 상호작용을 처리하는 presentation 계층, 시스템의 비즈니스 로직을 구현하고 데이터를 처리하는 business logic계층, 데이터베이스에 저장,검색,업데이트하는 Data Access 계층이있다.
각 계층은 서로 독립적으로 변경될 수 있돌고 설계되어있어 시스템 모듈화를 통한 유지 보수와 확장성을 높여준다.
Service-Oriented Architecture(SOA)
기존의 어플리케이션의 기능을 비즈니스 단위로 묶어서 표준화된 호출 인터페이스(REST API)를 통해 서비스라는 컴포넌트단위로 구현하고, 이 서비스들을 조합(통합)하여 어플리케이션을 구현하는 소프트웨어 아키텍처이다.
다양한 비즈니스 프로세스에서 서비스를 재사용 할 수 있어 빠르게 어플리케이션을 구성할 수 있으며 유지보수가 쉽다.
하지만 작은 변경사항에도 전체에대한 재구축이 필요하며 서비스가 많이 추가될수록 느려지은 단점이있다.
SOA는 회사전반에관련된 아키텍처 접근 방식인데 반해 MSA는 어플리케이션 개발 팀 내의 구현 전략이라는 차이점이있다.
📝 생각 정리
기본적인 개념과 왜 사용하는지를 명확하게 알고싶어서 찾아보고 정리해보자한건데 정말 새발의 피도안되는 양이다.
하나하나의 아키텍처의 통신방식과 개념들 언제사용해야하는지 고려할게 참 많았다.
그래도 다양한 글들을 읽어보면서 왜 면접에서 아키텍처에대해 질문하는지 개발자라면 어떤 것을 고려해야하는지 알 수 있었다.
일단 백엔드 채용공고글들을 보면 회사서버의 유지 보수 또는 신기능 개발이라는 내용이 거의 다 들어가있다.
회사 내부의 코드가 어떻게 작동되는지는 가서보면 알겠지라고 생각했는데 아키텍처를 알고보니 회사의 소프트웨어의 흐름을 모르는데 코드가 어떻게 동작하는지 제대로 알수있을까란 생각이들었다.
또, 고객들은 코드가 어떻게 작동하는지 잘만들어졌는지에는 관심이 없지만 새로운기능은 고품질로 빠르게 제공되기를 원한다.
고품질이라는게 오랜시간과 비용을 들여 만들어지는것일텐데, 아이러니하게 빠르고 좋은품질을 제공받기를 원한다.
좋은 아키텍처는 기능을 추가하기 쉽고 빠른 속도와 더 높은 퀄리티 로 고객의 기대에 부응할 수 있도록 도와준다.
그래서 개발자 또는 아키텍처 설계자는 고품질의 좋은 아키텍처를 만들수 있어야한다.
하지만 품질과 비용사이에서 균형점을 찾고 아키텍처의 시스템의 설계 원칙과 패턴, 구성요소 및 데이터의 흐름을 다루고 시스템의 성능과 보안, 확장성까지 고려해야하는 개발자는.. 정말공부할게 너무너무 많구나.
