TWpower Reading time ~2 minutes

DynamoDB Throttling 발생 사례 정리


환경

  • AWS
  • DynamoDB


배경

  • DynamoDB 프로비저닝된 모드에서 Auto Scaling 사용시 Throttling이 발생해서 이유를 조사해서 정리함.


이슈

  • DynamoDB 프로비저닝된 모드에서 Auto Scaling 설정을 사용했음에도 Throttling이 발생함.


이유

DynamoDB 관련 개념과 용어 정리

  • 내용을 정리하기 앞서서 몇 가지 개념과 용어가 새로 나와서 정리한다.

온디맨드 모드와 프로비저닝된 모드

  • 온디맨드 모드: 용량 계획 없이 초당 수백만 개의 요청을 처리할 수 있는 서버리스 청구 옵션으로 사용한만큼 지불하는 방식으로 보면 된다.
  • 프로비저닝된 모드: 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정할 수 있으며 Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있다.
  • 관련 링크: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/capacity-mode.html

WCU와 RCU

  • 프로비저닝된 용량 모드에서 애플리케이션에 필요한 초당 데이터 읽기 및 쓰기 단위이다.
  • WCU: 테이블에서 데이터를 쓰는 각 API 호출이 쓰기 요청이다.
  • RCU: 테이블에서 데이터를 읽는 각 API 호출이 읽기 요청이다.
  • 각 WCU 및 RCU에 대한 용량은 공식 문서에 나와있다.
  • 관련 링크: https://aws.amazon.com/ko/dynamodb/pricing/provisioned/

Auto Scaling

  • 위에 설명한 용량 단위의 최솟값 및 최댓값 그리고 목표 사용률 설정할 수 있다.
  • 목표 사용률에 따라 최솟값 및 최댓값 사이에서 용량을 조절한다. 간단하게 예를 들어 목표 사용률이 70% 이고 700 RCU를 사용한다면 1000 RCU를 프로비저닝 해둔다. 아래 정리하겠지만 남은 300 RCU를 패딩(Padding)이라 한다.
  • 관련 링크: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/AutoScaling.html

패딩(Padding), 버스트 용량 그리고 Spike


Spike 발생 시 Throttling 발생 이유

  • 프로비저닝된 용량을 훨씬 넘어서는 Spike(갑작스러운 데이터 요청) 발생 시 아래와 같은 순서로 요청이 처리될 수 있다고 한다.
목표 사용률 이하 RCU 사용
-> 모든 RCU(목표 사용률 이하 RCU + Padding)를 통해 처리
-> 버스트 용량에서 처리
  • Spike에 대해 그래프에서와 같이 처음에는 버스트 용량에서 처리되다가 버스트 용량을 다 소진하면서 Throttling이 발생한다. 이후 Auto Scaling이 완료된 이후에는 Throttling이 사라진다.
  • 문서에 따르면 “Auto scaling triggers when your consumed capacity breaches the configured target utilization for two consecutive minutes. CloudWatch alarms might have a short delay of up to a few minutes before triggering auto scaling.”라고 나와있다.
  • DynamoDB의 경우 Auto Scaling이 일어나려면 CloudWatch에 1분간 연속해서 사용된 값이 목표 사용률을 넘어야 한다고 했다. 그렇기에 아래와 같은 이유로 지연이 생기게 되며 이게 순간적인 많은 요청에 대해 Throttling을 발생 시킨다.
    • CloudWatch에 표시되려면 약간의 시간 지연이 필요하다.
    • CloudWatch에 연속된 1분동안 목표 사용률을 넘는 상황이 발생하면 Auto Scaling을 시작한다.
    • Auto Scaling이 되는 과정에서 위에서 언급한 “목표 사용률 이하 RCU 사용 → 모든 RCU(목표 사용률 이하 RCU + Padding)를 통해 처리 → 버스트 용량에서 처리”를 넘어서는 요청에 대해서는 Throttling이 발생한다.
  • 관련 링크: https://aws.amazon.com/ko/blogs/database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/
  • 관련 링크: https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/AutoScaling.html


