AO 생태계 승리의 열쇠: 웹3 시대의 마이크로서비스 아키텍처

저자: ArweaveOasis, 출처: PermaDAO

이 글에서는 마이크로서비스 아키텍처 또는 액터 모델을 채택할 때의 이점에 대해 논의하고 애플리케이션 개발에 가져오는 논리적 복잡성의 정도를 분석합니다.

아오더컴퓨터의 출시는 의심할 여지 없이 @ArweaveEco 생태계와 웹3.0 업계 전반에 새로운 사고방식과 실천 방식을 가져왔습니다. 이는 대다수 투자자들의 관심뿐만 아니라 심도 있는 연구를 시작하기 위해 많은 우수한 개발자들을 끌어들이는 데에도 반영되어 있습니다.

웹3가 대규모로 채택되는 것을 막는 요인은 무엇인가요?

단순히 말해, 사용할 만한 가치가 있는 탈중앙화 애플리케이션이 너무 적다는 것입니다.

웹3 인프라, 개발 도구, 소프트웨어 엔지니어링 관행 등의 현재 상태를 고려할 때 현재 많은 유형의 탈중앙화 애플리케이션을 구현하는 것은 거의 불가능합니다.

인프라 측면에서 보면 AO의 등장은 이러한 중요한 격차 중 일부를 메울 수 있다고 생각합니다. 그러나 대규모 탈중앙화 애플리케이션을 구축하는 데 필요한 엔지니어링의 복잡성은 현재로서는 여전히 벅찬 과제입니다. 이로 인해 초기 단계에서 흔히 그렇듯 제한된 리소스로 더 다양하고, 더 큰 규모의 탈중앙화 애플리케이션을 개발하지 못하고 있으며, 이는 곧 더 우수하고 기능이 풍부한 탈중앙화 애플리케이션을 개발하지 못하는 것을 의미합니다.

"스마트 콘트랙트/온체인 앱은 단순해야 하며, 복잡하게 만들 필요가 없다"는 말도 안 되는 말을 믿지 마세요!

현실은 원하지 않는 것이 아니라 할 수 없는 것입니다.

AO는 Arweave에서 실행되는 컴퓨터 시스템으로, 검증 가능한 무한한 컴퓨팅 성능을 달성하도록 설계되었습니다. Actor Oriented의 줄임말입니다. 이름에서 알 수 있듯이 AO에서 실행되는 탈중앙화 애플리케이션에는 액터 모델 기반 설계 및 프로그래밍 접근 방식이 필요합니다.

사실 AO가 블록체인(또는 "탈중앙화 인프라")에 액터 모델을 최초로 사용한 것은 아닙니다. 예를 들어, TON의 스마트 컨트랙트는 액터 모델을 사용하여 구축되었습니다. TON에 대해 말하자면, 저는 개인적으로 어떤 면에서는 AO와 상당히 유사하다고 생각합니다.

웹3를 아직 접해보지 않은 웹2.0 개발자들이 다른 "모놀리식 블록체인"과 비교해 AO나 TON의 가장 중요한 특징을 빠르게 이해하는 편리한 방법은 그 위에서 실행되는 스마트 콘트랙트(온체인 프로세스)를 다음과 같이 생각하면 됩니다. "마이크로 서비스"라고 생각하면 됩니다. 그리고 AO 또는 TON은 카프카, 쿠버네티스 등과 같이 이러한 마이크로 서비스의 실행을 지원하는 인프라입니다.

20년 이상 주로 애플리케이션 개발에 집중해 온 베테랑 CRUD 보이로서 저는 개인적으로 AO와 TON과 같은 비모놀리식 블록체인의 출현을 매우 기쁘게 생각하며, 이들의 발전을 기대하고 있습니다. 아래에서는 애플리케이션 개발자의 관점에서 AO에 대한 저의 견해를 이야기하고자 하며, 많은 부분이 성숙하지 않을 수 있습니다. 일부 앱 개발자는 진심어린 마음으로 공감할 수도 있을 것입니다.

