孫玄、Zhuanzhuan 社アーキテクチャアルゴリズム部門: AI によるマイクロサービスアーキテクチャ

[51CTO.com からのオリジナル記事] 2014 年頃から、マイクロサービスアーキテクチャの概念が徐々に普及してきました。Amazon や Netflix などの有名なインターネット企業のアプリケーションプラクティスと相まって、開発者はマイクロサービスがアーキテクチャレベルでボトルネックを打破できると確信するようになりました。今日では、新しく開発されたシステムであれ、10 年以上前のレガシーシステムであれ、マイクロサービスチームについて話さないことは稀です。では、マイクロサービスアーキテクチャの現在の適用状況はどうでしょうか?デメリットは何ですか? AI テクノロジーの実装によってどのような課題がもたらされるのでしょうか?

最近、2018 WOTグローバルソフトウェアおよび運用技術サミットの重鎮ゲストであり、Zhuanzhuanのアーキテクチャアルゴリズム部門の責任者であるSun Xuanが独占インタビューに応じました。インタビューでは、マイクロサービスアーキテクチャの利点、アプリケーションシナリオ、Zhuanzhuanのマイクロサービスアーキテクチャの進化、およびAIテクノロジーアプリケーションが直面しなければならない課題に焦点を当てました。

[[227143]]

孫玄、Zhuanzhuan 社の建築家 / 建築アルゴリズム部門責任者

マイクロサービスアーキテクチャの利点、適用シナリオ、欠点

マイクロサービスアーキテクチャの特徴

マイクロサービスアーキテクチャについて話す前に、まずモノリシックアーキテクチャについて話す必要があります。モノリシックアーキテクチャとは、すべてのビジネス機能が 1 つのプロセスで実装されることを意味し、次の 2 つの利点があります。

まず、リクエスト応答の遅延が低いです。クライアントのリクエストを受信した後、1 回のネットワークインタラクションの後に、データベースからデータが一括して取得されます。残りの機能はすべてプロセス内で完了し、複数のネットワークインタラクションを回避します。

2 つ目は、プロセスが 1 つだけなので、導入や運用・保守のコストが低く抑えられることです。

しかし、ビジネス機能単位間の結合が激しい、スケーラビリティが低い、テクノロジの選択が単一である（1 つのプロセスで複数の開発言語を使用できるかどうか）などの欠点も明らかです。その中でも、最大の問題は、アーキテクチャが粗すぎるため、システムの反復速度に重大な影響を与えることです。

モノリシックアーキテクチャでは、急速に成長するインターネットビジネスのニーズを満たすことが難しいため、特定の次元に従って分割されます。

システムを水平に分割します (水平階層化アーキテクチャ)。
ビジネス機能に応じた垂直分割（SOA アーキテクチャ）。
ビジネス機能に応じて垂直に分割し、システムに応じて水平に分割します (マイクロサービスアーキテクチャ)。

下の図に示すように、マイクロサービスアーキテクチャは 2014 年に Martin Fowler によって提案されたアーキテクチャパターンです。

マイクロサービスアーキテクチャは、一般的に、業務領域に応じてサービスを分割し、一連の小さなサービスで構成され、サービスを独立して展開し、独立して実行し、分散的にサービスを管理します (任意のサービスは、C/PHP/Go/Java など、任意の言語で開発できます)。

Linux/Windows などのあらゆるプラットフォームで実行可能 (理想はフル機能ですが、現実は比較的スリムです)。

孫玄氏は、マイクロサービスはまずビジネスドメインモデルに従って垂直に分割され、つまり、異なるビジネス機能単位に従って垂直に分割されると述べました。その後、垂直に分割されたサービスがさらに水平方向に分割されます。

マイクロサービスアーキテクチャの利点と現状

マイクロサービスアーキテクチャの利点について尋ねられた Sun Xuan 氏は、マイクロサービスアーキテクチャを採用した後、プロジェクトは迅速な反復と継続的な配信を実現できると述べました。サービスアーキテクチャの出現により、水平階層化アーキテクチャと SOA アーキテクチャの不完全な分割の問題が解決されます。

ビジネスの観点から見ると、マイクロサービスアーキテクチャは本質的にビジネスアーキテクチャです。ビジネスに対する理解が深まれば深まるほど、マイクロサービスの分割はより合理的になります。
システムの観点から見ると、マイクロサービスアーキテクチャは、水平階層型アーキテクチャと SOA アーキテクチャを組み合わせたものです。

