기본 설정 확인

Apache 상태 및 설정 검증

# Apache 서비스 상태 확인
sudo systemctl status apache2

# 설정 파일 문법 검사
sudo apache2ctl configtest

# 활성화된 가상호스트 목록 확인
sudo apache2ctl -S

# Apache 버전 확인
apache2 -v

# 로드된 모듈 확인
apache2ctl -M

필수 모듈 활성화

# 프록시 및 SSL 관련 모듈 활성화
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod ssl
sudo a2enmod rewrite
sudo a2enmod headers

# 변경사항 적용
sudo systemctl restart apache2

가상호스트 생성

1. 설정 파일 생성

# 새 가상호스트 설정 파일 생성
sudo vim /etc/apache2/sites-available/testdomain.conf

2. 기본 HTTP 가상호스트

<VirtualHost *:80>
    ServerName testdomain.com
    ServerAlias www.testdomain.com
    ServerAdmin admin@testdomain.com
    
    DocumentRoot /var/www/testdomain
    
    <Directory /var/www/testdomain>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
    
    ErrorLog ${APACHE_LOG_DIR}/testdomain_error.log
    CustomLog ${APACHE_LOG_DIR}/testdomain_access.log combined
</VirtualHost>

3. HTTP → HTTPS 리다이렉트

<VirtualHost *:80>
    ServerName testdomain.com
    ServerAlias www.testdomain.com
    
    # 모든 HTTP 요청을 HTTPS로 리다이렉트
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
    
    ErrorLog ${APACHE_LOG_DIR}/testdomain_http_error.log
    CustomLog ${APACHE_LOG_DIR}/testdomain_http_access.log combined
</VirtualHost>

4. HTTPS 가상호스트 (정적 파일)

<VirtualHost *:443>
    ServerName testdomain.com
    ServerAlias www.testdomain.com
    ServerAdmin admin@testdomain.com
    
    DocumentRoot /var/www/testdomain
    
    <Directory /var/www/testdomain>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
    
    # SSL 설정
    SSLEngine on
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/testdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/testdomain.com/privkey.pem
    
    # 보안 헤더
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header always set X-Content-Type-Options nosniff
    Header always set X-Frame-Options SAMEORIGIN
    Header always set X-XSS-Protection "1; mode=block"
    
    ErrorLog ${APACHE_LOG_DIR}/testdomain_https_error.log
    CustomLog ${APACHE_LOG_DIR}/testdomain_https_access.log combined
</VirtualHost>

다양한 설정 예제

리버스 프록시

<VirtualHost *:443>
    ServerName api.testdomain.com
    
    # SSL 설정
    SSLEngine on
    SSLProxyEngine on
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/api.testdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/api.testdomain.com/privkey.pem
    
    # 프록시 설정
    ProxyPreserveHost On
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/
    
    # 프록시 헤더 설정
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"
    ProxyAddHeaders On
    
    # 타임아웃 설정
    ProxyTimeout 300
    
    # 요청 크기 제한 해제
    LimitRequestBody 0
    LimitRequestLine 65536
    LimitRequestFieldSize 65536
    
    ErrorLog ${APACHE_LOG_DIR}/api_error.log
    CustomLog ${APACHE_LOG_DIR}/api_access.log combined
</VirtualHost>

WebSocket 프록시

<VirtualHost *:443>
    ServerName ws.testdomain.com
    
    SSLEngine on
    SSLProxyEngine on
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/ws.testdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/ws.testdomain.com/privkey.pem
    
    # WebSocket 지원을 위한 프록시 설정
    ProxyPreserveHost On
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule /(.*)           ws://localhost:8080/$1 [P,L]
    RewriteCond %{HTTP:Upgrade} !=websocket [NC]
    RewriteRule /(.*)           http://localhost:8080/$1 [P,L]
    
    ProxyPassReverse / http://localhost:8080/
    
    ErrorLog ${APACHE_LOG_DIR}/ws_error.log
    CustomLog ${APACHE_LOG_DIR}/ws_access.log combined
</VirtualHost>

여러 백엔드로 로드 밸런싱

sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

<Proxy balancer://mycluster>
    BalancerMember http://localhost:3001
    BalancerMember http://localhost:3002
    BalancerMember http://localhost:3003
    ProxySet lbmethod=byrequests
</Proxy>

<VirtualHost *:443>
    ServerName testdomain.com
    
    SSLEngine on
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/testdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/testdomain.com/privkey.pem
    
    ProxyPreserveHost On
    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/
    
    ErrorLog ${APACHE_LOG_DIR}/testdomain_error.log
    CustomLog ${APACHE_LOG_DIR}/testdomain_access.log combined
</VirtualHost>

경로별 다른 백엔드 라우팅

<VirtualHost *:443>
    ServerName testdomain.com
    
    SSLEngine on
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/testdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/testdomain.com/privkey.pem
    
    # API 요청은 백엔드 서버로
    ProxyPass /api http://localhost:8000/api
    ProxyPassReverse /api http://localhost:8000/api
    
    # 정적 파일은 직접 제공
    DocumentRoot /var/www/testdomain
    <Directory /var/www/testdomain>
        Require all granted
    </Directory>
    
    ErrorLog ${APACHE_LOG_DIR}/testdomain_error.log
    CustomLog ${APACHE_LOG_DIR}/testdomain_access.log combined
</VirtualHost>

특정 IP만 접근 허용

<VirtualHost *:443>
    ServerName admin.testdomain.com
    
    SSLEngine on
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/admin.testdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/admin.testdomain.com/privkey.pem
    
    DocumentRoot /var/www/admin
    
    <Directory /var/www/admin>
        # 특정 IP만 허용
        Require ip 192.168.1.0/24
        Require ip 10.0.0.5
    </Directory>
    
    ErrorLog ${APACHE_LOG_DIR}/admin_error.log
    CustomLog ${APACHE_LOG_DIR}/admin_access.log combined
</VirtualHost>

SSL/HTTPS 설정

Certbot으로 SSL 인증서 발급

# 자동 설정 (권장)
sudo certbot --apache -d testdomain.com -d www.testdomain.com

# 인증서만 발급 (수동 설정)
sudo certbot certonly --standalone -d testdomain.com -d www.testdomain.com

# 와일드카드 인증서 발급
sudo certbot certonly --manual --preferred-challenges dns -d testdomain.com -d *.testdomain.com

# 인증서 갱신 테스트
sudo certbot renew --dry-run

# 인증서 강제 갱신
sudo certbot renew --force-renewal

# 인증서 자동 갱신 크론잡 설정
sudo crontab -e
# 매일 새벽 2시에 갱신 확인
0 2 * * * certbot renew --quiet

SSL 설정 최적화

# /etc/letsencrypt/options-ssl-apache.conf 참고
# 또는 직접 설정

SSLEngine on
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

# OCSP Stapling 활성화
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

가상호스트 관리

활성화/비활성화

# 가상호스트 활성화
sudo a2ensite testdomain.conf

# 가상호스트 비활성화
sudo a2dissite testdomain.conf

# 기본 사이트 비활성화
sudo a2dissite 000-default.conf

# 설정 적용 (다운타임 없음)
sudo systemctl reload apache2

# 설정 재시작 (다운타임 발생)
sudo systemctl restart apache2

모듈 관리

# 모듈 활성화
sudo a2enmod 모듈명

# 모듈 비활성화
sudo a2dismod 모듈명

# 자주 사용하는 모듈들
sudo a2enmod rewrite      # URL 재작성
sudo a2enmod headers      # HTTP 헤더 조작
sudo a2enmod proxy        # 프록시 기능
sudo a2enmod proxy_http   # HTTP 프록시
sudo a2enmod proxy_wstunnel  # WebSocket 프록시
sudo a2enmod ssl          # SSL/TLS
sudo a2enmod deflate      # 압축
sudo a2enmod expires      # 캐시 제어

문제 해결

로그 확인

# 실시간 에러 로그 모니터링
sudo tail -f /var/log/apache2/error.log

# 실시간 액세스 로그 모니터링
sudo tail -f /var/log/apache2/access.log

# 특정 가상호스트 로그
sudo tail -f /var/log/apache2/testdomain_error.log

# 마지막 100줄 확인
sudo tail -100 /var/log/apache2/error.log

