Heroku개념정리 #4 - 헤로쿠의 작동 방식 How Heroku Works

Heroku Works 부분이다. Heroku 플랫폼에서 애플리케이션을 작성, 구성, 배포 및 실행할 때 접하게 되는 여러 개념들을 종합한 기술 설명서이다. 이 문서를 순차적으로 읽으면 Heroku 플랫폼을 설명하는 개념들을 이해 할 수 있다. 마지막 섹션에서는 배포 시점과 런타임 관점에서 Heroku의 모든 정의를 종합하여 설명한다.

Heroku Works 의 시작

Defining an application

applications은 특정 프로그래밍 언어(예: Ruby, Node.js, Java 등)로 작성된 소스 코드의 모음. 이 소스 코드는 하나의 프레임워크일 수도 있고, 여러 파일과 디렉토리로 구성될 수도 있음.
applications에는 소스 코드 외에도 해당 applications을 빌드하고 실행하는 데 필요한 종속성(Dependency) 설명이 포함됨. 종속성 설명은 빌드 시스템이 applications을 빌드하고 실행하는 데 어떤 추가 요소들이 필요한 지 알 수 있음.
applications: 소스 코드와 종속성 설명으로 구성된 것입니다.

종속성 매커님즘(Dependency Mechanisms)

종속성 메커니즘(Dependency Mechanisms)은 소프트웨어 개발에서 특정 applications을 빌드하고 실행하는 데 필요한 외부 라이브러리나 패키지들을 관리하는 방법을 의미하며 어플리케이션 마다 다름
- Ruby에서는 Gemfile
- Python에서는 requirements.txt
- Node.js에서는 package.json
- Java에서는 pom.xml
이러한 파일들은 applications이 실행되는 데 필요한 라이브러리와 패키지를 정의함.

소스 코드와 종속성 파일

applications의 소스 코드와 종속성 파일은 Heroku 플랫폼이 applications을 빌드하여 실행 가능한 상태로 만드는 데 필요한 모든 정보를 제공
빌드 시스템은 이 정보를 사용하여 applications을 컴파일하고 필요한 모든 종속성을 가져와 실행 가능한 형태 만듬

applications 정리

Heroku는 여러 프로그래밍 언어로 작성된 applications을 지원함.
applications은 소스 코드와 필요한 종속성을 설명하는 파일들로 구성 됨.
종속성 설명 파일은 언어마다 다르며, 이를 통해 Heroku는 applications을 빌드하고 실행 할 수 있음.

Knowing what to execute

Heroku에서 applications을 실행하기 위해 간단 하게 실행 가능. 사용 중인 언어를 Heroku가 이를 자동으로 감지할 수 있음. 예를 들어, Ruby on Rails에서는 일반적으로 rails server, Django에서는 python <app>/manage.py runserver, Node.js에서는 package.json의 main 필드를 사용함.

용어: Procfiles는 실행할 수 있는 명령을 나열한다.

다른 applications의 경우 실행 가능한 부분을 명시적으로 선언해야 할 수 있음.
이를 위해 소스 코드와 함께 Procfile이라는 텍스트 파일을 사용.
이 파일의 각 줄은 빌드된 applications에 대해 실행할 수 있는 명령을 선언

web: java -jar lib/foobar.jar $PORT
queue: java -jar lib/queue-processor.jar

위는 Procfiles 의 java 의 예시

web 프로세스 타입

web은 웹 서버를 실행하는 프로세스
java -jar lib/foobar.jar $PORT 명령을 실행
여기서 $PORT는 Heroku가 자동으로 할당하는 포트를 사용

queue 프로세스 타입

queue는 대기열 프로세서를 실행하는 프로세스
java -jar lib/queue-processor.jar 명령을 실행
이 프로세스는 대기열에 있는 작업을 처리하는 역할

applications은 소스 코드, 종속성 설명 및 Procfile로 구성

Procfile을 사용하면 이러한 확장을 쉽게 관리할 수 있습니다. 각 프로세스를 독립적으로 정의하고 관리 한다. 필요에 따라 특정 프로세스의 인스턴스 수를 늘리거나 줄 일 수 있다. 예를 들면 웹 트래픽이 급증할 때 웹 서버 인스턴스를 늘리고, 대기열에 쌓이는 작업이 많아질 때 대기열 프로세서 인스턴스를 늘릴 수 있음.

Deploying applications

Git은 소스 코드를 관리하고 버전 관리를 도와주는 도구이다. Heroku는 이 Git을 사용하여 애플리케이션을 배포한다. Heroku에 애플리케이션을 만들면, 애플리케이션의 로컬 Git 저장소에 heroku라는 새로운 원격 저장소를 추가 한다.

