HDFS Architecture Guide

by Dhruba Borthakur

1. Introduction

분산 파일 시스템. 기존 시스템과의 차이점 : highly falut-tolerant , 저가 하드웨어에 디플로이 가능.
HDFS 는 Apache Nutch web search engine project 의 인프라로 만들어짐.
Apache Hadoop subproject.

2. Assumptions and Goals

2.1 Hardware Failure

하드 페일은 예외라기 보다는 ‘표준’ 이다. HDFS 인스턴스는 수백, 수천의 서버로 구성되어 파일 시스템의 데이터를 저장한다.
많은 수의 컴퍼넌트가 있다는 사실, 각 컴퍼넌트가 non-trivial 한 실패 가능이 있다는 것은 HDFS 의 일부 컴퍼넌트가 항상 non-functional 있다는 것을 의미한다.
그러므로, 결함의 발견과 그것의 빠르고, 자동적인 복구는 HDFS 의 코어 설계 목적이다.

2.2 Streaming Data Access

HDFS 에서 도는 어플은 자신의 데이터 셑에 접근하는 스트리밍이 필요하다. 그것들은 일반 파일 시스템에서 도는 일반 목적의 어플이 아니다.
HDFS 는 일반 유저 사용이 아니라 배칭 프로세싱에 더 알맞게 설계되었다. 데이터 억세스의 낮은 레이턴시보다 high throughtput of data access 에 집중.
Posix 는 HDFS 에 타게팅된 어플에 필요없는 많은 요구조건을 강요하고 있다.
Posix 의 몇몇 키 영역에서의 의미론은 데이터 처리율을 높이는 데 상쇄되었다.

2.3 Large Data Sets

HDFS 에서 도는 프로그램은 기가 / 테라 바이트의 파일.  그러므로, HDFS는 큰 파일을 지원하도록 튜닝 되었음.
싱글 클러스터에서 높은 최종 데이터 밴드위스 와 수백개의 노드를 지원해야 함. 한 인스턴스에서 수천만개의 파일을 지원해야 함.

2.4 Simple Coherency Model

파일에 대해 “1회 쓰고 – 여러번 읽기” 모델 이 필요. 파일이 생성, 기록, 닫히면 변경이 불필요하다. 이 가정은 데이터 일관성 이슈를 간단히 하고, 높은 데이터 억세스 생산량을 가능케 한다. 맵 리듀스나 웹 크롤러는 이 모델에 완벽히 맞아 떨어진다.
향후 추가-기록 을 지원하는 계획이 있음.

2.5 “Moving Computation is Cheaper than Moving Data”

어플의 요청에 의한 계산은 자료가 가까이에 있으면 효율적이다. 특히, 이것은 데이터가 클때 그렇다. 이것은 네트워크 사용을 최소화하고 시스템 성능을 증가시킨다. 가정은 이렇다. 데이터 가까이 컴퓨테이션을 이동하는 게 데이터를 이동하는 것보다 종종 낫다는…
HDFS 는 이렇게 데이터 가까이 어플리케이션을 가까이 가져가는 인터페이스를 제공한다.

2.6 Portability Across Heterogeneous Hardware and Software Platforms

플랫폼 간 이동이 쉽다.

3. NameNode and DataNodes

HDFS 는 마스터/슬레이브 아키텍쳐.
한개의 네임노드 (마스터 서버) +  여러개의 데이터 노드(보통 클러스터에서 노드당 한개), 노드에 붙은 스토리지 관리.
HDFS는 파일 시스템 namespace 를 노출하여 유저 데이터가 파일에 저장되도록 허용함.
내부적으로 한 파일은 하나이상의 블럭으로 나뉘고 이 블럭들은 데이터 노드들의 세트에 저장.
> 네임노드는 file system namespace operation 을 파일이나 폴더를 열고/닫고/리네임 하듯 함.
또한, 데이터노드에 블럭을 매핑하는 결정을 한다.
> 데이터 노드는 클라이언트로부터의 읽기/쓰기 요청에 대응할 책임이 있음.
데이터 노드는 블락생성/삭제/복제 등을 수행.

이 노드들은 머신에서 돌도록 설계된 소프트웨어의 일부임. 이 머신들은 GNU/Linux .. 보통.
자바로 쓰여짐. 자바를 지원하면 노드들을 돌릴 수 있음. 자바가 포터블성이 좋으므로 여러 머신에서 동작 가능.
전형적인 디플로이는 전적으로 네임노드 소트트웨어를 돌림. 각각의 다른 머신은 한 데이터노드를 돌림.
여러 노드를 한 머신에서 돌리는 것이 구조상 가능하지만 실제로는 적다.

네임노드가 하나인 것은 구조를 간단히 해준다. 이 네임노드는 메타데이터 등을 담는 중재자 역할.
유저 데이터는 네임노드를 통해 ‘절대’ 흐르지 않음.

4. The File System Namespace

기존 파일 구성 체계 지원. 디렉토리 생성 가능.  파일을 생성, 이동, 리네임 등 기존 체계와 비슷.
하지만 유저 쿼타를 구현하지 않음. 하드/소프트 링크 지원 안함.  하지만, HDFS 아키텍춰는 이런 구현을 배제하지는 않음.

