イベントレポート
ブロックチェーン導入の重要性を語るキーワード「テクノロジーとビジネスの変革、データの氾濫」
オラクルの技術者向け勉強会「Blockchain GIG #2」後編
2019年4月11日 06:00
日本オラクル株式会社は4月4日、エンタープライズ領域でのブロックチェーン活用を検討しているユーザーや技術者向けの勉強会「Blockchain GIG」を開催した。本セミナーは数か月に一度というペースで定期開催され、今回が第2回目となる。今回は概念実証から商用展開まで手がけるエンジニアらが、エンタープライズのブロックチェーン活用について、さまざまな視点から講演を行った。
本稿では、秀嶋元才氏による「ブロックチェーン技術の本番適用に向けた顧客課題への取り組み」と、トライデントアーツ株式会社・CEOの町浩二氏による「Enterprise Blockchain サービス実用化における技術的なポイント」をまとめる。
勉強会前半の内容は記事「Hyperledger Fabricでの開発段階でハマりがちな落とし穴とは？」にて掲載中だ。
秀嶋氏講演「ブロックチェーン技術の本番適用に向けた顧客課題への取り組み」
秀島氏は、「ブロックチェーン技術の本番適用に向けた顧客課題への取り組み」と題して、ブロックチェーン技術を使ったプロジェクトを商談に持ち込むまでと、持ち込んでからの課題について話した。秀島氏は富士通でデータベースエンジニアとして証券基盤などの設計に携わり、ブロックチェーン開発などを経て、現在はある戦略コンサルファームでエンジニアチームを率いているという。今回は所属組織から登壇の許可が取れなかったため、一人のエンジニアとして参加とのこと。
商談に持ち込むまで
商談に持ち込むまで、つまり構想策定の段階では、顧客に対して「テクノロジーの歴史」を話すと秀島氏は言う。テクノロジーが移り変わる中で、ビジネスがどう変わってきたかを説明し、ブロックチェーンの必要性を主張する。
下図は、秀島氏が考える、ネットワーク技術の変革とビジネス構造の変化を表した図だ。ネットワークの進化よって、流通するデータ量は爆発的に増加した。この先、IoTなどの普及でありとあらゆる情報が互いに交換できるような状態が実現すると、中央集権的にデータを処理・管理することは不可能になるという。
そうした流れの中で、データ自体に所有権などの利権が絡んでくると一層複雑化してしまう。そこで、すべてのデータを開示し、分散管理しながら、その正当性を保証できる技術が注目されてきた。それがブロックチェーンを含む分散管理の新しい技術となる。「データが氾濫する世界において、ブロックチェーンは非常に有用」と説明した上で、顧客の事業内容にどう生かせるか検討を始めるという。
プロジェクトが始動してからの課題
商談が成立して、プロジェクトが動き出すと課題が出てくる。まずは既存システムとの連携面である。エンタープライズでブロックチェーンを導入する際、殆どの場合は既存システムと接続することになる。
設計においては、ブロックチェーンと既存のデータベースとの間で、どの程度の間隔で同期を取るかといった部分を業務上許容できる範囲などを厳密に取り決めて、検証・設計していく必要があるという。また、性能面の設計では、システムの安定性と業務のパフォーマンス最大化を両立しなければならない。
これらを、実証実験（PoC）の段階で、実際にテストすることを秀島氏は強く勧めた。実運用上想定される最大の負荷を実際にかけて、ブロックチェーンを含めたシステム全体のパフォーマンスを見るというプロセスは極めて重要であるという。
検証においては、システムに対して短期サイクルでデータを投入していく。処理の発生は一定ではなく、処理の滞留でスパイクが生じることもあるため、その制御も重要であるという。秀島氏の経験では、ブロックチェーンに処理を渡す前にトランザクションを制御するための工夫などを加えて問題を回避することが多いという。
最後に、秀島氏は実証実験を終えた後に、実運用に向けて機能・非機能の評価を行うことを勧めた。検証項目ごとに評価を行い、総合的なスコアリングによって業務との適合性を見極めるのだという。さらに、「ブロックチェーン」「既存技術のみ」「ブロックチェーンと既存技術のミックス」のそれぞれでコストや適合性を算出し、最適な運用方法を提案していくと語った。
トライデントアーツ町氏講演「Enterprise Blockchain サービス実用化における技術的なポイント」
町氏はビジネスITの業務に取り組む傍ら、2009年という最初期からブロックチェーン分野に取り組んでいるという。業界では古株のエンジニアとなる。これまで、エンタープライズ領域のシステム開発・モデル設計を手がけてきたとのこと。ここまでの登壇者とは違って、現在はEnterprise Ethereumをベースとしたエンタープライズ向けのシステム開発を行っている。
今回、町氏が解説する領域は、Enterprise Ethereumを用いたシステム設計と開発における、システム構造に関わる部分。中でも分かりやすいという「ビジネスアーキテクチャ」「データアーキテクチャ」「アプリケーションアーキテクチャ」の3点について語る。
ビジネスアーキテクチャ
エンタープライズでのブロックチェーン導入に関して、金融分野を除けば現行のトランザクション性能はほとんどの要件を満たすと町氏は言う。多くても秒間1000件のトランザクションができれば十分であり、現行のエンタープライズブロックチェーンは秒間2000件程度まで対応可能だ。
システムの要件を定義する上で、「システムの寿命年数」を算出することも有効だという。どんなシステムでも、5年も経てば償却によって入れ替えることとなる。その間に発生する処理の量、それに対応するために必要なシステムの処理能力を設計すればいいということだ。
要件を定義した上で、システムのネットワークとディスクへの入出力（IO）を重視して、最適な設計を行う。CPUの性能は基本的に現行のシステムに対して余力がある。そのため、ディスクIOを減らしたり、ネットワーク構成を最適化したりすることが、数年先を見通すと重要になってくるという。
データアーキテクチャとアプリケーションアーキテクチャ
エンタープライズにおいては、既存システムとのデータ連係が必要となる。Ethereumでは、パブリックのコミュニティから供給される豊富なオープンソースのコードが、エンタープライズにおいても役に立つと思われがちだが、そのほとんどが不十分だと町氏は言う。多くのDAppsは企業のインターフェースを想定して作られていないので、既存システムに対応するインターフェースを設計・構築することが、エンタープライズエンジニアの腕の見せ所になる。
特に注意するのは、ブロックチェーン外の経路上での「データ消失」だと町氏は語る。従来のシステム設計思想であればデータの再送などの対策を施すが、その場合ブロックチェーンに再度データが書き込まれることになり、データ重複の問題となる場合があるなど、取り得る手法が異なってくる。
また、オープンソースのDAppsは組織変更や制度対応について、仕様変更が考慮されていないケースが多いという。そのため、柔軟に仕様変更へ対応できるよう「疎結合・階層化・モジュール化」という考え方でアーキテクチャを設計していると町氏は語る。
町氏は、実装の一例として、Enterprise EthereumのQuorumをベースとして、疎結合・階層化・モジュール化の概念を適用して実際に開発した実装例を示した。下図のようにサーバーの構成を、UX基盤・台帳基盤・台帳間接続基盤に分ける。さらに、それぞれをアプリ層・台帳層・ノード層に分けて考えるという。
上図において、2つの代替不可コンテンツを別々の台帳として、台帳層に作ったとする。この2つを、1つ上層のアプリ層で連携する。コンテンツAをコインBで購入するといった取引を司る部分は、アプリ層の台帳基盤上で実装する仕組みを取る。この形態であれば、ユースケースが変わった場合にもコインだけを変更するなど、一部の変更で柔軟に対応できるという。