# 특정 키워드로 검색
sudo grep "testdomain" /var/log/apache2/*.log

# 에러만 필터링
sudo grep "error" /var/log/apache2/error.log

# 최근 에러 (systemd)
sudo journalctl -u apache2 -n 50

연결 테스트

# HTTP 응답 헤더 확인
curl -I http://testdomain.com/

# HTTPS 응답 헤더 확인
curl -I https://testdomain.com/

# 상세 디버깅 정보
curl -v https://testdomain.com/

# POST 요청 테스트
curl -X POST https://testdomain.com/api/endpoint \
  -H "Content-Type: application/json" \
  -d '{"key":"value"}'

# SSL 인증서 정보 확인
openssl s_client -connect testdomain.com:443 -servername testdomain.com < /dev/null

# 백엔드 서비스 테스트
curl -v http://localhost:3000/

포트 및 프로세스 확인

# 특정 포트 사용 확인
sudo netstat -tlnp | grep :80
sudo netstat -tlnp | grep :443
sudo netstat -tlnp | grep :3000

# 또는 ss 명령어 사용 (더 빠름)
sudo ss -tlnp | grep :80

# Apache 프로세스 확인
ps aux | grep apache2

# 열린 파일 확인
sudo lsof -i :80
sudo lsof -i :443

일반적인 문제 해결

포트 충돌 문제 체크

Apache + Nginx 동시 사용 시 자주 발생
특히 Certbot –apache 사용 시 충돌할 수 있음.

sudo ss -tlnp | grep :80
sudo ss -tlnp | grep :443

// 만약 Nginx가 잡고 있다면
sudo systemctl stop nginx
sudo systemctl disable nginx

403 Forbidden 오류

# Directory 권한 확인
<Directory /var/www/testdomain>
    Require all granted
    # 또는
    Options +Indexes
</Directory>

# 파일 시스템 권한 확인
sudo chmod -R 755 /var/www/testdomain
sudo chown -R www-data:www-data /var/www/testdomain

500 Internal Server Error

# 설정 문법 오류 확인
sudo apache2ctl configtest

# .htaccess 문제 확인
sudo tail -50 /var/log/apache2/error.log

# SELinux 확인 (CentOS/RHEL)
sudo setenforce 0  # 임시 비활성화

SSL 인증서 오류

# 인증서 파일 존재 확인
ls -la /etc/letsencrypt/live/testdomain.com/

# 인증서 유효기간 확인
sudo certbot certificates

# 인증서 갱신
sudo certbot renew

# SSL 인증서 권한 변경 주의
# SSLCertificateFile: file '/etc/letsencrypt/live/.../fullchain.pem' does not exist or is empty // 원인은 보통 인증서 폴더 권한 문제

sudo chmod 755 /etc/letsencrypt/live
sudo chmod 644 /etc/letsencrypt/live/DOMAIN/fullchain.pem
sudo chmod 600 /etc/letsencrypt/live/DOMAIN/privkey.pem

프록시 오류 (502 Bad Gateway)

# 백엔드 서비스 작동 확인
curl http://localhost:3000/

# SELinux 설정 (CentOS/RHEL)
sudo setsebool -P httpd_can_network_connect 1

# 프록시 타임아웃 늘리기
ProxyTimeout 600

Proxy 헤더 관련 ForwardedHeaders 추가

ASP.NET Core, Node.js, Django 모두 HTTPS 프록시 환경에서 필수

RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s
RequestHeader set X-Forwarded-Proto https
RequestHeader set X-Forwarded-Host %{HTTP_HOST}s

# (예시) ASP.NET Core
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

보안 강화

보안 헤더 설정

<VirtualHost *:443>
    ServerName testdomain.com
    
    # ... SSL 설정 ...
    
    # HSTS (HTTP Strict Transport Security)
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    
    # XSS 방지
    Header always set X-XSS-Protection "1; mode=block"
    
    # MIME 타입 스니핑 방지
    Header always set X-Content-Type-Options "nosniff"
    
    # 클릭재킹 방지
    Header always set X-Frame-Options "SAMEORIGIN"
    
    # Referrer 정책
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    
    # CSP (Content Security Policy)
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"
    
    # 서버 정보 숨기기
    ServerTokens Prod
    ServerSignature Off
</VirtualHost>

접근 제어

# IP 기반 접근 제어
<Directory /var/www/admin>
    # 특정 IP만 허용
    Require ip 192.168.1.0/24
    Require ip 10.0.0.5
    
    # 또는 특정 IP 차단
    Require all granted
    Require not ip 192.168.1.100
</Directory>

# HTTP Basic 인증
<Directory /var/www/protected>
    AuthType Basic
    AuthName "Restricted Area"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
</Directory>

.htpasswd 파일 생성

# htpasswd 파일 생성 (첫 사용자)
sudo htpasswd -c /etc/apache2/.htpasswd username

# 추가 사용자 등록 (-c 옵션 제거)
sudo htpasswd /etc/apache2/.htpasswd username2

Rate Limiting (mod_ratelimit)

<Location /api>
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
    SetEnv rate-initial-burst 100
</Location>

성능 최적화

캐싱 설정

<VirtualHost *:443>
    ServerName testdomain.com
    
    # ... 기본 설정 ...
    
    # 정적 파일 캐싱
    <IfModule mod_expires.c>
        ExpiresActive On
        
        # 이미지
        ExpiresByType image/jpg "access plus 1 year"
        ExpiresByType image/jpeg "access plus 1 year"
        ExpiresByType image/gif "access plus 1 year"
        ExpiresByType image/png "access plus 1 year"
        ExpiresByType image/webp "access plus 1 year"
        ExpiresByType image/svg+xml "access plus 1 year"
        
        # CSS/JS
        ExpiresByType text/css "access plus 1 month"
        ExpiresByType application/javascript "access plus 1 month"
        
        # 폰트
        ExpiresByType font/woff2 "access plus 1 year"
        ExpiresByType font/woff "access plus 1 year"
        
        # HTML
        ExpiresByType text/html "access plus 1 hour"
    </IfModule>
    
    # Cache-Control 헤더
    <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|css|js|woff|woff2)$">
        Header set Cache-Control "max-age=31536000, public"
    </FilesMatch>
</VirtualHost>

Gzip & Brotli 압축

<IfModule mod_deflate.c>
    # 압축 활성화
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
    AddOutputFilterByType DEFLATE application/javascript application/json
    AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
    AddOutputFilterByType DEFLATE image/svg+xml
    
    # 이미지는 압축 제외 (이미 압축됨)
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|webp)$ no-gzip
</IfModule>


sudo apt install libapache2-mod-brotli
sudo a2enmod brotli

<IfModule mod_brotli.c>
    BrotliCompressionQuality 5
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json image/svg+xml
</IfModule>

KeepAlive 설정

# /etc/apache2/apache2.conf

# KeepAlive 활성화
KeepAlive On

# 최대 요청 수
MaxKeepAliveRequests 100

# 타임아웃 (초)
KeepAliveTimeout 5

MPM 설정 최적화

# /etc/apache2/mods-available/mpm_event.conf

<IfModule mpm_event_module>
    StartServers             2
    MinSpareThreads          25
    MaxSpareThreads          75
    ThreadLimit              64
    ThreadsPerChild          25
    MaxRequestWorkers        150
    MaxConnectionsPerChild   0
</IfModule>

디렉토리 구조

Apache 설정 파일 구조

/etc/apache2/
├── apache2.conf              # 메인 설정 파일
├── ports.conf                # 포트 설정
├── conf-available/           # 사용 가능한 설정
├── conf-enabled/             # 활성화된 설정
├── mods-available/           # 사용 가능한 모듈
├── mods-enabled/             # 활성화된 모듈 (심볼릭 링크)
├── sites-available/          # 사용 가능한 가상호스트
│   ├── 000-default.conf
│   ├── testdomain.conf
│   └── api.testdomain.conf
├── sites-enabled/            # 활성화된 가상호스트 (심볼릭 링크)
│   ├── 000-default.conf -> ../sites-available/000-default.conf
│   └── testdomain.conf -> ../sites-available/testdomain.conf
└── envvars                   # 환경 변수

웹 컨텐츠 디렉토리

/var/www/
├── html/                     # 기본 DocumentRoot
├── testdomain/               # 가상호스트 디렉토리
│   ├── public/
│   ├── index.html
│   └── .htaccess
└── logs/                     # 로그 (선택사항)

유용한 명령어 모음

빠른 참조

# 설정 테스트
sudo apache2ctl configtest

# 가상호스트 목록
sudo apache2ctl -S

# 설정 리로드 (무중단)
sudo systemctl reload apache2

# 재시작
sudo systemctl restart apache2

# 상태 확인
sudo systemctl status apache2

# 로그 실시간 모니터링
sudo tail -f /var/log/apache2/error.log

# 특정 도메인 설정 확인
sudo apache2ctl -D DUMP_VHOSTS | grep testdomain

# 활성화된 모듈 목록
apache2ctl -M

# 설정 파일 문법 체크
sudo apachectl -t

자주 사용하는 작업

# 새 가상호스트 생성부터 활성화까지
sudo vim /etc/apache2/sites-available/newsite.conf
sudo a2ensite newsite.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

# SSL 인증서 발급 및 자동 설정
sudo certbot --apache -d newsite.com

# 로그 분석
sudo tail -1000 /var/log/apache2/access.log | grep "POST" | wc -l

# 디스크 사용량 확인
sudo du -sh /var/log/apache2/*

# 오래된 로그 정리
sudo find /var/log/apache2/ -name "*.log.*" -mtime +30 -delete

문제 상황별 체크리스트

사이트가 접속되지 않을 때

• [ ] Apache 서비스 작동 확인: sudo systemctl status apache2
• [ ] 포트 리스닝 확인: sudo netstat -tlnp | grep :80
• [ ] 방화벽 확인: sudo ufw status
• [ ] DNS 설정 확인: nslookup testdomain.com
• [ ] 가상호스트 활성화 확인: sudo apache2ctl -S
• [ ] 설정 문법 확인: sudo apache2ctl configtest

502 Bad Gateway 발생 시

• [ ] 백엔드 서비스 작동 확인: curl http://localhost:3000/
• [ ] 프록시 설정 확인: ProxyPass, ProxyPassReverse
• [ ] SELinux 설정 확인 (CentOS/RHEL)
• [ ] 타임아웃 설정 확인: ProxyTimeout
• [ ] 에러 로그 확인: sudo tail -50 /var/log/apache2/error.log

SSL 인증서 오류 시

• [ ] 인증서 파일 존재 확인
• [ ] 인증서 유효기간 확인: sudo certbot certificates
• [ ] 인증서 경로 확인
• [ ] 포트 443 리스닝 확인
• [ ] SSL 모듈 활성화 확인: apache2ctl -M | grep ssl

The post Apache Virtual Host Guide (Apache 가상 호스트 설정) appeared first on 어제와 내일의 나 그 사이의 이야기.

HTML iframe?

<iframe> (Inline Frame) 태그는 현재 HTML 문서 안에 다른 웹 페이지나 미디어 콘텐츠를 임베드(embed)할 때 사용하는 HTML 요소입니다.

외부 콘텐츠를 현재 페이지에 “창문처럼” 삽입하는 기능을 제공하며, 웹 개발에서 매우 유용한 도구입니다.

1. 기본 구조와 문법

기본 문법

<iframe 
    src="삽입할_콘텐츠_URL" 
    width="너비" 
    height="높이" 
    title="프레임 설명"
    allow="fullscreen">
    <!-- 대체 콘텐츠 (iframe을 지원하지 않는 브라우저용) -->
    <p>이 브라우저는 iframe을 지원하지 않습니다.</p>
</iframe>

최소 권장 구조

<iframe 
    src="https://example.com" 
    title="Example Website"
    width="600" 
    height="400">
</iframe>

2. 핵심 속성

3. 주요 사용 사례

1) YouTube 동영상 임베드

<div class="video-container">
    <iframe src="https://www.youtube.com/embed/rdwz7QiG0lk?enablejsapi=1"
            id="ytPlayer"
            width="560"
            height="315"
            title="YouTube on the tube!"
            allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; fullscreen; picture-in-picture; web-share">
    </iframe>
</div>

<style>
    .video-container {
        position: relative;
        padding-bottom: 56.25%; /* 16:9 비율 */
        height: 0;
        overflow: hidden;
    }

    .video-container iframe {
        position: absolute;
        top: 0;
        left: 0;
        width: 100%;
        height: 100%;
    }
</style>

2) Google Maps 임베드

<iframe
    src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d3165.303576908283!2d127.024612!3d37.515582!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.1!3m3!1m2!1s0x0%3A0x0!2zMzfCsDMwJzU2LjEiTiAxMjfCsDAxJzI4LjYiRQ!5e0!3m2!1sen!2skr!4v1620000000000!5m2!1sen!2skr"
    width="600"
    height="450"
    title="Google Maps"
    style="border:0;"
    allow="fullscreen"
    loading="lazy"
    referrerpolicy="no-referrer-when-downgrade">
</iframe>

3) PDF 문서 표시

<iframe 
    src="/documents/sample.pdf" 
    width="100%" 
    height="600px"
    title="PDF 문서">
    <p>PDF를 표시할 수 없습니다. <a href="/documents/sample.pdf">다운로드</a>하세요.</p>
</iframe>

4) 인라인 HTML 콘텐츠 (srcdoc 사용)

<iframe 
    srcdoc="<html><body><h1>안녕하세요!</h1><p>이것은 인라인 HTML입니다.</p></body></html>"
    width="400" 
    height="200"
    title="인라인 HTML">
</iframe>

4. 보안 및 권한 제어 속성 (sandbox & allow)

4.1 sandbox 속성 – 보안 제한 설정

sandbox 속성은 iframe 내 콘텐츠의 보안을 강화하기 위해 사용됩니다.

기본적으로 모든 것을 차단하고 필요한 기능만 허용하는 방식입니다.

sandbox 기본 사용법

<!-- 모든 제한 적용 (최고 보안) -->
<iframe src="..." sandbox></iframe>

<!-- 특정 기능만 허용 -->
<iframe src="..." sandbox="allow-scripts allow-same-origin allow-forms"></iframe>

sandbox 값들

4.2 allow 속성 – 기능 권한 제어

allow 속성은 브라우저의 고급 기능에 대한 접근 권한을 제어합니다.

Permissions Policy를 통해 특정 웹 API 사용을 허용하거나 차단합니다.

allow 기본 사용법

<!-- 특정 브라우저 기능 허용 -->
<iframe src="..." 
        allow="camera; microphone; geolocation">
</iframe>

<!-- YouTube 동영상에 필요한 기능들 -->
<iframe src="https://www.youtube.com/embed/..."
        allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share">
</iframe>

allow 값들

4.3 사용 예시

신뢰할 수 없는 콘텐츠 (높은 보안)

<!-- 외부 광고, 사용자 생성 콘텐츠 -->
<iframe src="https://untrusted-ads.com/banner" 
        sandbox="allow-scripts"
        width="300" height="250">
</iframe>

부분적으로 신뢰하는 콘텐츠 (중간 보안)

<!-- 서드파티 앱, 외부 도구 -->
<iframe src="https://third-party-tool.com"
        sandbox="allow-scripts allow-same-origin allow-forms"
        allow="clipboard-write"
        width="600" height="400">
</iframe>

신뢰할 수 있는 서비스 (기능 중심)