작가의 생각

  • Auto Scaling에서도 급격한 요청에 대해서는 Scaling을 탐지하는 부분과 조정하는 시간이 필요하기에 앞으로 설계시 이에 대한 고려도 하면 좋을거 같다.
  • 관련 조사를 진행하면서 DynamoDB Auto Scaling에 대해 많이 배웠다.
  • 예상하지 못한 급격한 트래픽 요청에 대해서는 알람이 오게 해야하며 트랙픽 증가가 예정된 부분이 있다면 점검하는 습관을 만들어야겠다.


참고자료

TWpower Reading time ~2 minutes

Post about case of DyanmoDb throttling


Environment and Prerequisite

  • AWS
  • DynamoDB


Background

  • Investigated and summarized the reasons for throttling when using auto scaling in DynamoDB provisioned mode.


Issue

  • Throttling occurs in DynamoDB even though auto scaling is set in provisioned mode.


Reason

  • Before summarize content, let me clarify some concepts and words.

On-demand capacity mode and Provisioned capacity mode

  • On-demand capacity mode: A serverless billing option that can serve millions of requests per second without capacity planning. Easily say pay what I used.
  • Provisioned capacity mode: Specify the number of reads and writes per second that you require for your application. We can use auto scaling to adjust your table’s provisioned capacity automatically in response to traffic changes.
  • Related Link: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html

WCU and RCU

  • Specify the number of data reads and writes per second that you require for your application. Unit of read and write in provisioned mode.
  • WCU: Each API call to write data to your table is a write request.
  • RCU: Each API call to read data from your table is a read request.
  • Each size of WCU and RCU is on official document.
  • Related Link: https://aws.amazon.com/dynamodb/pricing/provisioned/

Auto Scaling

  • We can set minimum, maximum provisioned capacity unit as mentioned in above and target utilization.
  • Capacity is controlled between minimum and maximun following to target utilization. For example if target utilization is 70% and use 700 RCU, then provisioned would be 1000 RCU. I will explain later but rest 300 RCU are called padding.
  • Related Link: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html

Padding, Burst Capacity and Spike


Reason of Throttling When Spike Occurs

  • When a spike(sudden request traffic) exceeds the provisioned capacity, requests may be processed in the following order.
Use RCU under Target Utilization
-> Use All RCU(RCU under Target Utilization + Padding)
-> Use Burst Capacity
  • In spike, as shown in the above graph, firstly burst capacity handles requests and then throttling occures after use all prepared burst capacity. After auto scaling is done, then throttling disappears.
  • In document it says “Auto scaling triggers when your consumed capacity breaches the configured target utilization for two consecutive minutes. CloudWatch alarms might have a short delay of up to a few minutes before triggering auto scaling.”.
  • In DynamoDB auto scaling occurs when consumed capacity breaches the configured target utilization for two consecutive minutes. Therefore, delays occur for the following reasons, leading to throttling in reponse to spike in requests.
    • There is a short delay of up to CloudWatch.
    • Auto scaling will be started when consumed capacity breaches the configured target utilization for two consecutive minutes.
    • Throttling occurs in process of auto scaling over above “Use RCU under Target Utilization -> Use All RCU(RCU under Target Utilization + Padding) -> Use Burst Capacity” requests.
  • Related Link: https://aws.amazon.com/blogs/database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/
  • Related Link: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html


Author’s Thoughts

  • Due to scaling timing detection and setting time in auto scaling, it is good to consider about it when designing.
  • I learned many things about DynamoDB auto scaling.
  • Make alarm for unexpected sudden increase traffic. Make habit of review capacity when there is plan to have more traffic.


Reference

TWpower Reading time ~5 minutes

상반기 회고


작성 이유

  • 상반기 과제가 끝나기도 했고 의무감도 있고 남은 2024년을 계획 할 마음으로 작성한다.
  • 항상 글을 작성하면 머릿속에 너무 많은 생각이 있어서 글이 많이 길어지는데 짧게 필요한 내용만 작성하려 한다. 회사 업무, 개인 업무 그리고 자기 개발정도에 대해서만 적어보겠다.


