AOエコシステム勝利の鍵：Web3時代のマイクロサービス・アーキテクチャ

著者：ArweaveOasis、ソース：PermaDAO

この記事では、マイクロサービスアーキテクチャ（Actorモデル）を採用する利点について議論し、それがアプリケーション開発にもたらす論理的な複雑さの度合いを分析します。

@aoTheComputerの立ち上げは、間違いなく@ArweaveEcoエコシステムとWeb3業界全体に新しい考え方と実践方法をもたらしました。これは、大多数の投資家の注目に反映されただけでなく、綿密な研究を開始するために多くの質の高い開発者を引き付けたことにも反映されています。

Web3が大規模に採用されるのを妨げているものは何でしょうか？

単純に、利用価値のある分散型アプリケーションが少なすぎるのです。

Web3のインフラ、開発ツール、ソフトウェアエンジニアリングの実践などの現状からすると、多くの種類の分散型アプリケーションを実装することは、現在のところほぼ不可能です。

インフラという点では、AOの登場がこれらの重大なギャップのいくつかを埋めていると思います。しかし、大規模な分散型アプリケーションを構築するためのエンジニアリングの複雑さは、現時点ではまだ困難です。そのため、より多様で大規模な、つまり限られたリソースでより優れた、機能豊富な分散型アプリケーションを開発することができないのです-物事の初期段階ではよくあることですが。

「スマートコントラクト/オンチェーンアプリはシンプルであるべきで、複雑にする必要はない」という戯言を信じてはいけません！

現実は、やりたくないのではなく、できないのです。

AOはArweave上で動作するコンピュータシステムで、検証可能な無限の計算能力を達成するように設計されています。Actor Orientedの略です。その名が示すように、AO上で動作する分散型アプリケーションには、アクターモデルに基づいた設計とプログラミングのアプローチが必要であることを示しています。

実際、ブロックチェーン（または「分散型インフラ」）にActorモデルを使用したのはAOが初めてではない。たとえば、TONのスマートコントラクトはActorモデルを使って構築されています。TONといえば、個人的にはAOと似ているところがあると思います。

まだWeb3を掘り下げていないWeb2開発者にとって、他の「モノリシックなブロックチェーン」と比較してAOやTONの最も重要な特徴を素早く理解する便利な方法は、それらの上で実行されるスマートコントラクト（チェーン上のプロセス）を「マイクロサービス」と考えることです。「マイクロサービス」と考えることだ。そしてAOやTONは、KafkaやKubernetesなどのような、これらのマイクロサービスの実行をサポートするインフラです。

20年以上、主にアプリケーション開発に注力してきたベテランのCRUDボーイとして、個人的にはAOやTONのような非モノリシックなブロックチェーンの登場をとても嬉しく思いますし、その発展を楽しみにしています。以下、アプリケーション開発者の立場から、AOに対する私の見解を述べたいと思います。もしかしたら、心に響くアプリ開発者もいるかもしれませんし、それで十分です。

ブロックチェーンにActorモデルを適用することは、本当に必要なのか？

答えはイエスだ。大量採用」を達成したWeb2アプリケーションを見ればわかります。

あまりにも多くのアーキテクトが、Web2アプリケーションを「大きく」する方法をすでに知っています。マイクロサービスアーキテクチャ（MSA）、イベント駆動アーキテクチャ（EDA）、メッセージ通信メカニズム、最終的な一貫性モデル、シャーディング、......何と呼ばれようと、それらは常にアクターモデルと共通しています。それらが何と呼ばれようと、常にアクター・モデルと共生している。これらのコンセプトの中には、ひとつのものの異なる側面に過ぎないとさえ言えるものもある。そのため、以下では「マイクロサービス」と「アクター」を区別せず、同義と考えていただいて構いません。

今日のインターネットの繁栄は、こうしたアーキテクトたちの知恵によるものだ。彼らは探求し、実践し、要約し、最終的にはエンジニアリングプラクティスの完全なシステムを開発した。

