BYUN Kyuhyun

ML Data platform engineering 에서 Feature Store의 장기적인 성능 개선 과제를 고민하다가 cache 뿐만 아니라, disk storage를 활용하는 것 또한 검토해보고 있다. 왜냐하면 network latency를 줄이고, disk storage를 활용하면 remote cache보다 더 빠르게 데이터를 읽고 쓸 수 있을거라 기대하기 때문이다. 그래서 AWS에서 Disk storage처럼 활용할 수 있는 EBS, FSx와 EFS에 대해 알아보고자 한다. AWS EBS AWS EBS(Elastic Block Store)는 다양한 종류의 볼륨 타입을 제공하며, 크게 SSD 기반과 HDD 기반으로 나눌 수 있다. 각 볼륨 타입은 성능 특성과 가격이 다르므로 애플리케이션의 요구사항에 맞게 선택할 수 있다. ...

질문이 생기게 된 이유 pm.me라는 도메인을 가진 이메일을 보았다. 이를 운영하는 회사는 proton mail이라는 회사인데, 여기에서 개발하는 방법에 대해서 찾아보니 모든 코드를 Github에서 공개하고 관리한다는 것을 보았다. 하필이면, PR이 하나 열려있었고, 해당 PR의 제목은 “Add checks to prevent formatting hxxps"이었다. 이를 보고, hxxp와 hxxps가 무엇인지 궁금해졌다. http와 흡사한데 왜 이걸 활용하게 되는 것일까? Perplexity에게 물어보니 가볍게 다음과 같이 답변이 나왔다. 이메일 보안을 위한 내용이니 알아두면 언젠가는 도움이 될 것 같다. http와 https 대신 hxxp와 hxxps를 사용하는 주된 이유는 보안과 관련이 있습니다. 이 방식을 “URL 무해화(URL defanging)“라고 하며, 다음과 같은 목적으로 사용됩니다: ...

1. Computing & Application AWS Lambda 소개: 이벤트 기반의 서버리스 컴퓨팅 서비스 해결문제: 짧은 실행 시간의 작업, 이벤트 처리, API 요청 처리 대체서비스: EC2, ECS, EKS 규모: 최소: 128MB 메모리, 실행시간 제한 15분 최대: 10GB 메모리, 동시실행 1000개 (증설 가능) AWS Fargate 소개: 컨테이너화된 애플리케이션을 위한 서버리스 컴퓨팅 엔진 해결문제: 컨테이너 운영에 따른 서버 관리 부담 제거 대체서비스: ECS/EKS with EC2 규모: 최소: vCPU 0.25개, 메모리 0.5GB 최대: vCPU 16개, 메모리 120GB 2. Integration & Orchestration ...

When comparing UI Bakery and Retool for operating in-house data and creating dashboards with charts, both platforms offer strong capabilities but have some key differences. Let’s examine how they compare in these specific areas: Data Handling and Integration Retool Retool excels in data handling and integration, making it a strong choice for operating in-house data[1][4]. It offers: Powerful integration with external data sources, including APIs, databases, and cloud services Support for SQL/NoSQL databases and services like Firebase, MongoDB, and PostgreSQL Real-time data syncing between the UI and data sources UI Bakery ...

It’s difficult to definitively say one is “better” than the other, as each has its strengths and is suited for different use cases. However, I can provide a comparison of their key features and performance to help you make an informed decision: Performance and Scalability Appwrite consistently outperformed Supabase in stress tests, especially when scaling up to handle more users[1][4]. For example: On a €5/month self-hosted server, Appwrite handled up to 2,000 users per day comfortably, while Supabase struggled with larger loads[1]. On a more powerful €30/month server, Appwrite managed up to 250 simultaneous users, while Supabase hit its limit at only 45 users[1]. In breakpoint tests, Appwrite reached 6,800 virtual users, processing 100,000 requests with an average 3-second response time. Supabase reached its breakpoint at 3,000 virtual users, with 59,000 requests and a 6-second average response time[4]. Ease of Use Appwrite offers a smoother self-hosting experience with fewer restrictions and less setup complexity[1][3]. Supabase can be more challenging to configure in a self-hosted environment and has some features restricted or limited when self-hosted[1][3]. Features Both platforms offer similar core features, including authentication, databases, storage, and serverless functions. However, there are some differences: ...