회사 업무

1월부터 6월까지

1월

새로운 업무들을 받아서 했으나 중간에 한번 업무가 바뀌었다. 관련해서 새로 배우는 기간으로 실질적인 업무를 하기보다는 따라가기에 바빴다. 기존에 하던 업무를 병행해서 진행했다. 새로 익히고 하는 기간이라 정신없이 지나갔다.

2월~3월

서비스 측과 소통하면서 시스템을 연결하는 업무를 했다. 관련하여 일을 하면서 소통하는 부분이 업무에 있어서 큰 부분을 차지한다는 걸 깨달았고 디버깅하면서 작은 단편적인 지식을 배우게 되었다. 앞선 일들과 작은 이슈 해결과 기능 개발 정도만 했다. 많은 사람들과 소통하면서 엔지니어의 또 다른 능력으로 소통하는 게 정말 중요하다는 걸 느꼈다. 특별하게 어떤 소통의 기술이 늘어났다고 할 수 있을지는 모르지만 약간의 두려움이 사라지고 맷집이 생긴 거 같다.

4월~6월

과제의 마감이 6월이었기에 과제 마감을 위한 작업을 했다. 작은 이슈들을 수정하고 소통도 열심히 했다. 정말 “이걸 우리가 다 할 수 있을까?” 하는 과제였는데 마무리가 된 거 같다. 꽤 오래 했던 과제라 마무리한 만큼 뿌듯했다. 이전과 마찬가지로 작은 이슈 해결이나 기능 개발 정도만 했다.


그래서 1월부터 6월은?

앞서 기록을 다 했지만… 뭔가 성과를 냈다고 할 수 있는 무언가를 만들지는 못했다. 6월에 마무리해야 하는 과제를 향해 열심히 달렸으며 중간에 어려운 상황들을 해결하긴 했다. Terraform 관련한 이슈도 찾아내고 새로운 데이터베이스 관련 코드도 추가하고 갑작스러운 이슈에 케이스를 오픈해 해결하기도 하고 네트워크 연결이 안 되는 부분도 서비스 측과 소통하면서 하나씩 해결했다. 개발 관련된 부분들을 뒤로하고 오직 6월 과제 완수만을 바라보며 달렸던 거 같다. 마무리해서 뿌듯하다. 이제는 밀렸던 부분들을 정리하고 새로운 기능들을 개발했으면 좋겠다. (물론 쉬면 더 좋겠다!)

6월까지 지내오면서 느낀 몇 가지만 짧게 정리하면 아래와 같다.

  • 엔지니어에게 소통 능력은 개발 능력만큼 중요하다. 서로가 같은 생각을 하고 있는지 확인하는 부분, 업무를 전달하는 부분, 요구사항을 이해하는 부분 이런 모든 부분이 소통에 속하는 거 같다. 이러한 부분들이 잘 이루어지지 않으면 결국 만들어내는 소프트웨어 제품에 영향이 갔었다. 예를 들어 업무를 전달했는데 이해한 부분이 달라서 다시 요청하거나 생각했던 범위가 달라서 다시 이야기하거나 하는 부분들이 있었다.
  • 여러 방면으로 의심을 해봐야 한다. 사람은 실수할 수 있으며 그 과정을 하나하나 볼 필요가 있다. 여기서 의심은 누군가를 비난하는 게 아니라 사람이 입력하는 것과 같은 부분이 있으면 문제가 생길 수 있음을 알아야 하고 소통해서 확인해야 한다. 사람뿐만 아니라 오픈소스도 의심할 필요가 있다. 사람이 검증하는 부분이기에 실수가 있을 수 있으며 이슈가 생겼을 때 바라볼 필요가 있다. 실제로 항상 최신 코드를 가져와서 사용하다가 이슈가 발생한 적이 있었다. 처음에 의심하지 않아 다른 길로 빠질 수도 있었었는데 관련한 내용을 우연히 검색으로 발견할 수 있었다.
  • 기술이 다가 아니다. 10분 만에 해결될 일이 감정 문제로 10일이 걸릴 수도 있다. 개발은 완료되었지만, 서비스 측에 갑자기 생긴 프로세스로 업무가 늘어난 사례가 있었다. 실무자의 협조가 어렵다고 한 부분을 매니저 또는 더 위에 상급자의 도움을 받아서 더 빠르게 해결한 경우도 있었다. 이렇듯 때로는 개발만이 아닌 사람을 통해서도 문제가 해결될 수 있는 거 같다.

