안녕하세요, 짧은머리 개발자에요.

오늘은 초기 스타트업인 회사에서 CI/CD 파이프라인을 도입하고 이에 대한 정책 결정에 대한 고민과 솔루션을 공유하려 해요.

우선 제가 입사하기 전까지 회사는 데브옵스 엔지니어가 없었기에 CI/CD 파이프라인 마찬가지로 없었고, 클라우드 내에 딱히 정해진 정책 없이 애플리케이션을 운영중하고 있었어요. 그렇기 때문에 현재 운영중인 애플리케이션의 버전을 알 수 없었고, 언제 어떻게 배포되었는지 추적하기 어려운 환경이었어요.

이러한 환경에서 제가 CI/CD 파이프라인을 도입하기 위해 회사의 현재 상황을 분석하고 마련한 예비 요구사항은 다음과 같아요.

1. Continuous Integration, Continuous Delivery, Continuous Deploy 각 단계에서 현재 상태와 결과를 알 수 있어야 한다.
2. 현재 운영중인 애플리케이션의 버전과 상태를 알 수 있어야 한다.
3. 자동화된 시스템을 통해 개발자는 CI/CD를 수행할 수 있어야 한다.
   • 기존에는 CI ~ Deploy까지 한 번에 무조건 실행되어서 애플리케이션의 테스트 없이 곧바로 Production에 올라가는 문제가 있었어요. 이를 해결하기 위해 “적절한 자동화”를 통해 각자가 담당한 애플리케이션을 관리, 배포할 수 있게 하고자 했어요.
4. DevOps Engineer를 제외한 개발자는 CI/CD 각 단계가 어떻게 진행되는지 몰라도 된다.
   • DevOps Engineer가 생긴 만큼 개발자는 각자의 영역에 충실할 수 있게끔 하고자 했어요.
5. Git Ops와 융합되어야 한다.
   • 회사에서 GitHub Enterprise를 이용중이었고, 따라서 GitOps와 융합하고자 했어요.

1, 2번을 묶어서 기존 시스템의 가장 큰 문제점인 현재 운영중인 애플리케이션의 버전을 알 수 없는 점과 각 단계에서의 결과와 상태를 앎으로써 배포 후보군이 되는 애플리케이션이 어떤 내용을 갖는지 추적할 수 있게 하고자 했어요.

GCP Artifact Registry에 대한 Git Actions 접근 허가하기

GCP의 경우 워크로드 아이덴티티 제휴(Workload Identity Federation)를 통해 외부 서비스와의 융합을 지원하는데요, Git Actions에서 GCP에 접근 또한 이를 활용하여 해결할 수 있어요.

워크로드 아이덴티티 제휴는 쉽게 말해 GCP의 Iam Roles for Service Accounts(IRSA)라 볼 수 있어요. 즉, GCP의 리소스를 이용하는 작업(Workload)에 대해 신원(Identity)을 제공하는 기능이에요.

Git Actions에서 GCP의 서비스인 Artifact Registry에 접근할 필요가 있었고, 이를 위한 워크로드 아이덴티티 제휴를 구성했어요.

생성할 서비스 계정은 워크로드 아이덴티티 풀과 Artifact Registry에 접근하기 위해서 다음의 Role들을 가지고 있어요.

• roles/iam.workloadIdentityUser
  • 서비스 계정을 통해 GCP의 워크로드 아이덴티티를 사용하기 위함이에요.
• roles/iam.serviceAccountUser
  • 서비스 계정을 통해 GCP 리소스에 접근하기 위함이에요.
• roles/artifactregistry.writer
  • 서비스 계정을 통해 Artifact Registry에 Git Actions로 생성된 컨테이너 이미지를 업로드하기 위함이에요.
• roles/iam.serviceAccountTokenCreator
  • 서비스 계정에 대한 단기 인증정보를 만들 수 있도록 해요. 이를 통해 Git Actions 워크 플로우에 정의된 서비스 계정의 OAuth 2.0 토큰을 획득하고 명시된 권한을 사용할 수 있어요.

