티스토리 뷰
한빛 미디어에서 진행하는 공감 세미나에 다녀왔다. 공감 세미나는 자바까페에서 자주 발표하고 있는 행사 중 하나로, 반기별로 진행되는 것 같다. 지난번엔 같이 SQL 스터디를 하셨던 정재욱님께서 발표를 하셨었는데, 이번엔 Elasticsearch 스터디를 진행중이신 김흥래님께서 발표를 하셔서인지 의미가 남다른 행사이다.
DC/OS [발표자료]
Toss에서 DevOps로 근무하시는 최명규님의 발표였다. 레이니스트CTO, 카카오 서버개발자에서 DevOps로 전향하였기에 더 흥미로운 발표였다.
Toss는 금융서비스라 클라우드사용이 어려워 On Premise 환경에 구성하였는데, 서비스 수나 배포 수가 많아 자동화에 대한 니즈가 있었다고 한다. (Micro service 수 : 44개 이상, Container 수 : 200개 이상, 일일 배포 수 : 50회 이상)
1. 왜 DC/OS인가
UI를 통해 서버 클러스터 파악이 쉬우며, REST api를 이용하여 배포가 가능하다. 그리고 모든 서비스를 Docker container로 격리하여 cold booting을 없애고 Service discovery를 적극 활용하여 특정 서버/포트를 점유할 필요가 없어졌다.
2. 어떻게 도입하였는가
1) 처음에는 각 도구들을 튜토리얼 수준으로 만들어서 운영을 시작
-> 배포 프로세스가 나름 개선되었지만 코드 버그로 인한 Side-effect도 증가
롤백시 시간이 10여분 소요
2) 파이프라인을 도입하여 전체를 빌드하던 부분 개선
-> 롤백시 최소 2분 소요
Blue-Green 배포의 경우 배포 프로세스가 모두 완료되어야 트래픽 전환이 이루어짐
3) Canary 배포로 변경
-> 전체 트래픽 중 일부만 신규버전에 보내 안전한지 체크한 후 트래픽을 조정하는 방식
3. MSA vs Test
마이크로 서비스가 증가하면서 점점 로컬에서 테스트하기가 어려워졌다. MSA 통신방식의 단점으로, Service discovery를 통해야 통신이 되었기에 라이브에서 테스트해야 하는 경우나 특정 유저만 테스트해야 하는 경우 등의 상황에서 테스트하기 어려움이 있었다. 이에 개인 클러스터 개념을 도입하여 트래픽을 좀 더 세밀하게 제어하였다. 식별자를 두어 Service discovery에서 통제했던 것으로 보이는데 실제로 구현해봐야 좀 더 이해가 될 것 같았다.
4. 그 외
Auto-scaling(CPU, Memory 외에도 Tomcat의 Thread나 DB Idle count 등의 metric도 임계치 설정)
batch job 코드도 containter로 구성 (DC/OS slave 어디에서든 실행될 수 있도록)
로그 중앙 수집 (Service -> Kafka -> Elasticsearch or influxdb)
5. 데모
데모는 Toss의 grafana, marathon, consul 등의 웹 UI를 보면서 진행되었기에 매우 흥미로웠다.
몇 가지 동작을 했을 때 화면상으로 나타나는 여러 지표의 변화를 보거나 각 파이프라인들을 보니, 앞에서 간략히 설명했던 추상화된 개념들을 보다 직관적으로 이해할 수 있었다.
6. Service discovery의 metric을 통한 장애감지
- Connection reset : Service discovery의 reload시 트래픽 유실을 파악 (DNS unknown host도 같이보자)
- 5XX, 4XX : Response Type을 확인시엔 어떤 api에서 발생했는지도 확인
- 그 외 : CPU, JVM, api anomaly detection, network 등
7. 파이프라인
1) git master branch 변경사항 발생
2) building
3) staging에 배포
4) 정적 분석
5) integration test
6) 보안테스트
7) canary or blue green 배포를 개발자가 직접 수행
앞으로의 계획은 Slack을 통해 긴급 상황을 처리할 수 있는 api 서버를 구현하는 것이라고 하셨다.(ChatOps??)
8. 질문
Applilcation의 경우 Blue-Green/Canary 등을 통해 중단없는 배포가 가능하지만, Service discovery같은 component는 어떤 형태로 버전업을 하는지가 궁금했다. 이에 대해, Consul의 keyvalue store을 활용하여 사용할 Service discovery를 제어하여 rolling-update를 한다고 하셨다.
추가적으로, DB 스키마와 Application API Level에서 Sync가 안맞는 경우엔 Canary 배포는 불가하고 Blue-Green 배포로 진행해야 한다는 이야기를 들었다.
이 후에 네트워킹 옆자리에 앉게 되어 추가적으로 IDC 환경에서 유휴장비에 대한 문제를 어떻게 해결하는지 물어보았고, Toss는 비용부분에서는 비효율적일수는 있으나 장비는 가급적 여유있게 확충해놓고 운영한다고 하셨다.
JenkinsX [발표자료]
Redhat의 원종석님께서 발표하셨다. 이 발표는 JenkinsX를 활용하여 데모 배포를 하는 것으로 발표 전반을 이루었던지라, JenkinsX를 경험하는 측면에서는 매우 좋았으나 다소 긴장감이 떨어지는 시간이었다.
1. 도입 배경
우선, JenkinsX를 사용하더라도 기존의 pipeline이 바뀌지는 않는다. (Code change -> PR -> review -> merge -> staging -> production)
다만, On Premise에서 Cloud로, Baremetar/VMs 에서 Container로, Monolithics에서 Microservice로 변해가는 시점에서 Kubernetes가 산업상 표준이 되어가고 있어 Kubernetes상에서 Jenkins를 구현한 것이 JenkinsX이다.
2. 주된 기능
CI/CD 자동화, Multi Cloud 환경 대응이다. Kubernetes가 필요한 세팅(Jenkins pipeline)등을 자동으로 설정해주고, git 기반으로 개발/스테이징/운영환경 등의 Stage를 구성해준다. 또한 Pull Request를 생성했을 때 변경분에 대한 Application을 빌드해서 Container로 띄워 Review할 수 있게 해주는 부분은 꽤 흥미가 갔다.
3. 구성
JenkinsX는 Jenkins(CI/CD pipeline), Nexus, Helm, ChartMuseum(Helm Chart Repository), Monocular(Web UI for helm chart), Skaffold 등으로 구성되어 있다. 그리고 jx 명령어로 제어 가능하다.
JenkinsX는 git 생태계에 대한 오랜 고민들을 잘 반영하여 CI/CD가 잘 구현되어 있다는 인상을 받았으나, Operation과 관련해서는 엿볼 수 없어 DevOps라고 하기엔 한계점이 있어 보였다.
Elasticsearch [발표자료]
네이버 비즈플랫폼의 김흥래님께서 발표를 하셨다. 원래는 이번 세미나 전에 책을 전부 출간하는게 목표이셨으나, 계획했던 시리즈 중 1권인 아파치 루씬에 관한 책만 출간된 채 발표를 하게 되었다.
1. 장애경험 공유
1) Cerebro가 노란색으로 바뀐다면
우선 지켜본다. 해소가 안되면 껐다 켠다. 혹은 더 지켜본다...
노란색의 의미는 replica가 있으므로 서비스에는 문제가 없다는 의미이다. 하지만 기존의 replica shard가 master node로 전환되었기 때문에 새로운 replica shard를 생성하다보니 부하가 걸리기 시작한다.
그런데 때때로 replica shard가 생성되었는데 CPU가 올라가기 시작하는 경우가 있다. 죽었던 노드가 복구되면서 다시 Shard를 분산하기 때문이다.
이러한 리밸런싱이 모두 완료되어야 정상으로 변경된다. 이런 경험을 통해 볼 때, 복구 메커니즘에 따른 적절한 데이터 분산(Node수 혹은 Shard수)이 필요하다. 왜냐하면 일반적으로 Shard 단위만큼 장애시 replica로 데이터가 이동하면서 네트워크 대역을 차지하기 때문이다.
일반적으로 데이터 사이즈는 Compressed OOP를 고려할때 32GB 이상을 권장하지 않는다고 한다. 그리고 replica set의 개수는 많아질수록 읽기 성능이 좋아지나, 인덱싱될 때마다 전부 복사가 이루어지며 복구과정에서의 비용이 크므로 자신의 상황에 맞추어 고민하여야 한다.
내부 네트워크는 가급적 10G로, 같은 라우터 안에 클러스터를 구성하는 것이 좋다.
2) Elasticsearch는 Transaction을 지원하지 않기때문에..
쓰기 작업을 하면 즉시 Indexing하지 않고 Queue에 쌓은 후 index thread pool에서 처리한다. 이에 bulk 요청 후 read할 경우 원하지 않는 결과가 나올 가능성이 크다. 이 경우 refresh=wait_for 옵션을 주면 indexing하고 replica set에 복사된 후 리턴된다. 그러나 이 경우 시간이 어느정도 걸리는지 테스트해봐야 한다.
3) Kibana를 헤비유저에게 오픈할 경우..
각 요청이 aggregation call이므로 구성 등에 따라 node에 부하를 줄 수 있다. 그래서 최근 Elasticsearch는 coordinating node를 제공한다. kibana는 coordinating node에 요청을 하게 되고 이 노드가 각 elasticsearch node에 요청을 하는 구조이다. 즉, 중간 버퍼역할을 하게 된다는 것인데 이 또한 coordinating node가 죽었을 경우에 대한 근본적인 한계를 갖고 있다. 결국 대안으로는 xpack을 사용하여 인가 및 접근권한 세부화하는 것인데, 이는 비용이 많이 나간다. 다른 대안으로는 proxy를 도입하여 kibana 앞에서 기한 설정 등을 관리하는 것이 제시되었다.
4) Aggregation시 장애지점이 될만한 부분
Elasticsearch의 Aggregation은 Solar와 가장 구별되는 부분으로, 기존 Lucene의 facets과는 별도로 자체적으로 구현한 기능이다.
만약 distinct 요청으로 cadinality 연산을 할 경우, 값이 아닌 데이터리스트를 주고 받는 상황에서 데이터사이즈가 크면 coordinating node가 죽는 이슈가 발생할 수 있다. 이에 Elasticsearch는 Hyperloglog++ 알고리즘을 이용한 근사값을 사용한다. 이 경우 threshold를 설정하여 샘플링 갯수를 지정할 수 있는데, 정확한 값은 자신의 데이터사이즈/건수/노드수 등을 고려하여 테스트해봐야 한다.
그렇다면 UV, PV처럼 정확한 값을 보여주어야 하는 경우는 어떻게 해야 할까?
Unique 처리한 데이터로 별도의 인덱스를 생성해서 관리하는 방식이 고려될 수 있다. 아니면 실시간 처리와 배치 처리된 데이터를 나눠서 보여주는 방안도 고려될 수 있다.
2. 장애방지를 위한 제안
우선, 모니터링을 cluster/node/index 구성별로 나눠서 하여야 한다. (이때부터 시간이 촉박해서인지 빠르게 지나가서 아쉽다. 운영하면서 좀 더 metric를 살펴봐야겠다.)
그리고 환경설정에 Priority가 있다는 것을 처음 알았다. persistent, transitent, 논리적인 index 설정, 물리적인 index 설정순으로 설정이 적용된다. 가능하면 물리적인 설정은 Node명/Node타입/네트워크설정만 하도록 하고, 클리우드 전체에 적용되는 설정은 REST를 이용하여 논리적으로 설정하는 것이 좋다. 그리고 반드시 Runtime 환경에서 설정값을 확인해보아야 한다. '_cluster/settings?include_default=true'으로 실제로 설정된 값들을 확인 가능하다.
3. 대용량 클러스터를 위한 제안
데이터 노드간에 네트워크 트래픽이 많이 발생하므로 의존성을 줄이시키기 위해서 Master node는 분리시키는 것이 좋다.
그리고 가능한 64G 장비에서 Elassticsearch에 31G만 할당하고 나머지는 Lucene이 쓰도록 하는 것이 좋다. Elasticsearch는 mmap을 통해 시스템 콜이 빈번히 발생하기 때문이다. 분산클러스터 특성상 고사양 서버보다는 저사양 서버 다수가 더 효율적이라고 한다. 그리고 앞서 이야기했듯 64bit 시스템이더라도 heap 메모리가 32G 이하일 경우 Compressed OOP를 사용하여 32bit 포인터 사용이 가능하므로 이를 활용하는 것이 좋다. (Context switching 등에서 Inode와 같은 메타데이터의 저장공간을 줄이기 위함인데 실제로 엄청난 성능차이가 발생하는 것도 아니고 SSD를 사용하는 등 다른 조치들이 더 효율적이므로 이 부분에 너무 스트레스받지는 말자)
4. 클러스터 최적화를 위한 벤치마크
rally를 사용하여, cluster 설정들을 바꿔가면서, 벤치마크를 돌려봐야 최적화된 클러스터를 구성할 수 있다.(https://www.elastic.co/kr/blog/announcing-rally-benchmarking-for-elasticsearch)
그리고 kibana monitoring으로 시계열정보도 같이 보는 것이 중요하다.