Connection Mode (Session Mode) Each client maintains a dedicated connection to the database for the entire session duration[2]. The connection is only released back to the pool when the client disconnects from the database[2]. This mode replicates a direct connection to PostgreSQL and supports all PostgreSQL features and mechanisms[2]. It’s safer and more compatible with all PostgreSQL clients[2]. Does not significantly reduce the load on database resources[2]. Transaction Mode The connection to PostgreSQL is maintained only for the duration of a transaction[2]. When the transaction completes, the connection is returned to the pool and can be reused by other clients[2]. Allows for a higher number of client connections (up to 10,000) with a smaller pool size[2]. Reduces the load on DBMS resources, especially beneficial for a large number of low-load client connections[2]. More efficient in terms of resource utilization, as idle connections are released back to the pool[3]. Key Differences Connection Duration: ...

Summary “고언어 프로젝트 가이드 A-Z"라는 주제로, 작은 프로젝트부터 엔터프라이즈 애플리케이션까지 Go 언어를 사용한 개발 방법론에 대해서 공유해보았습니다. 작은 프로젝트와 큰 프로젝트의 차이점을 설명하고, 작은 프로젝트에 적합한 간단한 코드 패턴을 소개하고, 기능 단위의 프로젝트를 위한 코드 패턴으로 Handler와 HandlerFunc 방식을 비교하고 각각의 장단점을 설명합니다. 엔터프라이즈 애플리케이션을 위한 코드 패턴으로 Domain Driven Design (DDD) 접근 방식을 소개하고, 각 레이어(Presenter, Handler, Usecase, Service, Repository, Recorder)의 역할과 장점을 설명합니다. NoSQL 데이터베이스 (DynamoDB) 사용 시의 모델링 방법을 간략히 소개합니다. 그리고 각 레이어에서의 테스트 코드 작성 방법과 모킹 도구인 counterfeiter의 사용법을 설명합니다. 애플리케이션 릴리즈를 위해 필요한 도구들(APM, 에러 모니터링, 메트릭 수집, 로그 서비스)을 소개하고 그 중요성을 강조합니다. ...

Summary Gophercon Korea 2023에서 발표한 “Go 도입 후, 4년 간의 기록"이라는 주제로 공유했습니다. Go를 도입하여 높은 트래픽을 처리하고 있으며, 주요 이슈와 해결 방법을 공유하고, Go를 통해 더 효율적이고 안정적인 서비스를 제공하기 위한 고민들을 공유합니다. Youtube Slideshare Go 도입 후 4년 간 기록 from Kyuhyun Byun

의사결정과 업무 진행은 프로덕트를 사용하는 고객관점에서 시작한다. 고객관점이라는 말은 많이 하지만 실제로 이게 왜 사용되어야 하는지 두 가지 방면에서 설명한다. 1. 조직에서의 의사결정 측면 이런 상황은 자주 발생했을 것이라 생각한다. 서로의 팀원(혹은 조직)의 생각이 달라서 벌어진 상황이다. 각 팀원은 수단에 대해서 집착을 하게 되고 이야기가 평행선을 달리게 된다. 이때 어떻게 이야기를 하면 문제를 해결할 수 있을까? 고객이 겪는 문제 상황에 대해서 먼저 정확히 이해하는 게 필요하다. 혹은 고객에게 꼭 필요하다고 생각하는 것에 대한 정의가 필요하다. 이를 문서 최상위에 “목표”로 정의를 한다. ...

The word “burnout” is being heard from all directions. It is being expressed as a reason for quitting, changing jobs, taking vacations, and as a way to express difficulties in life. I think everyone has heard it at least once, and I believe there have been times when you’ve wondered if you are experiencing burnout. When I hear people talking about burnout, I often feel a deep sense of sympathy, but I also feel that there is little I can do to help. I can suggest various things to try, but those who are experiencing burnout often don’t seem to hear those suggestions. So, while contemplating what to do, I decided to write this. ...