[⭐️ TIP] CloudKit 공부

[GroundDev]

CloudKit 관련 공부자료 정리

Jason : 이번 챌린지 프로젝트를 말씀하신대로 데이터 변환해서 클라이언트가 열람하게하려면 잭 말씀대로 서버를 쓰지않을 수 없겠군요. 이런 경우에는 CloudKit을 우선사용 권장드립니다! 파이어베이스보다 느리지만 저렴하다는 등 장단점이 있겠지만, 한번 직접 비교해보시고 업계나 주변에서 많이 사용해서 한번 해보는게 아니라, 여러가지 서버사용방법들 한번 리서치해보시고 선택하신면 될것같습니다!

이번에 제이슨이 저희 서버로 CloudKit을 추천해주셨습니다.
저 포함 다른 분들도 잘 모르리라 생각해서, 공부 내용을 하나하나 정리해 나갈려고 합니다.

[GroundDev]

우선 애플 공식홈페이지에 있는것부터 살펴보죠

https://developer.apple.com/icloud/cloudkit/

Store your app’s data in iCloud and keep everything up-to-date across devices and on the web. Featuring efficient syncing, as well as simple monitoring and management, it’s never been easier to build and grow your apps with CloudKit. Store private data securely in your users’ iCloud accounts for limitless scale as your user base grows, and get up to 1PB of storage for your app’s public data.

네 이걸 통해서 iCloud 계정을 구독해야겠다는 결심이 섰습니다... 하하... 그래요 애플이 내게 주는 돈이 얼만데 이정도 푼돈은 내줄게...

마지막 문장에서 느낌이 확 오지 않나요?

CloudKit provides a comprehensive feature set that lets you easily develop powerful cloud apps.

네 그렇습니다. 이 녀석을 쓰게 되면, 우리의 앱이 cloud app이 됩니다. Wow.

Configure fields in private CloudKit databases to be encrypted, ensuring data protection in storage and in transport to your application.

또한 데이터의 보안이 보장된다는 점도 매우 좋네요! 저희는 서버를 통해 서로의 메시지를 전달할텐데, 그 또한 민감한 내용이 들어갈 수도 있으니까요.
이러한 CloudKit에 관해 배우는 과정으로 애플이 제시한 단계는 총 4단계입니다.