기술적으로 어떤 걸 만들거나 큰 업적이나 멋진 말이 없어서 실망스러울 수도 있지만 개발 외에 관련한 부분들을 많이 배운 거 같다.

관리나 행정적인 부분에서 이해가 안 가는 부분들이 있었다. 팀원 혹은 업무의 분배나 타 부서와의 협업이나 위에서부터 내려오는 일 등등에 대해 물음표가 생길 때가 꽤 있었다. 여러 높은 의사 결정권자들을 회사와 정치에서 보면서 “과연 나라면 어떻게 했을까?”라는 질문을 많이 했었다. 속으로 화가 날 때 답답할 때 그리고 이해가 안 갈 때가 더 많았던 거 같다.

유독 이번에는 집중하기 어려운 환경이었다. 일하는 중간에 인터럽트가 자주 발생했었다. 이슈가 발생하거나 다른 업무 요청이 오거나 우선순위가 바뀌는 거와 같은 여러 요인이 있었다. 스프린트에 있는 티켓을 가져가서 개발을 집중해서 하고 싶은데 여러 요청과 이슈가 생기면서 집중하기 어려웠고 생산성이 저하되는 일이 있었다. 내 개인 능력의 문제도 맞지만, 팀원 전체가 같은 부분을 느꼈기에 이러한 부분이 개선되었으면 어떨까 싶었고 나라도 조금씩 개선해 보고 싶다.

문득 생각이 들었는데 체력적으로나, 정신적으로 약간 지친 거 같기도 하다. 나태해진 부분도 있었다. 해야 할 일을 뒤로 미루기도 하고 사실 피한 적도 있었다. 도와드려야 하는 상황에 여유가 없어서 내 일만 한 적도 있었다. 지친 게 원인이었던 거 같고 여러 가지 신경 쓸 일들이 생겨서 그런 거 같다. 무리해서 달리면 무조건 탈이 나기 때문에 앞으로는 지치거나 힘들 때는 쉴 생각이다.

사실 쓰고 싶은 이야기와 생각이 너무도 많지만 이번에는 여기까지만 쓰겠다. 평소에 생각이 많았는데 적으려니 중구난방이라 앞으로는 생각날 때마다 일기에라도 정리해 봐야겠다.


개인 업무와 자기 개발

블로그

내가 소중하게 여기는 블로그로 최대한 시간을 내서 쓰고 있다. 예전에는 공부한 내용이나 기록을 주로 했었는데 요즘은 사례 중심으로 글을 쓰고 있다. 여전히 글 하나를 쓰는 데는 긴 시간이 걸린다… 최소 3시간 정도는 걸리는 거 같다. 남들한테 보이는 글이고 생각보다 많은 사람들이 본다는 생각에 많은 시간을 쓰는 거 같다. 그런데 여기에만 시간을 투자해서 다른 공부를 못하는데 여전히 개선해야 할 부분이다. 영어로도 꼭 쓰는데…. 여기서도 시간이 오래 걸린다. 따로 시간을 내서 영어 쓰기 공부를 안 하고 있어서 이렇게라도 영어 쓰기를 공부하자는 마음에 하는 거라 그만둘 수 없다. 하지만 요즘은 번역기에 많이 의존하고 있다 으악.

앞으로도 여러 가지 내용의 글을 쓸 예정이다. 공부한 내용, 기록, 사례 등등 더 다양한 글로 형식에 얽매이지 않고 쓸 예정이다.

