안녕하세요. LINE Financial Data Platform을 운영하고 개발하고 있는 이웅규입니다. 저는 지난 NAVER DEVIEW 2020에서 발표했던 Kubernetes를 이용한 효율적인 데이터 엔지니어링 (Airflow on Kubernetes VS Airflow Kubernetes Executor) 세션에서 발표 형식 및 시간 관계상 설명하기 힘들었던 부분을 블로그를 통해 조금 더 자세하게 설명하고자 합니다.  Apache Airflow는 데이터 엔지니어링을 효율적으로 수행할 수 있도록 도와주는 오픈소스 플랫폼으로, 최신 마이너 버전인 1.10.x에 신규 피처(feature)로 Kubernetes Executor가 추가되었습니다. 이 피처는 일반적인 Kubernetes 환경에서 데이터를 엔지니어링할 때 발생하는 단점을 보완하고 Kubernetes의 장점을 데이터 엔지니어링에 적용할 수 있는 방법입니다. 저희 조직에서는 이를 이용해 LINE Financial의 다양한 서비스 데이터를 하나의 금융 데이터 플랫폼으로 모으고, 이렇게 수집한 데이터를 처리하고 가공해 다양한 플랫폼의 사용자에게 유의미한 데이터를 제공하는 역할로 사용하고 있습니다.  저는 두 번에 걸쳐 Kubernetes를 이용한 효율적인 데이터 엔지니어링에 대해 공유하려고 하는데요. 먼저 이번 글에서는 Apache Airflow를 간략하게 소개하고 Executor의 종류와 각 종류별 동작 방식을 설명하겠습니다. 이어지는 2부에서는 일반적인 Kubernetes Airflow 환경과 새로운 방식의 특징 및 장단점을 비교한 뒤, 새로운 방식인 Kubernetes Executor와 KubernetesPodOperator를 적용해 데이터 플랫폼을 어떻게 운영하고 개발하고 있는지 말씀드리겠습니다. 이를 통해 Kubernetes를 데이터 엔지니어링에 적용해 기존보다 확장성을 높였던 경험을 여러분께 공유하려고 합니다. 이 글은 기본적으로 Airflow를 알고 계신다는 가정 하에 작성했습니다. 이 글에 첨부한 코드와 설명은 Apache Airflow 1.10.12 기준이며, 최근 Apache Airflow 2.0이 개발되었지만 기본적인 원리 측면에서는 다르지 않다고 생각합니다.  Apache Airflow는 무엇인가? Apache Airflow란? 공식 홈페이지에서 Airflow는 워크 플로를 코드로 작성하고 스케줄링한 뒤 모니터링하는 플랫폼이라고 설명하고 있습니다. 모든 기술이 그렇듯 Airflow에도 당연히 수많은 장점과 단점이 존재합니다. 제가 생각하는 가장 큰 장점은 데이터 조직이라면 필수로 하게 되는 과거 데이터 재처리 작업을 편리하게 수행할 수 있는 점이라고 생각합니다. 이런 이유로 많은 데이터 조직에서 이미 Airflow를 도입해 사용하고 계실 거라고 생각합니다. Airflow는 Apache 인큐베이터 프로젝트로 선정된 지 3년 만에 탑 레벨 프로젝트(Top-Level Project, TLP)로 선정될 만큼 커뮤니티가 빠른 속도로 확장되고 있습니다.  Apache Ai

