ScalarDL Ledgerの制作チェックリスト
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
このチェックリストは、実稼働環境に ScalarDL Ledger を展開する際の推奨事項を提供します。
あなたが始める前に
このチェックリストでは、推奨される管理対象 Kubernetes クラスターに ScalarDL Ledger をデプロイしていることを前提としています。
プロダクションチェックリスト: ScalarDL Ledger
以下は、運用環境で ScalarDL Ledger をセットアップする際の推奨事項のチェックリストです。
ScalarDL の可用性
Kubernetes クラスターの高可用性を確保するには、少なくとも3つのワーカーノードを使用し、ワーカーノード全体に 少なくとも3つのポッドをデプロイする必要があります。3つのポッドをワーカーノードに分散させるための podAntiAffinity のサンプル構成を参照できます。
ワーカーノードを異なるアベイラビリティゾーン (AZ) に配置すると、AZ の障害に耐えることができます。
リソース
商用ライセンスの観点から、ScalarDL Ledger を実行する1つのポッドのリソースは 2vCPU / 4GB メモリに制限されます。ScalarDL Ledger ポッドに加えて、Kubernetes は次のコンポーネントの一部を各ワーカーノードにデプロイできます。
- ScalarDL Ledger ポッド (2vCPU / 4GB)
- Envoy プロキシ
- 監視コンポーネント (
kube-prometheus-stackなどの監視コンポーネントを デプロイする場合) - Kubernetes コンポーネント
これを念頭に置いて、ScalarDL の可用性 で説明されているように、少なくとも 4vCPU / 8GB のメモリリソースを持つワーカーノードを使用し、可用性のために少なくとも3つのワーカーノードを使用する必要があります。
ただし、ノードあたり少なくとも 4vCPU / 8GB のメモリリソースを備えた3つのノードが運用環境の最小環境となります。システムのワークロードに応じて、Kubernetes クラスターのリソース (ワーカーノードの数、ノードあたりの vCPU、ノードあたりのメモリ、ScalarDL Ledger ポッドなど) も考慮する必要があります。また、Horizontal Pod Autoscaling (HPA) などの機能を使用してポッドを自動的にスケーリングする予定の場合は、ワーカーノードのリソースを決定するときにワーカーノード上の最大ポッド数を考慮する必要があります。
通信網
ScalarDL Ledger はインターネットアクセス経由でユーザーにサービスを直接提供しないため、Kubernetes クラスターはプライベートネットワーク上に作成する必要があります。アプリケーションからプライベートネットワーク経由で ScalarDL Ledger にアクセスすることをお勧めします。
監視とログ記録
デプロイされたコンポーネントを監視し、そのログを収集する必要があります。詳細については、Kubernetes クラスター上の Scalar 製品の監視および Kubernetes クラスター上の Scalar 製品からのログの収集を参照してください。
バックアップと復元
バックエンドデータベースで自動バックアップ機能とポイントインタイムリカバリ (PITR) 機能を有効にする必要があります。詳細については、ScalarDB/ScalarDL 導入用のデータベースのセットアップ を参照してください。
運用チェックリスト: ScalarDL Ledger にアクセスするクライアントアプリケーション
以下は、運用環境で ScalarDL Ledger にアクセスするクライアントアプリケーションをセットアップする際の推奨事項のチェックリストです。
クライアントアプリケーションのデプロイメント
ScalarDL でのビザンチン障害検出が適切に機能するには、アプリケーションポッドを ScalarDL Ledger デプロイメントと同じ Kubernetes クラスターにデプロイしないでください。代わりに、ScalarDL Ledger デプロイメントの管理ドメイン以外の環境 (Kubernetes クラスター以外) にアプリケーションをデプロイする必要があります。
実稼働環境に必要
運用環境では推奨されません (テスト目的のみ)
コントラクトと機能
コントラクトと機能がガイ ドラインに従っているかどうかを確認するには、次を参照してください。
コントラクトのバージョン管理
コントラクトを登録した後は、既存のコントラクトを上書きすることはできません。したがって、コントラクトのバージョン管理を検討する必要があります。次の2つの方法のいずれかを推奨します。
クラス名 を使用したバージョニング
Contract ID : FooV1
Binary Name : com.example.contract.FooV1
Class file (Class Name) : src/main/java/com/example/contract/FooV1.class
---
Contract ID : FooV2
Binary Name : com.example.contract.FooV2
Class file (Class Name) : src/main/java/com/example/contract/FooV2.class
Package Name を使用したバージョニング
Contract ID : FooV3
Binary Name : com.example.contract.v3.Foo
Class file (Class Name) : src/main/java/com/example/contract/v3/Foo.class
---
Contract ID : FooV4
Binary Name : com.example.contract.v4.Foo
Class file (Class Name) : src/main/java/com/example/contract/v4/Foo.class
コントラクト上の制限
コントラクト登録時にバイナリ名、パッケージ名、クラス名が異なる場合、登録後にそのコントラクトを実行することはできません。
バイナリ名とクラス名が異なります (このコントラクトは実行できません)
Contract ID : FooV5
Binary Name : com.example.contract.FooV5
Class file (Class Name) : src/main/java/com/example/contract/FooV6.class
バイナリ名とパッケージ名が異なります (本コントラクトは実行できません)
Contract ID : FooV7
Binary Name : com.example.contract.v7.Foo
Class file (Class Name) : src/main/java/com/example/contract/v8/Foo.class
秘密鍵と証明書
認証に PKI を使用する場合、ScalarDL Ledger に登録する秘密鍵と証明書が次の要件を満たしていることを確認する必要があります。
Algorithm : ECDSA
Hash function : SHA256
Curve parameter : P-256
詳しくは How to get a certificate をご覧ください。
例外処理
アプリケーションが例外を処理することを確認する必要があります。詳細については、A Guide on How to Handle Errors in ScalarDL を参照してください。