2021 SLASH 21

Park.Dyel·2021년 7월 22일
0

conference

목록 보기
1/2
post-thumbnail

SLASH 21

SLASH 21을 들으면서 내용을 정리해본다. 해당 도메인에 대해서 지식이 전무한 상태로 작성한 글이 대부분이기에 사실에 대한 이해보다는 어떤 노력을 했는지 살펴보기로 했다. 내용도 이해못하면서 적어두는 이유는 연상기억이라도 해보려고 노력하는 것이다.

DAY 1

토스의 서버 인프라 모니터링

K8S이 접근성이 훨씬 높았을텐데, 어떤 장점이 있어 DC/OS를 사용했을지 궁금하다. DC/OS는 정말 처음 들어봤다.

도표

범례인프라모니터링
이전DC/OS + vampinfluxdb + telegraf
이후Istio + kubernatesprometheus + thanos
  • DC/OS: 컨테이너 오케스트레이션 엔진
  • vamp: 마이크로 서비스의 서비스 디스커버리 API Gateway

전환 후 장점

  • 이전에는 API Gateway에 장애가 발생하면, 전체로 전파되었지만 클라이언트 사이드 로드밸린싱인 Service Mesh를 사용하여 하나의 인스턴스에서 장애가 발생해도 영향이 적어졌다.
  • Service Mesh를 사용하면서 이전보다 풍성한 네트워크 매트릭을 쌓을 수 있었다.

토스 서비스를 구성하는 서버 기술

사용하는 기술에 대해선 거의 모르겠다. 이렇게 하는구나 싶다... 진짜 모르겠다...

서버 구성

  • K8S + Istio + Ceph(민감 정보에 대한 내부 스토리지 서비스로 사용)
  • 내부 캐시는 데이터 보존 문제와 optimistic lock 구현 편이성으로 인해 Memcached에서 Redis cluster를 캐쉬로 활용

Application

  • WebFlux:
  • reactor:
  • reactor의 러닝커브가 커서 coroutine 도 사용할수 있게 했다고 하는것 같다.

SRE 사례 소개

문제를 해결하는 과정에 대해서 차분하게 설명해주셔서 되게 좋았다

  1. redis rebalancing

    • bigkeys가 있는 경우 migrate가 오래 걸린다.
    • cluster fix
    • lettuce를 사용하는데 multi-threading 환경에서 버그가 있어서. ASK 에러가 발생했다고 한다. Key를 기반으로 migrate 중에 한 Key에 대해 여러 요청이 발생했을 때, 이미 해당 key는 destination으로 이동 된 경우, A 요청에 의해 Source(원래 Key가 있던 노드)에 키가 없는걸 확인하고 Destination에 ASK를 요청하지만, 이때 Source에서 키가 없는걸 확인하고 의해 Destination에서 ASK 처리를 하게 되면, A 요청이 연속적인 행위를 할때, 이미 관련된 처리가 이루어졌기 때문에 Destination에서는 source 에게 redirect 처리하게 된다. 이 과정에서 maxAsk 값인 2가 되면서 ASK가 발생했다고 한다. (이 내용은 전혀 모르는 상태로 이해했기 때문에 잘못된 내용일 것이다. 그럼에도 이러한 과정에 대해서 적어두는 이유는 이슈가 있을 때 사용하는 도메인에 대해서 이해력이 높아야 되는걸 보여주는 사례라고 생각해서이다)
  2. Memcached Redistribute

    • Spymemcached 라이브러리에서 한개의 노드에 장애가 발생했을 때, 재분배 과정을 거치는 데 특정 일부 키의 경우는 또 다시 죽은 노드를 가르키도록 코딩이 되어 있었다. 라이브러리의 주석상에는 1/2^7의 확률(Ketama Hash)로 죽은 노드를 가르키게 되어있었다고 한다.
  3. Prometheus Scrapping

    • 변화에 대한 로그(배포, DevOps 변경 등)
    • 로그 메시지
    • 메트릭

실수 없이 안전하게 쿠버네티스 운영하기

쿠버에도 이것저것 붙는구나...

  1. ArgoCD를 이용한 GitOps 패턴

    • Git을 Single Source of Truth 로 여긴다는 전제로 시작함
    • 이때 Git 상의 템플릿을 현재 상태가 아닌 의도된 상태로 정의함
  2. OPA(Open Police Agent)로 휴먼 에러 방지하기

테스트 커버리지 100%

믿음과 시간, 그리고 의지의 문제이다..

결론

  • 테스트 커버리지는 얼마든지 높일 수 있다.
  • 테스트 커버리지가 낮으면 빌드를 실패하도록 하자.
  • 테스트는 빨라야 한다.
    • 프로파일링해서 개선하는 방법도, 그리고 돈으로 머신을 더 크고 아름답게 하자.
  • 커버리지가 100%라도 버그는 있다.
  • 그럼에도 믿고 배포할 수 있으므로, 부담없는 리팩토링을 통해 코드 가독성을 유지할 수 있다.
  • 테스트 커버리지 100%는 할만한다.

결제 시스템의 SDK와 API 디자인

사용하기 쉬운 API를 위한 노력

  • 의외로 많은 가맹점이 HTTP 메소드의 PUT과 DELETE를 사용할 수 없어, 여러가지 고민을 하게 되었다. 결국 GET/POST만 사용하고 path의 마지막에 동사로 동작을 나타내므로 일관성 있는 Path 구조를 작성하였다.
  • Header의 Accept-Language를 통해 Localization을 구현했다. 에러 메세지를 예로 들수 있을것 같다.
  • JavaScript SDK를 설계할 때 인자명을 최대한 선언적으로, 줄임말 없이 선언하려고 했다.
profile
ㄱH발자

0개의 댓글