概要

2023年5月23日に『Google Cloud』が主催した企業のDXの実現と新たなビジネス価値の創造についてのカンファレンスで、国内No.1のブロックチェーンノード運用実績を有する弊社技術開発チームのマネージャー・鷲見が、どのようにインフラの信頼性を高めてきたか、その具体的な手法についてお話しましたので本レポートではその内容をお届けします。ビジネスを加速するヒントが見つかれば幸いです。

スピーカーと弊社のご紹介

株式会社Gincoの鷲見です。エンジニアとしてキャリアを積んできて、 現在プラットホーム部という社内共通基盤やプロダクトの信頼性を担当する部署のマネージャーをしています。

今年3月に弊社のブロックチェーンノード基盤をGoogle Cloudへ移行しましたので、それを踏まえて本日のアジェンダ『ブロックチェーンノード基盤の紹介と今回行った刷新プロジェクト』についてお話したいと思います。

まずはじめに弊社Gincoについてのご紹介です。弊社はブロックチェーンのスタートアップ企業としてWeb3領域の総合デベロッパーとして国内トップの実績を多数有しています。

主にB2Bで事業の基盤となるウォレットやブロックチェーンノードを提供することで、デジタルアセットを活用したWeb3のユースケース創出を裏側から支えております。

Gincoのプロダクトは、大きくは『Web3 SaaS』と『Web3 Cloud』の２つがあります。本日紹介するブロックチェーンノード基盤は『Web3 Cloud』のサービスの１つになります。

『Web3 Cloud』とは、Web3サービスを開発する上で負担の大きいノードやウォレットをSDKやAPIとして提供するクラウドサービスです。

弊社が提供する『Web3 SaaS』のインフラとしても利用している弊社基盤の根幹となるものです。

『Web3 Cloud』が提供するウォレットやノード、エクスプローラーといった機能は、実装に要求される専門性が高いだけでなく、様々な資産を扱うことから高い信頼性を求められます。そのため、Web3ビジネスの非競争領域、かつ対応コストが高いこの部分をオールインワンで解決することが『Web3 Cloud』の価値となっています。

本日はこの『Web3 Cloud』のプロダクトの１つである「ブロックチェーンノード基盤」についてお話しします。

１．ブロックチェーンノード基盤の紹介

まず、ブロックチェーンとブロックチェーンノードについてお話しします。

ブロックチェーンとは、対改ざん性・対障害性が高い分散型台帳システムです。世界中のサーバーでOSSを稼働させP2Pでネットワークを構成します。金融、DID（分散型ID）、トレーサビリティなどの用途で利用されます。

ブロックチェーンノードは、ネットワークを構成するサーバーの１つです。ブロックチェーンにアクセスするためのAPIを提供します。そのためブロックチェンを用いたアプリケーションの開発に必要となります。

ブロックチェンノードの仕組みについて、ノードはP2Pのアプリケーションとデータベースの２つからなります。

機能としては、取引情報の取得、検証、保持、配信があります。また、マイナーやバリデータと呼ばれる一部のノードはブロック生成を行いネットワークの運営を行います。

このようにブロックチェーンを構成するノードですが、この運用は簡単ではありません。安定稼働のためには近年のWebシステムとは違った難しさに取り組む必要があります。

まず、１つ目はネットワークの同期です。ブロックチェーンは資産など重要なデータを扱うことが多く、取引情報は即時表示することが望ましいです。そのため、同期チェーンを最小限にする必要があります。

一方でブロックチェーンではどのノードが最新の情報を持っているかわからないため、新しいデータを持つノードを見つけ出し取得する必要があります。

２つ目は、再起動時のダウンタイムです。ブロックチェーンノードの再起動時には、ネットワークに対して安定した接続を確立し、新しいブロックの取得や検証が行われます。これらの処理により再起動が起きただけでも、通常数分から数時間のダウンタイムが発生します。

以上の課題を踏まえて、Gincoでどのようにブロックチェーンノードを運用しているかをお話しします。


まず、前提としてブロックチェーンノードは、それ自体が巨大なプロジェクトです。またGincoは多くのブロックチェーンを扱う必要がありますので、そこでGincoではノードの回収なしに安定したAPIを提供できるように構成しました。具体的には、ノードを冗長化し、ネットワークへ同期しているノードにのみルーティングする仕組みを構築しています。基盤の全体像はこのようになっています。

基盤には、Kubernetesを用いてノードを冗長化して稼働させています。ノードの前段には独自のロードバランサーがあり、正常なノードへのみリクエストをルーティングしています。またロードバランサーでは認証機能を提供しており、そのためにデータベースを利用しています。

