as

_posts/2022-10-19-Logging.md

@@ -0,0 +1,120 @@
+---
+layout: post 
+title: "로그에 대한 여러 생각"
+authors: [iju1633]
+tags: ["logging"]
+image: ../assets/images/post-Logging/thumbnail.png
+featured: true
+---
+
+## 로그를 주제로 다룬 이유
+최근 로그를 모니터링하는 것에 큰 흥미를 갖게 되었습니다.  
+
+스프링 액추에이터를 프로젝트에 적용해보며 콘솔에 남아 있는 로그를 http로 볼 수 있다는 것도 신기했고 Backend 팀에서 스크럼을 진행하며 인프라 분야 분들이 스프링 액추에이터와 다른 서비스를 연동하여 매트릭 관리를 하고 있다는 것을 언급해주셨어서 로깅하는 것에 대한 관심이 깊어졌습니다.  
+
+또한, 이슈 트래킹 시간을 줄이기 위해 로그를 기록하는 것은 필수적이라는 말을 들으며 평소에 로그를 적극적으로 활용하지 못했던 것 같아 이제부터 로그를 기록하는 습관을 들이고자 합니다.
+
+
+# 로그를 왜 남기는 가
+![archieve](../assets/images/post-Logging/archieve.png)  
+1. 에러에 대한 단서(= 문제 대응)
+    - 예기치 않은 에러가 발생할 수 있는 가변적인 데이터에 대해 로그를 남긴다면 에러를 찾을 확률이 올라갑니다. 특히, 로그 레벨(ERROR, INFO, DEBUG 등)을 활용해서 장애 원인을 더욱 빠르게 파악할 수 있도록 할 수 있습니다.
+    - 로그 레벨을 활용하여 설정한 레벨 이상의 로그 메시지를 찍을 수 있습니다.
+2. 자신이 분담한 파트에 대한 결백
+    - 로그의 결과를 보여줌으로서, 자신이 맡은 부분에 있어서 에러는 없었다는 것을 입증할 수 있습니다.
+3. 테스트나 디버깅에서 활용성이 높습니다.
+4. 트래킹, 모니터링에 활용
+    - 데이터 분석
+    - 진단용
+5. 에러의 규모를 파악하기 위해서 활용(= 에러 관리 측면)
+6. 복구용
+    - 트랜잭션 실패 시, 로그를 참고하여 롤백할 수 있습니다.
+        - 데이터 복제에도 사용될 수 있습니다.
+
+
+## print문으로 로그를 남기는 것이 적절한가
+개인 프로젝트라면 사용해도 무방하다고 생각합니다. 그러나 좋은 개발 습관을 위해서라면 로깅 라이브러리를 활용한 로깅이 적합하다고 생각합니다.  
+
+추가적으로 print문을 사용한 로깅은 성능에 영향을 많이 준다고 해서 찾아보니, 파일이나 콘솔에 로그를 남기게 되면 해당 print문이 완전히 프린트 되기 전까지 뒤에 프린트하려는 부분은 대기할 수 밖에 없어 대기 시간이 발생한다고 합니다.  
+
+printf가 비효율적인 이유에 대해 더 자세히 알아봤습니다.  
+1. 중복적으로 작성이 되어야 하고, 하드코딩할 필요가 없어집니다.
+2. printf는 동기적인 방식이라 작업이 io 작업이라면 부하가 커져 성능에 있어 단점이 됩니다.
+3. 로그 파일을 따로 남기지 않는다면 배포 이후에는 로그를 활용할 수 없습니다.
+
+
+## 어떤 정보를 로그로 남겨야 하고, 남기지 말아야 하는 가
+![public_private](../assets/images/post-Logging/public_private.jpg)  
+
+**남기면 좋은 데이터**  
+- 날짜와 시간
+- 요청자의 ID와 같은 유일한 값
+- 접근한 경로, 에러코드
+- 행동 로그, 서비스 로그
+    - 고유한 ID 값을 저장해서 추적용으로 사용하기도 합니다.
+        - 필요한 context 저장
+        - 쓰레드별로 로그 분류하기
+
+**남기면 안되는 데이터**  
+- 개인정보
+  - 남겨야한다면 암호화 이후 저장하는 것을 추천합니다.
+- 시스템 계정 정보
+
+추가적으로, DevOps나 Infra 관리를 시스템적으로 하지 않는다면, 로그가 저장되는 저장소 관리는 어떻게 이루어질 건지 명확한 계획이 있어야 할 것입니다.
+
+
+## 로그를 어디에 남기는 가
+1. 코드 위치 기반
+    - 클래스나 메소드에 진입하거나 결과를 리턴하기 직전 등의 위치를 기반으로 로그를 작성합니다.
+    - 기능 문맥 기반에 비해 서비스 로직의 전후를 잘 살필 수 있습니다.
+    - 에러가 발생했을 때, 시간 순으로 어떻게 흘러갔는 지 파악하기 용이하지만 여러 요청들이 혼합되어 로그가 매우 많이 쌓였을 때, 필요한 부분을 필터링해서 보는 것이 좀 까다로울 수 있습니다.
+2. 기능 문맥 기반
+    - 기능별, 레이어별로 로그를 파악할 수 있고, 키워드 검색이 가능합니다.
+    - 같은 기능에 따라 중복된 로그가 남겨지기에 구별할 수 있는 정보가 추가적으로 필요합니다.  
+
+개인적으로 자신이 구상한대로 서비스가 잘 흘러가고 있는 지 파악하는 용도로 사용하는 경우가 많았어서 코드 위치 기반으로 로그를 남겼던 경우가 많았던 거 같습니다.
+
+
+## 무엇으로 로그를 분석하는 가
+1. Elastic Search
+    - appender를 사용하여 로그를 consumer에게 제공하기도 합니다.
+    - 오래된 로그는 cold storage, 주로 쓰는 것은 object storage에 저장하기도 합니다.
+2. kafka
+    - 메시지 큐 활용
+3. 스프링 액추에이터
+    - 로그 시각화
+    - 로그 분석
+
+
+## 로깅 라이브러리
+1. slf4j (추상체)
+    - 자체적인 로킹 프레임워크가 아니고 logger 추상체로써 다른 로깅 프레임워크가 접근할 수 있도록 도와주는 추상화 계층이입니다.
+      - 즉, logback이나 log4j2와 같은 로킹 프레임워크의 인터페이스의 역할을 합니다.
+    - 코드를 일정하게 유지하면서 구현체의 전환을 통해 다른 로깅 프레임워크로의 전환을 쉽고 간단하게 할 수 있습니다.
+2. LogBack
+    - slf4j의 구현체로 springboot 환경에서는 spring-boot-starter-web에 포함되어 있어 dependency 추가 없이 사용 가능합니다.
+    - 로그 레벨 변경에 대해 서버 재시작 없는 자동 리로딩을 지원해줍니다.
+3. log4j
+    - 가장 오래된 로깅 프레임워크로 콘솔 및 파일 출력의 형태로 로깅 지원합니다.
+4. log4j2
+    - logback과의 가장 큰 차이는 Multi Thread 환경에서 비동기 로거(Async Logger)의 경우 다른 로깅 프레임워크보다 처리량이 훨씬 많고, 대기 시간이 훨씬 짧습니다.
+    - Java8부터 도입된 람다식을 지원합니다.
+    - 쓰레드 로컬을 사용하지 않아 성능이 더욱 좋습니다.
+        - async appender
+        - async logger
+            - 쓰레드 로컬을 사용하지 않아 garbage collector를 거의 사용하지 않아도 되는 게 성능 향상의 원인입니다.
+
+
+## 매트릭이란
+![log_metric](../assets/images/post-Logging/log_metric.png)  
+- 타임스탬프와 보통 한두 가지 숫자 값을 포함하는 이벤트입니다.
+- 로그와 다르게 주기적으로 발생합니다.
+- 단순한 상태를 보여줍니다.
+- 리소스 사용 모니터링, 데이터베이스 실행 메트릭 모니터링 등 소프트웨어나 하드웨어의 상태 모니터링 맥락에서 사용합니다.
+- 주로 원인이 있어 찍는 것이 로그에 해당하며, 단순히 상태를 보여주는 것이 매트릭입니다.
+
+
+## 블로그를 마치며..
+여러분들도 글을 읽어 보며 어떻게 하면 로그를 잘 쓰고 남길 수 있을 지 고민해보시길 바랍니다.  
+부족함이 많은 글이지만, 로그에 대한 자신의 생각을 정리해볼 수 있는 계기가 되는 글이 되었으면 좋겠습니다.  
+따라서 저도 기존 프로젝트에 스프링 액추에이터를 적용하고 기록해보며 로깅에 대한 좋은 개발 습관을 만들어보고자 합니다.

