[SAA-C03] 2. Storage

 

Storage Type

• File Storage
  • 데이터를 파일단위로 저장, 관리하는 방식
  • 파일 시스템을 통해 접근 가능, 파일 경로를 통해 파일을 식별 가능
  • 장점 : 사용 및 관리 용이, 기존 어플리케이션과 호솬성이 좋다.
  • 단점 : 대규모데이터를 처리하는데에 비효율적일 수 있다. 파일시스템의 제약을 받는다.
• Block Storage
  • 데이터를 고정된 크기의 블럭 단위로 나누어 저장한다.
  • 각 블록은 고유 식별자를 가지며, 블록 단위로 데이터를 읽고 쓴다.
  • 장점 : 높은 성능과 확장성 제공, 데이터의 빠른접근 가능
  • 단점 : 블록 단위로 파일이 나뉘어져있으므로 관리 및 설정이 복잡할 수있다.
• Object Storage
  • 데이터를 오브젝트 단위로 저장, 각 오브젝트는 고유한 식별자와 메타 데이터를 갖는다.
  • 장점 : 무한에 가까운 확장성 제공, 메타 데이터를 통해 데이터 관리가 용이
  • 단점 : 지연 시간이 길 수 있다. 데이터 업데이트가 비효율적일 수 있다.

Amazon S3 (Simple Storage Service)

• S3는 AWS의 오브젝트 스토리지
  • 실제로는 폴더 구조가 아니지만, 슬러쉬 문자열(/)을 구분자로 판단하여 관리자 콘솔에서는 폴더구조처럼 표시된다.
  • 높은 내구성 → 장애복구를 위해 기본적으로 3개 이상의 AZ에 복제된다.
    • S3의 구조 : 버킷, 키(prefix + object)로 구성되어 있다.
    • e.g. 인프라 가동 실패, 데이터 센터 보안 침해
  • s3 한 버킷에 저장될 수 있는 오브젝트의 개수는 무한대이고, 각 오브젝트는 5TB를 넘지 못한다.
    • 개별 버킷 또는 계정 내 모든 버킷에 업로드할 수 있는 용량 제한은 없다. (각 오브젝트 별 용량제한은 5TB)
    • 업로드 횟수 제한 없음
    • 하지만 계정당 S3 버킷 개수는 최대 100개로 제한됨
• S3의 구조 : 버킷, 키(prefix + object)로 구성되어 있다.

S3의 경로

1. prefix : 그룹화하려면 객체에 공통적으로 붙이는 이름
2. bucketname이라는 이름의 S3 버킷에 퍼블릭 접근이 가능한 filename이라는 이름의 파일이 있다. 이때 웹브라우저를 통해 접근할 수 있는 파일의 주소

Storage Class

Standard Storage Class

S3에 저장된 오브젝트 이용 빈도 및 가용성에 따라, S3 이용 유형이 나뉜다.

• S3 Standard
  • 잦은 오브젝트 액세스가 일어날 때 사용
  • 기본적으로 3개 이상의 AZ에 오브젝트를 복제된다.
• S3 Standard-IA(Infrequent Access)
  • 스탠다드보다 저장된 오브젝트의 이용 빈도가 적다.
  • 이 유형에도 기본적으로 3개 이상의 AZ에 오브젝트를 복제된다.
  • 99.9%의 가용성을 보장한다.
• S3 One Zone-IA(Infrequent Access)
  • 스탠다드 IA와 마찬가지로, 오브젝트에 접근하는 빈도가 적다.
  • 오직 1개의 AZ에 오브젝트를 복제된다.
  • 비용이 적게든다.
• S3 Intelligent - Tiering
  • 저장된 오브젝트의 이용 빈도를 현재는 정확히 모를 때, AWS에서 이용빈도를 체크해서 스토리지 클래스를 자동으로 변환해준다.
  • 기본적으로 3개의 AZ에 오브젝트를 복제한다.
• Reduced Redundancy Storage (RRS)
  • 낮은 내구성
  • 사본의 수를 줄여 비용을 절감(20%)
  • 원본 이외의 데이터를 저장할 때 사용
  • One Zone-IA 데이터와 Reduce Redundancy 데이터의 차이점

Glacier Storage Class

Glacier → 잘 사용하지 않는 오브젝트를 아카이빙하는 용도. 사용빈도에 따라 나뉜다.