ブロックチェーンノード基盤への要件は主に「ネットワークに同期したノードへのみアクセスしたい」「レスポンスには一貫性がほしい」の２つです。

これはKubernetesやクラウドのロードバランサーでは要件を満たせません。ノードはそれぞれネットワークと同期処理を行っており、最新ブロックを取得しているものもあれば、数百ブロック遅れているものもあります。

この状況下で要件を満たすためGincoでは独自のロードバランサーを開発しています。

独自のロードバランサーでは稼働状況をチェックし、正常なノードへのみルーティング。そしてユーザーごとにルーティングするノードを固定、という処理を行っています。これにより同期しているノードにのみルーティングがされ、リクエストの一貫性も保たれます。

動作イメージとしては、上の図のようにまずロードバランサーが各ノードの同期状況をチェックします。この図の場合であれば、上２つのノードが同期していることを検出します。加えて認証情報からユーザーを特定します。その後、同期しているノードのうち、ユーザーを決まったノードにルーティングします。

以上が、弊社のノード基盤と独自ロードバランサーの紹介になります。

なお、Gincoではこのノード基盤で下記図の通り、主要なほとんどのブロックチェーンに対応しており、稼働しているブロックチェーンノード数、サーバー規模、稼働率と高水準で提供しています。

そして今年の３月に、より良いサービスを提供するためにノード基盤の刷新を行いました。ここからは、ノード基盤の刷新プロジェクトについてお話しします。

２．ブロックチェーンノード基盤の刷新

プロジェクトで行ったことの概観を説明します。プロジェクト以前２つの課題がありました。

１つ目は、複数クラウドの利用による非効率さ。２つ目は定期的に発生する基盤のアップグレードコストが高い、というものです。これらにより、規模拡大につれ開発とコストの効率が低下している状態でした。

今回の刷新プロジェクトにより、クラウドの統一。そしてツール変更と環境追加によるアップグレード工数とアップグレード頻度の削減を行いました。これによりさらに高速に安定したシステムを提供可能になりました。 

ここからはプロジェクトで行ったことを順に説明します。

▶クラウド統一による効率化

まず複数クラウドの利用によって２種類の非効率さがありました。

１つ目が開発効率です。Gincoでは上図のようにプロダクトや社内ツールの多くを「Google Cloud」で構築しています。一方で、ノード基盤には、料金面から別のクラウドを選定していました。

開発者の多くが「Google Cloud」に慣れており、異なるクラウドの作業開始時にオーバーヘッドが発生している状態でした。

もう１つが通信コストです。Gincoのプロダクトはブロックチェーンに流れる全てのトランザクションをチェックし、ユーザーのものであればデータを取り込むなどの処理をする必要があります。対応ブロックチェーンやユーザーなど規模拡大につれて通信コストが増加していました。

どのクラウドでもインターネットへ出る方向の通信料に対して高めの料金が発生するという料金体系になっていますので、クラウドをまたいだ通信コストが課題でした。

以上から開発通信費ともに複数クラウドの併用が要因となり非効率さが生まれていました。この課題を解消するため「Google Cloud」へ統一しました。

「Google Cloud」を利用したのは開発しやすさと信頼性のためです。Gincoは５年以上「Google Cloud」を利用していますが、開発時に扱う概念やUIが分かりやすく設計の際にシンプルにアーキテクチャを考えられます。

また、今まで使ってきて完全に停止するなどの大きな障害には当たっておらず信頼性も高いと感じています。

「Google Cloud」への移行方法としては、基盤のKubernetesクラスターを「Google Cloud」へ移行し、プロダクトが参照するグローバルIPを変更するだけです。

グローバルIPを参照していても「Google Cloud」のVM同士なら内部ネットワークでルーティングされます。これにより、通信コストを約９０パーセント削減することができました。また、加えて低レイテンシな通信を実現することができました。

▶アップグレードコストの低減

次に、アップクレードコストの低減についてお話しします。

刷新プロジェクト以前、ノード基盤ではKubernetesに加えIstioを利用していましたが、我々にとって課題だったのはサポート期間の違いでした。

 Kubernetesは約１年なのに対しIstioは半年、と倍の頻度でのアップグレードが必要でした。

KubernetesとIstioのアップグレードで必要な作業としては、次の図にある４つです。

検証環境の構築の必要がある上、先ほどの通りブロックチェーンノードは再起動時のダウンタイムが長いという特徴があります。 

以上から検証・リリース合わせて半年に約１人月必要な状態でした。また、お客様にメンテナンス枠をいただく必要もあり体験もいいものではありません。

