APISIX如何助力Beeto社交媒体平台在中东地区的本地化部署

概要

課題

モノリシックなサービスアーキテクチャにより、保守と運用のコストが高い
複雑なアーキテクチャのデプロイとサービス呼び出し、複数の技術スタック

成果

南北および東西トラフィックを統一し、リソースと人件費を節約し、動的かつ統一的な管理を実現
デプロイアーキテクチャを簡素化し、ゲートウェイとユーザー間の相互作用を低減
APISIXの複数の拡張プラグインにより、Beetoは権限検証、ルート配信、サービスのヘルスチェック機能を効率的に管理
APISIXにより、Beetoはサービスを動的に起動および移行でき、開発者にとって使いやすい

Beetoの紹介

中東市場向けに、Beetoはアラビア語のソーシャルメディアプラットフォームであり、ローカライズされた製品設計と技術アーキテクチャを備えています。サウジアラビアのiOSアプリストアのトップリストで4位にランクインし、ベテランのソーシャルプラットフォーム大手であるFacebookを上回りました。

中東のインターネット開発は成熟しており、ソーシャルネットワークのアクティブユーザーの浸透率が非常に高いです。特にサウジアラビアでは、2019年に90％の人々がインターネットを利用していました。2020年には、サウジアラビアのアクティブユーザーの浸透率は9位にランクインしました。

インターネット市場の成熟により、WhatsApp、YouTube、Instagramなどの人気のある国際的なソーシャルソフトウェアが普及しています。しかし、Twitterのようなローカライズされたソーシャルソフトウェアは存在しません。そのため、中東の「成熟したインターネットだがローカライズが少ない」という状況を目指して、Beetoはローカライズされた製品開発を開始しました。

Beetoにとってのローカライズの重要性

TwitterやFacebookのようなフィードストリームアプリケーションをベンチマークとして、Beetoは中東でのビジネスアーキテクチャのデプロイメントのための比較的完全なフレームワークを計画しました。例えば、ソーシャル属性の関係相互作用、コンテンツ消費（テキスト、ビデオライブストリーミング、ローカル広告など）、報酬、引き出し、投票、金融およびサービスカテゴリの抽選など、さまざまなビジネスを満たすことに取り組みました。さらに、プラットフォームの監督とコンテンツセキュリティレビューの要件も満たす必要がありました。

前述のように、中東市場のインターネットの成熟度は、必然的に高品質の製品を要求します。そのため、Beetoのビジネスアーキテクチャの最初のバージョンは、主流のソーシャルソフトウェアが持つべきすべての機能を統合した完全な製品でした。一方で、Beetoの目標は、「ローカライズの特徴」を持つ中東最大のアラビア語ソーシャルプラットフォームおよび最高のアラビア語コミュニティになることです。この目標を実現するために、Beetoは以下のようなローカライズ要件を分析しました。

ローカライズの要望

Beetoのアーキテクチャ設計における課題

ローカライズには、ビジネスレベルでの既存のローカルソーシャルニーズと、技術レベルでのローカルオペレーション（サービスのデプロイメントやデータストレージなど）が含まれます。WeiboやTwitterに詳しい人なら、そのような巨大な情報フロープロダクトの背後には、数十または数百のアーキテクチャシステムが協力していることを知っているでしょう。Beetoのアーキテクチャにおける課題は以下の通りです。

モノリシックなサービスアーキテクチャによる高コスト

Beetoのサービスは、以下の8つの部分に分けることができます。

サービス分割

これらのビジネスを実現するためには、中東でのローカルデプロイメントが必要です。各サービスは、サービスごとに分割すると、それぞれが独立したモノリシックアーキテクチャになります。

モノリシックアーキテクチャ

上記のモノリシックアーキテクチャ図は、一般的なデプロイメントアーキテクチャを示しています。Beetoのフィードストリーミングサービスを例にとると、ユーザーがフィードストリームを閲覧するための要求を実現するためには、パブリックネットワークアクセス、つまり南北トラフィックアクセスをサポートする必要があります。同時に、フィードストリーミングサービスは、トピックビジネスの形で内部呼び出しも提供します。つまり、東西トラフィック呼び出しです。

したがって、全体のサービスは外部および内部呼び出しモードをサポートしています。レイヤー7の負荷分散後、ユーザートラフィックは異なるサーバーに分散され、その後、異なるストレージリソースが呼び出されます。東西トラフィックも同様です。レイヤー7クラスタは、南北および東西トラフィック、負荷分散、認証、ノード監視を処理します。

複数のビジネスのサービスが組み合わされると、全体のアーキテクチャは以下のようになります。

全体アーキテクチャ

ご覧の通り、サービスは適応層、ビジネス層、基本サービス層に存在します。これらの各サービスのデプロイメントアーキテクチャには、前述のモノリシックアーキテクチャの詳細が含まれているため、その間にいくつかのレイヤー7クラスタが存在し、非常に大規模で複雑なシステムアーキテクチャになっています。