안녕하세요. 테크코스교육개발팀 이원미입니다. 우아한테크코스(이하, 우테코) 2기도 어느덧 막바지를 향해 달려가고 있습니다. 레벨 3 기간 동안 우테코 크루들은 실제 현장을 더 밀접하게 경험하기 위해서 팀 프로젝트를 진행하였는데요. 서비스를 실제로 만들어보면서 크루들 각자 느낀 바가 달랐을 것이라 생각합니다. ️ 이번 글쓰기는 레벨 3 활동을 돌아보는 의미에서 팀 프로젝트가 나에게 남긴 것을 주제로 작성하였습니다. 각 팀들은 매주 팀 회고의 과정을 거치고 있기에 프로젝트에 대한 회고가 아닌, 팀 프로젝트에 참여하고 있는 자신을 돌아보는 글을 쓸 수 있도록 가이드 하였고, 그에 따라 자신에 대한 이야기를 솔직하게 남겨주었다고 하는데요! 크루들이 각자의 팀 안에서 어떤 사람이었는지, 어떤 마음으로 프로젝트를 임했고 이 경험을 통해 배운 점은 무엇인지 한 번 확인해볼까요? 바쁜 와중에도 좋은 글을 써 준 크루들에게 감사의 말을 전합니다. ️ 우테코 프로젝트 결과 직고래 대한민국 중고 거래 앱 곧 1등! 당신이 속한 그룹 어디든, 당신이 원하는 무엇이든 사고 팔 수 있는 조직 중고 거래 서비스 직고래입니다. slidemd Beautiful, Minimal Slides With Markdown 칵테일 픽 칵테일 추천 및 정보 제공 서비스 칵테일 픽입니다. 좋은 술을, 고민 없이를 모토로 하는 마시는 여섯들이 제작했습니다. Devbie "초보 개발자 devbie로 데뷔하자"라는 슬로건을 가진 Devbie(Developer + Newbie) 서비스 입니다. 개발자 취업을 준비하는 개발자 지망생들을 위한 취업 정보 공유 커뮤니티 서비스 입니다. peloton 스터디, 운동, 여가활동 등 목표 달성을 도와주는 동기부여 서비스입니다!‍️ 펠로톤 앱은 안드로이드의 Playstore에서 곧 만나보실 수 있어요~(아직 심사중입니다 ) API 관련 문서는 이 곳에서 확인하실 수 있습니다! https://peloton.ga 새벽 새벽은 감정 일기를 올리고, 서로 공감해줄 수 있는 익명 공유 다이어리에요. taggle Bookmarking, Tagging, Subscribing 미소 인스타그램 해시태그 개수를 이용한 핫 플레이스 지도 시각화 서비스 우리동네캡짱 자랑거리에 대해 자랑하는 서비스입니다. 지역+부문 조합과 좋아요(짱)를 통해 랭킹을 매기고, 이에 따라 수상까지 하는, 자신의 자랑을 인정받기 위한, 타인의 자랑을 인정해주기 위한 서비스입니다. 우(김현우)의 글 프로젝트 내내 팀원들과 많이 부딪혔다. 팀 프로젝트에 대한 이상향이 있었다. 모든 사람이 한 곳을 바라보고, 모두가 서로의 코드를 이해하는. 말 그대로 한 몸 같은 팀을 바랬다. 하지만 이상과 현실은 생각보다 차이가 컸다. 같은 언어를 사용하지만 각자 속뜻이 달라 이야기를 하다 보면 다른 곳을 보고 있었던 때가 많았다. 모든 팀원의 코드를 리뷰하려다 보니 개발에 속도가 나지 않을 때가 있었다. 급기야 나중에는 종일 리뷰만 한 날도 있었다. 그런 데다가 반대를 많이 했다. 모든 행동에는 이유가 필요하다

무엇을 공부했나요? 이번 시간에는 Two scoops of Django 24장 장고성능 향상시키기 와 25장 Asynchronous Task Queues을 공부하였습니다. 24장은 안영님이 요약하였고 25장의 내용은 제가, 심화는 연태님이 준비하셨습니다. 성능향상시키기 성능을 향상시키는 여러가지 방법에 대하여서 배웠습니다. 하나의 소프트웨어 제품에는 그것을 이루는 여러가지 계층이 존재하는데요, 그 각각의 성능을 개선하는 방법을 살펴보았습니다. 1. Query: 중복 쿼리를 줄인다,인덱스로 최적화한다, slow query를 제거한다 2. Database: 로그나 일시적 데이터 포함하지 않기, 각 database(psql 혹은 mysql) 환경 세팅에 주의하기 3. Cache: 캐시를 이용할 곳을 잘 정하기, cache invalidation의 시점 4. HTML, CSS, Javascript 같은 static file: 압축, 최소화 하기 5. 업스트림 캐시나 CDN 사용 성능 향상 시키기와 관련된 챕터에서 항상 빠지지 않고 등장하는 말이 있습니다. 서툰 최적화는 해가 될 수 있다. 물론 규모가 큰 서비스를 운영하는 회사에서 일을 하다보면 최적화에 신경써야 하고, 새로운 기능을 추가할 때에도 혹은 기존의 기능을 변경할 때에도 규모의 관점에서 항상 사고해야합니다. 그러나 작은 스타트업에서 새로 서비스를 시작한다거나 혹은 개인적으로 서비스를 만들어 운영하다보면 이와 같은 고민들이 무의미할 때가 많습니다. 물론 장인과 같은 마음으로 개발을 하다보면 자신이 만든 제품이 좀 더 완벽하고 멋있길 바랍니다. 그래서 필요하지도 않은 최적화를 시도하거나 큰 규모에서는 제대로 동작하지 않을거라며 지레 겁먹고 개발하기를 주저하는 경우도 있습니다. 제가 그랬었는데요. 그래서 최소한의 기능을 하는 프로덕트조차 만들지 못했었습니다. 지금 생각하면 바보같은 생각이었죠. 단 한명의 사용자도 없는 상태에서 최적화를 고민하고 있었으니까요. 최적화는 당연히 비용적인 측면이나 서비스의 안정적인 측면에서 매우 중요하지만, 생각보다 그 행복한 고민을 하게되는 시점은 꽤 늦게 찾아오니 위의 내용들을 잊지는 마시고 꼭 나중에 그런 시점을 맞이하시길 바랍니다. 비동기 작업 큐를 써야할 때 책에서는 여러가지 상황들을 나열해가며 비동기 작업을 써야할 때와 그렇지 않아야 할 때를 설명해주었습니다. 일반적으로 결과를 처리하는데 시간이 오래걸리는 작업에는 Task queue를 사용하는 것이 좋지만, 결과를 사용자가 즉시 확인하거나 사용해야되는 작업에는 사용하지 않는 것이 좋다고 합니다. 비동기 태스크 큐의 용도와 특징을 생각해보면 당연하다는 생각이 들 것입니다. 몇가지 주의할 점 1. 멱등성을 유지할 수 있도록 작성하라! * 재시도의 가능성이 항상 있기 때문입니다. 2. 중요한 데이터를 보관하지 마라! * retry 메커니즘이 있지만 실패할 가능성이 있습니다. 예를들어 보내야 할 메시지가 있다면 작업 내용에만 메시지가 있는 것이 아니라, 메시지는 Database에 보관해두고 작업큐에서는 해당

