Big Tree

임대 서버의 경우, 해당 서버 상태를 주시하고 문제가 생겼을 때 바로바로 처리가 가능해야한다. 지금이야 트래픽이 많이 발생하지 않지만 언젠가는 문제 생길 수 있다. 더불어 트래픽이 넘친다면 서버 스케일에도 변화를 줘야하기 때문에 더욱 중요하다. 따라서 현재 사용중인 슬랙에 메시지를 적용시키기로 했다. 프로세스는 다음과 같다 1. 서버 내 문제 발생 2. 모니터링 시스템 감지 3. 슬랙 채팅 전송 4. 앱으로 채팅 메시지 확인 여기서 1-3번을 내 로컬 서버에서 처리할 수 있는 시스템이 구축되어야 한다. 4번은 슬랙 앱이 알아서 해주니까. 찾아보니 슬랙 플러그인 중 웹후크라는 것이 있다. API로 텍스트를 JSON으로 전송하면 선택되어 있는 채널에 메시지를 날려준다. Slack app directory 에..

앱을 개발하다보니 푸시알림이 발생할 경우, 아이콘에 숫자 뱃지를 달아줘야 했다. 근데 이게 이렇게 복잡한 것인줄 몰랐다.... 괜히 Sendbird(채팅 API 회기업) 가 기업가치가 1조가 된게 아니다. 그냥 숫자만 달아주면 되는거 아닌가? 싶었는데, 고려할 부분이 너무나도 많고, 버그라도 발생하면 숫자 꼬이기가 너-무 쉽다. 우선 우리 앱은 푸시알림이 2가지 타입이다. 1.채팅 푸시 2.알림 푸시 (새 공지, 새 일정 등록 등등) 내가 생각한 루트는 2가지 이다. 1.서버에서 푸시를 날려서 local에 도착할때마다 local client에서 숫자++ 하는 것. 2.서버에서 푸시에 숫자값을 같이 날려 local client에서 보여주기만 하는 것. 당연히 전자가 처리하기 편하다. 서버는 푸시만 날리고 ..

여러 프로세스를 사용하면, 같은 메모리 공간을 건드리는 경우도 있을텐데 그러면 문제가 발생할 것이다. 가령 남의 메모리 공간을 지워버린다거나.. 수정한다거나.. 코드를 캡슐화하는 것과 조금 비슷한 고민이라고 생각한다. 즉 Q. 어떻게 메인 메모리를 프로세스간에 공유할 수 있을까? Q. 어떻게 각각의 메모리들을 보호할 수 있을까? 이와같은 물음에 대해 우리는 가상 메모리 개념을 도입한다. 가상 메모리는 physical memory의 주소값을 갖는 형태로, 프로세스별로 각각 독립된 가상 메모리 공간을 가지면 physical memory에 가상 메모리에 담긴 주소값으로 접근하는 것이다. Virtual Memory -> Physical Memery 로의 전환은 MMU(Memory-Management-Unit)이..

"값이 싸면서 처리속도가 빠른 메모리는 없다" SRAM을 활용하는 캐시메모리는 값이 비싸지만 속도가 빠르다 > 0.5ns - 0.2ns per $500 - $1000 DRAM을 활용하는 메인메모리는 값이 싸지만 속도가 느리다 > 50ns - 70ns per $10 - $20 비싼 재료를 쓰면 맛은 좋지만 가격이 많이 나가는 원리랄까.. 이러한 메모리 처리속도의 문제는 컴퓨터 동작에서 문제를 일으킨다. 가령 CPU가 데이터 내놔!! 라고 소리지르는데, 램은 처~언~처~언히 주는 경우, 지연(latency)가 발생한다. 따라서 램보다 빠른놈을 중간에 둬서(캐시) 연산을 하면, 많이 쓰는 놈은 중간놈(캐시)에게 두면 좀 편안해진다. CPU < 캐시 < 메인메모리(RAM) < HDD 순서로 두는 것이다. CPU..

Flutter 로 iOS에서 작업 중이다. FCM 사용중이고 최근에 앱 아이콘에 뱃지를 달아주기 위해서 background or terminated 상태에서도 동작하는 코드를 구현해야 했다. (ex. 메인 위젯에서 1, 2, 3 푸시 알림 쌓이는거 ...) firebase_messaging 패키지 8.0.0 버전을 썼는데, 문제는 해당 동작이 이뤄지지 않았다는 것이다. FirebaseMessaging.onBackgroundMessage(_firebaseMessagingBackgroundHandler); Future _firebaseMessagingBackgroundHandler(RemoteMessage message) async { AppIconBadger().add(); } *이때 콜백함수는 class..

