기억을 기록하는 블로그

Apache vs Nginx

무주아빠 — Mon, 18 May 2020 16:48:00 +0900

APACHE

요청(Request)하나 당 프로세스(또는 스레드)가 처리하는 구조
즉 요청이 많을수록 CPU와 메모리사용이 증가 -> 성능 저하
서버의 프로세스가 블록킹이 되면 요청을 처리하지 못하고, 처리가 완료 될 때까지 계속 대기 하는 일이 발생
위의 문제는 Keep Alive를 활성화 함으로써 해결 가능하나, 이 때문에 대량 접속 시 효율이 급격히 떨어지는 다른 문제가 발생
Keep Alive?
- KeepAlive On -> KeepAliveTimeOut 시간동안 접속을 끊지 않고 다음 접속을 기다림
- 한 번 연결된 클라이언트와 통신을 유지하고 있기에, 다음 통신시 Connection을 생성하고 끝는 작업이 불필요
- 성능 향상을 기대 할 수 있음
- 정적 자원으로만 구성된 웹 서버에 설정시 약 50% 성능 향상이 기대 가능 하다고 함
- 단 바쁜 서버환경에서 KeepAlive On 설정시엔 모든 요청마다 연결을 유지 -> 프로세스 수 급격히 증가 -> MaxClient 초과 -> 많은 메모리 사용 -> 성능 저하
- 즉 트래픽이 적은 서버 환경에 유리
- 2.4 버전부터 Event MPM방식을 지원 => 요청을 처리하는 스레드를 따로 두어 분산된 처리를 가능하게 함

NGINX

아파치에 비해 가벼움
보안과 속도를 최적화 시키려는 노력에서 탄생
사용이 매우 심플하고 규모가 작은 서비스 + 정적 데이터 처리가 많은 서비스에 적합
프로그램 흐름이 이벤트에 의해 결정이 되는 Event Driven(비동기 이벤트 기반) 방식
즉 요청에 대한 각 상태(state)를 정해서, event가 발생하면 event를 처리
적은 수의 스레드로 효율적인 일 처리 가능 -> 스레드당 할당되는 메모리도 작음 -> context switching 비용 적음 -> cpu소모 적음
모듈 개발이 어려우며, 다양한 모듈이 없는 것이 단점
.htaccess를 지원하지 않아, ReWrite나 특정 디렉토리에만 권한부여 하는 것이 어려움

정리

Apache는 요청 당 스레드 또는 프로세스가 처리, Nginx는 비동기 이벤트 기반으로 처리
최근 대용량의 정적파일 및 큰 규모의 사이트가 많아짐에 따라 대량 접속에도 적은 리소스를 사용하며 빠르게 서비스를 할 수 있는 웹 사이트가 대세가 됨
이로인해 Nginx가 각광 받기 시작
하지만 Apache 2.4가 발표되면서 Nginx에 대응 시작
그래도 Nginx가 성능면에서는 크진 않지만 더 뛰어남
하지만 PHP모듈등을 직접 적재가능한 구조적 특징상 복잡한 사이트의 경우 Apache가 유리, 손쉬운 셋팅도 한 몫
안정성, 확장성, 호환성은 Apache가 성능은 Nginx가 우세

프로세스와 스레드

무주아빠 — Mon, 18 May 2020 16:46:01 +0900

프로세스와 스레드?

프로세스는 운영체제로부터 자원을 할당 받는 작업의 단위
스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위

좀 더 자세히...

프로세스는 실행될 때 운영체제로부터프로세서를 할당받고, 운영되기 위해 필요한 주소공간, 메모리 등의 자원도 할당받음
스레드는 하나의 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내의 주소공간, 메모리 등의 자원을 프로세스내에 스레드끼리 공유하면서 실행된다

스레드를 왜 사용해?