네임노드는 파일 시스템 네임스페이스를 유지한다. 파일 시스템 네임공간의 변화는 네임노드에 의해 기록된다. 어플이 복제의 수를 규정. 파일의 복제 갯수는 그 파일의 replication factor 라고 함.  이 정보는 네임노드에 저장됨.

5. Data Replication

HDFS 는 큰 클러스터에 큰 파일을 여러 머신에 안정적으로 저장하게 설계되어 있음. 블락의 연속으로 파일 저장 ;
마지막 블락을 제외한 모든 블락은 같은 크기.
파일의 블락은 fault tolerance 를 위해 복제됨. 블락 크기와 복제팩터은 파일 별로 조절 가능. 어플리케이션이 파일의 복제수를 규정.
복제팩터는 파일 생성시에 규정 가능하고 나중에 바뀔 수 있다.
파일은 한번-쓰고 항상 한 writer 를 갖는다.

네임노드는 모든 블락의 복제에 관해 결정을 내림. 주기적으로 핫빝과 블락 레포트를 데이터노드로 부터 받음.
핫빝의 영수증은 잘 기능한다는 걸 의미.
레포트는 데이터노드의 모든 블락의 리스트를 포함함.

5.1 Replica Placement : The First Baby Steps

복제는 신뢰성/성능에 매우 중요.  복제 최적화는 HDFS의 차별화 요소. 또한 튜닝과 경험 필요.
랙 인식 복제의 목적은 데이터 신뢰성, 가용성, 밴드폭 활용을 향상시키기 위함.
현재 복제 정책의 구현은 이 방향의 첫번째 노력이다. 단기 목표는 제품 시스템에서 검증, 행동 연구, 더 복잡한 정책 연구 등이다.

대규모 HDFS 인스턴스는 여러 랙에 걸쳐 분산된다. 다른 랙의 두 노드사이의 통신은 스위치를 통해야 한다. 대부분의 경우 같은 랙 머신간의 네트웤 밴드폭은 다른 랙 사이보다 크다.

네임노드는 각 데이터노드가 속한 랙 아이디를 ‘하둡 랙 인지(Awareness)’ 에서 정하는 프로세스에 따라 결정한다.
간단하지만 최적은 아닌 정책이 복제를 유니크한 랙에 둔다.
이것은 랙 전체가 페일날 때 데이터 유실을 예방하고 데이터 읽기작업에 여러 랙으로부터의 밴드폭을 허용한다.
이 정책은 복제를 골고루 분산시켜 콤포넌트 실패에 로드 발란스를 쉽게 한다. 하지만, 이 방법은 쓰기작업이 여러 랙에 블락을 옮기는 것을 막아야하기 때문에 쓰기 비용을 늘린다.

일반적인 경우 복제계수가 3이면 HDFS의 원칙은 하나를 로컬랙의 한 노드에 놓고, 다른 건 다른 랙의 노드에, 세번째는 다른 랙의 다른 노드에 놓는다.
랙 페일의 가능성은 노드 페일보다 훨씬 적다. 이 원칙은 데이터 신뢰도와 가응성을 해치지 않는다.
하지만, 3개가 아닌 2 랙에 분리되어 있어 데이터 읽을 때의 밴드폭은 줄여준다. 또한, 랙에 골고루 분산시키지는 않는다.
이 원칙은 데이터 신뢰성과 읽기 성능을 떨어뜨리지 않으면서 쓰기 퍼포먼스를 향상시킨다.

여기서 기술된 현재의 디폴트 원칙은 진행 중임.

5.2 Replica Selection

글로벌 밴드폭 소비와 읽기 레이턴시를 최소화하기 위해 HDFS 는 리더에 가장 가까운 복제본으로부터 읽어야 한다?.
리더 노드와 같은 랙에 복제본이 있으면 그놈이 읽기 요청을 만족하는 것이 바람직함. 클러스터가 여러 데이터 센터로 펼쳐지면 로컬 데이터센터에 있는 복제본은 어느 원격 복제본보다 우선된다.

5.3 Safe Mode

시작 시 네임노드는 ‘안전 모드’ 로 들어간다. 이때 복제 작업 없음. 네임노드가 Heartbeat & Blockreport 메시지를 데이터노드로부터 받는다. 블락레포트는 한 데이터노드가 호스팅하는 블록들의 리스트를 담고 있다. 각 블럭은 복제본의 정해진 최소 수를 갖고 있다.
블락은 네임노드에 최소개수가 체크인하면 안전하게  복제됐다고 간주된다. 안전하게 복제된 복제본의 일정 퍼센트가 체크인하고 (추가 30초 ) 후에 안전모드에서 나온다. 그리고나서 정해진 숫자 이하의 블락을 갖는 데이터블록을 결정한다.
그리고나서 네임노드는 이 블락을 데이터노드에 복제한다.

6. The Persistence of File System Metadata