SQL Join은 두 개 이상의 테이블에서 데이터를 결합하는 것을 의미함. 합집합의 개념이라고 보면 된다. 크게 보면 INNER JOIN / OUTER JOIN 두가지로 나눌 수 있음 OUTER JOIN은 INNER JOIN과 달리 일치하지 않는 데이터도 포함하여 두 개 이상의 테이블에서 데이터 결합함. OUTER JOIN에는 LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN 세 가지 유형 - LEFT OUTER JOIN: 왼쪽 테이블의 모든 레코드와 일치하는 오른쪽 테이블의 레코드를 반환하고, 일치하지 않는 경우 NULL 값 반환 - RIGHT OUTER JOIN: 오른쪽 테이블의 모든 레코드와 일치하는 왼쪽 테이블의 레코드를 반환하고, 일치하지 않는 경우 NULL 값 반환 - FU..

현재 실시간 문서 협업 기능과 채팅 시스템 도입을 진행 중이다. HTTP 한계상 실시간에는 어울리지 않고, 이를 통한 오버헤드 또한 결국 트래픽 비용이므로 Websocket 활용한 클라이언트-서버 시스템을 구축해야 한다. Flask 로 진행중이므로 해당 스펙에 맞는 적절한 라이브러리를 찾아야 했다. SocketIO 가 꽤 인기있는 라이브러리이지만 결론적으로 선택하지 못했다. SocketIO는 WebSocket + HTTP (polling , long-polling ...) 을 결합한 것으로 WebSocket을 미지원하는 브라우저의 경우 HTTP 로 폴링한다고 한다. 그러나, SocketIO 공식 문서에 보면 다음과 같이 나와있다. 웹소켓을 활용하나 결국엔 SocketIO 만의 추가 메타 데이터가 필요하다..

HTTP 에 대해서 구글링하면 무수히 많이 나오는 내용 ★☆HTTP 통신 vs 소켓 통신 차이점★☆ 결론만 말하면 HTTP 통신은 소켓 통신이다. " 1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜입니다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송됩니다. " " 연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖입니다. HTTP는 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않습니다; 다만 그저 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시) 연결을 요구할 뿐입니다. 인터넷 상의 가장 일반적인 두 개의 전송 프로토콜 중..

*공부하면서 정리한 부분이라 잘못된 부분이 있을 수도 있습니다. 암호화 방식은 (1)대칭키 암호화 방식과 (2)공개키(비대칭키) 암호화 방식이 있다. 대칭키 암호화 방식 대칭키 암호화 방식은 암호화, 복호화를 오직 한 가지 키값으로 진행하는 방식으로, 해당 키값이 해커에 의해 노출되면 복호화가 된다는 단점이 있다. 예) A가 B에게 비밀번호를 보내려고 한다. A가 특정 키값으로 비밀번호 텍스트를 암호화를 하여 변형시킨다. (키값+비밀번호) 데이터를 함께 B에게 보낸다. 앗! 근데 사실 C가 A와 B 사이 네트워크를 감시하다가 해당 내용을 봤다. 복호화 키값을 알고, 비밀번호 텍스트도 알고 있으니 그냥 알고리즘 방식에 따라 복호화를 진행하면 원래 내용이 보인다. 이런 방식의 공격자(C)를 막기 위해서, 키..

웹 개발 中 클라이언트는 HTTP 를 통해 서버에 해당 웹문서를 요청하고 서버는 해당하는 요청에 따라 문서를 응답하는 형식을 기본으로 한다. 이것이 우리가 통용하고 있는 웹서비스의 구조이다. 요청과 응답, 이 두가지 개념을 갖고 그 위에 다양한 기술들이 쓰이는 것 뿐. 쿠키(Cookie) "하루동안 이 창을 열지 않음" 과 같은 것을 본 적이 있을 것이다. 여기에 체크를 하게 되면 클라이언트의 쿠키에 해당 값을 False 로 지정할 수 있도록 처리되는 것이다. Set-Cookie : eventPopup = 'False' 처럼 말이다. (그냥 이해하기 쉬운 예시임. 이렇게 안할듯) 나중에 이런 것들이 쌓여서 Cookie 값들을 만들어내고 웹서버에 요청을 할때, 같이 전달해서 수고를 더는 것이다. "네가 필..