인프콘 2023 골라보기 5가지

 

소프트웨어 설계를 위한 추상적 구조적 사고

 

 

• 모델: 세상을 표현하기 위한 방법
  • 분류
    • Categorizing
    • Grouping
  • 추상화
    • Projection
    • Layering
  • 일반화
    • Pattern ex) 디자인패턴, 재사용 함수

 
추상화와 구조화는 함께간다.
 
소프트웨어 구현 단계
1. 도메인 모델링 : 비지니스 로직을 프로그래밍 언어로 표현하는 것
2. 아키텍쳐
3. 코드작성
 
로직

• usecase - 어떤 기능을 위해
• aspect - 어떤 관점에서
• function - 로직을 구성하는 함수

 
리팩토링 : 코드를 수정하는 것

• 패러다임
• 코드크기
• 소유권
• 중복여부
• 수정가능성
• 의존

 
리팩토링 방법
1. 추상화 : 코드 내용을 숨길지
2. 구조화 : 코드를 분리할지 합칠지
3. 일반화 : 공통 코드를 분리할지 중복시킬지
 
추상적, 구조적 사고를 하는 방법

• 내가 백엔드여도 프론트엔드에 관심을 가지기
• 다른 언어도 사용해보기
• 여러 패러다임을 경험해보기
• 다른 서비스를 모델링해보기
• 도식화해보기 ex) UML
• 패턴을 많이 익히자
• CS 공부도 하자

 

---

 

2곳 중 1곳은 무조건 합격하는 개발자 이력서 만들기

 

 

포트폴리오의 프로젝트 설명 구조
1. AS-IS (문제 상황) 

• 내가 만들고 싶은 기능
• 내가 해결해야 하는 문제
• 프로젝트를 진행하면서 맞닥뜨릴 수 있는 모든 문제

2. Challenge (해결방안)

• 어떤 기술로 이 문제를 해결했는지
• 왜 이 스택을 선택했는지
• 왜 이런 로직을 작성했는지

3. TO-BE (결과)

• 아웃풋
• 프로젝트의 결과

 

---

 

API First Design과 CodeGen 활용하기

 
 

 
API 문서 관리의 어려움을 겪는 경우가 많다.

• 문제1) API를 만들기 위해 먼저 설계를 하며 만든 문서와, 프론트엔드 개발자에게 전달하는 문서를 따로 만들게 되는 문제
• 문제2) 나중에 변경사항으로 수정은 했지만 API문서는 업데이트 하지 않은 경우

 
1. API First Design 이란?
open API 명세 기반의 API계약서를 우선순위 1로 고려하여 협업하여 설계하는 것
 
2. API First Design으로 문제 해결하기
프로세스

• 1단계) OpenAPI 명세서 설계
• 2단계) 반복적 설계(토론+공유) 
• 3단계) Open API 도구 활용&구현
  • -> 원하는 형태로 API를 생성할 수 있다. ex) 노션, swagger 등
  • -> Code Generator로 코드를 자동으로 생성해준다.
  • -> Mock Server로 선 테스트를 할 수 있다.
• 4단계) 프론트엔드개발자에게 전달하기

 
차이점: 기존에는 코드를 먼저 만들고 API를 전달함 (Code First) 

장점
1. API 변경에 대한 히스토리 관리를 할 수 있다. -> versioning 을 제공해줌
2. 공통 API 문서를 통해 함께 협업할 수 있다. -> One source, Multi Using 서로 다른 팀이더라도 같은 소스를 가질 수 있다.
3. 이해관계자들과 함께 풍성한 내용이 담긴 API를 만들 수 있다. -> 용어, URL, 적절한 요청/응답을 논의하며 만들 수 있다.
 
 

---

 
왜 구글 시니어 개발자는 코딩을 안할까?
 
 

 
 
발표자분이 했던 얘기 중
시니어분이 제일 많이 쓰는 언어는 뭔가요? 영어요 
제일 많이 쓰는 IDE는 뭔가요? 구글독스요
라고 했다는 말을 듣고 웃겼습니다.ㅋㅋ
 
 

