🤖

弊社がNacosを使用について色々喋ります

John Xu

2023/12/13に公開

どうも、イオンスマートテクノロジー（略称AST）のXuです。
この記事は、AEON Advent Calendar 2023の13日目です。

ASTは業務中台というシステムが存在しています、そのシステムのサービスディスカバリの役割を担当しているのはNacosです。今回の記事でそのNacosを紹介しながら少しASTのテクノロジーアーキテクチャを紹介したいと思います。

でも、ここまでご覧になりますと、「え？見たことない日本語が出たね、業務中台は何だ？ぎょ、業務スーパーってこと...?」という質問が出てくると思います。

その質問は回答しないと、Nacosのメリットはあんまりわからないと思います。一旦話を逸らして、ASTの中の業務中台を説明いたします。

なぜASTは業務中台を使いますか

ASTはイオングループの中に主に担っている役割はお客様向けのiAEONアプリの開発、イオンのスーパーなどの現場の従業員向けのシステム開発、そして、イオングループの全グループのDXを推進を実現します。

https://www.aeon-st.co.jp/business/

特に皆さん使われているiAEONはお客様とイオンのタッチポイントです。そのアプリをご覧になるならわかるはず、それはスーパーアプリで、沢山なサービス一つのアプリに包括しています。それを実現できるために、ASTはマイクロサービスを活用しています。

そのマイクロサービス成り立つために、核心的な位置付けしているシステムは、上記に書いた業務中台です、これは最初からDMCという会社から作って、中国のイオンの中にうまく使われていました。

「業務中台」という名前は元々中国語から直訳されました、この単語の意味をわかりやすく説明しますと、

業務: 会社の業務をDXにすることを対応
中: 会社に対してに「中心」的な存在。
台: 中国語で「プラットフォーム」という意味。

だから「業務中台」は会社の日々のコア業務をDX化にして、会社の中心的なプラットフォームとして使われています。もっと具体的に説明しますと、会員情報関連の業務、商品情報関連の業務、在庫管理関連の業務、販促・マーケティング関連の業務など、色んな会社のコア業務を抽象してモジュール化にし、APIの形で作って社内で提供して、マイクロサービス的なプラットフォームとして運用しています。

test ASTの業務中台参照:https://techplay.jp/column/1507

もし何か顧客向けまたはイオン従業員むけのサービスを作りたいときに、フロントエンドは直接に業務中台のAPIを叩いて機能開発ができます。フロントエンドが特別な機能を必要とする場合、バックエンドはその要求に応じて動きます。具体的には、バックエンドでは、業務中台に存在するAPIをクライアントが求める形に適切に加工して返し、フロントエンド専用の新しいAPIが作成されます。その方法はBFFといいます。

「業務中台＋BFF」の形で開発のスピードが速くなります、バックエンド側は業務中台のAPIをどのようにうまく使うのを考えればいいです。フロントエンド側もより効果的に動作し、ユーザーに最適な体験を提供できるようになります。

イオンの業務中台は以下のように作りました:

開発言語とツール: Java、Spring Cloud Alibaba
インフラ構成:
- AKS（業務APIを提供）
- VM（Nacos、Kibana、Elasticsearchなど）

そういえば、上にAKSを書きましたが、弊社のSREチームのイケイケな人たち@Tocyuki（通称：KASAI Leaderがやる）と@hikkie13（通称：ヒカルしか勝たん）がCloudNative Days Tokyo 2023のスポンサーセッションに登壇することが決まってます。イオンがKubernetesを採用してどうなった？っていう内容ですので、興味があればぜひ見てみてください。

数多くのAPIを提供していますので、APIを提供しているPodまたはインスタンスの管理があります、会社内の他のサービス連携も管理が必要になります、とにかく、管理は大変複雑です。こんな沢山なマイクロサービスをより便利に管理するために、Nacosの出番です。

では、本題に入ります。

なぜASTはNacosを導入しますか

理由は上記にも書いた通りに、Nacosはマイクロサービスを管理することは便利です、特にSpring Cloud Alibabaというツールを使う場合に、一発で必要な設定ができます。こちらのセクションはNacosの機能と仕組みから説明して、読者はよりNacosを理解していただいた上に、ASTはどのようにNacosを活用するのも説明します。

