다메카솔

지난 5월 15일, 코엑스 컨퍼런스룸 3층에서 열린 마이크로소프트 x 깃허브 로드쇼에 참석했습니다. 이 행사에서는 2년 전에 출시된 Github Copilot을 활용하여 개발자의 생산성을 향상시키는 방법과 클라우드 네이티브 환경에서 인공지능(AI)의 도움을 받아 빠르게 서비스를 출시하는 미래 시대의 개발문화를 체험할 수 있었습니다.

ChatGPT는 이미 많은 직장인들이 업무에 활용하여 반복적인 작업을 줄이고 생산성을 높이는 데 큰 도움을 주고 있습니다. 실제 개발자의 코드 작성 작업에서도 ChatGPT는 주석을 입력하면 원하는 코드를 제안해주고, 제안된 템플릿을 검토한 후 상황에 맞게 수정하여 적용하면 잘 작동합니다. 또한, 코드형 인프라(IaC)의 설정 파일 작성과 쿠버네티스 설정도 지원하는 것을 시연했습니다.

이 행사에서는 Github Copilot과 마이크로소프트에서 제공하는 다양한 클라우드 서비스들을 소개했지만, 가장 인상 깊었던 것은 AI를 활용한 개발 생산성 향상이었습니다. AI가 다양한 영역에서 사람들의 업무를 자동화하고 개발 생산성을 향상시키는 상황에서, 이를 비즈니스에 어떻게 적용하여 더 좋은 제품과 서비스를 제공할 수 있는지, 그리고 AI가 대체하지 못하는 요소들(예: 팀의 성격, 문화, 아키텍처 등)에는 어떻게 AI의 도움을 받아 더욱 생산성을 향상시킬 수 있는지에 대한 궁금증이 생겼습니다.

우선 AI시대에 뒤쳐지지 않도록 업무에서 활용하며 큰 효과를 보고있는 Copilot을 팀원들에게 적극 추천하고, 개발생산성에 대한 논의를 제시해보는 방법부터 시작해봐야 할 것 같습니다.

많이 지났지만, 지난 2023년 3월 19일 SQLP 시험을 보고 왔습니다.

먼저 시험 결과부터 이야기하자면, 불합격 하였습니다. 그래도 시험을 보고 나니 응시하길 잘한 것 같아서 다행입니다.

작년 말 빅데이터 분석기사 실기 합격결과 발표 때, 내년엔 무엇을 공부할까 고민하던 중 어렵기로 유명한 SQLP 자격증이 떠올랐습니다. SQLP 자격증은 합격률이 10% 미만으로 매우 어려운 시험으로, 공부량도 많고 내용도 어려워서 정말 쉽지 않은 도전이 될 것이라 생각했습니다. 하지만, 개발자로 일하면서 언젠간 느린 SQL을 튜닝해야 할 상황이 올 것이고, 데이터베이스 아키텍처에 대해 체계적으로 공부해야 더 성장할 수 있다고 느꼈습니다. 그래서 2023년에 SQLP 시험을 보기로 결심했습니다.

실제 시험은 예상보다 익숙한 용어들이 많이 등장하였고, 공부한 내용들도 생각보다 꽤 출제되었습니다. 꾸준한 노력과 숙달하게 공부한다면, 다음 시험이나 다다음 시험에서는 더 나은 결과를 얻을 수 있을 것 같은 희망이 생겼습니다.

다음 시험은 9월입니다. 합격발표가 나고 4월부터 공부를 시작했는데 한 3주는 열심히 하다 요즘 지지부진해진 것 같네요 ㅠ.ㅠ 다시 마음잡고 공부를 해야겠습니다.

https://product.kyobobook.co.kr/detail/S000200381165

독서기간 : 2023.03

독서시간 : 5H

평점 : ★★★★☆

한줄평 : 시니어들이 경력을 쌓으며 만든 원칙들을 공유받을 수 있습니다.

인생을 살아가면서 사람들은 다양한 경험을 하고, 성공과 실패를 통하여 이전보다 더 성장합니다.

개발자들은 조직의 문제, 프로젝트의 문제, 더 나아가 사회의 문제를 해결하기 위해 성장을 추구합니다.

많은 책을 읽거나 컨퍼런스 등에 참여하여 새로운 정보를 얻고, 그 정보를 사람들과 나누며 함께 성장하며 살아갑니다.

이제 막 개발을 시작한 주니어들은 주변에 사수가 있을 수도 있고, 없을 수도 있고, 같이 성장할 비슷한 레벨의 동료들이 있을 수도 있지만 없을 수도 있습니다. 

