Amazon Web Services ブログ

Piksel RetailによるAWS上のSAP Hybris Commerceのホスティング

Piksel Group_badge
Connect with Piksel-1
Rate Piksel-1

Piksel Retailのジェネラルマネージャーを務めるJonathan Kirby、同じくPiksel Retailのテクニカルアーキテクトを務めるMichal Stypikによる記事です。

多くの小売環境で、伝統的な方法として最もよく述べられるものに、SAP Hybris Commerceをプロダクションに導入していることがあります。Hybris Commerceは、インプレース方式のコードリリースにより、静的なクラスターとして実装されます。つまり、構成変更のために、実行中のサーバー上でファイルを置き換えたり更新したりする必要があります。アップデートには慎重なリリース計画が必要であり、ダウンタイムを適切に管理する必要もあり、現行ページの裏で変更を行わなければならず、プロセス全体が非常に混乱する恐れもあります。

いくつかの組織で、SAP Hybris Commerceをクラウドに移行することを選択していますが、「リフト・アンド・シフト」の方法を採用しています。これは、クラウドに移行はしたものの、その過程で再構築はしていないことを意味しています。その結果、プラットフォームはオンプレミス環境とほぼ同じように動作しています。

Pikselのグループ企業であるPiksel Retailでは、最近、これらの課題に対処するために、デジタルコマースチャネル (Digital Commerce Channel、DC2)を構築しました。DC2は、SAP Hybrisベースのeコマースソリューションで、Amazon Web Services (AWS)上に導入しています。

Piksel Groupは、Amazon CloudFrontのサービスデリバリーの認定を保有するAWS Partner Network (APN) アドバンスドコンサルティングパートナーです。私たちは、グローバルポートフォリオを持つ大規模な小売業者向けのクラウド・テクノロジー・ソリューションの設計、導入、そして運用管理を専門としています。Piksel Groupは、英国の小売業界で最もよく名前の知られているいくつかの企業と連携して、AWSクラウドが持つ生来のコスト、スピード、およびアジリティのメリットを活用しています。

Piksel RetailのDC2

DC2は、包括的なインフラストラクチャ管理、メンテナンスオーバーヘッドの軽減、そして顧客コードの迅速な開発と展開のためのプラットフォームを提供します。

DC2の目標は、クラウドに合わせてSAP Hybris Commerceを再構築し、弾力性やスケーラビリティなどのAWSクラウドの機能を利用した、より魅力的な方法でHybris Commerceを展開し、お客様に提供することです。これを実現するために、私たちはDC2を構築し、AWS上にHybris Commerceを導入するための、完全自動化されたインフラストラクチャ・アズ・コードのアプローチを採用しました。

インフラストラクチャとアプリケーションコードの両方の変更は、継続的デリバリーのパイプラインで管理されます。つまり、毎日本番環境に導入するわけではありません。単にアプリケーションやインフラストラクチャをいつでもどこでも展開できるようにプラットフォームを運用するだけです。Hybris Commerceプラットフォームとカスタム拡張に影響を与えるリリースは個別に管理します。

Hybris Commerceコンポーネントの迅速な展開

Hybris Commerceには、コンポーネント、アクセラレータ、およびバックオフィス環境を構成するためのインストールツールが付属しています。実際のサーバーのビルドは、通常、実行中のサーバーで開始されます。DC2はイミュータブル・インフラストラクチャとして構築されているため、コードリリースを適用するにはサーバーを再展開する必要があります。これは従来だと時間がかかるマニュアル作業ですが、DC2では自動化されており、オートスケーリング、自動化、セキュリティ、そして全体的に合理化された展開プロセスによって非常に便利になっています。

私たちが使用したツールの一つにTerraformがあり、迅速なインフラストラクチャの展開、コードのバージョニング、そして開発とブルー・グリーン・デプロイメントに必要なPhoenix環境の作成に役立ちました。

DC2のテンプレートでは、AWSのオートスケーリンググループも有効にできます。デフォルトではスケジュールされた水平スケーリングを使用しますが、現在は動的な需要ベースのオートスケーリングのソリューションに取り組んでいます。

SAP Hybris Commerceは、比較的長いスタートアップサイクルが必要な傾向があります。私たちのラボ環境でのデフォルトのインストールだと、起動まで5分以上かかっています。私たちは、Java Virtual Machine (JVM)の起動時間を短縮する方法に多額の投資を行い、店頭やバックオフィスなどのすべてのサーバーロールに対して1つのAmazon Machine Image (AMI)を構築しています。ストアフロントは、JVMの起動時間を劇的に短縮するために、バックエンドサービスなしで開始します。

