Meet CloudKit Console

ハイライト

Apple は CloudKit コンソールを発表し、開発者が CloudKit スキーマの管理、レコードのクエリ、運用変更のデプロイ、ブラウザでのテレメトリとログの表示を可能にし、同期データのデバッグとオンライン問題のトラブルシューティングのコストを削減します。

主要内容

開発者が CloudKit (iCloud データベース サービス) にデータを入力した後、実際に面倒な作業がオンラインになる前後に発生することがよくあります。

開発段階では、新しいレコード タイプが開発環境に書き込まれていること、フィールド タイプが正しく入力されていないこと、インデックスがクエリをサポートしていることを確認する必要があります。オンラインにする前に、スキーマを開発環境から運用環境にプッシュし、この展開によって古いクライアントが破壊されないことを確認する必要もあります。オンラインになった後、ユーザーは同期が失敗したと報告します。リクエストが CloudKit に到達したかどうか、および新しいバージョンのリリース後にエラーの数が増加したかどうかを知る必要があります。

以前は、これらのアクションはさまざまな見解に分散していました。問題を特定する場合、開発者はまずコンテナを見つけ、次に環境に切り替え、次にレコードを確認し、最後にログまたはインジケータを確認する必要があります。 CloudKit コンソールは、これらのアクションを統合インターフェイスに組み込みます。データベースはスキーマとロギングを担当し、テレメトリはメトリクスの集計を担当し、ログはリクエストレベルのトラブルシューティングを担当します。

今回の Apple の変更では、新しいクライアント フレームワークは導入されません。 CloudKit 開発者ワークベンチが変更されます。 CloudKit を使用するアプリの場合、これにより「データの書き込み - データの検証 - スキーマのデプロイ - オンラインでの動作の観察」のサイクルを直接短縮できます。

詳細

スキーマの管理: レコード タイプ、フィールド、インデックス

(01:24) CloudKit データベースはコンテナ内にあります。各コンテナには、Development (開発環境) と Production (実稼働環境) の 2 つの環境があります。開発者は、開発環境でジャストインタイムのスキーマ作成を使用したり、コンソールでデータ モデルを定義したりできます。

(02:21) レコード タイプは CloudKit データ構造を定義します。コンソールの「スキーマ」ページでは、レコードタイプ、フィールド、インデックスを表示できます。音声の例では、開発者は次のとおりです。authorフィールドには、アルファベット順に並べ替えるための並べ替え可能なインデックスが追加されます。

このセッションには「コード」タブはありません。次のスクリプトは、コンソール内の構成を実行可能なデータ構造に編成して、各ステップの検証を容易にします。コンソール自体は、Web ページを通じてこれらの操作を実行します。

const bookRecordType = {
  name: "Book",
  fields: [
    { name: "title", type: "String" },
    { name: "author", type: "String" }
  ],
  indexes: [
    { field: "author", type: "sortable" }
  ]
};

const sortableFields = bookRecordType.indexes
  .filter((index) => index.type === "sortable")
  .map((index) => index.field);

console.log(`${bookRecordType.name} can sort by: ${sortableFields.join(", ")}`);

キーポイント:

• name: "Book"コンソールのレコード タイプに対応します。
• fieldsレコードタイプに含まれるフィールドをリストします。スピーチにフィールドを追加するときは、フィールド名を入力し、タイプを選択する必要があります。
• author講義でソート可能なインデックスに使用されるフィールドです。
• indexesコンソールで作成されたインデックスを表します。講演では、インデックスを作成するときに、フィールドと 3 つのインデックス タイプのいずれかを選択する必要があると述べました。
• filter((index) => index.type === "sortable")シミュレーションがオンラインになる前に確認してください: どのフィールドが並べ替えをサポートしているか。

クエリ ビルダーを使用して開発環境レコードを検証する

(03:35) データベース アプリでのレコードの参照は、左から右のプロセスに従います。まず [データベース] を選択し、次に [ゾーン] を選択し、最後に [レコード タイプ] を選択します。コンテキストを選択すると、左側にレコードのリストが表示され、中央にレコードの詳細が表示されます。