코드를 Heroku에 배포할 때는 익숙한 git push 명령을 사용하되, heroku 원격 저장소로 푸시한다.

$ git push heroku main

applications 배포는 Git, GitHub 또는 API를 사용하여 applications을 Heroku로 전송하는 것

애플리케이션을 Heroku로 배포하는 방법은 Git뿐만 아니라, GitHub 또는 Heroku API를 사용해서도 가능
예를 들어, GitHub와 통합하면 풀 리퀘스트마다 새로운 애플리케이션을 생성하여 지속적인 통합 작업에 매우 유용.

Building applications

Heroku 플랫폼이 applications 소스를 수신하면 소스 applications의 빌드를 시작한다. 빌드 메커니즘은 일반적으로 언어별로 다르지만 동일한 패턴이다. 일반적으로 지정된 종속성을 가져오고 필요한 자산을 생성한다 (스타일 시트 처리만큼 간단하거나 코드 컴파일만큼 복잡할 수 있다).

Heroku에서 애플리케이션 빌드 과정

소스 코드 받기
- Heroku는 애플리케이션의 소스 코드를 받습니다.
빌드 시작:
- 받은 소스 코드를 빌드하기 시작합니다.
- 빌드 과정은 사용된 언어에 따라 다르지만, 일반적으로 동일한 패턴을 따릅니다.
- 필요한 종속성을 다운로드하고, 필요한 자산(스타일 시트나 컴파일된 코드 등)을 생성합니다.
빌드팩(Buildpacks):
- 빌드팩은 빌드 과정의 핵심 도구입니다.
- 빌드팩은 애플리케이션, 종속성, 언어 런타임을 받아 슬러그(slugs)를 생성합니다.
- 슬러그는 오픈 소스이므로 Heroku를 다양한 언어와 프레임워크로 확장할 수 있습니다.
예시:
- Rails 애플리케이션: Gemfile에 지정된 종속성을 가져오고 자산 파일을 생성합니다.
- Java 애플리케이션: Maven을 사용해 종속성을 가져오고, 소스 코드를 컴파일해 JAR 파일을 생성합니다.
슬러그 생성:
- 소스 코드, 가져온 종속성, 빌드 과정의 출력물(생성된 자산이나 컴파일된 코드), 언어 및 프레임워크를 하나로 모아서 슬러그를 만듭니다.
슬러그의 역할:
- 슬러그는 실행 준비가 완료된 애플리케이션의 번들입니다.
- 이 슬러그는 실행할 명령어(Procfile)와 함께 애플리케이션 실행을 준비합니다.

슬러그(Slug)란?

슬러그는 Heroku에서 애플리케이션을 실행하기 위해 필요한 모든 요소를 포함한 압축된 패키지입니다. 이는 다음과 같은 요소들로 구성됩니다.

– 애플리케이션의 소스 코드
– 애플리케이션이 필요로 하는 종속성
– 언어 런타임
– 컴파일된 결과물 또는 빌드된 자산

슬러그는 Heroku 플랫폼에서 애플리케이션을 실행할 수 있도록 모든 필요한 파일과 설정을 포함한 상태로 준비되어 있습니다. 이는 애플리케이션의 빠른 배포와 실행을 가능하게 해줍니다.

Running applications on dynos

Dyno 는 Heroku에서 애플리케이션을 실행하는 가벼운 가상 Unix 컨테이너이다.
각 dyno는 애플리케이션이 실행되기 위한 환경을 제공한다.

실행 : Heroku는 애플리케이션을 실행할 때, Procfile에 지정된 명령어를 사용하여 dyno를 실행한다.
처음 애플리케이션을 배포하면 Heroku는 자동으로 1개의 웹 dyno를 실행한다.

조정 : Heroku에서는 실행 중인 dyno의 수를 조절할 수 있다. 예를 들면 다음 명령어를 사용하여 웹 프로세스에 3개, 큐 프로세스에 2개의 dyno를 실행할 수 있다.

$ heroku ps:scale web=3 queue=2

새로운 버전의 애플리케이션을 배포하면 기존에 실행 중인 dyno는 종료되고, 새로운 릴리스로 새로운 dyno가 시작 된다.

Dyno 확인 : 현재 실행 중인 dyno의 총 수를 말한다. 웹 프로세스와 큐 프로세스 각각에 몇 개의 dyno가 실행 중인지를 나타낸다.