블록체인에 액터 모델을 적용하는 것이 정말 필요한가요?

정답은 '그렇다'입니다. "대중적 채택"을 달성한 웹2.0 애플리케이션을 살펴보면 알 수 있습니다.

마이크로서비스 아키텍처(MSA), 이벤트 중심 아키텍처(EDA), 메시지 통신 메커니즘, 최종 일관성 모델, 샤딩, ...... 등 수많은 아키텍트들이 이미 웹2.0 애플리케이션을 '대규모'로 만드는 방법을 알고 있으며, 그 명칭이 무엇이든 항상 액터 모델과 공통점을 가지고 있습니다. 무엇이라고 부르든 항상 액터 모델과 공생합니다. 이러한 개념 중 일부는 한 가지의 다른 측면이라고 할 수도 있습니다. 따라서 다음 글에서는 마이크로서비스와 액터를 구분하지 않고 동의어로 생각하시면 됩니다.

오늘날 인터넷의 번영은 이러한 설계자들의 지혜 덕분입니다. 그들은 탐구하고, 연습하고, 요약하여 결국 완전한 엔지니어링 관행 시스템을 개발했습니다.

웹3 인프라로서 AO는 훌륭한 역할을 합니다. 적어도 제 생각에 AO는 현재 웹3 분야 최고의 탈중앙화 메시징 에이전트로서 큰 잠재력을 보여주었습니다. 전통적인 웹2.0 애플리케이션 개발자라면 그 중요성을 즉시 이해할 수 있을 것입니다. 오늘날의 많은 대형 인터넷 애플리케이션을 카프카나 카프카와 유사한 메시징 에이전트 없이 '프로그래밍'하는 것을 상상할 수 있을까요?

이론적으로는 액터 모델이 여러 면에서 우수하지만, 제 생각에는 액터 모델과 마이크로서비스 아키텍처는 특정 애플리케이션, 특히 대규모 애플리케이션을 개발하기 위해 개발자가 감당해야 하는 골치 아픈 문제입니다.

기술 전문가가 아닌 독자들에게 이 점을 설명하기 위해 간단한 예를 들어 보겠습니다. 전 세계의 모든 은행이 단일화된 시스템인 '월드 컴퓨터'를 기반으로 비즈니스를 수행한다고 가정해 보겠습니다. 따라서 중국공상은행의 고객인 장산이 중국상업은행에 계좌가 있는 리시에게 100달러를 송금할 때 개발자는 다음과 같이 이체 프로그램을 코딩할 수 있습니다.

1. 거래(또는 '트랜잭션')를 시작합니다. "트랜잭션"은 영어로 같은 단어입니다)

2. 장산의 계좌에서 100달러를 차감합니다.

3. 리시의 계좌에 100달러를 추가합니다.

4. 트랜잭션을 제출합니다.

위 단계 중 어떤 단계가 잘못되더라도, 예를 들어 3단계인 리시의 계좌에 금액을 추가하는 단계가 어떤 이유로 실패하면 전체 작업이 아무 일도 없었던 것처럼 롤백됩니다. 그런데 이런 방식으로 프로그램을 작성할 때 우리는 이를 '강력한 일관성' 모델이라고 부릅니다.

전 세계의 컴퓨터가 마이크로 서비스 아키텍처(MSA) 시스템이라면 어떨까요?

ICBC 계정을 관리하는 마이크로서비스(또는 액터)와 중국공상은행 계정을 관리하는 마이크로서비스가 동일할 가능성은 거의 없습니다. 두 마이크로서비스가 실제로 동일하지 않다고 가정하고, 전자를 액터 ICBC, 후자를 액터 CMB라고 부르겠습니다. 이 시점에서 개발자는 다음과 같이 송금 코드를 작성해야 합니다.

1. 액터 ICBC는 먼저 "장산이 리시에게 $100를 송금합니다"라는 정보를 다음과 같이 기록합니다. 액터 ICBC는 장산의 계좌에서 100달러를 차감하고 액터 CMB에게 "장산이 리시에게 100달러를 이체했습니다"라는 메시지를 보냅니다.