<!-- YouTube, Google Maps 등 -->
<iframe src="https://www.youtube.com/embed/rdwz7QiG0lk"
        allow="accelerometer; autoplay; encrypted-media; fullscreen; gyroscope; picture-in-picture; web-share">
</iframe>

둘 다 사용하는 경우

<!-- 보안과 기능 모두 제어 -->
<iframe src="https://video-chat-app.com"
        sandbox="allow-scripts allow-same-origin allow-forms"
        allow="camera; microphone; autoplay"
        width="800" height="600">
</iframe>

5. 보안 및 성능 고려사항

보안 고려사항

X-Frame-Options 헤더

X-Frame-Options: DENY          # 모든 프레임에서 차단
X-Frame-Options: SAMEORIGIN   # 동일 출처에서만 허용
X-Frame-Options: ALLOW-FROM https://example.com  # 대부분 지원 중단되었으므로 CSP frame-ancestors를 사용

# "특정 도메인"은 해당 웹사이트를 iframe으로 임베드할 수 있는 허용된 출처(도메인)를 의미

Content Security Policy (CSP)

<meta http-equiv="Content-Security-Policy" 
      content="frame-src https://youtube.com https://maps.google.com;">

안전한 iframe 사용법

<iframe 
    src="https://trusted-site.com"
    sandbox="allow-scripts allow-same-origin"
    referrerpolicy="strict-origin-when-cross-origin">
</iframe>

성능 최적화

지연 로딩 (Lazy Loading)

<iframe 
    src="https://example.com" 
    loading="lazy"
    width="600" 
    height="400">
</iframe>

리소스 힌트 사용

<!-- DNS 사전 해석 -->
<link rel="dns-prefetch" href="https://www.youtube.com">

<!-- 사전 연결 -->
<link rel="preconnect" href="https://www.youtube.com">

<!-- 리소스 사전 로드 -->
<link rel="preload" href="https://example.com/critical-frame" as="document">

Intersection Observer를 이용한 동적 로딩

const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
        if (entry.isIntersecting) {
            const iframe = entry.target;
            iframe.src = iframe.dataset.src;
            observer.unobserve(iframe);
        }
    });
});

document.querySelectorAll('iframe[data-src]').forEach(iframe => {
    observer.observe(iframe);
});

6. 반응형 디자인

CSS를 이용한 반응형 iframe

.iframe-container {
    position: relative;
    width: 100%;
    padding-bottom: 56.25%; /* 16:9 비율 */
    height: 0;
    overflow: hidden;
}

.iframe-container iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    border: 0;
}

<div class="iframe-container">
    <iframe src="https://www.youtube.com/embed/dQw4w9WgXcQ" 
            title="YouTube 동영상"
            allow="fullscreen">
    </iframe>
</div>

다양한 비율 지원

.aspect-16-9 { padding-bottom: 56.25%; }  /* 16:9 */
.aspect-4-3 { padding-bottom: 75%; }      /* 4:3 */
.aspect-1-1 { padding-bottom: 100%; }     /* 1:1 */
.aspect-21-9 { padding-bottom: 42.86%; }  /* 21:9 */

7. JavaScript와의 상호작용

postMessage API 사용

// 부모 페이지에서 iframe으로 메시지 전송
const iframe = document.getElementById('myFrame');
iframe.contentWindow.postMessage('Hello from parent', '*');

// 메시지 수신 리스너
window.addEventListener('message', (event) => {
    if (event.origin !== 'https://trusted-domain.com') return;
    console.log('받은 메시지:', event.data);
});

iframe 로드 완료 감지

const iframe = document.getElementById('myFrame');
iframe.addEventListener('load', () => {
    console.log('iframe 로드 완료');
});

8. 프레임워크별 사용 예시

React

function YouTubeEmbed({ videoId }) {
    return (
        <div className="iframe-container">
            <iframe
                src={`https://www.youtube.com/embed/${videoId}`}
                title="YouTube video player"
                allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen"
            />
        </div>
    );
}

Vue.js

<template>
    <div class="iframe-container">
        <iframe
            :src="`https://www.youtube.com/embed/${videoId}`"
            title="YouTube video player"
            allow="fullscreen"
        />
    </div>
</template>

<script>
export default {
    props: ['videoId']
}
</script>

Blazor

@page "/iframe-demo"

<div class="iframe-wrapper">
    <iframe src="https://www.youtube.com/embed/dQw4w9WgXcQ"
            width="560"
            height="315"
            title="YouTube 동영상"
            allow="fullscreen"
            class="youtube-frame">
    </iframe>
</div>

<style>
    .youtube-frame {
        border: none;
        border-radius: 8px;
        box-shadow: 0 4px 8px rgba(0,0,0,0.1);
    }
    
    .iframe-wrapper {
        display: flex;
        justify-content: center;
        margin: 20px 0;
    }
</style>

9. 접근성 (Accessibility)

필수 접근성 고려사항

<iframe
    src="https://example.com"
    title="명확하고 설명적인 제목"
    aria-label="iframe 내용에 대한 추가 설명"
    tabindex="0">
    <p>이 콘텐츠를 보려면 <a href="https://example.com">여기를 클릭</a>하세요.</p>
</iframe>

키보드 네비게이션

iframe:focus {
    outline: 2px solid #007cba;
    outline-offset: 2px;
}

10. 문제 해결 및 디버깅

일반적인 문제들

1. 콘텐츠가 보이지 않을 때

// 개발자 도구에서 확인할 사항들
console.log('iframe src:', iframe.src);
console.log('iframe 로드 상태:', iframe.readyState);

// 오류 핸들링
iframe.addEventListener('error', (e) => {
    console.error('iframe 로드 오류:', e);
});

2. X-Frame-Options 오류 해결

• 개발자 도구 → Network 탭에서 응답 헤더 확인
• 가능한 해결책: 프록시 서버 사용 또는 API를 통한 콘텐츠 가져오기

3. CORS 정책 위반

// 안전한 방법: 서버 사이드에서 콘텐츠 프록시
fetch('/api/proxy?url=' + encodeURIComponent(targetUrl))
    .then(response => response.text())
    .then(html => {
        iframe.srcdoc = html;
    });

디버깅 도구

// iframe 상태 체크 함수
function checkIframeStatus(iframeId) {
    const iframe = document.getElementById(iframeId);
    console.log({
        src: iframe.src,
        contentDocument: iframe.contentDocument,
        contentWindow: iframe.contentWindow,
        readyState: iframe.readyState
    });
}

11. 모범 사례 및 권장사항

권장사항

1. 항상 title 속성 제공 – 접근성을 위해 필수
2. 적절한 크기 설정 – 반응형 디자인 고려
3. loading=”lazy” 사용 – 성능 최적화
4. sandbox 속성 활용 – 보안 강화
5. 대체 콘텐츠 제공 – 호환성 보장
6. HTTPS 사용 – 보안 및 호환성

피해야 할 것들

1. frameborder 속성 – HTML5에서는 CSS 사용 권장
2. 과도한 중첩 – 성능 저하 원인
3. 신뢰할 수 없는 소스 – 보안 위험
4. 고정 크기만 사용 – 반응형 웹에 부적합
5. title 속성 누락 – 접근성 문제

12. 대안 기술들

1. object 태그

<object data="document.pdf" type="application/pdf" width="600" height="400">
    <p>PDF를 표시할 수 없습니다. <a href="document.pdf">다운로드</a>하세요.</p>
</object>

2. embed 태그

<embed src="movie.mp4" type="video/mp4" width="600" height="400">

3. Web Components

class CustomEmbed extends HTMLElement {
    connectedCallback() {
        this.innerHTML = `
            <iframe src="${this.getAttribute('src')}" 
                    title="${this.getAttribute('title')}">
            </iframe>
        `;
    }
}
customElements.define('custom-embed', CustomEmbed);

결론

iframe은 웹 개발에서 외부 콘텐츠를 삽입하는 강력한 도구입니다.

올바른 사용법과 보안 고려사항을 숙지하여 안전하고 효율적인 웹 애플리케이션을 개발할 수 있습니다.

특히 현대 웹 개발에서는 성능, 보안, 접근성을 모두 고려한 구현이 중요합니다.

The post HTML iframe 정리 appeared first on 어제와 내일의 나 그 사이의 이야기.

1. Docker 백그라운드 실행 명령어

컨테이너를 백그라운드(detached) 모드로 실행하여 터미널을 점유하지 않고 계속해서 동작하게 하는 명령어

// docker run -d [이미지 이름]
// -d 또는 --detach 옵션은 컨테이너를 백그라운드에서 실행하도록 지시
docker run -d -p 8080:80 nginx

2. 실행 중인 컨테이너 확인 명령어

현재 시스템에서 실행 중인 컨테이너를 확인하는 명령어

// ps는 "process status"의 약자로, 현재 실행 중인 컨테이너의 목록을 보여줌
docker ps


CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                   NAMES
a1b2c3d4e5f6   nginx     "/docker-entrypoint.sh"  10 seconds ago   Up 8 seconds    0.0.0.0:8080->80/tcp, :::8080->80/tcp   web_server

// CONTAINER ID: 컨테이너의 고유 ID
// IMAGE: 컨테이너를 생성하는 데 사용된 이미지
// COMMAND: 컨테이너가 실행될 때 사용된 명령어
// CREATED: 컨테이너가 생성된 시점
// STATUS: 컨테이너의 현재 상태 (예: Up 5 minutes)
// PORTS: 포트 매핑 정보
// NAMES: 컨테이너에 할당된 이름

3. 모든 컨테이너 확인 명령어 (실행 중 + 정지)

실행 중인 컨테이너뿐만 아니라, 이전에 실행되었다가 현재는 정지된 모든 컨테이너를 확인하는 명령어

// -a 또는 --all 옵션은 모든 컨테이너를 표시하도록 지시
docker ps -a

CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS                      PORTS     NAMES
a1b2c3d4e5f6   nginx     "/docker-entrypoint.sh"  2 minutes ago   Up 2 minutes                ...       web_server
e6f5d4c3b2a1   ubuntu    "/bin/bash"              5 hours ago     Exited (0) 4 minutes ago              test_container

4. 기타 유용한 명령어

• docker stop
• docker start
• docker kill
• docker logs
• docker attach
• docker exec

// 컨테이너 중지: docker stop [컨테이너 ID 또는 이름]
// 실행 중인 컨테이너를 정상적으로 종료시킵니다.
docker stop web_server

// 컨테이너 시작: docker start [컨테이너 ID 또는 이름]
// 정지된 컨테이너를 다시 시작합니다.
docker start test_container

// 컨테이너 강제 종료: docker kill [컨테이너 ID 또는 이름]
// 컨테이너를 강제로 즉시 종료시킵니다.
docker kill web_server

// 컨테이너 로그 확인: docker logs [컨테이너 ID 또는 이름]
// 컨테이너의 표준 출력(stdout)과 표준 에러(stderr) 로그를 확인합니다.
docker logs web_server

// 컨테이너 접속: docker attach [컨테이너 ID 또는 이름]
// 백그라운드에서 실행 중인 컨테이너의 터미널에 연결합니다.
docker attach web_server

// 컨테이너 내부에 명령어 실행: docker exec [컨테이너 ID 또는 이름] [명령어]
// 실행 중인 컨테이너 내부에 새로운 프로세스를 실행합니다.
// 예시 : Nginx 컨테이너에서 bash 셸을 실행하여 내부로 접속
docker exec -it web_server /bin/bash

The post Docker 백그라운드 실행 명령어 appeared first on 어제와 내일의 나 그 사이의 이야기.

Docker 포트 매핑 (Port Mapping)

Docker에서 포트 매핑은 컨테이너 내부에서 실행 중인 서비스의 포트와 호스트 컴퓨터(Docker가 설치된 머신)의 포트를 연결하는 중요한 기능입니다.