또한 아무 Git 리포지터리에서 실행되는 Git Actions의 워크플로우를 통해 우리의 GCP 인프라에 접근하면 안되기 때문에 다음과 같이 GitHub 계정 혹은 리포지터리에 대한 제한 및 격리를 시켜야 합니다.

module "oidc_gh" {
  ...
  sa_mapping = {
    "github-sa" = {
      sa_name   = google_service_account.github_sa.id
      attribute = "attribute.repository_owner/{{ Organization }}"
    }
  }
  ...
}

# module.oidc_gh 중
resource "google_service_account_iam_member" "wif-sa" {
  for_each           = var.sa_mapping
  service_account_id = each.value.sa_name
  role               = "roles/iam.workloadIdentityUser"
  member             = "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.this.name}/${each.value.attribute}"
}

• Git Actions OIDC에서 제공하는 Claims은 다음 링크에서 확인할 수 있어요. https://token.actions.githubusercontent.com/.well-known/openid-configuration

이렇게 GCP와 Git Actions에 대한 WIP를 설정했다면, Git Actions에서 실제로 접근 가능한지 테스트해야 해요.

GCP의 경우 Git Actions에서 사용 가능한 Git Action을 제공하고 있는데요, google-github-actions/auth@v2를 통해서 GCP 서비스 계정의 권한을 획득할거에요.

build-and-delivery:
  runs-on: ubuntu-latest
  permissions:
    id-token: "write"
  steps:
	- name: "GCP Auth"
	  id: "gcp-auth"
	  uses: "google-github-actions/auth@v2"
	  with:
	    token_format: "access_token"
	    workload_identity_provider: "{{ 워크로드 아이덴티티 제공자 }}"
	    service_account: "{{ 워크로드 아이덴티티 서비스 계정 }}"
	    access_token_lifetime: "300s"

해당 Git Actions를 실행하면 GCP의 OAuth 2.0 토큰을 해당 잡에서 사용할 수 있게 해요.

• 이를 위해 Git Actions에서 토큰에 대한 권한을 설정해야 해요. permissions의 id-token 속성을 write로 구성해야 합니다.
• Github OIDC Provider는 클라우드 제공자로 부터 토큰을 전달받아 사용하는데, 여기서는 GCP의 OAuth 2.0 토큰을 받아 사용합니다.

이렇게 획득한 OAuth 2.0 토큰을 바탕으로 Artifact Registry 로그인 하여 이미지를 업로드 할 수 있어요.

- name: "Login to GAR"
  uses: docker/login-action@v3
  with:
    registry: asia-northeast3-docker.pkg.dev
    username: oauth2accesstoken
    password: ${{ steps.auth.outputs.auth_token }}

- name: "Docker auth with GCP Auth"
  run: |
    gcloud auth configure-docker asia-northeast3-docker.pkg.dev --quiet

Continuous Integration ~ Continuous Delivery 스텝 정의하기

Git Actions를 통해 Google Artifact Registry에 대한 권한을 획득했으니 실질적으로 CI ~ Delivery 까지의 Step을 정의해야 해요.

Continuous Integration은 한 제품을 개발하는 많은 개발자들이 각자의 코드를 융합하고 문제없이 돌아가는지 확인하며 제품으로 빌드하는 행위를 하도록 다음과 같이 정의했어요.

1. 코드 테스트 단계
   • Git Actions에서 GCP Artifact Registry로 잘 접근이 되는지 확인해요.
   • 코드에 대한 테스트를 수행해요.
2. 코드 빌드 단계
   • 코드 테스트 단계를 통과했다면 합쳐진 코드를 바탕으로 제품을 빌드해요.
   • 우리의 경우 Container 환경에서 애플리케이션을 운영하기 때문에 Container Image를 생성하는 행위를 의미해요.
3. 제품 배달 단계
   • 생성된 Container Image를 GCP Artifact Registry로 업로드해요.

특히 우리는 예비 요구사항에서 각 스텝에 대한 결과와 상태를 알 수 있어야 한다.는 요구사항이 있었어요. 이를 지원하기 위해 CI ~ Delivery에 Slack Notification을 전송하는 Job을 추가했어요.

Slack Notification은 총 두 단계로 구성되어 있어요.

