클라우드 네이티브 기술
[ Scalabale Applications in Cloud ]
참고
Journey to achieving Cloud Native at Kakao
Containers
- 클라우드 네이티브에서 실행의 기본단위는 컨테이너
- 컨테이너와 VM의 차이점은 격리의 수준
- Container
→ Host Kernal 을 공유, User Space 격리 제공, 레이어 기반의 이미지 구성 - Virtual Machine
→ Host Kernal 과 완전 격리 가능, Guest OS의 선택이 가능, 디스크 기반 이미지 구성
Microservices Architecture
- 단일 기능을 하는 여러 서비스들이 API 및 RPC 로 통신을 하면서 일련의 동작들을 수행하도록 하는 아키텍처
- 개별 서비스: 하나의 컨테이너 or 쿠버네티스의 컨테이너 집합인 POD
- API 는 HTTP 기반의 RESTful API 형태로 동작
→ 때로는 특정 로직을 좀 더 빠르게 수행하기 위해, 메시지 브로커링을 통한 IPC 로도 API가 동작
[ 장점 ]
단일 책임, 스케일이 쉽고, 장애 도메인을 격리하기 용이, 배포하기 쉽다.
[ 단점 ]
디버깅이나 테스팅이 어렵고,
전체적으로 트랜잭셔널 레이턴시 증가
배포가 쉽지만, 배포를 잘하기 위한 것들이 굉장히 복잡
Service Meshes
- 애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법
- 서비스 간 커뮤니케이션을 관리하는 다른 시스템들과 달리, 서비스 메쉬는 애플리케이션에 구축된 전용 인프라 계층
- 서로 다른 애플리케이션 부분이 얼마나 원활하게 상호작용하는지를 기록할 수 있으므로, 더욱 손쉽게 커뮤니케이션을 최적화하고 애플리케이션 확장에 따른 다운 타임을 방지
- Service Mesh Control Plane: 서비스에 달려 있는 프록시와 연결되어 있고, 해당 연결된 통로를 통해서 사용자의 요청을 수용하게 된다. 이때 수용된 사용자의 요청들은 정해진 정책에 따라서 맞기도 하고, 흘려보내기도 하고, 여러 추가적인 행위들을 할 수 있도록 도와주게 됩니다.
→ 마이크로 서비스 아키텍처가 가지고 있는 어떤 한계점들을 극복하기 위한 방법
Immutable Infrastucture [ 변경 불가능한 인프라 ]
- ❗️ 기존의 인프라 구성은 특정한 배포시점에 버전을 가진 인스턴스들이 시간이 지남에 따라 패치되어, 최종의 형상과 달라지는 모양
- 서버가 배포된 이후 절대 변경되지 않는 형태의 인프라 패러다임
- 만약 어떤 사항을 업데이트하거나 수정, 변경해야 할 경우
→ 공용 이미지에 적절한 수정을 한 새 서버가 프로비저닝(provision)
→ 새 서버는 검증이 완료되면 서비스에 투입 & 기존 서버는 더 이상 사용하지 않게 된다. - 인프라의 일관성과 신뢰성, 간단하고 예측 가능한 배포 프로세스
- 런타임에 설정을 변경할 수 없기 때문에, Configuration Draft라는 것이 존재하지 않음
declarative APIs [ 선언적 API ]
- 명령형: 특정 상태로 가기 위한 모든 절차를 다 정의
- 선언형: 명령어들을 추상화해서 어떤 형태들을 바라고자 하는 형태들을 먼저 정의하도록 유도하는 것
- 선언형 API 예시 → 쿠버네티스 app.yaml
→ declarative action을 할 수 있는 엔진이 이를 해석해서 개별 레이어별로 필요한 API 호출, 그 API들은 실제적으로 리소스를 생성하고 어플리케이션을 실행하는 등의 절차들을 거침 - [ 장점 ] 모든 것을 오브젝트로 정의
12 factors
[ SaaS에서 클라우드에 맞는 어플리케이션이 가져야 하는 특성 12가지 ]
1. 코드베이스
- 버전 관리 되는 하나의 코드 베이스
- 공유하는 코드를 라이브러리화 및 관리
2. 종속성
- 명시적으로 선언(pip)되고 분리된 종속성(virtualenv)
- 새로운 개발자도 설치를 빠르게 할 수 있음
3. 설정
- 설정을 코드에서 엄격하게 분리
- 코드 변경 없이 쉽게 변경
4. 백엔드 서비스
- 백엔드 서비스를 연결된 리소스로 취급
- 코드를 전혀 수정하지 않고 현재 운영에 사용하고 있는 데이터베이스를 분리하고 새로운 데이터베이스를 연결할 수 있음
5. 빌드, 릴리즈, 실행: 철저하게 분리된 빌드와 실행 단계
- 빌드 단계: 실행 가능한 번들로 변환시키는 단계
→ 배포 프로세스에서 지정된 버전을 사용
→ 종속성을 가져와 바이너리와 Asset 들을 컴파일 - 릴리즈 단계: 빌드 단계에서 만들어진 빌드와 배포의 현재 설정을 결합
→ 실행 환경에서 바로 실행될 수 있도록 준비 - 실행 단계(런타임): 애플리케이션 프로세스의 집합을 시작
6. 프로세스
- 애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행
- 유지될 필요가 있는 모든 데이터는 안정된 백엔드 서비스(DB)에 저장
7. 포트 바인딩
- 포트 바인딩을 통해 HTTP 서비스로 공개
→ 하나의 앱이 다른 앱을 위한 백엔드 서비스가 될 수 있다.
8. 동시성
- 프로세스 모델[ 일급 시민 ]을 사용한 확장
- App의 작업을 적절한 프로세스 타입에 할당함으로서, 다양한 작업 부하를 처리할 수 있도록 설계
- 프로세스는 절대 데몬화해서는 안되며 PID 파일을 작성해서는 안됩니다.
- OS의 프로세스 관리자(예: systemd)나 클라우드 플랫폼의 분산 프로세스 매니저, 혹은 Foreman 같은 툴에 의존하여 아웃풋 스트림을 관리
- 충돌이 발생한 프로세스에 대응하고, 재시작과 종료를 처리
9. 폐기 가능(Disposability)
10. 개발/프로덕션 환경 일치
- 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지
- 환경의 차이: 시간의 차이, 담당자의 차이, 툴의 차이
11. 로그
- 로그: 실행 중인 app의 동작을 확인할 수 있는 수단
- 로그를 이벤트 스트림으로 취급
- app은 로그 파일을 작성하거나, 관리하려고 해서는 안됩니다.
- 각 프로세스는 이벤트 스트림을 버퍼링 없이
stdout에 출력
12. Admin 프로세스
클라우드 흐름
참고
- 기업들의 클라우드 지향점이 서비스형 인프라(IaaS)에서 출발해 플랫폼(PaaS)을 지나 소프트웨어(SaaS)로 간다.
1) 기본(basic)
2) 표준(standard)[효율, Programmable Resourcement, 자동화 관리]
3) 서비스(service)[사용자가 직접 IT를 쓸 수 있게 해준다]
4) 전략(Strategy)[IaaS보다 운영은 간편하면서 현업의 문제를 실제 해결 가능한 SaaS의 시장 기회] - 오픈소스 소프트웨어(SW)에 채택된 라이선스와 클라우드 비즈니스 모델이 충돌하고 있다.
- 멀티·하이브리드 클라우드 혼용 시나리오가 현실화하기 시작했다.
→ 각각의 장점을 극대화할 수 있는 방안
→ 오픈소스는 이런 혼용 환경의 기술적 과제를 극복할 수단을 이미 제공
→ 헤테로지니어스 클라우드
→ 프라이빗 클라우드는 보안과 가성비가 좋고 조직의 기존 기술자산에 친숙한 장점이 있으나 기능과 확장성은 아쉬울 수 있다.
→ 퍼블릭 클라우드는 기능과 확장성이 넉넉한 반면 가성비와 기술 친숙성은 떨어진다.