しかし、Beeto製品はスタートアップ段階にあり、製品は中東でローンチされていますが、そのR&Dチームは中国にいるため、サーバーと保守のコストが非常に高くなります。さらに、ビジネスが増加すると、モノリシックサービスの数も必然的に増加し、コストと保守操作の両方を制御することがより困難になります。

複数サービスの起動の難しさ

アーキテクチャデプロイメントの複雑さに加えて、クラスタ内のサービス間の呼び出しも非常に複雑です。

南北トラフィックはさまざまなサービスプールに分散され、東西トラフィックもさまざまなサービスの間で交錯し、これらのサービス間の呼び出し関係が絡み合っています。

さらに、これらの呼び出し関係はサービスによって維持される必要があり、これにより呼び出しのトレーシングが不明確で、管理が困難になります。

技術スタックの差異

呼び出し関係の複雑さに加えて、各サービス間の技術スタックにも差異があります。例えば、呼び出しプロトコルでは、一部のサービスはHTTPを提供し、他のサービスはRPCを提供します。プログラミング言語の開発では、Java、Go、その他のプログラミング言語が混在しています。

このような多サービスアーキテクチャシステムは、ローカルで実装されると、高いデプロイメントと保守コストの問題が明らかになります。さらに、Beetoは各レイヤー7サービスにサーバーコストを投入する必要があり、各サービスのトラフィックの違いにより、リソースの利用率が低くなり、サーバーなどのリソースが浪費されます。

Beetoはビジネスのアップグレードとイテレーションに重点を置いているため、アーキテクチャは保守と統一的な管理を容易にするために設計されています。では、この目標をどのように達成するのでしょうか？

APISIXゲートウェイがBeetoのアーキテクチャを強化

サービス管理の不便さと高コストの問題を解決し、APISIXの動的パフォーマンスとetcdの利点を活かすため、APISIXがAPIゲートウェイとしてアーキテクチャデプロイメントに導入され、ゲートウェイクラスタが構築されました。以下の図に示すように。

APISIXを導入したBeetoのAPIゲートウェイアーキテクチャ

APISIXゲートウェイクラスタは、すべてのサービスに対してレジストリセンター、サービス制御、サービス監視、プロトコル転送、プラグインなどの拡張ツールを提供します。サービスのクラスタはすべてゲートウェイに登録でき、新しいサービスはゲートウェイを介して直接追加および削除できます。

Beetoのアーキテクチャのクラスタトレーシング

ゲートウェイが導入された後、クラスタ全体の呼び出しトレーシングがより明確になりました。南北トラフィックはゲートウェイによってルーティングおよび転送され、東西トラフィックはイントラネット上のサービスのためにゲートウェイによって処理されます。機能レベルでは、APISIXはこのトラフィックによって呼び出される認証を維持する責任があり、ゲートウェイ層はサービスのパフォーマンスの違いとトラフィックの違いを明確に理解できます。

もちろん、ゲートウェイがこのアーキテクチャのすべてのトラフィックを担っているため、サービスの拡大に伴いサービスの数が増加すると、ゲートウェイの保守コストが増加し、新しいソリューションを検討する必要があります。しかし、現状では、このソリューションが最良の選択肢です。

APISIX導入後の実践

Apache APISIXは、APIゲートウェイとして、ゲートウェイレベルでさまざまなポリシーを処理できます。例えば、認証、サービス転送、ヘルスチェックなどです。そのため、BeetoはAPISIXを導入した後、ビジネス実践レベルで多くの試みを行いました。

セキュリティ：認証プラグイン

南北トラフィック：Cookie

前述のように、パブリックネットワークユーザーのアクセストラフィックはゲートウェイを通過します。パブリックネットワークユーザーの認証は、Cookie認証に基づくユーザーリクエストです。ユーザーがCookieをゲートウェイに持ってリクエストすると、認証プラグインによって検証されます。

Cookie処理プロセス

上記のフローチャートに示すように、プラグインはまずローカライズ検証を実行し、その後、ポリシーに従ってリモートサービスの認証検証を実行します。リクエストがCookieチェックを通過すると、指定されたサービスに転送されます。

これを行う利点は2つあります：

ユーザーのCookieのセキュリティが確保されます。実行中にCookieを処理できるのはゲートウェイ層のみであり、Cookieは機密データであるためです。これにより、ビジネス処理ルールの不一致によるセキュリティ問題を防ぎ、人的要因や不規則性によるCookie漏洩を効果的に回避します。
サービスのCookie認証の複雑さを低減します。Cookieはローカルまたはリモートで検証する必要があり、Cookieがアップグレードされると同時にサービスのアップグレードも必要です。APISIXは統一的な管理と検証を行い、ビジネスサービスの検証コストを節約し、結果を示すことで、各ビジネス処理がビジネス自体に集中できるようにします。

東西トラフィック：Token