私たちのロードマップでは、Kubernetes、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Container Service for Kubernetes (Amazon EKS)への展開など、ソリューションをよりダイナミックかつオンデマンドに改善できるソリューションを検討しています。また、ブルー・グリーン・デプロイメント (カナリアリリースを含む)とSAP / Hybrisノードのコールドスタートを排除するキャッシングのための追加機能も検討しています。

TerraformによるHybris ASG構築の例

module "hybris" {
  source = "git::ssh:/…/infrastructure-modules.git//hybris?ref=v0.1.6"
 
  stage        = "${var.stage}"
  default_tags = "${var.default_tags}"
 
  vpc_id          = "${data.terraform_remote_state.network_state.vpc_id}"
  private_subnets = "${data.terraform_remote_state.network_state.private_subnets}"
  public_zone_id  = "${data.terraform_remote_state.network_state.dns_zone_id}"
  private_zone_id = "${data.terraform_remote_state.network_state.dns_private_zone}"
  lb_frontend     = "${module.loadbalancers.hybris_frontend}"
  lb_backend      = "${module.loadbalancers.hybris_backend}"
 
  db_writer       = "${module.aurora.writer_endpoint}"
  db_reader       = "${module.aurora.reader_endpoint}"
  sessions_writer = "${module.elasticache_redis.dns_endpoint}"
 
  additonal_security_groups = [
    "${module.aurora.aurora_security_group}",
    "${module.elasticache_redis.security_group}",
    "${module.efs.efs_security_group}",
  ]
 
  blue_version       = "${var.blue_version}" # build number, AMI ID lookup
  green_version      = "${var.green_version}" # build number or latest AMI
  backoffice_version = "${var.backoffice_version}" # build number
  released_version   = "${var.released_version}" # blue or green
}

SAP Hybris Commerceプラットフォームとカスタム拡張は、HashiCorpのPackerビルドを実行するデリバリーパイプラインで事前生成されたAMIにより構成されています。すべての環境で同じテンプレートが使用され、本稼働環境にも展開されます。環境の違いは、AWS Systems Manager パラメータストアで管理される機密情報に特化したカスタム変数によって制御され、ユーザーデータのスクリプトを介してシステムの起動時に処理されます。

SAP Hybris Commere-1

図 1 – Hybris Commerceのビルドパイプライン

AWSコンポーネント

DC2では、静的コンテンツと動的コンテンツの両方のためのAWS CloudFrontの背後にストアフロントが展開されます。Application Load Balancerは、Hybris Commerceノードにトラフィックを送信する起点となっています。Apacheなどのプロキシサーバーはオプションで使用できますが、可能な限り、DC2はウェブ層なしで展開されます。

望ましいキャッシング層はAWS CloudFrontで実現し、AWS Lambda@EdgeをHTTPリダイレクトやメンテナンスページの提供、または特定の要求を別のオリジンに送信するなどのウェブサーバー機能の置き換えに使用しています。この特定の機能は、ブルー・グリーン・デプロイメントにも使用できます。CloudFrontは、OSWAP Top 10に対する保護を提供するShield AdvancedやAWS WAFと連携し、不要なトラフィックをブロックし、管理用のエンドポイントやプリプロダクション環境へのアクセスを保護します。

ウェブプロキシが必要な場合、DC2ではオプションのApacheウェブ層が利用できます。フロントエンドのロードバランサは、Hybris Commerceノードに直接ではなくウェブノードに要求を送信し、別の内部向けロードバランサがウェブのバックエンドとして使用されます。Hybris ASGは、ロードバランサのHybrisターゲットを自動的に更新するため、Hybrisノードを削除または追加する際にApacheの設定を更新する必要はありません。

SAP Hybris Commerceの推奨は、静的なクラスターで正常に動作するスティッキーセッションを使用することですが、これはオートスケーリングされた動的なシステムでは問題になります。DC2では、ウェブ層が追加されたときに、スティッキーを使用した設計はサポートしていないですが、AJPプロトコル (Hybrisの推奨)を使用できるNetwork Load Balancerで構成しています。また、スティッキーが必要な場合は、ウェブノードとHybrisを接続する別の内部向けApplication Load Balancerを配置することもできます。

デフォルトのDC2のインストールでは、Amazon AuroraのMySQL互換データベースが実行されます。Auroraは、それが提供する高可用性、パフォーマンス、スケーラビリティ、そして安全性といったメリットから選択しています。詳細は、SAP Hybris Commerceの認定を受けているAmazon Aurora Databaseに関するブログ記事を参照してください。Hybrisによって提供される構成設定であるスレーブの読み取りデータソースを使用して、リーダーエンドポイント (Aurora レプリカ)にインデックスやレポート出力などの多くの追加タスクが接続されていますが、アプリケーションはライターエンドポイントに接続されています。