게임

이전 회고에서도 작성했지만 게임을 만들고 메시지를 전달하고 싶다. 그래서 퇴근 후 혹은 주말에 시간을 내서 공부하고 있다. Unity는 어느 정도 공부를 해서 최근에는 그림을 직접 그리려고 일러스트레이터를 공부하고 있다.

요즘에 체력이 내 마음을 따라가지 못해서 거의 못하고 있는데… (마음이 아프다ㅠ 내 몸이여!) 10분이라도 공부하려고 노력하고 있다.

올해 말에는 리소스를 그릴 수 있고 게임 줄거리가 나와서 개발에 들어가는 게 목표다. 얼른 게임을 만들어서 메시지도 전하고 사람들에게 감동이나 여운을 주고 싶다.

영어 공부

마음 같아서는 영어, 스페인어, 중국어 등등 많은 외국어를 하고 싶은데 역시나 세상은 쉽지 않다. 시간이 없어서 출근할 때 그리고 운동할 때마다 영어 회화를 듣고 있다. 시간 없으니 이렇게라도 꾸준하게 공부할 예정이다.

전공 및 개발 공부

사실 따로 정리할 필요가 없는 게 항상 어디를 가나 궁금한 부분들이 생기고 찾아보는 거 같다. 회사에 많은 교육 과정도 있어서 하게 되면 자연스럽게 공부도 하게 된다. 이 정도만 꾸준하게 유지할 수 있으면 좋겠다.

회사 DX 크리에이터

내 목표 중 하나인 큰 무대에서 발표하는 것을 연습하기 위해 올해 DX 크리에이터에 지원했고, 합격하여 활동했다. DX 크리에이터란 DX(Device eXperience)부문의 임직원이 회사 생활을 알리는 영상을 직접 기획, 출연, 촬영 및 편집하는 활동이다. 단순히 업무만 하는 것보다 목표에 다가가고 발표를 연습하기 위해 지원했는데, 이 과정이 리프레시되면서 큰 도움이 되고 있다.

발표와 카메라 앞에 서는 목표를 위해 여기서도 열심히 활동하고 있다.


남은 2024년의 목표

정말 짧게 쓴다는 게 또 길어졌다. 이걸 또 영어로 옮기려면 시간이 들겠지?! 그래도 남은 2024년의 목표를 작게나마 정리한다.

  • 충분히 일을 하고 있지만 올해도 큼지막한 하나의 성과를 내고 싶고 발표도 하면 좋겠다.
  • 업무 관련된 내용들만 썼지만 다 필요 없고 건강이 최고다. 건강 없으면 아무것도 없다 진짜. 건강이 제일 우선이다.
  • 지금 하는 대로 열심히 성실하게 살자.
  • 이제부터는 시간이 금인데 항상 매사에 최선을 다해서 집중하자.
  • 인생에는 우선순위가 있다. 그 우선순위와 가치에 따라 행동하자. 가족이 중요하다!

글을 쓰면서 나 자신을 돌아보는데 그래도 괜찮은 6개월을 보냈고 건강을 꼭 잘 챙기면서 남은 2024년을 보내면 좋겠다.

부족한 만큼 앞으로도 언제나 겸손하고 성실하게 최선을 다하면서 살자!

TWpower Reading time ~7 minutes

The first half retrospective


Background

  • I am writing this to plan for the rest of 2024 and I have completed tasks of the first half of the year. Also a bit of duty?
  • When I write a post, I always have too many thoughts in my head which makes my writing so long. However I decided to write short for this one. Work in company, my work and self-development.


Work in Company

January to June

January

I got a new work but it changed one in middle of month. Technically it was focus on learning than doing practical work which makes me busy. I carried on with my existing tasks while also taking on new ones. It was a hectic time as I was learning new things.

Feburary to March

I did my work while communicate with other services. About that I realized communication take huge part in work and learned small things. I did previous mentioned work, resolved issues and developed small functions. By communicating with many people, I realized that communication is truly an important skill for an engineer. While I can’t say that I’ve significantly improved any specific communication skills, I feel that my fear has diminished somewhat, and I’ve developed more resilience.