HDFS namespace 는 네임노드에 의해 저장된다.
네임노드는 현재 파일 시스템 메타데이터의 변화를 끊임없이 기록하기 위해 EditLog라 불리는 트랜잭션 로그를 사용한다.
예를 들어 새로운 파일을 생성할 때 네임노드는 이것을 가리키는 에딧로그에 레코드를 삽입한다. 복제 팩터를 바꾸는 것도 비슷.
네임노드는 수정로그 저장에 로컬 호스트 OS 파일 시스템을 이용한다.
파일 블록의 맵핑을 포함한 파일 시스템 이름공간 전체는 FsImage 라는 파일에 저장된다.
이 파일 역시 네임노드의 로컬 파일 시스템에 파일로 저장된다.

네임노드는 전체 파일 시스템 이름공간의 이미지와 파일 블록맵을 ‘메모리’에 띄운다. 이 키 메타데이터 아이템은 작게 설계되어 4기가의 램도 충분하다.
네임노드가 기동할 때 FsImage 와 EditLog 를 디스크에서 읽고 EditLog로 부터의 모든 트랜잭션을 FsImage의 인-메모리 객체에 적용하고 이 새로운 버전을 디스크의 새로운 FsImage 로 플러시아웃 한다.
그리고나서 기존의 EditLog 를 (반영이 되었으므로) 없앤다.
이 과정을 ‘체크포인트’ 라고 한다.
현재 구현에서는 체크포인트는 네임노드가 기동할 때만 일어난다. 향후에는 주기적으로 할 계획이다.

데이터 노드는 HDFS 데이터를 로컬 파일시스템에 저장한다. 데이터노드는  HDFS 에 대해 모른다.
단지 파일의 블럭을 로컬 파일 시스템에 저장할 뿐이다. 모든 파일을 같은 디렉토리에 생성하지 않는다. 대신, ‘자기발견 heuristic’ 을 사용하여 디렉토리당 최적의 파일 수를 결정하고 적당히 하위 디렉토리를 만든다. 모든 파일을 같은 디렉토리에 놓는 것은 적합하지 않다. (파일 시스템 문제)
데이터노드가 기동시 로컬 파일 시스템을 스캔하고 데이터 블록의 리스트를 만들고 이 레포트를 네임노드에 보낸다.
이것은 ‘블럭 레포트’ 이다.

7. The Communication Protocols

모든 HDFS 통신은 TCP/IP 위에 놓여진다. 클라이언트는 네임노드 머신위에 TCP 포트 연결을 확보하여 네임노드와 ClientProtocol 을 통신한다.
데이터노드는 네임노드와 ‘데이터노드 프로토콜’ 을 이용하여 소통한다.
RPC (remote procedure call) 추상화는 클라이언트 / 데이터노드 프로토콜 양쪽을 랩핑한다.
설계상, 네임노드는 어떤 RPC 도 초기화하지 않는다. 대신 데이터노드나 클라이언트에 의해 요청된 RPC 에 응답할 뿐.

8. Robustness

HDFS 의 주된 목적은 실패가 나더라도 데이터를 안정적으로 저장하는 것.
3가지 실패.

8.1 Data Disk Failure, Hearbeats and Re-Replication

각 데이터노드는 네임노드에게 핫빗 메시지를 주기적으로 보냄. 네트워크 파티션은 데이터노드의 섭셋이 네임노드와 연결을 잃게 할 수 있다. 네임노드는 최근에 핫빗을 안 보낸 데이터노드를 죽은 것으로 간주하고 더 이상의 IO 를 보내지 않는다. 죽은 노드에 기록된 데이터는 HDFS 에서 접근할 수 없다. 데이터노드의 죽음은 블럭의 복제 팩터가 내려가게 한다. 네임노드는 끊임없이 어떤 블락이 복제가 필요한 지 추적한다.
재-복제의 필요성이 여러 이유에 의해 제기된다 : 데이터노드가 접근불가,
복제본이 상한경우, 하드 디스크 페일 또는 복제 팩터 증가.

8.2 Cluster Rebalancing

HDFS 구조는 데이터 재균형 계획과 호환됨. 이것은 데이터노드의 빈 공간이 어느 레벨 이하로 내려가면 자동으로 다른 데이터노드로부터 옮겨온다.  어떤 파일에 대해 갑자기 높은 요구가 생기면 스킴은 동적으로 추가의 복제를 생성하고 클러스터의 다른 데이터와 재-균형할 수 있다.
이런 재균형은 아직 ‘미 구 현’ ..

8.3 Data Integrity

데이터노드로부터 가져온 블락이 손상되었을 가능성이 있다.  원인은 스토리지 이상, 네트워크 부실, 소프트웨어 버그.
클라이언트는 첵섬을 구현한다.
클라이언트가 HDFS 파일을 생성하면 각 블럭의 첵섬을 계산하여 HDFS 네임 공간에 히든 파일로 저장한다.
클라이언트가 데이터를 받을 때 확인.
틀리면 그 블럭을 다른 복제본에서 가져온다.

8.4 Metadata Disk Failure