2. 액터 CMB는 메시지를 수신하고 리시의 계좌에 100달러를 추가한 후 액터 ICBC에게 "리시가 리시에게 100달러를 이체했습니다"라는 메시지를 보냅니다.

3. 액터 CMB가 메시지를 수신하고 리시의 계정에 100달러를 추가한 후 액터 ICBC에게 "리시가 장산으로부터 100달러를 받았습니다"라는 메시지를 보냅니다.

3. 액터 ICBC가 메시지를 수신하고 "장산이 리시에게 100달러를 성공적으로 이체했습니다"로 기록합니다.

위 과정은 "모든 것이 정상"인 과정입니다. 하지만 두 번째 단계인 "Li의 계좌에 $100 추가"와 같은 단계 중 하나에 문제가 발생하면 어떻게 될까요?

개발자는 이러한 문제에 대비하여 다음과 같은 처리 로직을 작성해야 합니다.

• 액터 CMB가 액터 ICBC에 "ZhangSan에서 LiSi로 $100를 이체하는 데 실패했습니다! ".

• 액터 ICBC가 메시지를 수신하고 장산의 계좌에 $100를 추가한 후 "장산에서 리산으로 $100 이체, 실패"라고 기록합니다.

이 절차는 최종 일관성 모델을 사용하여 호출하는 방식으로 작성되었습니다.

기술 전문가가 아닌 독자도 모놀리식 애플리케이션을 개발하는 것과 MSA 애플리케이션을 개발하는 것의 엄청난 작업량 차이를 시각화할 수 있을 것입니다. 위에서 설명한 전송 예시는 기능이 아닌 애플리케이션이라고 부른다면 매우 단순한 애플리케이션에 불과하다는 점을 명심하세요. 대규모 애플리케이션의 기능은 이 예시보다 훨씬 더 복잡한 경우가 많습니다.

이 마이크로서비스는 얼마나 커야 하나요?

다시 말해, "이 마이크로서비스가 너무 커서 둘로 나눠야 할까요?"라는 질문입니다.

유감스럽게도 이 질문에 대한 표준적인 답은 없으며, 이는 예술입니다. 마이크로서비스가 작을수록 필요에 따라 새 인스턴스를 생성하고 이동하여 시스템을 최적화하기가 더 쉽습니다. 그러나 마이크로서비스의 규모가 작을수록 위에서 설명한 것처럼 개발자가 복잡한 프로세스를 구현하기가 더 어려워집니다.

그런데 애플리케이션을 여러 개의 마이크로서비스로 분할하는 것을 데이터베이스 설계 관점에서 "샤딩"이라고 합니다. 마이크로서비스 아키텍처의 모범 사례 중 하나는 각 마이크로서비스가 자체적으로 하나의 로컬 데이터베이스만 사용한다는 것입니다. 간단히 말해, 샤딩은 수평적 확장을 가능하게 합니다. 데이터 세트가 너무 커져서 기존 방식으로는 처리할 수 없게 되면, 이를 더 작은 조각으로 나누는 것 외에는 (확장할 수 있는) 다른 방법이 없습니다.

마이크로서비스 분할 문제로 돌아가겠습니다. 이 기술을 연습하기 위해서는 몇 가지 사고 도구의 사용법을 익혀야 하는데, DDD의 "Aggregate"는 꼭 필요한 도구 중 하나입니다. 소프트웨어 설계에서 '핵심 복잡성'을 없애는 데 도움이 됩니다.

전술적 수준에서 어그리게이션은 DDD에서 가장 중요한 개념 중 하나라고 생각합니다.

집계란 무엇인가요? 집계는 개체 간, 특히 엔티티 간에 경계를 설정합니다. 집계는 반드시 집계 루트 엔터티와 불확실한 수의 집계 내 엔터티(또는 비집계 루트 엔터티)를 포함해야 하며, 오직 집계 루트 엔터티만 포함해야 합니다.