그러면 여러 프로세스(멀티 프로세스)를 하지 않고 굳이 하나의 프로세스안에 스레드로 나눠서 실행하는가?
운영체제는 시스템작업을 효율적으로 관리하기 위해 존재 -> 이 목적을 달성하기 위함
멀티 스레드의 장점
- 프로세스 생성, 자원 할당 이라는 시스템 콜을 줄여 자원을 효율적으로 관리 할 수 있음
- 프로세스간의 통신보다 스레드간의 통신이 비용이 적으므로 작업들간의 부담도 줄일 수 있음

그러면 멀티 스레드가 답인가?

멀티 스레드는 자원의 효율성을 증가 시켜주지만 주의할 점이 있음
스레드간 공유하는 자원은 전역변수로 사용하기에, 동기화에 신경을 써야 함 (동시에 여러 스레드가 실행되는 경우)
- 공유자원을 사용하지 않는 프로세스와 프로세스사이는 상대적으로 안전

해결방법?

한 번에 한 스레드만 공유자원에 접근할 수 있도록 조정해주면 된다
이것을 Lock이라고 하는데, 얼마나 적은 Lock을 거는가가 성능의 관건

Proxy Server

무주아빠 — Mon, 18 May 2020 16:43:12 +0900

Proxy Server

프록시 서버의 종류와 역할을 알아보자

Forward Proxy

흐름
- Client -> Proxy, FireWall -> Internet -> Server
설명
- Client을 대변한다.
- 외부로 나가기전에 Proxy를 거치므로 Client의 정보를 숨길 수 있다.
- 같은 이유를 외부를 나가는 Request를 통제 할 수 있다. (내부통신통제)
- 내부에서 외부로의 통신, Caching을 하면 성능향상 기대 가능

Reverse Proxy

흐름
- Client -> Internet -> FireWall, Proxy -> Server
설명
- Server를 대변한다.
- Target서버에 도달하기 전에 Proxy를 거치므로 Target서버의 정보를 숨길 수가 있다.
- 로드벨런스와 같이 특정 Target서버로 부하를 분산 시킬 수도 있다.

SQL vs NoSQL

무주아빠 — Wed, 13 May 2020 15:55:59 +0900

SQL vs NoSQL

둘의 차이를 비교해보자

비교

SQL	NoSQL
규칙에 맞는 데이터 입력	자유로운 데이터 입력
테이블간 JOIN 지원	컬렉션간 JOIN 미지원
트랜잭션 지원	트랜잭션 미지원
안전성, 일관성	확장성, 가용성
용어: 테이블, 로우, 칼럼	용어: 컬렉션, 도큐먼트, 필드

* 트랜잭션의 경우 몽고DB v3에는 지원하지 않으나 v4부터는 지원할 것이라고 한다

NoSQL 등장배경

지난 20년, 트랜잭션을 통한 안정적 데이터 관리가 가능한 RDB가 대세였다
WEB2.0 + 빅데이터의 등장 => 데이터 처리 비용증가로 위기가 왔다
데이터 트래픽 증가 -> 1대에서 실행되는 것으로 설계된 RDB에서는 큰 비용으로 다가옴
스캐일 아웃이아닌 스캐일 업을 해야 하기에 OMG!
NoSQL은 일관성을 어느정도 포기한 대신 데이터의 분산저장을 목표로 등장하였다

설명

RDB의 장점은 뭐니뭐니해도 트랜잭션과 관계성을 통한 데이터의 일관성보장
이를 트레이드 오프하여 확장성을 얻은 것이 NoSQL
- 다수가 동시에 읽고 쓰는 상황에서의 성능향상
- 분산 환경에서 노드 들이 잘 작동하나 시스템의 일부가 장애시 데이터베이스가 사용 불가능한 문제를 해결
RDB가 클러스터 상에서 운영을 못하는 것이 아니나, 태생적으로 효율적이지 못하다

장단비교

