%EC%84%9C%EB%B9%84%EC%8A%A4%EC%9A%B4%EC%98%81

어제 글쓰기 흥미 [1] 를 자극하는 글 이 올라왔다. 조금 더 정확하게 말하면 글에서 인용한 이미지가 내 시선을 잡아 끌어 여러 가지 생각을 만들도록 했다. 그래서 아래 이미지에 기초해 주관적인 감상을 쓴다. 빙산의 일각을 비교해보자 그림이 주는 시각적 흡수가 오해일 수 있어 오류를 줄이려 원문을 찾아보았으나 원하는 설명은 없었다. 후에 확인을 하면 고치기로 하고 가정속에서 글을 써보자. 그림을 그린 이가 비교하려는 두 개의 빙산 즉, On-Premise와 Cloud Computing 이라는 묵직한 결정에 대해서 드러난 부분의 크기를 일부러 같은 사이즈로 그렸을까? 알 수 없다. 스스로 그리는 사람이라고 생각하고 상상해보자. 그러면, 그린 이의 의도를 짐작...

[원본글] https://ericygkim.wordpress.com/2019/07/11/aws-ebselastic-block-storage-의-비용-최적화/ 애플리케이션 개발 후 AWS에 애플리케이션을 설치할 때 성능, 가용성, 확장성, 비용, 서비스 특성등 많은 요구사항들을 고려하여 복잡한 고민을 거쳐 EC2 인스턴스 사이즈등  AWS 자원들을 선택하게 됩니다. 그 중 중요한 요소 중 하나가 EC2인스턴스나 RDS에 연결되는 스토리지인 EBS(Elastic Block Storage)를 선택하는 일인데, 성능 및 비용까지 고려해서 선택하는 과정은 많은 고민을 할 수 밖에 없습니다.  EBS 볼륨의 크기를 정하는 것도 중요하지만 그것보다 더 중요한 것은 EBS 볼륨의 종류를 선택하고 성능과 비용 최적화 하는 것입니다. 얼마나 빠른 EBS 볼륨을 선택하는냐에 따라 애플리케이션, 데이터베이스의 성능에 큰 영향을 미치게 됩니다. 또한 EBS 볼륨의 유형에 따라 비용이 크게 달라집니다.  그러므로 요구되는 성능과 비용을 고려하여 적절한 스토리지 유형과 크기를 현명하게 선택하여야 합니다. 이와 관련된 기본 지식과 약간의 노하우를 공유할까 합니다....

1편에 이어 2편을 올려봅니다. Latency에 대한 이해 1편에서 언급하였듯이 Latency가 높아지는 (길어지는) 이유는 전송단의 각 파이프 라인 단계별 변수들이 복합적으로 작용하기 때문에 실무에서는 정확한 원인과 해결책을 찾기는 매우 어렵다. 또한, 종단간 (End-to-End) latency를 기술적으로 측정하는 정량화된 방법도 아직은 없는 상태이다. 어떤 분들은 카메라 앞에서 손을 흔들고 시간을 측정하시는 분들도 있고, 어떤 분들은 "아" 소리를 내고 들릴때까지 측정하는 사람도 있다. 저도 매우 원시적인 방법을 사용하고 있다. Millisecond로 표시되는 디지털 시계를 카메라로 계속 생중계하면서 단말기에서 보이는 화면과 실제 시간을 비교하는 방법을 사용하고 있다. 즉, 정량화된 방법은 부재인 상태이지만 기본적으로 가장 이상적인 환경에서 구축한 서비스의 Latency를 측정할 필요는 있다. 이러한 정량적인 방법의 부재로 현실적인 다른 관점에서측정방법을 하나 소개하고자 한다. 지금까지의 경험으로 비추어 보아 Latency의 최종 결과물인 시청자들의 시청경험(QoE: Quality-Of-Experience)라는  관점에서 Latency에 대한 설명을...

처음으로 공개 블로그인 Popit에 글을 올려봅니다. 단어나 표현이 조금 부족하더라도 너그러운 마음으로 읽어 주세요. 감사합니다. 초고속 인터넷망의 지속적인 확산과 모바일 환경이 빠른 속도로 진화를 거듭해왔지만 , 고 해상도 디지털 비디오를 인터넷으로 전송하는 작업은 항상 품질에 대한 확신을 할 수 없는 어려운 일이다 . 최근 VoD(Video-on-Demand) 사업의 경쟁이 치열해지다보니 라이브 비디오 스트리밍 서비스를 이용한 새로운 사업들이 디지털 비디오 시장의 새로운 성장 동력이 되어 많은 회사들이 시장에 진입하고 있는 상황이다....