FsImage & EditLog 는 중앙 데이터 구조임. 이 파일이 망가지면 HDFS 인스턴스가 기능 정지하게 됨.
이런 이유로 네임노드는 이 파일들을 여러 카피 유지하도록 함.
이 파일이 수정되면 각각의 복사본이 싱크되게 함.
이런 싱크 작업은 초당 트랜잭션 정도를 줄일 수 있다.
하지만, 메타데이터가 큰 것은 아니기 때문에 이런 성능저하는 수용할 만 하다.
네임노드가 재 시작할 때 최근의 파일들을 이용한다.

HDFS 클러스터에서는 네임노드 머신이 페일나는 한 지점이다. 네임노드가 페일나면 매뉴얼 작업이 필요하다.
현재, 자동 재시작과 네임노드의 페일오버시 다른 머신으로 이전은 지원되지 않는다.

8.5 Snapshots

특정 시간의 데이터의 카피 저장을 지원.  쓰임은 타임머쉰.. 에러 나기 전 시간으로 되돌림.  향후 기능.

9. Data Organization

9.1 Data Blocks

HDFS 는 큰 파일을 지원하기 위해 설계 되었음. 호환되는 어플은 큰 데이터 세트를 다룬다.
이 어플들은 데이터를 한번 쓰지만 한번 이상 읽고 이러한 읽기는 스트리밍 속도를 만족하는 것이 필요하다.
HDFS는 1번쓰고 여러번 읽는 개념을 지원한다. 전형적인 블럭 사이즈는 64 메가 바이트.
그러므로 64씩 잘라지고 다른 데이터 노드에 자리잡는다.

9.2 Staging

파일을 생성하라는 클라이언트 요청은 네임노드에 즉시 닿지 않는다.
실제로, 초기에 HDFS 클라이언트는 파일 데이터를 임시 로컬 파일에 캐시한다.
어플 쓰기는 이 임시 로컬 파일에 투명하게 redirect 된다.
로컬 파일이 블럭 사이즈만큼 데이터를 쌓게 되면 클라이언트는 네임노드에 컨택한다.
네임노드는 파일 이름을 파일시스템 위계에 넣고 데이터블럭을 잡는다.
클라이언트 요청에  네임노드는 데이터노드의 아이디와 최종 데이터 블록을 갖고 응답한다. 그리고나서 클라이언트는 임시파일에서 데이터 블럭을 지운다.
파일이 닫히면, 남은 데이터는 데이터노드로 옮겨진다. 그리고, 클라이언트는 네임노드에 파일이 닫혔다고 한다.
이때, 네임노드는 영구 공간에 파일생성 작업을 커밋한다.
파일이 닫히기전에 네임노드가 죽으면 파일은 잃어버린다.

위의 접근방식은 어플의 특성을 고려하여 세심히 설계 되었다. 이 어플들은 파일에 대해 스트리밍 쓰기가 필요하다. 클라이언트가 클라이언트 측 버퍼링 없이 원격파일에 직접 쓰면 네트워크 속도와 congestion in the network 는 작업에 상당히 영향을 준다.
이 접근은 선례가 없지 않다.  초기의 분산 파일 시스템은 성능을 향상시키기 위해 클라이언트 캐싱을 이용했다.
POSIX 요구는 더 높은 성능을 위해 relaxed ..

9.3 Replication Pipelining

클라이언트가 파일을 쓸 때 로컬 파일에 먼저 쓴다.
복제 계수가 3일 때를 가정.
로컬 파일이 데이터로 가득 차면, 클라이언트는 네임노드로 부터 데이터노드 리스트를 갱신한다.
이 리스트는 그 블록의 복제물을 보관할 데이터노드를 갖고 있다.
그럼 클라이언트는 그 블록을 첫번째 데이터노드에 플러시 한다.
첫번째 데이터노드는 데이터를 작은 조각(4KB)으로 받기 시작해서 로컬 저장소에 쓰면서 그 부분을 두번째 데이터노드에 전달한다.
두번째 노드는 똑같이 세번째 노드에 전달한다.
마침내 세번째 노드가 저장소에 보관한다.
데이터 노드는 파이프라인의 이전 노드에서 데이터를 받고 다음 노드로 넘겨준다.
그러므로 데이터는 한 데이터 노드에서 다음으로 파이프라인 된다.

10 Accessability

HDFS 는 어플에서 여러가지 방법으로 접근 가능하다.  네이티브는 자바 API 제공.
이것에 대한 C 래퍼 또한 가능.   HTTP 브라우저 가능.
WebDAV 프로토콜을 통하는 방법은 개발 중.

10.1 FS Shell

HDFS 는 사용자 데이터를 파일/ 디렉토리로 구성한다. 사용자 인터페이스를 위해 쉘 제공.
다른 쉘과 비슷.
스크립트 언어 지원 위해 필요.

10.2 DFSAdmin

Command set..  HDFS cluster 관리용
관리자 만의 용도.

10.3 Browser Interface

전형적인 HDFS 설치는 TCP 포트를 통한  ‘네임스페이스’를 노출시키는 웹서버를 구성한다.
이것을 통해 브라우징 하면서 내용을 확인할 수 있다.

11. Space Reclamation

11. 1 File Deletes and Undeletes