マイクロサービスアーキテクチャについて語るとき、Netflix について言及する必要があります。 Netflix は、マイクロサービスアーキテクチャの実装に成功したインターネット企業です。数年前、Netflix はマイクロサービスフレームワークスタックのほぼ全体をオープンソースコミュニティに提供しました。

Netflix のオープンソースフレームワークコンポーネントは、Netflix の大規模分散マイクロサービス環境で長年にわたり運用検証されており、マイクロサービスフレームワークを構築するための標準コンポーネントとしてコミュニティに徐々に受け入れられています。昨年 Pivotal がリリースした Spring Cloud オープンソース製品は、主に Netflix オープンソースコンポーネントのさらなるカプセル化に基づいており、Spring 開発者がマイクロサービスの基本フレームワークを構築しやすくなっています。

マイクロサービスアーキテクチャの適用シナリオ

現在、国内の多くのシステムがマイクロサービスアーキテクチャを採用しており、Zhuan Zhuan 中古品取引プラットフォームもその 1 つです。社内でマイクロサービスアーキテクチャを積極的に実装するだけでなく、Baidu の ppc、Alibaba の Dubbo など、フレームワークをオープンソース化する企業もあります。

マイクロサービスアーキテクチャが適用できないアプリケーションシナリオは、内部システム、低レイテンシを必要とするシステム、強力な一貫性を必要とするデータの 3 つです。

内部システム

これらのシステムには、社内OAシステム（作業報告書など）、財務監査システム（精算システムなど）、人事システム（勤怠システムなど）、管理システム（会議室予約など）、運用保守自動化システム（作業指示システム、リリースシステム、CMDBシステムなど）が含まれます。このタイプのシステムは、機能が比較的単純で、要件が固定されており、変更頻度が低く、ユーザー数が少なく、平均訪問回数が少ないことが特徴です。このタイプのシステムでは、マイクロサービスアーキテクチャを使用する必要はほとんどありません。

システム要件: 低遅延

マイクロサービスアーキテクチャに従ってサービスを分割すると、サービスの数が増加し、サービス間の呼び出し関係が複雑になり、リクエストチェーンが長くなり、平均リクエスト時間が長くなります。したがって、リクエスト時間の消費に非常に敏感なシナリオでは、マイクロサービスアーキテクチャは適切な選択ではありません。たとえば、定量取引のシナリオでは、リクエストは複数のサービスプロバイダーに届きます。どのサービスプロバイダーの応答が受け入れられるかは、サービスプロバイダーの応答速度によって異なります。このビジネスシナリオでは、応答速度が 1 ミリ秒遅い場合でも無効になります。

データには強い一貫性が必要

マイクロサービスアーキテクチャでは、データが比較的分散しており、データの一貫性、特に強力な一貫性を実装することが比較的困難です。したがって、データの強力な一貫性が求められるシナリオでは、マイクロサービスアーキテクチャは不適切になります。

上記の 3 つのシナリオに加えて、マイクロサービスアーキテクチャはインターネット上の他のシナリオでも使用できます。

孫玄氏は、マイクロサービスアーキテクチャにも明らかな欠点があると述べました。ビジネスロジックの実装に重点を置くことに加えて、開発者はサービス登録、サービス検出、サービス通信、負荷分散、サービスサーキットブレーク、要求タイムアウトの再試行など、マイクロサービスモジュール内の一連の問題にも対処する必要があり、これは非常に悪いことです。ビジネス開発チームの強みは、テクノロジーではなく、ビジネスへの理解にあります。ビジネス開発者がビジネス開発のみに集中し、サービス間通信やリクエスト管理機能を気にしなくて済むようにすることは可能でしょうか?サービスメッシュアーキテクチャはこの問題を解決し、ビジネス開発者の負担を真に軽減します。

Zhuanzhuan中古プラットフォームのマイクロサービスアーキテクチャの進化

中古品ショッピングプラットフォームには、ユーザー機能、商品機能、取引機能、検索機能、推奨機能などが含まれます。各ビジネスユニットは比較的独立しています。まず、ビジネスドメインモデルに従って、ユーザー、製品、トランザクション、検索、推奨のマイクロサービスに垂直に分割されます。機能単位（製品等）ごとに、製品ゲートウェイ層、製品ビジネスロジック層、製品データアクセス層、製品DB/キャッシュに水平分割し、同様にユーザー、トランザクション、検索、レコメンデーション、その他の業務についても水平分割します。

