Update Posts

- 2024 당근 테크 밋업 - 메모 및 후기 (SERVER)
- [우아한테크토크] 선착순 이벤트 서버 생존기! 47만 RPM에서 살아남다?!

Author: devFancy

_posts/2024-02-03-Technology-Woowa-Tech-Talk-First-Come-First-Served-Event.md

@@ -9,7 +9,7 @@ author: devFancy
 
 ## 선착순 이벤트 배너
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-1.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-1.png)
 
 - 역대급 이벤트
 - 어떤 반응인지 커뮤니티를 참고
@@ -19,7 +19,7 @@ author: devFancy
 
 - 장애나는 날 전화가 폭주함
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-3.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-3.png)
 
 - 2가지 큰 목표를 잡음
 - 개발 기간이 1~2주 → 빠르게 개발, 최대한 기존 로직은 건드리지 않고 새로운 시스템을 가지고 구성하려했음
@@ -32,23 +32,23 @@ author: devFancy
 
 ## 기존의 주문 시스템
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-4.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-4.png)
 
 - 주문에 들어가기전에 여러 유효성 검사처리를 하고, 해당 데이터들을 세션에 저장을 한다.
 - 고객이 주문지연 웹 뷰에 들어와서 정보를 입력 → 결제 → 결제완료 ⇒ 하나의 주문 건 완성
 - 하나의 주문이 완성하려면 수십건의 API 요청을 해야함
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-5.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-5.png)
 
 - 이렇게 “주문”은 여러 개의 시스템과 연계되어있음
 
 ### 이벤트시 문제점
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-6.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-6.png)
 
 - 평소보다 10배이상 트래픽이 발생하게 됨
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-7.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-7.png)
 
 - 주말피크와 이벤트 최고 RPM 차이는 약 **150배** 차이가 남
 - 예상하지 못한 트래픽이 발생함(예상: 10배, 실제 150배)
@@ -64,7 +64,7 @@ author: devFancy
 - 김성주의 안내로 번호표를 통해 대기줄을 빠르게 정리되고 있었음
 - 저희는 이 김성주에 집중을 했음 ⇒ 모든 트래픽을 차례대로 처리할 수 있을 만큼 들여보내자.
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-8.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-8.png)
 
 - 일단 Redis를 선택함
 
@@ -76,38 +76,38 @@ author: devFancy
 
 > 어떤 요구사항인가?
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-9.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-9.png)
 
 ### 해결 - Sorted set
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-10.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-10.png)
 
 - 해당 자료구조 하나로 쉽게 처리할 수 있었음
 
 > 레디스 사용시 고려사항
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-11.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-11.png)
 
 - Keys 명령어는 쓰면 장애가 남
 - 각 명령어의 시간복잡도를 확인해봐야 함 ⇒ Sorted Set의 경우 시간복잡도 O(log(n))
 
 ### 큐 시스템 플로우
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-12.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-12.png)
 
 - 이벤트 주문 요청을 하면 → 대기번호 발급 받음
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-13.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-13.png)
 
 - 현재 내 상태(참가열, 대기열)에 있는지 → 대기열이면 몇 번인지 조회
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-14.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-14.png)
 
 프로모션 스케줄러를 통해서 뒤로 흘리는 TPS를 조절
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-15.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-15.png)
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-16.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-16.png)
 
 - 순간적인 **대량 트래픽** 소화
 - 이제는 트래픽을 일정하게 보낼 수 있게 됨
@@ -116,22 +116,22 @@ author: devFancy
 
 하나의 문제점 → `큐 시스템`을 **중간에 어떻게 끼워넣지?**
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-17.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-17.png)
 
 - 우아한형제들 회사에서 만든 `주문라우터` 를 이용
 - `주문라우터`에 있는 해당 Rule을 이용한다.
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-18.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-18.png)
 
 - 회원번호, 업소번호를 보고 → Rule에 들어있으면 ⇒ 설정된 post로 라우팅을 해준다. ⇒ 큐 시스템으로 넘어간다.
 - 만약 Rule 에 들어있지 않으면 → 주문 으로 넘어간다.
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-19.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-19.png)
 
 - 일반 사용자는 기존 프로세스의 경우 **주문 라우터 → 주문**
 - 쿠폰발급 + 이벤트업소의 경우 **주문 라우터 → 큐 시스템 → 주문** 순으로 구현
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-20.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-20.png)
 
 - AWS 사용하는 경우 주문 시스템을 “이벤트용 주문”에 복제해서 큐 시스템 뒤에 붙였음
 - 이렇게 하면 일반 사용자는 해당 영향을 받지 않도록 시스템을 격리시킴
