ECサイト/アプリに最適なアーキテクチャを考える - 導入
はじめに
この記事は、ECサイト/アプリに最適なアーキテクチャを考えるところからスタートし、実際にシステムのアーキテクチャの検討を行うまでをまとめたものです。
テーマが多岐にわたるため、いくつかの記事に分けてシリーズ化して解説していきます。
なお、この記事は特定の企業やサービスを対象にしたものではなく、一般的なECサイト/アプリを前提として議論を進めています。
すべてのECサイト/アプリに当てはまるわけではないことをご了承ください。
ECに最適なアーキテクチャとは
大規模な総合ECサイト以外で、企業が独自にECサイトやアプリを構築する場合、モノリシックなアーキテクチャ構成が採用されていることが多くあります。特に既存システムでは、この傾向が顕著です。
パブリッククラウドが一般化し、サーバーレス構成が可能になった現在でも、モノリシックな構成を継続採用しているケースは多く見られますが、果たして本当に最適なアーキテクチャなのでしょうか。
モノリシックな構成は、シンプルでわかりやすい反面、以下のような課題があります。
- スケーラビリティの制限
- ある一部の機能のみが高負荷になる場合、その機能だけをスケールアップまたはスケールアウトすることが難しく、アプリケーション全体をスケールアップまたはスケールアウトする必要があります。
- 多数の機能を有したモノリシックアプリケーションは、スケーリングに時間を要したり、規模が大きくなりがちでリソースの無駄遣いにつながることがあります。
- 開発の複雑化
- アプリケーションの管理単位が大きくなるにつれ、コードベースの依存関係も複雑になります。
- アプリケーションのコード規模が大きくなると共通処理などの設計要素が増えることになり、結果としてテスト工数の増加が発生します。
- 障害の影響範囲の拡大
- アプリケーションの一部で障害が発生すると、アプリケーション全体に影響を及ぼす可能性があります。
- 特に性能問題などの非機能への影響が多く発生することがあります。
- アプリケーションの一部で障害が発生すると、アプリケーション全体に影響を及ぼす可能性があります。
これらの課題を解決するために、マイクロサービスアーキテクチャ（MSA）の採用が検討されることがありますが、マイクロサービスアーキテクチャにも以下のような課題があります。
- サービス間通信の複雑化
- サービス間の通信が増えることで、ネットワークの遅延や障害が発生する可能性があります。
- サービス間の通信を管理するために、APIゲートウェイやサービスメッシュなどの追加のインフラストラクチャが必要になることがあります。
- データの一貫性の確保
- 各サービスが独自のデータストアを持つ場合、データの一貫性を確保することが難しくなります。
- 分散トランザクションの管理が複雑になることがあります。
単一のビジネスのみを展開している企業であれば、マイクロサービスアーキテクチャ（MSA）の検討も比較的容易ですが、
複数のビジネスを展開している企業では、マイクロサービスアーキテクチャ（MSA）を採用することが困難な場合があります。
理由の1つとして、業務領域が多数存在し、適切なドメイン境界を定義することの難しさが挙げられます。
これらの課題をすべて解決することはできませんが、主要な課題にアプローチしつつ、変化する市場・業務要件に追従でき、
かつアーキテクチャ自体も継続的に進化させられるような、柔軟性を備えたアーキテクチャを検討していきます。
アーキテクチャ設計におけるコストの重要性
ECサイト/アプリのアーキテクチャを考える上で、コストを意識することは非常に重要です。
特に、スタートアップや中小企業にとっては、限られた予算内で最大の効果を得ることが求められます。
ECにおいては、1つの商品が売れることに対してどれくらいのシステムコストがかかるのかを意識してアーキテクチャを検討する必要があります。
例えば、月間100万円の売上を目指すECサイトの場合、月間10万円のインフラコストは売上対比10%で許容できる範囲と考えられますが、月間50万円のインフラコストでは売上対比50%となり、ビジネス継続性の観点で問題となる可能性があります。
理想的なのは、売上とシステムコストの比率を一定に保てるアーキテクチャです。例えば「売上の1%をシステムコストの上限とする」といったルールを設定し、
ビジネスが拡大するにつれてシステムもスケールアウトしながら、コスト比率を一定に保てるようなアーキテクチャが望ましいでしょう。
データからのアプローチ
ECに流れるデータについて考えてみる
ECでは、ユーザーがサイトまたはアプリに訪れ、商品（服・家電・食品など）を選択し、購入するという一連の流れがあります。
この流れで扱われるデータは、サイトごとに詳細は異なりますが、おおむね以下の種類のデータが存在すると考えられます。
| データの種類 | 内容 | 不特定多数アクセス要否 | 検索性要否 |
|---|---|---|---|
| 商品データ | ECが販売している商品のデータ。 | ◯ | ◯ |
| ユーザーデータ | ユーザー固有のデータ | × | × |
| カートデータ | ユーザーが商品を購入する候補として選んでいる、または選んだデータ | × | × |
| 注文データ | ユーザーが購入した商品、配送状況などのデータ | △ | ◯ |
ECのコア業務領域（バックオフィスやマーケティングを除く）において、商品にまつわるデータ以外は、不特定多数がアクセスしたり検索性が求められるデータは比較的少ないことがわかります。
商品データの閲覧・展示機能はECにおいて極めて重要な業務であり、機能・非機能の両面で最も高い要件が求められます。
そのため、技術的な制約を受けることなく、ビジネス要件を柔軟に実現できるアーキテクチャが望ましいといえます。
一方、その他のデータは、一度業務フローが整理できれば、サービスの業態が大きく変わらない限り大幅な変更は発生しにくい特徴があります。
サービス業態の変化とは、例えば「宅配便による配送のみ → 店舗受け取りサービス追加」「従来配送 → ドローン配送対応」といった変化を指します。
このような大きな変化が発生する場合、企業として戦略的な意思決定と相応の予算投下を伴うことが一般的であり、
ECシステムにおいても一定規模の改修が必要になることは許容される傾向にあります。
ECに流れるデータの管理方法を考えてみる
前述したECで扱うデータの特性を踏まえ、それぞれに適した管理方法を以下のように整理しました。
| データの種類 | 管理方法 | 理由 |
|---|---|---|
| 商品データ |
RDB or RDB + 検索エンジン
|
不特定多数からのアクセスが多く、検索性も求められるため。 |
| ユーザーデータ | NoSQL |
不特定多数からのアクセスはなく、検索性も求められないため。 |
| カートデータ | NoSQL |
不特定多数からのアクセスはなく、検索性も求められないため。 |
| 注文データ |
RDB or NoSQL
|
不特定多数がアクセスすることは少ないが、検索性は求められるため。 |
AWSサービスに当てはめると、RDBはAmazon AuroraやAmazon RDSなどのリレーショナルデータベース、NoSQLはAmazon DynamoDBなどのNoSQLデータベースが該当します。
検索エンジンにはAmazon OpenSearch Serviceなどが利用可能です。
機能からのアプローチ
ECに必要な機能を考えてみる
ECに必要な機能は多岐にわたりますが、コアな業務領域に絞って考えると以下のような機能が必要になると思います。
| 機能 | 内容 |
|---|---|
| 商品管理 | 商品データの登録、更新、削除、検索などの機能。 |
| ユーザー管理 | ユーザーデータの登録、更新、削除、認証、認可などの機能。 |
| カート管理 | カートデータの登録、更新、削除、取得などの機能。 |
| 注文管理 | 注文データの登録、更新、削除、検索、注文処理などの機能。 |
| 決済管理 | 決済処理、支払い方法の管理、返金処理などの機能。 |
| 配送管理 | 配送方法の管理、配送状況の追跡、配送業者との連携などの機能。 |
これらの機能は、同期処理が必要なものと、非同期処理でも問題ないものに分類できます。
商品管理やユーザー管理は同期的な処理が求められますが、注文管理や決済管理は非同期処理でも十分対応可能な場合があります。
むしろ非同期処理を採用することで、システムのスケーラビリティや耐障害性を大幅に向上させることができます。
また、配送管理は非同期処理が適しています。配送業者との連携は外部システムとの統合が必要で、外部システムの応答時間に依存するためです。
ECに必要な機能の実装方法を考えてみる
前述したECに必要な機能の特性を踏まえ、それぞれの実装方針を以下のように整理しました。
| 機能 | 管理方法 | 性能 | 理由 |
|---|---|---|---|
| 商品管理 | 同期 |
高 | ユーザーの買い物体験の多くがこの機能によって提供されるため。 |
| ユーザー管理 | 同期 |
中 | 確実性、セキュリティ面の要求が高い機能。暫定ログイン状態にするなどはできないので同期処理となる。 |
| カート管理 | 同期 |
高 | ユーザーの買い物体験の多くがこの機能によって提供されるため。 |
| 注文管理 | 非同期 |
低 | 確実性、セキュリティ面の要求が高い機能。バックエンドで処理可能。 |
| 決済管理 | 非同期 |
中 | 確実性、セキュリティ面の要求が高い機能。また、外部の決済サービスとの連携が必要な場合が多く、応答時間に依存するため。 |
| 配送管理 | 非同期 |
低 | 確実性、セキュリティ面の要求が高い機能。また、外部の配送業者との連携が必要な場合が多く、応答時間に依存するため。 |
アーキテクチャの検討
具体的なアーキテクチャの検討に入ります。
同期 & 非同期を組み合わせたアーキテクチャを考える
前述した機能要件の分析結果を踏まえ、同期処理と非同期処理を組み合わせたハイブリッドアーキテクチャを考えました。
同期処理は、ユーザーの購買体験に直結する部分であり、レスポンス性能と即時性が重要です。
一方、非同期処理は、バックエンドで実行可能な業務処理であり、確実性を重視し即時性の要求はそれほど高くありません。
このように同期処理と非同期処理を適切に使い分けることで、システム全体のスケーラビリティと耐障害性を大幅に向上させることが可能になります。
同期処理は、モバイルアプリなどのフロントエンドUIからのリクエストを受けて、処理完了まで待機し、処理終了後にレスポンスを返す方式です。
オンライン非同期処理は、フロントエンドからのリクエストを受け付けた後、即座にレスポンスを返し、実際の業務処理はバックエンドで非同期実行する方式です。
バッチ非同期処理は、ユーザー操作を直接のトリガーとしない、定期実行や他システム連携などのバックエンド処理を指します。
非同期とはどういうことか
非同期処理について、より具体的なアーキテクチャパターンを考えてみます。最もシンプルな実装例として、Amazon SQSを活用したProducer-Consumerモデルが挙げられます。
例として、ユーザーがお気に入り商品を登録する機能を考えてみます。
ユーザーのお気に入り情報はRDBに同期的に保存される一方、「お気に入り登録」というイベントをトリガーとして、以下のような後続処理が非同期で実行されます：
- 商品の人気度スコアの更新
- レコメンドエンジンへの学習データ送信
- マーケティング分析用データの蓄積
このようなケースで、SQSを介した非同期処理アーキテクチャが効果を発揮します。
※実際の本格運用では、エラーハンドリング、リトライ制御、デッドレターキューなど、より多くの考慮事項があることを付け加えておきます。
今後は、より具体的なアーキテクチャの設計や実装に進んでいきます。
おわりに
本記事を最後まで読んでいただき、ありがとうございました。
今回は、ECサイト/アプリのアーキテクチャ検討における導入編として、データの特性と機能要件の観点から、同期・非同期処理を組み合わせたアーキテクチャの考え方をご紹介しました。
次回以降の記事では、より具体的な実装方法や運用面での考慮点について深掘りしていく予定です。引き続き、シリーズをお楽しみいただければ幸いです。
Discussion