ユーザーセッションは、SAP Hybrisサーバーから外部のデータストア、つまりRedis 用 Amazon ElastiCacheにエクスポートされます。動的クラスタリングとオートスケーリングが可能で、Hybrisノードはユーザーセッションを失うことなく終了することができます。デフォルトのHybrisのインストールでは、外部の集中管理されたセッションストレージはサポートされていませんが、Tomcatのコンテキストを更新することで追加できます。

他のカスタマイズと同様に、この更新はPacker AMIのビルドプロセスの一部であり、必要なライブラリを追加し、必要な設定を追加し、値を動的に変更できるようにしています。ElastiCacheのRedisクラスターは、DC2のTerraformコードのオプションコンポーネントです。

Redisにユーザーセッションを保存するための追加機能

yacceleratorstorefront.tomcat.context.Valve.className=com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve
yacceleratorstorefront.tomcat.context.Manager.className=com.orangefunction.tomcat.redissessions.RedisSessionManager
yacceleratorstorefront.tomcat.context.Manager.host=<CHANGE_ME>
yacceleratorstorefront.tomcat.context.Manager.port=6379
yacceleratorstorefront.tomcat.context.Manager.database=0
yacceleratorstorefront.tomcat.context.Manager.expireSessionsOnShutdown=false
yacceleratorstorefront.tomcat.context.Manager.notifyListenersOnReplication=true

秘密情報を保護したり、エンドポイントやデータベースのパスワードといった環境の差異に使用できる特別なプロパティ値<CHANGE_ME>に注意してください。また、システムが起動しない場合、変数が設定されていることを確認する必要があります。

SAP Hybrisのメディアファイルは、一般的にローカルに保存されます。ネットワークストレージは、Amazon Elastic File System (Amazon EFS)などの従来のマルチノード構成を使用しますが、DC2の動的なアーキテクチャでは、クラウドネイティブのソリューションを使用することをお勧めします。メディアの場合、Amazon Simple Storage Service (Amazon S3) バケットに格納し、CloudFrontの静的なウェブディストリビューションを使用して配信することをお勧めしています。

DC2へのお客様環境の展開は、Piksel Retailのマネージドサービスとしてサポートされます。通常、Amazon CloudWatchの統合を使い、Datadog、AppDynamics、Dynatraceなどの高度なサードパーティ製ツールを組み合わせて基本的な監視を行います。CloudWatchで生成されたアラートは、Amazon Simple Notification Service (SNS)経由でAWS Lambda関数に送信されます。この関数は、PikselのPlatform Operations Manager (POM)にチケットを記録し、オンコールエンジニアに警告を促すイベントを通知します。

DC2のインフラストラクチャの構成図

SAP Hybris Commere-2.1

図 2 – DC2のインフラストラクチャの構成図

DC2の利点

DC2は、SAP Hybris Commerceをクラウドに移行する際の効果を高めるために設計されています。それは、4つの重要な問題に取り組むことによって実現しています：

  • 静的なクラスター: 静的なクラスターから解放されると、ノードの動的な削除と追加が可能になり、オートスケーリングが可能になります。
  • ピーク処理に対応できるインフラストラクチャの過剰な調達: オートスケーリングにより、Hybrisユーザーはスケーリングコストを最適化しながら、あらゆる要求を満たすことができます。
  • インプレースでの展開: これにより、アーティファクトを構築する新しい方法が作成され、展開時間が短縮できます。
  • 現行ページの裏でのコードリリース: ブルー・グリーン・デプロイメントにより、現行ページが不要なコードリリースが可能になり、停止時間がほとんど、または全くなくなります (つまり、読み取り専用の操作が許可されます)。

まとめると、DC2はAWS上でSAP Hybris Commerceを迅速に移行、および展開することを可能にします。

このブログの内容や意見はサードパーティの著者のものであり、AWSはこの記事の内容や正確さについての責任は負いません。

.

 Piksel Group_card logo
 AWS Service Delivery_biz cards-2

Piksel Group – APNパートナースポットライト

Piksel Groupは、APNアドバンスドコンサルティングパートナーです。彼らの目標は、変革を促進し、拡張可能なセキュアなソリューションを実装することです。Pikselは、小売、メディア、放送、輸送、医療、新興企業、テレコムを専門としています。

Pikselへの問い合わせ | 会社概要

*既にPikselと連携されていますか？ Pikselを評価することができます

*APNパートナーを評価するには、そのAPNパートナーとプロジェクトで直接関わったことのあるAWSのお客様でなければなりません

翻訳はPartner SA 河原が担当しました。原文はこちらです。