• S3 Glacier Instant Retrieval
  • Glacier에 아카이빙을 한 후, 즉각적으로 조회가 가능해야하는 오브젝트에 사용
  • 저장 비용이 비싸다 ⬆️
• S3 Glacier Flexible Retrieval
  • 인스턴트보다 좀 더 조회에 지연에 있어도 되는 오브젝트의 저장에 사용
• S3 Glacier Deep Archive
  • 아카이빙을 더 깊게 해서, 조회 시간이 더 오래 걸리는 오브젝트를 저장할 때 사용
  • 저장 비용이 가장 저렴하다 ⬇️ (MOST Cost-Effecive)

S3 스토리지 vs Glacier 아카이브

	S3	Glacier
저장 용량	용량 제한 없음	최대 40TB
데이터 암호화	옵션으로 선택한다.	아카이브 생성 시 기본적으로 저장 데이터를 암호화한다.
형식	사람이 읽기 쉬운 키 이름을 제공한다.	아카이브 이름은 기계 생성 ID 형식을 가진다.
데이터 인출 시간	거의 즉각적으로 객체를 인출할 수 있다	객체를 인출하는 데는 수 시간이 소요될 수 있다. +) 별도의 이용료를 지불한 뒤, 수 분만에 데이터를 인출할 수 있는 촉진 인출(Expedited retrievals) 옵션을 제공한다.
가격	비교적 비싸다	비교적 저렴하다
내구성	99.999999999%	99.999999999%

 

S3 Intelligent-Tiering(S3 지능형 계층화)

• 자동 계층 이동
  • 데이터 액세스 빈도를 자동으로 모니터링하고, 이에 따라 데이터를 가장 비용 효율적인 계층으로 이동
  • 계층별로 저장 비용이 다르다.
    • Frequent Access Tier > Infrequent Access Tier > Archive Access Tier > Deep Archive Access Tier
• 계층 구조
  •  
  • Frequent Access Tier (빈번한 액세스 계층)
    • 데이터를 자주 읽는 경우.
    • S3 Standard와 동일한 비용.
  • Infrequent Access Tier (드문 액세스 계층)
    • 데이터를 30일 이상 읽지 않을 경우 이동.
    • 저장 비용이 낮음.
  • Archive Access Tier (아카이브 액세스 계층)
    • 데이터를 90일 이상 액세스하지 않을 경우 이동.
    • 비용이 더 낮지만, 데이터를 액세스하려면 복원 시간이 필요.
  • Deep Archieve Access Tier(딥 아카이브 액세스 계층)
    • 데이터를 180일 이상 액세스하지 않을 경우 이동.
    • 가장 낮은 비용, 복원 시간이 길어짐.

• 비용 효율성
  • 사용자는 초기에는 Frequent Access Tier 비용을 지불하지만, 데이터가 30일 이상 액세스되지 않으면 자동으로 Infrequent Access Tier로 이동하여 저장 비용이 줄어든다.
• 사용환경
  • 예측할 수 없는 패턴의 데이터, 변화하는 데이터 액세스 패턴을 가진 데이터를 저장할 때 이상적이다. (아직 예측할 수 없는 데이터나 계속 불규칙한 데이터 패턴에도 적합하다.)

S3 Lifecycle management (수명주기 설정기능)

한 오브젝트가 처음 사용할 때는 사용빈도가 높았다가 → 한달 정도가 지나면 사용빈도가 줄어들고 → 1년이 지나면 아카이빙해야하는 오브젝트

• S3에서는 수명주기 설정기능을 제공
• 수명주기 규칙 정의 시 특정 접두사(prefix)를 지정한다.

⚠️주의해야하는 점
저비용 클래스로 이동하면, 표준 클래스로는 돌아갈 수 없다.

S3 Versioning (버전관리 설정)

• S3는 버킷에 저장된 오브젝트의 변경 이력을 모두 관리할 수 있는 버전관리 설정이 있다.
• 이를 통해 오브젝트가 변경된 이력을 모두 캡쳐 가능
• 버전관리 설정은 S3 버킷단위로 가능하고, 객체단위의 설정은 불가능하다.

