[후기] NHN FORWARD 2022 세션 별 상세 정리

안녕하세요. 오두막 입니다.
오랜만에 NHN FORWARD 를 참여하였는데, 좋은 기회로 세미나에 참석할 수 있어 재미있는 시간이었습니다.

아래는 제가 들었던 세션 별 정리 입니다.

키노트

• GAME
  • GamwAnvil
  • GameTalk
    • Game Package Manager
• 데이터 플랫폼 - NHN DATA 이진수
  • 좋은 기술?
    • 고객이 혜택을 체감할 수 있을때 고마운 기술이라고
    • 고마운 기술
    • 사용할 수 있는 데이터를 만드는 것에 집중
  • DBTI Type 비즈니스 유형에 따른 기술 적용
  • 올바른 데이터를 확보할 수 있도록 돕고 비즈니스를 성공할 수 있도록 돕는다
• 클라우드 - NHN Cloud 김명신
  • Toast Cloud를 2021년 NHN Cloud로 변경
  • 100+ Services + 150+ Solution
  • NKS (Kubernetes)
    • 국내 퍼블릭 클라우드 사업자 중 최초/유일
    • Cloud Native 기술력 보유
• AI - NHN Cloud 박근한
  • AI 인프라
  • 프레임워크
  • 깊은이해
  • 일상 속에서 누구나 사용 가능한 보편적인 AI
  • 작은 발걸음이 큰 차이를 만든다

편안한 휴식 시간을 지켜줄 안정적인 백엔드 운영과 개발 기법

• 들어가기
  • 개발 담당자가 서비스를 운영한다는 롤을 가지고 있다.
    • 장점
      • 빠른 장애 대응
      • 최적의 서버 구성
      • 설계/개발 단계에서 운영 고려
    • 단점
      • 운영이 전문적이지 않아서 불안하다
      • 장애로 인해 주말에도 제대로 쉴 수 없다
      • 운영 전문가보다 비전문적이다
        • 개발과 운영 두분야를 잘해야한다
    • Dooray!를 운영하면서 고민했던 이야기
      • 사용자가 많아지면서 장애가 발생하기 시작했다
    • 자동 재시작 (self-healing)
      • 서버의 재시작이 필요한 경우
        • Garbage collection death spiral (죽음의 소용돌이?)
          • 메모리 사용량보다 CPU사용량이 증가하여 heap과 관련된 이슈
          • 원인: 해제되지 않는 객체 참조 등
      • -XX:+OnOutOfMemoryError='kill -9 %p'
      • -XX:+OnOutOfMemoryError='lb_out.sh; sleep30; kill.sh %p'
      • out of memory만 문제일 것인가?
      • kubernetes의 LivenessProbe
        • kubelet
      • 위험관리
        • 위험대응
          • 정지->생각->호흡->행동
          • 성급한 대응은 상황을 악화시킨다
        • 자동화
          • 반복된 패턴은 자동화 지향한다
          • 당황해서
        • 스레드차단
    • 과부하를 처리하는 방법
      • cascading failures
        • 소수 서버의 문제가 다른 서버의 문제로 이어지며 발생
      • 지표의 측정 (가시화)
        • CPU 사용량, Active thread 수, 분당 메일 수신건 수
      • 지표 측정 결과
        • 동시에 많은 대용량 메일이 수신됐을 때
      • 대응방안
        • Scale Up/Out
          • 낭비될 수 있다
        • Message Broker
        • AutoScale
          • 단시간에 폭증하는 요청을 Auto Scale이 커버 할 수 없다
        • Circuit Breaker
          • 대표적인 해결법이지만, 장애시 일시적으로 사용자에게 노출됨
        • Too Many Request(429)
          • 사용자에게 노출되지 않는 API에만 적용
          • 비용이 높은 API에 적용
    • 백엔드에서 HTTP Cache 활용
      • 한정된 자원에서 효율적으로 사용하는 방법
      • HTTP Cache
        • Cache-Control 헤더
        • Etag 헤더
        • If-None-Match 헤더
        • 304 Not Modified를 백엔드에 활용 할 수 있을까?
        • 주의
          • Shared Cache 기본 설정: public인 경우만 cache
          • HTTP Cache는 GET에서만 적용됨
    • Netty로 구현한 소켓서버
      • 사용자의 요청 데이터에 비해 응답 데이터 크기가 매우 큼