1. Git Actions 시작 알림 메시지
   • 해당 메시지를 통해서 Git Actions의 결과물로 나올 컨테이너 이미지에 대한 정보를 함축적으로 전달해요.
   • 변경에 대한 Commits List를 추가하여 Slack의 쓰레드 메시지로 전달해요.
2. Git Actions 종료 알림 메시지
   • Git Actions의 성공 여부와 Git Actions 링크 정보를 포함한 메시지를 전달해요

• 단순히 알림 메시지를 단순히 보내는 것에 끝내지 않고 데이터베이스에 저장하여서 해당 커밋 혹은 릴리즈를 통해 배달된 버전이 어떤 변경점을 갖는지 추후에 확인할 수 있게 했어요.

슬랙에 메시지를 보냄으로써 생성된 이미지에 대해 변경사항을 확인할 수 있고 추후 애플리케이션 배포 시에도 활용하고자 했어요.

독립된 Continuous Deploy

이제 배달 된 제품 빌드에 대해 배포할 차례에요. 기존의 문제점에서 현재 운영중인 애플리케이션의 버전을 알 수 없는 점을 해결하기 위해 배포에 대한 파이프라인을 앞 단계와 분리했어요.

웹 대시보드를 통해 배포하고자 하는 버전과 그 변경사항을 알 수 있게 했고, 현재 배포된 애플리케이션 차트가 어떻게 구성되어 있는지 확인할 수 있도록 배포 서버를 개발 했어요. 해당 서버의 경우 코드를 정리한 다음에 오픈소스로 공개할 예정이에요.

우리 회사는 GKE를 이용해서 애플리케이션을 운영하고 있는데, 실제 쿠버네티스에 배포에 대한 책임은 Argo CD에 위임했어요.

즉, 직접적으로 Continuous Deploy가 해결해야 하는 것은 Argo CD가 알 수 있도록 애플리케이션 매니페스트를 수정해주면 돼요.

여기까지 CI/CD 파이프라인을 설계하며 고민했던 내용을 정리했어요.

읽어주셔서 고맙습니다 🙂

안녕하세요, 짧은머리 개발자에요.

제가 근무하고 있는 회사는 Google Cloud Platform을 이용하여 서비스를 운영하고 있어요. 특히 컨테이너의 시대인 만큼 Google Kubernetes Engine을 이용하여 컨테이너를 관리하고 있는데요, 오늘은 처음 GKE를 도입하면서 GCP의 Cloud Load Balancer를 연동하며 했던 고민을 공유하려 해요.

먼저 GCP는 관리중인 서비스를 외부 혹은 내부에서 접근할 수 있도록 Cload Load Balancing이라는 명칭의 PaaS를 제공하고 있어요. CLB라고 불리는 이 서비스는 GCP에 배포된 서비스들에 고성능 부하 분산 기능을 제공하는 역할을 해요. AWS에는 ALB(NLB)라는 솔루션이 있어요.

우리 회사가 GKE에서 운영중인 서비스들에 대해 외부에서 접근할 수 있도록 하는것이 목표였는데요, GCP에서는 일반적으로 GKE의 외부 노출을 위해 다음의 솔루션을 제공해요.

1. 쿠버네티스 게이트웨이 API를 이용한 외부 노출
2. 쿠버네티스 인그레스를 이용한 외부 노출
3. 서비스 + CLB 직접 관리를 통한 외부 노출

우리 회사가 선택한 방법은 3번인데, 그 이유는 다음과 같아요.

1. Load Balancer의 직접 관리를 통해 보다 폭 넓은 제어가 필요하다.

• 2번의 경우 CLB가 자동으로 생성, 관리되는데 이 경우 직접적인 제어가 까다로웠어요. 특히 인그레스 혹은 게이트웨이를 생성할 때 마다 CLB가 생성되는데, 이는 불필요한 CLB의 증가로 인해 관리가 복잡해지고 비용이 늘어나는 원인이 되기도 했어요.

2. SSL에 대한 폭 넓은 제어가 필요하다.1, 2번의 경우 인그레스, 게이트웨이가 늘어날 때 마다 해당 요청을 처리하는 도메인에 대한 SSL을 명시해 주고 관리해야 하는데 이것은 불필요한 관리를 유발했어요.