어플이나 사용자에 의해 파일이 삭제되면 바로 삭제 되지 않음.
휴지통으로 이동.
이동한 파일은 정해진 시간만큼 존재.
완전히 삭제된 후 네임노드는 HDFS 이름공간에서 파일을 삭제.
파일의 삭제는 그에 할당된 블락들을 해제시킴.
파일의 삭제와 빈공간의 증가 사이에는 시간 차이가 존재함.

파일이 휴지통에 있는 동안은 복구 가능.
복구하려면 휴지통으로 가서 복구 해야 함. 여기에는 최종본만 있음.
복구하는 규칙 :: 현재의 정책은 6시간 이상 경과한 파일을 지우는 것.
향후에는 여러 옵션을 적용할 수 있을 것이다.

11.2 Decrease Replication Factor

복제 계수가 줄어들면 네임노드가 지워질 여분의 복제분을 선택한다.
다음번의 핫빗 이 이 정보를 데이터노드에 전달.
데이터 노드가 블럭을 지우고 자유 공간이 증가.  역시 시간차이가 존재.

 

 

Advertisements

In Memory DB ..

2007년 글이지만 참고할 만한 글..

메모리 디비는 ‘소프트웨어’ 이다.
디비 ‘전체’ 를 메모리에 올린다.
‘질의 처리기’
‘동시성 제어 기술’

동시성 제어 기술

동시성 제어 기법은 기존의 “열 단위 잠금(row locking)” 방식의 단점으로 지적돼 왔던 수정된 데이터(updating data)에 대해 장기간 동안 연산이 대기하는 문제점을 해결하는 기술이다.
다중 버전 기법 : MVCC // Multi-Version Concurrency Control
Hot Backup : 디비를 종료하지 않고 즉시 백업..

다중 사용자 처리 기술

시스템 용량과 ‘정비례’ 하지는 않는다.  사용자 수 만큼의 프로세스.. 자원 낭비.  => 쓰레드 기반 아키텍처로 가는 추세. 확장성의 문제..
==> 풀  사용…

질의 최적화 기술

CPU, Cache .. L1, L2 ..

어플라이언스 / 인메모리 

어플라이언스 : 하드웨어와 최적화. 오라클.

인메모리 : SAP  (여기서는 메인 메모리.. DRAM ) 속도가 빠름.. 100배에서 10만배 빨라짐.

iTunes Connect Developer Guide [ In-App Purchase ] section

원문

IAP 의 관리는 App Summary 페이지의 Manage In-App Purchases  버튼을 클릭하여 이루어짐. 이 버튼은 계정이 어드민, 기술 역할 등에 할당되었을 때 ‘보여진다’

About In-App Purchase

스토어-킷 을 통해 구현한다. 스토어-킷은 당신의 앱을 대신하여 앱 스토어에 연결하고, 결재를 위한 UI 제공,  ..

>> 추가적인 성능
>> 북 리더앱의 새 책.
>> 게임의 뉴 레벨
>> 온라인 게임에서의 가상 특성 구입
>> turn-by-turn 맵 서비스 접속
>> 전자 잡지 / 뉴스레터

앱내구매를 앱에서 구현하려면 ‘최신 Paid Applications contract’ 가 유효하고, 팀 요원이 프로그램 라이센스에 동의해야 함.
애플에 리뷰를 위해 보내기전에, 모든 앱내구매는 ‘아이튠즈 커넥트’ 에 등록되고 샌드박스 환경에서 테스트 되어야 한다.

Registering In-App Purchases

무료/유료 앱에 적용 가능.  제품은 먼저 ‘아 – 커넥트’에 등록되어야 함. 등록 시 ‘이름, 설명, 가격’ 와 다른 메타 데이터 추가.
제품은 ‘product indentifier’ 라는 유니크한 문자로 구별함. 앱이 스토어킷을 사용 시 이 ‘구별자’ 를 사용.
당신은 앱내구매를  ‘생성, 수정, 삭제’ 할 수 있고 리뷰를 위해 애플에 제출할 수 있다.
앱내 구매에는 10,000 개 까지 다른 ‘구별자’를 생성할 수 있다. 이것은 거래 숫자가 아님.
앱 서머리 페이지에서 생성 시작할 수 있다.

Creating In-App Purchases

>> Log into iTunes Connect
>> Manage Your Applications
>> Click the App
>> Manage IAP click  (이 버튼이 보이지 않으면 계약에 동의하지 않은 것임)
>> Create New
>> Select Type .. consumable, Non-consumable, Auto-Renewable Subscriptions, Free Subscription, Non-renewing subscription
>> Fill out the form
>> Click Save.  앱내 구매가 ‘관리’ 페이지에서 보인다.

Entering In-App Purchase Information

표 12-2 의 내용 입력.

>> Free Subscription form [ 언어 추가, 스크린 샷 … ]

>> Non-Renewable Subscription or Consumable form..

Table 12-2 Common IAP properties
Reference Name, Product ID < unique UTF-8 alphanumerical identifier > Not editable, Pricing and Availability, Languages, Review Notes < for Apple review >, Screenshot

Privacy Policy URL input…

Testing Your IAP