• 다이빙 강사가 들려주는 개발이야기

분산 시스템에서 데이터를 전달하는 효율적인 방법

• 분산시스템
  • 목표를 달성하기 위하여 여러 개의 컴퓨터 리소스를 사용하는 시스템
• 데이터를 전달하는
  • MessageQueue를 사용한 데이터 전파
• 효율적인 방법
  •  
• 데이터 전달 보장 방법론
  • At most once delivery (최대 한번 전달)
    • 장점
      • 간단한구조
      • 간단한 개발
    • 단점
      • 누락 가능성이 있음
  • At-least-once delivery (최소 한번 전달)
    • 장점
      • Producer는 메시지 발송 보장
      • 효과 대비 쉬운 개발
    • 단점
      • 같은 메시지를 여러번 받을 수 있음
      • 역등성있게 개발이 필요
  • Exactly-once (정확히 한번 전달)
    • 장점
      • 누락과 중복이 없음
    • 단점
      • 가장 어려운 개발 난이도
• RDB를 사용하는 애플리케이션에서 전달 방법
  • 서비스별 데이터베이스 패턴
  • @transactionalEventListener + @Retryable
  • 마이크로서비스 아키텍처 패턴
    • Transactional Outbox Pattern
      • 하나의 트렌젝션에 묶어서
    • Polling Publisher Pattern
  • 장점
    • REST-API 환경에서 At-least-once를 구현할 수 있다
  • 단점
    • Polling, Publisher 과정으로 인한 지연 처리
    • 데이터베이스 부하
    • 데이터베이스 비례한 처리속도
• RabbitMQ를 사용한 전달 방법
  • RabbitMQ
    • AMQP 를 구현한 메시지 브로커
  • Producer Confirm, Consumer Ack
  • Queue에서 정상적으로 처리하지 못한경우 Retry 후 Dead letter로 이동
• Kafka를 사용한 전달 방법
  • Producer Confirm, Consumer Ack
• 성능에 따라 최소

Hadoop 개발 환경 구축과 MySQL 기반 배치를 Hadoop으로 옮긴 이야기

• Hadoop 개발 환경 구축
  • NameNodes 2대(Automatic failover), DataNodes 2대
  • service db sqoop
  • Automatic failover
    • Journal Nodes가 EditLog 기록 및 반영
    • Zoo Keeper와 ZKFC(Zoo keeper failover controller)가 헬스 체크
    • Zoo keeper와 Journal Node는 4대의 서버에서 3대만 설치 (매커니즘과 관련됨)
• Hadoop HA 구축
  • prefix 설정 core-site.xml
  • Active가 두대가 구동되지 않도록 설정 fencing method / hdfs-site.xml
  • data, journal 파일 위치 설정
  • yarn을 사용하기 위해서 리소스매니저의 위치 지정 / yarn-site.xml
• ZooKeeper
  • zoo.cfg
    • tickTime=2000
    • initLimit=10
    • syncLimit=5
    • dataDir=/var/lib/zookeeper/ 인메모리기반 스냅샷 저장
    • clientPort=2181
    • server1=서버2ip:2888:3888 (2888:zookeeper끼리, 3888: 새로운 리더 선정에 쓰이는 포트)
  • ha.zookeeper.quorum / core-site.xml
• Hive 1.1.0 설치
  • 메타 데이터 저장에 MySQL을 사용하기 때문에 설정 필요
  • Mysql 커넥터 설치
  • schematool 실행 (MySQL상에 Hive 메타데이터가 저장됨)
• MySQL 5.7 설치
  • HIve 계정생성
• Airflow 설치
  • 패치 스캐줄링 플랫폼
  • airflow.cfg
    • 명령어에 대한 결과분 저장 위치
    • timezone은 Asia/Seoul
    • web페이지 접속정보 포트
  • 초기화를 위한 airflow initdb 실행
• Sqoop 설치

MySQL 기반 배치를 Hadoop으로 옮긴 이야기

• 일별 log 수집(유저 게임, 결제 내역)
• 일별 집계와 월 1회 집계만 사용하는 서비스
  • update, insert가 없이 select만 있는 서비스
• Hadoop 기반 배치
  • 컬럼 기반 parquet 사용