예를 들어 구매 내역이나 게임의 로그 같은 데이터들은 매 초마다 엄청난 양이 생성되지만 한번 저장되고 난 뒤에는 수정될 일이 거의 없다
이런 데이터들을 저장하는 데 데이터의 일관성을 보장하기 위해 ACID 트랜잭션을 지원할 필요는 없을 것이다.
거기다 생성되는 데이터의 양도 많기 때문에 장비의 성능에도 상당한 영향을 미칠 것이다. NoSQL은 이러한 데이터들을 효율적으로 저장할 수 있다.
여러 대의 장비에 빠른 속도로 저장이 가능하며, 데이터의 양이 누적되더라도 얼마든지 수평적 확장이 가능하기 때문이다.

활용예

트위터, 페이스북: 게시글 저장에 사용
- 쏟아지는 트래픽을 모두 RDB에 저장한다면, 글작성 -> 저장 까지 한 참이 소요된다
각종 검색엔진: 텍스트 형태소 분석 -> 토큰 -> 역 인덱스구조 맵핑

결론

용도에 맞게 상호보완적으로 사용해야 한다

스케일 아웃 / 스케일 업 / 로드밸런싱

무주아빠 — Wed, 13 May 2020 15:45:30 +0900

스케일 아웃, 스캐일 업, 로드밸런싱

서버 확장을 위한 방법

스케일 아웃 (Scale out)

서버를 여러 대 추가하여 시스템을 확장 하는 방법
서버가 여러대가 되기에 로드밸런싱이 필수
다중화를 통해서 서버에서 장애가 나더라도 다른 서버에서 대응이 가능
반면 모든 서버가 동일한 데이터를 가지고 있어야기야 데이터 변화가 적은 웹서버에 적합

스케일 업 (Scale up)

서버에 CPU / RAM 등을 추가하거나, 고성능의 부품, 서버로 교환하는 방법
추가적으로 장비를 장착한 여유 슬롯이 있어야 하며 그렇지 않으면 서버 자체를 교환해야 한다
스케일 업의 경우 모든 부하가 서버 한 대에 집중되므로 장애시 위험하다
모든 데이터를 한 곳에서 처리하므로 데이터 갱신이 빈번하게 일어나는 데이터베이스 서버에 적합

로드밸런서의 주요기능

NAT: 사설 IP 주소를 공인 IP 주소로 바꾸는데 사용하는 통신망 주소 변조기
DSR: 서버에서 클라이언트로 돌아가는경우, 목적지 주소를 스위치 IP 주소가 아닌, 클라이언트의 IP 주소로 전달하여 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념
Tunneling: 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념
데이터를 캡슐화해서 연결된 상호간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다
주의 할 점
- 매 요청마다, 다른 서버로 접근하기에 정보 일관성 유지가 어렵다 (세션 등)
- 세션 고정이 필요, 특정 사용자의 요청이 전달될 노드를 고정하는 방법이 있지만, 해당 노드가 장애시 무용지물

로드밸런서의 종류

L2: Mac주소를 바탕으로 로드밸런싱
L3: IP주소를 바탕으로 로드밸런싱
L4: Transport Layer(IP와 Port) 레벨에서 로드밸런싱, (TCP, UDP)
L7: Application Layer(사용자의 Request) 레벨에서 로드밸런싱, (HTTP,HTTPS, FTP)

밸런싱 방법

Round Robin: 한 번씩 돌아가며 선택, 가장 일반적인 방법
Least Connections: 연결 개수가 가장 적은 서버를 선택, 세션이 길어지는 경우 권장
Source: 사용자의 IP를 해싱하여 분배, 사용자는 항상 같은 서버로 연결되는 것을 보장

2019 KAKAO BLIND RECRUITMENT - 실패율

무주아빠 — Fri, 17 Apr 2020 23:40:14 +0900

풀기전에

처음으로 회사에서 출제되는 문제를 풀어 보았다.

프로그래머스에서 보여지는 난이도는 Level1 이라고 되어 있지만, 왠지 모르게 쫄아서 피했던것 같다.

문제가 꽤나 재미있다. 진짜로 있을 것 같은 케이스라고 할 까?

게임에 있어서 각 스테이지의 실패율을 구하는 문제인데 나는 아래와 같이 풀었다.