heroku ps
== web: 'java lib/foobar.jar $PORT'
web.1: up (~ 13m ago)
web.2: up (~ 20m ago)
web.3: up (~ 41m ago)

== queue: `java lib/queue-processor.jar`
queue.1: up (~ 32m ago)
queue.2: up (~ 32m ago)

Config vars

Config Vars: 애플리케이션의 구성 데이터이다.. 이 데이터는 데이터베이스, 자격 증명 또는 환경 변수를 포함하며, 환경마다(예: 스테이징, 프로덕션, 개발 환경) 달라질 수 있다. 이 구성 데이터는 애플리케이션 코드 외부에 저장되고 코드와 독립적으로 변경할 수 있다.

Heroku에서는 애플리케이션의 구성 설정을 Config Vars로 관리
아래의 코드는 암호화 키를 설정하는 방법

$ heroku config:set ENCRYPTION_KEY=my_secret_launch_codes
Adding config vars and restarting demoapp... done, v14
ENCRYPTION_KEY:     my_secret_launch_codes

실행 중인 애플리케이션에서 Config Vars는 환경 변수로 접근할 수 있다.
모든 dyno는 동일한 Config Vars에 접근 한다. 환경마다 다른 구성 데이터를 관리하고
애플리케이션이 이를 동적으로 사용한다.

Releases

애플리케이션의 슬러그(slug)와 구성 변수(config vars)의 조합
슬러그와 구성 변수를 결합하여 애플리케이션의 특정 버전을 형성

릴리스의 저장 및 관리

모든 릴리스는 추가만 가능한 형식으로 기록되어 관리한다.
릴리스 번호 옆의 커밋 해시는 Heroku에 배포된 저장소의 커밋 해시를 나타낸다.

heroku releases
== demoapp Releases
v103 Deploy 582fc95  jon@heroku.com   2013/01/31 12:15:35
v102 Deploy 990d916  jon@heroku.com   2013/01/31 12:01:12

새로운 릴리스 생성

새로운 버전을 배포할 때마다 새로운 슬러그가 생성되고 릴리스가 생성 된다.
구성 변수를 변경하면 새로운 릴리스가 생성 된다.

롤백 : Heroku는 이전 릴리스를 저장하므로 이전 릴리스로 쉽게 롤백 할 수 있다.

heroku releases:rollback v102
Rolling back demoapp... done, v102
heroku releases
== demoapp Releases
v104 Rollback to v102 jon@heroku.com   2013/01/31 14:11:33 (~15s ago)
v103 Deploy 582fc95   jon@heroku.com   2013/01/31 12:15:35
v102 Deploy 990d916   jon@heroku.com   2013/01/31 12:01:12

Dyno manager

Dyno Manager: Heroku 플랫폼에서 dyno를 관리하는 역할
Dyno Manager는 모든 애플리케이션의 dyno가 정상적으로 실행되도록 유지
dyno는 하루에 한 번 이상 주기적으로 재시작
애플리케이션 실행 중 오류가 발생하거나 하드웨어 문제가 감지되면 dyno를 새로운 물리적 위치로 이동
Heroku는 애플리케이션을 관리하고 실행하기 때문에 운영체제나 내부 시스템 구성을 관리할 필요가 없음

Dyno Manager

Heroku 플랫폼에서 모든 애플리케이션의 dyno를 관리하는 역할을 담당한다.

에코(Eco) Dyno

HTTP 트래픽이 없으면 슬립/제로 스케일 상태로 전환된다. 슬립 상태에서 HTTP 트래픽이 발생하면 몇 초 동안의 지연 후에 깨어난다. 다른 dyno 타입을 사용하면 슬립을 피할 수 있다.

운영체제 관리 불필요

Heroku는 애플리케이션을 관리하고 실행하기 때문에 운영체제나 내부 시스템 구성을 관리할 필요가 없다.

One-off Dyno

일시적인 dyno로, 로컬 터미널에 입출력이 연결된 상태로 실행할 수 있습니다. 최신 릴리스로 로드 된다.
One-off dyno를 생성하고 연결 방법

heroku run bash
Running `bash` attached to terminal... up, run.8963
~ $ ls

Ephemeral Filesystem

dyno는 자체 일시적인 파일 시스템을 갖는다.
최신 릴리스의 새 복사본으로 제공 된다.
임시 작업 공간으로 사용할 수 있지만 파일 시스템의 변경 사항은 다른 dyno에 반영되지 않으며 배포 및 dyno 재시작 시 지속되지 않는다.
heroku run bash 명령을 통해 one-off dyno를 생성하고 Unix 셸에서 파일을 생성한 후 세션을 종료하면 해당 변경 사항은 손실 된다.
모든 dyno는 애플리케이션 내에서도 서로 격리되어 있고 세션이 종료되면 dyno는 종료된다.
새로운 dyno는 항상 슬러그에서 생성되며 다른 dyno의 상태에서 생성되지 않는다.

