インストールと設定
リソース計画
DLT を実行するために必要なハードウェア構成は、必要なスループットとレイテンシ要件に依存します。Cassandra は、CPU、ディスク IO、およびメモリ要件が最も多いコンポーネントです。ほとんどの場合、パフォーマンスは CPU 使用率またはディスク IO レイテンシによって制限されます。Cassandra インスタンスの CPU 使用率およびディスク IO レイテンシを監視し、Cassandra サーバーの CPU とディスク帯域幅が十分であることを確認することをお勧めします。サーバー接続されたディスクを使用するとディスクレイテンシが小さくなるため、ネットワーク接続されたディスクに比べてスループットが向上します。
Core と Apollo にはシステム要件がほとんどなく、同じインスタンスにインストールできます。ただし、これらのアプリケーションは、Cassandra インスタンスとは別のインスタンスで実行することをお勧めします。
インストールと設定
このセクションでは、DLT スタックのインストール方法について説明します。以下の手順では、特定のクラウドプロバイダを想定せず、任意のインフラストラクチャプロバイダおよびベアメタルセットアップに適用することができます。
前述のとおり DLT には 3 つの階層があり、各階層のインストール手順は以下のとおりです。このガイドで説明されている手順に従って、特定のインフラストラクチャ環境でスタックを設定する自動化スクリプトを作成できます。このような AWS 向けスクリプトのセットはここに用意されています。
ステップ 1: Cassandra のインストール
DLT スタックには Cassandra バージョン 2.2.11 が使用されています。次のコードを使用して、クラスタのすべてのインスタンスに Cassandra をインストールできます。
# Add Apache repository
$ cat > /etc/yum.repos.d/cassandra.repo <<EOF
[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/22x/
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://www.apache.org/dist/cassandra/KEYS
EOF
# Install Cassandra
$ yum install cassandra
ステップ 2: Cassandra の構成
Cassandra をすべてのインスタンスにインストールしたら、設定が必要です。設定の前にシードノードを選択する必要があります。シードノードとして、Cassandra クラスタの 1 つまたは 2 つのインスタンスが指定されます。各シードノードの IP アドレスはメモしておきます。次に、各 Cassandra インスタンスの Cassandra 構成ファイル /etc/cassandra/conf/cassandra.yaml で次の値を変更します。構成ファイルのその他のプロパティはすべてデフォルト値のままにしておきます。
cluster_name: Orb DLT
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "<Seed node 1 IP>", "<Seed node 2 IP>"
listen_address: <private node ip>
rpc_address: <private node ip>
endpoint_snitch: GossipingPropertyFileSnitch
commitlog_sync: batch
commitlog_sync_batch_window_in_ms: 2
設定が完了したら、シードノードで Cassandra を 1 つずつ起動します。シードノードが使用可能になった後、その他のノードは一括で起動できます。
$ sudo service cassandra start
サービスがすべてのノードで起動された後、nodetool status コマンドを使用して、任意のノードでクラスタのステータスを確認できます。予想される出力は次のようになります。
$ nodetool status
Datacenter: datacenter1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 10.0.0.10 103.26 KB 256 100.0% 8cb0b05d-f55d-4792-8512-cdbabeabe0b1 rack1
UN 10.0.0.20 101.91 KB 256 100.0% 5775d3d3-e4be-4e80-9113-85920426ca98 rack1
UN 10.0.0.30 102.11 KB 256 100.0% 8fb8b86d-67fa-4de7-b9e6-13fd04b6ab92 rack1
ステップ 3:Apollo のインストール
次のステップは、Apollo のインストールです。Apollo は、Cassandra を実行しているインスタンスとは別のインスタンスにインストールすることをお勧めします。
Apollo は Java アプリケーションです。Java は事前にインストールしておく必要があります。Oracle JDK v1.8 の使用を推奨します。 以下のステップは、Java を他の前提条件とともにインストールする場合の例です。
# Install Java
$ S3_STORE="s3://imagine-orb-com-k8s-state-store"
$ aws s3 cp $S3_STORE/jdk/jdk-8u144-linux-x64.tar.gz /tmp/
$ tar -xzf /tmp/jdk-8u144-linux-x64.tar.gz -C /usr/lib/jdk
$ ln -sf /usr/lib/jdk/jdk1.8.0_144/bin/java /usr/bin/java
$ rm /tmp/jdk-8u144-linux-x64.tar.gz
S3 から Apollo jar と設定ファイルをダウンロードします。将来的には、これらのファイルを他のソースからも入手出来るようにするかもしれません。
$ S3_STORE="s3://imagine-orb-com-k8s-state-store"
$ tar_name=apollo.tar.gz
# Configuration Files
$ aws s3 cp --recursive $S3_STORE/applications/apollo/conf/ /etc/apollo/conf/
# Apollo jars
$ aws s3 cp $S3_STORE/applications/apollo/$VERSION/$tar_name /usr/local/bin/apollo/$VERSION/
$ tar -xzf /usr/local/bin/apollo/$VERSION/$tar_name -C /usr/local/bin/apollo/$VERSION/
$ ln -sf /usr/local/bin/apollo/$VERSION/jars /apollo/
最後に、/etc/apollo/conf/storage.yaml ファイルに Cassandra を実行しているノードの IP アドレスを設定します。ファイルは次のようになります。
# Configurations in Apollo Storage (/etc/apollo/conf/storage.yaml)
storage_class: com.orb.apollo.storage.api.CassandraStorage
endpoints:
- 10.0.0.10
- 10.0.0.20
- 10.0.0.30
Apollo を開始する準備が完了しました。Linux ディストリビューションに応じて、upstart または systemd を使用して Apollo を実行することを推奨します。サーバーを実行した後の出力は次のようになります。デフォルトでは、Apollo サーバーはポート 9090 をリッスンします。
$ java -cp "/apollo/jars/netty-all-4.0.42.Final.jar:/apollo/jars/*" com.orb.apollo.thrift.Server
2018-01-17 14:30:49,728 [INFO com.orb.apollo.thrift.Server] Apollo Thrift server is started.
ステップ 4:Core のインストール
インストールの最後のステップは Core のインストールです。Core は単一のバイナリアプリケーションです。実行時に渡される引数に応じて、同じバイナリを Coin Core、Account Core、または Query Core として使用できます。Core には依存関係の要件はありません。
次のステップで AWS S3 からバイナリファイルをダウンロードします。$VERSION 変数は、DevOps チームで利用可能なリストから選択する必要があります。
$ S3_STORE="s3://imagine-orb-com-k8s-state-store"
# Download the core binary
$ mkdir -p /usr/local/bin/core/$VERSION
$ aws s3 cp $S3_STORE/applications/core/$VERSION/core /usr/local/bin/core/$VERSION/
$ ln -sf /usr/local/bin/core/$VERSION/core /usr/bin/core
ステップ 5:Core の設定
Core、Coin、Account、Query の設定ファイルが正常にインストールされたら、使用できる状態にする必要があります。これらの設定ファイルのセットは、S3 上にも用意されています。次のステップでは S3 からダウンロードする方法を示しますが、独自の設定ファイルを使用することもできます。現在は、特定の構成ファイルのセットを使用して DLT スタックが動作状態になると、その構成ファイルを変更することはできないことに注意してください。
# Download configuration
$ mkdir -p /etc/core/conf
$ aws s3 cp --recursive $S3_STORE/applications/core/conf/ /etc/core/conf/
バイナリは、以下のように Coin Core、Account Core、および Query Core プロセスを開始するために使用できます。同じインスタンスに Apollo サーバーをインストールした場合、デフォルトでは Apollo の ip:port は localhost:9090 になります。これらのサービスについても、systemd または upstart のサービスファイルを作成することをお勧めします。
# Start Coin Core
$ /usr/bin/core coin -tls=false -config=/etc/core/conf -listen=0.0.0.0:8080 -log=warning -storage-host=<apollo ip:port> -keyspace=orb_coin
# Start Account Core
$ /usr/bin/core account -tls=false -config=/etc/core/conf -listen=0.0.0.0:8080 -log=warning -storage-host=<apollo ip:port> -keyspace=orb_coin
# Start QueryCore
$ /usr/bin/core query -tls=false -config=/etc/core/conf -listen=0.0.0.0:8080 -log=warning -storage-host=<apollo ip:port> -keyspace=orb_coin
Cassandra の操作
すべてのデータベースには定期的なチェックと保守が必要です。Cassandra クラスタに対して定期的に修復とバックアップの手順を実行することをお勧めします。修復により、クラスタ内のすべてのノードが常に互いに同期していることが保証されます。万が一 Cassandra クラスタに重大な障害が発生した場合でも、バックアップによりデータが失われるのを防ぎます。以下のセクションでは、それぞれの運用について詳細に説明します。
修復
分散データベースシステムでは、ノード上のデータがクラスタの残りの部分と同期していない状態が生じることがあります。たとえば、ノードがしばらくの間停止していたり、ネットワークの問題のためにアクセスできないような場合です。Cassandra はこのようなシナリオに自動的に対処するように設計されていますが、定期的に各ノードで repair コマンドを実行することをお勧めします。このコマンドは、ノード上のデータをクラスタと同期させます。
修復コマンドは、Cassandra が稼動しているノードで次のように実行できます。このコマンドは、Cassandra が稼動している各ノードで実行してください。修復コマンドは少なくとも 10 日おきに実行することをお勧めします。cron を使用して修復の実行をスケジュールすることができます。
$ nodetool repair
修復プロセスはリソースを大量に消費します。修復処理は一度に 1 つのノードに対してのみ実行することをお勧めします。修復コマンドを管理するには、Cassandra Reaper を使用することをお勧めします。Cassandra Reaper を使用するには、Cassandra でリモート JMX を有効にする必要があります。それには、etc/cassandra/conf/cassandra-env.sh ファイルでローカル JMX を無効にします。次に、Reaper をインストールして DLT Cassandra クラスタを修復するように設定します。Reaper には Web ベースの UI があります。設定時は、SSH Tunneling を使用して Web ベースの UI にアクセスできます。
バックアップ
Cassandra データベースは定期的にバックアップする必要があります。バックアップは、データのリストア、あるいは Point-in-Time リストアに役立ちます。バックアップ手順を設定するには、すべての Cassandra ノードでバックアップスクリプト tar をダウンロードします。各ノードを個別にバックアップする必要があることに注意してください。
バックアップスクリプトをダウンロードしたら、conf/backup.yaml ファイルを使用して次のように設定します。
# Application name
app_name: ORB_DLT
# keyspaces:
cass_keyspaces:
system:
Orb_coin:
# cassandra's config file path
cass_conf_path: /etc/cassandra/conf/cassandra.yaml
# the period to upload incremental backup file
cass_upload_upload_period_incremental_backup: 86400
バックアップスクリプトはノード上の Cassandra データファイルをバックアップして AWS S3 にアップロードします。バックアップは次のコマンドを実行して開始します。
$ AWS_S3_BUCKET_NAME=<bucket_name> backup.sh SNAP
cron を使用して毎週のバックアップをスケジュールします。
監視
DLT スタックの 3 つのコンポーネントのすべてについてアプリケーションの健全性を監視するようにスクリプトを構成することをお勧めします。AWS Cloudwatch を使用して、Cassandra、Apollo、および Core アプリケーションに関するさまざまな統計情報を保存および表示することができます。次のパラメータを追跡できます。
- Cassandra: Cassandra はスタック内で唯一のステートフルアプリケーションです。これにはすべての台帳データが保存されます。監視が必要な Cassandra の主なパラメータは、プロセスのライブ状態、ディスクパラメータ、および CPU 使用率です。次のパラメータを推奨します。
- サービスステータス: 理想的には、すべてのノードが常に稼動している必要があります。ただし、RF 3 で Cassandra を実行している場合、1 つのノードが停止してもクラスタは引き続き動作します。サービスステータスメトリックを使用して、ノードが停止したときにアラートが出力されるようにします。これにより、2 つ以上のノードが同時にダウンする可能性を低くすることができます。
- 残りディスク容量: ノードは常に 60 ～ 70％未満のディスク使用率で動作していることが理想的です。これは、バックアップをスムーズに実行するための要件です。これよりも使用率が増える場合は、より大きなインスタンスに移動するか、ディスク容量を増やします。
- ディスク読み書きの IO 統計: ディスク IOPS (読み取りと書き込み) が台帳トランザクションのボトルネックになる場合があります。20 の台帳トランザクションに対して 1 秒当たり約 2K の書き込み IOPS が発生していることが確認されています。スループットの問題が発生した場合は、ディスク IOPS が上限に近づいていないかを確認してください。
- CPU 使用率: これは高スループットに対するもう 1 つのボトルネック要因です。常時高い CPU 負荷で稼動している場合、Cassandra ノードの数を増やすか、より大きなサーバーを使用する必要があります。
- Apollo と Core
- メモリ使用量: アプリケーションにメモリリークがないことを確認することが重要です。
- CPU 使用率: Apollo と Core は、どちらも CPU の要件が最小限に抑えられています。両方を合計すると、1 秒当たり 20 のトランザクションで t2.large AWS インスタンスの CPU を 10% 使用します。
AWS Cloudwatch を使用すると、上記のパラメータの監視ツールを簡単に設定できます。これは開発者側での設定が不要で、CPU 使用率などの基本的な監視を提供します。カスタムパラメータを追加するには、こちらのスクリプトを使用してこれらのメトリックを Cloudwatch にアップロードすることができます。AWS Cloudwatch コンソールを使用して、これらのメトリックを表示するダッシュボードを設定できます。
まとめ
要約すると、DLT スタックは Core、Apollo、Cassandra で構成されています。このガイドでは、これらのコンポーネントをインストールして接続する方法について説明しました。また、DLT セットアップをスムーズに実行する方法も説明しました。このガイドは主に AWS に重点を置いていますが、ここで説明するステップを別のクラウドプラットフォームに適用することもそれほど難しくはありません。
Updated about 6 years ago