Resource-Oriented 설계, 그리고 qandaapis안녕하세요. QANDA팀에서 Server 개발을 하는 Joshua 입니다.이 글에서는 API-First Approach를 간략히 알아보고, QANDA팀에서는 이를 바탕으로 기존 개발 프로세스에서 어떤 문제점들을 개선하였는지 알아봅니다.시작먼저, QANDA팀에서 API-First Approach의 시작은 Next QANDA API Raid (👉 QANDA팀 Raid 문화 알아보기)였습니다. qandaapis라는 Git Repository가 2021년 12월에 처음 만들어지고, Next QANDA API Raid는 2022년 1월부터 본격적으로 시작하였습니다.이 Raid를 통해 풀고자 했던 문제의식은설계 단계부터 기술적인 API 설계/리뷰 프로세스 부재제품 개발 과정의 효율화명확한 API Spec 기반의 소통 기반 마련정도로 정리해볼 수 있을 것 같습니다. 그래서 다음을 Next QANDA API Raid의 목표로 삼았습니다.Good API가 무엇인지 정의하고, 구성원들이 같은 그림을 바라볼 수 있도록 한다.Good API가 지속적으로 생산/운영될 수 있는 시스템을 만든다.API First Approach가 개발 문화로 자리 잡도록 한다.이 Raid의 결과로 qandaapis라는 Monorepo를 바탕으로 한, API-First Approach 기반 API 설계/리뷰 프로세스를 마련할 수 있었습니다. (이하, qandaapis라 함은 Git Repository를 지칭함과 동시에 이러한 API 설계/리뷰 프로세스를 통칭합니다.)이어서, API-First Approach를 적용해 나가던 과정을 소개해 보겠습니다.제품 개발 과정전통적인 제품 개발 과정을 생각해보면, 다음과 같이 기획과 디자인 이후 요구사항을 분석하고, Server 개발을 진행하고 이후 API 개발이 진행되면서 이후 Client(및 Web, 이하 Native Client와 Web을 Client로 통칭합니다.) 개발이 진행됩니다.일반적인 제품 개발 과정이처럼 기획부터 제품 출시까지 선형적으로 진행되기 마련인데, 이 글에서는 개발 과정을 중점적으로 다루고자 합니다.Flow chart와 같이 대체로 비지니스 로직들을 Server 중심으로 개발을 하기 대문에, 요구 사항 분석 이후 Server가 어떤 API들이 필요한지 고려하고 먼저 개발을 시작하게 됩니다. 물론 Client에서는 Server API가 나오기 전까지 기다리는 동안, UI/UX 개발을 진행 할 수 있습니다.비즈니스 요구사항에 따라서 어떠한 기능들은 각 파트 별 개발 소요 기간이 제각각 일 수 있어서, 그 중에서도 Server에서 API 개발 및 전달까지 걸리는 시간이 길어지는 경우 병목이 되어 이후 Client개발 기간에도 영향을 줄 수 있습니다.API-First ApproachAPI-First Approach는 이름에서도 알 수 있듯이 API 설계를 우선시하는 전략입니다. 앞서 언급한 바와 같이 전통적인 제품 개발 과정에서 Server에서 API를 개발하는 동