애그리게이션 개념을 사용하여 애플리케이션이 제공하는 도메인을 분석하고 모델링한 다음, 코딩할 때 마이크로서비스를 애그리게이션별로 세분화할 수 있습니다. 가장 간단하게는 각 집계를 마이크로서비스로 구현하면 됩니다.

그러나 코딩에 능숙하다고 해도 처음부터 이런 종류의 작업을 제대로 수행할 수 있다고 보장할 수는 없습니다. 이 때 모델링 결과를 최대한 빨리 검증하고 제대로 작동하지 않을 경우 푸시백할 수 있는 도구가 매우 유용합니다.

대규모 웹2.0 애플리케이션을 AO 에코시스템으로 마이그레이션하는 데 걸림돌이 되는 또 다른 요소는 무엇인가요?

언어 및 애플리케이션 런타임 문제에 대해 말씀드리고 싶습니다.

AO는 데이터 프로토콜입니다. AO 네트워크의 다양한 '단위'가 협업할 수 있는 방법을 정의하는 일련의 인터페이스 사양이라고 생각하시면 됩니다. 현재 AO의 공식 구현에는 AO 프로세스 개발을 간소화하도록 설계된 WASM 기반 가상 머신 환경과 WASM으로 컴파일된 Lua 런타임 환경(ao-lib)이 포함됩니다.

Lua는 작고 아름다운 언어입니다. 일반적으로 Lua의 강점은 가볍고 다른 언어에 쉽게 임베드할 수 있어 게임 개발과 같은 특정 시나리오에서 특히 유용하다는 점으로 알려져 있습니다. 하지만 대규모 인터넷 애플리케이션을 개발하기 위한 주류 선택은 아닙니다. 대규모 인터넷 애플리케이션 개발에서는 보다 포괄적인 에코시스템과 도구 체인은 물론 광범위한 커뮤니티 지원을 제공하는 Java, C#, PHP, Python, JavaScript, Ruby 등의 언어를 선호하는 경우가 많습니다.

일부에서는 이러한 모든 언어를 WASM 바이트코드로 컴파일하여 WASM 가상 머신에서 실행할 수 있다고 주장할 수도 있습니다. 하지만 사실 WASM은 웹 프런트엔드 개발 영역에서는 강점이 있지만, 인터넷 애플리케이션의 백엔드 런타임 환경으로 WASM을 채택하는 것은 현재 주류 옵션이 아닙니다. 스마트 컨트랙트(온체인 애플리케이션)는 웹 3.0 시대의 '새로운 백엔드'라는 점에 유의하세요.

요약

위에서는 마이크로서비스 아키텍처 또는 액터 모델을 채택할 때의 장점과 애플리케이션 개발에 가져오는 복잡성에 대해 설명했습니다. 이러한 복잡성 중 일부는 피할 수 없습니다. 예를 들어, 메시지 통신을 기반으로 '최종 일관성'을 달성하는 것은 보다 엔지니어링된 웹2.0 환경에서도 이미 많은 개발자에게 어려운 과제입니다. 초기 AO 플랫폼에서 디앱을 개발하면 이러한 과제가 더욱 두드러지게 나타나는데, 물론 이는 충분히 이해할 수 있는 일입니다. 이에 대한 예시는 아래 링크된 글의 시작 부분에 나와 있습니다.

https://github.com/dddappp/A-AO-Demo?tab=readme-ov-file#an-ao-dapp-development-demo-with-a-low-code

퍼블릭 체인을 위한 싸움은 앱 개발자들의 전쟁이라는 것을 우리 모두 알고 있습니다. 그렇다면 이 경우 AO는 어떻게 개발자들을 이길 수 있을까요?

이미 '대중적 채택'을 달성한 웹2.0으로부터 계속 배워야 한다고 생각합니다. 여기에는 인프라뿐만 아니라 개발 방법론, 도구, 소프트웨어 엔지니어링 관행에 대한 학습도 포함됩니다. 다음 글에서는 제가 강력하게 믿는 한 가지 해결책인 로우코드 개발을 소개하겠습니다.