• 버킷에 오브젝트 추가 → S3 버킷의 버전은 yyy에서 zzz로 versioning된다.
• 버킷에 오브젝트 삭제 → S3 버킷의 버전은 yyy에서 zzz로 versioning되고, Delete Marker를 둘 수 있다.
  • 만약 사용자가 오브젝트를 삭제한다면, 해당 오브젝트는 해당 버킷에서 보이지 않다.
• 버킷의 오브젝트 복구 → 해당 버킷의 버저닝을 이전으로 돌린다면 오브젝트를 복구할 수 있다.

S3 Replication(복제)

• Replication
  • SRR (Same Region Replicaion, 동일 리전 내 복제)
  • CRR (Cross Region Replication, 다른 리전 간 복제)
    • 다른 리전에 복제하는 경우에는 한 리전 전체가 장애가 발생했을 경우를 대비하여 다른 리전에 복제한다.
    • 데이터를 여러 리전의 S3 버킷 간에 복제할 수 있다.
  • Version control must be enbled(복제는 버전 관리가 활성화 되어야 가능하다)

S3 Access Control(접근 제어)

• IAM Policy
  • IAM으로 관리하는 방법
  • 사용자나 그룹에 대한 권한을 부여하거나 제한하여 S3에 리소스에 대한 접근 제어
• Bucket Policy
  • json document로 되어있다.
  • s3 버킷 및 객체에 대한 접근 권한을 설정하는 json document 로 정책을 지정할 수 있다.
  • 버킷 정책의 ‘principal’ = 신뢰 개체는 버켓에 대한 접근 권한을 부여한 개체를 의미
  • 버킷 정책에 OAI(원본 액세스 ID)를 설정 → OAI를 통해 요청이 전달될 때만 접근을 허용
  • OAI를 설정한 후, S3 버킷의 퍼블릭 접근을 완전히 차단하여, CloudFront를 경유하지 않은 직접 요청을 거부
• Block Public Access
  • 공개 액세스를 차단하는 방법
  • s3 버킷 및 객체에 대한 공용 액세스를 방지하여 실수로 노출되는 것을 방지한다.
  • e.g. IAM 정책이나 버켓 정책을 설정할 때, 그 설정이 잘못돼서 퍼블릭으로 액세스 되는 경우가 있는데 이를 사전에 방지하기 위해서 보안이 꼭 필요한 문서의 경우에는 퍼블릭 액세스를 차단할 수 있다.
• Pre-Signed URLs
  • 특정 s3 객체에 대한 제한된 시간동안의 접근을 허용하는 임시 URL을 만들 수 있다.
  • 타인공유에 유용
  • 프리사인 URL의 지속 시간 = 1시간 = 3600초
• S3 ACL(접근제어목록)
  • 과거에 널리 사용했던 레거시 기능이며 IAM 정책 또는 S3 버킷 정책보다 유연성이 떨어진다.
• S3 + CloudFront 사용하는 상황에서, S3에 직접 액세스하는 것을 막으려면 OAC or OAI 사용
  • OAI (Origin Access Identity)
    • CloudFront와 S3 버킷에 대한 접근을 프라이빗하게 연결하는 기능
    • 다른 사용자들이 S3 버킷의 URL로 직접 접근하지 못하고, CloudFront를 통해서만(S3 버킷에 접근할 수 있는 특수 사용자만) 콘텐츠를 접근하게 디어 보안이 강화된다.
  • OAC(Origin Access Control)
    • OAI의 업그레이드 버전으로, IAM Role을 사용해 더 세부적이고 유연한 보안 설정이 가능하다.
    • +) CloudFront에서의 배포 = 들어오는 트래픽을 처리하는 것과 응답하는 것을 모두 포함
• S3 버킷 - EC2 간 통신이 인터넷에 노출되지 않도록 ⇒ S3 Gateway Endpoint

Glacier Vault Lock & S3 Object Lock

Glacier Vault Lock

• S3 Glacier Vault Lock은 WORM(Write Once Read Many) 모델을 채택하여 데이터를 한 번 기록한 후에는 수정이나 삭제할 수 없도록 잠그는 기능.
• 이는 규정 준수와 데이터 보존을 목적으로 사용되며, 보존된 데이터를 무단으로 변경하거나 삭제할 수 없게 보호한다.
  • 일단 데이터가 Glacier 볼트에 저장되면, Vault Lock 정책이 적용되어 데이터는 삭제되지 않으며, 관리자조차도 이를 변경할 수 없다.