위 책은 시니어 레벨의 테크 리더들이 현실세계의 문제를 해결하면서 깨달은 성공, 그리고 성장을 위한 원칙들의 노하우를 요약한 책입니다. 일을 하거나 인생을 살아가면서 이미 경험한 누군가가 건네주는 조언은 후임자들의 실행착오를 줄여주며 그만큼 더 생산적인 결과가 나올 수 있게되고, 결과적으로 사회가 더 좋아지게 될 것입니다.

각각의 테크리더들이 처한 상황과 관점이 다르다보니 책에서 소개하는 원칙들을 독자들이 처한 상황에 100% 적용할 수 있을지는 잘 모르겠습니다. 저같은 경우 주니어레벨에게 설계의 원칙을 이야기한 챕터를 읽을 때, 아직은 해당 원칙을 고민해야 할 정도로 개발자로서 성장하지 않았다는 느낌을 받았습니다.

하지만 지금 제 고민을 더 좋은 방법으로 해결해줄 수 있는 원칙들도 있었고, 곧 닥쳐올 고민에 대한 이야기도 있었습니다.

책을 통해 쉽게 듣기 힘든 테크리더들의 노하우를 공유받을 수 있다는 부분에서 유익한 독서였습니다.

Nginx는 오픈소스 웹 서버 및 리버스 프록시 서버 소프트웨어로, 다양한 운영 체제에서 사용되며 높은 성능과 안정성을 가지고 있습니다. Nginx는 이벤트 기반 구조를 사용하여 비동기적으로 동작하며, 적은 자원으로 많은 연결을 처리할 수 있어 인기 있는 소프트웨어입니다.

이전에 작성한 Nginx에 대한 소개 글에 이어 Nginx의 구조에 대해 살펴보겠습니다.

https://damecasol.tistory.com/86

Nginx의 구조

NGINX는 이벤트 구동, 비동기 및 비차단 모델을 지원하여 마스터-슬레이브 아키텍처로 구성되어있습니다.

1. Master process : 모든 워커 프로세스를 관리하는 부모 프로세스입니다.
2. Worker process : 클라이언트 요청을 처리하는 자식 프로세스입니다.
3. Event module : Nginx의 비동기 이벤트 처리 엔진으로, I/O 처리를 담당합니다.
4. Cache module : 자주 요청되는 리소스를 캐시하여 처리 속도를 높입니다.
5. HTTP module : HTTP 요청 및 응답 처리를 담당합니다.
6. Reverse proxy module : 웹 서버에서 클라이언트 요청을 받아 백엔드 서버로 전달하는 역할을 합니다.
7. Load balancing module : 여러 백엔드 서버로 부하를 분산하는 로드 밸런싱을 수행합니다.
8. SSL module : SSL/TLS 암호화 연결을 지원합니다.

위의 이미지에서 핵심 부분 3가지를 조금 더 정리하면 다음과 같습니다.

Master Process

클라이언트의 요청에 따라 작업자에게 작업을 할당합니다. 작업자에게 작업이 할당되면 마스터는 작업자의 응답을 기다리지 않는 클라이언트의 다음 요청을 찾습니다. 작업자로부터 응답이 오면 마스터가 클라이언트에 응답을 보냅니다.

Worker Process

워커는 NGINX 아키텍처의 슬레이브이며 마스터를 리스닝합니다(원문 heed). 각 워커는 단일 스레드 방식으로 한 번에 1000개 이상의 요청을 처리할 수 있습니다. 프로세스가 완료되면 응답이 마스터로 전송됩니다. 단일 스레드는 다른 메모리 공간 대신 ​​동일한 메모리 공간에서 작업하여 RAM 및 ROM 크기를 절약합니다. 다중 스레드는 다른 메모리 공간에서 작동합니다.

Cache 

Nginx 캐시는 서버에서 가져오는 대신 캐시 메모리에서 가져와 페이지를 매우 빠르게 렌더링하는 데 사용됩니다. 페이지에 대한 첫 번째 요청 시 페이지가 캐시 메모리에 저장됩니다.

정리

Nginx의 구조를 알아보면서 마스터-슬레이브 아키텍처, 그리고 Nginx가 멀티프로세스 - 단일스레드 방식으로 작동한다는 것을 알게 되었습니다.

위의 내용에 대해서는 후에 더 정보를 찾아봐야 겠습니다.

참고자료

https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

https://medium.com/@premsuryamj/nginx-architecture-9f97cf7887e2

TCP 공부를 하면서 Graceful Shutdown이라는 내용을 접하였습니다.

