Canister のデプロイとアップグレード

デプロイのメカニズム

デプロイの際、懸念されるのは主に２点です。それは Canister とコードです。 Canister に関する懸念は、コードが最終的にどこで実行されるのか、そしてそれをどのように正しい場所に持っていくのか、ということに尽きます。もうひとつは、データの損失がなく、ダウンタイムが可能な限り短く、設定ミスがないように、コードをどのように管理するかということです。デプロイ時には考慮すべきことが多く、うまくいかないことも多いため、開発者を楽にするためのツールが存在します。そのようなツールのひとつが DFINITY Canister Software Development Kit（SDK）で、デプロイを管理する CLI ツールは dfx と呼ばれています（このページでは例として用いられています）。

Canister ライフサイクル

Internet Computer は、いわゆる Canister で任意の WebAssembly モジュールを実行します。最初のデプロイでは、実行するはずの個々の WebAssembly モジュールごとに新しい Canister を作成する必要があります。これらの Canister の作成時に、Canister ID が割り当てられます。Canister には中央レジストリは存在しないので、開発者（あるいはそのツール）はこれらの ID を追跡する必要があります。コードが Canister にデプロイされると、Canister ID を使用して他の Canister の関数を呼び出すことができるようになります。

Canister は実行中に Cycle を消費します。計算の実行だけでなく、データの保存にも Cycle がかかります。 Canister が動作している間は、動作を維持するのに十分な Cycle を含んでいなければなりません。ここでも、開発者（または開発ツール）が ID や Cycle 残高を追跡する必要があります。Canister の Cycle が非常に少なくなると、フリーズし（更新の呼び出しに応答しなくなる）、完全になくなると、削除されます。

誰もが Canister の変更を許可されているわけではありません。 Canister にはすべて、設定の更新や実行中のコードのインストール/アップグレード、さらには Canister の削除を許可されたコントローラーのリストが存在します。開発者、自動化ツール、他の Canister、または何もない状態でも、コントローラーになることができます。 Canister の目標に応じて、さまざまなコントローラーを組み合わせることができます。以下のセクション信頼の実践 で、より詳しく説明しています。

Canister のライフサイクルが終了したら、削除することができます。その前に、所有者の一人が Canister を削除する前に、残りの Cycle を引き出しておくことをお勧めします。そうしないと、これらの Cycle は失われます。これらの Cycle を手動で引き出すのはかなり面倒な作業なので、この作業を容易にするツールが存在します。 Canister を削除する以外の方法として、自動的に削除されるまで Canister を稼動させたままにすることができます。

コードをデプロイする

Canister は任意の WebAssembly（WASM）モジュールを実行できますが、 Internet Computer にはその機能を最大限に活用しやすくするためのいくつかの規約があります。例えば、canister_init という関数は、コードが初めてインストールされた後に最初に呼び出される関数です。これらの規約を守りやすくするために、 Canister 開発キット（CDK）が 異なる言語毎に存在します。

Internet Computer の install_code 機能で利用できる 3つのモードのうちのひとつを Canister にコードをインストールするには：

• install モードはすべての Canister が持つモードです。インストールされていない Canister に対してのみ呼び出すことができ、 Canister に提供された Wasm モジュールを組み込みます。インストールが完了すると、前述の関数 canister_init（通常 CDK では init として公開されます）が存在すれば、それが呼び出されます。これにより、呼び出しが行われる前に、コードが必要な設定を行うことができます。
• reinstall モードは install とほぼ同じ動作をしますが、 Canister にすでに実行中のコードが含まれている場合、そのステートは破棄され、実行中のコードが削除されます。その後は install モードの手順が踏襲されます。
• upgradeモードは最もよく使われるモードです。このモードでは、 Canister のステートをすべて失うことなく、Canister のコードを変更することができます。このモードでは、まず Canister は canister_pre_upgrade（CDK では pre_upgrade として公開）関数でステーブルメモリに任意のステートを保存します。その後、新しいコードがインストールされ、init 関数を呼び出す代わりに canister_post_upgrade 関数（CDK では post_ugrade として公開）を実行して、ステーブルメモリからデータを読み込むことができるようになります。 3つの install_code モードは、すべてアトミックです。もし、説明した手順の中で何か問題が発生した場合、 Canister のステートは install_code 関数が呼ばれる前のステートに戻されます。また、これらの説明で十分に理解できない場合は、install_code の IC 仕様 を御覧ください。

caution

Internet Computer のすべての関数呼び出しには、実行可能な命令数の制限があります。もし pre_upgrade 関数がこの制限を超えると、関数はキャンセルされ、アップグレードは失敗します。これによって、 Canister がアップグレードできなくなることがあります。この制限を回避する方法として、Wiki にいくつかのアイデア があります。

既存の Canister をアップグレードする場合、さらにいくつかの注意点があります：

• 未決定（Outstanding）のコールバック：Canister が他の Canister からのレスポンスを await している場合、送信してからレスポンスを受信するまでの間にアップグレードされてしまう可能性があります。コードが upgrade モードでインストールされている場合、コールバックはアップグレードが行われていないかのように実行されます。このようなことが起こしたくないのなら、まず Canister を停止するか、コードをアンインストールしてから、再度インストールする必要があります。
• インターフェイスの互換性：Canister やスクリプトが、アップグレードされた Canister に特定のインターフェイスがある場合、アップグレードによって既存のワークフローが破壊される可能性があります。DFX は、アップグレードによって特定の署名が壊れることを（可能な限り）ユーザーに警告しますが、見落とされる可能性のあるコーナーケースが存在します。

考慮すべきこと

• （ガスの）資金調達
• Demonstrating Trust

資金調達

Internet Computer Canister は、時間の経過とともに徐々に消費される Cycle のバランスに応じて資金を調達しています。お客様は、割り当てられたメモリ量と、クエリーやアップデートにかかる CPU 時間に対して支払いを行うことになります。

ここでは、そのチェックリストを紹介します：

• Canister の資金源とはなにか？
  • デベロッパーによる前払い
  • コミュニティからの寄付金で調達
  • ICP や Cycle の継続的な収益で賄われる
• Canister のバランスはどのように把握するのか？
• 万が一、残高が足りなくなった場合の対策は？
• 残高がなくなり、最終的に Canister が消去されたらどうなるのか？

ユースケースによって、アプリケーション毎に異なる答えが最適解になるでしょう。追加されたすべてのコンテンツが永遠に利用できると仮定する他のブロックチェーンとは異なり、Internet Computer では、使用しているコンピューティングリソースのコストと持続可能性について考える必要があります。

NFT プロジェクトや DeFi Canister は、取引手数料を使って自分たちの Cycle を購入することで、自己資金を確保することができるかもしれません。その他の使用例では、企業や DAO に残高を管理する責任を負ってもらうとよいでしょう。いずれにせよ、 Canister を長持ちさせるための計画について考えておくことは価値があります。

信頼の実践

ブロックチェーンの分野では、ユーザーがやり取りするスマートコントラクトをどのように信頼できるかが大きなトピックとなっています。あなたがデプロイしたいプロジェクトの種類によって、異なるレベルで適切な信頼モデルがあります。

ここでは、検討する必要がある事柄のチェックリストを示します：

• このプロジェクトには、どれくらいの信頼が必要か？
• Canister が本来の機能を発揮するためには、どのようにすればよいか？
  • Canister の信頼と再現可能なビルドには、このトピックに関連する情報が記載されています。
• コードが突然変更されないと、ユーザーは信頼できるか？