Add-On

– 애플리케이션의 기능을 확장할 수 있는 서드 파티의 특화된 클라우드 서비스
데이터베이스, 큐잉 및 캐싱 시스템, 스토리지, 이메일 서비스 등과 같은 백엔드 서비스를 제공하는 도구
Heroku와 서드 파티에서 제공하고 Heroku의 마켓플레이스에서 선택할 수 있음.

애드온 추가 방법

Heroku는 애드온을 애플리케이션에 연결된 리소스로 처리. 애드온을 프로비저닝(provision)하는 것은 마켓플레이스에서 선택하여 애플리케이션에 연결
ex) Heroku Data for Redis 애드온을 애플리케이션에 추가하는 방법

heroku addons:create heroku-redis:mini

파일 상태 공유

Dyno는 파일 상태를 공유하지 않기 때문에, 애플리케이션 내에서 dyno 간의 통신을 위해 스토리지를 제공하는 애드온을 사용합니다.
ex) Redis나 Postgres를 큐의 백엔드 메커니즘으로 사용 – 웹 프로세스 타입의 dyno는 큐에 작업 요청을 푸시하고 큐 프로세스 타입의 dyno는 큐에서 작업 요청을 가져올 수 있음.

애드온 서비스 제공자

애드온 서비스 제공자는 서비스에 대한 책임을 집니다. 애플리케이션과의 인터페이스는 종종 구성 변수(config var)를 통해 제공
ex) 애드온을 프로비저닝하면 자동으로 애플리케이션에 REDIS_URL이 추가 되고 서비스에 연결하는 코드를 작성할 수 있음.

uri = URI.parse(ENV["REDIS_URL"])
REDIS = Redis.new(:host => uri.host, :port => uri.port, :password => uri.password)

릴리스와 애드온

애드온은 구성 변수와 마찬가지로 애플리케이션에 연결됨.
애플리케이션의 릴리스는 슬러그와 구성 변수뿐만 아니라 프로비저닝된 애드온 세트도 포함
슬러그, 구성 변수 및 애드온의 추가만 가능한 형식의 기록. Heroku는 릴리스를 추가만 가능한 형식으로 기록하여 관리
구성 변수와 마찬가지로, 애드온을 추가, 제거 또는 변경할 때마다 새로운 릴리스가 생성됨.

Logging and monitoring

시간에 따라 기록된 이벤트 스트림이다. 모든 dyno와 Heroku 플랫폼 구성 요소에서 생성된 로그를 Logplex라는 시스템으로 모은다.
Logplex는 고성능 실시간 로그 전달 시스템이다.

로그 확인 방법

모든 플랫폼 구성 요소와 dyno에서 생성된 로그를 쉽게 확인할 수 있습니다
첫 번째 로그는 Heroku의 라우터 로그 이고 나머지 두 개의 로그는 웹 프로세스 타입의 두 개의 dyno에서 생성된 것이다.

heroku logs
2013-02-11T15:19:10+00:00 heroku[router]: at=info method=GET path=/articles/custom-domains host=mydemoapp.heroku.com fwd=74.58.173.188 dyno=web.1 queue=0 wait=0ms connect=0ms service=1452ms status=200 bytes=5783
2013-02-11T15:19:10+00:00 app[web.2]: Started GET "/" for 1.169.38.175 at 2013-02-11 15:19:10 +0000
2013-02-11T15:19:10+00:00 app[web.1]: Started GET "/" for 2.161.132.15 at 2013-02-11 15:20:10 +0000

Logplex

애플리케이션의 모든 실행 중인 dyno와 라우터 같은 다른 구성 요소에서 로그 항목을 자동으로 모아 단일 소스로 제공하는 시스템이다.

특정 Dyno의 로그 확인

특정 dyno의 로그만 확인하고 채널을 열어두어 추가 이벤트를 듣고 싶다면 다음 명령어를 사용할 수 있다.

heroku logs --ps web.1 --tail
2013-02-11T15:19:10+00:00 app[web.1]: Started GET "/" for 1.169.38.175 at 2013-02-11 15:19:10 +0000

로그 보존 및 알림