• 장기 데이터 보존이 필요한 금융, 의료 또는 정부 기관에서 매우 유용하다.
• Vault Lock 사용 과정
  • 1. 볼트 잠금 정책 생성 : 먼저 Gacier 볼트에 Vault Lock 정책을 설정한다.
  • 2. 정책 잠금 : 정책을 설정한 후 잠금하면, 이후에는 누구도 해당 정책을 변경하거나 삭제할 수 없다.

S3 Object Lock

• S3 객체 잠금(S3 Object Lock)은 Glacier Vault Lock보다 조금 더 복잡하지만, 유연한 데이터 보호를 제공한다.
• 이 기능은 특정 S3 버킷 내에서 각 객체에 대해 개별적으로 잠금을 설정할 수 있으며, 역시 WORM 모델을 기반으로 한다.
• S3 객체 잠금을 활성화하려면 먼저 버저닝(Versioning) 기능을 활성화해야 합니다. 이 기능을 통해 각 객체의 버전을 관리하며, 객체의 삭제 및 덮어쓰기를 방지할 수 있습니다.
• S3 객체 잠금은 두 가지 보존 모드를 제공합니다:
  1. 규정 준수 모드(Compliance Mode): 이 모드는 Glacier Vault Lock과 유사하게, 누구도 객체를 덮어쓰거나 삭제할 수 없습니다. 규정 준수 모드에서는 관리자조차도 보존 모드를 변경하거나 보존 기간을 단축할 수 없으며, 엄격한 데이터 보호가 필요할 때 사용됩니다.
  2. 거버넌스 모드(Governance Mode): 거버넌스 모드는 규정 준수 모드보다 유연합니다. 대부분의 사용자는 객체를 변경하거나 삭제할 수 없지만, 특별한 권한을 가진 관리자는 보존 기간을 변경하거나 객체를 삭제할 수 있습니다. 이는 규정 준수보다는 데이터 관리에 중점을 두고 있으며, 일부 유연성을 제공합니다.
  3. 이때 객체를 사용해야 하는 사용자의 IAM 정책에 S3:PutObjectLegalHold 권한을 추가한다.
• S3 Object Lock을 한 S3에 대한 권한 관리는 버킷정책으로 해야한다.

S3 Data Encryption(데이터 암호화)

서버측 암호화(SSE-S3, SSE-KMS, SSE-C)

서버측 암호화의 1,2

• 암호화키 - S3에서 관리하는 키 사용 or KMS(Key Managed Service)의 키를 사용
  • 요청을 통해 키로 암호화 하고, 암호화된 데이터를 받을 수 있다.
  • KMS key는 S3 key와 달리 세밀한 감사 추적 기능을 제공한다.
  • SSE-KMS보다 SSE-S3가 관리 운영 오버헤드가 더 적다
  • 키를 매년 자동으로 교체 할 수 있다.
  • 고객관리키가 SSE-KMS에 포함된다.
• 암호화 키 - 클라이언트 측에서 전달받은 키(Client-Side Data key)로 서버측에서 암호화
  • 사용자가 서버측에 요청할 때, 클라이언트 사이드 데이터 키와 함께 요청을 해야한다.
  • 오직 https로만 접근해야한다

클라이언트측 암호화(Customer-Managed Key)

• 클라이언트 측에서 암호화를 완료해서 S3로 전송하는 방식
  • 암호화 키가 aws로 전송되지 않고, 클라이언트측에서 키 수명 주기 관리를 모두 해주어야한다.
  • 암호화가 버킷에 저장되기 전에 이루어진다

고객 관리형 키(Customer-Managed Key) vs SSE-C(Server-Side Encryption with Customer Privided Keys)

• 고객 관리형 키(SSE-KMS)
  • AWS KMS를 사용해 고객이 생성하고 관리하는 암호화 키를 의미한다.
  • AWS KMS를 통해 생성된 키는 고객이 소유권과 제어권을 가지며, 이를 통해 데이터 암호화 및 복호화에 사용할 수 있다.
  • 이 키는 SSE-KMS 방식에서 사용된다.
  • 데이터 암호화는 AWS가 처리하므로, 운영 오버헤드가 최소화된다.