def solution(N, stages):
    answer = [0] * N
    counters = dict()

    for i in stages:
        counters[i] = counters.get(i, 0) + 1

    for k, v in counters.items():
        i = 1
        while k > i:
            answer[i-1] += v
            i += 1

    people = len(stages)
    for i in range(len(answer)):
        tmp = answer[i]
        answer[i] = (i + 1, 0) if people == 0 else (i + 1, (people - answer[i]) / people)
        people = tmp

	
    answer = sorted(answer, reverse=True, key=lambda stage: stage[1])
    answer = [stage[0] for stage in answer]

    return answer

풀고난 후

생각보다 어렵지 않아서 재미있게 풀었던 문제. 덕분에 자신감도 생겼다.

앞으로도 하나씩 도전해야지.

[도쿄-에비스] - 루파바 Rue Favart

무주아빠 — Wed, 11 Mar 2020 00:37:48 +0900

건물 외관

다녀온 지는 꽤나 시간이 흘렀지만, 블로깅 해야겠다 싶어서 사진을 찍어 두었다.

아직 날이 추웠던 2월, 콧바람도 쐴겸 에비스로 향했다. 지인의 소개로 알게된 이곳 루파바(Rue Favart).

에비스 가든 플레이스 출구로 나와서 왼쪽으로 길을 따라 걷다보면 큰 사거리가 나오는데, 그곳에 딱 하니 자리 잡고 있다. 타베로그에서도 나쁘지 않은 평을 받고 있는 곳이다.

타베로그 정보

현관 앞

신호등을 건너고 이윽고 도착한 식당앞에서 나는 메뉴판을 발견 할 수 있었다.

오늘의 메뉴

런치메뉴의 구성은 다음과 같다.

고기요리: 돼지고기 등심 소테(*버터를 발라 살짝 지진 고기), 홀그레인 머스타드 소스, 1000엔, 곱배기는 1600엔
생선요리: 도미 뫼니에르(*생선에 밀가루에 버터를 발라 구운 생선), 풍부한 향의 버터 소스, 1000엔
파스타: 조개 우엉 파스타
리조또: 관자 크림 리조또
덮밥: 돼지고기와 아보카도를 곁들인 덮밥 또는 돼지고기 숙주볶음 덮밥

파스타, 리조또, 덮밥에는 샐러드가 포함 되어 있고, 모든 메뉴가 주문시에 식전빵, 야채스프, 애플민트 티, 식후 미니 디저트가 제공된다.

같이 간 지인에 의하면 다른 메뉴는 모르겠으나 고기요리는 항상 고정메뉴(테방)인 것 같다고 하였다.

식당 1층은 디저트가 진열되어 판매중이었고, 나는 3층으로 안내받아 이동하였다.

식당 내부

내부 인테리어도 유럽 느낌이 물씬나는 분위기에 색으로 꾸며져 있다. 이곳에서 햇살 좋은 날에 창가쪽에 앉아 좋은 사람과 함께하는 식사는 선물과도 같은 시간이 될 것이다.

주문한 메뉴는

돼지고기 등심 소테 곱배기 (하나는 양이 작을 것 같아서...)
관자 크림 리조또

애플민트티

기본으로 제공 되는 서비스 구성

먼저 식전빵과 애플민트티, 야채스프를 제공 받았다. 식전빵은 진짜 담백한 맛이 너무 좋았다.

리필이 된다기에 3번을 추가로 제공 받았다.

돼지고기 등심 소테

관자 크림 리조또

메인요리인 돼지고기 등심 소테와 관자 크림 리조또가 나왔다.

훌륭한 돼지고기 스테이크와 일본에와서 먹을기회가 좀 처럼 없었던 크림 리조또였다.

곱배기를 시키길 잘 했다. 기본은 아마 한 덩이가 나왔을 텐데, 부족했을거라 생각한다.

탄성을 자아낼 정도의 훌륭한 맛은 아니었지만, 가게 분위기와 어우러져 충분하고 훌륭했다.