• 특히 초기의 경우 도메인에 대한 asterisk를 SSL에 등록하지 않고, 우리 회사에서 사용하는 도메인들에 대해 SSL을 발급, 관리했는데 이는 매우 까다로운 절차였어요.
• 인증서를 관리하기 위해 Google Certificates Manager를 이용하고 있어요. 문제는 DevOps 관점에서 SSL의 변경 혹은 추가가 일어날 때, Terraform을 이용한 생성 및 CLB 할당에서 인증서 관리를 마무리 하고 싶었어요.

3. L7 뿐만 아니라 L4에 대한 트래픽 제어도 필요하다.

• 블록체인을 운영하는 회사로서 노드에 대한 RPC 통신을 지원해야 했기 때문에 CLB를 통한 직접적인 관리가 필요했어요.

4. 회사의 규모가 크지 않은만큼 필요한 수의 CLB만 유지하고 싶었어요.

• GCP의 CLB는 고가용성을 제공하는 만큼 증가하는 트래픽에 대한 CLB를 분리하여 운영할 필요가 없었기에, 필요한 CLB의 숫자만 유지하고 싶었어요.

GCP에서는 최종적으로 GKE의 서비스에 접근하기 위해 GCP Backend Service와 Network Endpoint Group을 이용해야 해요.

GCP는 이를 지원하기 위해 AutoNeg 쿠버네티스 오퍼레이터를 제공하고 있어요. 이를 통해 쿠버네티스에 배포된 서비스를 바탕으로 GCP Backend Service와 Network Endpoint Group을 생성해 줘요.

이를 위해 쿠버네티스 서비스를 생성할 때 다음의 예시처럼 Backend Service와 NEG에 필요한 정보를 어노테이션에 담아 생성해야 해요.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "nginx-neg-svc"}}}'
  name: nginx-neg-test
  namespace: devops
  labels:
    app: nginx-neg-test
spec:
  ports:
    - port: 80
      protocol: TCP
  selector:
    app: nginx

이처럼 서비스에 AutoNeg를 통해 GKE와 CLB를 융합하며 운영했을 때 다음의 큰 문제가 발생했어요.

• GKE 서비스를 배포할 때, Network Endpoint Group이 생성되는 Zone을 명시할 수 없다.
  • 특히 이는 AWS의 EKS의 경우 AWS Load Balancer Controller와 Target Group Binding 그리고 리스너를 통해 배포되어 있는 EKS Pod에 대한 외부 노출이 가능한데 이에 대해 한번에 지원되지 않는게 의아했어요.

이는 Pod의 Spec이 변경될 때 마다 NEG 위치가 변하는 이슈가 있었고, CLB에서는 변경된 NEG로 다시 설정해 줘야 트래픽의 정상적인 처리가 가능했어요. 즉 Downtime이 발생할 수 있는 위험성을 가지고 있어요.

이를 해결하기 위해 GCP의 GKE 외부 노출 방법중 Ingress를 이용하여 애플리케이션을 외부로 노출해 봤어요.

# nginx.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: devops
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-neg-test
  namespace: devops
  labels:
    app: nginx-neg-test
spec:
  ports:
    - port: 80
      protocol: TCP
  selector:
    app: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: devops
spec:
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: nginx-neg-test
                port:
                  number: 80

이 경우 AutoNeg과는 다르게 Ingress로 배포한 서비스는 자동으로 현재 GKE가 배포되어 있는 Region 내의 모든 Zone에 대해 Network Endpoint Groups를 배포하는 것을 확인했고, 머리속에서 이거다! 하는 생각이 떠올랐어요.

GCP의 AutoNeg의 경우 배포되는 Service가 사용할 Network Endpoint Groud에 대해 다음의 규칙을 지키면 이미 생성된 NEG을 활용해요.

• 참고) https://cloud.google.com/knowledge/kb/standalone-network-endpoint-groups-sync-fails-000004875

💡 Note
Updating NEG description is impossible, so this only works if the NEG is used for populating endpoints from a specific set: [Cluster, service name, namespace, port] which does not change.