Web3のインフラとして、AOは素晴らしい仕事をしています。少なくとも、AOは今日のWeb3空間における最高の分散型メッセージングエージェントとして、大きな可能性を示しています(私の意見ですが)。KafkaやKafkaのようなメッセージングエージェントなしに、今日の大規模なインターネットアプリケーションの多くを「プログラミング」することを想像できますか？

Actorモデルは理論的には多くの点で優れていますが、Actorモデルとマイクロサービスアーキテクチャは、特定のアプリケーション、特に大規模なアプリケーションを開発するために開発者が負担しなければならない、首の痛くなるようなものだと私は考えています。

この点を非技術的な読者に説明するために、簡単な例を使ってみよう。世界中のすべての銀行が、モノリシックなシステムである「ワールドコンピュータ」に基づいて業務を行っているとしましょう。そこで、ICBCの顧客であるチャン・サンが、中国招商銀行の口座を持っているリー・シーに100ドルを送金する場合、開発者は次のような送金プログラムをコーディングすることができる：

1.トランザクション（または「取引」）を開始する。「

2.チャン・サンの口座から100ドルを引き落とす。

3.リー・シーの口座に100ドルを追加する。

4.トランザクションを送信する。

上記のステップのどれが失敗しても、例えばステップ3の李斯の口座への追加が何らかの理由で失敗しても、全ての操作は何事もなかったかのようにロールバックされる。ちなみに、このような書き方をするプログラムを「強い一貫性」モデルと呼ぶ。

世界のコンピュータがマイクロサービスアーキテクチャ（MSA）システムだったらどうでしょうか？

ICBCの口座を管理するマイクロサービス（またはアクター）が、中国招商銀行の口座を管理するものと同じである可能性は極めて低い。前者をアクターICBC、後者をアクターCMBと呼ぶことにします。 この時点で、開発者は次のような送金コードを書く必要があるかもしれません：

1.アクターICBCはまず次の情報を記録します："Zhang San transfers $100 to Li Si"アクターICBCはZhang Sanの口座から100ドルを引き落とし、アクターCMBに「Zhang San transferred $100 to Li Si」というメッセージを送信する。

2. アクターCMBはメッセージを受信し、Li Siの口座に100ドルを追加し、アクターICBCに「Li Si has transferred $100 to Li Si」というメッセージを送信する。アクターCMBはメッセージを受信し、李さんの口座に100ドルを追加し、アクターICBCに「李さんは張三から100ドルを受け取りました」というメッセージを送信します;

3. アクターICBCはメッセージを受信し、「張三は100ドルを李さんに送金しました、成功しました」と記録します。

上記は「すべて順調」なプロセスです。しかし、ステップの1つ、例えば2番目の「李さんの口座に100ドルを追加する」に問題があるとしたらどうでしょう？

• アクターCMBはアクターICBCにメッセージを送ります： "Failed to process a $100 from ZhangSan to LiSi！".

• Actor ICBCはメッセージを受け取り、Zhangsanの口座に100ドルを追加し、「ZhangsanからLisanへの100ドルの送金、失敗」と記録する。

手続きは、最終的な一貫性モデルを使用して呼び出すように書かれています。

上記で、技術的でない読者は、モノリシックアプリケーションの開発とMSAアプリケーションの開発の作業負荷の大きな違いを視覚化できるはずですね。上で説明した転送の例は、機能ではなくアプリケーションと呼ぶのであれば、非常に単純なアプリケーションに過ぎないことに留意してください。大規模なアプリケーションの機能は、この例よりもはるかに複雑であることがよくあります。

このマイクロサービスはどのくらいの大きさにすべきでしょうか？

言い換えれば、"このマイクロサービスは大きすぎて、2つに分けるべきか？"ということです。

残念ながら、この質問に対する標準的な答えはありません。マイクロサービスが小さければ小さいほど、新しいインスタンスを作成してオンデマンドで移動させることで、システムを最適化しやすくなります。しかし、マイクロサービスが小さくなればなるほど、開発者が複雑なプロセスを実装するのは難しくなります。