설명을 보면 정상적으로 종료할 때 (ex : 전송 중인 데이터를 다 전송한 뒤에 종료할 때) 사용하는 것 같은데, 명확하게 와닿지가 않아서 조금 더 조사해보았습니다.

Gracefull Shutdown

TCP 프로토콜에서 Graceful Shutdown은 두 개의 호스트 간의 연결을 종료할 때 데이터의 손실을 방지하고 완전한 데이터 전송을 보장하는 방법입니다. 이는 애플리케이션에서 특정 작업이나 프로세스가 완료될 때 해당 작업이나 프로세스에 대한 연결을 종료할 때 자주 사용됩니다. 

TCP의 4-way handshake

TCP의 4-way handshake는 서버와 클라이언트 간에 데이터를 주고받을 때, 연결을 설정하고 해제하는 과정입니다. Graceful Shutdown에서도 4-way handshake를 사용하여 연결을 종료합니다. 클라이언트는 서버에게 연결 종료 요청을 보내고 서버는 연결 종료 응답을 보냅니다. 그 후, 서버는 클라이언트로부터 데이터 전송이 완료될 때까지 대기하고 최종 확인 응답을 보냅니다. 마지막으로 클라이언트는 확인 응답을 받으면 연결을 종료합니다.

Gracefull Shtudown과 반대되는 개념으로 착각하여 강제종료 같은 선입견이 생겼었는데 추가로 정보를 찾으면서 잘 정리한 것 같습니다.

데이터 손실 방지

Graceful Shutdown은 데이터의 손실을 방지하고 완전한 데이터 전송을 보장합니다. 이는 데이터가 완전히 전송되기 전에 연결을 종료하지 않으므로 발생하는 것입니다. 이것은 애플리케이션에서 데이터의 손실이 발생하지 않도록 하고, 네트워크 성능을 향상시키는 데 매우 중요합니다.

Graceful Shutdown의 예시

Graceful Shutdown은 많은 서비스에서 사용됩니다. 예를 들어, 웹 서버에서는 연결이 길게 유지되는 경우 연결을 종료하기 전에 모든 데이터를 보내야 합니다. 이는 사용자가 전송한 데이터가 완전히 처리되었음을 보장하고, 불필요한 리소스 사용을 방지하며, 서버의 가용성을 유지하는 데 도움이 됩니다. 또한, 데이터베이스 서버에서는 데이터베이스 작업이 완료된 후 연결을 종료하는 데 Graceful Shutdown을 사용합니다.

참고자료

https://www.rfc-editor.org/rfc/rfc793

사내 솔루션을 ASIS JSP + Spring로 구성된 WAS 단일서버에서 Vue.js + Spring으로 UI 차세대를 진행하였습니다.

그에따라 Web서버를 구성해야 할 필요성이 생겼으며, Nginx로 Web서버를 구성하기 위해 찾은 내용을 정리하였습니다.

Nginx란

nginx는 오픈 소스 웹 서버 및 리버스 프록시 소프트웨어입니다. nginx는 Apache와 함께 가장 인기있는 웹 서버 중 하나입니다. nginx는 간단하고 가벼우며 높은 성능과 안정성을 제공합니다.

nginx는 단일 서버 또는 여러 서버에서 사용할 수 있습니다. 여러 서버에서 사용할 경우, nginx는 로드 밸런싱, 캐싱 및 HTTP 및 TCP 로드 밸런싱 기능을 제공합니다.

nginx의 구성은 유연하고 사용자 정의가 가능합니다. nginx 구성 파일은 기본적으로 설정 파일을 읽는 순서로 작성됩니다. 이렇게하면 새로운 구성을 적용하기 전에 이전 구성을 쉽게 되돌릴 수 있습니다.

nginx는 다양한 운영 체제에서 실행될 수 있습니다. 또한 다양한 모듈과 플러그인이 있어서 다양한 기능을 확장할 수 있습니다. 이러한 기능 중 일부는 HTTPS 지원, FastCGI 프로토콜 지원 및 웹 소켓 프로토콜 지원입니다.

nginx는 높은 성능, 안정성 및 유연성으로 인해 많은 대규모 웹 사이트와 애플리케이션에서 사용됩니다.

WEB서버와 WAS 서버

일반적으로, 웹 서버는 정적인 컨텐츠를 처리하고, 애플리케이션 서버는 동적인 컨텐츠를 처리합니다. 이렇게 역할을 나누어 웹 서버는 클라이언트의 요청을 받아 정적인 페이지나 파일을 반환하고, 애플리케이션 서버는 동적인 컨텐츠를 생성하여 반환합니다.

