Education*
Devops
Architecture
F/B End
B.Chain
Basic
Others
CLOSE
Search For:
Search
BY TAGS
linux
HTTP
golang
flutter
java
fintech
개발환경
kubernetes
network
Docker
devops
database
tutorial
cli
분산시스템
www
블록체인
AWS
system admin
bigdata
보안
금융
msa
mysql
redis
Linux command
dns
javascript
CICD
VPC
FILESYSTEM
S3
NGINX
TCP/IP
ZOOKEEPER
NOSQL
IAC
CLOUD
TERRAFORM
logging
IT용어
Kafka
docker-compose
Dart
Amazon Route 53 Cheat Sheets
Recommanded
Free
YOUTUBE Lecture:
<% selectedImage[1] %>
yundream
2023-06-14
2022-10-27
2674
## DNS DNS는 Domain Name System의 줄임말로 "도메인이름을 IP주소로 변환하는 일"을 하는 분산 시스템이다. 이 시스템은 결국 도메인이름과 IP 정보를 저장하고 있는 데이터베이스인데, 도메인 이름과 IP의 맵핑 정보를 저장하고 있다가 사용자 요청을 받아서 IP를 찾아서 응답하는 일을 하는 서버를 네임서버(Name Server)라고 한다. #### DNS Hierarchy 인터넷은 공공기관, 교육기관, 연구소, 기업, 개인 등 수많은 서비스들이 연결되어있다. 이들은 모두 도메인 이름을 가지기 때문에 DNS는 계층 구조를 만들어서 이들을 효과적으로 관리한다. ![DNS Hierarchy](https://docs.google.com/drawings/d/e/2PACX-1vRjFaei90ktnMp8EXHmcBt0o3QDAqFW5A7QgKYiFs-QC9Gwl8pg16KffuZdSxDP1NDETw2NJLjm1mia/pub?w=866&h=417) 이렇게 계층 구조를 만들면 각 계칑의 서버는 바로 밑에 있는 하위 계층의 이름만 관리하면 되므로 대량의 도메인 이름을 효과적으로 관리할 수 있다. * Root Domain: 인터넷 도메인 체계에서 최상위다. 인터넷 도메인의 뿌리다. * TLD: DNS 계층 구조에서 루트 서버보다 한 단계 아래에 있다. '.org', '.com', '.edu'등이 있다. 최상위 도메인이라고도 부른다. * SLD: 차상위 도메인이라고 부른다. ![Domain](https://docs.google.com/drawings/d/e/2PACX-1vRXL4L8czTrNkChukVt10pxBBzV0QhSc9xAvyH8zFkffJbhAnibdI8c2VVCIca3v4pXvug-Np6Zl-px/pub?w=845&h=274) ## Amazon Route 53 Amazon Route 53은 고가용성(High available), 확장성(Scalable)을 가진 DNS(Domain Name System) 서비스다. Amazon Route 53의 핵심 기능은 아래와 같다. 1. Domain Name 등록 : 도메인 이름을 구매하고 관리 할 수 있다. 2. DNS resolution 3. AWS 리소스에 대한 Health Check Public DNS 레코드를 생성하고 관리할 수 있다. DNS는 인터넷의 전화번호부 역할을 한다. 전화번호부와 마찬가지로 도메인 이름으로 IP 주소를 관리 할 수 있게 해준다. 즉 www.joinc.co.kr 과 같은 특정 도메인 이름이 192.168.0.4와 같은 IP주소로 변환 할 수 있다. ## Route 53의 작동 방식 기본적으로 DNS 서버의 작동방식과 동일하다. ![Route 53 작동 원리](https://docs.google.com/drawings/d/e/2PACX-1vQicJcreezHTj8fmtrTz0SevQoS9q-YhtT5ZOulZNScpHH8vAVWu18cttEJWJCnQBsqRLq9Sig5NwAA/pub?w=882&h=699) 1. 사용자가 웹 브라우저에 www.example.com 을 입력한다. 2. 브라우저는 www.example.com 에 대한 IP 주소를 요청한다. 이 요청은 DNS resolver로 전달된다. * DNS resolver는 클라이언트 대신에 도메인 이름 질의를 한다. 또한 자주 사용하는 도메인 이름은 캐시(cache)하고 있다가 바로 리턴한다. 지금은 프로세스를 확인하는게 목적이므로 캐시하고 있지 않다고 가정한다. 3. DNS resolver는 root name server에 .com을 관리하는 TLD name server의 IP를 요청한다. 4. DNS resolver는 .com을 관리하는 TLD 서버에 example.com 을 관리하는 SLD 서버의 IP를 요청한다. 5. DNS resolver는 example.com을 관리하는 SLD 서버에 www.example.com 의 IP를 요청한다. 6. www.example.com 의 IP인 192.0.2.44를 리턴한다. 7. DNS resolver는 192.0.2.44를 웹 브라우저에 리턴한다. 8. 웹 브라우저는 192.0.2.44 로 연결한다. 참고로 root name server는 13개가 존재하며 dig를 통해서도 확인 할 수 있다. ```text $ dig . NS . 1 ↵ ; <<>> DiG 9.18.12-1ubuntu1-Ubuntu <<>> . NS . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36154 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 432588 IN NS k.root-servers.net. . 432588 IN NS b.root-servers.net. . 432588 IN NS j.root-servers.net. . 432588 IN NS d.root-servers.net. . 432588 IN NS h.root-servers.net. . 432588 IN NS f.root-servers.net. . 432588 IN NS m.root-servers.net. . 432588 IN NS e.root-servers.net. . 432588 IN NS i.root-servers.net. . 432588 IN NS c.root-servers.net. . 432588 IN NS a.root-servers.net. . 432588 IN NS l.root-servers.net. . 432588 IN NS g.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 576039 IN A 198.41.0.4 b.root-servers.net. 552443 IN A 199.9.14.201 c.root-servers.net. 552442 IN A 192.33.4.12 d.root-servers.net. 250540 IN A 199.7.91.13 e.root-servers.net. 590080 IN A 192.203.230.10 f.root-servers.net. 552443 IN A 192.5.5.241 g.root-servers.net. 424963 IN A 192.112.36.4 h.root-servers.net. 572455 IN A 198.97.190.53 i.root-servers.net. 585048 IN A 192.36.148.17 j.root-servers.net. 547427 IN A 192.58.128.30 k.root-servers.net. 552448 IN A 193.0.14.129 l.root-servers.net. 585594 IN A 199.7.83.42 m.root-servers.net. 500683 IN A 202.12.27.33 ``` ## Route 53 주요 특징 * Route 53은 전 세계적으로 분산된 DNS 서비스를 제공한다. * Route 53은 모든 edge location에 위치한다. 즉 클라이언트와 위치적으로 가까운 곳에 위치함으로 빠르게 DNS 질의에 응답 할 수 있다. * Health Check 기능을 이용해서 연결된 리소스가 사용 가능한지를 체크할 수 있다. 이를 이용해서, 사용 가능한 서비스로 고객을 보낼 수 있다. * AWS는 도메인 등록을 대행하며, Route 53을 이용해서 도메인을 구매 / 등록할 수 있다. * Route 53은 다른 도메인 등록 대행사를 통해 등록된 도메인을 관리 할 수 있다. * Route 53에 도메인을 등록하면 사용자가 관리 할 수 있는 Public Hosting 영역이 생성된다. * DNS 레코드는 TTL(Time to Live) 값을 가진다. 이로 인해 최대 48시간 동안 변경된 레코드 정보가 적용되지 않을 수 있다. * Route 53으로 등록한 도메인을 다른 대행사로 이전 할 수 있다. 이 경우 AWS 지원이 필요하다. * 다른 AWS 계정으로 도메인을 이전 할 수 있다. * TCP와 UDP(53번 포트)를 모두 사용 할 수 있다. 일반적으로 UDP 를 주로 사용한다. * AWS는 Route 53에 대해서 100%의 SLA를 제공한다. * DNS는 Private와 Public을 생성 할 수 있다. Public의 경우 DNS 레코드가 인터넷에 노출되지만 Private는 인터넷에 노출되지 않는다. Private는 주로 내부 리소스 관리 목적으로 사용한다. ## Records 기본적으로 DNS는 도메인 이름과 IP를 관리하는 데이터베이스 시스템이다. 레코드는 관리하려는 데이터인 도메인 이름, IP 등에 대한 정보들을 담고 있는 중요한 구성요소로 특히 DevOps / 클라우드 엔지니어라면 반드시 숙지하고 있어야 한다. * A Record : IPv4 타입의 인터넷 주소를 도메인이름으로 연결 할 수 있다. ``` 192.168.2.1 ``` * AAAA Record : IPv6 타입의 인터넷 주소를 도메인이름으로 연결 할 수 있다. ``` 2001:0db8:85a3:0:0:8a2e:0370:7334 ``` * CNAME Record : CNAME 레코드는 acme.example.com과 같은 도메인이름을 다른 도메인이름으로 연결하기 위해서 사용한다. ELB 혹은 CloudFront의 경우에는 AWS에서 관리하는 독자적인 도메인이름으로 관리된다. 이 도메인이름을 고객이 관리하는 도메인이름으로 연결하기 원할 때 주로 사용한다. ``` hostname.example.com ``` * DS Record : DS(Delegation Signer)는 **위임에 대한 서명자**라는 의미를 가지고 있다. DS 레코드는 자식 도메인 존의 DNSKEY 레코드의 해시 값을 가지고 있어서 해시값을 이용 자식 도메인 존의 DNSKEY 레코드가 DS 레코드의 해시 값과 일치하는지 여부를 인증/확인 할 수 있다. * MX Record : 메일서버의 이름을 지정하고 두 개 이상의 메일 서버가 있는 경우 우선순위를 설정 할 수 있다. MX Record는 우선순위와 도메인 이름 두가지 값을 포함한다. ``` 10 mail.example.com ``` * NAPTR Record : DNS에 여러 서비스를 등록할 수 있다. DNS의 탐색 기능을 이용해서 SIP와 같은 서비스를 관리하려는 목적으로 사용한다. * NS Record : Hosted Zone의 네임서버 값을 설정한다. Hosted Zone을 생성하면 기본 4개의 NS Record가 만들어진다. ``` ns-1.example.com ``` * PTR Record : IP 주소에 연결된 도메인이름을 제공한다. PTR 레코드를 통해서 수신 메일 서버는 해당 IP 주소가 서버가 연결하는 이름에 해당하는지 여부를 확인하여 전송 메일 서버의 진위를 확인 할 수 있다. * SOA Record : SOA(Start of authority)는 Hosted Zone에 대한 정보를 제공한다. 여기에서 제공하는 정보는 다음과 같다. * SOA 레코드를 생성한 Route 53의 Name Server (ex: ns-2048.awsdns-64.net) * 관리자의 이메일 주소 (ex: hostadmin.example.com) * Record를 업데이트 할 때마다 증가되는 값. 기본 값은 1이다. * Record 업데이트를 확인하기 위한 새로 고침 시간이다. 기본 값은 7200 초이다. ``` ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400 ``` * SPF Record : 도메인을 대신하여 이메일을 보낼 수 있는 모든 승인된 호스트 이름 또는 IP 주소의 목록이다. * SRV Record : 우선순위, 가중치, 포트 및 도메인 이름을 나타낸다. * TXT Record : 도메인에 대한 추가적인 텍스트 정보를 포함한다. | CNAME Record | Alias Record | |-----------------------------------------------|-------------------------------------------------| | Zone apex와 동일한 CNAME Record를 생성할 수 없다. | Zone apex와 동일한 alias record를 생성 할 수 있다. | | CNAME 쿼리에 대한 요금을 부과한다. | Alias 쿼리에 대한 요금을 부과하지 않는다. | | DNS Record로 리다이렉션 할 수 있다 | 선택한 AWS 리소스로만 리다이렉션 할 수 있다. | | dig 또는 nslookup 쿼리에 대해 CNAME으로 나타난다. | dig 또는 nslookup에 대해서 A, AAAA 로 나타난다. | ## Hosted Zone * Hosted Zone은 도메인 관리 영역으로 도메인에 대한 레코드를 관리 할 수 있다. 기존 DNS Zone file 영역과 유사하다. 기존에는 전문 시스템 관리자가 DNS Zone file을 직접 수정해야 했으나, Route 53에서는 Web UI 기반으로 쉽게 관리 할 수 있다. * 2가지 타입의 Hosted Zone이 있다. * Public hosted zone : 인터넷으로 부터의 요청을 라우팅한다. * Private hosted zone for VPC : VPC 내부에서 발생하는 요청을 라우팅 한다. 보통 VPC 내부에서 사용하는 리소스를 라우팅하기 위해서 사용한다. * Hosted Zone을 생성하면 자동으로 Name Server(NS)와 Start of Authority(SOA)를 설정한다. ![Hosted Zone NS and SOA](https://docs.google.com/drawings/d/e/2PACX-1vRlug7C_bWOIlQmcP9uAeI8jUwb74frqoKe69gC-14IQMpDdfB8W1CkARWjP3b7zFS1ggGWdvadXcib/pub?w=564&h=390) * Hosted Zone을 생성하면 4개의 Name Server 세트를 생성하여 Name Server의 가용성을 제공한다. * 관리자는 dig나 nslookup등을 이용해서 도메인 이름이 성공적으로 설정됐는지 테스트 할 수 있다. ## Health Checks AWS 에서는 가용성을 위해서 웹 서버(EC2 인스턴스) , 데이터베이스, 정적 데이터 스토리지에 대해서 동일한 기능을 사용하는 둘 이상의 리소스를 배포하는게 일반적이다. 만약 이들 리소스 중 하나에 장애가 생겼다면, 장애가 생긴 리소스로는 트래픽을 보내지 않고, 정상적인 리소스로만 트래픽을 보내야 할 것이다. 이를 위해서는 리소스에 대한 상태체크가 필요한데 Route 53을 이용해서 상태확인과 장애조치를 할 수 있다. ![route 53 장애조치와 health checks](https://d1tcczg8b21j1t.cloudfront.net/strapi-assets/32_Route_53_health_checks_12_317621ea21.png) Route 53은 endpoint의 상태를 체크한다. 만약 문제가 발생했다면(HTTP Status Code가 200~300이 아니라거나, 특정 문자열을 포함하지 않은 등), Failover 조치를 한다. 그리고 SNS(Amazon Simple Notification Service)를 이용해서 이를 관리자 등에게 통지한다. * Route 53은 3가지 유형의 Health Check를 사용 할 수 있다. 일반적으로 Endpoint 유형을 주로 사용 한다. * Endpoint * Status of the health checks(calculated health check) * State of CloudWatch alarm * Endpoint health check : IP주소 또는 도메인이름으로 지정된 endpoint를 모니터링 하도록 구성 할 수 있다. 지정한 시간 주기로 요청을 애플리케이션, 서버, ELB 혹은 기타 리소스에 전송하고 응답을 검토해서 기능이 제대로 작동하는지 확인한다. * Status of other health checks : 이미 설정된 여러개의 health check 모니터 값을 조합하여 정상여부를 확인한다. * Amaozn CloudWatch alarm health checks : CloudWatch Alarm을 통해서 health checks를 수행할 수 있다. 이 유형의 Route 53 Health Check는 CloudWatch 데이터 스트림을 모니터링하여 상태를 확인한다. * 아래 유형의 Health check를 만들 수 있다. * HTTP : 리소스에 HTTP 요청을 전송한다. HTTP Status Code가 200 이상 300미만이라면 성공으로 처리한다. * HTTPS : 리소스에 HTTPS 요청을 전송한다. HTTP Status Code가 200이상 300미만이라면 성공으로 처리한다. * HTTP_STR_MATCH : 리소스에 HTTP 요청을 전송하며, 응답 본문(Body)의 처음 5,120 바이트에 일치하는 문자열이 있는지를 확인한다. 일치하는 문자열이 있다면 성공으로 처리한다. * HTTPS_STR_MATCH : 리소스에 HTTPS 요청을 전송하며, 응답 본문(Body)의 처음 5,120 바이트에 일치하는 문자열이 있는지를 확인한다. 일치하는 문자열이 있다면 성공으로 처리한다. ## Routing Policies Route 53은 유저가 도메인 이름을 제출 했을 때, 어디로 보내야 할지(Routing)를 알려주는게 가장 중요한 기능이다. Route 53은 유저를 최적의 리소스로 보내기 위한 7 개의 라우팅 정책(Routing Policies)을 제공한다. ![Routing policies](https://docs.google.com/drawings/d/e/2PACX-1vSkEJLl1QRxJ8VkOcP833LmcFckH2pCPinHXlReHfQa6pIxuDp0CZbheXe2edeIir7L9fPRfktl_znH/pub?w=818&h=796) ### Simple routing 가중치, 지연시간, 위치와 같은 특별한 기능을 제공하지 않고 **단일 리소스(로드배런서, IP)** 로 트래픽을 라우팅한다. 가장 많이 사용하는 정책이다. ![Simple routing](https://docs.google.com/drawings/d/e/2PACX-1vRLB-ULbeykErLUsetoAEA2MdP-GksB-w5Egd1xZW9_aLq_rysZmRL6wtKK7Niz739nAI1ZoQThwox_/pub?w=1088&h=662) Value에 하나 이상의 리소스를 입력하면 된다. ![Simple routing](https://docs.google.com/drawings/d/e/2PACX-1vSPdhKmIeYOOVT_WxDdmSXjsNkxalMbYV-NFQSCLa1lvEnGM03reH8gPq2L0G6F2WYKlDul7S9tWpi4/pub?w=676&h=514) ### Weighted routing 가중치 기반 라우팅(weighted routing)를 이용하면, 리소스로 라우팅되는 비율을 설정할 수 있다. 예를 들어서 서울리전과 도쿄리전에서 서비스를 하고 있다고 가정해 보자. 관리자는 서울리전:도쿄리전=3:7과 같은 방식으로 가중치를 줄 수 있다. 그러면 트래픽의 70%가 도쿄리전으로 향하게 된다. ![Weighted routing](https://docs.google.com/drawings/d/e/2PACX-1vRdD_7ZoBCQXb5k7AEO7S_ycOST6uY6vjBp9fjlGx-HWlWxBe431huYAN90D2KWSjUD7GQlOc74T7Rc/pub?w=810&h=758) * Simple routing와 비슷하지만 각 레코드별로 가중치를 설정할 수 있다. * 가중치가 0일 경우 트래픽을 라우팅하지 않는다. ![Wight routing](https://docs.google.com/drawings/d/e/2PACX-1vQlBaiw0LC18bfDP6cv_whnN419vFJokOW1qoC0X27Ftaq4Zb0XKYE_34I1YmDxKFqOAnfUZYsymZIt/pub?w=557&h=346) ### Latency Routing ![Latency Routing](https://docs.google.com/drawings/d/e/2PACX-1vTusw_1qPIAhj7sqIkcRy4BnS5b_Ql0byMYpVEEo2jr2ovHtTtcBfanGQvy9BVYWwKXO3MjKfs-8giI/pub?w=826&h=756) AWS는 전 세계의 여러 지역에서 자신들의 클라우드 데이터센터로의 지연시간을 관리하고 있다. 이 데이터를 이용하여 최적의 지연시간을 가진 리소스로 요청을 라우팅 할 수 있다. * 지연시간이 짧은 곳으로 트래픽을 라우팅한다. * AWS Route 53은 여러 위치에서 리소스에 대한 지연시간을 기록하고 있다. 아래 이미지는 Route 53의 Latency Routing 정책 구성을 보여주고 있다. ![Latency Routing](https://docs.google.com/drawings/d/e/2PACX-1vRdNhalTRtvU2uj6lRfAKUz_BexiTTPBNyiwmMHj59qeLqvrla2kOoCX42_XhQsPjMdRRe3gvYOFVuP/pub?w=874&h=626) ### Geolocation routing 사용자의 위치에 기반하여 트래픽을 라우팅한다. ![geolocation](https://docs.google.com/drawings/d/e/2PACX-1vT3ita-Whyl_0xMdLqLyA5QC8dgucQ5JJfRjnYPnjoGyA1y_48nvVGXoWg8KJmq9nN8B5EpbTDs9Wap/pub?w=860&h=622) * 다양한 국가, 언어를 수용 할 수 있다. * 특정 지역에 있는 사용자를 위한 리소스로 라우팅 할 수 있다. * 지역간에 균등하게 부하를 분산하는데 사용 할 수 있다. * 위치는 IP를 기반으로 판단한다. 지리적 위치에 맵핑되지 않는 IP주소를 위한 기본 레코드를 생성 할 수 있다. ## Traffic Flow Traffic Flow는 Route 53에서 제공하는 GTM(Global Traffic Management)서비스다. 관리자는 failover, geolocation routing과 같은 라우팅 정책을 조합하여서 정교한 라우팅 정책을 구현할 수 있다. * GUI 편집기인 Visual Editor를 이용해서 정교한 라우팅 정책을 쉽게 생성할 수 있다. * 정책 버전관리를 이용해서 다양한 버전의 정책을 효과적으로 관리 할 수 있다. * 지리근접 라우팅 정책은 Traffic Flow에서만 사용 할 수 있다. 지리 근접 라우팅을 사용하면 리소스 위치를 기반으로 라우팅하고 선택적으로 한 위치의 리소스에서 다른 위치의 리소스로 트래피글 이동할 수 있다. ## Route 53 Resolver ![Route 53 Resolver](https://docs.google.com/drawings/d/e/2PACX-1vQHiP99i7YDDdL3_FPCHWAUpgj0UK6lWMpGeQgPKqfQV9ISWUNJ8blm_heNe68hajctRJOoEBhVqEnr/pub?w=542&h=654) Route 53 Resolver는 **모든 Amazon VPC에서 기본제공되는 Amazon DNS 서버**다. 예를 들어 10.0.0.0/16 VPC 네트워크를 만들었다면 DNS 서버는 10.0.0.2에 위치한다. 이런 이유로 ".2 resolver"라고 부르기도 한다. Route 53 Resolver는 VPC 내의 AWS 리소스에서 발생하는 DNS 레코드, 퍼블릭 DNS 레코드, Route 53 private hosting 영역에 대한 DNS 쿼리에 응답한다. * Resolver는 region 단위로 작동한다. * AWS VPC 클라우드 네트워크와 On-Premise 네트워크로 구성되는 하이브리드 클라우드 환경에서 원할한 DNS 질의를 수행하기 위해서 주로 사용한다. * intounb and outbound, inbound only, outbound only 의 3가지 타입이있다. * Inbound는 온-프레미스 혹은 다른 VPC에서의 DNS 질의를 처리하기 위한 endpoint다. * Outbound는 특정 VPC에서 외부 도메인에 대한 질의를 처리하기 위한 endpoint다. * Route 53 Resolver DNS Firewall를 이용해서 악성 도메인 질의를 차단하고 신뢰할 수 있는 도메인 질의를 허용할 수 있도록 정책설정을 할 수 있다. ## ELB와의 통합 ![ELB & Route 53](https://docs.google.com/drawings/d/e/2PACX-1vQL37DhoMIJxNE6jeWvfkM7YITHy1z8lOFBTXQcVq6eDp1mP_TpXTNupACDgeNys0aDgATv3BxVm6V2/pub?w=934&h=403) Route 53과 ELB 모두 AWS 자원으로 자연스럽게 연동할 수 있다. 별칭(Aliais)를 이용하면 AWS 자원을 Route 53 도메인으로 맵핑 할 수 있다. 1. Amazon API Gateway 2. Amazon VPC interface endpoint 3. CloudFront distribution 4. Elastic Beanstalk environment 5. ELB Load Balancer 6. AWS Global Accelerator accelerator 7. S3 static website 8. AWS App Sync domain name ## SSL과의 통합 Route 53으로 만든 호스트존의 도메인에 대해서 ACM(AWS Certificate Manager)로 인증서를 발급할 수 있다. 도메인에 대한 SSL 인증서를 만들 경우 도메인을 소유하고 있는지를 검증한다. Email 혹은 DNS에 특정 레코드를 삽입하는 것으로 검증한다. Route 53으로 만든 경우 ACM이 자동으로 레코드를 삽입해주기 때문에 간단하게 인증서를 발급하여 사용 할 수 있다.
Recent Posts
생성 AI 모델 Flux.1 설치 및 사용
GPT를 이용한 Reranker 테스트
5분만에 만들어보는 Streamlit 챗봇
Let's encrypt로 SSL 인증서 관리하기
Upscayl을 이용한 이미지 업스케일링
스테이블 디퓨전 설치 및 사용해보기
Elasticsearch 설치
AI / LLM에 대한 친절한 소개
SLA 다운타임 계산기
Docker로 GitLab 설치하기
Archive Posts
Tags
aws
aws cheat sheet
cloud
Copyrights © -
Joinc
, All Rights Reserved.
Inherited From -
Yundream
Rebranded By -
Joonphil
Recent Posts
Archive Posts
Tags