(Review) Towards Modern Development of Cloud Applications

date

Apr 11, 2024

slug

towards-modern-development-of-cloud-applications

author

status

Public

tags

Paper Review

summary

Google Service Weaver의 근간이 되는 논문 리뷰

type

Post

thumbnail

category

paper-review

updatedAt

Oct 1, 2025 06:23 AM

Index

• Background

• Problem & Challenge of Current MSA

• Proposed Solutions

• Contributions

• Problems of This Paper

• Conclusion

Background

Monolithic Architecture vs Micro Service Architecture

• 모놀리스 (Monolith) 아키텍처는 하나의 소프트웨어를 구성하는 모든 모듈과 코드를 하나의 프로젝트에서 관리하는 것입니다. 일반적으로 생각하는 웹 애플리케이션 개발 프로젝트를 하나 생각하면 될 것 같습니다.

• MSA 아키텍쳐는 하나의 소프트웨어를 구성하는 컴포넌트들을 독립적인 프로젝트들로 분리하여 관리하는 것입니다. 위의 웹 애플리케이션을 예시로 생각했을 때, 구분이 되는 각 도메인(유저, 결제, 상품 등등)을 모두 별개의 (백엔드 애플리케이션 + DB) 환경의 조합으로 구분(node js, fastapi, spring 등의 Framework + MySQL, Postgres, Oracle 등의 DB)할 수 있다고 생각하면 될 것 같습니다.

• High Scalability ⇒ 각 Micro Service는 독립적이므로 Scale up, out, down 등이 용이해서 resource 사용량을 최적화할 수 있습니다.

• High Availability ⇒ Micro Service들은 독립적이고 Scalable하며 K8s나 Cloud Service 등으로 쉽게 Auto Scaling, Self Healing이 가능하고, 로드밸런싱 등으로 분산처리가 가능합니다.

• Continuous Deployment ⇒ 각 Micro Service를 개별적으로 배포가 가능함으로써 전체 아키텍처를 재배포하지 않고 지속적으로 업데이트 가능합니다.

• Small Codebase ⇒ 각 Micro Service는 전체 아키텍처에 대해서 상대적으로 작은 규모의 코드베이스로 개발, 유지보수 등이 용이합니다.

Must MSA?

EDM (Event Driven Micro Service)

DDD (Domain Driven Architecture)

효율?

플랫폼, 인프라 학습 비용

Problem & Challenge of Current MSA

• Performance

• Correctness

• Manage

• Freeze APIs

• Development

• 완화하는 것을 목표로 Framework와 Process를 개발 중이지만 완전히는 개선x (Terraform과 Jenkins 등을 예시로 드는데 음…뭔가 최신은 아니네요)

• gRPC, Protocol Buffer 등으로 개선 중이었다하는데 이건 본인들 연구 한번 참조해준 느낌입니다.

• 개발자가 메뉴얼하게 애플리케이션을 여러 바이너리로 분할한다고 “전제”하기 때문

• 애플리케이션 바이너리가 개별적으로 Production에 Release된다고 “전제”하기 때문

• 애플리케이션을 Modularized Monolithic으로 작성 (logical component로 구분)

• Dynamically / Automatically하게 logical component를 physical process로 전환/할당할 수 있는 Runtime

• 애플리케이션을 atomically하게 배포해서 버전간 interaction 발생 방지

Proposed Solution

• 개발자가 비즈니스 로직에만 신경을 쓰도록, 단일 바이너리 Module형 애플리케이션을 작성할 수 있는 추상화가 포함된 Programming Model

• 위의 Programming Model 맞춤 build, deploy, optimize 모두 포함된 Runtime

Programming Model

Component

• 애플리케이션은 독립적인 Component들로 구성

• Interface로 정의되며, 외부에서는 Interface의 Method로만 Component에 접근가능

• State를 가지며 Long-lived한 독립적 Computational agent 단위 (대충 Micro Service 백엔드를 잘 돌려말한 것 같습니다.)

• 개발자는 Component 내부 구현만 신경쓰고, Physical Process에는 신경 안쓰도록

• Component는 여러 node에 hosting될 수 있음 (중복 존재 가능)

• 동일한 node간 Component 통신은 Local Procedure Call로 이루어짐

• Runtime이 Component의 분산 실행, 배치, Scaling 등을 결정 (K8s의 Control Plane 역할?)

• node가 다를 때는 Runtime에 의해 LPC → RPC (Remote Procedure Call)로 전환

API

// reverser.go
package main

import (
    "context"

    "github.com/ServiceWeaver/weaver"
)

// Reverser component.
type Reverser interface {
    Reverse(context.Context, string) (string, error)
}

// Implementation of the Reverser component.
type reverser struct{
    weaver.Implements[Reverser]
}

func (r *reverser) Reverse(_ context.Context, s string) (string, error) {
    runes := []rune(s)
    n := len(runes)
    for i := 0; i < n/2; i++ {
        runes[i], runes[n-i-1] = runes[n-i-1], runes[i]
    }
    return string(runes), nil
}

// main.go
package main

import (
    "context"
    "fmt"
    "log"

    "github.com/ServiceWeaver/weaver"
)

func main() {
    if err := weaver.Run(context.Background(), serve); err != nil {
        log.Fatal(err)
    }
}

type app struct{
    weaver.Implements[weaver.Main]
    reverser weaver.Ref[Reverser]
}

func serve(ctx context.Context, app *app) error {
    // Call the Reverse method.
    var r Reverser = app.reverser.Get()
    reversed, err := r.Reverse(ctx, "!dlroW ,olleH")
    if err != nil {
        return err
    }
    fmt.Println(reversed)
    return nil
}

func (g *greeterComponent) Greet(ctx context.Context, name string) (string, error) {
    // 데이터베이스에서 사용자 정보 가져오기
    user, err := g.userRepo.GetByName(ctx, name)
    if err != nil {
        return "", err
    }

    // 외부 API 호출하여 인사말 생성
    greeting, err := g.greetingService.Generate(ctx, user.Language)
    if err != nil {
        return "", err
    }

    // 결과 가공 및 반환
    return fmt.Sprintf("%s, %s!", greeting, user.Name), nil
}

Runtime

• Code Generation

• Application-Runtime Interaction

• Atomic Rollout

Contribution

• Transport Placement, Scaling

• Routing

• Automated Testing

• Prototype Implementation

• Networking Abstraction

Problems of This Paper

Discussion

• Multiple Application Binary

• Integration with External Services

• Distributed Systems Challenge

• Programming Guide

Problem

• Business Logic 구현 (Logical)과 Physical Process를 구분했으나 실제 Component(Micro Service)간 Coupling은 없어지지 않음.

• 사용자 편의성 및 통신 성능 관련 기여 대부분이 gRPC(Google Remote Procedure Call)를 최대한 활용한 것에 의존

• 테스트 Application을 Go로 통일하고 RPC 개념 자체에 의존하기 때문에, 본인들이 제시하는 “language-agnostic”이 와닿지 않음.

• 실험이 단순 HPA이기 때문에 “Cloud Application”이라는 거대한 범주를 고려했다고 보기 힘듦

• Runtime, Proclet은 K8s를 한번 더 구현한 느낌.

Conclusion