そこで、まず環境ごとにクラスタを分割しました。

刷新前は１クラスタで、メインネット、テストネット、両方のノードを運用していました。メインネットというのは資産価値がついている暗号資産が流通するネットワークのこと。テストネットは資産価値がついていないテスト用のネットワークのことです。

１クラスタで開発していることにより初期開発は早く進められました。一方、検証用のクラスタがないため、クラスタやIstioのアップグレードの検証に時間がかかりました。そこで今回の刷新プロジェクトにより環境ごとにクラスタを分割しました。

本番環境と同一環境を作っておくことにより、環境構築と検証の期間を短縮することができました。以上により、アップグレードあたりの工数が約０．５人月、５０％削減することができました。

次にIstioについてです。

元々Istioは実装なしにObservabilityを得ることを目的として導入しました。その目的は達成できていたのですが、課題として開発が活発でサポート期間が短いこと。プロキシにより障害リスクが高いことがありました。

上図が必要なアーキテクチャですが、サーバーに対してアプリケーションが複数展開されているとします。Istioアプリケーションの前段緑枠の部分にプロキシを挟み込み、Control Planeがプロキシを制御することでObservabilityの取得やネットワーキングの処理を行っています。
 
そのため、Istioのアップグレードの際にはアプリケーションの再起動が必要で、ブロックチェーンノードの運用には好ましくありません。

これを解決するため、我々はPixieを採用しました。

これは、CNCFのeBPFのAPMツールです。上図がPixieのアーキテクチャーです。真ん中の青枠がKubernetesクラスタ、水色の枠がKubernetesノードになっています。

ノードの中にカーネルがあり、その機能の１つとしてeBPFがあります。eBPFの特徴はカーネルに動的かつ安全に処理を差し込めることです。Pixieはこれをパフォーマンスやネットワーキングのメトリクスの取得に利用しています。
 
ここで嬉しいのはIstioと異なり、プロキシなしでObservabilityを得られることです。そのため稼働しているアプリケーションに再起動が必要なく、ブロックチェーンノードを稼働させたままアップグレードが可能です。 

これにより、必要にかけていたメンテナンス工数が浮き、メンテナンス工数とメンテナンス枠を５０％削減できました。

▶併せて行った改善

今回の基盤刷新に合わせて行った改善については２つあります。まず１つが「Backup for GKE」によるバックアップです。

これは、フルマネージドでクラスタ構成とVolumeのバックアップが可能というものです。 同様の機能を提供するOSSもありますが、こちらはフルマネージドのため管理コストがかからず助かっています。

もう１つがモニタリングの強化です。

モニタリングには社内の共通の基盤を利用しています。基盤にはモニタリングツールとしてDatadogを、インシデント管理ツールとしてSquadcastを利用しています。

ダッシュボードは、Terraformで「Infrastructure as Code化」されており、新規ブロックチェーンに対応する際に自動的にモニタリングが構成されるようになっています。

また、ダッシュボードはこのようになっています。

ブロックチェーンごとにウィジェットを作り、よくあるCPU、メモリー、ディスクといった項目に加え、ブロック高やノードが繋がっているピアの数などをモニタリングしているのが特徴です。 

以上がGincoのブロックチェーンノード基盤と刷新プロジェクトの紹介になります。

３．今回のまとめ

Gincoは今年の3月に開発効率とコスト効率を高めるため、ブロックチェーンノード基盤を刷新し「Google Cloud」へ移行しました。刷新プロジェクトでは次を実施しました。

１つ目が、クラウド統一による開発と通信費のオーバーヘッドの解消。２つ目が、環境追加とIstio脱却によるアップグレードコストの低減です。これにより開発とコスト効率を改善し、より高速に安定したシステムを提供可能になりました。

４．今後の展望

今後の展望としては、今回刷新プロジェクトでクラスターの運用環境が改善されたので、ブロックチェーンノードの運用作業の自動化を現在進めています。
 
ブロックチェーンノードの運用作業としては、主にノードのアップグレードやノード内のデータベースに関する作業が発生しています。そのためアルゴワークフローやKubernetes Operatorなどを用いて自動化を進めています。

他にはより低レイテンシを実現するためのグローバルへのノードの展開、また今回一旦「Google Cloud」にワークフローを寄せましたが、さらにより高い可用性を実現するためマルチクラウドにもアプリケーションを展開していくことを考えています。
 
いずれも、お客様のニーズに合わせて実施していきます。発表内容は以上になります。

最後に宣伝をさせてください。銀行では、経済の巡りを変えていくため、エンジニアリングにより、世の中やプロダクトをより良くしたい方を募集しています。