포트 매핑 왜 필요한가?

Docker 컨테이너는 기본적으로 격리된 환경에서 실행됩니다.

즉, 컨테이너 내부에 웹 서버가 80번 포트에서 동작하더라도, 외부에서는 이 포트에 직접 접근할 수 없습니다.

컨테이너는 자체적인 IP 주소를 가지고 있으며, 호스트 컴퓨터와는 다른 네트워크 환경에 있습니다.

포트 매핑의 역할

포트 매핑은 컨테이너의 특정 포트를 호스트 컴퓨터의 특정 포트로 터널링(tunneling)하는 역할을 합니다.

이를 통해 외부 사용자는 호스트 컴퓨터의 포트를 통해 컨테이너 내부의 서비스에 접근할 수 있게 됩니다.

간단한 예시

Nginx 웹 서버를 실행하는 컨테이너를 생각해봅시다.

Nginx는 기본적으로 80번 포트에서 동작합니다.

이 컨테이너에 외부에서 접근할 수 있도록 하려면 다음과 같이 포트 매핑을 설정할 수 있습니다.

Bash

docker run -p 8080:80 nginx

• -p:
  포트 매핑 옵션
• 8080:
  호스트 컴퓨터의 포트로 외부에서 http://[호스트 IP]:8080으로 접속
• 80:
  컨테이너 내부의 포트로 Nginx가 이 포트에서 대기
• nginx:
  사용할 Docker 이미지 이름

호스트 컴퓨터의 8080번 포트로 들어오는 모든 네트워크 요청은 Docker에 의해 컨테이너의 80번 포트로 전달됩니다.

이로써 외부 사용자는 http://localhost:8080 (만약 로컬에서 실행했다면)으로 접속하여 컨테이너 내부의 Nginx 웹 서버에 접근할 수 있게 됩니다.

요약

The post Docker Port Mapping(포트 매핑) appeared first on 어제와 내일의 나 그 사이의 이야기.

Docker에서 HTML 페이지 배포

기본적으로 웹 서버로 이동하여 HTML 페이지를 렌더링

웹 서버 nginx 이미지 가져오기

docker pull nginx

index.html 파일을 준비

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <title>테스트 페이지</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      background-color: #f0f0f0;
      text-align: center;
      padding: 50px;
    }
    h1 {
      color: #333;
    }
    button {
      padding: 10px 20px;
      font-size: 16px;
    }
  </style>
</head>
<body>
  <h1>HTML 테스트 페이지</h1>
  <p>이 페이지는 테스트용으로 생성되었습니다.</p>
  <button onclick="alert('버튼이 클릭되었습니다!')">클릭해보세요</button>
</body>
</html>

nginx 이미지를 사용하여 Docker 컨테이너에 로드

Dockerfile 생성

도커파일은 확장자가 없음

FROM nginx
COPY ./SampleWebApp/ /usr/share/nginx/html

Dockerfile 이미지 생성

도커파일은 확장자가 없음

cd C:\Users\IKHO\Desktop\Docker 
// dockerfile 위치로 이동

ls 
// 파일 목록 확인

docker build -t sample_web_app:1.0.0 .
// docker build: 현재 디렉터리에 있는 Dockerfile을 기반으로 Docker 이미지를 만들라는 명령입니다.
// -t sample_web_app:1.0.0: 생성될 이미지의 이름과 태그를 지정합니다.
// sample_web_app이 이미지 이름
// 1.0.0은 버전 또는 태그 (나중에 버전별로 관리할 때 유용)

컨테이너를 생성 및 실행

docker run --name sample_web_app-container -p 9000:80 sample_web_app:1.0.0
// docker run   : 새로운 컨테이너를 생성하고 실행합니다
// --name sample_web_app-container   : 컨테이너의 이름을 sample_web_app-container로 설정합니다
// -p 9000:80   : 포트 매핑: 호스트의 9000 포트를 컨테이너의 80 포트에 연결합니다 (외부에서 localhost:9000으로 접근 가능)
// sample_web_app:1.0.0   : sample_web_app라는 이름과 1.0.0 태그가 붙은 이미지를 기반으로 컨테이너를 생성합니다



http://127.0.0.1:9000/

The post Docker에서 HTML 페이지 배포 appeared first on 어제와 내일의 나 그 사이의 이야기.

기본적인 Docker 명령어

docker --version

// Docker Hub에서 hello-world 이미지를 다운로드하는 명령어
docker pull hello-world

docker images

docker run hello-world

// 실행 중인 컨테이너 목록만 출력
docker ps

모든 컨테이너 목록 출력
// 중지된, 종료된, 에러 난 컨테이너도 포함해서 모두 보여줌
docker ps -a

docker ps // 컨테이너 확인
docker ps -a // 모든 컨테이너 확인
docker rm 5fea
docker rm 6c465
docker rm 0fe
docker rm 1957
docker ps -a // 모든 컨테이너 확인
docker images // 이미지 검색
docker rmi ec1538 // 이미지 제거

docker run -d ubuntu sleep 10

항목	의미
docker run	새로운 컨테이너를 생성하고 실행
-d	Detached mode → 백그라운드에서 실행
ubuntu	사용할 이미지 이름 (없으면 자동으로 Docker Hub에서 pull함)
sleep 10	컨테이너 내부에서 실행할 명령어 (10초 동안 대기)

.NET Image 추가

docker pull mcr.microsoft.com/dotnet/sdk:8.0
docker images

두 항목의 IMAGE ID가 동일
REPOSITORY: mcr.microsoft.com/dotnet/sdk
TAG: 9.0 → IMAGE ID: 08fe223b9022
TAG: latest → IMAGE ID: 08fe223b9022
이유: latest 태그는 별칭(alias) 이기 때문이다
도커에서 태그(TAG)는 특정 이미지 버전을 지칭하는 이름일 뿐이며, 동일한 이미지에 여러 개의 태그를 붙일 수 있습니다.
=> 9.0 버전의 이미지에 latest라는 이름을 추가로 붙여 놓은 것

The post 기본적인 Docker 명령어 연습 appeared first on 어제와 내일의 나 그 사이의 이야기.

현대 소프트웨어 개발에서 가상화 기술은 필수적인 요소입니다.

전통적인 가상머신(Virtual Machine)과 Docker 컨테이너 기술의 차이점을 알아봅니다.

• Infrastructure (물리적 하드웨어)
• Host OS (호스트 운영체제)
• Hypervisor (가상화 관리자)
• Guest OS (각 가상머신마다 독립된 운영체제)
• bins/lib (각 VM마다 독립된 바이너리/라이브러리)
• App 1, 2, 3 (애플리케이션들)

1. 아키텍처 비교

1.1 Virtual Machine 아키텍처

Virtual Machine은 다음과 같은 계층 구조를 가집니다:

특징:

• 각 가상머신은 독립된 Guest OS를 보유
• 하드웨어 가상화를 통한 완전한 격리
• Hypervisor가 하드웨어 리소스 관리

1.2 Docker 아키텍처

Docker는 다음과 같은 경량화된 구조를 가집니다:

특징:

• Guest OS 레이어 제거
• Host OS 커널 공유
• 컨테이너 단위의 프로세스 격리

2. 핵심 차이점 분석

2.1 운영체제 레이어

2.2 리소스 사용량

Virtual Machine

• 메모리: GB 단위 (OS + 애플리케이션)
• 디스크: 수 GB ~ 수십 GB
• CPU: OS 오버헤드 포함
• 네트워크: 가상 네트워크 스택

Docker

• 메모리: MB 단위 (애플리케이션만)
• 디스크: MB ~ GB 단위
• CPU: 최소한의 오버헤드
• 네트워크: Host 네트워크 스택 공유

2.3 성능 비교

3. 장단점 비교

3.1 Virtual Machine

장점

• 완전한 격리: 하드웨어 레벨의 보안 격리
• OS 다양성: 다양한 운영체제 동시 실행 가능
• 성숙한 기술: 오랜 기간 검증된 안정성
• 강력한 보안: 하이퍼바이저 레벨 보안

단점

• 높은 리소스 사용량: OS 오버헤드
• 느린 시작: 부팅 시간 필요
• 관리 복잡성: 각 VM의 OS 관리 필요
• 낮은 밀도: 제한적인 VM 수

3.2 Docker

장점

• 경량성: 최소한의 리소스 사용
• 빠른 시작: 초 단위 컨테이너 시작
• 높은 밀도: 단일 호스트에 많은 컨테이너
• 일관성: “한 번 빌드, 어디서든 실행”
• DevOps 친화적: CI/CD 파이프라인 최적화

단점

• 보안 취약점: 커널 공유로 인한 잠재적 위험
• OS 제약: Linux 컨테이너는 Linux에서만
• 복잡한 네트워킹: 컨테이너 간 통신 설정
• 데이터 지속성: 컨테이너 재시작 시 데이터 손실 위험

4. 사용 사례별 권장사항

4.1 Virtual Machine이 적합한 경우

기업 환경

• 레거시 애플리케이션 운영
• 서로 다른 OS가 필요한 환경
• 강력한 보안 격리가 필요한 경우
• 규제 준수가 중요한 산업

기술적 요구사항

• Windows와 Linux 애플리케이션 동시 운영
• 커널 수준의 소프트웨어 개발
• 완전한 네트워크 격리 필요
• 다양한 OS 버전 테스트

4.2 Docker가 적합한 경우

현대적 애플리케이션 개발

• 마이크로서비스 아키텍처
• 클라우드 네이티브 애플리케이션
• 지속적 통합/배포 (CI/CD)
• 개발 환경 표준화

운영 효율성

• 빠른 스케일링이 필요한 서비스
• 리소스 효율성이 중요한 환경
• 개발팀 간 환경 일관성
• 컨테이너 오케스트레이션 (Kubernetes)

5. 하이브리드 접근법

많은 조직에서는 두 기술을 함께 사용합니다:

5.1 VM 위의 Docker

• VM으로 기본 격리 제공
• VM 내에서 Docker로 애플리케이션 컨테이너화
• 보안과 효율성의 균형

5.2 클라우드 환경

• AWS ECS, Google Cloud Run 등
• 관리형 컨테이너 서비스
• 인프라 추상화

6. 결론

Virtual Machine과 Docker는 각각 고유한 장점과 적용 영역을 가지고 있습니다.

Virtual Machine은 강력한 격리와 다양한 OS 지원이 필요한 전통적인 엔터프라이즈 환경에 적합하며,

Docker는 현대적인 클라우드 네이티브 애플리케이션 개발과 운영에 최적화되어 있습니다.

성공적인 시스템 설계를 위해서는 각 기술의 특성을 정확히 이해하고, 프로젝트의 요구사항에 맞는 적절한 선택을 하는 것이 중요합니다.

많은 경우 두 기술을 적절히 조합하여 사용하는 하이브리드 접근법이 최적의 결과를 제공할 수 있습니다.

The post Docker / Virtual Machine 차이점 appeared first on 어제와 내일의 나 그 사이의 이야기.

미들웨어(Middleware)

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-8.0

ASP.NET Core의 미들웨어는 모든 HTTP 요청과 응답 파이프라인을 형성하는 일련의 구성 요소입니다.

각 미들웨어 구성 요소는 다음을 수행할 수 있습니다:

• 들어오는 요청을 검사합니다.
• 요청 또는 응답을 수정합니다 (필요한 경우).
• 파이프라인의 다음 미들웨어를 호출하거나, 프로세스를 단락(short-circuit)시키고 자체적으로 응답을 생성합니다.

이러한 파이프라인을 통해 애플리케이션의 로직을 모듈화하고, 인증, 로깅, 오류 처리, 라우팅 등과 같은 기능을 깔끔하고 유지 관리하기 쉬운 방식으로 추가할 수 있습니다.

미들웨어 체인 (요청 파이프라인)

