Application Architeture란?
개발 방법론에 대한 공부가 끝났고 이제는 Application Architecture에 대해 설명할 차례이다.
Application Architecture에는 대표적으로 Monolithic, N-Tier Architecture, 그리고 Microservice Architecture(MSA)가 존재한다. 그렇다면 Application Architecture란 무엇인가?
Application Architecture란 애플리케이션을 설계하고 구축할 때 활용할 수 있는 패턴이나 기술들을 의미한다.
즉, "어떤 방식으로" Application을 만들 것인가에 정하는 설계도라고 보면 될 것이다.
Application Architecture는 개발하는 Software에서 Componenet끼리의 관계 및 기능을 정의해주며 전체 Application이 실행되기 위한 Component의 흐름 등을 설명해준다.
그렇다면 Applicatoin Architecture에 속하는 개념들에 대해 공부해보며 개념을 확실히 공부해보자
Monolithic Architecture(모놀리식 아키텍처)란?
모놀리식 아키텍처는 전통적인 웹 시스템 개발 스타일로써 하나의 애플리케이션 내에 모든 로직이 들어가 있는 구조를 의미한다.
블로그 기능에 대하여 개발을 진행한다고 생각해보자.
보통 블로그에는 로그인, 글 쓰기, 글 조회, 글 수정, 글 삭제 기능이 존재해야 할 것이다. 또한 이를 User에게 보여주기 위한 Frontend파일(jsp나 html 파일)도 존재해야 할 것이다.
모놀리식 아키텍처에서는 로그인, 글 쓰기, 글 조회, 글 수정, 글 삭제에 대한 로직과 이에 대한 Frontend파일을 모두 1곳에서 저장 및 관리한다.
따라서 모놀리식 아키텍처에서는 1개의 파일만 실행하면 바로 전체 서비스를 구동시킬 수 있는 것이다.
모놀리식 아키텍처를 간단히 말하자면 Backend 파일 및 Frotnend파일을 한 번에 Build 하여 배포하는 방식으로 1개의 커다란 Application을 구축하는 방식이라고 할 수 있다.
Monolithic Architecture의 장점
간편한 개발과 배포
모놀리식 아키텍처는 1개의 애플리케이션으로 SW의 모든 기능 및 요구사항을 처리하는 개발 방법을 의미한다.
이는 개발과 배포의 간편함을 가지고 온다.
MVC Model을 활용하여 개발을 진행해봤다면 느끼겠지만 코드를 깃허브에 올리고 Gradle에 의존성들만 제대로 입력시켜 놓는다면 완전히 다른 컴퓨터에서도 최소한의 툴(IntelliJ, Java 등)만 설치하고 동일한 코드를 실행시킬 경우 똑같은 방식으로 동작함을 알 수 있다.
즉, 1개의 애플리케이션만 통째로 실행시키면 되기 때문에 환경 설정이 편해지며 설정이 동일하다면 여러 컴퓨터에서 동일한 동작 과정을 거치기 때문에 개발을 진행하기 매우 편리해진다.
모놀리식 아키텍처는 배포가 간단하다는 장점이 있다.
결국 1개의 애플리케이션을 통해서 전체 SW를 동작시킬 수 있기 때문에 1개의 애플리케이션만 배포하면 바로 완전한 서비스를 수행시킬 수 있는 것이다. 또한 개발 환경과 동일하게 운영 환경을 만들어준다면 (이론적으로) 완벽히 같은 동작 방식을 가질 것이므로 조금 더 안정성 있게 SW를 배포할 수 있다는 장점도 가지고 온다.
배포가 쉽다는 장점은 확장성이라는 면에서도 큰 장점을 지닌다. 트래픽으로 인해 서버를 확장시켜야 할 경우 모놀리식 아키텍처를 활용할 경우 서버 환경 설정을 수행해주고 1개의 파일만 배포한 이후 실행시킴으로써 바로 서비스 확장이 가능해지기 때문에 매우 편리하다.
간편한 테스트
모놀리식 아키텍처를 테스트할 경우 개발했던 1개의 애플리케이션만 구동시킨 뒤 바로 실험해보면 되므로 테스트를 진행하기 쉽다.
이에 대해서는 찾아본 결과 의견이 조금 분분했던 것 같다.
어떤 분들은 오히려 모놀리식보다는 작은 서비스를 여러 개 개발하여 통합시키는 MSA(마이크로서비스 아키텍처)를 활용하는 것이 더 좋다고 주장하셨다. MSA 같은 경우 서비스를 작은 단위로 개발하며 작은 서비스에 대한 테스트가 더 쉽다는 사실에 의거하여 당연히 MSA가 테스트가 더 간편하다고 주장하셨다.
하지만 개인적으로는 모놀리식이 테스트에 있어서는 더욱 편리하다고 생각하다.
물론, 당연히 작은 서비스를 테스트하는 것이 훨씬 쉽고 어떤 테스트를 해야할지 명확해진다는 점에서는 MSA가 테스트에 더 적합하다고 생각할 수 있다. 문제는 SW라는 것이 1개의 기능만 테스트하여 완료되는 서비스가 아니라는 것이다.
위에서 말했던 블로그 기능을 테스트하려면 로그인 기능도 테스트 해봐야 하고 블로그에서 외부 저장소에 저장된 파일을 가지고 오는 기능을 테스트해 봐야 할 수도 있다. 즉, 1개의 작은 서비스만이 아닌 외부에 존재하는 개발한 서비스와 연동된 다른 서비스의 동작 방식도 고려해야 하는 것이다.
따라서 테스트를 진행할 경우 연동된 서비스들과 연결시켜 테스트를 진행해야 하는데 이 과정에서 REST API 등의 통신 방식을 활용해야 하기 때문에 테스트가 더욱 어려워진다고 생각한다. 추가로 개발한 서비스와 연동된 다른 서비스들이 모두 구동되고 있어야 한다는 전제조건이 깔리기 때문에 사전 조건이 필요하다는 불편함도 존재한다고 생각한다.
Call-by-reference
각 컴포넌트는 상호 호출을 함수로 수행하는 Call-by-reference 구조를 취한다.
먼저 Call-by-Value와 Call-by-Reference에 대해서 알아보자.
Call-by-Value는 "값을 복사"하는 호출 방식이며 Call-by-Reference는 "주솟값을 복사"하는 호출 방식이다.
예시를 통해 조금 더 쉽게 알아보자.
A라는 변수에 "Java"라는 String 타입 데이터를 저장했다고 가정하자.
그리고 B라는 메서드에서 A를 활용하고 싶다고 가정하자.
Call-by-Value는 "Java"라는 객체를 복사하고 메모리에서 다른 공간에 저장한다. 그리고 이렇게 다른 공간에 복사된 데이터를 B 메서드에서 활용하는 것이다. 원본을 복사하여 복사본을 활용하는 것이기 때문에 원본에 영향을 끼치지 않고 반대로 원본의 영향에도 자유롭다는 안정성을 가지지만, 복사본을 저장할 추가 메모리가 필요하며 복사하는데 시간이 필요하다는 단점이 존재한다.
Call-by-Reference는 A 변수의 메모리 주솟값을 전달해주는 것이다. B 메서드 입장에서는 이미 저장되어 있는 A 데이터를 그대로 받아오는 것이기 때문에 굳이 값을 복사하는데 시간을 들일 필요가 없고 A는 이미 메모리 상에 저장되어 있는 데이터로써 추가적인 메모리 공간이 필요하지 않기 때문에 메모리를 아낄 수 있다. 물론 B 메서드에서 바라보는 A변수와 다른 메서드에서 바라보는 A 변수가 동일하기 때문에 A 변수 값을 변화시킬 경우 다른 메서드에서도 그 영향을 받을 수 있다는 단점이 존재한다.
모놀리식 아키텍처에서는 메서드들을 "Call-by-Reference" 방식으로 호출한다.
메서드들이 수행될 때 Parameter(매개 변수)값만 바뀌고 메서드의 로직 자체는 변화하지 않기 때문에 다른 메서드나 로직에 영향을 끼칠 수도 있다는 단점을 고려하지 않아도 된다.
동시에 메서드를 복사하여 실행시킨다는 추가적인 시간이 필요하지 않기 때문에 모놀리식 아키텍처에서는 Call-by-Reference를 통해 빠른 컴포넌트 호출로써 성능에 제약을 줄일 수 있다는 장점을 가지고 오는 것이다.
Monolithic Architecture 단점
빌드 및 배포 시간이 길어짐
모놀리식 아키텍처는 결국 1개의 애플리케이션에 기능들을 덧대는 형식이다.
즉, 기능이 많을수록 애플리케이션의 Size가 커질 수 밖에 없다.
빌드에 걸리는 시간은 애플리케이션의 Size와 비례한다.
당연한 말이라면 당연한 말인데, 빌드라는 것은 결국 원래 존재하는 Application 코드를 서버 상에 운영할 수 있는 상태로 만드는 작업이기 때문에 당연히 원래 Application 코드가 클 경우 코드들을 모두 파악하고 적절한 형태로 만들어주는 작업에도 긴 시간이 걸리게 될 것이다.
또한 애플리케이션의 크기가 클 수록 배포 시간도 길어진다.
우리가 USB에서 작은 파일과 큰 파일을 꺼내려고 할 때 걸리는 시간 차이를 생각해보면 당연히 큰 파일이 오랜 시간이 걸린다는 것을 알 수 있다.
또한 오랜 시간을 걸려서 빌드 파일을 운영 서버에 올렸다고 하더라도 이를 실행시키는 데에 있어 또 오랜 시간이 걸린다.
즉, 배포와 빌드라는 것은 Application의 Size와 비례하는 것으로써 1개의 애플리케이션을 통해 전체 SW 기능을 처리해야 하는 모놀리식 아키텍처에서는 배포와 빌드 시간이 길어질 수밖에 없다.
수정에 대한 불편함(선택적 확장의 어려움)
배포와 빌드 시간이 길어진다는 단점과 이어지는 단점이다.
모놀리식 아키텍처에서는 자그마한 수정사항이 발생했더라도 애플리케이션 전체를 빌드 및 배포시켜야 한다.
만약 내가 에러 발생 이유를 찾기 위해 1개의 메서드에만 Logging을 위한 코드를 추가한 이후 확인하고 싶더라도 전체 코드를 다시 빌드 및 배포시켜야 하는 것이다.
이런 자그마한 수정에도 전체 애플리케이션을 재실행시켜야 한다는 단점이 빌드와 배포 시간이 길어진다는 단점과 결합된다면 자그마한 수정을 확인하기 위해서 너무 오랜 시간이 필요하다는 단점이 되며 만약 발생한 에러가 해결되지 않을 경우 코드를 다시 수정한 뒤 또 애플리케이션 전체를 재실행시켜야 한다.
결국, 수정한 코드를 확인하기 어려워지며 에러를 신속하게 처리하는 데에도 문제점이 생기는 것이다.
이런 점은 기능 확장에 대한 어려움도 가져온다.
추가적인 기능 또한 결국 기존에 존재하던 애플리케이션에 덧대는 방식으로 개발이 진행된다. 따라서 추가적인 기능이 제대로 동작하는지 확인하기 위해서는 애플리케이션 전체를 재실행시켜야 하며 이는 기능 확장에 오랜 시간이 걸린다는 단점으로 이어진다.
협업의 어려움(높은 의존성)
모놀리식 아키텍처는 1개의 어플리케이션에 많은 기능들이 몰려있다.
그리고 이 많은 기능(Component)들은 Call-by-Reference라는 호출 방식으로 로직을 수행한다.
즉, 모놀리식 아키텍처에서는 대부분의 기능들이 의존성을 가지고 있게 된다.
이는 빠른 실행이라는 장점을 가지고 오기도 하지만 SW가 너무 높은 의존성을 가진다는 단점을 가지고 온다. 너무 높은 의존성은 곧 1개의 작은 에러가 전체 서비스에 대한 에러로 확장될 수 있다는 의미를 가진다.
1개의 작은 에러가 전체 서비스의 에러로 확장될 수 있기 때문에 여러 사람이 참여하는 프로젝트의 경우 다른 사람이 발생시킨 오류가 내가 개발하고 있는 기능에도 오류를 발생시킬 수 있기 때문에 협업을 어렵게 한다.
기술의 혼용이 어려움
모놀리식 아키텍처는 1개의 애플리케이션을 통해 전체 기능을 수행한다.
동시에 SW 수행을 위한 설정도 한 번에 수행한다는 특징을 가지는데, 이는 쉬운 설정이라는 장점도 가지지만 단점도 가지고 온다.
바로 기술의 혼용이 어렵다는 점이다.
Application이 한 개 밖에 존재하지 않으므로 여러 기술을 혼용하기 어렵고, 동시에 여러 개발 언어를 활용하여 SW를 개발하기도 어려워진다.
예를 들어보자.
A 기능은 NoSQL과 잘 연동되며 B 기능은 RDBMS에 유리한 기능이라고 가정하자.
모놀리식 아키텍처에서는 기능이 어떤 기술에 유리하든지 간에 처음 설정할 때 1개의 DB 접속만 설정할 수 있기 때문에 NoSQL로만 기능들을 구현하거나 RDBMS를 통해서만 기능을 구현해야 하는 것이다
대형 시스템 개발이 힘듦
위 모든 단점들을 합치면 대형 시스템 개발이 힘들다는 단점으로 귀결된다.
먼저, 대형 시스템의 크기가 너무 크다면 빌드 및 배포 시간이 길어지며 서버의 기동시간이 오래 걸릴 것이다.
또한 1개의 에러가 전체 시스템에 에러를 발생시키기 때문에 여러 개의 기능이 존재하는 대형 시스템의 경우 어떤 에러가 전체 시스템에 영향을 미치는지 찾고 해결하기가 더욱 어려워진다.
두 번째로 기능 1개를 추가하고 싶더라도 전체 애플리케이션을 재실행해야하는데 이는 에러를 수정하기 어렵고 빌드 및 배포 시간이 긴 모놀리식 아키텍처에서는 매우 어려운 작업이 된다.
마지막으로 모놀리식 아키텍처는 높은 의존성을 가지므로 전체 시스템을 제대로 이해해야 다른 기능에 피해를 안 끼칠 수 있는데 시스템이 커질수록 전체 시스템을 이해하는 것이 어려워진다는 단점도 존재한다.
추가적으로 CI/CD의 자동화가 어렵다는 단점도 가지고 온다.
이런 모든 단점들은 개발 시스템이 커지면 커질수록 모놀리식 아키텍처로서는 처리하기 어려워진다는 단점으로 귀결되는 것이다.