Nacosは元々Alibabaの社内のプロジェクトで、2008年から使い始めました、2018年にOSSとして公開しました。Nacosの機能は主に以下です:

システムのサービスのレジスターとサービスディカバリ
サービスの死活監視とマイクロサービスの負荷分散の実現
コンソールでサービスの管理

機能をもっと詳細に説明しましょう。

システムのサービスレジスターとサービスディスカバリ

Nacosの基本の機能はサービスレジスターとサービスディスカバリです。

Nacosの中にNacos ServerとNacos ClientというC/S的な構成になっています。Nacos Serverの役割は主にService Registryというサービス登録フォームを管理します。Nacos ClientはSidecarの形で、各自のサービスと連携しています。そして、分かりやすく理解するために、Nacos ClientはConsumerという他のサービスから情報を取得するロールとProviderという情報を提供するロールに分かれています。

Nacosのサービスレジスターとサービスディカバリの仕組み

Nacosを使ってサービスレジスターとサービスディスカバリの流れは以下です:

① サービスレジスター: user-serviceとorder-serviceはSpring Cloud alibabaを利用して、Nacos ServerのService Registry APIを叩いて、各自のサービスのメタデータをNacos ServerのService Registryに登録します。そのメタデータはservice name, ip, port, statusなどがあります。

② サービスディスカバリ: Consumerのロールとしてuser-serviceはProviderのロールのorder-serviceをアクセスしたいです。user-serviceはorder-serviceのipとportが知らないですので、NacosのService Acquisition APIを叩いて、Service Registryの中に記録したorder-serviceのメタデータを取得します。

③ 上のステップでuser-serviceはorder-serviceのipとportがわかりますので、order-serviceをアクセスします。

サービスの死活監視とマイクロサービスの負荷分散の実現

上記の内容はわかりやすいと思いますので、もっと掘り下げて説明したいと思います。

より実務と近いケースを考えてください:

AKSを活用して、マイクロサービスを実現しています、その中にuser-serviceとorder-serviceというサービスがあります。user-serviceは会員情報業務関連のサービスです、order-serviceは商品購入する業務の関連サービスです、今はこの二つのサービスは以下のように設定しています:

user-serviceのpodは一つ
order-serviceのpodは二つ

なら、order-serviceの一つのpodは死んだとしたら、user-serviceはどのように検知しますか？(Nacosは使っていますので、Kubernetsのserviceを使わないとします)
それで、user-serviceはどのようにその二つのorder-serviceを負荷分散を実現しますか?

この図に沿って、以上の質問を回答します

order-serviceの一つのpodは死んだとしたら、user-serviceはどのように検知しますか？
- order-serviceのNacos Clientの中にTime Taskというコンポーネントが存在しています。設定時間内（デフォルトは15s）のorder-serviceのNacos ClientからNacos ServerのHeartbeat APIにハートビットを送ります。設定時間過ぎでもNacos ServerはそのサービスのNacos Clientのハートビットを取得できていない場合に、Service Registryに該当Nacos Clientのメタデータのstatusはfalseとして登録します。
- user-serviceのNacos Clientはorder-serviceと同じ構成があり、設定時間内もハートビットを送ります。でも、そのTime Taskはもう一つの役割があります：一定時間内にService Registryのメタデータを取得し、キャッシュに書き込みます。目的はその時間に最新メタデータの一覧を取得し、statusはfalseになるNacos Clientを早めに検知し、アクセスしないようになります。
- もし30s過ぎでも、Nacos ClientはハートビットをHeartbeat APIに送っていない場合に、Nacos Clientはサービス停止というシグナルをRegistry Remove APIに送ります、Nacos Serverは該当Nacos Clientのメタデータを削除し、サービスを外します。
user-serviceはどのようにその二つのorder-serviceを負荷分散を実現するか?

1で書いたようにTime Taskは一定の時間内に最新のService Registryのメタデータを取得し、キャッシュに書き込みます。ConsumerロールのNacos Clientはロードバランサーを設定できます。そのロードバランサーはキャッシュにより、生きているorder-serviceのAPIを叩きます。

以上の二つの質問を回答しながら、Nacosの死活監視の方法とマイクロサービスの負荷分散の実現方法を説明しました。