April to June

Since project due was June, I worked on tasks to meet the deadline. I solved many small issues and communicated hard. We thought “Can we do this?” but we did it. Since it was a project I had been working on for quite a long time, I felt proud to have completed it. As before, I only handled small issues and minor feature development.


So how was Janurary to June?

I wrote in above… I didn’t create anything that could be considered as an achievement. I worked hard towards completing the project due in June and managed to resolve some difficult situations along the way. Found issue in terraform, add code for new database, open case for incident, make network connection by communicating with service I solved each issue step by step. I focused solely on completing the project, setting aside development related tasks. It feels satisfying to have finished it. Now I hope to tidy up the backlog and work on developing new features. (Of course, taking a break would be even better!)

Here are some things that I felt until June.

  • To engineer communication skill is as important as development skill. It involves ensuring mutual understanding, conveying tasks effectively, and comprehending requirements. If these aspects are not well executed, they ultimately affect the software product. For example miscommunication could lead to request tasks again or revisit discussions due to differing understandings.
  • Make doubt to many things. People can make mistakes and it’s necessary to examine each step of the processes are done carefully. In this context doubt doesn’t imply blaming someone, but rather recognizing that issues can arise from human inputs or similar factors, and thus it’s important to communicate to clarify. It’s necessary to have doubt not only of people but also of open-source software. Since it’s human verified, mistakes can occur and it’s important to look into issues when they arise. In fact, I’ve encountered issues in the past by always pulling the latest code. Initially, I didn’t suspect anything and could have gone down the wrong path, but I found relevant information through a search and was able to resolve it.
  • It’s not all about technical skills. Something that could be resolved in 10 minutes technically might take 10 days due to emotional issues. There was a case that work time becomes longer due to newly created process in service part even though development were done. There was a case that owner told us that they cannot corporate but we asked to high level manager to corporate it. After that issue was solved. It seems that sometimes problems can be resolved not only through development but also by communication with people.

It could be disappointed that there were no technical achievement or impressive cases. However, I feel I’ve learned a lot beyond development.

There are some things of management and administration that I could not understand. There are few things that makes me question mark on my head. Those are distribution of tasks or team members, collaboration with other departments, and assignments coming from above. I often asked to myself, “What would I have done if I were them?” while watching various high level decision makers in both the company and politics. There were more times when I felt angry, frustrated, or confused inside.

It was particularly difficult to concentrate. There were frequent interruptions while working. There were some factors such as issues arising, other work requests coming in, or changes in priorities. I wanted to focus on the tickets in the sprint but various requests and issues made it difficult to concentrate which leads to decreased productivity. Although it could be an issue of my ability, the entire team member felt the same way. I thought it would be good if this could be improved and I would like to improve it.

I’ve been feeling a bit exhausted both physically and mentally lately. There have been moments of laziness and procrastination. Also I’ve even avoided things I should have done. There were times when I focused only on my own tasks and couldn’t help others due to lack of time. I think fatigue was a factor which coupled with various things to care about. Rushing can only lead to burnout. So from now on, I plan to take breaks when I feel tired or overwhelmed.

Although I have so many stories and thoughts I want to write, I’ll stop here for now. I usually have a lot of thoughts but when I try to write them down they end up all over the place. From now on I will write them in a journal whenever they come to mind.


My Work and Self-Development

Blog

One of my favorites is my blog. I tried to make a post when I have a time. Previously I mainly wrote about what I learned and what I experienced. However nowadays I tried to write about case. Still writing a post takes so much time… At least it takes 3 hours. Since other people can read my blog, this make me to spend much time on writing a post. However spending too much time should be amended. I also write post in english which also takes much time. Nowadays I strongly depend on translator.

In the future, I plan to write about various topics. I intend to write more diverse views, including what I’ve studied, records, case studies, and more, without being constrained by format.

Game