ASP.NET Core 요청 파이프라인은 차례로 호출되는 일련의 요청 대리자로 구성됩니다.

요청 파이프라인을 일련의 연결된 파이프라고 상상해 보세요.

각 미들웨어 조각은 이 파이프라인의 밸브와 같아서, 정보의 흐름을 제어하고 다양한 단계에서 특정 작업을 적용할 수 있습니다.

미들웨어를 등록하는 순서는 매우 중요하며, 등록된 순서대로 실행됩니다.

각 델리게이트는 다음 델리게이트를 호출하기 전과 후에 작업을 수행할 수 있습니다.

예외 처리 델리게이트는 파이프라인의 후반 단계에서 발생하는 예외를 Catch할 수 있도록 파이프라인의 초기에 호출되어야 합니다.

가장 간단한 ASP.NET Core 앱은 모든 요청을 처리하는 단일 요청 델리게이트를 설정합니다.

이 경우에는 실제 요청 파이프라인이 포함되지 않습니다.

대신, 모든 HTTP 요청에 대한 응답으로 단일 익명 함수가 호출됩니다.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Run(); // 이 app.Run은 위의 app.Run이 파이프라인을 종료하므로 실행되지 않습니다.

Use 메서드를 사용하면 여러 요청 델리게이트를 체인으로 연결할 수 있습니다.

이때 next 매개변수는 파이프라인의 다음 델리게이트를 나타냅니다.

next 매개변수를 호출하지 않음으로써 파이프라인을 단락(short-circuit)시킬 수 있습니다.

다음 예시에서 보여주듯이, 일반적으로 next 델리게이트를 호출하기 전과 후에 모두 작업을 수행할 수 있습니다.

var builder = WebApplication.CreateBuilder(args); // 웹 애플리케이션 빌더를 생성합니다.
var app = builder.Build(); // 빌더를 사용하여 웹 애플리케이션 인스턴스를 생성합니다.

// 첫 번째 미들웨어: app.Use()를 사용하여 파이프라인에 추가합니다.
app.Use(async (context, next) =>
{
    // 응답에 쓸 수 있는 작업을 수행합니다. (예: 헤더 추가, 응답의 시작 부분 작성)
    // 이 부분의 코드는 다음 미들웨어가 실행되기 전에 실행됩니다.

    await next.Invoke(); // 다음 미들웨어(이 경우 app.Run)를 호출하여 제어를 넘깁니다.

    // 응답에 쓰지 않는 로깅 또는 다른 작업을 수행합니다.
    // 이 부분의 코드는 다음 미들웨어가 실행된 후(응답이 생성된 후) 실행됩니다.
});

// 두 번째 미들웨어: app.Run()을 사용하여 파이프라인에 추가합니다.
// app.Run()은 파이프라인을 종료하는 미들웨어입니다.
app.Run(async context =>
{
    // 이 미들웨어는 "Hello from 2nd delegate."를 응답에 작성하고 파이프라인을 종료합니다.
    await context.Response.WriteAsync("Hello from 2nd delegate.");
});

// 이 app.Run()은 위의 app.Run()이 이미 파이프라인을 종료했기 때문에 실행되지 않습니다.
app.Run();

요청 파이프라인 단락(Short-circuiting)

ASP.NET Core의 미들웨어 파이프라인에서, 특정 델리게이트(미들웨어)가 요청을 다음 델리게이트로 전달하지 않을 때 이를 요청 파이프라인을 단락(short-circuiting)시킨다고 합니다.

파이프라인 단락은 불필요한 작업을 피할 수 있기 때문에 종종 유용합니다.

예를 들어, 정적 파일 미들웨어(Static File Middleware)는 요청된 파일이 정적 파일(이미지, CSS, JavaScript 등)일 경우 해당 요청을 처리하고

파이프라인의 나머지 부분을 단락시킴으로써 종료 미들웨어(terminal middleware) 역할을 할 수 있습니다.

이렇게 되면 정적 파일을 제공한 후에는 인증이나 라우팅과 같은 다른 미들웨어들이 실행될 필요가 없으므로 효율성이 높아집니다.

단락과 next.Invoke() 이후 코드 실행

파이프라인의 추가적인 처리를 종료시키는 미들웨어보다 앞서 파이프라인에 추가된 미들웨어는 여전히 next.Invoke() 구문 이후의 코드를 처리합니다.

즉, 비록 파이프라인이 단락되어 최종 응답이 더 이상 아래로 전달되지 않더라도, next.Invoke()를 호출했던 이전 미들웨어들은 응답이 완료된 후 자신의 후처리 로직을 실행할 수 있습니다.

경고: 응답 전송 후 작업 주의

응답이 클라이언트에게 이미 전송되었거나 전송되기 시작한 후에는 next.Invoke()를 호출하거나 응답에 쓰려고 시도하지 마세요.

HttpResponse가 시작된 후에는 응답에 변경을 가하려고 하면 예외가 발생합니다.

예를 들어, 응답이 시작된 후 헤더나 상태 코드를 설정하려고 하면 예외가 발생합니다.

next.Invoke() 호출 후 응답 본문에 쓰는 것은 다음과 같은 문제를 야기할 수 있습니다:

• 프로토콜 위반: 명시된 Content-Length보다 더 많은 내용을 작성하는 것과 같은 프로토콜 위반을 초래할 수 있습니다.
• 본문 형식 손상: CSS 파일에 HTML 푸터(footer)를 작성하는 것처럼 본문 형식을 손상시킬 수 있습니다.

HasStarted 속성은 헤더가 전송되었는지 또는 본문이 작성되었는지 여부를 나타내는 유용한 힌트가 될 수 있습니다.

app.Use vs. app.Run

이 두 메서드는 파이프라인에 미들웨어를 추가하는 데 기본적이지만, 핵심적인 차이점이 있습니다:

app.Use(async (context, next) => { ... })

• 요청 수정 불가:
  마지막 단계이므로 요청을 다음으로 전달하기 전에 수정할 수 없습니다.
• 비종료(Non-Terminal) 미들웨어:
  이 유형의 미들웨어는 일반적으로 어떤 작업을 수행한 다음, next 델리게이트를 호출하여 파이프라인의 다음 미들웨어로 제어를 전달합니다.
• 요청/응답 수정 가능:
  요청을 다음으로 전달하기 전에 요청이나 응답을 변경할 수 있습니다.
• 예시:
  인증, 로깅, 커스텀 헤더 추가 등.

app.Run(async (context) => { ... })

• 종료(Terminal) 미들웨어:
  이 미들웨어는 next를 호출하지 않습니다.
  파이프라인을 종료하고 자체적으로 응답을 생성합니다.
• 최종 응답에 주로 사용:
  더 이상 처리가 필요 없는 요청(예: 간단한 메시지 반환)을 처리하는 데 일반적으로 사용됩니다.

// 여러 app.Run 호출의 결과

app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("Hello");
});

app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("Hello again");
});

app.Run(); // 이 app.Run은 위의 app.Run들이 이미 파이프라인을 종료했기 때문에 절대 실행되지 않습니다.

이 코드에서는 오직 첫 번째 app.Run 미들웨어만 실행됩니다.

“Hello”를 응답에 작성하여 파이프라인을 종료하고, 그 뒤의 app.Run (이것은 “Hello again”을 작성할 것임)은 실행될 기회를 얻지 못합니다.

// app.Use와 app.Run으로 미들웨어 체인 연결하기

// 미들웨어 1
app.Use(async (context, next) => {
    await context.Response.WriteAsync("Hello "); // 1. "Hello " 작성
    await next(context); // 2. 다음 미들웨어 호출
});

// 미들웨어 2
app.Use(async (context, next) => {
    await context.Response.WriteAsync("Hello again "); // 3. "Hello again " 작성
    await next(context); // 4. 다음 미들웨어 호출 (이 경우 app.Run)
});

// 미들웨어 3 (종료 미들웨어)
app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("Hello again"); // 5. "Hello again" 작성 후 파이프라인 종료
});

이 코드는 미들웨어를 올바르게 연결하는 방법을 보여줍니다.

1. 첫 번째 app.Use는 응답에 “Hello “를 작성하고 next를 호출하여 다음 미들웨어로 제어를 전달합니다.
2. 두 번째 app.Use는 “Hello again “을 작성하고 역시 next를 호출합니다.
3. 마지막 app.Run (종료 미들웨어)는 “Hello again”을 작성하고 파이프라인을 종료합니다.

ASP.NET Core의 커스텀 미들웨어

ASP.NET Core는 다양한 내장 미들웨어 구성 요소를 제공하지만, 때로는 애플리케이션 고유의 특정 요구 사항을 해결하기 위해 자신만의 커스텀 미들웨어를 만들어야 할 수도 있습니다.

커스텀 미들웨어를 통해 다음을 수행할 수 있습니다:

• 로직 캡슐화:
  관련 작업(예: 로깅, 보안 검사, 사용자 정의 헤더)을 재사용 가능한 구성 요소로 묶습니다.
• 동작 사용자 정의:
  애플리케이션의 요구 사항에 정확히 맞게 요청/응답 파이프라인을 조정합니다.
• 코드 구성 개선:
  미들웨어 코드를 깔끔하고 유지 관리하기 쉽게 만듭니다.

커스텀 미들웨어 클래스의 구조

IMiddleware 구현: 이 인터페이스는 단 하나의 메서드 InvokeAsync(HttpContext context, RequestDelegate next)를 요구합니다.

이 메서드는 미들웨어 로직의 핵심입니다

InvokeAsync 또는 Invoke 메서드

• context:
  HttpContext는 요청 및 응답 객체에 대한 접근을 제공합니다.
• next:
  RequestDelegate는 파이프라인의 다음 미들웨어를 호출할 수 있도록 합니다.

// MyCustomMiddleware.cs
namespace MiddlewareExample.CustomMiddleware
{
    public class MyCustomMiddleware : IMiddleware // IMiddleware 인터페이스 구현
    {
        public async Task InvokeAsync(HttpContext context, RequestDelegate next)
        {
            await context.Response.WriteAsync("My Custom Middleware - Starts\n"); // 1. 응답 시작 부분에 출력
            await next(context); // 2. 다음 미들웨어 호출
            await context.Response.WriteAsync("My Custom Middleware - Ends\n"); // 3. 다음 미들웨어 완료 후 응답 끝 부분에 출력
        }
    }

    // 쉽게 등록하기 위한 확장 메서드
    public static class CustomMiddlewareExtension
    {
        public static IApplicationBuilder UseMyCustomMiddleware(this IApplicationBuilder app)
        {
            return app.UseMiddleware<MyCustomMiddleware>();
        }
    }
}

// Program.cs (또는 Startup.cs)
using MiddlewareExample.CustomMiddleware;

// ... (다른 설정 코드) ...

builder.Services.AddTransient<MyCustomMiddleware>(); // 트랜지언트 서비스로 등록

app.Use(async (HttpContext context, RequestDelegate next) => {
    await context.Response.WriteAsync("From Middleware 1\n"); // 첫 번째 미들웨어: 시작 부분
    await next(context);
});

app.UseMyCustomMiddleware(); // 확장 메서드를 사용하여 커스텀 미들웨어 추가

app.Run(async (HttpContext context) => {
    await context.Response.WriteAsync("From Middleware 3\n"); // 세 번째 미들웨어: 파이프라인 종료
});

• 등록:
  ASP.NET Core가 필요할 때 MyCustomMiddleware 인스턴스를 생성할 수 있도록 이를 트랜지언트 서비스로 등록합니다.
• 파이프라인 통합:
  app.UseMyCustomMiddleware() 확장 메서드는 커스텀 미들웨어를 파이프라인에 추가합니다.
• 실행 순서:
  미들웨어 구성 요소는 파이프라인에 추가된 순서대로 실행됩니다. 이 경우 순서는 미들웨어 1, MyCustomMiddleware, 그리고 미들웨어 3이 됩니다.