(04:02) クエリ ビルダーは、ターゲット レコードを検索するためのフィルター条件を追加できます。クエリは保存して、後で開発を続行するときに直接再利用できます。コンソール URL は特定の機能を指すこともでき、開発者は Safari ブックマークにレコード ビューを追加できます。

const savedQuery = {
  environment: "Development",
  database: "Public",
  zone: "_defaultZone",
  recordType: "Book",
  filters: [
    { field: "author", operator: "equals", value: "Octavia Butler" }
  ]
};

function describeQuery(query) {
  const filterText = query.filters
    .map((filter) => `${filter.field} ${filter.operator} ${filter.value}`)
    .join(" AND ");

  return `${query.environment}/${query.database}/${query.zone}/${query.recordType}: ${filterText}`;
}

console.log(describeQuery(savedQuery));

キーポイント:

• environment: "Development"音声では開発環境のデータを検証する処理に相当します。
• database、zone、recordType左から右の 3 レベルのコンソール選択に対応します。
• filtersクエリビルダーのフィルタ条件に対応します。
• describeQueryクエリを読み取り可能なテキストに変換し、クエリを保存する前に手動チェックをシミュレートします。
• 実際のクエリは CloudKit コンソール Web ページで実行され、このスクリプトはチームによって合意されたクエリ条件を記録するために使用されます。

スキーマのデプロイ: まず diff を確認してから、実稼働環境に入ります。

(05:08) 開発環境のスキーマの準備ができたら、Deploy Schema Changes変更ビューに入ります。このビューには、運用環境の現在のスキーマと開発環境にデプロイされる変更との違いが表示されます。

(05:33) 運用環境の変更を元に戻すことはできません。 diff ビューの目的は、開発者が予想される変更のみが運用環境に反映されることを確認できるようにすることです。 CloudKit は、古いクライアントの破損を避けるために更新の整合性も検証します。

const productionSchema = {
  recordTypes: {
    Book: {
      fields: ["title"],
      indexes: []
    }
  }
};

const developmentSchema = {
  recordTypes: {
    Book: {
      fields: ["title", "author"],
      indexes: ["author:sortable"]
    }
  }
};

const changes = {
  addedFields: developmentSchema.recordTypes.Book.fields
    .filter((field) => !productionSchema.recordTypes.Book.fields.includes(field)),
  addedIndexes: developmentSchema.recordTypes.Book.indexes
    .filter((index) => !productionSchema.recordTypes.Book.indexes.includes(index))
};

console.log(JSON.stringify(changes, null, 2));

キーポイント:

• productionSchema現在の運用環境のステータスを示します。
• developmentSchemaデプロイメントの準備ができた開発環境の状態を表します。
• addedFieldsどのフィールドが実稼働環境に追加されるかを調べてください。
• addedIndexes実稼働環境に追加されるインデックスを見つけます。
• JSON.stringify(changes, null, 2)差分のような結果を出力して、デプロイをクリックする前に各項目を確認するよう開発者に思い出させます。

テレメトリとログを使用してオンライン動作のトラブルシューティングを行う

(05:46) スキーマがデプロイされた後、Telemetry アプリ (テレメトリ ツール) には、アプリと CloudKit データベースのやり取りの主要なメトリクスが表示されます。講演でリストされるメトリクスには、リクエスト レート、サーバー レイテンシー、エラー数、平均リクエスト サイズが含まれます。これらのグラフは、時間の経過に伴うアプリの動作の変化を観察するためのフィルタリングをサポートしています。

(06:20) ログ アプリ (ロギング ツール) は、より詳細なリクエスト処理出力を提供します。開発段階ではリクエストを検証するために使用でき、運用環境では問題を調査するために使用できます。

const telemetry = [
  { version: "1.0", requestRate: 120, serverLatencyMs: 80, errorCount: 2, averageRequestSizeKb: 14 },
  { version: "1.1", requestRate: 160, serverLatencyMs: 95, errorCount: 18, averageRequestSizeKb: 15 }
];