저는 지금 중니어 개발자인 것 같네요! 스태프 개발자 이후로는 대마법사로 퉁친게 재밌습니다ㅋㅋㅋ
 
개발업무에 코딩+시간+사람 이 있다면
연차가 적을 때는 코딩의 비율이 높고, 쌓일수록 시간, 사람에 비율이 높아진다고 합니다.
 
시니어 개발자들이 하는 것 "곱빼기 코딩" 

• 주기적인 리팩토링으로 코드의 스파게티화를 막는다. 
• 좋은 테스트 패턴을 적용, 추후 테스트 작성을 쉽게 만든다
• 흔히 할 수 있는 실수를 예방하도록 Best Practice Guide 작성 및 Linter Rule 적용
• 새로운 기능의 안전한 배포를 위해 A/B 테스팅 프레임워크 도입
• 개발 조직에서 자주 사용되는 기능을 모듈화 "바퀴 재발명"을 막는다.

--> 개발의 생산성을 높인다.
 
ex) 아마존 

 
 
이러이러한 기능 만들어주세요! 할 때 드는 생각..ㅋㅋㅋ

 
발표자가 기술관리자에게 코딩을 못해서 슬프지 않으신가요? 라는 물음에
사람을 관리하는 것도 코딩 같다. 오히려 더 어려운 코딩이라고 하셨다는 말에 오.. 그럴 수 있겠구나 생각했습니다.
 

---

 
 
패션 이커머스 서비스의 아키텍처 성장 기록

 

 

 

29cm의 마이크로서비스 전환

1. 전환 원칙

1) 스트랭글러 패턴

• 기존 기능과 동일한 로직을 신규 서비스에 구현한다
• LB 등을 활용하여 기존 서비스와 신규 서비스에 트래픽을 적절히 분배한다
• 신규 서비스의 검증이 완료되면 모든 트래픽을 신규 서비스에 전달하고 기존 서비스 로직은 제거한다

2) 새 기능은 신규 서비스로 구현
없앨 모놀리식 서비스에 추가할 필요가 없다

3) 임팩트 기준으로 모놀리식 분해 순서 결정
도메인의 의존 관계를 생각하면 가장 하단의 도메인을 먼저 전환하는 것이 좋다. ex) 유저, 인증, 푸시
하지마, 비즈니스 임팩트가 큰 것을 먼저 전환할 때 얻게 되는 이익을 생각하자. ex) 상품, 커머스

4) (선택) 기존 서비스는 인증과 트래픽을 분배하는 역할로 활용

당시 7명의 개발자로는 마이크로 서비스 전환 시 개발, 운영, 모니터링 등이 필요하게되는데 불가하기 때문에 동료 개발자를 채용했다고 합니다.

심지어 기존 파이썬, 장고 기술스택으로는 채용이 쉽지 않아서 자바, 스프링으로 기술스택까지 전환해서 채용을 했다고 하는데 의지가 정말 대단한 것 같습니다.
또한 기존 멤버들에게 자바 스프링을 익힐 수 있는 충분한 시간과 기회를 줬다고 하는데 부러움을 느꼈습니다..!

마이크로서비스 전환 팁

모놀리스는 무조건 나쁘다?
-> 상황에 따른 선택일뿐 나쁘지않다

다양한 기술 스택을 사용하는게 좋다?
-> 자유도가 높지만 팀의 상황과 효율을 생각해야한다.

도메인을 처음 쪼갤때 세분화가 좋다?
-> 우선 크게 쪼개고 이후에 세분화하자. 쪼개면 쪼갤수록 운영 비용이 크게 든다.

성장 과정에서의 도전

1. 장애 발생

거래액의 증가, 트래픽의 증가, 다양한 기능의 추가와 코드 변경

- 23년 상반기 동안 11번의 장애발생. 22년 23번의 장애 발생
- 목표 수치 SLO 99.85% 는 유지했다
- 대부분 30분 안에 해결됨. 일부는 1시간 넘게 지속됨