샌드박스 환경 -> 금융 결재 발생 안함.  앱 스토어를 이요하지만 결재 하지는 않음. 실제 결제와 동일한 값 리턴.  앱내구매에 한정된 특별한 ‘아-커넥트’ 계정 사용.  일반 계정은 샌드박스에서 쓸 수 없음.

Creating Test User Accounts

커넥트를 이용하여 1개 이상의 테스트 계정 생성. 각 언어에 대하여 1개 이상의 계정 생성해야. 테스트 유저 계정은 새롭고, 유니크한 애플 계정이어야하고, 기존 계정을 이용할 수 없다.
어드민, 기술 역할로 어사인 되어 있어야 생성 가능. ‘커넥트’ 에 접근 불가, 하지만 앱내구매에서 테스트 가능. 개발 환경의 등록된 테스트 기기에서만..

>> Log into iTunes Connect.
>> Manage Users..
>> Click Test User.
>> Add New User.

<<주의>> 실수로 테스트 유저 계정으로  (테스트 환경 대신) 기기에서 제품 환경에  로그인하면, 테스트 계정은 invalid 되고 다시 사용할 수 없게 됨.

Using Test User Accounts

#1. 테스트 유저 계정 셋업. 아이디(이메일), 비번 입력.
#2. 테스트 기기의 계정 정보 초기화 할것. 테스팅 중에 실제 계정이 쓰일 염려때문.
<< 주의 >> 테스트 계정 정보를 ‘스토어 세팅’ 패널에서 넣지 말것. 이것은 테스트 계정을 폐기할 수 있음.
#3. 샌드박스에 대비한( against ) 기능을 테스트하려면 기기를 개발 웤스테이션에 연결하고 기기를 Active SDK 로 선택할 것.
#4. 앱이 스토어킷 API 를 통해 결재를 요청할 때, 결재 확인 창이 뜨고 Sign In 패널이 또 뜬다. ‘Use Existing Account’ 선택하고 테스트 유저네임과 비번을 넣은 후 구매 테스트를 완료함. 금융거래는 일어나지 않지만 영수증을 포함한 완전한 구매가 생성. 테스트 계정에는 신용카드정보가 없으므로 실제 금융 거래는 일어나지 않음.

Sandbox Testing Your IAP

애플에 리뷰를 위해 제출하기 전에 샌드박스 환경에서 테스트 해야 함. 샌드박스로 테스트 하기 전에 아이튠즈 계정에서 로그 아웃 해야 함. 테스트 유저 계정을 테스트 디바이스에서 로그인 하면 계정이 폐기된다.
오토-리뉴어블 앱내구매를 테스팅할 때는 지속 시간이 짧아진다. 부가적으로 샌드박스 제출은 6번 까지만 ‘오토-리뉴’ 된다.

Submitting Your In-App Purchases

새로 만든 ‘앱내구매’를 다음 바이너리 업로드 때 써밋 할 지, 지금 바로 리뷰에 들어갈 지 결정해야 한다.
첫번째 앱내구매는 앱 버전과 같이 제출되어야 한다. Version Details 페이지에 해야 한다. (적어야 한다) 바이너리가 업로드 되고, 첫번째 앱내구매가 리뷰에 들어간 후 추가적인 앱내구매는 앰내구매 ‘관리’ 뷰의 테이블을 통해 제출될 수 있다.
바이너리와 함께 서밋하려면 Version Details Page 에서 선택해야 한다.
스크린 샷에서 에디트 를 클릭하여 어느 놈이 리뷰되야 하는지 선택한다.
세이브. 바이너리와 함께 제출되었다.
대규모 제출도 가능.  제출할 놈을 체크.. Ready to Submit 으로 만든다.   “Submit for Review” 클릭..
<개별 제출> 앱내구매 페이지에서 개별적으로 제출 가능. “Ready to Submit” 에서 “Waiting for Review” 로 바뀌고 즉시 리뷰를 위해 보내진다.

Tracking Your IAP Status

제출한 후에는 “Waiting for Review” 로 상태가 바뀐다. 리뷰를 기다리는 동안 수정이 가능하다.

“In Review” 로 바뀜. 수정 불가.이 상태에서는 삭제도 불가.

“Approved” 바이너리 없이 …. 암튼 완료..

바이너리와 함께 제출하기로 선택했다면, 애플에서 심사 후에 앱 심사가 끝날 때까지 approved 가 안 나옴.
리뷰 과정에서 앱내구매가 리젝되면 애플에서 연락이 간다.  커넥트의 Contact Us 를 통해 물어볼 수 있다. 리젝되면 다시 만들어야 한다.

IAP plugin 설명..

일단 iTunesConnect 에서 제품 셋업을 하고 테스트 유저 1 ~ 2를 생성하면 테스트 할 준비가 된 것.

씬에 StoreKitManager.cs 스크립트가 연결된 게임 오브젝트가 있어야 한다.

네이티브 코드로 부터의 콜백함수는 그 클래스의 메소드를 부를 것이다.

애플은 구매를 ‘초기화’ 하기 전에 먼저 ‘리트리브’ 하는 앱들을 리젝 시켜왔다.