들어가며안녕하세요. MSE2(Messaging Server Engineering 2)에서 인증 도메인을 개발하고 있는 김종민입니다. LINE에서는 서버 개발에 비동기 서버사이드 프레임워크인 Armeria를 적극 사용하고 있습니다. Armeria와 같은 비동기 서버를 처음 사용해 서버 애플리케이션을 개발하다 보면 간혹 서버의 응답 속도가 느려지거나 서비스가 응답 불능 상태가 되는 문제를 겪게 됩니다. 이는 비동기 서버의 이벤트 루프를 블록하기 때문에 발생하는 문제일 가능성이 높습니다.사실 위와 같은 문제는 Armeria뿐만 아니라 이벤트 루프를 바탕으로 하는 라이브러리나 프레임워크를 이용해 애플리케이션을 개발하는 경우에는 언제 어디서나 발생할 수 있는 문제입니다. 저도 처음 위와 같은 문제를 겪고 이벤트 루프가 무엇인지 열심히 찾아가며 공부했던 기억이 있는데요. 그 과정이 쉽지만은 않았습니다. 그래서 제가 공부했던 내용을 바탕으로 이벤트 루프가 무엇이고 블록하는 것이 왜 문제가 되는 것인지, 저와 비슷한 문제를 겪고 있는 엔지니어들에게 조금이나마 도움이 되었으면 하는 바람으로 이 글을 작성하게 되었습니다. 글은 세 편에 걸쳐 아래와 같은 순서로 진행할 예정입니다.비동기 서버에서 이벤트 루프를 블록하면 안 되는 이유 1부 - 멀티플렉싱 기반의 다중 접속 서버로 가기까지 비동기 서버에서 이벤트 루프를 블록하면 안 되는 이유 2부 - Java NIO와 멀티플렉싱 기반의 다중 접속 서버 비동기 서버에서 이벤트 루프를 블록하면 안 되는 이유 3부 - Reactor 패턴과 이벤트 루프1부는 다음과 같은 순서로 진행합니다.이벤트 루프란이벤트 루프는 동시성(concurrency)을 제공하기 위한 프로그래밍 모델 중 하나로, 특정 이벤트가 발생할 때까지 대기하다가 이벤트가 발생하면 디스패치해 처리하는 방식으로 작동합니다. 이벤트 루프는 여러 라이브러리에서 구현되어 중심적인 역할을 담당하고 있습니다. 중요하고 핵심적인 역할을 맡고 있는 만큼 이벤트 루프를 잘 이해하지 못하고 사용하면 앞서 말씀드린 것처럼 정상적인 서비스를 수행할 수 없는 문제가 발생하기도 합니다.이벤트 루프를 블록하면 안 되는 이유를 다루는 이번 시리즈에서는 이벤트 루프 스레드를 블록하면 어떤 문제가 발생하는지 알아보는 것을 시작으로 이벤트 루프를 왜 블록하면 안 되는지 이해할 수 있도록 이벤트 루프가 어떤 구조로 만들어졌는지 소개하겠습니다.Armeria의 이벤트 루프 스레드를 블록하면 발생하는 문제Armeria는 gRPC, Thrift, Kotlin, Retrofit, Reactive Streams, Spring Boot 등 여러 기술을 쉽게 활용해 마이크로 서비스를 만들 수 있도록 해주는 프레임워크입니다. Armeria 역시 내부에서 이벤트 루프를 사용하고 있습니다. Armeria의 이벤트 루프를 블록하면 어떤 문제가 발생할까요? 간단한 예시를 통해서 알아보겠습니다.Armeria는 들어오는 요청이나 처리 후 내보내는 응답에 공통 로직을 적용할 수 있도록 decorator를 제공하고 있습

안녕하세요. Developer Relations 팀의 최예지입니다. 지난 몇 년간 코로나 때문에 콘퍼런스라는 콘퍼런스는 모두 온라인에서 진행돼 꽤나 아쉬웠는데요. 조금은 잠잠해진 요즘, 오랜만에 열린 오프라인 콘퍼런스를 LINE에서 후원해 다녀왔습니다.바로 인프런의 첫 번째 오프라인 콘퍼런스, INFCON 2022입니다. 이번 글에서는 지난 8월 26일 강남구 삼성동 코엑스에서 열렸던 행사 분위기를 전해드리려고 합니다.INFCON 2022는?INFCON은 개발자들에게 친숙한 교육 플랫폼인 인프런에서 주최한 IT 콘퍼런스입니다. 서비스를 만든 IT인들의 경험과 성장 스토리를 담은 다양한 세션이 준비돼 있었습니다.오랜만에 열린 오프라인 콘퍼런스여서인지 개발자와 IT 관계자분들이 정말 많이 찾아오셨습니다. 행사장 곳곳에 네트워킹할 수 있는 자리가 마련돼 있었고 행사장 한편에서는 위 사진과 같이 인프랩 CTO 이동욱 님이 진행하는 YouTube 채널 '개발바닥' 라이브 방송도 진행됐습니다.복작복작한 부스에서 오랜만에 느낀 오프라인 행사 분위기기업들의 후원 부스도 콘퍼런스에 재미를 더했습니다. LINE 외에도 토스, 야놀자, 오늘의집, 당근마켓, JetBrains, 우아한형제들에서 이번 행사를 후원했는데요. 채용풀 등록, 설문조사 등 회사마다 각기 다른 이벤트를 진행하고 있어서 돌아보는 재미가 쏠쏠했습니다. 부스 앞에 줄이 길게 늘어선 모습도 장관이었어요.LINE도 후원사로서 부스를 운영했습니다. 저희 부스에서는 LINE DEV에서 운영하는 채널을 구독하면 다양한 선물을 제공하는 이벤트를 진행했는데 예상했던 것보다 훨씬 많은 분들이 방문해 주셔서 놀랐습니다.INFCON을 방문하지 않았더라도 언제든지 구독 가능한 채널이니 아래 채널을 구독하고 LINE 개발자들의 이야기를 자주 들어보세요!오픈소스 MSA 프레임워크 Armeria 핸즈 온 세션LINE 개발자들이 진행하는 '10만 connection 그까이꺼, Armeria 서버 한 대면 끝!' 핸즈 온 세션도 열렸습니다. LINE의 자랑스러운 오픈소스인 MSA(microservice architecture) 프레임워크 Armeria를 소개하는 시간이었습니다. Armeria의 메인테이너이신 송민우, 엄익훈, 이한남 님이 세션을 이끌어 고성능 비동기 서버를 손쉽게 구현하는 법을 공유해 드렸는데요. 동기 서버만 개발해 보신 분들에게 비동기 서버의 개념을 이해할 수 있는 유익한 시간이 되었길 바랍니다. ?사내 개발자가 아닌 외부 참가자분들과 핸즈 온을 진행한 것은 이번이 처음이었는데요. 걱정과는 달리 다들 높은 집중력으로 잘 따라와 주셔서 세션을 진행하면서 뿌듯했다는 메인테이너 분들의 소감을 들을 수 있었습니다. Armeria에 더 궁금한 점이 있으시다면 Armeria Slack 채널로 들어와주세요.INFCON 세션 발표 자료와 예제 코드는 아래 링크에서 확인하실 수 있습니다.다음 콘퍼런스에서 만나요!함께 모여서 기술 이야기를 나눌 수 있는 환경이 된 만큼, LINE은 앞으로도 다양한 오프라인 콘퍼런스에 후