쁘띠 슈

1층에서 디저트류를 판매하는 것으로 보아, 기본적으로 이곳은 차와 디저트를 메인으로 하는 것 같은 느낌이 들었다.

후식으로 제공된 미니 디저트도 양은 적었지만, 메인요리로 어지럽혀진 입맛을 깔끔히 정리해주기엔 부족함이 없었다.

다시 한 번 생각날 것 같은 분위기와 맛이었다. 다음에는 꼭 햇살 좋은날, 창가쪽자리의 행운이 함께하기를!

홈페이지: http://www.ruefavart.com/

[도쿄-도쿄역] - 울프강 스테이크 하우스

무주아빠 — Mon, 27 Jan 2020 01:35:51 +0900

현관 간판

이른바, 뉴욕 3대 스테이크(킨스, 피터 루거, 울프강 스테이크) 중 하나라는 울프강 스테이크 하우스, 도쿄 마루노우치점에 다녀 왔다.

얼마 전 쯔양(유투버)이 가서 모든 스테이크를 클리어 했던 동영상을 봤던지라 더더욱 흥미가 있었던 곳이다.

드레스코드를 지키지 않으면 입장거절 당할 수 도 있다는 정보가 있었기에 간만에 구도도 신고 갔다.

주문한 메뉴는

울프강 샐러드
스테이크 포 투 (stake for two)
랍스타 맥앤치즈

그리고 뉴턴 클라렛 레드 와인을 주문 했다.

먼저, 식전빵이 나왔고 식전빵은 구운양파맛 빵, 일반 바게트, 호두빵이 버터와 함께 나왔다.

맛있었다. 필요하면 리필도 가능했다.

뉴턴 클라렛

와인 맛은 강하고 달달한 맛이 났다. 육류와 어울렸다.

울프강 샐러드

울프강 샐러드, 이름을 보고 시그니처인가 해서 시켰다. 맛은 역시나 훌륭.

간이 되어 있는 구운 고기와 데친 새우, 토마토, 양파 그리고 상큼한 지중해풍 소스의 조화가 좋았다.

스테이크 포 투

티본 스테이크 인것 같다. 등심, 안심 모두 같은 굽기로 굽기가 쉽지 않은데 같은 굽기(미디엄 레어)로 훌륭하게 구워냈다.

셋팅

스테이크가 나오면 직원분이 이렇게 등심, 안심 한 점씩 셋팅을 해준다. 그리고 고기가 비어 있을떄 마다 수시로 다시 셋팅해준다. 테이블에 배치되어 있는 울프강 올드 패션 소스와의 궁합도 아주 좋았다.

랍스타 맥앤치즈

개인적으로 맥앤치즈 덕후라서 주문했다. 랍스타와 맥앤치즈라니, 생각도 못한 조합에 크림 스피니치를 포기하고 선택했다. 후회 없는 선택.

일본에 와서 처음으로 가본 고급 스테이크 하우스. 피렌체에서 먹었던 티본 스테이크를 갱신하는 맛이었다.

랍스타 맥앤치즈도 새로운 경험을 선물해줬다.

기념일이나, 가족들과 함께 좋은 시간을 가지고 싶을때 다시 찾을 듯 하다.

아파치(Apache)인증 설정 (Basic, Digest)

무주아빠 — Wed, 23 Oct 2019 17:25:20 +0900

특정 디렉토리에 접근을 제한하기 위한 방법으로 아파치 인증을 설정할 수 있습니다.

Basic, Digest 이 두가지의 방식을 소개합니다.

기본설명

아래의 사진과 같이 특정 디렉토리/URL에 접근을 제어할 수 있도록 해주기 위한 방법을 소개하겠습니다.

Basic 인증의 예

Basic

말그대로 기본적인 방법으로 인증을 요구하는 방식입니다. 간단한 방법/방식(Base64) 때문에 보안수준은 낮은편이나 간단하다는 장점이 있습니다.
.htaccess 를 기준으로 예시를 작성하겠습니다.