以下の図では、サービスAがサービスBを呼び出します。一般的に言えば、APIを呼び出すだけで十分です。しかし、内部プロセスでは、「誰がAPIを呼び出したか、どのように呼び出したか、権限をチェックする必要があるか、研究者を制御する必要があるか」などを理解する必要があり、これらは内部で処理される必要があります。

Token処理プロセス

APISIXゲートウェイを使用すると、このプロセスが大幅に簡素化されます。すべての内部サービスの相互呼び出しは、Auth認証サービスに登録するだけでよく、各サービスにAppキーが発行され、サービスのIDを示します。同時に、内部サービスの相互呼び出しもゲートウェイを通過します。ゲートウェイを通過してトークンを運ぶと、ゲートウェイはトークンプラグインを介してトークンを認証します。認証が通過すると、認証識別子が呼び出されたサービスに渡されます。このプロセス全体で、サービスシステムは認証登録を実行し、相互呼び出しを完了します。

Appキーのトークンルールのおかげで、上記の操作は呼び出し元を簡単にトレースでき、トラブルシューティングや権限制御に使用でき、不正な呼び出しを効果的に制御できます。したがって、統一的な認証の利点は、南北または東西トラフィックのいずれにおいても、クラスタのセキュリティと統一性を確保し、問題のトレーシングと呼び出し制御に大きく役立ちます。

スケーラビリティ：ステートレスサービスの拡張と移行

Beetoのクラスタの全体デプロイメントアーキテクチャは、上から下まで以下のように構成されています：APISIXゲートウェイクラスタ - ステートレスサービスのビジネスサービスクラスタ - ステートフルサービスのデータセンタークラスタ。中東でローカルにデプロイされると、これらはすべて主要なクラウドクラスタにデプロイされます。中東のクラウドカバレッジスケールと異なる地域のクラウドメーカーに応じて、サービスのデプロイメント時にクラウドサービスの拡張と移行を考慮する必要があります。

移行プロセスでは、Beetoはステートレスサービスの移行に重点を置きました。データセンターの移行コストが限られているため、動的な調整には適していません。ほとんどのリクエストはステートレスサービスによって処理されるため、ステートレスサービスが良好な拡張性を持つことが非常に重要です。

移行プロセス

Beetoのアーキテクチャでは、サービスの拡張性は主に2つの側面で反映されます：モノリシックサービスの拡張性と全体クラスタの拡張性。例えば、モノリシックサービスのリソースが不足し、拡張が必要な場合、APISIXゲートウェイは動的にノードを追加して拡張できます。同様に、クロスクラスタまたはクロスクラウドの状況では、複数のAPISIXゲートウェイをデプロイし、異なるサービスを異なるゲートウェイノードに移行することで、クラスタの拡張性を実現できます。

ビジネスサービスの場合、全体のアーキテクチャは変わらないため、ゲートウェイ層でさまざまなサービスの動的な拡張と縮小、およびサービスの移行を実現できます。このプロセス全体には明確な計画と目的があり、変更が発生しても全体のアーキテクチャが不安定になることはありません。

機能拡張性：サービスの動的転送

上記の一般的なゲートウェイシナリオに加えて、Apache APISIXはサービスの動的転送においてもBeetoに大きな支援を提供します。

アプリのUIとバックエンドに詳しい人なら、異なる製品ページが異なるサービスによって提供されていることを知っているでしょう。ページは異なるモジュールで構成され、その内容はすべてAPIから送信されます。APIがモジュールに送信するデータは、エンドでレンダリングされます。これは、クライアントサイドレンダリングプロセスをより汎用的にし、ビジネス処理をより柔軟にするための共通のクライアントサイドレンダリング仕様です。

PageABC

上記の図のPageAの実装では、クライアントがサービスAのAPIを呼び出し、対応するモジュールのデータを送信し、PageAのレンダリングを完了します。この操作により、クライアントは各ページと各サービスへのAPIを維持する必要があり、コンテンツが変更されると、公開によって解決する必要があるという問題が発生します。これは操作性と効率の面で非常に不便です。

上記の問題の解決策は、全体アーキテクチャでサービスの統一的な配信を実装することです。クライアントはまずAPIアドレスをリクエストし、このタイプのすべてのリクエストを1つのAPIに転送し、ゲートウェイレベルでリクエストパラメータとURLルールを処理し、配信プラグインを導入します。最後に、解析されたリクエストは設定ルールに従ってゲートウェイ層で指定されたサービスに直接転送されます。

ビジネス動的転送

クライアントは、データのソースではなく、レンダリング仕様を決定するだけで済みます。ゲートウェイ層はサービスの配信責任を担い、トラフィックを直接転送します。APISIXのプラグイン設定ファイルはリアルタイムで動的に更新でき、転送ルールを動的に調整できるため、非常に柔軟です。実際、BFF（Backend for Frontend）アーキテクチャのようなアプリケーションでは、このような要件はゲートウェイ層で解決できます。