성공적인 애플리케이션 현대화를 위한 12가지 기본 원칙

애플리케이션 현대화(Application Modernization)는 기존 애플리케이션을 클라우드 네이티브 환경에서 가장 잘 구동될 수 있게 개선하는 활동을 의미합니다. 단순 레거시 인프라 환경에서 구동하는 애플리케이션을 클라우드에 배포하는 것이 아니라, 클라우드가 주는 이점을 최대한 살리기 위해 애플리케이션을 개선하는 것입니다. 애플리케이션 현대화는 애플리케이션의 아키텍처, 코드, 데이터, 보안, 개발 및 운영 방식을 개선하는 것을 포괄적으로 포함합니다. 이를 통해 애플리케이션의 효율성, 신뢰성, 보안성, 확장성, 유지보수성, 개발 및 운영 효율성을 향상할 수 있으며 비즈니스와 외부 환경 대응에 더욱 유연하고 민첩하게 대응할 수 있습니다. 특히, 디지털 전환의 핵심 요소기술인 AI/ML, 빅데이터, 블록체인, IoT, 메타버스 등의 기술 수준이 빠르게 성숙함에 따라 애플리케이션이 이러한 기술들을 쉽게 활용하고 보조를 맞출 수 있도록 준비되어야 합니다. 이런 측면에서 애플리케이션 현대화는 기업이나 조직에서 피할 수 없는 활동이 되고 있으며, 애플리케이션 현대화를 위한 전략과 기술을 갖추지 않은 조직은 시장에서 뒤처지고 있습니다.

애플리케이션 현대화를 위해 12요소 애플리케이션 원칙을 적용하는 것은 애플리케이션 현대화의 기본입니다. 12요소 애플리케이션 원칙을 적용하는 것은 최소 리팩토링 수준의 전략을 수행한다는 것이고 이는 애플리케이션의 배포 효율성이나 유지보수성, 관리 용이성 등이 비약적으로 상승할 것으로 기대되기 때문입니다. 12요소 애플리케이션 원칙은 애플리케이션을 클라우드 네이티브 애플리케이션으로 재탄생시키는 실행 법칙이며, 이미 많은 조직에서 검증되었습니다. 12요소 애플리케이션 원칙은 다음과 같은 12가지 원칙으로 구성되어 있습니다.

1. 코드 베이스

코드 베이스는 모든 환경 정보는 코드로 구성되어 있고 코드 리파지토리에서 관리되어야 함을 의미합니다. 애플리케이션 배포 환경은 흔히 개발, 테스트, 스테이지, 운영 환경으로 분리되는데 환경별 구성 정보는 각각 코드로 작성되며 코드 변경에 대한 관리가 버전 컨트롤 도구에 의해 이루어져야 합니다. 이 코드 베이스의 원칙은 다양한 환경에 애플리케이션을 배포할 때 Immutable Infrastructure를 구성할 수 있도록 도와줍니다. Immutable Infrastructure는 코드에 의해서만 환경이 구성되고, 변경하려면 기존 환경을 버리고 변경된 코드에 의해 새로 생성하는 것을 의미합니다.

2. 의존성

의존성은 애플리케이션을 실행하는 데 필요한 모든 종속성을 명시적으로 선언해야 함을 의미합니다. 선언되는 대상은 라이브러리, 도구, 프레임워크, 퍼시스턴스/메시징 클라이언트 등입니다. 의존성 역시 코드로 명시되어야 하며 코드 리파지토리에서 관리되어야 합니다. 자바의 Gradle이나 Maven과 같은 도구로 외부 라이브러리를 선언적으로 관리하고 리파지토리를 통해 관리하는 것이 대표적인 예입니다.

3. 구성 정보(Configuration)