커스텀 컨벤셔널 미들웨어 (Custom Conventional Middleware)

ASP.NET Core 미들웨어에는 두 가지 유형이 있습니다: 컨벤셔널(Conventional)과 팩토리 기반(Factory-based)

예시에서 보여진 컨벤셔널 미들웨어는 HTTP 요청 및 응답 처리를 위한 커스텀 로직을 캡슐화하는 간단하면서도 강력한 방법입니다.

주요 특징

• 클래스 기반:
  컨벤셔널 미들웨어는 클래스로 구현됩니다.
• 생성자 주입:
  의존성(있는 경우)을 생성자를 통해 받습니다.
• Invoke 메서드:
  이 메서드는 각 요청을 처리하는 로직을 포함하는 미들웨어의 핵심입니다.
• RequestDelegate:
  Invoke 메서드는 RequestDelegate 매개변수(_next로 명명)를 받습니다. 이 델리게이트는 파이프라인의 다음 미들웨어를 나타냅니다.
• 유연성:
  Invoke 메서드 내에서 요청 및 응답 객체를 완벽하게 제어할 수 있습니다.

// NameConcatenationMiddleware.cs
public class NameConcatenationMiddleware
{
    private readonly RequestDelegate _next;

    public NameConcatenationMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (context.Request.Query.ContainsKey("firstname") &&
            context.Request.Query.ContainsKey("lastname"))
        {
            string fullName = $"{context.Request.Query["firstname"]} {context.Request.Query["lastname"]}";
            await context.Response.WriteAsync(fullName);
            return; // 명시적으로 반환하여 다음 미들웨어 호출 방지
        }
        
        await _next(context);
    }
}

// MiddlewareExtensions.cs
public static class MiddlewareExtensions
{
    public static IApplicationBuilder UseNameConcatenation(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<NameConcatenationMiddleware>();
    }
}

미들웨어 파이프라인의 이상적인 순서

미들웨어의 순서는 애플리케이션의 동작과 효율성, 보안에 큰 영향을 미칩니다.

다음은 일반적으로 권장되는 이상적인 순서입니다

예외/오류 처리(Exception/Error Handling):

• 목적: 파이프라인의 어느 곳에서든 발생하는 예외를 Catch하고 처리합니다.
• 예시: UseExceptionHandler (프로덕션용), UseDeveloperExceptionPage (개발 환경용).
• 이유: 예외를 초기에 Catch하여 파이프라인 아래로 전파되어 더 큰 문제를 일으키는 것을 방지합니다.

HTTPS 리디렉션(HTTPS Redirection):

• 목적: 보안을 위해 HTTP 요청을 HTTPS로 리디렉션합니다.
• 예시: UseHttpsRedirection.
• 이유: 보안을 최우선으로 하여 모든 통신이 암호화되도록 합니다.

정적 파일(Static Files):

• 목적: 이미지, CSS, JavaScript 파일과 같은 정적 파일을 클라이언트에게 직접 제공합니다.
• 예시: UseStaticFiles.
• 이유: 정적 파일 요청은 빠르게 처리되어야 하며, 불필요하게 파이프라인의 다른 무거운 구성 요소를 거치지 않도록 일찍 처리합니다.

라우팅(Routing):

• 목적: URL을 기반으로 들어오는 요청을 특정 엔드포인트에 매칭합니다.
• 예시: UseRouting, UseEndpoints.
• 이유: 라우팅은 애플리케이션의 핵심 로직이 요청을 어떻게 처리할지 결정하는 기반이 됩니다.

CORS (Cross-Origin Resource Sharing):

• 목적: 다른 도메인으로부터의 안전한 교차 출처(cross-origin) 요청을 가능하게 합니다.
• 예시: UseCors.
• 이유: 인증/인가 전에 위치하여, 사전 요청(preflight request)이 불필요하게 인증/인가 미들웨어를 거치지 않도록 합니다.

인증(Authentication):

• 목적: 사용자 신원을 확인하고 사용자 주체(principal)를 설정합니다.
• 예시: UseAuthentication.
• 이유: 사용자가 누구인지 확인한 후에 리소스에 대한 접근 권한을 부여할 수 있습니다.

인가(Authorization):

• 목적: 사용자가 특정 리소스에 접근하거나 특정 작업을 수행할 수 있는지 여부를 결정합니다.
• 예시: UseAuthorization.
• 이유: 인증된 사용자에게만 권한 부여 여부를 검사합니다.

커스텀 미들웨어(Custom Middleware):

• 목적: 로깅, 기능 플래그 등 애플리케이션별 미들웨어 구성 요소를 처리합니다.
• 이유: 애플리케이션별 로직을 적절한 단계에서 파이프라인 내에 배치합니다.

MVC/Razor Pages/Minimal APIs:

• 목적: 실제 애플리케이션의 최종 엔드포인트 처리 로직을 실행합니다.
• 예시: MapControllers(), MapRazorPages(), MapGet() 등.

Program.cs 파일에 미들웨어 구성 요소가 추가되는 순서는 요청 시 미들웨어 구성 요소가 호출되는 순서를 정의하며, 응답 시에는 역순으로 호출됩니다.

이러한 순서는 보안, 성능 및 기능에 매우 중요합니다.

Program.cs의 다음 강조 표시된 코드는 보안 관련 미들웨어 구성 요소를 일반적으로 권장되는 순서로 추가하는 예시입니다:

using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
using WebMiddleware.Data;

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
// app.UseCookiePolicy();

app.UseRouting();
// app.UseRateLimiter();
// app.UseRequestLocalization();
// app.UseCors();

app.UseAuthentication();
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();

app.MapRazorPages();
app.MapDefaultControllerRoute();

app.Run();

UseWhen()

UseWhen()은 ASP.NET Core의 IApplicationBuilder 인터페이스에 있는 강력한 확장 메서드입니다.

이는 조건(predicate)에 따라 미들웨어를 요청 파이프라인에 조건부로 추가할 수 있도록 합니다.

즉, 특정 조건이 충족될 때만 특정 미들웨어 구성 요소가 실행되는 동적인 파이프라인을 만들 수 있습니다.

app.UseWhen(
    context => /* 여기에 조건 */, // HttpContext를 받아 true/false 반환
    app => /* 이 분기에서 실행될 미들웨어 구성 */ // 조건이 true일 때 실행될 미들웨어 파이프라인
);

• context:
  현재 요청을 나타내는 HttpContext 객체입니다.
• Predicate (조건):
  HttpContext를 받아들이고 미들웨어 분기가 실행되어야 할 경우 true를, 그렇지 않을 경우 false를 반환하는 함수입니다.
• Middleware Configuration (미들웨어 구성):
  조건이 true일 때 실행되어야 할 미들웨어 구성 요소를 구성하는 액션입니다.
  여기서 app.Use(), app.Run(), 또는 다른 미들웨어 등록 메서드를 사용합니다.

UseWhen() 작동 방식

• 조건 평가:
  요청이 들어오면 UseWhen() 메서드는 먼저 HttpContext에 대해 조건 함수를 평가합니다.
• 분기(조건이 true일 경우):
  조건이 true를 반환하면, 구성 액션에 지정된 미들웨어 분기가 실행됩니다.
  요청은 이 분기를 통해 흐르며, 수정되거나 응답을 생성할 수 있습니다.
• 메인 파이프라인 재진입:
  분기가 실행된 후(또는 조건이 false여서 건너뛰어진 경우), 요청 흐름은 메인 파이프라인으로 다시 진입하여 UseWhen() 호출 뒤에 등록된 다음 미들웨어 구성 요소로 계속 진행됩니다.

app.UseWhen(
    context => context.Request.Query.ContainsKey("username"), // 조건: 쿼리 문자열에 "username"이 있는지 확인
    app => {
        app.Use(async (context, next) =>
        {
            await context.Response.WriteAsync("Hello from Middleware branch\n"); // 분기 미들웨어: "Hello from Middleware branch" 작성
            await next(); // 다음 미들웨어 호출
        });
    });

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from middleware at main chain"); // 메인 파이프라인 미들웨어
});

• 조건:
  context.Request.Query.ContainsKey("username") 조건은 쿼리 문자열에 “username”이라는 매개변수가 포함되어 있는지 확인합니다.
• 분기 미들웨어:
  “username” 매개변수가 존재하면 분기 미들웨어가 실행됩니다.
  이 미들웨어는 응답에 “Hello from Middleware branch”를 작성하고 next를 호출하여 나머지 파이프라인이 계속되도록 합니다.
• 메인 파이프라인:
  마지막 app.Run 미들웨어는 메인 파이프라인의 일부입니다.
  이는 응답에 “Hello from middleware at main chain”을 작성합니다.

UseWhen() 사용 시점

• 조건부 기능:
  요청에 따라 특정 기능을 활성화하거나 비활성화합니다 (예: 특정 사용자에게만 로깅, 쿼리 매개변수에 따른 캐싱 규칙 적용).
• 동적 파이프라인:
  다양한 요청에 맞춰 조정되는 파이프라인을 만듭니다 (예: 특정 경로에 대해 다른 인증 미들웨어).
• A/B 테스트:
  실험을 위해 사용자 하위 집합을 대체 미들웨어 분기를 통해 라우팅합니다.
• 디버깅 및 진단:
  개발 환경에서만 진단 미들웨어를 적용합니다.

The post ASP.NET Core의 미들웨어(Middleware) appeared first on 어제와 내일의 나 그 사이의 이야기.

개요

Microsoft.Extensions.Hosting 네임스페이스는 .NET 애플리케이션의 호스팅 모델(Hosting Model)을 제공하는 핵심 구성 요소입니다.

Host 클래스는 이 모델의 시작점 역할을 하며, 애플리케이션의 생명 주기(lifecycle), 구성(configuration), 의존성 주입(dependency injection, DI), 로깅(logging) 등 다양한 인프라 서비스를 중앙 집중식으로 관리합니다.

이 호스팅 모델은 ASP.NET Core 애플리케이션에서 시작되었지만, 현재는 콘솔 애플리케이션, 백그라운드 서비스, Windows 서비스, WPF 애플리케이션 등 다양한 종류의 .NET 애플리케이션에서 표준적인 방식으로 사용되고 있습니다.

1. Host 클래스의 목적과 역할

Host 클래스는 특정 애플리케이션 유형에 구애받지 않고, 공통적인 인프라 기능을 쉽게 통합하고 관리할 수 있도록 설계되었습니다.

• 생명 주기 관리: 애플리케이션의 시작(StartAsync) 및 종료(StopAsync)를 관리하고, 이 과정에서 필요한 서비스들이 올바른 순서로 초기화되고 정리될 수 있도록 합니다.
• 의존성 주입 (DI): 애플리케이션 전반에 걸쳐 강력한 DI 컨테이너를 제공하여, 서비스 간의 느슨한 결합을 촉진하고 테스트 용이성을 향상시킵니다.
• 구성 (Configuration): appsettings.json, 환경 변수, 명령줄 인수 등 다양한 소스에서 설정을 로드하고 관리하는 일관된 방법을 제공합니다.
• 로깅 (Logging): 다양한 로깅 프로바이더(콘솔, 파일, 데이터베이스 등)를 쉽게 통합하고, 로깅 레벨을 유연하게 제어할 수 있도록 합니다.
• 백그라운드 서비스 (IHostedService): 장시간 실행되는 백그라운드 작업을 호스트의 생명 주기에 통합하여 관리할 수 있도록 합니다. 이는 API를 제공하지 않고 단순히 작업을 수행하는 서비스에 특히 유용합니다.

2. Host 클래스 핵심 인터페이스 및 메서드

Host 클래스 자체보다는, 이와 관련된 IHost 및 IHostBuilder 인터페이스를 이해하는 것이 중요합니다.