웹 서버와 애플리케이션 서버를 분리하는 이유는 다음과 같습니다.

1. 확장성: 웹 서버와 애플리케이션 서버를 분리하면, 각각의 서버를 별도로 확장할 수 있습니다. 웹 서버를 추가로 배치하여 클라이언트 요청을 더 많이 처리하고, 애플리케이션 서버를 추가로 배치하여 동적인 컨텐츠를 처리하는 데에 집중할 수 있습니다.
2. 보안: 웹 서버와 애플리케이션 서버를 분리하면, 보안 측면에서 더욱 안전한 구성이 가능합니다. 애플리케이션 서버는 외부로부터 직접적인 접근을 받지 않기 때문에, 애플리케이션 서버 자체의 보안성을 높일 수 있습니다.
3. 유지보수: 웹 서버와 애플리케이션 서버를 분리하면, 각각의 역할에 따라 서버를 유지보수할 수 있습니다. 예를 들어, 웹 서버는 정적인 컨텐츠를 처리하므로, 웹 서버를 유지보수할 때 애플리케이션 서버를 중단시키지 않아도 됩니다.

Nginx 기능

wiki에 나열되어 있는 웹 서버 기능은 다음과 같습니다.

• 정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능.
• 캐싱을 통한 리버스 프록시
• 로드 밸런싱
• 고장 진단
• SSL 지원
• 캐싱을 통한 FastCGI 지원
• Name-, IP-기반 가상서버
• FLV 스트리밍
• MP4 스트리밍 모듈을 이용한 MP4 스트리밍
• 웹페이지 접근 인증
• gzip 압축
• 10000개의 동시 접속을 처리할 수 있는 능력
• URL 다시쓰기 (URL rewriting)
• 맞춤 로깅
• 서버 사이드 기능 포함
• WebDAV

이중 궁금한 내용 몇가지만 추가로 찾아보았습니다.

정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능

Nginx는 웹 서버 기능을 수행하며, HTTP 요청에 대한 응답으로 정적 파일을 서비스할 수 있습니다. 이때, 정적 파일이란 이미 생성된 HTML, CSS, JavaScript, 이미지 파일 등을 의미합니다. 이러한 정적 파일들은 일반적으로 웹 서버의 특정 디렉토리에 저장되어 있으며, 클라이언트가 해당 파일의 URL을 요청하면 Nginx는 해당 파일을 응답으로 제공합니다.

Nginx는 클라이언트가 요청한 파일이 없을 경우, 디렉토리 내에 있는 인덱스 파일을 반환합니다. 인덱스 파일은 해당 디렉토리에 위치한 기본 파일을 말합니다. 기본적으로 Nginx에서는 index.html, index.htm, index.php 등을 인덱스 파일로 지정하고 있습니다.

또한, Nginx는 자동 인덱싱 기능을 제공합니다. 자동 인덱싱 기능은 인덱스 파일을 설정하지 않았을 경우, 해당 디렉토리 내에 있는 파일 목록을 자동으로 생성하여 클라이언트에게 보여줍니다. 이때 파일 목록은 정렬된 상태로 제공되며, 클라이언트는 이 목록에서 원하는 파일을 선택하여 다운로드할 수 있습니다.

캐싱을 통한 리버스 프록시

이번에 Nginx를 사용하게 된 주된 이유입니다.

캐싱을 통한 리버스 프록시란, 리버스 프록시 서버가 클라이언트 요청에 대한 응답을 받아서 해당 응답을 캐시에 저장하고, 이후에 같은 요청이 들어오면 캐시된 응답을 바로 제공하는 방식입니다. 이는 웹 서버의 부하를 줄이고, 성능을 향상시키는 데에 유용합니다.

리버스 프록시는 일반적으로 웹 서버 앞단에서 사용되며, 클라이언트 요청을 받아서 웹 서버로 전달합니다. 이때, 리버스 프록시는 요청에 대한 응답을 받아서 클라이언트에게 전달하기 전에 캐시에 저장할 수 있습니다. 이후에 같은 요청이 들어오면 리버스 프록시는 캐시된 응답을 클라이언트에게 바로 전달합니다.

캐시를 통한 리버스 프록시는 다음과 같은 장점을 가집니다.

성능 향상: 캐시를 사용하면 웹 서버의 부하를 줄일 수 있습니다. 이미 캐시된 응답을 제공하기 때문에 웹 서버가 해당 요청에 대한 처리를 다시 할 필요가 없기 때문입니다.

대역폭 절약: 캐시를 사용하면 웹 서버에서 클라이언트로 전송되는 데이터 양을 줄일 수 있습니다. 이미 캐시된 응답을 제공하기 때문에 웹 서버에서 클라이언트로 전송되는 데이터 양이 줄어들기 때문입니다.