• 성능 비교
  • Quartz, spring batch, MySQL
  • Hive, impala, airflow
    • 1/5 속도 감소
  • 조회하는 부분에 속도 개선이 있었음
• impala 및 airflow는 기존에 사용하고 있어서

모바일 해킹 사례와 NHN AppGuard를 활용한 대응 방안

• 리세마라
• 모바일 해킹 유형
• Android
  • 정적분석
    • IL 데이터 확보
  • 동적분석
    • FRIDA
      • 프리다 후킹 동작 원리 - 인라인 후킹
• 앱의 수명을 늘리기 위해서는
• 대응 방안
  • 서버 검증
    • 현실적으로는 재화나 민감한 데이터만 검증한다
  • 클라이언트의 라이브러리 코드 변조 & 인라인 후킹 탐지 방법
  • Unity 엔진 보호
    • 난독화 하는 방법
• iOS
  • 해킹 유형
    • 탈옥
    • tweak (cydia에서 설치)
      • 함수 후킹을 통해 파라메터 변조
    • 디버깅
      • API에 break point 를 설정하여 보안모듈 탐지 및 우회
    • 앱 위 변조
      • 코드 변조 플랫폼
  • 대응 방법
    • 탈옥 탐지
      • Cydia 앱 탐징
      • P_TRACED플래그 체크하여 debuger 확인
      • tweak 이 특정경로에 존재하는지 확인
      • 메서드 스위즐링 탐지
        • 코드영역에 주소가 있는지 확인
      • 앱 위 변조 탐지
        • 핵심 정보에대한 정보를 서버에 전달하여 서버에서 확인

빠른 정보 제공을 위한 통계 시스템 개선기

• 람다 아키텍처를 통해
• 스피드 레이어에서는 실시간 데이터 처리 후 데이터 웨어하우스에 저장
• 배치 레이어에서는 데이터 레이크에 원본을 저장하고 배치 수행
• 시각화 레이어에서는 데이터 분석 레이어
• 엘라스틱 서치
• 데이터 수집기
  • 메모리, 장애 취약, 실시간 X, 저장소
• 배치

DDD 뭣이 중헌디? 🧐

• DDD에서 전략적 설계가 중요하다.
• 그외 오해들
  • 은탄환이다
  • MSA로 귀결된다
  • 방법론이다
  • 기술이나 구현 영역이다
    • 전술적패턴에 함몰되어 발생하는 오해
• DDD는 구체적인 방법론이 아니고 추상적이다
• 도메인
  • 비지니스 도메인 (티켓팅)
    • 현실세계
  • 문제 도메인 (인터넷예매)
    • 소프트웨어세계
  • 문제 도메인 추출하고 하위 도메인을 추출하는것은 문제공간이라고 한다
    • 핵심 하위 도메인 (예매)
      • 핵심 도메인은 경쟁사 우위를 가져야하고 복잡도 높으며 내부(in-house)에서 개발해야 한다
    • 지원 하위 도메인 (도면, 상품)
    • 일반 하위 도메인 (회원)
  • 해결공간에서 지식 탐구는 개발자가 추가된다
  • 브라운 필드 전략적 설계
    • 초창기에 적용하지 않는다
  • big ball of mud
    • 방대한 복잡성을 해결하기 위한 전략적 설계를 사용
  • 전략적 설계 시 유용한 도구
    • 사용 사례 분석 (use-case)
    • 이벤트 스토밍
    • 비지니스 모델 분석
  • DDD의 핵심은 의사소통이 필요하다
  • 전략적 설계 vs 전술적 설계
  • 전략
    • 전반적
    • 문제 도메인을 해결영역으로
    • 전쟁에서 전략
  • 전술
    • 특정 Bounded-Context
    • 풍부한 도메인 모델 적용
    • 전투에서 전술
• Bounded-Context
• 콘웨이의 법칙
  • 조직의 구조가 소프트웨어의 구조를 만든다
• 역콘웨이의 전략
  • 개발하는 조직의 구조를 소프트웨어의 구조에 맞춘다.
• 일종의 철학이다.
• DDD에서 전략적 설계가 중요하다
• 지식 탐구 커뮤니케이션
• 언제 어디서나 유비쿼터스 언어로 설명한다
• 이해당사자와 지식합의가 필요하다

1.