1부에서는 기술블로그 구독서비스(이하 서비스)를 왜 만들게 되었고 어떤구조로 만들가에 대해 이야기를 해보았다면, 이번 포스팅에서는 만들면서 만나게 된 각종 트러블슈팅 종합세트(?) 를 하나씩 풀어보고자 한다.  물론 개발을 하면서 아무 문제 없이 잘 되면 당연히 좋겠으나 잘되도 이상한게 개발이라는 세계가 아니던가. 잘 안되면 문제, 잘 되도 문제 ㅠㅠ, 출처 : https://www.clien.net/service/board/park/9111495 1부 : 왜 만들게 되었는가 그리고 어떤 구조로 만들었는가...

요즘 일상에서 가장 많이 쓰는 도구는 Dooray 서비스 다. 지난 번에 지극히 개인적인 활용을 다룬 글 을 올리긴 했지만, 두레이의 일반적인 쓰임새는 개인 작업 관리용이 아니라 협업 도구다. 약 19개월정도 써온 사용자 1) 로서 두레이를 쓰면서 이 점은 좋으니 널리 알리고 싶다 거나 이렇게 써보면 좋겠다 고 느낀 내용을 몇 가지를 써본다. 화면 기획서를 공유하며 다자간 협업 이끌어내기 하위 작업을 통해 주 단위 작업 흐름 만들기 태그 그룹을 이용해 개발 단계 표현하기...

시간의 흐름에 따라 만들어진 데이터를 분석하는것을 시계열 데이터 분석이라 부르고 있다. 필자가 운영하는 서비스에서 시계열 데이터 분석을 통해 장애를 사전에 방지하는 사례를 공유 해보고자 한다....

정확히 이러한 문화를 뭐라 불러야 할지 모르겠다. 기민한 개발조직으로 만들려고 혹은 시장에서 도태되지 않기 위한 간절한 변화의 노력 으로 지난 2년간 만들어낸 우리 조직 [1] 의 개발 문화에 대한 이야기다. 뭉뚱그려 말하면 애자일이라 할 수 있겠으나 애자일이라는 말의 쓰임이 너무나 다양하게 쓰여지고 있어 의미를 얼마나 전달할까 싶다.  아무튼 일을 해나가는 과정속에서 무리하게 정의하려고 들기 보다는 사례를 공유하고, 글을 쓰는 과정에서 조금이나마 개념 정리를 시도해보고자 글을 쓴다....

2017년 popit 회고 에 자극받아 그간 팝잇에 썼던 글을 훑어보고, 그 경험을 한번 되짚어보려고 한다. 그 과정에서 쓰는 욕구에 충실했던 입장에서 한발 떨어져 스스로 회고해보려고 한다. (그래서 뭘 얻을지는 아직 모르지만)   마지막으로 올린 글이 컴퓨터과학이 여는 세계 인데 처음 글을 올린 시점은 2016년 11월 6일 이다. 1년이 조금 넘는 14개월동안 올린 글은 45개로, 매월 3.2개를 올렸다. 사실 올리지 않고 쓰다가 버린 글도 꽤 된다. 팝잇의 출판 플랫폼인 워드프레스가 임시글 기능을 제공하기 때문에 쓰고 싶은 내용이 있으면 일단 썼다. 하지만, 독자에게 의미가 있을지를 재고한 후에 긍정적이라고 생각한 경우만 올렸다. 딱 하나 예외가 있는데 술김에  올렸다가 내리지 않은 글...

중국 이커머스 최대 행사인 쐉쓰이(双十一)때 11월11일 0시가 되자마자 매출이 급상승함과 동시에 이벤트가 미친듯이 순식간에 몰려드는 것을 보고, 일 년 전 밤을 지새우며 O2O 시스템을 Event driven 방식으로 바꾸느라 고생했던 순간이 떠올랐다. 쐉쓰이의 분위기는 동료가 쓴 글인 개발자가 바라본 중국 쇼핑 축제 쐉쓰이(광군제) 에 생생하게 나타나 있다. 실제 당일날 MongoDB 인덱스 문제, 디스크 부족으로 인한 kafka 서버 장애, 등 몇몇 문제가 발생하기도 했지만, 고객에게는 문제없이 서비스가 제공되었고...