어떤 분산 파일 시스템을 사용해야 하는가?

발췌 :

http://helloworld.naver.com/helloworld/textyle/258077

 

우리는 하나의 데이터를 여러 서버가 공유할 때 분산 파일 시스템을 사용합니다. 최근에는 NFS나 CIFS와 같은 분산 파일 시스템 이외에도 비용이나 성능면 에서 경쟁력이 있는 많은 분산 파일 시스템을 쉽게 접할 수 있습니다. NHN에서도 NFS, CIFS 이외에 OwFS나 HDFS를 사용하고 있습니다. 그러나 각 분산 파일 시스템별로 장단점이나 특징이 있기 때문에 이를 잘 고려하여 선택한다면 좀 더 경쟁력 있는 인터넷 서비스를 만들 수 있을 것입니다. 이 글에서는 여러 분산 파일 시스템의 특징을 알아보고, 사례별로 적합한 분산 파일 시스템을 제시합니다.

어떤 분산 파일 시스템을 사용해야 하는가?

현재 NHN에서 사용하고 있는 분산 파일 시스템(Distributed File System)으로는 NFS(Network File System)와 CIFS(Common Internet File System), HDFS(Hadoop Distributed File System), OwFS(Owner-based File System)가 있다.

분산 파일 시스템이란 네트워크를 이용해 접근하는 파일 시스템을 말한다. 이러한 분산 파일 시스템의 장점은 여러 호스트에서 저장된 정보를 공유할 수 있다는 것이다. 2008년 이전 NHN에서는 NAS(Network Attached Storage)를 이용한 NFS와 CIFS만 이용했지만, 2008년 이후 자체 개발한 OwFS를 사용하기 시작하면서 OwFS의 이용량이 많아졌다. HDFS는 널리 알려졌다시피 Google의 GFS(Google File System)에 영향을 받아 만들어진 오픈소스 파일 시스템이다.

NFS나 CIFS를 사용할 때는 보통 고가의 스토리지 시스템인 NAS를 사용한다. 그렇기 때문에 용량을 증가시킬 때마다 높은 인프라 비용이 발생한다는 단점이 있다. 반면 OwFS와 HDFS는 상대적으로 저 비용의 하드웨어(commodity server)를 사용할 수 있게 만들어졌기 때문에 훨씬 더 낮은 비용으로 고용량 저장소를 구축할 수 있다.

그러나 모든 경우에 OwFS나 HDFS가 NAS를 사용하는 것이 NFS나 CIFS를 사용하는 것보다 유리한 것은 아니다. 목적에 따라서는 NAS를 사용해야 하는 경우도 있다. OwFS와 HDFS 또한 마찬가지다. 서로 다른 목적으로 만들어졌기 때문에 구현하려는 인터넷 서비스의 목적에 따라 적합한 파일 시스템을 선택할 필요가 있다.

그래서 이 글에서는 NHN에서 사용하는 대표적인 분산 파일 시스템의 특징을 설명하고, 어떤 분산 파일 시스템을 사용하는 것이 적합할지 설명하려 한다.

추가로 아직 NHN에서는 사용하고 있지 않지만, 최근 등장한 오픈소스 분산 파일 시스템과 Google에서 사용하고 있는 분산 파일 시스템, 그리고 전반적인 분산 파일 시스템의 발전 동향도 소개하겠다.

NFS와 CIFS

일반적으로 NFS(Network File System)는 Linux/Unix 환경에서, CIFS는 Micsrosoft Windows 환경에서 사용한다.

NFS는 1984년에 Sun Microsystems에서 개발한 분산 파일 시스템으로, 네트워크를 통하여 다른 호스트에 있는 파일을 공유해 사용할 수 있도록 한 것이다. NFS에는 여러 버전이 있는데, NFSv2부터 널리 사용되기 시작했고 현재 주류를 이루는 것은 NFSv3이다. 성능과 보안을 개선한 NFSv4가 2003년에 나왔으며, 2010년에는 클러스터 기반으로 확장할 수 있는 NFSv4.1이 발표되었다. NFS는 매우 오랜 역사를 지니고 있을 뿐 아니라, 현재까지도 지속적으로 발전하고 있는 분산 파일 시스템이라고 할 수 있겠다.