구성 정보는 애플리케이션에 필요한 구성 정보를 어떻게 관리할 것인지에 대한 원칙입니다. 소스 코드에 어떠한 형태로도 하드코딩 되어서는 안 됩니다. 개발, 테스트, 스테이지, 운영 등 다양한 배포 환경에 맞는 구성 정보는 별도의 코드로 작성되고 실제 애플리케이션이 배포될 때 구성 정보가 주입되어 배포 환경에 전달됩니다. 애플리케이션의 스케일링이나 장애 복구 등의 이유로 애플리케이션이 재시작되는 경우에도 구성 정보는 변경되지 않아야 합니다. 이러한 구성 정보는 코드 베이스에 의해 관리되어야 합니다. 애플리케이션이 수많은 인스턴스로 스케일 아웃 되어있는 경우에도 구성 정보는 배포할 때나 런타임 구동 시 실시간으로 주입되어야 합니다.

4. 리소스로서의 서비스(Backing Service)

애플리케이션은 상태를 가지고 있으면 안 됩니다. 상태를 가져야 할 때는 명시적으로 선언된 외부 리소스를 첨부하는 식으로 상태를 관리해야 합니다. 예를 들어, 애플리케이션이 특정 블랍에 어떠한 이미지 정보를 써야 할 때, 그 블랍 정보는 특정 프로토콜을 사용하여 (예: HTTPS) 외부 리소스로서 통신하는 구성으로 적용되어야 합니다. 애플리케이션이 로컬 디스크에 데이터베이스를 사용하였다고 하면 이 데이터베이스는 외부 리소스로 분리, 애플리케이션과 명시적인 방식으로 선언, 통신하는 구조로 변경되어야 합니다.

5. 빌드, 릴리즈, 실행

이 원칙은 애플리케이션 배포가 빌드, 릴리즈, 실행 단계와 완전히 분리되어야 함을 의미합니다. 애플리케이션을 빌드할 때에는 특정 배포 환경에 완전히 독립적이어야 합니다. 애플리케이션이 빌드되면 해당 환경을 위한 구성 정보가 주입되어 특정 배포 환경에 릴리즈됩니다.

6. 프로세스

마이크로서비스는 언제나 상태를 갖지 않고 오직 요청받은 트랜잭션을 처리하는 데 필요한 정보만 가지고 있어야 합니다. 마이크로서비스는 인스턴스가 종료되더라도 데이터가 손실되면 안 됩니다. 언제든지 종료되어도 새 인스턴스로 교체될 수 있어야 합니다. 데이터가 손실된다는 것은 마이크로서비스가 상태를 갖고 있다는 것이고 이를 피하는 설계를 해야 합니다. 상태의 저장이 필요하면 위에서 설명한 “리소스로서 서비스”에 저장해야 합니다. 쉽게 말하면, 상태를 mySQL이나 Redis와 같은 외부 리소스에 저장하는 것입니다.

7. 포트 바인딩

마이크로서비스가 제공하는 포트와 외부에 노출하는 포트를 명시적으로 연결하는 것을 포트 바인딩이라고 합니다. 마이크로서비스는 필요한 모든 라이브러리를 보유하며 스스로 구동될 수 있도록 패키징 되어야 합니다. Tomcat이나 WebLogic과 같은 외부의 WAS(Web Application Service) 컨테이너 없이도 스스로 구동되어야 합니다. 이때 포트 바인딩으로 정의된 HTTP 포트로 외부에 공개되어야 하며 내, 외부 포트는 변경에 유연해야 합니다.

8. 동시성

동시성은 멀티스레드나 동시 프로그래밍을 이야기하는 것이 아닙니다. 마이크로서비스의 인스턴스가 수평적으로 동시에 서비스를 제공하는 능력을 의미합니다. 서비스의 성능을 확장하기 위해 CPU나 메모리를 업그레이드할 수 있으나 이러한 방법은 성능 확장에 한계를 가져옵니다. 따라서 적은 CPU와 메모리를 가진 인스턴스를 수평적으로 여러 개 배치하여 성능을 확장하는 것이 요구됩니다. 이 원칙은 클라우드 네이티브 애플리케이션을 실현시키는 데 가장 중요한 원칙으로 작동합니다.

9. 폐기성