빠른 응답 속도: 캐시를 사용하면 클라이언트가 요청한 응답을 바로 제공할 수 있습니다. 이미 캐시된 응답을 제공하기 때문에 웹 서버에서 응답을 생성하는 시간이 필요 없기 때문입니다.

로드밸런싱

Nginx는 로드 밸런싱 기능을 지원하는 웹 서버 및 리버스 프록시입니다. 로드 밸런싱은 여러 대의 서버에 걸쳐 트래픽을 분산시키는 기술로, 클라이언트 요청을 여러 대의 서버에 분산하여 서버의 부하를 분산시켜 안정적인 서비스를 제공하는 것을 목적으로 합니다.

Nginx의 로드 밸런싱 기능은 다음과 같은 특징을 가집니다.

알고리즘: Nginx는 가중 라운드 로빈, IP 해시, Least Connections 등 다양한 로드 밸런싱 알고리즘을 지원합니다. 가중 라운드 로빈 알고리즘은 서버에 부여된 가중치를 기반으로 요청을 분산시키며, IP 해시 알고리즘은 클라이언트의 IP 주소를 해시하여 분산시킵니다. Least Connections 알고리즘은 현재 가장 적은 연결 수를 가진 서버에 요청을 전달하는 방식으로 작동합니다.

Health check: Nginx는 로드 밸런싱 대상 서버의 상태를 주기적으로 확인하는 Health check 기능을 제공합니다. 서버의 상태가 이상하면 요청을 보내지 않고, 정상적인 서버에만 요청을 분산시킵니다.

Sticky session: Sticky session 기능은 클라이언트가 처음 요청한 서버에 계속해서 요청이 전달되도록 합니다. 이 기능을 사용하면 클라이언트의 세션 상태를 유지할 수 있어, 로그인 등의 상태 유지 기능을 구현할 수 있습니다.

Upstream: Nginx는 로드 밸런싱 대상 서버를 Upstream 블록으로 정의하여 관리합니다. Upstream 블록은 로드 밸런싱 대상 서버의 주소와 포트 정보를 포함하며, 서버의 추가나 삭제 등 유지보수 작업이 용이합니다.

다양한 프로토콜 지원: Nginx는 HTTP, HTTPS, TCP, UDP 등 다양한 프로토콜을 지원합니다. 따라서, 로드 밸런싱 기능을 사용하여 다양한 서비스를 제공할 수 있습니다.

참고자료

https://ko.wikipedia.org/wiki/Nginx

TCP 란

TCP(Transmission Control Protocol)는 인터넷에서 컴퓨터들이 신뢰성 있는 데이터 통신을 하기 위한 프로토콜입니다. TCP는 IP(Internet Protocol)와 함께 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나로, OSI 7계층에서 전송 계층(Transport Layer)에 해당됩니다.

TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 세그먼트(Segment) 단위로 데이터를 나누어 전송합니다. 전송 중 데이터가 유실되거나 손실되었을 경우, TCP는 재전송을 수행하여 데이터의 신뢰성을 보장합니다. 또한, TCP는 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control) 기능을 갖추어, 데이터 전송 시 네트워크 혼잡을 방지하고 성능을 최적화합니다.

TCP는 연결 지향적(Connection-oriented)인 프로토콜로, 3-way handshake를 통해 연결을 설정하고, 4-way handshake를 통해 연결을 종료합니다. 연결 설정 과정에서는 SYN(Synchronize)과 ACK(Acknowledgement) 플래그를 이용하여 연결을 수립하며, 연결 종료 과정에서는 FIN(Finish) 플래그를 이용하여 연결을 종료합니다.

TCP는 다양한 응용 프로그램에서 사용되며, 특히 웹 브라우저와 웹 서버 간의 HTTP 통신에서 사용됩니다.

TCP vs UDP

TCP의 특징을 이해하기 위해선 TCP가 아닌 UDP 프로토콜에 대한 이해도 필요합니다.

TCP와 UDP는 모두 인터넷 프로토콜 스위트의 전송 계층(Transport Layer)에서 사용되는 프로토콜입니다. 그러나 두 프로토콜은 목적과 특징에서 차이가 있습니다.

TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 보장하는 연결 지향적(Connection-oriented) 프로토콜입니다. 데이터 전송 전에 연결을 설정하고, 데이터를 송수신할 때마다 확인 응답을 주고받아 데이터 전송의 신뢰성을 보장합니다. 데이터 전송 과정에서 패킷 유실이나 손상이 발생하면 재전송을 요청하여 데이터의 정확성과 신뢰성을 보장합니다. 이러한 특성 때문에 웹, 이메일, 파일 전송 등 신뢰성이 중요한 응용 프로그램에서 사용됩니다.