@@ -140,19 +140,19 @@ author: devFancy
 
 ## 최종 아키텍쳐
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-21.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-21.png)
 
 > 모니터링 - CloudWatch
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-22.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-22.png)
 
 - 주요 서버들, 확인해야할 지표들만 가지고 대시보드로 구성해서 모니터링을 진행함
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-23.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-23.png)
 
 - 어드민을 만들어서 대기열, 참가열 모니터링, 변수 셋팅을 했음
 
-![](/assets/img/tech_insight/Woowa-Tech-Talk-First-Come-First-Served-Event-24.png)
+![](/assets/img/technology/woowabros/Woowa-Tech-Talk-First-Come-First-Served-Event-24.png)
 
 - 이상 이벤트에 대한 대응을 잘했음
 

_posts/2024-11-24-Technology-Daanggn-Tech-MeetUp-2024.md

@@ -61,7 +61,7 @@ author: devFancy
 
     * [3] 화면에 표시하기 위한 뷰 작성 (ex. 문의 처리 화면)
 
-![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-1.png)
+![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-1.png)
 
 #### 문제 상황
 
@@ -71,7 +71,7 @@ author: devFancy
 
     * 코드를 추가하거나 수정할 위치를 찾기 어렵고, 응답 시간이 길어지면서 성능이 저하된다.
 
-![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-2.png)
+![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-2.png)
 
 #### 해결 방안 `1단계`: 서비스별 API 분리
 
@@ -85,7 +85,7 @@ author: devFancy
 
     * 하지만 각 서비스 정보 조회 API를 보면, 여전히 너무 많은 코드가 API 메서드 1개에 작동되고 있다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-3.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-3.png)
 
 #### 해결 방안 `2단계`: 역할 기반 분리
 
@@ -101,7 +101,7 @@ author: devFancy
 
     * 역할이 분리하고 난 뒤에 다른 서비스에 있는 `사용자 정보 조회` 를 봤더니, 결국에는 모든 API가 비슷한 형태로 된 것을 확인할 수 있다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-4.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-4.png)
 
 #### 해결 방안 `3단계`: 서비스별 API 통합
 
@@ -113,7 +113,7 @@ author: devFancy
 
     * 하지만 이는 서비스가 추가될 때마다 이 분기문 길이가 길어지면서 다시 코드가 복잡해지는 문제가 발생한다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-5.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-5.png)
 
 #### 해결 방안 `4단계`: 메타 프로그래밍 도입
 
@@ -123,7 +123,7 @@ author: devFancy
 
     * 여러 언어(JavaScript, Java, C++ 등)에서도 이 `메타 프로그래밍` 을 쓸 수 있다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-6.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-6.png)
 
     * 정리하면, 초기에 문제가 되었던 200줄이 넘는 코드와 평균 응답 시간이 2초(2000ms)가 걸렸고, 한 메서드 안에서 여러 서비스에 대한 사용자 정보를 순서대로 요청하고 응답받는 구조이다.
 
@@ -137,7 +137,7 @@ author: devFancy
 
     * 새로운 서비스를 추가하더라도 한 번 API 호출 할 때 하나의 서비스 정보만 불러오기 때문에, 응답 시간에는 영향을 미치지 않는다. 이는 확장성의 의미인 **최소한의 사이드 이펙트** 로 새로운 기능을 추가할 수 있는 상태가 되었다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-7.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-7.png)
 
 * 규칙 기반 UI 생성
 
@@ -257,13 +257,13 @@ author: devFancy
 
     * 발생 빈도가 높지 않거나 핵심 기능에 미치는 영향이 적다면 바로 대응하지 않고 모니터링을 걸어둔 채, 현재 하고 있던 작업을 빠르게 마치도록 한다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-8.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-8.png)
 
     * 반대로, 발생 빈도가 높거나 핵심 기능에 미치는 영향이 크다면 빠르게 원인 파악을 들어가고, 현재 작업과 에러에 대한 대응하는 두 가지 중 **사용자에게 더 큰 가치를 전달하는 것인지를 고민**하고
 
     * 그 과정에서 현재 작업을 완료하는 것이 더 중요하다면, 현재 작업을 완료하고 에러를 대응하기로 한다.
 
-    ![](/assets/img/tech_insight/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-9.png)
+    ![](/assets/img/technology/daanggn/Daanggn-Tech-MeetUp-2024-Ops-Dev-Team-9.png)
 
 * 이 에러 대응 프로세스에서 가장 중요했던 지점은 **이 에러가 어떠한 양상으로 서비스에 영향을 미치는지 파악**하는 것이다.