As I wrote before, I’d like to make game and give message to users. So after work or on weekends, I tried to make time to study. Since I have already studied Unity, I am currently learning Illustrator to draw my own design resources.

These days my physical energy can’t keep up with my enthusiasm so I can hardly get anything done… (It breaks my heart. Oh, my body!) Still, I try to study for at least 10 minutes.

In last of this year, my goal is to publish my game. I’d like to create a game quickly to send messages and make people feeling moved and touched.

English Studying

I wish to speak many foreign languages but its not easy. I listen to english conversation when I walk or work out. Since I don’t have much time, I plan to study consistently in this way.

Major and Development Study

I have many curiosity which make me to search and study in usual day. There are many courses in company which also makes me to study. I just hope keep this habit for long.

Company DX Creator

One of my goals is to present on a big stage. So I applied to DX Creator in company and working on it now. DX Creators are employees in the DX (Device eXperience) Divison who plan, appear in, film, and edit videos of work life. It’s a step towards my goal. It feels refreshing and helpful.

I’m also actively participating here to prepare for presenting in front of the camera.


Rest 2024 Goals

It seems like this writing become long again. Whatever I briefly write my goals of rest 2024.

  • I’m working hard enough, but this year, I want to achieve something significant and also give a presentation.
  • I wrote mainly about work but health is the most important thing. Nothing is more important than health.
  • Keep work hard and live diligently.
  • Time is one of the best precious things. Focus and concentrate what I do.
  • In life there are priorities. Live according to those priorities and values. Family is important!

Reflecting on myself while writing this post. It was a quite good 6 months. I hope to spend the rest of 2024 well.

Keep live humbly and diligently always doing my best despite my shortcomings!

TWpower Reading time ~1 minute

kubectl port-forward 사용 방법과 예제


환경

  • Kubernetes
  • kubectl


배경

  • Kubernetes 사용시 포트 포워딩을 자주 사용하는데 사용법을 까먹어서 기억할 목적으로 정리.


kubectl port-forward

공식 문서

  • 공식 문서에 보면 예시가 잘 나와있다.
  • Pod뿐만 아니라 Deployment와 Service에도 사용할 수 있었다.
  • --address 옵션을 사용하면 수신할 IP 주소를 지정할 수 있다. ,로 구분되며 기본값은 localhost와 127.0.0.1다.

사용 방법

kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]

예시

 # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
 kubectl port-forward pod/mypod 5000 6000
  
 # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the deployment
 kubectl port-forward deployment/mydeployment 5000 6000
 
 # Listen on port 8443 locally, forwarding to the targetPort of the service's port named "https" in a pod selected by the service
 kubectl port-forward service/myservice 8443:https
 
 # Listen on port 8888 locally, forwarding to 5000 in the pod
 kubectl port-forward pod/mypod 8888:5000
 
 # Listen on port 8888 on all addresses, forwarding to 5000 in the pod
 kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000
 
 # Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod
 kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000
 
 # Listen on a random port locally, forwarding to 5000 in the pod
 kubectl port-forward pod/mypod :5000


예시별 사용 방법

Pod에 포트 포워딩

kubectl port-forward pod/[pod name] [local port]:[pod port]

Deployment에 포트 포워딩

kubectl port-forward deployment/[deployment name] [local port]:[pod port]

Service에 포트 포워딩

kubectl port-forward service/[service name] [local port]:[service port]

수신 IP 주소 지정

  • 모든 IP에 대해 수신해서 포트 포워딩
kubectl port-forward --address 0.0.0.0 pod/[pod name] [local port]:[port]
  • 로컬 및 특정 IP에 대해 수신해서 포트 포워딩
  • 아래의 경우 명령어를 실행하는 OS 인스턴스가 10.19.21.23 주소를 가지고 있다고 가정한 경우로 외부에서 접근을 제어하는 Whitelist 같은 개념이 아니라 포트를 연결할 IP 주소를 명시하는 경우로 보면 된다.
kubectl port-forward --address localhost,10.19.21.23 pod/[pod name] [local port]:[port]


참고자료