LINE DEV Meetup #11 'LINE 서버 개발자들이 말한다! Armeria 아직도 안 써요?'에서 김기환, 임경수 님이 발표하신 'Hello Armeria, Bye Spring' 세션 내용을 옮긴 글입니다.안녕하세요. 이번 글에서는 레거시 Spring 프로젝트 애플리케이션을 Armeria로 마이그레이션하면서 얻었던 인사이트를 공유하려고 합니다. 먼저 Armeria로 마이그레이션하게 된 동기를 말씀드리고 이어서 어떻게 마이그레이션 작업을 진행했고 그 과정에서 무엇을 얻었는지 말씀드리겠습니다. 앞서 이희승 님이 Armeria를 소개합니다라는 글에서 Armeria는 'at your pace'를 지향한다고 말씀해 주셨습니다. Armeria로 마이그레이션하는 것 또한 조금씩 나눠서 점진적으로, 자신의 페이스대로 진행하는 것이 가능합니다. 저희는 세 단계로 나눠서 진행했는데요. 각 단계별로 어떤 작업을 진행했고 그 작업을 통해 무엇을 얻었는지 말씀드리겠습니다. 그리고 마지막으로 Armeria로 마이그레이션한 뒤 얻었던 여러 이점 중에서 꼭 언급하고 싶은 성능 관점에서의 이점을 말씀드리겠습니다.Armeria로 마이그레이션한 이유Armeria로 마이그레이션한 동기를 말씀드리기 전에 마이그레이션 대상 컴포넌트를 먼저 소개하겠습니다. 저희는 현재 LINE에서 API 게이트웨이 역할을 맡고 있는 Channel Gateway라는 컴포넌트를 개발하고 있습니다. LINE의 여러 패밀리 서비스와 서드파티 앱들이 LINE에서 리소스를 가져가고 싶을 때 반드시 거쳐야 하는 컴포넌트입니다. LINE에 존재하는 여러 리소스를 다양한 형태로 가공해서 클라이언트로 보내야 하는 역할을 맡고 있으며, 그에 따라 굉장히 많은 업스트림 서비스가 Channel Gateway 서버에 연결돼 있습니다. 규모 측면에서 하루에 약 80억 건 정도의 요청이 들어오는, 대규모 트래픽을 소화하고 있는 서버입니다.Channel Gateway는 Armeria를 도입하기 전에는 전형적인 Spring MVC 애플리케이션으로 구성돼 있었습니다. 서버에서의 네트워크는 모두 Tomcat으로 처리하고, 업스트림과의 통신은 Apache HTTPClient를 사용해서 동기 방식으로 통신하는 구성이었는데요. 이와 같은 구성에 기인하는 전형적인 문제를 겪고 있었습니다. 앞서 업스트림 서비스가 굉장히 많이 붙어 있다고 말씀드렸는데 그중 어떤 하나의 업스트림에 장애가 발생해서 응답 지연 시간이 길어지는 상황이 발생했을 때, 그로부터 파생된 장애가 전체 서버 시스템을 마비시키기까지 그리 오랜 시간이 걸리지 않는다는 문제였습니다. 아래 슬라이드 하단의 지표를 보시겠습니다. 장애가 발생한 업스트림의 응답을 Tomcat 스레드가 계속 기다리면서 대기하다가, 종국에는 Tomcat 스레드 풀의 모든 스레드가 해당 업스트림의 응답을 기다리게 되면서 더 이상 요청을 받을 수 없는 상태에 빠지는 모습입니다. 이와 같은 일이 굉장히 빈번히 발생했습니다.이에 Armeria 적용 전에는 이런 전면 장애 상황에 빠지는 것을 막기 위