• 고객 제공키(SSE-C)
  • 고객이 직접 생성한 키를 AWS S3에 제공하여 데이터 암호화와 복호화를 수행하는 방식
  • 고객이 키를 AWS 외부에서 직접 생성하고 관리
  • AWS는 키를 저장하지 않으므로 고객이 키를 안전하게 관리해야한다.
  • 운영 오버헤드가 높다.(키 관리, 키 보안, 복호화 키 제공 등)

S3 Hosting Static Website

S3를 통한 정적 웹호스팅 방법

• S3를 활용해서 HTML, CSS, JS 파일이 버킷에 있다면, 이를 통해 정적 웹사이트를 만들 수 있다.
  • 1. 아래와 같이 버킷 네임과 리전네임으로 웹사이트를 만들 수 있다.
    2. 이 웹사이트의 접근 관리는 버킷 정책이나 ACL로 특정 유저에게 접근 권한을 줄 수 있다.
• 이때, https를 사용해야한다면 s3 앞단에 CloudFront를 앞단에 두어서 설계를 해야한다.
• S3로 호스팅하는 정적 웹사이트의 보안성 및 사용자 경험을 높여줄 수 있는 S3 이외의 AWS 서비스
  • AWS Certificate Manager : CloudFront 배포의 일부로서 사용될 때, 웹사이트에 SSL/TLS 암호화 인증서를 적용한다.
  • Route 53 : Route 53를 통해 사이트에 DNS 도메인 네임을 연결할 수 있다.

+) EC2 인스턴스 및 RDS 인스턴스는 정적 웹사이트용으로 사용하지 않는다.

+) 퍼블릭 속성의 정적 웹사이트에는 KMS를 사용하지 않는다. KMS 키는 지정된 사용자 외에는 웹 애셋을 다운로드하지 못하게 만드는 장치이다.

S3의 최종적 일관성(종국적 일관성 데이터)

• 등장 배경
  • s3는 다수의 지역에 데이터를 복제한다. 이는 기존 객체를 업데이트하면 시스템 전체에 이러한 사실이 전파될 떄까지 약간의 시간 지연이 발생할 수 있기 때문이다
  • 파일의 새 버전을 업로드한 직후 구 버전의 파일을 삭제하면, 특정 위치에서는 이러한 변경 사항이 미처 전파되지 못하는 상황이 발생할 수 있다. (단일 객체에 대한 버전 충돌)
  • 따라서 데이터 상태 변경에 대한 (1~2초의) 시간 지연을 감안한 뒤 관련 작업 수행의 방식을 설계해야 한다.
• 최종적 일관성이란?
  • 데이터 변경이 발생했을때, 시간이 지남에 따라 여러 노드에 전파되면서 당장은 아니지만 최종적으로 일관성이 유지되는 것
  • 따라서, 동시성을 제공하지 않고 결과적으로 일관성을 가지게 된다는 것
• 적용 범위
  • 업데이트 및 삭제 작업 → 최종적 일관성 기준이 적용
  • 새 객체 생성 및 PUT(덮어쓰기) → 최종적 일관성 기준 적용 X, 쓰기 후 읽기 일관성 적용 O

Amazon Elastic Block Storage (EBS)

• EBS는 EC2와 함께 사용되는 블록 스토리지 서비스로, 하드디스크나 SSD와 같은 역할을 수행한다.
  • EBS는 EC2와 함께 사용될 때 EC2가 중지되더라도 데이터를 저장하고 있기 때문에, 할당된 만큼의 요금이 계속 발생한다.
  • EC2 어플리케이션의 데이터 로그, 그리고 구성 정보를 저장한다.
  • 하나의 EBS 볼륨이 EC2 인스턴스에 연결되지만, 추가로 연결하는 것도 가능하다.
    • EBS 볼륨 종류 : SSD, IOPS SSD, HDD, Cold HDD
    • EBS 스토리지 하나당 EC2 하나가 연결된다.(EBS 하나에 EC2 두개 연결 못함)
  • EBS는 스냅샷과 백업 기능을 제공한다 → 이를 통해 데이터를 안전하게 보호하고 복구할 수 있다.

Amazon Elastic File System (EFS)