그래서 저는 AWS의 ALB Controller + Target Group Binding 노하우를 활용하여 다음과 같이 GKE 애플리케이션 외부 노출 정책을 결정했답니다.

1. 인프라에 배포할 애플리케이션 요구사항에 맞춰 CLB, Backend Service, Network Endpoint Group을 먼저 생성한다.

2. Backend Services를 생성하며 생성된 NEG을 연결한다.

• AutoNeg를 이용하여 서비스를 배포할 때 Backend Service와 NEG의 이름을 명시적으로 사용할 수 있어요.
• 이를 적용하기 위해 Backend Service를 생성할 때 쿠버네티스 서비스에 명시할 이름을 스펙으로 설정해야 해요.

3. 쿠버네티스 서비스 배포시 Backend Service를 생성한 스펙을 바탕으로 AutoNeg Annotation을 설정하여 배포한다.

이렇게 할 경우 Pod가 재배포 되면서 스펙에 변경사항이 발생되더라도 자동으로 AutoNeg이 서비스를 검사하여 GCP의 NEG과 Backend Service에 해당하는 서비스를 연결하는것을 확인했고 Downtime 없이 Application을 배포할 수 있었어요.

본 논문은 쿠버네티스의 전신인 Borg System 논문이다.

오늘의 요약

• 즉 구글은 수 십만 개의 잡을 돌리는 클러스터 매니저인 Borg를 개발했다.
• 해당 잡 들은 수 천개의 서로 다른 애플리케이션에서 발생하는데
  • 이들이 어떻게 관리되는지 시스템 유저(서비스 개발자)는 알 필요 없이 Borg System을 만들었다.
    • 자원 관리에 대한 세부 사항 (CPU, Memory, Disk, Network 할당 등)
    • 어느 컴퓨터에서 개발된 서비스가 동작할지
    • 실패되어도 다시 살아난다. (Self Healing)
    • 실패 처리를 유저가 직접하지 않아도 된다.
• 구글은 이러한 시스템을 만들기 위해 구글이 실행하는 서비스를 두 가지로 분류했다.
  • Long Running Services
    • End User에게 제공되는 Production
      • GMail, Google Search, Google Docs, 그리고 구글 내부의 BigTable 등
    • 즉 절대 죽어서는 안되는, 수 µs ~ 몇백 ms 라는 짧은 latency를 가져 사용자에게 불편함을 주면 안되는 서비스
    • 매우 많은 리소스를 사용한다.
    • 쉽게 말해 Production Level
  • Batch Jobs
    • 짧게는 수 초, 길게는 수 일 동안 작업되는 서비스
    • 단기적 성능 변동에 훨씬 덜 민감하다.
    • 쉽게 말해 Non-Production Level
• 해당 작업을 수행하는 머신들은 Cell이라 불리는 곳에 저장된다.
  • 셀 안에 많은 머신이 포함되며, 해당 머신들은 고성능 데이터 센터 규모로 정의된 단일 클러스터에 포함된다.
    • 단일 클러스터에 속하는 머신들은
      • High Performance, Datacenter Scale Network 구조로 정의
      • 해당 클러스터는 단일 데이터센터 빌딩에 존재하고, 이러한 빌딩들의 집합이 site를 만든다.
      • 클러스터는 일반적으로 하나의 거대한 셀의 주인이고(hosts)
        • 몇 개의
          • 작은 스케일의 테스트를 갖거나
          • 특수 목적 셀을 가진다.
      • Single Point of Failure를 피한다.
    • 중간 사이즈의 셀들은
      • 테스트 셀을 제외하고 대략 1만대 이상의 머신을 가지는데, 몇 몇은 더 큰 규모를 가진다.
      • 해당 머신들은 서로 이질적인 많은 디멘션을 가지는데,
        • CPU, RAM, Network, Disk 등
        • Processor Type, Performance, 외부 IP 주소 등
  • 놀랍게도 Borg System은 이러한 차이점 및 특징을 시스템 사용자(개발자 등)에게 철저히 숨겨 개발자들이 본연의 업무(개발)에만 집중할 수 있도록 한다.

Abstract

