[네이버오픈소스세미나] Contribution, 전쟁의 서막 : Apache OpenWhisk 성능 개선 - 김동경

Contribution - 전쟁의 서막
Apache OpenWhisk 성능 개선

20%30%50%
컨트리뷰션 경험담 기술 이슈 운영
오늘 드릴 말씀은요

발표자 소개
@style95
style9595@gmail.com
dominic.kim@navercorp.com

Apache OpenWhisk 소개
오픈소스 Serverless 플랫폼

오픈소스 Serverless 플랫폼 Apache 프로젝트

컨테이너 기반

컨테이너 기반 Scala

IBM이 오픈소스화

총 44개 repo

• Core: Scala
• CLI: Go
• ETC: Lua, Python, …
• Ansible, Helm, Compose

https://landscape.cncf.io/sort=stars

다양한 런타임 지원

다양한 런타임 지원 다양한 Cloud 상에서 동작

Function chaining 가능
다양한 Cloud 상에서 동작

Function chaining 가능 이벤트에 반응하여 실행
다양한 Cloud 상에서 동작

• Nginx: SSL termination
• Controller: Rest API + Scheduling
• CouchDB: Function 및 실행 결과 저장
• Kafka: Request 포워딩
• Invoker: 컨테이너 구동 및 Function 실행

OpenWhisk Core repo
OpenWhisk CLI Serverless OpenWhisk
Merged: 34
Open: 6
Contribution

하지만 실제로 열어보니..

2017년 7월 28일 최종 머지
https://github.com/apache/incubator-openwhisk/pull/1790

TL님의 홍보(?)
6개월 만에 머지

뭐가 문제인가?
Host에서 컨테이너 IP로 직접 접근 필요
Host(10.10.10.10)
Docker network(172.17.0.0/16)
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
ContainerC
(172.17.0.4)
Test process
172.17.0.2:8080

리눅스 기반의 Docker 네트워크 구조
docker0 인터페이스가 컨테이너들의 Gateway 역할
Host(10.10.10.10)
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
ContainerC
(172.17.0.4)
Eth0: 10.10.10.10
docker0: 172.17.0.1

