消費財業界においてマイクロサービスアーキテクチャに移行するための成功戦略

以前のブログ投稿（DTC e コマースサイトをモダナイズするための3つのステップ）では、消費者向け（Direct-to-consumer; DTC） e コマースサイトをモダナイズするための3つの戦略について共有しました。

DCT e コマースサイトを AWS にリフト＆シフトする
e コマースサイトのアーキテクチャを分解しマイクロサービス化する
サーバーレスコンピューティングに移行し、ビジネスに集中する

なぜ消費財業界においてマイクロサービスなのか？

このブログでは、マイクロサービスアーキテクチャを適用してウェブサイトを再設計するための戦略について詳しく説明します。消費財企業にとっては非常に関心の高いことです。まず DTC ウェブサイトがモノリスな、かつ、レガシーテクノロジーで構築され、開発チームと DBA チームによって管理されているという前提で話を進めます。クラウドテクノロジーが出現し主流となったところに、パンデミックによる混乱が引き起こされたことで、企業ブランドはこれまで以上に柔軟で俊敏な e コマースサイトを必要とするようになりました。

従来の e コマースサイトには柔軟性が欠けています。マイクロサービスを適用することで、製品カタログなどの各プロセスは独立したコンポーネントとして設計、開発されます。さまざまなマイクロサービス同士が API を介して相互に通信します。このモダンなデザインでは、バグの修正や新しいウェブサイト機能の提供をより迅速に実行でき、それにより顧客体験は向上し、ビジネスは差別化され、最終的に収益の増加に繋がります。

e コマースアプリケーションを見直すための戦略

マイクロサービスを適用して e コマースサイトを再設計するためには、慎重な計画が必要です。まず、ウェブサイト機能をマイクロサービスとして再構築するにあたっての優先順位付けを行います。各アプリケーションプロセスを特定し、マイクロサービスで機能を再構築するための計画段階であり、私はこのプロセスを分解と呼んでいます。

典型的な e コマースウェブサイトに含まれているコンポーネントは以下のようなものです：

ホームページ
製品検索
製品カタログ
製品価格
プロモーション
支払い
製品在庫
ユーザープロファイル
ショッピングカート
チェックアウト処理
静的コンテンツ
店舗案内
パーソナライズされたコンテンツ、パーソナライゼーション

上記のような機能を、簡単にキャッシュできる機能（あるいは本質的に静的な機能）と、簡単にキャッシュできない機能（より動的な機能）に分類します。次のように2つのグループに分類しました：

Group 1: 簡単にキャッシュできる機能

ホームページ
製品検索
製品カタログ
製品価格
静的コンテンツ
店舗案内

Group 2: 簡単にキャッシュできない機能

プロモーション
支払い
製品在庫
ユーザープロファイル
ショッピングカート
チェックアウト処理
パーソナライズされたコンテンツ、パーソナライゼーション

いきなり大きく始めないこと！

あるいはやりすぎないこと、という表現でも構いません。今回のブログでお伝えしたいのは、 e コマースサイト全体を一気に再設計しないでください、と言うことです。じっくりと計画し、段階的に作業を行ってください。マイクロサービスを適用した新しいウェブサイトを構築する間も既存のレガシーな e コマースサイトを運用できるようにしておくためです。

私のお薦めのロードマップは次のとおりです: ホームページ、製品カタログ、製品検索、検索結果ページといったいくつかのフェイスリフト（訳者註: 主に見た目のマイナーチェンジ）から始めるといいでしょう。いずれも前述の Group 1 に分類したものであることにお気づきでしょうか。ジャーニーを始めたばかりでも、これらの要素をマイクロサービスとして再設計し始めたばかりだとしても、消費者目線ではまったく新しいウェブサイトを手に入れたような印象を与えることができます。

顧客体験を向上させるべくページの応答時間を改善する必要がある場合は、Group 1 の機能性にも焦点を当てることをお薦めします。最も影響が大きいと思われる機能を特定し、それらを独立したマイクロサービスコンポーネントとして再構築して提供します。ウェブサイトから直接あるいは、API 呼び出しを介して呼び出せるようにします。

なぜそのような戦略をとる必要があるのか

なぜ Group 2 ではなく Group 1 から始めるのか疑問に思われるかもしれません。まず、一般的に Group 1 の機能は互いに独立していることが多いということ。そしてこれらの機能は多くの場合、検索エンジンやキャッシュシステムなどの別のアプリケーションによってサポートされているため、e コマースアプリケーションから比較的移動しやすいことが理由です。

そして最も重要なこととして、Group 1 の分解・再構築から取り組むことで、開発チームが他の依存関係を気にすることなく、AWS 上で使い慣れた言語でコードを書くことを学ぶ機会が得られる点が挙げられます。 AWS 仮想サーバー上のアプリケーションを管理するための AWS 共有責任モデルについても詳しく知ることができます。

さらに、Amazon Elastic Kubernetes Service（Amazon EKS）や Amazon Elastic Container Service（Amazon ECS）などの AWS サービスを使用してコードをコンテナ化することもできます。どちらも、マイクロサービスアーキテクチャをネイティブにサポートする、マネージドコンテナオーケストレーションサービスを提供するものです。スケーラビリティ、復元力、およびセキュリティも提供します。 Duolingo、Intel、Autodesk、General Electric などのお客様で本番環境のワークロードにこれらのサービスが利用されています。

チームがこの戦略の手順を体系的に実行することで、e コマースサイト全体がマイクロサービスで機能するようになります。組織は、サーバーやデータベースの管理といった「他との差別化につながらない重労働」ではなく、DevOps のような他の最新の開発方法を活用する道を進んでいくことになるでしょう。

AWS for CPGの詳細については、AWSアカウントチームにお問い合わせください。

著者について

Danny Yin

Danny（Yen-Lin）Yin は、消費財業界における AWS パートナーのグローバルテクニカルリードです。 e コマースアプリケーションの開発と運用に18年の経験を持ち、2018年に AWS に入社しました。Danny は、消費財企業が消費者に提供するデジタルユーザーエクスペリエンスを向上させ、さまざまな事業分野で運用効率を高める支援をしています。 Danny は、 AWS における消費財業界テクノロジーと、コンサルティングパートナーのソリューションアーキテクチャと技術支援も担当しています。 AWS 以前は、トイザらスでデジタルエンジニアリングのディレクターを務め、アウトソーシングしていた世界最大の玩具ウェブストアを、オンプレミスと AWS のハイブリッドクラウドのアプリケーションへと自社開発で移行することに成功しました。

翻訳は Solutions Architect 杉中が担当しました。原文はこちらです。

Amazon Web Services ブログ