server { server_name test.test.co.kr; listen 80; proxy_read_timeout 3600000; proxy_send_timeout 3600000; location / { # proxy_set_header Host $host; # proxy_redirect http://localhost:3000 http://test.test.co.kr; proxy_pass http://localhost:3000; proxy_set_header Host "http://test.test.co.kr"; ..
배포 환경이 여의치 않은 경우 종종 연결 확인을 위해 일단 로컬로 붙여보자고 제안하는 경우가 있다. 어째 이럴 때마다 로그인이 종종 발목을 잡는데, 대개는 credentials 내지는 cookie 세팅이 원인이다. cookie 설정인 secure나 samesite 등은 독립된 성질이 아니라는 점이 더욱 그런 것 같다. 이 기회에 기록을 좀 해두어야겠다. secure 쿠키를 암호화된 방식으로 보낼 것인지에 대한 인자이다. 이 암호화는 SSL 계층을 통해 진행되므로, https 방식으로 통신하지 않으면 true로 설정했더라도 적용되지 않는다. 또한 sameSite=none은 secure가 true일 때만 적용된다. httpOnly 브라우저 단에서 쿠키에 접속하는 것을 제한하기 위한 설정이다. true로 설정..
프로세서나 메모리는 고장나면 정상 제품으로 변경하면 되지만, 스토리지는 고장나면 데이터 소실로 일어날 수 있다. 특히 HDD는 물리적 충격 등에 취약하므로 서버용 스토리지는 일반적으로 RAID 구성을 통해 장애 대응을 위한 대비를 구성하는 편이다. RAID 0 두 개, 혹은 그 이상의 하드디스크에 데이터를 분산하고 한꺼번에 출력, 즉, 스트라이핑. 이론적으로 하드디스크에서 읽을 수 있는 속도의 한계를 병렬 읽기를 통해 읽으므로 이론상 n배의 액세스 속도로 읽을 수 있다. 이는 내결함성을 위한 구성이 아니며 디스크 I/O 성능 개선이 목표이다. 특정 하드디스크에 문제가 발생할 경우 데이터가 분산되어 있으므로 다른 하드디스크의 데이터도 사용할 수 없게 된다. JBOD Just a Bunch of Disks...
{ "Version": "2012-10-17", "Id": "Policy1680360081176", "Statement": [ { "Sid": "Stmt1680360078784", "Effect": "Allow", "Principal": "*", "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:GetObjectAcl" ], "Resource": "arn:aws:s3:::{버킷명}/*" } ] }