CIFS는 IBM에서 개발한 SMB(Server Message Block)를 바탕으로 보안 등의 기능을 개선해 Microsoft가 Windows에 적용한 분산 파일 시스템이다.

NFS와 CIFS는 POSIX 표준을 준수한다. 그렇기 때문에 NFS나 CIFS를 사용하는 애플리케이션은 로컬 파일 시스템처럼 분산 파일 시스템을 사용할 수 있다. 즉 애플리케이션을 구현하거나 가동할 때 로컬 파일 시스템과 분산 파일 시스템을 구별해 작성할 필요가 없다는 것이다.

많은 경우 NFS나 CIFS를 사용할 때는 성능과 가용성을 위해 NAS(Network Attached Storage)를 사용한다. NAS 자체에는 고유의 파일 시스템이 있고, NAS 게이트웨이가 NFS나 CIFS 프로토콜을 지원하도록 해 원격에서의 파일 접근 요청을 처리하도록 하고 있다.

일반적으로 NAS는 <그림 1>과 같은 구조를 가진다.

그림 1 일반적인 NAS의 구조

NFS나 CIFS의 특징은 다음과 같이 정리해 볼 수 있다.

• 로컬 파일 시스템과 동일한 기능 제공
• NAS를 사용하는 경우가 많기 때문에 NAS에 대한 높은 구매 비용 필요
• NAS는 OwFS와 HDFS에 비하여 확장성이 크게 떨어짐

OwFS(Owner-based File System)

OwFS는 NHN이 자체적으로 개발한 분산 파일 시스템으로, 현재 NHN에서 사용하는 분산 파일 시스템 중 가장 많이 사용하는 시스템이다.

OwFS는 Owner라고 하는 컨테이너 개념을 가지고 있는 것이 특징이다. Owner란 OwFS 내부에서 관리하는 메타데이터의 기본 단위다. OwFS에서는 이 Owner를 기반으로 데이터의 복제본을 관리한다. 각각의 Owner는 독립적인 파일 저장 공간을 가지고 있으며, 그 공간 안에 파일과 디렉터리를 저장할 수 있다. OwFS는 이 Owner들을 모아 하나의 커다란 파일 시스템을 구성하는 것이다. 사용자가 파일에 접근하기 위해서는 먼저 이 Owner에 대한 정보를 얻어야 한다.

OwFS의 전체적인 구조는 다음과 같다.

그림 2 OwFS 구조

OwFS의 Meta-Data Server(MDS)는 Data Server(DS)들의 상태를 관리한다. 구체적으로 MDS는 각 DS의 용량을 관리하고 장애가 발생했을 때 Owner들의 복제본을 이용해 복구 작업을 실행한다.

OwFS를 HDFS에 비교했을 때 장점은 많은 수의 파일을 효율적으로 처리할 수 있다는 것이다(주로 파일 하나가 수십 메가바이트 이내일 때). 왜냐하면 파일 개수가 많아지더라도 MDS의 부담이 커지지 않도록 설계했기 때문이다. Owner 내에 저장된 파일과 디렉터리에 대한 정보(즉, 파일과 디렉터리에 대한 메타데이터)는 DS가 직접 관리하고, MDS는 오직 Owner에 대한 정보와 해당 Owner에 대한 복제본의 위치 정보만 가지도록 하고 있다. 그렇기 때문에 파일 개수가 많아져도 MDS가 처리해야 하는 메타데이터가 증가하지 않고 MDS의 부담이 그리 커지지 않게 된다.

OwFS의 특징은 다음과 같이 정리해 볼 수 있다.

• Owner라는 컨테이너 개념. Owner는 하나의 파일 시스템이며 Owner가 모여 전체 파일 시스템을 이룬다.
• DS에 Owner 정보(파일 데이터와 메타데이터)를 저장
• 하나의 DS에 여러 Owner를 저장할 수 있고, Owner는 서로 다른 DS에 분산 저장(복제)돼 있음
• 복제본 위치를 포함한 Owner에 대한 위치 정보는 MDS(Metadata Data Server)에 저장
• 수십 메가바이트 이내의 많은 수의 파일을 처리하기에 적합함
• 모든 구성 요소가 이중화, 삼중화돼 있어 장애가 발생해도 안정적으로 동작함