ところで、アプリケーションを複数のマイクロサービスに分割することは、データベース設計の観点から「シャーディング」として知られています。マイクロサービスアーキテクチャのベストプラクティスの1つは、各マイクロサービスがそれ自身のローカルデータベースを1つだけ使用することです。簡単に言うと、シャーディングは水平スケーリングを可能にする。データセットが大きくなりすぎて従来の方法では扱えなくなった場合、（スケーリングするには）小さく分割する以外に方法はありません。

マイクロサービスの分割の問題に戻ろう。この技術を実践するためには、いくつかの思考ツールの使い方をマスターする必要がある。つまり、ソフトウェア設計における「核となる複雑性」を破壊するのに役立ちます。

私は、集約は戦術レベルでDDDの最も重要な概念の1つだと考えています。

集約とは何でしょうか？集約はオブジェクト間、特にエンティティ間の境界を引きます。集約は、集約ルートエンティティと、おそらく不確定な数の集約内エンティティ（または非集約ルートエンティティ）を含まなければならず、また、それだけを含まなければなりません。

集約の概念を使用して、アプリケーションによって提供されるドメインを分析し、モデル化することができます。最も単純に言えば、これは各集約をマイクロサービスとして実装することで行われます。

しかし、たとえあなたが熟練した技術を持っていたとしても、この種のことが最初からうまくいく保証はありません。そこで、モデリング結果をできるだけ早く検証し、うまくいかなければプッシュバックできるツールが、あなたにとって貴重な存在になるのです。

大規模なWeb2アプリケーションをAOエコシステムに移行する上で、他に障壁となるものは何でしょうか？

言語とアプリケーションのランタイムの問題についてお話したいと思います。

AOはデータプロトコルです。AOネットワーク内のさまざまな「ユニット」がどのようにコラボレーションできるかを定義する、インターフェイス仕様のセットと考えることができます。現在、AOの公式実装には、WASMベースの仮想マシン環境と、WASMにコンパイルされたLua実行環境（ao-lib）があり、AOプロセスの開発を簡素化するように設計されています。

Luaは小さくて美しい言語です。Luaの長所は、軽量で他の言語への組み込みが容易な点にあると一般に認められており、ゲーム開発などの特定の場面で特に有用です。しかし、大規模なインターネット・アプリケーションの開発では、Luaは主流ではありません。大規模なインターネットアプリケーションの開発では、Java、C#、PHP、Python、JavaScript、Rubyなどの言語が好まれることが多く、これらの言語はより包括的なエコシステムとツールチェーンを提供し、コミュニティによるサポートも充実しているからです。

これらの言語はすべてWASMバイトコードにコンパイルでき、WASM仮想マシンで実行できると主張する人もいるかもしれません。しかし実際のところ、WASMはWebフロントエンド開発の分野では強力ですが、インターネットアプリケーションのバックエンド実行環境としてWASMを採用することは、現在のところ主流の選択肢ではありません。スマートコントラクト（オンチェーンアプリケーション）は、Web3時代の「新しいバックエンド」であることに注意してください。

まとめ

まとめとして、マイクロサービスアーキテクチャ（Actorモデル）を採用する利点と、それがアプリケーション開発にもたらす複雑さについて述べてきました。この複雑さの中には避けられないものもあります。例えば、メッセージ通信に基づく「最終的な一貫性」を実現することは、よりエンジニア的なWeb2環境であっても、多くの開発者にとって既に課題となっている。AOプラットフォームでDappsを開発することは、この課題をより顕著にするように思える。その一例が、下記リンク先の記事の冒頭にある。

https://github.com/dddappp/A-AO-Demo?tab=readme-ov-file#an-ao-dapp-development-demo-with-a-low-code。-アプローチ

パブリックチェーンの戦いは、実際にはアプリ開発者の戦いであることは誰もが知っている。では、この場合、AOはどうやって開発者を獲得するのだろうか？

私は、すでに「大量採用」を達成したWeb2から学び続ける必要があると思います。これには、インフラだけでなく、開発方法論、ツール、ソフトウェアエンジニアリングの実践についても学ぶことが含まれます。次回の投稿では、私が強く信じているソリューションのひとつ、ローコード開発を紹介しよう。