_posts/2022-10-21-save-data-without-server.md

@@ -0,0 +1,170 @@
+---
+layout: post
+title: "서버 없이 데이터를 저장하고 싶어요!"
+authors: [baebae02]
+tags: ["web", "웹 스토리지", "클라이언트"]
+image: ../assets/images/post-save-data-without-server/1.jpg
+featured: true
+---
+
+# 서버 없이 데이터를 저장하고 싶어요!
+
+웹 개발을 하다 보면 정보를 기억해야 하는 순간이 꼭 옵니다. 회원가입 시 입력한 개인정보뿐만 아니라 이전 페이지에서 무엇을 체크했는지와 같은 사소한 선택지도 있겠죠?
+
+<aside>
+❓ 이러한 데이터를 저장하려면 꼭 데이터베이스와 서버가 필요 할까요?
+
+</aside>
+
+정답은 **“아니다”** 입니다!
+
+우리는 **웹 브라우저에서 제공하는 db를** 사용해 데이터를 저장할 수 있어요. 브라우저의 db를 사용할 수 있는 방법엔 “IndexedDB, Cookies, Web storage(Local, Session)”등이 있습니다.
+
+<aside>
+💡 IndexedDB, Cookies, Web storage(Local, Session)를 통해 브라우저에 데이터 저장 가능
+
+</aside>
+
+오늘은 위에서 언급한 **4가지 방법**을 모두 다루려고 합니다!
+
+![image](../assets/images/post-save-data-without-server/1.jpg)
+
+## WebStorage
+
+웹 스토리지는 웹 개발을 한다면 한 번쯤은 사용하게 될 친구입니다. **Local Storage, Session Storage** 두 가지가 있는데, 이 둘의 차이는 **'무엇을 기준으로 저장되느냐?’**에 있습니다.
+
+### Local Storage
+
+로컬 스토리지는 창, 즉 브라우저를 기준으로 저장됩니다. **한 브라우저당 하나의 Local Storage**을 가집니다. 만약 내가 한 창안에서 여러 탭을 띄웠다면 이 탭들은 같은 Local Storage를 공유합니다. 그래서 한 탭에서 다른 탭으로 이동해도 Local Storage에 저장된 데이터는 사라지지 않습니다. 하지만 사파리와 크롬을 하나씩 띄웠다면, 이 두 브라우저는 각각 다른 로컬 스토리지를 갖고 있겠죠?
+
+Local Storage에 저장한 데이터를 지우려면 **JavaScript를 코드로 삭제하거나 브라우저의 캐시 또는 local Storage 데이터를 직접 지워야**합니다. 그 때문에 로그인이나 접속 이력 등을 관리할 때 편리합니다.
+
+
+### Session Storage
+
+세션 스토리지는 탭, 즉 세션을 기준으로 저장됩니다. 한 탭 당 하나의 Session Storage를 가집니다. 때문에 내가 탭을 이동하면 이동한 탭의 세션 스토리지는 이전 탭의 스토리지와 다릅니다!
+
+Session Storage에 저장된 데이터는 탭 또는 창이 종료되면 자동으로 삭제됩니다. 이런 이유로 Local Storage보다 데이터 보존 시간이 짧다는 것입니다.
+
+Session Storage는 수강신청 탭에서 세션만료를 체크할 때 사용하거나, 사용자가 '입력폼'을 입력하다가 페이지를 벗어난 경우 백업하기 위해 사용하기도 합니다. 
+
+<aside>
+💡 저장 공간은 Local Storage > Session Storage 입니다.
+
+</aside>
+
+### 사용법
+
+```jsx
+// 키에 데이터 쓰기
+window.localStorage.setItem("key", value);
+window.sessionStorage.setItem("key", value);
+
+// 키로 부터 데이터 읽기
+window.localStorage.getItem("key");
+window.sessionStorage.getItem("key", value);
+
+// 키의 데이터 삭제
+window.localStorage.removeItem("key");
+window.sessionStorage.removeItem("key", value);
+
+// 모든 키의 데이터 삭제
+window.localStorage.clear();
+window.sessionStorage.clear();
+
+// 저장된 키/값 쌍의 개수
+window.localStorage.length;
+window.sessionStorage.length;
+```
+
+### 예제(Local)
+
+- F12를 눌러 개발자 도구에 들어간 상태에서, 콘솔창에 다음과 같이 쳐봅니다.
+- 그런 다음 ‘Application’에 들어가줍니다.
+
+![image](../assets/images/post-save-data-without-server/2.png)
+
+![image](../assets/images/post-save-data-without-server/3.png)
+
+- LocalStorage에 들어가 보면 value를 “gdsc”로 갖는 데이터가 저장되었음을 볼 수 있습니다.
+- 이미 다른 데이터도 많이 저장되어 있죠? 제가 설치한 크롬 확장 프로그램에서 저장해 둔 데이터인 것 같습니다.
+- **탭을 껐다 켜도 남아있어요. 한번 테스트해보세요!**
+- Session Storage도 같은 방식으로 테스트할 수 있습니다.
+
+### IndexedDB
+
+다음으로는 IndexedDB입니다.
+
+> IndexedDB는 관계형 데이터베이스(RDBMS)와 같이 트랜잭션을 사용하는 데이터베이스 시스템입니다. 그러나 IndexedDB는 RDBMS의 고정컬럼 테이블 대신 JavaScript 기반의 객체지향 데이터베이스입니다.
+>
+
+사용할 수 있는 웹 스토리지 중에서 제일 실제 데이터베이스와 비슷하달까요!
+
+문자열 타입의 키&값을 사용해야 하는 webStorage와 달리 IndexedDB에서는 js가 취급하는 모든 타입을 사용할 수 있습니다. 여러개의 데이터베이스를 생성할 수 있으며, **데이터를 요청하고 응답받는 과정이 비동기적으로 작동한다**는 점이 특이사항입니다.
+
+그 때문에 단순하고 적은 양의 데이터가 아닌, 많은 양의 구조화된 데이터를 쌓고 싶을 때 추천합니다 😎
+
+## 사용순서
+
+1. 데이터베이스 열기
+2. 데이터베이스에 객체 저장소(*Object store*) 생성하기
+3. 요청 보내기
+   트랜잭션을 사용해서 보냄. (`readonly`, `readwrite`, `versionchange`)
+4. 요청이 완료될 때까지 기다리기
+5. 요청 결과를 가지고 어떤 동작하기
+
+<aside>
+❓ 트랜젝션이란 db의 상태를 변화시키기 위해 수행하는 작업 단위
+
+</aside>
+
+**예시코드**
+
+```jsx
+//1. 데이터베이스 열기
+const idxedDB = window.indexedDB;
+const request = idxedDB.open('SampleDB');
+
+//2. 데이터베이스에 객체 저장소 생성하기
+IDBRequest.createObjectStore('store_name', {keyPath: 'id'})
+
+//3. 트랜젝션 사용하여 요청 보내기
+IDBDatabase.transaction(store_names, mode, options);
+
+//4. 이후 get, put, delete, create를 통해 데이터 수정 가능
+const objStore = transaction.objectStore('name');
+const request = objStore.add(name); //[POST]
+const objStoreRequest = objStore.get(key); //[GET]
+const updateRequest = objStore.put(value); //[PUT]
+const objStoreRequest = objStore.delete(key); //[DELETE]
+```
+
+> **C(create), R(read), U(update), D(delete)**는 데이터베이스를 사용하기 위한 기초적인 4가지 쿼리 형식이며, 줄여서 **CRUD**라고 부른답니다!
+indexedDB에서는 CRUD에 해당하는 메소드들이 **add, get, put, delete**로 정의되어 있어요 :)
+>
+
+# 총정리
+
+|  | session storage       | local storage                       | indexedDB            |
+| --- |-----------------------|-------------------------------------|----------------------|
+| 용량 | 가장 적음                 | 보통                      | 가장 큼                 |
+| 수명 | 탭이 닫히면, 세션이 만료되면 삭제 됨 | 코드를 통해서 삭제하거나 직접 삭제. 창이 꺼져도 삭제되지 않음 | 코드를 통해서 삭제하거나 직접 삭제. |
+| 방식 | 동기                    | 동기                                  | 비동기                  |
+| 형식 | 문자열 타입만 가능            | 문자열 타입만 가능                          | JS 자료형 가능            |
+| 여러개의 데이터베이스 | X                     | X                                   | O                    |
+| 난이도 | ⭐️                    | ⭐️                                  | ⭐️⭐️⭐️               |
+
+<aside>
+❓ web storage와 함께 쿠키 & 세션에 대한 개념도 같이 공부하시길 추천합니다 !
+
+</aside>
+
+[쿠키와 세션을 이용한 로그인 (feat. JWT)](https://gdsc-university-of-seoul.github.io/Login-using-cookie-and-session/)
+
+### References
+
+[브라우저 저장소 (Cookie, WebStorage,Indexed DB)](https://velog.io/@yebb/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%A0%80%EC%9E%A5%EC%86%8C-Cookie-WebStorageIndexed-DB)
+
+[cool-dawn-szlel](https://codesandbox.io/s/cool-dawn-szlel?file=/src/App.vue)
+
+[indexedDB에 대해 알아보자!](https://mong-blog.tistory.com/entry/indexedDB%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90)