OwFS는 자체적인 고유의 인터페이스(API)를 제공하고 있다. 그러나 OwFs_Fuse 모듈 또한 제공하기 때문에 NAS처럼 OwFS를 마운트해 로컬 디스크처럼 사용할 수도 있다. 또한 Apache 웹 서버에서 OwFS에 저장된 파일에 접근할 수 있도록 Apache 모듈도 제공하고 있다.

HDFS(Hadoop Distributed File System)

Google은 웹 페이지 정보를 크롤링해 저장할 수 있는 고유의 분산 파일 시스템인 GFS(Google File System)를 만들었다. Google은 2003년 이 GFS에 대한 정보를 논문으로 발표했고, HDFS는 GFS를 모델로 해서 만들어진 오픈소스다.

그렇기 때문에 HDFS는 GFS와 동일한 특징을 가진다. HDFS는 대용량의 파일을 청크(chunk)라는 단위로 분할해 데이터노드(Datanode)에 3개씩 분산 저장한다. 즉 하나의 파일이 분산된 여러 데이터노드에 저장되는 것이다. 하나의 파일에 대한 복제본이 3개씩 있고, 이 청크의 크기 단위는 보통 64MB다.

이 청크가 어느 데이터노드에 저장되었는지에 대한 메타데이터는 네임노드(Namenode)에 저장한다. 그리고 MapReduce 프레임워크를 이용해 분산 저장된 파일을 읽어 연산할 수 있도록 했다.

HDFS의 구성은 <그림 3>에서 볼 수 있다.