마이크로서비스의 폐기성은 언제나 “폐기 가능한” 상태로 설계되어야 함을 의미합니다. 즉, 언제나 수요에 맞춰 시작되거나 폐기되어야 함을 의미하며 탄력적인 성능 대응에 필수적인 요소가 됩니다. 마이크로서비스는 구동되는데 매우 짧은 시간만 소요되어야 하는데 컨테이너 환경이라면 일반적으로 수 초 내에 구동이 완료되어야 합니다. 리소스 모듈 등 다양한 모듈을 메모리에 적재한다 해도 수십 초 내에 구동되어야 합니다. 또한 특정 인스턴스가 장애나 스케일링 인으로 인해 다운된다고 해도 다른 인스턴스에 영향을 끼쳐서는 안 됩니다.

10. 개발/운영 일치성

개발계, 테스트계, 운영계 등의 다양한 애플리케이션 구동 환경이 존재할 때 이 환경은 최대한 일치성을 보유하고 있어야 합니다. 즉, 환경별 구성 정보는 별개의 설정으로 정의되나 다른 요소들 - 애플리케이션, 네트워크 환경, 애플리케이션이 구동되는 컨테이너 환경 - 은 모두 환경이 일치되어야 합니다. 지속적 배포 환경을 위해서는 이 일치성이 매우 중요한데, 코드가 Commit 되는 순간 단위테스트가 수행되고 개발, 테스트계에 배포되고 통합 테스트나 인수 테스트가 자동으로 수행되어 운영계로 배포될 때까지 복잡한 과정에서의 오류나 불일치성을 피하려면 이 원칙은 반드시 구현되어야 하는 것입니다. 개발계에서는 문제가 없었고 테스트계에서 테스트가 완전히 수행되었어도 운영계에서 오류가 발생하는 사례가 아직도 흔하게 발생합니다. 배포 시 발생하는 환경 불일치를 줄이기 위해 개발과 운영 환경을 최대한 일치하게 구성하고 단일 코드 베이스의 애플리케이션에 환경별 구성 정보를 주입하는 방식으로 배포 작업을 구성해야 합니다.

11. 로그

로그는 항상 스트림으로 출력되어야 합니다. 이 스트림으로 출력된 것을 Log Stash나 다른 외부 로그 수집 도구로 중앙 집중된 수집 환경을 구성해야 합니다. 마이크로서비스는 로그가 어떻게 어디로 수집되는지 고려하지 않고 오직 스트림 출력만을 고려하면 됩니다.

12. 관리 프로세스

개발자나 운영자는 데이터 이관이나 변환, 디버깅을 위한 툴 사용 등의 관리적 일을 수행합니다. 이때 해당 인스턴스로 직접 들어가서 임시로 수행하는 것이 아니라 코드 저장소에서 코드로 관리되고 유지되는 스크립트만 수행해야 합니다. 마이크로서비스 실행 시 필요한 관리 작업 유형이 사전에 정의되어야 하고 이를 통해서만 관리 작업을 수행해야 하는데, 사전에 모든 관리 작업이 도출되지 않아 임시 작업이 발생한다고 하면 그 임시 작업을 새로운 작업 유형에 포함시켜 코드 저장소에서 관리되도록 해야 합니다. 위에서 설명한 12개의 모든 요소는 중장기적으로 애플리케이션 현대화를 위해 모두 반영이 되어야 합니다. 하지만 당장의 조직이 보유한 리소스나 시간적 한계로 인해 단계적으로 적용이 필요하다고 하면 우선순위와 난이도를 정의할 수 있습니다.

레거시 앱을 조직이 원하는 수준의 민첩성을 가진 애플리케이션으로 현대화하는 것은 쉬운 일이 아닙니다. 하지만 조직의 비즈니스 성과나 생존을 위해 더 이상 미루거나 피할 수는 없습니다. 차세대 같은 전면 재개발이라는 거대한 접근 방식보다 애플리케이션 현대화를 위한 목표와 전략을 세우고 우선순위에 따라 작게 시작할 수 있습니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.