diff --git "a/\354\261\225\355\204\260_25/\353\260\225\354\212\271\355\233\210.md" "b/\354\261\225\355\204\260_25/\353\260\225\354\212\271\355\233\210.md"
new file mode 100644
index 0000000..08e8af8
--- /dev/null
+++ "b/\354\261\225\355\204\260_25/\353\260\225\354\212\271\355\233\210.md"
@@ -0,0 +1,128 @@
+## 컴퓨트 환경 길들이기
+
+### 힘든 일은 자동으로
+
+- 안일한 솔루션으로는 거대한 시스템을 지탱할 수 없다.
+- 간단한 자동화
+  - 셸 스크립트 자동화
+  - 이상 감지시 프로세스 재시동
+  - VM이나 컨테이너 재생성
+- 스케줄링 자동화
+  - 머신 할당: 서비스형 컴퓨트의 시작
+  - 머신의 상태를 검사하는 데몬이나 개별 프로세스 모니터 데이터 활용
+
+### 컨테이너화와 멀티테넌시
+
+- 하나의 머신 위에 구동되는 프로그램은 보통 여러 개이다.
+- 컴퓨팅 자원을 효율적으로 활용하기 위한 스케줄러가 필요하다.
+- 프로그램의 격리
+  - 민감한 데이터, 라이브러리의 버전, 전역 자원 등 같은 머신에서 돌아가는 서로 다른 프로그램들의 격리가 필요하다.
+  - 멀티테턴트 컴퓨트 서비스는 테넌트들을 일정 수준 격리해 보호해줘야 한다.
+- 이를 위해 고전적으로는 가상 머신(VM)을 사용
+- 가상 머신 위에서 OS를 돌리고 부팅을 해야 하는 등 느리고 자원도 많이 쓴다.
+- 때문에 Docker 등의 컨테이너로 진화
+
+### 요약
+
+"조직이 커지고 제품들이 많이 사용될수록 다음의 세 요인 모두가 증가한다."
+
+- 관리해야 할 애플리케이션의 종류
+- 운영해야 할 애플리케이션의 복재본 수
+- 가장 큰 애플리케이션의 크기
+
+이를 감당하기 위해서는 자동화 자체도 더 복잡해진다는 사실을 인지하고 대비해야 한다.
+
+## 관리형 컴퓨트에 적합한 소프트웨어 작성하기
+
+### 장애를 감안한 아키텍처 설계
+
+- 머신 하나에 문제가 생기면 다른 머신이 짐을 대신 짊어지도록 설계하기
+- 사람의 개입이 필요한 '반려동물'이 아닌 '가축'처럼 완전 자동화하기
+- 작업을 여러 뭉치(chunk)로 나눠서 문제 상황에서의 분량을 최소화하기
+- **로드밸런서**를 이용해 문제 상황에서 트래픽을 다른 컨테이너로 전달한다.
+
+### 배치 vs 서빙
+
+- 배치는 정해진 태스크를 처리하는 끝이 있는 작업
+- 서빙은 끝없이 실행되며, 들어오는 요청을 그때그때 처리
+
+- 대표적인 차이점
+  - 배치는 처리량, 서빙은 지연시간이 중요
+  - 배치는 수명이 짧고, 서빙은 오래 지속
+  - 서빙은 더 오래 걸릴 가능성이 크다.
+
+## 상태 관리
+
+- 문제가 발생하여 작업을 다른 머신으로 옮기면 처리중인 상태는 유실된다.
+- 처리중인 상태는 휘발성 데이터로 취급하며, '진짜 스토리지'는 다른 곳에 둬야 한다.
+- 외부 스토리지를 이용한다. 단, 이것이 견고한가?
+- 데이터 조각을 복제하여 장애에 대응해야 한다.. 이게 좋은가?
+- 모든 상태를 휘발성으로 두어 애플리케이션에서 활용한다.
+- 예를 들어 캐시는 휘발성 로컬 스토리지
+- **지연 시간 목표를 달성하기 위해 캐시를 이용하되 핵심 애플리케이션은 캐시 없이도 전체 부하를 감당할 수 있게 준비해둬야 한다.**
+
+### 일회성 코드
+
+- 수백 개의 CPU 코어를 제공하는 분산 환경에서 빠르게 작업을 처리할 수 있게 할 수 있다.
+- 비싸지 않은가? 하지만 컴퓨트 자원의 비용이 엔지니어의 시간보다 비싼 경우는 흔치 않다.
+- 하지만 프로그램은 작은 실수 하나로 머신을 과하게 많이 사용할 수 있기 때문에 사용량을 제한하여 해결한다.
+
+## 시간과 규모에 따른 CaaS
+
+### 추상화 수단으로써의 CaaS
+
+- 컨테이너는 하나의 머신에서의 간섭을 줄여주는 격리 매커니즘의 역할로 시작
+- 컴퓨트 환경을 추상화하는 데에 매우 중요한 역할로 발전
+- 머신을 변경하게 되더라도 컨테이너 SW를 손보면 된다.
+- 컨테이너를 이용하면 이름 있는 자원도 쉽게 관리 가능(ex. 네트워크 포트, GPU)
+
+### 모든 작업을 하나의 아키텍처로
+
+- 자체 머신 풀을 팀마다 관리한다면 회사 차원의 통합이나 변경, 이전은 큰 일이 된다.
+- 모든 작업을 공통된 컴퓨트 서비스로 처리하여 관리 인프라를 통합하면 관리를 통일할 수 있다.
+
+### 표준 설정 언어
+
+- 복잡한 구성을 공통되게 표현할 수 있는 설정 언어가 있으면 좋다.
+- 어느 팀이든 표준 설정을 자기 팀의 서비스 정의에 쉽게 포함시킬 수 있다.
+- 배포 자동화에도 꼭 필요하다.
+
+## 컴퓨트 서비스 선택하기
+
+- 컴퓨트 인프라는 강력한 종속 요인이다.
+- 어떤 컴퓨트 아키텍처를 선택흐냐는 매우 중요하다. (트레이드 오프가 있다.)
+
+### 중앙 관리 vs 사용자화
+
+- 컴퓨트 스택의 관리 부담 측면에서 보면 조직 전체에서 CaaS만 이용하는 게 좋다.
+- 조직이 커져도 관리 비용은 크게 늘어나지 않는다.
+- 공통된 관리는 예외를 인정하지 않거나 분기를 만드는데, 성장하는 조직에서는 치명적일 수 있어 사용자화도 공존한다.
+
+### 또다른 수준의 추상화: 서버리스
+
+- VM은 자체 OS를 유지할 수 있어 다양한 OS가 필요한 작업에서 유용하다.
+- 서버리스 프레임워크는 '반려동물형 VM' 모델과 비교한다.
+- 프로비전된 서버가 존재하지 않고 자동 확장과 낮은 부하, 가축 관리의 모든 이점을 제공한다.
+- 단, 서버리스에도 단점이 있다.
+  - 코드에 상태가 전혀 없어야 한다.
+  - 서버리스 모델로는 처리할 수 없는 작업들이 있다.
+  - 컨테이너 기반과 서버리스 서비스를 혼동할 수 있다.
+  - 환경에 대한 통제력을 일부 잃게 된다.
+
+### 공용 vs 사설
+
+- CaaS를 자체 개발할 것인지, 공용 클라우드를 이용할 것인지
+- 추상화 수준이 높아질수록 확장이 용이하다. (물리 머신 > VM > 관리형 컨테이너 > 서버리스)
+- 젊은 조직이나 새로 출시한 제품은 자원 요구량을 예측하기 어려운데 자원을 미리 프로비전할 필요가 없다는 것은 이점
+- 클라우드를 선택하면 업체에 종속된다는 위험이 있다. 서비스를 옮겨야 할 때에는 난처하다.
+- 이렇게 확장할 수 있다.
+  - 저수준 공용 클라우드 위에 고수준 오픈 소스 제품 얹기(EC2 위에 OpenWhisk나 Knative)
+  - 여러 클라우드를 혼용하는 멀티 클라우드 방법
+  - 하이브리드 클라우드(작업의 일부는 사설 인프라, 일부는 공용 클라우드에서 돌리기)
+
+## 마치며
+
+- 공통 컴퓨트 인프라는 관리와 자원 활용 효율을 상당히 개선할 수 있다.
+- 서로 다른 작업이 같은 물리(or 가상) 머신을 공유할 수 있도록 하는 컨테이너가 필요하다.
+- 컨테이너로 추상 계층을 만들어서 애플리케이션의 탄력적 운용이 가능하게 한다.
+- 단, 데이터를 휘발성으로 생각한다거나 호스트 이름을 하드코딩하지 않는 등 생각하는 방식을 전환해야 한다.