• 구글의 Borg 시스템은 수 십만 개의 잡을 돌리는 클러스터 매니저다.
  • 해당 잡 들은 수 천 개의 서로 다른 애플리케이션으로 부터 발생하는데
  • 해당 애플리케이션은 수 만 개의 머신에서 동작한다.
• Borg 시스템은 High Utilization을 달성하는데
  • 제어 허용(admission control), 효율적인 작업 패킹, 과다 할당(over commitment to machine), 그리고 프로세스 레벨의 성능 격리를 통한 머신 공유(자원 공유)
  • 를 조합하여 사용함으로써
• Bog 시스템은 고가용성 runtime 애플리케이션을 지원한다.
  • Fault Recovery 시간을 최소화하고
  • 관련있는 실패할 가능성을 줄이는 스케줄링 정책을 수립함으로써
• Borg 시스템은 사용자의 삶을 단순화한다.
  • Declarative Job Specification Language, Name Service 통합, 실시간 작업 모니터링 및 시스템 동작을 분석하고 시뮬레이션하는 도구를 제공하여
• 우리는 Borg System의 아키텍처와 Features, 중요한 디자인 결정, Borg System의 몇몇 정책 결정에 대한 질적인 분석, 10년간의 운영 경험에서 얻은 교훈에 대한 질적 교훈을 제시한다.

1. Introduction

• Borg System이라 부르는 클러스터 관리 시스템은
  • 관리하고, 스케줄하고, 시작하고, 재시작하고, 그리고 모니터링한다.
  • 구글이 실행하는 모든 애플리케이션의 Full Range로부터
• 해당 본문은 이것이 어떻게 되는지 설명한다.
• Borg는 세 가지 주요 장점을 제공한다.
  • 자원 관리에 대한 세부 사항과 실패 처리와 관련된 세부 사항을 숨김으로써, 유저는 애플리케이션 개발에 집중할 수 있다.
  • 매우 높은 신뢰성과 가용성을 바탕으로 동작하며, Borg에서 관리되는 애플리케이션 또한 이를 제공받는다.
  • 수만 대의 시스템에서 워크로드를 효율적으로 실행할 수 있도록 한다.
• Borg는 이러한 이슈를 제기한 첫 번째 시스템이 아니다.
  • 하지만 Borg와 같이 큰 스케일, 탄력성과 완전성,에서 실행되는 것은 몇 없다.
• 해당 논문은 이러한 주제를 중심으로 구성되어 있으며
• 10년 이상 프로덕션 환경에서 Borg를 운영하면서 얻은 일련의 정성적 관찰로 결론을 내린다.

2. The User Perspective

• Borg 시스템의 유저는 구글의 개발자와 시스템 관리자(Site Reliability Engineers)다.
  • 구글의 애플리케이션과 서비스들을 실행하는
• 사용자들은 그들의 일을 Borg의 jobs 폼에 맞춰 제출한다.
  • jobs: 하나 이상의 tasks로 구성
  • tasks: 모두 동일한 바이너리 프로그램을 실행
• 각각의 job은 Borg Cell에서 실행되는데
  • Borg Cell은 하나의 유닛처럼 관리되는 머신의 집합이다.
• 본 단락에서 중요한 것은 Borg가 유저에게 어떻게 노출되느냐다.
  • 유저 관점에서 Borg를 어떻게 사용하는지

2.1 The Workload

• Borg Cells는 두 개의 이질적인 주요 파트에서 실행된다.
• 첫 번 째는, “절대로” 죽어서는 안되고, 수 µs ~ 몇백 ms 라는 짧은 latency를 가지는, Long Running Services다.
  • Gmail, Google Docs, Web Search와 같이 End User에게 제공되는 Product들, 그리고 구글 내부의 인프라 서비스(Big Table) 등이 그 예다.
• 두 번 째는, 수 초 ~ 수 일 안에 완료되는 batch jobs다.
  • 이러한 작업은 단기적인 성능 변동에 훨씬 덜 민감하다.