반면에 UDP(User Datagram Protocol)는 비신뢰성 있는 데이터 전송을 하는 비연결형(Connectionless) 프로토콜입니다. 데이터를 송수신할 때 연결 설정 과정이 없으며, 데이터 전송 과정에서 확인 응답을 보내지 않습니다. 이러한 특성 때문에 TCP보다 빠른 전송 속도를 가지고 있습니다. 그러나 데이터 전송의 신뢰성을 보장하지 않기 때문에, 오류나 손상이 발생하면 복구할 수 없습니다. 이러한 특성 때문에 DNS, 멀티미디어 스트리밍 등 속도가 중요한 응용 프로그램에서 사용됩니다.

따라서, TCP와 UDP는 목적에 따라 선택하여 사용해야 합니다. 만약 데이터의 신뢰성이 중요하다면 TCP를 사용하고, 데이터 전송 속도가 중요하다면 UDP를 사용합니다.

3-way handshake

3-way handshake는 TCP 연결을 설정할 때 사용되며, 다음과 같은 과정으로 이루어집니다.

1. 클라이언트가 서버에게 SYN 패킷을 보냅니다.
2. 서버는 SYN 패킷을 받고, 클라이언트에게 ACK와 SYN 패킷을 보냅니다.
3. 클라이언트는 ACK 패킷을 보내서 연결을 완료합니다.

4-way handshake

4-way handshake는 TCP 연결을 해제할 때 사용되며, 다음과 같은 과정으로 이루어집니다.

1. 클라이언트가 서버에게 FIN 패킷을 보냅니다.
2. 서버는 FIN 패킷을 받고, ACK 패킷을 보내서 클라이언트에게 확인합니다.
3. 서버가 데이터를 모두 보낼 때까지 대기합니다.
4. 서버가 데이터를 모두 보낸 후, 클라이언트에게 FIN 패킷을 보냅니다.

전송계층의 특징

전송 계층은 송신자와 수신자 간의 신뢰성 있는 데이터 전송을 보장하기 위한 계층입니다. 이를 위해 전송 계층은 다음과 같은 특징을 가지고 있습니다.

연결 지향성(Connection-oriented)
TCP(Transmission Control Protocol) 프로토콜은 연결 지향성을 가지고 있습니다. 이는 데이터 전송 전에 먼저 연결을 설정하고, 데이터 전송 후에는 연결을 해제하는 과정을 거치는 것을 의미합니다. 이러한 연결 지향성은 신뢰성 있는 데이터 전송을 보장합니다.

비연결 지향성(Connectionless-oriented)
UDP(User Datagram Protocol) 프로토콜은 비연결 지향성을 가지고 있습니다. 이는 데이터 전송에 앞서 연결 설정을 하지 않고, 단순히 데이터를 전송하는 것을 의미합니다. 이러한 비연결 지향성은 전송 속도가 빠르다는 장점이 있지만, 데이터 전송 중 손실이 발생할 경우 복구할 수 있는 기능이 없습니다.

에러 제어(Error control)
전송된 데이터가 손실되거나 손상되는 경우를 대비하여, 전송 계층에서는 에러 제어 기능을 제공합니다. TCP 프로토콜에서는 수신자가 전송한 데이터를 잘 받았는지 확인하는 기능인 'ACK'와 데이터 전송 중 손실된 패킷을 다시 전송하는 기능인 '재전송' 기능 등을 제공합니다.

흐름 제어(Flow control)
전송 계층에서는 수신자가 처리할 수 있는 데이터 양을 조절하기 위해 흐름 제어 기능을 제공합니다. 이를 통해 송신자와 수신자 간의 데이터 전송 속도 차이로 인해 발생할 수 있는 문제를 예방할 수 있습니다.

다중화(Multiplexing)
하나의 호스트에서 여러 개의 프로세스가 동시에 데이터를 전송할 경우, 전송 계층에서는 각각의 프로세스를 구분하기 위한 다중화 기능을 제공합니다. 이를 통해 하나의 호스트에서 여러 개의 어플리케이션이 동시에 동작할 수 있습니다.

확인

사용중인 컴퓨터에서 실제로 연결된 TCP 정보를 확인할 수 있습니다.

CMD 창을 실행한 뒤, netstat -an 명령어를 입력하면 다음과 같이 프로토콜과 로컬 주소, 외부 주소 및 상태를 확인할 수 있습니다.