1. Designing for CloudKit(https://developer.apple.com/icloud/cloudkit/designing/)
2. CloudKit sample projects(https://github.com/apple?q=cloudkit-sample&type=repository”)
3. CloudKit framework(https://developer.apple.com/documentation/cloudkit)
4. CloudKit development automation(https://developer.apple.com/icloud/cloudkit/automating/)

하나하나 살펴봅시다!

[GroundDev]

Desigining for CloudKit

https://developer.apple.com/icloud/cloudkit/designing/

Containers

CloudKit organizes data using logical spaces called containers. A single CloudKit app typically uses a single container for all of its production data, although you can configure a single app to use multiple containers and multiple apps can use a single container. Each container represents an app’s storage in CloudKit and silos your app’s data. You manage the app’s schema within its container.

containers는 logical한 space인데, CloudKit은 이 containers라 불리는 녀석을 이용해서 데이터를 조직화한다고 하네요.
대체적으로는 하나의 CloudKit app은 하나의 container를 쓰길 마련이지만, 뭐 세상살이가 그렇듯이 꼭 그런건 아니라네요.
각각의 container는 CloudKit 내의 앱의 저장공간을 나타내며, 앱의 데이터를 silo(지하저장고)화 한다고 합니다.
말 그대로 컨테이너네요.
우리는 이 앱을 도식화할 때(뭐 앱을 설계할때를 뜻하는것 같죠?) 이 container내에서 한다고 합니다.

Databases

Containers can include different types of databases: public, private, and shared. Each container has a single public database that is shared among all users of the app. Individual app users also have exclusive access to their own private database, as well as a shared database that allows them to share information with other users (see below).

근데 위에서 살펴본 container란 녀석이 글쎄 무려 3가지의 database를 가질 수 있다고 합니다. 바로 public, private, shared 입니다.
우선, 이 public은 무엇이냐. 이 앱을 쓰는 모든 유저가 공유하는 database입니다. 각 container는 이러한 public을 하나 가진다고 하네요.
이 앱을 사용하는 한 유저는 개인의 private, 다른 유저와의 데이터 공유를 가능케 하는 shared에 대해 배타적인(독점적인) 접근 권한을 가진다고 합니다.
이렇게 세 종류의 database를 선택적으로 사용함으로써 ACL model같은 듣기만 해도 머리가 아파지는 녀석들을 쓰지 않고도 data access를 control할 수 있게 되었다고 합니다.
각 녀석들의 활용은 그 이름에서 대충 짐작은 되는데, shared는 뭘까요? 이 녀석은 유저가 어떤 특정 유저들과(이 앱을 이용하는 많은 유저가 아닙니다!) 특정 데이터를 같이 보고 수정하는 용도로 채택됩니다.

Zones

CloudKit’s databases contain zones, which are logical separations of data records. A public database has only one zone, called the default zone. Each private database also has a default zone, but the database can also be separated into multiple custom zones. Shared databases do not have a default zone (see below).

네 그렇게 지금까지 살펴본 결과, 대체적으로는 하나의 앱은 하나의 container를 사용하고, 그 하나의 container 내에는 public, private, shared라는 세 종류의 database들이 용도에 맞게 선택적으로 잘 사용된다는걸 알 수 있었습니다. 그리고 그러한 database는 data records의 logical한 seperation인 zone들로 이루어져 있습니다. public 이 녀석은 default zone이라고 하는 한 zone만 갖고 있습니다. private 또한 하나의 default zone을 가지는데, 이 녀석은 신기하게도 여러개의 custom zone들로 분리가 될 수 있다고 하네요. shared는 default zone이 없습니다.

When a record is saved to a public or private database, it's placed by default in that database’s default zone. However, you can choose to place records in custom zones within your private database. Custom zones are useful for grouping related records together for specific purposes. For example, if you have different kinds of data in your private database that need to be updated at different rates on devices, you could group different sets of that data into different zones based on type and sync any changes on a zone-by-zone basis. This lets you avoid syncing all zones at once, eliminating unnecessary data transfers.

당연히 shared에는 default zone이 없으니까, 만일 record가 저장되어야 한다면 public 또는 private으로 갈겁니다. 이때 뭐 해당 database의 default zone에 놔둬지는건 그야말로 '기본값'이겠죠. 근데, 이러한 record들을 private내에서 custom zone으로 넣을 수도 있습니다. 이렇게 하면 무슨 장점이 있을까요? 바로 관련있는 record들끼리 그룹핑이 가능하다는 겁니다. 이렇게 함으로써 효율적인 data transfer를 설계할 수 있게 되죠.

Environments

CloudKit provides separate development and production environments for your projects and apps. When your project is still in the development stage, you store your container’s schema and records in the sandbox environment, which allows you to test or experiment with your database schema before you make it available to users. Only members of your development team have access to the sandbox environment.

이러한 CloudKit은 project, app에 따라 개별적인 개발환경들을 제공한다고 합니다.

After you finish developing your schema, you can move it into production through a process called promotion. When promoted, the schema can only be modified in a forward-compatible manner. This means you can’t delete entity types. You can add fields in an entity, but you can’t modify or remove them. Because you typically don’t have control over the frequency of client updates, this methodology helps ensure continuity between older clients and schema changes. When you’re ready to distribute your app for testing, migrate the development schema to the production environment, copying over its record types, fields, and indexes. Apps sold on the App Store can access only the production environment.

Um... okay! 다 이해하셨죠? :)
원래 공부란 것이 우선 이해되는것들만 훌쩍훌쩍 읽어가면서 나중에 이 부분이 필요해지면 다시 와서 읽어야지 하면서 넘어가면 됩니다. 넘어가죠!

Permissions and access control

CloudKit uses role-based access control (RBAC) to manage privileges and control access to data in public databases (private databases are private). With CloudKit, you set permission levels for a role, then assign the role to a given record type.

만일 data가 public에 들어가기로 결정했다면, 해당 data는 이 앱을 쓰는 모든 유저에게 공유되게 됩니다. 그렇다면 모두가 접근할 수 있는 건 좋은데, 그때의 권한을 좀 세분화해서 할 필요가 있겠어요. '역할'에 따라 permission level을 달리 책정해둔 상태에서, 어떠한 record type에 그러한 '역할'을 부여하면 됩니다. 이러한 permission level에는 read, write, create이 있다고 하네요. 그리고 role에는 World, Authenticated, Creator가 있다고 합니다.

Connectivity

CloudKit provides strongly consistent storage and makes it easy to share that data across a user’s devices or among multiple users. Because the data is shared, your app also needs to keep local records synchronized. Its native framework lets you store your app’s data in CloudKit containers, so a user can access it on multiple devices.

app의 데이터 자체를 CloudKit container에다가 넣어둠으로써 여러 기기에서, 여러 사용자 간의 데이터 공유를 한결같이(즉 뭐 믿을 만하게 한다는 뜻이겠죠), 그리고 매우 쉽게 할 수 있다고 합니다.

[GroundDev]

여기까지 공부한 결과를 바탕으로 우리 앱에서 어떻게 사용해먹을지 한번 생각해봤습니다.

1. 우선 김재성97 회원이 "러브야 생일축하해"라는 메시지를 작성해서 Send를 눌렀습니다. 이 "러브야 생일축하해"는 public, private, shared 중 어디에 저장될까요?
   먼저 public에다 넣는걸 생각해볼까요? public은 앞서 말씀드린바와 같이 이 GiveCake앱을 이용하는 모든 유저가 접근할 수 있는 database입니다. 물론 접근은 하되 그 와중에 뭘 할 수 있는지는 저희가 각각의 유저에게 '역할'을 지정해서 달리 할 수 있을 것 같긴 합니다, 만, 그럴 필요가 있나요? 김재성97 회원이 보낸 메시지를 그라운드79 회원이 볼 일은 없습니다. 즉 기부자 그룹, 위탁가정 그룹 이렇게 두가지의 그룹으로 나눠진다 할 때 기부자 그룹에는 전혀 전달될 필요가 없는거죠. 물론 public으로 하고선 read도 주지 않으면 되는거 아니냐고 할 수 있는데, 제일 최소한의 level인 read도 안되게 할려 한다면 굳이 public으로 할 필요가 없을 겁니다.
2. 그래서 남은건 private, shared이 두 가지 선택지인데, 아래 그림을 살펴보죠.

저희의 목적과 얼추 비슷해 보이지 않습니까? App User 1을 방금 메시지를 작성한 김재성97이라고 가정해보죠. 이 메시지는 김재성97 유저의 private의 zone으로 들어가면 됩니다(default zone인지 분리한 zone인지는 아직 잘 모르겠어요. 이후 용도에 따라 달라지겠죠?). 이후 위탁가정 그룹에 속한 모든 유저들의 shared로 전달되면 됩니다.

---

이렇듯 저희가 CloudKit을 이용한다면, 어떤 데이터를 다루며 각각의 데이터는 어디에서 생성되어서 어디로 흘러가는지를 미리 세분화하여 정리해야 구현할때도 모델을 쉽게 구현할 수 있을 것으로 보입니다.

[GroundDev]

CloudKit sample projects

https://github.com/apple?q=cloudkit-sample&type=repository”

이게 들어가보면 알겠지만, 애플이 친절하게도 어떻게 쓰는지를 tutorial로 만들어줬습니다
만
이 친구들 SwiftUI, UIKit tutorial에서 한두번 당한게 아니잖아요? 지금 생각해보면 무슨 tutorial에 JSON parsing해오는 코드를 집어넣을수가 있는거죠. 애플 친구들 머리는 좋은데 tutorial은 기가막히게 못만들어요.
이번에도 아니나다를까 import UIKit, import SwiftUI 동시에 나오는걸 보고 GG쳤습니다.
나중에 코드가 필요하면 그때 참고해야지, 개념 단계인 현 시점에서는... 봐 봤자 이해 안됩니다.

[GroundDev]

CloudKit framework

https://developer.apple.com/documentation/cloudkit

아 이건 뭔가 했더니 공식문서네요! 공식문서를 전부 다 번역하긴 어려우니 읽어보고 주목할 만한 내용이 있다면 추가적으로 update하겠습니다.

[GroundDev]

CloudKit development automation

https://developer.apple.com/icloud/cloudkit/automating/

이걸 제대로 써먹고 있는지를 테스트를 할 수 있는 tool을 제공해준다는 것 같네요.

[GroundDev]

정말 놀랍게도 이 CloudKit에 관한 논문이 있습니다.
논문이 읽을때는 머리아프긴 한데 일단 읽으면 유용하게 쓸 때가
없었는데요
그래도 있으니 한번 읽어볼 필요는 있겠습니다.
쭉 훑어보니 초반에 개념 설명해주는 부분이 있는데, 이 부분을 읽어보면 되겠습니다.
논문의 생명은 빌드업에서 나오기 때문에, 이렇게 초반부에 위치한 개념설명은 은근히 읽기가 쉽기도
하고 어렵기도 해가지고 읽어봐야 알 것 같습니다.
단, 2018년도 자료임은 고려하면서 살펴보면 좋을 것 같습니다.
https://www.vldb.org/pvldb/vol11/p540-shraer.pdf

[HANS5109]

와우 엄청 많네요! 고생하셨어요👏

[SeonJeon]

이제 다 읽어봤는데 잘 정리하셨네요 고생하셨습니다 :)