• 워크로드 혼합은 Borg Cell 마다 다르며
  • Borg Cell은 다양한 애플리케이션의 혼합을 실행하는데
    • 애플리케이션은 작업에 따라 다르다. (주요 테넌트에 따라 다양한 애플리케이션 혼합을 실행)
      • 예: 일부 셀은 배치 집약적임
    • 또한 실행 시간에 따라 다르다.
    • 예를 들어
      • 배치 작업은 빠른 시간 안에 실행 되었다가 종료되고
      • End User Facing(Proudcts)는 주간 사용 패턴을 보인다. (오래 사용)
• Borg 시스템은 이들 케이스 모두를 동일하게 잘 처리할 필요가 있다.
• 대표적인 Borg workload는 2011년 5월부터 월 단위 추적이 가능한데, 이는 매우 잘 광범위하게 분석되었다.
• 많은 애플리케이션 프레임워크는 Borg의 Top에서 만들어졌다.
  • Internal Map Reducing System, Flume Java, Millwhell, Pregel 등
• 이들 대부분은 컨트롤러를 가지고 있는데
  • master job 과 하나 이상의 워커 잡을 제출한다.
  • 이들은 YARN의 어플리케이션 매니저와 비슷하다.
    • https://blog.cloudera.com/apache-hadoop-yarn-concepts-and-applications/
    • https://sungsoo.github.io/2014/02/28/yarn-concepts-and-applications.html
• 구글의 분산 저장소 시스템, GFS, CFS, Bigtable, Megastore 모두 Borg에서 동작한다.
• 본 문단에서 명시하는 것은
  • workload를 두 가지로 분류 가능한데
  • production 레벨
    • Long Running Services
  • non-production 레벨
    • Batch Jobs
• 대표적인 셀에
  • production 레벨의 잡은 70% 정도의 CPU, 55%의 메모리를 할당받았으며
    • 이 중 60%, 85% 를 사용중이다.
  • 나머지를 non-production이 할당 및 사용
  • 이 실제 할당량과 사용량의 불일치는 5.5단락에서 자세하게 설명된다.

2.2 Clusters and Cells

셀의 머신은 이를 연결하는 고성능 데이터 센터 규모의 네트워크 패브릭으로 정의된 단일 클러스터에 속한다.

• 단일 클러스터에 속하는 셀의 머신들은
  • High Performance, Datacenter Scale Network 구조로 정의되는데
  • 해당 클러스터는 단일 데이터센터 빌딩에 존재하고, 이러한 빌딩들의 집합이 site를 만든다.
  • 클러스터는 일반적으로 하나의 거대한 셀의 주인이고(hosts)
    • 몇 개의
      • 작은 스케일의 테스트를 갖거나
      • 특수 목적 셀을 가진다.
  • 우리는 몇 개의 단일 실패 지점을 피한다.
• 우리의 중간 셀의 사이즈는 테스트 셀을 제외하여 대략 1만대의 머신의 크기인데
  • 몇 몇은 훨씬 더 크다.
  • 해당 머신들은 이질적인, 많은 디멘션에 속하는데
    • CPU, RAM, Disk, Network의 크기가 다르거나
    • processor type이 다르거나
    • performance가 다르거나
    • Flash Storage 혹은 외부 IP 주소 등 능력이 다르거나
• Borg 시스템은 이러한 차이점 대부분으로부터 사용자를 격리한다.(사용자는 신경쓸 필요 없다.)
  • 셀에서 작업을 실행할 위치를 결정하고
  • 리소스를 할당하고
  • 프로그램 및 기타 종속성을 설치하고
  • 상태를 모니터링하고
  • 실패할 경우 다시 시작하는 등

Problem

• 연속 펄스 부분 수열의 합

darklight

sublimevimemacs

Java

문제 설명

어떤 수열의 연속 부분 수열에 같은 길이의 펄스 수열을 각 원소끼리 곱하여 연속 펄스 부분 수열을 만들려 합니다. 펄스 수열이란 [1, -1, 1, -1 …] 또는 [-1, 1, -1, 1 …] 과 같이 1 또는 -1로 시작하면서 1과 -1이 번갈아 나오는 수열입니다.예를 들어 수열 [2, 3, -6, 1, 3, -1, 2, 4]의 연속 부분 수열 [3, -6, 1]에 펄스 수열 [1, -1, 1]을 곱하면 연속 펄스 부분수열은 [3, 6, 1]이 됩니다. 또 다른 예시로 연속 부분 수열 [3, -1, 2, 4]에 펄스 수열 [-1, 1, -1, 1]을 곱하면 연속 펄스 부분수열은 [-3, -1, -2, 4]이 됩니다.정수 수열 sequence가 매개변수로 주어질 때, 연속 펄스 부분 수열의 합 중 가장 큰 것을 return 하도록 solution 함수를 완성해주세요.