(1) IHostBuilder 인터페이스

IHostBuilder는 호스트를 구성(Configure)하는 데 사용되는 인터페이스입니다.

Host.CreateDefaultBuilder() 메서드가 반환하는 객체가 바로 IHostBuilder 타입입니다.

이 빌더를 통해 다음을 정의할 수 있습니다:

• ConfigureAppConfiguration:
  설정 소스(파일, 환경 변수 등)를 추가하거나 커스터마이징합니다.

.ConfigureAppConfiguration((context, config) =>
{
    config.AddJsonFile("custom.json", optional: true)
          .AddEnvironmentVariables()
          .AddCommandLine(args);
})

• ConfigureLogging:
  로깅 프로바이더(콘솔, 디버그, 파일 등)를 추가하고 로깅 필터링 규칙을 정의합니다.

.ConfigureLogging((context, logging) =>
{
    logging.AddConsole()
           .AddDebug()
           .SetMinimumLevel(LogLevel.Information);
})

• ConfigureServices:
  의존성 주입 컨테이너에 애플리케이션의 서비스들을 등록합니다.
  AddSingleton, AddScoped, AddTransient 등의 메서드를 사용하여 서비스의 생명 주기를 지정할 수 있습니다.

.ConfigureServices((context, services) =>
{
    services.AddSingleton<ISingletonService, SingletonService>();
    services.AddScoped<IScopedService, ScopedService>();
    services.AddTransient<ITransientService, TransientService>();
    services.AddHostedService<MyBackgroundService>();
})

• UseConsoleLifetime:
  콘솔 애플리케이션의 경우, Ctrl+C와 같은 콘솔 시그널을 감지하여 호스트를 정상적으로 종료하도록 설정합니다.
  (이는 Host.CreateDefaultBuilder()에 의해 기본적으로 포함됩니다.)
• Build():
  IHostBuilder에 정의된 모든 구성을 기반으로 최종 IHost 인스턴스를 생성합니다.

(2) IHost 인터페이스

IHost는 빌드된 호스트 인스턴스를 나타내며, 실제로 애플리케이션을 실행하고 관리하는 데 사용됩니다.

주요 메서드는 다음과 같습니다

• Services:
  등록된 모든 서비스 인스턴스에 접근할 수 있는 IServiceProvider를 제공합니다.
  이를 통해 런타임에 필요한 서비스를 resolve(가져오기)할 수 있습니다.
• StartAsync(CancellationToken cancellationToken):
  호스트를 비동기적으로 시작합니다. 이 메서드가 호출되면 등록된 모든 IHostedService 인스턴스의 StartAsync 메서드가 호출됩니다.
• StopAsync(CancellationToken cancellationToken):
  호스트를 비동기적으로 종료합니다. 등록된 모든 IHostedService 인스턴스의 StopAsync 메서드가 호출되어 리소스를 정리할 기회를 줍니다.
• RunAsync(CancellationToken cancellationToken = default):
  StartAsync를 호출하고, 호스트가 종료될 때까지 대기한 후 StopAsync를 호출합니다.
  대부분의 콘솔 애플리케이션에서 메인 실행 루프로 사용됩니다.

(3) IHostedService 인터페이스

IHostedService는 호스트의 생명 주기에 통합되어 백그라운드 작업을 수행하는 서비스들을 정의하는 인터페이스입니다.

StartAsync와 StopAsync 두 가지 메서드를 구현해야 합니다.

• StartAsync(CancellationToken cancellationToken):
  호스트가 시작될 때 호출됩니다. 장시간 실행되는 작업을 시작하는 데 사용됩니다.
• StopAsync(CancellationToken cancellationToken):
  호스트가 종료될 때 호출됩니다. StartAsync에서 시작된 작업을 정상적으로 중지하고 리소스를 정리하는 데 사용됩니다.

3. Host.CreateDefaultBuilder() 메서드의 이점

이 메서드는 많은 “관습(conventions)”을 제공하여 애플리케이션 초기 설정을 간소화하는 장점이 있습니다.

• 일관성:
  모든 .NET 애플리케이션 유형(웹, 콘솔, 백그라운드 서비스)에서 동일한 방식으로 인프라를 설정할 수 있게 하여 코드의 일관성을 유지합니다.
• 생산성:
  설정, 로깅, DI 등 반복적인 초기화 코드를 작성할 필요 없이 바로 비즈니스 로직에 집중할 수 있도록 합니다.
• 확장성:
  기본 설정을 사용하면서도 ConfigureAppConfiguration, ConfigureServices 등의 메서드를 통해 언제든지 필요에 따라 커스터마이징하고 확장할 수 있습니다.
• 테스트 용이성:
  DI 컨테이너를 중심으로 설계되어, 단위 테스트 및 통합 테스트에서 의존성을 쉽게 Mocking하거나 대체할 수 있습니다.
  참고: Mocking – 테스트 코드 작성 시 가짜 객체(Mock)를 만들어 실제 객체 대신 사용하는 기법

예시 코드: 콘솔 애플리케이션에서 Host 사용하기

콘솔 애플리케이션에서 Host 클래스를 사용하여 백그라운드 서비스(카운터)를 실행하고, 설정 및 로깅을 사용하는 예제

• Microsoft.Extensions.Hosting NuGet 패키지를 설치

dotnet add package Microsoft.Extensions.Hosting

• appsettings.json 파일을 추가하고 내용을 작성합니다.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AppConfig": {
    "IntervalSeconds": 2
  }
}

• Services/MyBackgroundService.cs (커스텀 IHostedService 구현):

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Configuration; // IConfiguration 주입을 위해 추가
using System;
using System.Threading;
using System.Threading.Tasks;

namespace MyConsoleApp.Services
{
    // IHostedService를 구현하여 호스트의 생명 주기에 통합될 백그라운드 서비스를 정의합니다.
    public class MyBackgroundService : IHostedService, IDisposable
    {
        private readonly ILogger<MyBackgroundService> _logger;
        private readonly IConfiguration _configuration;
        private Timer? _timer;
        private int _executionCount = 0;
        private int _intervalSeconds;

        public MyBackgroundService(ILogger<MyBackgroundService> logger, IConfiguration configuration)
        {
            _logger = logger;
            _configuration = configuration;

            // appsettings.json에서 설정 값 읽기
            _intervalSeconds = _configuration.GetValue<int>("AppConfig:IntervalSeconds", 5); // 기본값 5초
        }

        // 호스트가 시작될 때 호출됩니다.
        public Task StartAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("MyBackgroundService가 시작되었습니다.");

            // 타이머를 설정하여 지정된 간격마다 DoWork 메서드를 호출합니다.
            _timer = new Timer(DoWork, null, TimeSpan.Zero, TimeSpan.FromSeconds(_intervalSeconds));

            return Task.CompletedTask; // 비동기 작업 시작을 알리고 즉시 반환
        }

        // 타이머에 의해 주기적으로 호출되는 실제 작업 메서드
        private void DoWork(object? state)
        {
            var count = Interlocked.Increment(ref _executionCount);
            _logger.LogInformation(
                "MyBackgroundService가 {count}번째 작업을 수행 중입니다. 현재 시간: {time}",
                count, DateTimeOffset.Now);
        }

        // 호스트가 종료될 때 호출됩니다.
        public Task StopAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("MyBackgroundService가 중지되고 있습니다.");

            // 타이머를 중지하고 리소스를 해제합니다.
            // Change(Timeout.Infinite, 0)은 타이머를 비활성화하는 표준 방법입니다.
            _timer?.Change(Timeout.Infinite, 0);

            _logger.LogInformation("MyBackgroundService가 중지되었습니다.");
            return Task.CompletedTask; // 작업 완료를 알립니다.
        }

        // 리소스 해제를 위한 Dispose 메서드 (IHostedService는 IDisposable을 구현하는 경우가 많음)
        public void Dispose()
        {
            _timer?.Dispose();
        }
    }
}

• Program.cs 구현:

using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using MyConsoleApp.Services; // MyBackgroundService를 사용하기 위해 추가
using System;
using System.Threading.Tasks;

namespace MyConsoleApp
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            Console.WriteLine("콘솔 애플리케이션 호스트가 시작됩니다. 종료하려면 Ctrl+C를 누르세요.");

            // 1. IHostBuilder 인스턴스 생성: Host.CreateDefaultBuilder()는 기본적인 구성(config, logging, DI)을 설정합니다.
            var builder = Host.CreateDefaultBuilder(args)
                // 2. 서비스 컨테이너 구성: 의존성 주입을 위한 서비스들을 등록합니다.
                .ConfigureServices((hostContext, services) =>
                {
                    // MyBackgroundService를 IHostedService로 등록합니다.
                    // 호스트가 시작될 때 StartAsync가 호출되고, 종료될 때 StopAsync가 호출됩니다.
                    services.AddHostedService<MyBackgroundService>();

                    // 여기에 다른 서비스들도 등록할 수 있습니다. 예:
                    // services.AddSingleton<IMyService, MyService>();
                    // services.AddScoped<IOtherService, OtherService>();
                })
                // 3. 로깅 구성 (선택 사항: CreateDefaultBuilder가 기본 설정 제공하지만, 커스터마이징 가능)
                .ConfigureLogging(logging =>
                {
                    logging.ClearProviders(); // 기본 로깅 프로바이더를 지우고 새로 추가하거나
                    logging.AddConsole();    // 콘솔 로거를 추가합니다.
                    // logging.AddDebug();    // 디버그 로거 추가
                });
                // 4. 기타 구성 (선택 사항: 파일 경로, 환경 등)
                // .UseContentRoot(Directory.GetCurrentDirectory())
                // .UseEnvironment("Development")
                // .ConfigureAppConfiguration((hostingContext, config) => {
                //    config.AddJsonFile("custom.json", optional: true);
                // });

            // 5. IHost 인스턴스 빌드: 구성된 빌더를 바탕으로 실제 호스트를 생성합니다.
            var host = builder.Build();

            // 6. 호스트 실행: 등록된 모든 IHostedService를 시작하고 애플리케이션 종료를 대기합니다.
            // Ctrl+C 시그널을 감지하여 정상적으로 종료됩니다.
            await host.RunAsync();

            Console.WriteLine("콘솔 애플리케이션 호스트가 종료되었습니다.");
        }
    }
}

The post Microsoft.Extensions.Hosting, 호스팅 모델(Hosting Model) appeared first on 어제와 내일의 나 그 사이의 이야기.

CancellationToken, CancellationTokenSource

https://learn.microsoft.com/ko-kr/dotnet/api/system.threading.cancellationtokensource?view=net-9.0

개념 정리

CancellationToken과 CancellationTokenSource는 C#에서 비동기 작업(Task)이나 스레드를 안전하게 취소할 수 있도록 제공되는 기능합니다.

이를 활용하면 비동기 작업을 중단하거나, 긴 루프를 중지할 수 있도록 관리할 수 있습니다.

CancellationTokenSource

• 취소 요청을 생성하고 관리하는 역할을 합니다.
• CancellationToken을 생성할 수 있으며, Cancel() 메서드를 호출하면 해당 토큰을 통해 작업을 중단할 수 있습니다.

CancellationToken

• CancellationTokenSource에서 생성한 취소 토큰을 비동기 작업이나 스레드에 전달하여, 취소 여부를 확인하는 데 사용됩니다.

기본적인 사용법

CancellationToken 사용 예제

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        CancellationTokenSource cts = new CancellationTokenSource();
        CancellationToken token = cts.Token;

        Task task = DoWorkAsync(token);

        // 3초 후에 작업 취소 요청
        await Task.Delay(3000);
        cts.Cancel();

        await task;
    }

    static async Task DoWorkAsync(CancellationToken token)
    {
        for (int i = 0; i < 10; i++)
        {
            // 작업이 취소되었는지 확인
            if (token.IsCancellationRequested)
            {
                Console.WriteLine("작업이 취소되었습니다.");
                return;
            }

            Console.WriteLine($"작업 진행 중... {i}");
            await Task.Delay(1000); // 1초 대기
        }
    }
}