こちらのポジションだけでなく、様々なポジションで積極採用中です。興味のある方は、こちらのQRコードからでも私のSNSからでも構いませんので、ぜひお声がけください。

以上で、私のセッションを終了します。ご清聴ありがとうございました。

質疑応答

❶「ブロックチェーンのノードの立ち上げを早くするための何か工夫をされていることはありますか？」

ブロックチェーンノードは、スライドでも説明しましたが、ローカルにデータを持っておく必要があります。初回のデータロードに時間がかかるのは仕方ないのですが、一旦同期したあと再度立ち上げるスピードを早くしたい。これが基本のところだと思いますが、定期的にスナップショットを取って、いつでも正しかった状態に復元しやすくできるように構成することだと思います。

❷「同一ブロックチェーンのノードの同期が遅れてしまうことが発生するのはどのような原因が多かったのですか？」

ブロックチェーンノードを開発し始めた５年前はそういったことがありましたが最近はあまりなく、あったとしてもネットワーク全体でパフォーマンスが落ちている場合が多いです。それでも発生してしまった場合に考えられる原因としては、ネットワークのパフォーマンスが悪いピアに自分が運用しているブロックチェーンノードが繋がってしまっている、という場合が考えられると思います。

❸「ブロックチェーンノードのアップグレードの作業の頻度はどれくらいですか？」

ブロックチェーンによって様々ですが、慣らすと大体１ブロックチェーン月に１回ぐらい多かれ少なかれアップグレードが配信されており、それが３０ブロックチェーンぐらいなので、月に３０種類ぐらいのアップデートを扱う必要があります。対象ノードが１６０個あるのでかなりの頻度でアップグレードしています。ここはまだ安易に自動化もできる部分ではないので、チームメンバーが頑張ってくれています。

❹「Prometheusもアーキテクチャ図に入ってましたが、Datadogとの使い分けはどうのようになっていますか？」

DatadogもPrometheusのようにエージェントを入れて使うことができると思いますが、基本的なデータ収集をPrometheusに渡していて、Datadogには可視化周りとかアラート周りをメインに役割を持ってもらっています。

❺「クラスタを環境ごとに分割することでアップグレードする必要がクラスターが増えているのに、工数が削減できる原因はなんでしょうか？」

テストネットとメインネットでクラスターを分割する話をしましたが、一番注力してアップグレードするべきはメインネットのクラスタです。そこが一番アップグレードに時間がかかるので、アップグレードを行った時の作業回数は増えるものの作業全体にかかる時間は変わらない。さらに分けたことで検証がしやすくなって検証しやすくなった分の工数が浮いています。

❻「ブロックチェーンノードの運用で、最も大変なことはなんでしょうか？」

ネットワークにノードの同期した状態を保つことです。一番最初にP2Pで繋がっていますよ、という話と、データベースの運用する必要がある、という話をしましたが、そもそもデータベースの運用は昨今クラウドに任せるのが普通なので、やることではなく大変です。P2Pアプリケーションに様々なパラメータがあり、その辺りをチューニングして常にネットワークに同期した状態を保つのが難しいです。その辺りは自動化ができず、ある程度は手動でチューニングを行っています。より良いパラメータ求めて実験を繰り返しているところです。

❼「オリジナルロードバランサーはOSS化されてますか？」

検討はしていますがOSS化はされていないです。完全にその要件に合わせてフレームワークなどを使いながら、ほとんどの機能を自分たちで実装しています。

❽「ブロックチェーンのTPSはどれくらいですか？」

ブロックチェーンによりますが、例えば最近よく使われているPolygonでは、1万TPS行かないぐらいだったと思います。これはよくチューニングしたとしても確か10万TPSぐらいだったと思うので、１桁変わるぐらいのTPSは出ています。

あとがき

以上、今回は『Google Cloud』が主催したビジネス価値創造をテーマにしたカンファレンスで、弊社技術開発チームのリーダー・鷲見が『開発効率化とコスト削減。GKEを用いたブロックチェーンノード基盤の刷新』について発表した内容をお届けしました。普段ここまで掘り下げた話をお伝えする機会はありませんでしたので、ブロックチェーンインフラの信頼性構築の技術の一端が伝わっていれば幸いです。

弊社Gincoでは、ブロックチェーンの活用を検討されている企業様向けにブロックチェーン導入支援・コンサルティングサービス等を行なっております。もし、セミナー参加者様、本レポートをご覧になった方で興味・ご関心がございましたら、下記の弊社概要欄よりお問い合わせください。