$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 02:42:4a:06:2c:db txqueuelen 0 (Ethernet)
RX packets 1600061407 bytes 757851585498 (705.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2662761605 bytes 240562713498 (224.0 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
.
.
.

# route –n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.106.100.1 0.0.0.0 UG 0 0 0 eth1
10.106.100.0 0.0.0.0 255.255.254.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
bash-4.4# route –n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
[호스트 머신]
[컨테이너 내부]

리눅스에서의 구조
Host(10.10.10.10)
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
ContainerC
(172.17.0.4)
Test process
172.17.0.2:8080
docker0: 172.17.0.1

Host(10.10.10.10)
VM(virtualbox) network(192.168.0.0/8)
맥 OS(Docker-machine) 에서의 구조
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
ContainerC
(172.17.0.4)
Test process
172.17.0.2:8080
docker0: 172.17.0.1
192.168.99.10

Docker-machine 예제
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default * virtualbox Running tcp://192.168.99.187:2376 v1.9.1
$ env | grep DOCKER
DOCKER_HOST=tcp://192.168.99.187:2376
DOCKER_MACHINE_NAME=default
DOCKER_TLS_VERIFY=1
DOCKER_CERT_PATH=/Users/<your_username>/.docker/machine/machines/default

Host(10.10.10.10)
VM(xhyve) network
Docker for Mac
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
ContainerC
(172.17.0.4)
Process
docker ps
Forward

Host(10.10.10.10)
VM(xhyve) network
맥 OS(Docker for Mac) 에서의 구조
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
ContainerC
(172.17.0.4)
Test Process
172.17.0.2:8080
docker0: 172.17.0.1

Host(10.10.10.10)
VM(xhyve) network
맥 OS(Docker for Mac) 에서의 구조
ContainerA
(172.17.0.2)
ContainerB
(172.17.0.3)
Squid-proxy
(172.17.0.4)
Test Process
Proxy configuration
localhost:3128
3128 port
8080 port
172.17.0.2:8080

Akka-http client는 proxy를 지원하지않음

Contribution 포인트
•Production
• 성능
• Failover
• 모니터링
• 기능

CouchDB 이슈
• 데이터 삭제가 되지 않음
• 잦은 Crash
• High bulk Insertion때 Crash
• Indexing으로 인한 Crash

CouchDB의 삭제 = 업데이트
Rev-1 Rev-2
Update
여러 버전의 Rev을 유지하고 있음
Rev을 통해 여러 노드간의 Conflict를 해결

Rev-1 Rev-2
Update
Rev-1
Rev-2
(_deleted)
Delete
문서 내용은 삭제되지만
Tombstone은 지워지지 않음
여러 버전의 Rev을 유지하고 있음
Rev을 통해 여러 노드간의 Conflict를 해결

초기 상태

초기 상태 데이터 삽입

데이터 삭제

데이터 삭제 Compaction 수행

CouchDB 1.x -> CouchDB 2.x
CouchDB
1.x
CouchDB
1.x
CouchDB
1.x
Standalone node
ReplicationReplication
CouchDB
2.x
CouchDB
2.x
CouchDB
2.x
Consistent Hashing
Clustering
ShardingReplication
Cloudant(IBM)사에서 집중적으로 Contribution

Bulk insertion issue
CouchDB
2.x
CouchDB
2.x
CouchDB
2.x
Client
1. 500 docs / request
3. Replication
2. Indexing
3. Replication
4. Indexing
4. Indexing

Bulk insertion issue
메모리 상에 적용되지 않은 변경들이 쌓이기 시작

CouchDB 성능 이슈
1. Pending_changes가 계속 증가하면서
메모리를 소진
2. 메모리가 100% 달하면
CouchDB 노드가 Crash되고 재시작됨
40 Cores, 128 GB Memory, 2TB SSD

CouchDB 성능 이슈
처리되지 못한 데이터의 유실
불안정한 클러스터
불안정한 TPS

MongoDB로 변경

ElasticSearch Activation Store

Metric 전송
• JVM 애플리케이션을 위한 모니터링 툴
• Metrics, Tracing, 등의 기능 제공
• Scala에서 활용하기 좋음

Tag를 이용한 Aggregation 지원

신규 스케쥴링 알고리즘 공유
https://www.youtube.com/watch?v=cgictUeK-Vk&feature=youtu.be
Bi-weekly Meeting
- 커뮤니티 멤버들끼리 모여서 이슈나 신규 기술 등을 공유하는 자리
- 누구나 참석 가능
- 밤 12시에 시작됨

신규 스케쥴링 알고리즘 공유
https://www.youtube.com/watch?v=cgictUeK-Vk&feature=youtu.be

현재 스케쥴링 로직 분석

Proto-typing 및 성능 비교 벤치마크

https://cwiki.apache.org/confluence/display/OPENWHISK/Autonomous+Container+Scheduling

Docker 데몬의 성능 이슈
OpenWhiskClient
Docker
Daemon
.
.
.
Function 실행 Docker API
컨테이너 생성/삭제
컨테이너 정지/재시작

액션 실행 결과
Docker 생성/삭제 API 성능
Docker 정지/재개 API 성능

OpenWhiskClient
Docker
Daemon
.
.
.
5~10ms
500~700ms
100~200ms

OpenWhiskClient
Docker
Daemon
.
.
.
5~10ms
500~700ms
100~200ms
bottleneck

• Docker API의 처리속도가 느림
• 잦은 API 호출 및 동시 호출 (X)
• Docker API 호출 최소화가 관건

오픈소스 프로젝트의 매력
• 누구에게나 평등한 기회
• 장소와 시간에 구애 받지 않음
• 코드로만 표현되고 평가받음

느낀점
• 다이나믹한 개발 경험
• 전 세계의 개발자들과 함께 커뮤니케이션
• 영국, 독일, 미국 등 다양한 나라의 개발자들과 화상회의
• Apache 프로젝트에 내 코드가 들어가는 경험
• 장소에 구애 받지 않을 수 있음
• 다양한 외부 발표 기회

[네이버오픈소스세미나] Contribution, 전쟁의 서막 : Apache OpenWhisk 성능 개선 - 김동경

More Related Content

What's hot

Similar to [네이버오픈소스세미나] Contribution, 전쟁의 서막 : Apache OpenWhisk 성능 개선 - 김동경

More from NAVER Engineering

[네이버오픈소스세미나] Contribution, 전쟁의 서막 : Apache OpenWhisk 성능 개선 - 김동경