제한 사항

• 1 ≤ sequence의 길이 ≤ 500,000
• 100,000 ≤ sequence의 원소 ≤ 100,000
  • sequence의 원소는 정수입니다.

입출력 예

입출력 예 설명

주어진 수열의 연속 부분 수열 [3, -6, 1]에 펄스 수열 [1, -1, 1]을 곱하여 연속 펄스 부분 수열 [3, 6, 1]을 얻을 수 있고 그 합은 10으로서 가장 큽니다.

Description

• 솔직히 이게 3레벨이라 믿기지 않는 문제. 1레벨이면 충분할 것 같다.
• 설명에서 주어진 바와 같이 배열의 각 인덱스에 1과 -1을 번갈아가며 곱해준 것과 -1과 1을 번갈아가며 곱해준 것 중 연속 합이 큰 것을 고르면 된다.
• DP를 이용해 쉽게 풀 수 있는데, 현재 값을 더 했을 때의 최대 값과 더하지 않았을 때의 최대 값을 비교하면 된다.
• 최대 값을 저장하기 위한 1차원 DP 배열을 선언한다.
  • long[] sum = new long[length]
• 주어진 예제를 이용해 설명해 보면
  • 먼저 1, -1, 1, -1, … 을 곱한 배열은 다음과 같다.
  • [2, -3, -6, -1, 3, 1, 2, -4]
  • 여기에 대해 0번 인덱스 부터 하나씩 옮겨가며 다음과 같이 비교한다.
    • if 문의 비교연산은 다음 의미를 갖는다.
      • 이전까지의 합과 현재 합을 더했을 때, 0보다 큰가? 즉, 음수가 되지 않았는가에 대한 비교이다.
      • 만약 0 이하라면, sum[i] → 0으로 설정하여 현재 인덱스 까지의 연산을 초기화한다.
  • if(sum[i-1] + sequence[i] > 0) sum[i] = sum[i-1] + sequence[i]; else sum[i] = 0;
  • 그런 다음, answer와 현재까지의 합에 대하여 크기 비교를 수행한다.
    • if 문의 비교 연산은 다음 의미를 갖는다.
      • 이전 index까지 배열의 합이 answer보다 크다는 것은, 이전의 최대 합 보다 현재의 최대 합이 더 크다는 뜻이다. 따라서 answer을 갱신한다.
      • 그렇지 않을 경우, 이전에 찾은 answer가 최대 값이기 때문에 answer를 유지한다.
  • if(sum[i] > answer) answer = sum[i];

Result

import java.util.*;
class Solution {
    public long solution(int[] sequence) {
        long answer = 0;
        int length = sequence.length;
        long[] sum = new long[length];
        int m = 0, n = 1;

        if(length == 1){
            return Math.max(sequence[0], sequence[0] * -1);
        }

        //* [1, -1, 1, -1] ... 을 곱했을 때
        for(int i = 0; i < length; i++){
            if(i % 2 == 1){
                sequence[i] *= -1;
            }

            //* Business Logic
            if(i == 0){
                sum[i] = Math.max(sequence[i], 0);
                continue;
            }
            sum[i] = Math.max(0, sum[i-1] + sequence[i]);
            answer = Math.max(answer, sum[i]);
        }

        //* [-1, 1, -1, 1] ... 을 곱했을 때
        for(int i = 0; i < length; i++){
            sequence[i] *= -1;

            //* Business Logic
            if(i == 0){
                sum[i] = Math.max(sequence[i], 0);
                continue;
            }
            sum[i] = Math.max(0, sum[i-1] + sequence[i]);
            answer = Math.max(answer, sum[i]);
        }

        return answer;
    }
}