그림 3 HDFS 구조(원본 출처: http://hadoop.apache.org/docs/hdfs/current/hdfs_design.html)

HDFS의 네임노드는 모든 파일의 네임스페이스와 메타데이터, 파일의 청크 정보를 관리한다. 청크는 데이터노드에 저장하고, 이 데이터노드가 클라이언트로부터 오는 파일 연산 요청을 처리한다.

앞서 설명한 바와 같이 HDFS에서는 대용량 파일을 효과적으로 분산 저장할 수 있다. 그뿐만 아니라 청크 위치 정보를 기반으로 MapReduce 프레임워크를 이용해 연산마저 분산 처리할 수 있다.

OwFS에 비교해서 HDFS의 취약점은 많은 개수의 파일을 처리하기 적합하지 않다는 것이다. 왜냐하면 네임노드에 병목 현상이 발생하기 때문이다. 파일의 개수가 많아지면 네임노드의 서비스 데몬에 OOM(Out of Memory)이 발생하여 데몬 프로세스가 종료되는 문제가 생긴다.

HDFS의 특징은 다음과 같이 정리해 볼 수 있다.

• 크기가 큰 파일이 청크 단위로 나뉘어 여러 데이터노드에 분산 복제 저장됨
• 청크 크기는 보통 64MB이고, 각각의 청크는 3개의 복제본이 존재하며, 서로 다른 데이터 노드에 청크가 저장됨
• 이 청크들에 대한 정보는 네임노드에 저장돼 있음
• 대용량의 파일을 저장하는 데 유리하며, 파일의 개수가 많으면 네임노드의 부담이 커짐
• 네임노드가 SPOF(Single Point Of Failure). 네임노드에 장애가 발생하면 운영 불가 상황이 발생하며 수동 복구 필요

HDFS는 Java로 작성돼 있기 때문에 제공하는 인터페이스(API)도 Java API다. 그러나 JNI(Nava Native Interface)를 이용한 C API도 사용할 수 있다. Hadoop 커뮤니티는 공식적으로 FUSE를 이용한 마운트를 제공하고 있지는 않다. 그러나 서드 파티에서 HDFS에 대한 FUSE 마운트 기능을 제공하고 있다.

HDFS를 이용할 때 가장 주의할 사항은 네임노드에 대한 장애 대비다. 네임노드에 장애가 발생하면 HDFS 자체를 이용할 수 없기 때문에 장애 발생 시간에 대한 고려가 필요하다.

표 1 OwFS와 HDFS비교

사례로 보는 알아보는 분산 스토리지 선택

사례 1

사용하는 파일의 크기가 그리 크지 않고(보통 수십MB 이내), 파일의 개수는 매우 많아질 가능성이 있다. 전체적으로 약 10~100TB 정도의 용량이 필요할 것으로 예상한다. 그리고 한 번 저장된 파일이 변경되는 경우는 거의 없다.

분산 스토리지 선택

OwFS가 적합하다. 일단 파일의 크기가 크지 않고 그 수가 많아질 가능성이 높기 때문에 HDFS보다는 OwFS가 유리한 것이다. 파일 내용에 대한 변경이 없으며 전체적으로 필요한 용량도 수십TB 이상 되므로 NAS를 사용하는 것보다 비용 면에서 유리하다.

사례 2

웹 서버에서 생성되는 로그 파일을 저장하고 주기적으로 그 내용을 분석해야 한다. 로그 파일의 크기는 평균 1TB 정도며, 하루에 10개 정도 생성되고 유지 기간은 1개월이다.

분산 스토리지 선택

HDFS가 적합하다. 일단 파일의 크기가 크고, 개수가 그리 많지 않기 때문이다. 이런 대용량 파일을 분석할 때에는 HDFS를 사용하는 것이 좋다. 그러나 HDFS에서는 한 번 저장된 파일을 변경할 수 없다. 그렇기 때문에 하나의 로그 파일이 완전히 생성된 다음에 해당 파일을 HDFS에 저장해야 한다.

사례 3

웹 서버에서 생성되는 로그 파일을 저장하고 주기적으로 그 내용을 분석해야 한다. 로그 파일은 하루에 1개가 서버별로 따로 생성되며, 그 크기는 평균 100KB 정도다. 현재 로그를 수집해야 하는 서버는 10,000여 대이며 유지 기간은 100일이다.

분산 스토리지 선택

OwFS를 사용하는 것이 좋다. 100일간 유지해야 하기 때문에 파일 개수가 많아질 수 밖에 없고 로그 파일의 크기가 그리 크지 않기 때문이다. 분석 작업은 MapReduce 프레임워크로 할 수 있다. MFO(MapReduce Framework for OwFS)를 이용하면 OwFS에서도 MapReduce 프레임워크를 사용할 수 있다.

사례 4

각 사용자들은 여러 파일을 가질 수 있고, 이 사용자들이 자신이 가지고 있는 파일을 빠르게 검색할 수 있도록 파일 정보에 대한 인덱스를 구축하려 하는데, 이 인덱스 파일을 저장할 수 있는 스토리지가 필요하다. 파일이 추가되거나 삭제 또는 변경될 때 인덱스 파일이 수정돼야 한다.

파일 개수가 많지 않은 경우 인덱스 파일의 크기는 작지만, 파일 개수가 많은 경우 인덱스 파일은 수백MB 이상으로 커질 수 있다. 전체 사용자 수는 약 10만 명 정도로 예상한다.

분산 스토리지 선택

NAS를 쓰는 것이 유리하다. 일반적으로 인덱스 파일은 자주 변경돼야 하는데, OwFS나 HDFS에서는 한 번 저장된 파일은 변경할 수 없기 때문이다.

OwFS의 경우 풀 모드(full mode)로 OwFS_FUSE를 사용하면 파일 변경 작업을 할 수 있다. 그러나 이 방식은 전체 파일을 읽어 파일을 변경하여 다시 쓰기를 하는 방식이다. 전체 파일에서 단 1바이트만 변경하더라도 말이다. 또한 전체 용량도 수십TB 정도라면 NAS를 이용한다 해도 많은 비용이 발생하지 않는다.

사례 5

약 1KB 크기의 파일이 1,000,000개 이상 된다. 전체적으로 필요한 용량은 3GB 정도다. 그리고 기존에 사용하던 디렉터리 구조를 바꾸기는 어렵다.

분산 스토리지 선택

NAS를 쓰는 것이 유리하다. OwFS_FUSE를 이용하면 로컬 파일 시스템만큼 유연한 디렉터리 구조를 사용할 수 있지만, 작은 파일이 많을 때는 NAS에 비해 성능이 떨어지는 경우도 있다. HDFS 또한 FUSE를 이용하여 HDFS를 마운트할 수 있지만, 많은 개수의 파일을 사용하는 데 적합하지 않다. 또한 필요한 전체 용량이 워낙 작기 때문에 NAS를 사용해도 운영 비용상의 문제가 발생하지 않는다.

사례 6

파일의 크기가 수 MB에서 수 GB 정도며 전체적으로 필요한 용량은 500TB 정도다. 디렉터리 구조는 바꾸지 않았으면 좋겠고, 파일의 내용 변경은 가끔 있을 수 있다.

분산 스토리지 선택

OwFS를 사용하는 것이 좋다. 500TB 정도의 대용량이 필요하다면 NAS는 비용상 적합하지 않다. 그리고 500TB 정도의 용량이라면 그만큼 파일의 개수 또한 많다는 것을 의미한다. 그러므로 HDFS보다는 OwFS가 유리하다. OwFS_FUSE를 이용해 사용하던 디렉터리 구조 그대로 사용할 수도 있겠지만, 성능을 위해서는 가급적 Owner가 잘 처리할 수 있는 디렉터리 구조 형태로 변경하는 것이 좋다. 파일의 내용을 변경할 때는, 애플리케이션 서버에서 파일을 읽어 변경한 후 애플리케이션 서버에서 OwFS에 덮어 쓰도록 하면 전체 시스템 부하가 커지지 않도록 할 수 있다.

분산 스토리지 선택 기준

사례별로 살펴 본 분산 스토리지 선택 기준을 다시 정리해 보면 다음 표와 같다.

표 2 OwFS, HDFS, NFS/CIFS 선택 기준

주목할 만한 분산 파일 시스템들

NHN에서는 사용하고 있지 않지만 주목할 만한 분산 파일 시스템을 소개하겠다. 여기서 소개할 분산 파일 시스템은 GFS2, Swift, Ceph 그리고 pNFS다. 이들을 간략하게 소개하고 그 특징을 설명하겠다.

GFS2

분산 파일 시스템 분야에서 Google의 GFS는 음악계의 서태지와 아이들이나 비틀즈와 같다. HDFS를 비롯해 많은 분산 파일 시스템이 GFS에 영향을 받아 만들어졌기 때문이다.

그러나 이 GFS에도 커다란 구조적인 단점이 있는데, 바로 네임노드의 장애 취약성이다. GFS는 HDFS와 달리 슬레이브 네임노드가 있다. 그래서 GFS는 HDFS에 비해 장애에 덜 취약하다. 그러나 슬레이브 네임노드가 있더라도 마스터 네임노드에 장애가 발생했을 때 절체 시간이 짧지 않다.

그리고 파일 개수가 많아지면 메타데이터의 양 또한 많아지게 돼, 처리 속도가 저하될 뿐만 아니라 마스터 서버의 메모리 크기 제한 때문에 사용할 수 있는 전체 파일 개수에 제한이 발생한다는 문제 또한 있다.

청크 크기가 보통 64MB인데 이보다 작은 데이터를 저장하는 데 너무 비효율적이다. 물론 청크 크기를 줄일 수 있지만 청크 크기를 줄이면 그만큼 많은 메타데이터가 생성되기 때문에 64MB보다 작은 크기의 파일이 많다고 하더라도 청크 크기를 줄이기 어려운 문제가 있었다.

GFS2는 이러한 GFS의 단점을 극복한 것이다. GFS2는 GFS보다 훨씬 더 발전된 메타데이터 관리 방법을 사용한다. GFS2의 네임노드는 싱글 마스터가 아니라 분산 구조를 따르고 있다. 그리고 메타데이터는 수정이 가능한 BigTable과 같은 데이터베이스에 저장한다. 이러한 방법으로 파일 개수의 제한이나 네임노드 장애 취약성을 개선했다.

처리할 수 있는 메타데이터의 양을 손쉽게 늘릴 수 있게 되다 보니 청크 크기를 1MB로 줄일 수 있다고 한다. 이 GFS2의 구조는 현재 대부분의 분산 파일 시스템이 가지고 있는 구조를 개선하는 방향에 많은 영향을 줄 것으로 보인다.

Swift

Swift는 OpenStack에서 사용하는 분산 객체 저장소(Object Storage)로 Rackspace Cloud 등에서 이용하고 있다. Swift는 Amazon S3와 같이 마스터 서버를 따로 두지 않는 구조를 사용하는 것이 특징이다. 파일을 관리하기 위해 Account, Container, Object라는 3단계 객체 구조를 사용하고 있다. Account 객체는 계정과 같은 개념으로 Container 객체를 관리하는 객체다. Container 객체는 디렉터리와 같이 Object 객체를 관리는 객체로 Amazon S3의 bucket과 같은 것이다. Object 객체는 파일에 해당하는 객체로 이 Object 객체에 접근하려면 Account 객체와 Container 객체에 차례로 접근해야 한다. Swift는 REST API를 제공하며 이 REST API 제공을 위해 프락시 서버를 따로 두고 있다. 원하는 객체가 할당된 위치를 결정할 때 미리 정한 정적 테이블을 이용하는데, 이것을 Ring이라고 한다. Swift 내의 모든 서버들은 이 Ring 정보를 공유하고 원하는 객체의 위치를 찾아가게 된다.

Swift는 최근 OpenStack의 빠를 발전과 많은 대형 회사들의 참여로 점점 많은 주목을 받고 있다. 국내에서도 kt가 OpenStack에 참여하고 있으며 kt ucloud를 Swift를 이용해 서비스하고 있다.

Ceph

Ceph는 분산 파일 시스템으로 메타데이터를 관하는 방식이 독특하다. 메타데이터 서버를 이용해 전체 파일 시스템의 네임스페이스와 메타데이터를 관리하는 것은 다른 분산 파일 시스템과 비슷하지만, 메타데이터 서버들이 클러스터 형태로 동작하며 동적으로 부하 정도에 따라 메타데이터별로 담당하는 네임스페이스 영역을 조정할 수 있다는 것이 특징이다. 이를 통해 부하가 일부에 집중되는 경우에도 쉽게 대처할 수 있으며 쉽게 메타데이터 서버를 확장할 수 있다. 그뿐만 아니라 다른 분산 파일 시스템과 달리 POSIX와 호환하기 때문에 분산 파일 시스템에 저장된 파일에 접근할 때 로컬 파일 시스템처럼 접근할 수 있다는 것이 장점이다.

REST API도 지원하며 Swift나 Amazon S3의 REST API와도 호환이 가능하다.

Ceph를 주목해야 하는 이유는 Linux 커널 소스(kernel source)에 포함돼 있다는 것이다. 아직 출시된 버전이 그리 높지는 않지만, Linux의 발전과 더불어 미래에 Linux의 주력 파일 시스템이 될 수 있는 가능성이 있다는 것이다. 그리고 POSIX 호환 형태이고 커널 마운트를 지원하는 것도 큰 매력이라 할 수 있다.

pNFS(Parallel Network File System)

앞서 설명했듯이 NFS에는 여러 버전이 있다. NFSv4까지의 확장성 문제를 해결하기 위해 NFSv4.1는 pNFS 기능을 도입하였다. 파일 내용과 파일의 메타데이터를 분리해 처리할 수 있도록 했으며, 하나의 파일을 여러 곳에 나눠 분산 저장하는 기능도 제공한다. 클라이언트는 어떤 파일에 대한 메타데이터를 가져와 해당 파일의 위치를 알게 되면, 이후 같은 파일에 접근할 때 파일의 내용을 가지고 있는 서버에 연결할 수 있도록 했다. 이때 여러 서버에 존재하는 파일의 내용을 병렬적으로 읽거나 쓸 수 있다. 그리고 메타데이터를 관리하는 메타데이터 서버도 병목현상이 발생하지 않도록 쉽게 확장할 수 있는 기능을 지원한다.

최근 분산 파일 시스템의 트렌드를 반영하여 NFS가 발전한 것이다. 그래서 pNFS는 기존 NFS의 장점을 계승하면서도 최근 분산 파일 시스템의 장점을 가지고 있다고 할 수 있다. 현재 제한적이지만 pNFS 기능을 지원하는 제품들이 나오고 있다.

pNFS를 주목해야 하는 이유의 하나는 현재 NFS 자체를 Oracle(Sun)이 아닌 IETF(Internet Engineering Task Force)에서 관리하고 있다는 것이다. NFS는 여러 Linux/Unix에서 표준처럼 사용하고 있기 때문에, 여러 벤더에서 이 pNFS를 지원하는 제품을 출시하여 pNFS 사용이 대중화될 수 있다는 것이다.

결론

지금까지 여러 분산 파일 시스템에는 고유의 특징이 있으며 비즈니스 요구 사항에 따라 적합한 분산 파일 시스템을 적용해야 한다는 것에 대해 알아보았다. 또한 새롭게 주목받기 시작하고 있는 분산 파일 시스템을 소개함으로써 새로운 트렌드와 참고할 만한 사항들을 설명했다.