사용자에게 구매를 허용하기 전에 항상 requestProductData 를 불러주도록.

Server Product model Overview Image

스토어킷은 비동기적으로 이루어지므로 실패 유무의 콜백 함수를 유심히 봐야 한다.

중요한 함수는  productPuchased()  임..  이것이 오면 구매가 원활히 이루어진 것임.

StoreKitManager 네이티브로부터의 콜백을 모두 노출함.

[ storeKitEventListener ] 프리팹을 당신의 씬에 가져다 놓으면 미리 연결된 함수를 통해 모니터링 가능하다.

Xcode 의 로그를 보는 것이 가장 도움이 됨.

또한, StoreKitManager  프리팹은 처음 로딩 씬에 추가되어 있어야 함.

아래는 애플의 가이드라인.  다음의 이유로 product identifier 가 in valid 로 리턴될 수 있음.

# 테스팅 하지 않는 애플 아이디는 완전히 로그아웃 할 것.. ( 세팅 -> 스토어 -> 사인 아웃 )

# 금융 동의에 완전히 서명하지 않음.

# 적당한 ‘제품 아이디’를 쓰지 않음.

# IAP 제품을 for sale 로 클리어 하지 않음.

# 제품 수정이 모든 서버에 전파 되지 않았음.

# 아이튠즈 커넥트의 제품을 리젝했음.

# 앱 리뷰가 준비될때까지 바이너리를 업로드 하지 말것.  개발용 바이너리가 있으면 리젝될 것임.  방법은 :: 앱내구매 없이 올려서 승인을 받고,  바이너리가 승인을 받으면 앱내구매 기능을 테스트 한다. ??

앱내구매 테스트 팁

# 번들 아이디를 유니티 /   Xcode 에서 이중 체크 할 것.

# 프로비저닝 파일 유효

# 테스트 유저만 아이튠즈 커넥트 포탈을 사용할 것.

# 테스트 사이에는 앱을 지울 것..  requestProductData 로부터 데이터를 받을  수 있으므로.

샘플소스는 작동 안될 것임.. 참고용.

In App Purchase 매뉴얼..

In-App Purchase Programming Guide

Overview of In-App Purchase

Product

팔고 싶은 특성 모두. iTunes Connect 를 통해 새로운 앱을 만들때 처럼 연결.  4가지 방법. & 컨텐트 : 전자첵. 잡지, 사진, 아트웤, 게임레벨, 케릭 등등  어플에 배달 가능한 컨텐트. & 기능 : 이미 구현되어 있는 기능을 언락 / 기능 확장. & 서비스 : 1회성 서비스에 대해 과금. 음성 받아적기 등. & Subscriptions : 확장에 기반한 컨텐트/서비스 접속. 금융 정보에 1달간 접속 가능, 온라인 게임 포털에 접속 가능… 등.. 제품 설계 시 중요한 가이드라인. > 실제 제품 판매에는 사용하지 말것. > 전자머니를 나타내는 아이템을 제공하지 말라.. 사용자가 특정 아이템/서비스를 구매하는 것으로 아는 것이 중요 > 포르노, 도박, 혐오 에 관련되지 않도록..

Registering Products with the App Store

모든 아이템은 iTunes Connect 를 통해 먼저 등록 되어야 함.  이름/설명/가격 이 있어야 함. 특정 제품을 <product identifier> 라는 스트링으로 구별할 수 있다. 스토어킷을 이용하면 제품에 제공한 데이터를 가져올 때 PI 를 사용. 나중에 고객이 구매하고자 할 때, 어플은 PI 를 이용하여 그 제품이 구매된 것인 지 구별한다. 앱 스토어가 제공하는 제품의 종류 > Consumable : 매번 사야 하는 것. 1회성. > Non-consumable : 특정 유저가 한번만 구매.  모든 디바이스에 적용. 스토어킷은 이러한 기능 제공. > Auto-renewable subscriptions : 앞의 것처럼 모든 기기에 적용. subscription 의 기간 선택. 당신의 앱이 유효한지 안한지 책임진다. 가장 최근의 결재를 업데이트… > Free subscriptions : 뉴스 스탠드에 무료 자료. 폐기되지 않고 ‘뉴스 스탠드’ 가능한 앱에서만 사용 가능. > Non-renewing subscriptions : 제한된 기간을 갖는 제품. 오토-리뉴어블 과 다른 점. >> 아이튠즈커낵트에 제품 생성 시 섭스크립션 이란 단어가 선언되지 않음. 당신의 앱이 제공. 보통 제품 설명에 포함. >> 넌-리뉴잉 은 여러번 구매할 수 있다. 앱스토어에 의해 자동으로 ‘리뉴’ 되지 않음. 리뉴얼 프로세스를 앱 안에서 구현해라. >> 넌 리뉴잉  을 모든 기기에서 보여줘야. 자동으로 싱크되지 않음.

Feature Delivery

Buil-in / sever model..

Built-in Product Model