const previous = telemetry[0];
const current = telemetry[1];

const errorIncrease = current.errorCount - previous.errorCount;
const needsLogReview = errorIncrease > 10;

console.log({
  version: current.version,
  errorIncrease,
  needsLogReview
});

キーポイント:

• telemetry講演でリストされている 4 つの指標 (リクエスト レート、サーバー レイテンシー、エラー数、平均リクエスト サイズ) を使用します。
• versionスピーチにおける「新しいバージョンが異常な動作をするかどうか」という観測シナリオに相当します。
• errorIncrease新しいバージョンの後にエラーの数が増加するかどうかを判断するために使用されます。
• needsLogReview次のステップでは、ログ アプリにアクセスしてリクエスト レベルの詳細を表示する必要があることを示します。
• テレメトリは傾向を示し、ログはリクエストが実際に CloudKit によってどのように処理されているかを確認するために使用されます。

重要ポイント

1. やるべきこと: チーム用の CloudKit ロールアウト チェックリストを作成します。 実行する価値がある理由: コンソールの差分ビューでは、開発環境から運用環境へのスキーマの変更を表示できます。生産上の変更を元に戻すことはできません。 開始方法: 毎回展開するレコード タイプ、フィールド、インデックスのリストを作成し、[Deploy Schema Changesdiffで比較する前に項目ごとに確認してください。

2. 作業内容: 一般的なデバッグ シナリオ用にクエリ ビルダー クエリを保存します。 実行する価値がある理由: 講演では、クエリを保存し、その後の開発で再利用するプロセスが示されました。これは、同じ種類のテスト記録を繰り返し検証するのに適しています。 開始方法: データベース、ゾーン、レコード タイプでコンテキストを設定し、キー フィールドにフィルター条件を追加し、結果ページまたは関数 URL をブックマークします。

3. やるべきこと: 新しいバージョンのリリース用に CloudKit Telemetry 観察ウィンドウを作成します。 実行する価値がある理由: テレメトリでは、リクエスト レート、サーバー レイテンシー、エラー数、平均リクエスト サイズを表示できます。これは、新しいバージョンによってデータベースの対話動作が変更されるかどうかを確認するのに適しています。 開始方法: 公開後にエラー数とサーバー遅延を確認します。インジケーターが増加した場合は、ログ アプリにアクセスして、同じ期間のリクエスト処理の詳細を確認します。

4. 作業内容: 開発環境の書き込み検証を機能開発プロセスに追加します。 実行する価値がある理由: コンソールは開発環境でレコードの詳細を直接表示し、アプリによって実際に CloudKit に書き込まれた内容を確認できます。 開始方法: 新しいレコード タイプを追加するたびに、まず開発環境でテスト データを書き込み、次にクエリ ビルダーを使用してターゲット レコードをフィルターし、フィールド値を確認します。

5. やるべきこと: パブリック データベースのセキュリティ ロールの稼働前レビューを実施します。 実行する価値がある理由: 講演では、パブリック データベースのセキュリティ ロールには、パブリック データベース レコードへのアクセスを管理するための新しい UI があると述べられました。 開始方法: スキーマ管理フェーズでセキュリティ ロール ページを開き、読み取りおよび書き込み権限が製品の期待を満たしているかどうかを確認してから、運用環境にデプロイします。

関連セッション

• CloudKit の新機能 — CloudKit コンソールでの表示に適した、2021 年の CloudKit の新機能について学びます。
• cktool と宣言的スキーマを使用して CloudKit テストを自動化する — コマンド ラインと宣言的スキーマを使用してテストを自動化し、コンソールの手動操作プロセスを補完します。
• CloudKit と Core Data を通じてデータを共有するアプリを構築する — Core Data と CloudKit 共有データのアプリケーション アーキテクチャについて説明します。
• macOS の FileProvider を使用してファイルをクラウドに同期する — ファイル レベルの同期ソリューションに焦点を当てた、別のクラウド同期シナリオを示します。