• 리눅스 인스턴스를 위한 확장성, 공유성 높은 파일 스토리지, 저지연성 읽기/쓰기를 지원한다.
• EFS는 NFSv4 프로토콜을 사용하는 파일 시스템이다.
• petabyte 규모의 스토리지를 지원하며 99.9%의 가용성을 제공한다.
• 또한 스토리지 기반 자동확장 기능을 제공하여 사용량에 따라 자동으로 용량 조절이 가능하다
• 가용성과 내구성을 보장할 수 있다.

⚠️  Amazon Elastic File System → 여러 인스턴스 간의 파일 공유와 저지연성 읽기/쓰기 지원한다

⚠️ 하나의 파일을 공유하기 위해서는 EFS를 사용하면 된다.

• EFS(Elastic File System)는 여러 인스턴스 간에 공유 가능한 파일 시스템으로 설계되었다.
• EFS를 사용하면 두 인스턴스가 동일한 파일 시스템을 통해 데이터를 공유할 수 있어, 모든 사용자에게 동일한 문서를 제공한다.
• 따라서 새로운 문서가 추가되더라도 두 인스턴스에서 접근할 수 있으므로 모든 사용자에게 모든 문서를 볼 수 있는 환경을 제공한다

 

Amazon FSx (for all types)

• 파일스토리지이며, 두가지 타입이 있다.
• FSx for Winodws File Server
  • SMB 프로토콜을 사용하여 파일 스토리지 제공
    • SMB 프로토콜 : 윈도우 환경에서 흔히 사용되는 파일 공유 프로토콜
  • 맥 OS에서도 사용가능하다
  • Server Message Block, NTFS, Microsoft AD(Active Directory)를 제공한다.
• FSx for Lustre
  • 고속의 러스트레 파일시스템을 사용하여 파일 스토리지를 제공하는 서비스
  • Rustre 파일 시스템은 고성능 컴퓨팅 환경에 적합한 파일 시스템(HPC 등)
  • 리눅스 환경에서 사용 가능

AWS Backup (Backup as a service)

• AWS의 EBS, EFS, FSx 같은 스토리지, RDS, DynamoDB 같은 데이터베이스의 데이터를 백업하는 서비스
  • 백업 규칙을 설정하면 백업이 자동으로 실시되고, 백업은 S3에 저장되므로 가용성과 내구성이 매우 높다.
  • 비용효율적(Cost-effective)이고 완전 관리형(fully-managed)이며 정책 기반 데이터 보호를 제공한다.
    • 데이터 보호 정책 준수를 감사하고 보고할 수 있다.
  • AWS Organization 을 통해 중앙에서 데이터 보호정책을 배포활 수있다.
  • AWS 계정과 리소스 전반에 걸쳐 백업을 구성, 관리, 통제할 수 있다.

AWS Storage Gateway

• 스토리지 게이트웨이는 온프레미스에서 클라우드 스토리지에 접근할 수 있게해주는 서비스
  • 자주 접근하는 데이터를 온프레미스에서 캐시하여 저지연 성능을 제공
  • 데이터 전송을 최적화하여 변경된 데이터만 전송하고 압축할 수 있다.
• S3, FSx, IAM, AMS 클라우드 워치, 클라우드 트레일과 통합되어 사용될 수 있다.
• S3 파일 게이트웨이를 생성하여 스토리지 공간을 확장할 수 있다.
  • 최근에 액세스한 데이터에 대한 빠른 로컬 액세스를 유지하면서 온프레미스 파일 데이터를 Amazon S3로 마이그레이션

AWS Snow Family

• AWS Snow Family는 AWS 클라우드 환경으로 대량의 데이터(exabyte까지)를 안전하게 전송하기 위한 물리적 장치이자 서비스이다. (대량의 데이터를 클라우드로 전송할 때 보통의 인터넷 연결 방식을 이용하면 지나치게 많은 시간 소모, 비효율적)
• Data Migration을 할 때 주로 사용된다.
• 1. AWS Console에서 데이터 전송용 디바이스(Snowball)을 주문한다.
  2. AWS측에서 택배로 주소지에 배달온다.
  3. 디바이스에 데이터를 넣어서 AWS에 다시 택배를 보내면, S3에 데이터를 업로드 해준다.
• 종류
  • Snowcone (8TB HDD, 14TB SSD)
  • Snowball Edge (80TB)
  • Snowmobile (100 PB)

 

참고: https://youtu.be/zBwikdaBqGA?si=iFIlbooO8_Xq5jTU