작업 진행 중... 0
작업 진행 중... 1
작업 진행 중... 2
작업이 취소되었습니다.

설명

1. CancellationTokenSource를 생성하여 CancellationToken을 가져옴
2. DoWorkAsync() 메서드에서 token.IsCancellationRequested를 통해 취소 여부 확인
3. Task.Delay(3000) 후 cts.Cancel()을 호출하여 비동기 작업을 취소

알아두면 유용한 기능

ThrowIfCancellationRequested()

이전의 예제에서는 IsCancellationRequested로 확인 후 return 했지만, ThrowIfCancellationRequested()를 사용하면 예외(Exception) 형태로 중단할 수도 있습니다.

static async Task DoWorkAsync(CancellationToken token)
{
    for (int i = 0; i < 10; i++)
    {
        token.ThrowIfCancellationRequested(); // 취소 요청 시 예외 발생

        Console.WriteLine($"작업 진행 중... {i}");
        await Task.Delay(1000);
    }
}

예외 처리 추가 (try-catch로 OperationCanceledException을 catch가 가능)

try
{
    await DoWorkAsync(token);
}
catch (OperationCanceledException)
{
    Console.WriteLine("작업이 취소되었습니다. (예외 발생)");
}

Task.Run()에서 CancellationToken

비동기 작업을 Task.Run()을 사용하여 실행하는 경우, CancellationToken을 직접 전달할 수 있습니다.

Task.Run()과 함께 사용할 경우, CancellationToken을 직접 전달하면 자동으로 OperationCanceledException이 발생하여 처리하기 편리합니다.

CancellationTokenSource cts = new CancellationTokenSource();

Task task = Task.Run(() => 
{
    for (int i = 0; i < 10; i++)
    {
        cts.Token.ThrowIfCancellationRequested();
        Console.WriteLine($"작업 진행 중... {i}");
        Thread.Sleep(1000);
    }
}, cts.Token); // CancellationToken을 직접 전달

await Task.Delay(3000);
cts.Cancel(); // 3초 후 취소

Register()를 활용한 CallBack 함수

CancellationToken.Register()를 사용하면, 취소될 때 특정 작업을 실행할 수 있습니다.

cts.Token.Register(() => Console.WriteLine("취소 요청이 감지되었습니다!"));

사용 예제

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        CancellationTokenSource cts = new CancellationTokenSource();
        CancellationToken token = cts.Token;

        // 취소 요청 시 실행될 콜백 등록
        token.Register(() => Console.WriteLine("취소 요청이 감지되었습니다!"));

        Task task = DoWorkAsync(token);

        await Task.Delay(3000);
        cts.Cancel(); // 3초 후 취소 요청

        await task;
    }

    static async Task DoWorkAsync(CancellationToken token)
    {
        for (int i = 0; i < 10; i++)
        {
            if (token.IsCancellationRequested)
            {
                Console.WriteLine("작업이 취소되었습니다.");
                return;
            }

            Console.WriteLine($"작업 진행 중... {i}");
            await Task.Delay(1000);
        }
    }
}

작업 진행 중... 0
작업 진행 중... 1
작업 진행 중... 2
취소 요청이 감지되었습니다!
작업이 취소되었습니다.

async와 CancellationToken을 활용한 HttpClient 요청 취소

HttpClient에서 CancellationToken을 사용하여 HTTP 요청을 중단할 수도 있습니다.

HttpClient 요청이 너무 오래 걸리면 CancellationToken을 이용해 요청을 취소할 수 있습니다.

using System;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        using (HttpClient client = new HttpClient())
        using (CancellationTokenSource cts = new CancellationTokenSource(TimeSpan.FromSeconds(2))) // 2초 후 자동 취소
        {
            try
            {
                HttpResponseMessage response = await client.GetAsync("https://example.com", cts.Token);
                Console.WriteLine("응답 수신 완료!");
            }
            catch (TaskCanceledException)
            {
                Console.WriteLine("HTTP 요청이 취소되었습니다.");
            }
        }
    }
}

CancelAfter()를 활용한 자동 취소

일정 시간이 지나면 자동으로 취소되도록 설정 가능 (CancelAfter(milliseconds))

cts.Token.Register(() => Console.WriteLine("취소 요청이 감지되었습니다!"));

사용 예제 (5초 후 자동 취소되는 코드)

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        CancellationTokenSource cts = new CancellationTokenSource();
        cts.CancelAfter(5000); // 5초 후 자동 취소

        try
        {
            await DoWorkAsync(cts.Token);
        }
        catch (OperationCanceledException)
        {
            Console.WriteLine("작업이 시간 초과로 취소되었습니다.");
        }
    }

    static async Task DoWorkAsync(CancellationToken token)
    {
        for (int i = 0; i < 10; i++)
        {
            token.ThrowIfCancellationRequested();
            Console.WriteLine($"작업 진행 중... {i}");
            await Task.Delay(1000);
        }
    }
}

LinkedTokenSource를 사용하여 여러 토큰을 결합

여러 CancellationTokenSource를 결합하여 하나의 토큰으로 관리 가능

어느 하나라도 취소되면 전체 작업이 취소됨

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        CancellationTokenSource cts1 = new CancellationTokenSource();
        CancellationTokenSource cts2 = new CancellationTokenSource();

        // 두 개의 토큰을 하나로 결합
        using (CancellationTokenSource linkedCts = CancellationTokenSource.CreateLinkedTokenSource(cts1.Token, cts2.Token))
        {
            Task task = DoWorkAsync(linkedCts.Token);

            await Task.Delay(3000);
            cts1.Cancel(); // 하나의 토큰만 취소해도 작업 전체가 중단됨

            await task;
        }
    }

    static async Task DoWorkAsync(CancellationToken token)
    {
        for (int i = 0; i < 10; i++)
        {
            token.ThrowIfCancellationRequested();
            Console.WriteLine($"작업 진행 중... {i}");
            await Task.Delay(1000);
        }
    }
}

결과적으로 cts1.Cancel(); 호출 시 linkedCts도 취소됨

Parallel.ForEach()에서 CancellationToken 적용

Parallel.ForEach()에서 CancellationToken을 사용하여 병렬 처리 도중 특정 조건에서 중단할 수도 있습니다.

ParallelOptions을 통해 취소 토큰을 설정하면 병렬 처리에서도 취소를 손쉽게 관리할 수 있습니다.

ParallelOptions options = new ParallelOptions
{
    CancellationToken = cts.Token,
    MaxDegreeOfParallelism = 4 // 최대 4개의 스레드 사용
};

try
{
    Parallel.ForEach(Enumerable.Range(1, 100), options, (num, state) =>
    {
        options.CancellationToken.ThrowIfCancellationRequested();
        Console.WriteLine($"Processing {num}");
        Thread.Sleep(500); // 가상의 작업
    });
}
catch (OperationCanceledException)
{
    Console.WriteLine("병렬 작업이 취소되었습니다.");
}

주의 사항

리소스 정리의 중요성

취소된 작업에서도 적절한 리소스 정리가 필요합니다.

try/finally 블록이나 using 문을 적절이 활용하는 것이 좋습니다.

static async Task ProcessFileAsync(string path, CancellationToken token)
{
    FileStream file = null;
    try
    {
        file = new FileStream(path, FileMode.Open);
        // 파일 처리 작업
        token.ThrowIfCancellationRequested();
    }
    catch (OperationCanceledException)
    {
        Console.WriteLine("파일 처리가 취소되었습니다.");
        throw;
    }
    finally
    {
        // 취소 여부와 상관없이 항상 실행됨
        file?.Dispose();
    }
}

CancellationToken 확인 빈도

장시간 실행되는 작업에서는 적절한 간격으로 취소 토큰을 확인하는 것이 중요합니다.

취소 토큰 확인은 가벼운 연산이지만, 매우 빈번하게 호출되는 코드에서는 성능에 영향을 줄 수 있습니다.

static void ProcessLargeData(IEnumerable<int> items, CancellationToken token)
{
    int count = 0;
    foreach (var item in items)
    {
        // 100개 항목마다 취소 여부 확인 (너무 자주 확인하면 성능 저하)
        if (count++ % 100 == 0 && token.IsCancellationRequested)
        {
            Console.WriteLine("작업이 취소되었습니다.");
            return;
        }
        
        // 항목 처리...
    }
}

CancellationTokenSource.Dispose() 중요성

CancellationTokenSource는 사용 후 수명이 끝나면 반드시 Dispose()를 호출해야 합니다. (메모리 누수)

using 문을 사용하는 것을 추천합니다.

using (var cts = new CancellationTokenSource())
{
    // 작업 수행
}
// 여기서 자동으로 cts.Dispose() 호출됨

공식 문서 사용 예제

// https://learn.microsoft.com/ko-kr/dotnet/api/system.threading.cancellationtokensource?view=net-9.0
using System;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;

public class Example
{
   public static void Main()
   {
      // Define the cancellation token.
      CancellationTokenSource source = new CancellationTokenSource();
      CancellationToken token = source.Token;

      Random rnd = new Random();
      Object lockObj = new Object();
      
      List<Task<int[]>> tasks = new List<Task<int[]>>();
      TaskFactory factory = new TaskFactory(token);
      for (int taskCtr = 0; taskCtr <= 10; taskCtr++) {
         int iteration = taskCtr + 1;
         tasks.Add(factory.StartNew( () => {
           int value;
           int[] values = new int[10];
           for (int ctr = 1; ctr <= 10; ctr++) {
              lock (lockObj) {
                 value = rnd.Next(0,101);
              }
              if (value == 0) { 
                 source.Cancel();
                 Console.WriteLine("Cancelling at task {0}", iteration);
                 break;
              }   
              values[ctr-1] = value; 
           }
           return values;
        }, token));   
      }
      try {
         Task<double> fTask = factory.ContinueWhenAll(tasks.ToArray(), 
         (results) => {
            Console.WriteLine("Calculating overall mean...");
            long sum = 0;
            int n = 0; 
            foreach (var t in results) {
               foreach (var r in t.Result) {
                  sum += r;
                  n++;
               }
            }
            return sum/(double) n;
         } , token);
         Console.WriteLine("The mean is {0}.", fTask.Result);
      }   
      catch (AggregateException ae) {
         foreach (Exception e in ae.InnerExceptions) {
            if (e is TaskCanceledException)
               Console.WriteLine("Unable to compute mean: {0}", 
                  ((TaskCanceledException) e).Message);
            else
               Console.WriteLine("Exception: " + e.GetType().Name);
         }
      }
      finally {
         source.Dispose();
      }
   }
}
// Repeated execution of the example produces output like the following:
//       Cancelling at task 5
//       Unable to compute mean: A task was canceled.
//       
//       Cancelling at task 10
//       Unable to compute mean: A task was canceled.
//       
//       Calculating overall mean...
//       The mean is 5.29545454545455.
//       
//       Cancelling at task 4
//       Unable to compute mean: A task was canceled.
//       
//       Cancelling at task 5
//       Unable to compute mean: A task was canceled.
//       
//       Cancelling at task 6
//       Unable to compute mean: A task was canceled.
//       
//       Calculating overall mean...
//       The mean is 4.97363636363636.
//       
//       Cancelling at task 4
//       Unable to compute mean: A task was canceled.
//       
//       Cancelling at task 5
//       Unable to compute mean: A task was canceled.
//       
//       Cancelling at task 4
//       Unable to compute mean: A task was canceled.
//       
//       Calculating overall mean...
//       The mean is 4.86545454545455.

The post C#의 CancellationToken, CancellationTokenSource appeared first on 어제와 내일의 나 그 사이의 이야기.