서버에 요청을 한 뒤 4way handshake를 통해 FIN 명령어를 받아 TIEM_WAIT 상태로 남아있는 연결정보를 확인할 수 있으며, 현재 연결상태로 유지되고 있는  ESTABLISHED, 또한 요청을 기다리고 있는 LISTENING 포트도 확인할 수 있습니다.

사내에서 프로젝트를 진행하면서 개발 및 배포를 할 때 현재 사용하는 방법은

강의를 듣거나 책을 읽을 때 나오는 `고대의 방법'인 war파일을 생성하고, was서버의 배포 폴더에 이동 한 뒤 재기동하는 방식을 사용하고 있습니다.

사내 시스템을 효율적으로 개선하고 싶어서 임원분들과 관리자분에게 여러번 요청하였지만 우선순위에 밀려 진행하지 못하다 이번에 여유가 생겨 시스템을 도입하기로 하였습니다.

Jenkins 도입에 앞서 Jenkins를 사용하는 목적인 CI/CD가 무엇이고 어떤 장단점이 있는지 정리해보았습니다.

CI/CD란?

CI/CD란 소프트웨어 개발에서 지속적인 통합과 배포를 의미하는 용어입니다. CI는 소스 코드 변경이 일어날 때마다 자동으로 빌드, 테스트 등의 작업을 수행하여 팀 내에서 통합된 코드를 유지하고 품질을 유지하는 것을 말하며, CD는 CI를 통해 빌드된 코드를 자동으로 배포하여 최종 사용자에게 제공하는 것을 의미합니다.

CI/CD의 필요성

개발자 생산성 향상

CI/CD를 도입하면 개발자는 빠른 피드백과 자동화된 빌드, 배포 등의 작업을 통해 개발 속도를 높일 수 있습니다. 이는 개발자들이 더욱 집중적으로 개발에만 집중할 수 있도록 돕습니다.

높은 코드 품질

CI/CD를 활용하면 빌드와 테스트 자동화를 통해 오류 발생 가능성을 줄일 수 있습니다. 이는 코드의 품질과 안정성을 높이고, 버그 발생 가능성을 낮출 수 있습니다.

빠른 배포

CI/CD를 도입하면 빠른 속도로 배포를 수행할 수 있습니다. 이는 고객 요구사항이나 시장 상황 변화에 빠르게 대응할 수 있도록 돕습니다. 또한, 빠른 배포는 개발자들이 새로운 기능을 빠르게 출시하여 경쟁 우위를 유지할 수 있도록 돕습니다.

개발 프로세스의 표준화

CI/CD를 도입하면 개발 프로세스를 자동화하고 표준화할 수 있습니다. 이는 프로젝트 참여자들 간의 협업을 더욱 원활하게 할 수 있으며, 코드의 일관성과 품질을 유지할 수 있습니다.

Jenkins란

Jenkins는 자동화된 소프트웨어 개발 프로세스를 지원하는 오픈 소스 도구입니다. 이 도구를 사용하면 개발자들이 소스 코드를 지속적으로 빌드, 테스트 및 배포할 수 있으며, 이를 자동화하여 더욱 빠르고 안정적인 소프트웨어 개발 및 배포를 가능하게 합니다.

Jenkins는 다양한 플러그인을 지원하며, 이를 통해 빌드, 테스트, 배포, 지속적인 통합 및 배포(CI/CD) 파이프라인 등의 작업을 자동화할 수 있습니다. 이를 통해 개발자들은 자동화된 작업으로 인해 더 많은 시간과 노력을 코드 작성에 집중할 수 있습니다.

Jenkins는 Java로 작성되어 있으며, Java 기반의 어플리케이션을 빌드 및 배포하는 것을 지원합니다. 그러나 이 외에도 다양한 언어와 프레임워크를 지원하며, 개발자들은 다양한 플러그인을 통해 커스터마이징할 수 있습니다.

Jenkins는 오픈 소스이므로 무료로 사용이 가능하며, 커뮤니티에서 지속적으로 업데이트 및 개선이 이루어지고 있습니다.

사내 Jenkins 서버 구축 목표

• 반복적인 작업을 자동화
  • ex) 빌드 → ssh접속 → 배포 및 백업 → 서버 재기동
• 빌드 환경 표준화
  • 개발자마다 로컬 개발PC 환경이 달라진다면 빌드 결과물이 달라질 수 있음
  • Jenkins : 빌드서버 구축으로 표준화된 빌드 환경 구축

참고자료

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

https://ko.wikipedia.org/wiki/%EC%A0%A0%ED%82%A8%EC%8A%A4_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4) 

https://ko.wikipedia.org/wiki/%EC%A7%80%EC%86%8D%EC%A0%81_%ED%86%B5%ED%95%A9

알고리즘 문제를 풀 때 답을 제출하기 위해서 문자열을 조작할 때 자주 사용하는 클래스가 두가지가 있습니다.

StringBuilder와 BufferedWriter가 있는데, 두가지 모두 유사하게 사용하고 있지만, 자세하게 어떤 차이가 있는지 그리고 어떤 특징과 장단점이 있는지 잘 정리가 안되어서 각각의 특징과 장단점을 알아봅시다.

StringBuilder와 BufferedWriter는 둘 다 문자열을 처리하는 클래스입니다. 하지만 각각의 특징과 장단점은 다릅니다.

StringBuilder

StringBuilder는 문자열을 조작하는 데 사용되며, 내부적으로 가변 문자열 배열을 사용합니다. 문자열 조작은 메모리 내부에서 수행되므로 속도가 빠르며, 문자열을 추가하거나 수정하는 데 용이합니다. 반면에 StringBuilder는 멀티스레드 환경에서 안전하지 않으므로, 동시에 여러 스레드에서 접근하거나 수정하는 것은 권장되지 않습니다.

StringBuilder의 장점

• 문자열 조작이 빠르다.
• 추가 및 수정이 용이하다.

StringBuilder의 단점

• 멀티스레드 환경에서 안전하지 않다.
• 문자열 출력 기능이 없다.

BufferedWriter

BufferedWriter는 출력 스트림에 대한 버퍼를 제공하여 문자열을 출력할 때 I/O 작업 횟수를 줄입니다. 즉, 출력 작업이 매우 빠르게 수행되며, 매번 파일에 접근하지 않고, 한 번에 많은 양의 데이터를 출력할 때 유용합니다. BufferedWriter는 멀티스레드 환경에서 안전합니다.

BufferedWriter의 장점

• 출력 작업이 매우 빠르다.
• 파일에 접근하지 않고, 한 번에 많은 양의 데이터를 출력할 때 유용하다.

BufferedWriter의 단점

• 문자열 조작 기능이 없다.

참고 자료

StringBuilder 공식문서: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StringBuilder.html

BufferedWriter 공식문서: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/BufferedWriter.html

자바로 애플리케이션 개발을 할 때 자주 사용하는 Mybatis와 CDATA에 대해 알아봅시다.

MyBatis란?

MyBatis는 SQL Mapper Framework 중 하나로, 자바 객체와 SQL문 사이의 자동 매핑을 지원합니다. 데이터베이스의 CRUD(Create, Read, Update, Delete) 작업을 간편하게 처리할 수 있도록 도와줍니다.

CDATA 태그란?

CDATA 태그는 XML 문서 안에 특수 문자를 포함시킬 때 사용됩니다. 특수 문자를 그대로 출력하게 해주는 역할을 합니다.

MyBatis에서 CDATA 태그 사용하기

MyBatis에서 SQL문을 작성할 때, 문자열 안에 특수 문자가 포함될 경우 문제가 발생할 수 있습니다. 이런 경우에 CDATA 태그를 사용하여 특수 문자를 그대로 출력할 수 있습니다.

예시

xmlCopy code

<select id="selectUserByName" parameterType="java.lang.String" resultType="User">
	SELECT * FROM users WHERE name = <![CDATA[#{name}]]> 
</select>

CDATA 태그를 사용하면 SQL문 안에서 작은 괄호(<, >)나 & 같은 특수 문자들이 자동으로 이스케이핑되지 않으므로, SQL문 작성 시 편리하게 사용할 수 있습니다.

MyBatis에서 CDATA 태그 사용 시 주의할 점

하지만 CDATA 태그를 사용할 때 주의할 점이 있습니다. 예를 들어, SQL문 안에 ]]> 문자열이 포함된 경우에는 CDATA 태그를 닫는 문자열과 혼동이 발생할 수 있습니다. 이런 경우에는 ]]>]]&gt;와 같이 문자열을 변경해 주어야 합니다.

공식문서

MyBatis 공식문서: https://mybatis.org/mybatis-3/ko/index.html

XML 이스케이핑(MyBatis 공식문서): https://mybatis.org/mybatis-3/sqlmap-xml.html#XML_Escaping

참고자료

MyBatis - SQL Mapper Framework: https://github.com/mybatis/mybatis-3

CDATA Section (MDN Web Docs): https://developer.mozilla.org/ko/docs/Web/XML/CDATA