GSP1116
概要
セキュリティ、コンプライアンス、パフォーマンス、プライバシーのために、独自のブロックチェーン ノードをホストする必要がある場合があります。分散型で、復元力があり、サステナブルなネットワークは、あらゆるブロックチェーン プロトコルにとって重要な基盤です。Web3 デベロッパーは、Web3 開発用のフルマネージド ノードホスティング ソリューションである Google Cloud のブロックチェーン ノード エンジンを使用できます。組織は、Google Cloud で独自のノードを構成して管理することもできます。Web3 インフラストラクチャの信頼できるパートナーとして、Google Cloud は安全で信頼性が高く、スケーラブルなノードホスティング インフラストラクチャを提供します。Google Cloud でのノードのホスティングについて詳しくは、ブログ投稿「Web3 開発のためのフルマネージド ノードホスティング、ブロックチェーン ノード エンジンを発表」をご覧ください。
セルフマネージド ブロックチェーン ノードをクラウドにデプロイする際に必要な技術的な考慮事項とアーキテクチャ上の決定事項について詳しくは、ブログ投稿「Web3 向け Google Cloud」をご覧ください。
このラボでは、仮想マシン(VM)を作成して Ethereum RPC ノードをデプロイします。Ethereum RPC ノードは、ネットワークからブロックチェーンの更新を受信し、RPC API リクエストを処理できます。ここで使用するのは e2-standard-4 マシンタイプで、20 GB のブートディスク、4 つの仮想 CPU(vCPU)、16 GB の RAM を搭載しています。ブロックチェーン データを格納できるだけの容量を確保するため、200 GB の SSD ディスクをインスタンスに接続します。Ubuntu 20.04 を使用して、「実行レイヤ」の Geth と「コンセンサス レイヤ」の Lighthouse の 2 つのサービスをデプロイします。これらのサービスは連携して Ethereum RPC ノードを形成します。
目標
このラボでは、次のタスクの実行方法について学びます。
- 永続ディスクを使用する Compute Engine インスタンスを作成する。
- 静的 IP アドレスとネットワークファイアウォール ルールを構成する。
- 定期バックアップをスケジュールする。
- Ethereum の実行レイヤである Geth をデプロイする。
- Ethereum のコンセンサス レイヤである Lighthouse をデプロイする。
- Ethereum RPC 呼び出しを行う。
- Cloud Logging を構成する。
- Cloud Monitoring を構成する。
- 稼働時間チェックを構成する。
設定と要件
[ラボを開始] ボタンをクリックする前に
こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。
このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
- 標準的なインターネット ブラウザ(Chrome を推奨)
注: このラボの実行には、シークレット モード(推奨)またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。
- ラボを完了するための時間(開始後は一時停止できません)
注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。
ラボを開始して Google Cloud コンソールにログインする方法
-
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。
右側の [ラボの設定とアクセス] パネルには、以下が表示されます。
- [Google Cloud コンソールを開く] ボタン
- このラボで使用する一時的な認証情報(ユーザー名とパスワード)
- このラボを行うために必要なその他の情報(ある場合)
ラボのタイマーはページの上部に表示され、残り時間が示されます。
-
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します)。
ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択] ダイアログが表示された場合は、[別のアカウントを使用] をクリックします。
-
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
{{{user_0.username | "Username"}}}
[ラボの設定とアクセス] パネルでもユーザー名を確認できます。
-
[次へ] をクリックします。
-
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
{{{user_0.password | "Password"}}}
[ラボの設定とアクセス] パネルでもパスワードを確認できます。
-
[次へ] をクリックします。
重要: ラボで指定された認証情報を使用する必要があります。ご自身の Google Cloud アカウントの認証情報は使用しないでください。
注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
-
その後のページはクリックして先に進みます。
- 利用規約に同意します。
- 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
- 無料トライアルには登録しないでください。
しばらくすると、このタブで Google Cloud コンソールが開きます。
注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。
このラボでは、次のツールを使用します。
- Ubuntu 24.04
- Geth
- Lighthouse
- Curl
- gcloud
タスク 1. 仮想マシンのインフラストラクチャを作成する
パブリック静的 IP アドレス、ファイアウォール ルール、サービス アカウント、スナップショット スケジュール、新しい IP アドレスを持つ仮想マシンを作成します。これは、Ethereum がデプロイされるインフラストラクチャです。
パブリック静的 IP アドレスを作成する
このセクションでは、仮想マシンに使用するパブリック IP アドレスを設定します。
- Cloud コンソールで、ナビゲーション メニュー(
) > [VPC ネットワーク] > [IP アドレス] に移動します。
- [IP アドレス] カードの [外部を予約] をクリックして、静的 IP アドレスを作成します。
- 静的アドレスの構成には、以下を使用します。
| プロパティ |
値(入力または選択) |
| 名前 |
eth-mainnet-rpc-ip |
| Network Service Tier |
プレミアム |
| IP バージョン |
IPv4 |
| タイプ |
リージョン |
| リージョン |
|
| 接続先 |
なし |
- [予約] をクリックします。
ファイアウォール ルールの作成
VM が指定されたポートで通信できるようにファイアウォール ルールを作成します。
Geth P2P は、ポート 30303 で TCP と UDP を使用して通信します。Lighthouse P2P は、ポート 9000 で TCP と UDP を使用して通信します。Geth RPC は TCP 8545 を使用します。
- Cloud コンソールで、ナビゲーション メニュー(
) > [VPC ネットワーク] > [ファイアウォール] に移動します。
- アクションバーの [ファイアウォール ルールを作成] をクリックして、ファイアウォール ルールを作成します。
- ファイアウォールの構成には、以下を使用します。
| プロパティ |
値(入力または選択) |
| 名前 |
eth-rpc-node-fw |
| ログ |
オフ |
| ネットワーク |
デフォルト |
| 優先度 |
1000 |
| トラフィックの方向 |
Ingress |
| 一致したときのアクション |
許可 |
| ターゲット |
指定されたターゲットタグ |
| ターゲットタグ |
eth-rpc-node(値を入力したら Enter キーを押す) |
| ソースフィルタ |
IPv4 範囲 |
| 送信元 IPv4 範囲 |
0.0.0.0/0(値を入力したら Enter キーを押します) |
| 指定したプロトコルとポート: |
TCP: 30303、9000、8545 UDP: 30303、9000 |
- [作成] をクリックします。
サービス アカウントを作成する
VM が動作するサービス アカウントを作成します。
- Cloud コンソールで、ナビゲーション メニュー(
)> [IAM と管理] > [サービス アカウント] に移動します。
- アクションバーの [サービス アカウントを作成] をクリックして、サービス アカウントを作成します。
- サービス アカウントの構成には、以下を使用します。
| プロパティ |
値(入力または選択) |
| サービス アカウント名 |
eth-rpc-node-sa |
| サービス アカウント ID |
eth-rpc-node-sa |
- [作成して続行] をクリックします。
- 次のロールを追加します。
| プロパティ |
値(入力または選択) |
| ロール |
Compute OS Login、サービス コントローラ、ログ書き込み、モニタリング指標の書き込み、Cloud Trace エージェント、Compute ネットワーク ユーザー
|
- [続行] をクリックします。
- [完了] をクリックします。
スナップショット スケジュールの作成
このセクションでは、ブロックチェーン データを含む、仮想マシンにアタッチされたディスクに使用するスナップショット スケジュールを設定します。これにより、チェーンデータがバックアップされます。
- Cloud コンソールで、ナビゲーション メニュー(
) > [Compute Engine] > [スナップショット] に移動します。
- [スナップショット スケジュールを作成] をクリックして、スナップショット スケジュールを作成します。
- スナップショット スケジュールには、以下を使用します。
| プロパティ |
値(入力または選択) |
| 名前 |
eth-mainnet-rpc-node-disk-snapshot |
| リージョン |
|
| リージョン |
|
| スケジュール オプション |
スケジュール頻度: 毎日、開始時間(UTC): 午後 6:00~午後 7:00、スナップショットの自動削除: 7 日後 |
| 削除ルール |
スナップショットを保持する |
- [作成] をクリックします。
仮想マシンを作成する
このセクションでは、Ethereum のデプロイに使用する仮想マシンを設定します。
-
Cloud コンソールで、ナビゲーション メニュー(
) > [Compute Engine] > [VM インスタンス] に移動します。
-
[インスタンスを作成] をクリックして VM を作成します。
-
[マシンの構成] を参照します。
次のフィールドに値を入力します。
| プロパティ |
値(入力または選択) |
| 名前 |
eth-mainnet-rpc-node |
| リージョン |
|
| ゾーン |
|
| シリーズ |
E2 |
| マシンタイプ |
e2-standard-4 |
-
[OS とストレージ] をクリックします。
[変更] をクリックし、次の値を選択します。
| プロパティ |
値(入力または選択) |
| OS |
Ubuntu |
| バージョン |
Ubuntu 24.04 LTS(x86/64) |
| ブートディスクの種類 |
SSD 永続ディスク |
| サイズ |
50 GB |
[選択] をクリックします。
[追加ディスク] で [新しいディスクを追加] をクリックします。
| プロパティ |
値(入力または選択) |
| 名前 |
eth-mainnet-rpc-node-disk |
| ディスクソースのタイプ |
空のディスク |
| ディスクタイプ |
SSD 永続ディスク |
| サイズ |
200 GB(大規模なインストールでは 2,000 GB) |
[保存] をクリックします。
-
[データ保護] をクリックします。
[スナップショット スケジュール] で [eth-mainnet-rpc-node-disk-snapshot] を選択します。
-
[ネットワーキング] をクリックします。
| プロパティ |
値(入力または選択) |
| ネットワーク タグ |
eth-rpc-node(値を入力したら Enter キーを押します。ファイアウォール設定と一致します) |
-
[ネットワーク インターフェース] で [デフォルト] をクリックします。
-
[ネットワーク インターフェース カード] で [gVNIC] を選択します。
-
外部 IPv4 アドレス: eth-mainnet-rpc-ip(先ほど作成した静的 IP アドレスを選択)
[完了] をクリックします。
-
[セキュリティ] をクリックします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
仮想マシンのインフラストラクチャを作成する
タスク 2. 仮想マシンでの設定とインストール
次に、VM に SSH 接続し、コマンドを実行してソフトウェアをインストールします。
VM への SSH 通信
- Cloud コンソールで、ナビゲーション メニュー(
) > [Compute Engine] > [VM インスタンス] に移動します。
-
eth-mainnet-rpc-node と同じ行で、[SSH] をクリックして SSH ウィンドウを開きます。
- [ブラウザでの SSH による VM への接続を許可します。] というプロンプトが表示されたら、[承認] をクリックします。
VM にスワップ ファイルを作成する
プロセスに RAM を追加するには、スワップ ファイルを作成します。これは、必要に応じて VM が使用できる RAM の量を増やすためです。
- 40 GB のスワップ ファイルを作成するには、次のコマンドを実行します。
sudo dd if=/dev/zero of=/swapfile bs=1MiB count=40KiB
最初のコマンドの実行には少し時間がかかります。
- スワップ ファイルの権限を更新します。
sudo chmod 0600 /swapfile
- スワップ パーティションとして使用するファイルを指定します。
sudo mkswap /swapfile
- スワップ ファイルの構成を /etc/fstab に追加します。これにより、再起動時にマウントされたドライブが認識されるようになります。
echo "/swapfile swap swap defaults 0 0" | sudo tee -a /etc/fstab
- スワップ ファイルを有効にします。
sudo swapon -a
- スワップが認識されたことを確認します。
free -g
次のような行を含むメッセージが表示されます。
出力:
total used free shared buff/cache available
Mem: 15 0 0 0 15 15
Swap: 24 0 24
アタッチされたディスクを VM にマウントする
VM の設定時に、アタッチされたディスクを作成しました。VM はこれを自動的に認識しません。使用する前にフォーマットして「マウント」する必要があります。
- アタッチされたディスクを表示します。sdb のエントリがサイズ 200 GB で表示されます。
sudo lsblk
- アタッチされたディスクをフォーマットします。
sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/sdb
- フォルダを作成し、アタッチされたディスクをマウントします。
sudo mkdir -p /mnt/disks/chaindata-disk
sudo mount -o discard,defaults /dev/sdb /mnt/disks/chaindata-disk
- プロセスがフォルダを読み取り / 書き込みできるように、フォルダの権限を更新します。
sudo chmod a+w /mnt/disks/chaindata-disk
- マウントされたドライブのディスク ID を取得して、ドライブがマウントされたことを確認します。
sudo blkid /dev/sdb
以下の出力ボックスに表示されているようなメッセージが表示されます。
出力:
/dev/sdb: UUID="7fa9c421-0054-4555-b0ca-b470a97a3d84" TYPE="ext4"
- マウントされたディスクのディスク ID を取得し、/etc/fstab ファイルに追加します。このファイルにより、VM が再起動してもドライブがマウントされたままになります。
export DISK_UUID=$(findmnt -n -o UUID /dev/sdb)
echo "UUID=$DISK_UUID /mnt/disks/chaindata-disk ext4 discard,defaults,nofail 0 2" | sudo tee -a /etc/fstab
- df コマンドを実行して、ディスクがマウントおよびフォーマットされ、正しいサイズが割り当てられていることを確認します。
df -h
新しくマウントされたボリュームとそのサイズを示す次のような行を含むメッセージが表示されます。
出力:
/dev/sdb 196G 28K 196G 1% /mnt/disks/chaindata-disk
後でディスクのサイズを変更する必要がある場合は、こちらの手順に沿って操作してください。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
VM にスワップ ファイルを作成し、アタッチされたディスクを VM にマウントする
VM にユーザーを作成する
プロセスを実行するユーザーを作成します。
- ethereum という名前のユーザーを作成するには、次のコマンドを実行します。
sudo useradd -m ethereum
sudo usermod -aG sudo ethereum
sudo usermod -aG google-sudoers ethereum
- ethereum ユーザーに切り替えます。
sudo su ethereum
- bash コマンドラインを起動します。
bash
- ethereum ユーザーのホームフォルダに移動します。
cd ~
Ethereum ソフトウェアをインストールする
- オペレーティング システムを更新します。
sudo apt update -y
sudo apt-get update -y
- 一般的なソフトウェアをインストールします。
sudo apt install -y dstat jq software-properties-common
- Google Cloud Ops エージェントをインストールします。
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
- ダウンロードしたスクリプト ファイルを削除します。
rm add-google-cloud-ops-agent-repo.sh
- Geth クライアントと Lighthouse クライアントのログとチェーンデータ用のフォルダを作成します。
mkdir /mnt/disks/chaindata-disk/ethereum/
mkdir /mnt/disks/chaindata-disk/ethereum/geth
mkdir /mnt/disks/chaindata-disk/ethereum/geth/chaindata
mkdir /mnt/disks/chaindata-disk/ethereum/geth/logs
mkdir /mnt/disks/chaindata-disk/ethereum/lighthouse
mkdir /mnt/disks/chaindata-disk/ethereum/lighthouse/chaindata
mkdir /mnt/disks/chaindata-disk/ethereum/lighthouse/logs
- パッケージ マネージャーから Geth をインストールします。
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get -y install ethereum
- Geth が利用可能で、最新バージョンであることを確認します。
geth version
次のような行を含むメッセージが表示されます。
出力:
Geth
Version: 1.14.11-stable
Git Commit: ea9e62ca3db5c33aa7438ebf39c189afd53c6bf8
Architecture: amd64
Go Version: go1.23.1
Operating System: linux
GOPATH=
GOROOT=
- Lighthouse クライアントをダウンロードします。このスクリプトは、GitHub から最新リリースをダウンロードします。
# Fetch the latest release information from GitHub API
RELEASE_URL="https://api.github.com/repos/sigp/lighthouse/releases/latest"
LATEST_VERSION=$(curl -s $RELEASE_URL | jq -r '.tag_name')
# Download the latest release using curl
DOWNLOAD_URL=$(curl -s $RELEASE_URL | jq -r '.assets[] | select(.name | endswith("x86_64-unknown-linux-gnu.tar.gz")) | .browser_download_url')
curl -L "$DOWNLOAD_URL" -o "lighthouse-${LATEST_VERSION}-x86_64-unknown-linux-gnu.tar.gz"
- Lighthouse の tar ファイルを抽出して削除します。
# Extract the tar file
tar -xvf "lighthouse-${LATEST_VERSION}-x86_64-unknown-linux-gnu.tar.gz"
# Remove the tar file
rm "lighthouse-${LATEST_VERSION}-x86_64-unknown-linux-gnu.tar.gz"
- Lighthouse バイナリを /usr/bin フォルダに移動し、権限を更新します。
sudo mv lighthouse /usr/bin
- Lighthouse が利用可能で、最新バージョンであることを確認します。
lighthouse --version
次のような行を含むメッセージが表示されます。バージョン番号は異なる場合があります。
出力:
Lighthouse v5.3.0-d6ba8c3
BLS library: blst-portable
BLS hardware acceleration: true
SHA256 hardware acceleration: false
Allocator: jemalloc
Profile: maxperf
Specs: mainnet (true), minimal (false), gnosis (true)
- 共有 JWT シークレットを作成します。この JWT シークレットは、実行クライアントの RPC エンドポイントを呼び出すことができるユーザーを制限するセキュリティ メカニズムとして使用されます。
cd ~
mkdir ~/.secret
openssl rand -hex 32 > ~/.secret/jwtsecret
chmod 440 ~/.secret/jwtsecret
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
VM にユーザーを作成して Ethereum ソフトウェアをインストールする
タスク 3. Ethereum 実行クライアントとコンセンサス クライアントを起動する
Ethereum には、実行レイヤの Geth とコンセンサス レイヤの Lighthouse の 2 つのクライアントがあります。これらは並行して実行され、連携して機能します。その後、Geth は Lighthouse が呼び出す authrpc エンドポイントとポートを確立します。このエンドポイントは、ローカルに保存された共通のセキュリティ トークンによって保護されています。Lighthouse は、実行エンドポイントとセキュリティ トークンを使用して Geth に接続します。
Geth がコンセンサス クライアントに接続する方法については、コンセンサス クライアントへの接続に関するドキュメントをご覧ください。Lighthouse が実行クライアントに接続する方法の詳細については、Merge Migration - Lighthouse Book のドキュメントをご覧ください。
Geth を起動する
以下を実行して Geth 実行クライアントを起動します。
- まず、gcloud での認証を行います。SSH セッション内で、次を実行します。
gcloud auth login
[Do you want to continue (Y/n)?] プロンプトが表示されたら、Enter キーを押します。
-
新しいタブに表示されているリンクに移動します。
-
アクティブなユーザー名()をクリックし、[Allow] をクリックします。
-
[Enter the following verification code in gcloud CLI on the machine you want to log into] プロンプトが表示されたら、コピーボタンをクリックして SSH セッションに戻り、コピーしたコードを [Enter authorization code:] プロンプトに貼り付けます。
-
外部 IP アドレスの環境変数を設定します。
export CHAIN=eth
export NETWORK=mainnet
export EXT_IP_ADDRESS_NAME=$CHAIN-$NETWORK-rpc-ip
export EXT_IP_ADDRESS=$(gcloud compute addresses list --filter=$EXT_IP_ADDRESS_NAME --format="value(address_range())")
- 次のコマンドを実行して、Geth をバックグラウンド プロセスとして起動します。このラボでは、ライトノードである「snap」同期モードを使用します。フルノードとして同期するには、同期モードとして「full」を使用します。このコマンドは、コマンドラインで実行することも、.sh ファイルに保存してから実行することもできます。systemd を使用してサービスとして実行するように構成することもできます。
nohup geth --datadir "/mnt/disks/chaindata-disk/ethereum/geth/chaindata" \
--http.corsdomain "*" \
--http \
--http.addr 0.0.0.0 \
--http.port 8545 \
--http.corsdomain "*" \
--http.api admin,debug,web3,eth,txpool,net \
--http.vhosts "*" \
--gcmode full \
--cache 2048 \
--mainnet \
--metrics \
--metrics.addr 127.0.0.1 \
--syncmode snap \
--authrpc.vhosts="localhost" \
--authrpc.port 8551 \
--authrpc.jwtsecret=/home/ethereum/.secret/jwtsecret \
--txpool.accountslots 32 \
--txpool.globalslots 8192 \
--txpool.accountqueue 128 \
--txpool.globalqueue 2048 \
--nat extip:$EXT_IP_ADDRESS \
&> "/mnt/disks/chaindata-disk/ethereum/geth/logs/geth.log" &
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
Geth をバックグラウンド プロセスとして起動し、スナップ同期モードを使用する
- プロセス ID を確認するには、次のコマンドを実行します。
ps -A | grep geth
- ログをチェックして、プロセスが正しく開始されたかどうかを確認します。
tail -f /mnt/disks/chaindata-disk/ethereum/geth/logs/geth.log
以下の出力ボックスに表示されているようなメッセージが表示されます。Geth クライアントは、コンセンサス クライアントとペアリングするまで続行されません。
出力:
Looking for peers peercount=1 tried=27 static=0
Post-merge network, but no beacon client seen. Please launch one to follow the chain!
-
Ctrl+C キーを押して、ログのモニタリングを終了します。
Lighthouse を起動する
次に、Lighthouse コンセンサス クライアントを起動します。
- 次のコマンドを実行して、Lighthouse をバックグラウンド プロセスとして起動します。このコマンドは、コマンドラインで実行することも、.sh ファイルに保存してから実行することもできます。systemd を使用してサービスとして実行するように構成することもできます。
nohup lighthouse bn \
--network mainnet \
--http \
--metrics \
--datadir /mnt/disks/chaindata-disk/ethereum/lighthouse/chaindata \
--execution-jwt /home/ethereum/.secret/jwtsecret \
--execution-endpoint http://localhost:8551 \
--checkpoint-sync-url https://sync-mainnet.beaconcha.in \
&> "/mnt/disks/chaindata-disk/ethereum/lighthouse/logs/lighthouse.log" &
- プロセス ID を確認するには、次のコマンドを実行します。
ps -A | grep lighthouse
- ログファイルをチェックして、プロセスが正常に開始されたかどうかを確認します。表示されるまでに数分かかることがあります。
tail -f /mnt/disks/chaindata-disk/ethereum/lighthouse/logs/lighthouse.log
次のようなメッセージが表示されます。
出力:
INFO Syncing
INFO Synced
INFO New block received
-
Ctrl+C キーを押して、ログのモニタリングを終了します。
-
Geth ログを再度確認して、ログが正しく生成されていることを確認します。
tail -f /mnt/disks/chaindata-disk/ethereum/geth/logs/geth.log
以下の出力ボックスに表示されているようなメッセージが表示されます。
出力:
Syncing beacon headers
ノードがブロックチェーンと同期されていることを確認する
ノードがまだ同期中かどうかを確認します。ノードが同期されるまでしばらく時間がかかります(ラボを完了するために、ノードが同期するまで待つ必要はありません。出力には、false ではなく、同期ステータスの JSON が表示されるはずです)。同期ステータスを確認するには、Geth と RPC 呼び出しの 2 つの方法があります。
- 次の Geth コマンドを実行して、ノードがまだ同期中かどうかを確認します。出力が「false」の場合は、ネットワークと完全に同期されていることを意味しますが、このラボではまだ同期中である可能性が高いです。
geth attach /mnt/disks/chaindata-disk/ethereum/geth/chaindata/geth.ipc
- Geth コンソールで次のコマンドを実行します。
eth.syncing
次のように表示されます。
出力:
#If not synced:
{
currentBlock: 5186007,
healedBytecodeBytes: 0,
healedBytecodes: 0,
healedTrienodeBytes: 0,
healedTrienodes: 0,
healingBytecode: 0,
healingTrienodes: 0,
highestBlock: 16193909,
startingBlock: 0,
syncedAccountBytes: 2338698797,
syncedAccounts: 9417189,
syncedBytecodeBytes: 302598044,
syncedBytecodes: 58012,
syncedStorage: 42832820,
syncedStorageBytes: 9263550660
}
#If synced:
false
- 「exit」と入力して Geth コンソールを終了します。
- 次の curl コマンドを実行して、ノードがまだ同期中かどうかを確認します。コマンドライン ツール「jq」は、curl コマンドの JSON 出力をフォーマットします。「false」が出力された場合は、ネットワークと同期されていることを意味します
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","id":67}' http://localhost:8545 | jq
出力:
#If not synced:
{
"jsonrpc": "2.0",
"id": 67,
"result": {
"currentBlock": "0x4d70e9",
"healedBytecodeBytes": "0x0",
"healedBytecodes": "0x0",
"healedTrienodeBytes": "0x0",
"healedTrienodes": "0x0",
"healingBytecode": "0x0",
"healingTrienodes": "0x0",
"highestBlock": "0xf71975",
"startingBlock": "0x0",
"syncedAccountBytes": "0x8b65b62d",
"syncedAccounts": "0x8fb1e5",
"syncedBytecodeBytes": "0x1209479c",
"syncedBytecodes": "0xe29c",
"syncedStorage": "0x28d93b4",
"syncedStorageBytes": "0x2282690c4"
}
}
#If synced:
{"jsonrpc":"2.0","id":67,"result":false}
- 次の curl コマンドを実行して、外部 IP アドレスを介してノードにアクセスできるかどうかを確認します。
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","id":67}' http://$EXT_IP_ADDRESS:8545 | jq
出力:
#If not synced:
{
"jsonrpc": "2.0",
"id": 67,
"result": {
"currentBlock": "0x4d70e9",
"healedBytecodeBytes": "0x0",
"healedBytecodes": "0x0",
"healedTrienodeBytes": "0x0",
"healedTrienodes": "0x0",
"healingBytecode": "0x0",
"healingTrienodes": "0x0",
"highestBlock": "0xf71975",
"startingBlock": "0x0",
"syncedAccountBytes": "0x8b65b62d",
"syncedAccounts": "0x8fb1e5",
"syncedBytecodeBytes": "0x1209479c",
"syncedBytecodes": "0xe29c",
"syncedStorage": "0x28d93b4",
"syncedStorageBytes": "0x2282690c4"
}
}
#If synced:
{"jsonrpc":"2.0","id":67,"result":false}
タスク 4. Cloud Operations を構成する
Google Cloud には、Ethereum ノードを管理するための運用サービスがいくつかあります。このセクションでは、Cloud Logging、マネージド Prometheus、Cloud Monitoring、Cloud アラートの構成について説明します。
Cloud Logging を構成する
デフォルトでは、Geth と Lighthouse は宣言されたログファイルにロギングします。ログデータを Cloud Logging に取り込む必要があります。Cloud Logging には強力な検索機能があり、特定のログメッセージに対してアラートを作成できます。
- Cloud Ops 構成ファイルの権限を更新して、ファイルを更新できるようにします。
sudo chmod 666 /etc/google-cloud-ops-agent/config.yaml
- ログデータを Cloud Logging に送信するように Cloud Ops エージェントを構成します。この Ops エージェント構成を含めて、ファイル「/etc/google-cloud-ops-agent/config.yaml」を更新します。この構成ファイルでは、Cloud Logging にインポートする Geth と Lighthouse のログファイルを定義します。
sudo cat << EOF >> /etc/google-cloud-ops-agent/config.yaml
logging:
receivers:
syslog:
type: files
include_paths:
- /var/log/messages
- /var/log/syslog
ethGethLog:
type: files
include_paths: ["/mnt/disks/chaindata-disk/ethereum/geth/logs/geth.log"]
record_log_file_path: true
ethLighthouseLog:
type: files
include_paths: ["/mnt/disks/chaindata-disk/ethereum/lighthouse/logs/lighthouse.log"]
record_log_file_path: true
journalLog:
type: systemd_journald
service:
pipelines:
logging_pipeline:
receivers:
- syslog
- journalLog
- ethGethLog
- ethLighthouseLog
EOF
- 保存後、次のコマンドを実行してエージェントを再起動し、変更を反映します。
sudo systemctl stop google-cloud-ops-agent
sudo systemctl start google-cloud-ops-agent
sudo systemctl status google-cloud-ops-agent
-
Ctrl+C キーを押してステータス画面を終了します。
- ステータスにエラーがある場合は、次のコマンドを使用して詳細を確認します。
sudo journalctl -xe | grep "google_cloud_ops_agent_engine"
- Cloud Logging をチェックして、ログメッセージがコンソールに表示されていることを確認します。Cloud コンソールで、ナビゲーション メニュー(
)に移動し、[すべてのプロダクトを表示] をクリックします。次に、[オブザーバビリティ] で [ロギング] をクリックします。左側のメニューで [ログ エクスプローラ] をクリックします。次のようなメッセージが表示されます。
マネージド Prometheus を構成する
geth クライアントと lighthouse クライアントを --metrics フラグを付けて起動したため、両方のクライアントが http ポートに指標を出力します。これらの指標は、Prometheus などの時系列データベースに保存し、豊富な分析情報を提供する grafana ダッシュボードにデータを提供するために使用できます。通常は VM に Prometheus をインストールする必要がありますが、Cloud Ops エージェントの簡単な構成で指標をキャプチャし、Google Cloud のマネージド Prometheus サービスに保存できます。
- VM のコマンドラインで、Geth 指標エンドポイントがアクティブであることを確認します。
curl http://localhost:6060/debug/metrics/prometheus
出力:
......
# TYPE vflux_server_clientEvent_deactivated gauge
vflux_server_clientEvent_deactivated 0
# TYPE vflux_server_clientEvent_disconnected gauge
vflux_server_clientEvent_disconnected 0
# TYPE vflux_server_inactive_count gauge
vflux_server_inactive_count 0
- VM のコマンドラインで、Lighthouse 指標エンドポイントがアクティブであることを確認します。
curl http://localhost:5054/metrics
出力:
......
gossipsub_heartbeat_duration_bucket{le="300.0"} 5679573
gossipsub_heartbeat_duration_bucket{le="350.0"} 5679573
gossipsub_heartbeat_duration_bucket{le="400.0"} 5679573
gossipsub_heartbeat_duration_bucket{le="450.0"} 5679573
gossipsub_heartbeat_duration_bucket{le="+Inf"} 5679573
......
- Cloud Ops エージェントを構成して、指標データをマネージド Prometheus に送信します。この Ops エージェント構成を含めて、ファイル「/etc/google-cloud-ops-agent/config.yaml」を更新します。この構成ファイルは、マネージド Prometheus にインポートする Geth と Lighthouse の指標エンドポイントを定義します。
sudo cat << EOF >> /etc/google-cloud-ops-agent/config.yaml
metrics:
receivers:
prometheus:
type: prometheus
config:
scrape_configs:
- job_name: 'geth_exporter'
scrape_interval: 10s
metrics_path: /debug/metrics/prometheus
static_configs:
- targets: ['localhost:6060']
- job_name: 'lighthouse_exporter'
scrape_interval: 10s
metrics_path: /metrics
static_configs:
- targets: ['localhost:5054']
service:
pipelines:
prometheus_pipeline:
receivers:
- prometheus
EOF
- 保存後、次のコマンドを実行してエージェントを再起動し、変更を反映します。
sudo systemctl stop google-cloud-ops-agent
sudo systemctl start google-cloud-ops-agent
sudo systemctl status google-cloud-ops-agent
-
Ctrl+C キーを押してステータス画面を終了します。
- ステータスにエラーがある場合は、次のコマンドを使用して詳細を確認します。
sudo journalctl -xe | grep "google_cloud_ops_agent_engine"
-
Cloud Logging をチェックして、指標がコンソールに表示されていることを確認します。Cloud コンソールで、ナビゲーション メニュー(
)に移動し、[すべてのプロダクトを表示] をクリックします。次に、[オブザーバビリティ] で [モニタリング] をクリックします。左側のメニューで [Metrics Explorer] をクリックします。
-
[<> PromQL] オプションを選択します。クエリボックスに、Lighthouse 指標 gossipsub_heartbeat_duration_bucket を入力します。[クエリを実行] をクリックします。次のような結果が表示されます。
Geth 指標(例: rpc_duration_eth_blockNumber_success_count)についても同様に、Geth 指標が表示されていることを確認できます。
Cloud Monitoring を表示する
仮想マシンで Cloud Monitoring がすでに有効になっている必要があります。
- Cloud コンソールで、ナビゲーション メニュー(
) > [Compute Engine] > [VM インスタンス] に移動します。
- VM eth-mainnet-rpc-node をクリックします。
- [オブザーバビリティ] タブをクリックします。
- すべてのセクションに、VM のさまざまな指標のグラフが表示されます。
- さまざまなサブメニューや期間をクリックして、VM から直接キャプチャされるさまざまな種類の指標を確認します。
通知チャンネルを構成する
アラートの送信先となる通知チャンネルを構成します。
- Cloud コンソールで、ナビゲーション メニュー(
)に移動し、[すべてのプロダクトを表示] をクリックします。次に、[オブザーバビリティ] で [モニタリング] をクリックします。左側のメニューで、[アラート] をクリックします。
- [通知チャネルの編集] をクリックします。
- [メール] で [新規追加] をクリックします。
- 通知を受け取るユーザーのメールアドレスと表示名を入力します。
- [保存] をクリックします。
指標アラートを構成する
VM 指標に基づいてアラートを構成します。
- 左側のメニューの [検出] セクションで、[アラート] をクリックします。
- [ポリシーの作成] をクリックします。
- [指標を選択] をクリックします。
- [VM インスタンス] > [ディスク] > [ディスク使用率] をクリックし、[適用] をクリックします。
- 次のフィルタを追加します。
| プロパティ |
値(入力または選択) |
| デバイス |
/dev/sdb |
| 状態 |
使用済み |
- [次へ] をクリックします。
- しきい値として「90%」を入力します。
- [次へ] をクリックし、次の値を選択します。
| プロパティ |
値 (入力または選択) |
| 通知チャンネルを使用 |
選択 |
| 通知チャンネル |
以前に作成した通知チャンネルを選択 |
| インシデントのクローズ時に通知 |
確認 |
| インシデントの自動クローズ期間 |
2 日 |
| ドキュメント |
VM のディスク容量を確認する |
| 名前 |
VM - ディスク容量アラート - 使用率 90% |
- [次へ] をクリックします。
- [ポリシーの作成] をクリックします。
稼働時間チェックを構成する
HTTP エンドポイントの稼働時間チェックを構成します。
- 左側のメニューの [検出] セクションで、[稼働時間チェック] をクリックします。
- [稼働時間チェックを作成] をクリックします。
- 次の値を使用して稼働時間チェックを構成します。
| プロパティ |
値 (入力または選択) |
| プロトコル |
HTTP |
| リソースの種類 |
URL |
| ホスト名 |
[インスタンスの外部 IP] |
| パス |
/ |
| [その他のターゲット オプション] を展開 |
|
| リクエスト メソッド |
GET |
| ポート |
8545 |
| [続行] をクリックします |
デフォルトを受け入れる |
| [続行] をクリックします |
デフォルトを受け入れる |
| 通知チャンネルを選択 |
以前に作成した通知チャンネルを選択 |
| タイトル |
eth-mainnet-rpc-node-uptime-check |
- [テスト] をクリックします(成功を示す 200 OK が表示されます)。
- [作成] をクリックします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
Cloud Operations を構成する
お疲れさまでした
このラボでは、永続ディスクを備えた Compute Engine インスタンスの作成、静的 IP アドレスの構成、ネットワークファイアウォール ルールの構成、バックアップのスケジュール、Geth と Lighthouse の Ethereum クライアントのデプロイ、Ethereum RPC 呼び出しでの設定のテスト、Cloud Logging と Cloud Monitoring の構成、稼働時間チェックの構成を行いました。
次のステップと詳細情報
Ethereum の学習を続けるには、以下のリソースをご覧ください。
Google Cloud トレーニングと認定資格
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2026 年 7 月 27 日
ラボの最終テスト日: 2026 年 7 月 27 日
Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。