次の図は、Zhuan Zhuan Second-hand Easy Platform の最終的なマイクロサービスアーキテクチャを示しています。

中古取引プラットフォームには、登録センターと構成センターというサービス管理機能も含まれています。ゲートウェイはアクセス要求を担当し、ビジネスロジック層はさまざまなビジネスロジックを処理するために使用されます。データアクセス層はデータアクセスエージェントとして使用され、ORM、データシャーディング、基盤となるストレージの違いのシールドなどの機能を提供します。登録センターはサービスの登録と検出を担当し、構成センターはパーソナライズされたサービス構成の読み取りを担当します。

製品機能がますます複雑になるにつれて、一部の機能はビジネスロジックレイヤーで重複するようになります (たとえば、ビジネスロジックレイヤーにはユーザーログインロジック機能が必要です)。重複機能の問題を解決するには、それらをビジネスロジックレイヤーの下に移動し、パブリックビジネスロジックレイヤーを抽象的に抽出します。ユーザーのリクエストリンクは、ゲートウェイ、ビジネスロジックレイヤー、パブリックロジックレイヤー、およびデータアクセスレイヤーになります。

AI におけるマイクロサービスアーキテクチャ

中古品取引プラットフォーム「Zhuan Zhuan」は、検索、パーソナライズされた推奨、リスク管理などの分野で AI 技術を活用しています。 AIの観点から見ると、Zhuanzhuan は機械学習、特に教師あり学習をより多く活用しています。当社ではディープラーニングの実験も行っており、リスク管理などの分野で活用され、良好な成果を上げています。

検索推奨に関しては、その本質は、大量の商品を呼び出して並べ替える問題を解決することです。

リコール層には大規模な製品データが関係します。製品リコールをより正確にする方法と複雑なモデルを使用する方法は、エンジニアリングとアルゴリズムの適用の両方で大きな課題に直面することになります。
ソートレイヤーはより多くの機能を使用し、複雑なソートモデルを適用して、最終的な順序をユーザーの期待にさらに沿わせます。

孫玄氏は、製品リコールの件数が増加し、機械学習モデルはますます複雑になっていると述べた。分散並列コンピューティング技術を合理的に使用して、ユーザーのリクエストにできるだけ早く応答できるようにする方法は、マイクロサービスエンジニアリングアーキテクチャにとってより大きな課題となるだろう。

では、製品の数が増え、機械学習モデルがますます複雑になるにつれて、エンジニアリングアーキテクチャシステムの観点からそれらをより適切にサポートするにはどうすればよいか、また、ユーザーのリクエストにできるだけ早く応答するにはどうすればよいか、という問題があります。

2018 年 5 月 18 日と 19 日、2018 WOT グローバルソフトウェアおよび運用テクノロジーサミットの「コンテナでの AIOps」セッションで、Sun Xuan が「Zhuanzhuan が AI エンジニアリングアーキテクチャシステムを構築する方法」をテーマに講演します。そのとき、石器時代、鉄器時代、産業革命の各段階における工学建築システムの適用場面、建築上の特徴、さらに進化した理由などが詳しく説明されます。開発者は、Zhuanzhuan の AI エンジニアリングアーキテクチャシステムの進化の道筋を理解し、実践的な経験から学び、それを独自の AI エンジニアリングアーキテクチャに適用できます。

【インタビュー対象者プロフィール】

孫玄氏は現在、Zhuanzhuan 社のチーフアーキテクト兼アーキテクチャアルゴリズム部門の責任者であり、58 グループ技術委員会の元会長、シニアシステムアーキテクトであり、「Beauty of Architecture」パブリックアカウントの著者でもあります。システムアーキテクチャ設計、ビッグデータ、機械学習などの技術分野に精通しています。彼は会社を代表して、Artificial Intelligence Conference、QCon、ArchSummit、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT などのカンファレンスで講演を行い、Programmer 誌に 2 つの記事を執筆しました。元Baiduシニアエンジニア。Baiduコミュニティ検索部の複数の基本システムの設計と実装に参加。浙江大学卒業。

【今月のランキング***0】