앱 내부에 모든 것이 이미 구현. [풀어 주는] 기능. 즉시 제공 가능. 대부분은 non-consumable.. *** IAP 는 결재 성공 후 어플을 패치하는 것은 하지 않음. 어플의 번들에 변화가 필요하면 업데이트된 버전을 앱스토어에 배달해야 함. 제품을 구별하기 위해 당신의 어플은 PI를 번들에 저장. Plist 를 권장. 컨텐트 주도 어플은 소스를 바꾸지 않고 새로운 컨텐트를 추가 가능. 구배 성공 후 언락하고 기능을 제공해야 한다. 가장 쉬운 방법은 preferences 를 바꾸는 것..  Implementing Application Preferences어플 프레퍼런스는 백업 된다. 유저에게 백업하라고 추천할 수도 있음.  도표 참조..

Server Product Model

당신이 제품을 공급할 서버를 운영.  게임 등에서는 뉴 레벨 등을 배달 가능. 스토어 킷은 어떤 것도 제공하지 않음. 당근.. 특정 유저를 구별하는 메카니즘도 제공 안 함.  도표 참조 …

## 사용자 스토어에서 아이템 선택 -> 어플이 앱 스토어에 결재 요청 전송 -> 앱 스토어 결재한 후 결재완료 리턴 -> 어플이 영수증 받고 서버로 보냄 …
—-> ** 서버가 앱 스토어로 확인 영수증 데이터 보냄. -> ** 앱 스토어가  영수증이 유효한지 확인한 후 영수증과 확인 되었는지 보냄 -> 서버가 반환된 영수증을 통해 구매 물품 확인 -> 서버가 구매 물품 어플에 전달.

애플은 서버로부터 PI를 받는 것을 추천.. plist에 저장은 비추.. >> 업데이트 없이 물품 추가하는 유연성 제공.

서버가 영수증을 받고 물품 확인 하는 절차.. Verifying Store Receipts..

서버 모델은 추가적인 보안, 신뢰성 부가… 보안코딩 가이드 참조할것..

Non-consumable 제품은 스토어 킷의 기능을 이용해 회복 가능하지만, non-renewing 제품은 당신의 서버에 저장되야 한다. 이 정보를 저장하는 것은 네 책임이다. Consumable 제품 역시 당신 서버에 의해 추적가능하다.  이 제품이 서버에 의해 제공되는 것이면, 사용자가 각 기기에서 수습하게 할 수 있다.

Retrieving Product Information

어플이 스토어를 보여줄 준비가 되면, 앱 스토어로부터의 정보를 UI 에 덧붙여야 함.  이 장은 앱 스토어에 제품 디테일을 요청하는 방법에 관한 것임.

Sending Requests to the App Store

스토어 킷은 요청하는 메카니즘 제공.  request 객체를 생성, 초기화 딜리깃을 붙이고 요청 시작. 시작하면 앱 스토어에 전달. 앱 스토어가 요청을 실행하면 딜리깃이 비동기적으로 불려서 결과를 전달함.

SKRequest : abstract base class

SKRequestDelegate : protocol  : 구현할 부분. 성공/실패 에 대하여

Requesting Information About Products

어플은 제품에 대해 로컬 정보를 얻기 위해 products request 를 사용.
어플이 product identifier string 의 리스트를 포함하는 request 를 생성. 앞에서 설명한대로 어플은 PI를 어플 내부에 임베드하거나 혹은 서버를 통해 갱신할 수 있다.  request 를 시작하면 identifier string 이 앱 스토어에 넘겨진다. 앱 스토어가 iTunes Connect 에서 입력한 로컬화된 정보로 응답한다. 이 디테일로 당신 스토어의 UI에 덧붙여라.

##** 중요 : 제품 구매를 허락하기 전에 특정 제품 identifier 를 요청해야 함. 앱 스토어로부터 제품 정보를 갱신하므로 제대로 된 제품을 파는 것을 보장할 수 있음.

SKProductsRequest

product identifier 의 리스트와 함께 생성.  상점에 진열될..

SKProductsRequestDelegate  프로토콜

상점으로부터의 반응을 받기 위해 구현.  요청이 성공되면 대답을 받음.

SKProductsResponse

스토어에 의해 인식되지 않은 PI의 리스트 뿐만 아니라 원래 요청의 유효한 PI 마다 하나의 SKProduct 객체를 갖고 있음. 스토어는 여러 이유로 식별하지 못할 수도 있음 : 오타, 판매 불가로 표시,  iTunes Connect 에서의 변경이 모든 앱 스토어 서버로 전달되지 않아서.

SKProduct

앱 스토어에 등록한 제품에 대해 로컬 정보를 제공함.

Unity Tips, tips..

컵에 글씨 쓰는 소스

 

File IO Javascript  @ Unity Answer

 

Blogs..

Over the rainbow.. 네이버 블로그.. 통신, 마켓 등등..

String Management

var packStr : String = ""; // 스트링이 있다.
var charArr:char[];  // 이렇게 어레이로 바꾼 다음..
charArr = packStr.ToCharArray();</pre>
<div>

aPacket = charArr[0];   이렇게 할당하고..

if (aPacket == 0x01) Debug.Log("charArr[0] is 0x01");  이렇게 확인 함...

else Debug.Log("charArr[0] is NOT 0x01");
<div>