ex)  검색과 추천 서비스 장애

순간적으로 20% 이상 높게 인입된 트래픽으로 인한 장애

-> ElasticSearch에는 그 이상의 부하가 전달됐다고 한다.

-> ES 장애

ElasticSearch 가 처리하는 요청

1. 검색 요청 2. 상품 조회를 위한 요청

장애 회고

1. 장기관점 해결책
모놀리틱에서는 하나의 API로 전달 가능한데 마이크로서비스에서는 도메인별 API를 호출하고 응답값을 조합해야함
-> Materialized View 구축

 

• API를 한번만 호출하면 되도록.
• 클라이언트가 필요로 하는 정보를 정의하고 각각의 도메인 서비스에서 필요한 정보를 사전에 수신하여 별도 저장 (실시간이 중요하기때문에, 배치보다는 비동기 메시징 기반의 갱신을 추천한다)
• 클라이언트는 반정규화된 정보의 집합을 빠르고 단순하게 조회할 수 있다.
• 어떤 DB를 쓰는게 좋을까? -> json에 특화돼있으면서 Write성능이 조은 MongoDB를 추천

2. 단기 관점 해결책

1) 추천 서비스 -> ES호출 시 실제 필요한 필드만 요구하도록 변경
100여개의 필드가 있는데 전부 다 가져오고 있었는데 불필요한 필드를 제거하여 CPU와 Memory사용을 최적화함 (OOME제거)

2) fallback 로직 구현
장애 발생 시 디폴트 응답을 제공할 수 있도록함.
일정 주기마다 응답을 로컬캐시에 저장하고 장애발생 시 미리 저장한 추천 응답을 활용하기.
ex) 쿠버네티스 feature flag 평상시에는 off 장애 발생 시 on으로 바꾸면 로컬 캐시에 저장한 응답을 리턴해줄 수 있음

3. ElasticSearch 클러스터의 노드 증설 (scale out)

• ES 전체 성능 확장을 위해 노드 증설
• 가장 쉽고 빠른 대응 (비용을 지불하고 시간을 산다.!)
• 하지만 항상 해결할 수 없다. 근본 원인을 해결하는게 좋다.
• 동일한 사유로 동일한 장애가 발생하지 않도록 하는 팀구조를 갖는 것이 중요하다.

 

도전2. 서비스 품질 유지의 어려움

스쿼드 중심 개발의 문제점

1) 스쿼드 내의 개발과 운영을 주도하는 개발자들은 스스로의 의사결정과 구현에 대한 고민을 갖게됨. 지금 잘하고 있는것인지
2) 소수의 시니어 개발자들이 모든 서비스의 설계와 개발을 도맡아 하는것은 불가함
-> 서비스의 일관성을 유지하면서 빠른 개발 속도를 유지할 수 있어야함.
-> 개발 디자인 문서를 작성한다!

개발 디자인 문서의 주요 항목

• 문제 정의 , 목표
• 해결방안
• 제약조건
• 대안
• 배포 방법
• 운영 및 모니터링 방법 등

 

29cm의 개발 디자인 작성 문화

1. 담당 개발자가 스스로 해당 문서를 작성하고
2. 이를 주요 개발자들에게 리뷰 요청한다.
3. 문서 리뷰 과정에서는 개발 방향이 유효한지, 보완해야할 점은 없는지, 좋은 대안이 있는지 등 논의한다.
4. 개발자들은 개발을 진행한다.

-> 담당 개발자는 설계와 개발 방향을 잡아갈 수 있고, 문서 작성 과정에서의 개인의 설계 역량, 글쓰기 역량을 키울 수 있다.
-> 한정된 시니어 개발자의 리소스도 충분히 활용할 수 있다.
-> 시스템의 일관성, 업무속도, 구성원의 성장을 모두 얻을 수 있다.

회사의 성장과, 개발자의 성장에 도움이된다.!

---