Logplex는 성능을 위해 제한된 버퍼만 유지한다. 로그를 영구적으로 보존하고 예외 발생 시 이메일 알림 같은 이벤트를 처리하려면
로그 드레인(log drain) API를 활용하는 로깅 애드온을 사용해야 한다.

HTTP routing

웹 프로세스 타입: Dyno 구성에 따라 일부 dyno는 웹 프로세스 타입과 연결된 명령어를 실행하고, 일부는 다른 프로세스 타입과 연결된 명령어를 실행합니다.
웹 프로세스 타입을 실행하는 dyno는 다른 모든 dyno와 달리 HTTP 트래픽을 받습니다. Heroku의 HTTP 라우터는 애플리케이션에 대한 들어오는 요청을 실행 중인 웹 dyno에 분배합니다.

애플리케이션의 웹 트래픽 처리 용량 확장

웹 트래픽을 처리하기 위한 애플리케이션의 용량을 확장하려면 웹 dyno의 수를 늘린다.

$ heroku ps:scale web+5

로드 밸런싱 및 라우팅

HTTP 요청 로드 밸런싱을 위해 무작위 선택 된다. 이 라우팅은 HTTP와 HTTPS 트래픽 모두를 처리한다.
또한 여러 개의 동시 연결 및 타임아웃 처리를 지원한다.

Tying it all together

현재 Heroku Works 에 대한 문서의 마지막 정리이다. 개념들은(Heroku Works) 두 가지로 나눌 수 있다.
애플리케이션의 개발 및 배포와 관련된 것들과, Heroku 플랫폼과 배포 후 애플리케이션의 런타임 운영과 관련된 것들이다.
아래의 내용은 (Heroku Works) 현재 문서의 플랫폼의 주요 구성 요소들을 다시 요약하여 두가지로 구분한다.

Deploy

애플리케이션: 소스 코드, 의존성에 대한 설명, 그리고 Procfile로 구성됩니다.
Procfile: 실행하려는 명령어를 나열한 프로세스 타입을 포함합니다.
애플리케이션 배포: Git, GitHub 또는 API를 사용하여 애플리케이션을 Heroku에 전송하는 과정입니다.
Buildpack: 슬러그 컴파일 과정을 지원합니다. Buildpack은 애플리케이션, 의존성 및 언어 런타임을 가져와 슬러그를 생성합니다.
슬러그: 소스 코드, 의존성, 언어 런타임, 빌드 시스템의 컴파일/생성된 출력물을 번들로 묶어 실행 준비를 마친 것입니다.
Config Vars: 소스 코드와 독립적으로 변경할 수 있는 사용자 정의 구성 데이터를 포함합니다. 이 구성은 환경 변수를 통해 실행 중인 애플리케이션에 노출됩니다.
애드온: 서드 파티에서 제공하는 특화된 클라우드 서비스로, 애플리케이션에 쉽게 첨부하여 기능을 확장할 수 있습니다.
릴리스: 슬러그(애플리케이션), config vars 및 애드온의 조합입니다. Heroku는 릴리스를 추가만 가능한 형식으로 기록하여 관리합니다.

Runtime

Dynos: 애플리케이션 실행에 필요한 환경을 제공하는 격리된 가상화된 Unix 컨테이너입니다.
애플리케이션의 Dyno 형성: 현재 실행 중인 모든 dyno의 총합으로, 확장한 다양한 프로세스 타입으로 나눌 수 있습니다.
Dyno Manager: Heroku에서 실행 중인 모든 애플리케이션의 dyno를 관리하는 역할을 합니다.
Eco Dyno 타입: 30분 동안 활동이 없으면 슬립 상태로 전환됩니다. 이를 피하려면 다른 dyno 타입으로 확장하면 됩니다.
One-off Dyno: 로컬 터미널에 입출력이 연결된 상태로 실행되는 일시적인 dyno입니다. 최신 릴리스로 로드됩니다.
일시적인 파일 시스템: 각 dyno는 최신 릴리스의 새 복사본을 가지며, 임시 작업 공간으로 사용할 수 있지만 파일 시스템의 변경 사항은 다른 dyno에 반영되지 않습니다.
Logplex: 애플리케이션의 모든 실행 중인 dyno와 라우터와 같은 다른 구성 요소에서 로그 항목을 자동으로 모아 단일 소스로 제공하는 시스템입니다.
애플리케이션 확장: 각 프로세스 타입의 dyno 수를 변경하는 것을 포함합니다.

참고문서 : https://devcenter.heroku.com/articles/how-heroku-works

Heroku개념정리 #4 – 헤로쿠의 작동 방식 How Heroku Works