18년도 까지 서비스 개발을 맡았지만 갑작스럽게 부서 이동으로 인해 FaaS 개발을 손을 떼고 신규 부서로 이전하게 되었다. 작년 초에도 큰 변화였는데 이번에도 더 큰 변화였다.
문제는 개발보다는 기획쪽에 더 가까운 업무였고 데이터 분석 관련한 플랫폼을 개발하는 TF에 포함되게 되었다. 머신러닝, 데이터 엔지니어링과는 담을 쌓았었지만 어쩔수 없이 분석 관련하여 과제 수행
1-3월에는 주로 모빌리티 관련 에코파트너들과 협력 및 사업개발을 위한 기술검토 및 검증.
4-6월에는 그룹 관계사들의 데이터레이크에 대한 정의와 설계, 플랫폼 구현을 위한 Design-Thinking, 서비스 포털 기획 등을 수행하고 그룹 관계사들의 데이터레이크에 대한 정의와 설계 진행.
7-9월에는 서비스 포털 개발을 위한 CI/CD 선정 및 devops 파이프라인 구성, 데이터 preparation 툴 검토 및 AWS Managed 서비스 검증 및 구현 업무를 수행했다. 또한 프론트엔드 서비스 처리를 위한 람다함수 개발 및 documents 레포지토리 구축 진행.
기본적으로 현재 업무 중에 IBM클라우드에서 AWS로 데이터를 가져와야 하는 업무가 생겨서 시작되었고 정기적으로 매일 새벽에 크롤링(Pull)방식으로 데이터를 복제해야하는 Use-Case를 구현해야 했다.
CI/CD Pipeline구성이 주 목적으로 Application구현은 포스팅 내용에서 제외하였다.
기본적으로 Batch 컴퓨팅을 목적으로 하는 서비스로 컴퓨팅 타입을 Fargate 또는 EC2 중 하나를 선택하여 동적으로 프로비저닝하는 서비스이다.
초기 설정이 번거롭긴 하지만 한번 구성하고 나면 별도 관리가 필요없고 Batch작업이 발생하는것과 컨테이너 이미지 보관비용 이외에는 추가 비용이 발생하지 않기 때문에 비용측면에서 장점이 있는 서비스이다.
위에서 이야기한 정기적으로 새벽마다 크롤링(Pull)방식으로 데이터를 복제해야하는 Use-Case를 구현하는것이 적당한 워크로드 구현방법이라 생각했기 때문에 AWS Batch 서비스를 사용하게 되었다.
circleci.com에 접속하여 Sign Up을 진행하면 GitHub과 BitBucket 계정을 연동할 수 있는데 일반적인 GitHub 3rd Party OAuth연동 진행을 하게된다.
위 그림처럼 모든 Repository가 확인되고 Follow할 Repository를 선택하면 초기 구성이 완료된다.
첫 연동이 되면 Build를 진행하게 되는데 위 그림과 같이 error를 보게 되는데 이는 기본적으로 circleci가 필요로 하는 기본 설정값(.circleci/config.yaml)이 없어서 발생하는 오류이다.
#!/bin/sh -eo pipefail # No configuration was found in your project. Please refer to https://circleci.com/docs/2.0/ to get started with your configuration. # # ------- # Warning: This configuration was auto-generated to show you the message above. # Don't rerun this job. Rerunning will have no effect. false
위에서 보이는것 처럼 config를 체크하는것도 하나의 가상머신(컨테이너)이 진행하는데 CircleCI콘솔에서 Spin up Environment 로그를 보면 Docker(18.09.6)로 aws Linux기반으로 환경구성을 하는 것을 알 수 있다.
Build-agent version 1.0.11727-b0960fc9 (2019-05-23T02:12:54+0000) Docker Engine Version: 18.09.6 Kernel Version: Linux 9a20a41aeae4 4.15.0-1035-aws #37-Ubuntu SMP Mon Mar 18 16:15:14 UTC 2019 x86_64 Linux Starting container bash:4.4.19 using image bash@sha256:9f0a4aa3c9931bd5fdda51b1b2b74a0398a8eabeaf9519d807e010b9d9d41993 ...
$ brew install circleci $ circleci orb list Orbs found: 43. Showing only certified orbs. Add --uncertified for a list of all orbs. circleci/android (0.1.0) circleci/artifactory (1.0.0) circleci/aws-cli (0.1.13) circleci/aws-code-deploy (0.0.9) circleci/aws-ecr (6.1.0) circleci/aws-ecs (0.0.8) circleci/aws-eks (0.1.0) circleci/aws-s3 (1.0.11) ... circleci/jira (1.0.5) circleci/jq (1.9.0) circleci/kubernetes (0.3.0) circleci/lein-nvd (0.0.2) circleci/maven (0.0.8) circleci/node (1.0.1) ... circleci/slack (3.2.0) circleci/twilio (0.0.1) circleci/welcome-orb (0.3.1) In order to see more details about each orb, type: `circleci orb info orb-namespace/orb-name` Search, filter, and view sources for all Orbs online at https://circleci.com/orbs/registry/
GitHub 또는 Bitbucket에서 관리하는 Repository가 CircleCI 프로젝트로 승인되면 최초에는 컨테이너나 가상머신환경(2core 4GB)이 프로비저닝 되고 자동으로 테스트가 진행된다.
테스트가 완료된 후 성공 또는 실패에 대한 Alert설정(Email, Slack)이 가능하고 각 단계(job, workflow)에 대한 결과는 각 단계별 세부 정보 페이지에서 확인할 수 있다.
또한 배포는 AWS CodeDeploy, AWS ECS, AWS S3, AWS EKS, Google Kubernetes Engine (GKE) 및 Heroku 등 다양한 환경에 코드를 배포하도록 구성 할 수 있다. 이외의 클라우드 서비스 배포는 SSH를 통해 직접 사용하거나 terraform과 같은 도구를 가지고 해당 클라우드 서비스의 API통해 자동화가 가능한 구조로 되어있다.
이는 Git Repository를 연동할때도 Java Plugin을 설치해야하는 번거로움을 덜 수 있다. 가장 중요한건 SaaS라는 장점도 무시할수 없다. Travis 무료 플랜과 비교해도 작은 프로젝트의 경우 별도의 Docker environment(2core, 4GB)를 제공받기 때문에 지연없이 바로 빌드가 가능하다는 점이다.
다음번 포스팅에는 terraform을 통해 ECR과 ECS로 배포하는 workflow를 살펴보려고 한다.
이번에는 Knative를 EKS에 구성해보려고 한다. 4월은 발표 및 여러가지 업무로 인해서 포스팅을 할 시간이 부족했지만 5월부터 조금씩 여유가 생겨서 더 바빠지기전에 좀 써보려고 한다. 사실 Facebook @최용호님께서 한번 해보는것도 좋겠다고 하셔서 테스트를 진행하였다.
제목만 보면 Lambda나 ECS, Batch 서비스가 있는데 왜 이걸 써야하지? 라는 생각부터 하는 사람도 있을것 같다. 하지만 이전 포스팅들과 발표에서도 여러번 이야기 한것처럼 Knative는 간단하게 서버리스 워크로드를 빌드, 배포, 관리하기 위한 Kubernetes기반 FaaS플랫폼이고 현재 CNCF Landscape에서 가장 빠른 속도로 개발되고 있는 오픈소스 프로젝트 중 하나이다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-24-168.ap-northeast-2.compute.internal Ready <none> 2m v1.11.9 ip-192-168-78-204.ap-northeast-2.compute.internal Ready <none> 2m v1.11.9
Istio injection을 하기 위해 배포할 defaults namespace 전체에 Labeling을 한다.
$ kubectl label namespace default istio-injection=enabled namespace/default labeled $ kubectl get namespaces --show-labels NAME STATUS AGE LABELS default Active 43m istio-injection=enabled istio-system Active 27m istio-injection=disabled kube-public Active 43m <none> kube-system Active 43m <none>
미리 Dockerhub에서 hello-python repository(docker.io/ddiiwoong/hello-python)를 생성한다.
그리고 위에서 생성한 build-bot 계정과 image tag hello-python정보를 Build template에 작성하여 배포한다.
아래 Knative Build 과정은 kaniko executor를 사용하여 다음과 같은 과정을 수행한다.
spec.source 에서 Source Clone (git)를 수행하고 이후
spec.steps 에서 Docker Build, Tag, Registry Login, Push를 수행한다.
kubectl get svc istio-ingressgateway --namespace istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.100.208.80 a220723d475df11e980220a02e220b34-2021915778.ap-northeast-2.elb.amazonaws.com 80:31581/TCP,443:31490/TCP,31400:30367/TCP,15011:32495/TCP,8060:31418/TCP,853:30310/TCP,15030:32405/TCP,15031:31410/TCP 13h
위와 같이 AWS LoadBalancer로 배포면 ALB가 자동으로 생성되므로 추후 eksctl로 클러스터를 삭제하기 전에 반드시 LoadBalancer 형태로 배포된 서비스를 삭제하고 진행해야 한다.
Knative Service를 확인한다.
$ kubectl get ksvc NAME DOMAIN LATESTCREATED LATESTREADY READY REASON helloworld-python helloworld-python.default.example.com helloworld-python-4rw95 helloworld-python-4rw95 True
위에서 얻은 두가지 정보(LoadBalancer, Domain)로 생성된 app을 테스트한다.
Knative는 내부적으로 example.com이라고 하는 기본 domain을 사용하므로 내부적으로는 helloworld-python.default.example.com으로 curl을 실행하게 된다.
$ curl -H "Host:helloworld-python.default.example.com" http://a220723d475df11e980220a02e220b34-2021915778.ap-northeast-2.elb.amazonaws.com Hello World: Python Sample v1 with Knative on EKS!
Cold Start(default timeout 5분) 때문에 잠시 응답이 늦어질 수도 있지만(2-5초) 잠시 기다리면 위처럼 결과를 확인할 수 있다.
위에서도 잠깐 언급했지만 Lambda나 ECS, Batch 서비스가 있는데 Knative on EKS 를 구지 왜 하느냐라고 궁금해하는 분들이 계실지도 모른다. 하지만 다들 아래와 같은 고민을 해봤을거라 생각한다.
컨테이너와 Kubernetes가 DevOps도구로서의 표준이 되어가는 시대에 Lambda를 쓸지 오픈소스를 쓸지에 대한 고민은 결국 이식성과 벤더 종속성을 제거하고 운영효율화 측면에서 그 답을 찾을수 있을것 같다.
현재 몸담고 있는 최근 프로젝트에서 Lambda, ECS, Batch 등을 사용하는 경우가 많아졌는데 실제 엔터프라이즈에서 정해진 자원내에서 정해진 일을 할때는 매니지드 서비스가 적합하다고 생각한다. 하지만 On-Premise 또는 그에 준하는 Kubernetes 클러스터를 운영하는 조직에서는 Knative를 사용하여 컨테이너 기반 서비리스 워크로드를 구현하는 것이 향후 Hybrid 관점에서 확장성과 벤더 종속성을 제거하는데 큰 도움이 될것이라 생각한다.
조금씩 Kubernetes 및 생태계 Learning에 대한 피로도가 증가하고 있고 Hype Driven Development(설레발 주도개발)가 되는것 같아서 아쉬운 부분은 있지만 현재 가장 핫한 기술이고 관심도가 높기 때문에 배워두면 언젠가는 써먹게 될거라 확신한다.
다시한번 Conference driven development(architecture)가 되지 않도록 자중하고 Loudest Guy가 되지 않도록 조심해야할 것 같다.
위 링크와 설정을 참고하여 아래 그림과 같이 Build Statud Badge를 달 수 있다. 