AuthType Basic                                    # 인증방식
AuthName Guest                                    # 영역(realm)을 지정합니다. 한 번 인증된 영역은 다시 묻지 않습니다.
AuthUserFile /usr/apache/passwd/.htpasswd         # 인증 ID/PW정보가 담긴 파일위치
require user rbowen                               # 사용자 지정

.htpasswd생성방법 [Basic]

htpasswd [FilePath] [UserName]

$ htpasswd -c /usr/apache/passwd/.htpasswd rbowen       # -c는 새롭게 생성한다는 의미, 첫 회에만 필요
New password:                                           # user에 설정할 패스워드 입력
Re-type new password: 
Adding password for user rbowen

Digest

Basic인증보다 보안수준이 나은 MD5 Hash를 통해 저장하는 방식을 사용합니다.
사용하기 위해서는 mod_auth_digest모듈(Module)이 필요합니다. 없는 분들은 httpd.conf파일에 아래의 내용을 추가해 주세요.

LoadModule auth_digest_module modules/mod_auth_digest.so

준비가 되었다면 본격적으로 설정에 들어가겠습니다.

AuthType Digest
AuthName Guest                                        # htdigest 실행시 Realm과 일치해야한다.
AuthUserFile /usr/apache/passwd/.htpasswd
require valid-user                                    # valid-user는 누구라도 ID/PW만 맞다면 허용하겠다는 의미

.htpasswd생성방법 [Digest]

htdigest [FilePath] [Realm] [UserName]

$ htdigest -c /usr/apache/passwd/.htpasswd Guest rbowen   # -c는 새롭게 생성한다는 의미, 첫 회에만 필요
New password:                                             # user에 설정할 패스워드 입력
Re-type new password: 
Adding password for user rbowen

구글 드라이브로 이미지 호스팅하기

무주아빠 — Tue, 22 Oct 2019 01:32:04 +0900

블로그를 시작하면서 이미지를 호스팅하는 방법에 대해 고민했는데요.
이것저것 시도해본 결과 무난히 사용가능 했던 구글 드라이브를 소개합니다.

설명

블로그를 시작하면서 보다 효과적으로 컨텐츠정보를 전달하기 위해서는 이미지가 필요했습니다.
하지만 이미지를 파일째로 소스코드에 올리는 것은 페이지 로딩에도 좋지 못할 뿐더러 불필요한 용량을 차지하게 되죠.
보통의 개발환경이라면 NFS서버나 이미지 서버를 따로 두어 관리하는데요, 블로그 하나 하자고 서버를 설치하는 것은 배보다 배꼽이 크겠죠?!
그래서 다들 어떻게 하고있나 찾아본 결과 이런 저런 방법이 있었지만, 클라우드를 이용하는 방법이 간편해 보여서 이용하게 되었습니다.

요즘에는 모두 dropbox나 google drive같은 클라우드 스토리지 하나씩은 가지고 있을 것입니다.
이번 포스팅에서는 그 중 구글 드라이브를 이용하여 이미지를 호스팅하는 법에 대해 포스팅하고자 합니다. (참고로 구글 포토는 안되더라구요!ㅠㅠ)

방법

구글 드라이브에 사진을 업로드 합니다.
업로드한 사진에 오른쪽 마우스를 클릭하고 아래의 사진과 같이 공유 가능한 링크를 가져온다. (자동으로 클립보드에 복사됨)
공유 설정을 모든 사람이 볼 수 있도록 해주어야 한다.
아래의 변환 툴을 이용하여 공유가능한 링크로 이미지주소를 변환한다.
이미지를 넣고자하는 태그의 src 속성에 변환한 이미지주소를 기입한다.

공유 가능한 링크 가져오기 클릭!

변환 툴

Google Drive Path

Linkable Image Path

Preview Image

변환 툴 설명

원리는 매우 간단하다. 위의 방법에서 `2번`을 통해 취득한 링크부분에서 `open?`을 `uc?export=view&`로 치환하는 방식이다.