👉 효과성이란 효과성(Effectuation)이란 성공한 창업가들이 불확실한 상황에 대처하여 의사결정하는 하나의 방법이다. 이 방법은 우리에게 주어진 자원을 이용해 기회를 만들어내거나 문제를 해결하는 데에 초점이 맞춰져 있다. 미래를 위한 장기적인 계획을 세우거나 어떤 일이 벌어질지 예측하는 것과는 거리가 멀다. 불확실한 상황에 대처하는 데에 더 유용한 모델이라고 할 수 있을 듯하다. 이 과정을 하나의 커다란 흐름으로 도식화 하면 아래와 같이 그릴 수 있다. 이 과정을 하나씩 살펴보면 아래와 같은 다섯 개의 원칙으로 정리할 수 있다. 👉 1. Bird In Hand 손 안의 새. 내가 가지고 있는 자원을 파악하는 데에서부터 시작한다. 자기 자신과 자신이 가지고 있는 네트워크를 파악하고, 가지고 있는 자원..
최근에 워케이션을 다녀왔다 (!) 워케이션이란 Wok + Vacation 의 합성어로 휴양지에서 일하면서 휴식을 취하는 형태를 말한다. 팬데믹이 지속되면서 물리적으로 휴가를 못 가는 답답함과 리모트 근무가 확산 되면서 생겨난 문화인 듯하다. 사실 워케이션이라고 부르긴 했지만, 어쩌면 여행에 더 가까웠다고 봐야할 것 같다. 그래서 이번엔 다녀온 곳에 대한 후기를 남겨보려 한다. 🌿 왜 강화도로? 지난 5월부터 퇴사하고 나름대로 휴식 기간을 가지고 있다. 물리적인 시간의 여유가 많아서 나름대로 여유로운 시간을 보내던 중, 워케이션을 다녀오리라 마음을 먹었는데, 찾아보니 특히 강원도에 다양한 워케이션 공간들이 있단 걸 알게 되었다. 그러던 중 인스타그램 광고에서 강화 잠시섬 프로그램을 알게 되었는데... 로컬..
1. 반상회 준비위가 되기까지 글또라는 커뮤니티에는 6기부터 참여하고 있었다. 6기만 해도, 코로나로 인한 제약이 많아서 오프라인으로 모이기가 어려웠다. 오프라인 행사는 나중을 기약하며 7기에도 참여하게 되었다. 전체 오프라인 행사인 글또콘을 통해 에너지를 많이 얻어가면서, 8기에는 내가 나누고 싶다는 생각을 하게 되었고, 그 생각은 곧 글또 8기 운영진 참여로 이어졌다. GitHub - geultto/geultto-conference: [글또 7기] 글또콘 컨퍼런스 자료를 모아두는 Repository [글또 7기] 글또콘 컨퍼런스 자료를 모아두는 Repository. Contribute to geultto/geultto-conference development by creating an account ..
지난 글에서 처리율 제한 장치와 대표적인 알고리즘인 토큰 버킷 알고리즘에 대해 정리했다. 이어서 이번에는 다음과 같은 순서대로 알아보자. 누출 버킷 알고리즘 고정 윈도 카운터 알고리즘 이동 윈도 로깅 알고리즘 이동 윈도 카운터 알고리즘 처리율 제한 알고리즘 누출 버킷(leaky bucket) 커다란 맥락은 토큰 버킷 알고리즘과 유사하다. 그럼 토큰 버킷 알고리즘을 다시 떠올려보자. 토큰 버킷에서는 일정한 공급량이 정해져있었다. 누출 버킷 알고리즘은 공급되는 토큰의 비율이 아니라 처리되는 양을 파라미터로 사용한다. 우리의 서버로 어떤 요청이 꾸준히 들어올 텐데, 누출 버킷에서는 요청들을 FIFO 큐에서 처리하게 된다. 그러면 큐가 곧 버킷의 용량(bucket size, b)이 될 것이다. 요청이 들어오게 ..
API 서버를 개발하다 보면 다양한 이유로 처리율을 제한해야 하는 상황이 온다. 나의 경우, 담당하고 있던 서비스에서 DoS 공격까진 아니지만 짧은 시간 내에 무차별적으로 API 호출되는 경우가 있었다. 다행히도 호출 횟수 자체나 패턴을 봤을 때 공격이라고 판단하기 어렵기도 했거니와, 서버에 큰 부하를 주는 것도 아니었기 때문에 서비스 운영에 큰 차질은 없었다. 하지만 정상적이지 않은 이용 패턴이라고 판단하여 간단하게 처리율 제한 장치를 적용한 경험이 있다. 이번에는 이런 상황에서 적용할 수 있는 처리율 제한 장치(Rate Limiter)와 그 알고리즘에 대해 알아보려고 한다. 처리율 제한이란 처리율 제한(Rate Limiting)은 네트워크 인터페이스 컨트롤러에 의해 요청을 보냈거나 받은 수를 조절하..
최신 글
-
The Principles of Effectuation: 효과성의 원리
👉 효과성이란 효과성(Effectuation)이란 성공한 창업가들이 불확실한 상황에 대처하여 의사결정하는 하나의 방법이다. 이 방법은 우리에게 주어진 자원을 이용해 기회를 만들어내거나 문제를 해결하는 데에 초점이 맞춰져 있다. 미래를 위한 장기적인 계획을 세우거나 어떤 일이 벌어질지 예측하는 것과는 거리가 멀다. 불확실한 상황에 대처하는 데에 더 유용한 모델이라고 할 수 있을 듯하다. 이 과정을 하나의 커다란 흐름으로 도식화 하면 아래와 같이 그릴 수 있다. 이 과정을 하나씩 살펴보면 아래와 같은 다섯 개의 원칙으로 정리할 수 있다. 👉 1. Bird In Hand 손 안의 새. 내가 가지고 있는 자원을 파악하는 데에서부터 시작한다. 자기 자신과 자신이 가지고 있는 네트워크를 파악하고, 가지고 있는 자원..
-
강화도 잠시섬 워케이션(?) 후기
최근에 워케이션을 다녀왔다 (!) 워케이션이란 Wok + Vacation 의 합성어로 휴양지에서 일하면서 휴식을 취하는 형태를 말한다. 팬데믹이 지속되면서 물리적으로 휴가를 못 가는 답답함과 리모트 근무가 확산 되면서 생겨난 문화인 듯하다. 사실 워케이션이라고 부르긴 했지만, 어쩌면 여행에 더 가까웠다고 봐야할 것 같다. 그래서 이번엔 다녀온 곳에 대한 후기를 남겨보려 한다. 🌿 왜 강화도로? 지난 5월부터 퇴사하고 나름대로 휴식 기간을 가지고 있다. 물리적인 시간의 여유가 많아서 나름대로 여유로운 시간을 보내던 중, 워케이션을 다녀오리라 마음을 먹었는데, 찾아보니 특히 강원도에 다양한 워케이션 공간들이 있단 걸 알게 되었다. 그러던 중 인스타그램 광고에서 강화 잠시섬 프로그램을 알게 되었는데... 로컬..
-
2023 글또 백엔드/인프라 빌리지 반상회(백스페이스) 준비위 후기
1. 반상회 준비위가 되기까지 글또라는 커뮤니티에는 6기부터 참여하고 있었다. 6기만 해도, 코로나로 인한 제약이 많아서 오프라인으로 모이기가 어려웠다. 오프라인 행사는 나중을 기약하며 7기에도 참여하게 되었다. 전체 오프라인 행사인 글또콘을 통해 에너지를 많이 얻어가면서, 8기에는 내가 나누고 싶다는 생각을 하게 되었고, 그 생각은 곧 글또 8기 운영진 참여로 이어졌다. GitHub - geultto/geultto-conference: [글또 7기] 글또콘 컨퍼런스 자료를 모아두는 Repository [글또 7기] 글또콘 컨퍼런스 자료를 모아두는 Repository. Contribute to geultto/geultto-conference development by creating an account ..
-
처리율 제한 장치(Rate Limiter)와 알고리즘 (2)
지난 글에서 처리율 제한 장치와 대표적인 알고리즘인 토큰 버킷 알고리즘에 대해 정리했다. 이어서 이번에는 다음과 같은 순서대로 알아보자. 누출 버킷 알고리즘 고정 윈도 카운터 알고리즘 이동 윈도 로깅 알고리즘 이동 윈도 카운터 알고리즘 처리율 제한 알고리즘 누출 버킷(leaky bucket) 커다란 맥락은 토큰 버킷 알고리즘과 유사하다. 그럼 토큰 버킷 알고리즘을 다시 떠올려보자. 토큰 버킷에서는 일정한 공급량이 정해져있었다. 누출 버킷 알고리즘은 공급되는 토큰의 비율이 아니라 처리되는 양을 파라미터로 사용한다. 우리의 서버로 어떤 요청이 꾸준히 들어올 텐데, 누출 버킷에서는 요청들을 FIFO 큐에서 처리하게 된다. 그러면 큐가 곧 버킷의 용량(bucket size, b)이 될 것이다. 요청이 들어오게 ..
-
처리율 제한 장치(Rate Limiter)와 알고리즘 (1)
API 서버를 개발하다 보면 다양한 이유로 처리율을 제한해야 하는 상황이 온다. 나의 경우, 담당하고 있던 서비스에서 DoS 공격까진 아니지만 짧은 시간 내에 무차별적으로 API 호출되는 경우가 있었다. 다행히도 호출 횟수 자체나 패턴을 봤을 때 공격이라고 판단하기 어렵기도 했거니와, 서버에 큰 부하를 주는 것도 아니었기 때문에 서비스 운영에 큰 차질은 없었다. 하지만 정상적이지 않은 이용 패턴이라고 판단하여 간단하게 처리율 제한 장치를 적용한 경험이 있다. 이번에는 이런 상황에서 적용할 수 있는 처리율 제한 장치(Rate Limiter)와 그 알고리즘에 대해 알아보려고 한다. 처리율 제한이란 처리율 제한(Rate Limiting)은 네트워크 인터페이스 컨트롤러에 의해 요청을 보냈거나 받은 수를 조절하..
-
psycopg3은 어떻게 달라졌나
저번 글에서는 Django 4.2에서는 무엇이 달라졌는지에 대해서 알아보았다. 이번에는 Django 4.2에서 지원하는 psycopg3에서는 무엇이 달라졌는지 알아보려고 한다. psycopg3은 DBAPI 표준을 따르고, psycopg2와 최대한 비슷하게 동작하도록 개발되었지만, 그럼에도 불구하고 변경된 부분이 일부 있다. 변경된 부분은 유의할 필요가 있다. 1. 서버사이드 바인딩 지원 postgresql 서버의 기능을 활용해, 데이터베이스 쿼리를 더욱 빠르고 안전하게 실행할 수 있는 기능이다. 기존에는 데이터베이스 쿼리를 실행할 때, 파이썬 코드에서 파라미터 값을 문자열로 전달하고, 데이터베이스 서버에서는 다시 파싱하여 쿼리를 실행하는 방식이었다. 이 방식은 보안에 취약하고 쿼리 실행 속도도 느린 편이..
-
Django 4.2에서는 무엇이 달라졌나
Django에서는 X.2 버전을 LTS로 지정하고 있다. 4.2 버전 릴리즈 노트를 정리할 겸, 이번 버전에서 새로 지원하는 기능과 종료되는 기능에 대해 간단히 정리해보려고 한다. Django 4.2에서 새롭게 추가된 것 1. psycopg 3 지원 Django에서는 psycopg 3.1.8 혹은 그 상위 버전을 지원한다. 코드를 업데이트 하기 위해, ENGINE이나 django.db.backends.postgresql 설정까지 변경할 필요는 없이 psycopg 라이브러리를 설치하면 된다. psycopg2와 비교해서 변경된 부분이 있으므로 버전 변경에서 유의할 필요가 있다. 이때, psycopg 3에서 변경된 것 중 이와 관련하여 가장 눈여겨 볼 것은 server-side binding 이다. psyco..
-
월 500만명이 방문하는 서비스 속도 개선하기 (근데 이제 1000만까지 가능한)
제가 담당하고 있는 인포크링크라는 서비스는 최근 MAU가 1000만을 돌파했어요. 그런데 오늘은 MAU가 500만명 쯔음이었을 때에 발생한 문제에 대해 이야기해보려고 해요. 아래에 해당하시는 분들이 읽으시면 더 많은 것을 얻어가실 수 있어요. 이제 막 트래픽이 늘고 있는데 여기서 무엇을 개선하면 좋을지 모르겠는 분 곧 트래픽이 늘 것 같은데 무엇을 준비해두면 좋을지 고민하고 있는 분 이제 터질 때 쯤 된 것 같은데요? 라는 말을 종종 하던 때가 있었는데요. 그 전에 제가 운영하고 있는 인포크링크의 기능과 사용 예시에 대해 먼저 알려드려야 할 것 같아요. 유저는 한 페이지짜리 [방문자 페이지]에 보여질 컨텐츠를 입력한다. 유저는 [방문자 페이지]를 인스타그램 등의 프로필 영역에 링크를 등록한다. 유저가 인..
-
노션 데이터베이스 슬랙으로 알림 받기 (2/2) - @notionhq/client로 데이터베이스 쿼리하기
1년만에 2탄으로 돌아왔습니다... 포함하는 내용 및 포함하지 않는 내용 1편에서는 로컬 서버에서 노션 데이터베이스를 쿼리하고, 데이터를 받아오는 것까지 진행했습니다. 2편에서는 지난 글에 이어서 아래의 두가지 내용을 진행하려고 합니다. 1. 로컬 서버를 AWS Lambda(이하 람다)로 업로드 2. 람다에서 실행된 결과를 슬랙으로 전송 다만, 이 글에서는 람다의 구체적인 동작 원리에 대한 설명은 하지 않을 예정입니다. prerequisite 아래의 내용은 준비되어 있다고 가정합니다. AWS 계정 aws-cli 슬랙 웹훅 URL step 1. 로컬 서버를 람다로 올리기 1. 기존 서버를 노션에 올릴 수 있게 변형하기 지난 글에서 이용한 노드 서버를 활용해서 람다에 올릴 예정인데요. 프로젝트는 1편을 통해..
-
HTTP/3, HTTP over QUIC
HTTP/3는 3번째 메이저 버전으로 2022년 6월 6일 RFC 9114를 통해 표준화 되었습니다. HTTP/3에 대해 들어보셨다면 익히 아시겠지만, HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용합니다. 그래서 RFC 9114 의 주요 내용을 읽어보면서 (그 중에서도 의미론적인 접근방법으로) HTTP/3에 대해서 간략하게 소개하고, TCP 프로토콜의 한계에 대해 먼저 알아보려고 합니다. HTTP는 1994년 ~ 1995년에 인터넷 붐을 맞이하며, 1996년에 HTTP/1.0 을 문서화한 RFC 1945를 발표했습니다. HTTP/2를 문서화한 RFC 7540 은 2012년 처음 제안되어서 2015년 표준화되었습니다. 그리고 이번엔 7년만에 HTTP/3가 표준화된 것인데요. 아래의 점유율을 보면 R..