2016년 새해가 벌써 한 달이 지났습니다. 2014년 11월 1일에 오픈한 모씨 서비스도 하루가 다르게 바뀌고, 성장하고 있습니다. 오늘은 그 동안 미루어 두었던 모씨 서비스를 구성하는 시스템에 대해 이야기를 해볼까 합니다. 실제로 많은 분들께서 모씨 시스템 구성에 대해 궁금해 하시고, 몇몇 분들은 직접 사무실에 오셔서 문의를 주신 적도 있었습니다. 지난 1년 3개월동안 발전해 온 시스템 구성에 대해 알아보도록 하겠습니다. Hosting 모씨는 AWS EC2 를 사용합니다. 저희가 상주하는 곳은 도쿄 리전이며, 여러 사정으로 인하여 서울 리전으로 이주할 계획은 현재 없습니다. AWS 에서는 굉장히 많은 종류의 서비스를 제공하는데요, 가급적 AWS 에 지나치게 의존성이 발생하는 것을 최소화 하고자 EC2 서비스 이외에는 아주 일부분에 한하여 AWS 서비스를 이용하고 있습니다. 서비스 초기에 EC2 에 대한 이해가 높지 않은 상태로 시스템을 구성 하였다가 EC2 의 CPU credit 과 EBS 의 IOPS limit 에 부딪혀 낭패를 겪은 적이 몇 번 있었습니다. 특히 메인 데이터베이스의 EBS IOPS limit 문제가 터졌을 때는 정말 멘붕(?) 이었었는데요, 상용 서비스를 구축할 때는 반드시 관련 문서들을 참고 하여 저희와 같은 삽을 뜨지 않기를 바랍니다. 저희가 실질적으로 보유하고 있는 하드웨어 장비는 사내에 있는 맥 미니 서버 한 대 입니다. iOS/Android 클라이언트의 자동 빌드를 위해 보유하고 있습니다. OS 맥 미니 서버에 설치된 OSX 을 제외하고는 모든 서버에서 Ubuntu 14.04 LTS 를 이용하고 있습니다. 모씨 개발 팀은 4명의 개발자로 구성되어 있으며, 상대적으로 설정과 관리가 편한 Ubuntu는 소규모 개발팀에게는 축복과도 같은 운영체제라고 할 만합니다. 1년이 넘는 시간 동안 250만명 이상의 회원이 만들어 내는 트래픽을 수 십대의 Ubuntu 14.04 로 운영해 왔습니다만, Ubuntu 서버는 별 다른 문제를 일으킨 적이 없습니다. EC2 에서 사용 가능한 Ubuntu 14.04 에는 ixgbevf 모듈이 2.11.3-k 가 설치되어 있습니다. 관련 문서 에 따르면 2.14.2 를 설치할 경우 최적의 성능을 발휘할 수 있다고 명시되어 있습니다만, 커널과의 충돌이 발생하여 설치가 되지 않습니다. 현재 Canonical 사와 함께 커널 패치를 진행 중이라고 하니 Ubuntu 16.04 LTS 에서 최신 ixgbevf 모듈이 번들링 되기를 기대해 봅니다. Database 모씨는 다양한 데이터베이스가 유기적으로 연결되어 동작하고 있습니다. 하나씩 살펴보도록 하겠습니다. PostgreSQL 모씨 서비스는 메인 데이터베이스로 PostgreSQL 9.4 를 이용하고 있습니다. 이곳에 사실상 서비스와 관련된 모든 데이터들이 저장되고 있습니다. PostgreSQL 은 그 특성상 다른 데이터베이스에 비해 부하가 있을 경우에 체크해야 할 튜닝 포인트가 좀 여러군데입니다. 아마 데몬이 멀티 스레드가 아닌 멀티 프로세